Home Assistant: Open source Python3 home automation - deel 5

[Hmmbob]

Gonzalez schreef op maandag 11 november 2024 @ 13:06:
[...]

Hier ook een probleem met updaten naar 2024.11.3.
Krijg nu de melding ongezond systeem omdat de update is mislukt.

Zelfs op de frontpage nu: nieuws: Updates of installaties van Home Assistant Supervisor werken niet doo...

[Hmmbob]

En in ander nieuws:



25.000 posts in dit topic

[Gonzalez]

Hmmbob schreef op maandag 11 november 2024 @ 15:28:
[...]

Zelfs op de frontpage nu: nieuws: Updates of installaties van Home Assistant Supervisor werken niet doo...

Bij mij is de update er ondertussen doorgekomen.
Had nog eens een poging gedaan na een reactie onder het nieuwsartikel.

[Hmmbob]

Gonzalez schreef op maandag 11 november 2024 @ 15:36:
[...]

Bij mij is de update er ondertussen doorgekomen.
Had nog eens een poging gedaan na een reactie onder het nieuwsartikel.
[Afbeelding]

Ik ben benieuwd wat de oplossing dan was, want in de Supervisor repo staat geen commit oid

https://github.com/home-assistant/supervisor

[D4NG3R]

Hmmbob schreef op maandag 11 november 2024 @ 15:39:
[...]

Ik ben benieuwd wat de oplossing dan was, want in de Supervisor repo staat geen commit oid

https://github.com/home-assistant/supervisor

ghcr.io/home-assistant/amd64-hassio-supervisor:2024.11.3 klapt niet langer dicht op TOOMANYREQUESTS en wijst nu daadwerkelijk door naar de 11.3 package.

Iets specifieker, ze hebben zitten experimenteren met het updatemechanisme waardoor ghcr ingreep: https://github.com/home-a...aead5426522b233e04c4645a3

The upload and signing of version files to ghcr.io was an experiment and
is not really necessary. Let's drop it. This should unblock our CI and
allow updating the version file (which is currently blocked due to the
request rate limiting).

@Hayte hoop dat je het niet erg vind dat ik je hier tag, maar inmiddels werkt het dus weer.
nieuws: Updates of installaties van Home Assistant Supervisor werken niet doo...

offtopic:
Overigens:

Dat is alleen relevant voor zelfgehoste installaties.

Dat is alleen relevant voor supervised en HAOS installaties.

https://www.home-assistant.io/integrations/hassio/

[ Voor 63% gewijzigd door D4NG3R op 11-11-2024 16:08 ]

[TheFes]

RobertMe schreef op maandag 11 november 2024 @ 15:24:
[...]

Dus de HA smart speaker kan gebruikt worden als afspeelapparaat in Music Assistant?
Ik vermoed dan gewoon dat elke (ESPHome) media_player entity gebruikt kan worden met Music Assistant? * RobertMe is niet zo bekend met Music Assistant, maar dat klinkt wel handig dan. Uiteraard ook omdat ESPHome geen ondersteuning heeft voor Spotity / Tidal / ... en ik dus vermoed dat je via Music Assistant die wel kunt gebruiken?

Ja klopt, een ESPHome media_player kan voor Music Assistant gebruikt worden. En je kunt via Music Assistant inderdaad je streaming services gebruiken.

[Gizz]

@TheFes je eerste ervaringen klinken goed! Zelf niks qua slimme speakers van Google of Amazon in huis, maar zodra er een goede open source optie is wil ik stembesturing wel overwegen.

Werkt het ook goed in verschillende talen tegelijkertijd, dat bijvoorbeeld user 1 Engels praat en user 2 Nederlands?

[TheFes]

Gizz schreef op maandag 11 november 2024 @ 16:26:
@TheFes je eerste ervaringen klinken goed! Zelf niks qua slimme speakers van Google of Amazon in huis, maar zodra er een goede open source optie is wil ik stembesturing wel overwegen.

Werkt het ook goed in verschillende talen tegelijkertijd, dat bijvoorbeeld user 1 Engels praat en user 2 Nederlands?

Daar zijn wellicht wel mogelijkheden voor, het zal ook aan de hardware liggen. Als je HA de wakeword detectie laat doen met Open Wakeword, zou je verschillene wakewords kunnen gebruiken en daar een andere voice pipeline aan hangen.
Ook zou je gebruik kunnen maken van een LLM ipv Assist, die zowel NL als EN ondersteunt. Maar als je dat lokaal wil houden heb je flinke hardware nodig om dat LLM een beetje snel te laten reageren.

Als je microwakeword wil gebruiken waarbij de voice satellite zelf de wake word detectie doet, ben je beperkt tot één wakeword, dan zou het LLM dus nog wel een optie kunnen zijn.

[gomaster]

TheFes schreef op maandag 11 november 2024 @ 15:13:
Ik ben sinds vorige week een stuk actiever bezig met Assist en de mogelijkheden die voice control via HA biedt. En ik moet zeggen dat ik erg enthousiast ben. Ik was natuurlijk al even de language leader voor Nederlands, maar ik gebruikte het eigenlijk zelf niet echt. Mijn huis stond nog vol met Google Home speakers, en er was nog niet echt een trigger om over te stappen.

Die trigger kwam echter vorige week, en inmiddels ben ik over. Alle Google Home speakers zijn ontkoppeld en ik gebruik nu Assist.

Erg leuk is dat je het kunt combineren met een LLM. Zo heb ik een automation om muziek af te spelen, waarbij de query naar ChatGPT gaat, en die dan een json value teruggeeft met wat voor type muziek het is (album, track, playlist, radio) en wat er afgespeeld moet worden en in welke ruimte. Dat stuur ik dan vervolgens naar Music Assistant, en de gewenste muziek wordt afgespeeld.

Nog niet alles is ondersteund, maar met een sentence trigger in een automation, kun je veel zelf toevoegen. Zo heb ik een automation gemaakt die (ook weer met een json gemaakt door ChatGPT) een reminder in kan stellen en vervolgens op de juiste tijd naar een mobiele telefoon stuurt.

Wat een groot voordeel is ten opzichte van Google Home is dat je makkelijk elke response die je wil naar je Voice satellite kunt sturen, en dat hetgeen afspeelt dan gewoon weer verder gaat (via Music Assistant).

Ik merk nu ook dat sommige standaard zinnen niet lekker werken, waar ik als language leader dus mee aan de slag moet. Maar het fijne voor mij persoonlijk is dat ik weet hoe het werkt, en ik het zelf kan fixen (en lokaal beschikbaar kan maken voordat het in een core release meegenomen is).

Over de hardware kan ik nog niets zeggen nu, dat zal over een maand als het goed is wel mogen.

Dat klinkt erg interessant. Hoe doe je dat dan concreet met die muziek query naar chatgpt? Ik wil mij hier ook nog eens in verdiepen, maar zag het nut niet zo. Deze toepassing klinkt erg handig!

[JustMyOpinion]

Goed... wij gebruiken in huis Telegram om HA berichten te ontvangen.

Nu ben ik bezig om alles proberen terug te brengen naar 'core' HA. Had alles in Node Red staan, maar heb nu alles terug gezet naar HA automations (ChatGPT is hier trouwens enorm goed voor).

Maar heb nu zo ingesteld dat de berichten niet meer via Telegram, maar via HA app gaan. Echter duurt het een tijd voor de berichten binnen komen (Android).

Ik heb al ttl: 0 en priority: high gezet, maar dan nog komt het niet direct binnen.

Herkent iemand dit en/of weet iemand de oplossing?

[Gonzalez]

Hmmbob schreef op maandag 11 november 2024 @ 15:39:
[...]

Ik ben benieuwd wat de oplossing dan was, want in de Supervisor repo staat geen commit oid

https://github.com/home-assistant/supervisor

Geen idee, it just worked.

[Raven]

@JustMyOpinion Sluit Android de HA-app niet af om de accu te besparen? Is een instelling voor om dit tegen te gaan.

[JustMyOpinion]

Raven schreef op maandag 11 november 2024 @ 18:59:
@JustMyOpinion Sluit Android de HA-app niet af om de accu te besparen? Is een instelling voor om dit tegen te gaan.

Nee, heb de app alle batterij rechten gegeven. Vreemde is dat als ik mijn telefoon open heb, de berichten wel direct komen, maar als hij dus uit is niet. Mijn vrouw heeft trouwens dezelfde problemen, dus (te) late berichten.

[TheFes]

gomaster schreef op maandag 11 november 2024 @ 18:11:
[...]

Dat klinkt erg interessant. Hoe doe je dat dan concreet met die muziek query naar chatgpt? Ik wil mij hier ook nog eens in verdiepen, maar zag het nut niet zo. Deze toepassing klinkt erg handig!

Hier is de automation, bovenin in de comments staat een link naar een blogpost waar het in veel meer detail uitgelegd staat.

Mijn aangepaste prompt staat ook in de comments

https://github.com/TheFes...ite/voice_play_music.yaml

[JustMyOpinion]

JustMyOpinion schreef op maandag 11 november 2024 @ 19:41:
[...]


Nee, heb de app alle batterij rechten gegeven. Vreemde is dat als ik mijn telefoon open heb, de berichten wel direct komen, maar als hij dus uit is niet. Mijn vrouw heeft trouwens dezelfde problemen, dus (te) late berichten.

Volgens het wijze internet kan ik ook 'persistent connection' aanzetten. Dus dat heb ik nu bij beide telefoons gedaan. Benieuwd of dit werkt.

[alex3305]

Even checken. Ik schakel mijn individuele thermostaatknoppen met verschillende modi. Dit doe ik met een Input Select en zorgt voor een stukje abstractie:


Deze waarde lees ik dan uit met een automation die ik al eerder dit jaar had gedeeld en een maand later heb verfijnd o.a. met hulp van hier .

Ik was nu aan het proberen om de aansturing van deze Input Select wat te verfijnen. Dat is m.i. wat complex geworden met automations van > 100 regels code. Ik word daar wat minder blij van. Het bouwen is niet per se het probleem, maar ik kom er relatief weinig aan. En als ik dan na een half jaar terugkijk, dan moet ik altijd even schakelen. Ik zie alleen even niet hoe ik dit wellicht wat zou kunnen versimpelen. Een voorbeeld van de badkamer waar ik mee aan het prutsen was:

YAML:

- id: helper_thermostat_mode_bathroom
  alias: Helper - Thermostaat modus badkamer
  mode: restart
  triggers:
    - platform: state
      entity_id: binary_sensor.bathroom_window_sensor_contact
      to: null
    - platform: state
      entity_id: binary_sensor.presence_bathroom
      to: null
    - platform: state
      entity_id: input_select.thermostat_mode
      to: null
  actions:
    choose:
      - conditions:
          - or:
              - condition: state
                entity_id: input_select.thermostat_mode
                state:
                  - "Uit"
                  - "Automatisch - Uit"
              - condition: state
                entity_id: binary_sensor.bathroom_window_sensor_contact
                state: "on"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Uit"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Afwezig"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Afwezig"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Slapen"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Nacht"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Automatisch"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Thuis"

De binary_sensor.presence_bathroom trigger zou weg kunnen, maar dat maakt voor nu even niet uit.

Dit is wat mij betreft enigszins acceptabel. En zorgt er in ieder geval voor dat ik geen 5 of 6 automatiseringen hebben die met elkaar kunnen stoeien. Maar als ik nu bijvoorbeeld een conditie wil toevoegen dat het badkamerraam minimaal 5 minuten dicht moet zijn voordat ik wissel naar de Thuis optie verhoogt dat de complexiteit aanzienlijk . Althans ik zie ff niet hoe ik dat dan wat eenvoudiger kan doen.

Maar moet ik nu eigenlijk maar gewoon even toegeven en accepteren dat het wellicht niet simpeler wordt? Of zie ik misschien iets over het hoofd waardoor het toch iets beheerbaarder wordt?

[JustMyOpinion]

alex3305 schreef op maandag 11 november 2024 @ 20:47:
Even checken. Ik schakel mijn individuele thermostaatknoppen met verschillende modi. Dit doe ik met een Input Select en zorgt voor een stukje abstractie:
[Afbeelding]

