Is there a universal poller app like the Z-Wave Poller that could be used for wifi switches? I can't seem to find one.
I have 2 smart switches being used to turn on one light. One is connected directly and the other is just used to virtually turn on/the first switch. This works as general rules using a dashboard but as the switches are really slow to update it does not work physically. It only updates if you click Refresh.
Should work with a poller like the z-wave poller.
May I ask what switches are involved? They wouldn't be GE/Jasco?
No they are wifi switches using the Tasmota driver from Oh La Labs. The newer Tasmota driver works but often has errors in the dashboard so went back to the Oh La Labs driver.
But they don't update their state if you manually switch them on or off. You have to click refresh in the app to get them to update their current state.
Sorry, I should have read your first post better.
Is poll() implemented in that driver?
If it is, just setup a periodic rule that polls at the frequency you want (whilst being aware that polling too many devices or too often can bring a hub down to its knees - especially if the switches are offline).
If it were me, I would flash a newer version of Tasmota on the switches, and use the new Tasmota integration from @garyjmilne
Agreed there.
In the meantime, you dont even need the "poll" command on the driver, it can just be refresh. You can setup a simple RM on a periodic schedule to call a poll (or refresh if no poll) on the devices. No special apps needed.
Will give this a try.
The are actually ex-Tuya devices that have Beken chips and have been flashed with OpenBeken. They just so happen to work with the Tasmota Driver. However, they work better with the old driver than the newer @garyjmilne driver.
Have you considered using Home Assistant with Home Assistant Device Bridge (HADB) to bring them into Hubitat? Or using an MQTT broker and one of the many MQTT clients for Hubitat?
Both these approaches will work very very reliably with no need for polling/refreshing.
My driver gives people a chance to move forward with stock Tasmota vs running an old custom compilation. It works, but what it does not do well is rapid cycling. Under typical conditions it takes several seconds from the time the Hubitat command is sent for it to be acted upon, generate a sync packet, send it back to Hubitat and then process it to make sure things are in sync. In my experience this is 1-2 seconds at my house but it can be longer, with the main determinant being the quality of the WiFi signal.
If you are happier with the Oh La Labs driver then I'd recommend you stick with it. If you do see compelling value in a future Tasmota version you will have the option to mix or switch in the future.
P.S. I Assume you tested my driver using Tasmota 11 or later?
Sadly your driver, while better with actual Tasmota flashed devices, is not as good with OpenBeken flashed devices. It may be something minor that can be edited and then we are good to go but I haven't had time yet to look at what it is.
I myself run HA but this is set up for a non-tech friend and they only have a Hubitat (that I got them) and a ST hub. They had a mishmash of crap that they had bought from all over and I have helped streamline it for them. It is mostly all ok now except for a few Tuya devices left like ceiling fans most of everthing else was able to be got rid of or flashed with OpenBeken,
Sorry, I missed the significance of this in your OP. Had not heard of it before.
All good, MQTT should solve the problems.
I'm just glad that OpenBeken works with both Tasmota drivers in HE.
No OpenBeken drivers that work in Smartthings.
I started on SmartThings and I wrote a really good Tasmota driver in Groovy back before they purged all the groovy stuff. That was why I ended up over here as I knew most of my stuff would work.
I ended up just using RM as it was easier. It is random which OpenBeken switches work or dont in HE with your driver. In fact, I can set up the same switch on 2 different HE hubs and the switch will be fine on one and not the other.
For clarity, the switch actually works it is just when you add it to a dashboard it comes up with a ?. In the actual devices tab list it works. The old Universal driver seems to work with all OpenBeken flashed chips. But these all need to be added to RM to refresh their state if turned on mechanically by the actual switch.
Strange, the dashboard only knows about the device definitions (not the physical devices). As long as those are the same I'd expect them to behave the same.
Agreed, the only way it should show a ? on the DB is if you pick the wrong template for the dashboard tile. It would need to be set to "Switch" for a standard switch. Then as long as the device has the "switch" attribute populated with a value it would show on the dashboard properly.
Should and Does are 2 entirely different things.
To clarify, these are not Tasmota switches they are Beken flashed switches. While similar they are not the same. So it is just fortuitous that they work at all. Also the same Beken switch, with the exact same settings, works on a C4 but not 100% on a C7 and comes up with the ? in the HE dashboard. Put in Maker API they will work with HD+.
I will have to do some more investigation to see if it is related to the chip ie if it is just a BK7231T or BK7231N based chip.
Ok I mis-spoke, the word should was incorrect because it is a fact. The only way it WILL show a ? on the DB is if you pick the wrong template for the dashboard tile
That has nothing to do at all with how they show up on the dashboard. The only thing that matters is the template selected and the attributes on the device.
Sometimes when you have the dashboard self-populate tiles it can pick the wrong template for a device if it has extra attributes defined.
Working Example:
Now if I set the template wrong on purpose:
It seems the problem only exists with multi gang switches, something to do with the implementation and population of child devices. It has been coming up with * useChildDevices : false even though they had been populated and worked in the parent device.
After deleting and recreating child devices a few times I now have * useChildDevices : true and they are working.
I will see if that has fixed it or if child devices come back up at some stage as false again.
Download the Hubitat app
