Closed darkbasic closed 3 years ago
robertsLando
commented
3 years ago I dunno what you mean with "mixing it up" but I'm just calling the controller methods as you see in the logs, I don't cache anything about associations 😕
About the empty string bug I will fix it tomorrow thanks
AlCalzone
commented
3 years ago I mean this specifically:
z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of Node 2 +4s
The call in the first line should add an endpoint association, the 2nd line looks like it tries to add a node association. Or is this just a display issue? I'm pretty sure that adding endpoint associations works in zwave-js.
robertsLando
commented
3 years ago Or is this just a display issue
I think I forgot to add the endpoint to the log message
AlCalzone
commented
3 years ago The thing is it also does add a node association, not an endpoint association.
robertsLando
commented
3 years ago Check it here: https://github.com/zwave-js/zwavejs2mqtt/blob/master/lib/ZwaveClient.js
Line 1097, sorry I'm from the phone and I cannot find how to give you the direct line link
AlCalzone
commented
3 years ago Hm, this all doesn't make sense. @darkbasic I think I need one more logfile from your attempt to add the association.
darkbasic
commented
3 years ago Here it is:
z2m:App Zwave api call: getAssociations [ 2, 1 ] +9s
z2m:Zwave Success zwave api call getAssociations [] +14s
z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1 } ] ] +13s
z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of Node 2 +13s
z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +388ms
z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [] => [] +0ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [] => [ { nodeId: 1, endpoint: 0 } ] +1ms
z2m:Zwave Success zwave api call addAssociations +1ms
z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1, endpoint: 0 } ] +612ms
z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s
z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of Node 2 +4s
z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +367ms
z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [] => [] +1ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [ { nodeId: 1, endpoint: 0 } ] => [ { nodeId: 1, endpoint: 0 } ] +1ms
z2m:Zwave Success zwave api call addAssociations +1ms
z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1, endpoint: 0 } ] +631msThere's something weird happening with the device...
During the interview, the controller tries to assign itself as a multi channel association. The device first acknowledges this but then sends another report a few milliseconds later where the association is missing again.
That's why the first get above seems to yield no associations
z2m:App Zwave api call: getAssociations [ 2, 1 ] +9s z2m:Zwave Success zwave api call getAssociations [] +14s
Then you try to add a node association, but the device already has the multi channel association from before. Since the limit of associations in the group is 1, the node association is not added. The GET which should confirm the add now shows the multi channel association that was added earlier.
Adding the multi channel association again is effectively a no-op
petrovcicklemen
commented
3 years ago > Both OZW and this driver automatically configure lifeline associations during the device interview. Missing reports are almost always related to misconfigured associations. A general rule for Qubino Flush devices is, that the ordinary lifeline has to be configured (using ASSOCIATION_SET(groupId=1, nodeId=1)), whereas the multi channel lifeline association must be configured (using MULTI_CHANNEL_ASSOCIATION_SET(groupId=1, mcnodeId=1, endpoint=0), if CC_MULTI_CHANNEL is listed, which means the temperature sensor is connected or an additional input is configured).
The majority of Qubino devices are, in their default configurations, single channel devices, so they require an ordinary association to be configured. They expect the mc lifeline to be configured only, when additional endpoints are enabled.
These two mentioned commands are enough to configure unsolicited reporting. There is no need to configure any other association groups.
> zwave-js automatically uses Multi Channel Assocations (with a target endpoint) if possible, otherwise "normal" node assocations.
Like explained above, some Qubino devices will not send any unsolicited values, if a mc lifeline is configured in their default configurations, where they are represented as single channel (root endpoint only) devices.
AlCalzone
commented
3 years ago Like explained above, some Qubino devices will not send any unsolicited values, if a mc lifeline is configured in their default configurations, where they are represented as single channel (root endpoint only) devices.
Just to make sure I understand: Do these devices support MC associations?
If I remember correctly from reading the specs (but I might have mixed this up), Multi Channel Associations should be preferred over Associations starting with MC version 3.
petrovcicklemen
commented
3 years ago When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.
Unfortunately, the Dimmer only sends out unsolicited messages for SWITCH_MULTILEVEL_REPORT and not SWITCH_BINARY_REPORT, hence the toggle widget is not updated. In order of the state of the toggle widget to be updated, polling would have to be enabled (by issuing SWITCH_BINARY_GET commands).
This can also be seen in the zwave zniffer:
petrovcicklemen
commented
3 years ago > Just to make sure I understand: Do these devices support MC associations? They do, but only in their non-default configurations: when the temperature sensor is connected or when an additional input is enabled -> CC_MULTI_CHANNEL is listed. In these configurations, the devices are represented as multi channel devices. In both cases, reinclusion is required: a) when temperature sensor is connected (the Node Info lists CC_SENSOR_MULTILEVEL and CC_MULTI_CHANNEL) b) when at least one additional input is enabled (via parameter 100/101), CC_NOTIFICATION/CC_BINARY_SENSOR, CC_MULTI_CHANNEL are listed
> If I remember correctly from reading the specs (but I might have mixed this up), Multi Channel Associations should be preferred over Associations starting with MC version 3 Yes, now they are preffered, as the Silicon's ZIP/Zware libraries also configure a multi channel lifeline by default, but unfortunately, these devices require an ordinary, non-multichannel lifeline to be configured, in their default configurations.
AlCalzone
commented
3 years ago They do, but only in their non-default configurations: when the temperature sensor is connected or when an additional input is enabled -> CC_MULTI_CHANNEL is listed. In these configurations, the devices are represented as multi channel devices.
Sorry, I think we misunderstood each other. I was talking about the Multi Channel Association CC, not Multi Channel CC. Currently, the driver checks if that is supported to determine whether a multi channel or a node association is used for the lifeline. It does not check whether the Multi Channel CC is supported.
If the devices do not include Multi Channel CC in their NIF in the default configuration (which it does seem like judging from this log), that is something I can add a check for.
petrovcicklemen
commented
3 years ago Apologies, I should have worded my answer better.
> Just to make sure I understand: Do these devices support MC associations? Yes, the older Flush devices do advertise CC_MULTI_CHANNEL_ASSOCIATION in all their configurations, but it must only be used in their non default configurations. What I wanted to say in my previous reply was, that the multi channel association must be used in device configurations, where CC_MULTI_CHANNEL is listed.
To avoid such lifeline configuration issues, on newer single channel devices (like Flush OnOff Thermostat2), CC_MULTI_CHANNEL_ASSOCIATION is not supported/listed by the device.
AlCalzone
commented
3 years ago Thinking about it, this check would also make sense by default, not only for Qubino devices. The specs state the following
If an End Point Association is created from the Lifeline group, End Points MUST send relevant Multi Channel encapsulated commands to the Lifeline group destination.
This requirement cannot be fulfilled when the device does not support Multi Channel CC
darkbasic
commented
3 years ago When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.
Unfortunately, the Dimmer only sends out unsolicited messages for SWITCH_MULTILEVEL_REPORT and not SWITCH_BINARY_REPORT, hence the toggle widget is not updated.
Weird, this is not what I'm experiencing.
z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +676msAs you can see lifeline association has been set correctly.
z2m:App Zwave api call: writeValue [
{ nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
true
] +14s
z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14s
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109ms
z2m:Zwave Success zwave api call writeValue +2ms
z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 78.5 +1s
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 78.5 => 80.5 +996ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109ms
@AlCalzone is it a report from the dimmer or is it zwave-js acknowledging the user has changed the state of the switch?
EDIT: zwave-443440.log
z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14sz2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565ms
@petrovcicklemen as you can see in this case I got a level report (two of them to be precise, with the second being completely useless since the state didn't change)
z2m:App Zwave api call: writeValue [
{ nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
false
] +7s
z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +5s
z2m:Zwave Success zwave api call writeValue +3ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 80.5 => 0 +2s
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +1s
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms@petrovcicklemen but it this case I didn't get any report at all for the level. This is completely random and happens with an hard resetted controller placed a few centimeters away from an hard resetted Flush Dimmer. Why?
AlCalzone
commented
3 years ago @darkbasic Setting a value from zwave-js also requests the updated (current) value from the device, so that's why you're seeing this in the first log
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109msI'm not sure where these updates are coming from
z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14s
...
z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565msYou seem to control the device while the interview is still going on, so its a bit hard to tell whether the update was because of a request during the interview or unsolicited
darkbasic
commented
3 years ago You seem to control the device while the interview is still going on, so its a bit hard to tell whether the update was because of a request during the interview or unsolicited
That's weird, I clearly have an "interview completed" printed in the console before sending the commands and I always wait an additional minute for safety:
z2m:Zwave Node 2 ready: Qubino - ZMNHDD (Flush Dimmer Plus) +2ms
z2m:Zwave Scan completed +1ms
z2m:Zwave Network scan complete. Found: 2 nodes +0ms
z2m:Zwave Node 2: interview completed, all values are updated +1msAnyway I've got plenty of similar results later on:
z2m:App Zwave api call: writeValue [
{ nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
true
] +2s
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +506ms
z2m:Zwave Success zwave api call writeValue +5ms
z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +466ms
z2m:App Zwave api call: writeValue [
{ nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
false
] +1s
z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +1s
z2m:Zwave Success zwave api call writeValue +2ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 40.3 => 49.7 +995ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 49.7 => 0 +995ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +994ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0msBy the way in this case it looks like it updated the level but not the power with the first command, while it updated the power but not the level with the second one.
AlCalzone
commented
3 years ago I always wait an additional minute for safety
Hmm I saw a bunch of BinarySwitchCCSet commands during the interview, so I assumed you triggered them.
By the way in this case it looks like it updated the level but not the power with the first command, while it updated the power but not the level with the second one.
Weird, maybe @petrovcicklemen has some insight on this?
petrovcicklemen
commented
3 years ago > Weird, this is not what I'm experiencing. Like mentioned by @darkbasic the SWITCH_BINARY values are probably obtained via polling. The picture of the zniffer log, where I've tried changing the output state of the device, shows only SWITCH_MULTILEVEL_REPORTs, not SWITCH_BINARY_REPORTs (METER_REPORTs are missing, since no load was connected).
> @petrovcicklemen as you can see in this case I got a level report (two of them to be precise, with the second being completely useless since the state didn't change) The device might send multiple output state reports, while it is transitioning, so that could be one explanation. This is so the dimmer sliders are updated, during the transition. Aslo, perhaps this value was also polled (don't know how this is handler by this library), after the device stopped with its transition. The recommended polling behaviour is to poll a device every 30 seconds, for each main supported property.
> @petrovcicklemen but it this case I didn't get any report at all for the level. This is completely random and happens with an hard resetted controller placed a few centimeters away from an hard resetted Flush Dimmer. Why? Make sure you are testing using the correct switch type and also have correctly configured switch/input 1 type, since this influences the sending of unsolicited reports. If you normally get all level values and one is missing sporadically, then I'd say this is a firmware bug, related to the revision, that you have. Also, changing the state to quickly, might result in such cases, since the device needs some time to send out all its queued messages.
AlCalzone
commented
3 years ago @petrovcicklemen zwave-js does not do any polling, except to refresh the current value once after each SET (but not from different CCs) and when a SupervisionCC encapsulated command tells it that there was an update. Multilevel Switch reports after setting the Binary Switch value (and vice versa) therefore can only be unsolicited updates.
petrovcicklemen
commented
3 years ago @AlCalzone I've asked my colleague to prepare a sample device with the firmware revision, that @darkbasic has and it'll be tested this friday, since we're not on the firm until then. I'll check if that version sends out also unsolicited SWITCH_BINARY_REPORTs. I did test on the latest revision yesterday and as can be seen from the zniffer log above, no unsolicited SWITCH_BINARY_REPORTs were sent.
petrovcicklemen
commented
3 years ago We already did the tests: the mentioned firmware revision shouldn't send any unsolicited SWITCH_BINARY_REPORTs, which can be also queried by the gateway, by sending the ASSOCIATION_GROUP_COMMAND_LIST_GET command:
The mentioned command was sent to all the groups on the root endpoint and the byte sequence 0x2503 (SWITCH_BINARY_REPORT) was not listed in any of them, under the "Command" field:
Here's the zniffer log, if you'd be interested in seeing it: FlushDimmerTestNicolo.zip
Based on this, I think the occurrences that can be viewed in the log are due to polling. I can test the device also on this library, but I can do it sometime next week, if that's ok.
AlCalzone
commented
3 years ago When looking at the above log (after the interview is complete) I would confirm this:
darkbasic
commented
3 years ago I've asked my colleague to prepare a sample device with the firmware revision, that @darkbasic has and it'll be tested this friday, since we're not on the firm until then
Looks like a bug in the firmware to me, if you could send me a kit to update it I could try if latest one is affected as well. The device state needs to stay consistent and I can't simply poll everything in a network with ~100 devices, especially since Qubino doesn't support S2 and S0 has quite a bit of overhead.
petrovcicklemen
commented
3 years ago *> Binary Switch Reports are only sent in response to a Binary Switch Get (which the driver sends after setting the value).** Correct. This is also mandated by the specs (a REPORT should match the GET).
*> Binary Switch Reports are never sent after switching the node using Multilevel Switch Set** Correct. As explained and shown above, the device does not advertise SWITCH_BINARY_REPORT in none of the association groups. You can double check this in the log, provided above.
*> Meter Reports are sometimes sent after switching the node using Binary Switch Set, sometimes once, sometimes twice** There are two configuration parameters that govern the sending of unsolicited METER_REPORTs: 40 and 42. One determines the sending by time, while the other determines a power treshold. The sending of unsolicited reports is also affected by how quicly the output state changes, since it takes a few seconds for the reports to be sent.
*> Meter Reports are sometimes sent after switching the node using Multilevel Switch Set, sometimes once, sometimes twice** Same as above.
*> Multilevel Switch Reports are always sent in response to a Multilevel Switch Get (which the driver sends after setting the value).** Correct. The mentioned commands (0x2603) is advertised in association group 1, which can also be seen above.
*> Multilevel Switch Reports are sent during and at the end of the dimming(?) process** Correct. Multiple switch multilevel reports might be sent to update the dimming slider to indicate progress.
> Looks like a bug in the firmware to me, if you could send me a kit to update it I could try if latest one is affected as well. The absence of unsolicited SWITCH_BINARY_REPORTs is not a bug, as the device does not advertise the mentioned command in any of the association groups, meaning it will never send any SWITCH_BINARY_REPORTs. A dedicated hardware programmer is needed to reflash the devices, but we don't send it around, so you'd have to send the devices to us. I can share these findings with my colleagues and propose that this is added to the firmware, but can't promise this update will be made, as such decisions are not made by me.
darkbasic
commented
3 years ago There are two configuration parameters that govern the sending of unsolicited METER_REPORTs: 40 and 42. One determines the sending by time, while the other determines a power treshold.
But I was always switching between level 0 and level 99, so the delta didn't change at all: 0 watts when the light is off and ~80 Watts when the light is on. More than enough to surpass the threshold. Also I'm not clicking on the switch button like mad and I can reproduce it even if I wait a minute between each state change.
A dedicated hardware programmer is needed to reflash the devices, but we don't send it around, so you'd have to send the devices to us.
I know, because I've already sent my devices twice. The first time they didn't test the new firmware and the bug wasn't fixed at all, while the second time they hit another blocker and I've had to wait months before getting my devices back. Every time I send them to you I'm left in the dark (literally, because with no relays I can't turn my lights on and I can't even get some light from the windows because I can't move my venetian blinds either). Can't even let the venetian blinds open because I wouldn't be able to sleep at night: I have plisse' blinds in my bedroom. I'm not even counting the fact that removing and re-installing 50 devices would cost thousands of euros every time if I was not doing it myself. That's why Igor mentioned about sending the programmer if I ever needed to update my devices again and of course I can return it once I'm done. The only other option is sending 3-4 devices each time, but I think we will be both loosing our time such way.
petrovcicklemen
commented
3 years ago But I was always switching between level 0 and level 99, so the delta didn't change at all: 0 watts when the light is off and ~80 Watts when the light is on. More than enough to surpass the threshold. Also I'm not clicking on the switch button like mad and I can reproduce it even if I wait a minute between each state change.
@darkbasic I understand. Like I mentioned in one of my first comments, if METER_REPORTs are missing sporadically, then it's probably a firmware issue. Igor will attempt to replicate this tomorrow. If confirmed, he'll be discussing the next steps with you over the support portal, since this is not an integration issue.
AlCalzone
commented
3 years ago FYI, #1113 is going to change the interview to set up node associations for lifelines instead of Endpoint associations when Multi Channel CC is not present
darkbasic
commented
3 years ago Awesome, so I guess we can remove the "noEndpoint": true quirk in @zwave-js/config/config/devices/0x0159/zmnhdd.json?
If I understand correctly that would break the device when a temperature sensor is attached or the additional inputs are used.
AlCalzone
commented
3 years ago already did :) If you like, you can experiment with the current master.
AlCalzone
commented
3 years ago The changes we discussed are included in v5.4.0
robertsLando
commented
3 years ago Can this be closed ?
AlCalzone
commented
3 years ago The mutual update between Binary Switch and Multilevel Switch is still not happening, but I don't think there is a good heuristic (for all devices) when to poll the binary switch after a multilevel switch change.
darkbasic
commented
3 years ago I tried latest version of zwavejs2mqtt (which uses node-zwave-js 5.4.0) and I noticed that the switch command class (2-37-0-targetValue) doesn't reflect the 37-0-currentValue value. So when I click on the 2-37-0-targetValue switch the 37-0-currentValue gets true but the switch is still off because 2-37-0-targetValue is undefined.
{ nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
true
] +10s
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +16s
z2m:Zwave Node 2: value updated: 37-0-targetValue undefined => undefined +0ms
z2m:Zwave Success zwave api call writeValue +4ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 73.2 +2s
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 73.2 => 81.4 +993ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
z2m:Zwave Node 2: value updated: 50-0-value-66049 81.4 => 80.8 +998ms
z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
AlCalzone
commented
3 years ago but the switch is still off because 2-37-0-targetValue is undefined.
@robertsLando that's what we talked about a few days ago. This switch supports a newer version of the switch CCs, but does not report a target value in its reports. Maybe it does generally make sense not to update the targetValue property when a device does not report it.
AlCalzone
commented
3 years ago Lets discuss this further in https://github.com/zwave-js/node-zwave-js/issues/895
darkbasic
commented
3 years ago @petrovcicklemen can you please share your thoughts about this https://github.com/zwave-js/node-zwave-js/issues/1138
darkbasic
commented
3 years ago Like I mentioned in one of my first comments, if METER_REPORTs are missing sporadically, then it's probably a firmware issue.
@petrovcicklemen I confirm that the sporadically missing reports have been fixed by the new firmware, thanks!
Unfortunately the Flush Dimmer doesn't obey parameter 2, meaning that the additional scene input I2 behaves like a bistable switch despite being set as momentary switch (which is the default value). Also there is a big lag between the moment when you press I1 (or I2) and the moment the zwave notification gets sent (4-7 seconds). Hopefully this can be improved as well. I've made a video where I showcase the problem: https://www.youtube.com/watch?v=2INIV4gnIPw
When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.
Turning the light on with the switch command class (2-37-0-targetValue) Before:
After:
As you can see the switch on 2-37-0 has been updated to true but the level (2-38-0) hasn't been updated to 99 accordingly.
Turning the light on with the dimmer command class (setting the 2-38-0-targetValue level to 99) Before:
After:
As you can see the level on 2-38-0 has been updated to 99 but the switch (2-37-0) hasn't been updated to true accordingly.
zwave-284642.log