Qubino Smart Meters (ZMNHXD, ZMNHTD) endless problems


So, I have one Qubino 3-phase smart meter, and three Qubino 1-phase smart meters, measuring:

  • Total net consumption
  • Solar Inverter 1 Yield
  • Solar Inverter 2 Yield
  • Central Air Conditioner usage

They’re installed in the consumer boards where they should be.

Now, here’s the thing. They’ve never worked right. I’ve tried them with Fibaro HC2, Z-way, Jeedom, and now with the Z-Wave binding (2.4.0 release, and then 2.5.0 snapshot) in OpenHAB.

Either parameters are missing… or they don’t complete the interrogation… or they’re just not supported at all… or (in the case of openHAB), all parameters are there, but they don’t update values automatically, only when you hit refresh. Also, randomly, three out of the four now are offline, “Node is not communicating with controller”. Yes, they are some of my furthest Z-Wave devices from the controller (that was not the case when I tried with Z-Way and Jeedom, then the controllers were in the same small room) but there are plenty of mains powered Z-Wave devices between the controller and the Qubino meters, including one in the same small room as the meters, which I placed there solely so it could act as a repeater.

I’ve searched this forum and found plenty of other references to these things not working right.

So, here’s my question.

Is anyone using these devices? Are they working for anyone? Or are they just expensive pieces of you-know-what?

Their own compatibility chart is rather sad with not even one controller listed as 100% working.

Is there any hope of these devices ever working properly, or is it time to cut my losses and go with six of these:


…connected to one of these?

This statement doesn’t really make sense. Refresh what? Do you mean only when you initiate a zwave scan? Or only when you refresh the browser?

There is a whole host of stuff that takes place between the device and what you see in the UI in the browser. You need to investigate to figure out where in that chain of events things are going wrong.

If you are talking about refreshing the browser then in all likelihood everything is working fine but the browser isn’t refreshing properly (it’s been known to happen).

Look in the logs and see if your Items are getting updated.

If I understand correctly, one of the things that happens during the inclusion process is the controller determines and stores the signal strength. If you include the device in the same room and then move it to somewhere further away the controller or mesh may have difficulty communicating with device because the signal strength was set assuming while the device was in the same room. I’m no expert on this stuff though.

Initiating a heal (you can do this from Habmin). By default a heal is supposed to occur every night though which should address this though.

Though all things considered, all the evidence points to these devices not being supported. That row in the chart has an X across all the columns for openHAB.

I should have been more specific.
I meant they update only when I click the “Refresh Items” button in HABmin - Configuration - Things - [the device]. This initiates a ZWave Poll of the values (channels) that have items linked to them.

2019-06-19 21:55:58.448 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Command received zwave:device:109534bc:node36:meter_watts --> REFRESH [RefreshType]
2019-06-19 21:55:58.451 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Polling intialised at 86400 seconds - start in 50 milliseconds.
2019-06-19 21:55:58.501 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Polling...
2019-06-19 21:55:58.503 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 36: Polling zwave:device:109534bc:node36:meter_watts
2019-06-19 21:55:58.504 [DEBUG] [ternal.converter.ZWaveMeterConverter] - NODE 36: Generating poll message for COMMAND_CLASS_METER, endpoint 0
2019-06-19 21:55:58.506 [DEBUG] [ternal.converter.ZWaveMeterConverter] - NODE 36: Generating poll message for COMMAND_CLASS_METER, endpoint 0
2019-06-19 21:55:58.507 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 36: Creating new message for application command METER_GET
2019-06-19 21:55:58.508 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 36: SECURITY required on COMMAND_CLASS_METER
2019-06-19 21:55:58.509 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 36: Command Class COMMAND_CLASS_METER is required to be secured
2019-06-19 21:55:58.511 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 36: Adding to device queue
2019-06-19 21:55:58.512 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 36: Added 3120 to queue - size 5 

Indeed. I included the devices by moving the RPi running openHAB to my meter room (where the consumer boards and thus these Z-Wave devices are), otherwise I never would have been able to include them. However, after that, I waited until the next day, so that the automatic 2 AM heal could take place first. The per-thing “Heal” in HABmin is not useful because it does nothing until a device has responded to all the interrogation questions. If a device is stuck on REQUESTING_NIF (or whatever the message is), Heal refuses to do anything.