Deze waarde lees ik dan uit met een automation die ik al eerder dit jaar had gedeeld en een maand later heb verfijnd o.a. met hulp van hier .

Ik was nu aan het proberen om de aansturing van deze Input Select wat te verfijnen. Dat is m.i. wat complex geworden met automations van > 100 regels code. Ik word daar wat minder blij van. Het bouwen is niet per se het probleem, maar ik kom er relatief weinig aan. En als ik dan na een half jaar terugkijk, dan moet ik altijd even schakelen. Ik zie alleen even niet hoe ik dit wellicht wat zou kunnen versimpelen. Een voorbeeld van de badkamer waar ik mee aan het prutsen was:

YAML:

- id: helper_thermostat_mode_bathroom
  alias: Helper - Thermostaat modus badkamer
  mode: restart
  triggers:
    - platform: state
      entity_id: binary_sensor.bathroom_window_sensor_contact
      to: null
    - platform: state
      entity_id: binary_sensor.presence_bathroom
      to: null
    - platform: state
      entity_id: input_select.thermostat_mode
      to: null
  actions:
    choose:
      - conditions:
          - or:
              - condition: state
                entity_id: input_select.thermostat_mode
                state:
                  - "Uit"
                  - "Automatisch - Uit"
              - condition: state
                entity_id: binary_sensor.bathroom_window_sensor_contact
                state: "on"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Uit"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Afwezig"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Afwezig"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Slapen"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Nacht"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Automatisch"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Thuis"

De binary_sensor.presence_bathroom trigger zou weg kunnen, maar dat maakt voor nu even niet uit.

Dit is wat mij betreft enigszins acceptabel. En zorgt er in ieder geval voor dat ik geen 5 of 6 automatiseringen hebben die met elkaar kunnen stoeien. Maar als ik nu bijvoorbeeld een conditie wil toevoegen dat het badkamerraam minimaal 5 minuten dicht moet zijn voordat ik wissel naar de Thuis optie verhoogt dat de complexiteit aanzienlijk . Althans ik zie ff niet hoe ik dat dan wat eenvoudiger kan doen.

Maar moet ik nu eigenlijk maar gewoon even toegeven en accepteren dat het wellicht niet simpeler wordt? Of zie ik misschien iets over het hoofd waardoor het toch iets beheerbaarder wordt?

Heb je de code al een keer in ChatGPT gezet en gevraagd of het simpeler kan?

Ik heb afgelopen week al mijn node red omgezet naar HA automations. Werkte echt heel goed, heb zelfs paar 'gesprekken' gehad over wat er beter kon.

Als ik jou was zou ik het zeker eens proberen.

[Pejdref]

alex3305 schreef op maandag 11 november 2024 @ 20:47:
Even checken. Ik schakel mijn individuele thermostaatknoppen met verschillende modi. Dit doe ik met een Input Select en zorgt voor een stukje abstractie:
[Afbeelding]

Deze waarde lees ik dan uit met een automation die ik al eerder dit jaar had gedeeld en een maand later heb verfijnd o.a. met hulp van hier .

Ik was nu aan het proberen om de aansturing van deze Input Select wat te verfijnen. Dat is m.i. wat complex geworden met automations van > 100 regels code. Ik word daar wat minder blij van. Het bouwen is niet per se het probleem, maar ik kom er relatief weinig aan. En als ik dan na een half jaar terugkijk, dan moet ik altijd even schakelen. Ik zie alleen even niet hoe ik dit wellicht wat zou kunnen versimpelen. Een voorbeeld van de badkamer waar ik mee aan het prutsen was:

YAML:

- id: helper_thermostat_mode_bathroom
  alias: Helper - Thermostaat modus badkamer
  mode: restart
  triggers:
    - platform: state
      entity_id: binary_sensor.bathroom_window_sensor_contact
      to: null
    - platform: state
      entity_id: binary_sensor.presence_bathroom
      to: null
    - platform: state
      entity_id: input_select.thermostat_mode
      to: null
  actions:
    choose:
      - conditions:
          - or:
              - condition: state
                entity_id: input_select.thermostat_mode
                state:
                  - "Uit"
                  - "Automatisch - Uit"
              - condition: state
                entity_id: binary_sensor.bathroom_window_sensor_contact
                state: "on"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Uit"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Afwezig"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Afwezig"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Slapen"
          - not:
              - condition: state
                entity_id: input_select.thermostat_mode_bathroom
                state: "Uit"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Nacht"
      - conditions:
          - condition: state
            entity_id: input_select.thermostat_mode
            state: "Automatisch"
        sequence:
          action: input_select.select_option
          target:
            entity_id: input_select.thermostat_mode_bathroom
          data:
            option: "Thuis"

De binary_sensor.presence_bathroom trigger zou weg kunnen, maar dat maakt voor nu even niet uit.

Dit is wat mij betreft enigszins acceptabel. En zorgt er in ieder geval voor dat ik geen 5 of 6 automatiseringen hebben die met elkaar kunnen stoeien. Maar als ik nu bijvoorbeeld een conditie wil toevoegen dat het badkamerraam minimaal 5 minuten dicht moet zijn voordat ik wissel naar de Thuis optie verhoogt dat de complexiteit aanzienlijk . Althans ik zie ff niet hoe ik dat dan wat eenvoudiger kan doen.

Maar moet ik nu eigenlijk maar gewoon even toegeven en accepteren dat het wellicht niet simpeler wordt? Of zie ik misschien iets over het hoofd waardoor het toch iets beheerbaarder wordt?

Persoonlijk zou ik het aantal keuzemogelijkheden beperken om het simpeler te houden. Maar dat is je vraag niet.

Ik zou het oplossen door een trigger toe te voegen 'raam is 5 minuten dicht.'

Vervolgens zou ik een condition toevoegen 'raam moet 5 minuten dicht zijn or raam is open'

Als action 'if raam is open dan status uit, else de rest van je logica die niet naar het raam kijkt'.

[alex3305]

JustMyOpinion schreef op maandag 11 november 2024 @ 21:24:
Heb je de code al een keer in ChatGPT gezet en gevraagd of het simpeler kan?

[...]

Als ik jou was zou ik het zeker eens proberen.

Als professioneel software ontwikkelaar doet mij die opmerking echt pijn . Aan de andere kant moet ik het dan ook niet vragen natuurlijk . ChatGPT gaf als enige suggestie om de triggers te versimpelen. En action weer terug te zetten naar het oude service. Dat haalde dus helaas weinig uit.

Kijk op zichzelf is de code niet ook super complex. Alleen wat uitgebreid. Maar misschien is de aanpak onhandig. Vandaar de vraag.

[alex3305]

Pejdref schreef op maandag 11 november 2024 @ 21:39:
Persoonlijk zou ik het aantal keuzemogelijkheden beperken om het simpeler te houden. Maar dat is je vraag niet.

Nog verder beperken? Ik vind de zes keuzes die ik nu heb al vrij beperkt . Omdat ik dus mijn ruimtes individueel schakel ben ik ooit tot deze opzet gekomen. De gedachte erachter is eigenlijk:

• Uit, in de zomer en als er een raam of deur (langer) openstaat
• Afwezig, wanneer we niet thuis zijn
• Nacht, bij slapen
• Thuis, wanneer een van ons thuis is, maar niet in die ruimte aanwezig is
• Eco, wanneer een van ons thuis is en de ruimte bezet is
• Comfort, wanneer een van ons thuis is, de ruimte bezet is en op comfort tijd (bijv. avond en weekend)

Zo heb ik dit al zeker sinds 2020 en voldoet prima. Maar eens in de zoveel tijd herzie ik automatiseringen om te kijken of het e.e.a. niet beter of makkelijker kan . De badkamer is daarbij een relatief eenvoudige ruimte waarbij ik Eco en Comfort eigenlijk nooit gebruik, dus daar heb ik eigenlijk maar 4 statussen.

Ik zou het oplossen door een trigger toe te voegen 'raam is 5 minuten dicht.'

Vervolgens zou ik een condition toevoegen 'raam moet 5 minuten dicht zijn or raam is open'

Als action 'if raam is open dan status uit, else de rest van je logica die niet naar het raam kijkt'.

Ja, aan zoiets zat ik dus ook te denken. Alleen ben ik bang dat ik dan in de knoei gaan komen met de mode: restart. Misschien moet ik dan maar op het hoofdniveau van de actions een if-statement maken die alleen naar het raam/uit-staat kijkt.

Morgen weer mee verder

[Ronker32]

JustMyOpinion schreef op maandag 11 november 2024 @ 20:15:
[...]


Volgens het wijze internet kan ik ook 'persistent connection' aanzetten. Dus dat heb ik nu bij beide telefoons gedaan. Benieuwd of dit werkt.

Ik loop al geruime tijd tegen hetzelfde probleem aan, berichten die pas binnen lijken te komen als ik mijn telefoon ontgrendel of een willekeurige tijd later. Flink irritant bij bijvoorbeeld de bel.. Ben benieuwd of dit het probleem bij jou oplost.

[Pejdref]

@alex3305 Met mode:queued zou het ook goed gaan.

[JustMyOpinion]

Ronker32 schreef op dinsdag 12 november 2024 @ 08:39:
[...]


Ik loop al geruime tijd tegen hetzelfde probleem aan, berichten die pas binnen lijken te komen als ik mijn telefoon ontgrendel of een willekeurige tijd later. Flink irritant bij bijvoorbeeld de bel.. Ben benieuwd of dit het probleem bij jou oplost.

Tot heden heb ik alle berichten binnen gekregen! Dus dat valt niet tegen. Batterij drain weet ik nog niet, staat natuurlijk pas sinds kort aan.

Voor de mensen die ook 'persistent connection' willen aanzetten: Vanuit de app --> Instellingen --> Companion app --> Klik op je telefoon boven aan onder 'Servers & Apparaten' --> Helemaal beneden staat dan 'Aanhoudende verbinding' --> 'Altijd'

[raymondw]

JustMyOpinion schreef op dinsdag 12 november 2024 @ 08:57:
[...]


Tot heden heb ik alle berichten binnen gekregen! Dus dat valt niet tegen. Batterij drain weet ik nog niet, staat natuurlijk pas sinds kort aan.

Voor de mensen die ook 'persistent connection' willen aanzetten: Vanuit de app --> Instellingen --> Companion app --> Klik op je telefoon boven aan onder 'Servers & Apparaten' --> Helemaal beneden staat dan 'Aanhoudende verbinding' --> 'Altijd'

Bij mij staat de app op de standaard settings ivm de batt drain
Wat werkte was : priority: high

code:

data:
  message: *hier-je-eigen-bericht*
  data:
    sticky: "true"
    ttl: 0
    priority: high
action: notify.mobile_app_*mijn-mobiel*

[JustMyOpinion]

raymondw schreef op dinsdag 12 november 2024 @ 09:25:
[...]

Bij mij staat de app op de standaard settings ivm de batt drain
Wat werkte was : priority: high

code:

data:
  message: *hier-je-eigen-bericht*
  data:
    sticky: "true"
    ttl: 0
    priority: high
action: notify.mobile_app_*mijn-mobiel*

Dat heb ik ook geprobeerd, maar dat werkt niet bij mijn vrouw en mijzelf (Beide Samsung (A54 en A55)).

Even kijken of de batterij drain mee valt, anders bouw ik het maar weer terug naar Telegram.

[Septillion]

@alex3305 Ik zou me vooral niet blindstaren op de lengte. HA yaml triggers/conditions/actions zijn überhaupt vrij lang dus het tikt snel aan. Gaat er vooral om dat het een leesbaar geheel blijft. En voor mij persoonlijk, ook leesbaar in de UI^*. Nu kunnen er heel wat dingen korter in een template maar lang niet altijd vind ik dat de meest leesbare optie.

Dus naar mijn idee valt het dus wel mee en is de huidige lengte wel uitlegbaar door de complexiteit die je verlangt.

* Alleen zou ik heeeeel graag zien dat de UI standaard alle items uit zou klappen en alleen de laatste (dus de details) ingeklapt zou laten ipv alles dicht...

