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
