Home Assistant: Open source Python3 home automation - deel 5

[Septillion]

krizzziz schreef op dinsdag 20 mei 2025 @ 14:59:
Ik heb geen config map kom ik net achter. Mijn configuration.yaml zit meteen onder /homeassistant/configuration.yaml. Ook zit de map www direct onder /homeassistant/www waardoor ze niet te zien zijn voor de buitenwereld.

Iemand hier ervaringen mee?

Jij kijkt denk ik direct op je HA OS? Want binnen het OS heet de map homeassistant/. Deze is als config/ gemapt in de HA Core docker. Veel andere addons zoals bijvoorbeeld Samba of FileEditor doen hetzelfde.

[krizzziz]

Septillion schreef op dinsdag 20 mei 2025 @ 21:32:
[...]

Jij kijkt denk ik direct op je HA OS? Want binnen het OS heet de map homeassistant/. Deze is als config/ gemapt in de HA Core docker. Veel andere addons zoals bijvoorbeeld Samba of FileEditor doen hetzelfde.

Correct!

Ik zie dus nu ook dat alles wat in in /homeassistant/www/ flikker vervolgens op https://IP:poort/locall verschijnt. Dus prima, maar dan is dit duidelijk!

[zunrob]

We hebben sinds kort een Ikea/Sonos Symfonisk speaker. Ik krijg hem echter niet zichtbaar in de Sonos integratie.
Ik draai HA in een docker op de NAS, waarbij netwerk op host staat. Ik heb tevens in de firewall van de NAS poort 1400 open gezet. Maar alsnog blijft er staan dat er geen devices gevonden worden. De speaker bevindt zich in hetzelfde netwerk. Ik snap niet helemaal waarom het niet werkt, bij Shellys etc. werkt het wel gewoon.

Edit: overigens werkt het wel als ik het IP-adres in de configuration.yaml toewijs, maar wil graag begrijpen waarom de auto-discovery niet werkt.

[ Voor 14% gewijzigd door zunrob op 20-05-2025 22:47 ]

[Septillion]

@zunrob Als ik via de zeroconf browser kijk zie ik discovery van de Symfonisk op poort 7000 (_airplay._tcp.local en _raop._tcp.local) en 1443 (_sonos._tcp.local). Dus gok dat het nog steeds je firewall is.

[ Voor 33% gewijzigd door Septillion op 20-05-2025 23:13 ]

[FlowDesign]

Weet iemand of het mogelijk is om de lokaal gehoste n8n (zie Github) op Home Assistant te draaien? Ik gebruik geen docker, heb HA gewoon zo op m'n Raspberry draaien.

[avdwerf]

Kom uit een volgens mij heel simpel iets niet uit. Heb een sensor waar een datum in staat. Ik wil als morgen die datum is, ik om 19:30 een melding op mijn telefoon krijgen dat er iets moet gebeuren. Ik gebruik deze template

YAML:

{% set date_string = states('sensor.ophaaldag_gft')[6:10] + "-" + states('sensor.ophaaldag_gft')[3:5] + "-" + states('sensor.ophaaldag_gft')[0:2] %}
{{ (date_string | as_datetime | as_local - timedelta(days=1)).date() == now().date() }}

Die werkt op zich, veranderd naar true op de goede dag, maar dus al om 0:00 gelijk. Ik heb geprobeerd om bij Voor: dan 19 uur en 30 minuten in te vullen. Dat werkt, behalve als HA op die dag een keer reboot ivm updates. Heb ook geprobeerd een extra conditie toe te voegen (En als - tijd na 19:30) maar dat werkt natuurlijk ook niet, omdat die waarde al om 0:00 veranderd.

[bvw]

avdwerf schreef op woensdag 21 mei 2025 @ 08:16:
Kom uit een volgens mij heel simpel iets niet uit. Heb een sensor waar een datum in staat. Ik wil als morgen die datum is, ik om 19:30 een melding op mijn telefoon krijgen dat er iets moet gebeuren. Ik gebruik deze template

YAML:

{% set date_string = states('sensor.ophaaldag_gft')[6:10] + "-" + states('sensor.ophaaldag_gft')[3:5] + "-" + states('sensor.ophaaldag_gft')[0:2] %}
{{ (date_string | as_datetime | as_local - timedelta(days=1)).date() == now().date() }}

Die werkt op zich, veranderd naar true op de goede dag, maar dus al om 0:00 gelijk. Ik heb geprobeerd om bij Voor: dan 19 uur en 30 minuten in te vullen. Dat werkt, behalve als HA op die dag een keer reboot ivm updates. Heb ook geprobeerd een extra conditie toe te voegen (En als - tijd na 19:30) maar dat werkt natuurlijk ook niet, omdat die waarde al om 0:00 veranderd.

Als je nu als trigger een template op de tijd zet, en dan als condition een template op de datum, is het dan niet ok?

Er bestaat ook deze blueprint trouwens: https://community.home-as...t/garbage-reminder/284213

[ Voor 4% gewijzigd door bvw op 21-05-2025 08:22 ]

[avdwerf]

bvw schreef op woensdag 21 mei 2025 @ 08:20:
[...]


Als je nu als trigger een template op de tijd zet, en dan als condition een template op de datum, is het dan niet ok?

Er bestaat ook deze blueprint trouwens: https://community.home-as...t/garbage-reminder/284213

Thanks, heb dit nu ingesteld, vanavond kijken of het werkt en anders ga ik wel even met die blueprint aan de slag

[Hmmbob]

zunrob schreef op dinsdag 20 mei 2025 @ 22:17:
We hebben sinds kort een Ikea/Sonos Symfonisk speaker. Ik krijg hem echter niet zichtbaar in de Sonos integratie.
Ik draai HA in een docker op de NAS, waarbij netwerk op host staat. Ik heb tevens in de firewall van de NAS poort 1400 open gezet. Maar alsnog blijft er staan dat er geen devices gevonden worden. De speaker bevindt zich in hetzelfde netwerk. Ik snap niet helemaal waarom het niet werkt, bij Shellys etc. werkt het wel gewoon.

Edit: overigens werkt het wel als ik het IP-adres in de configuration.yaml toewijs, maar wil graag begrijpen waarom de auto-discovery niet werkt.

Soms gaat het in Docker setups ook mis met de IP-adressen van de HA server & autodiscovery. Zie de allerlaatste alinea over advertise_addr: https://www.home-assistan...tions/sonos/#advanced-use

edit:
en ik zie in mijn eigen docker-compose.yaml (waarin ik GEEN network=host gebruik) dat ik inderdaat zowel poort 1400 als 1443 geexposed heb, dus wat @Septillion hierboven noemde is ook een goeie pointer.

[ Voor 12% gewijzigd door Hmmbob op 21-05-2025 08:45 ]

[TheFes]

avdwerf schreef op woensdag 21 mei 2025 @ 08:16:
Kom uit een volgens mij heel simpel iets niet uit. Heb een sensor waar een datum in staat. Ik wil als morgen die datum is, ik om 19:30 een melding op mijn telefoon krijgen dat er iets moet gebeuren. Ik gebruik deze template

YAML:

{% set date_string = states('sensor.ophaaldag_gft')[6:10] + "-" + states('sensor.ophaaldag_gft')[3:5] + "-" + states('sensor.ophaaldag_gft')[0:2] %}
{{ (date_string | as_datetime | as_local - timedelta(days=1)).date() == now().date() }}

Die werkt op zich, veranderd naar true op de goede dag, maar dus al om 0:00 gelijk. Ik heb geprobeerd om bij Voor: dan 19 uur en 30 minuten in te vullen. Dat werkt, behalve als HA op die dag een keer reboot ivm updates. Heb ook geprobeerd een extra conditie toe te voegen (En als - tijd na 19:30) maar dat werkt natuurlijk ook niet, omdat die waarde al om 0:00 veranderd.

In je tweede regel ga je met datums rekenen, dus daarbij verlies je alles wat betreft tijd.
BTW, in plaats van dat geknutsel met die substrings kun je ook de Python strptime functie gebruiken.
Zie ook: https://www.home-assistan...guration/templating/#time

[Septillion]

@avdwerf Kon je niet gelijk naar datetime vanuit de entity ipv het knippen en plakken?

Verder is je trigger inderdaad gewoon "om 19:30", als conditie ga je uitzoeken of het morgen de datum is.

[ Voor 38% gewijzigd door Septillion op 21-05-2025 12:09 ]

[Janoz]

FlowDesign schreef op woensdag 21 mei 2025 @ 00:04:
Weet iemand of het mogelijk is om de lokaal gehoste n8n (zie Github) op Home Assistant te draaien? Ik gebruik geen docker, heb HA gewoon zo op m'n Raspberry draaien.

Je vraag is een beetje vreemd. Hoe heb je HA op je rapsberry draaien? Als je het gewoon als applicatie heb draaien, dan zou je n8n er gewoon naast kunnen zetten. Heb je Homa Assistant OS op je rapsberry draaien, dan wordt het ingewikkeld. Je zou n8n als docker container kunnen proberen te draaien binnen HaOS, maar dat geeft issues zoals het niet meer kunnen updaten van addons, of HaOS zelf.

Mocht je HaOS gebruiken dan is et meest simpele om n8n op een andere raspberry te installeren.

-- edit --
Oh, ik zie na een snelle google dat er iemand is die een n8n add-on gemaakt heeft. Die zou je ook kunnen gebruiken.

https://github.com/Rbillon59/hass-n8n

[ Voor 10% gewijzigd door Janoz op 21-05-2025 12:12 ]

[Gizz]

Even uithuilen hier:

Oeps 1: VM met HAOS heeft zich vannacht afgesloten omdat de storage pool vol was.
Oeps 2: Ruimte gemaakt en HAOS weer draaiend, allemaal fijne meldingen: Storage corruption detected for core.entity_registry/hacs.data/hacs.repositories en allemaal dingen die niet meer goed werken.
Oeps 3: Voor de eerste keer ooit er niet aan ontkomen om een back-up terug te zetten omdat het echt kapot lijkt: laatste backup is 12 dagen oud

