make address of main entrance configurable

[matejbart]

Description

I have stumbled upon an issue where the one and only outdoor station has changed its default address from 0 to 1, and as a consequence the corresponding entities that are triggered when someone makes a door call stopped working.

Would it be an option to make the address of the first outdoor station configurable as well?

The issue has obviously happened when I tried to simulate a door call from the outdoor to my indoor unit. I guess that the outdoor unit has recognized that issue and simply incremented its address to avoid collisions. Fortunately this didn't break anything serious except that any indoor stations that were unaware of this address change could not initiate a voice call to the AS. But, this is fixed as soon as the outdoor station makes a door call to the indoor station, as its obviously storing the last known address of the outdoor station. (This behavior is also consistent for those which use multiple outdoor stations as e.g. in #24).

Logs

No response

Which version of the ESPHome Doorman firmware config are you running?

2024.11.1

How do you manage your Doorman's updates?

ESPHome YAML Config

If you're using an ESPHome YAML config, which version of ESPHome are you running?

2024.11.1

ESPHome Config

No response

[AzonInc]

I have stumbled upon an issue where the one and only outdoor station has changed its default address from 0 to 1, and as a consequence the corresponding entities that are triggered when someone makes a door call stopped working.

I experienced this behaviour as well while using the control function button of the indoor station to toggle the ring to open automation.
I think this control function (8) is messing everything up.

Would it be an option to make the address of the first outdoor station configurable as well?

While it's no problem to implement this, it probably won't solve the issue of changing addresses.

The issue has obviously happened when I tried to simulate a door call from the outdoor to my indoor unit.

This always messes everything up and you can't talk anymore until somebody rings at the entrance but you could use a floor call instead which works without messing around with the outdoor station.

There is one easy way to fix the address change: restart the control unit. There is a command for this which I use to prevent going downstairs to fix an issue.

[matejbart]

While it's no problem to implement this, it probably won't solve the issue of changing addresses.

That's true. I mean the address is mostly only relevant if there are multiple outdoor stations, so we could also try to mimic an indoor stations behavior to keep and always update the last known outdoor station's address. And for someone who uses multiple outdoor stations, I think there is no other option than to update this manually :-/

I think this control function (8) is messing everything up.

Hm, interesting, I could not observe that behavior, this would also mean that if somebody presses that button, it would change the address of the outdoor station?

There is one easy way to fix the address change: restart the control unit. There is a command for this which I use to prevent going downstairs to fix an issue.

Could you tell which command this is? (Still, I guess I would keep this as-is, since the indoor stations will adapt once they're called out as you have described).

[AzonInc]

That's true. I mean the address is mostly only relevant if there are multiple outdoor stations, so we could also try to mimic an indoor stations behavior to keep and always update the last known outdoor station's address. And for someone who uses multiple outdoor stations, I think there is no other option than to update this manually :-/

That would mess up the setup process tho as the outdoor station with an address != 0 is saved as second outoor station whenever the first command arrives which has another address.

Hm, interesting, I could not observe that behavior, this would also mean that if somebody presses that button, it would change the address of the outdoor station?

Yeah and not only that, here it also changes the format of the command to use the serial number and not only 1100 anymore (for every indoor station).

Could you tell which command this is? (Still, I guess I would keep this as-is, since the indoor stations will adapt once they're called out as you have described).

This should do it:

button:
  - platform: template
    name: "Reboot Control Unit"
    on_press:
      - tc_bus.send:
          type: reset

[AzonInc]

Also an update here about the TCS call:
They are not familiar with outdoor stations changing it's address yet. So seems like we do something different.
The control function shouldn't cause such behavior even tho it does in our case.

[matejbart]

I have been digging a little bit into the manual of the TCSK-01 service device as there is some interesting information about the protocol.

It states that the address a.k.a AK-Absenderadresse of the outer station is undefined in its initial state. It can be optionally fixed and locked, but if it's not the case then the outer station(s) will automatically adapt their address. That explains what has happened in my case.

I'd say that in most of the cases, when there is just one outer station, the address will very likely be 0, we could also try to read out the serial numbers and addresses of the outer stations to determine this, but I guess that mentioning this in the doc + allowing to manipulate the address of the "main" outer station should be fine for now.

[AzonInc]

Reading the serial number of the outdoor station doesn't provide the address tho'. But in general it's 0, unless something is changing it.

I will try to add another config entity to allow changing the first stations address.