Zone status and trouble indication

[yvest]

First, great project, although I'm very new to ESPHome and Home assistant, I was able to get my DSC panel integrated surprisingly easily.

I have a couple of questions that are not so related to this project and more about the status I see from my panel, I hope you dont mind!

I have a simple Power832 (5010).

I have the ESP connected for a few days now and just today saw the zone status has a BL:12. The panel only has 8 zones (no expanders) and there is no wireless devices. Any idea what would the 12 might refer too?

This brings me to my other question. My panel has been showing a trouble that I have yet to sort out. From the panel, when I do a *2 I get a 1 and then when I press 1, I get a 5. Which from what I read is "General System Supervisory". I find this odd, since the only thing that it could be supervising is the keypad (which works just fine). Could the smoke detector trigger this trouble code?

I was hoping the "tr_msg" would magically tell me more info on what might be causing the trouble. It wasn't showing anything, but now that I went back at the keypad to do a *2 it is showing "SUP".

Thanks again sharing your great work on this project!

-yvest

[Dilbert66]

BL:12 means low battery on wireless zone 12. Sorry, I have no idea why your panel is reporting that error or why you are getting a supervisory error. I'm not a dsc expert unfortunately. The code just presents what it gets from the panel.

[yvest]

Thanks for the reply. That's pretty much what I expected.

Thanks for your time and for your work on this project!

[Dilbert66]

You might want to consider using the dev branch now as this has the latest code updates. I will be migrating it to main at some point.

[Dilbert66]

We can try to figure it out is you want to post the esphome logs while you are going into the *2 service menu, etc. We can see what the panel is sending.

[yvest]

logs_esphome-web-3fa4a8_logs.txt
I've attached the logs.

I haven't connected the transistor yet so the ESP is setup to only receive data for now.

[Dilbert66]

You can always try resetting supervision with program 902 and see if that fixes it. Seems like it's looking for a device but not seeing it on the bus.

[yvest]

Thanks for looking at the logs. It's pretty odd since there never was any other devices connected to it.

I wish I could try to reset the supervision, but I don't have the installer code. I wonder if it's possible to get the monitoring central to give it me.

[Dilbert66]

They should give it to you if they have it. You can also try my install code retrieval scripts to retrieve it from your panel. See the dev branch of my esphome-components repository

[yvest]

I have already found the unlocker example sketch in the dsc keybus interface lib and was considering giving that a shot.

I didn't find anything in our esphome-components repo, even in the dev branch, must of missed it somehow.

[Dilbert66]

Sorry, my mistake. I'ts in the dsckeybus repository as you noted.
I assume you've tried the default installer codes of 5555 or 5010?

[yvest]

Yeah, I tried those with no success.

I have errors when I try to compile the ESP32 version of the unlocker in Arduino IDE (see below), but the esp8266 compiles fine.
I'll try to setup an 8266 later tonight to give it a shot.

dscKeypad.cpp:65:22: error: too many arguments to function 'hw_timer_t* timerBegin(uint32_t)'
65 | timer1 = timerBegin(1, 80, true);

[Dilbert66]

Sorry, that is the unlocker script from the taligent repository, not mine. That one might work, I just never used it but I use this python script:
https://github.com/Dilbert66/esphome-dsckeybus/tree/dev/extras/crack_installer_code
I would suggest the crack_dsc_api.py script and the dev version of the esphome-dsckeybus firmware.

[yvest]

Thank again for your reply. The Arduino unlocker was running by the time you posted your reply and it managed to get me the code (after some 6000 tries).

A reset of the supervision cleared all of my trouble, woo-hoo!

Hopefully this should be my last question: Now that I have my ESPHome connected back and with the transistor installed, I tried to send a keypress from the alarm card and I get "Action mqtt.publish not found". Do I need to install an mqtt integration or something of that nature on HA for this to work?

[Dilbert66]

Awesome that you got the code and got the issue sorted out. As to the mqtt publish issue, it all depends on if you are using MQTT to talk to the esp. I assume not. I would recommend using the api instead of mqtt unless you have specific reasons you want to use mqtt. For the alarm card, there are 2 versions of the config. One that uses the esphome service type and the other uses mqtt. You need to use the esphome service one for the api.

[yvest]

I cant believe I missed that! My apologies for bugging you with my mistakes.

All sorted.

Now, just need to get all the stuff needed to go from by breadboard to a permanent install!

Again thank you for sharing the great work and for all the help.

This integration will have a significant impact on the Home Assistant setup (I have so many ideas).

-yvest

[Dilbert66]

No worries! I'm glad you like the project and find it useful!

[yvest]

Ok, I've for a question or comment: the partition status that goes "Unavailable" when the panel is not ready.

I'm very new to HA, but this seems to be a state that generally indicate an issue with the entity.
It displays a (!) on the settings -> Devices -> entities page. Watchman integration also flags this as a potential issue with the configuration.

Would it not be better to return something like "Not Ready" or something along those lines?

I'm curious if there is a specific reason "Unavailable" was chosen.

-yvest

[Dilbert66]

The reason "unavailable" was used at the time was because this was one of the values expected from the "template alarm" panel integration in ha.

value_template [template](https://www.home-assistant.io/docs/configuration/templating/) (Optional)

Defines a template to set the state of the alarm panel. Only the states armed_away, armed_home, armed_night, armed_vacation, arming, disarmed, pending, triggered and unavailable are used.

If you use the "dev" branch you will find that I now use "not_ready"

[yvest]

Looking at this list, I would say if you really needed/wanted to comply to the template, "disarmed" would probably more closely reflect the status, but it wouldn't be indicating the fact that not all zones are secured. "not_ready" has the advantage of showing a more detailed state of disarmed.

So unless the "not_ready" state actually breaks anything, I think the "not_ready" has it's merit.

[Dilbert66]

I've pushed on update to main to also default it to not_ready to avoid confusion.

[yvest]

Awesome,
I do get 'not ready' now.

Thank you!