So I'm currently running the ported InfluxDB logger app to log my events but my understanding is that there are at least two more approaches: a solution using the unofficial web socket and a solution based on the Maker API.
Is there a clear 'winner' amongst the three?
Would I be correct to assume that the websocket approach is the one using the least resources while the Maker API is the most future proof? Is the only thing going for the User App the fact that it is up and running and I don't have to change anything?
I have been using the InfluxDB port with no issues for over a month. I don't plan on changing unless I see a slowdown. I didn't want to go down the node red path yet. I'm logging everything from my 100 or so devices.
With other people reporting slow or lockup issues, I'm hesitant to do anything that adds additional load on the Hubitat. So I'm using Node-Red on Raspberry Pi.
But how do you get the data to Node-Red? The websocket interface isn't official, and since it sends all events from all devices it could add load.
@Krupka, So I'm biased, I wrote the Maker API version, and worked on the InfluxDB App. My 2 cents:
The Influxdb app seems to work just fine and recent versions shouldn't kill the hub, they don't do anything to weird. It delivers data once per minute, so surely the hub can handle 1 async http request/minute?
The Maker version I wrote to avoid running any thing support could point to and blame as a reason for slow down. It's not amazing code, but it's also not complicated.
The maker version used some code from the App for a reference, so they're pretty similar considering one if Groovy and the other is Javascript/Node.
There's few major feature differences:
The InfluxDB App polls all devices to "fill" data in InfluxDB if the device hasn't produced an event. I could not do this with the Maker version since the API lacks units field when polling devices. So the Maker API just repeats the last message received, but has to have actually received a message first.
The InfluxDB App has a very specific set of types it can process. (and a lot of them) The Maker App tries to parse every event it gets, so it should capture a wider range of information.
The Maker version maintains a set of very detailed metrics about what devices are producing events, the type of measurement and delivers them to InfluxDB so you can graph them. So you can easily track down noisy devices.
There could be some minor overhead with handling the communication on the socket for the Hubitat, but I would assume that there is no additional data formatting being performed by the hub. But only the folks at Hubitat can tell us for sure.
Just because I'm using Node-Red at this point doesn't mean I won't be using your app in the future. There's just too many experienced users that have been reporting issues for me to start adding any additional potentially significant loads on the hub... other than the new rules and some devices I still have to install and setup.
@billmeek Oh don't get me wrong, I actually really like Node-Red. I use it at work to help play with visualize some nice streams of data. (200-300 of messages a second)
I just worry about it's interface to Hubitat since its using the websocket interface which isn't official. It could easily use the HTTP in with the maker api and voila.
The websockets were created for Dashboard.. so in that limited sense they are "official" -- they were never intended for 'external use'. Because Hubitat controls both ends, Dashboard and the websockets, they (rightfully) feel they can change it without documenting, which is what makes them not official, I guess.
Hubitat has also said that they clearly understand how many uses it's been put to and will announce a replacement, when it comes up on their long list of To Do's. They will give the Community time to swap to the replacement, I'm sure.
That's my interpretation of comments I've read.
MakerAPI is a great tool but the differences can add up. "Filtering" (aka subscriptions) is done on the MakerAPI path while Event Socket is output prior to subscription processing. There was quite the discussion about de-duplicating and Event Socket in another thread.
@csteele Thanks for the background. To be honest I really don't see how the websocket interface could be blamed for anything, but I'm being a bit pedantic/cautious since I've seen hub slow downs myself.
I wanted to have as clean of a setup as possible, and if I'm going to be pedantic then something that's not design for the purpose fits that bill as unofficial.
It does seem like for logging status/graphs/etc the maker api is now the alternative offered.
I'm curious about the dedupping, are you worried about de-dupping between websocket and maker? Or are you worried a device reporting "off, off, off, off" and having that being de-duplicated into a single off?
The discussion was about if de-dupping occurred or not in Event Socket and the answer is, it does not. The point was the Event Log differences between two hubs. If you go to a Switch and click On, on, on, Event Socket shows them all. There are ZWave messages for each and that's reflected in Event Socket. However, the Event Log for that switch will show only one On. The Event Logs for a 'reflected' switch on another Hub will show On, on, on. Button devices absolutely must work that way, Nothing else needs to.
The point (from me, above) was that there are differences: there's a cost for being 'free"
"Free" Event Socket from the Hub pushes the de-dup task to the receiving device, MakerAPI, having done de-dup on the Hub, (cost incurred on the Hub) is "Filtered" from a logging viewpoint. What are the logs used for? Would the log results want to show On, on, on? It's just nice to know what is occurring, to the designer of an App, I think.
@csteele Got it! This sounds like a solution that's destined for tears, and maybe could be classified as a bug in the driver? I dunno, but if you have a solution that works, then...
As we both know events are filtered if there's no state change, but this affects apps, and everything listening for events on the hub itself. So no one can listen for "on,on,on", not even built in apps or RM, but the websocket interface can. Drivers can/could force a state change isStateChange in the sendEvent():
If they did this on a physical switch changed, then it would work for everyone.
The problem is, I've found no clear description around when events should be generated, so I guess it's all over the board. For example what does On mean? It seems it could mean:
Someone issued device.on() and device was off. (type digital)
Someone issues device.on() and the device was on.
Device really turned on (type physical)
Someone turned the switch off->on
Someone turned the switch on->on (from this thread)
It would be great is there was a doc that stated when the conditions are for each type of event and which should be forced as a state change. For example switch press should always generate an event? Sounds like "on" and "off" are too overloaded really, switch/button events should be broken out to be clearer.
Thanks everyone for your input. I went ahead and switched from the app to the websocket/node-red approach. Just wanted to learn about node-red and that was a good little project.
Works like a charm, but at least the node-red performance monitor from a different thread does not indicate any reduction in hub load. But then it was already pretty low.
The websocket interface isn't official, and since it sends all events from all devices it could add load.
