VonOx
17. Mai 2022 um 08:23
42
Für mich ist das codiert
COVER_STATE,
SIREN_LMH_VOLUME,
SIREN_MODE,
PILOT_WIRE_MODE,
LIQUID_STATE,
WATER_VALVE_CURRENT_DEVICE_STATUS,
CONTAMINATION_STATE,
STATE,
} = require('../../../utils/constants');
// Sirens naming their melodies "melody_1", "melody_2"… instead of publishing a plain number:
// the number is the Gladys value, and the expose list says which melodies the siren really has.
const MELODY_NAME = /^melody_(\d+)$/;
const WRITE_VALUE_MAPPING = {};
const READ_VALUE_MAPPING = {};
const addMapping = (exposeName, gladysValue, z2mValue) => {
const writeExposeMapping = WRITE_VALUE_MAPPING[exposeName] || {};
writeExposeMapping[gladysValue] = z2mValue;
WRITE_VALUE_MAPPING[exposeName] = writeExposeMapping;
Ich habe es nicht selbst getestet
Muss man keinen numerischen Wert angeben?
Psoy
17. Mai 2022 um 09:21
44
Airtable ist bereits enthalten (auch wenn eine Funktion fehlt)
Ich habe mich falsch ausgedrückt.
Psoy
17. Mai 2022 um 09:31
46
ich bestätige keinen langen Tastendruck auf Gladys, aber im Dashboard z2Mqtt OK
Psoy
17. Mai 2022 um 09:40
47
VonOx:
Für mich ist das codiert
Hallo @VonOx @Tlse-vins schreibt
VonOx
17. Mai 2022 um 09:52
48
Das sind dieselben Konstanten, um die Seite von Gladys zu vereinheitlichen
const BUTTON_STATUS = {
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
LONG_CLICK: 5,
};
Psoy
17. Mai 2022 um 10:21
49
Super
VonOx
17. Mai 2022 um 14:56
50
Okay, der Sonoff sendet „long“, ich weiß nicht, wie ich das mit den Switch-Cases handhaben soll (cc @AlexTrovato @pierre-gilles )
Was ich immer gesagt habe, ist, dass diese Werte niemals dem Benutzer präsentiert werden sollten, das ist nicht die Philosophie dieser v4!
Statt manuell 1, 2, 3 oder 4 einzugeben, sollte der Benutzer einfach einen Selektor in den Szenen sehen, so etwas wie das:
(ist nicht codiert, nur ein Mockup)
So muss sich niemand an diese Konstanten erinnern, die nur interne „Kochkunst“ sind
Ich wäre offen für einen PR zu diesem Thema
VonOx:
Okay, der Sonoff sendet „lang“, ich weiß nicht, wie ich das mit den Switch-Cases handhaben soll (cc @AlexTrovato @pierre-gilles )
Auf den ersten Blick denke ich, dass du den readValue ändern musst:
const READ_VALUE_MAPPING = {};
const addMapping = (exposeName, gladysValue, z2mValue) => {
const writeExposeMapping = WRITE_VALUE_MAPPING[exposeName] || {};
writeExposeMapping[gladysValue] = z2mValue;
WRITE_VALUE_MAPPING[exposeName] = writeExposeMapping;
const readExposeMapping = READ_VALUE_MAPPING[exposeName] || {};
readExposeMapping[z2mValue] = gladysValue;
READ_VALUE_MAPPING[exposeName] = readExposeMapping;
};
addMapping('action', BUTTON_STATUS.CLICK, 'single');
addMapping('action', BUTTON_STATUS.DOUBLE_CLICK, 'double');
addMapping('action', BUTTON_STATUS.HOLD_CLICK, 'hold');
addMapping('action', BUTTON_STATUS.LONG_CLICK, 'long');
addMapping('action', BUTTON_STATUS.ON, 'on');
addMapping('action', BUTTON_STATUS.OFF, 'off');
addMapping('action', BUTTON_STATUS.ON_DOUBLE, 'on_double');
addMapping('action', BUTTON_STATUS.OFF_DOUBLE, 'off_double');
Ich überlasse es @AlexTrovato , das zu bestätigen.
pierre-gilles:
Das, was ich immer gesagt habe, ist, dass diese Werte dem Benutzer niemals angezeigt werden sollten, das ist nicht die Philosophie von dieser v4!
Ich bin deiner Meinung, wenn alle Klicks codiert sind, muss man die Werte nicht kennen.
VonOx
17. Mai 2022 um 16:39
53
Alles klar, bei readValue gibt es kein Problem, also wird writeValue in diesem Fall bei den Schaltflächen nie verwendet?
Ich versuche zu verstehen
Ich bin nicht der Autor des Codes, also kann ich es nicht genau sagen, aber ich denke tatsächlich, dass im Fall eines Sensors, der nie gesteuert wird, nur der readValue nützlich ist.
VonOx
17. Mai 2022 um 16:50
55
pierre-gilles:
Das, was ich immer gesagt habe, ist, dass diese Werte dem Benutzer nie angezeigt werden sollten, das ist nicht die Philosophie von v4!
Statt manuell 1, 2, 3 oder 4 einzugeben, sollte der Benutzer einfach einen Selektor in den Szenen sehen, so etwas wie das:
+1
Ich würde mich gerne mit dem Thema beschäftigen, was wäre die Logik dahinter? Einfach eine Anzeige auf der Frontend-Seite oder etwas Komplexeres auf der Backend-Seite?
Ich habe auch den Fall beim Lixee Tic, er gibt die aktuelle Tarifierung zurück (Werttext HP HC usw.), also interessante Dinge, die in den Szenen genutzt werden können.
Es lohnt sich, ein eigenes Thema dafür zu erstellen.
Es geht nur um die Anzeige, ja! Danach nichts Neues, wir machen das schon für viele Typen:
Binär:
Anwesenheitsgerät:
Sensor mit Einheit:
Die Idee ist, dass wir in der UI niemals Werte anzeigen, die unsere interne „Küche“ sind. Wir zeigen immer ein schönes, übersetztes und leicht verständliches Component.
Es fehlt nur noch ein Component für Druckknöpfe wie die von Xiaomi.
Danach muss sichergestellt werden, dass nur dieser Knopf als solcher klassifiziert wird. Man muss wissen, woran man in der UI die Unterscheidung vornehmen muss.
VonOx
18. Mai 2022 um 07:36
57
Zuerst ein Pull Request zur Verwaltung des Buttons
master ← VonOx:z2m-sonoff-button
ouvert 07:34AM - 18 May 22 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fa… st as possible, make sure to review and check all of these items:
- [X] If your changes affects code, did your write the tests?
- [X] Are tests passing? (`npm test` on both front/server)
- [X] Is the linter passing? (`npm run eslint` on both front/server)
- [X] Did you run prettier? (`npm run prettier` on both front/server)
- [ ] If you are adding a new features/services, did you run integration comparator? (`npm run compare-translations` on front)
- [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to [the community](https://community.gladysassistant.com/) for testing before merging.
- [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code)
- [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com).
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com).
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
This PR provide support for Sonoff SNZB-01 button
https://community.gladysassistant.com/t/bouton-sonoff-snzb-01/6812/50?u=vonox
I've updated `BUTTON_STATUS` constants to use the same wording of the feature value
@VonOx der PR bricht die Abwärtskompatibilität für den LONG_CLICK, der von 5 auf 6 wechselt
VonOx
18. Mai 2022 um 17:01
59
Der alte Long wurde zu Hold, also nein (der Wert Hold z2m war auf Long gemappt, das ergab keinen Sinn) => Daher erschien es mir logisch
Soll ich trotzdem umkehren?
Kein Problem mit dem Variablennamen (das ist unser interner Code), aber der numerische Wert muss gleich bleiben (außer bei einer Migration).
Wenn jemand eine Szene kaputt gemacht hätte, indem er manuell 5 eingegeben hat, weil er gemerkt hat, dass 5 funktioniert, dann ist diese Szene mit diesem PR kaputt, und das müssen wir auf jeden Fall vermeiden!
Es muss nur sichergestellt werden, dass das Verhalten von 5 gleich bleibt.
VonOx
18. Mai 2022 um 17:20
61
Vor meinem PR
Z2m sendet « hold » => Gladys LONG_CLICK => 5
Mein PR:
Z2m sendet « hold » => Gladys HOLD_CLICK => 5
Eigentlich sehe ich nicht, was das kaputt macht, da
.
