After updating to 0.9.6.21 - panel not responding to commands

EyalRotem commented 2 months ago

This has been a hit and miss. i don't know what triggers the issue., only that that commands are not executed every once in a while. the previous version worked flawlessly (0.8.5.2).

My panel is a Power Master 10. I only updated after all the bug fixes versions came out. but it seems a bit unreliable for some reason.

attached is a long log. at the beginning it worked, than, at the end (2024-08-12 10:40:55), commands are send but not executed. I reloaded the integration, and than after some waiting, it works again.

home-assistant_2024-08-12T07-57-34.271Z.zip

.

_one thing to note-probably not related, the update generated a new alarm panel entity named "visonic_alarm", all my automations used "visonic_alarmpanel", so i changed it to that name. no idea if it may have any impact.

cmyasl commented 2 months ago

Hi Dave. Fantastic job. More or less, same here. With last updates (20 & 21), system is full stable, without disconnections, no more "Panel Problem Count" . But can´t anymore arm or disarm from HA. I have completely uninstalled, and reinstalled. It doesn´t give option :

cmyasl commented 2 months ago

Good news !!! I left the integrarion running since yesterday, just gathering information from the panel. Just now, the configuration window has given all the options. Even arm/disarm without code. It works like a charm...

EyalRotem commented 2 months ago

The issue I described is different than yours, anyway, glad it worked out for you.

Dave, I hope you could look at the log ad maybe point out what should I try, much obliged

davesmeghead commented 2 months ago

Hi,

I'm just catching up as I've been away from home for a few days. Gimme a little longer and I'll look at the log file.

I suspect I know what the issue is, are you able to grab a dev release from Github to try it, not the current Dev release, as I said gimme a bit of time.

Dave

EyalRotem commented 2 months ago

Sure, I would be able to do any testing, although I’m in reserve military duty on/off, I’ll find time once I’m home.

it does seem to be inconsistent a bit though.

take your time💪🏼

davesmeghead commented 2 months ago

Hi I've just uploaded a dev_B0 release to github.

You can download it here https://github.com/davesmeghead/visonic/tree/dev_b0

Select the green code and then download zip.

You then need to go to your Home Assistant config directory (where the log file is located) and go into custom_components, replace the visonic directory with the visonic directory in the zip file.

Restart Home Assistant

Dave

EyalRotem commented 2 months ago

I’ll try it as soon as I get back home.

I’ve never used the B0 configuration before, may I ask how it may relate to the issue?

davesmeghead commented 2 months ago

Hi, Only PowerMaster Panels generate B0 message data and they expect the Integration to handle them as well as the other messages, so I've been improving the decoding of the B0 data with help from someone else. As you have a PM10 then you've been using it, you just didn't know. This dev_B0 release also increases the rate that data is sent to the panel as I suspect there's a backlog of messages not getting sent, I've seen it recently in my testing and this fix sorted it. So for you it should be an improvement in both cases. Dave

EyalRotem commented 2 months ago

hi dave, thanks for explaining.

i tried the dev_b0 version, here's what i experienced:

upon initial loading of HA, it created a new panel entity (visonic_alarm_2)
after loading initially - panel status was "triggered" (whilst actually staying armed_away)
i reloaded the integration and it briefly updated to disarmed, than armed away, than "triggered"
i did a reset to the esp device, reloaded the integration -still the status is "triggered" home-assistant_2024-08-15T22-20-18.550Z.zip

as i am away from home i cant reset the panel itself unfortunately. let me know if i need to do something differently, like maybe settings up the alarm panel from scratch and enabling the b0 option.

davesmeghead commented 2 months ago

Hi, Thanks for giving it a go and thanks for the log file.

The Panel Entity name is a real conundrum for me, I just don't understand it. I can see from the log file that I ask Home Assistant to create alarm_control_panel.visonic_alarm on row 33 of your log file.

I've spotted the bug in the code and I've uploaded release 0.9.6.24 to dev_B0, can you try this release please, I had a time calculation the wrong way around.