I have not found a manual network-wide “Heal” button in either HABmin - Bindings - Z-Wave - Tools (the menu is empty), or anywhere in Paper UI. Because of this, I have accepted having to wait until the next day for a network heal to have taken place. Patience is a virtue, and I do understand and appreciate that openHAB supports a lot of other bindings besides ZWave, and that small details like this are par for the course.

Anyway, the second and third days, all devices showed as online, but the values did not update automatically – only when I pressed the “refresh items” button in HABmin.

The fourth day, three out of four devices are flagged as “node is not communicating with controller”.

All other (30+) nodes in my ZWave network are working beautifully. It’s only these Qubino’s that have been a problem.

Indeed the compatibility chart claims no Openhab compatibility, but it is an old chart, and there is certainly support for it in Openhab.

My question is, are these devices working for anyone else in OpenHAB or with any other controller? As in, is it worth spending more time on this?

I have tried them with Fibaro, Z-Way, and Jeedom, and now OpenHAB, and they’re not working satisfactorily in either. I have never seen flakyier or more finicky ZWave devices than these, and they weren’t cheap neither.

I believe that “Synchronize Network” performs a heal. To find that in Habmin browse to the Thing that represents your Zwave controller and select it. Click on Tools and click on “Show advanced settings”. then click on Tools again and you will see “Synchronize network” as an option.

I vaguely remember that there was a heal option in the Zwave Network Viewer but the Device Tools button doesn’t appear to do anything for me any longer.

Have you looked at the logs to verify that the heal actually occurred?

Hopefully someone can chime in and let you know you are not alone or how they got the device to work.

1 Like

“Synchronize network” is indeed heal, and it is indeed performing it. I didn’t know that option was there, that will be useful, thank you for that!

Let’s see if it gets the devices back to the state of communicating (but certainly not volunteering values until polled).

Indeed, looking at the logs is why I’m looking into ways of keeping logs permanently on some dedicated screens. I’ll start a new thread about that, I think. :slight_smile:

No - it isn’t. It synchronises the network state with the SUC. Heal Network performs the heal of the network :slight_smile: .

1 Like

So that raises the question, is there a way to trigger a heal from PaperUI or Habmin and if so where is it?

Yes - as I said above - it’s the option called “Heal Network”.

Hmmm - interesting, that seems to be missing in the definition. I’ll take a look at that…

I guess for now the easiest thing is to set the heal time to the current hour, then it will heal within the next hour. Remember though that the network may not work very well during a heal…

OK, I’m not losing my mind. I remember seeing that option there in the past but couldn’t find it. My zwave network is super stable so I rarely have to bring up these tools.


Do you need an issue filed?

Yes, I also thought it was there :sunglasses:

Yes - feel free - then it won’t get lost. Thanks.

1 Like

Done. https://github.com/openhab/openhab-webui/issues/83

1 Like

I’m starting to wonder if the meter room is one big faraday cage. Perhaps it’s a signal strength issue?

In hindsight, I can see how the ZMNHXD would have problems considering it’s inside a metal box. Perhaps it’s not the most sensible thing in the world to design Z-Wave devices to sit inside a consumer board to begin with?

The reason I went with the Qubino devices over for example Aeotec’s home energy meter is that I was building a brand new house and at the time it seemed like a cleaner solution to have the meters hardwired rather than clamped on. Little did I know how much of a headache they would be.

Just now, I left the door to the cabinet containing the ZMNHXD open, to give it a better chance of get a signal.

I also power-cycled the central air conditioner and its corresponding ZMNHTD meter

I then walked back into the house to check the HABmin things status.
Central Air is (ZMNHTD) is now suddenly online and delivering values without me asking for them!
ZMNHXD is also now online, but not delivering values.

And now suddenly the Aeotec plug (the one in the lower right corner of the picture, there solely as a repeater) is not communicating with the controller!

Obviously I have signal issues.

I have a spare Aeotec Gen5 Z-Wave USB stick, and a pile of raspberry Pi’s. What do you think about setting up a secondary OpenHAB system as a Z-Wave controller inside the meter room, to eliminate any possible signal/repeater issues and give these things a last-ditch effort?

