Add a wiki?

[appleguru]

Any way you can add a wiki to this project so we can build up a knowledge base? (Eg, compatible hardware, example builds, BOM…)

[Dilbert66]

I really don't have the resources at this time to maintain it and have not seen any real requests for more info then what is already available. It's a fairly basic circuit. If there is some confusion , I can always amend the docs.

[appleguru]

Just set it up and open up permissions so anyone can edit? Happy to contribute with a build guide/some photos/getting started/etc.

I’m still trying to sort out “ideal” part numbers for the voltage regulator (which if I understand correctly should allow it to be powered from the vista system?), for the optocoupler, and for the nodeMCU/ESP module itself. I think I can order everything I need for the build from mouser (if I’m willing to overpay a bit for the esp module).

[Dilbert66]

https://www.amazon.ca/Converter-Module-Keenso-Step-Down-Conversion/dp/B07PQLNXVC/ref=sr_1_26?dchild=1&keywords=step+down+mini&qid=1615644230&sr=8-26

or any lm2596 based regulator https://www.amazon.ca/Converter-Ajustable-Step-down-Converters-1-25V-35V/dp/B074J4DLWQ/ref=asc_df_B074J4DLWQ/?tag=googleshopc0c-20&linkCode=df0&hvadid=335365451913&hvpos=&hvnetw=g&hvrand=1334836585404895701&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9000757&hvtargid=pla-899437512675&psc=1

Both of those work extremely well. None of the parts are critical. Any inexpensive optocoupler will work. Same goes with the esp module. Any inexpensive one will work. I do suggest though that you power it with 3.3 volts (at the 3.3 volt input of course) instead of with 5 volts to avoid using the weak built in 5volt regulators on some esp modules. This is why i recommend the regulators above (or similar) as they are fully adjustable.

As to the wiki, I'll think about it.

[appleguru]

What about for an optocoupler? Will a cheap PC817 work?

[Dilbert66]

Sure, I think it would work perfectly

[appleguru]

Thanks. Did an Amazon order (which I generally avoid for electronics due to all the counterfeit parts, but should be ok for this circuit…)

Thanks for putting this together, excited to finally tie my (to date completely useless) existing security system into home assistant!

[appleguru]

Ok, my build is done and seems to be (mostly?) working. Not the prettiest, but functional. I think the remaining issues are likely due to configuration which I could definitely use some help with.

I disabled the expander, relay, and lrrsupervisor in the config since I think I have real devices on the system for all of those.

