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.
Ok, I ran into a bunch of esphome items that doesn’t allow the yaml to compile.
OTA and safe mode lines were adjusted to suit the recent releases of esphome.
Seem to have hit another snag with many repeated errors during compiling … copied and pasted this here instead because of the amount of text:
Yes, this was a bug. I didn’t test the esp8266 version when I was making changes to the esp32 compile. I’ve corrected the code, and it should now compile fine on both esp32 and esp8266
Yeah, it seems to compile correctly with the exception of this:
src/esphome/components/vista_alarm_panel/vista.cpp: In member function 'void Vista::writeChars()':
src/esphome/components/vista_alarm_panel/vista.cpp:770:20: warning: 'kt.keyType::seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
770 | tmpOutBuf[0] = kt.seq;
| ~~~~~~~~~~~~~^~~~~~~~
Otherwise it does still seem to complete the compile and doesn’t throw any errors.
I seem to have run into another issue though, but I don’t think this one is related to your component.
Using the same ESP board and all the same wifi credentials, I am now no longer able to connect to ESPHome, but it does connect to the home network without issue.
I’m seeing exactly the same thing. I’ve been playing with it for days, thinking there was something about ESP Home I wasn’t understanding or something I was doing wrong. I can see it on WiFi in the router but can’t attach to it in any way. Maybe this weekend I’ll back-track through the dev branch and see if I can find a version that works for me.
Ok, I’ve fixed the issue and at the same time went and optimized a few aspects with ram usage. The biggest problem was the use of the std::regexp library for parsing some data. It works ok with the ESP32, but on the ESP8266 was causing all kinds of havoc with the stack as well as using a huge amount of ram. It’s a total mess of a library. Anyhow, I’ve used a third party regex lib that now solves all the issues.
Now, some of the changes I’ve done will break your configs a bit. In your yaml switch section at the bottom, change the line that says “vista.keybusConnected” to $panelId->connected();
return $panelId->connected();
Secondly, if you are using the lovelace keypad card, you will need to change these config lines as they are now using the field type_id’s instead of the original snakecase object_id. Replace vistaalarm, with whatever your device is called.
Thank you, @Dilbert66 ! I had to pull in some other changes from your VistaAlarm.yml in addition to what you outlined above but it seems to be working for me now.