[--Christiaan--]

EDIT: Mijn eigen stommiteit gevonden

[ Voor 97% gewijzigd door --Christiaan-- op 12-11-2024 10:24 ]

[raymondw]

JustMyOpinion schreef op dinsdag 12 november 2024 @ 09:37:
[...]


Dat heb ik ook geprobeerd, maar dat werkt niet bij mijn vrouw en mijzelf (Beide Samsung (A54 en A55)).

Even kijken of de batterij drain mee valt, anders bouw ik het maar weer terug naar Telegram.

Gebruik een recente Galaxy S en mijn vriendin ook. Het is om het even qua snelheid.

Qua melding snelheid op mobiel
- Bell app
- Telegram
- HA

Als je kijkt naar bv snelheid in huis
- HA -> Nest hub (via mqtt)
- Bell app enz

Zodra iemand de bel indrukt gaat HA al af.
De vertraging zit hier in de externe factoren.

Maar in totaal tussen de hub en de HA melding op mobiel is ±3sec.

[JustMyOpinion]

raymondw schreef op dinsdag 12 november 2024 @ 10:25:
[...]

Gebruik een recente Galaxy S en mijn vriendin ook. Het is om het even qua snelheid.

Qua melding snelheid op mobiel
- Bell app
- Telegram
- HA

Als je kijkt naar bv snelheid in huis
- HA -> Nest hub (via mqtt)
- Bell app enz

Zodra iemand de bel indrukt gaat HA al af.
De vertraging zit hier in de externe factoren.

Maar in totaal tussen de hub en de HA melding op mobiel is ±3sec.

Nee, bij ons is het echt veel langer, denk aan >15 minuten of nog langer. Hiervoor had ik Telegram en dat werkte wel direct. Dus mocht dit echt niet werken kan ik altijd nog terug, maar idee was om de externe zaken (node red, telegram) weg te werken.

[Hmmbob]

Toch is "batterijbesparing" daarbij vaak het probleem.

edit: laat je automation eens zien?

[ Voor 26% gewijzigd door Hmmbob op 12-11-2024 10:31 ]

[alex3305]

@JustMyOpinion @raymondw In principe gebruikt de HA Companion app dezelfde Google bibliotheek en achterliggend netwerk als Telegram om berichten te ontvangen. Eigenlijk gebruiken bijna alla applicaties (uit de Play Store) dezelfde bibliotheek. Vandaar dat je ook het resterend/maximum berichten in de Instellingen ziet. Dat is gelimiteerd oa vanwege kosten vziw.

Ik heb de standaard instellingen dus Aanhoudende Verbindingen staat op Enkel wanneer verbonden met Thuisnetwerk. En die heb ik uiteraard ook ingesteld. Let wel op dat Home Assistant door Samsung niet in slaapstond wordt geplaatst. Dit zie je bij Apps > App-info > Batterij. Dat moet op Onbeperkt staat anders werkt het niet goed.

Voor directe notificaties gebruik ik het volgende.
Android

YAML:

action: notify.android_device
data:
  title: "Ding dong!"
  message: "Ik hoefde niet te kloppen want de bel deed het wel."
  data:
    ttl: 0
    priority: high

iOS

YAML:

action: notify.ios_device
data:
  title: "Ding dong!"
  message: "Ik hoefde niet te kloppen want de bel deed het wel."
  data:
    push:
      sound:
        name: "default"
        critical: 1
        volume: 0

Of natuurlijk een combinatie voor beide type devices. De vertraging die we hiermee ervaren is maximaal een paar seconden. In ieder geval op het thuisnetwerk.

[mr.inno]

In het kader van Assist heb ik een probleem met de spraak-naar-tekst functie in het Nederlands. Deze functie voegt namelijk automatisch interpunctie toe, terwijl de “Zin trigger” geen interpunctie ondersteunt. Bijvoorbeeld:

code:

Vertel Daisy, hoe laat ik thuis ben

Iemand enige idee?

[alex3305]

@Septillion Bedankt voor je input . Dat had ik denk ik ook even nodig. Ik gebruik de UI-editor vooralsnog nooit omdat:

• de items altijd zijn ingeklapt
• de (Nederlandse) vertalingen goed bedoelt zijn maar het m.i. enorm onduidelijk maken
• er geen default YAML view is

Ik probeer templates veelal te vermijden. Althans voor condities en acties omdat ik dezelfde mening deel. Vaak wordt ermee het nog onduidelijker. Een mooi voorbeeld uit een conditions block uit een script die controleert of de laatste keer slapen meer dan 22 uur geleden was is prachtig, maar niet super duidelijk:

YAML:

- condition: or
  conditions:
    - condition: time
      after: "23:00:00"
      before: "06:00:00"
    - condition: template
      value_template: >-
        {{ ((as_timestamp(now()) -
            as_timestamp(states('input_datetime.bedtime'))) / 3600) > 22
        }}

en IMHO ook niet heel handig vanuit de UI:


Maar wellicht is dat ook niet helemaal aan mij besteed .

[alex3305]

mr.inno schreef op dinsdag 12 november 2024 @ 10:39:
In het kader van Assist heb ik een probleem met de spraak-naar-tekst functie in het Nederlands. Deze functie voegt namelijk automatisch interpunctie toe, terwijl de “Zin trigger” geen interpunctie ondersteunt. Bijvoorbeeld:

code:

Vertel Daisy, hoe laat ik thuis ben

Iemand enige idee?

Je zou de interpunctie met een Jinja template er relatief eenvoudig uit kunnen halen. Ik weet niet precies wat de input is. Maar bijvoorbeeld:

Django/Jinja:

{% set input = "Vertel Daisy, hoe laat ik thuis ben" %}
{{ input | replace(',', '') | replace('.', '') }}

[JustMyOpinion]

Hmmbob schreef op dinsdag 12 november 2024 @ 10:30:
Toch is "batterijbesparing" daarbij vaak het probleem.

edit: laat je automation eens zien?

Neem aan dat je die van mij bedoelt?

Alle notifications zijn nu zo ingesteld:

YAML:

  actions:
  - data_template:
      message: Alarm is ingeschakeld
      data:
        car_ui: true
        actions:
        - action: URI
          title: Open logboek
          uri: settings://notification_history
    action: notify.all_homeassistant_users

Maar daarvoor had ik dus getest zonder 'Aanhoudende verbinding' en:

YAML:

action: notify.homeassistant_user_xxx
data:
  message: Beveiliging!
  data:
    actions:
      - action: URI
        title: Zie opname
        uri: ccab4aaf_frigate/ingress
    data:
      car_ui: true
      ttl: 0
      priority: high

De onderste gaf dus vertraging zonder 'Aanhoudende verbinding'.

Tot heden lijkt het te werken, batterij lijkt ook nog mee te vallen.

[ Voor 0% gewijzigd door Septillion op 12-11-2024 11:02 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Hmmbob]

JustMyOpinion schreef op dinsdag 12 november 2024 @ 10:50:
Maar daarvoor had ik dus getest zonder 'Aanhoudende verbinding' en:

code:

action: notify.homeassistant_user_xxx
data:
  message: Beveiliging!
  data:
    actions:
      - action: URI
        title: Zie opname
        uri: ccab4aaf_frigate/ingress
    data:
      car_ui: true
      ttl: 0
      priority: high

De onderste gaf dus vertraging zonder 'Aanhoudende verbinding'.

Tot heden lijkt het te werken, batterij lijkt ook nog mee te vallen.

Die klopt ook niet, je hebt nu 3x data in elkaar genest. Probeer eens met:

YAML:

- action: notify.homeassistant_user_xxx
  data:
    title: Beveiliging!
    message: Er staat iemand aan je deur
    data:
      actions:
        - action: URI
          title: Zie opname
          uri: ccab4aaf_frigate/ingress
      car_ui: true
      ttl: 0
      priority: high

edit: Sowieso is data_template: al een tijdje deprecated, je kan gewoon data: gebruiken.

Die "aanhoudende verbinding" is een workaround, die zou niet nodig moeten zijn. Dat issie hier thuis niet in ieder geval.

[ Voor 49% gewijzigd door Hmmbob op 12-11-2024 11:03 ]

[mr.inno]

alex3305 schreef op dinsdag 12 november 2024 @ 10:46:
[...]

Je zou de interpunctie met een Jinja template er relatief eenvoudig uit kunnen halen. Ik weet niet precies wat de input is. Maar bijvoorbeeld:

Django/Jinja:

{% set input = "Vertel Daisy, hoe laat ik thuis ben" %}
{{ input | replace(',', '') | replace('.', '') }}

Ik probeer een pipeline te maken waar ik vanuit de companion app een voice to text doe. deze triggerd een automation. Hier zit volgens mij geen optie in om de zin te bewerken.

[Septillion]

@alex3305 Zelf doe ik bijna niets puur in yaml, alleen de tweks. Maar het alles inklappen staat hoog op mijn WTH lijst...

En heb zelf HA volledig in het Engels staan. Vind de Nederlandse vertalingen niet slecht maar voor logica werkt mijn brein toch beter met Engels

En met "default yaml view" bedoel je dat hij standaard in yaml opent? Want op zich, als hij uit zou klappen tot de details zou ik dat juist fijner vinden. Geeft naar mijn idee nog meer overzicht dan de yaml.

En voor die template, mja, is ook het gedoe dat een state standaard een string is. En zeker met een datetime die ook niet standaard offset aware is Maar andere kant, laat ook mooi zien hoeveel edge cases de standaard yaml HA componenten dus op de achtergrond al af moeten vangen

[Marsman83]

Laat maar, ik moest shift-F5 doen om nieuwe cert in de browser te zien...

[ Voor 90% gewijzigd door Marsman83 op 12-11-2024 11:23 . Reden: Probleem opgelost ]

[JustMyOpinion]

Hmmbob schreef op dinsdag 12 november 2024 @ 10:57:
[...]

Die klopt ook niet, je hebt nu 3x data in elkaar genest. Probeer eens met:

YAML:

- action: notify.homeassistant_user_xxx
  data:
    title: Beveiliging!
    message: Er staat iemand aan je deur
    data:
      actions:
        - action: URI
          title: Zie opname
          uri: ccab4aaf_frigate/ingress
      car_ui: true
      ttl: 0
      priority: high

edit: Sowieso is data_template: al een tijdje deprecated, je kan gewoon data: gebruiken.

Die "aanhoudende verbinding" is een workaround, die zou niet nodig moeten zijn. Dat issie hier thuis niet in ieder geval.

Dank je voor je verbetering, ga ik zeker doorvoeren!

Maar aangezien ik het bericht wel daadwerkelijk op mijn telefoon krijg geloof ik niet dat hierdoor een vertraging kan optreden (?).

[alex3305]

@Septillion Ik ben het tegenovergestelde. Ik doe (bijna) alles in YAML. Wellicht is dat beroepsdeformatie .

Engels is logischer, vooral met automatiseringen. Maar ik heb alles in het Nederlands staan. Vind dan de UX als Nederlander wat beter en de WAF wat hoger,

En met "default yaml view" bedoel je dat hij standaard in yaml opent? Want op zich, als hij uit zou klappen tot de details zou ik dat juist fijner vinden. Geeft naar mijn idee nog meer overzicht dan de yaml.

Ja. Ik heb mijn automatiseringen eigenlijk alleen nog maar apart in Git staan omdat ik in Home Assistant niet standaard een YAML view kan instellen als ik een automatisering open.

Ik heb een hele tijd terug al mijn automatiseringen omgezet zodat ze in automations.yaml zaten en dus vanuit de UI te bewerken waren. Maar ik kon er maar niet over die extra stap heenstappen om elke keer de YAML editor te openen. Ik vind de UI editor enorm onprettig werken om redenen die ik al uit een heb gezet. Daar speelt wellicht ook mee dat ik slechtziend ben (bij jou bekend ) en dus mijn tekst groter staat. Ik verlies dus enorm snel het overzicht. Met YAML heb ik daar veel minder last van.

