Homey Community Forum

[App] Tasmota MQTT

Working fine after removal and adding it back - just a pity it wasn’t noticed in the changelog, otherwise I would notice it sooner then after 5 days :wink:

Sorry for that. Didn’t through it through.

No worries Pavlo, we still appreciate what you have done with Tasmota :wink:

Good morning everybody,

I have early test version 0.9.0 with Sonoff Zigbee bridge, and some Zigbee sensors support. As always you can find it here: Tasmota MQTT | Homey
Bt first warnings:
1. Zigbee sensors support is experimental for now. It is possible that in future versions current implementation will become incompatible with the new code, in this case, I would ask you to remove all senors and add them again. Do not create complex flows with Zigbee sensors yet!
2. Not all problems in this version are resolved yet. So I wouldn’t recommend you to use this version for important tasks. It is just for you to try and help me with testing

  1. Biggest changes are under the hood. A lot of code rewritten. Driver and device code splitter to make adding new devices (such as RF bridge) simpler in the future. Mqtt code moved from driver to application. The device discovery code was rewritten to be more general.
  2. Sonoff Zigbee bridge device support is added. You can add it the same way as before using “add Tasmota device”. You still can use Zigbee sensors attached to the Zigbee bridge without adding the Zigbee bridge itself to Homey.
  3. Added support for some Zigbee sensors. To add them you should use the new “Zigbee device (experimental)” type of device. What is supported: All sensors with temperature, humidity, and pressure (tested with TH01), motion sensors (at least lumi.sensor_motion.aq2, contact sensor (will work with lumi.sensor_magnet.aq2 only for now but it is possible to add new devices of this type), water leak sensor (will work with lumi.sensor_wleak.aq1 for now but it is possible to add new devices of this type in future).
  4. Signal strength value added for all devices (even for devices that was added in previous versions)

P.S. This version has a known non critical issue with 30 seconds delay in initialization for some devices . It is not important for testing but I will not publish this version to release, it will stay only as a test version.


Hi. I had a similar problem. Was on Homey 4.2 … I forgot that I had MQTT client set to Auto update. It updated and since then every device would go offline after each homey restart and I would have to restart Tasmota to get things to work after every reboot.

To fix this I thought maybe the new MQTT client update maybe was only compatible with Homey V5. So I updated to Homey V5 but the issues still occur…

I have the latest version of Tasmota MQTT, MQTT client and MQTT broker. Can anyone tell me if I need to wipe all my Tasmota devices from Tasmota MQTT and have to re-discover them all over again.? . am hoping to not have to do this .


My workaround is to restart the Tasmota app after 10 min after every homey reboot.:

1 Like

Hi, I am aware of this problem with the applications startup order and will try to fix it in the next versions. But now I need to stabilize and release Zigbee sensors related code. I also wanted to propose a solution similar to Joka’s. Restart Tasmota application by flow after startup with delay.
@Joka thanks!

No prob. Shall do… . thanks

Thanks for your work just received my first sonoff TX3EU (for test before to change all my light switch), flashed, configured MQTT broker/client, added device so all good. Just a question, I saw a post about icons (but don’t see any status). In Tasmota I chose Sonoff TX1 but in homey I have a plug icon and not light switch. Is it an issue with my config?
Again thanks for your work

Hi @Snoop ,
Icons support implementation still pending. And there is nothing wrong with your config. Icons are set automatically based on a number of relays and features supported. Light bulb icon assigned only if your device has a single relay and dim is supported. If you have one relay but no dim support you will get plug icon. And this can not be changed yet.

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
        { 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
        { topic: 'homey/#', reference: 'my.app.id' }, 
        (error) => this.log(error || 'unsubscribed from topic: homey/#')