Yeah that makes sense why it takes longer to process the commands compared to other integrations. The local control I am looking into does not require Tasmota flashing, there is local Tuya control but I cannot find very good docs about it.
Not sure if this is normal or contributing to the problem? I have not looked at the code yet to see why this happens, maybe it is just something with my device. But every time it refreshes I get multiple repeating log entries, I believe it is 6 every time. So if you have 25 devices and its doing some sort of processing x6 that would add up quick.
Yes that does look abnormal, I don't see that with my lights so I'd need to get a little more debugging detail to see the messages being received that is causing this behavior. Should only see one of those not six.
And here is current with ONE refresh (I left out the API calls at the bottom and blacked out some private looking stuff). Even going two screens tall it was too much to get in one shot, it keeps going off the top.
Thank you, took a while but I tracked down the issue which was introduced when I added support for multiple child devices per tuya device. I've posted a fix in the latest development branch code if you would like to try it.
Looks like that did the trick for the repeating events. Still does not do anything with the brightness/level but I mostly just use it for on/off anyway.
I see you have some local non-Tasmota Tuya drivers in there also. Might have to check out the RGB one and see how it works on my light strip. Or at least it might help me decode the dps "colour" string for Node-Red.
I just fixed what I think was causing the brightness level issue. As for scenes, I've not yet seen a way to set a scene number in the API otherwise I could add that.
Still not working for the level. If you dont have any devices that support it, I will try and check it out since I can test various things until it works. Also trying to use setLevel command from the device generated this error:
I'm going to try removing all the tuya devices and just use the Tap to run automations. I can get by with that. Otherwise i'll have my IT brother in law take a look. i suspect i might be having issues with static vs dynamic ip adresses.
Ah, that was helpful, turns out yet another device with a different value. That now makes the supported functions to now be: 'bright', 'bright_value', 'bright_value_v2', 'bright_value_1' Lets see if that gets us closer!
Hi Jonathan, maybe it's not an attribute, but a capability. I mean I can change the alarm type. This siren has 18 types of alarms. But I'm very grateful my siren is working.
@putudhony88@jonathanb I can propose you to wait a couple of days, as I have already started working on a Zigbee driver that should allow direct local control of this device.
If this attempt fails by any reason, the cloud solution will be a saver! : )
@putudhony88 it will be interesting if you can now compare how fast the siren switches on/off when controlled locally vs Tuya Cloud? Can you notice any difference?
My observations based on some other devices is that practically there is no noticeable difference in regards to the control speed when using the Tuya Cloud, at least with the Tuya cloud server that I am connected to (probably hosted in Europe).
Lets see if that gets us closer!