Wel grappig dat je jouw WTH lijst noemt. Mijn bovenste punt op mijn WTH lijst is momenteel dat de terug knop in de applicatie regelmatig niet of heel slecht werkt. Daar word ik echt knettergek van. Alhoewel ik het zojuist test en het perfect werkt . Ik zal zo eens de frontend release notes eens erop naslaan. Wellicht dat er iets in 2024.11 in veranderd is .

[Hmmbob]

JustMyOpinion schreef op dinsdag 12 november 2024 @ 11:24:
[...]


Dank je voor je verbetering, ga ik zeker doorvoeren!

Maar aangezien ik het bericht wel daadwerkelijk op mijn telefoon krijg geloof ik niet dat hierdoor een vertraging kan optreden (?).

ja, wel, want het stukje wat juist zorgt dat er geen vertraging zou moeten zijn zonder de permanente verbinding (ttl & priority) worden nu genegeerd omdat je ze niet juist in de code had staan.

[ Voor 3% gewijzigd door Hmmbob op 12-11-2024 11:56 ]

[Septillion]

@alex3305 Haha, ben maar een hobbiër die daarom steeds met een andere taal werkt (HA yaml, C, C++, Python, SQL, Linux Shell, PowerShell, HTML, CSS, LAD, SCL, FBD, PHP to name a few) dus ben enorm slecht in het onthouden van exacte attributen. Dus ik klik het heeeeel graag gewoon bij elkaar Anders maak ik alleen maar fouten in het standaard werk en blijf ik man pages opzoeken

En ja, de terug is vaak wel een ding. Zeker in de app waar vervolgens niet altijd het menu beschikbaar is

[Hippe Lip]

--Christiaan-- schreef op dinsdag 12 november 2024 @ 10:23:
EDIT: Mijn eigen stommiteit gevonden

@--Christiaan--
Nu maak je me toch nieuwsgierig: Wat was die stommiteit?

Het mooie van dit platform vind ik namelijk niet alleen dat je leert van elkaar en van elkaars voorbeelden en ideeën, maar ook van elkaars fouten. Het is geen schande om fouten te maken; doen we allemaal.

Daarom de vraag: wat ging er mis?

[JustMyOpinion]

Hmmbob schreef op dinsdag 12 november 2024 @ 11:55:
[...]

ja, wel, want het stukje wat juist zorgt dat er geen vertraging zou moeten zijn zonder de permanente verbinding (ttl & priority) worden nu genegeerd omdat je ze niet juist in de code had staan.

Heb zojuist de permanente verbinding uit gezet, ik hou het even in de gaten. Will report back!

[RobertMe]

Semi offtopic, maar lol Reddit draadje:
https://www.reddit.com/r/...is_home_assistant_really/

Emile, Homey oprichter, ook op Tweakers actief, snapt volgens mij niet hoe HA werkt. Mijn HA bevat bv helemaal nergens een verwijzing naar Nabu Casa / HA Cloud. Wel (meermaals) naar de Open Home Foundation.
En de cloud integratie is "just another integration" waarbij ik geen bewijs zie dat niemand een eigen, soortgelijke, integratie kan bouwen en daarvoor een PR kan aanmaken. Enige ding dat vervolgens over blijft is dat de (Nabu Casa) cloud integratie een afhankelijkheid is van de "default_config" integratie waardoor de cloud integratie dus default is ingeschakeld (/me heeft dus de "default_config" integratie dus niet aan staan). En het lijkt mij onwaarschijnlijk dat er meerdere cloud integraties default aan worden gezet. Kans lijkt mij dan nog groter dat de Nabu Casa Cloud integratie uit de "default_config" wordt gehaald en iedereen het handmatig moet enablen (/incl migratie dat die automatisch aan staat voor die wat het al geconfigureerd hebben).

[Kodess]

RobertMe schreef op dinsdag 12 november 2024 @ 12:56:
Semi offtopic, maar lol Reddit draadje:
https://www.reddit.com/r/...is_home_assistant_really/

Emile, Homey oprichter, ook op Tweakers actief, snapt volgens mij niet hoe HA werkt. Mijn HA bevat bv helemaal nergens een verwijzing naar Nabu Casa / HA Cloud. Wel (meermaals) naar de Open Home Foundation.
En de cloud integratie is "just another integration" waarbij ik geen bewijs zie dat niemand een eigen, soortgelijke, integratie kan bouwen en daarvoor een PR kan aanmaken. Enige ding dat vervolgens over blijft is dat de (Nabu Casa) cloud integratie een afhankelijkheid is van de "default_config" integratie waardoor de cloud integratie dus default is ingeschakeld (/me heeft dus de "default_config" integratie dus niet aan staan). En het lijkt mij onwaarschijnlijk dat er meerdere cloud integraties default aan worden gezet. Kans lijkt mij dan nog groter dat de Nabu Casa Cloud integratie uit de "default_config" wordt gehaald en iedereen het handmatig moet enablen (/incl migratie dat die automatisch aan staat voor die wat het al geconfigureerd hebben).

Eerst zeg je dat hij niet weet hoe het werkt en dan geef je aan dat het er wel inzit...
Sterker nog, het zit er in op een manier die voor leken onduidelijk is.
Hoe verwijder je bv de HA Cloud integratie via de UI?

Dus er is een third party die standaard in HA zit met reclame.
Want Nabu Casa is dus niet meer eigenaar van Home Assistant.

Vanuit de Open Home Foundation zou je verwachten dat ze dit juist niet zouden willen. Stel Logitech klopt bij ze aan met een koffer geld en ze willen een default integration worden.
Mijn aanname is dan dat ze weigeren, en dat zelfde zou hier dan ook moeten gelden.
Ook al zijn de twee ontzetten verweven, zeker als je kijkt naar medewerkers/oprichters.

Edit:
Ik lees nu pas de reacties op reddit, wat een dombo's zitten daar zeg. Ze hebben zijn kritiek niet eens gelezen. Het zijn alleen maar fanboys die zeggen ja maar ik wil wel betalen voor wat ze hebben gemaakt.
That's not the point.

[ Voor 19% gewijzigd door Kodess op 12-11-2024 13:46 ]

[alex3305]

@RobertMe Misschien niet super chique, maar hij heeft weldegelijk een punt. Ik ben hier weleens ingedoken omdat ik wel de default_config: wilde gebruiken, maar geen cloud wil omdat ik het toch niet gebruik. Dan kom je o.a. bij deze community thread waar een gebruiker met een oplossing komt om het component te overschrijven met een custom component. Maar dat werkt dus niet zonder meer. De frontend heeft ook een best specifieke afhankelijkheid van deze integratie. Uiteindelijk kom je dan op een soort van aangepaste default_config maar hoe wenselijk dat is weet ik niet.

Aan de hand hiervan heb ik zelf ook nog eens wat tijd gestoken om een custom cloud component te bouwen. Maar heel eenvoudig of transparant vond ik dat niet. Ook is natuurlijk de kans best groot dat bij het aanbieden van een vergelijkbare dienst op basis van de huidige integratie er tijdens updates wel het e.e.a. stuk zal gaan. Nabu Casa heeft hier wel echt een streepje voor. Daar heb ik verder geen mening over, maar is puur een vaststelling.

Ik heb die route uiteindelijk opgegeven en verberg de Nabu Casa reclame met mijn global-mod plugin en verwante CSS regels:

YAML:

---
default-global-mod:
  removeCloudDiscover-path: config/voice-assistants/assistants
  removeCloudDiscover-selector: home-assistant-main$ha-drawer ha-config-voice-assistants-assistants$
  removeCloudDiscover-style: "cloud-discover { display: none!important; }"

  removeCloudConfig-path: config/dashboard
  removeCloudConfig-selector: home-assistant-main$ha-drawer ha-config-dashboard$ha-config-navigation$ha-navigation-list$
  removeCloudConfig-style: "mwc-list ha-list-item:first-of-type { display: none; }"

[RobertMe]

Kodess schreef op dinsdag 12 november 2024 @ 13:39:
[...]

Eerst zeg je dat hij niet weet hoe het werkt en dan geef je aan dat het er wel inzit...
Sterker nog, het zit er in op een manier die voor leken onduidelijk is.
Hoe verwijder je bv de HA Cloud integratie via de UI?

Dat zeg ik niet. Maar er wordt net gedaan alsof een alternatief niet mogelijk is. En dat alternatief is zeker wel mogelijk. De Nabu Casa Cloud is een integratie zoals elke andere. En een third party bedrijf die iets soortgelijks wilt doen hoeft helemaal niet te forken of wat dan ook. Ze kunnen op mijn minst een custom component er voor maken en via bv HACS aanbieden. Daarnaast kunnen ze ook een PR aanmaken bij HA om het gebundeld te krijgen. Waarbij er momenteel geen enkel bewijs is dat zo'n PR geweigerd zou worden (want er is nog niemand die dit geprobeerd of gevraagd heeft). En als zo'n integratie geaccepteerd wordt is het dus ook "open" volgens de discussie (wnat concurrentie kan zichzelf ook in HA "van iedereen" opnemen, de code zit in de standaard installatie).

Dat de Nabu Casa Cloud integratie vervolgens standaard geactiveerd is (maar niks doet), tsja? Is dat een ramp? En als dat zo is kan er op zo'n moment nog altijd gediscussieerd worden over of of die concurrent ook standaard ingeschakeld moet zijn, of Nabu Casa Cloud standaard wordt uitgeschakeld. Of wat dan ook.

En v.w.b. "hoe makkelijk is het uit te schakelen" doet er IMO ook niet echt toe. Want er zijn veel meer integraties die standaard aan staan (onder default_config) die niet voor iedereen relevant zijn (assist bv).

De discussie is dus "een concurrent kan niet zo prominent in HA komen en dus is het niet open". Terwijl er geen concurrent is / geen bewijs is dat een concurrent is geweigerd. En een concurrent kan minimaal een integratie als custom component aanbieden (dus forken is nergens voor nodig). Maar ook een PR aanmaken om de (custom) component op te nemen in de core repository en dus " standaard installatie". En zo lang niemand heeft gevraagd naar of zo'n PR geaccepteerd zou worden (/de PR gewoon aanmaakt) valt er geen enkele conclusie te trekken over "openheid" en/of dat Nabu Casa wordt voorgetrokken. Je kunt alleen zeggen dat ("heel toevallig") Nabu Casa het enige bedrijf is dat heeft geprobeerd zo'n component op te nemen in HA, en dat is ze gelukt.

[Pejdref]

Kodess schreef op dinsdag 12 november 2024 @ 13:39:
[...]

Eerst zeg je dat hij niet weet hoe het werkt en dan geef je aan dat het er wel inzit...
Sterker nog, het zit er in op een manier die voor leken onduidelijk is.
Hoe verwijder je bv de HA Cloud integratie via de UI?

Dus er is een third party die standaard in HA zit met reclame.
Want Nabu Casa is dus niet meer eigenaar van Home Assistant.

Vanuit de Open Home Foundation zou je verwachten dat ze dit juist niet zouden willen. Stel Logitech klopt bij ze aan met een koffer geld en ze willen een default integration worden.
Mijn aanname is dan dat ze weigeren, en dat zelfde zou hier dan ook moeten gelden.
Ook al zijn de twee ontzetten verweven, zeker als je kijkt naar medewerkers/oprichters.

Edit:
Ik lees nu pas de reacties op reddit, wat een dombo's zitten daar zeg. Ze hebben zijn kritiek niet eens gelezen. Het zijn alleen maar fanboys die zeggen ja maar ik wil wel betalen voor wat ze hebben gemaakt.
That's not the point.

In principe kan Logitech dat ook doen, kijk maar op de website van de Open Home Foundation. Ze stellen echter meer voorwaarden dan alleen een bak geld.

[RobertMe]

alex3305 schreef op dinsdag 12 november 2024 @ 13:39:
@RobertMe Misschien niet super chique, maar hij heeft weldegelijk een punt. Ik ben hier weleens ingedoken omdat ik wel de default_config: wilde gebruiken, maar geen cloud wil omdat ik het toch niet gebruik. Dan kom je o.a. bij deze community thread waar een gebruiker met een oplossing komt om het component te overschrijven met een custom component. Maar dat werkt dus niet zonder meer. De frontend heeft ook een best specifieke afhankelijkheid van deze integratie. Uiteindelijk kom je dan op een soort van aangepaste default_config maar hoe wenselijk dat is weet ik niet.

