Strange MSR behaviours after NAS reboots
-
I am running HA, MSR and ZWavejs2MQTT on a Synology NAS (Docker). When the NAS reboots (after a power outage for example), I see errors (under Status), yellow triangles in front of Rule Sets and yellow bars in front of Global Expressions. See images below.
To give you some context, in some cases MSR writes statuses to HA Helpers. In order cases, MSR just can't seem to find the referenced entities.
Also, note the bevahior under Global Expressions (images below). The one with the yellow bar says, "Invalid reference to member attributes of null". If I click the Try this expression button, the Last value will refresh accordingly and the yellow bar disappears.
Interestingly, everything seems to be working like it should even if I don't do anything. Which is weird.
This behaviour does not happen when the MSR container is stopped and restarted manually.
Anybody experienced this? Thanks
-
Yup. Hass takes a long time to start up, and ZWaveJS2MQTT can as well. I have no visibility into the real progress of Hass, which is one of many reasons I'm working on supporting ZWaveJS directly.
I don't know if this is happening to others, but I can't read most of your screen shots because they are scaled down such that their "expanded" size is the same size as shown in line (and that's to say, too small to read). But I'm pretty sure @kfxo is spot on.
Posts should always include the Reactor version number installed/running.
-
I am running HA, MSR and ZWavejs2MQTT on a Synology NAS (Docker). When the NAS reboots (after a power outage for example), I see errors (under Status), yellow triangles in front of Rule Sets and yellow bars in front of Global Expressions. See images below.
To give you some context, in some cases MSR writes statuses to HA Helpers. In order cases, MSR just can't seem to find the referenced entities.
Also, note the bevahior under Global Expressions (images below). The one with the yellow bar says, "Invalid reference to member attributes of null". If I click the Try this expression button, the Last value will refresh accordingly and the yellow bar disappears.
Interestingly, everything seems to be working like it should even if I don't do anything. Which is weird.
This behaviour does not happen when the MSR container is stopped and restarted manually.
Anybody experienced this? Thanks
@snowman said in Strange MSR behaviours after NAS reboots:
Interestingly, everything seems to be working like it should even if I don't do anything. Which is weird.
So everything ends up working but the visual errors persist? It would be unsettling seeing all those errors even though it works fine.
-
@snowman said in Strange MSR behaviours after NAS reboots:
Interestingly, everything seems to be working like it should even if I don't do anything. Which is weird.
So everything ends up working but the visual errors persist? It would be unsettling seeing all those errors even though it works fine.
-
I stand corrected. After testing several reboots of the NAS, I can now confirm that nothing is working as it should. I need to reset every single Rule Sets and Expressions. Which makes more sense. Not sure where my brain was when I tested this morning. Maybe I needed my coffee first? Sorry about that and sincerely apologizing for the confusion. I'll make sure I test more next time.
This is definitely an issue especially when not around to manually restart MSR.
So I setup the "startup_wait" time to 5 minutes in the MSR config file. I restarted the NAS, and without any science behind it, it took about 4 minutes and 55 seconds for HA to display its (system is up message) and 5 seconds later, MSR displayed its Connected status.
No errors under Current Alerts. All working as expected. I will set the delay to 6 minutes to be on the safe side. Hopefully this work around can ensure MSR and HA can tango together.
-
I think I have a real solution for this. As part of the work on ZWaveJSController, I had to make some changes (fairly significant) that I think would stabilize entities when controller initializations are slow as you are seeing here. Most Reactor restarts occur when the hub is already running, but as you've found out, when everything comes up at once, there are nearly infinite ways things can be out of sequence or temporarily missing. Since Z-Wave and its devices can be so much more unpredictable than a running hub, at startup and during normal operation, some changes were needed. The ZWaveJSController testing folks have been using a separate version of Reactor that contains these changes, which I myself have been using for months, and I haven't heard of any issues that could be related to those changes, so I think it's about time I can bless them and put them into the mainline code branch and releases. Perhaps within the next week or so.
By the way... five minutes to restart Hass? Whiskey tango...