[APP][Pro] Tasmota MQTT

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.

Version 0.9.2 published to test. Some flow cards fixed. Added support for Xiaomi Mijia Door & Window Sensor MCCGQ01LM Zigbee compatibility info
As always you can find it here: Tasmota MQTT | Homey
If there will be no surprises this version will go to release in a couple of days.

I can also see, that in the v.0.9.2 the status update for the 1-gang switch started to work for flows. Thank You very much.

Looks like the last update broke flows to stop the sockets.

This option isn’t working anymore:

Any ideas how to solve this?

Sorry for that made a mistake when moved this action code from the device to the driver (according to the new SDK 3 approach). Funny that I tested it but only for a separate socket not for “all sockets”. Please, try the new test version v 0.9.3 Tasmota MQTT | Homey and let me know if it is working.

Yes it’s working again.
Thx :+1:t2:

Strange never heard about this problem before. An application is written in a way to prevent it. The only explanation I could think of is problems with resource allocation on the Homey side (not enough memory). Can you try to reboot Homey by disconnecting it from power and try to add the Tasmota device again after that?
If it will not help, I will explain how to send a bug report with logs and analyze this problem.

Hi everybody,

Here is the new test version 0.10.0: Tasmota MQTT | Homey
It is just a test version I will not publish it to release (want to do some improvements). So this version supports the device icon change. To change the icon you should select: Device settings → Advanced Settings → Device icon. A couple of limitations: 1. This functionality will only work for newly added devices. For old devices attempt to change icons will do nothing. 2. You can only use icons from the list and cant add yours (maybe I will add possibility to add custom icons in future). 3. Icon will be applied only after application restart (that’s the time when Homey front end picking up icons from storage). Immediately after icon change, you will see no difference. 4. If you will change the device icon and then revert back to the stable version (v.0.9.3) icon will still be the same as you set in 0.10.0. 5. Icon change now works only for tasmota devices (not working for Zigbee sensors yet)
Here is a reference picture for icons you can apply for your devices:


The name of the file is the name of the item in the settings dropdown box (just replace _ with space and make the first letter capital).
Let me know if everything works and also if you would like to see icons for other device types.

Wow amazing set already! I will definitely change my devices to the new version. But will I have to re-add them in the future for a final release?

Also for the other device types, I have some requests. You already have many types of lamps/lights, but only one for curtains. I use switches on:
Curtains (yours look fine!)
Roller shutters ( something like this? Roller Shutter Door - Free buildings icons)
Suhshades (mine are what they call “Zonnescherm” Iconen tekenen voor Pals zonwering Boskoop | Rhapsody Ontwerpt)
Other types of curtains or blinds (like Curtain Blind Icon Set Design Stock Vector (Royalty Free) 1383449000)

Greet work Pav,

:grin::grin::grin::grin::grin::grin::grin::grin::grin::grin::grin: