One for the team really.
Quite a few of us need to reboot our hubs when free memory drops to below about 200000, which really limits the uptime to a couple or so weeks maximum. Will the C8 be an improvement in this regard?
There's one way to find out 
I'll hopefully be able to tell you sometime soon....
2 Likes
I've run down to just under 120,000 without issue - at that point a new release of the firmware came out so can't say below that. For the record though, I have my low memory notification set at 150,000.
3 Likes
Perhaps there is a sweet spot, a "Jean point" if you will... where we should all look at rebooting... Sounds like a good setting in a device driver.... Hmmm... where to place it....
1 Like
I've had mine down at 80 and it still ran fine. Though now I have my reboot at 120.
1 Like
One of the recent beta versions had a bug that was sucking up memory, mine got below 100Kb in short time before I finally updated to the fixed version. Was still running fine at the time. Was discussing the memory with one of the devs and he suspects the low memory is not really the issue that makes you need to reboot. Something else is going on with an app or driver that is not easy to see and the memory declining is a symptom of whatever that issue is. This would explain why there is no set level of free mem where issues happen, because it is not really the cause of the issues that people have. I feel like I could run my hub indefinitely without rebooting, but there are always updates so its doesn't go more than a week or two.
To answer the question, the mem and cpu are the same as the C7, and as shown by the recent firmware update it runs the same firmware as the C7, so I would assume it will work in a similar fashion. If you are having issues on a C7, I do not think the C8 would fix it.
You might be able to split the load though and keep some heavy apps or wifi devices on the C7, and move the Z-Wave and Zigbee devices to the C8.
2 Likes
I have a nightly process that executes a reboot around 03:45. There's no reason to be trying to stretch uptime records with this device when most problems seem to be headed off by a periodic reboot. Since I added that reboot, almost all the "hinkiness" disappeared and the only unplanned reboots are done to install new firmware.
Incidentally, I find this to be a necessary evil with anything that is based on Java, regardless of platform. They all seem to have memory containers about as solid as your average kitchen sieve.
Just been reading up a bit on this, so the hubs could benefit from more ram? Or would that just be staving off the reboot time until later?
It would still just delay the inevitable.
That said, if it was enough extra ram, you'd eventually get to a point where you could avoid having to reboot to resolve this issue because you'd be rebooting for other reasons (like a system update).
1 Like
Also need to note that this is a YMMV issue...I don't get any regular periodic hinkiness if I don't reboot, I only reboot when updating FW on the hub.
Not saying there may not be real issues w/Java (I'm not a SW engineer, never played one on TV), just that a nightly reboot shouldn't be taken by folks as some basic requirement to use HE. 
2 Likes
Absolutely true.
It's all going to depend on how many other apps, devices, etc. you're using, and which ones.
Honestly, I don't need a nightly reboot. It would probably be fine to only do it weekly. Maybe even bi-weekly.
When I started out with the C4 I rarely rebooted the hub. But then I didn't have as many events going through the C4 as I have now. (mutiple dashboards with constant image and status updates, maker API calls etc).
For what it's worth, it can be done easily and automatically, as discussed here: Rule to reboot hub
Sure, it's simple to set up, there are apps to do it as well as rules...that's one of the best parts of HE, you can go accomplish things in multiple ways, depending on what suits you.
Sounds like you're having fun.
You could also simply write a rule that if it gets below 120k, then reboot it at 3:am and not even notice it...
Lol 
it was fun until it wasn't.
When I realised it was all the events being sent to the hub I spent a fair amount of time pairing down the frequency of these events (TBH who needs their electricity consumption updated every 30s? 
)
2 Likes
I could. But that's far more complicated than simply rebooting every night on the schedule.
Besides, what if it goes below 120k at 03:01? It's then a full 24-hours of unknown behaviour until it will reboot automatically.
For the 2-3 minutes of nightly outage when everyone's asleep and no automated rules are firing, to me, it make sense to just schedule it. Then I also can schedule my websockets log monitoring restarts to coincide with when it is back up a couple minutes later.
Also, as a side note, it's best to not schedule anything you want done nightly between 00:59 and 03:01 if you're in a place that automatically does DST changes as that occurs at 02:00 and goes either back an hour (to 01:00) or forward an hour (to 03:00). (TMYK) 
I'd say you could roughly guesstimate what it's likely to drop in a day (the drop off for me seems to slow right down the lower the free memory gets) and add that figure to the value you initially had in mind for the reboot taking place.
Sure... but for what gains?
We're making this so complex when there's no loss to rebooting it nightly.
i have a rule that checks if it below 140 as that is when i saw sluggish behaviour.. also it has to be that way for 2 checks and hour apart as it can drop low during nightly maint etc but come back up.
1 Like