Arming/disarming from home assistant don’t seem to be working (but this is likely user error? I’m trying to use Developer Tools -> Services for this now but it seems to have no effect. I put my alarm code into a secrets.yaml file as “access_code”. Ultimately I’d like a button for these in the UI, but first need to make sure it works at all…

I think I also might be missing some devices? (But am not 100% sure what I have on the vista system). Any help figuring that out would be greatly appreciated too!

[Dilbert66]

If you can't send keys that means your tx circuit is not working. Looking at your circuit soldering, the optocoupler looks to be miswired. It looks like your are bridging pins 3 and 4.

[appleguru]

I don’t think the pins are bridged, but will double check with a meter when I get home. What’s the easiest way to test TX? Arm/disarm?

[Dilbert66]

Looking at the soldering, they do look soldered together. only pins 2 and 3 go to ground.

[Dilbert66]

Arm /disarm/send a key. You should see a logged response on the esphome log window.

[appleguru]

The circled pins are actually 3/4 on the opto:

[Dilbert66]

If i were you I would double check the pinout on the 817 . The wiring is all wrong from what I see.

https://www.twinschip.com/PC817-Optocoupler

[appleguru]

If i were you I would double check the pinout on the 817 . The wiring is all wrong from what I see.

https://www.twinschip.com/PC817-Optocoupler

I think i have it right? (I misspoke before, I circled 3/4, not 2/3)

pin 1 goes to d2 via 220 ohm resistor Pin 2 goes to GND pin 3 goes to green wire input Pin 4 goes to red wire / +12v input

[Dilbert66]

Yes, that's correct but on the picture pin2 is going direct to the esp module? I don't get it? That should be ground

[appleguru]

Yes, that's correct but on the picture pin2 is going direct to the esp module? I don't get it? That should be ground

It’s going to a ground pin on the ESP module. They all should be connected; was just the closest ground to the part.

[Dilbert66]

ah ok.. I see now. The solder on the underside threw me off also.

[Dilbert66]

Either way, if the log is not showing a key was sent then, you might still have a wiring issue somewhere.

[appleguru]

Either way, if the log is not showing a key was sent then, you might still have a wiring issue somewhere.

Can you take a look at the log screenshot above? I’m not sure what I’m looking at/if it shows the key being sent (I think it does?)

[Dilbert66]

ok, It looks like your sending fine now that I have a closer look at your log image. The F6 is receiving from device id 0x10 (address 16) which I assume is your esp.

Try using the alarm_keypress service from developer tools and send send any keys you want there.

service: esphome.vistaalarmtest_alarm_keypress
data: {"keys":"12342"} 

Where 1234 is your arming access code the final "2" is armed away. You should see response like this on your esp log window

[Dilbert66]

This is my test system so I'm using 1234 as an access code

[Dilbert66]

Those F6 ext cmds in your log (the EXT is a pseudo field to display sent keys from peripherals in response to the previous F6 CMD) don't make sense. they show a lenght of 1. Normally for an arm cmd you will see a lenght of 6 ie. the 4 digit code, the 1 digit arm code and a 1 digit checksum. That would explain why it's not arming.

[adamurban]

Interesting.. Any idea what might cause that? Here's the output using the same 12342 example that you posted (I also of course tried with my actual alarm code too).

[Dilbert66]

Interesting. This looks to be a software bug somewhere. I'm running the same version as the master I think. I'll check to see.

[Dilbert66]

I recompiled my test version from the master copy and everything works fine on my end. Well, it's a mystery to me why your version is behaving like that. I assume you are using the latest master code version. I really can't see how the issue you have would occur.
What panel version do have?

[Dilbert66]

Can you post a longer copy and paste of the logs so I can view normal interactions. Also can you enter any random sequence of characters in the physical keypad and post the associated esp logs as well. Also note what characters you keyed so we can compare to the logs.

[Dilbert66]

It's possible that's it's conflicting with another device. Can you change your esp address to another address such as 17 instead of the default 16. I really havent tested this type of issue so I can't say for sure, but looking at the results, it points to that. My home alarm is really a DSC. I coded up this library with an older test vista20p system I had lying around.

[appleguru]

Success! Moved to address 17 and arming/disarming works ok now.

[Dilbert66]

Good stuff! I should have seen that solution sooner . Hindsight! lol

[appleguru]

Panel is version 10.23, which is why I assume address 17 worked for a keypad… Looking at the hardware, I have: 1) Vista-20p control panel 2) 6160 keypad 3) 5881ENL wireless receiver 4) GSMV4G alarm radio (for remote access??) 5) SRN2000 motion sensor 6) a crap load of contact and bar sensors… 7) WI-MTA1/5817 wireless temp sensor 8) WI-WB200 water sensor 9) ADEMCO-4204 ECP relay module (connected to a system sensor COSMOD2W 2wire fire alarm interface (which connects to COSMO2W smoke/CO detectors) 10) SDM-100 siren driver connected to a AS-SHX51 outdoor siren 11) 4219 wired zone expander 12) MPI35F indoor siren

And probably some other things that I missed. I don’t currently have the programming code for the system, but am hoping to get that tomorrow.

Any tips for identifying everything in HA/making sure I’m not missing any devices?

[appleguru]

From DIP switches, I see that my real 4219 wired zone expander is on address 7 and my real 4204 relay module is on address 12.

