How to transport data to Z-UNO

[mdietinger@gmail.com]

Is there a way to transport data from Z_Wave controller to Z-UNO other then the quite limited ZUNO_SWITCH_MULTILEVEL which only allows to send 0-99?
My plan would be to send actor ID's and names to Z-UNO, store them in EEPROM.
If there is a chance to send at least eg. 4bytes at the same time it would be possible with several transmissions to build the EEPROM table with ID's and names.
Once stored open, close and breach events would be send over the same channel only providing ID and status.
With that information a status display (eg. OLED) can be established.
Additionally with similar protokol more than 10 channels would be possible using scenes and virtual devices.

[A.Harrenberg]

Hi,

there is the class NODE_NAMING which would allow you to send a node name and a location name to the device. However this class is currently not supported and I have not seen any device in the field that supported that class.

The command class is limited to 16 character for each of the name and location and is for the complete device, so you can't give a name to each channel.

To define IDs there would be the possibility to use the CONFIGURATION_CLASS, currently there is only the debug and the LED control implemented, but I think that they stated that it will be implemented in one of the next releases.

Then there is TRANSPORT_SERVICE which is meant for transporting larger frames of data, it is also not implemented and I have never seen such a class in the field and don't know exactly how this would be used.

Another class that might be abused for this purpose is USER_CODE, it allows to set user codes for e.g. entry control systems. There you can set up users with 4-10 ASCII characters as their code. But again, this is currently not implemented.

At the moment I can't think of any other command class that would allow to transport and store some ASCII and unfortunately none of the above is currently available.

Once stored open, close and breach events would be send over the same channel only providing ID and status.
With that information a status display (eg. OLED) can be established.
Additionally with similar protokol more than 10 channels would be possible using scenes and virtual devices.

I don't understand what you mean here...
I believe that the number of 10 channels is a limitation from the ZUNO-team and could be increased. The current implementation is that each channel can only hold one value and that only this value can be reported. Other devices can report more values on a single channel, as long as there is only one of each type, for e.g. temperature and humidity the values can be distinguished by their unit. It is not possible to send 2 temperatures in the same channel! This is not a limitation of the ZUNO, you just can't distinguish them...

Do you really have an device in mind that will need more than 10 channels? What use do you have in mind?

Regards,
Andreas.

[mdietinger@gmail.com]

Andreas,

thanks for your extensive answer.
Maybe I need to describe in a bit more details what I want to achieve:
I want to keep a list with all doors and windows device ID and Names in Z-UNO.
One option is to hardcode in usercode, or store in EEPROM with a separate code processed once to store and then let the user code have access to that stored values.
Idea is to have a LUA scene(HC2) to report status changes like open, close or breached to Z-UNO and either display using LED's or with an OLED.
If there would be chance to transport bigger sets of data to Z-UNO other than 0-99 that table could be maintained using a LUA script without the need to touch Z-UNO again.
For this I have a simple protocol in mind to transport data to be stored in EEPROM or to trigger actions on Z-UNO.
For example:
Byte 1 Action (eg. 1-write to EEPROM, 2-read from EEPROM, 11-Door open, 12-Door closed, 13- Door breached, ....)
Byte 2&3 Device ID
optional Byte 4-x Information to be stored in EEPROM.

To support more than 10 Channels same or similar protocol can be used in LUA szene together with virtual device to for example address 20 LED's to display status of doors/windows, or to address 15 Relais, or to report 12 temperature values back to the Z-Wave controller.

In any case looks like this is not possible at the moment and if I want to implement a kind of status display in Z-UNO it would be possible, but would require multiple Switch_Multilevel channels and store lookup table in Z-UNO.
For example:
One to report Open event for Door/Window 1 to 99
One to report close event
and One to report breach

To me it looks like there is a rather high demand for users to have status displays for Z-Wave for being able to monitor status of their house and this could result in a push for Z-UNO given there are usable code examples available to realize status displays for the most common Z-Wave controllers.

best regards,

Markus

[A.Harrenberg]

Hi,

