I am quite new to Openhab, so I wonder if I am overlooking something.
Using openhab 1.7.1 on Beaglebone black
Several devices which work without problems
2 Zwave sensors (Eversping SP103 and a Fibaro motion sensor) which are troublesome
Both sensors are included in the network.
If I check devices in habmin, then both sensors do not show a device ID, Device type and manufacturer ID
The folder with xml files for each node does not have xml files for those 2
In the log I see some event from node 11 which ends up in a node address inconsistent (see below)
NODE 11: Application Command Request (ALIVE:PING)
NODE 11: Incoming command class BASIC
NODE 11: Found Command Class BASIC, passing to handleApplicationCommandRequest
NODE 11: Received Basic Request
NODE 11: Basic Set sent to the controller will be processed as Basic Report
NODE 11: Basic report, value = 0xFF
Notifying event listeners: ZWaveCommandClassValueEvent
ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
ZWaveActiveBinding:450 ]- NODE 11: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
ZWaveConverterHandler:340 ]- Getting converter for item = SP103_Motion_Sensor, command class = BASIC, item command class = sensor_binary
Getting converter for item = SP103_Motion_Sensor_Battery, command class = BASIC, item command class = battery
Transaction not completed: node address inconsistent.
So some questions:
I would expect that even if there is no item configured for a ZWAVE node the manufacturer and product ID would always be read and visible in habmin. Is this assumption correct ?
When are the xml files in /var/lib/openhab/zwave created ? ( I assume after mfg and device ID are read )
What is meant with “node address inconsistent”
Any other suggestion which might be wrong here ? Any help would be appreciated.
Yes - this should be the case, but I’ll explain more below…
They are created after the device is fully initialised, so yes, this is after the device ID is read, and a lot more stuff is also completed…
Ignore it - it’s a debug message that simply means the incoming message is not related to the last request…
Ok - so I suspect that your devices have not woken up, so they can’t be initialised. Looking at the log you attached, there is no wakeup message, so the binding can’t initialise the device. Just because your device is sending data, doesn’t mean that the binding can also send data to the device - have a read of this post, or the wiki to see what I mean.
I suspect you need to wake the device u manually so that the binding can properly initialise it. Normally there’s a button on the device you can press a few times to wake it up…
Unfortunately battery devices in zwave aren’t quite as easy, or as intuitive as you might hope for . Once they are configured, they should be ok, but getting them configured, and changing the configuration, can be problematic if you don’t understand what’s happening.
Hi Marcel,
I had the same issue last week, I n habmin go to configuration - bindings - zwave.
Tripple click the fibaro motion sensor then press include in habmin, repeat this until the xml file is created correctly. For me it took three or four attempts, if habin still doesn’t create the file try it vice versa, first press include in habmin then Tripple click the fibaro motion sensor.
If you see the motion sensor in habmin you have to add your zwave stick node as a member in association group - controller updates.
For me the fibaro motion sensor still need a tripple click on each new start from openhab. Don’t if this normal, cause I’m still a beginner!
This shouldn’t be necessary and is probably a misunderstanding…
If the wakeup is set ok (let’s say it’s set to 1 hour), then after the binding starts it will take up to 1 hour before HABmin reports the device is ‘green’. Up until this time, you’ll see a grey dot which means it’s still initialising. During this time, the device can still send alarms if the motion sensor goes off, but until it sends a wakeup message, the binding can’t send it messages, so it stays grey.
So, if you leave it along after the binding starts it should be ok after 1 or maybe 2 wakeup periods - this is normal. If it doesn’t go green after this time, it probably means that the device isn’t configured correctly. If you then look in the Wakeup ‘folder’ for the device in HABmin, you should be able to see if it’s set correctly (device should normally be set to 1, and the time should be 3600 seconds).
Ok - let me know how it goes. If you don’t think it’s working as I explain above, then please provide the XML file (in etc/zwave/node?.xml)in the first instance (and maybe a log later, but the XML should provide information on the current configuration).
Both thanks for your help. It is indeed not trivial and cost me several attempts to get the sensor recognized.
To Mario: It take a while to get the sensor initilized after restarting openhab. I changed the wake up interval with habmin from 7200 seconds to 3600 seconds this helps as well.
I tried to create a rule which switches on a lamp when the sensor detects movement. This also seems not so straightformward. The event is in the lig, but the ruls is not triggered. Should I react on ON or lavel 255 ?
It depends on your item configuration. If this is a switch, then the binding will convert the 255 (0xFF) that you see in the log into an ON and OFF, or OPEN / CLOSED (if the item is a Contact). If the item is a number, then it will be 255 - I assume you’re using a switch or door sensor though?
Basically it seems to work. Only have some problems with the rule. How does a zwave motion sensor work in a rule. E.g if changes from close to open … when wil it go back.
With other words …if I want to add a log event on every movement detected…how do I do that.
On changed… on off to on and then set to offin the event… on update received.
I can find out, but guess i am reinventing the wheel
It probably depends a little on the sensor - there’s often a timeout after which time the device will return to ‘normal’ state, and it may not retrigger for a while after that… However, forgetting these things, you should be able to trigger a rule each time the state is updated (ie Item <item> received update) - that will mean you get notified even if the device is already triggered…
. Once they are configured, they should be ok, but getting them configured, and changing the configuration, can be problematic if you don’t understand what’s happening.