FYI, I did set up a second Raspberry Pi with the Aeotec Gen5 Z-stick and tried to get things paired up. I only managed to see two of five devices in the meter room… the Aeotec plug and one of the Qubinos, nothing else.

I suspect my Aeotec Z-stick may be defective, because it’s sluggish in turning switches on and off even in a 1 or 2-device z-wave “network”.
My main RPi uses a Z-wave.me UZB1 which works flawlessly.

I have no other Z-wave controllers (except for the newly retired Fibaro HC2) so I am putting getting the Qubino’s working on hold for now.

I just ordered three more UZB1’s (need to have at least one backup anyway) and will get back to this when they arrive.

This raises the question of how you will get the signal from the RPi out of the room. I believe you mentioned previously that WiFi won’t reach reliably. Maybe that was someone else…

You can use Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide or set up federation between two openHAB instances (your main one and one running on the RPi) using MQTT if you can get WiFi.

I’d look at the logs before assuming that. Perhaps do a factory reset of the controller. There could be other explanations for the sluggishness.


Ah! This one I can answer, the meter room is the ethernet central of the house, containing both fiber modems, the mikrotik router and another ethernet switch. I’ll just plug it in the old fashioned way. :slight_smile:

But actually, come to think of it, 2.4 GHz WiFi goes into the room just fine. I have an ESP8266 MCU in the same room on doorbell sensor duty, and it stays on the network no problem.

THIS is interesting. You mean one openHAB could control two individual, separate Z-Wave networks?
That would be neat, I would totally have gone the bruteforce route of invididually scripting HTTP REST API updates for each individual parameter, if you hadn’t mentioned that.

Then again, this is counting the chickens before they hatch. So far, I can barely get them into a network, let alone getting parameters reliably.

Good point, I will do that, although I think I will save it for later (for the purpose minimizing frustration) and see if it works with the UZB1’s I ordered first, once they arrive.

I’ve also ordered a whole bunch of clamp-on current transformers, and I have a drawer full of MCU boards. They’ve under $4 each on aliexpress. This way, if after replacing the USB Z-Wave controller it still doesn’t work satisfactorily, I’ll be ready to cut my losses and get it done a different way.
At this point, setting it up with current transformers clamped onto the wiring and feeding the analog input pins of an MCU which in turn HTTP REST API update openHAB items, would take me less than a day. I’ve already spent way more than one day fighting the Qubinos. But, this is plan B, I’ll give it one last try when the UZB1s arrive.

It’s not all unicorns and gumdrops but lots of people go this route. Not everyone can locate their OH server in an ideal location for the zwave’s mesh network.

Others will host a separate OH instance and use MQTT to synchronize them. I chose this route, though that’s largely because the “secondary” OH instance is about 100 miles away. I want it to be a little more stand alone and self reliant.
Both have their pluses and minuses.

Most of us use ESP Easy on NodeMCUs and MQTT for stuff like this. I’ve a bunch of them scattered through my house to provide environmental monitoring. I’d recommend Tasmota but they don’t support the analog pin without recompiling the source yourself. The nice thing about EPS Easy is there is no coding, just configuration through a web interface and it supports OTA updates of the firmware. Also, there is a plug-in that supports the Homie convention (I’ve not yet tried to use it) which will enable automatic discovery of the device so they will show up in the Inbox just like Zwave devices do. No configuration required.

The one nice thing that that Tasmota has though is a central administration service you can run to update and configure all of your Tasmota devices from one location.

The diy home automation domain is old enough now that you almost never have to code this stuff yourself unless you really want to. :slight_smile:

1 Like

This is fantastic! I had been wondering what I was going to do when my main house was finished. One Z-Wave network covering two houses and a workshop would certainly have been asking for trouble. This way, I can leave an RPi with the UZB1 in place as a slave in the small house as I and the main controller move to the main house in two years when construction is done. One less thing to worry about. Thank you! :slight_smile:

No coding? But that’s the fun part! :wink:

My next little project, as soon as my Wemos D1 Mini boards arrive, is to IP-enable my kitchen ceiling fans, by way of one board + ir emitter inside each ceiling fan electronics housing, so I can stop using the fiddly remote control that came with them. Just the thing to keep me busy on a rainy day.

tutorials would be much appreciated if you get that working. I don’t think we have such a tutorial on the forum yet.