Vista 128bpt support

[TimelordDrWho]

First let me say, "YOU ROCK!". Built an isolated version of the interface and after some tinkering with resistors to get a clean read without gibberish and I was on my way to monitoring my shop alarm thru my Home Assistant. I'm using the dev version for multiple partition support and can see and interact with both partitions. Only problems I seem to be having is that the zones don't correspond to the what's in the panel and I think it might have something to do with the 128bpt supporting 128 zones with the panic zones being 997, 998, 999. I did edit the vistaalarm.h to 128 zones max. I'm pretty sure it has to do with my panel using 3 digit address vs the 2 digit addressing expected. Also I'm using the polling loop for all my sensors (except 2 glass breaks) if that makes a difference. The other issue I'm having is with the lrr emulation, other than changing it to true in the alarm.yaml, is there any other configuration? I set it to true, but never seem to see any lrr messages. Don't know if it makes a difference, but on the 128bpt panel, I'm expected to set an ecp address for the lrr module, but I don't see anywhere to put an address in for the lrr emulation in the alarm.yaml Thank you for all the time you spent on this wonderful piece of software and for your help.

[Dilbert66]

yes, the system is set for a max of 255 zones since I used unsigned 8 bit integers. I will need to switch to full integers for storage. I can do that but will take a bit of effort to do and I'm not sure when I'll get a chance. It's most likely not a huge change but it will need testing. I would also need to see some logs of how your panel sends out zone statuses.

As to the lrr issue, the other systems don't need an address. If yours needs that, then that might mean that the protocol is a bit more complex to enable the emulation. I'd have to see logs of a working 128bt system with lrr to see the difference, otherwise I would be guessing.

[Dilbert66]

I've pushed a new update to dev that adds initial support for zone numbers > 255. It's not complete yet as I need to see your logs to identify how the extended zone numbers are sent on the F7 command. Instead of one byte, the zone s in your case will be sent as 2 byte.

[TimelordDrWho]

Wow, I was not expecting a response so fast. Sorry for the the delay in my response, had to chase down a solder joint I flubbed when swapping resistors, lost the TX overnight and took a few to figure it out. Anyway, here is a Zip file with a log (using update you posted, lrr emulation=true) where I opened and closed a few doors, and pushed the * key on both a physical and the virtual keypad. Also included is a sanitized configuration printout from Honeywell compass alarm software, the relevant sections of the alarm.yaml file with the zone entries and the documentation I have on the panel. Let me know what else you need and I'm on it. Thanks again

Vista128_Info.zip

[Dilbert66]

Awesome. Ok, I had a quick look at your logs and a couple things I noted. First it looks like you are not getting a clean signal on your read line as I see a lot of checksum errors for the F7 cmd. Those are indicated with the 77 at the end. It's a flag I put there to show that. This tells me that your line has a weak signal. You might want to adjust your resistor values on that line again. I see that it does indeed use 3 digit zones but from what i see, the ones with a leading zero look ok. The concern I have is the zone 100 one which doesnt show up in the packet data. That's an odd one. It's possible that the zone high digit is stored in another byte in the packet further in the sequence (not in the first 12) but that would be odd as the rest of the packet is message data.

Anyhow, could you trigger some zones that have a zone number higher than 100. This would help identify the missing field.

As to the lrr, I don't see any data there. Those messages are carried in the F9 cmd. You need to enable that in the panel. In a vista20 you just enable it in cmd *29 but on your panel I don't know. I havent looked at the manual yet. If your panel needs an address, you can try entering a bogus one and see what that does.

Edit: Another thing I noticed, is in the yaml setup is incorrect for your zone lookup. The case xx has to match your zones. For instance, to trigger zone 100, you would use: case 100 : id(z100).publish_state(open); break;

Not case 31 like you have. The case numbers don't need to be sequential.

Edit: Here's some info I found to enable LRR on the 128. Might work for you.

http://www.techresource.online/guides/197

[TimelordDrWho]

