Could I somehow have changed my primary keypad to try to be a touchpad (it’s just a normal physical-button keypad)? I’ll check the address today.
Do you have an idea why this change is preventing my ESPHome device from forwarding on prompt messages? Both using keypadaddr1: 16 and keypadaddr1: 17 I don’t see the status messages update anymore after futzing with the programming, though I still see the status message in the logs
Edit: as you suspected, the keypad was configured as address 17. I reconfigured to 16 and it’s working again. Easy. In case it helps someone else, the full reprogramming sequence was:
Power cycle
Hold 1 & 3 until it shows the address
Type 0016*
I still don’t understand why the firmware wasn’t sending the status messages, even when I set keypadaddr1: 16. But I’m all up and running now including the HA keypad and the physical keypad both working
Also I was able to switch to the dev branch. Thanks for fixing that!
Great that you have it fixed. As to the issue why it wasnt displaying for address 16 was a bug in my firmware. I have updated both main and dev with the revised fix.
Great! Glad you solved the mystery! Thanks again for your help!
Longer term, any interest in potentially exposing this up as an ESPHome alarm_control_panel component? Then it would show up I think in HA as a standard alarm_control_panel type which would enable use of the stock Alarm Panel Card and the built in HA alarm services (e.g. alarm_control_panel.alarm_arm_away). This would standardize the core interface into your component (status, arming, disaarming) and you could still allow the user to expose zone sensors if they wanted. The code for a template alarm_control_panel would be the place to start for this.
No guarantees but I might be interested in helping out with that if it’d be of interest to you. I suppose I could shoe-horn this into an ESPHome template alarm_control_panel but that seems more geared towards building an alarm instead of exposing an existing one (e.g. it handles its own arming_away_time countdown).
Neat thanks! I prefer to use the stock cards as much as possible (less to manage during updates). Here’s what I came up with (using one small custom variation on vertical-stack to remove the borders between cards)
One more thing I’d like to do is allow the user to disarm the alarm if they accidentally armed it. The problem is that the system_status entity doesn’t haven an arming state. I can handle that with some template magic, but it looks like the service call to esphome.alarmname_alarm_disarm is a noop if the system is not fully armed because of this line. What do you think about removing the second half of that if statement so disarms are always allowed (even if not armed, or in the process of arming). So this line:
else if (state.compare("D") == 0 && partitionStates[partition-1].previousLightState.armed) {
becomes
else if (state.compare("D") == 0) {
Here’s my full template in case it’s useful to someone else:
Greetings! I picked this project back up and I seem to be in a worse state than I was initially months ago lol
I did update everything to the current release in master. And I updated my yaml file as well. All I see now in the log output is one of two things. When everything is ready to arm I see:
there is absolutely nothing else in the log. I don’t see the prompt text anymore like I used to. I’m not sure where to even start with this. My esp component is set to keypad 20 which is enabled in the vista. I do have the funky xfinity takeover box on here so I’m not sure how that plays in exactly. I’m using the isolated circuit with the octocouplers.
Any help is much appreciated.
You should be seeing some f7’s always. Either you have a wiring /signal issue or your panel is doing odd things. It’s possible your version is non standard . I assume you have a vista20 from your previous posts. I suspect myself that you have an issue with the signal . The isolated version is not my recommended version as it is prone to signal problems due to insufficient gain with some optocouplers as well as adding unecessary load to the bus. This would cause similar issues to what you are seeing. A user created a version with pre amplification stage and reduced load but it adds complexity to the build. I would suggest you try the resistor divider version instead and see what results you have. It has a better signal output as well as providing minimal load to the bus.
OK, my memory was crappy. I was using the preferred version for wiring. I hooked everything back up again after checking the circuit extensively and same result. So I removed the stupid takeover module to reduce confusion and hooked things to the vista directly. Same result.
Next I reverted the code to the one I previously had (dev branch circa May 2023) and I was back to a working state. In fact it worked exactly as expected.
So I put the takeover module back inline to the keypads (it sits between the vista and the keypad [and esp]). I’m back to where I was before where I’m getting the display output now again but the sensors don’t ever change.
So first, the newer code doesn’t work with my Vista20 even when in stock mode. I did do a clean of the build files before installing and recompiled it several times. I also noted that there were several warnings during the build about things being too big going to certain destinations in vistaalarm.h. Not sure what that is about.
For the May23 code that is somewhat working, IIRC the code is designed to look for FAULT [Zone] in order to trigger the state change. With the takeover module in place what I get is the name of the zone in fault instead of that string. Is that something I can work around? Other thoughts?
Thanks for all your help. I really appreciate it. If you have a venmo or something to buy you a cup of coffee I’m happy to toss some scratch your way
Well, you have me confused now. The new code should work fine. As a matter of fact, the new code no longer depends on the text fault xxx msgs to determine a fault. It uses the f7 flags to do that. I’d have to see the logs with the newer code running on your system to get a better idea. Just saying it doesnt work is not very helpful if you now what I mean. I specifically need to see the f7’s for sure.
yeah totally get it. I was a complete “user” there lol
I’ll flash everything super clean and try again tomorrow. I had pieced together the newer yaml and while I compared everything pretty closely it’s possible I missed something. So I’ll take a cleaner approach this time. I was at the stage of trying to get ‘something’ working so I’ll iterate on that and get you some logs. It looks like I can increase the logging with the debug setting in the yaml too so I’ll bump that up to get as much detail as possible. On my first go through with the new code there were no F7 commands shown. Let’s assume user error for now and I’ll get back to you. Thanks again for the help!
The error of my way was I didn’t realize the loading process had completely changed and I was using the 20SE code. Once I understood that all I needed was the new yaml file and all the rest was “magic” it loaded all nice and clean.
The only thing that doesn’t work is the battery status but I’m 99% sure that’s because the takeover module filters it out because it doesn’t report on the hardwired keypad either, only on the touchscreen add on.
Thank you so much! Especially for your patience! If there is a venmo or something where I can buy you a cup of coffee I’m happy to contribute for all your work!
Glad you got it working! That takeover module is a weird device. Yes, the firmware needs the F7 system message that provides status like armed/disarmed/system lo bat for battery status. Thats the cmd that provides all system statuses. The other F7’s are related to fault messages.
Interesting about you not seeing the battery status on the LCD, but you do see it on the touch screen. FYI, i’ve got the touch screen cmds decoded (F2 data) and can now immediately capture open/close events using the touch screen interface as it can poll those events directly from the panel. As to the battery status, I bet I can capture that as well from the touch screen cmd stream. I will have to do some more testing to see what flags indicate the battery on the F2 broadcasts.
FYI, if you want to try it the version from the DEV branch, go ahead. It has a lot of bug fixes and many optimizations. You will have to modify your yaml a bit to match the new requirments. You can look at the example yaml sample there. Also, there is no need to download any code. Just get the yaml, update it with your own settings and compile. It will go and fetch all needed files.
I’ve got this installed and has been running for about a year maybe? and was interested in migrating to the newer implementation. I was previously using the preferred method on an esp8266 board, but was wonder if anything from the wiring has changed at all?
Also, what is the purpose of the RF serial? After adding it to the yaml, what should I be seeing or what is gained in terms of functionality? I’ve got 4 RF motion sensors that I’ve got the serial numbers for.
Lastly, is the easiest way to go about doing the migration to just set aside the old implementation and start fresh following the instructions?
I’ve been running the latest code using an ESP8266 board - I’m using the JLCPCB that howardchen created and I’m using ESPHome 8.3 and the latest code from github as of June 28th 2024. No wiring changes were made.
Lots of changes have been made to the main configuration yaml since tha time - a lot of it makes future configuration easier, but I have had to re-code all of my sensors by hand at least twice to keep up with the configs, but it wasn’t too difficult.
RF Serial aka “rfseriallookup” is a setting in the config file that maps serial number of the RF wireless device to the zone number, and also has an additional field that describes which loop to monitor for the open/closed states. In my case I have 12 RF devices which are used to monitor my windows and doors, and some use loop 1 and others loop 2.
It works fantastic by the way - I use the RF devices to trigger other automations in Home Assistant.
The RF code was added as a request for some users to be able to identify RF zones directly from the zone sensor communications. This allows the ability to immediately detect zone opens and closures on RF zones at least. This is useful since the Vista panel itself does not send any closure messages to the LCD display panels so timeouts are needed to flag a zone as closed once a zone open message stops being sent. This can add a delay of up to the duration set in the “ttl” option to detect a zone closure. I’ve also added new code in the “dev” branch to partly emulate AUI communications to fetch zone statuses directly from the panel whenever a new AUI status update is received. This in effect gives the ability to capture zone closures/bypasses almost as soon as they happen on any internal/external zone types. To use this feature, you will need to set the “auiaddress” yaml option to an unused aui address. If you don’t have an AUI keypad (touchscreen panel), then you can set it to 1.
Sorry about all the config changes in the yaml. It was done to try and simplify zone setups as much as possible. There should not be any more extensive yaml config changes, except perhaps the addition of new options which would not impact existing configurations.