beside that the ZUNO-team has to implement classes, there are only a limited amount of classes available... And I don't know if e.g. the TRANSPORT_SERVICE allow transport of ANY kind of data.

One option I have missed before is the MANUFACTORER_SPECIFIC class. It is possible to have device specific, customized functions in the MANUFACTORER_SPECIFIC class, that would also be a possibility if the ZUNO team can generate a simple class that just use the ZWave transmission to transport the data. Then the "protocoll" has to be implemented at HC2 and at the ZUNO side and you would be able to do whatever you want!

Regards,
Andreas.

[PoltoS]

We plan to add Configuration Command Class with user defined config parameters. They will be 4 bytes params. 100 paramteres will be available. This will become available in January.

Beside this there is a ScreenMD Command Class, but no controllers support it. NodeNaming is not for this, it is to name the node. Manufacturer Proprietary is not allowed to use unless Sigma will approve it. And no controllers support it.

[A.Harrenberg]

Hi PoltoS,

We plan to add Configuration Command Class with user defined config parameters. They will be 4 bytes params. 100 paramteres will be available. This will become available in January.

that is good news!

Beside this there is a ScreenMD Command Class, but no controllers support it. NodeNaming is not for this, it is to name the node. Manufacturer Proprietary is not allowed to use unless Sigma will approve it. And no controllers support it.

I wasn't aware of ScreenMD, but it really looks that there is no support for it at the moment. But that would be great for controlling an OLED and send out any kind of status information. I guess that the priority to implement that in ZUNO is quite low? I could try to implement that class into the system I am using (fhem) and would love to have it, but for all other controllers/systems it would not be supported...

For the Manufacturer_Proprietary you mean ZUNO is not allowed to implement this unless Sigma will approve it? I know that there are some Fibaro sensor that use this class and at least one of these sensors is supported in fhem using a special command to control a shutter/blind and report the postion of the shutter/blind.

Regards,
Andreas.

[PoltoS]

I guess that the priority to implement that in ZUNO is quite low? I could try to implement that class into the system I am using (fhem) and would love to have it, but for all other controllers/systems it would not be supported...

Indeed, quite low. Even out Z-Way do not support it. We can add it - one work day in Z-Way and three in Z-Uno, but would that be so popular in usage to do it? Is it worth?

For the Manufacturer_Proprietary you mean ZUNO is not allowed to implement this unless Sigma will approve it? I know that there are some Fibaro sensor that use this class and at least one of these sensors is supported in fhem using a special command to control a shutter/blind and report the postion of the shutter/blind.

Indeed, Fibaro use it for lamel function. Some others do same. ANY company MUST be approved by Sigma to use this Command Class. This is to push companies to improve existing Command Classes instead of making own proprietary non-interoperable features. But many violate this.

BTW, can you share the Fibaro lamel support with us? We thought about implementing it in Z-Way unless they change it to interoprable way. But again... not sure it is worth spending the time

[A.Harrenberg]

Hi PoltoS,

Indeed, quite low. Even out Z-Way do not support it. We can add it - one work day in Z-Way and three in Z-Uno, but would that be so popular in usage to do it? Is it worth?

probably not, I would love it to use an OLED, but there might be less than 5 people in the whole world who would use it... So maybe you can add it to the very end of you list

Indeed, Fibaro use it for lamel function. Some others do same. ANY company MUST be approved by Sigma to use this Command Class. This is to push companies to improve existing Command Classes instead of making own proprietary non-interoperable features. But many violate this.

Yes, I am always suprised how many broken devices are on the market. The last thing I noticed was a sensor that reported 3 bytes for the sensor value where only 1, 2 or 4 are allowed... This caused some very strange reactions as the third byte was "thrown away"...

BTW, can you share the Fibaro lamel support with us? We thought about implementing it in Z-Way unless they change it to interoprable way. But again... not sure it is worth spending the time

I will have a look in the code what commands/reports are implemented and can provide you what is implemented. But I don't know if it is complete...
The Fibaro can also be set to only work with the standard ZWave-commands, but then there is no position report for the blinds, so for this special use case it is definetely better to use the proprietary commands/reports.

Regards,
Andreas.