Home Assistant: Open source Python3 home automation - deel 5

[Oon]

RobertMe schreef op maandag 15 september 2025 @ 18:30:
[...]

Als je de V3+ bridge hebt ondersteund deze HomeKit. En HA kan als HomeKit Controller dienst doen.

Maar je mist dan wel functionaliteiten. Bv de open raam detectie kun je niet inzien via HomeKit (en is mogelijk uberhaupt gewoon een slimme temp daling detectie aan de server kant en niet iets dat de hardware doet?). Maar ook het "pas temp aan voor X minuten" kan niet over HomeKit (doh). Het batterijpercentage kun je niet inzien. Etc etc. Er zitten dus wel wat haken en ogen aan.

Overigens is de Tado X natuurlijk net zo'n groot probleem v.w.b. deze API wijzigingen. Hoogstens dat je deze via Matter lokaal kunt aansturen? Maar ook dan kan het best dat niet alle functionaliteiten / gegevens ook via Matter aangeboden (kunnen) worden omdat bv de standaard niet overal in voorzien.

Batterijpercentage is wel een issue, zeker gezien de grote problemen die de Tado knoppen sowieso al hebben met batterijgebruik.

Denk dat ik voor mezelf de keuze al gemaakt heb, ik ga lekker een berg SonOff zigbee knoppen bestellen voor de helft van de prijs van Tado en nooit meer terugkijken. Al het automatisch sturen heeft toch nooit fatsoenlijk gewerkt bij Tado.

[Ben(V)]

RobertMe schreef op maandag 15 september 2025 @ 17:55:
[...]

Fout.

Matter is een op IP gebaseerd protocol.
Thread is een standaard om IP door de lucht te sturen. Soort van wifi concurrent maar dan met veel minder bandbreedte, mesh, etc. En dit protocol maakt weer gebruik van dezelfde 802.11(?) standaard als Zigbee.

Dus er is wel degelijk een relatie tussen Zigbee en Thread. Waarbij een stick die geschikt is voor Zigbee ook gebruikt kan worden voor Thread en vise versa. Origineel verkocht Nabu Casa de SkyConnect zelfs onder vermelding van dat die Zigbee en Thread tegelijkertijd ondersteunde. (Maar dit heeft nooit goed gewerkt waardoor je moet kiezen).

En de relatie tussen Matter en Thread is puur dat Matter een op IP gebaseerd protocol is en dat Thread IP draadloos door de lucht babbelt. Maar bv ESPHome ondersteund ook Thread om de ESPs met Thread radio te verbinden. Maar zij gebruiken vervolgens gewoon "de ESPHome API" en niet Matter. Maar dit kun je wel gewoon mixen en matchen. Een ESP met ESPHome kun je via bv een Apple TV die als Thread border router dienst kan doen koppelen aan je netwerk/LAN (/"IP netwerk") waarna die ESP gewoon met HA kan verbinden / babbelen. Terwijl die Apple TV tegelijkertijd dus ook kan babbelen met allemaal andere (Matter over) Thread hardware.

Edit:
Overigens is Threads een product van Meta Het IoT gebeuren heet Thread, zonder s.

Moet je toch teleurstellen.
Het feit dat een radio die voor Zigbee gebruikt kan worden ook Thread signalen van versturen maakt het nog niet dat Zigbee voor matter gebruikt kan worden.

Voor Matter heb je Thread (IPV6) nodig al is het ook mogelijk om wifi te gebruiken, maar Zigbee gaat niet werken.
En Zigbee werkt volgens de 802.15.4 standaard en niet volgens de wifi standaard (802.11.xxx).

[HuismAndré]

RobertMe schreef op maandag 15 september 2025 @ 18:30:
[...]

Als je de V3+ bridge hebt ondersteund deze HomeKit. En HA kan als HomeKit Controller dienst doen.

Maar je mist dan wel functionaliteiten. Bv de open raam detectie kun je niet inzien via HomeKit (en is mogelijk uberhaupt gewoon een slimme temp daling detectie aan de server kant en niet iets dat de hardware doet?). Maar ook het "pas temp aan voor X minuten" kan niet over HomeKit (doh). Het batterijpercentage kun je niet inzien. Etc etc. Er zitten dus wel wat haken en ogen aan.

