Testing Z-Wave binding on openHAB-2

Thanks chris, but I’m not sure that I have understand what you said. Who defines the data type which is associated with the channel? Is this done automatically during channel discovery? If so, comes the definition from the device itself?

And can I change the data type manually afterwards? With HABmin or PaperUI?

If I understand you right, when the data type is defined let’s say as a CONTACT, the item type also has to be CONTACT. For my problem (as only item type SWITCH has worked), the data type has been set to SWITCH?

Or in other words: As I want the device to work as a CONTACT, I’d have to change the data type to CONTACT (if possible).

Sorry for these questions. I could have tried this myself, but I recently switched back to OH1, so I have no working OH2 installation at the moment. I just try to get the problems solved which I have discovered. For the next migration you know… :wink:

It is defined in the channel definitions in the binding which is in this file here.

No - as above, this is defined in the channel definition. The binding doesn’t have any visibility of items, so it doesn’t know if you change the type, and then it doesn’t work (as you’ve found already).

It sounds like it?

The data type is defined in the channel definition and you can’t change it once the channel is defined.

It’s possible that the channel is not well defined of course, and we can look to change this if it makes sense. I clearly don’t have every device to test against so some will likely be wrong as there are a lot of channels, unless people provide feedback. In some cases, we should abide by the data types defined in ESH as well.

So this file isn’t device based. Does this mean that the channel of every window sensor is wrong in OH2 (which I won’t think)? Or does the sensative device acts some kind of non-standard so that the data type is set wrong? How can I find out what went wrong and how to correct this? When I take a look at your DB entry, there is some kind of “sensor luminance” values. Does this make sense, as it is only a window sensor? Couldn’t find this for example in the pepper db for this device. Maybe this is not directly related to this issue, but could it be that the device is not properly stored in your DB and therefore not properly discovered?

Can I be of any help to resolve this issue?

No - it’s common for all devices.

What do you mean by “wrong”?

I think I’ve said - this is defined in the channel definitions. I don’t know what you mean by “what went wrong”? ESH defines that a Door and Window should be a switch - as per the link I provided you above.

Probably not, but I guess someone either added this to the database, or the sensor reports that it supports this. What is in your XML file?

If there are database errors, then someone should correct them since they won’t correct themselves. The database is generally created from information reported directly from the device.

What do you mean by “not properly discovered”? It seems to be discovered ok if you are getting the channels added. Sorry - I’m confused a bit by this as I thought that it was discovered ok? Can you clearly state what the problem is?

And you have the right to be confused! :wink: It was my fault that I assumed because of OH1 has used the sensor as a CONTACT, that OH2 operates the same way.

Well, obviously the only one who was “wrong” was me. :slight_smile: I didn’t have had a closer look to the link you provided, so I didn’t found out that ESH defines a window sensor as a switch. I thought: In OH1 my sensor was a CONTACT, so in OH2 it has to be the same way, otherwise something went wrong. If it is defined that a window sensor is a switch, then nothing went wrong.

So there seems to be no problem.

Concerning the (maybe) not correct DB for the sensor, I’ve had a look at the XML, but couldn’t find anything with “luminance”. Is there a possibility to compare the XML with the DB information?

node5.xml (8.1 KB)

I should add that I don’t necessarily disagree with you on this. Also, there has been a lot of discussion about this sort of issue and the fact that bindings don’t know about the item type causes problems, and I think one day this might change which would be a big help I think. See below where this same issue was discussed previously…

Not automatically, but I agree with you, there’s nothing in there that shows SENSOR_MULTILEVEL so I’ve removed this. I would guess that someone added this by accident (I hope!) but I’ve not checked back through the history…

Hi

I’ve thought about moving my OpenHAB 1.8… installation to OpenHAB 2. And in the same time move my z-wave network from a VeraEdge to UZB stick, using Habmin as my z-wave controller. I have about 30 devices so it will take some time to make the move. Initially I’m not satisfied with the Vera (z-wave response, unstability, etc…) and are hoping that OpenHAB with Habmin will remedy a lot of this or at least make it simpler to identify problems in the network and fix it.

So today I’ve done some initial testing and made myself familiar with OpenHAB 2. There are some questions I have though.

One is regarding the autodetection and naming conventions for the Items linked to a Thing. They are very long, why is this? A Thing named LightsBath for example, why not call the Dimmer item for “LightsBathDimmer” instead of something like “zwave_device_f5a40e1f_node2_switch_dimmer1”? It makes writing rules, sitemaps a lot more troublesome the way it is now. And if this is not possible to achieve, is there an .items file stored elsewhere so the names can be changed or is the general idea to move away from items file and such?

Two (this is a little off this topic), since I already have a bunch of items through my Mios binding, can I delete the definitions (the curly brackets part) of the items and link them to the correct Thing Channel (after adding the Thing) using the Habmin UI? This would simplfy a lot and mean that I could keep most of my rules like they are now.

Hi,

I do recommend to switch of the “simple mode” for “Item Linking” in Paper UI > Configuration > System. Then you can create only items for channels you actually need. I currently still create those via .items file and link with {channel=""}; but the UI allows you to create new items as well (never did it, but I assume it allows you to give a name you like.

Alternatively an example of linking via .items (not all OH2 stuff will be supported this way - e.g. some graph engines):

Number powerWaschmaschine "Waschmaschine [%.1f W]" <energy> (gPower) {channel="zwave:device:zwave:node8:meter_watts"}

with kind regards,
Patrik

Yes, I’m considering doing this, but I like the idea of autodetecting as long as the naming convention is somewhat reasonable. This is also good in terms of consistency. Off course you do get a lot of items you don’t need (why is that by the way? Two dimmer items on a single dimmer and etc?) but they are easily deleted/deactivated in the Thing configuration.

I guess a renaming of the definitions in my .items file might be the way to go.

This is not possible. ESH uses a unique identifier (UID) to name everything - it can’t therefore use dynamic information for automatically generating items.

You are of course free to create your own items with whatever name you choose and it’s then up to you to manage this. This can be done in either the items files (which currently doesn’t work due to an ESH bug, but once this is fixed it should be ok) or simply by creating your own items in the UI.

I would strongly recommend not using auto detection and creating your own items. If you use the auto generated items, then you can not change the label, you can not add tags etc - it is a fixed set of data generated by the system.

Hi Chris,

I’m using snapshot #500 - here the .items approach seems to work; is this ESH bug already fixed in this build - or do I have to take some pre-cautions?

with kind regards,
Patrik

If you’re only creating items, and not things, then it’s probably ok. The error is actually in the definition of things since it’s not possible currently to define thing properties in the text files -:

Noted, seems .items file is the way to go then.
Just out of curiosity why have SimpleMode been created. Hmmm, thinking about the name “SimpleMode” I’m realising why…

Thanks for the heads up :slight_smile:

Hi @chris chris,

I’ve problems to get my EUROtronic Stella Z valves to work with OH2 (updated to latest snapshot today - but problem persists).

From the .log it looks like there is some information received:

But no device xml for the node is created and the UI shows it as unknown:

zWave .log available @ zwave.zip; do you have any advice - is this something I do wrong; or shall I report an issue for this?

thanks and kind regards,
Patrik

It looks like the device hasn’t completed initialisation yet. I don’t know if that’s due to a problem, or it’s just not been woken up to allow it to complete. I would wake the device up again to see if it completes - if not, send me the log after some more wakeups…

Hi Chris,

thank you for the reply; I did several wake ups - but unfortunately the device remains unknown.

Some more logs: Logfiles.zip

with kind regards,
Patrik

There is one wakeup in the log, but the initialisation doesn’t really do much as the request times out, so we’re still in the same situation that the initialisation isn’t completed and therefore the thing is not updated with the device type.

Part of this is due to the NIF causing timeouts, so I need to change the way this works - I’ll look at that tomorrow.

1 Like

With 1500 posts in this thread, I think I will close this as it’s too big now, and contains lots of information that probably can’t be found. Please create separate topics if you have any OH2 ZWave questions (feel free to @chris the post to make sure I see it if you want).

1 Like