How many devices? My memory is half that on one hub and a quarter of that on the other. 129928 and 209976. Incidentally, the one with less free memory is faster so far.
Roughly 75 physical devices (50 Zigbee, rest Z-Wave), 109 shadowed to ST via HubConnect; WebCoRE (107 pistons); 3 LAN devices, 59 virtual, 45 Simple Automation rules and a half dozen each of Motion Lighting and Button Controller instances. Plus a couple of groovy apps (Laundry monitor port from ST, HubWatchdog). RM2.5 and RM4 installed, but disabled. All running like a top, for now.
Is your memory status green, as well?
Edit: just checked and memory now 498424, up a tad. GC is doing its job...
Bear in mind guys that an app is typically dormant until an event of significance to it is thrown. This is why big apps are not necessarily resource hungry.
However if your app subscribes to device events it will run whenever a relevant device changes state. Typically you select these devices within the app. So these (runcounts) look potentially more culpable than they are, but to function they must do this.
More important is how efficiently the app deals with those events before exiting again, so runtime is interesting.
MQTT publishing status updates to a broker or monitoring a broker for updates may run frequently but hopefully handle such events efficiently.
That's why the run counts and total run time are interesting (and necessary) to see the big picture.
I see you guys are hungry for information, so I would like to contribute with the the list of REST endpoints I have been able to find over the past years. Some response with GET or POST and some are no longer working with the last versions but but I am sure some of you will dig deeper.
Filtered out the dangerous ones
I get it. I work in process automation in a refinery on 10-20 year old hardware.
Capturing this page before someone deletes the post.
Someone has seen the FW code...
I will be the nay-sayer here, and warn people that they shouldn't probably mess around with this unless you know what it does, or are instructed by support to do so.
I am just picturing the "my hub is bricked" threads that are going to be littering the forums.
Exactly, don't test any of this in your main / production Hub... I can assure you your wife won't be happy
I'm going to step out on a branch and say this probably wouldn't have happened if the HE people had been more forthcoming especially when they aren't giving proper attribution to the open source code/projects they are using which is a license violation. The more they resist the more people will push back.... The thirst for knowledge is strong.
But I do agree..... playing with some of these url's has the potential to brick a hub so be very careful.
And for that matter, why would you want to keep them in plain sight, maybe remove the links so accidents don't happen?
Too late! I already saved em. Had a feeling you'd be around sooner or later.
Bad behavior is rarely if ever an excuse for other poor behavior.
Why I think the list of links is a great resource. I also think the point here was to gather useful "undocumented features" With out knowing what they do they aren't really a feature.
I’m not sure there is any relevance to your thoughts about how they are handling open source projects. These are links to various endpoints in their closed source product.
I don’t think as consumers we are necessarily entitled to know every unpublished and undocumented endpoint. If you’re interested in knowing every possible detail of the software, perhaps it’s time to move onto an actual open source product to serve your home automation needs? Just my .02..
Seems like there is some agenda here by certain people to want Hubitat to fail.
LOL. I didn't suggest to remove the post, just the links so it's not a matter of clicking on one of them, and hoping for the best
I don't see that at all, just be a little more open. Some of the aspects of Hubitat's (reluctance to) release information/code seems unhelpful and overly paranoid and discourages developers who have to publish open source.
If they want to respect people's right to have closed source they should release a mechanism for developers to protect their apps (not something I believe in) ... but open source works two ways.