It was detecting that a sensor was triggered when it wasn't. The first time it tried to get the EPROM it failed and assumed Standard Emulation Mode. Whilst in this Mode (with the bug) it wrongly detected a motion sensor was triggered and therefore the panel is triggered. When you restarted it, it defaults to Disarmed until it gets the panel state i.e. Armed Away. And again it assume the panel was triggered.

Dave

EyalRotem commented 2 months ago

thanks for taking a look so quickly. i installed the 24 version, and behavior was still weird. log attached home-assistant_2024-08-15T23-51-36.282Z.zip

davesmeghead commented 2 months ago

Hi In the background I've been rewriting the low level interaction with the panel to centralise it and make it easier for me to understand and debug. I've just uploaded dev_B0 Release on Github, please give it a try Thanks for your help Dave

EyalRotem commented 2 months ago

i tried, it again loaded into triggered mode. tried resetting the esp device and reloading and it seemed to fail during the downloading stage. home-assistant_2024-08-17T16-43-01.586Z.log

davesmeghead commented 2 months ago

Thankyou for trying it straight away.

First of all I've just uploaded a bug fix for the failure in the downloading stage. In the past if it failed to download any of the EPROM then I just stopped and went to STANDARD Mode. In this new version I retry a number of times to get the EPROM and that's what failed in the code. The first time it got your EPROM without a problem, the second time it didn't and so found a bug in my retry code. I think I've fixed it.

Secondly, about the sensors being triggered on startup. This is an Issue that I'm not sure how to solve, and is specific to PowerMaster panels. Let me explain and perhaps you can comment please.

I don't want to get too technical but here goes....

PowerMax panels only send an A5 message to tell me when a sensor has been tripped. The information is basic but obvious and fairly quick from the Panel.

PowerMaster panels send either an A5 message or a B0 message. Most of the time it's a B0 which gives me a problem. It doesn't actually tell me that the sensor has been triggered, it tells me the time that it was last triggered. So the first time I get the message I don't know whether it's just been triggered or whether it was triggered 10 minutes or whatever before you started running the integration. I think I can fix it by getting the panel time and trying to compare it. Anyway, historically in old versions, the first time a sensor if triggered and I get a b0 then I just ignore it, so sometimes the first trigger of a sensor would be missed. In the current dev release I trigger on first running the integration until I can do a fix.

So after all that, can you assume that it will trigger some/most/all sensors on first running the integration (depending on whether I get an A5 or a B0.

One more thing, A5 can only do sensors 1 to 30 and so are no use for PowerMaster 30 panels. B0 messages cover sensors 1 to 64 for these panels.

Thanks again for testing Dave

EDIT: You also have your trigger duration set to 2 minutes so wait a while for them to clear.

davesmeghead commented 2 months ago

Just to add a bit more about the B0 message I mentioned, and this might get confusing as there are different types of B0 messages When a sensor is triggered,

the panel sends a different "control" B0 message to tell me that the panel has changed its "sensors" status,
so I do, I ask the panel for the "sensors" message(s) and
this is how I get the sensor B0 message that I mentioned int the previous post.

That is why there's a bit longer delay between the sensor being triggered and showing up in HA. Dave

EyalRotem commented 2 months ago

Thanks for all the explanations!

I will say this-

My setup has way less sensors than 30.
i think it’s safe to assume that the first trigger won’t be on startup, though comparing time stamps might be the ultimate way for some edge cases.
regarding the current behavior - so once it triggers Shula I disarm and re-arm for example? In that regard I want to add that my test were all done while armed away and I’m not at home.
Trigger duration is a panel setting, right? Tia means that no matter what it will stay triggered for 2 minutes at least?
I will try again, and update once I have data

I really like you explaining and diving into the technical stuff. Don’t hold back.

Eyal

EyalRotem commented 2 months ago

ok, attached are 2 logs -

the .1 log is the older one and it is a result of the following steps:
- alarm was disarmed prior to installation of the new version.
- than i armed it (home).
- reset the esp device and integration
- it resulted in a triggered mode.
- i disarmed, armed few timed, worked as expected
the other log is the newer one:
- this one loaded while alarm was armed
- it loaded as triggered as expected for this version.
- disarmed, armed - works as expected.

some observations:

this version seemed to fix the eeprom download issue i had.
powerlink mode is reached very fast i think.
alarm only triggers when it loaded in armed mode

let me know if the logs provide you some more insights. as for the logic for the triggered sensors - i think that your suggested condition for timestamp comparison is best. but if for some reason it proves unreliable - i would check if the panel is armed, if so - ignore the initial sensor trigger date. as system reset during triggered alarm is an extreme edge case (at least in my use case). also - in my setup at least, i have a gsm module that notifies me via mail/sms/phone, i guess others might have redundancy too. anyway, since you have more experience i will let you decide whats best. maybe even add the logic as a checkbox for the integration setup.

thanks again!

ha_logs.zip

davesmeghead commented 2 months ago

Thanks for the logs and the info, really really helpful.

I've just uploaded latest to Github, dev_B0 with these release notes Updated New Sequencer for EPROM Download and Enrol Updated triggering control of Motion/Camera Sensors (may not work if not in the UK as it uses UTC timezone and I've only tested here in the UK) All time sources/values have a timezone associated with them.

