b3nj1
b3nj1
@mdegat01 , No, the add-on starts in the right order. After running for days, the add-on crashed, but it was not restarted by the watchdog mechanism.
> > What did you mean by this then? It just seemed relevant, but maybe it is a red herring. I did **not** initiate anything with the supervisor at that...
Hi @mdegat01 , thanks for trying to reproduce this and the help! > What is different on your end A few years worth of flows :) I have countless flows....
Is it possible that the order of events was: 1. supervisor crashed 2. node-red crashed as a result of 1. 3. supervisor restarted itself And all we see is #2...
I'm using a VM. I look forward to the #3902 fix because my MQTT add-on often does not function on startup of my VM. I was able to get the...
@alwynallan , thanks for the fixes. I'm using this PR successfully.
I'm seeing this too. It seems to happen after we plug our car into our home charger. That's unfortunate since I have automations that manage the charge time & duration,...
Hi @zachowj , thanks for checking. The state is still wrong after refreshing. I just tried again to confirm. So far, the only way I've seen it corrected is when...
Entity type: template sensor of device type lock. I see the mismatch state in both cases: - reboot home assistant, so both HA and NR are cold - while running...
Yes, the **current state** node returns the correct state for the entity even when the global context is wrong.