ratgdo / esphome-ratgdo

ratgdo for ESPHome
GNU General Public License v2.0
344 stars 102 forks source link

Door close command does not work all others do #146

Closed alrassia closed 2 months ago

alrassia commented 9 months ago

I have a chamberlain ML700EV with 8 terminals and a ratgdo 2.5i with latest esp software. My setup features no wall buttons and i previously only used the radio remotes. Type TX2REV with only one button for open and close. image

I got the ratgdo to work with the wiring setup for the 14 terminal setup (use green 0 iso of red terminal for the serial line).

The status is read correctly and commands work, except the close command. Open, stop, toggle,light work ok. Just close results in no action.

Any clues what is going on here or what might be the cause? Could it maybe use a different close command byte than other models? Any logs i could run to help provide more insight?

PaulWieland commented 9 months ago

Capture the serial log so we can see what’s happening.

alrassia commented 9 months ago

I hope this covers the requested logs (VERY_VERBOSE log level), otherwise please let me know what else to do.

logs_ratgdov25i-f614ca_logs.txt

mariusmuja commented 9 months ago

I don't see anything unusual in the logs, other than the fact that your GDO seems to be completely ignoring the close command.

We might need to add a "quirks" feature flag or something like that for cases like this... such as USE_TOGGLE_FOR_CLOSE in this particular case.

P.S. If you feel like experimenting you can see if maybe there's another value for DOOR_CLOSE that works for your GDO. You'll need to change the constant here https://github.com/ratgdo/esphome-ratgdo/blob/main/components/ratgdo/ratgdo.h#L52 and recompile/re-flash to test.

mulcmu commented 8 months ago

To experiment quicker you can add this to your yaml under api: and then call the service from HA developer tools.

  services:
  - service: service_send_door_command
      variables:
        door_data: int
      then:
        - lambda: !lambda |-
            if(door_data >= 0) {
              id($id_prefix).door_command(door_data);  

I tried 0x4 to 0xF and 0xFF on my gdo with door open. No response

alrassia commented 8 months ago

Thx I will try to give

To experiment quicker you can add this to your yaml under api: and then call the service from HA developer tools.

  services:
  - service: service_send_door_command
      variables:
        door_data: int
      then:
        - lambda: !lambda |-
            if(door_data >= 0) {
              id($id_prefix).door_command(door_data);  

I tried 0x4 to 0xF and 0xFF on my gdo with door open. No response

I tried to copy in the quoted text but get mapping values are not allowed in this context in "", line 13, column 16. Line 13 being the line starting with - lambda.

My yaml looks like:

substitutions:
  name: ratgdov25i-f614ca
  friendly_name: ratgdov2.5i f614ca
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v25iboard.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  services:
  - service: service_send_door_command
      variables:
        door_data: int
      then:
        - lambda: !lambda |-
            if(door_data >= 0) {
              id($id_prefix).door_command(door_data);

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password 
alrassia commented 8 months ago

Never mind figured it out, some reformatting and a missing bracket and got it to work

alrassia commented 8 months ago

I tried 0x4 to 0xf no response, it seems the command is one byte only though as with a second byte the behaviour is the same as with a single one. (0x$1-3 behave like expected, 0 does nothing as expected).

i don't have obstruction sensors on the door itself, it detects obstruction through resistance though. Could that be a reason it does not respond to a close command?

mulcmu commented 8 months ago

i don't have obstruction sensors on the door itself, it detects obstruction through resistance though. Could that be a reason it does not respond to a close command?

...sounds plausible, but I would have thought the gdo response should be the same to the TX2REV button presses to close. Do you have the obstruction sensors still to test if ratgdo will close the door when they are hooked back up? Alternatively, do you have a factory wall control to hook up to see if it closes the door?

It appears that the wall controls have a press and hold feature to close door in event of obstruction sensor malfunction. I'll take a look at my setup and see what commands the wall control sends to make this happen.

alrassia commented 8 months ago

I tested a bit more:

When a command is received by the door an orange led blinks, so all commands are received.

with the close command when the door is idle (flood light in opener turned itself off) sending the close command does turn on the floodlight but the door does not act. For other incorrect commands this does not happen. This makes it seem there is some sort of interlock at work, that prevent the door from closing.

i have a loose button supplied with the door, however this is a single button device which probably acts like a toggle switch. I will test though but dont expect much.

my door did not come with the obstruction sensors, are they simulateable in some way?

alrassia commented 8 months ago

I noticed that the door also signals obstruction on on the webpage (state obstruction in ha). Is that normal?

alrassia commented 8 months ago

So i did some digging, for the opener i have the ml800ev. To use myq you need an external gateway type 830REV, this comes together with a mandatory obstruction sensor type 771REV.

So that probably explains it why the door wont close by command, it needs the obstruction sensors to function.

tmjo commented 8 months ago

Hi! First of all, a million thanks to @PaulWieland for making this. Just got my RatGDO hardware a couple of days ago, installed it and had it running perfectly in no-time with the ESPHome port of the software. Really awesome, and just the way I would like things to be!!

I came over this issue and wanted to chime in and say I observe the same behavior as you @alrassia. My opener is a Liftmaster LM100EVS produced in 2016. I had to use the leftmost terminal 0 (green) for my "red" wire too, and everything seems to work well except I am not allowed to close the door. Opening works fine, light is ok, and all statuses as far as I've been able to see. I also see that it reports an obstruction every time the door is open, so I assume that's causing a close block.

I do not have any obstruction sensors, so I cannot connect any. Manual says it is internally protected so I assume it is some kind of torque or force limitation that will stop the door in case it hits something. First thought that came to my mind was if it could be possible to connect a "fake sensor" so that there is never any obstruction observed. Do you guys know what kind of sensor it is? Read somewhere that it may be a resistor bridge with specific ohmic values, but not sure where I got that info. Or is it just a plain dry contact?

Originally I have four wireless remotes, two small one that lives in the cars and two wall mounted. They continue to work fine together with the RatGDO, and they do allow closing the door also after the RatGDO installation. So I'm not quite sure why the opener is ok with closing, just not from RatGDO. Perhaps it is possible to adapt software somehow to work around this?

Anyway, I will be following the topic. Kindly let me know if I can provide further test/info to support the work.

My connections and opener model:

image

damaar666 commented 8 months ago

I noticed that the door also signals obstruction on on the webpage (state obstruction in ha). Is that normal?

I have a similar door (different model but same terminals), and have the same issue with door close not working. I initially had mine wired the same as yours (I presume looking at the terminals in the picture, and had an obstruction warning. I removed the terminal from BLK OBST to terminal 3 (grey) and it went away. All other functions appeared to work with no issues (albeit still couldn't close without using the door toggle. I am not sure if the obstruction is the cause of the issue, as I cleared mine and I still can't close.

I can do some testing also if needed.

Mine is a different model, but similar looking. https://motepro.com.au/Manuals/Chamberlain/Sectional/SectionalLift_Plus_CS105MYQ.pdf

jacobpoder commented 7 months ago

I had the same issue with model LM130EVS and ratgdo. All functions worked except close. I can confirm that after connecting Failsafe infrared safety sensor kit (771EV), close function works fine also!

tonyma commented 7 months ago

I am having the same issues, couldn't close without using toggle: image I disconnected the black wire but the close still doesn't work. Let me know if any test I can do to help.

Rossaluss commented 7 months ago

I was having the exact same problem, with the exact same model (ML700EV).

I did some testing and bought the cheapest pair of sensors I could find, connected them in, and the ratgdo is now capable of both opening and closing. So it looks like the ratgdo is incompatible with the base model of this GDO (unable to bypass the lack of sensor, which the GDO itself can do with the wall buttons/remotes).

May be that the ratgdo team just needs to update something in the code to allow the bypass? Not sure.

damaar666 commented 7 months ago

I was having the exact same problem, with the exact same model (ML700EV).

I did some testing and bought the cheapest pair of sensors I could find, connected them in, and the ratgdo is now capable of both opening and closing. So it looks like the ratgdo is incompatible with the base model of this GDO (unable to bypass the lack of sensor, which the GDO itself can do with the wall buttons/remotes).

May be that the ratgdo team just needs to update something in the code to allow the bypass? Not sure.

What sensor did you find? In New Zealand, you can only buy the senors with the MyQ WiFi module, and even in Australia sensors seem quite expensive. If there is a good option to provide the right signal, that could be a good option as a workaround for now.

Rossaluss commented 7 months ago

What sensor did you find? In New Zealand, you can only buy the senors with the MyQ WiFi module, and even in Australia sensors seem quite expensive. If there is a good option to provide the right signal, that could be a good option as a workaround for now.

Just these ones from Amazon - https://www.amazon.co.uk/dp/B0BC12JRNM

jacobpoder commented 7 months ago

If you don't need/want the sensors, a resistor can possible be used instead. When I get home, I can measure the voltage across the two terminals with and without the sensors connected and also the current drawn. With that information, we should be able to find a resistor to put in-between the terminals to fake the actual sensors...

Rossaluss commented 7 months ago

If you don't need/want the sensors, a resistor can possible be used instead. When I get home, I can measure the voltage across the two terminals with and without the sensors connected and also the current drawn. With that information, we should be able to find a resistor to put in-between the terminals to fake the actual sensors...

I was reading about this, and I don't believe that will work, as apparently the GDO is expecting some sort of pulsing input that the sensors output, rather than a standard voltage reading. Though do let us know if you do have any luck!

tonyma commented 7 months ago

Would it be easier to fix the firmware other than adding the fake sensor?

jacobpoder commented 7 months ago

Would it be easier to fix the firmware other than adding the fake sensor?

This seems to be a security feature built into the GDO, so unless it can be overridden by a command on the serial interface, it can't be "fixed" in the firmware.

jacobpoder commented 7 months ago

If you don't need/want the sensors, a resistor can possible be used instead. When I get home, I can measure the voltage across the two terminals with and without the sensors connected and also the current drawn. With that information, we should be able to find a resistor to put in-between the terminals to fake the actual sensors...

I was reading about this, and I don't believe that will work, as apparently the GDO is expecting some sort of pulsing input that the sensors output, rather than a standard voltage reading. Though do let us know if you do have any luck!

I may be wrong, but I only recall seeing the pulsing signal when the sensors were obstructed, which is not the state we want to emulate. I'll check later...

PaulWieland commented 7 months ago

If you have a ROW opener with an eserial terminal AND all of the following are true:

Then please give this comment a thumbs up.

If you are experiencing a different issue, please leave a reply explaining what is different from the above.

jacobpoder commented 7 months ago

I measured the voltage between sensor terminals to 6.6 VDC without sensors connected and 5.2 VDC with sensors. The current drain was 32 mAh. 6.6/.032 - (6.6-5.2)/0.032 = 162,5 Ohms Tested with a 150 Ohm resistor, which resulted in 4.98 VDC across the terminals - didn't work! I will see if I can find a resistor to get closer to the 5.2 V target and test again...

mariusmuja commented 7 months ago

@jacobpoder

A resistor is not going to work. The GDO provides a voltage on the line and the sensors clamp the line to ground at at certain frequency for a certain duration (I can't remember the values, would have to put the oscilloscope on the wire again to look). Anyway, that's why you measure a lower voltage with the sensors on, but it's not a DC voltage, it's a square signal.

You could emulate it with a microcontroller and a transitor to clamp the line to ground for x ms every y ms.

jacobpoder commented 7 months ago

@mariusmuja Sounds like the PWM used to detect faulty bulbs in my car... IIRC my multimeter does have a mode to detect duty cycle, so I guess I can try that...

mariusmuja commented 7 months ago

You could emulate it with a microcontroller and a transitor to clamp the line to ground for x ms every y ms.

About 0.4ms every 6.9ms on my GDO:

obstruction_sensors

danps1 commented 7 months ago

Hi - I have this exact same issue, also have no sensors, and with the black wire disconnect, close command doesn't work.

If needed, my logs are at https://github.com/ratgdo/esphome-ratgdo/issues/213

Also, happy to provide any additional logging if it will help?

Is there an interim solution, where the "toggle" command could be sent in place of "close"?

Thnx

bobbyschuitemaker commented 7 months ago

I have a chamberlain ML700EV with 8 terminals and a ratgdo 2.5i with latest esp software. My setup features no wall buttons and i previously only used the radio remotes. Type TX2REV with only one button for open and close. image

I got the ratgdo to work with the wiring setup for the 14 terminal setup (use green 0 iso of red terminal for the serial line).

The status is read correctly and commands work, except the close command. Open, stop, toggle,light work ok. Just close results in no action.

Any clues what is going on here or what might be the cause? Could it maybe use a different close command byte than other models? Any logs i could run to help provide more insight?

Exact same issue here

damaar666 commented 7 months ago

I forgot to mention earlier - that due to the issues with the esphome firmware, I have been running the MQTT version. MQTT appears to work with cover.close in home assistant. Unsure if the command "close" actually uses toggle internally or not, but sending the cover.close command from home assistant does close the garage door via MQTT. Unsure if that means that the GDO is receiving a close command correctly or not, as MQTT may be received and simply toggle.

May not be useful information but in case, I thought I would comment.

mvannas commented 7 months ago

I have almost the same problem, but with a strange twist. IF i connect the black wire then my problem is exactly like the one described earlier, aka. everything else works except "CLOSE". If I disconnect the black wire as is instructed (I don't have obstruction sensors) also OPEN function stops working! However "TOGGLE" still works.

mvannas commented 7 months ago

As for the people trying to emulate obstruction sensor, it is surprisingly difficult, I tried with manually adjustable electronics circuit without success.

With a microchip controlled oscillation it works... for a time. It seems I have a bug in control software and it eventually somehow goes off sync because it stops working. I haven't continued with this as it seems to be really difficult to emulate the obstruction sensors and was hoping for an easier and more reliable solution with ratgdo :)

PaulWieland commented 7 months ago

I forgot to mention earlier - that due to the issues with the esphome firmware, I have been running the MQTT version. MQTT appears to work with cover.close in home assistant.

That's because the mqtt version only uses toggle commands.

If you click close, and the door is already closed, the mqtt firmware won't send any wireline command at all (and vice versa with open).

The ESPHome version sends a discrete close command (the GDO can decide if it should ignore it depending on the physical state). The problem here is that ROW openers which have optional obstruction sensors (they are mandatory in NA) ignore the explicit close command if no sensor is connected. They respond to toggle commands though, which are sent by the wall control panels which have a single button control.

damaar666 commented 7 months ago

I forgot to mention earlier - that due to the issues with the esphome firmware, I have been running the MQTT version. MQTT appears to work with cover.close in home assistant.

That's because the mqtt version only uses toggle commands.

If you click close, and the door is already closed, the mqtt firmware won't send any wireline command at all (and vice versa with open).

The ESPHome version sends a discrete close command (the GDO can decide if it should ignore it depending on the physical state). The problem here is that ROW openers which have optional obstruction sensors (they are mandatory in NA) ignore the explicit close command if no sensor is connected. They respond to toggle commands though, which are sent by the wall control panels which have a single button control.

I thought that may be the case. Interestingly chamberlain make a point of saying the obstruction sensor is optional in nz, and it has an obstruction reverse feature built in if the GDO senses an obstruction. It is really effective.

@PaulWieland Is it likely to work around it in firmware? I am holding off getting the obstruction sensor, but if you think it is a while odd or very hard to do/a compromise functionality wise, I will order them in from the US. Ones available in nz are super expensive. :)

Thanks I advance!

mariusmuja commented 7 months ago

The advantage of using a close command vs a toggle command is that the result is a closed door even if ratgdo has the incorrect door state. The disadvantage is that some (all?) GDOs ignore it if no obstruction sensors are connected.

We could add a feature flag allowing the user to select the behaviour they want.

mvannas commented 7 months ago

Is the ratgdo hardware capable of controlling the 6v output of the obstruction pin-out, or is it just passthrough? I noticed that there is a loop function to check the high-low transformation on the obstruction signal which could possibly be also used to emulate the high-low transition every 6.5 ms?

damaar666 commented 7 months ago

Hi all, thought I would provide a quick update. I have bought and installed some sensors (many thanks @Rossaluss for the recommendation). Now they are installed and everything works reasonably well with the esphome ratgdo firmware and ROW garage door opener.

I did notice one thing: When I close the door (through the close command) on either Home Assistant with cover.close or through the web interface on the device, the light flashes 4 times (roughly 4 seconds) then starts to close. There is no obstruction or issue. It appears that the firmware counts this as it's close time so a door close command is about 4-5seconds longer than it really is. that means if I try to set the door to say, 50%, it doesn't go too far down as it includes the first 4 seconds or so of flashing light. Looking at the logs, it appears to start closing at around 70-65% closed according to the learnt time.

Is that expected behavior? I didn't see anything obvious in the manual. Will do some further investigation.

Thanks all for the support. I am glad I have it working now, shame the obstruction sensors were needed, however I will look to mount them properly to get the use out of them, currently just looking at each other on the roof to get things going.

(side note: If anyone buys the Amazon linked ones above, you need to reverse the wires based on the instructions. instructions are terrible and the wires are not very long, so you will need to buy additional connecting wiring. Mounting kit seems good too. Pretty happy considering the cheap price)

PaulWieland commented 7 months ago

the light flashes 4 times (roughly 4 seconds) then starts to close

This is probably a warning the GDO is issuing to occupants that the door has been commanded to close.

Nevets77x commented 6 months ago

Hello, read through this thread as I'm having a similar issue where everything BUT close works. The slight variation to my situation is a I can use the door OPEN command it will close the door. I'm using MQTT and this seems to be working as a toggle.

I'm also quite certain this used to work normally as I have an automation setup the automatically close my GDO after 15 minutes.

TesLocker commented 6 months ago

Never mind figured it out, some reformatting and a missing bracket and got it to work

Could you please share your revised yaml? I'm getting the same error as you were and am not able to figure it out.

Edit:

I updated to the below YAML, and now it tries to compile, but I get the following error:

Screenshot 2024-03-03 at 9 02 04 PM
substitutions:
  name: ratgdov25i-19376d
  friendly_name: ratgdov2.5i 19376d
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v25iboard.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  services:
    - service: service_send_door_command
      variables:
        door_data: int
      then:
        - lambda: !lambda |-
            if(door_data >= 0) {
              id($id_prefix).door_command(door_data);
            }
  encryption:
    key: <<<<REDACTED>>>>

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
Stuart5851 commented 4 months ago

I've bought some cheap obstruction sensors but struggling to get them wired correctly. 2 wires from each, white/black and white. What terminals would you connect these to? Assuming the black wire stays in terminal 3?

rlowens commented 4 months ago

What terminals do you have? What model GDO? What does it look like?

This might work for your GDO https://support.chamberlaingroup.com/s/article/How-to-wire-safety-sensors-to-a-garage-door-opener-1484145658420#:~:text=Twist%20together%20the%20two%20white,gray%20on%20the%20motor%20unit.

  1. Strip 7/16-inch of insulation from each of the two wires on each sensor—each sensor has two wires, a solid white one and one white with a black stripe, for a total of four wires.
  2. Twist together the two white-with-black-stripe wires from both sensors.
  3. Twist together the two white solid wires from both sensors.
  4. Connect the two white-with-black-stripe wires in the gray terminal on the motor unit.
  5. Connect the two white solid wires in the white terminal next to the gray on the motor unit.
timsuley commented 4 months ago

Experiencing the same issue with the Close button on HA with my Merlin MS65MYQ. No obstruction sensors, and black RATGDO wire is disconnected from the door opener.

Stuart5851 commented 4 months ago

What terminals do you have? What model GDO? What does it look like?

This might work for your GDO https://support.chamberlaingroup.com/s/article/How-to-wire-safety-sensors-to-a-garage-door-opener-1484145658420#:~:text=Twist%20together%20the%20two%20white,gray%20on%20the%20motor%20unit.

  1. Strip 7/16-inch of insulation from each of the two wires on each sensor—each sensor has two wires, a solid white one and one white with a black stripe, for a total of four wires.
  2. Twist together the two white-with-black-stripe wires from both sensors.
  3. Twist together the two white solid wires from both sensors.
  4. Connect the two white-with-black-stripe wires in the gray terminal on the motor unit.
  5. Connect the two white solid wires in the white terminal next to the gray on the motor unit.

Thanks for this, really helpful!

DannyvdSluijs commented 3 months ago

I'm running into the same issue at this point as well.

I'm happy to help debug, try-out or any other means that could help would just need a few pointers on what is needed. I would also believe having the door close command to be configured to use the toggle command (as mentioned by @mariusmuja) would be a good option.

Edit: After sleeping on this I also realised a toggle command would also make more sense as it would allow you to fully control the door using a single button (as also used in HomeAssistant and with the Chamberlain remotes)

mvannas commented 3 months ago

I believe only real solution to this problem would be emulation of obstruction sensor signal (see my suggestion ealier). Using toggle-function is a workaround. It does not work well when you have other remote controls also (meaning that the opening/closing status of the door is unrealiable) or when you want to make sure that the door closes without seeing it (automatic closing). Of course this is the reason it actually doesn't work without obstruction sensors to prevent accidents.

DannyvdSluijs commented 3 months ago

I can see your reasoning but I think the situation can differ from person to person.

Using toggle-function is a workaround. It does not work well when you have other remote controls also (meaning that the opening/closing status of the door is unrealiable) or when you want to make sure that the door closes without seeing it

For me the toggle is actually they way my other remotes work. My Chamberlain remote is using a toggle button (there is no explicit open or close button on the remote). And my HomeAssistant also only offers a single button using the toggle function

Of course this is the reason it actually doesn't work without obstruction sensors to prevent accidents.

Which is logical but not how my specific garage door works. Using RATGDO obviously you can open de door from everywhere in the world. This isn't my use case however, I use RATGDO as an alternative to the physical remotes I dont feel like carrying with me.

As you can see situations can differ and I'm not advocating for changing the defaults, but I think you can make people happy if the product would allow for a config/setting change in either firmware of in the web UI to match their specific needs. Hope this explanation helps in understanding.

chatz86 commented 2 months ago

Hey fellas. Any updates with this? I've been using an automation to query the door status every few seconds but that comes with its own issues...

damaar666 commented 2 months ago

I bought the cheaper obstruction sensors of Amazon a while back. It did fix the closing issue (being blocked and not closing), but I find the ratgdo to be quite poor at opening and closing the garage. I need to investigate more but I consistently get issues with having the right state or responding to open/close events. Unsure why, could be something else but it seems to be very unreliable. So much so I have reinstalled my opengarage controller. I need to investigate more. Unsure if it is related to this model model or not and how it handles open/close service. But overall, has been a bit underwhelming. Will look through other issues and spend more time on it soon(ish).