Sec +1 doesn't give door status

[dbrewer-wdc]

I don't think this is a ratgdo issue but just in case, I'll post. I have a jackshaft opener with the purple button and the wired control panel has motion detection and remote lockout. I have the ratgdo configured as sec+1 and Home Assistant via MQTT.

Everything works except the door status. It is Unknown. From the Serial log, I only get status words for 3 items: 1) 3740 (doesn't seem to ever change change) 2) 3A58 or 3A5C depending on the state of the light. 3) 3900 or 3904 depending on the state of the obstruction detect. 3904 when beam is broken.

I do not see status for the door, 38XX. Is this a known issue?

[dbrewer-wdc]

Poking a bit more on figuring status for this opener. For the "Lock" to disable remotes, that status is in the same 3A Key as the lights. Bit 3 of the value is the lock state. If set, it is unlocked, and if cleared, it is locked. And bit 2 is the light status.

Before the lock status changes, I can see these commands: Unlock to lock: 343A followed by status and then 3553 Lock to unlock: 3453 followed by status and then 353A It does seem a little odd that the right byte, 3A and 53 seem to trade places from lock to unlock.

As for motion, I don't see any specific status...and more importantly, I don't seem to see status for the door.

[PaulWieland]

Hi @dbrewer-wdc no this isn't a known issue. One test you can do is to unhook your OEM wired wall panel and let ratgdo enter emulation mode (you'll have to reboot it after you unhook the wall panel). The wall panel is actually querying the GDO and if it doesn't ask for 0x38, then the door status will never be sent.

Regarding the lock... setting and reading and state are on my todo list!

[dbrewer-wdc]

@PaulWieland that did work and GDO did respond with the correct status with the wall panel removed

I was a bit confused when I STOPped the door via Homeassistant / MQTT command and things got goofed up, but the code looks for the wall panel again with a door code of 6 and went right to "Wall panel detected." Then the status stopped. Not sure how it got a door status of 6 as I don't see it in the log. However, I do know that a byte seems to get dropped from time to time. If it is of any interest, Here is the sequence at the MQTT Stop. I don't think I hit "stop" twice, but the log says the command was sent twice. Sometimes when I turn off the light with Home assistant, I'll get a quick on and off of the light after it has been off for 2-3 seconds.

3852 | door state: 52 1010010 3031 313A 3900 3804 | door state: 4 100 Door state closing QUEUE MSG SENT [/home/geirajratgdo-31185/status/door] closing 3A5C 3900 3804 | door state: 4 100 3A5C 3900 3804 | door state: 4 100 3A5C QUEUE MSG ARRIVED [/home/geirajratgdo-31185/command/door] stop MQTT: stop the door 3900 3031 3138 3A5C 3938 3A39 Light state off QUEUE MSG SENT [/home/geirajratgdo-31185/status/light] off QUEUE MSG ARRIVED [/home/geirajratgdo-31185/command/door] stop MQTT: stop the door 30FF 3131 Door state syncing QUEUE MSG SENT [/home/geirajratgdo-31185/status/door] syncing Wall panel detected. 3900 QUEUE MSG ARRIVED [/home/geirajratgdo-31185/command/door] open MQTT: open the door 3031 31FF QUEUE MSG ARRIVED

[dbrewer-wdc]

@PaulWieland I had an incident where the garage door opened in the middle of the night. Fortunately, I have alerts for that so it wasn't open too long. Unfortunately, there isn't much logged in Homeassistant regarding this. I'm thinking of what may have happened and I think I know where the problem might be. After allowing the ratgdo to go into wall switch emulation, I reconnected the wall switch, so now both are requesting status. I had no problem with this for over 24 hours but because my door opened in the middle of the night it made be wonder if somehow the commands collided and GDO misinterpreted an open command. Is this possible or should I seek another probability. It seems the requests are single bytes and commands are dual bytes? If the wall switch and the ratgdo contended for the bus at the same time, could bytes be intermingled to look like an open request? I think for the time being, I'm going take the ratgdo out of emulation mode and forfeit door status for the time being while I make a new wall switch.

[PaulWieland]

Yeah based on what you are telling me I’m thinking there’s an incompatibility with the current firmware and that specific wall control panel. I’m swamped right now so I haven’t been able to dig into it yet.

[dbrewer-wdc]

@PaulWieland no worries. Although having both the wall switch and the ratgo emulation mode on at the same time would seem to work, I don't have to have it. I think I have have a work around. Right now, my intent is to get rid of the wall switch and just use emulation mode to get the door status, but I would look forward to 2 things to get rid of that panel.

1) Ability to set the lock mode by button press preferably (button 1 door toggle, button 2 light toggle, button 3 lock toggle 2) Fix the issue where door state 6 puts it in Wall switch detected state when no wall switch is present.

If there is a document on setting up the compile environment, I could experiment the changes and give you the results. I'm familiar with Arduino Sketch environment, but not a proper C++ one. Otherwise, take your time and I'll be patient. :)

Thanks.

[mbcomer]

