[250BPT] Bypassed Sensor Fault

[rcmurphy]

As a user of a Vista system, I would like to be able to know when a motion sensor faults.

My understanding was that this was possible from snooping the serial number of the sensor off the ECP bus, but I could be wrong.

[rcmurphy]

The advantage of associating serial numbers would be that you could overcome the limitation of the vista panels and get motion detection in interior zones 😄 You could even make the user add the LUT. It would be lovely if there was a way to pass in MAX_ZONES so I don't have to keep patching that too, but that might be tougher as its a constant.

[Dilbert66]

The FB cmds (RF serial data) are messed up in you logs. I have to fix my code. It's tough testing those as I don't have an RF module to work with. I depend on you folks!

[rcmurphy]

Shoot me your address and I'll send you a 5881ENH that needs a good home!

[Dilbert66]

I'll add the max_zones config in the yaml as well as the serial lookups. Easy enough to do. Never needed it before so didnt bother. FYI, my main home system is a DSC panel where I have RF there. The vista was a side project to toy with :)

[Dilbert66]

Shoot me your address and I'll send you a 5881ENH that needs a good home!

Hmm, very tempting! If you're sure you don't need it. I'll pay shipping.

[rcmurphy]

Ok, I emailed you.

[Dilbert66]

The advantage of associating serial numbers would be that you could overcome the limitation of the vista panels and get motion detection in interior zones 😄 You could even make the user add the LUT. It would be lovely if there was a way to pass in MAX_ZONES so I don't have to keep patching that too, but that might be tougher as its a constant.

I do like that idea. I have something similar on my DSC. Internal RF is monitored but doesnt trigger the panel. I'lll put the LUT config in the yaml .

[Dilbert66]

I've pushed a small tweak to "vista.cpp". See if that helps with your FB (rf cmd processing).
Edit. Never mind. Still no improvement on my end. Wait a bit.

[rcmurphy]

whoops.

[Dilbert66]

Well, another tweak. See if that helps with the FB cmds and serial decode.

[rcmurphy]

logs_alarm-system_upload (1).txt

[Dilbert66]

Can you post some logs with the last pushed version of vista.cpp? Tks! The log you show is showing issues with the RF command.

[rcmurphy]

Oh, That was updated I thought. I think I updated the wrong file though; is that second copy vestigial? logs_alarm-system_logs (1).txt

[Dilbert66]

If possible, can i see a sample of a logic analyzer trace when sending keys via your physical keypad? There are differences in the sync pulses for your system compared to a vista20 and this will impact keypad presses. I need to figure out how yours does it. Your system:

Vista20p:

[Dilbert66]

Oh, That was updated I thought. I think I updated the wrong file though; is that second copy vestigial? logs_alarm-system_logs (1).txt

Still big issue in your RF command processing.. Puzzling. Have to do some thinkin here to see if your sync pulses are causing the discrepencies.

[Dilbert66]

Ok, I should have seen it before. Anyhow, looks like the 250bpt (and perhaps the 128) is using the protocol of the older vista20se and using the F7 cmds for display like the vista20p. Was confusing. I assume its due to it's introduction before the vista20p which then had some protocol changes. it's basically a hybrid of sorts. That explains why the processing isnt working right. The RF modules will work with all the systems but will have some slight differences in how it does it's request to send pulses. They keypad protocol is very different for the vista20se compared to the vista20p. The vista20p uses an f6 cmd why the vista20se sends out the keys during one of the sync pulses. Once I see a sample of your panel with keypad access, I will know for sure

[rcmurphy]

So you want me to record interacting with the keypad?

[Dilbert66]

Yes, please. I need to confirm it does behave the same as the vista20se.

[rcmurphy]

Random keypresses ok?Best,RebeccaOn Dec 19, 2022, at 09:44, Alain Turbide @.***> wrote: Yes, please. I need to confirm it does behave the same as the vista20se.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[Dilbert66]

yes any keypresses

[rcmurphy]

Emailed the dumps 😄 let me know if you need anything else!

[Dilbert66]

Got them. Look good. Confirmed that at least the vista250 does use the f6 mechanism to send keys which is better. The main difference is in the type of sync pulses used and the mechanism for doing RTS requests. I'll modify the code and place it under a new subdirectory called vista250bpt under the src root.

[Dilbert66]

Ok, pushed an updated. Only the vista.cpp from the vista250bpt directory needs updating. Give it a try and post logs of zone open/closed.

[Dilbert66]

Interestingly enough the simplied version works fine on the vista20p so might not need a separate version for the 250bpt.

[rcmurphy]

logs_alarm-system_upload (2).txt

[Dilbert66]

Hmm, still missing on the FB commands. Not switching the baud rate correctly to pick up the header byte. Odd one. I'll have another look.

[Dilbert66]

