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).
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
Is that definitely the case? I don't like rebooting it too frequently. After a reboot all devices show everything as 'unknown' in Z Wave Mesh Details until they've received a command (digitally) from the hub. Many of my devices are behind dumb switches so they can stay in that 'unknown' state for days. Because of that I've a tendency after a reboot (or update that does one) to go through my dashboard switching every light and device on/off to generate the command and populate the values.
1 Like
Maybe it's running Windows 95 under the hood?
Nope. Worse. FAR worse.
It's built on Java. 
Well, I can't tell you how long it took, but my hub has been up for a little over eight hours and every device is showing as "OK" on the Z-wave mesh details page. That's with about 85 z-wave devices, most (I think I might have one or two that isn't) Z-wave+.
I'm not sure I understand what you mean by "behind dumb switches" - do you mean that they are sometimes not powered?
No they’re permanently powered Z Wave Dimmer modules. They’re all ok, everything works, there’s just no values present for RTT, RSSI etc until the hub sends a command to them. I’ve noticed that often they don’t jump to an optimum route until after a command is sent and those values populate. I speed that up by switching the devices on from the dashboard or device page as some may not receive a command for a long time otherwise. That’s just my observation
Honestly, I think you're delving into it further than is necessary.
If the device still turns on and off from the dashboard, it's connected well-enough, even if you don't have stats on its connection.
If you really wanted, you could add a Rule to refresh all devices when the device is rebooted. A refresh should be enough to trigger what you're hoping to have populated. I keep a rule like that around (for manual execution) anyway for the odd time when the hub gets out of sync with devices.
1 Like
