[2.5.0M1+Z-Wave Snapshot] Z-Wave power consumption not updating, but manual polling works instantly

There are several possible reasons:
associations not properly set (or associations set which do not point to the controller).
Device config is set to use Basic Command Classes, but items are linked to the channels for Multichannel Command Classes (for example it is always best to use the multichannel command classes for other endpoints than 0, for example meter_watts1 instead of meter_watts, assuming your device configuration is set to multichannel)

1 Like

I’m trying to follow but this is a lot of new nomenclature for me.
Looking in both Paper UI and HABmin, I don’t see any other channels for watts.
Is this something missing from the database / XML file?

I do not see any place in the three different config subsections in HABmin (configuration parameters, device configuration, configuration) that give me a choice between Basic or Multichannel.

I do see the Association Groups option where I can assign Lifeline, Group 2 and Group 3. Group 3 is labeled “send notification to associated devices”. The former two are more specific. Are you saying I should set ID 1 for Group 3? I’d certainly be willing to try, but I have never needed to before, nor have I done so for any of the other devices whose reporting is working.

So, I’m not trying to be helpless, I’m really trying to follow your advice, but I just don’t have enough experience to make use of it yet.

Would you please elaborate and add some more detail as to what you mean?

Please read our zwave guru’s pages: :grinning:

It is all just guessing because I don’t know about which device your are talking:

What device is node 9?

If you don’t want to control your devices directly (without use of openHAB) the Lifeline is the one to go with, set it to your controller. Don’t set the other associations.

This would be an example, see the different endpoints:

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/416

1 Like

Node 9 is also a NEO CoolCam plug (0003:1087) – same type of device (and same ID) as the ones measuring the power consumption of dehumidifiers (ID 27, 28). Yet, Node 9 reports fine, despite not having deleted and re-added it since OH 2.4. I did that with Node 27 and 28, which had no effect – they still don’t report.

cd-jackson.com

I will read the Z-Wave bindings page now.

I tried the lifeline association to the controller and it did not have any effect. The value does not update, nor do I see any Node 27 related events in the Z-Wave log when I force a change in power usage by turning the dehumidifier off (300 -> 0 watts). Polling still works though.

association !

1 Like

Indeed :slight_smile:

See edit above.

But yeah, what’s so confusing for me about all this is: it’s not a complicated device. Some devices have multiple endpoints… these don’t. and they don’t have all that many configuration options. I don’t see anything set differently between the instances of the same device that report properly, and the ones that don’t. I haven’t changed any configuration options, I included them all the same way, and i’ve even compared the settings to make sure they’re the same – and they are. This is what I don’t get.

Then a debug log is an option, feed it through Chris’ zwave log viewer.

I just found that zwave log viewer after reading the entire page about the binding. Wow, nice one! That’s a lot easier to read.

From the log, it looks like it’s the device that isn’t reporting the power usage.
That could be, too… but it seems like a big coincidence that they would fail just now (after months of working perfectly with another controller), and both at the same time, while others of the same type keep working.

Here is my last Z-Wave log if you care to take a look again.

You can see me setting the association at 21:29:14.
Then nothing else from node 27 until my scripts asks for a power update at 21:32:54.
No indication at all that the power usage went from 300 to 0 watts around 21:30:30.

Is there a reason for having multiple associations?

To be honest, because of all your refresh scripts I am not sure what is going on, maybe @chris has some time left to take a look at your debug log.

1 Like

Whoa! No, I’m definitely not meaning to have multiple associations. There is no node 193 on my network. Should I exclude and try to factory reset devices 27 and 28?

There is really only one refresh shript and it runs every 5 minutes, on node 27 and 28 (the ones in question). All other updates are reports, not polls.

As you did that already before I think it will not help :innocent:

So a couple of points…

Firstly, I would try and get rid of this association to non-existant nodes. I don’t know what this would do in the node, but it’s probably not good as these requests will fail. I would suggest to try and clear the association group and see if that removes these nodes - I’m not 100% sure if this will work so if not, please provide the log.

Second - I’m not really sure why you need to use these refresh commands all the time? Why not just set the polling period to a faster rate?

1 Like

@sihui I didn’t exclude and re-include them. I will see if Z-Wave exclusion works in the snapshot binding I’m running – if it’s like 2.4.0 (where exclusion never worked for me) I will end up shutting down
OH and plugging the UZB into my workstation and run the Z-Wave PC Controller and do it there.

@chris, I will try, my only idea how to do that is to try to factory reset the devices.

Regarding the refresh command, my thought was that tightening the global polling period would poll all devices, while a-la-carte refresh commands only polls those where the power consumption is used for decision making. In this case I’m only polling two devices, a lot less than the total number of devices in my network.

The poll interval is set per device.

1 Like

Indeed it is. I went to look for it now and was reminded why I didn’t use it – minimum poll interval is 10 minutes and I kind of had my heart set on 5. Still, it could be useful.

Now the devices are on the bench. I’m going to get to the bottom of this. Wish me luck :slight_smile:

Edit: I was not able to cleanly exclude the devices. In fact, I’ve never been able to cleanly exclude a z-wave device with openHAB, not once. I always end up in a state where the “thing” remains, and the device still thinks it’s included, yet they completely stop communicating. Next step is to pull the UZB dongle and clean up with Z-Wave PC controller.

