I have a Virtual Switch, and on my laptop is a script that hits the Maker API for this VS every 30s -- the /on endpoint if my laptop is connected to ethernet, and /off endpoint if disconnected.
If I close my laptop before disconnecting the ethernet cable, the VS will remain "on" without subsequent updates via the API. The best fix for this is probably to find a way to add some sort of "on-sleep" hook to my laptop's script.
However in the meantime, I figured I could just implement an auto-off in Hubitat with a timeout of ~2 min; and as discussed in this post, doing this without a custom driver means using a rule. I'm struggling to figure out how to have the VS auto-off only 2m after the last "event" (= last API endpoint hit), as opposed to the last state change, i.e. reset the 2m counter even if the "on" command was run while switch was already on.
The Event names shown in the device details seem to be "command-on" and "command-off" when the /on and /off endpoints are hit when already in those respective states, and "switch" when the endpoint hit results in a state change. And while I do see a way to use "Time Since Event: Any Attribute" as a condition in Rule Machine, I don't see in Trigger options a way to use these command events, or to use Maker API activity events.
Currently I'm doing the following in my automations as a workaround:
Not sure what automations you're using this for, but you can solve the general problem with a second virtual switch. Have the MakerAPI-controlled switch turn off quickly (say, 1s). Then one RM rule to turn on the second virtual switch when the first one turns on, and another RM rule to turn it off only when the first switch turns off "and stays off for 2 minutes". The second switch would be used in your automations.
And just wondering, is there any particular reason why the built-in Virtual Switch driver's "enable auto off" wasn't made to accept arbitrary values in seconds or millis?
I don't know, but come to think of it, you could use a virtual button instead, that will send an event on every command.
You could even have both the belt and the suspenders. Have the "Ethernet Connection" virtual switch controlled directly by your laptop when it comes on/off, AND have the heartbeat virtual button commanded every 30s while the laptop is on.
As you can see, there are many ways to design for your requirement.
If I recall correctly, years ago we asked the Hubitat Dev team to add an auto-off feature to the Virtual Switch in order to allow it to be used within an Amazon Alexa Routine as a trigger for a Rule Machine Rule (or similar app) on the Hubitat platform. By automatically resetting back to the "off" state, the device would be ready again for another 'trigger' from an Alexa Routine. Thus, there was no need for a very extended automatic off time within the virtual switch device.
It appears what you want is a sort of Watchdog between your PC and HE Hub. Another possible option would be to have the HE Hub simply Ping your PC (make sure the PC always uses the same IP address via a DHCP Reservation in your router, or by using a true Static IP Address on the PC) and use the results to set the state of a Virtual Switch which would indicate whether or not the PC is on. This removes the need for any code on the PC as well as the Maker API instance on the HE hub. You can probably find other examples of this technique by searching through the previous forum posts.
Sure, the HE->PC ping method would of course work if I only wanted to check if my PC was online on the network at all.
The point of this is I need to check whether it's connected via a specific interface, which is why I have a bash script on the PC that checks that and then pings HE Hub.
That's a fair point, there can also be the consideration that you want to decentralise the check... but that's another point... Ultimately checking the specific connection method is a reasonable one...
I would think it's generally better to avoid (constant) polling from the hub to device(s) and more scalable to have devices report their status (which status report can be made to be richer than simply "the ICMP layer is still active").
