Help needed for OpenBeken Project

[pafade89]

Is your feature request related to a problem? Please describe.

Is it possible to help the OpenBeken Developer to correct his firmware for MQTT? It concerns the OpenBeken project, which I think is similar to Tasmota and could be useful for integration with ioBroker. It is already functional, but there seem to be some remaining communication issues as described by @TPTim in ioBroker forum.

https://forum.iobroker.net/topic/72435/warnmeldungen-im-sekundentakt-sonoff-mit-openbeken/6

Currently, the developer of OpenBK needs help with understanding what exactly the Sonoff adapter expects via MQTT: Link to GitHub Issue

As the number of devices natively supported by Tasmota is decreasing, it might be sensible to promote and correctly implement OpenBK.

Thanks in advance to everyone! 😉

As requested, here's a log from the Sonoff adapter detailing the current events: OpenBK_Log.txt

[Apollon77]

@pafade89 please show me your config if the adapter.especially the default QoS setting.

In fact the adater has a default Qos of 0 which should just send the message and do not expect any response - hence the error should never appear. It should opnly appear with QoS 2 ... because here we "remember" the packet and if the relevant message exchange needed for qos2 is not done the message stays in the array and is then condidered "not received" nd so resend ... but after some tries we say "nope, go away".

The relevant code is in https://github.com/ioBroker/ioBroker.sonoff/blob/master/lib/server.js#L1542 and down, so it ciould be an idea to add logging to all these "on("...") that are relevant to see what happens on the protocol level.

I remember we had comparable issues in mqtt adapter some years ago but I do not remember what the final solution was. in fact the code from this is https://github.com/ioBroker/ioBroker.mqtt/blob/master/lib/server.js#L864 and following ... I did a short compare and found one slight difference.

@pafade89 wanne try something?

• go on a shell and edit /opt/iobroker/node_modules/iobroker.sonoff/lib/server.js
• go to line 1654 (https://github.com/ioBroker/ioBroker.sonoff/blob/master/lib/server.js#L1654)
• add a new line AFTER this line (so AFTER the "receivedTopic" line
• insert client._messages && client._messages.splice(pos, 1);
• safe the file, restart adapter test if this solved the issue

If not we nneed to check deeper

[pafade89]

@Apollon77 After making the changes you described in the server.js file for the QoS 2 block, I no longer receive the mentioned warnings. So now I have some Questions ;)

1. Does the Sonoff adapter default to QoS 2?
2. Would it make sense to create a menu for it?
3. What does this mean for the OpenBeken developer?

Thank you in advanced

[Apollon77]

When this fixes it then I would simply add this fix into the adapter and we are done. I think when sending default is QoS 0 or whatever you have set int the adapter config. But it seems we simply handled stuff wrongly when we were the receiver of the message. So OpenBeken should be fine then :-)

[pafade89]

@Apollon77

Where can I set the QoS for Sonoff?

[Apollon77]

Good question, next question, seems to be not exposed in admin config UI https://github.com/ioBroker/ioBroker.sonoff/blob/master/io-package.json#L173

[pafade89]

@Apollon77

When this fixes it then I would simply add this fix into the adapter and we are done. I think when sending default is QoS 0 or whatever you have set int the adapter config. But it seems we simply handled stuff wrongly when we were the receiver of the message. So OpenBeken should be fine then :-)

Sounds great, I'm awaiting the next release.

PS: Does it make sense to add QoS as a menu in the admin UI?

[Apollon77]

fixed in next version