Made a couple changes to the receive isr routine for better cmd header handling. Hopefully that should address the issue you are having. It's not switching to 2400 but the cmd byte for the FB cmd. The vista sends the cmd byte at 2400, then switches to 4800 for the rest of the data. This is only for the zone and rf extender handling. (FB and FA cmds). The rest of the cmds are sent at 4800 baud. There is a special pulse width and shape that determines the baud. I pushed the changes to dev. Since the changes done will work on the vista20p, there will be no need for a separate vista250 version going forward barring any new discoveries.

[rcmurphy]

So do I switch to the vista20se or back to vistaEcpInterface?

[rcmurphy]

logs_alarm-system_upload (3).txt updated logs. Still no RF detection seemingly.

[Dilbert66]

use vistaecpinterface. Don't use the vista20se. I had created a directory vista250. Ok, I see the FB cmds but the length is incorrect. One sec.

[Dilbert66]

ok, another tweak. use vista.cpp and vista.h from vistaecpinterface. Your system for some reason produces a weird artifact byte after a cmd. I might need to tweak the serial routines. For now, I just have the system ignore it.

[rcmurphy]

logs_alarm-system_upload (4).txt Another log!

[Dilbert66]

Ok, much much better. The RF FB cmds are coming in fine now. The only issue is that they are not being decoded from the main code. Odd as they are correct. These are the cmds in question. Byte 5 with 80 means open. 00 is closed. 0c 7d 01 and 00 4e 1a are the serial numbers hex encoded.

[18:36:42][I][EXT:518]: 2022-12-19 18:36  FB 04 00 4E 1A 80 00 00 00 00 00 00 00 //open
[18:36:44][I][EXT:518]: 2022-12-19 18:36  FB 04 00 4E 1A 00 00 00 00 00 00 00 00 //close

[18:36:42][I][EXT:518]: 2022-12-19 18:36  FB 04 0C 7D 01 80 00 00 00 00 00 00 00 //open
[18:36:45][I][EXT:518]: 2022-12-19 18:36  FB 04 0C 7D 01 00 00 00 00 00 00 00 00 //close

The decode function to process this line is here in vistaalarm.h:

[line783]         } else if (vista.extcmd[0] == 0xFB && vista.extcmd[1] == 4) {

            char rf_serial_char[14];
            //FB 04 06 18 98 B0 00 00 00 00 00 00 
            uint32_t device_serial = (vista.extcmd[2] << 16) + (vista.extcmd[3] << 8) + vista.extcmd[4];
            sprintf(rf_serial_char, "%03d%04d,%02X", device_serial / 10000, device_serial % 10000, vista.extcmd[5]);
            if (debug > 0) ESP_LOGD("info", "RFX: %s", rf_serial_char);
            rfMsgChangeCallback(rf_serial_char);
            refreshRfTime = millis();

          } 
          /* rf_serial_char

            1 - ? (loop flag?)
              2 - Low battery
              3 -   Supervision required 
              4 - ?
              5 -   Loop 3 
              6 -   Loop 2 
              7 -   Loop 4 
              8 -   Loop 1 

          */

The new issue now is why they are not being decoded and displayed. I have to track back the code and look for a bug.

[Dilbert66]

I just did a test with my code and it works fine. Do you have the debug level > 0 in your yaml?

[19:31:00][I][EXT:518]: 2022-12-19 19:30  FB 04 0C 7D 01 00 00 00 00 00 00 00 00 
[19:31:00][D][info:789]: RFX: 0818433,00
[19:31:00][D][text_sensor:067]: 'vistaalarmtest RF Msg': Sending state '0818433,00'

[rcmurphy]

debug is 1. took new logs with a fresh copy just to make sure. logs_alarm-system_upload (5).txt

[rcmurphy]

oh, actual log level I'm not sure, one sec

[rcmurphy]

Yeah, so debug was 1, but logger.debug was INFO.

[20:58:35][I][EXT:518]: 2022-12-19 20:58  02 21 05 D8 00 00 00 00 00 00 00 00 74 
[20:58:36][I][CMD:518]: 2022-12-19 20:58  FB 08 20 F1 EC 00 00 00 00 00 00 00 00 
[20:58:37][I][EXT:518]: 2022-12-19 20:58  FB 04 0C 7D 01 80 00 00 00 00 00 00 00 
[20:58:37][D][info:789]: RFX: 0818433,80
[20:58:37][D][text_sensor:067]: 'Alarm System RF Msg': Sending state '0818433,80'
[20:58:41][I][CMD:518]: 2022-12-19 20:58  FB 08 25 F1 E7 00 00 00 00 00 00 00 00 
[20:58:41][I][EXT:518]: 2022-12-19 20:58  FB 04 0C 7D 01 00 00 00 00 00 00 00 00 
[20:58:41][D][info:789]: RFX: 0818433,00
[20:58:41][D][text_sensor:067]: 'Alarm System RF Msg': Sending state '0818433,00'
[20:58:41][I][CMD:518]: 2022-12-19 20:58  F7 73 00 00 00 20 00 00 28 02 00 00 46 
[20:58:41][I][INFO:826]: Display to partition: 01
[20:58:41][I][INFO:846]: Prompt: FAULT 020 OWNERS 
[20:58:41][I][INFO:847]: Prompt: BEDROOM DOOR    