With the dongle in my workstation and Z-Wave PC controller running, I’m able to toggle both devices on or off. So the devices are obviously still included. it appears that placing the controller in Exclusion Mode from either Paper UI or HABmin, and activating the device (by triple-clicking the physical button) only results in killing the communication, not actual exclusion. Not sure how else to explain it @chris. I have never seen exclusion work properly in openHAB but I am familiar with the procedure of excluding devices from other Z-Wave controllers as I successfully excluded every single device in my network from the Fibaro controller within the last couple of weeks.

Don’t know if it’s at all useful but here’s what ZPCC says about the device:

Edit:

  • I excluded the devices (with the Z-Wave PC Controller software, ZPCC henceforth)
  • I reset them (through holding the device button until it flashes red behind the blue lens and really looks like pink – brilliant industrial design, this)
  • I re-added the devices in ZPCC (as Node 42 and 43)
  • I verified that I could command them on/off from ZPCC
  • I closed ZPCC and moved the UZB back to the Raspberry Pi
  • I started the openhab2 service back up
  • I deleted the old devices 27/28 through PaperUI (now corrently shown as not found in z-wave network)
  • I added the two new devices in the inbox (42 and 43)
  • I edited the old item bindings from 27/28 to 42/43

Meter reporting now works.

I have no idea why it suddenly failed previously, because it worked in the beginning! But, now it works again. I will keep an eye on it and report back. Thanks for the help, everyone!

@chris, have you looked at the exclusion procedure recently? Are you sure it’s still okay?

This is an editable field, so you can set it to whatever you want, even if it’s not in the dropdown. I think I remember the minimum being 15s. The unit is seconds.

Guys (@sihui @chris) are you sure the ASSOCIATION_REPORT logging is accurate?

I was looking for it in the text logs and could not find it by name. I finally found it by timestamp. It’s not decoded at all in the text log, it’s only decoded by Chris’ log viewer.

Here’s the one Sihui found yesterday which made us suspicious about the associations:

Here’s the corresponding entry from the log text:

2019-06-28 21:29:14.455 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 04 00 1B 06 85 03 01 05 00 01 C1 00 AA  

C1 hexadecimal is 193 decimal so it’s definitely the right log entry. I thought “i don’t have a device 193” in my network, in fact I don’t think I ever did."
…but then I looked at my backups of my old dehumidifier LUA script from the fibaro system… and lo and behold, this dongle was Fibaro Device ID 193 in my old z-wave network, in my old controller! Note that this is NOT a Z-Wave ID – it’s fibaro’s own device ID which can go higher than 8 bits. I know this because the other dehumidifier was device 198, and then that plug failed in a puff of smoke (as the NEO coolcam plugs tend to do after a while) and the new one got id 298. Z-wave IDs don’t go that high. Anyway, it would be quite a coincidence if this number 193 wasn’t retained from before. The odds are a couple of orders of magnitude below winning the lottery, to be sure, but 1 in 256 still feels like a strange coincidence.

Anyway.

Now that I know to look for association report, I decided to look it up in my CURRENT log (since resetting and re-including the devices).


181? 182?? No. First of all device 42 and 43 are freshly reset and re-included, and second those node numbers are not a thing in my network. Also, they happen to be sequential. @chris, are you sure this is interpreted correctly? If so, please, what does it mean?

Also, it’s working beautifully now. Despite the supposed ghost associations which I have no idea where they came from or whether they’re even real, it IS telling me what the power usage is without me even having to ask for it! Glorious.

As far as I’m aware there has never been a problem with exclusion - are you sure it gets enabled (ie are you sure you look in the right place in PaperUI)?

You can set the polling period on a per device basis.

As above, I’ve never had a problem with it and not had reports of problems. I’ve not personally checked it recently, but I’ve no reason to suspect it doesn’t work as it’s a single command to the controller.

Yes - I double checked it.

Yes, it is also decided in the text log, but it only shows the nodes that are real (ie node 1). However that doesn’t mean that the device isn’t trying to send to other nodes in the list.

I spent time last night double checking this and it is correct.

It’s 1 in 232, but who’s counting :slight_smile:

1 Like

@chris, I’m aware of the following two places to enable exclusion mode:


Are they equivalent? Should the thing you are excluding go away automatically in other views, or do you still have to delete the thing manually after exclusion?

In that case… what’s going on? Are these just bad devices which randomly make up associations to non-existent nodes, even after a full reset? I thought Z-wave had certification and stuff.

:rofl:

Yes - they both send the same command to the binding.

No - I used to do this, but ESH/OH core now prevents bindings from removing things, so you need to delete the thing yourself.

Yes, you must also delete the thing.

I thought I read above that you hadn’t done an exclusion?

It’s unlikely - I thought above you said that 193 was the address used by the Fibaro controller? Presumably something has set this association. It could be openHAB of course if something has configured it, or it could be something else in the network - I don’t know.

Well - don’t assume that means devices conform to the standards. We’ve found some really fundamental bugs in devices that have supposedly been certified! The worst one is the CT100 (or 101 - I forget) thermostat which doesn’t respond to MC encapsulation correctly and is unusable - ZWA confirmed that this device was non-compliant (but it was certified) and the manufacturer took it off the shelf (actually, they sold their stock cheaply to unsuspecting victims).

There are a lot of devices that don’t follow the standards.