Homebridge not updating status of switches

[Egregius]

Hi all,

Because I moved my Homepod mini to the bathroom I wanted it to start playing music as soon as I turn on the light from the bathroom.
That's when I noticed that the status of the light isn't updated in homebridge/homekit anymore.

When I send a switch command in domoticz homebridge and homekit don't see this until I refresh the homebridge ui accessoires page.
When I send the command from within the home app all is instantly up-to-date.
Tried returning to previous versions from homebridge and from edomoticz plugin but none works.

I also tried with 2 browser windows open. Refreshing one of them results in both being up-to-date. Strange thing...

MQTT Explorer instantly receives the new status.

Any ideas?

[Ben-Bitdiddle-DE]

Kind of having the same here. My configuration is not to use MQTT, so everything goes directly between domoticz and edomoticz/homebridge.

When i switch on a device in the domoticz UI (the device is switched on...), this status is not reflected in homebridge device dashboard (within domoticz it is shown switched on).

The same, when a switch on the device by itself (these are shelly devices), the status is updated correctly within domoticz but not in homebridge (and also not in homekit app on iOS device).

After reloading the dashboard within homebridge the device status is shown correctly (with some delay, firstly the device on the iOS homekit app is updated, then homekits dashboard).

Switching from within homebridge or homekit app instantly shows correct status (also within domoticz).

It seems that there is no async status signaling as a background process from domoticz to edomoticz/homebridge, or might there be some other issue? (i did wait some specific time to see if the status is fetched on an interval based way, but that did also not update the device status).

Homebridge 1.7.0
edomoticz 2.1.46

[PatchworkBoy]

Separate issue. If you don’t use MQTT you have to pull to refresh. If you want things to update automatically in a timely fashion you MUST use MQTT.

[Egregius]

Well, I do have MQTT enabled. Either just by MQTT: true or with manual config:
"mqtt": {
"host": "127.0.0.1",
"port": 1883,
"topic": "domoticz/out",
"username": "",
"password": ""
}

Both work exactly the same. When a switch is changed in domoticz the Homebridge UI isn't reflected until several seconds after the page is refreshed.

[Ben-Bitdiddle-DE]

Separate issue. If you don’t use MQTT you have to pull to refresh. If you want things to update automatically in a timely fashion you MUST use MQTT.

Yes, i expected that. Thus, as the plugin only subscribes to one topic (e.g. domoticz/out), this will only help if domoticz would mirror the device status via that topic (which is not recommended by domoticz, as PreventLoop should be set to true).

Switching the device via domoticz via its UI works now (immediately within homebridge), but switching of the device itself is not recognized that way.

When i switch the device remotely, it will send it's status via domoticz/in topic (to inform domoticz about it), which is then unknown to edomoticz. Domoticz updates it's status, but homebridge will not get aware of that.

Any hint here?

[Ben-Bitdiddle-DE]

Any hint here?

Another interesting observation (mqtt enabled (domoticz/out)):

• Switching the device via domoticz: 1. switches on the device / 2. updates the device status in homebridge (instantly)
  (edomoticz gets aware of the change via domoticz/out)
• Switching the device via homebridge: 1. updates the device status in domoticz / 2. does NOT switch on the device
  (no message via domoticz/out, domoticz is being informed about that status change via domoticz/in)
• Switching the device via the device itself: 1. updates the device status in domoticz / 2. updates the device status in homebridge (only after reloading the dashboard)
  (domoticz gets aware of that via domoticz/in, homebridge only via regathering devices via dashboard reload)

I remember darkly that this has been my reason not to use mqtt, as without at least switching devices via homebridge does work.

mqtt disabled:

• Switching the device via domoticz: 1. switches on the device / 2. updates the device status in homebridge (only after reloading the dashboard)
  (edomoticz gets aware of the change only via regathering devices via dashboard reload)
• Switching the device via homebridge: 1. updates the device status in domoticz / 2. does switch on the device
  (message via domoticz/out (from domoticz itself), domoticz is being informed via URL api call)
• Switching the device via the device itself: 1. updates the device status in domoticz / 2. updates the device status in homebridge (only after reloading the dashboard)
  (domoticz gets aware of that via domoticz/in, homebridge only via regathering devices via dashboard reload)

mqtt enabled (domoticz/in):

• Switching the device via domoticz: 1. switches on the device / 2. updates the device status in homebridge (instantly)
  (edomoticz gets aware of the change via domoticz/in which the switch sends itself after being switched, same as domoticz)
• Switching the device via homebridge: 1. updates the device status in domoticz / 2. does NOT switch on the device
  (no message via domoticz/out, domoticz is being informed about that status change via domoticz/in)
• Switching the device via the device itself: 1. updates the device status in domoticz / 2. updates the device status in homebridge instantly
  (domoticz gets aware of that via domoticz/in, homebridge also)

