esphome-dsckeybus
esphome-dsckeybus copied to clipboard
Dilbert66
Slow response on zones - Stability
Hello @Dilbert66 hope you are fine and thank you for this incredibly project.
I have been monitoring my alarm for a couple of months and i see some weird things like slow response on some RF sensors. The thing is that the PCB i builded i discard any kind of noise since i have test it separately on a osciloscope and i dont see any kind of noise on the DC-DC signals.
After a few investigations i saw this video about level shifting. https://www.youtube.com/watch?v=t-yuYasIKtY&ab_channel=KevinDarrah
The intesresting thing is that i didn't test the signals on the I2C bus but im pretty sure that when you have several devices (30+ zones) + RF emiter/transmiter + GPRS + Keypad + This decoder. You may saturate the clock signal and lead to read wrong or slow instructions.
The idea is to improve on this case the comunication bewteen the alarm pannel and the decoder. Maybe is not the simplest way but is the most trusted and for security system i consider it very important. I dont know if you can do some tests according with the frequency of the signals and evaluate if we should change to a transistor or mosfet method for level shifting as improvement.
If you do, i could update PCBs designs with no problem.
Thank you and have a good day.
Edit PD: I also consider the length of the wires but on this case its about 6cm between the alarm pannel and the decoder. Also i have changed the old wires for new and better quality wires for all other devices.
Well, I doubt using transistors or mosfets will change anything. The resistor dividers have minimal impact on the bus since they are very high value. But then, the only way to know what is going on is to see some some logic analyzer traces of the bus as well as the serial logging output from the esp during the slowdowns you indicate. The serial data would definitively help to see what's going on and show the communications in progress.
When you say slow response, is it just slow showing on homeassistant or also slow showing on the physical keypad? I doubt the issue is hardware. I would suspect that the issue might be more software related due to the amount of traffic that the esp has to process . I've also seen in some cases a lot of weird traffic on the bus due to a very chatty expander board (which would cause delays due to the traffic) but I have not found why they were sending this repeating data.
Are you using the zone virtual expander code? If so, can you test with it disabled for a while to ensure that the expander code is not causing some conflict?
Just to clarify, no matter how many devices are on the bus, the data frequency will not change at all. No device sends at the same time. They all have dedicated address slots and only respond to send data on their own corresponding messsage cmds when asked by the panel. It is very coordinated. If it was frequency related, the issue would occur even on an idle system. Again, this issues seems more related to firmware . I definitively suspect there is some extra traffic occurring somewhere that is slowing down the firmware . For this, we need to see serial logs of the traffic otherwise everything is a guess.
Thank you @Dilbert66. Yep it's very weird.
The delay is also showing on the physical keypad and only occour on some specific zones. For example zone 28 (initially a windows closed). If i open that windows and check my HA with my phone, nothing happen, If i check it on the keypad it says closed. After 1-2 minutes (sometimes even after 10minutes), then it changes to open. But this rarely happen, not always, but 95% of time this and the rest of the zones are almost instantly.
Im not sure if im using a virtual expander code, honestly i dont know about it. I just upload the firmware code just like it is from this repo and changed the DscAlarm.yaml file with my custom config (such zone names, etc.)
Im totally agree with what we guess, i thought that the frequency of the signal was too high and maybe there could be some bad lectures if the signal is slightly modified. But if the frecuency range is between kilo-hertz, resistors for voltage divider are ok. So on this case i think we could discard a hardware issue.
If you could, leave some instructions to enable a debug log report and i will try to capture exactly the moment when this happen, as i said not always occour so i need some time to capture that moment.
set DSCkeybus->debug=3; in the yaml and using arduino serial monitor at 115200 baud and the esp connected via usb,
I suspect there is some heavy traffic causing some delay but I can't know for sure. It could be the firmware sending a command by error that causes one of the attached peripherals to generate requests without answers. I've seen it happen a few odd times but could not find the exact source of the issue since I did not catch the beginning of it.
It will be a little difficult if i monitor via serial or usb. If there is a method to store a log file on my HA server could be more easier and just search the timestamp when it occours
Fair enough. Which branch are you using for your code, master or dev? I will post an updated version that prints more info on the ha console. Yo will need to setup esphome from the command line and use it to dump the generated logs to a file so you can do long term logging. https://esphome.io/guides/getting_started_command_line.html.
Unfortunately from ha directly I don't have a good way to save long term logging to a file so I use the command line version. The command line setup involves installing Python, then using pip3 to install the esphome script, then using the script to run your dscalarm.yaml copy. You will need to copy the files to a local directory on your pc first which involves copying the dscalarm.yaml and secrets.yaml file to the same directory, then create an include subdirectory for the dsc library similar to the esphome setup called dscKeybusInterface (or whatever you called it in the yaml) where you copy all the dsc library *.h and *.cpp files to it.
You then run that config by calling" esphome dscalarm.yaml logs > savedlogs.txt"
FYI, I posted a new update to the 'dev' branch that fixes an issue with module handling that could cause the delays you were having.