Ik laat al jaren netjes elke 3 dagen een full back-up maken met de HA Google Drive Backup add-on, zowel lokaal als naar Google Drive. Dat heeft hij blijkbaar de laatste maanden netjes gedaan, maar de laatste back-ups waren van 3, 6 en 9 mei. Daarna is er gewoon niks. Blijkbaar add-on dood zonder dat ik het door had, terwijl de watchdog wel gewoon aan stond.



edit: mijn energy dashboard doet het nog wel prima en alle data daarin klopt. Even kijken hoe ik de data van de laatste 12 dagen kan bewaren om terug te zetten als ik de rollback doe van mijn nu halfwerkende HA naar de backup van 9 mei. Iemand een snelle tip?

[ Voor 13% gewijzigd door Gizz op 21-05-2025 12:24 ]

[HuismAndré]

Gizz schreef op woensdag 21 mei 2025 @ 12:12:
Even uithuilen hier:

Oeps 1: VM met HAOS heeft zich vannacht afgesloten omdat de storage pool vol was.
Oeps 2: Ruimte gemaakt en HAOS weer draaiend, allemaal fijne meldingen: Storage corruption detected for core.entity_registry/hacs.data.hacs.repositories en allemaal dingen die niet meer goed werken.
Oeps 3: Voor de eerste keer ooit er niet aan ontkomen om een back-up terug te zetten omdat het echt kapot lijkt: laatste backup is 12 dagen oud

Ik laat al jaren netjes elke 3 dagen een full back-up maken met de HA Google Drive Backup add-on, zowel lokaal als naar Google Drive. Dat heeft hij blijkbaar de laatste maanden netjes gedaan, maar de laatste back-ups waren van 3, 6 en 9 mei. Daarna is er gewoon niks. Blijkbaar add-on dood zonder dat ik het door had, terwijl de watchdog wel gewoon aan stond.



edit: mijn energy dashboard doet het nog wel prima en alle data daarin klopt. Even kijken hoe ik de data van de laatste 12 dagen kan bewaren om terug te zetten als ik de rollback doe van mijn nu halfwerkende HA naar de backup van 9 mei. Iemand een snelle tip?

Database veilig stellen, backup restoren, database eroverheen gooien en repareren wat verder nog nodig is.

[FlowDesign]

Janoz schreef op woensdag 21 mei 2025 @ 12:09:
[...]

Je vraag is een beetje vreemd. Hoe heb je HA op je rapsberry draaien? Als je het gewoon als applicatie heb draaien, dan zou je n8n er gewoon naast kunnen zetten. Heb je Homa Assistant OS op je rapsberry draaien, dan wordt het ingewikkeld. Je zou n8n als docker container kunnen proberen te draaien binnen HaOS, maar dat geeft issues zoals het niet meer kunnen updaten van addons, of HaOS zelf.

Mocht je HaOS gebruiken dan is et meest simpele om n8n op een andere raspberry te installeren.

-- edit --
Oh, ik zie na een snelle google dat er iemand is die een n8n add-on gemaakt heeft. Die zou je ook kunnen gebruiken.

https://github.com/Rbillon59/hass-n8n

Ik heb indd gewoon HAOS draaien op m'n Raspberry, dus niet in een container oid.

Dank voor de link! Dat was precies wat ik zocht en niet kon vinden

[avdwerf]

Septillion schreef op woensdag 21 mei 2025 @ 12:08:
@avdwerf Kon je niet gelijk naar datetime vanuit de entity ipv het knippen en plakken?

Verder is je trigger inderdaad gewoon "om 19:30", als conditie ga je uitzoeken of het morgen de datum is.

Eerlijk gezegd geen idee, vond wat ik nu heb ergens online en dat 1 op 1 gebruikt. Werkte in het begin prima tot ik mijn HA een keer moest rebooten op die dag en ik geen meldingen meer kreeg.

[meesje]

Hier ben ik weer. Ik heb nu mijn Ring (doorbell wired) via Scrypted (op Raspberry Pi 3) toegevoegd aan HomeKit. Best wat youtube video’s voor de beste settings. Dit werkt nu wel, maar (a) de opnames in iCloud zijn soms een beetje schokkerig, (b) het duurt soms wat langer dan gewend voor er een live view is, en (c) de opnames starten een stukje later t.o.v. een dedicated HomeKit camera maar ook de opname in de Ring cloud. Je ziet dan namelijk ook een stukje voordat er daadwerkelijk beweging is.
Ik heb het gevoel dat dit laatste niet is op te lossen door zwaardere apparatuur waarop Scrypted draait, maar kan ik (a) en (b) wel verbeteren door bv een NUC te gebruiken? Via pepper zag ik een N150 met 16gb en 512gb voorbij komen voor 127 euro. Zou een dergelijk apparaat (al dan niet samen met HA) zorgen voor een performance verbetering?

[Maeslant]

Ik heb echt wat hulp nodig. Graag maak ik gebruik van color-state-based items.

Dit heeft dus gewerkt, maar ineens niet meer. Hoe kan ik dit goed doen, zodat het na update blijft werken.

Doel is icon veranderd van kleur op basis van state.

YAML:

show_name: false
show_icon: true
show_state: true
type: glance
entities:
  - entity: sensor.awair_element_75177_carbon_dioxide
    icon: mdi:molecule-co2
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set co2 = states('sensor.awair_element_75177_carbon_dioxide') | float %}
            {% if co2 < 700 %}
              green
            {% elif co2 < 1000 %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.awair_element_75177_pm2_5
    icon: mdi:molecule
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set ppm = states('sensor.awair_element_75177_pm2_5') | float %}
            {% if ppm < 12 %}
              green
            {% elif ppm < 30  %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.awair_element_75177_score
    icon: mdi:blur
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set score = states('sensor.awair_element_75177_score') | float %}
            {% if score < 85 %}
              red
            {% elif score < 93 %}
              orange
            {% else %}
              green
            {% endif %};
  - entity: sensor.awair_element_75177_temperature
    icon: mdi:thermometer
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set tem1 = states('sensor.awair_element_75177_temperature') | float %}
            {% if tem1 < 19.5 %}
              orange
            {% elif tem1 > 22 %}
              orange
            {% elif tem1 > 24 %}
              red
            {% elif tem1 < 18 %}
              red
            {% else %}
              green
            {% endif %};
        }
  - entity: sensor.awair_element_75177_humidity
    icon: mdi:water-percent
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set hum = states('sensor.awair_element_75177_humidity') | float %}
            {% if hum < 60 > 40 %}
              green
            {% elif hum > 60  %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.awair_element_75177_vocs
    icon: mdi:weather-dust
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set vocs = states('sensor.awair_element_75177_vocs') | float %}
            {% if vocs < 250 %}
              green
            {% elif vocs < 500 %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.master_bedroom_carbon_dioxide
    icon: mdi:molecule-co2
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set co2m = states('sensor.master_bedroom_carbon_dioxide') | float %}
            {% if co2m < 600 %}
              green
            {% elif co2m < 800 %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.lauren_carbon_dioxide
    icon: mdi:molecule-co2
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set co2l = states('sensor.lauren_carbon_dioxide') | float %}
            {% if co2l < 600 %}
              green
            {% elif co2l < 800 %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.outdoor_sensor_humidity
    icon: mdi:water-percent
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set hum2 = states('sensor.outdoor_sensor_humidity') | float %}
            {% if hum2 < 60 %}
              green
            {% elif hum2 < 80 %}
              orange
            {% else %}
              red
            {% endif %};
        }
  - entity: sensor.outdoor_sensor_temperature
    icon: mdi:molecule-co2
    card_mod:
      style: |
        :host {
          --paper-item-icon-color:
            {% set co2 = states('sensor.outdoor_sensor_temperature') | float %}
            {% if co2 < 400 %}
              green
            {% elif co2 < 700 %}
              orange
            {% else %}
              red
            {% endif %};
        }
state_color: false

[ Voor 0% gewijzigd door Septillion op 21-05-2025 15:24 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Danielson]

Frigate kan sinds versie 0.16 ook de snelheid van objecten meten, maar de Home Assistant integratie krijgt deze data nog niet door, iemand toevallig al bezig geweest om een leaderbord te maken in HA van de hoogst gemeten snelheden in je straat?

https://deploy-preview-16...n/zones/#speed-estimation

[ Voor 16% gewijzigd door Danielson op 21-05-2025 16:13 ]

[tjanssen]

Ik heb in media een folder met jpg bestanden staan. Weet iemand hoe ik deze gemakkelijk kan bekijken? Ik bedoel dan met een simpele klik om naar de volgende of vorige jpg te gaan. In de media browser moet ik eerst het bestand wegklikken, alvorens ik een ander bestand kan bekijken.

[Septillion]

@Maeslant Probeer eens --card-mod-icon-color ipv --paper-item-icon-color.

[Workaholic]

Hebben jullie ervaring met een goede zigbee kraan voor het besproeien van de tuin? Ik wil eigenlijk gewoon een domme aan/uit water schakelaar hebben op zigbee zodat ik met HA de juiste tijdstip kan regelen met ja/nee scenario's etc.

Er zijn er best veel te koop. Benieuwd of jullie nog tips hebben! Zal op batterij moeten vrees ik.

Ik dacht aan zoiets..

[ Voor 12% gewijzigd door Workaholic op 21-05-2025 19:55 ]

[Torch1969]

Workaholic schreef op woensdag 21 mei 2025 @ 19:55:
Hebben jullie ervaring met een goede zigbee kraan voor het besproeien van de tuin? Ik wil eigenlijk gewoon een domme aan/uit water schakelaar hebben op zigbee zodat ik met HA de juiste tijdstip kan regelen met ja/nee scenario's etc.

Er zijn er best veel te koop. Benieuwd of jullie nog tips hebben! Zal op batterij moeten vrees ik.

Ik dacht aan zoiets..

