I couldn't explain that. I don't have google home to test with.
Functionality wise having both switch and light capabilities shouldn't have any harmful effects IMO.
Yes, at least not in Hubitat, it is more an integration issue, and that I find very hard to keep track of, especially since I don't integrate with any cloud services... They don't work very well here in China anyway...
1 Like
My RGB driver only has Light and ColorControl now.. I completely removed the switch capability since its not a switch at all.
Ok, I have removed switch from mine as well. I have ColorControl, ColorTemperature and SwitchLevel on top of that, since it is supposed to handle the RGB+CW+WW as well...
1 Like
Perfect. This is what I use in my RGBW driver
capability "Actuator"
capability "Sensor"
capability "Refresh" // refresh command
capability "SwitchLevel"
capability "Polling"
capability "PowerMeter"
capability "ChangeLevel"
capability "Light"
capability "LightEffects"
capability "ColorControl"I'll add the Light Effects once I implement support for that... I also don't have ChangeLevel implemented. Before adding that, mine now looks like this:
capability "Actuator"
capability "Light"
capability "ColorControl"
capability "ColorTemperature"
capability "SwitchLevel"// Default Capabilities
capability "Refresh"
capability "Configuration"
capability "HealthCheck"
I have updated all drivers and uploaded them to my dev-hub, so will update my git now... Github is updated with this change.
Is this really needed in HE ? I thought Mike said is does nothing.
1 Like
I use the ping command, I guess I could add that as a command, but I used HealthCheck. Not sure if it is used apart from that. From what I've read, it is not used.
EDIT: Hmm, checking, I did use it, now it just goes to refresh anyway... So could remove it.
HealthCheck is a ST nuttiness
1 Like
Since HealthCheck and Ping only existed in shared code, it was easy to remove and all drivers will be without it in a few minutes, just waiting for them to be sent to the hub before committing to git. Thank you for your pointers, I'm still new here, long-time coder, new Hubitat user... Not caught up on everything in the forum, would be nice with documentation distilling all of these things in one place...
1 Like
I used to have my code in the open for anyone but I changed that when people started stealing it and removing my credits to pretend they wrote it and then posting here for help when they broke the code they stole.
A couple of my drivers started with 20 lines of code. Now it's nearly 1000 lines.
1 Like
I understand, that is not ok, I started this project with code from @ericm, it has now morphed and only the App is still resembling what he wrote. I do give him all the creds I can, which is the correct and proper way. I do wish everyone could do the same. Anyone using my code to edit by hand will have a fun time... And to get the python-environment which builds by drivers to play ball you would need to know quite a lot anyway, and would probably not bother to steal code that way... We'll see, if the community behaves I'll leave it in the open, I really hope I can keep it open.
They do grow these drivers... Not sure what impact it has on performance since metrics are hard/impossible to come by. I want timeIt()...
If I had an enormous amount of time I'd like to build a test-suit with fake devices (zigbee/z-wave and wifi) controlled by a server pushing buttons, triggering motion etc... All in software and connected to a HE just used for tests... Don't see how I would ever justify the time needed for that though.
1 Like
That doesn't sounds likely, but you could try with the generic plug/switch driver to find out. Or just remove the sensor capabilities from the TH driver.
I doubt it.
The Driver I am using is tasmota-generic-pm-plug-parent-expanded with tasmota-generic-pm-plug-child-expanded with 2 power strips, one with 4 UK power sockets and one bank of USB's and the other with 3 UK sockets and one bank of USB's. So I have two parent drivers, one with 4 children the other with 5 children.
Currently Alexa see's them as switches and you can change them to be lights. But even if they are set to switches and are grouped into them room where they are, if you say "Alexa, Lights off" all the switches also go off. This did not happen when they had the Tuya firmware.
As I am only using them as switches (with the option in Alexa to toggle them to lights) and they have no power monitoring capability etc, what is the minimum capabilites I need to make them act just as switches.
Which Hubitat driver did you use with the Tuya firmware? Or did you not use them with Hubitat then?
Did not use them in HE when they were on Tuya Firmware, they were integrated into Alexa with the Smartlife skill.
Wanted to get local control hence the move to your firmware once I got HE.
I believe this might be a Hubitat integration issue:
Do search some more about this in the forum, I'm rather new and have not followed these topics, I've probably missed something important. If you find anything pointing at there being something I can do in the driver I will fix it. As it is, I don't know what else to do, I did update the capabilities according to recommendations today, so have a look at trying those.
I am at work at the moment, when I get back home this evening I will try the new driver with the updated capabilities.
But I do not think it is a HE issue as I have another room where I have lights and a smartthings plug/switch all integrated into Alexa and HE and when I say "alexa, turn on lights" in that room only the lights turn on and not the switch.
