[APP][Pro] Tasmota MQTT

Hi, sorry for long delay with an answer. It looks like Tasmota MQTT app just don’t receive anything from MQTT client. Can you try to restart Homey applications in following order Broker App (only if you are using Homey app broker), MQTT client app and last Tasmota MQTT app. After restarting each application wait 2-3 minutes before restarting next one. Hope this will fix your problem.

Hi Pavlo,

Today I have added a sensor module to an ESP8266. This module has two sensors:
CCS811 for CO2 & TVOC
HDC0180 for Temperature, Humidity and DewPoint.

On the screenshot below you can see that both sensors are working in Tasmota.

The MQTT information is sent to Homey and works fine. Below the dat which Homey receives:

{“Time”:“2021-01-08T21:07:01”,“CCS811”:{“eCO2”:1653,“TVOC”:190},“HDC1080”:{“Temperature”:26.2,“Humidity”:40.0,“DewPoint”:11.5},“TempUnit”:“C”}

When I add a new device to Homey with Tasmota MQTT, I only see one sensor (HDC1080). I cannot find out why the other sensor information is not visible.

It is possible to disable in Tasmota a sensor. When I disable the HDC1080 only the CCS811 is visible.

If I add a device with Tasmota MQTT, the result is a device without information.

The MQTT information received by the host is:
{“Time”:“2021-01-08T21:22:58”,“CCS811”:{“eCO2”:1516,“TVOC”:170}}

Do you have any idea what I am doing wrong or is it maybe not allowed to have numbers in the header of “eCO2”? I do not know why the information of the CCS811 sensor is not visible.

UPDATE:

I have compiled a new Tasmota version. In this version I have changed the headers of the CSS811 sensor:

eCO2 => HUMIDITY
TVOC => VOLTAGE

As you can see in the screenshot below the problem is solved due to the fact that the Tasmota app does not recognize the headers: eCO2 & TVOC.

Can you please add these headers to the Tasmota app?

1 Like

Done. Published as a test version, check it, please. test 0.8.2
P.S. Thanks for the detailed post with MQTT payloads and Tasmota screenshots it was really easy to add those two values.

Thanks Pavlo for adding the 2 values.

I have flashed the device with the original Tasmota firmware, so the headers are correct.

Can you please check your changes because I miss the value: eCO2. Only the TOVC is
added in the app update.

{“Time”:“2021-01-09T09:55:08”,“CCS811”:{“eCO2”:2747,“TVOC”:357},“HDC1080”:{“Temperature”:21.4,“Humidity”:42.4,“DewPoint”:8.1},“TempUnit”:“C”}

Thanks for your support.

Should be fixed (copy/paste mistake :frowning: ). Check 0.8.3

Thanks for the quick update. It is fixed. :+1:t2:

Hi Rob,

Can you please share how you made this CO2 sensor on the ESP8266?

Hi Arnold,

I think this video CO2 Sensor linked to an ESP will help you. This YouTube video explains step by step the installation. I have used a different sensor but when you connect the sensor to an ESP it will be exactly the same.

If something is nog clear please let me know.

1 Like

Thank you Rob

Hi everybody,

Is there anybody who has 30+ tasmota devices in a network configured to communicate to MQTT broker? I need some help with testing. I working on new devices discovery approach. It should work faster and more reliable but I have doubts if it will work well enough if there is a lot of devices in the network. SO if you can and want to help - let me know I will share test version.

Hi Pavlo…

Thanks again for all the great work your doing… Ive noticed things have been progressing really well over the last few months. Your recent work on this app is starting to restore my faith in Homey. I was almost considering jumping ship and going with Hubitat due to an apparent lack of progress or activity by Athom regarding some major and essential features that don’t really perform properly and/or are incomplete for which they just don’t seem to care about… Now that i have confidence that Tasmota is going to be viable on this platform im going to hold on and see if they get their act together in 2021… (Home Kit :unamused:) flakey, buggy as hell… Its crazy this doesn’t work…

I just have a quick question regarding multi gang light switches… I have a 3 gang light switch made by a company called Deta… Its flashed with the latest Tasmota… When its detected by your app its detected as being one device (or entity) in the Homey device list. The three individual switches in the unit are “technically” detected and registered by the system (and are also accessible via tags), but each switch isn’t individually visible in the Homey device list rather they just show as being one device (entity) and are only accessible via a sub menu under that device (entity) … Will it be possible in future versions that individual light switches in a multi gang light switch assembly can show as individual switches in the main Homey device list ? thanks Russ…

Hi Russel.

Thank you for the kind words. I will try to do my best to continue developing this application. As for the feature that you requesting it is in my development plans but on the bottom of the list. This feature will require a lot of work because of internal application architecture and some other reasons. Also, it is not really clear for me how the application should behave if there is, for example, two gang switch with a temperature sensor. Should this sensor be a separate device? Or belong to the first individual switch? Or both switches should have copies of the sensor? And this is only one of many questions. Also, these individual switches should coexist with current implementation (because there is a lot of people that use the current approach). So what I am trying to say: don’t expect this feature soon.

Just to make everything clear, let me share with you my current development plan:

  • Next version (I think it will be 0.8.5). I would say it is 80% ready. Shutters support, improved device discovery, a couple of bug fixes (there still one nasty bug I still chasing).
  • Version 0.9.0: Icons support. If it would work as I see it users will be able to assign predefined (and maybe custom) icons to devices. Each icon change will require application restart (Homey SDK limitation)
  • Version 1.0.0: Sonoff RF bridge support.
  • Version 1.1.0: Adding individual switches as separate devices for multi switches devices.

