Hello guys, I'd really appreciate getting your thoughts and suggestions on the best strategy for me to reach my goal.
Goal: I am creating a webservice (in python, if it matters) that will receive some "messages" from hubitat and then do some stuff. The messages can be Maker API Post messages or, if you recommended, a hubitat App that might do some logic and then possibly reach out to my webservice.
Maybe a relevant thing here is that my application doesn't necessary act on every event from Hubitat, so I need to have my logic implemented somewhere (either in my webservice, in case I am consuming Maker API Post updates or in the Hubitat app I would create). What would be better? I did a quick try to create such Hubitat app but failed to make the event handlers work properly. So I am not sure what way to go.
In theory, having the hubitat app implemented would reduce the number of API requests sent to my web service, which I believe is more convenient and elegant. But I dunno if there are any trade offs or limitations with such kind of funcionality.
Personally I'd go the app development route so that I could minimize the traffic and to aid in debugging. You mentioned that you were having issues getting the event handlers to work, if you'll post what you were trying I'm sure that someone on here will attempt to help you work through those issues.
I’d consider how much load you’re putting on the hubitat, the network, and the receiver when assigning responsibilities. For example, if sending everything without logic filters isn’t a big deal for the network and the receiver, I’d do that. You could always add intelligence on the hubitat side later, if things don’t work out. On the other hand, if the network or receiver is going to get hammered, I’d definitely set up more intelligence on the hub. I’m not familiar with groovy, so if it were me, I’d concentrate on the receiver and worry about filtering the messages only if I need to.
How many devices are we talking about and what mix of device? Switches vs Sensors?
Tks for the comments so far, guys.
@jtp10181
My home has somewhere around 50 devices that might be involved on this. Some them are virtual sensors but the vast majority are lights, sockets and switches. There are a few thermometers too and one of the reasons of my filtering logic to exist is to only act on temperature variations if that is bigger than a certain threshold.
I can tell you guys how my implementation works today (the POC stage). I created a web service that every few minutes requests from Maker API a detail list of all devices and their current attributes. My logic does some clean up, removing info about the attributes and commands that I don't need. Let's call the result of this cleaned up data a "snapshot". Then I compare it with the previous snapshot I collected minutes before so I know if there was some change that I care about.
This approach works today but I would like to share my work with other users and I don't think this approach is very scalable given the volume of data being fetched every few min.
Worth noting that this approach also causes my solution to not react fast on events and even miss then out (imagine if a light gets turned on and off in between my pooling to maker API). I am fine with the approach being a bit slow, although I would rather knowing that a light got turned on and then back off (I guess there is no straightforward way to know that from Maker API). So that's why I am trying to design a new strategy.
I have around 70 devices of a similar mix (typical household) pushing to Node-Red via Maker API. Have never noticed an issue with it. I also have a large number of devices pushing to Homebridge through a separate app. The hub can handle it fine. Keep in mind switches do not change state very often so its really only very busy sensors that will send a lot of info over. It will probably be far less traffic than the polling you are doing now.
I think I would start out with Maker API pushing the events. Later it might be good to work on a custom app, you could have different categories of devices that might get special handling, or you could filter attributes so that only what is desired is sent over.
Depending on how much time and effort is going to be involved in building your web service, I'd recommend you look into just doing what you need to do in Node Red. There are specific nodes available to connect to Hubitat devices, or you can point a websocket listener at the log socket or event socket and see all the messages coming from those endpoints.
I have Node Red running in Docker on a Raspberry Pi 4 (4 GB) alongside many other applications. It is listening to all events, the log socket, and the event socket from 3 different hubs (two C-7 and a C-8 Pro), plus I have many nodes listening to specific devices. Neither the hubs nor the Pi are breaking a sweat.
I use Node Red to store all log messages and events in a database, and I have a bunch of flows that send notifications or take other actions based on what's happening on the hubs. While most of my home automation logic is on the hubs themselves, a few things are easier to do in Node Red.
You haven't been very specific about what you plan to do with the info from the hub other than 'do some stuff', but I expect going with Node Red will get you where you need to be faster and with less effort than coding your own web server and all the logic from scratch. If you have the skill to do that, learning Node Red should be easy.
First i would adjust your app to look at events vs polling. Simply put polling isn't a good practice as it creates alot of unneeded work that is likely uselss. It also operates under the primise of tryint to capture a event state vs actualy having that state sent to you.
There are a few good ways to capture events. Makeer API can post events to a external application like Node-Red or your own app and is very efficient with doing so. You could also writea app to post your event data exactly how you want it, and that shouldn't be to hard to do. Then there are also apps like InfluxDB Logger that function this way as well. It even has the ability to do a soft poll as well though it isn't liked by allot of users. InfluxDB Logger also has a way to filter out unchanged values when doing polling as well. and it can Queue up records if your app can handle that to reduce the number of outbout posts.
One thing to remember is that if you write a app to handle this custom apps have a limit to the number of http actions athey can do at one time. I believe the number is 10 so depending on how much activity you are doing at once that could be a problem, and it will generate alerts in the logs.
Personally I would suggest writing your app to ingest the data from Maker API that is posted based on device events. That will get you all of the data for status changes and reduce the work on both sides most likely.
Tks guys. I think that for now I will follow what some of you suggested: I will just let MakerAPI post the events into my web service. The web service will then treat the event, decide to take action on it, etc. The main reasons for deciding this approach were:
-Not creating an hubitat app right now and having one more thing to learn and maintain.
-Related to that, I would probably have to do lots of updates on the hubitat app during the first iterations of my project. So if there'd be other ppl using it, that would get extra annoying.
-As some of you pointed out, the load on the webservice should be quite manageable, at least if I limit myself to a few homes.
Tks a lot!
