Summary
The cycleSpeed() function operates normally when clicking on it in the Device UI but acts differently when called from ABC or RM via button press. Commands are issued twice and the fan speed increases in 2 increments instead of 1.
Goal
I’m trying to use a scene controller to control a fan unit (Sonoff iFan04). My goal is to have repeated presses of a button cycle through the various speeds. This is the log output under different scenarios.
Device UI: cycleSpeed() function run clicking on cycleSpeed button in devices UI starting at off.
Speed goes from off to 1.
Scene Controller Button: cycleSpeed() function run by actually clicking button 2 on the scene controller starting at off.
Speed goes from off to 1 and then 1 to 2. Note this method causes 2 sendCommand statements.
Using Rule Machine
The same result is generated when using RM with rules. This avoids all use of the cycleSpeed() function as it attempts to set a specific speed.
A little more info. I’ve replicated this issue with two different Tasmota drivers, one from Markus Li and the other from Damondins. My platform version is 2.3.1.128 but this problem existed before the latest upgrade.
I know that I could work around it programmatically but wanted to see if there was any insight as to why this might be happening and if anything could be done about it. I’d rather have it work as expected and not need to do a workaround if possible.
Looks at the Device Details page for your button device, and click on the EVENTS link to see if the device is Issuing duplicate events. It sure sounds like it is to me.
The device does issue dual events when called via the scene controller button press, but not when using any of the WebUI buttons to initiate it. I would expect it to work the same in all scenarios.
Oh, and the scene controller log shows only a single button press.
Well then, that’s the issue that would need to be resolved. The Apps are simply reacting to both events.
What is the specific make and model of the scene controller? If using a built-in Hubitat driver for the scene controller, you may want to reach out to @bcopeland for Z-Wave devices, or @mike.maxwell for Zigbee devices.
Thanks for the pointers. It had not occurred to me that the physical button device might issue two events for each button press. On a switch that would not matter (On and then On again) but on a toggle or a fan cycleSpeed() you are going to notice that it's wonky. The device is 4 button Moes Zigbee Scene Controller The device looks like this and is quite a nice size and build quality is good if it can be made to work fully. I got mine on Amazon for $20.
I have tried both the built in Tuya Zigbee Scene Switch driver and the user Tuya Scene Switch TS004F and they both have the same problem of generating two events.
This is the internal info.
This link had a lot of info referencing _TZ3000_abci1hiu that might be useful if someone is attempting to update a driver.
Per your recommendation I am tagging @mike.maxwell and @kkossev who wrote the Tuya Scene Switch TS400F driver. P.S. In the latter case I did play around with the debounce variable but without getting predictable results.
I hope someone can help as it's a nice device, about 4" x 1.25" x 0.5" and could provide a lot of flexibility if this issue can be resolved. It's still useful but it would be great to do repeated button presses to cycle through a list of options like fan speed, brightness, volume or scenes.
The best approach in my opinion is that if Mike agrees and you send him this remote for checking and solving the core reason of the problem.
My driver was written for Tuya devices that are identified as TS004F model and it was not intended to handle TS0044 scene switches, that are supported from the inbuilt 'Tuya Zigbee Scene Switch', which works perfectly with TS0044 devices that were on the market....until this MOES remote.
TS004F driver 'debouncing' code is more of a workaround, rather than a solution of the problem with the duplicated packets that are send from some scene switches or remote controllers. As HE does not expose the sequential numbers of the packets on drivers level, the filtering is based on a time frame in which one and the same key press event is considered as duplicated. But even if the sequential numbers were available and were used for the same purpose, it would still remain a workaround. A permanent solution could be related to a change of HE Default Responses to some Zigbee commands (discussed here) - something that is above my Zigbee low-level protocol knowledge skills...
Anyway, you could try this test version of the TS004F driver, I have included your device fingerprint and have also included it in the 'debouncing' workaround logic. After switching to this test driver code, you will need to re-pair it again to HE hub. Please let me know if there is any change.
I just tried it out and it works just fine, only getting a single event on a button push now. Have not tried the double click or the long press yet but I will do that when I get a chance later and let you know. It's a nice little device, I'm sure I'll get another.
Thank you for taking to the time to make the change and doing it so expeditiously.
I tried the other functions with the button controller.
Single press works (with your new code)
Double click mostly works. On some occasions it would not fire, or sometimes it would fire the single click definition. I tried to be consistent but quite likely due to the speed of my fingers and perhaps some of the de-bounce code. Is this double-click speed determined by the device or by your driver?
Held works with a caveat. The Held time seems to be about 3-4 seconds in practice (manual says 5 seconds). A 6 second hold on Button 1 will put it into pairing mode (manual says 10) as indicated by a flashing LED at which point to have to wait about 20 seconds before you can do anything else and you will have to re-Pair it before it will work again. Not your issue but notable for anyone thinking about buying one of these.
Released I'm not sure I understand how this is differentiated as there is always a release. The manual makes no mention of this mode. I could not get this to work anyway.
Overall it is certainly quite livable as it is. Be a week before this goes into full "production" but I'll get a better sense of the reliability after some real world use. I'll probably try to use mainly the single click and have it cycle through various, speeds, brightnesses, scenes or whatever the situation calls for.
It is the device itself that distinguishes between single and double click and sends the corresponding event. After some more practice, you will probably have a better success rate with the double-clicks, but the risk to generate a single click instead remains. If you have other types of remotes that require other timings for registering double clicks... it becomes ever more inconvinient.
I don't like how 'Held' works as well. Philips Hue and OSRAM remotes user experience is much better,
'Released' events are generated by TS004F devices in 'Dimmer' mode, which is not supported in HE due to being group broadcasts. So in the next update, I will remove the 'Released' type of events for TS0044 remotes to avoid confusion.
I think that actually this is the applications that a scene switch is designed for. Scene switch mode:
On/Off
Singe/Double clicks - Rotate through predefined scenes (slow, typically no faster than 1 change per second!)
Held (actually sent when the button is released after 3-4 seconds!)
Dimmer mode: (not supported in HE)
On/off
Single/Double clicks - rotate scenes
Held - the event is sent quickly when pressed for more than 1.5..2 seconds (while the button is still held)
Released - sent immediately when a previously held button is depressed.
So the Dimmer mode of TS004F remotes (not your model, TS0044 seems to be only a scene switch) is what would be ideal for smoothly ramping up/down bulbs brightness or color temperature or volume, etc.. I was able to test it with the Tuya gateway, but also with my old SmartThings V3 hub where the group broadcasts are received and available in the drivers.
OSRAM remotes (both 3 keys and 4 keys models) work very well as dimmers (I ramp up/down bulbs groups through CoCoHue integration), but these are a bit difficult to find nowadays.
I will create a dedicated new tread on TS004F devices, as now all the information is spread is several different topics.
Hey, I've been setting up some scene switching using the Moes. Mostly it works and it looks like this in the logs. But sometimes (maybe 1 in 5/10) it does what it does at the top of the log. Reports the button push but no mention of the debounce. Furthermore the remote becomes non-responsive, a subsequent button press does nothing right away. Then a few seconds later it will free up and start working again.
Does that sound like a hardware or driver issue to you?
After a bit more study I was able to determine that their is an issue with the driver. What is happening is that sometimes the state.LastButtonNumber is getting stuck at 1 even after the timeout. When that happens it then ignores the next button press (considers it the dup) and then the actual dup button press gets treated like the real thing.
What I suspect is happening as I've run into this before is that it is caused by caching of state variables. When you write a state variable and then almost immediately read it back there is no guarantee that you will actually get the most recent value. In apps you can guarantee it by using Atomic state but not in drivers.
However I do think this link has an approach will resolve the problem. Basically, the driver waits until the end of the debounce period and then only submits a single event, no matter how many events are received.
The only disadvantage is that the button press is delayed until the debounce period ends so it reduces the responsiveness of the system, but that is a small price for stability when the response is sub second.
Hey @garyjmilne , many thanks for your feedback and analysis of the problem!
I will review the logic carefully tomorrow morning when on a fresh mind ..
This was probably the first driver that I wrote for Hubitat platform, and what I remember is that after I discovered the magic sequence that switches the TS004F into Scene mode, I wrote the debouncing code very quickly in a hurry to publish the driver that the others can test and confirm it is working.
The thing is the logic looks just fine until you realize that writing and reading back state variables does not always give you the results you think you should get. I wrote a couple of drivers on ST so I have a little experience if I can help. I don't know anything about the whole fingerprints stuff though.
Oh, I did mean to mention that moving the debounce time to the settings would be a helpful improvement. If you wanted to go a little further you could add the ability to measure the interval between button press events and display it so that someone could get a better estimate of a good period for their particular device.
OK, I understand what you mean about the possible issue of flushing the state variables, and now I remember that in all my later drivers I have added :
singleThreaded: true
in the definition section. But this early driver is missing it !
Can you add the above option and see if it makes any difference?
P.S. I have also updated the code in the test branch from the link above
That is interesting, the singleThreaded option did not exist back when I was writing drivers for ST. I was sure that would fix it, but alas that is not the problem. There are still times when the lastButtonNumber sticks at 1 and remains that way until there is another button press. Which, per the logic, gets ignored.
However, with the single thread option it would be easy to write a state variable that would be the time at which the debounce timeout "expires" and resets the lastButtonNumber to 0.
I'd like to get my remote working for a project this weekend. So if you don't get to it I will take a look and try to get it going. I know it's hard for you to test without the actual device.
I have now at least 2-3 ideas on how to prove (or I think that it is much more likely - to deny!) the hypothesis that the state variable value is not always updated.
I've found a bug, at line #157 the debouncing timer (which zeroes the lastButtonNumber) was not started for your device type, but only for TS004F models!
That seemed to do the trick. As you can see from the attached picture that I can have over a second gap between my duplicate zigbee events so it did not work for me at the default value. But I bumped it to 1200 and now it works.
FYI. My RSSI is poor because the remote is normally on the other end of the house. Perhaps the repeat zigbee events generated by the remote are related in part to the poor RSSI\LQI. I'll do one more post on this thread once I have a little more experience with it and the remote is back where it is supposed to be.
Thanks for all of your help. It has peaked my curiosity about understanding the Zigbee protocol so I ordered an Xbee to dig into it more. Your driver helped me understand the zigbee cluster gobbledygook as I'd never really studied a Zigbee driver before in any detail.
