Sorry, it looks like I can’t fix this easily at least for now. Flowcard triggered by Homey SDK itself once I changed property. Of course, I can add delay to check if the property didn’t switch back but it will influence everything. So I will live it this way and will try to find some workaround in next version.
Hello,
I have noticed recently, that when I remove the Tasmota device from Tasmota’s MQTT app (ver 0.8.5) (Homey (5.0.0)) and add it again (with Tasmota’s MQTT app), then for the power measuring device (e.g. Sonoff’s POW2, or Athom’s ZEU socket) the Homey’s energy tab is not recognising the meter readings from these devices anymore (even when they are presenent in the Tasmota device’s app’s GUI, and Insights).
The visible differences I have noticed are that the Tasmota’s devices meters’ positions (in app’s GUI) have changed (prior removal of the device, the upper left corner started with a ‘voltage’ etc, then after reinsertion it starts with a ‘power meter’). Also, under the Tasmota device’s additional settings’, there are ‘additional sensors’ (named “total”, “yesterday” etc) listed for the device after the newer insertion, while the same device had this field empty prior removal).
(These devices have currently Tasmota v.9.3.1on them, but it was the same also for v.9.2.0.)
Has anybody else also noticed anything like that? Are there any suggestions of how to get the meter readings back to Homey’s Energy computation? And would there be an option to change the position of the meters’ icons in the Tasmota device’s tab (so that it would show at least voltage and current in the upper part of the window)?
Thank you in advance.
Janno
Hi, thanks for the detailed report. It looks like my fault. Thing is that energy in tasmota reported the same way as sensors so I wanted to have unified code to process sensors and energy. I will not dig dip into details but apparently, Homey uses energy values for devices only if they used with specific properties names. Will try to fix this asap.
Oh, that sounds really perfect! I wasn’t sure about if it was about Homey (5.0) or Tasmota or anything else…
Other than that, one additional feature You could think of, might be introducing the (Sonoff’s) “L1MusicSync” enable/disable (or also settings) also to the GUI, which was introduced to Tasmota recently…
Hi Pavlo,
thanks for your work. I’m very grateful because you makes live better for Tasmota-Sonoff users like me. And thanks also for your recent implemetation of sensors.
Yesterday I successufully tasmotized a Sonoff Zigbee Bridge, and joined an (zigbee) Aqara Water Leak Sensor. Then I added the bridge to Homey through your app. I thought that I could be able to control the water sensor from Homey, but the bridge says “No available controls - This device has no available controls for display”. I’d like to use the water sensor in some flow of mines.
Sure someone could say that I could add the water sensor directly to Homey, but a) my building (a school) is very large, and the Sonoff ZigBee Bridge with is capability to bridge wifi<->zigbee would be the best solution, and b) the two (Sonoff Bridge and Aqara water leak sensor) are wonderfully cheap (from Aliexpress).
I don’t really sure what this setting does, and how it should be used. Can you explain, please? Is it available only for Sonoff L1?
I have mixed feelings about this device. On one hand, it should be relatively easy to add sensors (such as Aquara temperature, door contact, or water leak) but on another hand, it would be a huge pain to add all controlled devices as Zigbee lights. So I am not sure if I want to open this Pandora box and start supporting zigbee2tasmota. I wouldn’t be able to support this full scale for sure. I will think about it. Anyway, even if I will decide to implement this it will take some time so don’t expect it soon.
afaik, “L1Musicsync” enables the microphone usage via Tasmota (for Sonoff), so that the L1-device (the ones, which have a built-in microphone) flashes its lights based on surrounding sound, e.g. music… I would assume that some people are using this solution behind a TV-set, if not making any addressable LED-strip solutions. Kids would like that as well ;). L1-device is the RGB-LED controller.
https://tasmota.github.io/docs/Commands/#l1musicsync
There is also a review of the L1 Lite (lower power, indoors) version:
Thanks for your fast reply. I understand.
If I can be of some type of support in it (I’m a dummy user however), when you possibly try, please let me know.
Thanks! I will think about supporting it. Not really clear to me how to detect that this feature is supported.
Actually, I already took a look at these zigbee2tasmota things and it looks like it could work for the Zigbee sensors the same way (or with minimal changes) as wired sensors. Now I am working on sensors related modifications so it is a good time to try to make it more general. This solution wouldn’t be pretty (for example to make it generic I will need to use a sensor address like 0x7C5A instead of name) but it will work. So I ordered Sonoff Zigbee bridge (will arrive in 10-14 days) but I don’t have any water leak sensors. It would help if you will provide me MQTT payload related to Zigbee for your sensors. It should look similar to this (this one is for temperature sensor):
MQT: tele/%topic%/SENSOR ={“ZbReceived”: {“0x8F20”: {“Name”: “Kitchen”, “Voltage”: 2.995, “Battery”: 98, “Temperature”: 21.01, “Humidity”: 53.68, “Pressure”: 1004.04, “PressureUnit”: “hPa”, “Endpoint”: 1, “LinkQuality”: 88}}
You can find this in the console of your Zigbee gateway.
Hi Pavlo,
you’re really a smart guy!
Here the payload related to the Aqara Water Leak sensor:
MQT: tele/tasmota_9C20F7/SENSOR = {“ZbReceived”:{“0xD9A3”:{“Device”:“0xD9A3”,“BatteryVoltage”:3.12,“BatteryPercentage”:100,“Xiaomi_64”:0,“Endpoint”:1,“LinkQuality”:152}}}
Thanks again!
Sorry,
the previous was the payload in a dry condition. Here I add what happened when I put the sensor in contact with water:
17:12:10.091 MQT: tele/tasmota_9C20F7/SENSOR = {“ZbReceived”:{“0xD9A3”:{“Device”:“0xD9A3”,“ModelId”:“lumi.sensor_wleak.aq1”,“BatteryVoltage”:3.12,“BatteryPercentage”:100,“Xiaomi_64”:0,“Endpoint”:1,“LinkQuality”:126}}}
17:12:17.815 ZIG: {“ZbEZSPReceived”:“450000040100050101000100007CF0D8A3D9FFFF09191800010000FF000002”}
17:12:17.817 ZIG: {“ZbZCLReceived”:{“groupid”:0,“clusterid”:“0x0500”,“srcaddr”:“0xD9A3”,“srcendpoint”:1,“dstendpoint”:1,“wasbroadcast”:0,“LinkQuality”:123,“securityuse”:0,“seqnumber”:124,“fc”:“0x19”,“frametype”:1,“direction”:1,“disableresp”:1,“manuf”:“0x0000”,“transact”:24,“cmdid”:“0x00”,“payload”:“010000FF0000”}}
17:12:17.820 ZIG: ZbZCLRawReceived: {“0xD9A3”:{“0500<00”:“010000FF0000”,“ZoneStatusChange”:1,“Endpoint”:1,“LinkQuality”:123}}
17:12:17.824 MQT: tele/tasmota_9C20F7/SENSOR = {“ZbReceived”:{“0xD9A3”:{“Device”:“0xD9A3”,“0500<00”:“010000FF0000”,“ZoneStatusChange”:1,“Endpoint”:1,“LinkQuality”:123}}}
Hope it helps.
Thanks, for the input data it should help!
Meanwhile, I almost finished fixing power monitoring and support for analog inputs. Reworked almost all code related to sensors, now it is more logical, compact, and faster but probably will consume more memory. Also made preparations for support of Zigbee sensors. If you are using devices with energy monitoring like Sonoff POW2 and added it in version 0.8.5 they will stop working you will need to remove them and add them again, sorry for that (devices added earlier should work). The test version is here: Tasmota MQTT | Homey
I didn’t tested it a lot yet so be warned it can be buggy. And most likely I will not publish it as release (want to add Zigbee sensors support before releasing the new version)
I was converting some more screens and shutters to Tasmota and updating my flows for them, when I found some strange things.
- When setting a position in a flow to go to, it only accepts values above 0. Position 0 (completely close) is not accepted here.
Also when in the slider screen of the device UI. Pressing the top image will open completely. Pressing the bottom image will only flash the slider but do nothing. - Also I have request. Currently you can start flows based on the status (direction) and position, which is very nice. But in the AND cards, you can only use the status (direction) and not the position.
I have a flow based on a light sensor to slightly open or close the shutters, where the trigger is the light sensor and the second requirement should also be if the shutter is open or closed. I would love to check the current position for that. - Just noticed that Google Home commands do not work anymore. Before the "Open " and "Close " commands would work, but not this does nothing. They do show up in Google Home as Blinds (don’t know the English name for sure it’s listed as Jaloezieën in Dutch). That was also the type that was previously working when still connected via the Tuya Cloud app in Homey.
I Will check, it is possible I messed somewhere. It is possible that the problem is in type casting in js.
These flow cards created by homey SDK not me, but of course I can add some more. I will check.
What version are you talking about? Is it 0.8.6? Strange I haven’t changed a lot related to blinds. Can you try to remove device and add it again?
Yes I am working with the latest and greatest. This was also the version I added the devices with, so won’t be any leftover from previous versions.
But what I meant was that the functionality in Google was working when still had the devices with original firmware on Tuya Cloud app. I have never tried the Google commands on a Tasmota version yet. Just tried it now. I now have a workaround that used the <Group> app to combine the two shutters I added, with Control and Position passed on to the group. The group (also type shutter) does react to the Google Commands. So somehow even though they have the same types (in Google and Homey) some react and some don’t…
I can’t test google assistant integration and it is mostly on the Homey SDK itself application just need to use proper capabilities. So from my point of view, it should work. Anyway, I will check again.
2 All,
Short update about the current development status:
-
I almost finished migration to the new SDK v3 that was introduced with Homey version 5 software. This means that you will need to update your Homey to the latest version if you want to have updates for this application in the future.
-
I checked the new Tasmota discovery strategy that was introduced in version 9.2.0. It looks really nice but I can’t use it because of the limitations of the MQTT Client application. It does not allow subscribers (my application) to receive retain messages properly. I already hit some boundaries of the MQTT Client and this application didn’t have updates longer than a year. In the future, I will need to do something about it. As I see it I have 3 options: 1. ask the MQTT client author to implement some features (or implement it myself and ask him to merge my changes into the app), 2. Implement a new MQTT Client application myself and use it in Tasmota MQTT application. 3. Add MQTT client functionality inside Tasmota MQTT application. Each option has advantages and disadvantages. As application users which one do you prefer?
-
About Zigbee bridge support. My bridge has arrived, so I start looking at how it works. There are good news and 2 bad news. Good news: support of sensor values readings is easy and almost the same as reading wired sensors in Tasmota. The first bad news: sensor discovery strategy for Zigbee devices should be completely different. It is so different that I thinking of implementing it in the future as a separate driver. It will require some time for code refactoring and changes. So it will not get into the new release version of the application. The second bad news is about leak sensors: there is no way to request leakage status. For example, if you added a leak sensor to the application, it will not know if the device detecting leakage right after it was added until the status change. And the same if device status changed at the time when Tasmota MQTT application is not active. So let’s say the application is restarting because of the update and at the same time your sensor detected leakage, the application will miss it and will still think that everything is OK even if Zigbee bridge is aware that the status changed. And there is no way to fix this. Zigbee functionality in Tasmota is actively developed now so maybe it will be fixed in the future. But for now, be aware that there is a huge limitation.
-
Next thing I want to do is to do some code refactoring. I start hitting some limitations of the current application architecture. All MQTT communication goes through the driver so it leads to the situation that if I want to add new device types (such as Sonoff Zigbee bridge, Sonoff RF bridge, single socket for multi socket device) I need to create an almost exact copy of the current driver just to keep same way of communication with MQTT. I need to split driver functionality and MQTT commutator functionality. That will allow me to add new devices easier in the future.
2 Likes
My €0,02 regarding your MQTT issues: I would suggest contacting the developer (@scanno) and ask if he would be willing to accept PR’s from you. If it’s not possible to keep using the MQTT Client app, implement MQTT functionality in the Tasmota app directly. I’ve done the latter in my Sonoff app. I would not advise creating your own MQTT Client app.
Thanks, good suggestion. I agree with you. Making my own app was the last option for me,
Fixed this, can’t get used that js interprets 0 as null and MQTT Client app has problems with sending 0 as number. You should always convert it to string or sending will fail. Will be included in next version.
I checked it, it is not a good idea to use position in AND condition. Usually, the position visible to application is 2-3 seconds late (Tasmota reports with delay + delay added by MQTT delivery + processing delay). So your condition will always work with the wrong value.
Voice commands should work for direction but not position. So command “Up” or “Down” for blinds should work. Can you try these values?
That is how Homey SDK defines them. Also Homey use this string for “blinds” device class:
So probably that is how you should call them when using voice command.
Thank will look forward to that change! Any idea when you will release a testversion?
I found that the Up/Omhoog and Down/Omlaag give weird results (always have) with Google not understanding it and giving me search results… 
Also when looking at the Google Home Hub interface, google provides you with open & close buttons.
I found that the Open <shutter name> commands works fine, but the close command does not. But i think this is related to the 0 issue. When I give the command to close, i see the shutter interface flash a second. Seems like the command is given, but nothing happens. Would love to test this with a new test version.
No, it doesn’t. Sounds more like developer error 