Nouja, ik heb de default_config: dus niet meer in de configuration.yaml staan en heb geen issues (dus het frontend is er niet afhankelijk van?). Uiteraard wel dan een "helr lijst" van componenten zelf moeten opnemen.

Ook is natuurlijk de kans best groot dat bij het aanbieden van een vergelijkbare dienst op basis van de huidige integratie er tijdens updates wel het e.e.a. stuk zal gaan.

Dat lijkt me best sterk. Als er bv breaking changes in de code worden gedaan zal degene die die changes doet ervoor moeten zorgen dat alles blijft werken (voor alle ingebouwde componenten). Anders kan die change gewoon niet geaccepteerd worden. En hetzelfde zie je bv bij de Linux kernel. Ook daar zal niet elk bedrijf dat iets voor hun hardware heeft bijgedragen continu bovenop de ontwikkelingen zitten om hun onderdeel werkende te houden. Als iemand anders een breaking change wilt doen moet die het maar werkende houden. Voor externe componenten geldt dat uiteraard niet. Maar HA documenteert wel hun breaking API changes voor custom componenten.

[--Christiaan--]

Hippe Lip schreef op dinsdag 12 november 2024 @ 11:59:
[...]

@--Christiaan--
Nu maak je me toch nieuwsgierig: Wat was die stommiteit?

Het mooie van dit platform vind ik namelijk niet alleen dat je leert van elkaar en van elkaars voorbeelden en ideeën, maar ook van elkaars fouten. Het is geen schande om fouten te maken; doen we allemaal.

Daarom de vraag: wat ging er mis?

Goed punt, ik heb deze Yaml en vroeg me af waarom de kachel niet aanging onder de 16,5 graad. Oorspronkelijk had ik 16.0 graad ingevoerd en toen ik aan het meten was, was het 16.3. Ik bleek de trigger wel aangepast te hebben, maar daaronder niet de action, zie hieronder.

YAML:

alias: Verwarming Automatisering kamer
description: ""
triggers:
  - entity_id:
      - sensor.esphome_co2_2_co2_temperature
    below: 16.5
    trigger: numeric_state
  - entity_id: sensor.esphome_co2_2_co2_temperature
    above: 20
    trigger: numeric_state
conditions:
  - condition: time
    after: "19:00:00"
    before: "07:00:00"
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.esphome_co2_2_co2_temperature
            below: 16
        sequence:
          - target:
              entity_id: switch.kacheltje
            action: switch.turn_on
            data: {}
      - conditions:
          - condition: numeric_state
            entity_id: sensor.esphome_co2_2_co2_temperature
            above: 20
        sequence:
          - target:
              entity_id: switch.kacheltje
            action: switch.turn_off
            data: {}
mode: single

[TheFes]

--Christiaan-- schreef op dinsdag 12 november 2024 @ 13:58:
[...]


Goed punt, ik heb deze Yaml en vroeg me af waarom de kachel niet aanging onder de 16,5 graad. Oorspronkelijk had ik 16.0 graad ingevoerd en toen ik aan het meten was, was het 16.3. Ik bleek de trigger wel aangepast te hebben, maar daaronder niet de action, zie hieronder.

YAML:

alias: Verwarming Automatisering kamer
description: ""
triggers:
  - entity_id:
      - sensor.esphome_co2_2_co2_temperature
    below: 16.5
    trigger: numeric_state
  - entity_id: sensor.esphome_co2_2_co2_temperature
    above: 20
    trigger: numeric_state
conditions:
  - condition: time
    after: "19:00:00"
    before: "07:00:00"
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.esphome_co2_2_co2_temperature
            below: 16
        sequence:
          - target:
              entity_id: switch.kacheltje
            action: switch.turn_on
            data: {}
      - conditions:
          - condition: numeric_state
            entity_id: sensor.esphome_co2_2_co2_temperature
            above: 20
        sequence:
          - target:
              entity_id: switch.kacheltje
            action: switch.turn_off
            data: {}
mode: single

In zo'n geval lijkt het me beter om te werken met trigger id's. Dan hoef je het ook maar op één plek aan te passen.

[Kodess]

RobertMe schreef op dinsdag 12 november 2024 @ 13:50:
[...]

Dat zeg ik niet. Maar er wordt net gedaan alsof een alternatief niet mogelijk is. En dat alternatief is zeker wel mogelijk. De Nabu Casa Cloud is een integratie zoals elke andere. En een third party bedrijf die iets soortgelijks wilt doen hoeft helemaal niet te forken of wat dan ook. Ze kunnen op mijn minst een custom component er voor maken en via bv HACS aanbieden. Daarnaast kunnen ze ook een PR aanmaken bij HA om het gebundeld te krijgen. Waarbij er momenteel geen enkel bewijs is dat zo'n PR geweigerd zou worden (want er is nog niemand die dit geprobeerd of gevraagd heeft). En als zo'n integratie geaccepteerd wordt is het dus ook "open" volgens de discussie (wnat concurrentie kan zichzelf ook in HA "van iedereen" opnemen, de code zit in de standaard installatie).

Dat de Nabu Casa Cloud integratie vervolgens standaard geactiveerd is (maar niks doet), tsja? Is dat een ramp? En als dat zo is kan er op zo'n moment nog altijd gediscussieerd worden over of of die concurrent ook standaard ingeschakeld moet zijn, of Nabu Casa Cloud standaard wordt uitgeschakeld. Of wat dan ook.

En v.w.b. "hoe makkelijk is het uit te schakelen" doet er IMO ook niet echt toe. Want er zijn veel meer integraties die standaard aan staan (onder default_config) die niet voor iedereen relevant zijn (assist bv).

De discussie is dus "een concurrent kan niet zo prominent in HA komen en dus is het niet open". Terwijl er geen concurrent is / geen bewijs is dat een concurrent is geweigerd. En een concurrent kan minimaal een integratie als custom component aanbieden (dus forken is nergens voor nodig). Maar ook een PR aanmaken om de (custom) component op te nemen in de core repository en dus " standaard installatie". En zo lang niemand heeft gevraagd naar of zo'n PR geaccepteerd zou worden (/de PR gewoon aanmaakt) valt er geen enkele conclusie te trekken over "openheid" en/of dat Nabu Casa wordt voorgetrokken. Je kunt alleen zeggen dat ("heel toevallig") Nabu Casa het enige bedrijf is dat heeft geprobeerd zo'n component op te nemen in HA, en dat is ze gelukt.

Volgens mij is dat niet de discussie. Het gaat hem niet om de concurrenten of andere oplossingen maar juist om de gebruiker. Hij vraagt hoe Open Source is het nou eigenlijk als je een winstgevend losstaand bedrijf zo prominent weergeeft. Belangen kunnen dan makkelijk verstrengeld raken. Ik geloof dat dat in dit geval niet zou gebeuren, maar het gaat denk ik om het principe. En het is een lastige. De vraag is waarom is HA onder Open Home Foundation geschoven als het zo ingevlochten zit met Nabu Casa. Niet alleen met de integratie maar ook vooral kwa ontwikkeling/ontwikkelaars die allen bij Nabu Casa zitten.
Wat zou er gebeuren als Nabu Casa wordt verkocht aan een investeerder. Wat als ze reclames en analytics er in willen zetten? Wat als ze aan de backend kant beginnen met al het netwerk verkeer loggen? Wordt de integratie dan meteen verwijderd? Wat gebeurt er met de ontwikkelaars. Komt er een fork?

Hij eindigt ook met deze statement die je toch best mag stellen?

Before it was Nabu Casa’s project, this was all fine. But now that Home Assistant is owned by the Open Home Foundation, I would argue that either:

all upsells and references to Nabu Casa must be removed, or;

any company can advertise their services within the ui (similar to Microsoft being forced to show a browser selection screen).

Mijn voorkeur zou hier ook naar uit gaan om eerlijk te zijn. Meer transparantie.

[ Voor 17% gewijzigd door Kodess op 12-11-2024 14:20 ]

[Septillion]

@Kodess Naar mijn idee kan dat prima. De manier hoe het er nu in zit kan ik ook bijna geen reclame noemen en het staat zo ver ik kan zien vrij om als alternatieve aanbieder erin te komen. Met als voorwaarde dat je dus ook support aan het project moet geven en het geen data deelt als je het niet gebruikt. Eventuele ander aanbieder zou gewoon onder hetzelfde kopje "Home Assiant Cloud" kunnen. Misschien dat het wat anders vormgegeven moet worden als er 20 aanbieders zijn.

Dus volgens mij zijn we dus gewoon al bij 'any company can advertise their ([red.]Home Assistant Cloud) services within the ui".

[HuismAndré]

alex3305 schreef op dinsdag 12 november 2024 @ 11:45:
@Septillion Ik ben het tegenovergestelde. Ik doe (bijna) alles in YAML. Wellicht is dat beroepsdeformatie .

Engels is logischer, vooral met automatiseringen. Maar ik heb alles in het Nederlands staan. Vind dan de UX als Nederlander wat beter en de WAF wat hoger,

Entities in het Engels en Names in het Nederlands is een mooi compromis. Tijdens het proggen kun je Engels blijven denken en aan de buitenkant ziet alles er Nederlands uit.

[alex3305]

RobertMe schreef op dinsdag 12 november 2024 @ 13:57:
Nouja, ik heb de default_config: dus niet meer in de configuration.yaml staan en heb geen issues (dus het frontend is er niet afhankelijk van?). Uiteraard wel dan een "helr lijst" van componenten zelf moeten opnemen.

Er wordt een check gedaan vanuit de frontend of het cloud component geladen is. Aan de hand daarvan wordt bepaalde logica uitgevoerd. Dat is uniek ten opzichte van andere integraties of componenten.

Dat lijkt me best sterk. Als er bv breaking changes in de code worden gedaan zal degene die die changes doet ervoor moeten zorgen dat alles blijft werken (voor alle ingebouwde componenten). Anders kan die change gewoon niet geaccepteerd worden.

Ik zie dat toch anders. Een recent voorbeeld hiervan is het Z-Wave Climate validate temperature(s) out of range issue. Vanaf 2024.8 was er plots strikte validatie op ingevoerde setpoints. Deze verandering was alleen maar een voetnoot in de release notes, maar zorgde ervoor dat de meeste van mijn radiatorknoppen niet meer werkte. Een PR werd direct afgeschoten met daarin o.a. de reactie: "There is nothing to fix [...]" van een van de hoofdontwikkelaars. Dan is het wel gedocumenteerd, maar toch is er dan een community afhankelijkheid van Home Assistant core developers (die allemaal bij Nabu Casa werken) om een dergelijke verandering geaccepteerd te krijgen.

En hetzelfde zie je bv bij de Linux kernel. [...] Maar HA documenteert wel hun breaking API changes voor custom componenten.

Zeker, maar dat heeft niets met Cloud component zelf te maken. Dat is een speciaal component met een hele strakke koppeling met de frontend. Ik betwijfel enorm of dit component wel te vervangen is door een custom component zoals de oprichter van Homey suggereert.

Bij Linux zit dat dan toch anders in elkaar. Daar komt niet in de instellingen van het OS naar voren dat je een managed Linux oid kunt afnemen. Daar zit geen commerciële partij naast of achter. Waarmee ik er geen oordeel over heb, maar het is wat mij betreft appels en peren vergelijken.

En ja, met dit soort acties maak je jezelf ook niet geloofwaardiger in de open-source community. Alweer een paar jaar geleden en uiteindelijk wel opgelost, maar handig is anders.

[RobertMe]

alex3305 schreef op dinsdag 12 november 2024 @ 15:18:
[...]

Er wordt een check gedaan vanuit de frontend of het cloud component geladen is. Aan de hand daarvan wordt bepaalde logica uitgevoerd. Dat is uniek ten opzichte van andere integraties of componenten.