Good to know about the case #s and zone #s, I'm more of a hardware guy, software is more akin to ancient Egyptian to me, I can stumble thru if I have a good enough reference manual 😆. I'll make the changes and and swap the resistors again and post another log with the >100 zones triggered for you. I hope it wont make a difference, but most of the zones >100 are for rf fobs and access control. I'll also renable a dummy ecp address for llr, I had tried that before, but didn't seem to be seeing any valid messages just the 'vistaalarm Lrr Msg': Sending state '' message.

[Dilbert66]

Did you try the link I posted above about the lrr? They seem to use device address 03 there so give that a shot. I started as a hardware guy but moved on to software many years ago... So I play in both sandboxes :)

At least we know the main issue you were having is the case statements. Once you get your signal sorted out you should be in good shape. Right now you are missing a few partition messages because of the checksum. Those f7's are the zone and system updates.

[TimelordDrWho]

I already have an rf expander on ecp id 3, I'll have to use id 4 for the lrr.

[TimelordDrWho]

Alright, I dropped the resistors on the ecp bus side to 3.3k and am still seeing some f7s ending in 77. How much lower can I safely go on those resistors?

Fixing the case # = zone # fixed the scrambled zones.

Here is a log with zones 100, 121,and 123 triggered in that order. It also has a lrr enabled in the panel on ecp address 6. Zone 100 is the latch bolt monitor on the access control and zones 121 and 123 are rf keyfob buttons if that makes a difference. The only other things besides zone 100 currently up in the 3 digits are access control (vistakey modules, they connect via the vplex polling loop) and rf keyfob buttons that aren't available right now (home with employees).

Also, how should I handle my relays, they aren't the normal relay board hanging off the ecp bus, they are vplex polling loop relays that are programmed as zones 60-64 then again in the panel as relays. Check the config I sent earlier and it should make sense. Anyway, currently the relay status as zones shows 'unknown'. Should I just put them in both places in the yaml?

Thanks again. Please tell me there is an address where I can send you something to show my appreciation, I've been doing some really cool James Webb prints with my 46" HP z3200 printer that I'd love to send you a few in recognition of your awesome software and help. logs_vistaalarm_logs_zonesover 100_triggered.txt

[Dilbert66]

Ok, you should not go too low as it will affect the whole bus since you will be loading it up. The best way to see what's going on is to use an oscilloscope. You should be getting square pulse of around 12 volt max going to 0. Lowering the resistor too much will bring that voltage down. What optocouplers are you using? You can always try the non-isolated version. That always works very well and less problematic. I find the optocouplers a bit fiddly some times to get the right values as the gains differ from type to type.

ok, I can see that you have enabled the lrr as I can now see the F9 commands. The oddity is that I can see other devices respond to it (the EXT:xxx messages) which is odd. A couple do send some interesting looking responses. Another thing is I don't see the f9 cmd that is reporting the usual statuses (sub command 58) so that's a mystery also. Looks like your system handles lrr a bit differently.

For relays, normally those statuses come as FA commands (same as with zone expanders) which I don't see any in your logs so that looks to work differently on your system as well. So I don't have an answer yet as to how you should handle those as they dont' show up in the traffic that I can see. Were any activated in the logs? I didnt anything there.

Those telescope prints must look phenomenal on that printer but I don't think you want to ship anything to Canada! It costs an arm and a leg up here to ship anything. But I do appreciate the offer :)

[Dilbert66]

I looked in the logs and didnt see anything from zones 121,123. Only 100. But then again those might have come on the F7's that had checksum errors. Another oddity is that you indicated that you have zone expanders and RF devices but I don't see that traffic in the logs either. With the vista20, you would see FB and FA messages related to those devices. Again, this looks like your system handles those a bit differently with different hardware.

Edit: ok, I did see some FB's in your original log but the responses are unknown at this. They don't match the 5 byte statuses I saw for the RF zones with include serial and status for the rf device. Perhaps they are keyfobs but at this point, I can't identify what the traffic is without knowing what event happened at the time of the log entry.

[Dilbert66]

Going back to the circuit, seems like a lot of people gravitate to the full isolation version to implement on their system but in my opinion, it's the least favorable one for the reason you see. It's assumed that because it's isolated electronically, that it will have no impact. On the contrary, it has more impact then the non-isolated version if not done right due to it's current sink dependency. For instance, to be able to get a decent signal output, we have to have the smallest serial resistance value we can without loading up the line too much. If the optocoupler does not have enough gain, that will be problem since, the resistor value needed to get a good signal, will cause too much loading on the bus and will affect all connected peripherals. The bus can only source so much current.

By using the non-isolated version, we use 33k in series with a 10k effectively putting 43k on the bus which will only add a minuscule amount of loading on the bus but still give us a strong signal ouput on the esp side since the signal will be voltage driven, not current driven like the optocoupler version. The only optocoupler used in the non-isolated is the TX line which does not cause any loading in idle.

I provided the optocoupler version because there were some requests for it but my recommendation is to go for the simpler version for reliability. The bus voltage is capped at 12 volts so there is no issue of voltage spikes, that could impact the ESP. Also , any short, etc on the ESP side won't impact the ECP bus due to the high resistances used on the voltage divider portion.

Anyways, this is my speech on the subject :)

[Dilbert66]

You might want to turn off the LRR emulation in the yaml and perhaps the panel. I see a lot of traffic generated but at this point, the protocol looks to be very different than the vista20 so I really can't do much with it since I dont have any hardware to experiment on. It's just going to clutter up your logs for no reason anyways. Also the LRR is nice to have but not really necessary for monitoring the panel. It just provides extra details. We would need to view logs of an active LRR session using real hardware to see what info gets sent/received. Right now it's just guessing.

[TimelordDrWho]

Ya, you're right, should have just built the simple version, I did see the whole discussion about it. I opted for the isolated version (using 4n35) mainly as an excuse to go see the guys at the local electronics parts shop and have a small project to build. Wouldn't be the first time that doing things that way has bitten me in the ass. I'll build a simple version today and put it in this evening.

Ok, as far as what equipment is all hanging off the ecp bus the list is address 0: Partition 1 keypad 6160 address 1: Partition 9 keypad 6160px address 2: RF expander 5881enhc address 3: RF expander 5881enhc address 17: ESP virtual keypad partition 1 address 18: ESP virtual keypad partition 2 address 23: Prox-Tag reader integrated in 6160px for rfid tag arming/disarming programmed for partition 2

RF Stuff: No sensors currently, only 4x 5834-8 RF keyfobs. (zones 121,123 are the 2 actions (They trigger the access point for the gate and entry door respectively) I have entered in the programming currently for the remote I carry).

Relays: They are 4101SN V-Plex Single-Output Relay Modules. Currently I have 5 hooked up. I use them to indicate if the system is armed via some led lights outside. As V-Plex devices they are programed in as zones, then under the panel relay programing you enter the zone id where the ecp address goes.

No, I don't think any of the relays were trigger in any of the logs I sent, I'll make sure to make a log where they are triggered this evening.

Other Equipment on the system: No expanders 1x 4297 V-Plex Loop Isolation Extender 2x VPLEX-VSI Polling Loop Short Isolator 3x VistaKey Access control modules. RFID swipe card access control systems wired to the door and gate. 1 on entry door and 2 on the gate (1 inside, 1 outside the gate (inside one allows to close the gate with a card once inside they open again) System disarms on valid card swipe and opens gate or door. System can also arm partition by pressing button programmed as 'exit button' then swiping card on reader after exiting.

lrr: Might have a solution to getting some valid messages, I still have a 4g comm module from when the system was monitored by total connect. I can try hooking it back up and capturing some logs for you, will do that tonight.

And as far as shipping some prints to Canada, I'll gladly do so, heck you're our "Neighbor to the North"; Hello from the Southwest USA, Albuquerque, New Mexico to be specific. I would have happily shipped around the world for the person that wrote this software and all the help you've given. Thanks again P.S. I also have some textured material that makes for some stellar looking art prints if there is a painting you want a print of.

[Dilbert66]

That's quite a setup you have there! Those commercial alarm system do add quite a few features. Those V-plex loops are new to me. Gonna have to read up on those. My personal home system is a DSC Power832 panel so I play around at developing ESP32 software for both systems. The vista20 system I have is a bench test panel I use for testing the firmware. I can see that the main parts of the ESP firmware will support the panel as far as zones , system status, etc. Perhpas RF statuses too. Just need to figure out the data for the fobs. As to the relays, that's going to be tough since those are sitting a separate bus (the polling loop) and not on the ecp bus so we can't intercept the communications between the panel and the polling loop devices. If the relays are triggering a zone (or zone follower type setup) then we can use that since that should show up as a normal zone being triggered, otherwise, I'm not sure how we can capture relay activity.

This is an interesting setup. I'm always happy to enhance the software to support more devices if I can.

And a hello back from Toronto, Ontario, Canada :) It's getting colder up here. Winter is around the corner. I'm sure you're enjoying a bit more the warm weather a bit longer! I'll keep it in mind about the prints! I'm sure they look incredible on that beast of a printer!

