Moving MSR from a QNAP container to RP 5 - some issues

[RogerO]

Hello,

Likely this is already in MSR, but I am trying to catch when Home Assistant crashes in MSR and power cycle the Pi it is running on. I have something causing instability in my Home Assistant and it becomes unresponsive once or twice a day. In MSR I get a red alert on the title bar and in the current alerts, but not seeing how I can use that as a trigger in MSR. What should I be monitoring?
Thanks,

[toggledbits]

Second time today this question was asked, each for a different platform, but the answer is the same.

I really want you guys to think about this. Two things to consider:

1. Since you can easily write conditions based on the changes of attributes to entities, is there an entity that maps to your system controller instance, and does it have attributes that might help? (Hint: yes)
2. Recently, the alerts data were added as attributes of the Reactor System entity, and this discussion ensued. I won't say this is the recommended way to get it done; it's the lesser of the two in my view, but it is a possibility. And that conversation/thread actually began with exactly the same question that started this one.

[wmarcolin]

@toggledbits done!

Thanks!

[toggledbits]

Well, that's one way. Not the best way IMO, but it works. It has the advantage of capturing a lot of different circumstances, not just the one you asked about.

By the way, you have installed the recommended here and here Hub Information app, right?

[wmarcolin]

@toggledbits yes, all!!

  - id: hubitat
    enabled: true
    implementation: HubitatController
    name: Hubitat Elevation system
    config:
      # Copy the entire URL from the Maker API app page on your Hubitat UI. A quick, easy way is to
      # right-click the "Get All Devices" link and choose "Copy link location", the paste it below.
      source: "http://192.168.33.22/apps/api/131/devices?access_token=fc________________65"
      #
      # dump_all_devices - This is for troubleshooting. Do not enable unless asked.
      dump_all_devices: false
      # OPCIONAL TEMPORIZADOR ENTRE ACOES - 0,500s entre acoes - ou 2 acoes por segundo
      action_pace: 100
      warn_unresponsive: true
      probe_device: hubitat>132
      probe_action: x_hubitat_Configuration.configure

I limited Hubitat's warning, because there have been no other mistakes, so when it happens, I will understand and take action.

I also have yet to explore the gain of having monitoring by Hub Information, which can really help me keep up with the platform. I understand that for the connection issue it helps, now what else could it be doing that would be useful? Any suggestions?

Thanks.

[toggledbits]

If you have Hub Information installed and have created a device for it, and published that device in Maker API, you do not need to set probe_device or probe_action — HubitatController will know what to do with the device when it sees it.

Hub Information will , for example, let you make a rule that notifies you when an update is available (assuming you don't regularly log in to your hub's UI to see that). Browse the attributes in the entity. See what you might find, and let your imagination run wild!

[toggledbits]

OK, what's missing here is that the fastest and simplest way to see if a hub connection is to check the sys_system.state attribute on the hub's system entity (all controllers make two entities by default: the system entity, and a group entity). If it's false, the hub connection is down; if it's true, the hub connection is up. Some hubs have additional capabilities and attributes:

• VeraController — x_vera_sys.reloads increments/changes every time Luup reloads;
• HubitatController — x_hubitat_sys.reconnects increments/changes every time Reactor has to reconnect to the hub;
• EzloController — x_ezlo_sys.reconnects increments/changes every time Reactor has to reconnect to the hub; x_ezlo_sys.restarts increments/changes each time the hub reloads/restarts;

These can be more specific, and easier, tests than scanning the alerts array on the Reactor System device (which is why I prefer these over that method). You will also get fewer "false positives", as the approach @wmarcolin shows will catch any notification with the word "Hubitat" in it, and those may not all be connection-related.

[wmarcolin]

@toggledbits hi!

I had already created the rule with sys_system.state before, adding this control for the message is a plus that I am putting in case any more Hubitat warnings appear.

Regarding the previous message, I will then remove the probe_device from the configuration, because I followed your recommendation and installed the Hub Information > created a device to receive the information > and published it in the Make API. I will put together this update tip, I think it is worth it. Thanks.

[wmarcolin]

Master @toggledbits

Following the line "I show you the way, I don't give you the transport":), the MSR indicates in Entities the time of the last device status change. Where is this information stored?

Use case: I want to monitor all devices, and the ones that are not communicating for more than 48 hours should know and take action.

For sure there are some that can not even, because it would be a problem, then I create an exception list. But initially, I want to see everything that has not been communicated in 48 hours.

The principle is almost the same as Hubitat's WatchDog APP, but I want to have my own, and not be dependent on Hubitat's communication or action. I also understand that it has more validity, because it is a way to ensure that the MSR is talking to all devices, and not only to Hubitat.

Thanks.