You are using the wrong pin for tx on the esp32. You have it on gpio13 instead of gpio21 like the config is set to. The reason I don’t use gpio13 on the esp32 is that it outputs pwm on boot and we don’t want to induce noise on the ecp bus for no reason.
@Dilbert66
I am using the GPIO21. (I believe the angel wasn’t good in the last photo gave wrong impression about gpio13).
I am using GPIO 22, 21, and 18 and GND and VIN in the ESP32 as can be seen here.
Any advice?
again I really appreciate your help 
Try a different pin then as that is the only thing it can be. The code is fine. You can also try lowering the resistor value of the optocoupler from 220 to 180 or something to see if that also helps. Other wise, the only way of knowing what is going on for sure is to trace the signals with a scope.
@Dilbert66
wow, I had 150 handly and changed the 220 to 150. Works perfectly now.
and thanks a lot.
Should I change it to 180 or 150 is fine?
You should be ok with 150. Assuming a forward voltage drop of around 1.3 (typical) of the 4n26, you will be sourcing about 13ma of current give or take. The esp pins are rated at around 12ma. Since the output is not continuous, it should not be a problem. Using 180 will bring the current to about 11ma.
I use tlp521’s here since I have tons of em and they have slightly more gain and hence the 220 ohm value.
It is interesting though that the esp8266 had no issues but the esp32 did.
1 Like
I went back and had a look at the esp32 datasheet and it seems to indicate that 40ma is the max source current on a pin. That seems high but there is a some confusion out there about what the true limit on the ESP32 is. The 12ma value comes from the ESP8266 i suspect.
Either way, I’m pretty sure using 150ohm is best here so stick with that value on the ESP32. I will amend my schematic to indicate that.
1 Like
Hi @Dilbert66 Thank you again for this amazing project. One more question. I have an Ademco CE3 code Encryptor which provides key fobs to Arm and Disarm the alarm. It also provides two relays for unlocking doors. Do you think the buttons for the relays could be read from this application?
I’m not familiar with that peripheral so can’t say how they work. The documenation doesnt describe the relays as programmable from the panel so suspect they will not be visible. You can try capturing the logs while you operate the fobs and see if we can view any interesting traffic. The one to watch is the 98 cmd.
FYI,before you post the logs, you might want to check or edit the F6 cmds generated when you use the keyfobs as they will most likely contain the user code assigned to the encryptor board (it emulates a keypad and sends the associated user code to arm/dissarm). The f6 will start with F6 11 (keypad id 17 response)
The F6 01 are the touch keypad cmd/responses. Those are fine.
I went back and retested with a bunch of optocouplers I had on hand and found that the 4N25/4N26 I had initially suggested is inadequate for this use. The CTR (gain) is too low. I recommend using a 4N35 or TLP521 (those I have tested and use currently) as they will produce a good signal with minimal forward current. Hence you could drive the optocoupler with 220 ohm instead of 150 if needed.
I have amended the schematic to reflect the new design recommendations. I have also published a fully isolated version for those that would prefer it.
2 Likes
@Dilbert66 sorry to trouble you yet again. The system is working perfectly. I am now looking at an automation to turnoff the alarm. I can activate the arlarm by callign service ESPHome: vistaalarm_alarm_arm_away, but when I call service ESPHome: vistaalarm_alarm_disarm with the code I have setup nothing happens. I can’t even find a log. Any suggestions please.
I have got it working by using esphome.vistaalarm_alarm_keypress instead. So thank you all.
1 Like
Ok, good news I have a prelimininary test version that works with this board (Vista 20SE). Honestly, the protocol on it is the weirdest thing. It uses a combination of 4800 8E2, 2400 8E2 and even uses 2400 5N1 (for the sent keys). It uses 2400 baud for comms with the keypad and 4800 baud for the later peripherals such as zone expanders (wired and RF). This makes it a real PITA to work with especially switching bauds in mid sync window. I did it for the challenge really especially since I doubt there are many of them still in use. Very different then the later vista 20 models
I will clean up the code a bit and post it in the dev branch when I get a chance.
1 Like
Ok, I’ve pushed a test version to the DEV branch that supports this board. You can find the necessary files in directory Vista20SE.
1 Like
I’m so happy to have this working. Thanks again for making this project. This was one of the top things I wanted to automate when I started setting up my home assistant. The alternatives were much more expensive and would have been less fulfilling. Since I was satisfied my wiring and everything was correct I decided to “productionize” my setup. It was originally just done on a breadboard with wires all over, dangling in the box. Now I’ve soldered it up on a nice small board and stuck it to the side of the box. Much cleaner.
Looks good!
I’ve pushed a new update to master that fixes a long standing bug with the serial library that would cause some data packets to be missed. You might want to update from the master branch.
Working on the SE version helped in solving this issue. I’ve updated the library on both vista20p and vista20se variants. I’ve also added an MQTT example for the vista20se for those that want to use the code on a non HA environment such as openHAB or homeKit.
1 Like
For those that prefer binary sensors for the zones instead of the current text sensors, I’ve pushed an additional sample configuration yaml “VistaAlarm_binary_sensors.yaml” to the “DEV” branch that does that, including setting device classes for the sensor type (ie door/window/motion). The difference is that you will not be able to see the alarm /bypass status at zone level. Instead, for bypass/alarm status, I’ve added a new field called “Zone Status” that will indicate which zones are bypassed/alarmed using the format BY:x,AL:x where x is the zone bypassed or alarmed. You will need to update all files.
Also, I’m playing around with setting up automatic zone shadowing using virtual relays. For those that dont’ know what that is, this is a trick used to allow us to be able to view in real time the zone status for the built in zones even if zones are bypassed or the system is armed. When a relay output is setup to follow a zone state, my firmware can capture it and update the corresponding zone status on HA.
This is not an issue with extended zones from 4229 or RF extenders as for those I capture their responses directly to update the status. This is not possible with the 8 built in zones. Please note that this won’t work with the vista20SE as this panel only supports 2 relays.
1 Like
Does anyone know or have tried this with a Vista-10P panel and 6150 keypad?
If anybody is interested. I do have a standalone application that I’m testing which does not require having any home control software in place using this library. It provides a web based virtual keypad as well as push notification and control via the Telegram app. It’s a work on progress but very stable so far. This type of application is useful for a home that only needs access to their alarm system with web notifications without needing any costly monitoring in place since the Telegram app on their phone will allow communications direct with the panel.