Die heb ik net aangeschaft. Paar dagen mee proef gedraaid. Eerste indruk is goed. Redelijk groot en degelijk apparaat die stevig op de buitenkraan te bevestigen is. Koppelt goed met zigbee2mqtt inclusief firmware update. Komt goed door naar HA. Zitten wat geavanceerde functies in waarvan ik nog niet precies weet hoe ze werken, maar belangrijkste is de aan/uit functie en die werkt goed. De werking over langere periode kan ik nog niet beoordelen.

[Maeslant]

Septillion schreef op woensdag 21 mei 2025 @ 19:30:
@Maeslant Probeer eens --card-mod-icon-color ipv --paper-item-icon-color.

Super bedankt dat werkt. Update; bijna in de app werkt het dus niet.

Nog 1 vraag, de meeste statussen zijn float (en nummeriek). Nu heb ik ook 1 state dat een tekst veld is.

Kan ik ook daar van de kleur veranderen met deze code?

YAML:

  - entity: sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate
    icon: mdi:dishwasher
    card_mod:
      style: |
        :host {
          --card-mod-icon-color:
            {% set dish = states('sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate') %}
            {% if dish = "Inactive" %}
              green
            {% elif hum "Run"  %}
              orange
            {% else %}
              red
            {% endif %};
        }

[sypie]

Voor een kennis van mij heb ik hun RIng systeem in HA toegevoegd. De camera's en deurbel werken allemaal netjes, geen centje pijn.

Nu wordt mij gevraagd of de status van "Thuis, weg en "disarmed" " ook in Home Assistant zou kunnen werken. Kennelijk kan dit in de app of via de website. Ik ben dit nog niet tegengekomen in mijn zoektocht maar misschien heeft iemand hier een oplossing?

[TheFes]

Maeslant schreef op woensdag 21 mei 2025 @ 21:59:
[...]


Super bedankt dat werkt. Update; bijna in de app werkt het dus niet.

Nog 1 vraag, de meeste statussen zijn float (en nummeriek). Nu heb ik ook 1 state dat een tekst veld is.

Kan ik ook daar van de kleur veranderen met deze code?

YAML:

  - entity: sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate
    icon: mdi:dishwasher
    card_mod:
      style: |
        :host {
          --card-mod-icon-color:
            {% set dish = states('sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate') %}
            {% if dish = "Inactive" %}
              green
            {% elif hum "Run"  %}
              orange
            {% else %}
              red
            {% endif %};
        }

code:

{% elif hum "Run"  %}

Daar gaat iets fout...

[Antonio di]

Workaholic schreef op woensdag 21 mei 2025 @ 19:55:
Hebben jullie ervaring met een goede zigbee kraan voor het besproeien van de tuin? Ik wil eigenlijk gewoon een domme aan/uit water schakelaar hebben op zigbee zodat ik met HA de juiste tijdstip kan regelen met ja/nee scenario's etc.

Er zijn er best veel te koop. Benieuwd of jullie nog tips hebben! Zal op batterij moeten vrees ik.

Ik dacht aan zoiets..

Zie review met ook advies over Slimme kraantjes:
GiEX Zigbee smart buitenkraan met watermeter review door Antonio di

[verjager]

tjanssen schreef op woensdag 21 mei 2025 @ 17:24:
Ik heb in media een folder met jpg bestanden staan. Weet iemand hoe ik deze gemakkelijk kan bekijken? Ik bedoel dan met een simpele klik om naar de volgende of vorige jpg te gaan. In de media browser moet ik eerst het bestand wegklikken, alvorens ik een ander bestand kan bekijken.

Ik gebruik hiervoor al een tijdje de custom Gallery Card. Die wordt sinds eind 2024 niet meer ondersteund, maar werkt nog wel. Een paar maanden geleden was er een probleem, dat had ik toen tijdelijk gefixed maar nu werkt de card weer gewoon volgens mij. Ik heb dus de fork van lukelalo nog niet nodig gehad.

YAML:

type: custom:gallery-card
entities:
  - media-source://media_source/local/camera_snapshots/deurbel/
menu_alignment: hidden
maximum_files: 20
file_name_format: YYYYMMDD-HHmmss
caption_format: "[Deurbel] D-M-YYYY [om] H:mm"
show_reload: true

[ChrisM]

Ik heb een probleem, waar ik niet uit kom. Mijn hele huis heeft Shelly dimmers (en een paar keer een PlugS) om de verlichting mee te besturen. Das top, werkt ook goed in HA. Ik heb een helper gemaakt, met alle energy sensoren van de Shelly's, om de energy van al mijn binnenverlichting te kunnen meten. Maar als ik dat in mijn energy dashboard laat zien, gebeurt er iets geks (namelijk: regelmatig heel erg veel verbruik (>1000 kWh (ja, echt), want niet mogelijk is). Dus ik ging eens onderzoeken, en ik zie dat mijn Shelly's om de zoveel dagen de verbinding verbreken voor iets langer dan een minuut.

De blauwe lijn is mijn groep (gewoon via een helper gemaakt in HA), de lijntjes daaronder zijn de verschillende Shelly's. Als je inzoomt, zie je dat het niet op hetzelfde moment gebeurt. Daarom gaat de lijn van de groep ook in stapjes naar beneden. (Ik heb trouwens niet alle entities hier, het zijn er een stuk of 30). Bovenaan zie je een grijze lijn, dat is die van een PM Mini, die niet in de verlichting groep zit, maar ook hetzelfde laat zien (en van een totaal andere generatie is dan de dimmers).

Dit is irritant, want ik wil graag het energie verbruik van mijn verlichting in mijn dashboard laten zien. Ik kan een template sensor schrijven, dat zo gauw er 1 van de Shelly's op unavailable gaat, de hele sensor op unavailable gaat... maar dat vind ik maar een matige oplossing (en gaat gegarandeerd later vragen oproepen, als ik niet meer weet dat ik dit heb gedaan ). Dus ik wil het eigenlijk in de oorzaak oplossen.

Hebben jullie suggesties waar ik zou kunnen beginnen?

[CWH]

Ik probeer dag/nachttarief in te voeren. Ik heb dit als utility_meter:

YAML:

utility_meter:
  power_day:
    source: sensor.p1_meter_3c39e72f22cc_total_power_import
    cycle: daily
    tariffs:
      - dag
      - nacht

En dit in de automation:

YAML:

alias: "Tarief wissel: dag/nacht"
triggers:
  - at: "06:00:00"
    trigger: time
  - at: "21:00:00"
    trigger: time
actions:
  - target:
      entity_id: utility_meter.power_day
    data:
      tariff: |
        {% if now().hour >= 6 and now().hour < 21 %}
          dag
        {% else %}
          nacht
        {% endif %}
    action: select.select_option
mode: single

Maar hij ziet alleen dagtarief.
Waar zit(ten) de fout(en)?

[Septillion]

@ChrisM Als oplossing voor de helper: maak een template helper die de som maakt en zorg dat deze unknow/unavailable wordt als een van de bronnen niet beschikbaar is. Want een energy sensor mag nooit lager worden. Dus een standaard group sum is niet handig daarvoor.

En waarom niet gewoon de devices individueel? Of is dat te veel clutter?

En qua Shelly's, hoe is je Wifi geregeld?

[ChrisM]

Septillion schreef op donderdag 22 mei 2025 @ 08:12:
@ChrisM Als oplossing voor de helper: maak een template helper die de som maakt en zorg dat deze unknow/unavailable wordt als een van de bronnen niet beschikbaar is. Want een energy sensor mag nooit lager worden. Dus een standaard group sum is niet handig daarvoor.

Thanks, dacht al dat ik het in die richting moet zoeken...

En waarom niet gewoon de devices individueel? Of is dat te veel clutter?

Ja, zijn er een stuk of 30... met allemaal een piepklein beetje verbruik, maar bij elkaar opgeteld is het toch wel weer significant.

En qua Shelly's, hoe is je Wifi geregeld?

Denk wel goed.. goede unifi punten verdeeld over m'n hele huis, eigenlijk nooit last dat de verbinding weg valt. Ook al eens van kanaal gewisseld.. verbinding is mega stabiel, alleen dus om de zoveel dagen, willekeurig, een minuutje geen verbinding. Is een nieuw huis, stroom is ook allemaal stabiel.

Hebben anderen die Shelly's gebruiken voor energy, niet dat deze af en toe de verbinding verliezen? Ook al is het maar voor een minuutje? Dan moet het iets in mijn set-up zijn namelijk.

[Septillion]

@CWH Je kunt een select.select_option niet toepassen op utility_meter.power_day. Sterker nog, dat bestaat niet eens als domein

Als het goed is heb je dan ook select.power_day.

[Septillion]

@ChrisM Okay, dat klinkt inderdaad wel goed. Dacht even dat je misschien dus 30+ devices op een standaard ISP doosje probeerde. Die willen dat nog wel eens te veel vinden.

[prekz]

Ik heb op dit moment 3 temperatuur sensoren in 1 ruimte:

1. Evohome radiator thermostaat: 20,3 graden
2. Aqara temp sensor: 20,93 graden
3. Airco: 22 graden

1 en 2 liggen bij elkaar. 3 hangt hier circa 1,5 meter boven dus logisch dat die iets warmer registreert. Daarnaast geloof ik niet dat de airco met decimalen werkt.

Mijn issue is dus dat er verschil in deze sensoren zit, en welke moet ik nu voor waarheid zien?
Wanneer ik 1 a 2 uur de airco aanheb zie ik .1 naar rond de 18,5 gaan, terwijl .2 naar rond de 19,5/20 gaat. Mijn gevoel zegt dat die laatste realistischer is maar hoe kan ik dit hard maken?

Zijn er sensoren die beter zijn of iets dergelijks?

[Hmmbob]

Hebben Shelly's iets van een "weekly reboot schedule", of een "automatic update" ofzo?

Omdat het zo typisch allemaal tegelijk is, zou ik het in die hoek zoeken....

