Elk M1 panel lovelace UI not accepting arming code

[caseyd]

The problem

when using the lovelace Panel UI entering the user code and selecting arming type doesn't work. the ui panel clears the entered user code text and does not change the M1 state. the ui panel does correctly show the M1 state, as confirmed by manually using the same code on a hardware panel to arm and disarm the system the elkm1 integration is properly tracking senor state from the M1 hardware.

What version of Home Assistant Core has the issue?

core-2024.1.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ElkM1

Link to integration documentation on our website

https://www.home-assistant.io/integrations/elkm1

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

running elk's debug logging this is emitted for both safari and firefox when attempting to arm via the UI keypad:

2024-01-13 15:05:02.707 DEBUG (MainThread) [elkm1_lib.connection] write_data '0Da41009854002C'
2024-01-13 15:05:02.778 DEBUG (MainThread) [elkm1_lib.connection] got_data '17IC000000000000004080070'
2024-01-13 15:05:02.838 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD12990041150501130007240045'
2024-01-13 15:05:02.898 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD13200041150501130007240054'
2024-01-13 15:05:02.968 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000001111111100000000000E'
2024-01-13 15:05:03.008 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F'

Additional information

there are also errors such as this, for both tested browsers: 2024-01-13 14:03:54.860 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:03:55.790 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:03:56.398 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:03:56.496 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:04:05.930 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:04:05.958 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error. null @:0:0 2024-01-13 14:04:05.977 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Safari 13.1 on Mac OS 10.15.4 Script error.

====

2024-01-13 14:51:10.603 DEBUG (MainThread) [elkm1_lib.connection] got_data '17IC000000000000004080070' 2024-01-13 14:51:10.663 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD12990041145101130007240045' 2024-01-13 14:51:10.723 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD13200041145101130007240054' 2024-01-13 14:51:10.783 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000001111111100000000000E' 2024-01-13 14:51:10.823 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F' 2024-01-13 14:51:25.586 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK24511471301240100072' 2024-01-13 14:51:55.592 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK5451147130124010006F' 2024-01-13 14:52:25.598 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK24521471301240100071' 2024-01-13 14:52:55.624 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK5452147130124010006E' 2024-01-13 14:53:25.630 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK24531471301240100070' 2024-01-13 14:53:54.002 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:54.923 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:54.967 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:55.044 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:55.257 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:55.601 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) 2024-01-13 14:53:55.658 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK5453147130124010006D' 2024-01-13 14:53:55.938 ERROR (MainThread) [frontend.js.latest.202401040] Uncaught error from Firefox 121.0 on Mac OS 10.15 TypeError: e is undefined keyFunction (src/components/data-table/ha-data-table.ts:362:52) item (src/virtualize.ts:116:53) r (src/directives/repeat.ts:56:28) ct (src/directives/repeat.ts:93:52) update (src/directive.ts:134:16) $AS (src/lit-html.ts:1085:23) S (src/lit-html.ts:1362:12) _$AI (src/async-directive.ts:366:18) setValue (src/virtualize.ts:139:13) dispatchEvent (src/Virtualizer.ts:808:23) null

[home-assistant[bot]]

