No output to Vista 20P

[rbauman70]

Hey, thanks for making this project available. I can see you put a lot of time into it.

I've assembled the circuitry around a NodeMcu V1.0 and I'm getting status correctly in Home Assistant. I've been unable to get the Vista 20P panel to respond to anything sent from Home Assistant, though. Using the esphome.vistaalarm_alarm_keypress service in the Developer Tools I issue a "#33" string which shows up in the logs on the node. Here's a snippet:

[19:25:11][I][CMD:333]: F7 02 00 FF 10 08 00 1C 08 02 00 00 [19:25:11][I][INFO:524]: Prompt: DISARMED [19:25:11][I][INFO:525]: Prompt: Ready to Arm [19:25:11][I][INFO:526]: Beeps: 0 [19:25:11] [19:25:13][D][Debug:300]: Writing keys: #33 [19:25:19][I][CMD:333]: F6 01 00 00 00 00 00 00 00 00 00 00 [19:25:19][I][EXT:333]: F6 01 00 61 0C 00 6A 62 02 45 43 F5 [19:25:19][I][CMD:333]: F2 0E 02 00 00 00 00 52 FE FE EC 01 [19:25:19][I][INFO:524]: Prompt: DISARMED [19:25:19][I][INFO:525]: Prompt: Ready to Arm [19:25:19][I][INFO:526]: Beeps: 0 [19:25:19] [19:25:20][I][CMD:333]: F7 02 00 FF 10 08 00 1C 08 02 00 00 [19:25:20][I][INFO:524]: Prompt: DISARMED [19:25:20][I][INFO:525]: Prompt: Ready to Arm [19:25:20][I][INFO:526]: Beeps: 0 [19:25:20]

KeypadAddr is set to 16. I've modified the code to write to the GPIO16 output, the NodeMcu LED, but inverted, whenever the TX_PIN is written. Here's a little movie of the LED activity. I gave up my 'scope a few years ago so I can't actually look at the green line to to the panel. Does this seem normal to you? Any ideas for further debugging?

Ron

https://user-images.githubusercontent.com/79720569/109345821-b8488d00-783e-11eb-8c32-605c0eef4ea5.mp4

[Dilbert66]

Looks like you don't have something hooked up right with the optocoupler circuit going to the green line. Only thing it could be.

[rbauman70]

Thanks for the quick response. That's what I thought, too. I forgot I had a USB logic analyzer, so I hauled that out and put some test points on the board. Here's a couple of traces. The TX signal is definitely getting to the green line. But the NodeMcu seems to be the one generating the frequent 3-burst pattern.

Does this look right?

[Dilbert66]

Edit: I correct my comment. Your display above is odd. It's been a while since I looked at some digital dumps so I'm going by memory here. I think you have something odd with the optocoupler or you are sampling at odd locations. D1 and d2 should not be the same. D2 is panel data and that is not shown there. Looking at it now, it looks like the 3 pulses would be the request to send (sent on an f7) , then an f6 would come from the panel with the address of id of the device, then the esp would send the cmd data which is what I think we see there. We dont' see the ack back from the panel as you are not showing the d2 data. So, I'm guessing here. You'd have to have the have the panel decode bits there with 8e2 (or 8e1)

[Dilbert66]

Actually, looking back at your logs. The F6 response is not correct for your device. It's responding to device 01 and not to 10 (address 16). Also it is very delayed so I don't think the panel is responding at all to the esp cmd. Post a few more logs after each cmd sent to see if the pattern is the same.

Are you sure your address is set to 16 in the yaml?

[rbauman70]

The VistaAlarm.yaml has keypadAddr set to 16.

Some context: I have a Honeywell VAM attached to the panel. It's essentially a Tuxedo touchscreen but without the screen. It is considered an AUI device and defaults to ECP address 1 which accounts for the traffic you were seeing. I've disconnected it so it won't obfuscate whatever problem we're looking at. So now it's just the Vista 20P panel (firmware 10.23), one 6160 keypad at address 16 and the NodeMcu device on the ECP bus.

From debug statements, I can confirm that keypresses are requested to be sent in rxHandleISR but never sent since writeChars is not called.

[Dilbert66]

Well, it still points to a hardware wiring issue on the tx line since the fact that the software is attempting to send the request to send (in the rxhandleisr) but it is not sent out. Without this happening, you won't see a corresponding f6 sent back to your keypad address to do the send in writechars. This is not sofware related. The tx data is just not going on the green line.

Edit: or if the rts is being sent out, the panel perhaps is ignoring that address which would be odd for address 16 . You can try a different address perhaps to see if that makes a difference.