Nja, dat is dan mogelijk lastig voor andere cloud providers. Maar dat toont dus wel aan dat het frontend niet stuk gaat als de integratie uit staat

[...]

Ik zie dat toch anders. Een recent voorbeeld hiervan is het Z-Wave Climate validate temperature(s) out of range issue. Vanaf 2024.8 was er plots strikte validatie op ingevoerde setpoints. Deze verandering was alleen maar een voetnoot in de release notes, maar zorgde ervoor dat de meeste van mijn radiatorknoppen niet meer werkte. Een PR werd direct afgeschoten met daarin o.a. de reactie: "There is nothing to fix [...]" van een van de hoofdontwikkelaars. Dan is het wel gedocumenteerd, maar toch is er dan een community afhankelijkheid van Home Assistant core developers (die allemaal bij Nabu Casa werken) om een dergelijke verandering geaccepteerd te krijgen.

Dat is iets geks in ZWave en staat los van Home Assistant. De wijzigingen in HA zijn backwards compatible gedaan (door een fallback te doen). Alleen ia die fallback in jou specifiek geval niet goef genoeg en zou je liever uberhaupt de fallback niet nodig hebben (maar is wel nodig doordat het eerst in ZWave niet verplicht was om aan te geven welke min & max er moest zijn).
Dit gaat dus ook niet om een API breakage, maar een ongelukkige samenloop waardoor bepaalde situaties niet meer zo werken als voorheen (maar het niet stuk is / de boel crasht).
En als HA een andere cloud integratie zou accepteren zullen ze bij API changes dus ook alle ("gebundelde") integraties moeten fixen (wat nogmaals, prima het geval was in jouw situatie. Want er is een fallback etc).

[...]

Zeker, maar dat heeft niets met Cloud component zelf te maken. Dat is een speciaal component met een hele strakke koppeling met de frontend. Ik betwijfel enorm of dit component wel te vervangen is door een custom component zoals de oprichter van Homey suggereert.

Ook al is die koppeling nog zo strak, het kan wel worden uit gezet (je hebt zelf al naar de relevante code gelinkt ). En die 3th party kan ook zelf de benodigde wijzigingen in het frontend doen om een net zo strakke koppeling met hun integratie te doen.

En ja, met dit soort acties maak je jezelf ook niet geloofwaardiger in de open-source community. Alweer een paar jaar geleden en uiteindelijk wel opgelost, maar handig is anders.

Ik kende het niet. Maar een van de laatste reacties van Frenck vind ik wel duidelijk hierin. Home Assistant komt gebundeld met een hele berg aan gebundelde Python libraries waarbij er een min of meer harde koppeling is tussen de HA versie en de versie van de library. Deze twee kun je dus ook niet onafhankelijk van elkaar installeren en gebruiken. Dat Nixos vervolgens ogenschijnlijk allemaal losse packages wilt maken van deze libraries en deze onafhankelijk van HA wilt updaten (en installeren) is raar. En vraagt ook om bergen aan compatibiliteitsproblemen (bij een HA update niet de onderliggende libraries updaten en dingen die daardoor stuk gaan). Best logisch dus dat hij zich daar tegen uit sprak. Want als Nixos een package "Ambee" aanbied en daarbij linkt naar Frenck dan lijkt het net alsof hij daar volledige support op gaat geven en bij incompatibiliteit van HA + Ambee (op Nixos) hij daar support op gaat geven. Terwijl in totaliteit de manier waarop Nixos HA ter installatie aanbied niet matcht met de manier waarop je HA zou moeten installeren (in de zin van één package met alle dependencies gebundeld. En niet een HA package dat binnen de Nixos package manager depend op tientallen/honderden andere packages uit de Nixos package manager waarbij de kans groot is dat er mismatches in versies zijn).

Edit:
Naar mijn idee (als ik het goed interpreteer) gaat dat verzoek van Frenck ook niet in tegen open source of zo. Maar om "ja, jullie kunnen doen wat jullie willen (want open source). Maar het is heel erg dom en ik krijg dadelijk de klachten van jullie gebruikers voor jullie domme actie. En vraag daarom om dit niet te doen".

[ Voor 3% gewijzigd door RobertMe op 12-11-2024 15:52 ]

[Septillion]

@alex3305 Volgens mij zou een ander cloud component daar dus ook prima op in kunnen haken. Dat er dus ook was aan de frontend aangepast moet worden vind ik nog niet zo raar. Zou het wat modulairder kunnen, zeker. Maar gezien de organische maar snelle groei vind ik het nog niet zo heel raar. Dus als een andere partij er op in wil haken zou dat modulair maken een mooie eerste bijdrage zijn

offtopic:
En hoe vervelend ook, ik ben het dus ook nog steeds eens met de keuze van het team dat de min-max in het component aangepast moet worden. Gezien het diep geworteld zit in de climate filosofie van HA en daaruit dus altijd (of al een hele tijd) gold dat min-max een verplichting was. Dus de fix zou dus naar mijn idee in Z-wave JS gedaan moeten worden, dat is ook in the long run meer gebruikersvriendelijk. Dat dit heeft kunnen gebeuren in een standaard integratie is natuurlijk wel jammer. Dat vind ik feitelijk het grotere pijnpunt.

[alex3305]

RobertMe schreef op dinsdag 12 november 2024 @ 15:47:
Dit gaat dus ook niet om een API breakage, maar een ongelukkige samenloop waardoor bepaalde situaties niet meer zo werken als voorheen (maar het niet stuk is / de boel crasht).

Eens, maar het is wel stuk, want mijn Z-Wave knoppen die voldoen aan de Z-Wave spec werken immers niet meer met Home Assistant. Theoretisch gezien ontbrak hierdoor zelfs even de Z-Wave certificering. Er werd namelijk niet meer voldaan aan de standaard. Dit heeft de hoofdontwikkelaar van Z-Wave JS ook bevestigd.

Ook al is die koppeling nog zo strak, het kan wel worden uit gezet (je hebt zelf al naar de relevante code gelinkt ). En die 3th party kan ook zelf de benodigde wijzigingen in het frontend doen om een net zo strakke koppeling met hun integratie te doen.

Het kan uit worden gezet, maar daar houdt het ook mee op. Dergelijke veranderingen in de frontend zouden dan door Home Assistant ontwikkelaars, in dienst van Nabu Casa, goedgekeurd moeten worden om upstream gemerged te worden. De kans hierop acht ik enorm klein. Hopelijk kan iemand het tegendeel bewijzen.

Daarnaast zijn er nog meer plekken waar er specifiek naar Nabu Casa gelinkt wordt. Dat is niet zomaar te vervangen. Ook omdat je tegen gesloten onderdelen aan aan het werken bent. Bijvoorbeeld in het Cast element. En als je een custom frontend mee wilt geven moet je of met een development frontend gaan werken of Home Assistant opnieuw bundlen.

Naar mijn idee (als ik het goed interpreteer) gaat dat verzoek van Frenck ook niet in tegen open source of zo. Maar om "ja, jullie kunnen doen wat jullie willen (want open source). Maar het is heel erg dom en ik krijg dadelijk de klachten van jullie gebruikers voor jullie domme actie. En vraag daarom om dit niet te doen".

De boodschap: ik wijzig de licentie wel en dan kunnen jullie geen upstream meer gebruiken vind ik nogal anti open-source. Ik begrijp zijn standpunt verder wel.

[alex3305]

@Septillion Even voor de duidelijkheid. Ik ben 0,0 problemen met Nabu Casa of dat Home Assistant daarmee adverteert. Ook niet met de koppeling naar de frontend. Maar ik denk dat het naïef is om te denken dat er zomaar een alternatief cloud component in Home Assistant geïmplementeerd kan worden. Waarbij er officieel (voor zover ik weet) ook geen gebruik gemaakt mag worden van Home Assistant naam of branding.

Ik vind de gelinkte Reddit vraag wellicht wat onhandig of hard gesteld, maar wel terecht.

[sterremos]

ben vandaag bezig geweest om HACS te installeren op home assistant core via ssh, Hacs gedownload bij github.
geïnstalleerd bij de map home /data/homeassistant/custom_components/hacs.
In de map hacs staan de files.



code opgehaald bij github en ingevuld in configuration yaml

code:

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

hacs: 
  token: ghp_11111111111111111111111

maar ik blijf maar een melding krijgen dat Integration error: hacs - Integration 'hacs' not found.
Het lukt me maar niet om de fout te vinden.

[JustMyOpinion]

sterremos schreef op dinsdag 12 november 2024 @ 19:07:
ben vandaag bezig geweest om HACS te installeren op home assistant core via ssh, Hacs gedownload bij github.
geïnstalleerd bij de map home /data/homeassistant/custom_components/hacs.
In de map hacs staan de files.

[Afbeelding]

code opgehaald bij github en ingevuld in configuration yaml

code:

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

hacs: 
  token: ghp_11111111111111111111111

maar ik blijf maar een melding krijgen dat Integration error: hacs - Integration 'hacs' not found.
Het lukt me maar niet om de fout te vinden.

[Afbeelding]

Heb je echt alles letterlijk gedaan wat hier staat? https://www.hacs.xyz/docs/use/configuration/basic/

[TheFes]

sterremos schreef op dinsdag 12 november 2024 @ 19:07:
ben vandaag bezig geweest om HACS te installeren op home assistant core via ssh, Hacs gedownload bij github.
geïnstalleerd bij de map home /data/homeassistant/custom_components/hacs.
In de map hacs staan de files.

[Afbeelding]

code opgehaald bij github en ingevuld in configuration yaml

code:

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

hacs: 
  token: ghp_11111111111111111111111

maar ik blijf maar een melding krijgen dat Integration error: hacs - Integration 'hacs' not found.
Het lukt me maar niet om de fout te vinden.

[Afbeelding]

HACS gebruikt geen YAML config meer, en je zult een herstart moeten doen voor de integratie geladen is.

Daarna zou je hem onder Settings > Devices & Services moeten kunnen toevoegen

[skank]

Zit met iets moeilijks

Ik heb mealie draaien als addon in HA
Nu wil ik dat dashboard casten naar mijn google hub
Dat casten op zich lukt met script MAAR

Het dashboard dat ik wil casten heeft bovenaan buttons (cast en stop cast) en daaronder een iframe
Op mn tablet binnenhuis, lukt het laden van dat iframe en zie ik daarin mooi de mealie addon over http
Ondertussen ben ik ook teweten gekomen dat google cast verplicht https is.

Nu komt en je weet het vermoedelijk al:
Bij het casten heb ik de melding kan iframes verwijzend naar websites over http niet laden als home assistant verbinding maakt over https

Ik gok dus dat dat het probleem is
De vraag is, hoe los ik dat op?
Dus het dashboard moet te bereiken zijn via https?

[TheFes]

skank schreef op dinsdag 12 november 2024 @ 20:47:
Zit met iets moeilijks

Ik heb mealie draaien als addon in HA
Nu wil ik dat dashboard casten naar mijn google hub
Dat casten op zich lukt met script MAAR

Het dashboard dat ik wil casten heeft bovenaan buttons (cast en stop cast) en daaronder een iframe
Op mn tablet binnenhuis, lukt het laden van dat iframe en zie ik daarin mooi de mealie addon over http
Ondertussen ben ik ook teweten gekomen dat google cast verplicht https is.

Nu komt en je weet het vermoedelijk al:
Bij het casten heb ik de melding kan iframes verwijzend naar websites over http niet laden als home assistant verbinding maakt over https

Ik gok dus dat dat het probleem is
De vraag is, hoe los ik dat op?
Dus het dashboard moet te bereiken zijn via https?

Mealie ook beschikbaar maken via https via the reverse proxy?

[skank]

TheFes schreef op dinsdag 12 november 2024 @ 20:52:
[...]


Mealie ook beschikbaar maken via https via the reverse proxy?

Dit is met nginx zeker?
Voor mij is HA nu accesible met cloudflare (ik kom van nginx)

[ Voor 20% gewijzigd door skank op 12-11-2024 20:55 ]

[sterremos]

TheFes schreef op dinsdag 12 november 2024 @ 19:33:
[...]