Hey there @gwww, @bdraco, mind taking a look at this issue as it has been labeled with an integration (elkm1) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `elkm1` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign elkm1` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

elkm1 documentation elkm1 source _{^{(message by IssueLinks)}}

[caseyd]

just tested disarming; works as expected.

[gwww]

Can you try arming using a service. alarm_control_panel.alarm_arm_away is one you could try. I suspect that this is a frontend issue from looking at the logs and that would confirm it.

[caseyd]

I am unable to arm using the service, however I can change the text on all the panels. service: Alarm Control Panel: Arm Night target: ElkM1 Badu HQ ( which is control panel 1 ) code: our code

I get a green check but nothing happens on the physical panel, and the alarm system remains unarmed. when I examine the panel it reports 'Ready to Arm'

the generated yaml looks like this:

service: alarm_control_panel.alarm_arm_night target: entity_id:

• alarm_control_panel.elkm1_badu_hq data: code: "*****"

code is correct ( not sure how to drive indentation here )

[gwww]

I just test arm away from developer tools and it works for me.

Has it ever worked?

Have you tried arm away instead of night?

Can you share the debug logs when calling the service from the developer menu.

Was there anything in the ElkM1 system’s log?

Can you try in Chrome. Only say that because the log you provided had JS errors in Safari.

[caseyd]

WFM. gotcha. when I use the services too to arm I get a green check for 'success' but no change on the alarm system itself. QUESTION: I should be sending this service call to the alarm panel entity for 'zone 1' correct? that's where I sent the string changing the display label...

1. has it ever worked: yes. that's why I expected it to work. I will roll back to an earlier version; I have a 'spare' cached away on another proxmox box.
2. can try later today; tricky when the house is full of people. I'm pretty sure I've flailed at all M1 states. Remember if I arm the panel manually I can disarm it from the UI
3. yes.
4. hmm, good idea. I'll fire up the windows VM which I use to manage it and take a look.
5. in the sentence before the big paste bomb I mentioned that I had tried firefox as well. the logs are the same except for the user agent. FWIW I've also tried it with FF on debian, no luck. I'll see if I have chrome on a sacrificial machine around here. when I do item 4 I'll also poke at it from Explorer.

in the browser console I can see the request from the services call go out:

> Sending 
> Object { type: "execute_script", sequence: (1) […], id: 53 }
> ​
> id: 53
> ​
> sequence: Array [ {…} ]
> ​​
> 0: Object { service: "alarm_control_panel.alarm_arm_night", data: {…}, target: {…} }
> ​​​
> data: Object { code: "9854" }
> ​​​
> service: "alarm_control_panel.alarm_arm_night"
> ​​​
> target: Object { area_id: "callcenter", entity_id: "alarm_control_panel.elkm1_badu_hq" }
> ​​​​
> area_id: "callcenter"
> ​​​​
> entity_id: "alarm_control_panel.elkm1_badu_hq"
> ​​​​
> <prototype>: Object { … }
> ​​​
> <prototype>: Object { … }

and the response, which is null.

[gwww]

I can’t talk to JS logs. That said it feels like there’s something happening frontend that’s causing this. So, I’m trying to find proof something is wrong with the integration.

Logs will be the best help. Send the log when you try and arm. Also send logs for when you disarm. Do both using developer tools.

To your question above the entity should be alarm_control_panel and whatever area you are arming.

Skip testing on Chrome since you’ve already tried two browsers.

[gwww]

I just took another look at the debug logs above.

The first message is arm night and contains a presumably correct code.

The 5th message is AS which is arming status and show no arming is taking place. That is preceded by two LD messages which suggest the panel did not like the arm command. I don’t have time to look them up right now but that seems suspicious. You can look at the logs on your ElkM1.

I will have more time on the weekend to dig deeper if your investigation doesn’t yield new info.

[caseyd]

hi GWWW, I'll do the rollback after my radio meeting ( currently happening )

[caseyd]

[image: HA_Elk issues.png] weird state. notes. I'm checking the M1 logs next... hmm. this is a mix of me using the UI (16:17? ) and the physical keypad.

[image: image.png] I will turn off duress option for the user Jarett.

here I arm it from ElkRP, and disarm it from a keypad down near my office. [image: image.png]

ok hmm. now I disconnect ElkRP from system, use HA Elk integration to attempt to set code. same unfortunate behavior, then disconnect to ElkRP [image: image.png] no logging of events from HA Elk UI

I think I will next simply remove the ElkM1 integration and re-install it.

---

(aggregation account, which means I check it every few days for email from various accounts) @.***

On Tue, Jan 16, 2024 at 7:30 PM Glenn Waters @.***> wrote:

I just took another look at the debug logs above.

The first message is arm night and contains a presumably correct code.

The 5th message is AS which is arming status and show no arming is taking place. That is preceded by two LD messages which suggest the panel did not like the arm command. I don’t have time to look them up right now but that seems suspicious. You can look at the logs on your ElkM1.

I will have more time on the weekend to dig deeper if your investigation doesn’t yield new info.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/107990#issuecomment-1894879920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYRK3DVNGFYUMOIXY3IWTYO5AVVAVCNFSM6AAAAABBZUM35SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUHA3TSOJSGA . You are receiving this because you authored the thread.Message ID: @.***>

[HerveB]

Correction - issue resolved on my end: I THOUGHT I had the same issue. I lost the ability to arm or disarm my ELK M1 Gold using the keypad GUI in Home Assistant. Everything else involving the ELK integration still works.

BUT, I noticed that one of by motion sensor had a problem and the zone was reported as such. After disabling the zone in question, the panel in HA allowed me to arm and disarm my alarm system.

[gwww]

Can you try using developer tools and using the alarm_control_panel.alarm_arm_away service to arm.

If that does not work, then turn on debug logs for the Elk integration, and try again. Provide the logs.

[caseyd]

quick peek via web UI after service called, debug enabled:

2024-01-21 12:06:20.419 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000001111111100000000000E' 2024-01-21 12:06:20.479 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F' 2024-01-21 12:06:21.903 DEBUG (MainThread) [elkm1_lib.connection] got_data '0AZC017B00B8' 2024-01-21 12:06:21.960 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000000111111100000000000F' 2024-01-21 12:06:22.012 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F' 2024-01-21 12:06:32.852 DEBUG (MainThread) [elkm1_lib.connection] got_data '0AZC032B00BB' 2024-01-21 12:06:35.453 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK3306121210124010007B'

full log below

[caseyd]

home-assistant_elkm1_2024-01-21T20-15-18.426Z.log

[gwww]

After the sync with the panel is complete, there are 0 writes to the panel. A write is used to arm the panel. For example you should see something like write_data '0Da11001234003F', which is arm area 1 in away mode (a11) with user code 1234 (001234). 0D is a message length. and the trailing 003F is two spare bytes and checksum (you can ignore them).

Can you try again? Do a restart of HA before attempting. Might as well try both using the HA keypad and the service.

[caseyd]

ok here is what I will do; just to be sure we;re on the same page

1. re-enable debug mode for the integration
2. full restart of HA
3. do service call
4. do HA Alarm Panel UI
5. so service call to change message ( which has worked )
6. arm panel from panel hardware
7. disarm panel from HA Alarm Panel
8. disable debug
9. send log.

LMK if that's in sync with your expectations and helpful.

Glenn, did you get the attachemnts in my earlier email? no writes are seen on the Elk logs as well. However state in HA shows arming; and infact doesn't show hardware panel disarming.

[gwww]

1. Restart HA
2. Enable debug through the UI (on the Elk device page in Devices)
3. Arm using UI
4. Disable debug through the UI
5. Capture log.

Repeat except for #3 now being arm using service call.

Send two log files. If you do cut/paste (instead of sending files) then please use the paste as code using the triple backticks.

[caseyd]

home-assistant_elkm1_2024-01-21T22-40-18.091Z_SERVICE_CALL.log home-assistant_elkm1_2024-01-21T22-42-30.872Z_HA_PANEL_UL.log

there we are, named as created

[gwww]

Something funky going on.

In all of the logs the sync of the panel never completes. Kind of looks like a deadlock of the write queue. It happens at exactly the same place in all three logs. If indeed it is a deadlock that explains why arming would not work -- writes are no longer happening!

Could you try arming on 2023.12 and see if that works?

@bdraco Do you know of any changes between 2023.12 and 2024.1 that might explain this? Was there a change in the Python version (I have no idea where to look)? The area of code I'm looking at is https://github.com/gwww/elkm1/blob/main/elkm1_lib/connection.py#L109. There's a goodly use of async stuff in there.

[gwww]

Another request @caseyd. The funky after looking deeper is not funky. At least the code I was looking at is working as expected. I now have another theory, which will help understand what is happening, but I don't think will help understand why.

One more log. Pick using UI or service call. Doesn't matter. Same sequence as before with one small change. Before arming wait 3 full minutes (longer ok too) for the system to be up and running. Then arm. Then turn off debug and send log.

For some reason on your system I'm not seeing the sync_complete which triggers creating the elements. I'm pretty sure that is the problem. The log will turn the pretty sure to a certainty. I just have to figure out why next.

[gwww]

Ignore the request in the previous message. I have new procedure for capturing the log.

1. Turn on debugging as documented here: https://www.home-assistant.io/integrations/elkm1/#debugging
2. Restart HA.
3. Wait at least 3 minutes (there's a 120 second timer I want to see if it is triggering)
4. Arm system using whatever method you like.
5. Capture log.
6. Send log.
7. Turn off debugging by removing config added in step 1
8. Restart HA.

[caseyd]

starting in on this most recent request. I will wait 3 min after restart.

home-assistant_elkm1_2024-01-24T22-11-24.727Z.log

the Elk entries don't seem much different. I don't see a response from the M1.

a few min later I re-enabled logging and used the UI to arm.

2024-01-24 14:19:48.883 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK4719144240124010006A'
2024-01-24 14:20:18.910 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK16201442401240100076'
2024-01-24 14:20:25.066 DEBUG (MainThread) [elkm1_lib.connection] write_data '0Da41009854002C'
2024-01-24 14:20:25.139 DEBUG (MainThread) [elkm1_lib.connection] got_data '17IC000000000000004070071'
2024-01-24 14:20:25.201 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD13190041142001240004240051'
2024-01-24 14:20:25.270 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000001111111100000000000E'
2024-01-24 14:20:25.310 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F'

but no change in M1 state.

[gwww]

As far as I can tell, the integration is doing exactly what it is supposed to...

In the 0D a4 1 009854 002C message a4 says arm to night mode, area 1, user code 009854 -- assuming the user code and area are correct then the system should arm. The fact that it is not tells me that the ElkM1 doesn't like something about what you told it or that it is configured incorrectly.

The 17 IC 000000000000 004 07 0071 message says that the user code sent was valid (that's the 000000000000 - all zero means correct user code, non zero contains the incorrect code) and was for user 004 (Jarett), keypad 07 (I'm not sure why 7 since this is sent through the API). I'd say this is as expected.

Next up is 1C LD 1319 004 1 142001240004240051 which is a log message generated from the Elk. 1319 is keypad 7 log message, 004 is user 004, followed by area 1, and the rest is date/time stuff along with a log number. All good here.

Next is 1E AS 00000000 11111111 00000000 000E which is arming status and has 3 8-byte arrays where each byte is for an area. We only care about area 1 thus only care about the first byte of each of the arrays. The first array is armed status, and is 0, which is disarmed. The second array is arm up state, and is 1, which is ready to arm. The third array is alarm state, and is 0, which is no active alarm. This is the "money" message - you asked the system to arm with the a4 message and it came back with this message and basically said nothing changed. So, the only thing I can conclude is that there is something wrong in your ElkM1 config as the integration, I believe, has done exactly what it should and it got back results that are also correct - even if not the desired result.

Did you change ANYTHING at all on the panel in the since it stopped working?

Do other user codes work? Do other arming modes work, such as arm away?

Can you check that you've met all the requirements here: https://www.home-assistant.io/integrations/elkm1/#elkm1-configuration-and-version.

[HerveB]

starting in on this most recent request. I will wait 3 min after restart.

home-assistant_elkm1_2024-01-24T22-11-24.727Z.log

the Elk entries don't seem much different. I don't see a response from the M1.

a few min later I re-enabled logging and used the UI to arm.

2024-01-24 14:19:48.883 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK4719144240124010006A'
2024-01-24 14:20:18.910 DEBUG (MainThread) [elkm1_lib.connection] got_data '16XK16201442401240100076'
2024-01-24 14:20:25.066 DEBUG (MainThread) [elkm1_lib.connection] write_data '0Da41009854002C'
2024-01-24 14:20:25.139 DEBUG (MainThread) [elkm1_lib.connection] got_data '17IC000000000000004070071'
2024-01-24 14:20:25.201 DEBUG (MainThread) [elkm1_lib.connection] got_data '1CLD13190041142001240004240051'
2024-01-24 14:20:25.270 DEBUG (MainThread) [elkm1_lib.connection] got_data '1EAS000000001111111100000000000E'
2024-01-24 14:20:25.310 DEBUG (MainThread) [elkm1_lib.connection] got_data '0CAM000000007F'

but no change in M1 state.

Have you check you don’t have issue with any zone in you Elk system? In my case, I found that one of my motion sensors had a problem which prevented to arm the alarm using HA and the ELK keypad. Silly miss on my end but I hardly use the Elk keypad. Disabling the zone solved the problem.

[caseyd]

Users have the following attributes: Areas 1-8, Arm, Disarm, Bypass, Access, Temp, Master, Menus 1-5, Duress.

The code of Users with the "Master" attribute fail to arm as I have described. ( I haven't iterated across the attributes Access->Duress. )

The code of Uses w/out the "Master" attribute will successfully arm using this integration.

the hint came from this support article: https://www.elkproducts.com/forums/topic/arming-by-only-entering-user-code/