success!!!

[rcmurphy]

Current mystery:

[21:00:30][D][text_sensor:067]: 'Alarm System System Status': Sending state 'unavailable'

[Dilbert66]

That's normal if the system is not armed but has open zones. (not ready). You can change the status term here:

    //the default ha alarm panel card likes to see "unavailable" instead of not_ready when the system can't be armed
 [line 105 vistaalarm.h]   const char *
      const STATUS_NOT_READY = "unavailable";
    const char *

[Dilbert66]

Awesome! Glad it works now. Your panel data exposed some flaws in my protocol decoding algo so this was good to plug those holes. I should change that esp log message to esp_logi instead of esp_logd to have it show on INFO debug level. I havent done anything really with the RF messages since I couldnt really test it fully. Your idea of having a look up table to process those is good no matter if they are bypassed or not. Of course, that only works for RF and zone extender zones

[rcmurphy]

I think it works for anything that reports to the LRR in theory, right?

On Mon, Dec 19, 2022 at 9:19 PM Alain Turbide @.***> wrote:

Awesome! Glad it works now. Your panel data exposed some flaws in my protocol decoding algo so this was good to plug those holes. I should change that esp log message to esp_logi instead of esp_logd to have it show on INFO debug level. I havent done anything really with the RF messages since I couldnt really test it fully. Your idea of having a look up table to process those is good no matter if they are bypassed or not. Of course, that only works for RF and zone extender zones

— Reply to this email directly, view it on GitHub https://github.com/Dilbert66/esphome-vistaECP/issues/86#issuecomment-1358749173, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGIMYHYKPMMWLPOULTDMRDWOEJTXANCNFSM6AAAAAASYJP6YI . You are receiving this because you authored the thread.Message ID: @.***>

[Dilbert66]

No, the LRR is totally different. The FB and FA commands are capturing the traffic between the RF/Zone extender boards to the panel. The lrr cmd is the F9 which is capturing the traffic between the panel to the LRR device. So with the f9, we can capture various status messages that the panel sends, similar to what it sends to the keypad. Internal zones to the panel we can't capture directly as they are on the panel. There are ways to do that though with relay channels setup as zone followers. This way when an internal zone is opened/closed you will see the relay extender reflect the corresponding status. So, for internal zones we get the fault message since it shows in the keypad but when the zone is restored, we don't get that status. All that happens is that the fault stops being reported. To detect a close, in that case I use a time to live timeout that will set a zone as closed if it no longer gets a fault message from the panel.

Edit: I should clarify though that the LRR should be reporting most statuses but not open/closed statuses of zones. I don't use it currently to set the system state. Only reporting it.

[Dilbert66]

as per our discussion, I've added a serial number lookup table function. The yaml config globals: section will need to be updated with a new variable as below:

globals:
    - id: rfSerialLookup # list of RF serial numbers with associated zone
      type: std::string
      restore_value: no
      initial_value: '"0123456:10,0123457:11"' # RF serial #:associated zone#

This function will then use the RF sensor responses to show the open/close status of any zone no matter the bypass or alarm status of the panel. Note, this is only needed for RF zones. Zone extender zones are already supported with this feature.

[Dilbert66]

I've also added pins 36,39 as valid gpio pins.

[Dilbert66]

Added ability to configure maxzones and maxpartitions from the yaml. You'll need to adjust your yaml to add the new functions there.

[rcmurphy]

[17:39:19][I][info:846]: Updating zone 40 to O
[17:39:20][D][text_sensor:067]: 'Alarm System RF Msg': Sending state '0019994,80'
[17:39:20][I][CMD:561]: 2022-12-20 17:39  F7 73 00 00 00 00 00 1C 28 02 00 00 34 
[17:39:20][I][INFO:885]: Display to partition: 01
[17:39:20][I][INFO:905]: Prompt:  REDACTED
[17:39:20][I][INFO:906]: Prompt:   READY TO ARM  
[17:39:20][I][INFO:907]: Beeps: 0
[17:39:22][I][CMD:561]: 2022-12-20 17:39  FB 08 25 F1 E7 00 00 00 00 00 00 00 00 
[17:39:22][I][EXT:561]: 2022-12-20 17:39  FB 04 00 4E 1A 00 00 00 00 00 00 00 00 
[17:39:22][I][info:835]: RFX: 0019994,00
[17:39:22][D][text_sensor:067]: 'Alarm System Zone 40: Foyer Motion': Sending state 'C'

This is AWESOME! Thank you!

[Dilbert66]

Great! Glad it's working! Tks for the input and testing.