[TimelordDrWho]

Apologies for the delay in response, been a busy couple days (car sensor died and left me stranded @ 3am, had to fix that and play catch up).

Managed to eliminate all the messages ending in 77, so pretty sure the interface is solid at this point.

Forgot that I also have a receipt printer hooked up to the serial port for arm/disarm/access logs and to assist with troubleshooting. Currently it is set to output pretty much everything (all faults/restores/trouble/etc) there is while I'm working on it. It does keep track of if the printer is on-line, so that may generate extra messages..

Here are a bunch of logs for you. RF_Button_log; Triggered button on RF remote corresponding to zone 123, which triggers access point 1 (vistakey access control), repeated 3 times. Did not open door when access granted so should be no other trigger zones.

Relay_log: Turned on/off Relay 04, repeated 3 times. Relay 04 is programmed in panel as zone 63 (since it is a vplex relay like the other I have), shows as zone 604 in other places (notice the panel messages when it auto-advances, relay 5 shows as zone 605 in the log).

Access_log: Used access keycard at access point 1 to open door (zone 25 and 100 (latchbolt monitor), repeated 3 times.

Access_arm_log: Used keycard at access point 1 to arm partition 2 Arm procedure: 1: Press button corresponding to zone 32 (momentary exit) 2: Exit door corresponding to zone 25 (door magnetic sensor) and zone 100 (latchbolt monitor on the vistakey access module) 3: Close door 4: Swipe keycard on reader 5: System arms 6: System closes relay 5 (zone 64) to turn on green light outside as visual reference that system is armed

Access_disarm_log: Used keycard at access point 1 to disarm partition 2, then opened door zone 25 (don't know if the commands sent from the vistakey module differ if system is armed vs disarmed, don't know if it makes a difference but figured I'd include it).

Don't worry about any access/user codes in the logs, I created a new user with a code and keycard just for this project for the logs (does the code look familiar, are you an 80's music fan?)

I dug up the old lrr module that was on the system a few years ago, its a Honeywell LTE-XV communicator module. I need to see if I can dig up any of the old settings sheets from back then to see what address it was on (soft address programming, no dip switches), failing that I was thinking to just factory reset it. Then I plan on pulling the sim card and hooking it up to see if I can get you some logs to see if there is anything useful there. I know you won't get any of the central station responses, but hopefully it will give you something. Give me a few day on that one though, my filing system is a bit atrocious.

I've also included with the logs the manuals I have on the vistakey module and the LTE-XV module, plus a couple of picture of some of the art prints I did just to show off a little bit and encourage you to take me up on my offer.

Let me know if there is anything else you need from me and I'll get right on it, although my response time might be a bit slow for the next couple days.

Thanks again

alarm logs 11-13-22.zip

edit: Do you have a copy of the Honeywell Compass software? Its for programming vista alarm panels. If not I'll post you a link to grab it off my nextcloud.

[Dilbert66]

Wow, great details and logs. Tks! I've been going through them a bit and I can see that you have corrected the communicataions issues. Looks good now. What did you end up doing?

First, as to the relays, I can see the interactiion with the keypad to the panel to turn them on or off but I do not see any flags that can be used to capture a relay change that is not triggered by keypad cmd.

As to zone interaction, in particular zone 100. I still can't where the most significant digit is sent in the F7 cmd. Only the lower 2 digits are sent as usual. Not sure if the panel sends those since the keypad would not need it. Perhaps for capturing the zone, the actual panel line message would need to be parsed for the zone number instead of depending on the cmd byte as I do with the vista20. I don't like doing that as it's language and panel message specific.

As to the RF and swipe cards, I can't see anything in the f7 or fb cmds to indicate anything new but there is some interesting activity on the bus which I'm not sure what it is. Those are the EXT: cmds . Those are from monitoring the peripherals on the bus so those unkown cmds are data sent to the panel from those devices. They don't look familiar so I'm assuming here this is in response to a different cmd that I don't have decoded yet. They could also just be noise but there is a consistency to them. I really don't know how much info they would carry and how long the packets are. I would need to use a logic analyzer on the bus to know for sure what's going on.

For now, I've pushed a small update to the dev branch to add a bit more debugging to see if a new cmd is being sent. The only file changed is the vista.cpp file. Give that shot and try the RF button again and see if anything comes up.

Those prints look great! Like the Mona Lisa!

[TimelordDrWho]

Ended up going with the simple resistor version, but with the small change of following Honeywell's spec for powering ecp devices with a separate power supply. Pretty much break the 12v connection to the panel and wire in a 12v power supply between the 12v in and ground.

Ya, the v-plex relays are a bit weird, they seem to have 2 zone numbers associated with each relay; the first one whatever zone I program it as, then another zone in the 600s, plus the relay number that I assign it. I'm guessing one of the zones is used for tamper, the other for status (I swear I read somewhere the relay position was supervised) but that's just a guess. It does allow me a bit more flexibility in their use though. Example, I can assign zone 60 relay to two different relay addresses, That allows me to have 2 different triggers on the same relay and use two different effects (not sure if you can do that with the ecp style relays). Armed Away triggers the relay controlling a green led to go solid, while Armed Stay triggers the same relay as pulsed. Maybe once the over 100 zones are resolved it will fall into place (maybe relay status are in the 600 zones, since I'm not using the tamper supervision) 🤷‍♂️

I had a thought last night about getting you more info on zones over 100. It dawned on me I have a couple extra door sensor for a project I haven't made it to yet; I'll pull them out and reprogram some of the rf remotes to addresses below 100 and the door sensors into those vacated slots. I should have 3 so I'll spread them out between 110 and 128 and I'll put 2 on partition 1 and the other one partition 2 (I only have one other sensor on partition 1, the gate sensor). Hopefully that will give you more info.

Just tell me what logic analyzer to order off Amazon and I'll get one on its way (I'd rather you recommend a quality one over cheap, as long as its under $100 I can just pin it under normal business supplies, Thanks). You may have to walk me though a bit of the usage though.

I'll update with the new cpp file and other changes as mentioned above and work on getting you logs tonight.

Just let me know what size you want (up to 44' in the biggest dimension; and the material I use for fine art prints is self-adhesive, just peel and stick it right on the wall) and a copy (or if you have another favorite piece, I'll see if I can find a good hi-res copy to print) is yours. Like I said it's the least you deserve for all your hard work. (Plus its a win-win for me, I need to print stuff every so often to keep the printer heads from clogging solid and the family and friends are running out of wall space).

Thanks again

[Dilbert66]

Good plan about a separate power supply. I just power mine via the usb port. Works fine.
Yea, that vplex bus is interesting. Unfortunately, it's a separate bus really and the only way we can know what's going on is to capture what gets sent to the display panel. That info is pretty limited. With the vista20, the zone expanders, rf modules are all on the same bus as the display so we can intercept all their communications. Not so with the polled loop. I don't know anything about the protocol, etc. Is it encrypted? etc.. You'd have to have that bus monitored separately. At least, for faults, the panel send that the panel so we can capture that. Not sure yet about RF devices, etc.

As to a logic analyzer, I use the cheapest clone out there and it works perfect. I also use Pulse View to capture the data. Something like this one: https://www.amazon.com/HiLetgo-Analyzer-Ferrite-Channel-Arduino/dp/B077LSG5P2/ref=sr_1_3?crid=1SI4K50OB1NOP&keywords=logic+analyzer&qid=1668472493&sprefix=logic+anal%2Caps%2C133&sr=8-3

Here's a quick run down on how to get a sample with pulseview and the analyzer:

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. Connect the ground line to the black line. Panel ground.

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.

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.

vistaecp2.zip

I'll let you know about the prints. Not sure yet as to what i would want on my office wall! I have to work around my wife's decorating too :)

