[zwave]: issues with Qubino Weather Station (ZMNHZD)

Hi community,

I have a several problems with a new Qubino Weather Station.

  1. The 1st thing I did was to complete hte zwave configurations to the z-wave device database:
    http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/364

But this could not finished due to some database issues.
@chris Maybe you can have a look at this.

  1. Never the less I have been able to export the the XML file from database and put the result to
  • database/qubino/zmnhzd.xml
  • database/products.xml

Build result: org.openhab.binding.zwave-1.9.0-SNAPSHOT.jar

Now habmin was able to recognise this device.

Unfortunately only ‘SENSOR_MULTILEVEL’ items configured for endpoint = 0 were seen. All the other sensors configured as ‘SENSOR_MULTILEVEL’ with endpoint>0 are not reported.
An interesting point is, that ‘BATTERY’ reporting works well for endpoints > 0.

Has anyone an idea how I can check this and get it working?

I have prepared a log file:
https://www.dropbox.com/s/ezgql58fvzikqph/zwave-zmdhzd.zip?dl=0

Bye, Jens

Hi Jens,

What still needs to be done? I fixed up the errors you mentioned last weekend I think (unless I missed something?).

I will try and take a look at the log later tonight.

Seems I missed your changes and approval on it. No more action required from the datebase point of view. Thanks.

Hi @Chris, in case you need more information please let me know. I can also do some debugging for you but I need some details which functions of the zwave stack may affected.

Thanks.

The log looks basically ok. Have you tried a recent version of the binding since the device was added to the database? Is the device detected ok?

Since the binding infomation was not yet part of the current zwave-device-database I checked out the OH-master branch and put my modifications there. Outcome was (see above) a snapshot of version 1.9.0.
I think the device is now well detected.

@Chris: I wrote you a PM with some other details.

Sorry - I didn’t realise you were using OH1 (sorry if you mentioned this) so it was only added to OH2.

I replied to your PM - I don’t know what question you asked but I think there is some confusion since the binding of course supports both multi-channel and multi-instance. Multi-Channel is an updated version of multi-instance and both are supported.

Yes I still use OH1. What do you mean with “so it was only added to OH2”?
Do I need to Switch over to OH2?

My problem is still the issue as described above.
This zwave device has in sum 11 endpoints (0-10) as you can refer from the database information. Each endpoint supports the SENSOR_MULTILEVEL command class. But only reports from SENSOR_MULTILEVEL at endpoint=0 were seen and reported by the zwave binding.

SENSOR_MULTILEVEL reports for endpoint>0 were never seen.

I have no idea why these values are not supported.
For your info, the BATTERY report is working well and I am able to receive battery values from all endpoints. But this is for sure a different command class.

I only added the database entry to OH2. OH1 doesn’t use the database other than for configuration, but as items are manually configured in OH1, it does not require any input from the database in any way.

I couldn’t easily tell this from the log as it didn’t contain the packet information, but I could see many different parameters being received. If you can provide a full debug log I’ll take a look.

Normally multi-channel data is provided also in the root endpoint as well as the other endpoints. Since you don’t say how you have configured your items I don’t know how this is works in your system…

Please find here my used item configuration for OH1. I have added some comments to the end of each line, which items were (not) seen.

Group grWeatherStation 	   "Wetterstation"           <weather>		(grHouse)	
Group grWeatherStationBatt

Number WS_THS1_Batt "Batterie Ch1 [%s %%]" 	 <battery>	(grWeatherStation,grWeatherStationBatt) 	{zwave="18:1:command=battery"} //seen
Number WS_Wind_Batt "Batterie Wind [%s %%]" 	 <battery>	(grWeatherStation,grWeatherStationBatt) 	{zwave="18:6:command=battery"} //seen
Number WS_Rain_Batt "Batterie Regen [%s %%]" 	 <battery>	(grWeatherStation,grWeatherStationBatt) 	{zwave="18:7:command=battery"} //seen
Number WS_THS2_Batt "Batterie Ch2 [%s %%]" 	 <battery>	(grWeatherStation,grWeatherStationBatt) 	{zwave="18:9:command=battery"} //seen

Number WS_THS1_Temp "Temperatur Ch1 [%.1f °C]"	     <temperature>  (grWeatherStation)	        {zwave="18:0:command=sensor_multilevel,sensor_type=1,sensor_scale=0"} //seen
Number WS_THS1_Humi "humidity Ch1 [%.1f %%]"            	    (grWeatherStation)	        {zwave="18:0:command=sensor_multilevel,sensor_type=5"} //seen
Number WS_Wind_Velo "Windgeschwindigkeit [%.1f m/s]" <wind>         (grWeatherStation) 		{zwave="18:0:command=sensor_multilevel,sensor_type=6"} //seen 
Number WS_Wind_Dir  "Windrichtung [%.1f °]"                        (grWeatherStation)          {zwave="18:0:command=sensor_multilevel,sensor_type=7"} //seen
Number WS_Rain      "Regen [%.1f mm/h]"		     <rain>	    (grWeatherStation)		{zwave="18:0:command=sensor_multilevel,sensor_type=12,sensor_scale=0"} //seen 

Number WS_Wind_Gust "Windgust [%.1f m/s]"                       (grWeatherStation) 	{zwave="18:4:command=sensor_multilevel,sensor_type=6"  } //never seen
Number WS_Wind_Temp "Aussentemperatur [%.1f m/s]" <temperature>	(grWeatherStation)	{zwave="18:5:command=sensor_multilevel,sensor_type=1,sensor_scale=0"} //never seen
Number WS_Wind_Chil "Wind-Temperatur [%.1f m/s]"  <temperature>	(grWeatherStation)	{zwave="18:6:command=sensor_multilevel,sensor_type=1,sensor_scale=0"} //never seen
Number WS_THS2_Temp "Temperatur Ch2 [%.1f °C]"	  <temperature>	(grWeatherStation)	{zwave="18:9:command=sensor_multilevel,sensor_type=1,sensor_scale=0"} //never seen
Number WS_THS2_Humi "humidity Ch2 [%.1f %%]"                	(grWeatherStation)	{zwave="18:10:command=sensor_multilevel,sensor_type=5"} //never seen

