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?
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.
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.
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…
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.
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.
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
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.
Very appreciated.
