Do I need a custom driver to do equivalent of netcat (nc) when virtual switch changes state?

It would be a pretty simple driver and similar to one I've done previously. But, it's been a couple of years and thought I'd ask if there was a simpler way.

Just need to send a message to a specified ip and port when the virtual switch changes.

The Maker API app can be used to post device events to an endpoint (the receiving end will need to handle the event format).
Details about this feature and the event format can be found here:

2 Likes

Thanks!

I'll check it out.

Having trouble getting it to work.

Do I specify port by suffixing it in the URL like this?

That’s not a URL. You need something that can accept an HTTP POST listening at the other end.

Why do you say it's not a URL?

I have a one line http server at that URL. It echoes posts I do using postman

PORT=1234 http-echo-server

If you have something listening, then try:

http://ip_address:port_number

Here's what the echo server reports when I do a POST to 192.168.0.222:1234 using postman:

pi@rpi-magic2:~ $ PORT=1234 http-echo-server
[server] event: listening (port: 1234)
[server] event: connection (socket#1)
[socket#1] event: resume
[socket#1] event: data
--> POST / HTTP/1.1
--> User-Agent: PostmanRuntime/7.26.8
--> Accept: */*
--> Cache-Control: no-cache
--> Postman-Token: e44941d1-21d9-4d82-8005-f2b11a38ff50
--> Host: 192.168.0.222:1234
--> Accept-Encoding: gzip, deflate, br
--> Connection: keep-alive
--> Content-Length: 0
-->
-->
[socket#1] event: prefinish
[socket#1] event: finish
[socket#1] event: readable
[socket#1] event: end
[socket#1] event: close
[server] event: connection (socket#2)
[socket#2] event: resume
[socket#2] event: data
--> POST / HTTP/1.1
--> User-Agent: PostmanRuntime/7.26.8
--> Accept: */*
--> Cache-Control: no-cache
--> Postman-Token: 3c7688e2-e072-46f7-8e73-37707dff1c04
--> Host: 192.168.0.222:1234
--> Accept-Encoding: gzip, deflate, br
--> Connection: keep-alive
--> Content-Length: 0
-->
-->
[socket#2] event: prefinish
[socket#2] event: finish
[socket#2] event: readable
[socket#2] event: end
[socket#2] event: close

That worked (adding the http;//).

Thanks!

2 Likes

Is there a way I can get the post to occur, regardless of the current state of the virtual switch?

Right now, the post only occurs if the state changes from off to on or vice versa.

Hubitat is event-driven, so I think the only way to do that is periodically get Device Details from the other end.

But I’m curious, what is your use case that requires this? Do you not cache device state at the other end?

I guess I will need custom driver.

No, state is not cached at the other end. It could be, but that just complicates things unnecessarily.

On event sent regardless of state, off event sent, regardless of state. Simple.

I would flip this around. I can't imagine why you'd ever want to cache state. Save a few bytes of communication? In todays world?

I did it in my x10 driver like this (no way to query state in X10 devices and they can be switched on/off locally).

sendEvent(name: "switch", value: "off", isStateChange: true)

In a general sense, when devices have no way to query their state AND they can be controlled without Hubitat code being notified (e.g. legacy devices like X10), suppressing event notification based on a notion of current state just causes problems.

And the processor time to send it. And the network bandwidth used. Multiply that by a few hundred devices that are polled every few seconds and the utility of caching becomes evident.

1 Like

So, devices are polled for their current state regardless of whether there's event processing that needs that data?

Yes, I do this for two TVs. So a change in state can be used instantly in lighting settings.