Heatit Z-Dim doesn't restore "current value" when switching on "level"

[jmgiaever]

Hi,

I own 4 HeatIT Z-Dim dimmers. I normally use the level entity (multilevel switch up/down in zwavejs) to turn ON or OFF the lights, and not the binary ON/OFF.

While this works well for 1 device it doesn't work correctly with the 3 others. The lights are turning ON visually, but their «current value» aren't updated with the targeting value, so programmatically they appear as OFF.

Device information

Which device(s) is/are affected (make/model)? HeatIT Z-DIM ThermoFloor

What are the node IDs?

1. 37
2. 42
3. 43
4. 44

Last Known Working Configuration

• [x ] New device

• Previously working device (other platform)

  • Which platform?
    • OZW Daemon
  • Have you made any recent configuration changes to the device?
  • No, all of them uses them default config.
    I've tried to compare the configurations, but they all looks the same.

Installation information
How did you install node-zwave-js?

• [x ] Other: Snap package of the latest build of Zwavejs2mqtt (1.1.0)

Additional context
Add any other context about the problem here.

Logfile:

Here's the code when I press the two identical toggles on node 42 (working correctly) and node 43 (which isn't working correctly):

1.txt

[AlCalzone]

There must be some difference between the devices. Node 42 reports the change on its own, Node 43 doesn't.

While we are normally optimistic and update the currentValue with the targetValue when the set command succeeded, that is not possible for the value 255, which does not convey a level, but just means "on".

I guess we could poll even when supervision tells us that the "on" command worked, but since it works for one of your devices I'd try to figure out why. Have you compared the associations too?

[jmgiaever]

Hi,

for what I'm aware there aren't. They came with the same order - who knows, and how can I check this?

They all worked by toggling the level in OZW. The level value was restored and they appeared to be ON.

I'll do some more toggling while watching the logs to see if something's comes up :)

[jmgiaever]

Here's some toggling on node 43, one of the nodes that doesn't report correctly (sorry for the other garbage in here from other nodes): 43-toggling.txt

And here's for 42: 42-toggling.txt

[jmgiaever]

Have you compared the associations too?

Checked it now; Lifeline -> Node_1 on all devices

Also made a post on the HA community forum, asking if anyone else experienced the same.

[jmgiaever]

Not sure if these will help, but found a «debug info» tab:
42-debug.txt
43-debug.txt

[jmgiaever]

Sorry for all the info, but tried to do a device restart and got an error saying that "node 1 do not support associations". I'm having the UZB-1 dongle from Zwave.me.

I haven't added any associations to this (or any) node.

[AlCalzone]

Please attach logs as files. These inline logs make it really hard to digest the issue.
@robertsLando where can he check in z2m how the associations are set up?

[robertsLando]

Control Panel > Expand a node in the table > Group Associations Tab

[jmgiaever]

Please attach logs as files. These inline logs make it really hard to digest the issue.
@robertsLando where can he check in z2m how the associations are set up?

Hi, I already checked it for the dimmers. Node 1 (the controller) is in the Lifeline group of the devices.

There is no group association options for the controller, so nothing comes up there.

[AlCalzone]

Okay before we start guessing more, please send me your cache files (<some-hex-key>.json and .values.jsonl)

[jmgiaever]

Yes, are they safe to publish here or email them to you?

I also see that I have 3 different sets, probably because I tried to rebuild the whole network yesterday. How can I find out which is «current»?

Edit: Found it in CP under HomeHex :D

[AlCalzone]

You can send them via email

[jmgiaever]

@AlCalzone Sent! :)

[AlCalzone]

Ok a couple of observations:

• Both 42 and 43 support Z-Wave+ Info V2, which means they have to report all status updates via the lifeline.
• Node 42 reports Association CC as version 2, node 43 as version 0 (i.e. unsupported). The same happens for a couple of other CCs.
• For Node 37 we don't have any version information besides the CCs
• The associations are the same for all 4 nodes.