HACS gebruikt geen YAML config meer, en je zult een herstart moeten doen voor de integratie geladen is.

Daarna zou je hem onder Settings > Devices & Services moeten kunnen toevoegen

He dat wist ik niet Yaml verwijderd , cache verwijderd en opgestart een paar keer maar geen Hacs nog.

[TheFes]

sterremos schreef op dinsdag 12 november 2024 @ 20:58:
[...]


He dat wist ik niet Yaml verwijderd , cache verwijderd en opgestart een paar keer maar geen Hacs nog.

Als ik jou was zou ik gewoon de stappen uit de documentatie volgen. Daar staat ook hoe het werkt voor HA Core (en dat is dus niet wat jij gedaan hebt)

https://hacs.xyz/docs/use/#to-download-hacs

[TheFes]

skank schreef op dinsdag 12 november 2024 @ 20:53:
[...]

Dit is met nginx zeker?
Voor mij is HA nu accesible met cloudflare (ik kom van nginx)

Kan, hoe jij zelf wil.

[simonj]

verkeerde topic

[ Voor 87% gewijzigd door simonj op 13-11-2024 07:56 ]

[dotcom87]

Zijn er hier al veel mensen die een lokale voice assistant hebben draaien in HA?

Ik zou er ook graag eens mee beginnen (ter vervanging van mijn Google Home speakers), maar ik weet niet goed welke hardware te kopen. De Google Home speakers klinken luid (ik gebruik deze ook als "notification broadcast" in ons huis), dus dat zou ik ook wel graag willen in mijn nieuwe "smart speaker".


Suggesties zijn altijd welkom!

[TheFes]

dotcom87 schreef op woensdag 13 november 2024 @ 08:10:
Zijn er hier al veel mensen die een lokale voice assistant hebben draaien in HA?

Ik zou er ook graag eens mee beginnen (ter vervanging van mijn Google Home speakers), maar ik weet niet goed welke hardware te kopen. De Google Home speakers klinken luid (ik gebruik deze ook als "notification broadcast" in ons huis), dus dat zou ik ook wel graag willen in mijn nieuwe "smart speaker".


Suggesties zijn altijd welkom!

Mijn suggestie, wacht tot volgende maand, dan komt de Voice PE van Nabu Casa uit.

[JeroenH]

Óf mijn SolarEdge cloud-integratie, óf de SolarEdge API voelt zich niet zo lekker:



Als ik kijk naar de kWh-teller, dan ziet dat er zo uit. Bovenste grafiek is van de lokale integratie, onderste grafiek is van de cloud-integratie. Zoek de verschillen Het energy dashboard haalt zijn gegevens uit de cloud-integratie, dit zou ik graag overzetten maar dat is natuurlijk weer niet zo makkelijk



Echt gekke dingen te zien:



Hebben meer mensen dit?

-edit- eerst de integratie en later heel HA geherstart natuurlijk, dit had geen resultaat.

[ Voor 3% gewijzigd door JeroenH op 13-11-2024 08:48 ]

[Bart ®]

JeroenH schreef op woensdag 13 november 2024 @ 08:41:
Óf mijn SolarEdge cloud-integratie, óf de SolarEdge API voelt zich niet zo lekker:

[Afbeelding]

Als ik kijk naar de kWh-teller, dan ziet dat er zo uit. Bovenste grafiek is van de lokale integratie, onderste grafiek is van de cloud-integratie. Zoek de verschillen Het energy dashboard haalt zijn gegevens uit de cloud-integratie, dit zou ik graag overzetten maar dat is natuurlijk weer niet zo makkelijk

[Afbeelding]

Echt gekke dingen te zien:

[Afbeelding]

Hebben meer mensen dit?

-edit- eerst de integratie en later heel HA geherstart natuurlijk, dit had geen resultaat.

ff gecheckt, doet hier ook raar sinds 11 november.

[JeroenH]

Bart ® schreef op woensdag 13 november 2024 @ 08:58:
ff gecheckt, doet hier ook raar sinds 11 november.

Grrrr, dat betekent dat ik het niet zelf op kan lossen. Bedankt.

[Hmmbob]

sterremos schreef op dinsdag 12 november 2024 @ 19:07:
ben vandaag bezig geweest om HACS te installeren op home assistant core via ssh, Hacs gedownload bij github.
geïnstalleerd bij de map home /data/homeassistant/custom_components/hacs.
In de map hacs staan de files.

[Afbeelding]

code opgehaald bij github en ingevuld in configuration yaml

code:

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

hacs: 
  token: ghp_11111111111111111111111

maar ik blijf maar een melding krijgen dat Integration error: hacs - Integration 'hacs' not found.
Het lukt me maar niet om de fout te vinden.

[Afbeelding]

Euh, je hebt niet gedaan wat er in de handleiding staat. Je hebt ALLE files van die hele repo in je /custom_components/hacs/ map gezet. Dat had alleen de inhoud van de submap /custom_components/hacs/ van die repo moeten zijn.

Edit: los daarvan, manual download is helemaal geen recommended manier om HACS te installeren. Gewoon de handleiding volgen is beter.

[ Voor 4% gewijzigd door Hmmbob op 13-11-2024 09:05 ]

[Septillion]

@JeroenH Zou ik de API verdenken...

Work around zou kunnen zijn om een trigger base template sensor te maken die alleen stijgende waardes doorlaat.

[JeroenH]

Septillion schreef op woensdag 13 november 2024 @ 09:05:
@JeroenH Zou ik de API verdenken...

Ja dat is het ongetwijfeld. Ik zal het melden bij SE, maar of ze er iets mee doen...

Work around zou kunnen zijn om een trigger base template sensor te maken die alleen stijgende waardes doorlaat.

Lange termijn-oplossing is overschakelen op de lokale integratie voor het energy dashboard. Wil ik sowieso , want dan kan ik de omvormer afsluiten van internettoegang, dat is dan nergens meer voor nodig. Maar dan zit ik er weer mee dat ik dan met twee datasets zit...

[TheFes]

JeroenH schreef op woensdag 13 november 2024 @ 09:38:
[...]


Ja dat is het ongetwijfeld. Ik zal het melden bij SE, maar of ze er iets mee doen...


[...]


Lange termijn-oplossing is overschakelen op de lokale integratie voor het energy dashboard. Wil ik sowieso , want dan kan ik de omvormer afsluiten van internettoegang, dat is dan nergens meer voor nodig. Maar dan zit ik er weer mee dat ik dan met twee datasets zit...

Heb je de lokale integratie pas veel later toegevoegd vergeleken met de cloud versie?

[jwjol]

Goedemorgen,

Wie heeft er ervaring met de koppeling tussen HA en een Nest Learning Thermostat V3?
De koppeling is inmiddels gelukt (volgens https://www.home-assistant.io/integrations/nest/) en ik kan o.a. vanaf het dashboard de temperatuur instellen.
Wat me niet lukt, is het door HA laten versturen van een notificatie naar mijn mobiel, bij elke (handmatige) wijziging van de temperatuur op de Nest.
Ik ben een volledige newbie wat HA betreft (kom van een Homey Pro Early 2019), heb al heel wat websites en YT filmpjes bekeken, maar hier kom ik niet uit.

Wie o wie?

[JustMyOpinion]

jwjol schreef op woensdag 13 november 2024 @ 10:08:
Goedemorgen,

Wie heeft er ervaring met de koppeling tussen HA en een Nest Learning Thermostat V3?
De koppeling is inmiddels gelukt (volgens https://www.home-assistant.io/integrations/nest/) en ik kan o.a. vanaf het dashboard de temperatuur instellen.
Wat me niet lukt, is het door HA laten versturen van een notificatie naar mijn mobiel, bij elke (handmatige) wijziging van de temperatuur op de Nest.
Ik ben een volledige newbie wat HA betreft (kom van een Homey Pro Early 2019), heb al heel wat websites en YT filmpjes bekeken, maar hier kom ik niet uit.

Wie o wie?

Wat je beschrijft zijn eigenlijk twee aparte zaken. Het koppelen van de Nest is gelukt, dus dat is eigenlijk klaar. Wat je nu moet doen is een automation maken die je een bericht stuurt bij elke handmatige wijziging. Zoek even op notification, zijn meerdere manieren om berichten te versturen (via HA app, Telegram etc).

[Septillion]

@JeroenH Je hebt nu beide integraties?

Kant en klaar is dat inderdaad wat onhandig. Maar na mijn avontuur met een corrupte database mijn avontuur met een corrupte database zeg ik dat het niet onmogelijk is om statistieken van twee sensoren te mergen. Maar zal wel afhangen van wanneer het over moet en wat er nu voor beide al instaat.

[Xqlus1ve]

Iemand bekend met de yaml code van the mushroom template cards, en dan met name de animations?

Card mode 3 is geinstalleerd, heb het volgende in mijn configuration staan, verwijzing naar de card-mod.js in de correcte folder:
[code=yaml]
frontend:
themes: !include_dir_merge_named themes
extra_module_url:
- /www/community/lovelace-card-mod/card-mod.js
[/code]


originele code:
[code=yaml]
type: custom:mushroom-template-card
icon: mdi:washing-machine
icon_color: amber
primary: Washing Machine
card_mod:
style:
mushroom-shape-icon$: |
ha-icon {
--icon-animation: shake 400ms ease-in-out infinite, drum 2s ease infinite;
transform-origin: 50% 110%;
}
@keyframes shake {
0%, 100% { transform: translate(0, 0) rotate(0); }
20% { transform: translate(0.4px, -0.4px) rotate(-4deg); }
40% { transform: translate(-0.4px, 0.4px) rotate(4deg); }
60% { transform: translate(0.4px, 0.4px) rotate(-4deg); }
80% { transform: translate(-0.4px, -0.4px) rotate(4deg); }
}
@keyframes drum {
50% { clip-path: polygon(0 0, 0 100%, 35% 100%, 34% 68%, 60% 41%, 71% 56%, 65% 74%, 47% 79%, 32% 69%, 35% 100%, 100% 100%, 100% 0); }
}
[/code]

Maar zodra ik dit implimenteer dan "keyframes drum" niet correct, groter dan het in de icon getoont word, en inplaats van fade in/out is het een zwarte icon die knippert)
[code=yaml]
type: custom:mushroom-template-card
entity: input_text.washing_machine_status
icon: mdi:washing-machine
icon_color: light-green
secondary: "{{ states('input_text.washing_machine_status') }}"
primary: Washing Machine
card_mod:
style: |
mushroom-shape-icon {
{% if is_state(config.entity, 'Standby') %}
--card-mod-icon: mdi:washing-machine;
animation: shake 400ms ease-in-out infinite, drum 2s ease infinite; transform-origin: 50% 110%;
{% endif %}
display: flex;
}
@keyframes shake {
0%, 100% { transform: translate(0, 0) rotate(0); }
20% { transform: translate(0.4px, -0.4px) rotate(-4deg); }
40% { transform: translate(-0.4px, 0.4px) rotate(4deg); }
60% { transform: translate(0.4px, 0.4px) rotate(-4deg); }
80% { transform: translate(-0.4px, -0.4px) rotate(4deg); }
}
@keyframes drum {
50% { clip-path: polygon(0 0, 0 100%, 35% 100%, 34% 68%, 60% 41%, 71% 56%, 65% 74%, 47% 79%, 32% 69%, 35% 100%, 100% 100%, 100% 0); }
}

[/code]

[magnifor]

Nieuwste aanwinst in mijn Dashboard

[Hmmbob]

magnifor schreef op woensdag 13 november 2024 @ 11:01:
Nieuwste aanwinst in mijn Dashboard

[Afbeelding]

Beter als je een HA push message krijgt als je op 1 van die wegen rijdt

[magnifor]

Hmmbob schreef op woensdag 13 november 2024 @ 11:04:
[...]

Beter als je een HA push message krijgt als je op 1 van die wegen rijdt

Haha, ik heb niet eens flitsmeister. Hou over het algemeen netjes aan mijn snelheid. Voordat ik de weg op ga even kijken waar ze staan en dan daar wat voorzichtiger rijden. Heb al jaren geen Flitsmeister op mijn tel.

[Hmmbob]

Waze gebruiken. Prima waarschuwingen onderweg, en een integratie voor HA waarmee je (bijvoorbeeld) kan laten berekenen hoe lang je erover doet om thuis te komen en dit dan weer aan je betere helft sturen via een notificatie

https://github.com/hmmbob...l_time_notifications.yaml

[ Voor 19% gewijzigd door Hmmbob op 13-11-2024 11:11 ]

[Hmmbob]

TheFes schreef op woensdag 13 november 2024 @ 08:22:
[...]


Mijn suggestie, wacht tot volgende maand, dan komt de Voice PE van Nabu Casa uit.

Zit daar ook bluetooth (proxy) op?

Dan zou het een mooie combi-vervanging zijn voor wat Google Home Mini's + losse m5stack lite Bluetooth proxies....

[ Voor 19% gewijzigd door Hmmbob op 13-11-2024 11:20 ]

[mr.inno]

Hmmbob schreef op woensdag 13 november 2024 @ 11:11:
Waze gebruiken. Prima waarschuwingen onderweg, en een integratie voor HA waarmee je (bijvoorbeeld) kan laten berekenen hoe lang je erover doet om thuis te komen en dit dan weer aan je betere helft sturen via een notificatie

https://github.com/hmmbob...l_time_notifications.yaml

Mag ik vragen waarom je in één trigger 3 minuten extra lijkt te rekennen en in de ander 2 minuten extra?

code:

Waze denkt dat hij om {{ (now() + timedelta(minutes=(3 + states("sensor.reistijd_bob_naar_huis") | int))).strftime("%H:%M") }} thuis is.

code:

 Waze denkt dat hij om {{ (now() + timedelta(minutes=(2 + states("sensor.reistijd_bob_naar_huis") | int))).strftime("%H:%M") }} thuis is.

[JeroenH]

TheFes schreef op woensdag 13 november 2024 @ 09:44:
Heb je de lokale integratie pas veel later toegevoegd vergeleken met de cloud versie?

Ja, klopt. Cloud-integratie gaat ongeveer 2½ jaar terug, lokale integratie pas een half jaartje of zo.

Septillion schreef op woensdag 13 november 2024 @ 10:54:
@JeroenH Je hebt nu beide integraties?

Ja klopt. Jarenlang geleund op de cloudintegratie, maar toen ik dynamisch terugregelen wilde configureren moest ik naar de lokale integratie omdat de cloudintegratie a) het daadwerkelijk terugregelen niet ondersteunt en b) slechts elke 15 minuten data aanlevert. Maar de input van het energy dashboard op de cloud-integratie gelaten, omdat ik toen ook al geen manier zag om over te gaan.

