Did you add all of your zone definitions in /config/esphome/vistaalarm.yaml? If not, there are two places that require update, around line 160 (in the original file) and again beneath text_sensor:.
I’ve had to disconnect and go back to the alarm decoder + raspberry pi setup but …
yes, all the zone definitions are in – you can see that the motion and door sensors all show “C” or “O” in the screenshots above; although it looks like it’s just the the binary sensor’s associated with them are all “unknown” but there are actually other binary sensors that are not showing up. What I mean is even the predefined “trouble”, “chime”, “bypass” etc. binary sensors are not reading properly.
Try using the dev version. The master version might start with unknown status for some sensors and does not have a refresh mechanism in place. The dev version will refresh all value periodically to ensure that HA is updated.
Didn’t realize there was a dev branch and there seems to be a bit more write-up in there that wasn’t part of the Master. The main thing that was in the Dev branch was that there is a little bit of a writeup regarding each circuit … I had built the isolated version (the 3rd schematic) not realizing that it was mentioned that the first schematic (non-isolated) was the preferred. This, plus little bits here and there make the Dev branch a better read before starting the project.
Maybe next weekend I’ll try to tackle this project and report back.
Edit: as I read through more of the Dev branch, there is actually a lot more detailed explanation than the Master. Definitely well worth going over the Dev branch first (for anyone new attempting to tackle this).
tried setting things up in ESPHOME while waiting to get parts and to tinker with the panel …
I replaced everything in the Config/esphome/VistaEcpInterface folder from the master branch with what was in the dev branch (all the .h and .cpp files), updated the .yaml file with the binary_sensor version but now it won’t compile (see errors below):
Make sure you have the time section in the yaml (ie, make sure you are using the yaml from the dev branch as there are other changes than just sensors)
time:
- platform: sntp
id: sntp_time
ahh … thanks, i commented that part out because i wasn’t sure what that was for … putting that section back in, there’s just the one error left (the TRBL in the last screenshot above):
Could you also explain what this part is about below?
I don’t have any relays so the r1 and r2 have been commented out under the binary sensors section, do i need to edit this part out too?
VistaECP->onRelayStatusChange([&](uint8_t addr,int zone,bool open) {
switch(addr) {
case 12: switch (zone) {
case 1: id(r1).publish_state(open); break;
case 2: id(r2).publish_state(open); break;
}
break;
case 8: switch (zone) {
case 1: id(r1).publish_state(open); break;
case 2: id(r2).publish_state(open); break;
}
break;
case 13: break;
default: break;
}
}); //add as many case and switch statements as needed to control your binary sensor outputs
the offending portion of the code seems to be this:
//device check status
if (promptContains(p1,CHECK,tz) || promptContains(p1,TRBL,tz)) {
// if (zones[vista.statusFlags.zone].state != ztrouble)
//zoneStatusUpdate(vista.statusFlags.zone, "T");
//zones[vista.statusFlags.zone].time = millis();
//zones[vista.statusFlags.zone].state = ztrouble;
}
it looks like everything in the IF block is commented out and so I’ve commented out the actual IF line as well but there are a bunch more errors that follow. I’m going to tap out at this point and just wait for others more knowledgeable …
There is nothing wrong with the code. You have a configuration issue somewhere. This code is in use by many people including me.
ok thanks, will start over with the binary sensor yaml to see if can fix up my config.
You were correct. I missed one file when pushing changes earlier and it was missing the TRBL definition. It should be good now.
thanks, the esphome now installs correctly (aside from a small hitch).
I’m not sure if this is something to do with how I’ve setup my secrets.yaml or maybe i’m not configuring it correctly for this project. In my secrets.yaml file, I have my code defined as follows:
alarm_code:1234
Then in the rest of my HA setup, wherever I call upon it, I do this:
!secret alarm_code
However, in the esphome configuration this doesn’t work:
substitutions:
systemName: "vistaalarm"
accessCode: !secret alarm_code #Only comes into effect if needed for arming and quickarm is not set
I get an error validating the code saying:
Must be string, got <class 'esphome.helpers.EInt'>. did you forget putting quotes around the value?.
alarm_code: 1234
The error goes away if in my secrets.yaml file i define it this way with quotations:
alarm_code:"1234"
It doesn’t throw the error anymore if i do the following either, but I’m not sure that is actually passing the code or if it’s just passing literally the string of text that says !secret alarm_code
substitutions:
systemName: "vistaalarm"
accessCode: "!secret alarm_code" #Only comes into effect if needed for arming and quickarm is not set
Thoughts?
You need the quotes. The code will convert it to a number when needed.
So far I’m able to monitor everything correctly.
Just can’t seem to figure out how to control the alarm system. I’ve been trying through the developer tools using esphome service calls —maybe it’s not related to the alarm code.
Assuming all my wiring is correct, what other things aside from the keypad address will affect this (which is set in the yaml to match the new number I’ve configured in the alarm panel)?
In Developer Tools/SERVICES, the following works in order to disarm my two zones.
service: esphome.vistaalarm_alarm_keypress
data:
keys: "123401"
But when attached to a button I get "Failed to call service esphome/vistalarm_alarm_keypress. required key not provided @ data[‘keys’]
double_tap_action:
action: call-service
service: esphome.vistaalarm_alarm_keypress
data:
keys: "123401"
Any idea what I’m doing wrong? I’ve tried single and double-quotes around “keys” and the code.
A few things remaining that I can’t figure out:
-
I get a total of 34 entities from this esphome integration but there is 1 entity that’s just permanently “unknown” and that is the “Check” binary sensor (binary_sensor.vistaalarm_check). I’m not sure what it’s used for, does anyone know?
-
The other item I can’t figure out is how to come up with the ‘mask’ portion of the RF serial lookup in the esphome yaml code. The comment in the code says: “#Mask: hex value used to mask out open/close bit from RF returned value”. But I have no idea how/where to find this value.
-
I currently use the AlarmDecoder integration with their board on a Raspberry Pi. It’s been rock solid all these years. One great thing about the setup is that everything is powered via PoE and have never had it drop due to connectivity because of the ethernet. Running this ESPHome setup using an ESP32 tucked into a back corner of the basement, there are some wifi connectivity issues.
Looking at the history graph below (AD2Pi = AlarmDecoder Integration, ESP32 = this integration), you can see how the poor wifi connection is constantly dropping the ESP32. However, something odd about this is that the drops happen constantly only when the system is ‘disarmed’ but never when the system is ‘armed’ – this is a 24hr duration where there was only a short ‘armed’ duration but I can tell you that on other days with long ‘armed’ durations it never drops either. I’m going to try to see if i can relocate the ESP32 board to find better wifi connectivity, but at the same time I’m also wondering if there’s something in the code that maintains alarm status when armed but doesn’t do so when disarmed, following a connection drop?
Solved my own issue. I was using custom:button-card element, and apparently in that case, instead of “data:” you need “service_data:”
-
The check will only updated in the event that you have a zone issue such as a tamper, battery, etc or an issue with an expander. You 'll know since you will see Check xxx on your alarm display. You can just disable that entity in the yaml if you’re not interested in capturing those events.
-
This is an experimental feature to capture RF zone statuses from the actual device messages to the panel. It will allow to capture restore events more quickly then depending on a timeout of the fault messages. To figure out the correct mask, you would need to look at these messages in your logs for each serial device. For example:
vistaalarm RF Msg sending state ‘0118221,80’ (device open - fault)
vistaalarm RF Msg sending state ‘0118221,84’ (device close - restore)
so in this case you want to isolate bit 2 (the 4) as that is the bit that is changing for each status so the mask is 4. -
I have no issues with my esp32 but then again it depends on the device and the placement. You can also use esp32’s that have ethernet support such as the wt32-eth01 or the lilygo T-Internet-POE.
The wt32 is fairly inexpensive but does not have POE but you can easily power it from the panel +12v. The lilygo has POE but is twice the price.
As to alarm status, the esp32 always keesp track of status no matter what unless there is a reboot which could also be the issue you have. You would need to monitor the serial output to know for sure if it’s a reboot or just a wifi disconnect. It’s possible there could be an issue but no way of knowing that without seeing logs.
Thanks for quick response!
Should the check sensor not read something though? It shouldn’t say “unknown” should it? That makes it look like somethings not reading properly?
I do notice the RF message for when it opens, I never checked for when the sensor closes again. Once I figure out the mask and have that part configured, is there something I would notice in the operation? What I mean is, how do I know if I’ve got it configured correctly versus not configured at all?
I’ve since moved the board in a much better area and seems like for the past 2 hrs there isn’t any improvement; still constantly getting “Became unavailable triggered by state of vistaAlarm System Status”. How do I go about “monitoring serial output” as you mentioned above?
Just can’t figure out what the issue is … completely rebuilt this using an esp8266 and new wiring and still disconnects an incredible amount when disarmed. But on the contrary, no issues though when in armed mode.