Decoding Vista 20se

[CodingSquirrel]

Following up from our conversation on the home assistant board here.

I received my logic analyzer today. You said you could post a setup file for pulse view?

And to double check before I wire it in, I want to connect to the lines going into D1, D2, D5, and ground on the esp? Would I need to also do the 3.3v one too? And ground being shared between the panel and esp side shouldn't be a problem, right?

[Dilbert66]

Technically, you only need 2 channels. Connect the pulseview channel D0 to the yellow line input on the D1 ESP input pin and the pulseview channel D1 to the green line monitor input D5 pin on ESP and then finally ground to the common ground on the ESP side. You don't need to monitor vcc or the ESP D2 output since that will also be seen on the green line monitor input at D5. Make sure you don't connect the channel inputs to any voltage higher than around 5 volts.

You should not be sharing ground between the panel and the esp since you indicated you used the optocoupler isolated schematic to build your circuit. if you did, it won't hurt anything , it's just not needed.

The setup file is really just the decoder setup so you that you can actually see the data being sent. It's attached here. Just unzip it and load it into pulseview by selecting "Restore session" from the menu . Ensure you connect your device first before running Pulseview so that it picks it up on start up. (it will show up as a Saelea 8 channel) . Once it starts your session, you will see 8 inputs. Once you restore the saved session setup, you will see 3 channels and 2 decoders. One for the panel (yellow line) and one for the keypad (green line). You'll need to run the capture twice to actually capture data. Seems like the first time after loading a session, it does not see the channels but the second run is fine.

vistaecp2.zip

Once you have about 1 minute or so of data you can then click the save button to save the session. It will create an *.sr file. zip that and attach it here.

[CodingSquirrel]

I've attached a couple runs. The first one I tried running it and then opening and closing a few doors and windows, but I didn't realize it would only record 50 seconds. So it may or may not have captured them. The second run I open a door right near the start and then close it, then open and close it again.

pulseview_runs.zip

[Dilbert66]

Ahhhh... Excellent. The darn thing is using a completely different protocol and baud rate! Instead of 4800 baud, this one runs at 2400 and uses completely different cmds to send out the info. For example the display message is sent in chunks instead of all in one F7. I have to analyze the protocol a bit to see what's going. I don't see anythign on the green line info. Can you do a run and also press some numbers on the keypad too so we can analyze the responses back. I assume now that any vista devices auto detect the protocol in use and switches to it as needed depending on what panel they are connected to.

[CodingSquirrel]

Attached with a couple more runs. The first is just pressing all of the number keys, then * and #, then the blue and red buttons. The second run is arming away and disarming, then arming stay and disarming.

pulseview_runs_2.zip

Edit: The manual states keypads need to be set to address 31 when using my panel model. It's possible it knows to use the old protocol when set to that address.

[Dilbert66]

ok that helps a lot. You wiring is definitively good as the data looks correct.

Since this protocol is completely different than later versions, it would need it's own library to handle it. I'll cobble something together but it will take some time.

There is no F7 cmd. It gets it status by first getting a control cmd such as 02, 06, 08 with some option bits (have not decoded those yet) that sets status on the keypad. The control cmd will then be followed an FE cmd that starts the display message sequence, then with FF cmds that contain the rest of the ascii sequence. There usually are 8 of those packets containing 4 characters each. The panel occasionally sends a query cmd FA which gets a response of 1C 10 FC. Unknown what that is.

Keystrokes are sent 2 byte pairs for each character. they are sent on their own sync pulse after first sending a request to send F1 cmd first. This is mostly guesswork here as I would need to do action /reaction testing on the panel.

It's not a complicated protocol but as I said, totally different. The protocol uses 8E1 2400 baud instead of 8E2 4800 as used with the later versions.

You might be correct about the keypad knowing how to use the correct protocol when set to 31. It will be interesing to know how expander boards work with this protocol. Do you have wireless/expanders ?

[CodingSquirrel]

That's awesome, and looking at it set to 2400 baud I do see what you are talking about for key presses and responses. For expanders, I have a 4219 wired expander.

If there's any other data you need let me know and I'll try to capture it.

[Dilbert66]

If you also set the data format option on the decoder to ascii instead of hex you will also see the actual character data sent to the keypad display.

If possible could you also capture the bus when opening/closing some devices that are attached to the 4219 so we can see that interaction.

[CodingSquirrel]

I believe I found a couple sensors attached to the 4219. The labeling is not very good in my panel.

I attached another run where I tripped and reset one sensor twice and then tripped and reset another sensor twice that should both be attached to the expander.

pulseview_runs_3.zip

[Dilbert66]

Excellent. do you know what address the 4219 is set to? It helps to decode the addressing on the bus.

[CodingSquirrel]

It's set to address 1, which is what the manual states to set it to.

Switch 1 is on, so it's set to normal response time (300ms). 2,3,4,5 are off,on,on,on respectively for the address.

