search

gazoscalvertos / Hass-Custom-Alarm

Yet another take on a home assistant custom alarm
221 stars 94 forks source link

alarm sets itself every time I restart home assistant #77

Closed adipose closed 5 years ago

adipose commented 5 years ago

Describe the bug The alarm sets itself every time I restart home assistant. After restarting, if I open the alarm interface, it starts counting down as if I had just armed it.

To Reproduce Steps to reproduce the behavior:

  1. Disarm alarm
  2. Go to configuration / general / restart home assistant.
  3. Wait for restart of home assistant
  4. Click on "Alarm"
  5. Alarm is arming

Expected behavior The alarm should be in the previous state

This may be related to mqtt in some way.

akasma74 commented 5 years ago

HA/alarm version? Any patches/PR applied? I cannot reproduce it..

adipose commented 5 years ago

Currently 0.89.1, alarm 1.3.6. But it was happening on .88 and .87 as well.

I have applied the patch for the entity_id mispelling (entityID) but it didn't help or change anything.

I turned persistence on and off, but this didn't help either.

akasma74 commented 5 years ago

HA version is not that important, but you need to give versions from bwalarm.py and alarm.html. The patch for entity_id should not cause this behaviour.

adipose commented 5 years ago

alarm.html:

https://github.com/gazoscalvertos/Hass-Custom-Alarm VERSION: 1.3.6 MODIFIED: 10/02/19

bwalarm:

CUSTOM ALARM COMPONENT BWALARM https://github.com/gazoscalvertos/Hass-Custom-Alarm

VERSION: 1.1.4 MODIFIED: 10/02/19

adipose commented 5 years ago

I also applied this patch to bwalarm, but the same behavior was there before and after I applied it:

         if (self.persistence_load() and (self._persistence_list["state"] != STATE_ALARM_DISARMED)):
akasma74 commented 5 years ago

have no idea now to get what is your patch about as there is no details and I'm even lazier than you are ;) Anyway, there were so many PRs since 10/02/19.. Have you applied any of them? I can send you link to my working bwalarm.py and alarm.html to try out

adipose commented 5 years ago

Haha, well that one was :

https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/72

The entityid was:

https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/78

This PR is my own--there wasn't one to fix 1.3.6 that I could find. Both issues were minor errors as far as I could tell. I haven't applied any others yet.

adipose commented 5 years ago

Applied / merged https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/68 (no change) https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/67 (no change) https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/69 (no change) https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/73 (no change) https://github.com/gazoscalvertos/Hass-Custom-Alarm/pull/75 (no change)

akasma74 commented 5 years ago

Well, I can only confirm that if I do what you described, it stays in a state it was, everything works as expected. You can either get my sources and see if it makes any difference or debug it yourself/wait for the author to do that for you ;)

adipose commented 5 years ago

Yes, thanks for your help. I've diffed mine against your fork, and it had a few differences. Most were patches I listed above. But none seems to explain this behavior. :-/

adipose commented 5 years ago

I cleared my mqtt messages and the problem went away, for now. Not sure why mqtt never clears sometimes... :-/

akasma74 commented 5 years ago

Hurray! As far as I understand MQTT retains messages if they have retain flag, and they will be there forever unless you explicitly clear them. I believe that's not MQTT fault.

adipose commented 5 years ago

Yes, that makes sense. The messages come from the mqtt alarm control panel. I don't think it would set the messages to persist, but maybe it did...

adipose commented 5 years ago

I'm able to reproduce the issue, now. After clearing all mqtt messages, things are working fine. Then I send an mqtt command from mqtt alarm control panel. Later, I disable the alarm via home assistant. The mqtt "home/alarm/set" topic remains at "ARM_AWAY". The next time it subscribes (when restarting hass), it will get an ARM_AWAY command.

I think the the alarm should update the set topic when it disarms. This topic appears to be retained. Although the state topic is ok, it is valid to be both "disarmed" and have a command for "ARM_AWAY."

akasma74 commented 5 years ago

Could you do us all a favour and create a new issue here with a proper title and description? The reason is your description has nothing to do with the initial title and description of this issue, it's more complex.

Hope you understand my point.

adipose commented 5 years ago

Yep, I will do that.

akasma74 commented 5 years ago

Then I send an mqtt command from mqtt alarm control panel.

how exactly do you do that?

This topic appears to be retained.

afaik there is no such thing as "retained topic", you mix it up with "retained message".

Although the state topic is ok, it is valid to be both "disarmed" and have a command for "ARM_AWAY."

different topics, different messages..