Also somewhere in a middle, I will implement support for the new SDK 3 that should be released together with Homey firmware version 5.0.
This plan is not carved in stone so if you have ideas or suggestions - we can discuss them.

1 Like

Dealing with multiple functions in one physical device is a bit of a tricky one…

If it were me I think the overall best strategy would be to have every function discovered on a physical device created as an individual device. It’s not the most perfect strategy but I think overall it would be the best one for the following reasons.

1). Light switches are probably the most common devices used in peoples Home Automation setups , where as things like temperature sensor/relay combos are a bit more obscure and not really used very much… I think individual switches in multi gang light switches really need to be visible and easily accessible in the Homey device list and also in the favourites bar as it’s the one thing that people really be able to see and access quickly . Also it makes it a lot easy to access the switches via Siri/Alexa/Google if they are in the Homey device list. Yeah there is a work around by turning the light switch’s on a multi gang switch into individual Virtual switches but it’s very messy and complicated as hell to do.

  1. I don’t think it’s a major determinant if a user of a temperature/relay combo can’t see both functions under one window. Most of the time these devices are just used for automated tasks in the back ground (say a roof exhaust fan) and don’t needed to be accessed very often. Some people do however like to keep an eye on the temperature readings either in the dashboard or on their phones via HomeKit/Android etc etc… The Homey device list will probably also eventually display live temperature readings in device icons. For this to be done easily though a temperature sensor really needs be created as its own seperate device. At the moment I have to muck around and make up a Virtual device for mine to show up and be viewable…

  2. As Virtual Devices evolve users who have unusual sensor/relay combo’s or other combo devices will probably in the future be able to create Virtual combo devices…

  3. Making all discovered devices show as an individual devices in the Homey device list will also make your life a lot easier I think. No need for you to intervene. Just supply the bricks. The users can build the house…

Russ…

Hi Russell,

I agree with your arguments but it will not simplify tasks. Anyway, existing functionality will still as it is. In the opposite case, everybody will need to remove devices and add them back (and also fix flows). I think I will create a separate device type that will show only separate switches from multiple switches devices. But as I said, it is not really clear to me at the moment how these two device types should coexist. This functionality will require a l;to of time so that is why I moved it to the end of the list.

No prob. I think there are some device types that definitely work better having all their control inputs under one device entity… eg multi speed fan controllers, curtain controls , light dimmers , addressable LED light strips … etc etc. Those sort of things suit that format well.

Sorry for the very late reply. Life got in the way :slight_smile:

Below is the current Template I am using for the curtain switch:
{“NAME”:“WF-CS01”,“GPIO”:[544,0,290,33,225,162,0,0,160,224,289,226,288,0],“FLAG”:0,“BASE”:18} (from WF-CS01 Curtain Switch Template for Tasmota originaly)
In this setup I use the below setup in switches and buttons. There is also another setup (from the template database) i used before that has the setup of button vs switches exactly the other way around. I don’t know how this will impact your work, thought I should mention it. But at least this is the setyp I am currently using:
Switch1
Button2
Switch3

Here is the information of the statusses you wanted.
21:32:47 MQT: stat/Curtain1_747D18/STATUS10 = {“StatusSNS”:{“Time”:“2021-02-08T21:32:47”,“Switch1”:“OFF”,“Switch3”:“OFF”,“Shutter1”:{“Position”:0,“Direction”:0,“Target”:0}}}

21:32:53 MQT: stat/Curtain1_747D18/STATUS11 = {“StatusSTS”:{“Time”:“2021-02-08T21:32:53”,“Uptime”:“0T04:31:52”,“UptimeSec”:16312,“Heap”:20,“SleepMode”:“Dynamic”,“Sleep”:50,“LoadAvg”:29,“MqttCount”:7,“POWER1”:“OFF”,“POWER2”:“OFF”,“POWER3”:“OFF”,“Wifi”:{“AP”:1,“SSId”:"###",“BSSId”:"###",“Channel”:1,“RSSI”:58,“Signal”:-71,“LinkCount”:1,“Downtime”:“0T00:00:03”}}}

Just wanted to check something as well. When using the IF portion of flows based on my curtain switch (current state a multiple switch) if found the following:

Is this a naming mismatch or does the logic indeed match up with the names?
Because if I have All sockets are turned on, the reverse would be All sockets are turned off. Now it is Some sockets are turned off.

Hi Pavlo

Can you please have the app understand this MQTT?
its a bunch of analog values :slight_smile:

18:11:55 MQT: tele/tasmota_02386F/SENSOR = {“Time”:“2021-02-09T18:11:55”,“ADS1115-48”:{“A0”:1472,“A1”:2719,“A2”:2680,“A3”:3754},“ADS1115-4a”:{“A0”:967,“A1”:3243,“A2”:2997,“A3”:3153}}

image

Thanks. The new version with shutters support almost ready. Just stuck with flow cards. Not all of them working as I want them to work.
As for condition cards: everything is correct that is how formal logic works. If you have “All sockets is turned on” = “socket 1 turned on” and “socket 2 turned on” and “socket 3 turned on” … . To reverse this statement you need to replace and to or and reverse all parts of statement, so you will get => “socket 1 turned off” or “socket 2 turned off” or “socket 3 turned off” = “Some sockets are turned off”. And the same way for another one. Check this for the details De Morgan's laws - Wikipedia

@Stefan_Wempe it will require some work and I really want to finish shutters support so I will add this not in the next but following release.

1 Like

no problem, got it working through homeassistant → homey for now :slight_smile: