This won’t be related to the lack of reports - this is an issue receiving the config reports and I fixed it earlier today (I think it might be fixed in the version on GH now) - I’ll load a new version soon…
Regarding not getting reports, are you seeing anything coming in if you look at debug logging? If not, then it must be a device config and it could be that the binding converts the data into the type required by ESH (as in the ESH doc I referenced above). There was a discussion on the ESH forum some time back about checking if item types were as per the doc, and I seem to recall that checks were to be added to enforce this. Since the binding doesn’t know anything about items (only channels) it doesn’t know that you might have defined a different type, and this might be causing a problem (I’m not sure though, but I wouldn’t be surprised).
In this respect, this is very different to OH1 where the binding knows what type of item you have. Here we don’t know this, so if you’re defining a type that isn’t compatible with the channel, then it might be the problem…
I’ve updated the binding to include the new devices updated in the database today… I’ve also fixed a few minor bugs and added a few minor features -:
Option to reinitialise a device (note that this is an advanced option, so in HABmin you need to enable advanced options in the Tools menu in the top right of the config display - I don’t know what PaperUI does with Advanced options).
I’ve added the NodeNaming command class - this will show up as separate config options that aren’t linked to the thing name. I’ve not tested this yet as I’m not sure I have any devices that support this…
I’m not seeing the report in the binding/channel arena.
I’ve seen the following:
NODE 4: Incoming command class SENSOR_MULTILEVEL NODE 4: Incoming command class BATTERY NODE 4: Incoming command class ALARM NODE 4: Incoming command class WAKEUP NODE 4: Incoming command class VERSION
But I’ve yet to see one for SENSOR_BINARY which makes me think either the binding is dropping/losing the message (occasionally I see the zwave_serial_zstick_152e6d93f03_serial_sof increase with no other messages in the log) or the parameters on the device are incorrect (but PIR isn’t set as disabled in HABMIN so they’d have to be out of sync somehow).
I’ve updated the binding, updated the parameters in habmin and woke the device up a few times and could see the new configuration was received by the binding.
I was hoping to be able to see the device config as well, but it’s not in the file (apart from one parameter). Other than that everything looks fine.
Do you know what type of info is sent through the ALARM and SENSOR_BINARY classes? Are you sure the info you’re looking for is in the SENSOR_BINARY class? I recently (ie in the past week) updated the ALARM class from version 1 to 3 so there may be a bug in there - I’d be interested in seeing a larger log if you think this might be the case since I note that the device supports version 3…
I’ve gotta head off to bed so will look at this again tomorrow…
Ah - great . I missed this update while writing my previous response so feel free to ignore that (although the point about the ALARM class is still valid - it’s been updated with limited testing, so if you suspect problems, please let me know)…
It’s working at the moment so I won’t try and break it tonight as I’m off to bed now too. If you want me to mess around with things tomorrow I’ll give it a go.
Thanks Chris.
Edit: V3 alarms seem to work (this is from the tamper/vibration alarm):
Is this normal dla the same detected devices are present in PaperUI Inbox as Unknown and also present in Things as configured devices? I was removing .xml files from zwave folder when I was replacing zwave provider with latest version.
Thanks - are there any that aren’t showing up correctly in OH2?
No - this shouldn’t happen. Is this for all devices, or just some of them? It will happen if database names get changed. More specifically, in the database there’s a field called ‘thing id’ - if this is changed, then it will likely cause this. I don’t think there have been changes to the names though (obviously we don’t want to be changing them as it will screw up peoples systems) - the Aeon devices we all renamed last week so this might have impacted your Aeon device, but the Fibaros should be stable…
If this is the case that ‘all’ devices are in both places, then can you use the REST interface to dump both the inbox and the things list… Go to the OH2 dashboard and select “REST API”. The select Inbox, GET, and “try it out!” - this will dump the contents of your inbox. Then do the same thing for things…
As far as I can see none of Fibaro 2x1.5kW relay has been detected corretly. I’m also sure that I own various versions of this device since I was ordering it in different months/years.
Not only Aeon labs Multisensor has been visible as unknown and known. I see that Fibaro Dimmer is also visible in both places and Fibaro Relay switch 1x3kW too. But not all devices has been in both places so I will try to remove them from things when you will compile new jar file and check again.
Ok - thanks. I’ll take a look at your files later today. I note that the only version of the FGD221 that’s not already in the binding is version 1.9 to 1.11 - the other two versions should be ok and it works ok here (not sure what versions I have, but like you I’ve got a number of them and they were bought over a reasonably long period).
I linked their channel to the items and it works fine.
Now all of my unboxed Z-Wave devices works with the latest OH2-snapshot and your test version of the Z-Wave-Binding Thank you again for your great work and quick response.
The referenced list only says which item type you should use if you mark a channel with a given category. And yes, the general advice is to map a motion detector onto a switch, but I never said anything different on openHAB 1, when I was asked
Appearently, cleaning the cache does not help - I will have a look at it tomorrow. But as long as all is available in HABmin, this shouldn’t be too critical then!
I’ve uploaded a new version - this mostly updates device database, but also adds a polling time option in the thing. I’ve also updated HABmin to fix an issue with BOOLEAN data types.
The latest version I loaded last night introduces a configuration to allow you to set polling on a per device basis. Unfortunately, this has an issue in that it defaults to 15 seconds which is the minimum time the binding will allow… You might want to change this to something more sensible and I will default it to 1800 seconds…
One other point that was noted is that HABmin2 seems to have some problems with Firefox - I do most of my testing with Chrome, so I know that works well so I’d recommend to use Chrome if you have any problems (like not being able to save associations). I’ll look at fixing browser compatibility as soon as I get a few minutes…
edit: It seems Safari has the same problem as Firefox!
Hello, interesting thing. I’ve replaced zwave jar file with new version, removed XML files restarted OH2 service, removed items from Inbox and when nodes started to be rediscovered they are still being marked like:
This time there is no Unknown in node name but still devices are not being discovered. Fibaro 2x1.5kW, GreenWave, Aeon Energy Meter 3clamps (basically all nodes which XML files which I’ve provided in my previous post)
Any idea?
EDIT: I’ve noticed that after restarting OH2 nodes are called Unknown but their names after some time are being changed to Node xx.
. I missed this update while writing my previous response so feel free to ignore that (although the point about the ALARM class is still valid - it’s been updated with limited testing, so if you suspect problems, please let me know)…
Thank you again for your great work and quick response.