@dbrewer-wdc I have a very similar opener it would seem, and have the same problem. I am happy to work with both you and @PaulWieland to resolve. My C++ is a tiny bit rusty, but not too bad. Following, and I may dig into the code some as well.

[gshepperd]

Having the same issue with my Liftmaster 3800PLD Jackshaft with the purple button. Everything works except door status. Here is what I am seeing in the log:

the network...
TOPIC SUBSCRIBED [twocarsidetwocarside/command/#] 
QUEUE MSG SENT [homeassistant/cover/twocarside/config] 
{
  "~": "twocarsidetwocarside",
  "name": "Door",
  "unique_id": "twocarside_BC:FF:4D:86:AB:5D",
  "availability_topic": "~/status/availability",
  "device_class": "garage",
  "command_topic": "~/command/door",
  "payload_open": "open",
  "payload_close": "close",
  "payload_stop": "stop",
  "state_topic": "~/status/door",
  "device": {
    "name": "twocarside",
    "identifiers": "twocarside_BC:FF:4D:86:AB:5D",
    "manufacturer": "Paul Wieland",
    "model": "ratgdo",
    "sw_version": "2.51",
    "configuration_url": "http://10.1.3.153/"
  }
}
QUEUE MSG SENT [homeassistant/light/twocarside/config] 
{
  "~": "twocarsidetwocarside",
  "name": "Light",
  "unique_id": "twocarside_BC:FF:4D:86:AB:5D_light",
  "availability_topic": "~/status/availability",
  "command_topic": "~/command/light",
  "payload_on": "on",
  "payload_off": "off",
  "state_topic": "~/status/light",
  "device": {
    "name": "twocarside",
    "identifiers": "twocarside_BC:FF:4D:86:AB:5D",
    "manufacturer": "Paul Wieland",
    "model": "ratgdo",
    "sw_version": "2.51",
    "configuration_url": "http://10.1.3.153/"
  }
}
QUEUE MSG SENT [homeassistant/binary_sensor/twocarside/config] 
{
  "~": "twocarsidetwocarside",
  "name": "Obstruction",
  "unique_id": "twocarside_BC:FF:4D:86:AB:5D_obs",
  "availability_topic": "~/status/availability",
  "device_class": "motion",
  "state_topic": "~/status/obstruction",
  "payload_on": "obstructed",
  "payload_off": "clear",
  "device": {
    "name": "twocarside",
    "identifiers": "twocarside_BC:FF:4D:86:AB:5D",
    "manufacturer": "Paul Wieland",
    "model": "ratgdo",
    "sw_version": "2.51",
    "configuration_url": "http://10.1.3.153/"
  }
}
QUEUE MSG SENT [twocarsidetwocarside/status/availability] 
online
3900 Looking for security+ 1.0 wall panel...
3740 Obstruction status clear
QUEUE MSG SENT [twocarsidetwocarside/status/obstruction] 
clear
3A5C Light state on
QUEUE MSG SENT [twocarsidetwocarside/status/light] 
on
Wall panel detected.
3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 QUEUE MSG ARRIVED [twocarsidetwocarside/command/door] 
close
MQTT: close the door```

At this point, the door is closed and the door status in HA is still unavailable. If I use the wall button to open/close, nothing shows up in the serial console.

[gshepperd]

Here are some more logs if helpful. I intentionally obstructed the door, turned the light off and on a couple times, then opened/closed the door. All from within HA:

3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 Obstruction status obstructed
QUEUE MSG SENT [twocarsidetwocarside/status/obstruction] 
obstructed
3A5C 3904 Obstruction status clear
QUEUE MSG SENT [twocarsidetwocarside/status/obstruction] 
clear
3740 3A5C 3904 3740 3A5C 3904 3740 3A5C 3904 3740 3A5C 3904 3740 3A5C 3904 3740 3A5C 3904 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 QUEUE MSG ARRIVED [twocarsidetwocarside/command/light] 
off
MQTT: turn the light off
323F 3A58 Light state off
QUEUE MSG SENT [twocarsidetwocarside/status/light] 
off
3900 3740 3A58 3900 3740 3A58 3900 QUEUE MSG ARRIVED [twocarsidetwocarside/command/light] 
on
MQTT: turn the light on
323F 3740 3A5C Light state on
QUEUE MSG SENT [twocarsidetwocarside/status/light] 
on
3900 3740 3A5C QUEUE MSG ARRIVED [twocarsidetwocarside/command/light] 
off
MQTT: turn the light off
323F 3900 3740 3A58 Light state off
QUEUE MSG SENT [twocarsidetwocarside/status/light] 
off
3900 QUEUE MSG ARRIVED [twocarsidetwocarside/command/door] 
open
MQTT: open the door
3730 313F 3A5C Light state on
QUEUE MSG SENT [twocarsidetwocarside/status/light] 
on
3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 3740 3A5C 3900 QUEUE MSG ARRIVED [twocarsidetwocarside/command/door] 
close
MQTT: close the door

[PaulWieland]

That is helpful. I hard coded 0x38 as the door state but it seems like some wall panels use 0x37. Obviously there are a set of bits there that I should be watching for and not the whole byte

I’ll get it figured out as soon as I get a chance.

[gshepperd]

Thanks!

[dbrewer-wdc]

I don't think I've ever seen the x3740 change. It is always the same. x38 is the door status, but the problem is likely that the wall switch doesn't need door status so it doesn't ask for it. I've been working on this for a week now and here are a few things I picked up. -x39 is the obstruction status. x3904 is obstruction detected. x3901 is obstruction detected for about 10 seconds. This status is not as quick as with the obstruction sensors directly tied to the RatGDO, but it does the job. Saves an IO and wiring. I may try and remove my wall switch and just have RatGDO run emulation mode instead...in which case, I'd remove the wall switch and put the RatGDO in its place...with the two wire connection. Obstruction detection from the GDO works great. -x3A is both light and Lock detection. The 'C' in x3A5C says that the remotes are not locked out (bit 3) and bit 2 is the light status. This is also working 100% of the time. -x34 x35 are the commands to be sent to the GDO to toggle the lock. I made a mod to the code and put a timer on the detection between x34 and x35 from the wall switch and the time I got was bigger than I expected. I got between 2 seconds and 1.5 seconds. I tried this in the firmware and it didn't work. So I made the delay variable and found that around 300ms seems to work better. There must be some latency in pulling the time and storing it or something. Not sure. Anyway, it only worked some of the time. I changed the command to be like that for the door toggle and it worked better, but still, not all of the time. Once I tried a delay of 0 and the garage door opened. Sometimes when I issue the lock toggle command, the wall switch starts to scroll "LEAR" and then stops. I think it is thinking the GDO is indicating learning mode. I'm not too worried about this one, but it would be great to get it figured out. I have a logic analyzer I might try hanging on the wire to see if I can get some better details. -There is another sequence of commands that the log doesn't show, 00 53 21. Those are in the filtered range and are not displayed.

BR

[dbrewer-wdc]

A logic analyzer adds a lot of perspective. With this Jackshaft opener with the purple learn button (don't recall the model), the sequence is generally the same: command/status delay command/status delay etc. Typically, on the serial port, I'd see this: 3700 3A58 3900 repeated. (varies depending on status)

However, it is a little misleading. My logic analyzer trace shows: 5321 3A58 3900 37-- 4000. Where -- means no status. I'm assuming that the wall switch puts out the the first byte and the GDO puts out the second. So 37 is a request the GDO doesn't respond to?

Anyway, the time from command to command is about 262ms, and it is very consistent. The time between the command and the status is very short...about a bit width.

I was curious to see what the command sequence for door toggle would look like and it was something like this: 32 delay(standard 262ms) 33 delay(524ms to 1050ms) 30 delay(262ms to 524ms) 31. So it looks like the first thing it does is turn the light on. Not sure what the 33 is for, but then we see the 30 / 31 combo that is in the ratgdo code. The sequence is the same when the door is being closed or opened.

But what I found more interesting is a new status for the 40 command that we don't see in the serial output. When the door is moving, I get 40 80. For the entire time it is moving. Unfortunately, there is no door status of open or closed, but at least it is something. I've uploaded a screen grab of the analyzer output.

I did go back and measure more accurately the timing for the Lock toggle, and the original time a measure with modified code is pretty accurate. I measure 2 samples of 1.82 and 2.08 seconds.

For another day, I'm going to see what happens when the Ratgdo sends a door toggle command. I did send a light command and the whole sequence gets out of step. I know the door toggle command looks for the bus to quiesce before getting on the bus whereas the light command does not.

BR

[PaulWieland]

What model wall panel do you have?

Unhook it and restart ratgdo so it goes into emulation mode. What happens then?

[dbrewer-wdc]

@PaulWieland, I've done that already and it does work in emulation mode. I did the experiment above to see if I could find the secret for a reliable lock / unlock sequence as it seems to be unreliable so far.

I haven't worked on it in a few days. I was hoping that using the sequence that you use on the door would work for the lock/unlock, but it still isn't as reliable as I'd want it to be. But as I mentioned, the 37 appears to be a command the GDO doesn't respond to as there is no status after it. Other than that, the output sequence of an idle door looks like:

5321 3A5C 3900 37-- 4000 repeat

BR

[BeebleZap]

I have the same issue, with the same panel model.

[p-jean]

The gdoStateLoop() alternates between looking for a query (like 0x37, 0x38, 0x39, 0x3a..) and looking for the response to a query. If the response is missing, such as the case of 0x37 mentioned above, then it can be handled nicely by adding a response-timeout.

Specifically, if RATGDO does not see a response to a query within about 30ms then it could give up on the response and start looking for a new query.

Currently, I believe that RATGDO never gives up on getting a response and it misinterprets whatever is seen next as a response, even if it come much later.

[PaulWieland]

If you have a wall panel that uses serial communication and the request packet is 0x37 instead of 0x38, you have two options:

1. Use dry contact control protocol and reed switches to detect door state
2. change wall panels. A simple door bell button will work, with ratgdo emulation, or you need a myq panel (e.g. 889lm).