Thanks @garyjmilne. I will try it out as soon as you have the code ready for me. BTW, I found a work around as well. I could access all the plugs using Webcore. It works great! But for some reason Rule Machine could only see one plug.
I switched all my 30+ Smart life devices to Tasmota using the soft firmware hack couple of years before. I knew that vulnerability will be patched and so I bought more devices and switched them all to Tasmota. I don't believe new devices can be hacked using that method anymore. I haven't tried yet. Tuya local is now an another option.
It was a lot easier back in the day when you could install Tasmota OTA. There are some manufacturers that make devices with Tasmota pre-installed and a few that can be opened and flashed over serial. With 30+ Tasmota devices you should take a look at the Tasmota Broadcaster which is an option available when you install the Tasmota Sync drivers. It let's you send commands to multiple devices at the same time. Great for standardizing things or initiating upgrades. There is a little helper that lists many useful commands or you can type your own.
I might make some time to simplify the 1/2/4/8 versions of the driver to a single copy, as it would be easier to maintain with a single version and should be possible to work with a selector for the user to pick.
Did you manage to find the bits I meant? I'm still not near a proper computer so can't easily reference them better.
The switch on child1 is interesting. All of the other children update if controlled from the child itself, but child 1 doesn't. I suspect it's something to do with single relay devices and POWER/POWER1 or similar, but editing source code on a phone here to find it will break my brain.
Yes, I found all those and took care of them I believe. I also found and fixed the issue with POWER\POWER1. Attributes switch and switch1 are kept synonymous in the original code. I had to make a change to account for the child driver in this instance.
Thanks @garyjmilne for the quick turnaround. I installed the latest driver code from the [link] provided. I didn't change the plug count from 8 to 5. I recreated the device using the new driver code. Added the power bar to the dashboard (can't see other plugs). I picked the "switch" template for the powerbar. I still cannot control the other plugs. Rule Machine still couldn't see the other plugs as well. Is there anything I should do?
Do you have a dual device to test on? I have an 8 port but I can't use it right now as it's tied to my irrigation system and I might have unintended consequences if I power it up.
The good news is it does work. The bad news is I don't know why yours is not working.
P.S. The switches also show up as actionable in Rule Machine.
Sorry I don't have a dual power bar. I have a 4 plug power bar and a 4+1(USB) power bar. Both power bars on Tasmota 12.4 have the same issue. Is there any setting I should change on Tasmota for habitat?
I don't want to waste too much of your time. It is working for me with Webcore. I will try if you have a new device driver. thanks again
@cjcharles
Could we wrap this inside a test that determines whether or not child devices have been created. For example set a state value on createChild and remove it on deleteChild?
Or maybe I should just convert the log.debug to my logging structure so they can be turned off as it's going to be a very common error.
Open to your thoughts on this.
//Now find and update the child
def childName = device.deviceNetworkId+"-ep"+ep
def curdevice = null
try
{
// Got a zone status so first try to find the correct child device
curdevice = getChildDevices()?.find { it.deviceNetworkId == childName }
}
catch (e)
{
log.debug "Failed to find child " + childName + " - exception ${e}"
}
if (curdevice == null)
{
log.debug "Failed to find child called " + childName + " - exception ${e}"
}
else
{
curdevice?.sendEvent(name: "switch", value: status)
}
Yes, sorry I mostly wrote this for my benefit originally, and I was never going to 'not create child devices' so never saw this...!
Id agree that converting to your logging rules is probably more efficient than setting a parameter and constantly checking it, hence just make it the highest level of debug and for most people it would never show.
To better handle the distinction between when it is using child devices and when it is using the parent I added a state flag called "useChildDevices" that is set to true when you click on childrenCreate and set to false when you click on childrenDelete.
IF YOU ALREADY HAVE THE CHILD DEVICES CREATED AND DON"T WANT TO DELETE THEM JUST CLICK ON THE "Children Create" AND IT WILL SET THE FLAG. Not an issue for new installs.
I also converted over the logging messages to use my info logging model for consistency in the display of logging info.
I thought I responded to this yesterday but must not have.
What is the value of the state variable useChildDevices?
Are you using child devices?
What is your logging level?
