Panels do report close events #105
Comments
|
Vista's do not report closing to the display that I know of. Perhaps you can post logs of your panel messsages and we can see if yours is reporting different then others. There is no way for me to know about those supposed events unless I see packet logs. |
|
Oooh, let me know what to look for; would love to see if 250s are
different. The alarm company I have is amazing about explaining the
internals; I'll ask them too.
…On Mon, Jun 5, 2023 at 9:16 AM Alain Turbide ***@***.***> wrote:
Vista's do not report closing to the display that I know of. Perhaps you
can post logs of your panel messsages and we can see if yours is reporting
different then others. There is no way for me to know about those supposed
events unless I see packet logs.
—
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGIMYGTK7FPNRVEE6S277TXJXL4XANCNFSM6AAAAAAX32WX4I>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Ok, I should clarify. The display really only displays what the panel sends it. When a fault occurs, the panel sends a "fault" message to the display. When the fault is restored, there is no "restored" message. It simply stops sending the fault message. My firmware basically only emulates a display panel. Now having said that, I also added the ability to capture messages from the RF module to the panel since those are sent on the same bus. With those I can capture open/close/battery status messages direct from the device . That's the exception. With wired zones that is not happening since the panel detects those open/close events directly and nothing is sent on the bus so we have to depend on what the alarm panel sends out to the display. Now there is a way to detect close messages from the internal 8 wired zones but that requires the convoluted use of emulated relay followers, etc which I wont' get into here. So I don't see why Vista would have firmware that would send "restore" events to the panel for no reason since it doesnt display them anyhow. If your panel does display those restore, I'd be suprised, but hey, I havent seen everthing. Post logs of a fault/restore of a zone and we will see if the data supports what you are telling me. None of this of course will work with 250 devices because they use the external loop interface to talk to the panel |
|
@Dilbert66 Based on your response there I'm curious if Zones on Zone Expanders such as the 4219 would be faster to report the closed events since they're operating on the ECP bus? I would be tempted to add a zone expander and move my "important" zones to the zone expander if they're going to update quicker. I'm also tempted to attempt to build a board that acts as a zone expander with a analog to digital chip (I don't really awnt to cut out the EOL resistors) on the i2c bus using your library. I just haven't quite figured that out yet. :D |
|
Yes, they would report the close events immediately as the communications between the expanders and the panel are captured and processed. |
|
I have a Vista20P and I noticed that the panels report immediately when I close a door. The ready light turns on in under one second when I close the door, so there must be some message that is being sent. What logs would help figure out the message? Should I just capture the output from the ESPHome log output? |
|
You have to realize that the usual door switches are connected directly to the panel and not to the bus. The panel will detect the closure immediately because of that circuit, not because of a bus message. The panel will not send out a close message on the bus. It only sends out Fault messages to the keypads. The only way that a close event will be seen on the bus is if the door sensor is an RF module or attached to a zone expander so those messages will be captured on the bus. This is why the ESP code relies on an absense of a fault message for a period of time to determine a close event. Since you did not indicate how your door is wired to the panel, I'm assuing it's one of the built in panel zones. |
|
Sorry I was not clear with that message, I have two keypads attached to the main controller, when I open and close a door the keypads show both the open and close immediately, there is no delay as there is with the ESPHome integration. The keypads are connected exactly the same as the ESP32 module so they should receive the same data correct? And yes all of my switch are wired I have 16, 8 wired to the panel and another 8 wired via a zone expander. I was testing with the front door which is wired to the panel no the zone expander. |
|
You'll need to be more specific here as to what keypads you have. With 6160 keypads, all you see are the fault/alarm messages. You do not see closure messages. The ESP code is emulating a 6160 type LCD keypad. |
|
I re-read your message. The ready light turning on/off with the zone action is a different message altogether. When an open zone is closed, and if there are no other open zones on that partition, a ready message will be sent on the bus and the ESP code will show that as soon as it gets it which would be the same time as your physical keypad. If your implementation is not showing the ready signal quickly then there is something else at play than the esp code since there should not be any delay showing the ready light on. |
|
I was looking at that and I think the wired keypads when they get the READY message they also clear the code for the open switches. I was thinking maybe the integration could do the same thing, when it sees the READY message then trigger the close event for any opened switches, since they would have to be closed for the system to ready. Also I have to key pads an ADEMCO 6150 and a Honeywell 6271c graphical keypad. The graphical keypad shows the open zones, when one closes it is removed from the keypad in 2 seconds, but if I set the timeout in the ESPHome integration to 2 seconds, any open zone will continually trigger open and close. Why do you think there would be a difference? |
|
ah.. ok, I misunderstood what you were saying. Yes, I had mean to implement the reset of open zones when the ready flag is active but forgot about it since I got busy with other aspects. I'll do that. Thanks for reminding me. The graphical keypad works differently as it has a different protocol then the 6160 keypads. It has more info provided to it from the panel. As to the TTL timer, if you set it too short, it will timeout and think the zone is closed but then an updated Fault message comes in and retriggers it as open again. |
|
Oh, interesting. I get setting the TTL too low causes issue, I was just wondering why my keypad was behaving differently, now I know. Thanks. |
|
Actually, if you can, can you post esphome logs of the traffic you get when a zone is opened or closed? You would need to be using the dev branch version of the code though. I'm particularely interested in the F2 packet messages as those are the ones that hold the traffic between the panel and the 6170 keypad. I could potentially use this traffic to speed up zone status updates. It can also be used for other functions as retrieving panel status data such as partitions, attached devices, active zones, etc. I've also updated the dev branch to clear zone's when the partition is in status ready as discussed. |
|
Here is some data from opening and closing a door a couple times: [20:29:36][I][CMD:572]: 2024-05-15 20:29 F2 12 66 00 00 00 00 62 6C 02 45 6C F5 EC 01 01 01 00 00 31 |
|
Thank you ! It looks like you are missing the module data side of it. Do you have the monitor line hooked up on your circuit? This is the "monitorpin" config in the yaml. It is not showing data there. For instance it should show data sent from the keypads/expanders/etc to the panel. This is very useful for capturing expander open/close events to immediately close zones that are hooked up to the expanders or RF modules. You should be seeing EXT:xxx messages when the line is connected. This is a main component of the info I was looking for. Namely what the AUI keypad is sending to the panel to retrieve status data. The F6: cmds show the requests. |
|
I do have it connected, but maybe it is not connected correctly, I will take a look at my board. |
|
I had the wire on the wrong pin, oops, here is the output from opening and closing the front door multiple times: [07:42:25][D][text_sensor:064]: 'Beeps (bp_1)': Sending state '0' [07:42:53][D][text_sensor:064]: 'Line2 (ln2_1)': Sending state 'GUEST ROOM ' |
|
Awesome tks! Can I ask you another favor? I see that my f6 cmd log size is too small. I've updated the code to fully display the cmd so that we can capture the data sent from the display fully. If you look in your log, the EXT f6 cmds are what the keypad sends to the panel and the F2's are the resultant responses back. Can you recompile to pick up the latest update and do this log again? Much appreciated. I'm hoping to capture the cmds related to zone status. Edit: Actually , you dont need to capture again. I figured out the cmds sent. Tks! |
|
Here is the log with the latest code: [11:53:16][I][CMD:588]: 2024-05-18 11:53 F6 01 00 00 00 00 00 00 00 00 00 00 00 [11:53:46][I][CMD:588]: 2024-05-18 11:53 F6 01 00 00 00 00 00 00 00 00 00 00 00 |
|
Tks again! Well, from what I see, there are no queries for specific zone statuses. All I see are periodic system status queries. I guess the 6270's don't get zone close events either. I'll look into it more. |
|
Interesting, I wonder how it can get away with showing the zone as closed in a little less than two seconds. Maybe the controller sends updates to it faster than other keypads? |
|
Are you saying for example that you have two zones open and one closes, you get instant notification that this zone is closed? If there is only one zone open then closes, that's different as the system will send a ready flag and the keypad will close the zone immediately. With two zones open and one closes, the system will not send any status change as it is still not ready so as far as I can tell there is no individual zone notification. I've never seen a 6270 so not aware of how it displays individual zone statuses. |
|
Now, I do know that the keypad can retrieve zone statuses when asked via menu but that is a different process as it will send a cmd to the panel for it to send a zone update. It does not do that on it's own as far as I know. |
|
This is the screen on the keypad that shows the open zones. |
|
Yes if you could log that it would be great! You might need to recompile as your last log didn't contain the last updates. As to your question, yes, I can emulate all aspects of the communcations of this keypad including the zone lookup from they esp keypad emulation. This way I can retrieve any active zones and names from the panel. This is why I need logs of the communications so I can hard code the correct request cmds in. |
|
Fyi, whenever a zone or system status updates, there are 2 F2 system status messages sent out. Nothing zone related that I can see. Mostly system flags. But those F2 cmds can be used to trigger a zone status update request cmd to do exactly what is needed to update any zone status immediately. All I need is that zone status request cmd. |
|
Here is the log with the status page open on the keypad, hopefully this has the data you need: [17:12:06][I][CMD:588]: 2024-05-19 17:12 F7 02 00 1D 10 06 00 00 28 02 00 00 46 |
|
Tks again. Did you do a full recompile and re-upload? The code is still not showing the F6 length changes so the new code has not been picked up on your system.. They are still truncated at 13 characters. FYI, this is the cmd I'm interested it. It looks to be doing the zone request but is missing some characters: The response to the cmd is as below: The faulted zones are seen after the FE FE FE FE EC start sequence as ascii encoded numbers: 32 = zone 2 |
|
I did a clean and then a reinstall, that should have downloaded the new code. I will try again. |
|
I posted a corrected version
…On Fri, May 24, 2024, 8:53 PM Robert ***@***.***> wrote:
I am getting compile errors:
src/esphome/components/vista_alarm_panel/vistaalarm.cpp:534:10: error: no
declaration matches 'void
esphome::alarm_panel::vistaECPHome::send_cmd_bytes(int,
std::__cxx11::string)'
void vistaECPHome::send_cmd_bytes(int addr,std::string hexbytes) {
^~~~~~~~~~~~
In file included from
src/esphome/components/vista_alarm_panel/vistaalarm.cpp:1:
src/esphome/components/vista_alarm_panel/vistaalarm.h:378:10: note:
candidate is: 'void
esphome::alarm_panel::vistaECPHome::send_cmd_bytes(uint8_t,
std::__cxx11::string)'
void send_cmd_bytes(uint8_t addr,std::string hexbytes);
^~~~~~~~~~~~~~
In file included from
src/esphome/components/vista_alarm_panel/vistaalarm.cpp:1:
src/esphome/components/vista_alarm_panel/vistaalarm.h:97:8: note: 'class
esphome::alarm_panel::vistaECPHome' defined here
class vistaECPHome: public api::CustomAPIDevice, public
time::RealTimeClock {
^~~~~~~~~~~~
Compiling
.pioenvs/vista20p-bridge/src/esphome/components/wifi/wifi_component_esp8266.cpp.o
Compiling
.pioenvs/vista20p-bridge/src/esphome/components/wifi/wifi_component_esp_idf.cpp.o
Compiling
.pioenvs/vista20p-bridge/src/esphome/components/wifi/wifi_component_libretiny.cpp.o
***
[.pioenvs/vista20p-bridge/src/esphome/components/vista_alarm_panel/vistaalarm.cpp.o]
Error 1
—
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABW4E7IFFRGOACQF63G2PMDZD7OG5AVCNFSM6AAAAAAX32WX4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZQGYYTSNJXGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I am still getting an error: |
|
Doesnt look like it's picking up the new updates. What is your refresh: setting under the external_components: section? You should be able to retry today and have it work now. |
|
I did not have a refresh setting. I added one and it is compiling now. Thanks. |
|
This seems to be working very well. |
|
Great. Is there an option to show all enabled zones on the panel? Such as the menu "More choices" and "Show zones"? Is that the same option you used? I'm looking for the option that retrieves all enabled zones from the panel. Not just open or bypassed. If there is, could you capture that log? It could be handy to have the ESP retrieve all that data on startup and use the data on internal zone setup. |
|
Indeed there is, I will try and capture that info today. Would you like a separate issue for that so this one could be closed? |
|
leave it here for now. I can create a discussion later maybe. |
|
I did a quick test, I think the panel only requests the zone information when it restarts. I will have to do that tonight. |
|
yes, that makes sense! Thanks for trying it out! |
|
Here is the output after a restart, does this have the data you need? [14:59:23][I][CMD:572]: 2024-05-29 14:59 F6 01 00 00 00 00 00 00 00 00 00 00 00 |
|
Excellent! Exactly what I needed! Thank you! I just need to analyze the cmds a bit and see what I can use. So far I can retrieve the zone count per partition and enumerate each zone and identify the type and assigned name if it's there. |
|
I have another request if you don't mind. Can you capture the logs of going through a time/date set sequence and have it send to the panel ? I want to see what cmds that this display uses to talk to the panel for setting date and time. |
|
That's for a 6170 or tuxedo keypad right? I need the AUI traffic. |
|
I was actually thinking about the clock the other day and was going to ask if you could implement an auto set. Here is what I captured: |
|
Awesome! Tks for the logs again. FYI, I do have a set_panel_time() service existing on the esp code which just emulates the keypad cmds to actually set the date/time on the panel. Try it out from the dev console on HA. I want to also implement it using the AUI api if possible as it should be more consistent. |
|
Great, I found the command in your log and will have a working service on the next update in a day or so. |
|
I've updated the "dev" branch. The set_panel_time() service will use the AUI cmd for updating the time on the panel if you have an active aui address setup, otherwise, it will default to using the a key sequence to update the time as if it was entered from the panel. The time will be synced with the time platform on the ESP. You can use the service in the yaml by calling it with "$panelId->set_panel_time()" from an interval entry like this: Or you can call the service from HA as it's also available there. |
|
Very cool. I will give it a try. Thanks. |
|
The time set seems to be working. I am assuming the seconds are not set by this API as the clock is always off by some seconds. It seems to do the same thing even when setting from the actual panel. I would guess the vista firmware just does not reset the seconds when setting the time. No big deal. |
|
My system was showing odd behaviour with certain settings of the seconds. It would always fail when seconds sent were for example, 48, 47 57, 39, etc. The fields are there from what I see. Not sure what the issue is there. It would always work fine when the seconds were sent as zero. Your example looks like it is sending seconds but I need to see more examples. Can you provide more logs of setting the time at various periods? 5 or 6 times should be fine. I'd like to see if there is something I'm missing. |
|
Ok, now I think I have it. The last field is the day of the week. I thought it was the 2nd digits of the seconds. I'll post an update shortly. |
|
Ok, pushed a fix to "dev". Now sets the seconds and day of week correctly and synced to the esp time. |
|
I will give it a try. |
|
I am getting an error now: In file included from src/esphome/components/vista_alarm_panel/vistaalarm.cpp:2: |
|
ahh.. ok, hold on. You are not using the template_alarm for your sensors and using the binary_sensors. I'll push a quick change. |
|
Ok, update pushed. Hold on... I need to fix something else... |
|
Ok, now you should be good. |
|
Seems to be working. My panel is still off by about 30 seconds, not a big deal, but kind of strange. The panel must not be resetting the seconds, but its close enough. |
|
That's interesting. I know the panel is accepting the seconds fine and the code is picking up the accurate time. You're probably right that the panel is not using the seconds. When setting it on the keypad, there is no seconds adjustment. |
"The panel only sends fault messages when a zone is faulted or alarmed and does not send data when the zone is restored".
They can report closes, both wired and wireless. The Big Blue company always nerfed their firmware, perhaps what you have is.
I have several 20p, various firmware versions, bought through a Honeywell dealer and they all immediately report zone closings. As I understand it, this is not accounted for because your panel doesn't report closes and instead a TTL was implemented, is that correct?
Would it be hard to add reading those events from the ecp bus?
I used to have an EVL-4 that would report immediate closings, but sadly a lapse in my IoT firewall rules allowed it to phone home and it received a firmware update and zone status is now very slow. I'm looking to build and use your software now.
The text was updated successfully, but these errors were encountered: