Accessory state is not checked upon start

[rcarmo]

I'm trying to replace a homebridge setup that uses homebridge-mqtt-tasmota, and even though I can toggle outlet power, the HomeKit devices do not mirror the actual device states no matter what I do.

I initially suspected this was due to the requirement for the {"val": ... payload format (which I cannot customise without re-flashing all the devices), but I may be mis-understanding the topic structure.

The solution I'm using is very clear on the topic meaning, and looks like this:

"topics": {
	"statusGet": "stat/sonoff/RESULT",
	"statusSet": "cmnd/sonoff/POWER",
	"stateGet": "tele/sonoff/STATE"
},
"onValue": "ON",
"offValue": "OFF",
	
"activityTopic": "tele/sonoff/LWT",
"activityParameter": "Online",
    
"startCmd": "cmnd/sonoff/TelePeriod",
"startParameter": "60",

I tried using the statusGet topic as input to statusOn, but the semantics seem to be different, and the outlet code does not seem to issue a status request, only listen passively for a message in the right topic.

Any hint as to how to configure homekit2mqtt for this kind of setup?

[hobbyquaker]

The payload format can be either an object with val attribute or just a plain value, works both - so this should not be the problem.
The Message published on the topic you configured for statusOn should be retained, is that the case? Can you please provide the config snippet of the outlet accessory as well as the debug log showing switch on/off?

[rcarmo]

The Message published on the topic you configured for statusOn should be retained, is that the case?

No, not quite. I've been reading through the code, and I now realise that homekit2mqtt works quite differently from the homebridge plugin (which in turn sends out messages in tele/devicename/STATE to force the the accessories report their state when it starts). Also, my Sonoff outlets send out notifications when they're manually powered on, so the topic semantics are different.

I'm going to capture a couple of log sequences and get back to you on this.

[rcarmo]

OK, so here's a log of what homebridge sends out to the outlets:

# initial telemetry setting
cmnd/socket3/TelePeriod:'60'
# outlet reply
stat/socket3/RESULT:'{"TelePeriod":"60"}'

# switch off command
cmnd/socket3/POWER:'OFF'
# outlet reply
stat/socket3/RESULT:'{"POWER":"OFF"}'
# outlet status report (happens after the reply)
stat/socket3/POWER:'OFF'

# switch on command
cmnd/socket3/POWER:'ON'
# outlet reply
stat/socket3/RESULT:'{"POWER":"ON"}'
# outlet status report (happens after the reply)
stat/socket3/POWER:'ON'

# manual off
stat/socket3/RESULT:'{"POWER":"OFF"}'
stat/socket3/POWER:'OFF'

# recurring telemetry
tele/socket3/STATE:b'{"Time":"2017-12-25T23:56:50","Uptime":120,"Vcc":3.122,"POWER":"OFF","Wifi":{"AP":1,"SSId":"IoT","RSSI":48,"APMac":"DC:A4:CA:XX:XX:XX"}}'

Based on the above, I'm tempted to assume that this is the config I need:

  "topic": {
    "statusOn": "stat/socket3/POWER",
    "setOn": "cmnd/socket3/POWER"
  },
  "payload": {
    "onTrue": "ON",
    "onFalse": "OFF"
  },

...but on a first attempt nothing happens when I switch the outlet on manually, and reading through the code I don't see any obvious status checks... Any ideas?

[hobbyquaker]

are the messages on `stat/socket3/POWER´ published retained?

[rcarmo]

No.

…

On 5 Jan 2018, at 21:19, Sebastian Raff ***@***.***> wrote: are the messages on `stat/socket3/POWER´ published retained? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hobbyquaker]

I guess then that's the issue. Homekit2mqtt relies on getting retained status messages. To be sure you could just test if it behaves ok when you publish the status again after start of homekit2mqtt.

[hobbyquaker]

Question is now: do have the possibility to retain these messages? Otherwise - implementing a get-topic config var to all characteristics wouldn't be that much effort, could do it, but can't promise when.

[rcarmo]

Not without changing the firmware running on these devices. Relying on the messages being retained seems like an odd requirement, really.

[hobbyquaker]

hmm I don‘t think thats odd, thats what retained messages are made for - giving clients the possibility to get the last known status without having to send a message to request a status update. I think it‘s odd not to retain these messages :-)
Think of a User Interface e.g that shows hundred or more devices - do you really think it‘s better to send out 100 status request messages or just to subscribe and receive them retained?

[mattsheffiel]

If I'm understanding correctly you are using Sonoff devices running the Sonoff-Tasmota firmware. Is that right?

If so it seems that they can be configured to set retain on messages. It is mentioned in the commands section of the wiki for the repo. Search the page for "PowerRetain." I don't have any of these devices yet so I can't test it on my end but that may fix your problem.

[hobbyquaker]

Will close the issue for now, feel free to reopen if you want to discuss this further.

[alimovichpro]

Hello ! I have the same problem. After starting homekit2mqtt all switches is ON and no sensor information.

[mattsheffiel]

You need to make sure that your devices are setting the retain flag when they send their messages to your MQTT broker. If you devices aren't setting this flag the MQTT broker just passes the message along and then forgets it. HomeKit2MQTT itself does not store the state of MQTT devices and relies on the MQTT broker to give it the last known state when it starts up. Hope that helps.