Presumably because I have a GSMV4G, I want lrrSupervisor: "false" right? And if I want to use relay and/or zone emulation, I would want to change the default relayAddr1: "12" to 13 or something else, but expanderAddr1: "8" is OK. (I have these all set to 0 for now as I don't yet have a need for the emulated inputs).

Is there a good way to figure out what addresses everything else in the alarm system are set to?

[Dilbert66]

That's quite a loaded system you have. Yes, using the virtual expander with address 8 is ok and changing the relayaddr1 to 13 is correct also. And yes, since you already have a GSMv4g, you definitively want to set lrrSupervisor to False. That interface is used to report faults to a remote using cell or pager. With my system I just use those messages for display as it provides more info.

As to finding out what zones you have, there are two ways I guess. Open up every zone and record the message displayed on the keypad or the esp. The other method requires having the installer code and going to program 56, press 1 (to confirm) then use the key to step through all the programming to see what zones are setup and what type.

Did you try installer code 4112 or 6321 . Those are the defaults .

You enter 4112800 or 6321800 and see if it gets you the installer prompt. You should download a vista20p installer manual . Just google it. Lots of copies around.

[appleguru]

Yeah, the alarm company changed the default installer code; I tried both of those. I called them today and they said they should be able to remotely reset it back to the default code for me tomorrow; we’ll see if it works?

Used your example template to add a keypad, looks nice! I don’t really need/want to have to enter the code each time to disarm, so just hard-coded the “code” field and manually added the “disarm” state, which seems to work. Only problem now is the virtual keypad is useless… any way to make it pass the button presses through to the alarm_keypress service so I can use it like the real keypad on the wall?

[edit]In hindsight I guess I just needed to hardcode the code and not add the disarm entity manually… not much use in disarming when the system is already disarmed:

[/edit]

[Dilbert66]

What's needed is a different virtual keypad component. You are right that the existing keypad is very limited as it is now. Not sure what's available but that's a good idea though to fully emulate a keypad. If there isnt one around, I might try my hand at coding one up.

Once you find out your zones, you'll need to add new sections in the yaml to represent those and edit the existing to match your setup.

[appleguru]

I don’t think it quite works like this, but being able to conditionally call a service might work… something like:

        disarm: >
            {% if {{code}} %}
              - service: esphome.vistaalarm_alarm_keypress
                data_template:
                  keys: '{{code}}'
            {% else %}
              - service: esphome.vistaalarm_alarm_disarm
                data_template:
                  code: '1234'
            {% endif %}

[Dilbert66]

Maybe, I have not really looked too deeply into it since as it is the default panel is limited in it's ability to work as a standalone keypad since it is missing the "#" and "*" keys which are needed in a lot of commands, such as programming, etc. I'm going to look into adapting an existing custom card to add those since it will also be useful for my DSC implementation.

[appleguru]

Ok, progress.. found some system documentation with zone numbers listed that seems mostly correct, and also got the programming code.

I updated the yaml template entires and case statement entries like this:

   - platform: template
    id: z15
    name: "$systemName Basement Water Sensor"

case 15: id(z15).publish_state(open); break;

I now have a bunch on unavailable entities that I can’t seem to remove for the zones I no longer have, but the things that are there seem to be working. Will dive into the panel config on the keypad later and double check everything once I figure out how :D

One question: I see a few entries in the log like this:

 Got relay address 7 channel 12 = 0
 Got relay address 12 channel 56 = 0
 Got relay address 12 channel 53 = 0

Does this mean there are input devices I don’t yet have mapped? Or can I ignore these? I guess I still need to wrap my head around how addressing works in the vista system (address vs channel vs zone…)

[Dilbert66]

You might need to delete the esphome vista alarm entity and re-add it. That's the only I found to remove ghost entries after changes. Those relay messages are status changes from your panel. You can ignore those unless you want to see the relay activities. You can also comment out that log message from vistaalarm.h if you don't want to see it. It's more of a debug message than anything.

[Dilbert66]

By the way, I'm testing a custom keypad component that will work just like a regular alarm keypad with all keys. I also found an issue with the way my code handles key writes that I need to fix up so I will be pushing an update in a day or so.

[Dilbert66]

I've pushed a new commit to the "DEV" branch. This fixes the key send issue and adds a new custom panel card which emulates a regular keypad. You'll need to use the new yaml or at least add the changes below:

    VistaECP->onLine1DisplayChange([&](std::string msg) {
        id(l1).publish_state(msg); 
    });  
    VistaECP->onLine2DisplayChange([&](std::string msg) {
        id(l2).publish_state(msg); 
    });   

  - platform: template
    id: l1
    name: "$systemName Line1"

  - platform: template
    id: l2
    name: "$systemName Line2"

[Dilbert66]

I will add a few more buttons later such as the arm night/day/etc buttons and disarm.

[appleguru]

I think the c files are missing a function (unless I copied the wrong files??)

Compiling /data/vistaalarm/.pioenvs/vistaalarm/lib4d9/ESP8266WiFi/ESP8266WiFiMulti.cpp.o
Compiling /data/vistaalarm/.pioenvs/vistaalarm/lib4d9/ESP8266WiFi/ESP8266WiFiSTA-WPS.cpp.o
src/main.cpp: In lambda function:
src/main.cpp:616:17: error: 'class vistaECPHome' has no member named 'onLine1DisplayChange'
       VistaECP->onLine1DisplayChange([&](std::string msg) {
                 ^
src/main.cpp:619:17: error: 'class vistaECPHome' has no member named 'onLine2DisplayChange'
       VistaECP->onLine2DisplayChange([&](std::string msg) {
                 ^
Compiling /data/vistaalarm/.pioenvs/vistaalarm/lib4d9/ESP8266WiFi/ESP8266WiFiSTA.cpp.o
Compiling /data/vistaalarm/.pioenvs/vistaalarm/lib4d9/ESP8266WiFi/ESP8266WiFiScan.cpp.o
Compiling /data/vistaalarm/.pioenvs/vistaalarm/lib4d9/ESP8266WiFi/WiFiClient.cpp.o
*** [/data/vistaalarm/.pioenvs/vistaalarm/src/main.cpp.o] Error 1

[Dilbert66]

My copy missed some files. I've pushed them now. Try it again.

[Dilbert66]

I've updated the card to now allow configuring the 4 function keys to send any sequence of keys. You will need to update the resource file like so: /local/alarm-keypad-card.js?ver=1 (where 1 will increment everytime you need to refresh changes to it), You will then need to do an F5 on the browser to refresh the page and load the new version.

[appleguru]

Slick!

I didn’t see your example card yaml anywhere, so had to type that from your screenshot… here’s mine:

type: 'custom:alarm-keypad-card'
title: Vista
unique_id: vista
kpd_line1: sensor.vistaalarm_line1
kpd_line2: sensor.vistaalarm_line2
scale: 1
view_pad: true
kpd_service: vistaalarm_alarm_keypress
button_A: STAY
button_B: AWAY
button_C: DISARM
button_D: BYPASS
cmd_A: '12343'
cmd_B: '12342'
cmd_C: '12341'
cmd_D: '12346#'

[appleguru]

This virtual keypad is absolute 🔥… I can now do programming right from HA and don’t have to stand in the hallway taking photos of the LCD like a dork!

[Dilbert66]

I didnt post a yaml since I configured it using the gui. I can post a yaml too. As to programming via the gui, that was the idea!

[appleguru]

I didnt post a yaml since I configured it using the gui. I can post a yaml too

Maybe I missed the UI option? How/where would I find that? (I didn’t see it in “Add Card”, clicked custom at the bottom and just typed from your example screenshot. It helpfully prompted me for missing fields)

[Dilbert66]

When you edit a dashboard, you will then see an Edit on each card where you can make changes there.

[appleguru]

When you edit a dashboard, you will then see an Edit on each card where you can make changes there.

right, but where does the card come from in the first place?