Volgens mij kon je het percentage sowieso niet zien bij Tado. Je moest het doen met iets als "good" todat hij leeg was.

[RobertMe]

Ben(V) schreef op maandag 15 september 2025 @ 18:37:
[...]


Moet je toch teleurstellen.
Het feit dat een radio die voor Zigbee gebruikt kan worden ook Thread signalen van versturen maakt het nog niet dat Zigbee voor matter gebruikt kan worden.

Dan moet ik je toch teleurstellen. Ik schrijf namelijk nergens dat Zigbee voor Thread gebruikt kan worden. Ik schrijf alleen dat beiden gebruik maken van dezelfde "802.11(?)" standaard, en dat is blijkbaar 802.15.4. En dat maakt dus wel dat een Zigbee radio ook gebruikt kan worden als Thread radio. Immers is het een soortgelijk draadloos protocol (v.w.b. frequentie etc). Alleen de bitjes die er overheen gaan zijn anders, maar dat maakt voor de radio an zich niet uit.
Ik stel vervolgens nergens dat je IP / Matter over Zigbee kunt doen, dat verzin je er zelf bij.

En er is dus zeker ook een relatie tussen Zigbee en Thread, namelijk 802.15.4 dus. Verder stel ik nergens dat ze vervolgens volledig uitwisselbaar zijn. Alleen dat de radio beiden kan. En en Zigbee stick vaak ook geschikt is als "Thread stick" (zie dus bv de SkyConnect, die ze origineel zelfs verkochten als dat die beiden tegelijkertijd aan kon). Dus qua technologie (draadloos protocol, meshing, ...) zijn Zigbee en Thread toch echt zeer dicht aan elkaar gerelateerd.
Dat vervolgens de daadwerkelijke data totaal anders is doet daar niks aan af. En ja, "Zigbee" gebruikt dan "Zigbee" als data, en Thread gebruikt "IP" als data. Waarvan mijn post ook al aangaf dat Thread IP gebruikt, nergens stelde ik dat Zigbee dat doet of kan.

[RobertMe]

HuismAndré schreef op maandag 15 september 2025 @ 19:10:
[...]

Volgens mij kon je het percentage sowieso niet zien bij Tado. Je moest het doen met iets als "good" todat hij leeg was.

Klopt. Maar via HomeKit kun je het dus helemaal niet uitlezen Percentage of een beperkte "enum" (goed / bijna leeg), het zit niet in HomeKit / wordt niet door Tado aangeboden via HomeKit. (Geen idee of HomeKit het wel kan ondersteunen en Tado het niet doorgeeft, of dat de mogelijkheid uberhaupt niet in HomeKit zit).

[paQ]

w00p w00p

Het is gelukt de dweilrobots live te laten meelopen in het 3D dashboard


Refreshrate is met 3sec wel klaar jammer genoeg.
Wel handig om te zien waar hij ook echt (al) is geweest


was een enorm geklooi om de images transparant te krijgen, maar gelukt om bij elke entry een alpha slider te plaatsen door de code van map extractor wat te tweaken.

In options_flow.py:

