homekit-ratgdo icon indicating copy to clipboard operation
homekit-ratgdo copied to clipboard

[FEATURE REQUEST] A few settings to expose if possible / if relevant to this fork

Open edrikk opened this issue 6 months ago • 14 comments

Given that Sec V1 hasn't been in Homekit version, I've been using the ESPHome version for a couple of weeks, exposed to HomeKit via Home Assistant. This has been rock solid. In setting this up, I have found that a few settings when building the ESPhome version are quite useful/beneficial, and so thought to post in here so that hopefully it'll get implemented; Especially since V1 support is so close it looks like.

 wifi:
   output_power: 15.0dB

Being able to set the tx power of the wifi chip would be really beneficial for multiple reasons including 1) Reduced interference 2) Being able to control how far the device "talks" (which may also help the folks having trouble because their devices are hopping mesh nodes).

 logger:
   level: INFO

I'm not sure what log level HK firmware defaults to, but I learned that ESP seems to default to debug if not overwritten. I've set to INFO. ESPHome info says that "Increasing the log level severity (to e.g INFO or WARN) can help with the performance of the application and memory size."

preferences:
   flash_write_interval: 60min

Especially for V1 devices that don't have rolling code I think this will be beneficial in terms of flash wear.

esp8266:
  early_pin_init: false

Appears to be a recommended value to set (default is true) to avoid unexpected behavior.

# Delay 120 seconds on boot to allow GDO and 889LM wall panel to boot first. 
  on_boot:
    priority: 800
    then:
      - lambda: |-        
          delay(120000);

I know that ESPHome and MQTT versions wait for GDO/889LM in V1 to load before going into emulation mode (I assume it'll be added here as well), however, some people were still sharing that if the GDO/889LM competed booting after RATGDO (e.g. after a power outage) they were experiencing issues. I've added a delay that I can live with in case power goes out / each RATGDO reboot. Ideally this would be something exposed in the Web UI, and defaulted to 0.

[EDIT] Adding one request: Ability to set (i.e on first boot) and update there-after the WIFI network info beyond the tx power noted above. The use-case for this is that it breaks the reliance on USB loads, making the device once flashed an autonomous entity that can be given away, or have network topology changed, or even flash across firmware flavors untethered.


As a side note, I also tried to go through Homebridge using https://github.com/samhunt/homebridge-esphome-ts/commits/master/ This worked well for 1 device, however there seems to be naming collisions if there are multiple devices - basically only 1 device works. I've left a note in the fork at the relevant commit - hopefully the author does an update.

[UPDATE] Latest version of the homebridge plugin has resolved the above issue.

edrikk avatar Feb 17 '24 19:02 edrikk

if the GDO was turn on after 889LM (e.g. after a power outage)

I think you meant "if the GDO was turn on after ratgdo"

rlowens avatar Feb 17 '24 19:02 rlowens

Yes indeed. I corrected the original post’s wording.

edrikk avatar Feb 17 '24 21:02 edrikk

just a fyi, in the SEC1.0 of this HOMEKIT version, I did panel emulation differently... and I really haven't tested it.... one reason is myself and my other testers all have panels. I did ask people to test, I really got no takers... :(

mitchjs avatar Feb 18 '24 00:02 mitchjs

there is no rolling codes what so ever in V1 wire connections, the protocol is single byte send / rx i guess they felt no need to secure a wire... and i agree

mitchjs avatar Feb 18 '24 00:02 mitchjs

Yes for sure. All the more reason for the above to become configurable in this fork :)

edrikk avatar Feb 18 '24 20:02 edrikk

Chiming in here, as I think it would be great to be able to disable the emulation mode entirely. It's great to have it when you have an analogue panel, and to automatically turn on after a time period so ease of first run is good but this becomes an issue with the digital panel as I discovered at 6:30am after a power outage.

emlynmac avatar Feb 26 '24 18:02 emlynmac

hopefully the code work i did for the homekit sec+1.0 doesnt have this problem i have a wallplate, and funny enough had a power outage this morning, and when it came back as is working just fine i can prob can simulate power fail, with a toggle of my circuit breaker, the GDO and RATGDO board will lose power and get power at same time... i do know it takes a while for the wall panel to sync back up, not sure if thats related to charging the capacitors in it...

mitchjs avatar Feb 26 '24 18:02 mitchjs

but oh yes... we could certainly make it an option, how it works, the code listens for traffic (polling or bootup of the wall panel) and that's how it knows if its there or not(after x amount of time, i did set my timeout to 15sec)

mitchjs avatar Feb 26 '24 18:02 mitchjs

The test was pretty easy to do if you can cut power to the GDO. Cut power to that and your ratgdo board. Wait 2 hours (discharge the wall panel battery) Power up.

I've got a local build where I've just commented out the call to the emulation mode startup function in the cpp.

emlynmac avatar Feb 26 '24 19:02 emlynmac

@emlynmac you are using ESPHOME version, no? i can share with you the firmware.bin (or you can prob get the pending PR) and build and try my version of sec+1.0 support... but its only in Homekit

2hr is long time for me to keep gdo down... the wall panel has the caps, i believe they dischage in mins... and panel goes dead...

mitchjs avatar Feb 26 '24 19:02 mitchjs

@mitchjs yes - esphome version. Happy to grab a PR and work with that.

emlynmac avatar Feb 26 '24 19:02 emlynmac

i left it unpowered for 1hr+ and plugged it all back in, and it just works no issues with my 889LM when powering up i wanted to capture logs, but today is so busy, i couldnt i just powered it up, waited few mins.. then checked it

there is a PR in this homekit version, its pending, if you can use it... i think github will let you get the code build it... and flash away...

i also add you to where i stash the firmware.bin but you might need to install from web this homekit version, and set it up to your wifi and then do web update of firmware

mitch

mitchjs avatar Feb 26 '24 23:02 mitchjs

Need to think about these feature requests. I see how they are valuable, but I also want to honor the intent of the original developer of having no configurables. Although we have recently broken that to allow selecting Sec+1 or Sec+2 mode as well as an auto reboot selector. I still want to limit the amount of configurables. The device really should just work.

That said, some of the settings shown in the original post probably make sense to bake into the code like setting the output power to 15db. Setting the flash write interval to 60 minutes is probably feasible now that the device doesn't crash every 15 minutes. I'll need to understand the early_pin_init setting more, but maybe that makes sense to bake in as well.

jgstroud avatar Mar 20 '24 22:03 jgstroud

I've been a user of alarmdecoder for a few years. The intent behind it is/was much similar to ratgdo -> to remove dependency on alarm companies, and enable local management.

Fast forward a few years and it looks like the site (https://www.alarmdecoder.com) and its forums have been taken down, and with it no way to obtain the firmware, docker images, etc. At least I made backups of the microsd image and latest firmware.

All of this to say, this made me come here and bump this request. Most specifically, given that the firmware now allows for selection of other wifi items (e.g. auto, g, n), can we please have ability to change the SSID and password added?

That will allow the platform avoid becoming a brick if the online components disappear...

edrikk avatar May 11 '24 18:05 edrikk