I'm working on a device driver for the Rollease Acmeda Automate Hub V2 and got the driver working for a single shade motor via Telnet. But the problem with this hub is that it only allows a single Telnet connection, meaning that all motor devices have to share the same Telnet connection.
Is there a way in Hubitat to share the same Telnet connection among different devices, or maybe a way to tell Hubitat not to initiate a new connection if one already exists for the same IP/Port?
If this is not possible, I guess I may have to venture into using Parent/Child devices, where the parent establishes the Telnet connection, which is then used by the child devices.
This is my first Hubitat driver, so any pointers would be appreciated.
You'll want to do what Hubitat does with the Lutron hub. You create a Telnet device and then individual devices after that. All the communication with the other system goes through the tenet device and then the messages get parsed out to the other devices. This is easiest to do if you have a service manager app over top of everything acting as traffic cop to direct the messages since devices can only talk to each other if there is a parent/child relationship.
Which is another possibility if you're not talking a TON of devices but only a few. The parent does the talking and the children hold the state of the devices connected to the other system. Look at the Hubduino project if you want a model to work from.
I use this Wyze Sense integration that is Telnet and I have that running along with Lutron Hub integration. The developer might be able to give you some pointers.
If you go for a stand-alone Telnet driver shared by several apps using events then do be aware that every event is logged by HE and this contributes to the log and database sizes and the backup and in particular cleanup times. With heavy Telnet traffic this is problematic.
My MQTT app worked this way to share the broker but with the imminent v2.2.0 firmware and lots of events it caused the hub backup issues, taking over 7 hours for cleanup to run !
So the next version of the MQTT app (beta3) has reverted to parent child.. which hopefully alleviates this but connections can’t be shared anymore.
Parent/child is fine, as are several apps all using the same driver if traffic is reasonable/low. It’s just events are logged and backed up but child/parent and parent/child calls aren’t.
You didn't answer my question....parent app with child devices or a parent device with child devices?
There is a difference. A parent device with child devices will list all of the child devices under that parent device on the full device list. So they will not be sorted alphabetically with the rest of the devices. Child devices from an app will file like normal on the device listing. That's the method the Lutron integration uses. One device for the communication, the parent app simply directs the messages to the correct driver. (no body said anything about many apps) and then each driver parses their own messages to figure out what to do.
With something like MQTT, are you really going to want to have all your devices listed as children of one device?
Thanks everyone for the great suggestions! Looks like parent/child structure is the way to go. I got it working using parent/child devices but as @Ryan780 pointed, this forces all the child devices to be listed under the parent device in the device list which is not always ideal.
I will look into using a parent App instead to see if that makes more sense.
Just to confirm there's no way to invoke a custom command of an arbitrary device from within a driver, is there? (Without the devices having a parent-child relationship)
Then why does the Lutron integration use this method? I don't understand why it's a good idea for Hubitat to do it but not for us. Or are you saying that the Lutron integration isn't efficent?
My guess is because Hubitat's Lutron Integration was developed long before Hubitat supported Composite Device Drivers. I personally prefer using Composite (Parent/Child) device drivers as I feel it is simpler. When I ported ST_Anything originally to Hubitat, I had a Parent App, and Driver to communication to the Ardhino, and Drivers for each Child Device. After Hubitat released support for Composite Devices, I eliminated the Parent App which simplified things, IMHO.
I would agree with this statement though point out that with the Lutron integration usability with setting up the child devices wouldn’t be as intuitive if using a composite device. The app makes it easier to prompt for data such as device type, ID, name, etc. That is probably why it continues to use the “old” structure.
The parent app creates a child device (a hub if you will), which creates child devices as instructed from the parent app.
The hub device contains all the code to talk to the physical and child devices.
The app just functions as an interface to instruct the hub driver regarding which and how many children to create, once that step is completed the app is no longer used.
The decision of whether to use an app or not being driven by the needed ui complexity...