[TimelordDrWho]

Cool, logic analyzer on order, should be here in a few days. In the mean time, I'll move ahead with the stuff mention above.

Feel free to ask the wife if she wants a print of anything, I don't mind printing a couple of individual pieces for you and her.

[Dilbert66]

A couple things. Try to sample on the esp side as technically the logic analyzer is only rated to around 5 or so volts. I have used it on the 12 volt bus directly with no issue but be aware. Also, the main area of interest is the EXT: data from the logs so if you can sample during the times where you see this type of data;

[20:46:10][I][EXT:505]: 2022-11-12 20:46 F6 12 00 03 78 00 50 04 05 00 00 2C FD [20:46:11][I][EXT:505]: 2022-11-12 20:46 F6 12 00 FD FD 00 50 04 05 00 00 2C FD [20:46:11][I][CMD:505]: 2022-11-12 20:46 F7 00 00 84 00 25 00 1C 08 02 00 00 2A

or this:

[20:39:30][I][EXT:505]: 2022-11-12 20:39 03 00 05 FD FD 05 D8 FD 12 F0 00 2C 74 [20:39:31][I][EXT:505]: 2022-11-12 20:39 03 00 05 FD FD 05 D8 FD 12 F0 00 2C 74 [20:39:31][I][EXT:505]: 2022-11-12 20:39 03 00 05 FD FD 05 D8 FD 12 F0 00 2C 74

