[Question] Make device supervised by panel #279
Replies: 6 comments 4 replies
-
Hi @Alviunta - this should be possible, I've considered it previously but it's been lower priority as I haven't seen requests for this feature (until yours) and it would use additional resources on the microcontrollers (mostly an issue for Arduino). As you mentioned it would be a matter of deciding which type of module to emulate and then decode the Keybus signaling for it. Emulating a keypad should be straightforward since the 0x11 command is decoded.
This would be great! Getting more of the Keybus decoded is always a goal for this library.
I haven't seen data for the PC5400 printer module, logs from the
This thread on AVRFreaks is where I first came across folks decoding the Keybus protocol. The dscKeybusPrintData.cpp file documents the parts of the protocol that are currently decoded.
No apologies needed, your post was very clear! Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Supervision is definitively doable but in my opinion is not really a useful addition since when you think about it, the main idea of this library is to monitor and control the alarm system and not the reverse so having the alarm system monitor the keypad emulation seems unecessary. Of course, I could be missing a scenario. Anyhow, I did implement supervision with my expander board emulation version of this library. The firmware fully allowed the emulated expander boards to be supervised. I did not supervise the keypad since i found it unecessary but it would simply have needed the addition of setting a predefined unused slot as you noted. You need to be able to respond to the cmd 11 directly in the ISR routine to send back the slot info. Here's a link to the branch where you can view the implementation. https://github.com/taligentx/dscKeybusInterface/blob/expander/src/dscKeybusInterface.cpp In my own version , I don't bother activating the supervision as I found it to be just very annoying since during testing/development needed the restart of the chip and the panel would always scream that a device is missing at that time! Nikhil is correct in noting that it will impact resource use on lower ram devices so would need to be a #define to limit this function to more powerful devices. I am rewriting the expander version to be more modular and fit better within the new structure of Nikhil's library. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Dilbert66 @taligentx, sorry for the delay, I had some problems at home.
Soon I will get to work on this aspect, when I have the logs I will share them.
I understand where you mean that module supervision may be unnecessary, however, since it is a security system that works at all times, I believe that a "bidirectional" supervision provides a plus in terms of ensuring correct operation.
I looked at your implementation (briefly) and it seems to try to emulate "virtual" zones, it seems to me an excellent addition to this library but it goes beyond what I'm saying. My interest is to ensure that the device that I connect to the alarm system is working at all times. And that if at any time it fails, I find out at that moment and not in an undesirable situation.
When dealing with systems that must act in extreme and urgent situations, more supervision is always better, as far as I am concerned, I prefer to spend a little more money on a more powerful microcontroller instead of spending a lot of money on replacing stolen / burned things. I hope what I am trying to say is understood. |
Beta Was this translation helpful? Give feedback.
-
Hi Alain, this is great to hear, integrating your expander code has been on my TODO list for too long but hopefully with the new structure it'll be easier to include different functionalities while keeping lower resource utilization for more basic uses. I'm also looking at making writes to the panel more modular, the current code is based on writing as a keypad, but I think things like responding to supervision and emulating DSC modules could use a better structure. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Nikhil, I'm currently playing around on adding full LCD keypad emulation to the ESPHOME example and in doing this, I need to emulate full installer programming functions. One of the main features is to be able to update multi character field entries such as phone numbers which have 32 characters. This uses a mechanism of sending 0xA5 cmd on the 05/0a and receiving in response multiple 6E cmds of 4 bytes (holding 8 bcd numbers). For 32 charactes that's 4 6E's. For writing this data back, the keypad sends a AA cmd on the 05/0A and receives in response a 70 cmd which works the same as a 6e except for writing. The keypad responds with multiple 70's with the data to be written back to the cmd section. Anyhow, this works similar to what I had done with the expander code but it's getting messy and duplicates really what the keypad write code does. The ISR is code is getting too large. So as you noted, a better algorithm is needed. What I'm working on is a queueing mechanism where each device that needs to respond on a cmd, pushes it's message unto a queue. (or separate queues for each cmd) This message will include things like the data to send, the data lenght and the cmd it should be sent on. This would be stored in a structure. The ISR routine would then check on each cmd for any pending queue items for that cmd and process them. This would keep the ISR routine small since it would be universal for all types and there would be no issue with missed cmds since they would be processed as FIFO events. Also all event pre-processing would be done outside of the ISR keeping it as lean as possible. A critical part is the planning of the queue structure and retrieval. This is very similar to what I did with the VISTA panel firmware. |
Beta Was this translation helpful? Give feedback.
-
|
Some cmds would not need a queue such as the expanders. The cmd would just keep getting an updated field with fresh data. So cmds which are request cmds such as 05/0a/e6.20 would be queued and response cmds would be handled by a case statement which would return the associated cmd data as well as clearing the original request cmd. Just thinking out loud. Different ways of handling it. |
Beta Was this translation helpful? Give feedback.
-
|
I agree Nikhil. A structure change would be benificial to allow these external components to be modular and to be able to enable/disable them easily. I've encountered some low IRAM issues with the ESP8266 when combined with the ESPHOME library which needed compile time defines to turn off the expander portion when not needed. I'll wait to see what you come up with before working on recoding my end. One critical improvment will be to optimize IRAM useage. |
Beta Was this translation helpful? Give feedback.
-
|
I recently made my own interface using this library and made a bunch of config changes to my panel. I have a "Module Supervision" trouble and I was wondering if it might be the arduino module being wrongly "identified" by the panel and triggering the trouble. I'm looking for confirmation that this library does not implement a concept of supervised module and thus could not be the cause of the "module supervision" trouble I am having. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. This library as-is doesnt have any supervision reporting to panel nor panel can see it. |
Beta Was this translation helpful? Give feedback.
-
|
Adding supervision (assigning ESP as keypad slot) capability could be useful when using it with SMS-GSM or telegram/push examples - so when ESP goes offline/stuck you will get trouble light and know that there's something wrong with standalone ESP notifier and wouldn't get notified if alarm occurs. |
Beta Was this translation helpful? Give feedback.
-
Great job!
Does anyone know if it is possible to get the panel to monitor the arduino connection?
As far as I understand, the modules are supervised by the panels through the code 0x11 (module supervision query) to which each module places a series of bits at a specific time to indicate presence and connection, so if a module is disconnected it is disconnected you can see this directly on the keypad.
As the panel can support up to 8 keypads, perhaps a slot could be used to monitor the aruino connection and ensure that it is working at all times. I tried to use panelData [0] == 0x11 and a timer to write 00 in the KeyPad 2 slot (slot 8 was already in use) but it didn't work out as expected and the panel showed a module error, I don't know if any other is necessary type of interaction with the panel.
I have a series of modules that can be of help to try to decipher more information and achieve what I am proposing, as soon as I have more time I will get to work on it:
On the other hand, I have seen third-party IP communicators that connect to the KeyBus and wrap themselves in the printer slot (I suppose to explicitly obtain all the information or something like that). Does anyone have information on this? Perhaps this could make things easier for the future. If I get a module that works like this, I will gladly share what I find.
Is there any documentation on how the KeyBus protocol works? I looked in many places but I could find little, if someone can give me help I would be grateful.
I apologize for my bad English (Google Translate did most of the work) and I hope someone can help me!
Beta Was this translation helpful? Give feedback.
All reactions