Closed Eggster237 closed 1 year ago
Dilbert66
commented
2 years ago As I posted in the home assistant thread, try minimizing the amount of data showing in the logs to see if that helps by setting debug=1 or debug=0 for now:
DSCkeybus->debug=2; // 0 = off, 1 = minimal, 2 = all packets shown on console 3 = + serial port debugging
Eggster237
commented
2 years ago Please see below the logs when setting debug = 1.
I might not be able to get to it this evening due to a deadline for work, but I will load it onto the ESP32 with the debugging reduced as soon as I can and let you know if it worked.
INFO Reading configuration /config/esphome/DscAlarm.yaml... WARNING 'espdsc': Using the '' (underscore) character in the hostname is discouraged as it can cause problems with some DHCP and local name services. For more information, see https://esphome.io/guides/faq.html#why-shouldn-t-i-use-underscores-in-my-device-name INFO Starting log output from esp_dsc.local using esphome API INFO Successfully connected to esp_dsc.local [14:43:17][I][app:102]: ESPHome version 2022.9.2 compiled on Oct 5 2022, 14:40:30 [14:43:17][C][status_led:019]: Status LED: [14:43:17][C][status_led:020]: Pin: GPIO2
[14:43:17][C][wifi:360]: Local MAC: [redacted] [14:43:17][C][wifi:361]: SSID: [redacted] [14:43:17][C][wifi:362]: IP Address: 192.168.0.100 [14:43:17][C][wifi:363]: BSSID: [redacted]
[14:43:17][C][wifi:367]: Signal strength: -52 dB ▂▄▆█ [14:43:17][C][wifi:371]: Channel: 11 [14:43:17][C][wifi:372]: Subnet: 255.255.255.0 [14:43:17][C][wifi:373]: Gateway: 192.168.0.1 [14:43:17][C][wifi:374]: DNS1: 192.168.0.1 [14:43:17][C][wifi:375]: DNS2: 0.0.0.0
[14:43:17][C][logger:276]: Level: DEBUG [14:43:17][C][logger:277]: Log Baud Rate: 115200 [14:43:17][C][logger:278]: Hardware UART: UART0 [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Living Room(z1)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Front Door(z2)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'door' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Kitchen Door(z3)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'door' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Passage(z4)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Main Bedroom(z5)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Remote Panic(z6)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'safety' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Remote Blue Button(z7)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'opening' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Remote White Button(z8)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'opening' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Beam South(z9)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Beam West(z10)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Garage(z11)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Beam North(z12)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Beam East(z13)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'motion' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Test Zone(z17)' [14:43:17][C][template.binary_sensor:018]: Device Class: 'door' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Partition 1 Ready' [14:43:17][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Partition 1 Armed' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Partition 2 Ready' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Partition 2 Armed' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Trouble Status' [14:43:18][C][template.binary_sensor:018]: Device Class: 'problem' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Battery Status' [14:43:18][C][template.binary_sensor:018]: Device Class: 'problem' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc AC Status' [14:43:18][C][template.binary_sensor:018]: Device Class: 'plug' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc Panic Status' [14:43:18][C][template.binary_sensor:018]: Device Class: 'safety' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'f1' [14:43:18][C][template.binary_sensor:018]: Device Class: 'safety' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'f2' [14:43:18][C][template.binary_sensor:018]: Device Class: 'safety' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc PGM 1' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc PGM 2' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc PGM 3' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'esp_dsc PGM 4' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'r5' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'r6' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'r7' [14:43:18][C][template.binary_sensor:018]: Template Binary Sensor 'r8' [14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc System Status'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc zone status '
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc Partition 1 Status '
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc Partition 2 Status '
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc Partition 1 Msg '
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc Partition 2 Msg '
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc line1'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc line2'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc line1 partition 2'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc line2 partition 2'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc event'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc beeps'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc partition 2 beeps'
[14:43:18][C][template.text_sensor:021]: Template Sensor 'esp_dsc Trouble Msg '
[14:43:18][C][template.switch:058]: Template Switch 'esp_dsc Connection'
[14:43:18][C][template.switch:059]: Restore State: NO [14:43:18][C][template.switch:060]: Optimistic: NO [14:43:18][C][restart:022]: Restart Switch 'restart_switch'
[14:43:18][C][mdns:095]: Hostname: esp_dsc [14:43:18][C][ota:089]: Over-The-Air Updates: [14:43:18][C][ota:090]: Address: esp_dsc.local:8266 [14:43:18][C][ota:093]: Using Password. [14:43:18][C][api:138]: API Server: [14:43:18][C][api:139]: Address: esp_dsc.local:6053 [14:43:18][C][api:141]: Using noise encryption: YES [14:43:19][D][binary_sensor:036]: 'esp_dsc PGM 4': Sending state ON [14:43:19][I][Paneldata: :956]: 87: 87 00 03 00 8A 00 00 00 00 00 00 00 00 00 00 00 [14:43:19][D][info:1758]: status 05, last status 05,line2status 00,selection 00,partition=1,skip=0 [14:43:19][D][text_sensor:067]: 'esp_dsc line1': Sending state 'Armed: ' [14:43:19][D][text_sensor:067]: 'esp_dsc line2': Sending state 'Away ' [14:43:19][D][info:1758]: status 04, last status 04,line2status 00,selection 00,partition=2,skip=0 [14:43:19][D][text_sensor:067]: 'esp_dsc line1 partition 2': Sending state 'Armed: ' [14:43:19][D][text_sensor:067]: 'esp_dsc line2 partition 2': Sending state 'Stay ' [14:43:20][D][binary_sensor:036]: 'esp_dsc PGM 4': Sending state OFF [14:43:20][I][Paneldata: :956]: 87: 87 00 01 00 88 00 00 00 00 00 00 00 00 00 00 00 [14:43:20][D][info:1758]: status 05, last status 05,line2status 00,selection 00,partition=1,skip=0 [14:43:20][D][text_sensor:067]: 'esp_dsc line1': Sending state 'Armed: ' [14:43:20][D][text_sensor:067]: 'esp_dsc line2': Sending state 'Away ' [14:43:20][D][info:1758]: status 04, last status 04,line2status 00,selection 00,partition=2,skip=0 [14:43:20][D][text_sensor:067]: 'esp_dsc line1 partition 2': Sending state 'Armed: ' [14:43:20][D][text_sensor:067]: 'esp_dsc line2 partition 2': Sending state 'Stay ' [14:43:21][D][binary_sensor:036]: 'esp_dsc PGM 4': Sending state ON
Dilbert66
commented
2 years ago One thing I noticed is that your system is very chatty. For instance, the E6.2C (Enabled zones update)
[06:27:15][I][Paneldata: :956]: E6: E6 00 2C 02 00 00 00 00 14 00 00 00 00 00 00 00is sent every 5 seconds! On my system it only comes every minute.
Edit: Had a better look at the command and it looks like you have 8 partitions enabled as each e6.2c is reporting for each partition ( 1 to 8) which explains why so much traffic. I assume you are only reporting 2 to HA since that's what it shows. If you are not using the others you can disable them in program 201.
The odd part though is that the esp8266 has no issue handling the traffic. Why does the esp32 have issues? It's a perplexing problem. At this point I really don't have an answer.
Dilbert66
commented
2 years ago I believe you also have api encryption turned out. Another thing you can try is disable the api encryption and try again. As another I suppose, you can try changing the read line from 21 to another pin and see if that makes a difference. I can't see why it would unless there is a hardware issue in the chip for that pin. If you had another esp32 to try, that would be a better test.
Dilbert66
commented
2 years ago I had another thought. There is one difference in the esp32 version compared to the esp8266 and it's the use of the Realtime esphome functions to synchronize the panel with network time. Those are disabled in the esp8266 because they take a good chunk of ram memory which is more restrictive on that chip. The esp32 has plenty. I've modified the file dscalarm.h to disable this on the esp32. Let's see if that has an effect on your connectivity. I dont' think that's the problem since I use those functions here with no issues but who knows. It's worth a try.
You will also need to comment the "time:" and "interval:" sections in the yaml (as is done on the esp8266)
Eggster237
commented
2 years ago One thing I noticed is that your system is very chatty. For instance, the E6.2C (Enabled zones update)
[06:27:15][I][Paneldata: :956]: E6: E6 00 2C 02 00 00 00 00 14 00 00 00 00 00 00 00is sent every 5 seconds! On my system it only comes every minute.
Edit: Had a better look at the command and it looks like you have 8 partitions enabled as each e6.2c is reporting for each partition ( 1 to 8) which explains why so much traffic. I assume you are only reporting 2 to HA since that's what it shows. If you are not using the others you can disable them in program 201.
The odd part though is that the esp8266 has no issue handling the traffic. Why does the esp32 have issues? It's a perplexing problem. At this point I really don't have an answer.
Indeed my system only uses 2 partitions, so I will definitely disable the other 6, thanks for pointing that out. This will definitely decrease the amount of useless traffic that is sent over the data line and should make some sort of a difference, even if it doesn't solve the problem.
I agree that it is extremely puzzling that the ESP8266's performance is rock solid while the ESP32 is having issues. I'm actually quite impressed with how capable the ESP8266 is.
Eggster237
commented
2 years ago I believe you also have api encryption turned out. Another thing you can try is disable the api encryption and try again. As another I suppose, you can try changing the read line from 21 to another pin and see if that makes a difference. I can't see why it would unless there is a hardware issue in the chip for that pin. If you had another esp32 to try, that would be a better test.
Since I'm using a custom-built PCB, changing the pin to something else will need some hacking. I will have to build up a prototype on a breadboard for that level of testing, which I might end up doing this weekend. The alternative of testing another ESP32 board is also a good idea, but I will need to source one first.
Edit: I just remembered I do have another ESP32 in one of my project boxes, but it is the NodeMCU form version, so I will test that one as well while I'm playing with the breadboard over the weekend.
Eggster237
commented
2 years ago I had another thought. There is one difference in the esp32 version compared to the esp8266 and it's the use of the Realtime esphome functions to synchronize the panel with network time. Those are disabled in the esp8266 because they take a good chunk of ram memory which is more restrictive on that chip. The esp32 has plenty. I've modified the file dscalarm.h to disable this on the esp32. Let's see if that has an effect on your connectivity. I dont' think that's the problem since I use those functions here with no issues but who knows. It's worth a try.
You will also need to comment the "time:" and "interval:" sections in the yaml (as is done on the esp8266)
Now that you mention it, uncommenting the time sections is the only difference between the yaml that is loaded onto the ESP32 vs the ESP8266 (apart from the pin and board settings). Incidentally, the time syncing function is one of the main reasons why I decided to upgrade to an ESP32, but it is definitely worth a try to disable it for testing purposes.
Given the fact that the ESP32 works perfectly on your system without any changes to the code, and that everything works perfectly on my ESP8266, I am starting to think that the only plausible explanation may be that my ESP32 is somehow faulty. It's brand new and has never been used for anything else, but it could very well be a factory defect.
I will most likely only get to experiment some more over the weekend, but I will post the results as soon as I have done so.
Eggster237
commented
2 years ago Is your ESP32 interfaced directly to your system through voltage dividers or are you using opto-couplers for isolation?
Another common practice is to use pullup resistors on the I²C bus. Could their absence here not be a potential cause for unreliability, or were they left out for a specific reason?
Dilbert66
commented
2 years ago I have two panels I test with. One uses the voltage divider circuit and one uses the optocoupler version. Not knowing how the bus is implemented, I avoided adding extra pullups. I'm assuming they are already there internally anyhow . No need to add more. My goal was to minimize impact and keep the circuit simple.
zsamiatt
commented
2 years ago Hello, This DSC -esphome working with esp32? I would like using ESP32-POE-ISO with LAN whitout wifi. Thx.
Eggster237
commented
2 years ago @Dilbert66 I have done more testing by disabling the time settings and uploading the new header file with no luck.
One thing that I have noticed is the following warnings during compiling. Do you perhaps think that may be part of the problem?:
Over the next few days I will start testing with different ESP32 boards as well to determine whether it is my board that may be faulty.
Dilbert66
commented
2 years ago Well, at least we know what the issue isnt. Those compiler warnings are normal. They come from the esp32 framework code, not mine. It is a bizarre issue though with your wifi connectivity. It does seem to point to a hardware issue but hard to say for sure. Now that I think about it, I did have had one ESP32 some time ago that would work perfectly for a while then all of a sudden would lose connectivity and would not reconnect until a full reboot. I trashed it.
Dilbert66
commented
2 years ago Hello, This DSC -esphome working with esp32? I would like using ESP32-POE-ISO with LAN whitout wifi. Thx. Read this discussion for info: https://github.com/Dilbert66/esphome-dsckeybus/issues/56#issuecomment-1247513372
Eggster237
commented
2 years ago Success!! As a last resort I assigned a static IP to the device in the .yaml file and the first time it seemed as if it doesn't want to connect, but I let it sit for a few minutes just incase. Then it suddenly connected and worked as it should. After that I did a few disconnects and reconnects and it has connected to the WIFI quickly every time. I'm carefully optimistic that the problem may have been solved.
Dilbert66
commented
2 years ago Interesting. That's odd though.. Cool!
Eggster237
commented
2 years ago Makes no sense to me either and the fact that it only had connectivity issues when connected to the dsc tells me that it shouldn't be a DHCP issue. I will keep a close eye on it in case any issues arise. Thank you very much for your patience and support through the fault finding process.
Dilbert66
commented
2 years ago No worries. I just want to make sure it isnt a firmware issue that I need to address.
Dilbert66
commented
2 years ago If you get bored, i've pushed another update that changes a timer function to see if it helps your dhcp connectivity.
Dilbert66
commented
2 years ago The best way really to debug what is going on with your wifi connectivity is if you have a laptop or computer that you can connect to the esp32 usb port. You can then run epshome dashboard, select log, select connected to this computer. You can then reset the esp32 and capture the serial logs while it tries to connect to wifi. That should give an idea where it fails. If there isnt enough info, you can always set log level to verbose in the yaml and try again. It will print a LOT of info but might give an idea what the issue is with connectivity.
Eggster237
commented
2 years ago If you get bored, i've pushed another update that changes a timer function to see if it helps your dhcp connectivity.
Awesome, I will surely give it a try.
Eggster237
commented
2 years ago The best way really to debug what is going on with your wifi connectivity is if you have a laptop or computer that you can connect to the esp32 usb port. You can then run epshome dashboard, select log, select connected to this computer. You can then reset the esp32 and capture the serial logs while it tries to connect to wifi. That should give an idea where it fails. If there isnt enough info, you can always set log level to verbose in the yaml and try again. It will print a LOT of info but might give an idea what the issue is with connectivity.
Ahh.. I should have probably started with that, lol. If I start getting issues again I will follow that route. For now the device is still up and running and working perfectly.
Eggster237
commented
2 years ago If you get bored, i've pushed another update that changes a timer function to see if it helps your dhcp connectivity.
I had some network issues last night and when I got it up again the ESP32 had trouble connecting to the wifi again so I thought that I might try to install the latest version of your code quickly before work this morning to see whether it helps, but it gave me a new compilation error that hasn't appeared before. Please see the logs below:
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- WiFi @ 1.0
|-- ESPmDNS @ 1.0
|-- Update @ 1.0
|-- noise-c @ 0.1.4
| |-- libsodium @ 1.10018.1
Compiling /data/esp_dsc/.pioenvs/esp_dsc/src/main.cpp.o
In file included from src/main.cpp:83:0:
src/dscAlarm.h:203:67: error: expected class-name before '{' token
class DSCkeybushome: public CustomAPIDevice, public RealTimeClock {
^
src/dscAlarm.h:366:8: error: 'void DSCkeybushome::setup()' marked 'override', but does not override
void setup() override {
^
src/dscAlarm.h:1306:6: error: 'void DSCkeybushome::update()' marked 'override', but does not override
void update() override {
^
src/dscAlarm.h: In member function 'void DSCkeybushome::set_panel_time()':
src/dscAlarm.h:273:5: error: 'ESPTime' was not declared in this scope
ESPTime rtc = now();
^
src/dscAlarm.h:274:21: error: 'rtc' was not declared in this scope
dsc.setDateTime(rtc.year, rtc.month, rtc.day_of_month, rtc.hour, rtc.minute);
^
src/dscAlarm.h: In member function 'void DSCkeybushome::setup()':
src/dscAlarm.h:375:27: error: 'set_update_interval' was not declared in this scope
set_update_interval(16);
^
/config/esphome/DscAlarm.yaml: In lambda function:
/config/esphome/DscAlarm.yaml:230:24: error: could not convert '{DSCkeybus}' from '
Dilbert66
commented
2 years ago Uncomment the "time:' section in your yaml and the interval: section. I've added the time related functions as are not the issue. The time: section is needed.
Hi, as per our discussions on the Home Assistant community forum, please see below an ESP log of the working system (i.e. using the ESP8266). Unfortunately, I will have to swop out the board when I get home after work to post ESP32 logs, but since it cannot connect the logs just show that it cannot connect, so not much to see there.
Looking carefully at the logs now I noticed for the first time that there is a warning regarding the "_" (underscore) character at the top, which doesn't seem to be an issue in my case as both boards do connect to the network.
Log: