The traditional method for integrating a HTTP type of device like this is to write an OAuth2 Application. These apps expose an HTTP endpoint which can easily be used to integrate both LAN and CLOUD connections, and are secure.
If the device is LAN connected, there is another fairly simple option to have a Device Driver receive unsolicited HTTP posts which avoids the OAuth2 complexities.
It is strictly local with no oauth support (at this point with V1). The unsolicited posts device driver sounds perfect. Could you please point me to an example? Thanks for your help.
Very interesting. Please forgive me if I am wrong but from what you said ad looking at the code I surmised that Hubitat is listening on 39501 and routes http calls to a device with the ID of the http sender IP. When a match is found it calls the parse method on the device.
Is this correct? If so could I ask where you found this documented? Iāve searched poorly it seems.
Would be great if they added http as a first class citizen like the other protocols so a device driver could simply implement http_post(json) and go from there.
2 more examples of drivers with MAC addresses or IP:PORT in the device network ID so they can receive messages from LAN devices.
I believe I have helper methods in one of both of those take set the DNI as well from an IP/PORT combo in decimal (since it needs to be in caps hex I think).
I'm guessing you want to write an app that can receive http calls. Here's an example you can use. It may not work as I stripped out a lot of code but the key points is looking at the mappings section as that routes it to the handler. You also need to enable oauth when you add the app.
It should give a you a good idea as to how you can receive a call and action on it.
In the Live Logs, if there is not a corresponding device with a matching deviceNetworkId (DNI), Hubitat will log a message in the Live Logs. I don't think it includes the payload, though.
What are you using as your DNI? It needs to be HEX encoded. It does NOT need the sending port as a suffix, just the IP Address. Look in my Parent Driver and you'll see the code that sets the DNI based on the entered IP address of the sending device.
Here's the helper function to convert a string IP address to HEX
Thanks. I put a sniffer on it and determined RoomMe is not respecting the destination port setting and defaulting to 80 instead. I assume there is no way to get traffic on 80?
You'd have to create an OAuth2 enabled Hubitat App, instead of a driver. This would require the RoomMe folks to allow you to fully configure the URL that is being called, so you could include the OAuth2 key.
Turns out it was a bug in the RoomMe app and I got past that with their help so Iāve got a proof working. Now on to building out the real RoomMe support.
@wayne2 Just curious about RoomMe. Is there a way to get data directly from the sensors and bypass the app on the phone? Are you trying to have the phone app talk to the Hubitat Hub?
Using just the sensors in Hubitat would be cool.
One more question: Would the RoomMe sensors see other bluetooth devices you walk around with like a smartwatch or fitness band?
I love the idea of these solely as presence sensors, just don't like the phone idea as we put those down and don't walk around with them in the house.
RoomMe requires an app on a phone or smart watch. That app sends a message containing data in which device triggered which sensor and if it was enter or exit. This will be received by my Hubitat driver and the driver will maintain the room presence information for each person and each room. Iāve gotten completely sidetracked with a remodel but should be freeing up time soon.