MQTT Audo-discovery

[waltervl]

You also need to restart Domoticz to clear its INTERNAL HA AD devices table, as that is build when the config MQTT message are received and not clear until a restart of Domoticz.

An update (=restart) of MQTT Gateway with or without AD from menu Setup - Hardware will also do to clear internal MQTT device tables ?

[jvdz]

You also need to restart Domoticz to clear its INTERNAL HA AD devices table, as that is build when the config MQTT message are received and not clear until a restart of Domoticz.

An update (=restart) of MQTT Gateway with or without AD from menu Setup - Hardware will also do to clear internal MQTT device tables ?

Yes that works too....

[jake]

I updated my domoticz setup with both Mosquitto, zigbee2mqtt and zwavejsmqtt in Docker containers. All devices are auto-discovered properly, renamed to previous names and idx values updated in Dashticz. The OpenZwave hardware is removed.

So far so good.

However, when I restart the Domoticz service, all zwave devices are still there, but none can be reached. When I click on switch 558, Domoticz gives the following error:
Error sending switch command, check device/hardware (idx=558) !

The way to resolve this, is to open the zwave portal in the browser on port 8091 (operating the devices from there works fine), go to settings and click on 'Save'. I then see in the Domoticz log that autodiscovery runs again. No new devices are created (luckily) and all zwave devices can be operated again.

What is wrong? I'd assume that devices are available after restart of domoticz.

I'm running beta 2022.1 version 14124

UPDATE:
I checked throught the Zwave portal settings of 'Home Assistant'. I now enabled 'Retained Discovery' and during a restart of the Domoticz service, I see in the log that all Zwave devices are discovered again.
So I assume that this is the right solution for my problem? Strange that the https://www.domoticz.com/wiki/ZwaveJS2MQTT wiki shows a screen dump with this switch disabled.

[dheuts]

Good afternoon all,

Since some days after working for years I noticed delay of 3-7 seconds on battery operated Zwave PIR sensors and Zwave Door/Window contact not registering all updates. I noticed in the OZW logfile the command came in on the right time, but only 5 seconds later I was able to see it in Domoticz. I reinstalled Domoticz and restored my db backup, still the same delay.

Thanks to this topic I discovered a new way of setting up Zwave instead of the OZW plugin for Domoticz, so I was hoping this would solve the delay and other problems. I migrated all devices to Zwavejs2mqtt, and they are auto discovered in Domoticz and I replaced them. But, unfortunately there is no improvement and the delay is still the same.

Any idea what to do? Could the USB stick itself be faulty? Or any idea what to try before replacing it?
As you can see in the screenshot below, Gang PIR_motion_sensor_status seems to change status 5 seconds earlier then Gang PIR. So might the problem be in Domoticz after all? I don't think so, because Zigbee and 433 PIR's react very fast like normal.

Thanks.

Schermafbeelding 2022-02-06 om 12.17.20.png (227.13 KiB) Viewed 2598 times

[jvdz]

Did you check the mqtt message received at that time and do they show the same delay?

[dheuts]

Did you check the mqtt message received at that time and do they show the same delay?

Thanks for your reply!
Yes, indeed I see 4 seconds delay also over there, please check below:

Screenshot 2022-02-06 134833.png (34.75 KiB) Viewed 2585 times

[jvdz]

So that means to me the delay comes from within your zwave network. Maybe a faulty unit is causing this?

[dheuts]

So that means to me the delay comes from within your zwave network. Maybe a faulty unit is causing this?

That's what I think also indeed.
But the PIR in this example is connected directly to the controller and 5x Fibaro Dimmer 2 devices.
So because it's also direclty connected to the controller, I assume the controller is faulty?
The other Fibaro dimmers all work fine. Any idea how t debug this any further?

Or in case it's indeed the USB stick, can I backup the conifig and import it to the new stick in Zwavejs2mqtt? Or do I have to include them all again?
I'm very happy with the improved replace functionality in Domoticz in this case....

[dheuts]

I have bought another Zwave USB stick and set all the devices up in Zwavejs2mqtt and replaced all devices in Domoticz and the delay is gone.
Good news!

But since I have set it up via Zwavejs2mqtt instead of the open zwave plugin, I have a strange problem in Domoticz.
If I set the zwave Fibaro dimmers for example to 30%, it will not be on 30% but on 29% instead.

Because I have a Google Hub as Alarm clock, my morning routine with sunrise wakeup is not working anymore, because dimming to 1% turns them off instead. I also tested this with dimming via URL.