[TheFes]

@ChrisM
Je moet sowieso afvangen dat er Shellies unavailable zijn in je totaal-sensor. Anders krijg je ook na elke herstart van HA een piek, omdat dan nooit alle Shelly Dimmers gelijktijdig online zullen komen. Je zult dan dus ook dips krijgen in je totaal-sensor wat voor pieken op het Energy Dashboard zorgt.

Je kunt het wel afvangen in een template sensor, die dus unavailable is als 1 van de Shelly devices unavailable is, maar besef je wel dat:

• Als er een Shelly dimmer kapot gaat, je sensor dan altijd unavailable blijft (totdat je hem aanpast)
• Het vervangen van een Shelly dimmer (omdat hij dus kapot is) voor een piek zal zorgen, omdat het totaal dan lager wordt (de nieuwe begint weer op 0)

[ChrisM]

Hmmbob schreef op donderdag 22 mei 2025 @ 08:46:
Hebben Shelly's iets van een "weekly reboot schedule", of een "automatic update" ofzo?

Omdat het zo typisch allemaal tegelijk is, zou ik het in die hoek zoeken....

Ja.. daarom post ik hier ook, want ik denk dat er meerdere Shelly gebruikers zijn die dit misschien ook kunnen zien.

[ChrisM]

TheFes schreef op donderdag 22 mei 2025 @ 08:51:
@ChrisM
Je moet sowieso afvangen dat er Shellies unavailable zijn in je totaal-sensor. Anders krijg je ook na elke herstart van HA een piek, omdat dan nooit alle Shelly Dimmers gelijktijdig online zullen komen. Je zult dan dus ook dips krijgen in je totaal-sensor wat voor pieken op het Energy Dashboard zorgt.

Je kunt het wel afvangen in een template sensor, die dus unavailable is als 1 van de Shelly devices unavailable is, maar besef je wel dat:

• Als er een Shelly dimmer kapot gaat, je sensor dan altijd unavailable blijft (totdat je hem aanpast)
• Het vervangen van een Shelly dimmer (omdat hij dus kapot is) voor een piek zal zorgen, omdat het totaal dan lager wordt (de nieuwe begint weer op 0)

Ja eens.. dat houdt me ook tegen (heb toevallig een dimmer die kapot is). Daarom wil ik het liever oplossen bij de oorzaak: waarom gaan m’n dimmers even een minuutje offline?
Het kan inderdaad wel een update van m’n unifi netwerk zijn (dat gaat automatisch ‘s nachts). Ik zal eens kijken of ik wat meer data punten kan vinden.

[TheFes]

ChrisM schreef op donderdag 22 mei 2025 @ 09:06:
[...]

Ja eens.. dat houdt me ook tegen (heb toevallig een dimmer die kapot is). Daarom wil ik het liever oplossen bij de oorzaak: waarom gaan m’n dimmers even een minuutje offline?
Het kan inderdaad wel een update van m’n unifi netwerk zijn (dat gaat automatisch ‘s nachts). Ik zal eens kijken of ik wat meer data punten kan vinden.

Ja maar je Shellies gaan ook gegarandeerd iedere keer van unavailable naar een valide state als je HA herstart. Dat zul je toch af moeten vangen.

[CAP-Team]

Zijn er nog meer mensen die zaterdag naar de community meetup in Utrecht gaan?

[Septillion]

@CAP-Team Ik had me aangemeld maar niet goed in de agenda gekeken Ik heb dus moeten annuleren. Was er graag bij geweest! Wat mensen ontmoeten, goed bier en smarthome, dat moet wel gezellig worden

[TheFes]

@CAP-Team Ik kan er helaas ook niet bij zijn. Had ook graag gegaan

[Maeslant]

TheFes schreef op woensdag 21 mei 2025 @ 23:17:
[...]

code:

{% elif hum "Run"  %}

Daar gaat iets fout...

Dat het is aangepast, maar het werkt nog steeds niet.

Wat heb ik getest:

de state als onderstaand weergegeven 'run' of 'inactive'



Hierna ook getest:

de state als 'BSH.Common.EnumType.OperationState.Inactive' of 'BSH.Common.EnumType.OperationState.Run'



Beide lukken niet. Heeft iemand hier een idee?

[Septillion]

@Maeslant Wat heb je in de tabel als state staan? En is het niet toevallig 'inactive' ipv 'Inactive'?

[tjanssen]

verjager schreef op woensdag 21 mei 2025 @ 23:48:
[...]

Ik gebruik hiervoor al een tijdje de custom Gallery Card. Die wordt sinds eind 2024 niet meer ondersteund, maar werkt nog wel. Een paar maanden geleden was er een probleem, dat had ik toen tijdelijk gefixed maar nu werkt de card weer gewoon volgens mij. Ik heb dus de fork van lukelalo nog niet nodig gehad.

YAML:

type: custom:gallery-card
entities:
  - media-source://media_source/local/camera_snapshots/deurbel/
menu_alignment: hidden
maximum_files: 20
file_name_format: YYYYMMDD-HHmmss
caption_format: "[Deurbel] D-M-YYYY [om] H:mm"
show_reload: true

Bedankt voor de tip!

[Maeslant]

Septillion schreef op donderdag 22 mei 2025 @ 19:54:
@Maeslant Wat heb je in de tabel als state staan? En is het niet toevallig 'inactive' ipv 'Inactive'?

De hoofdletter heb ik al geprobeerd. Wat bedoel je in de tabel staan?

Sorry, het is opgelost. Ik moest een dubbele = gebruiken.

YAML:

  - entity: sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate
    icon: mdi:dishwasher
    card_mod:
      style: |
        :host {
          --card-mod-icon-color:
            {% set dish = states('sensor.siemens_sx678x26te_68a40e02ad57_bsh_common_status_operationstate') %}
            {% if dish == 'BSH.Common.EnumType.OperationState.Inactive' %}
              green
            {% elif dish == 'BSH.Common.EnumType.OperationState.Finished' %}
               orange           
            {% else %}
              red
            {% endif %};
        }

[ Voor 54% gewijzigd door Maeslant op 22-05-2025 21:34 ]

[Septillion]

@Maeslant Je liet hem nu zien in de state editor, maar hoe ziet de entity eruit in de tabel eronder. Dus zoals hier (via niet alt):


[edit]Ow, pffff. Daar had ik ook overheen gekeken zeg...

Had natuurlijk eigenlijk gewoon al moeten zeggen dat je de template in Dev tools => Templates had moeten testen

[ Voor 16% gewijzigd door Septillion op 22-05-2025 21:56 ]

[Leaplasher]

Home Assistant gaat support voor een aantal cpu type en installie methodes stoppen. Waarschuwing vanaf de zomer, einde verhaal eind dit jaar:

https://www.home-assistan...thods-and-32-bit-systems/

[Septillion]

@Leaplasher Wel een tikkeltje kort door de bocht, voor install methodes is het niet einde verhaal. Ze zijn dan wel direct unsupported maar zoals daar ook aangegeven waren ze dat toch al vaak niet.

Dus wat dat betreft zat het er ook al aan te komen. En kon je eigenlijk die installatiemethodes ook al niet aanraden.

[DaRk PoIsOn]

Septillion schreef op donderdag 22 mei 2025 @ 22:38:
@Leaplasher Wel een tikkeltje kort door de bocht, voor install methodes is het niet einde verhaal. Ze zijn dan wel direct unsupported maar zoals daar ook aangegeven waren ze dat toch al vaak niet.

Dus wat dat betreft zat het er ook al aan te komen. En kon je eigenlijk die installatiemethodes ook al niet aanraden.

Maar, waarom zou je dan nog willen investeren in het opbouwen of onderhouden van systeem.
Nu zijn ze idd unsupported, maar kan je ze installeren.
Vanaf 2025.6, zijn ze nog wel Installeerbaar, maar krijgen geen updates meer en vanaf 2025.12 kun je ze helemaal niet meer installeren.

[lubbertkramer]

CAP-Team schreef op donderdag 22 mei 2025 @ 10:42:
Zijn er nog meer mensen die zaterdag naar de community meetup in Utrecht gaan?

Yes! Kon alleen niet iets van een agenda vinden waardoor ik ervanuit ga dat als je iets later bent het geen probleem is

[TheFes]

lubbertkramer schreef op vrijdag 23 mei 2025 @ 08:40:
[...]


Yes! Kon alleen niet iets van een agenda vinden waardoor ik ervanuit ga dat als je iets later bent het geen probleem is

Er is volgens mij niet echt een programma, het is meer een meetup om met andere HA gebruikers te kunnen kletsen (voor zover ik begrepen heb).

[Septillion]

@DaRk PoIsOn Dat was dus precies mijn punt Core heb ik echt nooit aan kunnen raden en Supervised ook al een hele tijd niet meer. Naar mijn idee zijn Docker en OS dus wel de methodes

Overigens wel andersom, vanaf 2025.6 worden Core, Supervised en 32-bit niet meer aangeboden om te installeren. Vanaf 2025.12 krijgen de 32-bit geen updates meer. De unsupported installs blijven updates krijgen maar met 0 garantie. Tijdens ontwikkelen en testen wordt niet meer gekeken naar deze installs en kunnen dus breaking dingen in komen.

[ Voor 3% gewijzigd door Septillion op 23-05-2025 09:23 ]

[TheFes]

DaRk PoIsOn schreef op vrijdag 23 mei 2025 @ 01:08:
[...]


Maar, waarom zou je dan nog willen investeren in het opbouwen of onderhouden van systeem.
Nu zijn ze idd unsupported, maar kan je ze installeren.
Vanaf 2025.6, zijn ze nog wel Installeerbaar, maar krijgen geen updates meer en vanaf 2025.12 kun je ze helemaal niet meer installeren.

