Looking at the Tasmota documentation it looks like the fanspeed command is only supported for Sonoff iFan. I guess I will need to figure out a workaround with MQTT or something
1 Like
I just updated a few of my device from Tasmota 12.X to Tasmota 14.X and at first they would not respond. In order for them to work with this driver I had to issue the command "so128 1". May also be true with 13.X but I can't say for sure as I skipped right over that version.
The above command means to set Tasmota option 128 to ON which the Tasmota documentation describes as follows:
Once I did that it works as expected.
1 Like
I am trying to use 'tasmotaCustomCommand' from 'Set Variable, Mode or File, Run Custom Action' in the Rule Machine (rule-5.1), but nothing happens...
This works from device:
As does this:
This does NOT work (from Rule Machine):
(I don't even see any activity on the console at all!)
Try putting both parameters in quotes and then both not in quotes if the latter does not work. Turn up the logging on the device and the check the Hubitat log to see what happens.
1 Like
Is anybody else having strange behaviour when using the color change logic? Individual channel brightness levels seem quite unpredictable whenever changing color/preset? Or perhaps ColorApply should override brightness given you are already giving a full RGBWW string....
I think it is linked to using COLOR2 rather than COLOR, and I can understand that you might do this when brightness is not at 100%, but I find the level data seems to regularly populate with NaN or seemingly random numbers. I cant seem to crack what is going on and have currently overridden all COLOR2 commands to COLOR, but will spend some more time debugging if nobody else has ideas. Also I quite regularly see "Complete:Timeout" in the logs, but cant understand why!
EDIT: Tasmota seems to be responding with this data, hence confusing the behaviour of this integration, not sure why yet.
Thanks!
It's been several years since I wrote these and I have wondered how many people use them, I only have a few left myself. I vaguely remember the issues that related to how COLOR, COLOR2 and LEVEL were intertwined causing some trickiness.
If you can send me some specific values in order to reproduce I can try that, but I'll warn you that at the end of the week I'm leaving for a few months and won't be doing any development until I get back.
A Complete:Timeout will occur when a command has been sent but no response has been received before the timeout period has been reached. You can modify that value here:
If you turn up the Log Level you can get a lot of information that may help you validate the cause of the timeouts.
The first half Action - colorApply: until hubitatResponse: Color applied successfully is the initial call to the Tasmota device and the response.
The second half, from the above line to the end is the result of the Tasmota Sync that is generated because of the change in monitored device settings. You can see 4 lines before the end that this has been ignored (normal) because it is inside the Debounce interval.
Hope that helps.
P.S. It handles commands sequentially. So issuing a second command before the first one completes should be avoided.
1 Like
Thanks so much, will delve a bit deeper then. Yes I found the extra log levels (Hubitat has changed a fair bit since I last did debugging on it!!). Timeout seems to be happening even when it's set to 6 seconds, yet the device webpage seems to respond instantly so I figured there was something else going on (also commands are executed very fast when sent from Hubitat, but still get a timeout). Don't worry about investigating on my behalf, was more interested if other people had seen or fixed something similar without me investigating!
Have a great travel!
I’ve not looked at the code but my guess is that it is looking for a specific response for a given command. Perhaps one of the Tasmota responses is different in a newer version of Tasmota? Just a thought.
1 Like
I have in my home automation around 30 Tasmota devices linked mostly to relays, buttons and IR LEDs which I use to control ACs. In current setup they communicate through a simple mqtt broker, allowing single, double and triple taps to control other devices. It works well without a dedicated server, HA or anything. But, as it's very proprietary, it's not easy to maintain.
I bought a HE and tried to use it as a central point for the automation. With Gary's script I could easily integrate HE to the relays and, with some customizations, I added a "thermostat" functionality that enabled me to control the ACs.
However, I've been struggling to make the buttons work properly, controlling other devices. The options I am considering are: 1) keep using the the mqtt broker (that unfortunately I can't run inside HE), and 2) use webqueries on Tasmota and program virtual buttons inside Gary's code... Both options worked on tests, but it's all too complicated! It would be the same nightmare to maintain than the solution I've got now.
Can you enlighten me by telling me something about best practices in managing push buttons connected to Tasmota devices?
Tasmota Sync is really intended to match the state between the device and Hubitat as a low volume high latency legacy solution.
It works OK and it has gained decent acceptance and it does a decent job given the limitations but I’m not adding any new Tasmota devices to my mix because there are cleaner solutions such as Zigbee.
I think Mqtt is probably your best bet to give you speed, performance and manageability.
When I go to create a Power Meter Rule I see all my Sonoff/Tasmota non-power meter devices too.
I am using Sonoff basic devices with version 14.5.0 (release-tasmota) and the "Tasmota Sync - Single Relay/Switch/Plug with PM" driver in Hubitat. Under device the preferences tab it is configured to "Simple Plug. Log ONLY switch events. (Default)". The Sonoff basic devices do not have power metering. Is there a setting or configuration I can use to not have them show up as possible power metering devices when I'm creating power meter rules? Thanks!
The capabilities are defined regardless of any selections within the driver. There is no way to make them conditional. But you could copy the driver and edit out the capabilities that you don’t want to achieve your goal.
1 Like
Hello
This is my problem. I am using tasmota 10.0 with HttpHook from Theo Arends.
It is working really well with my tasmota devices . I have sonoff T1 T2 and T3. The device status updates super fast and the system works well in general ... The only problem I have is that certain devices after an power outage, the device is reset back to a sonoff basic by default. This is not happening with all devices but out of the 40 units I have, at least it happens randomly to 4 or 5 every time there is an outage. Once this happens I need to enter on each device and manually setup the correct device back again.
In the past I tried the native and real time sync from this post , and although it was working really well, the problem is that the status update in my tasmota devices takes 2 or 3 seconds to update. This is ok for lights but not for blinds because I need a quick status update to stop the blinds at the desire position.
Do you know if there is any way to reduce the status time in this release ?
Or if there is a different version I can try that also has httphook?
I have tried building my own version as well with the tasmota 15 and the httphook but unfortunately i have bricked the switch with my custom tasmota.bin . Therefore I do not want to keep trying.
Thanks a lot . Hope you can help me
Just to clarify Theo Arends wrote the Tasmota firmware and Markus Li wrote the HTTPHOOK modification.
Markus is no longer on Hubitat and it has probably been 3-4 years since he was active on here. The HTTPHOOK works well but requires a custom compilation. You can find the last release of his software here if you wanted to try and compile you own version.
I did not like being stuck on version 8.5 of Tasmota so I wrote a Tasmota Driver that uses the native triggers to send information when it changed. Now I can upgrade my Tasmota whenever I want with no special compilations required, the downside is that the response time is about 2-3 seconds.
The reason for that is that when a value changes (off -> on for example) it has to fire a trigger that causes the Tasmota Websend to occur. The minimum delay for a trigger is 1 second, even though the documentation says it is less, it was not true in my testing. This also gives it time to collect any other information that has changed (dimmer, power, color for example) into a single Websend, otherwise it would cause multiples and screw with the driver which only expects 1 response at a time.
There is an option to compile a version of Tasmota that incorporates the Berry scripting engine. I think by using this it could shorten this time, but its just speculation. I'm not sunsetting my Tasmota devices but any devices I'm adding are generally Zigbee if I have any choice in the matter.
1 Like
Hi @garyjmilne,
I'm using your solution and it has been working fine.
BTW, congrats for the solution to connect Tasmota devices (mine is a Sonoff IFan04) - sometimes the best solution (cost x benefit) is not the complicated or sophisticated one, but solutions like yours: elegant! Beauty is in the details! 
I'd like to ask you what exactly the message "Tasmota Sync request debounced. Exiting." means. I can see that it's connect with the "Debounce Interval for Tasmota Sync" parameter (set at the 7000 ms default value). However, since I've been getting this message for each command (see log below), I don't know if something is wrong with my installation or not.
Notes:
- Dev:2 is a device using the "Tasmota Sync - Fan" driver (Tasmota Sync Fan Driver with Switch version 1.0.2)
- The Tasmota Sync Broadcaster version in use is 1.1.4
Thank you in advance!
That is normal. If you are curious why I think you'll find an explanation in the docs. It has to do with ignoring the immediate response from Tasmota and waiting for the rule to fire as the definitive indicator of success or failure.
I missed the docs totally ...
Yep, it is there!
Thanks!!!!
1 Like
Any suggestions? Tasmota Sync works fine on the primary parent device (both switches work in the parent but only show up as a single device in the dashboard using Hub Mesh so need 2 child devices).
However, if it has child devices (dual GPO) the child devices (work fine on the primary hubitat) are disabled on Hub Sync hubitat. It says (Hub Mesh Disabled - true) on the Commands tab on the shared hubitat. It you enable this child it works for a second then goes back to disabled.
If I use Markus’ old Tasmota Device Manager the Child devices work on the shared hubitat but it is hard to get them to refresh their state.
Any tips?