Give it a go please if you can Thanks Dave

EyalRotem commented 2 months ago

Hi dave, after updating, most things work as expected, but i did see some weird things.

at around midnight i restarted and it seemed to get into standard plus mode this morning i looked and saw it is in powerlink mode, but also it was triggered for most of the night until disarming in the morning.

home-assistant_2024-08-20T03-52-50.627Z.zip

davesmeghead commented 2 months ago

I've just uploaded a new dev_B0 Release on Github, please give it a try Dave

EyalRotem commented 2 months ago

Hi Dave, I’ve updated and did a little test regarding the triggered state, it seems to be ok now. Will update if there are any issues.

2 other questions:

When the system loads and the alarm state is unknown (while downloading eeprom) - it displays as “disarmed”, I think that it would be more intuitive if it just says “unknown”/“unavailable” as it better represents the actual knowledge of the state. Issues may arise when automations trigger when changed to or from “disarmed”. This only matters when the system restarts and alarm is armed.
what is the “bridge interface” you introduced?

davesmeghead commented 2 months ago

OK, just let me know either way so if it's working I can close this issue.

1) I'll take a look and see what HA does with unknown states for Entities 2) It's a secret at the moment, soon though :secret: :smirk:

EyalRotem commented 2 months ago

ill give it a few more days to see its working fine, than I’ll make sure to close it💪🏼

I found something that might be relevant in pyvisonic.py at line 1294. But I’m unsure of it’s relevance
It might be the powelink module bridge then?? exciting!

davesmeghead commented 2 months ago

OK For 1) in const.py if you can edit it Change map_panel_status_to_ha_status to this

# For alarm_control_panel and sensor, map the alarm panel states across to the Home Assistant states
map_panel_status_to_ha_status = {
    AlPanelStatus.UNKNOWN     : STATE_UNKNOWN,
    AlPanelStatus.DISARMED    : STATE_ALARM_DISARMED,
    AlPanelStatus.SPECIAL     : STATE_UNKNOWN,
    AlPanelStatus.DOWNLOADING : STATE_UNKNOWN,
    AlPanelStatus.ENTRY_DELAY : STATE_ALARM_PENDING,
    AlPanelStatus.ARMING_HOME : STATE_ALARM_ARMING,
    AlPanelStatus.ARMING_AWAY : STATE_ALARM_ARMING,
    AlPanelStatus.ARMED_HOME  : STATE_ALARM_ARMED_HOME,
    AlPanelStatus.ARMED_AWAY  : STATE_ALARM_ARMED_AWAY    
}