Here we go: https://www.dropbox.com/s/ovakb18e2dbclwu/zwave-2016-44.7z?dl=0

Sorry - this log is 105MB (!!) so I can’t process something this big - it needs to be 10MB or smaller to process it through the viewer.

I had a quick look and it seems the device doesn’t send using the multi-channel. As I said in another mail, this might be due to the fact that associations are not set using the multi-instance-association as I see on other Qubino devices, but I don’t know why you specifically want this if all the data is available in the root since I do not intend to support the multi-instance-association in OH1 if that is actually what is stopping it sending the multi-channel messages.

Ok, I can finally check to provide you a smaller junk of logs.

And this is even not the case. 5 of 10 params were never seen.

So far I should think about moving from OH1 to OH2…

Thanks - if we can get a log showing some requests and responses that should be fine.

Also, have you tried polling - that may work ok in OH1 since it doesn’t rely on the multi-instance-associations to be configured.

Please find here a log <10MB. Hope this works better for some investigations. https://www.dropbox.com/s/t97377nosrksscf/zwave_log_short.7z?dl=0

I have changed all the affected items like

{zwave="18:4:command=sensor_multilevel,sensor_type=6,refresh_interval=120"  }

… but finally no change. In the latest log above these settings were activated.

Many thanks for your time and given support until now, Chris :slight_smile: Very appreciated.

So, the device is not responding with multi-channel requests - even though the binding is sending them…

In some cases, it doesn’t respond at all…

And the only channel that I have found that responds to multi-channel is the battery -:

I’m not really sure why this is configured for multiple endpoints though since I’m sure there’s only one battery…

This behaviour might be related to the multi-channel-association which is not supported in OH1, but I can’t say that for sure.

The ZWave standard however does state the following -:

Responses to a given frame must be carried out using the same encapsulation or lack of encapsulation as it was received,

In my opinion, this behaviour is non-compliant…

Many thanks for your investigations.

Right, Battery reporting works well.

No, the weather station has 4 units, all with batteries. These units are sending through RFXCom. The z-wave stick is more or less a converter from RFXCom to z-wave. Threrefore more than one battery reports are available.

I think this is really the case because I took the time to check this device with OH2 and everything works well with the new z-wave stack coming with OH2.

Unfortunately I could not stay at OH2 (for daily use) because not all my used z-wave devices are working with OH2. If you like, I can create seperate issues in OH2 section.

@Chris, do you think it is possibe (even for me) to port the multi-channel-association from from OH2 to OH1?
Maybe you have an idea about the expected effort for implementing and test?

Of course, anything is possible, but really, it is a lot of work. It’s not a simple command class update, and the problem is that it requires a significant change to the binding since you need to map the ASSOCIATION class, and the MULTI-CHANNEL-ASSOCIATION class to the same data. Then, it requires very major changes to HABmin (or another software if you like) to support this. I started this on OH1 quite a long time ago, but as it required significant changes to the structure of the binding, I never completed it until OH2.

Why not try and get your devices working on OH2?

hi all

I am a Vera MIOS user for the past few years, but due to the lack of integrating and time for Vera to implement new devices I have started looking around for a system that can specifically support the Qubino Weather station. I have seen that Openhab supports it, but with OH1 it has been too difficult to install the software.

2 days ago I decided to give it a go again, and so glad to see that OH2 has been released. I am using Openhabian and it has been a breeze to install.

Still trying to get my mind around everything. I have tried multiple times to get my Weather station to show up correctly, I am even now on the snapshot releases.

Some sensors are duplicating, some are not picked up correctly, like rain rate is Humidity.

Some info from my system below:

Z-Wave Node 3: ZMNHZD Multifunctional Weather Station
ZMNHZD Multifunctional Weather Station

zwave_class_basic ROUTING_SLAVE
zwave_class_generic MULTILEVEL_SENSOR
zwave_frequent false
zwave_neighbours
zwave_version 1.2
zwave_listening true
zwave_plus_devicetype AIR_TEMPERATURE_SENSOR
zwave_deviceid 83
zwave_nodeid 3
zwave_routing true
zwave_beaming true
zwave_class_specific ROUTING_SENSOR_MULTILEVEL
zwave_manufacturer 345
zwave_devicetype 7

Here is the link for the xml file that got created, new user so can’t upload yet: https://drive.google.com/file/d/0Bz8-IYzwsS9nUlMyNDF5cGdDcmM/view?usp=sharing

Some other controllers have picked up it very nice where it shows the wind direction not just as a number, but actual direction (i.e. North West):
http://www.planete-domotique.com/blog/en/2016/09/29/showcase-of-the-z-wave-weather-station-by-qubino/

Please let me know if you need any more information, I am still a noob with OH, but I can see a lot of potential.

thank you.
Ivan

Can you be clear about exactly what is wrong please? Which sensors are incorrectly labeled?

The duplication is due to the way the device is exposing the channels - it exposes the same data in the root endpoint as well as the individual endpoints. We can easily remove that, but of course you can also remove this by simply not linking these channels. It’s quite common for devices to expose multiple views of the same data - eg using the sensor_binary, and the notification command classes. The user is free to decide which to use in OH2 - just don’t link the two channels.