New Version Testing

[slipx06]

Hi

Firstly new updates look great. I'm busy testing the "new" dev version and noticed that when my alarm is armed in stay mode the "partition status" shows as unavailable. It correctly shows as pending but as soon as the panel is armed, partition status shows as unavailable. The new alarm card shows the correct status

I see that you also removed the partition msg sensor?

[Dilbert66]

Tks for testing. I've corrected the partition status on armed and re-added the missing partition msg sensor. Stuff got changed when I was testing.

A couple things to note, you can use the <> keys when the system is not armed to show the open zones. When you press the key you will then be able to scroll the availble options using the same <> keys and press to select similar to an LCD keypad. You should also be able to go into the installer mode and program options.

The main difference currently is that it will function similar to an LED keypad (ie it only shows the next available digit for any field instead of showing all values). For example if you have a field with 4 digits "1234", it will instead show [1], then you can press the 1 , which will then show you the next digit [2], and so on.

I do plan on adding full field editing but that will take quite a bit more work to buffer the entries and add a back end change to send the data in a special command.

[Dilbert66]

I've also added a beep function (for use in the card) but I need to fix the timing on that.

[slipx06]

Thanks for fixing so quickly. The <> keys work well and it updates the display as expected. Have not tried any installer mode yet but this is going to make things much easier for me as I only have an old LED keypad :)

The partition status is working again but not the partition messages

[slipx06]

What do these messages mean

[D][Debug:164]: Setting Fault: 13,01 [D][Debug:164]: Setting Fault: 13,00

[Dilbert66]

Those mean that an expander set_zone_fault cmd was sent to the esp from home assistant to zone 13 hex(19 decimal). The first triggers the fault (opens) and the second closes it. I'll edit that message to send the values in decimal instead to avoid confusion

[Dilbert66]

I've updated the "new" branch to re-add the missing partition msgs. I had removed them as they were redundant as it's the same info as what is sent in line1 and line2 lcd messages. What I've done is just combine the two lines into one message and sent it out that way.

[slipx06]

Those mean that an expander set_zone_fault cmd was sent to the esp from home assistant to zone 13. The first triggers the fault (opens) and the second closes it.

Strange I don't have anything defined for z13 and it seems to be triggering when one of the virtual expander zones trigger. I use address 10 so they only start at z17.

Will check out the updates

[Dilbert66]

Sorry, I corrected above That was 13hex so it's zone 19 decimal

[slipx06]

Makes sense now.

[slipx06]

Tested the new code and the partition message still shows as unknown. I suppose I could just pull this from the line1 and line2 sensors

[Dilbert66]

That's odd. Works fine here. Check the sensor name?

[slipx06]

I could also create a sensor in HA using the following template

{{ states('sensor.alarm_line1') | trim () }} {{ states('sensor.alarm_line2') |trim () }}

[Dilbert66]

Odd. I just check on mine and all is fine. check your yaml to make sure this is there?

     DSCkeybus->onPartitionMsgChange([&](uint8_t partition,std::string msg) {
       switch(partition) {
         case 1: id(m1).publish_state(msg); break;
         case 2: id(m2).publish_state(msg); break;
      } // if you only have one partition, remove the case 2 statement  and corresponding p2 sensor. You can also add more partitions if needed
    });
``

[slipx06]

Yes it is defined in my yaml file

[HenJou]

Hi I install the new branch with the ha_card and i want to test the new alarm panel. Have you got a example card ? Thanks

[Dilbert66]

You can start with this example setup. Just modify to suit your service names. I've pushed a sample lovelace.yaml sample:

type: 'custom:alarm-keypad-card'
title: DSCModule_ESPHOME
unique_id: dsc1
disp_line1: sensor.dscalarm_line1
disp_line2: sensor.dscalarm_line2
scale: 1
service_type: esphome
service: dscalarm_alarm_keypress
status_A: READY
status_B: ARMED
status_C: TROUBLE
status_D: AC
status_E: ''
status_F: ''
status_G: ''
status_H: ''
sensor_A: binary_sensor.dscalarm_partition_1_ready
sensor_B: binary_sensor.dscalarm_partition_1_armed
sensor_C: binary_sensor.dscalarm_trouble_status
sensor_D: binary_sensor.dscalarm_ac_status
button_A: STAY
button_B: AWAY
button_C: DISARM
button_D: ''
button_F: <
button_G: '>'
button_E: ''
button_H: ''
cmd_A:
  keys: /1S
cmd_B:
  keys: /1W
cmd_C:
  keys: '1234'
cmd_D:
  keys: ''
cmd_E:
  keys: A
cmd_H:
  keys: B
cmd_F:
  keys: <
cmd_G:
  keys: '>'
key_0:
  keys: '0'
