Is it possible to send an HTTP string on the local network?

I am evaluating what it will take to transition from ST to HE. One of the apps that I rely on in the ST environment is an app that sends an HTTP string to a personal computer running iSpy to command iSpy to take a picture with one of the security cameras connected to iSpy. Thus when the ST motion sensor on the front porch detects motion, it sends a string that causes iSpy to take a picture with the appropriate camera.

The key piece of functionality in the app seems to be the ability to execute the ST "sendHubCommand" - here is the line of code from the app:

sendHubCommand(new physicalgraph.device.HubAction("""GET /snapshot?ot=2&oid=$camera1 HTTP/1.1\r\nHOST: $ip\r\n\r\n""", physicalgraph.device.Protocol.LAN, "${deviceNetworkId}"))

Is there an analogous capability in HE?

I have ordered the hub but have not received it yet.



Yes, this is very easy to accomplish on Hubitat's platform. It is really almost identical to ST's implementation.

For example, take a look at my "HTTP Momentary Switch" Driver for Hubitat.

Also, take a look at this WiKi post which highlights some of the simple changes necessary when porting apps/driver from ST to Hubitat.


That's great news and great information. Thank you very much! I can't wait for the hub to arrive!


The app that sends the http command to my iSpy server when motion is detected on HE seems to be working as hoped. The changes to "port" it over from ST to HE were minor.


Glad to hear it!

Dan, as an example, I can turn ON an Insteon switch locally on the 2245 hub with...

curl http:// [Insteon hub usr] : [Insteon hub pwd] @ [Insteon hub IP] :25105/3?0262**[Insteon device ID]**0F12FF=I=3

and I can turn it off with...

curl http:// [Insteon hub usr] : [Insteon hub pwd] @ [Insteon hub IP] :25105/3?0262**[Insteon device ID]**0F1400=I=3

Can your driver allow me to do this somehow? I'm so fed up with HomeKit automation getting out of sync with my virtual switches, or just not working consistently. Sorry if I asked you this already. I'm just really longing for some other way to control my Insteon devices that doesn't involve the cloud.

You will need to modify the driver to add a separate on vs off URI and also to make the on() and off() functions use the two different URI's.

It should be fairly simply to do. This might be a very interesting type of virtual driver for the Hubitat Team to consider adding to the platform.

@mike.maxwell, @bravenel - Mike and Bruce - Any thoughts on this idea? A standard Virtual HTTP Switch driver that allows the user to issue an HTTP call for the on() and off() methods. The URI's for on() and off() would be simple user preferences, as well as whether they want a Post, Put, or Get. This new driver would allow any App that supports the Switch capability to interact with with these 'HTTP Devices'.

Of course, if users need the response parsed to properly update the 'switch status', we are getting a little too complicated for a generic driver, probably.

Perhaps something like this would make a better generic example driver that could be hosted in the Hubitat GitHub Repo as a starting point for users to build such a custom device driver for their particular integration?

Just thinking out loud. I'm definitely not very experienced with RESTful APIs, so I am sure others will have better ideas.


I've been looking for something exactly like this. Would be a great help, I'd do it myself, if only I was that gifted :wink:


I've been playing with the Express Server for Insteonlocal Homebridge plugin. Not sure why I ignored this for so long. It pretty much does exactly what I need. If I enter the correct path for ON and OFF respectively into your HTTP Momentary switch driver, it works and controls my Insteon lights locally, and very quickly.

The groovy could easily be modified by someone that understands it, so that it has two fields, one for ON and one for OFF, but this is really unnecessary. The primary variables will always be the Homebridge IP, the port number, and the Insteon device ID. The other variables in the path, will be the type and state (ON or OFF), but for this purpose, the type "light" is all that's needed. Unfortunately, I don't have the groovy skills to make that happen. No point in my posting the code. It would just be all wrong and missing so much, but I can give you a screen shot of what I'm thinking it could look like so you have a better idea of what I'm talking about. I've posted a shot of what works right now with a single http path.

