Hopefully that gets changed to be a config option before this gets added officially.
So I’m maybe wrong but that means you can’t run ozw and a mqtt broker for other any application that needs it ? Like zigbee2mqtt.
Thanks for the explanation. I have it running now, including my Fibaro FGRM-222 roller shutter. Cover component is configured like this:
- platform: "mqtt"
name: "level_mqtt_ozw"
command_topic: "OpenZWave/1/command/setvalue/"
set_position_topic: "OpenZWave/1/command/setvalue/"
set_position_template: "{ \"Value\": {{ position }}, \"ValueIDKey\": xxxxx }"
position_topic: "OpenZWave/1/node/24/instance/1/commandclass/38/value/xxxxx/"
value_template: "{{ value_json.Value }}"
position_open: 99
position_closed: 0
payload_open: "{ \"Value\": 99, \"ValueIDKey\": xxxxx }"
payload_close: "{ \"Value\": 0, \"ValueIDKey\": xxxxx }"
The one thing not working is the stop functionality. But I am not really using that.
And while looking at the payload_open/payload_close I may need to check that again. It may be swapped.
It was not working. Now it does work. The QT-Openzwave endpoint does not accept a value of 100, only 99 as a value for open (up).
2 Likes
Thanks for the reply, and to the others who did as well ofcourse.
Yeah, you pushed me in the right direction. THANKS!
Now I have the Daemon running (not the Add-on but in docker), and it is connecting to my separate MQTT instance.
I have Proxmox with Ubuntu container > Docker. I managed to get the USB stick to be passed through and used in the docker run command. Now I see the daemon doing its work, and see the info landing nicely inside the mqtt mosquitto broker not the addon one.
Now, Open Zwave Beta shows the info correctly. There are now 16 devices with 120 entities.
But, as known and expected, I see less devices than I have.
Just to inform: the devices I currently miss:
Shenzhen Neo Electronics Co Ltd Door/Window Detector
Shenzhen Neo Electronics Co Ltd Battery Powered PIR Sensor V2
Philio Technology Corp PH-PAT02-B.eu Multisensor 2in1
I will wait before I continue with the migration to mqtt untill the most ‘critical’ devices are working ok.
Good work on the dev team !!!
PS, I wasnt feeling down. I was a bit making fun in a self-depreciating manner. Ghehehe…
Actually now, I feel quit proude of my achievement, just having my first real linux experience since 1.5 months 
IN proxmox. I have never touched the stuff before. Now, I love the speed and stabillity of it. It just works.
Thanks. Good to know the cause now. I stopped trying to fix this in HA itself
Agreed. Hope so too.
As a work around, you could bridge the brokers. I’ve done this in the past, and it allows two brokers to share messages on either a set of topics, or all topics. This guide covers what you need (the simple config).
How did you call ozw.add_node? You just went to Services and clicked Call Service, without any params in it?
Just call it with no params and hope your device shows up under configuration -> devices…
There’s no user feedback about success or failure or anything to really debug that I could see… Hence my recommendation, just use the old Zwave Integration + UI. The new is not ready for general use IMO.
1 Like
Finally got a real chance to test this out.
I added a plug (which gets added as a switch) and I can see that it was discovered properly and got added to HA.
I can open it up in the states page (haven’t added it to lovelace yet) and it shows the correct status of the plug but I can’t control it from HA. If I control it from the device itself it turns on & off and gives the correct state feedback to HA. But I just can’t control it from HA.
I monitor the MQTT traffic and I can see HA sending a command but for some reason the device ignores it or maybe it’s sending the command to the wrong endpoint?
How am I supposed to know what HA is supposed to send?
Here are the commands sent from HA in MQTTFx:
Here is the status sent from the device when I switch it manually from the device itself:
and here is the info for the node from MQTT Explorer:
Any ideas on how I can troubleshoot this?
And another question that it brought up is what node information is the entity_id based on when it automatically gets added to the system?
That info would be good to know when we start transitioning our existing zwave integrations to this new integration so we can determine which device is which if we start renaming those things for automations, lovelace, etc to continue working.
The switch I just added ended up being “switch.unknown_type_ff00_id_ff07_switch” which is pretty un-useful to figure out which device is which later on.
As I mainly use ZWave to control radiators, and we are in high summer, I took the chance and migrated my ZWave network. Switches show up OK (use them to control lights, fans etc) and the batteries in the Danfoss rad valves also show up.
The actual migration was easy. I already use the MQTT add-on, so I
- stopped the ZWave network and HA,
- deleted the Wave config from configuration.yaml
- restarted HA and added the daemon addin, pointing it to the Wave stick
- Checked that the daemon was working
- added the OpenZWave Beta integration
The devices started to show up, but of course they had the wrong names. Using a process of physical changes and seeing what changed in HA, I was able to identify which new device was which node. I could then rename the device and entities in HA to be what they used to be.
I can’t do this with the valves yet because there is no way to determine which is which.
I have mine configured like this, seems to work. Hassio on virtualbox on Mac.
zwave_device: /dev/serial/by-id/usb-0658_0200-if00
OK, that must be recent then. It certainly didn’t like it when the add-on was first released.
I’ll update my response.
I have made a community guide that could help you rename your devices:
1 Like
Good work, @balk77. I’ve a small network, so it wasn’t too onerous; but your approach would have saved me some time.
replying to myself…
I’m not sure what fixed it but I updated the qt-ozw container to the latest and now it’s working. So I don’t know if it was the update or the container restart that fixed it.
Also, in doing some additional playing around I’ve found that yiu indeed can install the “zwave over mqtt” on multiple instances of HA (HA container and HA supervised) and all zwave devices can be controlled from all of them.
I even figured out that zwave over mqtt will even work along side the internal zwave integration as long as they use different sticks.
The only thing I saw when doing that was a bunch of errors in the logs like the following for every device:
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_switch when dispatching 'zwave_new_switch': (<Entity Garage Door North Operator Switch: off>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/switch.py", line 22, in async_add_switch
switch = ZWaveSwitch(value)
File "/config/custom_components/zwave_mqtt/entity.py", line 145, in __init__
self.options = values.options
AttributeError: 'ZwaveSwitch' object has no attribute 'options'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_binary_sensor when dispatching 'zwave_new_binary_sensor': (<Entity Garage Door North Position Sensor: off>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/binary_sensor.py", line 265, in async_add_binary_sensor
if values.primary.type == ValueType.LIST:
AttributeError: 'ZWaveBinarySensor' object has no attribute 'primary'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<Entity Garage Door North Position Alarm Type: 0>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 32, in async_add_sensor
if isinstance(value.primary.value, (float, int)):
AttributeError: 'ZWaveAlarmSensor' object has no attribute 'primary'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<Entity Garage Door North Position Alarm Level: 0>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 32, in async_add_sensor
if isinstance(value.primary.value, (float, int)):
AttributeError: 'ZWaveAlarmSensor' object has no attribute 'primary'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<Entity Garage Door North Position SourceNodeId: 0>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 32, in async_add_sensor
if isinstance(value.primary.value, (float, int)):
AttributeError: 'ZWaveAlarmSensor' object has no attribute 'primary'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<Entity Garage Door North Position Access Control: 23>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 32, in async_add_sensor
if isinstance(value.primary.value, (float, int)):
AttributeError: 'ZWaveAlarmSensor' object has no attribute 'primary'
2020-05-31 23:36:55 ERROR (MainThread) [homeassistant.util.logging] Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<Entity Garage Door North Position Burglar: 0>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 32, in async_add_sensor
if isinstance(value.primary.value, (float, int)):
AttributeError: 'ZWaveAlarmSensor' object has no attribute 'primary'
But aside from that everything still worked.
But that brings up another question.
Since the containers (HA and qt_ozw) use different sticks ion their definitions why would there be any errors using them together? why would the qt-ozw container even know about the other zwave devices connected to the other stick?
qt-openzw admin fails with version mismatch"
Trying to use new “Zwave (beta)” Integration with OpenZwave (official) Add-On. In the AddOn Config I’m exposing Port 1983/tcp to 1983 on (hassio) host system, Port ist open and can connect via telnet. If I start the latest QT-OpenZWave-Admin I get the following error:
Browsing https://github.com/OpenZWave/qt-openzwave there has been a commit yesterday commented with:
“Raise Error when Protocol Version mismatch” (https://github.com/OpenZWave/qt-openzwave/commit/30c8b9340b8b458b597311cb351874d87ea8bddb)"
Did this code change break the formerly working Admin-Interface? Or was this not working anyway and died silently before this commit? Has anybody QT-Admin GUI working in this scenario? Is this the way to go?
Running:
HassOS 4.10
supervisor 227
version 0.110.6
OpenZwave (official AddOn): Current version: 0.3.0
QT-Openzwave-Admin from: http://bamboo.my-ho.st/bamboo/browse/OZW-OZW-133/artifact/JOB1/Linux---AppImage/OZWAdmin-0.1-x86_64.AppImage
In the (AddOn) Logfile i see activities like:
[20200609 11:23:15.525 CEST] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/node/8/statistics/") payloadLength: 781
So I guess this part is working ok …?
Any help appreciated (I do not see any entities in ha, so I wanted to first get qt-admin GUI going before looking deeper into that …)
/Andi
Ive found that random issues with the new extension are usually resolved with a host reboot quite often.
You beautify beautiful person. That did it! Restarted the server that my docker containers are running on and all of the sudden, all my zwave topics started showing up in mqtt and shortly thereafter the entities showed up in HA
1 Like
Is there a way of checking if the addon is running from within HA automation?
did anybody have luck yet with the Fibaro CO sensor? I’ve just had to send it back, because I couldn’t get any sensor to respond to the CO level alarm at all, (using the still core integration) other than a single update on a CO sensor changing from 255 to 3, but never turning to something else after that. Battery and temp sensors seems ok, but that’s not what we need a CO sensor for.
Was hoping the new integration would be better integrating these Figaro sensors maybe? Sorry if I missed a related post in the matter.
unlike eg the flood sensor, I couldn’t find a sensor to change values, and create a template binary sensor with that for the CO level or any alarm sensor for that matter. Is this the so called Vendor lock, or should I maybe be able to change some of the settings in the Z-wave integration for a specific node