feat(tc_bus_device): distinguish calls to the parallel serial number - #88
feat(tc_bus_device): distinguish calls to the parallel serial number#88autrilla wants to merge 2 commits into
Conversation
|
I think this solution won't handle floor calls to the second indoor station. And for door calls, it won't separate which door was called (not that it matters much in most cases, but in some it could). I think we should consider adding separate sensor entities for a second indoor station, so that door and floor calls to either one can be cleanly separated. The |
|
Hmmm, yeah, separate entities would be cleaner. I'm fine with reworking this PR (or a separate one) to do that. Either way, to make sure I understand... right now, you can't distinguish between the calls either, because parallel calls just don't get recorded, right? |
I think this is correct. The The parallel serial gets written into the memory of your primary indoor station. Doorman doesn't do anything else with it, in particular it doesn't react on telegrams to/from the parallel serial. At least that is how I understood @AzonInc when he explained that feature to me. |
|
We could make use of the parallel serial number as separate entities, but i would prefer that as separate Firmware Variant as ESPHome does not support enabling and disabling entities dynamically. But the thing is: right now we have about 30 different firnware variants, that would double the count and I crease build times and storage usage. Disabling and enabling entities on the fly would be a highly appreciated feature for ESPHome, however that would require esphome API and home assistant changes. And someone that has an idea about a good implementation. About the parallel serial number: If an indoor station has a parallel serial number set, it will ring as well, as soon as the primary device rings. The primary device will not trigger a separate doorbell ring itself. It will just listen for two serial numbers. Some devices support even 3 parallel serial numbers. |
Exactly, and that is why I would rather not use a separate firmware variant for this relatively minor (nevertheless useful) feature. We could hide the respective entities by default, and whoever needs it can unhide it via Home Assistant. |
|
In general it would be even better defining two indoor stations in the firmware. That way you can manage both with all their entities. Mute/unmute/ringtones and whatever else. But for a rather easy addition, we could just add more event types and another binary sensor for now. This would make it possible to distinguish between the two serial numbers while not adding too much overhead and reusing the existing event entity. |
Yes, I think this is the way to go. Even if at first maybe not all features are supported. |
|
Note that in HA you can disable entire devices. For example in this screenshot I disabled the entire indoor station with one click: 
|
|
The issue was more the ESPHome Webserver which is kinda limited. Displaying stuff there and hiding things is not easy. Disabled by default is not shown by default. But everything else is always shown. The issue: there is no enable on demand for the webserver page as it is on home assistant. So for configuration it's a mess the more entities we have. |
Each of the four doorbell pattern listeners repeated the same ~60 line
on_multi_click block, differing only in the binary sensor, the event
entity and the trigger id prefix.
Extract the block into doorbell-pattern.yaml and instantiate it per
listener via !include vars.
No functional change. Verified by rendering the fully merged
configuration before and after the change with
esphome config doorman-s3-quad.ha.standard.local.yaml
and comparing the output: 4039 lines in both cases, identical as a
multiset of lines. The only ordered difference is `level: DEBUG` shifting
one position inside logger.log actions, whose keys codegen reads by name
rather than by position.
Indoor station listeners only ever matched telegrams addressed to the device's own serial number, because the serial was compared against this->serial_number_ directly. Calls addressed to a flat's parallel serial number are handled in the call answering path but never reached the listeners, so an entrance call to a parallel serial flat fired neither the doorbell binary sensor nor the event HA automations key off. Add an optional serial_number filter to the telegram binary sensor, alongside the existing type, address and payload filters. Unset means the device's own serial number, so existing listeners are unaffected. Use it to add a parallel counterpart for each of the three doorbell listeners. Rather than duplicating the event entities, the parallel listeners fire the existing ones with parallel_ prefixed event types, so one event entity still covers both serial numbers. The new entities are hidden while no parallel serial number is set. Verified with esphome config on the ha, homekit and mqtt variants. On device behaviour is untested. Note: a parallel serial number of 1000000 is treated as unset, since that is both the initial value and the clamp target for invalid input, but it is still representable in the 20 bit serial field.
d47bb4a to
ae2cfba
Compare
autrilla
changed the title
|
Thanks for the feedback! Reworked it, marking it a draft until I test this on my own hardware though since it's more complicated than the previous change. Since repeating the patterns in YAML was a bit... repetitive, I've extracted it out in the first commit so it's not as verbose. I've verified the first commit is effectively zero-diff. |
There was a problem hiding this comment.
Great idea to deduplicate that 👍🏼
Wouldnt it be even better to add the event block to the package itself to further consolidate it and make it easier to add per entity?
event:
- id: !extend entrance_doorbell_pattern
event_types:
- "single"
- "double"
- "triple"
- "quadruple"
as we pass the event id already anyway.
There was a problem hiding this comment.
Whats the intention on adding serial number to tc_bus_device?
The general tc_bus binary sensor has the serial number but tc_bus_device was not supposed to have this because its just for the device itself.
I'd rather add a bool to use parallel device and adjust the condition logic to use the parallel serial number when bool true than adding the serial number to the device, as thats already scoped to a specific device.
| sorting_group_id: sorting_group_diagnostics_listeners | ||
| sorting_weight: 210 | ||
|
|
||
| - platform: tc_bus_device |
There was a problem hiding this comment.
You can just use tc_bus instead of tc_bus device here as it has the serial_number
3 participants
Indoor-station listeners only matched calls addressed to the device's own serial, since the telegram serial was compared against
this->serial_number_directly. Calls to a flat's parallel serial are handled in the call-answering path but never reach the listeners, so entrance calls to a parallel-serial flat never fire the Entrance Doorbell — and thus never fire theeventthat HA automations key off.Adds an optional
serial_numberfilter to the telegram binary sensor, alongside the existingtype,addressandpayload. Unset means the device's own serial, so existing listeners are unaffected. Each of the three doorbells gets a parallel counterpart, which fires the existing event entity withparallel_prefixed event types rather than duplicating it, per @AzonInc's suggestion.Confirmed on a TCS VTC42V2 whose entrance calls arrive on its parallel serial: the Entrance Doorbell never fired despite the handset chiming, while the Apartment Doorbell (main serial) worked normally.