[Dilbert66]

ok tks. Did a bit more digging. This is interesting. It talks to the keypad at 2400 baud BUT when talking to the extender board, it talks at 4800 baud using a slightly different 98 cmd as the vista-20p. A lot of other differences in how keys are sent ,etc. This will take some time. Keys are sent during the sync pulses while expander devices send their request to send just after the sync pulse then the panel sends a 98 request message and the expander responds with it's address and status .

[CodingSquirrel]

I'll pretend I understand the back half of the comment, haha. I want to say, I really appreciate you taking the time to look into this. If there's anything more I can do to help let me know.

[CodingSquirrel]

Just wanted to check and see if this was still on your radar. If not I might give it a try to see if I can get something working.

[Dilbert66]

This will requre a new base library written to support it as the protocol is very different than the rest of the Vista family. That takes time which I'm short on right now. I do have a board now but have hooked it up yet.

[Dilbert66]

Ok, i've got a basic implementation working for this board. As I noted in the HA forum , this board was a real challenge due to it's odd protocol (some of it is because it needed to work with newer peripherals as well as it's own older protocol devices). It seems to work fairly well so far. You can use the software keypad to program it like a real keypad.

I will post the code to the dev branch later when I get a chance to clean it up and merge it.
Just posting to let you know it's coming soon.

[CodingSquirrel]

Awesome. Look forward to trying it out.

[Dilbert66]

I've pushed a preliminary version to the dev branch. Use the files in the "vista20SE" directory and you can use the existing vistaAlarm.yaml. The expander addresses won't work as it only supports 1 board with address "1", otherwise everything else shold work the same as the vista20p I'm sure there are bugs but it seems to work fine. It will also work perfectly with the alarm keypad so you can use it to program the system with it if you choose to.

[CodingSquirrel]

Haven't had a chance to set up the virtual keypad and everything yet, but so far I'm seeing it correctly send zone and arm status updates to Home Assistant. Looks good so far. Nice job!

[CodingSquirrel]

It's been working great so far, thank you so much for the help!

I've noticed a couple things so far. The first is that it doesn't always update the open and closed state as expected. Is it only able to see the state if it shows in the display? Like for example if I get a "DISARMED-Press to show faults" it will say the door is closed until I press star "" then it will update correctly.

The second thing is that occasionally the display text will show garbage mixed in with the text. But looking at the log the FE and preceeding line will have the same hex values as the previous few sets. For example, one time it showed "READY T:.ARM". It usually fixes itself within a few seconds.

[Dilbert66]

The code should automatically detect the " to show" line and send a "" to simulate the keypress so that the faults will show. Do you have the transmit portion working on the green line? You have to remember that the way the vista system works is that the code will only see what the keypad sees so it's important for those messages to show. As to the closed state, the vista system never sends those to the keypad. Thats why there is a TTL option to adjust when to determine that the zone is no longer open (ie, it never sees any new FAULT messages) and will close the zone after the TTL timeout.

As to the garbage data, I've seen those periodically but don't see it often enough to pinpoint the reason yet. There is no chksum on those data packets so they can't be rejected like they can on the newer Vista's.

[Dilbert66]

I've made some tweaks to the espasync library so you can try that to see if it helps with the garbage lines. Also know, that the display contents come from 8 separate packets of 4 bytes each. I don't display them all so it's possible that one of the 8 is corrupted.

[CodingSquirrel]

Yes, the transmit works. I can arm, disarm, and do any interaction with the virtual key presses (even going through the programming menus).

The garbage issue isn't a big problem since it seems to normally correct within a few seconds when the panel resends the display text. At least the garbage value issue isn't isolated to me. I'll try the latest and see if that improves though.

[Dilbert66]

Interesting then that the request for * is not seen. It might not recognize it for some reason. You can change this line (103)

    const char *
        const HITSTAR = "* to show";

to match what you see there. It doesnt need to match the whole prompt. Just a portion of it. It's possible your system is a bit different. It looks for that match to identify the * request.

As to the garbage on screen. This might be due to wiring. I have not see the corrupted packets in a while on my end. Not sure what version of the schematic you used but I find the simple version is the best for signal integrity. You can try tweaking the optocoupler resistors to increase current . For example, use 3.3k instead of 4.7k for the diode side of the panel.

[CodingSquirrel]

That makes sense it wouldn't match. The full text for mine is

"DISARMED-Press *"
"  to show faults"

It looks like you store the prompt as one value so the line break shouldn't affect it, but likely the double space between "*" and "to" breaks the string comparison.

[CodingSquirrel]

Something I noticed from some limited testing (without the fix) is that it consistently shows that prompt after arming and then disarming. I can also preemptively press "*" and it will go straight to showing the faults even if I don't open a door right away. So "*" could theoretically also be added to the end of a disarm event to reduce the need for checking.

[CodingSquirrel]

Vista 20SE is now supported. Closing issue.