So it seems that mqtt status update via domoticz/in is the right way, but for some reason switching via homebridge does not work then, domoticz does not create switching messages in that case.

[Ben-Bitdiddle-DE]

Some debug logs exams:

(1) Switching the device via domoticz or by itself creates mqtt domoticz/in messages on which edomoticz correctly reacts:

[1/23/2024, 12:58:17 PM] [EG Diele] MQTT Message received for EG-D [Licht].
Name:		EG-D [Licht]
Device:		Light/Switch,Switch
Is Switch:	true
SwitchTypeVal:	0
MQTT Message:
{
    "idx": 129,
    "nvalue": 1
}
[1/23/2024, 12:58:36 PM] [EG Diele] MQTT Message received for EG-D [Licht].
Name:		EG-D [Licht]
Device:		Light/Switch,Switch
Is Switch:	true
SwitchTypeVal:	0
MQTT Message:
{
    "idx": 129,
    "nvalue": 0
}

(2) Switching via homebridge creates some error messages:

[1/23/2024, 12:58:51 PM] [EG Diele] [ERR] MQTT message received, but no nvalue or svalue1 was found:
[1/23/2024, 12:58:51 PM] [EG Diele] { command: 'switchlight', idx: 129, switchcmd: 'On' }
[1/23/2024, 12:58:52 PM] [EG Diele] Data received for EG-D [Licht].

There was a mqtt message generated (on domoticz/in, which is hardcoded in edomoticz and has nothing to do with the configured mqtt topic).

{
"command": "switchlight",
"idx": 129,
"switchcmd": "On"
}

on which Domoticz updates its status, but no mqtt message to trigger the switch (i guess due to domoticz' configuration not to mirror mqtt messages).

Don't know what the error message could mean, as there is no incoming, but a outgoing message (which does not hold nvalue oder svalue). I think this is a result of having mqtt configured to subscribe to domoticz/in, where edomoticz itself publishes this message (and misses the values).

From the debug line i tried the domoticz URL-API myself (which is i guess is used when mqtt is disabled)
http://192.168.178.5:8080/json.htm?type=command&param=switchlight&idx=129&switchcmd=Off

This URL (with On or Off) does what it should, it updates domoticz, it switches the switch correctly (via domdoticz), and as a result the status within homebridge is also correctly updated (as there is that incoming mqtt message again).

As the mqtt-topic for outgoing messaged is hardcoded to domoticz/in, i am not quite sure which mqtt topic is the right one to be configured within edomoticz, most likely domoticz/out is the right one for reacting on domoticz messages, but this misses mqtt message from devices and domoticz will not replicate switching messages.

Will try to get around that with node-red, doubling/redirecting some messages.

[Ben-Bitdiddle-DE]

With configured mqtt, edomoticz will inform domoticz via mqtt-messages (as shown above), otherwise via the shown URL above. This results in missing outgoing mqtt messages for the devices itself, as domoticz will not mirror these messages (to domoticz/out, for example)

I gave it a try and commented out the mqtt-part within Domoticz.updateDeviceStatus (file domoticz.js, the only location where mqtt-messages are sent), giving the desired behaviour.

Maybe it is worth a though to stick for URLs for outgoing commands and for mqtt for incoming status, and/or having the outgoing message topic also being configurable (instead of fixed domoticz/in). This would give more flexibility.

In the meantime i am helping myself with doubling domoticz/in messages to edomoticz/notify, explicitly adressing homebridge by that. That works for incoming requests, homebridge will react now on these.

For outgoing commands, i am converting the

{
"command": "switchlight",
"idx": 129,
"switchcmd": "On"
}

mqtt messages into their URL-based counterparts (yes, domoticz is triggered twice now because of this...)

Both is done via node-red which i already have at place.

[Ben-Bitdiddle-DE]

Well, I do have MQTT enabled. Either just by MQTT: true or with manual config: "mqtt": { "host": "127.0.0.1", "port": 1883, "topic": "domoticz/out", "username": "", "password": "" }

Both work exactly the same. When a switch is changed in domoticz the Homebridge UI isn't reflected until several seconds after the page is refreshed.

You might enable the DEBUG environment variable and then have a look into the logs, to see if mqtt messages are being received.

[Egregius]

I don't even know how to do that. I would think they're received because the status is up-to-date after a page refresh in homebridge

[Ben-Bitdiddle-DE]

If they are received, devices are updated immediately. Refresh loads the devices and their status via http API from domoticz, there is no "internal cache" for mqtt-messages which could be worked on. So i strongly assume that you are not receiving mqtt messages.

Just goto settings,

enter value 1 for DEBUG,

restart homebridge and have a look in the logs.

[Egregius]

I'm still a bit stuck here. Should I see anything in the /logs view if I enable debug?