secplus 1 GDO can be unreliable if power cycled with RATGDO (Issue #18)

[p-jean]

Issue #18 was completed but I don't know the reason, so I have to ask.

The problem was seen in the latest binary (2.54), and there are no code changes in the last 6 days.

The log file clearly shows the RATGDO entering emulation mode while there is a wall-panel present,

[dbrewer-wdc]

@p-jean , I'm not sure exactly what is happening in your case, but I did look at the log and I've got some ideas. 1) in your log file, I see x31 31 over and over. According to some older code that Paul had in the static_code.cpp file, this meant that the GDO and the wall switch were syncing up and it would set the door status to a 6. At the same time, the code in ratgdo.cpp would take a door status of 6 as a reason to come out of emulation mode, or I guess, not go into it. So perhaps with your GDO, it takes longer to sync up and the ratgdo is impatient and goes into emulation mode while the x31 31 is occurring and because of the code change, it doesn't ever leave emulation mode. 2) I have an 8500 as well that doesn't give door status and when I was debugging, I put it in emulation mode and then later connected the wall switch. With the two of them on at the same time, I did have the GDO open in the middle of the night. I think that some amount of serial collisions can occur with the wallswitch AND the ratgdo sending status requests at the same time. And perhaps if they step on eachother at the same time, the GDO gets the wrong message. 3) At the end of your trace/log, things look better, but I wonder if you were to turn on the ratgdo after the gdo and the wall switch have been up for a while, perhaps this would not have an issue. Then the solution might just be to add an optional delay before the ratgdo is enabled. I also know that it does take the ratgdo some time to boot up. I'd think that if the GDO and the ratgdo were to be started at the same time that the GDO would have been synced up with the wall switch well before the ratgdo tries to detect activity on the serial bus.

[p-jean]

@dbrewer-wdc ,thanks for your comment.

1. Agree, except that once in emulation mode, it can never leave. Search for emulateWallPanel = false
2. On my system (8500/888), and similar, having RATGDO go into emulation mode is a recipe for instability because of collisions with the wallpanel. I never need or want emulation mode.
3. If the GDO is running for a while before RATGDO is started then it's fine. If there is a power failure then the system is unstable when the power resumes.

Issue #19 was rejected but it makes sense to me to allow emulation mode to be configured as ON/OFF or AUTO on a per system basis.

My system is not unique and others are starting to see/report this issue. Please see Issue #27

[dbrewer-wdc]

@p-jean , If you look at the wallPanelEmulatorLoop at line 167 in ratgdo.cpp, you'll see where the ratgdo will look for the wallpanel for 35 seconds...or 35000 milliseconds. After that is when it well go to emulateWallPanel = true. In that same line, however, notice the OR doorState == 6. In Paul's previous code for static_code.cpp, which isn't there now, was a check for the x31 31 syncing and it would set door / doorState to 6, which would prevent the emulation mode or even take it out of emulation mode if it were entered. Maybe there was a problem with it in someone else's case and he removed it, but I think that's what would have protected you in your situation when the door and wall panel take longer than expected to sync up.

The unfortunate reality is that there are too many different systems and Paul is probably overwhelmed with issues and requests that it might be some time before he can make a release that doesn't break your setup. If you have some home automation, perhaps you can put the ratgdo on a smart switch that holds power for a few minutes after a power outage. The other option would be to modify the code so that emulation mode is never entered. Personally, I've completely customized the code for my GDO and the changes you would need are not that big; however, it would mean setting up an environment to compile the code and downloading it.

[p-jean]

@dbrewer-wdc, thanks for your comment.

I can and do build my own firmware, but I'd rather not go off on my own, if possible. I raise issues mainly as a form of contribution, plus it makes sense to collaborate to get better solutions.

Finally, the issue of so many different systems to support is a good reason to have features like wall panel emulation configurable. I'm not saying that configuration is the only solution, but it would be quite safe and effective compared to trying to tweak the auto-emulation algorithm again.

[dbrewer-wdc]

I think you'd be safe to make that modification to just eliminate the emulated wall panel. You could do some other things too to keep it looking while x31 is still coming in. I'm sure Paul will eventually get to it, but if you don't want to wait, at least you have the option to modify. And honestly, once you get into it, you may even find more modifications to make.