[rbauman70]

I tried a different address and checked all the wiring again.

Here's a trace of an ECP request from a keypad when a key is pressed. The keypad is subsequently polled with an F6 command and its address like you described.

This is from a keypress requested from the ESP module.

This gets repeated at every tri-pulse burst. Something is wrong with the timing or the state flow on my module. There's a lot going on on this little device with Wifi running so maybe there's some timing issues. I'll find it eventually. This is a log of the build so you can see the toolchain I'm using.

ESP-build.zip

[Dilbert66]

The display above is not showing enough of the interaction to know what happens when a cmd sequence is sent. Such as the RTS pulses (which you do show) (on D1) then followed by the the f6 10 xxx ( on D2) then the written module data on (D2) then finally followed by the ack byte (D1). But it does show the RTS sequence fine. The odd part is the esp output data is not showing on the d5 monitortx line compared to the trace with the keypad which does show it. The green and d5 monitortx lines should be the same no matter what device is sending. Very odd behavior which to me indicates a connection issue or a bad ground connection somewhere. The other odd aspect is that looking at your esp build zip, there is the initial startup sequence which shows the * being sent by the esp and acknowledge by the panel. I would need to seem more logs of the interaction when other cmds are sent. I have not seen this behavior before. No matter how busy the device is, it should not matter since the rts is interrupt driven. You will always see the panel F6 10 response. If the chip is busy for some reason, the delay would be with the esp response to the f6 after (what you see in the EXT debug print)

[18:10:38][D][debug:832]: Vista::handle f6 10
[18:10:38][I][CMD:333]: F6 10 00 00 00 00 00 00 00 00 00 00 // panel cmd f6 to request device 0x10 (16) to go ahead and send
[18:10:38][I][EXT:333]: F6 10 00 10 02 0A E4 00 00 00 00 00  // esp response to f6. Header byte 10,packet len 02 byte sent: 0A (*) E4 checksum
[18:10:38][I][CMD:333]: F2 12 06 00 00 00 00 65 6C 02 45 6C
[18:10:38][I][INFO:524]: Prompt: ****DISARMED****
[18:10:38][I][INFO:525]: Prompt:   Ready to Arm
[18:10:38][I][INFO:526]: Beeps: 0

[rbauman70]

Here's the keypad keypress traces zoomed out.

The ESP request just repeats.

[Dilbert66]

You can see the difference. The esp request to send is not showing up on the d5 monitor tx output (which is the green line). You have a connection issue somewhere. If you look at the keypad output you can see it the data on the d5 line is showing up fine there. This tells me that the panel is not seeing the 3 pulse request to send. It keeps repeating it since it expects to see an F6 10 before it can send and will keep sending the rts until the panel acknowledges it with an F6.

[Dilbert66]

Also looking at this output from d0 Green line, that one does not make sense to me. Not sure where you're getting that data.

[Dilbert66]

What optocoupler are you using?

[rbauman70]

The MONITORTX does show the ESP request if I crank the logic threshold down to .85v.

I'm using a 4N26. Could it be not pulling the green line high, like in the active region? Doesn't seem likely. I'm more concerned that what should be a single pulse during the third period is showing as two. It's also shorter than the third one that the keypad is sending.

[Dilbert66]

The rts is not supposed to be a single pulse, It's a binary address which is why they are different. The fact that you have to crank the threshold for the esp and not for the keypad is odd. It still looks to be an issue with the pulse at the optocoupler to me. Perhaps try a smaller input resistor such as 220ohm

Can you double check that the input resistor to the optocoupler is indeed 330ohm and not higher?

[Dilbert66]

ok, I went and I hooked up my analyzer, and looking at my output, the rts to send on mine different than yours for address 16. For address 16 you would see a double wide pulse there to indicate address 0x10 and not the double pulse you show on your output. That shows an address above 16. Are you using address 17 or 18? I've attached a sample of mine showing a rts for address 16 and the corresponding f6 and ack

[rbauman70]

I'm using address 18 which accounts for the difference in pulses. The resistor change worked! The 4N26 is spec'd for 10 mA forward LED current. (3.3v - .7v)/.01A = 260 ohms, so 330 probably wasn't allowing enough drive. Thanks for helping me with this. Now I can get the alarm system finished up and work on other Home Assistant integrations.

[Dilbert66]

Good stuff. Glad you got that sorted out. I will change the schematic to lower that value. It works fine for me but that all depends on the tolerances.

[Dilbert66]

Schematic updated.