forum

Hi,

I am playing around with a DHT11 sensor which provide the temperature and the humidity via an one-wire interface. (There is a DHT library available for the sensor...)

I just took the "simple dimmer" example and added extra (seperate) channels for temperature and humidity. Now I end up with a main device plus three seperate sub-device for the dimmer, the temperature and the humidity. The plan is to add more sensors (motion, gas-sensor plus some buttons) but I don't like to have a sub-device for EACH of them.

The only way I currently see (but maybe I am overlooking some possibilities of the Z-Uno here) is to send reports via zunoSendReport(<channel_no>) command, where each channel only hold on value / measurement. I can not see how it would be possible to define a channel with more than one value and how to send these different values.

I am wondering if it would be possible to have such reports send to the main device WITHOUT having a subdevice AND to send several different values...

I have an AEOTEC Mulitsensor which send out humidity, luminance, UV-index, temperature, motion and vibration just to one main device. I would like to create such a behavior with the Z-Uno.

As long as I only have one value of each sensor_type this should be possible (and distinguishable). Having for example two temperatures won't work because they can't be distinguished, for that different channels have to be used. One drawback is that only one value can be requested, but that might be acceptable as it work for the AEOTEC Mulitisensor for me...

Would that be possible or is it related to the simplified approach / the encapsulation of the ZWave functions of the Z-Uno?

Any hints are welcome,
Andreas.

Z-Uno aims to simplify things. Our rule is one value = one channel. Otherwise how would you say which report to send?

Nowdays all controlles handles multichannel devices without problems. Normal users should not really care how does it look internally in Z-Wave.

Hi PoltoS,

PoltoS wrote:Z-Uno aims to simplify things. Our rule is one value = one channel. Otherwise how would you say which report to send?

Let's take the example of the AEOTEC Multisensor. You can request only the temperature from the device, that is the "default" report to send, but it also send out all its other values to the same device without creating a multichannel device. I think that this is fully compliant with ZWave specification.

I understand your target to make using ZWave simple (and you do a good job here, it is amazingly simple!), but are there maybe more lowlevel functions available that I could use to create "other" reports than the default one?

PoltoS wrote: Nowdays all controlles handles multichannel devices without problems. Normal users should not really care how does it look internally in Z-Wave.

My Controller handles multichannel devices, but I don't like get so many devices in my system. Looking up the different values from different device is not very comfortable, it would be much easier if they were reported in one location. I don't know how Z-Way represent multichannel devices to the user, It might be more user-friendly than my system. The representation here is more hardware/device oriented and multichannel is represented as another sub-device. I will include the Z-Uno in my RazBerry system with Z-Way to see how multichannel is supported there.

Best regards,
Andreas.

in Z-Way it.is same for multichannel and non-multichannel. In Fibaro and some others too. That's why we decided to make it that simple way internally

For me this is ideal. Because every device can be used in complex rules separately. I do not have to care which value to evaluate first, because there is one device per value. If you like to have something more compact you can use the combined sensor app (razberry web ui) which can combine multiple devices to one with all values. You can then hide the single devices so they won't show up in UI.

Hi ftrueck,

thanks for the information, but I am not using Z-Way...

I can also create some readinggroups where the data from different devices is combined in my system, the background here was more technical as I wanted to understand how to create a device that behave like the AEOTEC Multisensor.

I just don't like to have so many devices in my lists. I will have a look at my Z-Way again to see how the device are organized there, it seems that the look-and-feel is quite different to my sytem, which is very hardware oriented.

And if they extend the logic of which sensor values are also send to the root-device to alle more multilevel sensors as long as the TYPE of the sensor is different, then it will come quite close to the behavior of the AEOTEC.

Are you planning to build some specific device with the Z-Uno? Currently I am only playing with it, but the box with all the other sensors did not yet arrive... ,-(

Hi,

I also think that this implementation is the most logical for most cases.
One channel - one value / one action (switch etc.)
If you have 10 sensors (different type or same type) - in most cases it will be 10 devices.

Right, a multisensor is the same "device unit" - but anyway this are 4 internal devices/sensors.

@Andreas:
What sofware you are using? Even in OpenZwave it is working fine - and I can not see a difference (from users view) compare it with Aeon Multisensor...

Michael

Hi,

I am using FHEM, also an open source home automation system. The presentation the user is much more hardware oriented and as each channel is generated as a sub-device I got more devices.

Off course there is the possibility to create a "readinggroup" that show the values from various devices, but that is not the native view.

I still disagree that it is the most logical implementation in most cases. If you have a temperature/humidity/ambient pressure sensor e.g. from a weather station, there is really no need to have three devices for that. ZWave is capable of distinguish between a value send as temperatute/humidity/pressure.

I agree that this is the easisest implementation in terms of the Z-Uno. "Behind" the functions there are a lot of encapsulations for the "real" ZWave-functions, and that is quite complex, so I can understand that this is choosen.

Andreas.