I'm guessing that you're losing some messages, maybe due to RF issues. Since your log snippet in the OP is very short, I can't verify though.
Could you make and attach another zwave-js logfile (only that, no logs from zwavejs2mqtt please) including the entire startup and some switching attempts?

[jmgiaever]

Hi, will do! :)

I'm not sure if it's noteworthy, but three of the dimmers is approx 1 meter away from the controller. And node 42 and node 43 is located in a rack, with node 43 (which is also problematic).

Node 37 on the other hand is maybe 3 meters away, in the basement on an angle of 45⁰.

The Z-wave graph shows that all of these devices has 1 hop. That shouldn't be problematic, but I do not understand how/why, since they're so close to the controller.

I'm just upgrading zwavejs2mqtt to the recent version. Will enable logging and save it to file as soon as the compilation is done. :)

You'll hear from me asap.

[jmgiaever]

Log entry sent! ~9MB so it might take few minutes to arrive.

At (time)

1. ~18:05 All powered devices interviewed and battery devices is restored from cache
2. ~18:17 I'll do a re-interview of all powered devices
3. ~18:18 I'll start toggling. I've tried to repeat the same process for each device, each time. E.g do the same on node 42, 43, 37, 44 before trying to do something else.

For one of the iteration I set the target value, and "the level" then responds correctly.

[AlCalzone]

Hah - Node 42 is the only one of those 4 that is not included securely. I'll do some investigations what that could imply in regards to the Z-Wave+ CC V2 requirements.

[jmgiaever]

Ah, I'll see that now. It wasn't visual from the UI earlier, but with the upgrade I just did... I'll see it too. The logs aren't self-explanatory to me 📦

[jmgiaever]

Saw the discussion on this matter; Don't know if it's worth mentioning, but with OZW they were working with S0 and they were one of the snappiest devices I had in my system, however they had a habit of reporting their state to often. Are they supposed to get an ACK back to confirm that the data was received.

PS! When I tried to look up a thread that I once read regarding the spamming issue, I found this regarding OZW + Multilevel CC. Can this help in any way?

[AlCalzone]

OZW used to poll a lot. When using Multilevel Switch CC with Supervision (which OZW does not support), that is usually not necessary, because we know the device has reached its target state. The only exception is ON (255) where we don't know which value the device has chosen.
But since the Z-Wave+ V2 devices must report their changes (and 42 does), I want to figure out why the secure nodes don't. Such modern devices shouldn't require polling workarounds...

[jmgiaever]

Thanks for the clarification :)

I don't mind having a door or window sensor insecure, since that's something everyone without any technical background can see from the street (haha, read a post where this was your argument about a shutter - good one!).

But we are planning to establish this in all our short term rentals and don't want personal data (motion sensors etc) to be readable to an outside party.

We also strive to keep costs and environmental damages to the lowest, so anything that can be flipped (turned on/off) should be secure. Some of our rentals is up to 48 000 kWh a year. :|

Again! Thanks for all your work. I've put up a monthly sponsor.

[AlCalzone]

Okay from what I've found out: the 3 devices included with Security S0 are not behaving correctly. If you don't mind, I'd re-include them insecurely and try Security again once Security S2 is implemented.

[jmgiaever]

Hmm, I think it's strange that they worked flawlessly on OZW. :/

What the status on S2 if you dont mind me asking?

[AlCalzone]

That's probably because OZW verified all changes through polling by default, whether that is necessary or not. The ultimate goal of zwave-js is to get certified, so polling Z-Wave+ V2 devices would be a no-go.

I believe I've solved the hard parts of S2 already. Need to put it all together and test extensively. Unfortunately, the last couple of months were busy investigating the influx of issues from new HASS and zwavejs2mqtt users, so S2 got stuck on the sidelines.

[jmgiaever]

I can imagine! Excited to follow the path of Zwave-js. Let me know if you need real life testing when you'll get that far.

