Heads up: ESPHome firmware does not support Security 1.0 openers (purple learn button)

[avwuff]

I just spent an hour trying to get this to work and had no success. Turns out it's not supported in ESPHome firmware.

https://paulwieland.github.io/ratgdo/01_features.html

Just letting others know so they don't waste their time.

[niemyjski]

This is a duplicate of https://github.com/ratgdo/esphome-ratgdo/issues/70#issuecomment-1813189602 and it's marked as coming soon in the readme. An update by @PaulWieland would be greatly appreciated.

[Kylar514]

Interesting, just out of curioustiy what where the symptoms you were facing?

I have a brown button, which according to Chamberlain is the same as a purple, so it seems I an on Security 1.0. The weird thing is, I was able to get it to work intermittently. I have full status on obstruction sensors, toggling the door open and closed will work few and far between, mostly I am just getting a issue that says

17:12:06    [W] [component:214]  Component preferences took a long time for an operation (0.05 s).

17:12:06    [W] [component:215 Components should block for at most 20-30ms.

I assume thats what you were getting as well.

[bdraco]

duplicate of https://github.com/ratgdo/esphome-ratgdo/issues/62

[miles267]

Coming soon as in approx when? (ESPHome Security 1.0)

[mariusmuja]

It has been implemented, but it is completely untested as of now.

People feeling brave are welcome to try this branch: https://github.com/ratgdo/esphome-ratgdo/tree/sec_plus_v1, but be aware it's likely to have bugs. If so, posting the logs here could help fix those bugs...

[miles267]

@mariusmuja are testers needed to progress this? It seems the user community is anxiously watching the production release page for ESPHome with Security 1.0 support and most or all users did not see your post here w a pre-release version.

[mariusmuja]

@miles267 Yes, more testers would be nice. It's only been implemented for a few of days now, and I have no way to directly test it, relying 100% on other people to report issues with it and post debug logs.

[miles267]

@mariusmuja are you able to update this page to include a link so more users are aware and can find this info? https://ratgdo.github.io/esphome-ratgdo/

[4rsfed]

Can someone link me to what's necessary to flash this untested code? i am not familiar with ESP devices, but have 3 2.5 boards waiting for Sec1 support so happy to flash them and report issues/logs. Just not sure how to flash them/update them - I'd always used the web flasher.

[smarthomeaf]

I am trying to use the branch code, but i am having issues compiling. Would someone be able to point me in the right direction. I am willing to do any testing that is required.

Here is what i am getting during validation

Here is my code block

substitutions:
  name: "garage-door-right"
  friendly_name: Garage Door Right
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v25iboard.yaml@sec_plus_v1
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: I0Vo0DyYe9xsJny5JPGhw85Lc9942fPI34qlqnfgz1E=

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

external_components:
  - source:
      type: git
      url: https://github.com/ratgdo/esphome-ratgdo
      ref: sec_plus_v1
    refresh: 1s

preferences:
  flash_write_interval: 5s

ratgdo:
  id: ${id_prefix}
  input_gdo_pin: ${uart_rx_pin}
  output_gdo_pin: ${uart_tx_pin}
  input_obst_pin: ${input_obst_pin}
  protocol: secplusv1
  on_sync_failed:
    then:
      - homeassistant.service:
          service: persistent_notification.create
          data:
            title: "${friendly_name} sync failed"
            message: "Failed to communicate with garage opener on startup."
            notification_id: "esphome_ratgdo_${id_prefix}_sync_failed"

lock:
  - platform: ratgdo
    id: ${id_prefix}_lock_remotes
    ratgdo_id: ${id_prefix}
    name: "Lock remotes"

switch:
  - platform: gpio
    id: "${id_prefix}_status_door"
    internal: true
    pin:
      number: ${status_door_pin}  # D0 output door status, HIGH for open, LOW for closed
      mode:
        output: true
    name: "Status door"
    entity_category: diagnostic
  - platform: gpio
    id: "${id_prefix}_status_obstruction"
    internal: true
    pin:
      number: ${status_obstruction_pin}  # D8 output for obstruction status, HIGH for obstructed, LOW for clear
      mode:
        output: true
    name: "Status obstruction"
    entity_category: diagnostic

binary_sensor:
  - platform: ratgdo
    type: motion
    id: ${id_prefix}_motion
    ratgdo_id: ${id_prefix}
    name: "Motion"
    device_class: motion
  - platform: ratgdo
    type: obstruction
    id: ${id_prefix}_obstruction
    ratgdo_id: ${id_prefix}
    name: "Obstruction"
    device_class: problem
    on_press:
      - switch.turn_on: ${id_prefix}_status_obstruction
    on_release:
      - switch.turn_off: ${id_prefix}_status_obstruction
  - platform: ratgdo
    type: button
    id: ${id_prefix}_button
    ratgdo_id: ${id_prefix}
    name: "Button"
    entity_category: diagnostic
  - platform: gpio
    id: "${id_prefix}_dry_contact_open"
    pin:
      number: ${dry_contact_open_pin}  # D5 dry contact for opening door
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Dry contact open"
    entity_category: diagnostic
    filters:
      - delayed_on_off: 500ms
    on_press:
      - if:
          condition:
            binary_sensor.is_off: ${id_prefix}_dry_contact_close
          then:
            - cover.open: ${id_prefix}_garage_door
  - platform: gpio
    id: "${id_prefix}_dry_contact_close"
    pin:
      number: ${dry_contact_close_pin}  # D6 dry contact for closing door
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Dry contact close"
    entity_category: diagnostic
    filters:
      - delayed_on_off: 500ms
    on_press:
      - if:
          condition:
            binary_sensor.is_off: ${id_prefix}_dry_contact_open
          then:
            - cover.close: ${id_prefix}_garage_door
  - platform: gpio
    id: "${id_prefix}_dry_contact_light"
    pin:
      number: ${dry_contact_light_pin}  # D3 dry contact for triggering light (no discrete light commands, so toggle only)
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Dry contact light"
    entity_category: diagnostic
    filters:
      - delayed_on_off: 500ms
    on_press:
      - light.toggle: ${id_prefix}_light

number:
  - platform: ratgdo
    id: ${id_prefix}_rolling_code_counter
    type: rolling_code_counter
    entity_category: config
    ratgdo_id: ${id_prefix}
    name: "Rolling code counter"
    mode: box
    unit_of_measurement: "codes"

  - platform: ratgdo
    id: ${id_prefix}_opening_duration
    type: opening_duration
    entity_category: config
    ratgdo_id: ${id_prefix}
    name: "Opening duration"
    unit_of_measurement: "s"

  - platform: ratgdo
    id: ${id_prefix}_closing_duration
    type: closing_duration
    entity_category: config
    ratgdo_id: ${id_prefix}
    name: "Closing duration"
    unit_of_measurement: "s"

  - platform: ratgdo
    id: ${id_prefix}_client_id
    type: client_id
    entity_category: config
    ratgdo_id: ${id_prefix}
    name: "Client ID"
    mode: box

cover:
  - platform: ratgdo
    id: ${id_prefix}_garage_door
    device_class: garage
    name: "Door"
    ratgdo_id: ${id_prefix}
    on_closed:
      - switch.turn_off: ${id_prefix}_status_door
    on_open:
      - switch.turn_on: ${id_prefix}_status_door

light:
  - platform: ratgdo
    id: ${id_prefix}_light
    name: "Light"
    ratgdo_id: ${id_prefix}

button:
  - platform: restart
    name: "Restart"
  - platform: safe_mode
    name: "Safe mode boot"
    entity_category: diagnostic

  - platform: template
    id: ${id_prefix}_query_status
    entity_category: diagnostic
    name: "Query status"
    on_press:
      then:
        lambda: !lambda |-
          id($id_prefix).query_status();

  - platform: template
    id: ${id_prefix}_sync
    name: "Sync"
    entity_category: diagnostic
    on_press:
      then:
        lambda: !lambda |-
          id($id_prefix).sync();

  - platform: template
    id: ${id_prefix}_toggle_door
    name: "Toggle door"
    on_press:
      then:
        lambda: !lambda |-
          id($id_prefix).door_toggle();

[PaulWieland]

With esphome cli installed:

• Save the yaml file to your computer
• Edit the file and set your wifi credentials under the "wifi" section as follows:
  • delete ap
  • add ssid: YOUR_SSID
  • add password: YOUR_PASSWORD
  • save
  • run esphome run v25iboard_secplusv1.yaml to compile and install

[smarthomeaf]

Looks good now. I will physically install later today and let you know results.

[4rsfed]

Hooked up to my purple button SEC1.0 and the light control works (on/off) the garage goes up, but will not go down. Is there a way to get the logs out of the ESP UI to paste them here? I see the live log on the webUI, but I can't go back to the time I tested.

Only thing I noticed was the obstruction state never changed when putting my foot in front of the beams and removing it.

[rlowens]

Is there a way to get the logs out of the ESP UI to paste them here?

If you have ESPHome CLI, you can run esphome log v25iboard_secplusv1.yaml

If you have ESPHome Addon, click LOGS on the device in ESPHome UI.

Can also view the device's webpage/events, like http://ratgdo1.local/events or http://192.168.1.172/events

[4rsfed]

Log file attached here sec1.log

[mariusmuja]

Log file attached here

I can't find any door interaction in this log. Can you capture another log where you open/close the door? and update to the latest, I added a bit of extra logging.

[4rsfed]

sec1 second try.log

Working now (up, down, and lights) I had the wiring for the obstruction sensor incorrect the first time.

[miles267]

@4rsfed is ESPHome also allowing you to calibrate the door open and close as well as place the door partial open position with Security 1.0? I saw this was a feature of Security 2.0.

[4rsfed]

@miles267 - I have garage 5 doors, (3 sec1 and 2 sec2). All the sec2 doors are running ESPhome ratgdo boards. I haven't had to calibrate any of them. I am able to stop the door via UI at any time. I will try to open the door to a 50% state in a few bit. I expect it to work, as the log files update with the door % open/close. So the opener/ratgdo is aware of the current location during movement. (just guessing here)

[4rsfed]

Looking at the second log file I posted, doesn't have the positions...... not sure if I am doing something wrong when going to ip/events but I see the updates on the UI (took a video recording of the screen as it was going up and down)

[PaulWieland]

@4rsfed what color is your learn button?

[4rsfed]

@PaulWieland - purple

I put wires on all of these to help make it easier to troubleshoot/hook up. Only using 3 wires not all 4 that are pictured

[miles267]

Looks like this could be nearing production? Appreciate the testing. We’ve had unseasonably cold temps making it difficult to spend time in garage.

[smarthomeaf]

Works great other than not knowing if the door is open or closed. V1 has no way of knowing if door is open or closed. I can work around this by creating a custom cover using a Tilt Sensor that I have on my door, but would be great if we could allow users to add a binary_sensor (tilt or door) to track door status.

I use the below to create a custom cover.

cover:
  - platform: template
    covers:
      garage_door_left_c:
        device_class: garage
        friendly_name: "Garage: Left Door"
        value_template: "{{ is_state('binary_sensor.garage_left_tilt_door' , 'on') }}"
        unique_id: garage_door_left_id
        open_cover:
          service: cover.open_cover
          entity_id: cover.garage_left_door
        close_cover:
          service: cover.close_cover
          entity_id: cover.garage_left_door
        stop_cover:
          service: cover.stop_cover
          entity_id: cover.garage_left_door
        icon_template: >-
          {% if is_state('binary_sensor.garage_left_tilt_door' , 'on') %}
            mdi:garage-open
          {% else %}
            mdi:garage
          {% endif %}

[mariusmuja]

Works great other than not knowing if the door is open or closed. V1 has no way of knowing if door is open or closed.

Not true, V1 should receive door status. If it doesn't work for you, can you post a log capture here?

would be great if we could allow users to add a binary_sensor (tilt or door) to track door status.

It's going to be added for the dry contact protocol, which indeed has not way of knowing the door status.

[smarthomeaf]

logs_garagedoorright_logs (1).txt

Stand corrected. That said, the open position is fine, but close positions never calculates and hangs at the 8% according to logs. Unless I am missing something.

Close Position

Open Postion

[mariusmuja]

@smarthomeaf

In sec+v1 the wall panel is constantly polling the GDO (every 250ms) for door status, obstruction status and light/lock status.

We have seem three types of sec+v1 configurations:

• GDO with analog wall panel: the GDO is not queried and functions in dry-contact mode. In this case ratgdo starts polling the GDO like a wall panel would (wall panel emulation).
• GDO with a 889LM wall panel. The wall panel polls continuously and ratgdo just listens for status and occasionally inserts a command.
• GDO with a 398LM wall panel. This wall panel also polls continuously, but it's using a different query byte (0x37) instead of the 0x38 that the 889LM panel uses and in all cases we've seen so far, the GDO is not replying to 0x37 queries. In this case we insert our own 0x38 query right after 0x37 to which the GDO responds (but only to some queries).

Your wall panel/GDO combination behaves differently: the wall panel is sending 0x37 (is it a 398LM?), but the GDO is replying, but from what I can see in the log you sent, it always replies with 0x02, not matter what the door state is. It seems to mostly ignore the 0x38 queries we insert, except twice in your log (when the door was open and when it started closing). That's why you only get partial door status updates.

I pushed a change to a test branch (https://github.com/ratgdo/esphome-ratgdo/tree/sec_plus_v1_test) in which I'm not sending the 0x38 query right after a 0x37 in case the GDO is not ready to receive it (because it's sending a 0x02 reply itself), but slightly later. Give it a try and see if it works any better.

[smarthomeaf]

I will have to check the wall panel model (i know that this garage door is at least 10 years old). I am going to give the new version a whirl and let you know how it behaves.

[miles267]

I just realized my wall unit is an 888LM. I didn’t realize there was an 889LM model. How do they differ? My GDO has a purple learn button Security 1.0.

[smarthomeaf]

I think its a 398LM based on this picture and a reverse image search on google.

Now it seems to get stuck on 5% rather than 8%

Do the duration settings need to be changed?

sec1_test_code.txt

[mariusmuja]

Do the duration settings need to be changed?

They should automatically calibrate if you set them to 0. But since the door status is not reliably sent in your case that's probably not going to work, so you could time and set them manually.

Just want to confirm that you are using the sec_plus_v1_test branch? Looking at the last log you sent it appears as if you are still using sec_plus_v1.

[smarthomeaf]

Let me set them back to 0. Here is my code, does this look right.

[smarthomeaf]

logs_garagedoorright_logs (2).txt

now it does not look like I am getting anything other than 100%. I have a ratgdo on another door. It is currently running native RATDGO code. I will update it tomorrow to this code. At least it will help determine if it has anything to do with the wall panel

[mariusmuja]

@smarthomeaf

There was a ref in base_secplusv1.yaml pointing to the sec_plus_v1 branch that needed updated. You can try again when you get a chance.

[rlowens]

I just realized my wall unit is an 888LM. I didn’t realize there was an 889LM model. How do they differ?

I found this description of the 888LM https://ipcamtalk.com/threads/a-word-of-caution-regarding-liftmaster-888lm-wall-control.45759/

Unfortunately, sometimes the electrolytic capacitors that power them fail. When that happens, there can be spikes in power consumption large enough to make the opener think the button was pressed. Meaning the garage door may open itself (extra closings would typically go unnoticed). This has been reported in various reviews and forums. If your handy with a soldering iron it's easy enough to repair, but I'd tend to remove it and do something else that's powered independently to automate your garage door.

Liftmaster has an extended the warranty on this part and will replace it with the new model the 889LM through September 2023 https://cloud.info.liftmaster.com/888LMReplacement They claim the incidence of of problems is small, but in my view it's largely a matter of time, temperature, and capacitor batch. People in hotter climates will likely experience this sooner.

[smarthomeaf]

So i migrated my other RATDGO from standard (using MQTT) code to the ESPHOME sec_plus_v1_test and the result is teh same. One thing I did notice when monitoring the logs (sorry I did not capture them) is that when I flashed it via USB and monitored the logs, i noticed there was an entry something to the effect of... Searching for wall panel and eventually said using emulation.

But when I physically moved the RATDGO to the opener and monitored the logs, the search for the wall panel never happened. (at least it was not logged). I flashed it again via wifi while connected to teh door opener and again did not see that message in logs. I wonder if this has anything to do with it.

Here are the logs for both of my devices both on the sec_plus_v1_test branch. Would it make sense for me to flash it via USB Serial while connected to the door opener to trigged the searching for wall panel?

Also, i am going to flash one of the device to the sec_plus_v1 rather than teh sec_plus_v1_test as that one seem to report a broader array of percentages.

Right.txt Left.txt

[mariusmuja]

Had a look at both logs, and both openers are only reporting door status when the door is open and when it's closing, for example with door closing, there is a 38 04 response from the GDO:

[12:29:25][D][ratgdo_secplus1:240]: [119133] Received byte: [39]                                                                                                                                                                                                     
[12:29:25][D][ratgdo_secplus1:259]: [119137] Received byte: [00]                                                                                                                                                                                                     
[12:29:25][D][ratgdo_secplus1:284]: [119138] Received packet: [39 00]                                                                                                                                                                                                
[12:29:25][D][ratgdo_secplus1:240]: [119389] Received byte: [37]                                                                                                                                                                                                     
[12:29:25][D][ratgdo_secplus1:247]: [119392] Received command: [37]                                                                                                                                                                                                  
[12:29:25][D][ratgdo_secplus1:235]: [119411] Ignoring byte [08], baud: 1200                                                                                                                                                                                          
[12:29:25][D][ratgdo_secplus1:460]: [119474] Sent byte: [38]                                                                                                                                                                                                         
[12:29:25][D][ratgdo_secplus1:240]: [119487] Received byte: [38]                                                                                                                                                                                                     
[12:29:25][D][ratgdo_secplus1:259]: [119489] Received byte: [04]                                                                                                                                                                                                     
[12:29:25][D][ratgdo_secplus1:284]: [119491] Received packet: [38 04]                                                                                                                                                                                                
[12:29:25][D][ratgdo:098]: Door state=CLOSING 

As soon as the door closes, there are no replies to the 0x38 request:

[12:29:40][D][ratgdo_secplus1:240]: [134672] Received byte: [39]                                                                                                                                                                                                     
[12:29:40][D][ratgdo_secplus1:259]: [134692] Received byte: [00]                                                                                                                                                                                                     
[12:29:40][D][ratgdo_secplus1:284]: [134695] Received packet: [39 00]                                                                                                                                                                                                
[12:29:41][D][ratgdo_secplus1:240]: [134929] Received byte: [37]                                                                                                                                                                                                     
[12:29:41][D][ratgdo_secplus1:247]: [134932] Received command: [37]                                                                                                                                                                                                  
[12:29:41][D][ratgdo_secplus1:235]: [134951] Ignoring byte [08], baud: 1200                                                                                                                                                                                          
[12:29:41][D][ratgdo_secplus1:460]: [135012] Sent byte: [38]                                                                                                                                                                                                         
[12:29:41][D][ratgdo_secplus1:240]: [135033] Received byte: [38]                                                                                                                                                                                                     
[12:29:41][W][ratgdo_secplus1:273]: [135136] Discard incomplete packet: [38 ...] 

Searching for wall panel and eventually said using emulation.

Wall panel emulation is used if the status messages are not received for door status and light status. Since your GDO is reporting light status, it should not happen in your case.

the search for the wall panel never happened. (at least it was not logged).

It happens every time when ratgdo boots up, if you didn't look with a serial console you might have missed it by the time the ratgdo connected to wifi.

Would it make sense for me to flash it via USB Serial while connected to the door opener to trigged the searching for wall panel?

No, it wouldn't change anything. In both logs you sent there is no wall panel emulation running (as it shouldn't be because the wall panels are connected).

The problem is that your GDO is only reporting the door status when the door is open and the door is closing, so the door position is not showing correctly. The percentages you see depend on the closing duration configured (they are reported every 0.5s).

Another thing you can try is to disconnect the wall panel and leave only ratgdo connected (and reboot ratgdo). In that case ratgdo should start using wall panel emulation and you can test if the door position is reported correctly like that.

[smarthomeaf]

Another thing you can try is to disconnect the wall panel and leave only ratgdo connected (and reboot ratgdo). In that case ratgdo should start using wall panel emulation and you can test if the door position is reported correctly like that.

I will give this a whirl later today.

[smarthomeaf]

So disconnecting wall panel seemed to work. So emulation seems to be working fine. I also populated the opening and closing durations.

logs_garage-door-left_run (1).txt

[mariusmuja]

@smarthomeaf

Yeah, there's not much to do about it from a software point of view if the GDO doesn't report door status with the wall panel attached. You could replace the wall panels with 889LM models, those have been working fine for people.

Btw, the last log you sent is with the wall panel attached, it has the 0x37 commands in it.

[smarthomeaf]

@mariusmuja, this one logs_garage-door-left_run (1).txt has no wall panel attached.

[mariusmuja]

@mariusmuja, this one logs_garage-door-left_run (1).txt has no wall panel attached.

Are you sure? I'm still seeing 0x37 commands in it and we were sure those commands are sent by the 398LM wall panels (we never see them otherwise).

[smarthomeaf]

To avoid confusion, reran tests with correct labels. I am looking to see if I can get a cheap wall panel on ebay. with Panel.txt without panel.txt

[mariusmuja]

@smarthomeaf Yes, logs look like I would expect them to look like now.

[smarthomeaf]

I will look into buying a cheap 889LM on ebay. In the mean time, is there a way for me to force emulation even with wall panel installed? I don't was to lose the capabilities of the wall panel. The draw back on the emulation front is that the door would go out of synch if I open the door via some other means. (not know for sure if door is open or close). Alternatively, if I can manually add my tilt sensor to the esphome (rather than creating a custom Cover) would be good

[mariusmuja]

is there a way for me to force emulation even with wall panel installed? I

No, when installed the door panel queries the GDO for status of door/lights/lock/obstruction. The emulation does the same thing, except it's using 0x38 instead of the 0x37 for door status. They cannot query at the same time. We're trying to insert 0x38 query when we detect 0x37 queries, but it seems to work only for some GDOs.

Alternatively, if I can manually add my tilt sensor to the esphome (rather than creating a custom Cover) would be good

This is a feature that will be added in the near-ish future.

[smarthomeaf]

@mariusmuja thank you so much for your help here. I will use a custom cover in the meantime to work around the issues.

[4rsfed]

Log file attached here

I can't find any door interaction in this log. Can you capture another log where you open/close the door? and update to the latest, I added a bit of extra logging.

With a week of use on this, and no issues. What is required to remove/minimize the logging for SEC 1 openers? I'd like to add 2 more to my other garage doors, just don't want the logs writing so much. (probably doesn't matter, but I'd like to have it a clean output like the SEC 2 ESP devices)

[mariusmuja]

Logging has been reduced when it was merged to main. You can install the main branch and it should have less logging.

[4rsfed]

Logging has been reduced when it was merged to main. You can install the main branch and it should have less logging.

Awesome, I missed it was merged to main. Will upgrade to that now. Thank you!