Python:

    ## Add alpha channel
    async def async_step_room_colors_step2(self: Self, user_input=None) -> ConfigFlowResult:
        # Als de gebruiker op Verzenden klikt: RGB + ALPHA samenvoegen naar RGBA
        if user_input is not None:
            out = {}
            for room_id in self._room_color_ids:
                rgb = user_input.get(room_id, [0, 0, 0])[:3]
                a = int(user_input.get(room_id + "_alpha", 255))
                out[room_id] = [*rgb, a]
            self._changed_options[CONF_ROOM_COLORS] = out
            return await self._update_entry()

        # ✔️ Belangrijk: gebruik vol.Required voor ALLE velden
        color_fields = {vol.Required(room_id): ColorRGBSelector() for room_id in self._room_color_ids}
        alpha_fields = {vol.Required(room_id + "_alpha"): NumberSelector(
            config=NumberSelectorConfig(min=0, max=255, step=1, mode=NumberSelectorMode.SLIDER)
        ) for room_id in self._room_color_ids}

        schema = vol.Schema({**color_fields, **alpha_fields})

        # Defaults (RGB + alpha) invullen
        configured_colors = self.config_entry.options[CONF_ROOM_COLORS]
        palette = ColorsPalette()

        defaults: dict[str, Any] = {}
        for room_id in self._room_color_ids:
            if room_id in configured_colors:
                rgba = configured_colors[room_id]
                rgb = rgba[:3]
                a = rgba[3] if len(rgba) > 3 else 255
            else:
                rgb = palette.get_room_color(room_id)  # geeft RGB
                a = 255
            defaults[room_id] = rgb
            defaults[room_id + "_alpha"] = a

        data_schema = self.add_suggested_values_to_schema(schema, defaults)
        return self.async_show_form(step_id="room_colors_step2", data_schema=data_schema, last_step=True)

    # async def async_step_room_colors_step2(self: Self, user_input=None) -> ConfigFlowResult:
    #     if user_input is not None:
    #         self._changed_options[CONF_ROOM_COLORS] = user_input
    #         return await self._update_entry()

    #     schema = vol.Schema({vol.Required(room_id): ColorRGBSelector() for room_id in self._room_color_ids})
    #     configured_colors = self.config_entry.options[CONF_ROOM_COLORS]
    #     palette = ColorsPalette()
    #     data_schema = self.add_suggested_values_to_schema(
    #         schema,
    #         {
    #             room_id: (
    #                 configured_colors[room_id]
    #                 if room_id in configured_colors
    #                 else palette.get_room_color(room_id)
    #             )
    #             for room_id in self._room_color_ids
    #         }
    #     )
    #     return self.async_show_form(step_id="room_colors_step2", data_schema=data_schema, last_step=True)

[ Voor 67% gewijzigd door paQ op 15-09-2025 20:18 ]

[LordSinclair]

Oon schreef op maandag 15 september 2025 @ 18:06:
[...]

Ik ben dan toch wel benieuwd hóe je local-only bent gegaan. Is daar een alternatieve integratie voor?

Ik ben niks out of the box tegengekomen. Maar met scheduler cards, binaire helpers (de scheduler-cards hadden moeite met de thermostaat aansturen) en automatisering ben ik een eind met het programma gedeelte. Dat lijkt goed te werken. Alleen die timer nog bij handmatige wijzigingen.
Maar ik heb geen kamers met radiatorknoppen. En daarom is de battterij-info ook niet zo belangrijk. Daarnaast doet de app het op te telefoon het ook gewoon nog.

[Ben(V)]

RobertMe schreef op maandag 15 september 2025 @ 19:23:
[...]

Dan moet ik je toch teleurstellen. Ik schrijf namelijk nergens dat Zigbee voor Thread gebruikt kan worden. Ik schrijf alleen dat beiden gebruik maken van dezelfde "802.11(?)" standaard, en dat is blijkbaar 802.15.4. En dat maakt dus wel dat een Zigbee radio ook gebruikt kan worden als Thread radio. Immers is het een soortgelijk draadloos protocol (v.w.b. frequentie etc). Alleen de bitjes die er overheen gaan zijn anders, maar dat maakt voor de radio an zich niet uit.
Ik stel vervolgens nergens dat je IP / Matter over Zigbee kunt doen, dat verzin je er zelf bij.

En er is dus zeker ook een relatie tussen Zigbee en Thread, namelijk 802.15.4 dus. Verder stel ik nergens dat ze vervolgens volledig uitwisselbaar zijn. Alleen dat de radio beiden kan. En en Zigbee stick vaak ook geschikt is als "Thread stick" (zie dus bv de SkyConnect, die ze origineel zelfs verkochten als dat die beiden tegelijkertijd aan kon). Dus qua technologie (draadloos protocol, meshing, ...) zijn Zigbee en Thread toch echt zeer dicht aan elkaar gerelateerd.
Dat vervolgens de daadwerkelijke data totaal anders is doet daar niks aan af. En ja, "Zigbee" gebruikt dan "Zigbee" als data, en Thread gebruikt "IP" als data. Waarvan mijn post ook al aangaf dat Thread IP gebruikt, nergens stelde ik dat Zigbee dat doet of kan.