I'll be looking for a firmware update to the dimmers, and try to do an upgrade. Maybe that fixes it..

[zwave-js-assistant]

This issue has not seen any recent activity and was marked as "cannot fix ❌".
Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

[jmgiaever]

Hi @AlCalzone. I excluded all of the HeatIt ZDim devices and made a new/second Z-wave network with these devices only.

Node 42 (it has a new ID in the new network, but using this for reference) still works correctly in secure mode. Isn't it odd that this node works correctly, but the other ones don't?

[jmgiaever]

Now also tried to exclude one of the weird devices and include it insecurely. Same behavior as when it was added securely.

[jmgiaever]

It looks like all the data received is the same, except the last report. Node 42 sends a «MultilevelSwitchCCReport» while the other's sends a «MeterCCReport». Node 42 does not send this... However this is always 0.

Node 2 = 42 (before)
Node 3 = 43 (before)

2021-02-22 17:15:47.900 INFO ZWAVE: Node 2: value updated: 38-0-targetValue 0 => 99
2021-02-22 17:15:47.901 INFO ZWAVE: Node 2: value updated: 38-0-duration [Duration: 0seconds] => [Duration: 0seconds]
2021-02-22 17:15:47.902 INFO ZWAVE: Node 2: value updated: 38-0-currentValue 0 => 99
17:15:47.902 DRIVER « [Node 002] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[MultilevelSwitchCCReport]
                            current value: 99
                            target value:  99
                            duration:      [Duration: 0seconds]

2021-02-22 17:16:31.775 INFO ZWAVE: Node 3: value updated: 50-0-value-65537 0 => 0
2021-02-22 17:16:31.776 INFO ZWAVE: Node 3: value updated: 50-0-deltaTime-65537 0 => 0
17:16:31.776 DRIVER « [Node 003] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[MeterCCReport]
                            type:       Electric
                            scale:      kWh
                            rate type:  Consumed
                            value:      0
                            time delta: 0 seconds

[AlCalzone]

Is there anything you can configure on these devices, like which reports are getting sent?
If not, I'd advise you to bug the support, they should have some more insight.

[jmgiaever]

Everything is equal in the configuration part of Zwavejs2mqtt UI, and nothing that i related to reporting.

However... I found a post (written in Norwegian, my own lang.) from last Friday. He's writing that there's a new 2020A version which doesn't report changes in HomeSeer, while the 2019 version does.

I'm not sure which versions I have; however I bought them by the end of 2020. I removed the cover of the rack and can see some differences here. The QR code of node 42 (top) and node 43 (bottom) differs, and the text have different sizes. I blured out the QR code, as I'm not sure what it is. But see the text below.

So I guess node 42 is probably 2019 version while the others I have is 2020.

I've tried to find a complete manual for the 2020 version to see if it has more settings/configurations that is not included in the Zwavejs config. But I can only find the QuickStart guide for it, and its just a simple install guide mainly describing how to put it to inclusion mode.

I'm wondering if there is firmwares available somewhere. Tried to google but cant find any.

[AlCalzone]

I've removed your images as you did not blur the DSK under the QR codes.

So I guess node 42 is probably 2019 version while the others I have is 2020.

That could explain it. Like I said, it is probably best to ask the Heatit support what's going on.

[jmgiaever]

I've written them and linked to this post + the forum post that I found.

Thanks for your patience with me :)

[jmgiaever]

Just leaving a comment that the new OTA from Thermo-Floor / HeatIt solved this issue. I'm not able to attach the file here, but reaching out to them took a day until I had the file.

[irowan]

Just leaving a comment that the new OTA from Thermo-Floor / HeatIt solved this issue. I'm not able to attach the file here, but reaching out to them took a day until I had the file.

Hi!

Can you send it to me as well? I contacted you through Home Assistant Norge on Facebook, but the message probably went to the spam folder. :)