![]() I'll fix the 100s to be something more appropriate, but I don't think they're the actual source of this problem. The value ID is constructed like this in the server lib: Where do you see the hex/dec mixup in the script (or rather: in the log)? Timestamp T10:37:35.222Z Not sure if the automation converts strings to hex somehow? The property key sent to zwave-js should be the number 10. The gist correctly mentions that property 10 (hex 0x0a) is armed stay, but the automation sends 16 (hex 0x10). There seems to be some mixup between hexadecimal and decimal in the automations. I don't think that this sequence is complete, What was asking about is around the time the Entry Delay indicator is set after the door opens (around timestamp T11:01:59.951Z). is something that probably more related to how the driver handles S2 communication. need to be fixed in the blueprint/automation, 3. This is very likely contingent and not something that is directly caused by the automation (a delay somewhere might make it less likely, but I don't understand the situation well enough to judge that). In the logfile, an S2 collision has happened.The wrong property key is sent in at least one case apparently (maybe a hex/dec mixup).Some parameters in the blueprint are invalid (100 instead of 99 for multilevel indicators - not sure if that is volume or brightness in this case).If I understand correctly, there are three separate issues: Assuming that's the issue, maybe just add a small delay before sending the indicator? My guess is that the keypad by the door I usually use has the old firmware version without motion sensor reports, so there's not going to be a race between a motion sensor report and the "Entry Delay Started" indicator. I haven't noticed anything like the behavior being described here, but I can certainly believe there's some environmental difference. This could be one source of the issue - that the keypad does not receive an expected command. Note that 100 is not a valid value for multilevel things in Z-Wave, the maximum is 99 or 255 for last non-zero value. Keypad -> Z-Wave JS: Entry Control (ArmHome).Z-Wave JS -> Keypad: Indicator (Exit Delay, 180s) Z-Wave JS -> Keypad: Indicator (Bypass challenge, multilevel, 100). Keypad -> Z-Wave JS: Entry Control (ArmAway).Z-Wave JS -> Keypad: Indicator (Not armed, multilevel, 100). Keypad -> Z-Wave JS: Entry Control (Enter).I see the following sequences (omitting duplicates): ![]() I'm also not sure of the intended interaction here. What I don't quite understand yet is the IndicatorCCSet that gets sent to the keypad after entry control notifications. Each command from the keypad is supervised an Z-Wave JS responds. So I looked at the communication between the keypad and Z-Wave JS, and that seems rock stable. Zwavejs2mqtt branch: latest (6.15.1) Did you change anything?ĭon't know, this is a new device If yes, where did it work?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |