Z-Uno - Arduino Z-Wave node

Have there been any updates to this ? We have one on the desk here, and it does not discover correctly, due to missing db entry.
Can one be submitted ? or even better, overide locally ?

McIvar

Is the number of endpoints, and the command classes per endpoint (etc) fixed, or does it change depending on what you implement in the sketch? If it changes, then it’s really going to be a problem at the moment - if it’s fixed, then you can of course submit a database entry for it.

The number of endpoints depends on the user scketch.

May be you can help us understand your templates (write few for two-three examples from http://z-uno.z-wave.me/examples/) and then we can make a script that makes such templates based on user sketch?

But I would definitelly prefer OH to get all the defined channels from Z-Uno via standard Z-Wave protocol features… Pitty OH do not support it. May be it is time again to discuss adding our Z-Way as Z-Wave binding to OH instead of the your native Z-Wave binding? We support Security and many more features :wink:

I would be interested in this. Have nothing against @chris Z-wave binding, but it’s always good to have alternatives.

Other thing - according to http://z-uno.z-wave.me/examples/ Z-uno has certified Sketch with 0 channels. This must be the one, suitable for most users. Perhaps this should be added to Database first?

Yes - this is planned. The issue is that when the zwave binding was first written (12 months ago or more) OH2 did not support dynamic channels - everything had to be statically defined in the XML files. Since then, ESH has changed to allow dynamic channels so this is now possible.

I definitely agree that the static definitions aren’t so nice in many ways - currently the system provides the same functionality, but through the database - ie the binding interrogates the device and produces an XML, the XML is then read into the database which produces the channels - config parameters are added, and this is exported to the binding. The static XML does have some advantages though in that it allows modification of the definitions to work around device issues, and properly name channels etc. In the end, I think that a combination is probably best since XML will always be needed to fully define configuration.

Currently the binding is undergoing some refactoring following the public release of the ZWave standard. This will take a little time, but dynamic channels are planned (as I have done in other bindings already).

The ZWay binding is already an option I think, however for a number of reasons I don’t think it is right for ESH/OH2 - this is a similar to the use of Z/IP that I’m discussing with Sigma.

I’m really looking forward to the news about Z-Uno.

I was curious about the status of supporting Z-Uno? As this seems to be the most recent post I can find about it.

Any news on this?

Hi, +1 :slight_smile:

At the moment I don’t think it’s well supported, but I’m not sure. There is something added to the database, but since every device has the same device information, I’m not sure it works well. Since I don’t have one I haven’t tried this so maybe someone with a Z-Uno can comment.

I have just setup openhabian in a raspberry 3 model B with razberry. I have tried to add Z-Uno with the default sketch (a simple blinking) but unfortunatelly razberry detects it but it is not able to add as it is not in the database.

These are the log entries for the inclusion try:

2017-08-28 18:16:03.461 [BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@189d8c2
2017-08-28 18:16:08.542 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:cc34bab9:node29’ to inbox.
2017-08-28 18:16:08.543 [InboxAddedEvent ] - Discovery Result with UID ‘zwave:device:cc34bab9:node29’ has been added.
2017-08-28 18:16:08.560 [BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@14e3943
2017-08-28 18:16:08.632 [WARN ] [rialmessage.IdentifyNodeMessageClass] - Got IdentifyNodeMessage without request, ignoring. Last message was SendData.
2017-08-28 18:16:19.076 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 29: Device discovery could not resolve to a thingType! 0115:0110:0001::2.9
2017-08-28 18:16:33.222 [BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@171b3b2

Hi again,

I have been checking the Z-Uno XML definition in the database (reference 494). It is in the next link:

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/494#

In the definition there are errors that are the next:

Device definition contains errors

  • Command Class “SENSOR_MULTILEVEL” in endpoint 0 is duplicated!
  • Channel in endpoint 0 uses an unsupported channel (temperature)!
  • Channel in endpoint 3 uses an unsupported channel (temperature)!
  • Channel in endpoint 22 command class SWITCH_BINARY has no name!
  • Channel in endpoint 22 uses an unsupported channel ()!

I am quite sure that the content in “Channels” tag should be as follows in order to accomplish the description of the XML file:

      <channel id="switch_binary" typeId="switch_binary">
        <label>Switch</label>
        <properties>
          <property name="binding:*:OnOffType">SWITCH_BINARY,BASIC</property>
        </properties>
      </channel>
      <channel id="switch_dimmer" typeId="switch_dimmer">
        <label>Dimmer</label>
        <properties>
          <property name="binding:*:DecimalType">SWITCH_MULTILEVEL</property>
        </properties>
      </channel>
      <channel id="sensor_temperature" typeId="sensor_temperature">
        <label>Sensor (temperature)</label>
        <properties>
          <property name="binding:*:DecimalType">SENSOR_MULTILEVEL;type=TEMPERATURE</property>
        </properties>
      </channel>
      <channel id="sensor_binary" typeId="sensor_binary">
        <label>Door Sensor</label>
        <properties>
          <property name="binding:*:OnOffType">SENSOR_BINARY,BASIC</property>
        </properties>
      </channel>

With this XML definition, a Z-Uno sketch with this channel definition should work:

ZUNO_SETUP_CHANNELS
(
  ZUNO_SWITCH_BINARY ( getBinary , setBinary)
  ,ZUNO_SWITCH_MULTILEVEL ( getDimmer , setDimmer)
  ,ZUNO_SENSOR_MULTILEVEL ( ZUNO_SENSOR_MULTILEVEL_TYPE_TEMPERATURE , SENSOR_MULTILEVEL_SCALE_CELSIUS , getTemperature )
  ,ZUNO_SENSOR_BINARY_DOOR_WINDOW ( getDoor )
);

I have read, and I understand, that as each sketch is different is not possible to have every existing channel combinations in the database.

But as there is a Z-Uno definition in the database and its definition is wrong, I think that fixing it could be good for everybody and at least we will be able to test some sketches in Z-Uno with this 4 channels configured.

In fact, maybe the best way could be to create an Z-Uno XML with one of each available channels (9 if I am not wrong). This way, everybody could develop modules with this channel definition and use the channel more appropiated for his sketch.

Do you thing some of these two options could be possible, @chris?

Regards.

If I understand this, you want many different database entries? Unfortunately, this is not possible since the ZUno always uses a fixed device type/id identifier so there’s no way to differentiate the different versions. Please correct me if I’m wrong, but that’s what I was told.

My thought was to “simply” add all channels… Is there a “superset” of channels that we can define - I don’t know how flexible ZUno is with defining endpoints etc, but if we can get a single definition that covers everyones needs, then this seems to be the best way at this time.

I have very limited knowledge of the ZUno so can someone comment on the above idea? In the longer (medium) term I hope to make the binding more flexible and less dependant on the database in this area, but that will still be a little while away.

Hi @chris.

Blockquote If I understand this, you want many different database entries? Unfortunately, this is not possible since the ZUno always uses a fixed device type/id identifier so there’s no way to differentiate the different versions. Please correct me if I’m wrong, but that’s what I was told.

No, no, an unique entry: fixing the current entry or redoing it as a “superset”.

I was talking about two options:

  1. Fixing the current entry that has some errors. It is not the best option, because it has just 4 channels defined, so all the people want to use Z-Uno will need to develop a sketch with just this 4 channels. In the other hand… this first option is easy, because you just need to replace the wrong channel definition by the channel definition I have posted in the previous message (I think it is OK). Currently this wrong entry is not usefull for anybody.

  2. As you tell, the best option, but not so easy as the previous one, is to replace the entry by a wide definition with all the possible channels Z-Uno is able to use. I am not an expert, neither in openhab nor in Z-Uno, but I think that Z-Uno is pretty flexible to adapt to this “superset” you are purpossing.

Here is the link to the Z-Uno reference documentation, just in case someone want to check it:

https://z-uno.z-wave.me/reference/

As far as I know, Z-Uno has basically this 8 kind of channels:

  1. ZUNO_SWITCH_BINARY()
  2. ZUNO_SWITCH_MULTILEVEL()
  3. ZUNO_SENSOR_BINARY()
  4. ZUNO_SENSOR_MULTILEVEL()
  5. ZUNO_METER()
  6. ZUNO_BLINDS()
  7. ZUNO_FLOWSTOP()
  8. ZUNO_SIREN()

Basically, from 1 to 4 are the basic channels, that are currently developed in the datbase entry. From 5 to 8 seems to be mods of the first four kind of channels. For instance, ZUNO_SIREN is a Binary Switch. This is the reason, I suppose, because of the current database entry has just 4 channels defined: one for each main functionality.

If you need me to perform some test, just let me know.

Regards.

Out of curiosity, what are the advantages / disadvantages for using zwave rather than e.g. Wi-Fi (ESP8266)?
How do they different in power consumption, range, etc.?
Thanks

I think that’s a little off the topic of this thread - maybe a good topic for discussion elsewhere though if you want to start one…

Sorry @chris, you are right. I opened another topic here

1 Like

So I’m thinking about getting a Z-Uno to water four of my plants… using a 4x analogue in pins (for 4 moisture sensors) and 4 digital out pins (for the Solid state relays to 4 small pumps)… Before I buy the stuff though… am I correct in understanding that OpenHAB allows the following channels to be added and used?

Those should likely work for me… I’ll likely add 4x ZUNO_SENSOR_MULTILEVEL, and 4x ZUNO_SWITCH_BINARY on that device… Am I missing anything about the current OpenHAB support? Thanks in advance!

1 Like

For anyone that wants to go the route that I took (compile the binding with your own DB XML), here is a thread where I documented my process to get up and running with the Z-Uno.

My use case was an RGB LED light strip:

@chris I recently discovered that Z-Uno allows you to set your own Product ID from within the sketch. Using this product ID, there can be multiple database entries for the Z-Uno, each with a unique product ID. See the documentation Here.

Without using this function, the product ID defaults to 0X0110 and 0X0001 resulting in 0110:0001

However, you can use this function to set your own product ID which will result in 0111:XXXX (the 0111 is not editable, the XXXX is whatever you set it to be).

Hope this helps!

2 Likes