Homey Community Forum

[App] Tasmota MQTT

Thanks Pavlo. I can change the icône in HomeKit so it is not a big deal :slight_smile: just wanted to know if I messed around.

I have another stupid question. Just added a Sonoff TX3EU2C and it is display as a multi plug and no direct access to individual switch. I created a virtual device for each switch and linked to flows. But is it the easiest way to have a quick access to individual switch ?

That is another thing that is pending to be implemented. For now, there is no other way. I have plans in the future to add the possibility to add separate switches for multi-switch devices.

I wasn’t asking for more work on your side as I know very well this issue of finding time for side project. Is Virtual Device the more efficient method at the moment?

@snoop Maybe the ‘MQTT device’ of the MQTT hub app?

Hello everyone, I have multiple tasmota devices, but only one currently running mqtt and connected to my homey. It is an s26 smart plug with some lights connected. When I add the device in tasmota mqtt it is working fine for a while (days, up to a week) but inevitably it will be greyed out in my device list with a warning that says Device timed out. Restarting all the apps (broker, client, tasmota mqtt) does not fix it. The only fix is to remove the device and add it again. I don’t even know where to start troubleshooting when there is 3 different apps and one device at play here. Anyone have an idea about this?

Hi @unicus.
Most likely, if the device fails with timeout and the problem is not in the device (you didn’t change the configuration or disconnected the device), MQTT communication is broken. To check if the device communicates with MQTT use the console from your s26 web interface. YOu should be able to see messages like this:
06:00:59.899 MQT: stat/tasmota_******/STATUS
(with MQT after timestamp).
If you see these messages your device and MQTT broker communication is OK. Next step - to check the client. Use Configure App → Get logs from MQTT client and check if you can see messages like:
20210412-05:02:12 received …
If you see them client-broker communication also working. THen the reason should be - broken communication between the client and the tasmota MQTT app. The easiest way is to restart the tasmota MQTT application (but you will need to do it after each homey restart) or use this workaround: [App] Tasmota MQTT - #276 by Joka

Published 0.9.1 to beta (Tasmota MQTT | Homey) . This version is much more stable and contains a lot of fixes and small improvements. But I changed the way how Zigbee device ID generated so you need to remove all Zigbee (Zigbee only) devices added in version 0.9.0 and add them again (sorry but I warned it could happen). Also, I tried to fix the problem with the MQTT Client connection and I couldn’t reproduce the problem in my environment. Everything works like a charm, even if my app starts after the MQTT Client everything works. Anyway, I tried to work around the problem and add a mechanism that if there are no incoming MQTT messages longer than 10 minutes application will try to reconnect. Can somebody check if it is working? Also fixed all known bugs (and probably add a couple of fresh bugs :smiley: )

@pavlo Have you seen (and tried) this already? Hopefully it solves many of the connection problems.

1 Like

I also added a reference to the subscribe api. This reference can be used with the new unsubscribe api to dispose topics not needed anymore.

The reference can be any string grouping topic subscriptions.
The base scenario is sending your app.id with every topic subscription to unsubscribe on app uninstall. Another example could be a device.id to manage active topics per device.

Example usage:

// Subscribe to all messages in the `homey` topic
// messages will pass through the onMessage method via the realtime api
MQTTClient.post(
        'subscribe', 
        { topic: 'homey/#', reference: 'my.app.id' }, 
        (error) => this.log(error || 'subscribed to topic: homey/#')
 );

// Unsubscribe from topics used by this app
// If the topic is not provided, all topics used by 'my.app.id' will be unsubscribed
MQTTClient.post(
        'unsubscribe', 
        { topic: 'homey/#', reference: 'my.app.id' }, 
        (error) => this.log(error || 'unsubscribed from topic: homey/#')
);

@HarriedeGroot No I haven’t seen it yet. It looks like you did a great job. Will try it today. That is great that you improved the processing of retained messages. Now I can try to implement support for new tasmota discovery.

@pavlo maybe the Homie Discovery device of the MQTT Hub can give you a jump start? Because the retained messages are send at topic subscription, discovered devices are coming in immediately.

Also the unsubscribe API is very useful here. Discovery takes place at some root wildcard topic. Now we can free the resources if discovery is finished. Before the client kept listening to all these messages until the app was restarted.

Unsubscription is implemented in the test version of the MQTT Hub (beta branch).

Hello. I have noticed during few days a 1-gang wall switch’s status is not updating for flows anymore (switch can be operated via Homey’s GUI and its status is updated correctly for GUI). Earlier the status changes for flows was working. (No such issue with 3-gang switch, at least for particular ‘button’). E.q. I have created a flow to generate a timeline notice when the switch’s button is pressed, but no notices are created. As if device ‘status’ is used instead of gang’s ‘status’? Currently running Tasmota app V.0.9.1 (experimental), Homey 5.0.4.
Has anyone else seen that?

Yes, it could be my fault I changed a lot of code responsible for flow cards when were splitting code for Zigbee driver. I of course tested what I could but not all. Thanks for reporting I will check it.