The app I have been working on is close to being done.
Currently I have a virtual switch as part of the app which I use to open and close the telnet connection for testing.
It would seem to actually deploy the app I want it to be up and running whenever the hub is up and running.
How do I make it work that way.
In the same way how to I close the connection when the hub is shutting down, restarting, etc.
Thanks, Frederick
To turn it on, you can use the trigger of "Location Event: systemStart" in a rule. However, I don't see a similar option for shut down, so others will have to chime in to give you the other half of your answer.
If you can't find a way to turn the switch off at system shut down and it's not a huge deal to not formally close the connection, I would just use the systemstart trigger above and have the actions be to turn the switch off, then back on again with a short delay.
Will be interested to see if the more knowledgeable folks here have other suggestions.
Thanks.
I'm new to Hubitat and am still learning.
Really enjoying myself and the folks here seem great.
Frederick
Typically, a driver would handle all of the Telnet connection, disconnection, and reconnection logic.
If you add the following capability to your driver, and also implement the initialize() function, the hub will call your device's initialize routine when the hub starts up.
capability "Initialize"
Inside initialize(), I typically perform any one time activities needed to establish the connection to the device, be it a webSocket connection, a Telnet connection, etc...
Thanks, that is good to know.
I tried working with the rules app, which the other person mentioned, and that was interesting.
I saw I could turn on/off the existing virtual switches, that are part of the app, which I have been using for testing.
You mentioned using the Initialize capability and that the system would call the method of that name, assuming I created it.
Can the rules engine call methods in the app?
Thanks, Frederick
It is important to note the difference in a Hubitat "App" versus a Hubitat "Driver", as it will help to make sure we're all clear with exactly what is being asked.
An "App" can subscribe to 'events' that are generated by Devices (which use drivers), as well as platform events. Apps can also call commands that are implemented in device drivers.
Drivers cannot make calls into apps, except in the special case of a Parent App that has created Child devices. One can also create a Parent Device Driver, that creates child devices.
Rule Machine is a Hubitat provided "App". Apps cannot make calls into other applications. They can only make calls to a device's set of commands.
Hubitat uses the concept of a set of Standard Capabilities for its device drivers. By adding a capability to a driver, the developer is expected to implement that capability's list of Attributes and Commands. In doing so, an "App" can rest assured that if a device advertises itself as having a certain set of capabilities, that it can subscribe to the events generated whenever that device's standard Attributes are changed as well as know what commands that it can call on that device.
For example, if a driver implements the "Switch" capability, it is expected to provide the following attribute and pair of commands.
Perhaps the driver is not just for a simple on/off switch, but also is capable of providing dimming functionality. By adding the "SwitchLevel" capability, the driver will also need to implement the following additional attribute and command.
So, now we have a dimmable switch.
But what if we want to perform some special standard default configuration on this special, custom dimmable switch device each time the Hub starts up? We can simply implement the Initialize capability as well, and add the custom config code to the "initialize()" routine.
And so on, and so on.
The Telnet capability requires the driver to implement the following attribute and command.
Telnet also requires the developer to make certain calls to establish a connection (telnetConnect()), handle incoming data (parse()), and implement the telnetStatus() routine so the hub can let the driver know when the connection is dropped. This provides a mechanism for the developer to implement automatic reconnect logic.
https://docs2.hubitat.com/developer/interfaces/telnet-interface
Hopefully this helps a little in learning the platform architecture. Lots more information available in the Hubitat Developer Docs.
Thank you very much. That was most informative.
Frederick
Download the Hubitat app