key_1:
  keys: '1'
key_2:
  keys: '2'
key_3:
  keys: '3'
key_4:
  keys: '4'
key_5:
  keys: '5'
key_6:
  keys: '6'
key_7:
  keys: '7'
key_8:
  keys: '8'
key_9:
  keys: '9'
key_star:
  keys: '*'
key_pound:
  keys: '#'
beep: sensor.dscalarm_beeps
view_pad: true
view_display: true
view_status: true
view_status_2: true
view_bottom: true

[Dilbert66]

Yes it is defined in my yaml file

I can't see what the issue would be? Do you see it in the log as below?

[slipx06]

Its not in the logs either

[Dilbert66]

do you have these entries at line 1337 in dscalarm.h?

    rtrim(lcdLine1);
    rtrim(lcdLine2);
    lcdLine1=lcdLine1.append(" ").append(lcdLine2);
    partitionMsgChangeCallback(partition+1,lcdLine1);

[slipx06]

I don't know what I did. Cloned the repo again and clean build and now it's working. Sorry about that

[slipx06]

How do I get the beep function working? I've copied the audio files into the www folder?

[Dilbert66]

Beep is not fully working yet. Have a few bugs to iron out first.

[Dilbert66]

FYI, when you first restart the esp, it will not have the list of enabled and open zones. Therefore for the first few minutes you won't be able to use the menu to bypass zones until the information from the panel is updated. The trick to speed up the process is on inital start of the esp, just log in to installer mode and exit. It will force a refresh

[Dilbert66]

Ok, i've pushed a change that adds the beeps. Still a work in progress for now. A few other changes in the back end so hopefully nothing broke.

[slipx06]

I have not tested your latest changes but just noticed that I'm getting disconnected from the esphome api whenever I arm or disarm the alarm

[19:03:29][D][Debug:317]: Writing keys: /1S
[19:03:29][I][ Paneldata::388]: 0A: 0A 00 80 02 00 00 00 00 00 8C 00 00 
[19:03:29][D][text_sensor:015]: 'alarm line1': Sending state 'Stay         '
[19:03:29][D][text_sensor:015]: 'alarm line2': Sending state 'zones open      '
[19:03:29][D][text_sensor:015]: 'DSCAlarm Partition 1 Msg ': Sending state 'Stay zones open'
WARNING Disconnected from API: Timeout while waiting for message response!
INFO Connecting to 192.168.1.112:6053 (192.168.1.112)
INFO Successfully connected to 192.168.1.112

Still no beeps in the latest version

[Dilbert66]

Weird one. I don't get any timeouts or disconnects when arming or disarming. Looks to be related to the partition1msg perhaps. Too much traffic sent? I've seen that sometimes. You can try commenting the yaml portion that handles the m1 message to see if that fixes it? I would need to see the serial output if not to see if it's a software restart (ie bug related).

Did you add this line 'beep: sensor.dscalarm_beeps' to the alarm card config?

[HenJou]

Weird one. I don't get any timeouts or disconnects when arming or disarming. Looks to be related to the partition1msg perhaps. Too much traffic sent? I've seen that sometimes. You can try commenting the yaml portion that handles the m1 message to see if that fixes it? I would need to see the serial output if not to see if it's a software restart (ie bug related).

Did you add this line 'beep: sensor.dscalarm_beeps' to the alarm card config?

Hi I also get the timeouts with the latest one see below [18:56:47][D][Debug:322]: Writing keys: /1N [18:56:47][I][ Paneldata::393]: 0A: 0A 00 80 9F 00 00 00 00 00 29 01 00 [18:56:47][I][ Paneldata::393]: 05: 05 00 80 9F 81 C7 01 00 00 00 00 00 [18:56:47][D][info:1046]: status 9F, last status 01,line2status 9F,selection FF [18:56:47][D][text_sensor:015]: 'dscalarm line1': Sending state 'Enter ' [18:56:47][D][text_sensor:015]: 'dscalarm line2': Sending state 'access code ' [18:56:47][D][text_sensor:015]: 'dscalarm Partition 1 Msg ': Sending state 'Enter access code' [18:56:47][D][Debug:719]: got access code prompt [18:56:47][D][text_sensor:015]: 'dscalarm Partition 1 Status ': Sending state 'unavailable' [18:56:47][D][binary_sensor:036]: 'dscalarm Partition 1 Ready': Sending state OFF ERROR Error while reading incoming messages: Error while receiving data: [Errno 104] Connection reset by peer WARNING Disconnected from API: Error while receiving data: [Errno 104] Connection reset by peer INFO Connecting to dscalarm.local:6053 (192.168.65.243) WARNING Couldn't connect to API (Timeout while waiting for message response!). Trying to reconnect in 1 seconds INFO Connecting to dscalarm.local:6053 (192.168.65.243) INFO Successfully connected to dscalarm.local