Ook na 2025.12 kun je supervised en core nog steeds installeren. Het core team doet zelf hun development op deze installatiemethodes. Er wordt echter geen support meer op gegeven, dus als je core install niet meer werkt (bijvoorbeeld omdat je Python niet geüpdatet hebt) dan zul je dat zelf moeten uitzoeken.
Verder gebeurde het al heel vaak dat mensen supervised op bijvoorbeeld Ubuntu draaiden, of het wel op Debian draaide, maar er dan ook andere niet HA gerelateerde containers/applicaties naast draaiden. In beide gevallen was dat al niet supported.

Voor de 32 bit architectures ligt dat wat anders, daar worden de builds niet meer voor gemaakt. Nu zou je die zelf kunnen builden, maar zoals ook in de blogpost aangegeven houdt de 32bit support nu ook bepaalde updates van onderliggende componenten tegen. Als je het echt nog op een 32bit machine wil draaien, zul je die onderliggende componenten dus op oudere versies moeten pinnen, wat wellicht op andere plekken weer voor issues zorgt. Wellicht dat er wel wat mensen uit de community opstaan om dat te verzorgen, maar vanuit de OHF gaat dat dan ieder geval niet gebeuren.

[ActualFantasy]

Hoi. Ik ben compleet nieuw mbt home assistant, en ben daar momenteel mee aan het puzzelen. Heb al proberen te zoeken door dit topic heen maar het is inmiddels wel een beetje lang geworden, dus ik stel mijn vraag toch maar even hier.

Ik heb een P1 ethernet meter geinstalleerd, toegevoegd aan DSMR Smart Meter, hij vind de meter bij de integrations, maar zonder entiteiten. Ik kan er dus niks mee.

Nu heb ik wat logging aangezet, en er komen dus wel berichten binnen, want ik zie regels met received data en zo, maar goed, er komen daarna gelijk foutmeldingen waar ik geen idee heb waar ik moet beginnen.

code:

2025-05-23 09:43:33.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] keep-alive checked
2025-05-23 09:43:35.312 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=41 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=41, family=2, type=2, proto=0, laddr=('0.0.0.0', 50627)>
2025-05-23 09:43:39.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] connected
2025-05-23 09:43:39.650 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: !494B

2025-05-23 09:43:40.408 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /XMX5LGBÂLÁ4´15570779

1­3:0.2.8(50)
0-0:1.0.0(2505²3°94343S)
0-0:96.1.1¨4µ3°303435303034³2³2³6373433363138)
1-0:1.8.1(011·6·.345*kWh)
1-0:1.8.2(01±939.468*kWè)
±-0:2.8.1(003342.´1·*kWh)
1-0:2.8.2(0°7¸3¸.115*kWh)
0-0:¹6®14.0(0002)
1-0:1.7.0(°0.000*kW)
1-0:2.·.°(01.835*ëW)
0-0º9¶.·.21(0000³)
0­0º96.7.9(00001©
Š1­0:99.97.0(±)¨0­0:96.7.19)(230206075617×)¨0°00002397*s)
1-0:32®3².0(00005)
1­0:32.36.0(°0°00)
0-0:96.13.0¨)
1-0º3².·.0(235.0*V)
Š1-0:31.7®0¸008*A)
1-0º2±.7.0(00.00°*kW)
±-0:22.7.°(0
2025-05-23 09:43:40.511 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: 1.835*ëW©
0-±:²4.1.0(00³)
0-1:9¶.±.°(473030333²3µ36353532363831³9313137)
0-1º24.2.1(2µ0µ23094002Ó)(03363.µ79*m3)

2025-05-23 09:43:40.666 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: !5BDD

2025-05-23 09:43:40.666 ERROR (MainThread) [homeassistant] Error doing job: Fatal error: protocol.data_received() call failed. (None)
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 1019, in _read_ready__data_received
    self._protocol.data_received(data)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/site-packages/dsmr_parser/clients/protocol.py", line 132, in data_received
    telegram = telegram.encode("latin1").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 8: ordinal not in range(128)
2025-05-23 09:43:40.668 ERROR (MainThread) [dsmr_parser.clients.protocol] disconnected due to exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 1019, in _read_ready__data_received
    self._protocol.data_received(data)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/site-packages/dsmr_parser/clients/protocol.py", line 132, in data_received
    telegram = telegram.encode("latin1").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 8: ordinal not in range(128)
2025-05-23 09:44:02.657 WARNING (MainThread) [dsmr_parser.clients.protocol] keep-alive check failed
2025-05-23 09:44:05.315 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=41 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=41, family=2, type=2, proto=0, laddr=('0.0.0.0', 50627)>
2025-05-23 09:44:08.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] keep-alive checked
2025-05-23 09:44:10.675 DEBUG (MainThread) [dsmr_parser.clients.protocol] connected
2025-05-23 09:44:11.417 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /XMX5LGBÂLÁ4415570779

Iemand enig idee waarom ik geen entiteiten zie, en wat deze foutmeldingen betekenen?

Alvast bedankt.

[ Voor 0% gewijzigd door Septillion op 23-05-2025 09:57 . Reden: Code tags ]

[TheFes]

ActualFantasy schreef op vrijdag 23 mei 2025 @ 09:55:
Hoi. Ik ben compleet nieuw mbt home assistant, en ben daar momenteel mee aan het puzzelen. Heb al proberen te zoeken door dit topic heen maar het is inmiddels wel een beetje lang geworden, dus ik stel mijn vraag toch maar even hier.

Ik heb een P1 ethernet meter geinstalleerd, toegevoegd aan DSMR Smart Meter, hij vind de meter bij de integrations, maar zonder entiteiten. Ik kan er dus niks mee.

Nu heb ik wat logging aangezet, en er komen dus wel berichten binnen, want ik zie regels met received data en zo, maar goed, er komen daarna gelijk foutmeldingen waar ik geen idee heb waar ik moet beginnen.

--
2025-05-23 09:43:33.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] keep-alive checked
2025-05-23 09:43:35.312 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=41 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=41, family=2, type=2, proto=0, laddr=('0.0.0.0', 50627)>
2025-05-23 09:43:39.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] connected
2025-05-23 09:43:39.650 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: !494B

2025-05-23 09:43:40.408 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /XMX5LGBÂLÁ4´15570779

