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?

[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?

[Dilbert66]

from the js code in the resources. When you add a card, it just load the js code and displays it in whatever dashboard you are using.

[Dilbert66]

I've pushed an update that fixes an issue with the * being sent while in programming mode. This would cause odd behaviour if your trying to program the system while using the card. You should only need to update the file vistaalarm.h.

[appleguru]

Thanks, seems to be working well. I noticed you checked in some mp3 files and made a few changes for "beeps". Do those work? I copied them over but they don't seem to do anything.

Unrelated, I opened a small PR for the js to improve the button size/spacing to make the keypad behave better on mobile (and also match the native themes): #12

[Dilbert66]

The beep is still a work in progress. It needs to have the beep duration better controlled. It does beep depending on the beep code sent from the esp (you need to also have the beep section setup in the esp yaml).
Add this line to the card config:

beep: sensor.vistaalarmtest_beeps

Awesome about the PR, I'll check it out. I also want to add feedback on a keypress to show visually when the button is pressed. This polymer entity stuff is new to me .

[Dilbert66]

Tried the changes. Excellent. You even have the keypress showing correctly. Exactly what it needed.
I'll clean up the directory structure for the card resources later. I'd like to also add some indicator lights to match a real panel. Could show ready status, trouble, etc.

[appleguru]

I had to enable sound "auto play" in my browser too (it worked ok in the HA app out of the box at least).

Those beeps are pretty bad; maybe I'll just make some recordings of the actual beeps..

[appleguru]

Some more things to eventually go in the wiki if we make one:

Sensor entities from this integration can return the following states:
O = Open / Fault
C = Closed
A = Alarm
T = Trouble
B = Bypass

because they have more than two states, they aren't binary sensors, and the built in "Color icons based on state?" toggle (state_color) will have no impact.

There are lots of ways to address this, but I opted to use custom-ui. You can download a version compatible with the latest Home Assistant here: https://github.com/Mariusthvdb/custom-ui

Once you install the custom-ui.js file, you can add an icon-color glob rule to /config/customize_glob.yaml like this:

sensor.vistaalarm_*:
  templates:
    icon_color: >
      if (state == 'C') return 'steelblue';
      return 'var(--paper-item-icon-active-color)';

Make sure you also enable the glob .yaml by adding this to your main configuration.yaml if you don't already have it:

customize_glob: !include customize_glob.yaml

That's it, once you reboot your entities should be colored when not in the closed state, like this:

[Dilbert66]

Good info. Tks.

[AlexandreUSA]

Just found this thread. I will start the project soon to connect my Vista 21ip to HA. Can't wait to get the electronics on order.

[appleguru]

I see we have a new "Discussions" area on this project. Will start moving some of this information there, since GitHub wiki's aren't really community editable.

https://github.com/Dilbert66/esphome-vistaECP/discussions

Also, gave the latest code a whirl... I like it a lot! Having more buttons I can program is helpful (Eg, buttons to enter/exit programming mode since I'm a Vista n00b and always have to google it otherwise), and I like the status "lights". Only real (minor) nit now is that the bottom row of buttons doesn't auto align with the rest of the virtual panel (likely because they're in their own DIV?).

I guess I can cheat by making the labels the same width so that the buttons align... probably easier than actually "fixing" it:

[Dilbert66]

The idea was to be able to hide the bottom row since some users might not need it which is why I used a separate div but it causes the alignment issue you noticed. For the vista the <> buttons are not needed for navigation but they are used on the DSC which is why I have them there. I wanted a keypad that was flexible enough to use on different systems. I didnt spend too much time on the style to try and fix it as I am more concerned with the functions for now. I'm modifying my dsc application to fully emulate a DSC LCD keypad.

[Dilbert66]

Some more things to eventually go in the wiki if we make one:

Sensor entities from this integration can return the following states:
O = Open / Fault
C = Closed
A = Alarm
T = Trouble
B = Bypass

because they have more than two states, they aren't binary sensors, and the built in "Color icons based on state?" toggle (state_color) will have no impact.

There are lots of ways to address this, but I opted to use custom-ui. You can download a version compatible with the latest Home Assistant here: https://github.com/Mariusthvdb/custom-ui

Once you install the custom-ui.js file, you can add an icon-color glob rule to /config/customize_glob.yaml like this:

sensor.vistaalarm_*:
  templates:
    icon_color: >
      if (state == 'C') return 'steelblue';
      return 'var(--paper-item-icon-active-color)';

Make sure you also enable the glob .yaml by adding this to your main configuration.yaml if you don't already have it:

customize_glob: !include customize_glob.yaml

That's it, once you reboot your entities should be colored when not in the closed state, like this:

I'm going to add this to the readme when I get a chance.

[bmwhitetx]

Sorry to open an old discussion but speaking of the onscreen display I thought I would show a quick mod I made to the file alarm-keypad-card.js. I didn't like dull blue background color and wanted to match the display screen with the backlight on (used this site to pick color). Here is the change I made and what it looks like:

    .keypad_display {
      background: #94ff4d;

Thanks for a great program. I have mine working using the first hardware schematic.

[Dilbert66]

Color is an individual preference. I might just add some config options for users to set their own. I like the one I have but it's not for everyone :)

[bmwhitetx]

Yes, definitely a preference, just wanted to show an option - it was fun trying to figure out the code and how to install the panel. Speaking of which, the instructions on adding this interface panel in the readme.md somehow is tagged as code so it was difficult to read (no line wrap). I ended up just copying the whole section and pasting into an editor with word wrap and was able to follow the instructions. I think the part about the hardware interfaces got duplicated in there too. Its the part that starts with:
'## Setting up the alarm panel keyboard card on HA

And while you're in there, HA, as they are prone to do, moved things around - so this part:
Using UI: Configuration → Lovelace Dashboards → Resources Tab → Click Plus button → ...
Should now be:
Using UI: Settings → Dashboards → Click three dots in upper right → Choose Resources → Click Add Resource button → ...
The file option may have changed as well, I didn't have a lovelace section in my configuration.yaml file.

Thanks again for making this project!