The packets don't have to match exactly but it's definitvely the ext traffic that is of interest.

[Dilbert66]

I've pushed an update to vistalarm.h that can capture zone numbers from the f7 message instead of depending on the zone field that is part of the f7 data packet. This allows detecting zones above 99 since the F7 zone field only stores up to zones 99. Using the FAULT xxx message allows to use that to capture the true zone# from the text.

[TimelordDrWho]

Dang you're fast. I spent the night wiring in the spare sensors I was talking about and reprograming the panel and hadn't made it to updating the interface or capturing logs yet. Logs should be incoming tonight. Logic Analyzer should be here on the 17th.

[Dilbert66]

Was an easy change so I figured I'd add it. At least all the zones and such will work fine for you now.

[rcmurphy]

Not sure if you’re still working on this, but I just got a 128BPT and have a 4ch scope; let me know if there’s any assistance I can offer!

[Dilbert66]

What I want to do is try to decode the EXT messages which come from a peripheral on the bus. Most likely the RF extender. The format is unknown to me at this time so I want to capture the complete packet. No need for the scope at this point. I will see if I can modify the logging function to display the complete packet instead of only the first 13. This will allow for analysis of it. At this point , all zone activity should be captured now. Thanks for the offer though.

[rcmurphy]

@TimelordDrWho what resistor values did you use?

Edit: I see the issue now is that I was using the fully isolated version; could you maybe add a disclaimer given your remarks above @Dilbert66 ?

I wonder if for Vista - 128 / 250 series panels it would be better to listen to serial port activity vs the ECP bus; I can't seem to find any semblance of protocol documentation for it though.

[TimelordDrWho]

Apologies for disappearing for so long, Murphy decided I needed a kicking, (had a project go sideways, then threw out my back. The painkillers were nice though 😵 😴 ).

Getting back onto track with this now.

@rcmurphy I ended up building the simple resistor version using the recommended values. Worked great once it did that. Although I did opt to add a separate power supply onto the ecp bus (then a buck for the esp32 off that) using Honeywell's recommended method (pretty much break the 12v line from panel, external 12v to the ecp device, tie all gounds together) due to the number of devices on the system (I suspect I might have been closing in on the panel current limit due to the vplex isolators, extenders, and relays + the 2x radios and 2x keypads on the ecp bus.)

@Dilbert66 I got the logic analyzer , expect incoming logs shortly

[Dilbert66]

@rcmurphy , good point, I will add a few comments about the possible issues of the isolated version vs the simple resistor divider one.