[Dilbert66]

Interesting. I can't duplicate the issue but I've pushed an updated version that disables the partition messages and some debug prints to see if it resolves the issue. Try the new version. Only dscalarm.h has changed.

[Dilbert66]

If it is too much traffic causing the issue which I suspect it is since I dont' see the issue currently but have seen it before, you can reduce the amount of traffic sent in the esphome logs by changing the debug line below in the yaml to debug=1 or 2 instead of 3.

    DSCkeybus->debug=3; // 0 = off, 1 = minimal, 2 = all packets shown on console  3 =  + serial port 

[slipx06]

I have debug set to 2 but still getting the disconnect with your last update EDIT Setting to 0 and same problem so don think it is related to log levels

[22:12:46][D][Debug:322]: Writing keys: /1S
[22:12:46][I][ Paneldata::393]: 0A: 0A 00 80 01 00 00 00 00 00 8B 00 00 
[22:12:46][D][text_sensor:015]: 'alarm line1': Sending state 'Partition ready'
[22:12:46][D][text_sensor:015]: 'alarm line2': Sending state ''
WARNING Disconnected from API: Timeout while waiting for message response!
INFO Connecting to 192.168.1.112:6053 (192.168.1.112)
INFO Successfully connected to 192.168.1.112
[22:13:01][D][api.connection:617]: Client 'Home Assistant 2021.5.5 (192.168.1.103)' connected successfully!
[22:14:25][D][Debug:163]: Setting Zone Fault: 19,1
[22:14:26][I][ Paneldata::393]: 34: 34 00 8B 08 00 C7 04 92 00 00 00 00 
[22:14:26][D][binary_sensor:036]: 'Lounge': Sending state ON
[22:14:30][D][Debug:163]: Setting Zone Fault: 19,0
[22:14:31][I][ Paneldata::393]: 34: 34 00 8B 08 00 C7 00 8E 00 00 00 00 
[22:14:31][D][binary_sensor:036]: 'Lounge': Sending state OFF
[22:15:11][I][ Paneldata::393]: 27: 27 00 8A 04 00 C7 00 7C 00 00 00 00 
[22:15:11][D][binary_sensor:036]: 'DSCAlarm Partition 1 Armed': Sending state ON
[22:15:11][D][text_sensor:015]: 'DSCAlarm Partition 1 Status': Sending state 'armed_home'
[22:15:11][D][binary_sensor:036]: 'DSCAlarm Partition 1 Ready': Sending state OFF
[22:15:11][I][ Paneldata::393]: 05: 05 00 8A 04 00 C7 00 C7 00 C7 01 00 
[22:15:11][D][text_sensor:015]: 'alarm line1': Sending state 'Armed:       '
[22:15:11][D][text_sensor:015]: 'alarm line2': Sending state 'Stay            '

Did you add this line 'beep: sensor.dscalarm_beeps' to the alarm card config?

I do have this defined in the card config but dont see this sensor being published as an esphome entity?

[Dilbert66]

Yes , you are correct. i had forgotten to update the yaml with the beep change and a couple other tweaks. I've pushed everything that I'm using now.

[Dilbert66]

The timeout issue you were having is most likely due to the missing beep function in the yaml. \<slap on the forehead> :)

[slipx06]

I'm getting a compile error

Dependency Graph
|-- <ESPAsyncTCP-esphome> 1.2.3
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncWebServer-esphome> 1.2.7
|   |-- <ESPAsyncTCP-esphome> 1.2.3
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <ArduinoJson-esphomelib> 5.13.3
Compiling /data/alarm/.pioenvs/alarm/src/dscExpander.cpp.o
Compiling /data/alarm/.pioenvs/alarm/src/dscKeybusInterface.cpp.o
src/dscKeybusInterface.cpp: In static member function 'static void dscKeybusInterface::dscDataInterrupt()':
src/dscKeybusInterface.cpp:903:11: error: duplicate case value
           case 0x0A: statusCmd = 0x05; break;
           ^
src/dscKeybusInterface.cpp:894:11: error: previously used here
           case 0x0A:
           ^
*** [/data/alarm/.pioenvs/alarm/src/dscKeybusInterface.cpp.o] Error 1
========================== [FAILED] Took 2.56 seconds ==========================

[Dilbert66]

Oops. I was making some changes and copied my working copy. Fixed and pushed.

[slipx06]

Thanks. Don't see the new commit yet

[Dilbert66]

Sorry, I just pushed but found an issue after clearing an alarm which causes a reboot so be aware.

[slipx06]

OK noted. Thanks everything seems to be working now and i'm getting the beeps :)

[Dilbert66]

I'm working on viewing alarm memory and found this bug. After an alarm is triggered, you disarm and the display will show "Recent Closing". If you press * then # it will lock up the esp hard. Odd issue. Just making you aware.

[Dilbert66]

Ok, found and corrected the lockup issue. Was a problem with the origin library code in asterisk handling. Also added alarm memory viewing *3 capability. Code updated.

[slipx06]

Just wanted to report back that everything has been running perfectly for me. I did disable the beeps but they did work when enabled. *3 also working. Thanks again for the updates.

[Fabrizz]

Hi, first of all thank you for the code, integrating my old alarm panel with Esphome was much better than using the MQTT .bin. Reading this thread and comparing the dev and new branch I realized that there are much newer features. What branch should I use?

Are there any downsides on using the dev/new branches?

Again thanks and sorry for my English.

@Dilbert66

[Dilbert66]

Use the dev branch. It should be fine. It includes the lastest dsc library dev branch changes. I will migrate the changes to master at some point. The new branch has already been merged into dev so you can ignore that one. I

[w1tw0lf]

Tried to update to the dev branch but getting the same error as https://github.com/Dilbert66/esphome-dsckeybus/issues/11 running version 1.20.4 of esphome

[Dilbert66]

Interesting.. Try the "new" branch. It's in dev right now but mostly with keypad emulation such as lcd display , etc.

[Fabrizz]

Tried to update to the dev branch but getting the same error as #11 running version 1.20.4 of esphome.

If you can, downgrade to 1.20.3, it compiled just fine.

[w1tw0lf]

Interesting.. Try the "new" branch. It's in dev right now but mostly with keypad emulation such as lcd display , etc.

The new branch gave errors:

/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:262:14: error: 'dsc' was not declared in this scope
       return dsc.keybusConnected;
              ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:268:24: error: 'disconnectKeybus' was not declared in this scope
           disconnectKeybus();
                        ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:43:28: error: expected type-specifier before 'DSCkeybushome'
     auto DSCkeybus = new DSCkeybushome();
                            ^
/config/esphome/DscAlarm.yaml:67:44: error: 'troubleStatus' has not been declared
     DSCkeybus->onTroubleStatusChange([&](troubleStatus ts,bool open) {
                                            ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:69:20: error: 'trStatus' was not declared in this scope
             case trStatus: id(tr).publish_state(open);break;
                    ^
/config/esphome/DscAlarm.yaml:70:20: error: 'batStatus' was not declared in this scope
             case batStatus: id(bat).publish_state(open);break;
                    ^
/config/esphome/DscAlarm.yaml:71:20: error: 'acStatus' was not declared in this scope
             case acStatus: id(ac).publish_state(open);break;
                    ^
/config/esphome/DscAlarm.yaml:72:20: error: 'panicStatus' was not declared in this scope
             case panicStatus: id(panic).publish_state(open);break;
                    ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:111:24: error: could not convert '{DSCkeybus}' from '<brace-enclosed initializer list>' to 'std::vector<esphome::Component*>'
     return {DSCkeybus};
                        ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:263:3: warning: control reaches end of non-void function [-Wreturn-type]
     icon: "mdi:shield-link-variant"
   ^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:112:3: warning: control reaches end of non-void function [-Wreturn-type]

   ^
*** [/data/alarm/.pioenvs/alarm/src/main.cpp.o] Error 1

Tried to update to the dev branch but getting the same error as #11 running version 1.20.4 of esphome.

If you can, downgrade to 1.20.3, it compiled just fine.

Tried with "dev" on 1.20.3 and installed without issues.

[Dilbert66]

I suggest you do a clean first and/or also delete the "dscalarm" temporary compile directory to force a full recompile.

[w1tw0lf]

Found the issue, I added a few extra sensors to my all my esphome devices, like wifi signal, esphome version, uptime and so on....

Had to remove these 2 in order to get it work:

sensor:
  - platform: wifi_signal
    name: "$systemName WiFi signal"
    update_interval: 60s

  - platform: uptime
    name: "$systemName uptime"

Moment I added it back in 1.20.3 of esphome. Gave the same error as https://github.com/Dilbert66/esphome-dsckeybus/issues/11. Without it, could also install on 1.20.4

[Dilbert66]

That's interesting. Good find. Those functions must use IRAM storage. I have not delved into the back end ESP libs so can't say for sure. The error you get is because of the limited IRAM availability for ISR routines and the later version of the ESP libraries use more of it so with the addition of the ISR routines in the DSC lib, we run out.

I will look again into optimizing the IRAM use in the dsc lib if I can.

Alternatively, you can try using an ESP32 which has much more available IRAM available.

[w1tw0lf]

Also tried to compile the "new" branch again completed without issues.