Closed knifesk closed 3 years ago
Dilbert66
commented
3 years ago Interesting. Might be an effect of the esphome latest version. I'll upgrade and try it out. Your debug code is helpful as it points to the getextbytes where the error occurs. I'll look into it as well
Dilbert66
commented
3 years ago I do see one issue. I have a bug in my bounds checking for an arrary index (not compensating for an increment) so if the receive buffer goes beyond the initialized array, this could cause an error. Don't think it would create the error above but it all depends on what is stored at the address above the array that is being overwritten.
Edit: Never mind. The code is correct. Brain fart.
This still doesnt explain why you are getting that error since the array is large enough in normal operation not to overflow. Perhaps you are getting spurious data. Is your wiring correct to the alarm system? It could also be related to an issue with the 8266 new library itself. It works fine on the esp32 which I just tried now. I will have to switch chips and try out the esp8266 later.
Edit: did find an invalid array bounds check so fixed it and pushed to dev. Don't think it's your issue but who knows.
knifesk
commented
3 years ago I'm not even reaching the point of connecting the esp to the panel. I already had everything installed and I need to remove the module from the socket in order to flash it... I tried connecting it after it went into safe mode, but I couldn't debug it while it's up in the cabinet. Obviously I couldn't make it work, so I went back to the computer and tried again... Shouldn't it boot anyway if it's not connected to the panel?
On Thu, Aug 19, 2021, 21:42 Alain Turbide @.***> wrote:
I do see one issue. I have a bug in my bounds checking for an arrary index (not compensating for an increment) so if the receive buffer goes beyond the initialized array, this could cause an error. Don't think it would create the error above but it all depends on what is stored at the address above the array that is being overwritten. Anyhow, I will fix that.
This still doesnt explain why you are getting that error since the array is large enough in normal operation not to overflow. Perhaps you are getting spurious data. Is your wiring correct to the alarm system? It could also be related to an issue with the 8266 itself. It works fine on the esp32 which I just tried now. I will have to switch chips and try out the esp8266 later.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dilbert66/esphome-vistaECP/issues/52#issuecomment-902345965, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRO3FM7N2PCIKTRLK4MQDT5WQF5ANCNFSM5CPH7DLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
Dilbert66
commented
3 years ago It will boot fine without panel connection. I updated my test platform to the latest epshome version and can't see any issues. At this point I really don't have a solution to offer.
Dilbert66
commented
3 years ago Can you post your yaml config?
knifesk
commented
3 years ago First thing of all: Thanks for your time man! I really appreciate you take time off your own in order to help me.
I'll attach the YAML at the end. At first I added a couple zones (11 and 12) and also removed 1...3 and 5..8 (the wired ones) since my entire setups is wireless and the only wired sensor I have isn't wired yet, but I'm planning to wire it at z4.... as things were not running at all I restored the entire yaml to the original one and tried to change as little as possible, but it still not running... This is the last version I tried before reaching for help. I'm gonna give it another try with a freshly cloned repo... I'll report back in a couple minutes..
As a sidenote: thing was working just fine with the MQTT example before trying the ESP version.. is there any chance that the flash isn't wiping entirely? I've read several times that if the entire flash isn't wiped it might cause issues.
#for documentation see project at https://github.com/Dilbert66/esphome-VistaECP
substitutions:
systemName: "vistaalarm"
accessCode: !secret access_code #Only comes into effect if needed for arming and quickarm is not set
keypadAddr: "17" #set this to an unused keypad address slot. Make sure to enable it in your vista panel programming
##esp32
#rxPin: "22" #GPIO pin to use for data receive (yellow line)
#txPin: "21" #GPIO pin to use for data transmit (green line)
#monitorPin: "18" #GPIO pin to use for monitoring module traffic such as RF or Expanders . Set to -1 to disable
##esp8266
rxPin: "5" #GPIO pin to use for data receive (yellow line)
txPin: "4" #GPIO pin to use for data transmit (green line)
monitorPin: "-1" #GPIO pin to use for monitoring module traffic such as RF or Expanders . Set to -1 to disable
# module addresses:
# 07 4229 zone expander zones 9-16
# 08 4229 zone expander zones 17-24
# 09 4229 zone expander zones 25-32
# 10 4229 zone expander zones 33-40
# 11 4229 zone expander zones 41 48
# 12 4204 relay module
# 13 4204 relay module
# 14 4204 relay module
# 15 4204 relay module
expanderAddr1: "0" # 1st zone expander emulator (4229) address to use . Set to 0 to disable.
expanderAddr2: "0" # 2nd expander emulator address to use . Set to 0 to disable.
relayAddr1: "0" # relay module emulation (4204) addresses. Set to 0 to disable
relayAddr2: "0"
relayAddr3: "0"
relayAddr4: "0"
TTL: "30000" # time to live in ms for zone/fire status before expiring;
quickArm: "false"
lrrSupervisor: "false" # set to true if we don't have an LRR monitoring supervisor we can emulate one to get the statuses
globals:
#persistent storage variables
- id: zoneStates #persistant storage for zone states in case of reboot
type: int
restore_value: yes
- id: zoneAlarms #persistant storage for zone states in case of reboot
type: int
restore_value: yes
- id: zoneBypass #persistant storage for zone states in case of reboot
type: int
restore_value: yes
- id: zoneChecks #persistant storage for zone states in case of reboot
type: int
restore_value: yes
- id: lrrCode #persistant storage for last lrr message in case of reboot
type: int
restore_value: yes
esphome:
name: $systemName
#platform: ESP32
#board: nodemcu-32s
platform: ESP8266
board: nodemcuv2
# subdirectory where library *.h and *.cpp are placed
includes:
- vistaEcpInterface/
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "$systemName"
password: !secret ap_password
logger:
baud_rate: 115200
level: DEBUG
api:
password: !secret api_password
ota:
password: !secret ota_password
safe_mode: True
#status_led:
# pin:
# number: D4
# inverted: yes
custom_component:
- lambda: |-
auto VistaECP = new vistaECPHome($keypadAddr,$rxPin,$txPin,$monitorPin);
VistaECP->accessCode="$accessCode";
VistaECP->quickArm=$quickArm;
VistaECP->expanderAddr1=$expanderAddr1; //zone expander
VistaECP->expanderAddr2=$expanderAddr2;
VistaECP->relayAddr1=$relayAddr1; //relay module
VistaECP->relayAddr2=$relayAddr2;
VistaECP->relayAddr3=$relayAddr3;
VistaECP->relayAddr4=$relayAddr4;
VistaECP->lrrSupervisor=$lrrSupervisor;
VistaECP->TTL=$TTL;
VistaECP->debug=1;
VistaECP->onSystemStatusChange([&](std::string statusCode) {
id(system_status).publish_state(statusCode);
});
VistaECP->onLrrMsgChange([&](std::string msg) {
id(m1).publish_state(msg);
});
VistaECP->onRfMsgChange([&](std::string msg) {
id(rf1).publish_state(msg);
});
VistaECP->onLine1DisplayChange([&](std::string msg) {
id(l1).publish_state(msg);
});
VistaECP->onLine2DisplayChange([&](std::string msg) {
id(l2).publish_state(msg);
});
VistaECP->onBeepsChange([&](std::string beeps) {
id(beep1).publish_state(beeps);
});
VistaECP->onStatusChange([&](sysState led,bool open) {
switch(led) {
case sfire: id(fire).publish_state(open);break;
case salarm: id(alarm1).publish_state(open);break;
case strouble: id(trouble).publish_state(open);break;
case sarmedstay: id(stay).publish_state(open);break;
case sarmedaway: id(away).publish_state(open);break;
case sinstant: id(instant).publish_state(open);break;
case sready: id(ready).publish_state(open);break;
case sac: id(ac).publish_state(open);break;
case sbypass: id(bypass).publish_state(open);break;
case schime: id(chime).publish_state(open);break;
case sbat: id(bat).publish_state(open);break;
case scheck: id(check).publish_state(open);break;
case sarmednight: id(night).publish_state(open);break;
case sarmed: id(armed).publish_state(open);break;
default: break;
}
});
VistaECP->onZoneStatusChange([&](uint8_t zone, std::string open) {
switch (zone) {
case 1: id(z1).publish_state(open); break;
case 2: id(z2).publish_state(open); break;
case 3: id(z3).publish_state(open); break;
case 4: id(z4).publish_state(open); break;
case 5: id(z5).publish_state(open); break;
case 6: id(z6).publish_state(open); break;
case 7: id(z7).publish_state(open); break;
case 8: id(z8).publish_state(open); break;
case 9: id(z9).publish_state(open); break;
case 10: id(z10).publish_state(open); break;
case 17: id(z17).publish_state(open); break;
}
}); //you can add more zones above . Also add the text sensor entry below
VistaECP->onRelayStatusChange([&](uint8_t addr,uint8_t zone,bool open) {
switch(addr) {
case 12: switch (zone) {
case 1: id(r1).publish_state(open); break;
case 2: id(r2).publish_state(open); break;
}
break;
case 13: break;
}
}); //add as many case and switch statements as needed to control your binary sensor outputs
return {VistaECP};
binary_sensor:
#- platform: gpio #example use of pin d8 as a zone trigger port for the emulated zone expander
# pin: D8
# id: pind8
# device_class: window
# on_press: #zone,on/off
# - lambda: |-
# vista.setExpFault(17,1);
# on_release:
# - lambda: |-
# vista.setExpFault(17,0);
#system status indicator definitions
- platform: template
id: trouble
name: "$systemName Trouble"
device_class: problem
- platform: template
id: bypass
name: "$systemName Bypass"
- platform: template
id: away
name: "$systemName Away"
- platform: template
id: armed
name: "$systemName Armed"
- platform: template
id: stay
name: "$systemName Stay"
- platform: template
id: instant
name: "$systemName Instant"
- platform: template
id: night
name: "$systemName Night"
- platform: template
id: ac
name: "$systemName AC"
device_class: plug
- platform: template
id: chime
name: "$systemName Chime"
- platform: template
id: check
name: "$systemName Check"
device_class: problem
- platform: template
id: alarm1
name: "$systemName Alarm"
- platform: template
id: bat
name: "$systemName Battery"
device_class: problem
- platform: template
id: fire
device_class: smoke
name: "$systemName Fire"
- platform: template
id: ready
name: "$systemName Ready"
#device_class: problem
#relay module channels add as many as you need. To hide, comment out the name: attribute
- platform: template
id: r1
name: "$systemName Relay1"
- platform: template
id: r2
name: "$systemName Relay2"
#zone definitions. Add more (also add to the switch statment above). To hide, comment out the name: attribute
text_sensor:
#zone definitions
- platform: template
id: z1
name: "$systemName Front door"
- platform: template
id: z2
name: "$systemName Garage door"
- platform: template
id: z3
name: "$systemName Back door"
- platform: template
id: z4
name: "$systemName Living room window"
- platform: template
id: z5
name: "$systemName Dining room window"
- platform: template
id: z6
name: "$systemName Family room window LF"
- platform: template
id: z7
name: "$systemName Family room window RF"
- platform: template
id: z8
name: "$systemName Basement windows"
- platform: template
id: z9
name: "$systemName Basement windows9"
- platform: template
id: z10
name: "$systemName Basement windows10"
- platform: template
id: z17
name: "$systemName zone 17"
#system status
- platform: template
id: system_status
name: "$systemName System Status"
icon: "mdi:shield"
- platform: template
id: m1
name: "$systemName Lrr Msg"
icon: "mdi:alert-box"
- platform: template
id: rf1
name: "$systemName RF Msg"
icon: "mdi:alert-box"
- platform: template
id: l1
name: "$systemName Line1"
- platform: template
id: l2
name: "$systemName Line2"
- platform: template
id: beep1
name: "$systemName Beeps"
switch:
- platform: template
name: "$systemName Connection"
id: connection_status_switch
lambda: |-
return vista.keybusConnected;
icon: "mdi:shield-link-variant"
turn_on_action:
- switch.toggle: restart_switch
turn_off_action:
- lambda: |-
disconnectVista();
- platform: restart
id: restart_switch
Ok, i see the issue. You have the monitor pin set at -1 to disable but yet, my code is still trying to read an invalid disabled pin. The serial code should not allow that and technically my getextbyte routine should not be called. Initially the code used a #DEFINE to enable or disable the monitor code but I switched to using a yaml configuration.
I'll fix the code. For now, you can set a valid pin for the monitor pin config. (even if you don't have it hooked up) so that the code will at least run.
Dilbert66
commented
3 years ago Pushed corrected version.
knifesk
commented
3 years ago Yes sir! that was it! It's booting now! Does it make any difference to have it enabled and not connected? I'm not planning to use it anyway...
I need to do some other stuff rn, but as soon as I finish with my things I'll rebuild all the YAML as I intend to use it and re-connect the module to the panel. I'll be back later! I promise I'll bring a couple pics to show off hehe :)
Thanks for your time man, you're the best. I promised a couple months ago to make some contributions to the project, I'm planning to cleanup the codebase and see if I can improve something :D
Cheers!
Dilbert66
commented
3 years ago Best to leave it at -1 so you don't pick up errant bits. The monitor pin is really useful for those that have RF devices as it will pick up various states from those devices. Also on/off status will be detected immediately since the code will use the device response to decided if the sensor is off or on.
Hey guys, I had to rebuild my HomeAssistant instance and finally I decided to give ESPHome a Try... this is like the 10th time I rebuild the YAML, folder, wipe, clean and try again with the same results...
I have the NodeMCU connected via USB into the home asssitant pc, and I flashed via USB.. while it's building, flashing and starting.. the latter fails 10 times pretty quick and then the chip goes into safe mode. I think the lib is crashing.. maybe it's becase new versions of arduino or ESPHome? I'm a pretty experienced developer, but C++ and low level things are not my thing... so, I can't quite make heads or tails of this.
I tried to do the least modifictaions possible and still couldn't get it to work... Here's the log of the flash/boot process.. any hints are appreciated.