Unfortunately , I don't have access to a vista128 so cannot assist in reverse engineering the serial traffic. As you noted, there isnt much about it. I read that it runs at 9600bps on it.

@TimelordDrWho , hope your back gets better soon. I've been there!

[rcmurphy]

There should also be a bunch of zones in the 800-830 range reporting, if ECP bus supervision is configured, fwiw.

I'm having issues picking up lower zones as well (ie. 60-61).

Edit: bumped MAX_ZONES up, which catches everything up to 99.

[Dilbert66]

There should also be a bunch of zones in the 800-830 range reporting, if ECP bus supervision is configured, fwiw.

I'm having issues picking up lower zones as well (ie. 60-61).

Edit: bumped MAX_ZONES up, which catches everything up to 99.

The default field that I use for capturing zones only shows up to 99. That's why I made a change to capture the zone from the F7 display message. That should work for zones above 99. If it doesnt, please post a log showing a fault message with the zone .

[rcmurphy]

Ah. I was testing with Bypassing. Let me know if you want them with debug = 1

[19:37:49][I][INFO:835]: Prompt: HOME DISARMED    
[19:37:49][I][INFO:836]: Prompt: BYPAS-RDY TO ARM
[19:37:49][I][INFO:837]: Beeps: 0

[19:37:52][I][INFO:815]: Display to partition: 01
[19:37:52][I][INFO:835]: Prompt: BYPAS 200        
[19:37:52][I][INFO:836]: Prompt: UTILITY TAMPER  
[19:37:52][I][INFO:837]: Beeps: 1

[19:37:59][I][INFO:815]: Display to partition: 01
[19:37:59][I][INFO:835]: Prompt: BYPAS 821 TAMPER 
[19:37:59][I][INFO:836]: Prompt:                 
[19:37:59][I][INFO:837]: Beeps: 1

[Dilbert66]

ah, ok, I will make changes to pickup the zone on the bypass message as well. Tks.

[rcmurphy]

@Dilbert66 would you like me to get you a high zone number in check/trouble as well?

[Dilbert66]

Sure, I also need to see the previous F7 cmd as well. Tks.

Edit, no need about the trouble or check as I they will be similar to the fault and bypass, but I definitively need to see the F7

[rcmurphy]

[19:55:01][I][CMD:507]: 2022-12-07 19:55  F7 0F 00 10 00 00 01 10 38 02 00 00 42 
[19:55:01][I][INFO:815]: Display to partition: 01
[19:55:01][I][INFO:835]: Prompt: BYPAS 200        
[19:55:01][I][INFO:836]: Prompt: UTILITY TAMPER  
[19:55:01][I][INFO:837]: Beeps: 1

[19:56:52][I][CMD:507]: 2022-12-07 19:56  F7 0F 00 10 00 21 01 10 38 02 00 00 42 
[19:56:52][I][INFO:815]: Display to partition: 01
[19:56:52][I][INFO:835]: Prompt: BYPAS 821        
[19:56:52][I][INFO:836]: Prompt: XMITTER SUPERVIS
[19:56:52][I][INFO:837]: Beeps: 1

[19:56:30][I][CMD:507]: 2022-12-07 19:56  F9 55 02 52 5E 00 00 00 00 00 00 00 00 
[19:56:30][I][CMD:507]: 2022-12-07 19:56  F7 0F 00 10 00 21 00 00 38 02 00 00 46 
[19:56:30][I][INFO:815]: Display to partition: 01
[19:56:30][I][INFO:835]: Prompt: FAULT 821        
[19:56:30][I][INFO:836]: Prompt: XMITTER SUPERVIS
[19:56:30][I][INFO:837]: Beeps: 0

[Dilbert66]

Ok, tks. I've pushed a commit with a changed vistaalarm.h that adds the ability to get the zone from bypass,fire,fault ,check and alarm messages

[rcmurphy]

Ok, awesome. Looks like for 128/250 systems the correct value for MAX_ZONES is 999 if you want to capture everything.

[Dilbert66]

The only issue is that increasing zone support that high will use a lot more ram . Definitively only workable with an ESP32. If this becomes problematic, I will make changes to how I store zone statuses.