Je schrijft dat ik fout hebt, wat had ik dan fout?

Je schrijft dat er wel degelijk een relatie tussen thread en zigbee is en dat beargumenteer je door het feit dat ze dezelfde radio kunnen gebruiken, om vervolgens ook nog onterecht te beweren dat ze dezelfde (wifi) standaard gebruiken (802.11.xxx).
Ik beweer nergens dat het niet zo is dat ze dezelfde hardware kunnen gebruiken maar je kunt dat nauwelijks een relatie noemen.
En protocollen als data kwalificeren is ook een beetje krom, data wordt verstuurd met behulp van een protcol.

[RobertMe]

Ben(V) schreef op dinsdag 16 september 2025 @ 09:24:
[...]


Je schrijft dat ik fout hebt, wat had ik dan fout?

Je schreef dat Threads (hoort dus Thread te zijn) een protocol is dat door Matter gebruikt wordt. En dat klopt al niet. Want Matter gaat over IP en via Thread kun je IP sturen. Maar er is geen directe link tussen Matter en Thread (case in point: ESPHome dat Thread gebruikt voor de ESPHome API dat ook gewoon IP based is en naast Matter over dezelfde TBR kan gaan).

Je schrijft dat er wel degelijk een relatie tussen thread en zigbee is en dat beargumenteer je door het feit dat ze dezelfde radio kunnen gebruiken, om vervolgens ook nog onterecht te beweren dat ze dezelfde (wifi) standaard gebruiken (802.11.xxx).

Ik beweer niet dat ze dezelfde wifi standaard gebruikte. Ik wist niet de exacte standaard. N dat is dus 802.25.4 en niet 802.11. Iets waarvan je zelf in een latere reactie ook al aangaf dat ze dezelfde standaard (802.15.4 dus) gebruiken. En toch beweer je dat er geen relatie tussen beiden is?!

Ik beweer nergens dat het niet zo is dat ze dezelfde hardware kunnen gebruiken maar je kunt dat nauwelijks een relatie noemen.

Als beiden dezelfde standaard (802.15.4 dus) gebruiken, en dezelfde hardware kunnen gebruiken en er initieel beloftes waren dat 1 stuk hardware beiden tegelijkertijd kan ondersteunen wil ik dat toch wel een relatie tussen beiden noemen.

En protocollen als data kwalificeren is ook een beetje krom, data wordt verstuurd met behulp van een protcol.

En die data zelf voldoet ook aan een protocol / standaard. Anders is er vrij weinig interoperabiliteit.

En daarnaast:
* mompelt iets over verschillende lagen *
802.15.4 definieert de fysieke / link laag. Over die laag wordt data gestuurd, welke data dat is is totaal irrelevant binnen 802.15.4. Vervolgens heb je het Zigbee protocol / standaard die definieert hoe de data er uit ziet die in het geval van "Zigbee", dat over 802.15.4 wordt gestuurd. En Thread is zijn eigen protocol / standaard die definieert welke / hoe data over 802.15.4 wordt gestuurd. Waarbij 802.15.4 dus geen enkele kennis hoeft te hebben / heeft van welke data (/protocollen / standaarden / bytes / bitjes) er in de data laag verzonden worden.

En je kunt zo ongeveer ook het OSI model er bij pakken. 802.15.4 is de fysieke laag, vervolgens heb je IP op de netwerk laag en Matter (of de ESPHome API) op de applicatie laag. Terwijl Zigbee niet zo makkelijk in het OSI model te plaatsen is omdat alles boven de fysieke laag meteen het Zigbee protocol / standaard is en er niet nog allemaal lagen bovenop komen (en dus minder overhead).