When I send this command for example: /json.htm?type=command&param=switchlight&idx=11&switchcmd=Set%20Level&level=1
The log in domoticz shows: off

If I send this command for example: /json.htm?type=command&param=switchlight&idx=11&switchcmd=Set%20Level&level=30
The log in Domoticz shows: 2022-02-09 09:01:00 Set Level: 29 %

The MQTT log also shows the percentage 1% lower:

Code: Select all

domoticz/out/11 : msg.payload : Object
object
Battery: 255
LastUpdate: "2022-02-09 09:03:34"
Level: 29
RSSI: 12
description: ""
dtype: "Light/Switch"
hwid: "44"
id: "zwavejs2mqtt_0xf28168ac_21-38-1-currentValue"
idx: 11
name: "Woonkamer Spots"
nvalue: 2
stype: "Switch"
svalue1: "29"
switchType: "Dimmer"
unit: 1

Any idea how to solve this?
I also tested the same url with tasmota spots to 1% and they just go to the desired % instead of 1% power (off in case of 1%)

[jvdz]

@dheuts, is this only happening for ZWAVE devices right? The thing is that we have the convert a 100 scale to a 99 scale for ZWAVE as 100 means to switch the bulb ON and set it to its last used Level.
so that means that 100 becomes 99 and presumably 1 becomes 0 because we drop the decimals of the 0.99 value. (Need to double check this!)
...but the real question from my side would be: What makes the most sense here? should we round the result value in stead of dropping the decimals?

[jvdz]

Did some debugging and made PR to fix the rounding of level which will be available in the next Beta.

[dheuts]

@dheuts, is this only happening for ZWAVE devices right? The thing is that we have the convert a 100 scale to a 99 scale for ZWAVE as 100 means to switch the bulb ON and set it to its last used Level.
so that means that 100 becomes 99 and presumably 1 becomes 0 because we drop the decimals of the 0.99 value. (Need to double check this!)
...but the real question from my side would be: What makes the most sense here? should we round the result value in stead of dropping the decimals?

Yes, only for the Zwave devices indeed.
Rounding the decimals sounds like the best solution to me indeed..
Maybe possible to check how the Openzwave plugin handles it? I don't know how to check this.

Thanks a lot for your replies!

[jvdz]

Yes, only for the Zwave devices indeed.
Rounding the decimals sounds like the best solution to me indeed..
Maybe possible to check how the Openzwave plugin handles it? I don't know how to check this.

Thanks a lot for your replies!

As my last post states: It should be fixed in the latest Beta, so could you try that and let us know?

[dheuts]

Yes, only for the Zwave devices indeed.
Rounding the decimals sounds like the best solution to me indeed..
Maybe possible to check how the Openzwave plugin handles it? I don't know how to check this.

Thanks a lot for your replies!

As my last post states: It should be fixed in the latest Beta, so could you try that and let us know?

Thanks a lot!
It's working again if I set it to 1%, it doesnt turn off anymore.

I have to test if the Google wakeup light scene (sunrise) is also working again now.
I have to investigate this further. I am using Controlicz to control my Domoticz devices from Google Home, and it is working fine with a Tasmota light.

[Mazzokun]

Hi everyone!
Yesterday I reinstalled domoticz from scratch and added my devices via this plugin.
At first I didn't have any problems, but today I have dual / triple devices in the list and some of the old devices have stopped working (when I click it tells me "Error sending switch command, check device / hardware (idx = 1)!" ) being added / replaced automatically by new devices.
Any help?

[jvdz]

Hi everyone!
Yesterday I reinstalled domoticz from scratch and added my devices via this plugin.

PLugin? ThisMQTT auto discovery is build in and not to confuse with the plugin!

[Mazzokun]

Hello, excuse my poor English. I meant the built in.
As hardware I have only this, connected to an external MQTT server.

[jvdz]

New devices are only created when their uniqueid changes, which shouldn't be the case normally, so how where these devices previously created?
Did you change anything in the gateway for these devices?

[Mazzokun]

no, nothing has changed, I configured domoticz only with "MQTT Auto discovery" hardware, everything worked and I went to sleep. when I woke up a couple of duplicates began to appear, until 20 duplicates appeared and some old devices did not respond to commands but only the new ones.
So I tried adding the "MQTT Client gateway" to the hardware and the devices that no longer worked started working again.

[jvdz]

Ok, so please share the MQTT details so we can check what is happening:
- Which gateway & devices are giving you this issue?
- Share the Config & State update MQTT messages as described here.
- Share the domoticz log messages when the new devices are discovered/created.

Jos