I have this sensor working in HASS for some time.
did you check out this:
I believe so. I have the same network key in options.xml in both “/srv/hass/src/python-openzwave/openzwave/config” and “/srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config”
I didn’t see that one, but I seem to have the same setup as described in that thread, and I’m not still getting anything. I saw the suggestion to switch to binary reporting from basic, but I don’t see any option for that in OZWCP.
The Fibaro doesn’t have the option to switch to binary reporting.
What kind of controller are you using? As I wrote earlier, I’m using the Aeon Labs G5 ZStick which worked out of the box.
Maybe someone with the same combo as you might weigh in.
Sebastian
I think (but can’t check) that you need to add as non-secure device. I have tried secure for devices that support it but never had success with that.
If added non secure there is a field for reporting in OZWCP for that device under configuration. This needs to be set to basic.
I’m using the Aeon Labs G5 ZStick too
On a sidenote I am using the zwave.me UZB stick, not the AEON Labs stick.
cpc1027 what does the sensor look like in open-zwave web interface?
By any chance did you buy this sensor in the past 2 months or so?
Then it should definitely work. Maybe try including the sensor via the ZStick’s button.
If that doesn’t work, try a factory reset with the stick and the sensor as well.
The sensor can be added non-securely and securely - I tried both methods and both work.
Re-adding the sensor one way or the other increases the device number, though, so you’d need to update all the references in your hass config.
Sebastian
Yes, I bought it last week (I’m just getting started with HA). Here’s a screenshot of some of the OZWCP. If there is something specific that you wanted to see, let me know and I’ll get it in the frame. Right now, I have the manufacturer.xml files for both openzwave and hass pointed to the updated fibaro configuration xml file posted in the other thread, but neither the update or the original seem to have made a difference.
This also looks good. Basic command class is set to Basic. So that is not it.
I ran into this problem the first time I tried to include the sensor and thought I screwed something up, so I factory reset everything and tried again, which is where I am now. I can’t say for sure that I tried all of the same steps the first time, but I’ve been trying every potential solution that I can find since the reset.
I was poking around the zwcfg_*****.xml file that seems to be generated by HA, and I noticed that the information for “node 2” (my fibaro sensor) is considerably shorter than my lightbulb. I don’t really have any idea what this means, but it seems like a more complex sensor like the fibaro would have much more information associated with it. Does this spark any ideas about what might be going on (note that I still don’t have a sensor listing for this in HA’s state listing)? This is what is I have for node 2:
</Node>
<Node id="2" name="" location="" basic="4" generic="7" specific="1" type="Notification Sensor" listening="false" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Dynamic">
<Manufacturer id="0" name="">
<Product type="0" id="0" name="" />
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1">
<Instance index="1" />
<Value type="byte" genre="basic" instance="1" index="0" label="Basic" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
</CommandClass>
<CommandClass id="132" name="COMMAND_CLASS_WAKE_UP" version="1" request_flags="2">
<Instance index="1" />
<Value type="int" genre="system" instance="1" index="0" label="Wake-up Interval" units="Seconds" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="3600" />
</CommandClass>
</CommandClasses>That looks realy incomplete. Not sure what the parameter means, but that query_stage="Dynamic" looks suspicious to me.
For my sensor it says query_stage="Complete". I also have roletype="6" devicetype="3079" nodetype="0" attributes that seem to be missing for your sensor.
Maybe deleting the file will trigger a “rescan” by hass? - Just a wild guess…
Here’s the first lines from my sensor:
<Node id="8" name="" location="" basic="4" generic="7" specific="1" roletype="6" devicetype="3079" nodetype="0" type="Notification Sensor" listening="false" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" secured="true" query_stage="Complete">
<Manufacturer id="10f" name="FIBARO System">
<Product type="801" id="1001" name="FGMS001 Motion Sensor" />
</Manufacturer>
Sebastian
I think you’re right. I just looked at the openzwave log and it doesn’t look quite right there either, even though the OZWCP looks fine. As soon as I have time, I guess I’ll factory reset the thing again and try to re-add it to the network.
Is there something that I could have messed up with the secure node? I uncommented the network key line and replaced the default key with my own in the config files in both “/srv/hass/src/python-openzwave/openzwave/config” and “/srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config”. Then I used the “add secure node” function in the OZWCP to add the Fibaro sensor. Anything I missed there? Is there a way to add a secure node with the button on the z-wave stick? I didn’t see anything in the manual…
I did it the same way. Set a key and re-added the device securely using ozwcp.
I’m not sure that it’s possible via the zstick’s button since (I think) the stick does not know anything about the network key you set in your config file.
Sebastian
Well, the factory reset on the Fibaro was a no-go - it ended up with the same results. As best as I can tell, it looks like the sensor configuration information is not being correctly transmitted/interpreted by the hass-openzwave interface, but I haven’t been able to figure out a way to force that to happen. I’ll keep poking around and see what turns up.
Good news! I finally got it working. The problem seems to have been in my manufacturer_specific.xml - there was one line in the Fibaro configuration options (before the listing for this sensor) that was not indented correctly, and I think it was stopping my sensor from being identified. I fixed that and after a short time, the sensor states started tracking in hass. Now to do something with them…
I found this thread after having issues with the v35. First off in 0.39 it wouldnt show up at all, yet would in the OpenZWave Control panel… had to roll back to 0.38 - then upgrade again to 0.39 (as 0.38 has leaky memory issues for me!)
The missing piece of the jigsaw was that there were two options.xml files that needed adding the network key I generated!
For me:
pi@raspberrypi:/srv/hass $ find . -name options.xml
./lib/python3.4/site-packages/libopenzwave-0.3.2-py3.4-linux-armv7l.egg/config/options.xml
./src/python-openzwave/openzwave/config/options.xml
Then the motion seemed to come through in more real time
I also struggled quite a lot to get the Fibaro v3.2 working. The device was showing up fine in the OpenZWave Control Panel, but the OZW_Log.txtlogfile always showed unhandled command class, as also discussed here. The solution was to do the add_node_secure with an unpaired Fibaro motion sensor within HASS:
As far as I understand, the device really wants to safe battery and does expose the features rarely and once after pairing.