[Sp33dFr34k]

Even een brainstorm, HA mist een stopwatch helper (timer doet precies het omgekeerde).

Ik wil bijvoorbeeld bijhouden hoe lang de wasmachine draait, deze slingert een automation aan die start zodra de power x tijd boven x wattage is, en eindigt zodra de power een x tijd onder x wattage is. Een history stats helper kun je niet via een automation resetten... Zijn er nog andere opties?

[xXtronXx]

Recent een dashboard samengesteld met uitsluitend gebruik van de Area-Card. Achter elke kaart schuilt een hele reeks andere kaarten, en ik ben er eigenlijk best tevreden mee.

Nog een paar extra sensoren toevoegen en de afbeeldingen vervangen door foto's van ons eigen interieur.
Mijn laatste test van een Mmwave sensor doet het prima
(Hier)

Tof is dat de camerabeelden naadloos geïntegreerd zijn in dezelfde kaarten.
De auto's zijn ook een Area en krijgen ook de nodige info.

[Card Nox]

Domme vraag tussendoor: Ik heb een nieuwe telefoon. Je raad het al, alle automations wijzen naar mijn oude telefoon. Nu is er vast een slimmere manier om dit soort dingen op te lossen? Wellicht ipv notificaties naar device notificaties naar een device of naar een groep oid? Wat is hier de common practice?

[TheFes]

Card Nox schreef op dinsdag 16 september 2025 @ 16:27:
Domme vraag tussendoor: Ik heb een nieuwe telefoon. Je raad het al, alle automations wijzen naar mijn oude telefoon. Nu is er vast een slimmere manier om dit soort dingen op te lossen? Wellicht ipv notificaties naar device notificaties naar een device of naar een groep oid? Wat is hier de common practice?

Het makkelijkste is om de oude mobile app integratie (die met je oude telefoon dus) weg te gooien, en na installatie van de HA app op je nieuwe telefoon dezelfde naam te gebruiken.
Maar goed, als je oude telefoon iPhone 15 Pro heette en je hebt nu een iPhone 17 is dat wellicht wat verwarrend.

Om het voor de toekomst te voorkomen zou je een notfiy group aan kunnen maken met daarin alleen de notfiy action van je telefoon. Als je dan altijd die group gebruikt, hoef je bij een nieuwe wisseling alleen de instellingen van de group aan te passen.

Maar wat ik zelf gedaan heb is een find and replace in de VSCode add-on, om de oude notify action te hernoemen naar de nieuwe

Sowieso om issues bij vervangen van een device (of dat nu een telefoon of een vochtigheidssensor is) nooit device actions/conditions/triggers gebruiken, dan is het simpelweg je nieuwe entities dezelfde entity_id geven en alles werkt weer. Bij notifications is dat wat anders, want die werken (nog) niet met entities maar met actions.

[Get!em]

Sp33dFr34k schreef op dinsdag 16 september 2025 @ 16:21:
Even een brainstorm, HA mist een stopwatch helper (timer doet precies het omgekeerde).

Ik wil bijvoorbeeld bijhouden hoe lang de wasmachine draait, deze slingert een automation aan die start zodra de power x tijd boven x wattage is, en eindigt zodra de power een x tijd onder x wattage is. Een history stats helper kun je niet via een automation resetten... Zijn er nog andere opties?

https://gist.github.com/j...fbd9a9a725a290dad8c4eae24 zoiets?

[TheFes]

Sp33dFr34k schreef op dinsdag 16 september 2025 @ 16:21:
Even een brainstorm, HA mist een stopwatch helper (timer doet precies het omgekeerde).

Ik wil bijvoorbeeld bijhouden hoe lang de wasmachine draait, deze slingert een automation aan die start zodra de power x tijd boven x wattage is, en eindigt zodra de power een x tijd onder x wattage is. Een history stats helper kun je niet via een automation resetten... Zijn er nog andere opties?

Een input datetime op de huidige tijd zetten als je programma start, en een andere als het programma stopt. Vervolgens kun je die twee met elkaar vergelijken.