AlPanelStatus.SPECIAL is used when, for example, you do a walk test with the panel, or enter the Installer Menu so try these as well. If you think it's OK then I'll keep it like this EDIT: Scratch that, entering the Installer Menu leaves the panel in the state it was in, that's why it's not in the above list, you can't change panel state while in the installer menu.

No comment on 2) :smile:

davesmeghead commented 2 months ago

Oh damn, I just realised that as HA could be restarted whilst the panel is armed, the previous post and the current functionality isn't right

I think this is how it should be

# For alarm_control_panel and sensor, map the alarm panel states across to the Home Assistant states
map_panel_status_to_ha_status = {
    AlPanelStatus.UNKNOWN     : STATE_UNKNOWN,
    AlPanelStatus.DISARMED    : STATE_ALARM_DISARMED,
    AlPanelStatus.ARMING_HOME : STATE_ALARM_ARMING,
    AlPanelStatus.ARMING_AWAY : STATE_ALARM_ARMING,
    AlPanelStatus.ENTRY_DELAY : STATE_ALARM_PENDING,
    AlPanelStatus.ARMED_HOME  : STATE_ALARM_ARMED_HOME,
    AlPanelStatus.ARMED_AWAY  : STATE_ALARM_ARMED_AWAY,
    AlPanelStatus.SPECIAL     : STATE_UNKNOWN,
    AlPanelStatus.DOWNLOADING : STATE_UNKNOWN,
    AlPanelStatus.INSTALLER   : STATE_UNKNOWN
}

If the user enters walk test, the installer menu or does anything with the panel like that then the state is undefined, including downloading, what do you think?

EyalRotem commented 2 months ago

Actually that’s exactly what I just tested, your constant.py worked good actually.

what is the scenario you think it won’t work as expected?

davesmeghead commented 2 months ago

A couple of things. a) INSTALLER wasn't in the original list so that was a bug, although that would default to Unknown anyway :wink: b) my original list was wrong as it defaulted DOWNLOADING to Disarmed and HA could be restarted while the panel is Armed. But I think the updated list works OK

EyalRotem commented 2 months ago

That’s exactly what my initial issue was, and as iterated, this list works good.

EyalRotem commented 2 months ago

I know I’m a bit straying from the main issue but I think we’re on a roll.. While testing the above, I found that when the alarm was armed, door opened, the state changed to pending (entry delay) and then just to armed (instead of triggered). Then I disarmed it.

527D7765-0A41-446E-A60F-70B0E69194E5

home-assistant_2024-08-24T05-10-55.654Z.zip

EyalRotem commented 2 months ago

hi dave, maybe you missed my last comment, and also, after updating to the latest version (0.9.7.8) - i again have the alarm triggered HA (but not on the panel itself). this happened after restarting HA while the panel was armed

log: home-assistant_2024-08-28T18-24-57.784Z.log

davesmeghead commented 2 months ago

Thanks for the log file, I think that I've fixed it.... I've just released "0.9.7.9 - English Translation File, Logic Updates and Bug Fixes" to dev_B0, if you get the chance please give it a try.

EyalRotem commented 1 month ago

Hi again, using the latest version 0.9.7.10 : still issues such as not responding to commands.

after installing i was testing to see how everything goes. today around ~10:31 i tried arming - but nothing works. after checking it seems to move from PowerLink to StandartPlus and the log is filled with enrolling issues..

home-assistant_2024-09-05T07-44-37.679Z.zip

davesmeghead commented 1 month ago

Hi, I've just released dev_B0 0.9.8.0 as per the main forum. Thanks for the log file, I think that this release should fix this issue. https://community.home-assistant.io/t/visonic-powermax-and-powermaster-integration/316702/538

Please give the release a try and let me know over the next few days whether it still gives problems Dave

EyalRotem commented 1 month ago

installed 0.9.8.0 as it was available. so far so good 💪

davesmeghead commented 1 month ago

I'll close this issue as I've just created a HACS Master release 0.9.9.3. Any further problems (with 0.9.9.3) I'd rather they were in new issues please.

davesmeghead / visonic

After updating to 0.9.6.21 - panel not responding to commands #139