Hi Alain,
Please see the full logs here:
line453 shows:
[10:41:36][D][text_sensor:064]: ‘Partition 1 Status’: Sending state ‘not_ready’
Ok, i see. The actual issue is the status between “entry delay” and “disarmed”. There is a short window when the system is no longer armed but not ready yet. I"ve added a check to ignore that delay in between both entry and exit delays. I’ve also added an addititional partition status to show the entry_delay. I’ve pushed the changes to “dev”
This is great, many thanks Alain!
Just updated and I will try to test it today evening, when family is off to sleep, because otherwise I can only test it after 20. Aug.
@Dilbert66 The week before last, I suddenly found all automations rely on state trigger of HA Alarm Control Panel was not working! Few days before that, I updated my yaml file following ESPHome version 7.0. Of course, I used then latest ‘dev’ branch of GitHub during installation.
I strictly follow HA Alarm Control Panel documentation in my configuration.yaml like:
alarm_control_panel:
- platform: template
panels:
pc1832_esp:
value_template: " {{states('sensor.dscalam_eth_partition_1_status')}}"
I found, after the update, state of ‘alarm_control_panel.pc1832_esp’ (of which I used to trigger lots of automations such as turning security camera on or off) changed to ‘unknown’ as ‘ready/not_ready’ provided by ‘Partition 1 Status’ is not recognized by HA Alarm Control Panel as valid.
It should be fine (trigger my automations) if the state of ‘Partition 1 Status’ goes through ‘disarm’ first and then change to ‘ready/not ready’ to reflect the status of DSC alarm panel but that is not the case. I found the ‘Partition Status’ straightly changed from ‘armed_home or armed_away’ to ‘ready/not_ready’, depends on one of the doors were closed or opened when I disarm the DSC alarm panel.
I noticed that there are already numerous sensors, such as ‘Partition Ready’ or ‘Partition Msg’, can show whether the DSC alarm panel is ready or not. Is it a duplicate to show it with the ‘Partition Status’ text sensor?
I rolled back to use the ‘main’ branch on your GitHub repository in order to keep my automations working but then I lost the web_keypad (It caused compiled error with newer version of ESPHome).
I just tried to use the ‘dev’ branch again after you pushed the latest changes but it was the same.
Unfortunately there were some issues with the partition status handling I was doing before which would sometimes have a sensor value stick to an incorrect value in some cases. I’ve rewritten the process. It does impact the way the state sequence displays. I can add the “disarmed” state to occur before the final “ready/not_ready” state. I see your point about not needing the “ready/not_ready” state for the partition since it is already handled elsewhere but some users were wanting to see the full statuses on that one sensor.
It’s a case of not being able to please everyone. I tend to lean more on your side as far as replacing the ready/not_ready state to simply “disarmed” as that is what a lot of alarm panel implementations expect. For now, lets try it with the “disarmed” state showing after the disarm sequence started. It will switch to ready/no_ready after a few seconds to show the final state of the panel. I’ve pushed an update to “dev”
Edit: I can also add a yaml config option to control the behaviour to suit most needs if that alleviates the issue.
Ok, to try and make it more configurable for different use cases, I’ve added a new yaml boolean dsc_alarm_panel config option below to control the state options for the partition state (ps_x) sensor:
detailed_partition_state: <true/false>
if true the available states will be:
triggered,armed_home,armed_away,armed_night,pending,arming,disarmed,ready,not_ready
and if false the states will be:
triggered,armed_home,armed_away,armed_night,disarmed,arming,pending
The default is “false”
These statuses are set to match the states that the alarm control panel expects:
New version pushed to dev.
I tested this version (prior to latest adjustments) before leaving for vacation and works perfectly!
Many thanks Alain!
We also do have ‘exit_delay’ and ‘entry delay’ statuses now as well, aren’t we?
Actually weren’t these two new statuses replacing ‘pending’ completely?
Sorry for the confusion, exit_delay is changed to “arming” and “entry_delay” is changed to “pending” in order to satisfy the expected statuses of the ha alarm panel component.
Hello; great project, hoping someone can give me a little push. I have a PC1832 that was about to be trashed while gutting our home. Been repurposing devices/firmware since Vonage, so I quickly found Dilbert’s project and bought a few ESP32s (ESP-WROOM-32 ESP32 DEVKIT V1) to connect my HA to the DSC alarm board. I’ve flashed one ESP32 successfully via ESPHome (it’s being powered via one of the Chromebox running HA’s USB 3.0 ports), found the Black/Red/Yellow/Green wires coming off the board, and now…I’m stuck with how I connect the boards.
I’m a happy coder, but electrical diagrams are new to me. OHM sounds like yoga and the only breadboards I own are in the kitchen. I have found older diagrams using resistors, some transistors and newer diagrams using just mosfets. Hoping someone could explain for me the easiest way (without soldering) to connect them? Even a picture of a working setup would be helpful.
Thanks!
I would recommend that you use this circuit as it only requires one single component as an interface. You can’t get any simpler then that. Use the alternate interface using the BOB-12009 instead of the mosfets.
From the dev branch at: GitHub - Dilbert66/esphome-dsckeybus at dev
You can get the bob-12009 from Amazon:
Amazon.ca : arduino level shifter
Unfortunately, you can’t avoid soldering. You will need to solder it together on a proto board or point to point soldering.
Hey, thanks! Just picked up a Sparkfun model and looking at bread boards now.
I have spent time trying to solder things years in the past, mostly melting and burning anything close to what I was trying to solder. I started with a gun-type but the tip was too big; bought a pen-type but never got far with it since my first child started to toddle around my office too often.
You’ll be fine. Those pins are fairly easy to solder to. Use small gauge flux core solder.
I normally solder all the included pins to the cpu board, then plug it into a prototyping board, then you can wire up the connections to the protuding pins on the underside. Alternatively, you can just solder directly to the board pin holes without using pins. The circuit is simple enough that you don’t really need a prototyping board .
1 Like
@Dilbert66 I’ve been reading a lot about your project but am unsure if it will work for my classic PC3000RK. I know you mention the classic systems have older bus technology but i do see my board has 4 output (black, yellow red, ground) going to the keypad
Sorry, no , my project does not support the DSC classic as it uses a different protocol. I have had no opportunity to implement it and have no hardware to test it. You can use the taligentx source project here and try that as it does support the classic. GitHub - taligentx/dscKeybusInterface at develop
Hi Alain. back to my failed update a few months ago.
I updated HA and Esphome to the last version today and I copied your yaml and flashed the esp32 device but I am seeing this in the log and I am getting a status unavailable:
[00:14:14][I][Paneldata: :1130]: B1: B1 00 FF 00 00 00 00 00 00 00 B0 01 00 00 00 00
[00:14:15][I][Paneldata: :1130]: 5D: 5D 00 00 00 00 00 00 5D 01 00 00 00 00 00 00 00
[00:14:25][I][Paneldata: :1130]: 63: 63 00 00 00 00 00 00 63 01 00 00 00 00 00 00 00
[00:14:29][I][Paneldata: :1130]: 11: 11 00 AA AA AA AA AA 0B 00 00 00 00 00 00 00 00
[00:14:29][I][Moduledata::1130]: 11: FF 01 FF FC FF F3 FF 0F 00 00 00 00 00 00 00 00
[00:14:36][I][Paneldata: :1130]: 11: 11 00 AA AA AA AA AA 0B 00 00 00 00 00 00 00 00
[00:14:36][I][Paneldata: :1130]: 11: 11 00 AA AA AA AA AA 0B 00 00 00 00 00 00 00 00
[00:14:36][I][info:1955]: status 03, last status 03,line2status A3,selection 01,partition=1,skip=0,force=1
[00:14:36][D][text_sensor:064]: 'line1 Partition 1 (ln1_1)': Sending state 'Secure System'
[00:14:36][D][text_sensor:064]: 'line2 Partition 1 (ln2_1)': Sending state 'Before Arming <>'
[00:14:36][D][text_sensor:064]: 'System Status (ss)': Sending state 'online'
[00:14:36][D][text_sensor:064]: 'Partition 1 Status (ps_1)': Sending state 'unavailable'
[00:14:36][D][text_sensor:064]: 'zone status (zs)': Sending state 'OP:2'
[00:14:36][D][text_sensor:064]: 'Trouble Msg (tr_msg)': Sending state 'TEL TIME SYS '
[00:24:36][W][component:237]: Component dsc_alarm_panel took a long time for an operation (102 ms).
[00:24:36][W][component:238]: Components should block for at most 30 ms.
Any idea what I am missing here please?
Nothing wrong there. Unavailable means that the partition is not ready to arm as it has zones open. Try using the dev version of esphome-dsckeybus instead as that version has many updates and will show not_ready instead. If you bypass zone 2 , you will see that it will change to “ready”
That was real quick 
I was bypassing zone 2 before the update. I used the physical panel to bypass it again by pressing * 1 then choosing zone 2 and bypassing it pressing *.
I now see the correct status in the logs but the old panel and card in devices/integration/esphome are still not updating. The connection panel is showing unavailable. I think I have to update these guyus too, right?
tried the dev branch yaml only and getting this error:
Compiling .pioenvs/dscalarm/lib64d/WiFi/WiFi.cpp.o
/config/esphome/dscalarm.yaml: In lambda function:
/config/esphome/dscalarm.yaml:464:20: error: 'disconnectKeybus' is not a member of 'esphome::alarm_panel'
alarm_panel::disconnectKeybus();
^~~~~~~~~~~~~~~~
/config/esphome/dscalarm.yaml:464:20: note: suggested alternative:
In file included from src/esphome.h:20,
from src/main.cpp:3:
src/esphome/components/dsc_alarm_panel/dscAlarm.h:49:13: note: 'disconnectKeybus'
extern void disconnectKeybus();
^~~~~~~~~~~~~~~~
Compiling .pioenvs/dscalarm/lib64d/WiFi/WiFiAP.cpp.o
*** [.pioenvs/dscalarm/src/main.cpp.o] Error 1
========================= [FAILED] Took 86.61 seconds =========================
Answering the unavailable connection question: I removed the integration and re-configured it and now the connection is working.