I have a sensor for water tank depth built on Raspberry pi Pico W (the microcontroller with wifi) using Circuitpython and few Adafruit attachments. I don't have Zigbee/Zwave radio module, but WiFi on board of Pico serves plain vanilla TCP/IP communication just fine.
What is the recommend way to integrate such decice/sensor into Hubitat? Should HE poll the Pico in regular intervals? Can I push the event from Pico to HE (on change or in regular intervals)? I even found MQTT client lib for Circuitpython but He is not MQTT hub - and I don't want to add more moving parts into the mess.
So, if I want to build a device/sensor on IP network that behaves as similar as possible to ZWave/Zigbee devices, what is the way?
If you can write some scripting that would trigger an http call on the events you want to push to Hubitat you could do it with a Rule Machine endpoint trigger. Rule Machine | Hubitat Documentation
You could also use Maker API and expose a virtual device, then send events back to Maker to trigger changes to the virtual device.
No, this would be the opposite, you would make the Pico push the events to Hubitat. That is less traffic and less overhead on the hub. You would code something on the Pico that calls an http endpoint for Rule Machine on Hubitat (or maker API)
Yes, thats what MakerAPI is for, which if you have a lot of info to push with different sensors Maker is probably going to be easier, you could create different virtual sensors/switches and push the states to them via Maker API. Dont ask me how exactly, I just know it can be done.
If you can get your app to interface with Node-Red you could even use that as a middle man to talk to Maker API, there is a node red pallet that works with Hubitat. Thats what I use Maker API for so I know it works, just not the specific details.
Reviewing Maker API, this is not an ideal for my use case. Maker API is meant to open Rest API to 3rd-party systems to query and command devices that have their own drivers in HE.
Maker API is made for cases where - for example - I would want to make my firewall query people presence in the home and open firewall rules.
I could create several updating commands with parameters and call them from Pico in regular interval, each time sending the sensor data to HE through a GET statement and then persist that data in HE driver model - but that is far from elegant.
WiFi-enabled sensor should be able to be discovered, register its capabilities and commands, and behave just like Zigbee sensor. Maker API doesn't provide any of that.
Sure if you want to create your own Wifi driver from the ground up. I figured Maker might be easier to just push some event updates to virtual devices. You will use "virtual" devices for a Wifi driver as well.
I searched the repo and found some of the code with 39501. It looks like it is building up a string to send to the device. So the driver is not sending the POST itself, it is giving the command to the device, so the device knows where to post messages. I am not sure what the port 39501 interface is exactly on the hub, it might be the undocumented webhook I have seen people talking about before. Its not going through Maker API. If you search the forums for 39501 you will find other topics about it.
So, yes it looks like you could build a custom driver to catch messages sent to that port, and then code your Pico to send the hub messages as needed.
Looks like port 39501 listener is open on HE Hub and clients/devices/sensors can post straight to it.
Based on quick review of Tasmota driver, all communication is initiated on the client/device and all data exchange is done using POST statements from client/device to HE.
Lack of clarity and documentation on HE listening port 39501 concerns me. Where to go for more info?
All you can do is search the forums, it is an unofficial and undocumented feature if its the thing I am thinking of, after searching a little I think people call it the websocket interface. Maker API is the official documented route. The benefit of using the direct port I think is that the user does not have to bother with setting up the Maker API app in order to use the driver. Sorry I am not really sure how it works, I primarily develop Z-wave drivers.
Here is what I gathered - if it helps anyone (and if devs want to comment):
The Hubitat Elevation platform provides two different APIs that allow developers to interact with devices and other platform resources:
Hubitat API on port 39501: This is the primary API that is used by the Hubitat mobile app and web interface to communicate with the platform. It is a WebSocket-based API that operates on port 39501 and allows for real-time updates and events. This API is primarily intended for use within the Hubitat ecosystem and requires authentication with a valid user token.
Hubitat Maker API: This is a RESTful API that is designed for use by external applications and services. It allows developers to control devices, execute commands, and receive events and notifications from the Hubitat platform. The Maker API operates on port 80 or 443 (depending on whether SSL is enabled) and requires authentication with an API access token.
The main differences between the two APIs are the protocols used (WebSocket vs. REST), the intended use cases (internal vs. external), and the authentication methods required (user token vs. API token). The Hubitat API on port 39501 is generally used for real-time updates and control within the Hubitat ecosystem, while the Maker API is used for external integrations and automation with other services and platforms.