Kant en klaar is dat inderdaad wat onhandig. Maar nar mijn avontuur met een corrupte database mijn avontuur met een corrupte database zeg ik dat het niet onmogelijk is om statistieken van twee sensoren te mergen. Maar zal wel afhangen van wanneer het over moet en wat er nu voor beide al instaat.

Cloud-integratie: 2½ jaar, even lang als de meetdata uit mijn slimme meter. Lokale integratie: klein half jaar.

De enige (hopelijk) "makkelijke" manier die ik kan bedenken is de historie van de lokale integratie helemaal leeg maken, de cloud-integratie onklaar maken (maar niet verwijderen) en de lokale integratie toevoegen aan het energy dashboard. Dat is rommelig, maar hey, mijn watermeter ziet er zo uit na flink wat gekluns met de ESP32 door mij een tijd terug:





Weer iets voor op mijn wishlist voor HA: het eenvoudig kunnen samenvoegen van en knutselen aan grote hoeveelheden meetwaarden. Maar ik snap ook dat dat niet triviaal is, en dat iedereen daar iets anders van verwacht....

[Hmmbob]

mr.inno schreef op woensdag 13 november 2024 @ 11:25:
[...]


Mag ik vragen waarom je in één trigger 3 minuten extra lijkt te rekennen en in de ander 2 minuten extra?

code:

Waze denkt dat hij om {{ (now() + timedelta(minutes=(3 + states("sensor.reistijd_bob_naar_huis") | int))).strftime("%H:%M") }} thuis is.

code:

 Waze denkt dat hij om {{ (now() + timedelta(minutes=(2 + states("sensor.reistijd_bob_naar_huis") | int))).strftime("%H:%M") }} thuis is.

Dat mag, maar op het verschil heb ik geen antwoord

Ik pas het meteen even aan

ik pas overigens 2 minuten extra toe omdat het alijd fijner is om "eerder dan verwacht" binnen te lopen, dan "te laat te komen"

[Septillion]

@JeroenH Op zich, als je de cloud integratie nu gewoon helemaal verwijdert dan blijft je history bewaard. Als je daarna de lokale entiteiten dezelfde naam geeft als de oude cloud entiteiten gaat de boel gewoon door. Met alleen misschien een fout in de overgang die je dan handmatig moet aanpassen.

[JeroenH]

Septillion schreef op woensdag 13 november 2024 @ 12:01:
@JeroenH Op zich, als je de cloud integratie nu gewoon helemaal verwijdert dan blijft je history bewaard.

Ik heb er nu al nachtmerries van. Backups, ik weet het, maar toch....

Zeker weten dat de historie dan bewaard blijft?

Als je daarna de lokale entiteiten dezelfde naam geeft als de oude cloud entiteiten gaat de boel gewoon door. Met alleen misschien een fout in de overgang die je dan handmatig moet aanpassen.

Ik zal eens kijken of ik dat aandurf. Als er niemand thuis is, ik goed geslapen heb, mijn vloek-quotum nog niet verbruikt is, en ik minimaal 3-4 uur heb om het terug te knutselen als er iets onverwachts verkeerd gaat

[RobertMe]

Hmmbob schreef op woensdag 13 november 2024 @ 11:20:
[...]

Zit daar ook bluetooth (proxy) op?

Dan zou het een mooie combi-vervanging zijn voor wat Google Home Mini's + losse m5stack lite Bluetooth proxies....

Er draait ESPHome op, waarvan de code ook al online staat. En het zal vast een ESP32 chip zijn (ook dat kun je uit de repo / YAML halen ), en AFAIK ondersteunen alle ESP32 chips die wifi hebben ook Bluetooth (sommige ondersteunen alleen Zigbee, en dus geen wifi noch Bluetooth). Dus ja: lijkt mij dat BT Proxy prima moet werken er op.

Edit:
De repo met ESPHome verhaal dat er op draait: https://github.com/esphome/home-assistant-voice-pe

[ Voor 8% gewijzigd door RobertMe op 13-11-2024 12:08 ]

[Septillion]

@JeroenH Ja, die blijven bewaard. maar backup is altijd slim

Grap is dat het corrupt raken van mijn database namelijk ook voor een opruiming gezorgd heb. Ik heb namelijk alleen de statistiek van entiteiten overgezet die ook in de nieuwe db zit. En bij een vergelijking welke items dan niet overgenomen zouden worden kwam ik bijvoorbeeld het oude entity id tegen van mijn PV omvormer welk ik vrij snel na het toevoegen hernoemt had.

Maar ken het gevoel, het niet voor niets ruim 2 maanden geduurd voor ik het aandurfde om te klooien met de oude db

[ Voor 16% gewijzigd door Septillion op 13-11-2024 14:44 ]

[mbuurman]

Doel:
Op het dashboard als 'tap behavior/tap action' van een 'input_bolean' entity het logbook laten zien in plaats van 'More Info' als schakelaar.

Wat ie nu laat zien:


Wat ik graag zou willen zien:


Ik heb de volgende (onderdeel van een) code in een automation om te bepalen of er iemand aanwezig is in een ruimte. Voor deze opzet gebruik ik een Helper in de vorm van een toggle/input_boolean en dat werkt gewoon goed.

YAML:

actions:
    default:
      - condition: trigger
        id: idle
      - condition: and
        conditions:
          - condition: state
            entity_id: binary_sensor.2_zolder_pir_occupancy
            state: "off"
          - condition: state
            entity_id: binary_sensor.2_washok_presence_occupancy
            state: "off"
      - target:
          entity_id: input_boolean.aanwezigheid_washok
        data: {}
        action: input_boolean.turn_off

Maar als ik de 'input_boolean.aanwezigheid_washok'-entity op een dashboard zet dan lijkt het een schakelaar die je kun aan/uit zetten of het opent als 'tap_action' standaard 'more-info' waar het zich laat zien als een schakelaar. Maar dat is in voor deze toepassing natuurlijk niet de bedoeling.

Nu heb ik het geprobeerd met het openen van een url naar het logbook, maar dan opent HA een nieuwe browserpagina. Wel de info die ik wil zien, maar niet zoals ik het wil:

YAML:

tap_action:
  action: url
  url_path: >-
    http://172.31.254.54:8123/logbook?entity_id=input_boolean.aanwezigheid_washok

Als ik een template-helper aanmaak en deze koppel aan de input-bolean met:

Django/Jinja:

{{ states('input_boolean.aanwezigheid_washok') }}

Dan kan ik bij de aangemaakte binairy_sensor wel met 'tap-action' - 'more-info' het logbook direct laten zien.
Maar dan heb ik voor iedere ruimte in huis 2 helpers nodig om dit voor elkaar te krijgen en dan vraag ik mij af of dit niet handiger voor elkaar te krijgen is....

Heeft iemand een goede suggestie?

[JeroenH]

Ze zijn overigens bij SolarEdge aan het knutselen aan de API, het gedrag is duidelijk anders:



Maar nog altijd gaat de bovenste grafiek soms omlaag, wat met deze waarde (kWh opwek) niet zou moeten kunnen. @Bart ® zie jij dit ook?

[TheFes]

@Hmmbob @mr.inno

Ik heb toevallig net deze automation gemaakt voor gebruik met Assist

YAML:

automation:
  - id: c1f376c8-2a14-4d27-b55a-688a8c2635e3
    alias: Voice - ETA Marleen & Martijn
    triggers:
      - alias: Trigger sentence
        trigger: conversation
        command:
          - Wanneer is (Marleen|Martijn|mama|papa) thuis
          - Wanneer wordt (Marleen|Martijn|mama|papa) thuis verwacht
          - Wanneer kan ik (Martijn|Marleen|mama|papa) thuis verwachten
          - "[wat is] [de] ETA [van] (Martijn|Marleen|mama|papa)"
    actions:
      - variables:
          name: >
            {{ 'Martijn' if trigger.sentence | lower is search('martijn|papa') else 'Marleen' }}
          gender: "{{ 'hij' if name == 'Martijn' else 'ze' }}"
          person: "person.{{ name | lower }}"
          waze: "sensor.{{ name | lower }}_naar_huis"
          proximity: "sensor.thuis_{{ name | lower }}_direction_of_travel"
      - action: homeassistant.update_entity
        target:
          entity_id: "{{ [waze,proximity, person] }}"
      - delay: 0.5
      - alias: Set response
        set_conversation_response: >
          {%- set eta = (now() + timedelta(minutes=2 + states(waze) | float(0))).strftime('%H:%M') %}
          {%- if is_state(person, 'home') %}
            {{ name }} is al thuis
          {%- elif is_state(waze, 'towards') %}
            {{ name }} is om {{ eta }} thuis.
          {%- elif is_state(proximity, 'away_from') %}
            {{ name }} gaat de verkeerde kant op, maar als {{ gender }} nu omdraait is {{ gender }} om {{ eta }} thuis.
          {%- else %}
            {{ name }} is nog niet onderweg, maar als {{ gender }} nu vertrekt is {{ gender }} om {{ eta }} thuis.
          {%- endif %}

[Bart ®]

JeroenH schreef op woensdag 13 november 2024 @ 14:06:
Ze zijn overigens bij SolarEdge aan het knutselen aan de API, het gedrag is duidelijk anders:

[Afbeelding]

Maar nog altijd gaat de bovenste grafiek soms omlaag, wat met deze waarde (kWh opwek) niet zou moeten kunnen. @Bart ® zie jij dit ook?

Nee bij mij gaat ie niet omlaag, maar hij gedraagt zich wel abnormaal: