Hmm I understand what you’re saying. My use case would not be that time sensitive, but I do see what pandora’s box you’re opening. I just want to do a check to see if the blind are open, half down, closed and react differently to that when the sun value changes. I don’t have to react during a movement.
I’ll solve it by also storing the last known position in a variable then. Was hoping to avoid it 
Still need to test some features, maybe in a couple of days.
It looks like it.
Maybe, it was just an assumption. MQTT Client always gives an error if you are trying to send 0 as a number (but perfectly works with 1 and any other int). But works if you send 0 as a string.
If you want I can also add windowcoverings_closed capability, there is a condition flow card related to this capability that says is shutter closed or not. But it will add an additional control element (close/open shutter button) and will not help you with a “half-closed” situation.
Looks like that’s because of this line: nl.scanno.mqtt/broker.js at 44756f365aba375db53b8593566261b3e4e07b4a · scanno/nl.scanno.mqtt · GitHub
Specifically the check if (args.mqttMessage), which will fail if args.mqttMessage is the number 0.
Since MQTT is text-only anyway, it’s probably best to always pass strings.
1 Like
Thanks!
Don’t think this will be very useful in real life. Thinking about usage scenario’s, after knowing if it not closed, I would still like to know more detail. So the best way might be to be able to store the value of the position in a Homey variable each time it moves. You will have more granular data but with a bit of delay there, but that’s nothing new with Homey 
Version 0.8.7 is in beta. Now app using SDK 3 so your homey should run at least software version 5.0.0. Small fixes for device discovery, shutters, sensors. No Sonoff Zigbee bridge support yet (it will take more time than I expected). You can try it here Tasmota MQTT | Homey
If no critical bugs will be found I will publish this version to release after the weekend.
So far so good! The issues I had, are now gone. All other movements and flows also seem to be working for my shutters. Power Switch with metering also seems fine with correct values. Will test lights later, I also have an issue in Tasmota itself so that is still a bit wonky over there.
Today the MQTT Client app refreshed on my Homey, and since then the devices handled by Tasmota MQTT application show ‘Device update timeout’ error and a red triangle on it’s buttons.
Anyone else facing the same problem?
Bummer… what topics is it subscribing to and posting on… So some logging from the MQTT Client app would be nice @GergelyBarta . You can look at the logging from setting and retrieve the last few loglines.
@robertklep think i found the problem
This fails:
20210319-18:59:51 state.topic = homie/deviceid/$stats/uptime topic = homie/deviceid/$stats/uptime
20210319-18:59:51 topic: homie/deviceid/$stats/uptime pattern: homie/deviceid/$stats/uptime
20210319-18:59:51 regex test result: false
Hower this works:
20210319-19:00:51 state.topic = homie/deviceid/$stats/uptime topic = homie/deviceid/+/uptime
20210319-19:00:51 topic: homie/deviceid/$stats/uptime pattern: homie/deviceid/+/uptime
20210319-19:00:51 regex test result: true
Here’s a quick fix for that:
function topicMatches(topic, pattern) {
const regex = new RegExp('^' + pattern.replace(/([.$^*])/g, '\\\$1').replace(/\+/, '[^/]+').replace(/#/, '.+') + '$');
return regex.test(topic);
}
But perhaps it’s better to use a module like mqtt-wildcard, which should implement proper matching instead of using a regexp hack like I did 
Well mqtt-wildcard does not completely worked, but copied the function and modified one check
seems to work
If someone can check if this solves the problem?
1 Like
For me it works. After a restart of the Tasmota app, all devices linked. No issues found.
1 Like
Not completely. I’ve updates to 2.4.0 and running Tasmota MQTT 0.8.7. But still I woke up to all my devices being unavailable.
After a reboot of Tasmota MQTT app they are back again.
Did you restart the Tasmota app after updating the MQTT Client app? When you update the latter, all connections are gone and the Tasmota app needs to be restarted to set them up again.
Yes I did, after restarting them again this morning same thing just happened. Now only restarted the Tasmota MQTT app, devices are back up. Will let you know if the behavior continues.
Would any logging or report help in finding issues?
For me also only manual upgrade of the v0.8.7 was sufficient (I still run MQTT client v.2.3.0). I also loaded again the Tasmota devices and had to update the flows. (I have also some devices with Sonoff’s app (@robertklep ) and these were not affected). In v0.8.7, I noticed, that the power consumption values for Homey’s Energy-sheet look OK, and now also the manual power consumption values per each non-measuring device give the proper input to the Energy-sheet. Thank You!
What I noticed during the v0.8.7 upgrade, was that all re-added devices’ thumbnails had a status as “ON” initially, and not actual real status.
My Sonoff app doesn’t use the MQTT Client app.
Yes, I remembered that… 
