2024.3 and 2023.4 MQTT / ZB2MQTT errors

[zwartje]

So, in 2023.1 (build 15082) I have MQTT-auto to learn devices from MQTT into domoticz. Devices are switched through MQTT being read by Zigbee2MQTT. Working like a charm.

Every separate service is running in their own docker container so no dependencies.

Starting up 2024.3 or .4 (separate dockers) in a test folder, (not touching my production, glad to have made a BACKUP!), none of the devices can be switched. Instead they all give the error: "Error sending switch command, check device/hardware (idx=XXXX) !". Note this also happened when I thought I could quickly replace production so it is not the test folder causing this.

Nothing but the docker instance of domoticz changed, I cannot find any other report like this in the forum.

Really wondering what can be the issue here.

[Dantik]

I faced the same problem starting with the update to version 2024-2 and then again after the update to 2024-3, after which Domoticz stopped receiving data from almost all Zigbee devices including sensors, and when pressing switches the error "Error sending switch command, check device/hardware (idx=xxx)" appeared

However, earlier this problem was fixed by pressing "rename device" → "save description" button for all devices in a row in Zigbee2MQTT web interface and after that all devices started working correctly in Domoticz.

Today after the update to 2024-4 the problem is repeated but now the previous method of fixing it doesn't work anymore and even removing the device through Zigbee2MQTT interface and pairing it again doesn't fix the error.

[rini52]

I assume its relate to my problem as well. The unwrapping in mqttautodetect was changed between 2024.1 and higher

see my remarks:

https://www.domoticz.com/forum/viewtopic.php?t=41422

regards

[waltervl]

I assume its relate to my problem as well. The unwrapping in mqttautodetect was changes between 2024.1 and higher

see my remarks:

https://www.domoticz.com/forum/viewtopic.php?t=41422

regards

I do not think this is related.

[rini52]

Are you sure?
The unwrapping of the discovery mqtt message is clearly different after 2024.1. Maybe divert , but still altered.

[waltervl]

You are talking about 1 specific switch that does not work. The others have far more not working switches.
And they are related to zigbee devices and yours is related to the Zigbee2MQTT proces.

[rini52]

I assumed that also their zigbee devices are going through the same discovery process if they are autodetected as they indicate?
But I might be msitaken

[zwartje]

My switches are previously autodetected (and working) but since they are already present I doubt the autodetect can be the issue.

I did not check whether temperature and other zigbee sensors are working or not (in the new version) but NONE of the switches (zigbee) I tested worked.

So not importing new switches. The Zigbee2MQTT webUI has no issue, even when I bring up 2023.1 and 2024.4 (dockers, running on separate ports and working directories/databases) the old domoticz has no issues, the new one simultaneously prevents switching with said error message.

I checked that link and it sounds completely different issue indeed. Also never had any USB problem on the pi4.

Anything I can test to figure this out?

[rini52]

Indeed the USB problem is a different issue. It triggered the idea of using the restart button to get the zigbee dongle updated if I did not receive sensor info for some time. But as noted, it horribly failed.
Just a remark about an already "discovered" switch or sensor, They are put in DeviceStatus table of the Domoticz.db SQL database. Once they are in there , they stay in and will show up in the Domoticz webpages. Only if you remove them (via the webpage) they get removed. When I upgraded to 2024.2 or 3 they were in and stayed in. So giving you the (false) impression that they are rediscovered. Check the log files (status) and you see if they really (re)discovered.
The above shows the situation for me in this case. As a test, I inserted the restart button manually in the domoticz.db with sql after I removed the button via the webui. And indeed it showed up on the webpage of the switches.
The latter is what the mqttautodiscover code suppose to do in the new release, but failed. In the old release its done diffidently apparently, but also in the old 2024.1 the commands were not sent or you got an error. An example in my case was the permitjoin switch which is discovered by the zigbee2mqqt dongle in the 2024.1. It receives the update message from the dongle and shows up in the domoticz webUi when you press the permit button on Zigbee2Mqqt webqui. But it did not work from the Domoticz side. So the command was not send. In Homeasssitant it worked oke. So the mqqt servers is working as it should, only Domoticz is not up to date yet with these discover messages apparently. In the 2024.4 it works as it should, so things change for the better. The restart button remains a problem..

This stuff is much too complex for me to understand whats going on in the C++ code, so I gave up.

[zwartje]

I expect already discovered devices not to be rediscovered. That seems pointless.

Devices in the database have history and should not need to be removed and rediscovered.

So the question here really is why my existing devices no longer work.

If I can help out with a more specific test I will do my best.

[rini52]

I expect already discovered devices not to be rediscovered. That seems pointless.

Devices in the database have history and should not need to be removed and rediscovered.

So the question here really is why my existing devices no longer work.

If I can help out with a more specific test I will do my best.

There could be a lot of reasons why your devices no longer work,but one of them could be that they are not re-discovered. Reasons i.e. Z2M server updates, device updates or having payloads/discover changes. Indeed if you want to keep a history you don't want it to be removed and therefore, in the later case, you most likely end up with a new device that works (I assume). If nothing has changed they should connect to the existing switches/sensors etc.
Unfortunately when Domoticz code changes all the above is in jeopardy. Than we have to exchange our experience and hope there is someone who can fit the broken pieces together.

[zwartje]

Any update on this issue from the development team or admins or ?

Just curious to know if this is seen as an issue to be investigated/solved!

[waltervl]

Seems to be related to https://www.domoticz.com/forum/viewtopic.php?t=41962
a github issue has been opened:
https://github.com/domoticz/domoticz/issues/6025

[azonneveld]

Sounds like the same issue I have.

[azonneveld]

"Error sending switch command, check device/hardware (idx=XXXX) !

Can you share the contents of you zigbee2mqtt database?

I have a feeling some type of (rare) devices are causing the issue, since some users experience this problem and others are not.

[waltervl]

Could perhaps also be related to Zigbee2MQTT version? Perhaps your version behaves different from others and Domoticz is not expecting this?

[azonneveld]

Could perhaps also be related to Zigbee2MQTT version? Perhaps your version behaves different from others and Domoticz is not expecting this?

I have 1.33.2 running, dating from nov-23.
The issue appeared after installing 2024.2, I skipped 2024.1

I will try to compile 2024.3 using the MQTT Hardware Code v2023.2 code this week using a spare Raspberry PI 4.
If that fixes the issue, the problem is isolated in my opinion

[waltervl]

So you updated zigbee2MQTT before updating Domoticz or on the same time?

[azonneveld]

So you updated zigbee2MQTT before updating Domoticz or on the same time?

Zigbee 1.33.2 + MQTT 1.5.7* + Domo 2023.2 worked fine.
Zigbee 1.33.2 + MQTT 1.5.7* + Domo 2024.x not fine

bytheway: I also tried zigbee 1.35.2


*mosquitto version 1.5.7 mosquitto is an MQTT v3.1.1 broker.

[zwartje]

Can you share the contents of you zigbee2mqtt database?

I have a feeling some type of (rare) devices are causing the issue, since some users experience this problem and others are not.

I probably can (have to check how) but please note that this is working in 2023.1.

Version I use for zigbee2mqtt: 1.35.1 commit: 9eaaa0f