@mykesx Please excuse my ignorance but how does your integration use Maker API differently than the Hubitat Nodes in Node Red or Home Assistant integration? I have one installation of Maker API for each so any change in Hubitat sends a POST from Maker API. There is no need to poll anything and no real strain on HE hub.
There is a node in Hubitat's Node Red integration to get all device attributes of every device and it I were to push that 3 or 4 times in a row, I could lock up my hub instantly in early versions of Hubitat Node Red pallet.
Laymans answer please if there is such a thing in this case.
That doesn't make sense to me. It sounds like you are saying that this dashboard has to query every device on it at the update interval even if nothing changes. I have my Dashboard in Home Assistant that is accurate but it's not polling every device every 2 seconds to do so. It's reacting to any changes that it has received from Maker API. I don't have any Node Red dashboards but I didn't think it would work that way either.
When Node Red starts, it does initialize every Hubitat device but it only does that once at beginning and it usually takes 5-10 seconds. After that, it keeps the status of each device in cache and only changes on receipt of a new POST from Maker API if I understand the process correctly. @JasonJoel and @fblackburn know much more than I do.
I am not questioning the method. I am just trying to understand for my own education.
I am using the NR dashboard and I have it set to react to events via the HE device node no polling required - although I guess you could do it if you really wanted too. Also have some subflows that use the generic events node for things like battery levels. Everything reacts to Makers posts.
My understanding is the same as your @stephen_nutt but happy to be corrected if wrong.
I never said anything about node red. You did. All I.know is there are dashboard apps that query every device when you bring them.up. i tried one and quickly stopped using it. You are misinterpreting my comments.!
I am just trying to compare something I know a little how it works (Node Red) to how the dashboard in this thread works and it sounds like it is querying every device on a dashboard every 2 seconds so I can understand how that would be taxing on the hub. I accidentally had a Hubitat Device Node that queried all devices every time I deployed and if I deployed a few times within a minute for whatever reason, I would shut down the hub. Fortunately the creator of the Node Red Hubitat pallet changed something so that initialization process now is done MUCH quicker.
Not quite I am looking at it from the point of the Maker API posting the events which any external dashboard/app should be able to receive via a webhook without requiring expensive polling (except for initialization of course).
Before I knew of the post url for Maker API, I had to use getDevices() and poll. I don’t do that anymore, my hubitat microservice uses the events WebSocket AND the post URL of Maker API.
To handle the post from hubitat, I had to implement an Express server to handle the posts.
It works fine.
I do one getDevices at startup to build a hash map for converting device names to device ID suited for the Maker API http get urls.
If you want to detect newly added devices, you need to call getDevices(j.
Sorry if I have the function name wrong. You should get the gist.
Yeah that sucks - I have 50 Zigbee devices left I need to move over from 2 C-4 hubs over to a C-5. Already manually transferred my Z-Wave devices to a C-7.
My understanding is there is supposed to be a hub migration service available at some point (soon?) that you can migrate from a C-5 to C-7 and beyond.
One of the more interesting things about the RoboDomo architecture is that the microservices are meant to be long running programs - 24/7/365. When you are using and consuming APIs from sources you can't control, all kinds of weird things can happen. Like they change the format of some response, or their server has a bug, or the data is garbled or the response unexpected... Getting the microservices to not throw exceptions in weird cases took a lot of time. You think you implemented the right error handling, but it throws an exception in some edge case you didn't consider.
You can't just continue to run if the error is truly a fatal one. Like doing the getDevices() that returns no devices (for whatever reason). You get the error thrown, but if you proceed, the microservice isn't servicing any devices at all.
The eventsocket is better than polling in my opinion. Just listen in to the stream and act accordingly (eg arch for device changes etc). That's what I'm using for my custom dashboard and it's working like a sweet dream
The hub is all but locked up. To view the list of 6-8 apps I have installed takes about 15 seconds. Same for list of devices. After a reboot, those pages are a second or less.
Device Stats enabled: true
Device stats start time: 1607984522818
Device stats total run time: 276666
device id 44 runcount 81 total runtime 387 average run time 4.7777777778
device id 57 runcount 107 total runtime 967 average run time 9.0373831776
device id 13 runcount 81 total runtime 686 average run time 8.4691358025
device id 54 runcount 123 total runtime 1207 average run time 9.8130081301
device id 14 runcount 40 total runtime 636 average run time 15.9
device id 50 runcount 41 total runtime 141 average run time 3.4390243902
device id 51 runcount 41 total runtime 141 average run time 3.4390243902
device id 41 runcount 45 total runtime 10162 average run time 225.8222222222
device id 52 runcount 67 total runtime 226 average run time 3.3731343284
device id 225 runcount 14 total runtime 4862 average run time 347.2857142857
device id 98 runcount 2 total runtime 35 average run time 17.5
App Stats enabled: true
App stats start time: 1607984522820
App stats total run time: 276671
app id 132 runcount 198 total runtime 27625 average run time 139.5202020202
app id 131 runcount 133 total runtime 34281 average run time 257.7518796992
app id 134 runcount 5 total runtime 688 average run time 137.6
app id 4 runcount 2 total runtime 127 average run time 63.5