1­3:0.2.8(50)
0-0:1.0.0(2505²3°94343S)
0-0:96.1.1¨4µ3°303435303034³2³2³6373433363138)
1-0:1.8.1(011·6·.345*kWh)
1-0:1.8.2(01±939.468*kWè)
±-0:2.8.1(003342.´1·*kWh)
1-0:2.8.2(0°7¸3¸.115*kWh)
0-0:¹6®14.0(0002)
1-0:1.7.0(°0.000*kW)
1-0:2.·.°(01.835*ëW)
0-0º9¶.·.21(0000³)
0­0º96.7.9(00001©
Š1­0:99.97.0(±)¨0­0:96.7.19)(230206075617×)¨0°00002397*s)
1-0:32®3².0(00005)
1­0:32.36.0(°0°00)
0-0:96.13.0¨)
1-0º3².·.0(235.0*V)
Š1-0:31.7®0¸008*A)
1-0º2±.7.0(00.00°*kW)
±-0:22.7.°(0
2025-05-23 09:43:40.511 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: 1.835*ëW©
0-±:²4.1.0(00³)
0-1:9¶.±.°(473030333²3µ36353532363831³9313137)
0-1º24.2.1(2µ0µ23094002Ó)(03363.µ79*m3)

2025-05-23 09:43:40.666 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: !5BDD

2025-05-23 09:43:40.666 ERROR (MainThread) [homeassistant] Error doing job: Fatal error: protocol.data_received() call failed. (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 1019, in _read_ready__data_received
self._protocol.data_received(data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/usr/local/lib/python3.13/site-packages/dsmr_parser/clients/protocol.py", line 132, in data_received
telegram = telegram.encode("latin1").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 8: ordinal not in range(128)
2025-05-23 09:43:40.668 ERROR (MainThread) [dsmr_parser.clients.protocol] disconnected due to exception
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 1019, in _read_ready__data_received
self._protocol.data_received(data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/usr/local/lib/python3.13/site-packages/dsmr_parser/clients/protocol.py", line 132, in data_received
telegram = telegram.encode("latin1").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 8: ordinal not in range(128)
2025-05-23 09:44:02.657 WARNING (MainThread) [dsmr_parser.clients.protocol] keep-alive check failed
2025-05-23 09:44:05.315 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 101] Network unreachable, transport: <_SelectorDatagramTransport fd=41 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=41, family=2, type=2, proto=0, laddr=('0.0.0.0', 50627)>
2025-05-23 09:44:08.623 DEBUG (MainThread) [dsmr_parser.clients.protocol] keep-alive checked
2025-05-23 09:44:10.675 DEBUG (MainThread) [dsmr_parser.clients.protocol] connected
2025-05-23 09:44:11.417 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /XMX5LGBÂLÁ4415570779
--

Iemand enig idee waarom ik geen entiteiten zie, en wat deze foutmeldingen betekenen?

Alvast bedankt.

Heb je het juiste DSMR type gekozen tijdens de config van de integratie?

[ActualFantasy]

TheFes schreef op vrijdag 23 mei 2025 @ 09:56:
[...]


Heb je het juiste DSMR type gekozen tijdens de config van de integratie?

Er was maar 1 type wat hij pakte en dat was 5S. Bij alle andere gaf hij verbindingserrors.

Ik heb ook diagnostiek gegevens even bekeken en ik weet dus niet of dit klopt, maar in die json staat

code:

"setup_times": {},
  "data": {
    "entry": {
      "data": {
        "host": "verborgen",
        "port": verborgen,
        "dsmr_version": "5S",
        "serial_id": null,
        "serial_id_gas": null,
        "protocol": "dsmr_protocol"
      },
      "unique_id": null
    },
    "data": null

Geen idee of die NULL daar moeten staan, maar had daar ook wel iets verwacht eigenlijk

[ Voor 48% gewijzigd door ActualFantasy op 23-05-2025 09:59 ]

[Septillion]

@ActualFantasy 5S is voor Zweden, dus tenzij je daar woont is dat de verkeerde...

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 09:58:
@ActualFantasy 5S is voor Zweden, dus tenzij je daar woont is dat de verkeerde...

Maar bij alle andere krijg ik "kan niet verbinden"

[Septillion]

@ActualFantasy Welke meter van de netbeheerder heb je?

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 10:02:
@ActualFantasy Welke meter van de netbeheerder heb je?

[Septillion]

@ActualFantasy Dan zou je gewoon '5' als type moeten selecteren.

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 10:16:
@ActualFantasy Dan zou je gewoon '5' als type moeten selecteren.

Ok. Daarmee verbind hij niet, dan krijg ik kon geen verbinding maken.

Vraag mij af of ik die entiteiten handmatig moet toevoegen dan of zo?

Had ik toch beter de slimmelezer+ kunnen pakken ipv de p1 ethernet meter?

[CappieL]

Entiteiten zou je niet handmatig moeten toevoegen.
Welke "P1>ethernet-meter" gebruik je?

[Ben(V)]

Welke p1 interface gebruik je.
Die E350 gebruikt 115200 baud en heeft een pull-up weerstandje nodig tussen VCC en Rdx.

Ook heeft hij geïnverteerde data, dus "1" is 0V en "0" is 5V, dat moet je instellen in de P1 naar ethernet converter waarmee je aansluit.

[ActualFantasy]

CappieL schreef op vrijdag 23 mei 2025 @ 10:58:
Entiteiten zou je niet handmatig moeten toevoegen.
Welke "P1>ethernet-meter" gebruik je?

https://www.zuidwijk.com/product/p1-reader-ethernet/

Deze.

Factory defaults, poort 23 tcp server erop. In de statistieken zie ik dat op zowel p1 poort als op seriel poort data binnenkomt.

Maar als ik die toevoeg aan HA, dan vind hij hem alleen met DSMR 5S. Met 5, vind hij hem niet.

[alex3305]

Ik kan me eigenlijk niet voorstellen dat iemand nog HA Supervised draait. Want in de praktijk werd die methode ook al niet echt meer 'ondersteund'. Ik heb een aantal jaar deze installatiemethode gedraaid, maar de ontwikkelaars hebben deze manier een aantal jaar geleden al aardig praktisch onbruikbaar gemaakt.

Initieel had ik de voorkeur voor Supervised omdat ik eigen controle wilde houden over de Docker stack (en containers), maar tegelijkertijd de HA add-ons wilde gebruiken. Dat heeft een aantal jaar goed gewerkt, totdat ik bij een herinstallatie ineens tegen de verplichte eisen in ADR-0014 aanliep. Ook daar kon ik nog wel aardig mee uit de voeten, totdat in 2021 plots tevens de meeste recent OS Agent verplicht werd bij een Supervised installatie.

Op zichzelf is dat niet erg, behalve dat bij een niet transparante en niet uit te schakelen automatische update van Supervisor het systeem unhealthy kon worden. Dat was ook niet altijd even duidelijk, behalve dan vaak maar een of twee regels in de logs. Dat werd alleen maar erger toen ook Portainer als unhealthy container gezien werd.

Ik begrijp de volledige controle, mede ook door de mogelijk vele supportvragen door prutsconfiguraties, maar deze verplichtingen zorgden er m.i. voor dat Supervisor geen enkele meerwaarde meer had. Ik ben ook echt benieuwd wie dat nog daadwerkelijk gebruikt.

Ik ben toen van Supervisor naar OS gegaan, in een VM. En later naar Container. En dat laatste gebruik ik nu nog steeds. Container werkt op zichzelf prima, maar ook die installatie instructies vind ik nogal vaag. Het verplichten van root en privileged zonder enige uitleg vind ik waardeloos. Idem voor de kneuterige update instructies.

De Linuxserver.io container doet dat dan een stuk beter. De enige reden dat ik die niet gebruik is omdat het mij niet zou verbazen als ook die installatiemethode vakkundig wordt koudgemaakt.

[Septillion]

@ActualFantasy Eigenlijk wel gekke melding omdat het meer klinkt of HA dan geen verbinding kan maken met het device dan dat device niet werkt. En ook raar dat het selectief is op basis van protocol...

- Heeft device aan vast IP?
- En die geef je op incl port 23?
- Moet je in de webinterface van dat ding soms nog de baudrate instellen? Die moet dus op 115200 baud staan.

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 13:44:
@ActualFantasy Eigenlijk wel gekke melding omdat het meer klinkt of HA dan geen verbinding kan maken met het device dan dat device niet werkt. En ook raar dat het selectief is op basis van protocol...

- Heeft device aan vast IP?
- En die geef je op incl port 23?
- Moet je in de webinterface van dat ding soms nog de baudrate instellen? Die moet dus op 115200 baud staan.

Yep, ik ben het met je eens. Het lijkt alsof op basis van het protocol er wel of niet verbinding gemaakt kan worden.

Vast ip ja.
Poort geef ik ook op









Er is blijkbaar een topic op github met iemand die dit ook heeft, maar snap nog niet waarom het bij hem wel werkt dan.

https://github.com/home-assistant/core/issues/139398

Net een extra communicatiepoort aangemaakt op de p1 meter. Telnet deamon.

Putty opgestart en alle gegevens rollen zo binnen. Dus die kant, naar de meterkast werkt.

[ Voor 8% gewijzigd door ActualFantasy op 23-05-2025 14:56 ]

[Sp33dFr34k]

Even een check, ik heb een custom:mushroom-template-card, waarvan ik nu de icon heb vervangen door een picture. Als ik dat doe, dan werkt de hold action niet meer op de Android mobile app, via de webinterface werkt het wel nog. Zet ik het terug van picture naar icon, dan werkt het weer. Is dit een bekende bug dat iemand weet? En zonee, waar meld ik dit het beste?

[Septillion]

@alex3305 Heb het hier toch nog wel langs zien komen waarna ik het altijd heb afgeraden. Overigens is er niets verandert aan de bruikbaarheid, alleen aan de eisen voor supported zijn. Eerst gewoon strikter, tot nu gewoon niet supported. Het levert te gewoon te veel gezeik op van mensen waarvoor Linux boven hun pet is. En omdat het zo veel dingen gebruikt was het zo makkelijk om dus afhankelijkheden om zeep te helpen.

En voor de paar die het wel draaien en er niet z'n probleem mee hebben dat ze het unsupported draaide verandert er nu eigenlijk ook gewoon niets Het wordt nu vooral duidelijker dat aan die installatie echt wel haken en ogen zitten. De vragen van @rens-br in januari geeft dat al mooi weer aan. Dus denk dat het goed is om het niet meer als officiële / supported install aan te bieden en het puur voor devers (en zelf redzame) te laten.

[FredvZ]

ActualFantasy schreef op vrijdag 23 mei 2025 @ 14:07:

Is er een specifieke reden dat je DSMR 5S wil gebruiken?

[FredvZ]

Vandaag popte mijn Eufy Homebase3 als HomeKit spontaan op bij mijn devices in HA.
Heeft iemand al enig idee hoe je dat verder in moet stellen?

Als ik het in wil stellen vraagt HA om een "HomeKit pairing code". Ik heb 0,0 ervaring met Homekit, hoe kom ik aan die code?

[BiG-GuY]

@alex3305
De LinuxServer.io Docker container is nooit ondersteund geweest door Nabu Casa. Alleen de officiële eigen methodes worden door hun ondersteund.

Als er iets is met je install wanneer je een third party Docker Container gebruikt, dien je voor Support naar degene te gaan die het aangepast heeft.

Draai daarom zelf ook maar gewoon de officiële Container versie. Dat je Root moet zijn qua user heeft o.a. te maken met hoe ze de partities aanmaken binnen de Container. De LinuxServer.io versie is aangepast en draait scripts bij launch die de user mapping verzorgen.

Ook heb je Host netwerk nodig voor o.a. mDNS en Discovery.

[RobertMe]

BiG-GuY schreef op vrijdag 23 mei 2025 @ 18:32:
Ook heb je Host netwerk nodig voor o.a. mDNS en Discovery.

Nee, eigenlijk niet. Je kunt de container ook via macvlan of ipvlan aan het netwerk hangen. Dan hangt die ook gewoon rechtstreeks aan het netwerk, maar wel nog steeds via een eigen (virtuele) "poort" met een eigen IP adres etc..

Ik heb echt nog nooit een container met host network mode gedraaid. En toch heb ik prima mDNS & SSDP discovery.

[BiG-GuY]

RobertMe schreef op vrijdag 23 mei 2025 @ 18:38:
[...]

Nee, eigenlijk niet. Je kunt de container ook via macvlan of ipvlan aan het netwerk hangen. Dan hangt die ook gewoon rechtstreeks aan het netwerk, maar wel nog steeds via een eigen (virtuele) "poort" met een eigen IP adres etc..

Ik heb echt nog nooit een container met host network mode gedraaid. En toch heb ik prima mDNS & SSDP discovery.

Toen ik vroeger HomeKit gebruikte samen met Home Assistant kreeg ik dat niet stabiel zonder Host network voor Home Assistant. Maar dat is al een tijd geleden dat ik dat geprobeerd had via een andere weg.

Heb een hele tijd Home Assistant OS gedraaid, dat werkte altijd zonder problemen of gedoe op Host niveau.

[Septillion]

Host network is wel de grootste downer als het gaat om de HA Container Want je hebt gewoon geen enkel idee welke poorten nu in gebruik zijn. macvlan of gewoon transparant zijn bij elke integratie welke poorten je nodig hebt zou naar mijn idee veel mooier zijn.

[Ben(V)]

ActualFantasy schreef op vrijdag 23 mei 2025 @ 14:07:
[...]

Yep, ik ben het met je eens. Het lijkt alsof op basis van het protocol er wel of niet verbinding gemaakt kan worden.

Vast ip ja.
Poort geef ik ook op

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Er is blijkbaar een topic op github met iemand die dit ook heeft, maar snap nog niet waarom het bij hem wel werkt dan.

https://github.com/home-assistant/core/issues/139398

Net een extra communicatiepoort aangemaakt op de p1 meter. Telnet deamon.

Putty opgestart en alle gegevens rollen zo binnen. Dus die kant, naar de meterkast werkt.

Dat je wel een "DSMR 5S" komt door een foutje in de code waardoor hij die altijd accepteert maar niet gaat werken als je niet echt een 5S hebt.

Als je met je browser het adres van dat device benadert kom je in zijn configuratie pagina waar je vanalles kunt instellen.
Zie:
https://www.zuidwijk.com/category/faq/ethernet-e20/

[manusjevanalles]

Ik probeer een device_tracker toe te voegen die een mobiel pingt. Ik heb daarvoor de volgende code in configuration.yaml toegevoegd:

YAML:

device_tracker:
 - platform: ping
   interval_seconds: 20
   consider_home: 300
   hosts:
    ping_xxx: 10.0.0.100

Als ik vervolgens

YAML:

action: device_tracker.see
data:
  dev_id: ping_xxx

Uitvoer, dan zie ik dat de device_tracker is toegevoegd (hij verdwijnt wel weer na verloop van tijd). Maar de status blijft altijd op "home" staan, zelfs als de mobiel niet verbonden is (en fysiek afwezig is).

Bij developers tools > states zie ik hem staan, maar met states

YAML:

source_type: gps
friendly_name: ping_xxx

Ik krijg het niet aan de praat. Als ik bij settings > devices & services de ping-integratie toevoeg, dan pingt hij zonder problemen de mobiel en geeft netjes wel/niet connected aan.

Wat doe ik fout hier?

[ActualFantasy]

Ben(V) schreef op vrijdag 23 mei 2025 @ 19:59:
[...]


Dat je wel een "DSMR 5S" komt door een foutje in de code waardoor hij die altijd accepteert maar niet gaat werken als je niet echt een 5S hebt.

Als je met je browser het adres van dat device benadert kom je in zijn configuratie pagina waar je vanalles kunt instellen.
Zie:
https://www.zuidwijk.com/category/faq/ethernet-e20/

Bedankt, ik was al zo ver. Ik heb inmiddels contact met de maker van de P! meter, en ik heb denk ik wel wat gevonden.

Aan de hand van hoe het rj11 kabeltje door mijn meterkast hangt, krijg ik een beter of slechter signaal.....

Ik had net heel even dat het lukte om hem toe te voegen met dsmr 5, en hij had 3 entiteiten gevonden, maar nu is hij weer pleite.
Er lijkt dus iets te storen....

[Ben(V)]

Hoe ziet de kabel naar de p1 poort eruit?
Als het zo'n platte kabel is dan zijn de aders niet getwist en veel storing gevoeliger.

Korte kabel en device vlak bij de meter is altijd het beste.

[ Voor 19% gewijzigd door Ben(V) op 23-05-2025 20:24 ]

[ActualFantasy]

Ben(V) schreef op vrijdag 23 mei 2025 @ 20:21:
Hoe ziet de kabel naar de p1 poort eruit?
Als het zo'n platte kabel is dan zijn de aders niet getwist en veel storing gevoeliger.

Korte kabel en device vlak bij de meter is altijd het beste.

De kabel is 50cm, en idd plat.

Eens zoeken of ik ergens in huis nog een andere kabel heb, en wat korter.

Zilverfolie werkt averechts heb ik net gemerkt.

[RobertMe]

Septillion schreef op vrijdag 23 mei 2025 @ 19:45:
Host network is wel de grootste downer als het gaat om de HA Container Want je hebt gewoon geen enkel idee welke poorten nu in gebruik zijn. macvlan of gewoon transparant zijn bij elke integratie welke poorten je nodig hebt zou naar mijn idee veel mooier zijn.

Host network zal niet te maken hebben met transparantie in welke poorten gebruikt worden. Maar het is wél de makkelijkste optie om niet achter de bridge te zetten. Want als de container achter een bridge zit dan zit die dus in zijn eigen subnet en daarmee broadcast domain. Oftewel: dan werkt de mDNS / SSDP / elke andere vorm van discovery niet.

En bij dedicated hardware maakt host wellicht ook niet perse heel erg uit.

Maar ik heb een machientje waar een stuk of 5, 6 VLANs op binnen komen. En HA mag uiteraard alleen in het IoT VLAN zitten. En als ik host network mode zou gebruiken dan zou HA natuurlijk ineens in alle VLANs zitten te rommelen. Dus ik hem hem achter macvlan hangen (en de rest achter bridges waarbij ik ip rules heb die afhankelijk van de "binnenkomende" bridge een andere routing tabel gebruiken).

[Septillion]

@RobertMe Ja, multicast is dan ook wel een dingetje ja. Maar goed, poorten net zo goed. Als jij vervolgens doodleuk een andere container opzet en die geef je poort 6053 dan ben je ook ESPhome kwijt...

Dus mja, ook dan moet je dus wel een beetje opletten.

[Septillion]

@ActualFantasy Shielding heeft alleen zin als je deze aan de aarde hangt.

Andere kant, zo lang is 50cm nu ook niet. Kan je het niet gewoon lekker dicht bij de meter houden allemaal?

RJ12 kabels zijn niet meer zo wijdverspreid...

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 20:47:
@ActualFantasy Shielding heeft alleen zin als je deze aan de aarde hangt.

Andere kant, zo lang is 50cm nu ook niet. Kan je het niet gewoon lekker dicht bij de meter houden allemaal?

RJ12 kabels zijn niet meer zo wijdverspreid...

Ik heb hem net een keer zo kort mogelijk opgerold, maar dat maakt het alleen maar erger. Twijfel of de kabel wel gewoon goed is. Maar laatste keer dat ik een rj11 kabeltje in het wild zag was 10 jaar terug of zo...

[Septillion]

@ActualFantasy Begin ik eerder te twijfelen of de kabel wel goed is of dat er gewoon een ader van de kabel slecht contact maakt...

[Ben(V)]

Denk ik ook, 50cm zou geen storing moeten oppikken, ik gebruik hier 2m

[ActualFantasy]

Septillion schreef op vrijdag 23 mei 2025 @ 21:02:
@ActualFantasy Begin ik eerder te twijfelen of de kabel wel goed is of dat er gewoon een ader van de kabel slecht contact maakt...

Ga morgen wel even op zoek naar andere kabel. Ik heb hem nu nog een keer opgerold en in de poort gepropt…



En voila!!


3 minuten later zijn de entities weer onbereikbaar. Moet dus wel breuk in de kabel zijn of zo.

[ Voor 4% gewijzigd door ActualFantasy op 23-05-2025 21:12 ]

[alex3305]

BiG-GuY schreef op vrijdag 23 mei 2025 @ 18:32:
De LinuxServer.io Docker container is nooit ondersteund geweest door Nabu Casa. Alleen de officiële eigen methodes worden door hun ondersteund.

Ik heb het ook niet over supported hè. Ik heb het over onklaar maken. Al dan niet bewust. Dat gebeurde dus ook met de Supervisor installatie met het plots - want dat was het eigenlijk - verbieden van Watchtower en later Portainer. En dat Watchtower niet toegestaan wordt dat snap ik ook wel. Immers is het vragen om problemen wanneer Supervisor en andere infra container (o.a. DNS) op de achtergrond onverwacht geüpdatet worden. Maar Portainer was IMHO gewoon flauw. Want waarom de ene management container niet en de ander wel? Omdat de een populairder is dan de ander? Daarbij klinkt het niet echt alsof er over nagedacht is.

Wat mij betreft had destijds al de stekker uit Supervised getrokken mogen worden. Misschien komt het over alsof ik de mensen achter HA iets kwalijk neem, maar dat is niet zo. Wel vond ik het onaangenaam dat dergelijke ingrijpende beslissingen (bijv. verboden containers of aanvullende applicatie-eisen) zonder duidelijke overgangsperiode werden toegepast. Met name omdat Supervisor automatisch update en deze niet zomaar teruggerold kon worden.

De praktische bruikbaarheid, en met name het onderhoud, was al jaren enorm beroerd @Septillion. Want ook bij problemen was je nogal op jezelf aangewezen. Voor mij was de maat vol toen mijn systeem op een zondagmiddag plots Unhealthy werd en ik niets meer kon. Ik kon niets meer updaten en bij een reboot kwam ik niet eens verder dan Safe Mode . Toen bleek dat mijn Debian versie vanaf de - net automatisch geüpdatet - Supervisor versie niet meer ondersteund werd . Terugrollen was onmogelijk en ik had echt he-le-maal geen trek in een spontane OS upgrade.

Die middag ben ik halsoverkop naar een VM verkast. Dat ging enorm soepel, moet ik toegeven. Maar thuis heb ik eerlijk gezegd weinig trek in dit soort onaangename verrassingen...

Als er iets is met je install wanneer je een third party Docker Container gebruikt, dien je voor Support naar degene te gaan die het aangepast heeft.

Daar hoeven we geen discussie over te hebben. Maar ik verwacht wel van een Home Assistant container, ongeacht de bron, dat deze stabiel is. Want ik weet niet hoe het met jullie zit, maar ik ben op sommige vlakken aardig afhankelijk van Home Assistant.

Draai daarom zelf ook maar gewoon de officiële Container versie. Dat je Root moet zijn qua user heeft o.a. te maken met hoe ze de partities aanmaken binnen de Container. De LinuxServer.io versie is aangepast en draait scripts bij launch die de user mapping verzorgen.

Ik gebruik geen privileged in mijn container. Immers gebruik ik toch geen hardware. Wel vind ik deze instelling enorm kort door de bocht. Door middel van én root én privileged kan de Home Assistant container theoretisch bij heel mijn systeem en aangesloten apparaten. Ik vind dat anno 2025 voor een project als Home Assistant niet meer kunnen.

De Linuxserver.io manier is eveneens brak, maar zorgt onder water in ieder geval nog voor een klein beetje scheiding. En beschermt voornamelijk tegen bijvoorbeeld exploits in de gedraaide applicatie.

Ook heb je Host netwerk nodig voor o.a. mDNS en Discovery.

Dat werkt zoals @RobertMe terecht opmerkt ook prima met een mac- of ipvlan netwerk. Wellicht dat dit zelfs te doen is met een bridge of overlay netwerk en de benodigde iptables masquarading regels. Dat werkt immers ook vanuit o.a. Xiaomi apparaten en Home Assistant op aparte VLANs:

Bash:

# Home Assistant discovery exception for Xiaomi devices
iptables -t nat -A POSTROUTING -o wl0.1 -s homeassistant -d 192.168.0.0/16 -j MASQUERADE

[HuismAndré]

Septillion schreef op vrijdag 23 mei 2025 @ 20:47:
@ActualFantasy Shielding heeft alleen zin als je deze aan de aarde hangt.

Gelukkig niet (want dan zou je in een vliegtuig wel een probleempje hebben). Shielding werkt als je de stoorsignalen die erop terecht komen onderdeel kunt maken van je referentie. Dat kun je doen door je referentie laagohmig aan aarde te hangen (want dan sluit je de storing effectief kort) óf door de referentie mee te laten zweven met de storing (zoals je bijvoorbeeld bij _elke_ audio aansluiting van een volledig in klasse-2 (zonder randaarde) uitgevoerd audiosysteem doet). Als je dan gaat meten wat de referentie is ten opzichte van de aarde dan zie je dat deze op de helft van het lichtnet hangt (met daarbij opgeteld de stoorsignalen die via verbindingskabels komen).

Maar goed.. Dit alles is wel een beetje off-topic. Om het dan toch een beetje on-topic te maken. Een eventuele shield zou je kunnen knopen aan Pin-3 óf aan Pin-6 (uitproberen welke het beste resultaat geeft (ik gok op pin-3)).



Persoonlijk denk ik trouwens eerder dat er sprake is van een draadbreuk of een ander defect (9600 baud is zo slakkegangtraag dat je bij 50cm bijna onmogelijk ellende kunt krijgen)..

[Septillion]

@HuismAndré Ik gebruikte hier inderdaad aarde als Nederlandse vertaling van ground/GND ofwel de referentie

En grappig, uit wel document heb jij dat schema? Ik ken alleen die uit de 5.0.2 spec en daar hangen pin3 en pin6 hard aan elkaar.

PS DSMR 5 doet 115200, nog niet heeeel schokkend.

[synoniem]

Grootste probleem met HA vind ik nog steeds de breaking changes al dan niet gedocumenteerd. Het mooiste zou zijn als er LTS en bleeding edge versies waren. De basale zaken wil ik geen tijd aan kwijt zijn bij een update. Verbeteringen in het dashboard zoals afgelopen tijd zou ik liever in een testomgeving uitgebreid uitproberen voordat ik het loslaat op de "productieomgeving". Maar ik wil ook niet te ver achterlopen met updaten.

En ja het gecreëerde "gedoe" met Unhealthy in de supervised versie was ik ook niet heel blij mee. Voor mij ook reden om dan maar HA-OS virtueel te gaan draaien maar niet van harte.

[RobertMe]

alex3305 schreef op vrijdag 23 mei 2025 @ 21:15:
[...]

Dat werkt zoals @RobertMe terecht opmerkt ook prima met een mac- of ipvlan netwerk. Wellicht dat dit zelfs te doen is met een bridge of overlay netwerk en de benodigde iptables masquarading regels. Dat werkt immers ook vanuit o.a. Xiaomi apparaten en Home Assistant op aparte VLANs:

Bash:

# Home Assistant discovery exception for Xiaomi devices
iptables -t nat -A POSTROUTING -o wl0.1 -s homeassistant -d 192.168.0.0/16 -j MASQUERADE

Voor mDNS kun je natuurlijk een mDNS repeater / reflector gebruiken. Da's een redelijk standaard practice, want als je een wat geavanceerdere netwerk setup hebt met VLANs kan het best zijn dat je ook daarbij mDNS over de VLANs wilt hebben. En een mDNS reflector op de router (bv) zorgt er dan voor dat binnenkomende mDNS Requests op de ene poort gekopieerd (/herhaald / herschreven / unieke requests met dezelfde vraag) worden op een andere poort.
En voor SSDP zijn er ook dat soort trucjes.

En dat werkt natuurlijk net zo goed op een Docker host tussen de "fysieke" poort en de virtuele bridge als op een router met 2 fysieke poorten (of 2 VLANs op een poort).

[RobertMe]

synoniem schreef op vrijdag 23 mei 2025 @ 22:23:
Grootste probleem met HA vind ik nog steeds de breaking changes al dan niet gedocumenteerd.

Zijn ongedocumenteerde breaking changes geen bugs?

Als in: ongedocumenteerd kan ik mij alleen echte bugs herinneren (die vaak ook wel gefixt zijn in een patch versie).

[savagenld]

Ik heb hier een Android tablet aan de muur hangen. Als er genavigeerd wordt naar een ander tabblad, dan wordt er na afloop natuurlijk niet meer terug genavigeerd en blijft die tab de hele tijd open.

Ik ga niet eens proberen om de huisgenoten over te halen om terug te navigeren naar de eerste tab, die ga ik zeker verliezen . Dus heb ik oa de idle refresh van Fully kiosk browser geprobeerd. Maar als ik die op 5min zet zie ik hem nog steeds vaak refreshen als het scherm weer aan gaat. 2 sec extra wachten, klinkt niet erg, maar soms wel frustrerend.

Nu zie ik wel add-ons als ViewTimeout, maar dan schrik ik een beetje van de complexiteit.

Ik ben zeker niet de enige met dit probleem. Zijn er nog andere manieren om dit te fixen?

[HuismAndré]

Septillion schreef op vrijdag 23 mei 2025 @ 21:44:
@HuismAndré Ik gebruikte hier inderdaad aarde als Nederlandse vertaling van ground/GND ofwel de referentie

En grappig, uit wel document heb jij dat schema? Ik ken alleen die uit de 5.0.2 spec en daar hangen pin3 en pin6 hard aan elkaar.

https://conxxion.nl/?page_id=3641

(ging me vooral om aan te geven dat de uitgang compleet galvanisch gescheiden is oftewel zweeft als een dolle).

115k2 dacht ik ook al (maar ik kwam hier 9600 tegen dus dacht "dan zal ik het me wel verkeerd herinneren").

[Hmmbob]

savagenld schreef op vrijdag 23 mei 2025 @ 22:35:
Ik heb hier een Android tablet aan de muur hangen. Als er genavigeerd wordt naar een ander tabblad, dan wordt er na afloop natuurlijk niet meer terug genavigeerd en blijft die tab de hele tijd open.

Ik ga niet eens proberen om de huisgenoten over te halen om terug te navigeren naar de eerste tab, die ga ik zeker verliezen . Dus heb ik oa de idle refresh van Fully kiosk browser geprobeerd. Maar als ik die op 5min zet zie ik hem nog steeds vaak refreshen als het scherm weer aan gaat. 2 sec extra wachten, klinkt niet erg, maar soms wel frustrerend.

Nu zie ik wel add-ons als ViewTimeout, maar dan schrik ik een beetje van de complexiteit.

Ik ben zeker niet de enige met dit probleem. Zijn er nog andere manieren om dit te fixen?

Fully kiosk heeft je ook een entity in HA op welke pagina je zit. Je kan daarop automatiseren (met een gewone HA automation) en met bijvoorbeeld browser_mod een "navigate" commando geven naar je main page na 2 minuten ofzo

Edit: ik doe iets soortgelijks voor de screensaver:
https://github.com/hmmbob...eral/kiosk.yaml#L100-L141

[ Voor 9% gewijzigd door Hmmbob op 24-05-2025 08:26 ]

[Dutchess_Nicole]

savagenld schreef op vrijdag 23 mei 2025 @ 22:35:
Ik heb hier een Android tablet aan de muur hangen. Als er genavigeerd wordt naar een ander tabblad, dan wordt er na afloop natuurlijk niet meer terug genavigeerd en blijft die tab de hele tijd open.

Ik ga niet eens proberen om de huisgenoten over te halen om terug te navigeren naar de eerste tab, die ga ik zeker verliezen . Dus heb ik oa de idle refresh van Fully kiosk browser geprobeerd. Maar als ik die op 5min zet zie ik hem nog steeds vaak refreshen als het scherm weer aan gaat. 2 sec extra wachten, klinkt niet erg, maar soms wel frustrerend.

Nu zie ik wel add-ons als ViewTimeout, maar dan schrik ik een beetje van de complexiteit.

Ik ben zeker niet de enige met dit probleem. Zijn er nog andere manieren om dit te fixen?

There's an automation for that:

YAML:

alias: Reset Tabviewer screen to default when page changes
description: ""
triggers:
  - entity_id:
      - sensor.tabviewer_current_page
    id: tabviewer
    attribute: full_url
    not_from:
      - unavailable
      - unknown
    not_to:
      - unavailable
      - unknown
    trigger: state
  - entity_id:
      - sensor.tabviewer2_current_page
    id: tabviewer2
    attribute: full_url
    not_from:
      - unavailable
      - unknown
    not_to:
      - unavailable
      - unknown
    trigger: state
conditions: []
actions:
  - if:
      - condition: template
        value_template: "{{ 'thermostat-view/home' not in states(trigger.entity_id) }}"
    then:
      - delay:
          hours: 0
          minutes: 5
          seconds: 0
          milliseconds: 0
      - data: {}
        target:
          entity_id: button.{{ trigger.id }}_load_start_url
        action: button.press
mode: parallel
max: 5

Dit zal voor een veelvoud van walldisplays zorgen dat ze weer teruggezet worden naar wat je een nuttige start_url vindt.

Dit werkt al een paar jaar nu prima met Fully Kiosk.