Here are the possible http paths for the Insteonlocal Express Server. The only two that matter here are the first two for light ON and OFF. Dim would be nice, but so as to not over complicate things, that would be very simple to do once RM can do HTTP GET. And for that matter, your original HTTP Momentary switch would be fine for setting a dim level.

  • /light/[id]/on : turn on the light with Insteon [id]
  • /light/[id]/off : turn off the light with Insteon [id]
  • /light/[id]/status : get status of the light with Insteon [id]
  • /light/[id]/level/[targetlevel] : set brightness of the light with Insteon [id] to [targetlevel]
  • /scene/[group]/on : turn on the scene with Insteon [group] number
  • /scene/[group]/off : turn off the scene with Insteon [group] number
  • /iolinc/[id]/relay_on : turn on the relay for iolinc with Insteon [id]
  • /iolinc/[id]/relay_off : turn off the relay for iolinc with Insteon [id]
  • /iolinc/[id]/relay_status : get status of the relay for iolinc with Insteon [id]
  • /iolinc/[id]/sensor_status : get status of the sensor for iolinc with Insteon [id]
  • /links : get all links from your Insteon Hub
  • /links/[id] : get links for device with Insteon [id]
  • /info/[id] : get info for device with Insteon [id]

Here's what works now, but currently only supports the single local http path as you know, and momentary isn't desirable in this use case. "Get" will always be used. "Post" and "Push" are not needed.

I'm fairly certain modifying this would be trivial for you (don't want to take you away from the Alex TTS project though :stuck_out_tongue_winking_eye: ).

Here's what I'm thinking for a basic Insteonlocal Express Server switch. Again, the choice between POST, GET and PUT is unnecessary. Only GET is needed for this use.

[Edit] One other thing that would be nice to have would be the status via polling. If a light is operated outside of hubitat, it would be great if the driver could poll, say every 30 seconds (or a user definable amount) so that the driver state and the Insteon light state are always kept in sync.

  • /light/[id]/status : get status of the light with Insteon [id]

Lots of info in that post! :wink: I'll need some time to digest it when I am home.

I do have one quick question... Does your Insteon device listen on port 3000? I am starting to see a trend with many devices using port 3000 for their web-services. Just interesting to me...

1 Like

No, Insteon's standard port is 25105. Changeable, but would be unusual to do so. Port 3000 is the Express Server which is part of the Insteonlocal Homebridge plugin that Scott Kuester (@kuestess on ST forum) wrote.

You can curl direct to the hub, but Scott's express server simplifies things by allowing you to use HTTP GET and a simple ON or OFF at the end of the path, instead of having to remember 3?02620F11FF=I=3 means dimmer on to 100% and 3?02620F1300=I=3 means dimmer OFF when you are sending direct to Insteon :roll_eyes:

1 Like

One thing that the driver doesn't do right now is get status and even if I was able to stumble through a modification of what you've already done, I would have no idea how to take the status and update the driver state with it.

If I enter in a browser, it returns {"level":0} for a light that's OFF, {"level":100} for a light that's ON to 100%, and {"level":70} for a light that is turned ON to 70% for example. So if user definable polling was added to the driver, it would need to synchronize the driver state to OFF when the Insteon device ID returned {"level":0} and ON when the Insteon device ID returned anything higher than {"level":0}

1 Like

We should be able to add in a periodic refresh that returns the current status for each light without too much difficulty. I am not the best Groovy programmer, but I know how to use Google! :slight_smile:

1 Like

:joy: I can Google French translations, but it doesn't mean I understand the language! :wink:

1 Like

I am sorry if this has been covered- I haven't found it just yet.

I am wondering if we have an HTTP Switch device that has a separate ON and OFF URL field.

I like the momentary switch here but might like to have just one switch with ON and OFF URL fields.

Is this out there?

Thank you for your patience!

Take a look at this thread.


THANK YOU very much! This works perfectly. Thanks again!

1 Like


would your Hubitat HTTP Momentary Switch Driver support the following format in the address field for authentication/login requirements.

I am not sure... But the code is Open Source, so you should be able to tweak it for your application as you see fit.