error 4 after disconnection

[ljames8]

Hi there, I'm exploring what you guys did with this reverse engineering, it's really great, thank you.
I managed to communicate with my Supramatic E3, and I am now able to open/close my garage door thanks to you.
For now, I followed https://github.com/raintonr/hormann-hcp to connect from my laptop.

However, whenever I close the serial port, or disconnect the RJ12 cable, my radio controller stops working and the drive displays error 4 ("Stop UAP pressed" from the manual).
I see there is a reference to this issue which you already answered to. @stephan192 do you know a way to gracefully disconnect the emulated UAP1 device to avoid this error ?
Additional info: after the error 4 shows up, if I reopen the serial port, the radio controller works again.

[stephan192]

Hi @ljames8, like i already mentioned in the referenced issue i think there is no gracefull way to disconnect. Once you have connected you must stay connected (and respond with messages) forever. Only option i know: Perform a factory reset.

This for example is one of the reasons i've design my own PCB. I would never ever use a PC based solution, for something like this.

[ljames8]

Hi, thanks for the quick reply!

TL;DR: I think I found a workaround: simply changing UAP1_TYPE to a low value ( tested only with 0x02 and 0x03) seems to allow the communication errors to be discarded by the master.

Details
With UAP1 type 0x14 I confirm there seems to be no way around either a factory reset or starting to respond again to slave status requests in order to keep the radio controllers working normally.

However for fun I just tried and analyzed the replies the master sends while incrementing UAP1_TYPE from 0x00and on. For this, I setup my client to answer only to slave scan queries, not status requests.
It looks like that:

• from 0x04 until at least 0x2b types, the behavior is the same as the default 0x14one.
• But from 0x00 to 0x03 the master sends 6 consecutive requests, then pause until next slave scan if no reply, then start again with 6 requests.

I quickly tested 0x02 and 0x03 types and successfully managed to operate the door from both my client and the radio control, despite my client not replying to status requests or being connected at all.

I'll try to confirm everything works as expected and is stable enough, but if so, it may be safer to change the emulated slave device UAP1_TYPE as I did

[Semiranis]

Did you try other address numbers?

According to Hormann patents, addresses 16-45 are for devices (actuators, safety elements, etc.), so it may be safety reason to stop the operation of whole system (if one element is not working, it's usually better to stop everything, than risk some serious injury or equipment/property damage).

I think you could try address 144 (diagnostic device), or something between 129-143 (for control devices). The patent is not clear, because in other place it tells that after 144 it jumps to 142 (omits 143).

Edit: It may not be that simple. A device with highest number (higher than 128) will take over the "master" function. This probably won't be a problem for me, because I have a simple garage door with one drive and no additional safety features, and the remote opening is controlled by a contactor from the entrance gate manufacturer, so in my case taking over full control will be quite simple. But if someone has a more complex system, or uses Hormann remote controls, it possibly can be much harder.

Your solution may also introduce some complications. So far, I have only found 2 codes in the patents. Code 1 means edge safety device (SKS), code 2 means light barrier (LS). It is strange that the lack of a safety device (code 2) did not stop the entire system. Another possibility is that there is an error in the patent and it may be about addresses, not type codes (addresses 1-15 are reserved).