[gullygossner]

Issue #18 was completed but I don't know the reason, so I have to ask.

The problem was seen in the latest binary (2.54), and there are no code changes in the last 6 days.

The log file clearly shows the RATGDO entering emulation mode while there is a wall-panel present,

Have you tried with firmware version 2.56? I am curious if this has been resolved as it mentions bug fixes in the sec 1 side of things.

[p-jean]

@gullygossner,

I've checked all of the code updates, and I don't see any recent changes that would fix the problem.

The root cause is the RATGDO (with SEC1) getting into a mode where it transmits at the same time as the wall-panel. Multiple simultaneous transmissions eventually cause corruption which is misinterpreted by the GDO as a command, or which scramble the received GDO status.

When there is a wall-panel present that sends queries out regularly, the RATGDO is not meant to make regular transmissions. It should simply listen to the conversation between the wall-panel and the GDO to get status. Some systems do not have a wall-panel that sends regular queries, so RATGDO has an automatic feature to regularly transmit queries.

When the RATGDO starts up it listens for a wall-panel and if none are heard, then it enters wall-panel emulation mode until the next reset. On my system the problem happens when I power both RATGDO and GDO simultaneously (the case of a power-failure).

There are at least a few good ways to fix the problem: 1) Release a separate FW load without wall-panel emulation. Disable wallPanelEmulatorLoop(). 2) Make it possible for the user to turn off wall-panel emulation by web page configuration. 3) Improve the wall-panel detection algorithm so that it always works, for all systems.

I think that option 3 is nice, but hard to get right. Option 1 would be quick to do.

[gullygossner]

@p-jean thank you for the detailed response. I'll have to hold off for the time being then as my opener was afflicted with the issue you mention on more than one occasion.

[PaulWieland]

@p-jean post the log.

If you read the source code, it detects serial communication and only enters emulation mode if there is no digital wall panel present.

If you read the faq, it explains why some wall panels don’t work with secplus 1 protocol and what your options are.

[p-jean]

@p-jean post the log.

If you read the source code, it detects serial communication and only enters emulation mode if there is no digital wall panel present.

If you read the faq, it explains why some wall panels don’t work with secplus 1 protocol and what your options are.

The log is in Issue #18. Please let me know if you can't find it.

At line 131 it says "No wall panel detected. Switching to emulation mode.". I do have a wall-panel (888LM) which sends a -query each 250ms during steady-state. It is entering wall-panel emulation mode by mistake.

[PaulWieland]

The log is from version 2.54. Upgrade to the latest release.

[p-jean]

The wall-panel emulation code has not changed.

[PaulWieland]

The wall-panel emulation code has not changed.

Oh really?

Setup Complete
 _____ _____ _____ _____ ____  _____ 
| __  |  _  |_   _|   __|    \|     |
|    -|     | | | |  |  |  |  |  |  |
|__|__|__|__| |_| |_____|____/|_____|
version 2.56
IMPROVhttp://10.0.1.113S
### MQTT DISCONNECTED ###
Connecting to
MQTT Broker...
MQTT Last Will Params: 
willTopic: test/GlassDoor/status/availability
willPayload: offline
qos: 1
retain: 0
clean session: 1

MQTT CONNECTED

Reading data from
the network...
.....
QUEUE MSG SENT [test/GlassDoor/status/availability] 
online
3131 Door state syncing
QUEUE MSG SENT [test/GlassDoor/status/door] 
syncing
Looking for security+ 1.0 wall panel...
Wall panel detected.
3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 
3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 
3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 
3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 
3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 3131 

...
38B2  | door state: B2 10110010
3A1C Light state on
QUEUE MSG SENT [test/GlassDoor/status/light] 
on
Lock state unlocked
QUEUE MSG SENT [test/GlassDoor/status/lock] 
unlocked
3A1C 3A1C 3901 38B2  | door state: B2 10110010
Door state open
QUEUE MSG SENT [test/GlassDoor/status/door] 
open
3A1C 3901 3A1C 38B2  | door state: B2 10110010
3A1C 3901 3A1C 38B2  | door state: B2 10110010

[p-jean]

Ok, I see it now. Thanks. I believe that you have fixed the issue that I was seeing. Thanks (and you're welcome).