I’m using the power series 1832 board.
I’m a bit confused with how there are a few different hardware methods to make this work. With the little MOSFET board I used, I only connected two of the digital pins (18, and 19) but I see others using a third pin for theirs.
Should I be following this image instead?
The mosfet version is better as it has better signal quality and isolation as well as being the simplest. Your wiring looks fine but your logs don’t show the correct data. You only need 2 wires for the mosfet version as it is bidirectional (does read/write using the same pin). Double check that your pinouts match your wiring, that’s the only other thing I can think of that would be an issue.
Edit, it looks like you have the 18/19 connections reversed on the esp. Ie you have the yellow going to pin 18, and green to pin 19 on the esp. Just change the pin definitions in the yaml config. Clock=18, read/write=19
Oh, so simple! That worked, Thank you!
Hi Alain,
esphome throws an error on compile with this commit from yesterday:
src/esphome/components/dsc_alarm_panel/dscAlarm.cpp:151:10: error: no declaration matches 'void esphome::alarm_panel::DSCkeybushome::set_panel_time_manual(int32_t, int32_t, int32_t, int32_t, int32_t)'
151 | voidDSCkeybushome::set_panel_time_manual(int32_t year, int32_t month, int32_t day, int32_t hour, int32_t minute)
| ^~~~~~~~~~~~~
In file included from src/esphome/components/dsc_alarm_panel/dscAlarm.cpp:3:
src/esphome/components/dsc_alarm_panel/dscAlarm.h:400:12: note: candidate is: 'void esphome::alarm_panel::DSCkeybushome::set_panel_time_manual(int, int, int, int, int)'
400 | voidset_panel_time_manual(int year, int month, int day, int hour, int minute);
| ^~~~~~~~~~~~~~~~~~~~~
src/esphome/components/dsc_alarm_panel/dscAlarm.h:263:7: note: 'class esphome::alarm_panel::DSCkeybushome' defined here
263 | classDSCkeybushome : public api::CustomAPIDevice, public time::RealTimeClock
| ^~~~~~~~~~~~~
Compiling .pioenvs/dscalarm/src/esphome/core/scheduler.cpp.o
Compiling .pioenvs/dscalarm/src/esphome/core/static_task.cpp.o
Compiling .pioenvs/dscalarm/src/esphome/core/time.cpp.o
Compiling .pioenvs/dscalarm/src/esphome/core/util.cpp.o
Compiling .pioenvs/dscalarm/src/esphome/core/wake.cpp.o
Compiling .pioenvs/dscalarm/src/main.cpp.o
Compiling .pioenvs/dscalarm/lib185/libsodium/crypto_aead/chacha20poly1305/aead_chacha20poly1305.c.o
Compiling .pioenvs/dscalarm/lib185/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c.o
*** [.pioenvs/dscalarm/src/esphome/components/dsc_alarm_panel/dscAlarm.cpp.o] Error 1
Should be fixed now. I missed a header file when I pushed the last update on main branch.
Many thanks for the quick fix Alain!
It works! Great !
Chapeau bas! 
Hello. Great, great work! Many thanks!
Is it still the case (bidirectional data in dev only)?
Or is it now available in main also?
(schematic already is in main, right?)
I'm using main branch code now. Will try dev in the evening.
Meanwhile I have troubles writing from ESP32 to DSC. Looks like Keybus data messed up:
When using single pin for read and write:
When trying separate pins for read and write (and separate channels on I2C level shifter):
For now I configured write/read on separate pins and disconnected write wire for now - enjoying one way read data.
This is my first experience with development boards like ESP32, ESPHome. So I might be doing something stupid. E.g. I managed to connect DSC AUX- to HV+ on I2C level shifter. Didn't burn down the house, even some signals went through (like AC status) - but all zones showed as closed / no motion.
My setup:
You have a wiring problem. For one thing, nothing gets connected to the HV+ line (especially not the aux-) . I have no idea why you did that as it's not in the schematic. Only lines from the panel are the Yellow , Green and Black. The main branch does support the level shifter as well, FYI.
Sorry for my confusing note about wiring. I mentioned AUX- to HV+ connection just as initial mistake I made (to showcase my inexperience 
Now wiring is correct:
What I suspect - maybe I fried level shifter (with my stupid miswiring errors. or clumsy soldering).
So I will try to buy another. And hope my second soldering attempt will be cleaner.
As I mentioned - interestingly, read only operation works perfectly fine (if I specify write to unused PIN). I mean I can see all system and zones status updates in ESP and HA.
So current wiring should be right.
Mystery resolved. Bidiectional communication and all zones work now.
Issue was: Incorrect yaml config.
Clue was in the symptoms: ESP seemed to ‘fight’ on the keybus with DSC PC5108 (expander of zones 9-16).
Apparently I misunderstood meaning of expanderaddr1 setting. Thought it must match my actual hardwired DSC config, and set:
#zone expander addresses:
# 9 - zones 9-16
# 10 - zones 17-24
...
expanderaddr1: "9" # 1st zone expander emulator address to use . Set to 0 to disable.
expanderaddr2: "0" # 2nd expander emulator address to use . Set to 0 to disable.
Changed setting to expanderaddr1: "0" and now it works. Ufff…
Would this be required, if I’d need to feed attinional sensors via ESP back into DSC?
(and therefore virtual expander required to emulate this?)
ESP still not shown in DSC as additional LCD keypad under *8 <installer code> 903. But I don’t know if it should. Everythin works, so no complaints.
Oh, and I still did changed level shifter, much happier with soldering this time.
Component cost 2 euros, but worth it - learned some skill
yes the virtual expander is designed to be able to use non dsc sensors or external events to trigger zones.
You won’t see the esp keypad in the dsc panel 903 query since the code is not emulating supervision (it could but it’s unecessary and not useful). You don’t want the panel to trigger a fault whenever you reset the esp.
Has anyone tried this with an ESP32 and a DSC PC3000? Im confused as if GitHub - Dilbert66/esphome-dsckeybus: Esphome custom configuration for interfacing to a DSC POWERSERIES alarm system · GitHub works with the classic serries.
Classic series is not supported.
Hi Alain,
I’ve got the following error now when trying to build:
-- Build files have been written to: /data/build/dscalarm/build/bootloader
[1183/1254] Building CXX object esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj
FAILED: esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj
ccache /cache/idf/tools/xtensa-esp-elf/esp-14.2.0_20260121/xtensa-esp-elf/bin/xtensa-esp32-elf-g++ @esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj.rsp -MD -MT esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj -MF esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj.d -o esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/dsc_alarm_panel/dscAlarm.cpp.obj -c /data/build/dscalarm/src/esphome/components/dsc_alarm_panel/dscAlarm.cpp
../src/esphome/components/dsc_alarm_panel/dscAlarm.cpp: In member function 'void esphome::alarm_panel::DSCkeybushome::createSensorFromObj(void*, uint8_t, const char*, bool)':
../src/esphome/components/dsc_alarm_panel/dscAlarm.cpp:4840:75: error: 'class esphome::binary_sensor::BinarySensor' has no member named 'get_entity_key'; did you mean 'get_entity_category'?
4840 | s.hash = reinterpret_cast<binary_sensor::BinarySensor *>(obj)->get_entity_key();
| ^~~~~~~~~~~~~~
| get_entity_category
../src/esphome/components/dsc_alarm_panel/dscAlarm.cpp:4842:70: error: 'class esphome::text_sensor::TextSensor' has no member named 'get_entity_key'; did you mean 'get_entity_category'?
4842 | s.hash = reinterpret_cast<text_sensor::TextSensor *>(obj)->get_entity_key();
| ^~~~~~~~~~~~~~
| get_entity_category
[1204/1254] Building CXX object esp-idf/src/CMakeFiles/__idf_src.dir/esphome/components/mdns/mdns_component.cpp.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1, output of the command is in the /data/build/dscalarm/build/log/idf_py_stderr_output_10644 and /data/build/dscalarm/build/log/idf_py_stdout_output_10644
I would not recommend upgrading any device to a xxxx.0 release of any software at any time and would suggest waiting till a xxxx.1 or later till bugs get addressed. I had the code updated to the last beta and they went and removed the changes before publishing so I have to revert the changes. There is also a very odd compile error with a “ringbuffer” that has me stumped since I don’t use it. Anyhow, I’ll push the changes I have.
Edit: Ok, you should be good to go now. Pushed an update.
Superfast as always! Thank you Alain!
Hi! This would be my first ever message on the community. First of all, thanks to everyone involved in this project which is great!
Now, straight to the point. I’ve been testing the home assistant card and I found that the trouble icon, sometimes, gets out of sync. I’ve been trying to find the root cause but I have not have success, even after doing some changes in the set hass() function. This is the console output when I add a console.info(hass) in the set hass(hass) function.
I thought it was a kind of race condition but I was not able to find any issue so far. If you check the screenshot, trouble sensor is OFF but _troubleStyle remains as orange. It remains this way until another refresh is made because of a beep, a keypress or similar.
Any idea why? web_keypad works just fine on this regard.
You are correct. The problem is the missing trigger variables in the properties getter function. The led sensors were not in the list so were not triggering a refresh. I’ll update shortly but you can fix your own version by changing “get properties()” to this
static get properties() {
return {
_config: Object,
_title: String,
_kpdline1: {
type: Object,
},
_kpdline2: {
type: Object,
},
_kpdbeep: {
type: Object,
},
_kpdsetting: {
type: Object,
},
_sensor_ready: {
type: Object,
},
_sensor_armed: {
type: Object,
},
_sensor_chime: {
type: Object,
},
_sensor_trouble: {
type: Object,
},
_sensor_ac: {
type: Object,
},
};
}
@Dilbert66 thanks for the fast reply. I have tested the change and now it works fine. I have played with the JS by adding another label on the virtual_lcd div and noticed these declarations and I was wondering why there were just a few declarations and not all, I thought it was because the ones already there were text_sensor.
If you don’t mind, I’m trying to debug another issue that I have with the web_keypad which is that it works just fine on safari under macOS.
But when I open the web on my iPhone it looks as if I couldn’t login successfully (tried on Brave, Safari and Firefox).
The only things I tested so far is disabling auth and disabling encryption but it didn’t work. I noticed that it doesn’t show the started time counter so I’m not so sure if it has to do with auth or not because even when there’s no user logged in on my mac I can see the time counter.