Edit: Did a quick test. Heap Free from goes from 231608 to 215392 when max_zones increased from 48 to 999 on an ESP32. Only adds 16k and is not an issue on that platform. I would not use an ESP8266 as it's overly tight as it is now.

[rcmurphy]

Oh yeah, I always run my stuff on ESP32-WROVER equivalent or better anyway, so RAM was never a concern 😄

Plus, you aren't actually storing that much per zone. 8 MB of RAM is more than you'd think!

Let me know if there's anything else I can do to facilitate debugging; would also appreciate a glance at #85 as it really streamlines OTAs!

[Dilbert66]

Yes, I agree the ota adaption is good. I have this on my dsckeybus project in my dscalarm.yaml sample file but never added it to this one as I never saw it being an issue. Won't hurt to add it. Tks for noting it.

[rcmurphy]

Another issue for 128 support - it looks like you assume certain addresses, whereas with a 128/250, ECP devices (keypads, LRR, 5881 receiver, etc.) can have arbitrary addresses between 0 and 30.

According to Resideo, because ECP uses an IRQ-esque system, you should put higher priority devices (like keypads) lower in the address space (closer to 0), and "dumb stuff like relays" (direct quote) up closer to 30.

[Dilbert66]

I'm not sure what you mean here? Can you provice an example of the issue you indicate exists? The system processes data as it gets it. There is no priorities, etc. The cmd determines the action. Are you talking about the zone expanders here? Unfortunately, there isnt much I can do if your system handles those differently as I do not have access to such a system.

[rcmurphy]

Basically I experienced an issue when I set the address of the ESP32 to 01- it seemed to correctly parse all the zone data, but wasn't updating any of the general status fields. I have a work around, but just sharing in the interest of increased compatibility. Maybe it was a fluke though 🤷‍♀️

[Dilbert66]

Yes, the keypad address determines what partition it will process. You need to assign a keypad address to a partition in the panel then use that keypad address in the yaml so that the code can know to process that partition data. If you just pick any keypad address but don't assign it to a partition, then the panel won't send system data to it.

[rcmurphy]

Yep! I had the address correctly configured in the panel though, which is why I was calling it out.

[Dilbert66]

Ah, ok I see it now. You are correct, for processing I was restricting addresses to 16-23 for the vista20, since any other addresses are not used for keypads on that system. Ok, change the "getpartitionsfrommask" function in vistaalarm.h (line 673) to this:

    void getPartitionsFromMask() {
      memset(partitions, 0, sizeof(partitions));
        for (uint8_t p=1;p <= MAX_PARTITIONS;p++) {
            for (int8_t i=3;i>=0;i--) {
                int8_t shift=partitionKeypads[p]-(8*i);
                if (shift > 0 && (vista.statusFlags.keypad[i] & (0x01 << shift))) {
                    partitions[p-1] = 1;
                   break;
                }
            }
      }
    }

[rcmurphy]

How would you feel about a PR to pull out a lot of these configs into constants?

Would be awesome to specify in the yaml model: "250" and have presets set accordingly.

[Dilbert66]

No need as the changes will work with all systems. Just setting max_zones > 99 will ensure that zones are picked up from the f7 message. Everything else is universal.

[rcmurphy]

void getPartitionsFromMask() { memset(partitions, 0, sizeof(partitions)); for (uint8_t p=1;p <= MAX_PARTITIONS;p++) { for (int8_t i=3;i>=0;i--) { int8_t shift=partitionKeypads[p]-(8*i); if (shift > 0 && (vista.statusFlags.keypad[i] & (0x01 << shift))) { partitions[p-1] = 1; break; } } } }

worked great! still working on getting traces; pulseview doesn't work on ARM seemingly so finding an x64 machine to run it on.

[Dilbert66]

Would this package be useful? https://archlinuxarm.org/packages/armv7h/pulseview It's arch linux though. Not sure what you use.

Here's a dist for ubuntu: https://ubuntu.pkgs.org/20.04/ubuntu-universe-arm64/pulseview_0.4.1-1build1_arm64.deb.html

I do have a bunch of linux machines but all x86 variants and windows. I normally develop in windows due to contract work requirements.