Home Assistant: Open source Python3 home automation - deel 5

[belly89]

TheFes schreef op maandag 27 maart 2023 @ 15:11:
[...]


waarschijnlijk wel ja, na inladen van de config even in developer tools > statistics kijken of hij er dan bij staat.

Staat er inderdaad bij dan!!

[Xqlus1ve]

TheFes schreef op maandag 27 maart 2023 @ 14:45:
[...]


Maak je die sensoren zelf aan dan? Want als het template sensors zijn, kun je gewoon meteen zorgen dat ze goed zijn

Ja het is een sensor die gecombineerde enity van 6 stuks bij elkaar optelt, maar als template sensor werdt ik nog niet 123 wijzer, merk dat ik werkelijk met alles nog vast loop omdat ik nog niet weet hoe of wat

Volgende doelstelling is om er ook een cost entity van te maken met 2 tarieven zodat ik indivueel de kosten kan zien per vebruiker, ik maak mijn borst alvast nat

[CAP-Team]

Kon dat sinds de laatste versie ook niet via een helper?

[RobertMe]

Xqlus1ve schreef op maandag 27 maart 2023 @ 15:52:
[...]


Ja het is een sensor die gecombineerde enity van 6 stuks bij elkaar optelt, maar als template sensor werdt ik nog niet 123 wijzer, merk dat ik werkelijk met alles nog vast loop omdat ik nog niet weet hoe of wat

Ik heb niet de hele discussie gevolgd / teruggelezen. Maar als je puur de waarde van een X aantal sensoren bij elkaar wilt optellen kan dat met een helper. Aanmaken via de UI kan dan via Settings => Devices & Integrations => Helpers tab => Create Helper => Combine the state of several sensors. En dan Statistics characteristic: Sum gebruiken.

[IKKE86]

Toppe schreef op woensdag 22 maart 2023 @ 19:24:
[...]


Haha.

Alleen dus de vraag; kan je de kosten per dag eenvoudig op een andere plek her gebruiken?

Ora et Labora schreef op dinsdag 3 januari 2023 @ 10:22:
Wellicht een simpele vraag maar ik kan het tot nu toe nergens vinden.
Ik wil graag op m'n home-dashboard zien hoeveel kosten er deze dag gemaakt zijn met gas en elektra en de totale kosten.
Dit is in het energy-dashboard prima te zien maar ik wil dit graag in 1 oogopslag zien op m'n main-dashboard. Hoe pak ik dit het beste aan?
[Afbeelding]

Is het jullie (of andereren) nog gelukt om zelf een sensor te maken met de kosten van het stroomverbruik van vandaag?

Zelf kom ik niet verder dan dit, maar dit heeft natuurlijk weinig zin als je tarief elk uur wijzigt:

YAML:

{{ (states('sensor.zonneplan_p1_electricity_consumption_today')|float * states('sensor.zonneplan_current_electricity_tariff')|float)|round(2) }} 

[Xqlus1ve]

RobertMe schreef op maandag 27 maart 2023 @ 16:14:
[...]

Ik heb niet de hele discussie gevolgd / teruggelezen. Maar als je puur de waarde van een X aantal sensoren bij elkaar wilt optellen kan dat met een helper. Aanmaken via de UI kan dan via Settings => Devices & Integrations => Helpers tab => Create Helper => Combine the state of several sensors. En dan Statistics characteristic: Sum gebruiken.

Dat is correct, dat heb ik ook gedaan, daarna togevoegd aan Energy Dashboard, echter daar waaren bepaalde states incorrect om gebruikt te kunnen worden.

[TheFes]

Xqlus1ve schreef op maandag 27 maart 2023 @ 15:52:
[...]


Ja het is een sensor die gecombineerde enity van 6 stuks bij elkaar optelt, maar als template sensor werdt ik nog niet 123 wijzer, merk dat ik werkelijk met alles nog vast loop omdat ik nog niet weet hoe of wat

Volgende doelstelling is om er ook een cost entity van te maken met 2 tarieven zodat ik indivueel de kosten kan zien per vebruiker, ik maak mijn borst alvast nat

Gecombineerde sensoren is wel vragen om problemen als je die in je Energy dashboard wil gebruiken. Als er even eentje van de 6 wegvalt, wordt je totaal ineens lager. Dat zal als een reset geïnterpreteerd worden, waardoor het resterende deel bij het oude totaal opgeteld wordt, en je dus een spike in je verbruik krijgt.

Dan zou je in ieder geval moeten zorgen dat de gecombineerde sensor unavailable is als één van de bronsensoren unavailable is. En zelfs dan krijg je nog probremen mocht één van de bronsensoren bijvoorbeeld defect gaan, en je die dus wil vervangen. Dan wordt dat ook dus als een reset gezien.

Ik zou combineren van sensoren voor het Energy Dasboard zoveel mogelijk voorkomen.

[Xqlus1ve]

TheFes schreef op maandag 27 maart 2023 @ 16:32:
[...]


Gecombineerde sensoren is wel vragen om problemen als je die in je Energy dashboard wil gebruiken. Als er even eentje van de 6 wegvalt, wordt je totaal ineens lager. Dat zal als een reset geïnterpreteerd worden, waardoor het resterende deel bij het oude totaal opgeteld wordt, en je dus een spike in je verbruik krijgt.

Dan zou je in ieder geval moeten zorgen dat de gecombineerde sensor unavailable is als één van de bronsensoren unavailable is. En zelfs dan krijg je nog probremen mocht één van de bronsensoren bijvoorbeeld defect gaan, en je die dus wil vervangen. Dan wordt dat ook dus als een reset gezien.

Ik zou combineren van sensoren voor het Energy Dasboard zoveel mogelijk voorkomen.

Het is de energieverbruik van mijn 3 airco's. Daar zit een heat en cool vebruik entity op. Je bedoelt als 1 van deze airco's zijn verbinding verliest kan je deze spikes krijgen?

[TheFes]

Xqlus1ve schreef op maandag 27 maart 2023 @ 19:10:
[...]


Het is de energieverbruik van mijn 3 airco's. Daar zit een heat en cool vebruik entity op. Je bedoelt als 1 van deze airco's zijn verbinding verliest kan je deze spikes krijgen?

Dat bedoel ik inderdaad ja, het totaal gaat dan even omlaag, en dat veroorzaakt dan een spike

[FlashHeaven]

Hey allemaal, ik zou persoonlijk heel graag een Sonoff NSPanel Pro willen inbouwen in de muur net boven een lichtschakelaar. Nu moet je hier blauw en bruin (stroom) naartoe hebben lopen, maar lopen deze hier op dit moment nog niet. Wat is de beste manier om dit te realiseren of zijn er mensen die tips hebben?

[de Peer]

Potentiële overstapper vanaf Domoticz hier.
Echter... ik schrik toch wel een beetje van enkele nadelen van Home Assistent.
Bijvoorbeeld het niet opslaan van de 'latest change state' waardoor na een restart je niet meer kunt zien hoe lang geleden je op een button drukte of hoe lang geleden een motion sensor triggerde. Dit schijnt een hot topic te zijn, al jaren lang.
Wat is hier nu de beste work-around voor? Ik denk dat ik voor elke sensor en button maar zelf actief de timestamp ga opslaan bij indrukken/beweging zodat ik die later weer kan gebruiken voor mijn scripts.

Sowieso merk ik dat binnen HA veel meer met device-triggers gewerkt wordt en minder met time-triggers. In Domoticz maak je doorgaans veel gebruik van het time trigger script die 1 x per minuut uitgevoerd wordt. Ik vond dit fijn werken maar ik zie weinig mensen die binnen HA werken met een time pattern trigger van 1 minuut bijvoorbeeld. is dit af te raden?

Even concreet. Binnen Domoticz gebruik ik Aqara motion sensors. Als deze X minuten geen beweging detecteren wil ik een actie uitvoeren. In Domoticz deed ik dat met een time-trigger. 1 x per minuut wordt er gekeken of de sensor al X minuten in-actief is.
Binnen home assistant zou ik dat dan doen met een time pattern trigger (1 min) en door een door mij opgeslagen time-stamp uit te lezen.
Is dat de beste manier?

De meeste scripts die ik online zie lijken niet robuust en zullen niet goed werken bij een restart van HA of een andere verstoring vermoed ik.

Of is er een andere manier om een actie uit te laten voren bijvoorbeeld 30 minuten nadat een motion sensor getriggerd is, en die ook geactiveerd wordt met een restart/verstoring tussendoor?
Een timer zou kunnen natuurlijk, maar dat schaar ik onder dezelfde oplossing als mijn time-stamp oplossing en lijkt meer een work-around.

[Voor 9% gewijzigd door de Peer op 27-03-2023 20:53]

[Kodess]

de Peer schreef op maandag 27 maart 2023 @ 20:47:
Potentiële overstapper vanaf Domoticz hier.
Echter... ik schrik toch wel een beetje van enkele nadelen van Home Assistent.
Bijvoorbeeld het niet opslaan van de 'latest change state' waardoor na een restart je niet meer kunt zien hoe lang geleden je op een button drukte of hoe lang geleden een motion sensor triggerde. Dit schijnt een hot topic te zijn, al jaren lang.
Wat is hier nu de beste work-around voor? Ik denk dat ik voor elke sensor en button maar zelf actief de timestamp ga opslaan bij indrukken/beweging zodat ik die later weer kan gebruiken voor mijn scripts.

Sowieso merk ik dat binnen HA veel meer met device-triggers gewerkt wordt en minder met time-triggers. In Domoticz maak je doorgaans veel gebruik van het time trigger script die 1 x per minuut uitgevoerd wordt. Ik vond dit fijn werken maar ik zie weinig mensen die binnen HA werken met een time pattern trigger van 1 minuut bijvoorbeeld. is dit af te raden?

Even concreet. Binnen Domoticz gebruik ik Aqara motion sensors. Als deze X minuten geen beweging detecteren wil ik een actie uitvoeren. In Domoticz deed ik dat met een time-trigger. 1 x per minuut wordt er gekeken of de sensor al X minuten in-actief is.
Binnen home assistant zou ik dat dan doen met een time pattern trigger (1 min) en door een door mij opgeslagen time-stamp uit te lezen.
Is dat de beste manier?

De meeste scripts die ik online zie lijken niet robuust en zullen niet goed werken bij een restart van HA of een andere verstoring vermoed ik.

Of is er een andere manier om een actie uit te laten voren bijvoorbeeld 30 minuten nadat een motion sensor getriggerd is, en die ook geactiveerd wordt met een restart/verstoring tussendoor?
Een timer zou kunnen natuurlijk, maar dat schaar ik onder dezelfde oplossing als mijn time-stamp oplossing en lijkt meer een work-around.

Volgens mij houd je wel gewoon je historie waar je in kan kijken

Moet je domoticz zo vaak herstarten dan? Ik vind het een complexe situatie creeeren voor een gebeurtenis die niet vaak gebeurt (de restart)

[de Peer]

Kodess schreef op maandag 27 maart 2023 @ 20:55:
[...]

Volgens mij houd je wel gewoon je historie waar je in kan kijken

Oke, als ik die kan uitlezen en gebruiken in mijn scripts, zou dat een prima oplossing zijn, ga ik even uitzoeken.
update: hmm lijkt niet echt mogelijk om dat uit te lezen om in scripts te gebruiken.

Moet je domoticz zo vaak herstarten dan? Ik vind het een complexe situatie creeeren voor een gebeurtenis die niet vaak gebeurt (de restart)

Nee, dat is juist het punt. Domoticz slaat de state van sensoren/buttons wel gewoon op (zoals het hoort), terwijl er voor HA een work-around nodig is. Hier is veel frustratie over onder HA-gebruikers en was ook 1 van mijn eerste tegenvallers.
Een restart (of een andere verstoring) komt toch wel met enige regelmaat voor verwacht ik, en ik vind een robuust domotica systeem erg belangrijk. Ik ben nogal afhankelijk aangezien bijvoorbeeld warm water bereiding en auto laden er op aangesloten zijn.

Verder niet bedoeld om te bashen hoor , ik wil graag overstappen maar stuit op wat beren op de weg.

[Voor 13% gewijzigd door de Peer op 27-03-2023 21:10]

[breinonline]

de Peer schreef op maandag 27 maart 2023 @ 21:00:
[...]

Oke, als ik die kan uitlezen en gebruiken in mijn scripts, zou dat een prima oplossing zijn, ga ik even uitzoeken.

[...]

Nee, dat is juist het punt. Domoticz slaat de state van sensoren/buttons wel gewoon op (zoals het hoort), terwijl er voor HA een work-around nodig is. Hier is veel frustratie over onder HA-gebruikers en was ook 1 van mijn eerste tegenvallers.
Een restart (of een andere verstoring) komt toch wel met enige regelmaat voor verwacht ik, en ik vind een robuust domotica systeem erg belangrijk. Ik ben nogal afhankelijk aangezien bijvoorbeeld warm water bereiding en auto laden er op aangesloten zijn.

Ik weet het niet, maar als herstart dan weet home assistant prima de staat van mijn sensors en buttons? Waar heb je gelezen dat dit problemen geeft
Het zou kunnen dat je dan die sensoren waar het om draait in de recorder moet aangeven, maar dat is eigenlijk heel logisch.

[de Peer]

breinonline schreef op maandag 27 maart 2023 @ 21:03:
[...]

Ik weet het niet, maar als herstart dan weet home assistant prima de staat van mijn sensors en buttons? Waar heb je gelezen dat dit problemen geeft

Zie de hyperlink in mijn post. Het is één van de grote pijnpunten onder HA-gebruikers.

Het zou kunnen dat je dan die sensoren waar het om draait in de recorder moet aangeven, maar dat is eigenlijk heel logisch.

dat ga ik nog even uitzoeken. Wel wat bijzonder om hiervoor een logbook te moeten uitlezen, gaat niet werken vrees ik.

[Voor 7% gewijzigd door de Peer op 27-03-2023 21:08]

[RobertMe]

de Peer schreef op maandag 27 maart 2023 @ 20:47:
Potentiële overstapper vanaf Domoticz hier.
Echter... ik schrik toch wel een beetje van enkele nadelen van Home Assistent.
Bijvoorbeeld het niet opslaan van de 'latest change state' waardoor na een restart je niet meer kunt zien hoe lang geleden je op een button drukte of hoe lang geleden een motion sensor triggerde. Dit schijnt een hot topic te zijn, al jaren lang.
Wat is hier nu de beste work-around voor? Ik denk dat ik voor elke sensor en button maar zelf actief de timestamp ga opslaan bij indrukken/beweging zodat ik die later weer kan gebruiken voor mijn scripts.

Sowieso merk ik dat binnen HA veel meer met device-triggers gewerkt wordt en minder met time-triggers. In Domoticz maak je doorgaans veel gebruik van het time trigger script die 1 x per minuut uitgevoerd wordt. Ik vond dit fijn werken maar ik zie weinig mensen die binnen HA werken met een time pattern trigger van 1 minuut bijvoorbeeld. is dit af te raden?

Even concreet. Binnen Domoticz gebruik ik Aqara motion sensors. Als deze X minuten geen beweging detecteren wil ik een actie uitvoeren. In Domoticz deed ik dat met een time-trigger. 1 x per minuut wordt er gekeken of de sensor al X minuten in-actief is.
Binnen home assistant zou ik dat dan doen met een time pattern trigger (1 min) en door een door mij opgeslagen time-stamp uit te lezen.
Is dat de beste manier?

De meeste scripts die ik online zie lijken niet robuust en zullen niet goed werken bij een restart van HA of een andere verstoring vermoed ik.

Of is er een andere manier om een actie uit te laten voren bijvoorbeeld 30 minuten nadat een motion sensor getriggerd is, en die ook geactiveerd wordt met een restart/verstoring tussendoor?
Een timer zou kunnen natuurlijk, maar dat schaar ik onder dezelfde oplossing als mijn time-stamp oplossing en lijkt meer een work-around.

Home Assistant werkt event based. Voordeel daarvan is dat HA niks doet als niks gebeurt. Wat jij zegt met elke minuut iets controleren verbrand je lekker veel CPU cycli voor nop
Wat je bij HA doet in jouw voorbeeld met "bewegingsmelder is X minuten uit" is gebruik maken van "for" op de trigger.

YAML:

trigger:
  platform: state
  entity_id: binary_sensor.bewegingsmelder
  to: 'off'
  for: '00:05:00'

HA fixt dan zelf dat de trigger pas na 5 minuten vuurt. En ja, dit gaat fout als je HA in die 5 minuten start, maar waarom zou je dat doen?

Edit:

de Peer schreef op maandag 27 maart 2023 @ 21:05:
[...]

Zie de hyperlink in mijn post. Het is één van de grote pijnpunten onder HA-gebruikers.

Is het een van de grote pijnpunten onder HA gebruikers of is het een van de grote pijnpunten onder (mogelijke) overstappers? In alle jaren dat ik HA gebruik (jaar of 5) heb ik letterlijk nog nooit deze functionaliteit gemist.

[Voor 7% gewijzigd door RobertMe op 27-03-2023 21:19]

[de Peer]

RobertMe schreef op maandag 27 maart 2023 @ 21:17:
[...]

Home Assistant werkt event based. Voordeel daarvan is dat HA niks doet als niks gebeurt. Wat jij zegt met elke minuut iets controleren verbrand je lekker veel CPU cycli voor nop

Precies. Volgens mij werkt Domoticz net zo, alleen is het daar gangbaar om zowel device triggers te gebruiken als time triggers (1 x per minuut). Dat vond ik altijd fijn werken.
Bij Domoticz zorgde dit in ieder geval niet voor een hoge CPU verbruik.
Ik vermoed dat dat bij HA ook wel mee zou moeten vallen, aangezien in 99% van de gevallen niet aan de conditions voldaan wordt waardoor en dus geen actie uitgevoerd wordt.

Je hebt natuurlijk wel gelijk dat werken via device-triggers netter/efficiënter is.

Wat je bij HA doet in jouw voorbeeld met "bewegingsmelder is X minuten uit" is gebruik maken van "for" op de trigger.

HA fixt dan zelf dat de trigger pas na 5 minuten vuurt. En ja, dit gaat fout als je HA in die 5 minuten start, maar waarom zou je dat doen?

Exact. Dit is precies hoe ik nooit mijn automations zou willen opzetten. Je noemt nu 5 minuten, maar stel dat het om 120 minuten gaat, dan wordt de kans op een verstoring al wat groter.

Ik vind het persoonlijk niet acceptabel dat een restart, een korte stroom- of internet/netwerk dip of iets dergelijks mijn domoticasysteem belemmert in het aansturen van mijn apparaten. Dan word ik straks dus een keer wakker zonder dat er warm water bereid is .

Ik zou natuurlijk ook kunnen accepteren dat ik na een herstart handmatig alles na moet lopen om te kijken of er nergens iets aan is blijven staan, maar uiteraard liever niet.

[Voor 5% gewijzigd door de Peer op 27-03-2023 21:33]

[de Peer]

RobertMe schreef op maandag 27 maart 2023 @ 21:17:
[...]

Is het een van de grote pijnpunten onder HA gebruikers of is het een van de grote pijnpunten onder (mogelijke) overstappers? In alle jaren dat ik HA gebruik (jaar of 5) heb ik letterlijk nog nooit deze functionaliteit gemist.

Nou in ieder geval onder gebruikers van het HA forum. Ik denk dat dat meer gebruikers dan overstappers zijn.

Uiteraard als je eenmaal HA gebruikt ga je ook anders de boel opzetten waardoor je de problemen ook niet of minder zult ervaren.

In mijn geval bij een overstap van Domoticz word ik gedwongen om een bepaalde manier van werken los te laten omdat HA dit niet ondersteunt. Dus komt wel goed, maar even wennen.

[Voor 25% gewijzigd door de Peer op 27-03-2023 21:34]

[TheFes]

breinonline schreef op maandag 27 maart 2023 @ 21:03:
[...]

Ik weet het niet, maar als herstart dan weet home assistant prima de staat van mijn sensors en buttons? Waar heb je gelezen dat dit problemen geeft
Het zou kunnen dat je dan die sensoren waar het om draait in de recorder moet aangeven, maar dat is eigenlijk heel logisch.

Zijn probleem is niet dat de state onbekend is, maar dat het onbekend is hoe lang de entity al in deze state staat. Dus bijvoorbeeld hoe lang een motion sensor geen beweging detecteert.

Dat kun je wel uit het last_changed object halen, maar dat reset dus bij een reboot van HA.

@de Peer je zou met timers kunnen werken, die overleven ook een reboot.
Je zou ook voor de entiteiten waarvoor je het nodig hebt de lm timestamp van de laatste wijziging op kunnen slaan in een attribute van een template sensor. Ik heb daar ooit iets voor geschreven:
https://github.com/TheFes...trigger/last_changed.yaml
De eerste kan voor elke entity gebruikt worden en slaat alleen de timestamp op, de tweede werkt voor alle entities die on of off kunnen zijn en slaat de laatste wijziging naar die state op.

Nog steeds zou ik daarmee geen time pattern triggers gebruiken, maar de timestamp vergelijken met de huidige tijd in een template trigger.

[de Peer]

TheFes schreef op maandag 27 maart 2023 @ 21:34:
[...]

@de Peer je zou met timers kunnen werken, die overleven ook een reboot.
Je zou ook voor de entiteiten waarvoor je het nodig hebt de lm timestamp van de laatste wijziging op kunnen slaan in een attribute van een template sensor. Ik heb daar ooit iets voor geschreven:
https://github.com/TheFes...trigger/last_changed.yaml
De eerste kan voor elke entity gebruikt worden en slaat alleen de timestamp op, de tweede werkt voor alle entities die on of off kunnen zijn en slaat de laatste wijziging naar die state op.

Top, dank voor de bevestiging. Gebruik van Timer en timestamp opslaan zijn inderdaad de 2 work-arounds waar ik nu aan zit te denken, in ieder geval voor de devices die ik kritisch acht.

Nog steeds zou ik daarmee geen time pattern triggers gebruiken, maar de timestamp vergelijken met de huidige tijd in een template trigger.

Ja goed idee. Dat is nog even een andere manier van denken dan ik vanuit Domoticz gewend ben, maar klinkt als een beter alternatief! thanks.

[Faceless]

de Peer schreef op maandag 27 maart 2023 @ 21:26:
[...]
Ik vind het persoonlijk niet acceptabel dat een restart, een korte stroom- of internet/netwerk dip of iets dergelijks mijn domoticasysteem belemmert in het aansturen van mijn apparaten. Dan word ik straks dus een keer wakker zonder dat er warm water bereid is .

Ik zou natuurlijk ook kunnen accepteren dat ik na een herstart handmatig alles na moet lopen om te kijken of er nergens iets aan is blijven staan, maar uiteraard liever niet.

Gewoon iets creatiever denken. Als je 's ochtends warm water wilt, dan start je je boiler om 6u 's ochtends dus, in plaats dat je dag er voor om 10u 's ochtends hebt gezegd 'ga gedurende 20u slapen nu'. Alhoewel dat ook prima kan in HA

Je kunt ook gewoon plannetjes maken die zeggen over 5 minuten het licht uit. Of 20 minuten voor zonsondergang de licht aan. Of licht uit 5 minuten na de laatste beweging gezien is van de bewegingssensor.

Of schema's aanmaken waar je acties aan koppelt:
https://www.home-assistant.io/integrations/schedule/

Tot slot kun je ook a la crontab iets iedere paar minuten laten uitvoeren, desnoods iedere minuut:
https://www.home-assistan...ger/#time-pattern-trigger

Denk dat je met concretere voorbeelden moet komen.

[RobertMe]

de Peer schreef op maandag 27 maart 2023 @ 21:26:
[...]

Precies. Volgens mij werkt Domoticz net zo, alleen is het daar gangbaar om zowel device triggers te gebruiken als time triggers (1 x per minuut). Dat vond ik altijd fijn werken.
Bij Domoticz zorgde dit in ieder geval niet voor een hoge CPU verbruik.
Ik vermoed dat dat bij HA ook wel mee zou moeten vallen, aangezien in 99% van de gevallen niet aan de conditions voldaan wordt waardoor en dus geen actie uitgevoerd wordt.

Maar je controleert wel elke minuut onzinnig de condities

[...]

Exact. Dit is precies hoe ik nooit mijn automations zou willen opzetten. Je noemt nu 5 minuten, maar stel dat het om 120 minuten gaat, dan wordt de kans op een verstoring al wat groter.

Je kunt het tijdstip ook in een timer, of input_datetime zetten, die overleven een reboot wel.

Ik vind het persoonlijk niet acceptabel dat een restart, een korte stroom- of internet/netwerk dip of iets dergelijks mijn domoticasysteem belemmert in het aansturen van mijn apparaten. Dan word ik straks dus een keer wakker zonder dat er warm water bereid is .

Maar dat warm water wil je waarschijnlijk op een tijdstip bereiden dat je van tevoren weet, dus kun je af met een time trigger die werkt op basis van een sensor (met state_class datetime) of een input_datetime. Ik heb al jaren dat 3 minuten voor de wekker op de telefoon gaat de verlichting aan gaat, nog nooit mis gegaan behalve die ene keer dat ik met mijn slaapkop de wekker eerder uitschakelde en vervolgens in slaap viel. Vanuit de HA app wordt de wekker doorgegeven, en met een template based sensor haal ik daar 3 minuten vanaf. Deze sensor dient vervolgens als "input" voor een time trigger en klaar. Daarvoor hoef ik niet elke minuut te controleren "of nu de wekker moet gaan". En of dat nu via een time_pattern of template trigger is zoals @TheFes suggereert, beide van die oplossingen zijn "dom" in dat ze elke minuut onzinnig een conditie doorlopen. Daar waar een time trigger op OS niveau kan zeggen "roep deze code over X seconden/minuten/uren/dagen aan".

[de Peer]

Faceless schreef op maandag 27 maart 2023 @ 21:46:
[...]


Gewoon iets creatiever denken. Als je 's ochtends warm water wilt, dan start je je boiler om 6u 's ochtends dus, in plaats dat je dag er voor om 10u 's ochtends hebt gezegd 'ga gedurende 20u slapen nu'. Alhoewel dat ook prima kan in HA

Je kunt ook gewoon plannetjes maken die zeggen over 5 minuten het licht uit. Of 20 minuten voor zonsondergang de licht aan. Of licht uit 5 minuten na de laatste beweging gezien is van de bewegingssensor.

Ja dat is allemaal waar. Geen goed voorbeeld.
Momenteel verwarm ik mijn warm water op basis van dynamische tarieven, dus telkens een ander tijdstip ivm de fluctuerende prijzen, dus ik gebruik al de nodige regels om er voor te zorgen dat we goedkoop verwarmen maar wel met de garantie dat het op tijd klaar is.

Denk dat je met concretere voorbeelden moet komen.

Ik heb (in Domoticz) ook een functie die bepaalt of we (langdurig) van huis zijn. Als de beweging sensoren bijvoorbeeld meer dan 16 uur niemand gezien hebben zijn we vermoedelijk de volgende ochtend niet thuis en gaan de gordijnen en rolluiken automatisch open. Zonder deze regel zou alles dicht blijven.

En daar is natuurlijk ook wel weer iets op te verzinnen, maar het ging me er vooral even om dat ik mijn huidige manier van werken niet 1 op 1 over kan zetten naar Domoticz, omdat dus de 'last state' tijd niet opgeslagen blijft na een HA restart.
Op te lossen met o.a. een timer blijkt nu dus.

[de Peer]

RobertMe schreef op maandag 27 maart 2023 @ 21:47:
[...]

Maar je controleert wel elke minuut onzinnig de condities

Ja klopt. Binnen Domoticz is dit zelfs standard practice en wordt het aangemoedigd, maar ben het met je eens dat dit eigenlijk slordig is. Dus goed moment om daar vanaf te stappen.

Maar dat warm water wil je waarschijnlijk op een tijdstip bereiden dat je van tevoren weet

Nee (ik stuur op dynamische energietarieven) anders zou het erg simpel zijn inderdaad. Sterker nog dan zou ik het zelfs bewust buiten mijn domotica houden, want hoe simpeler hoe betrouwbaarder.
Bedankt voor het meedenken in ieder geval

Deze sensor dient vervolgens als "input" voor een time trigger en klaar. Daarvoor hoef ik niet elke minuut te controleren "of nu de wekker moet gaan". En of dat nu via een time_pattern of template trigger is zoals @TheFes suggereert, beide van die oplossingen zijn "dom" in dat ze elke minuut onzinnig een conditie doorlopen. Daar waar een time trigger op OS niveau kan zeggen "roep deze code over X seconden/minuten/uren/dagen aan".

Top, ga ik eens over nadenken. bedankt!
Maar als ik het goed begrijp ontkom je niet helemaal aan die 1 x per minuut als je van tevoren niet weet wanneer er aan een voorwaarde voldaan gaat worden. Tenzij je dus toch time pattern als trigger gebruikt en die op bijvoorbeeld elke 10-20 minuten zet. Al vraag ik me af of 1 x per minuut nu echt belastend is voor het systeem, denk dat het vrijwel verwaarloosbaar is.

[Voor 13% gewijzigd door de Peer op 27-03-2023 22:14]

[Faceless]

de Peer schreef op maandag 27 maart 2023 @ 21:57:
[...]

Momenteel verwarm ik mijn warm water op basis van dynamische tarieven, dus telkens een ander tijdstip ivm de fluctuerende prijzen, dus ik gebruik al de nodige regels om er voor te zorgen dat we goedkoop verwarmen maar wel met de garantie dat het op tijd klaar is.

[...]

In dat topic hier op tweakers zijn genoeg voorbeelden te vinden om op goedkope stroom momenten acties te starten. Hoef je niet opnieuw uit te vinden.

de Peer schreef op maandag 27 maart 2023 @ 21:57:

Ik heb (in Domoticz) ook een functie die bepaalt of we (langdurig) van huis zijn. Als de beweging sensoren bijvoorbeeld meer dan 16 uur niemand gezien hebben zijn we vermoedelijk de volgende ochtend niet thuis en gaan de gordijnen en rolluiken automatisch open. Zonder deze regel zou alles dicht blijven.

Leuk idee. Kun je wellicht vervangen door op moment van zonsopgang te kijken of er iemand thuis is (werkt bij mij prima dmv de HA applicatie op mijn telefoon die de locatie doorgeeft aan HA). Daarmee trigger ik ook dat m'n lichten uitgaan en verwarming uit op het moment dat ik de zone rond mijn huis uitga en v.v.

de Peer schreef op maandag 27 maart 2023 @ 21:57:

En daar is natuurlijk ook wel weer iets op te verzinnen, maar het ging me er vooral even om dat ik mijn huidige manier van werken niet 1 op 1 over kan zetten naar Domoticz, omdat dus de 'last state' tijd niet opgeslagen blijft na een HA restart.
Op te lossen met o.a. een timer blijkt nu dus.

Ik ben pas gestart met HA en merk dat ik de flow's veel intuïtiever en logischer kan maken dan voorheen in mijn Homey. Het geeft me veel meer opties dan in Homey.

[Sp33dFr34k]

Nooit gedacht dat er iemand teleurgesteld is na de overstap van Domoticz naar HA, ik vond het persoonlijk een behoorlijke verademing..

[de Peer]

Sp33dFr34k schreef op maandag 27 maart 2023 @ 22:39:
Nooit gedacht dat er iemand teleurgesteld is na de overstap van Domoticz naar HA, ik vond het persoonlijk een behoorlijke verademing..

Nou niet teleurgesteld hoor, maar ik ben wel kritisch omdat ik een zeer uitgebreid domotica systeem al 6 jaar heb draaien en ik ga er ongeveer 1 jaar voor uit trekken om dat langzaam om/over te zetten. En de moed zakte me een beetje in de schoenen toen bleek dat een simpele Aqara sensor al direct een timer of timestamp nodig had om hem op een robuuste (HA-herstart proof) manier te kunnen gebruiken.

Het is vooral wennen en hier en daar wat zaken los laten en van de gelegenheid gebruik maken om ook juist verbeteringen door te voeren.

Mijn indruk is dat HA met name voor beginners makkelijker en toegankelijker is, maar dat HA juist voor complexere zaken wat onhandiger in gebruik is dan Domoticz. Scripts maken in Domoticz in LUA werkte erg fijn.

Over het algemeen is mijn indruk best positief tot nu toe. Maar je merkt ook wel dat HA nog volop in ontwikkeling is en sommige basic zaken nog niet op orde heeft, zoals dus onder andere door mij aangehaald dat ''laste change" states domweg verloren gaan bij een herstart van HA. Dat kan écht niet!
Maar het zou me niets verbazen als dat volgend jaar opgelost wordt.

Automations via de UI is iets wat ik nooit ga gebruiken. Dan zit ik straks met 500 automations. Zeer onoverzichtelijk. Dan maar alles in YAML files. Alleen dat heeft weer als nadeel dat het nogal wollig is en veel ruimte inneemt. 20 regels waar je in Domoticz maar 3 regels nodig hebt bijvoorbeeld. Maargoed daar valt wel mee te leven.

Wat ik ook erg jammer vind is de 'Raw configuration editor' voor dashboard aanpassingen. Dat werkt voor geen meter, en telkens spaties tellen etc..
Jammer dat je daar niet gewoon direct VScode voor kunt gebruiken.
En ja tuurlijk kun je het copy-pasten, editen in een externe editor, en later weer terug plakken. Maar dat zijn van die dingen die echt nog beter mogen.

Domoticz heeft dan weer zijn eigen gebreken en begint achter te lopen, en ik ben bang dat dat door gaat zetten de komende jaren in de tijd dat HA juist (nog) volwassener wordt. Dus ik heb er wel vertrouwen in dat HA me (uiteindelijk) beter gaat bevallen. Maar het is best een stap vanaf een systeem dat in principe ook prima werkt nu. Voelt een beetje zonde om dat achter me te laten.

[Voor 24% gewijzigd door de Peer op 27-03-2023 22:58]

[Faceless]

de Peer schreef op maandag 27 maart 2023 @ 22:47:
[...]
Voelt een beetje zonde om dat achter me te laten.

Doe dat niet dan. HA is dan niet voor jou.

[Vaevictis_]

de Peer schreef op maandag 27 maart 2023 @ 22:47:
[...]


Nou niet teleurgesteld hoor, maar ik ben wel kritisch omdat ik een zeer uitgebreid domotica systeem al 6 jaar heb draaien en ik ga er ongeveer 1 jaar voor uit trekken om dat langzaam om/over te zetten. En de moed zakte me een beetje in de schoenen toen bleek dat een simpele Aqara sensor al direct een timer of timestamp nodig had om hem op een robuuste (HA-herstart proof) manier te kunnen gebruiken.

Het is vooral wennen en hier en daar wat zaken los laten en van de gelegenheid gebruik maken om ook juist verbeteringen door te voeren.

Mijn indruk is dat HA met name voor beginners makkelijker en toegankelijker is, maar dat HA juist voor complexere zaken wat onhandiger in gebruik is dan Domoticz. Scripts maken in Domoticz in LUA werkte erg fijn.

Over het algemeen is mijn indruk best positief tot nu toe. Maar je merkt ook wel dat HA nog volop in ontwikkeling is en sommige basic zaken nog niet op orde heeft, zoals dus onder andere door mij aangehaald dat ''laste change" states domweg verloren gaan bij een herstart van HA. Dat kan écht niet!
Maar het zou me niets verbazen als dat volgend jaar opgelost wordt.

Automations via de UI is iets wat ik nooit ga gebruiken. Dan zit ik straks met 500 automations. Zeer onoverzichtelijk. Dan maar alles in YAML files. Alleen dat heeft weer als nadeel dat het nogal wollig is en veel ruimte inneemt. 20 regels waar je in Domoticz maar 3 regels nodig hebt bijvoorbeeld. Maargoed daar valt wel mee te leven.

Wat ik ook erg jammer vind is de 'Raw configuration editor' voor dashboard aanpassingen. Dat werkt voor geen meter, en telkens spaties tellen etc..
Jammer dat je daar niet gewoon direct VScode voor kunt gebruiken.
En ja tuurlijk kun je het copy-pasten, editen in een externe editor, en later weer terug plakken. Maar dat zijn van die dingen die echt nog beter mogen.

Domoticz heeft dan weer zijn eigen gebreken en begint achter te lopen, en ik ben bang dat dat door gaat zetten de komende jaren in de tijd dat HA juist (nog) volwassener wordt. Dus ik heb er wel vertrouwen in dat HA me (uiteindelijk) beter gaat bevallen. Maar het is best een stap vanaf een systeem dat in principe ook prima werkt nu. Voelt een beetje zonde om dat achter me te laten.

Zelf in 2015 overstapt vanaf Domoticz naar HA, dat was toen wel erg wennen en het was allemaal nog in YAML configureren en veel werkte ook gewoon nog niet. En voor alle wijziging heel HA herstarten dat was eigenlijk niet te doen. De vooruitgang is echt fenomenaal dit in tegenstelling bij Domoticz. Zou dan ook lekker nog wachten want het is best een stijle leercurve en veel werk als je alles wil omzetten en veel waarde hecht aan historische gegevens (die ben je kwijt). Het grootste voordeel van HA is de community er zijn altijd wel anderen die iets doen wat jij ook wilt. Dat vond ik bij Domoticz niet, was veel met LUA, Bash en AWK scripts aan het schrijven om het werkend te krijgen.

[tlpeter]

de Peer schreef op maandag 27 maart 2023 @ 20:47:
Potentiële overstapper vanaf Domoticz hier.
Echter... ik schrik toch wel een beetje van enkele nadelen van Home Assistent.
Bijvoorbeeld het niet opslaan van de 'latest change state' waardoor na een restart je niet meer kunt zien hoe lang geleden je op een button drukte of hoe lang geleden een motion sensor triggerde. Dit schijnt een hot topic te zijn, al jaren lang.
Wat is hier nu de beste work-around voor? Ik denk dat ik voor elke sensor en button maar zelf actief de timestamp ga opslaan bij indrukken/beweging zodat ik die later weer kan gebruiken voor mijn scripts.

Sowieso merk ik dat binnen HA veel meer met device-triggers gewerkt wordt en minder met time-triggers. In Domoticz maak je doorgaans veel gebruik van het time trigger script die 1 x per minuut uitgevoerd wordt. Ik vond dit fijn werken maar ik zie weinig mensen die binnen HA werken met een time pattern trigger van 1 minuut bijvoorbeeld. is dit af te raden?

Even concreet. Binnen Domoticz gebruik ik Aqara motion sensors. Als deze X minuten geen beweging detecteren wil ik een actie uitvoeren. In Domoticz deed ik dat met een time-trigger. 1 x per minuut wordt er gekeken of de sensor al X minuten in-actief is.
Binnen home assistant zou ik dat dan doen met een time pattern trigger (1 min) en door een door mij opgeslagen time-stamp uit te lezen.
Is dat de beste manier?

De meeste scripts die ik online zie lijken niet robuust en zullen niet goed werken bij een restart van HA of een andere verstoring vermoed ik.

Of is er een andere manier om een actie uit te laten voren bijvoorbeeld 30 minuten nadat een motion sensor getriggerd is, en die ook geactiveerd wordt met een restart/verstoring tussendoor?
Een timer zou kunnen natuurlijk, maar dat schaar ik onder dezelfde oplossing als mijn time-stamp oplossing en lijkt meer een work-around.

Ik kom van Domoticz en kan je zeggen dat het even omschakelen is, maar je daarna nooit meer terug wilt.
Stabiele versies met gezonde regelmaat. Bij Domoticz had ik het idee dat men een release uitbracht wanneer de maan rood was.
Ik was bang om over te stappen maar die angst was ongegrond.

[de Peer]

Faceless schreef op dinsdag 28 maart 2023 @ 00:04:
[...]


Doe dat niet dan. HA is dan niet voor jou.

Dat bepaal ik uiteraard zelf wel . Zoals gezegd denk ik dat Domoticz begint te verouderen en dat er een moment komt dat ik sowieso over zal moeten gaan stappen. Dan beter nu ipv over 5 jaar. En bij zo'n overstap hoort nu eenmaal wat ongemak en hier en daar aanpassing.

Ik heb Domoticz 6 jaar gedraaid op een RPI 3B met 1 sd-kaart (nooit vervangen) en ik heb nu een intel NUC met SSD gekocht om HA ernaast te gaan draaien. En dan langzaam overstappen door 1 voor 1 devices over zetten. Te beginnen met de minst kritische om het scripten alvast onder de knie te hebben tegen de tijd dat ik met de kritische zaken (warmtepompen, auto/fiets laden, aquariumautomatisering etc.) bezig ga.

[Voor 18% gewijzigd door de Peer op 28-03-2023 07:43]

[de Peer]

Vaevictis_ schreef op dinsdag 28 maart 2023 @ 06:13:
[...]


Het grootste voordeel van HA is de community er zijn altijd wel anderen die iets doen wat jij ook wilt. Dat vond ik bij Domoticz niet, was veel met LUA, Bash en AWK scripts aan het schrijven om het werkend te krijgen.

Ja klopt. Via Domoticz stuur ik mijn grasmaaier (Worx Landroid) en stofzuiger (Roborock s5) ook aan maar via work-arounds, daar heb ik zelf flink wat moeite voor moeten doen. Het werkt, maar blijft een beetje gammel en traag vanwege de work-around die ik gebruik. Terwijl HA dit bijna out-of-the box ondersteunt. Dat geeft me niet veel vertrouwen in de toekomst van Domoticz.

[Vaevictis_]

de Peer schreef op dinsdag 28 maart 2023 @ 07:47:
[...]


Ja klopt. Via Domoticz stuur ik mijn grasmaaier (Worx Landroid) en stofzuiger (Roborock s5) ook aan maar via work-arounds, daar heb ik zelf flink wat moeite voor moeten doen. Het werkt, maar blijft een beetje gammel en traag vanwege de work-around die ik gebruik. Terwijl HA dit bijna out-of-the box ondersteunt. Dat geeft me niet veel vertrouwen in de toekomst van Domoticz.

De Roborock S5 heb ik ook, en de miio integratie (cloud) werkt goed. Soms opnieuw aanmelden maar is een paar keer per jaar. Heb zo'n afbeelding van de Roborock met gegevens transparant erover.

[TheFes]

de Peer schreef op maandag 27 maart 2023 @ 22:47:
[...]


Nou niet teleurgesteld hoor, maar ik ben wel kritisch omdat ik een zeer uitgebreid domotica systeem al 6 jaar heb draaien en ik ga er ongeveer 1 jaar voor uit trekken om dat langzaam om/over te zetten. En de moed zakte me een beetje in de schoenen toen bleek dat een simpele Aqara sensor al direct een timer of timestamp nodig had om hem op een robuuste (HA-herstart proof) manier te kunnen gebruiken.

Het is vooral wennen en hier en daar wat zaken los laten en van de gelegenheid gebruik maken om ook juist verbeteringen door te voeren.

Mijn indruk is dat HA met name voor beginners makkelijker en toegankelijker is, maar dat HA juist voor complexere zaken wat onhandiger in gebruik is dan Domoticz. Scripts maken in Domoticz in LUA werkte erg fijn.

Over het algemeen is mijn indruk best positief tot nu toe. Maar je merkt ook wel dat HA nog volop in ontwikkeling is en sommige basic zaken nog niet op orde heeft, zoals dus onder andere door mij aangehaald dat ''laste change" states domweg verloren gaan bij een herstart van HA. Dat kan écht niet!
Maar het zou me niets verbazen als dat volgend jaar opgelost wordt.

Automations via de UI is iets wat ik nooit ga gebruiken. Dan zit ik straks met 500 automations. Zeer onoverzichtelijk. Dan maar alles in YAML files. Alleen dat heeft weer als nadeel dat het nogal wollig is en veel ruimte inneemt. 20 regels waar je in Domoticz maar 3 regels nodig hebt bijvoorbeeld. Maargoed daar valt wel mee te leven.

Wat ik ook erg jammer vind is de 'Raw configuration editor' voor dashboard aanpassingen. Dat werkt voor geen meter, en telkens spaties tellen etc..
Jammer dat je daar niet gewoon direct VScode voor kunt gebruiken.
En ja tuurlijk kun je het copy-pasten, editen in een externe editor, en later weer terug plakken. Maar dat zijn van die dingen die echt nog beter mogen.

Domoticz heeft dan weer zijn eigen gebreken en begint achter te lopen, en ik ben bang dat dat door gaat zetten de komende jaren in de tijd dat HA juist (nog) volwassener wordt. Dus ik heb er wel vertrouwen in dat HA me (uiteindelijk) beter gaat bevallen. Maar het is best een stap vanaf een systeem dat in principe ook prima werkt nu. Voelt een beetje zonde om dat achter me te laten.

Als je graag in YAML wil werken, werkt het het beste als je de keuze maakt om YAML only te gaan. Dan kun je ook gewoon VSCode gebruiken voor je Dashboard.
Wat je eventueel kunt doen is een test Dashboard maken in storage mode, zodat je wel met de GUI wat in elkaar kunt klikken als het nodig is, en dat kunt copy pasten naar je YAML dashbard.

Verder is last_changed gewoon een gemaakt om de laatste state change van een entity op te slaan, en na een reboot is er een state change van unavailable/unknown naar een correcte state. Die wordt opgekpikt, en daarvan wordt de timestamp gelogd.

Er zijn inderdaad mensen die daarover klagen, maar het is echt niet zo dat het overgrote deel van de HA gebruikers hier last van heeft, het is een vocale minderheid, die je vooral tijdens de Month of the WTH weer even hoort. Verder lopen mensen er af en toe even tegenaan, maar dan vinden ze voor dat ene geval wel een work around. Er zijn relatief weinig gebruikers die hier structureel tegenaan lopen.

Waarom zou je met Automations via de GUI meer automations nodig hebben dan via YAML eigenlijk? Er zijn een aantal zaken die je niet in de GUI kunt, maar daarvoor kun je heel even omswitchen naar de YAML mode.
Er zijn wel andere voordelen van YAML only, bijvoorbeeld dat je comments kunt gebruiken, en dat je ze gestructureerd in folders op kunt slaan. Maar ik zie geen reden waarom het aantal automations anders zou moeten zijn.

[de Peer]

TheFes schreef op dinsdag 28 maart 2023 @ 08:57:
[...]


Als je graag in YAML wil werken, werkt het het beste als je de keuze maakt om YAML only te gaan. Dan kun je ook gewoon VSCode gebruiken voor je Dashboard.
Wat je eventueel kunt doen is een test Dashboard maken in storage mode, zodat je wel met de GUI wat in elkaar kunt klikken als het nodig is, en dat kunt copy pasten naar je YAML dashbard.

Goede tip, ga ik eens naar kijken.

Verder is last_changed gewoon een gemaakt om de laatste state change van een entity op te slaan, en na een reboot is er een state change van unavailable/unknown naar een correcte state. Die wordt opgekpikt, en daarvan wordt de timestamp gelogd.

Er zijn inderdaad mensen die daarover klagen, maar het is echt niet zo dat het overgrote deel van de HA gebruikers hier last van heeft, het is een vocale minderheid, die je vooral tijdens de Month of the WTH weer even hoort. Verder lopen mensen er af en toe even tegenaan, maar dan vinden ze voor dat ene geval wel een work around. Er zijn relatief weinig gebruikers die hier structureel tegenaan lopen.

Ja met een timer of timestamp is het wel op te lossen. Het is vooral even wennen omdat in Domoticz op grote schaal gebruik wordt gemaakt van de 'last changed'.

Waarom zou je met Automations via de GUI meer automations nodig hebben dan via YAML eigenlijk? Er zijn een aantal zaken die je niet in de GUI kunt, maar daarvoor kun je heel even omswitchen naar de YAML mode.
Er zijn wel andere voordelen van YAML only, bijvoorbeeld dat je comments kunt gebruiken, en dat je ze gestructureerd in folders op kunt slaan. Maar ik zie geen reden waarom het aantal automations anders zou moeten zijn.

Inderdaad het aantal automations verandert niet, maar in YAML files is het overzichtelijker en werkt copy-pasten fijn als je zaken aan het uitbreiden bent.

[Panzer_V]

@de Peer , ikzelf ben eind vorig jaar overgestapt van Domoticz naar HA. De leercurve is vrij stijl en het duurde bij mij ook even voordat ik doorhad hoe HA precies in elkaar zit (vergeet niet aan de 'statistics' te denken. Hierin worden alle lange termijn gegevens opgeslagen).

Qua automatisering zou ik niets liever meer willen dan HA. Het werken via de GUI is zoveel prettiger dan het programmeren in Domoticz. En als je eens moet terugvallen op YAML dan is dat niet eens zo moeilijk.

Je merkt duidelijk dat HA flinkt doorontwikkeld is waar Domoticz een beetje stil lijkt te staan....

[-Casper]

de Peer schreef op dinsdag 28 maart 2023 @ 09:17:
[...]

Goede tip, ga ik eens naar kijken.

[...]

Ja met een timer of timestamp is het wel op te lossen. Het is vooral even wennen omdat in Domoticz op grote schaal gebruik wordt gemaakt van de 'last changed'.

[...]

Inderdaad het aantal automations verandert niet, maar in YAML files is het overzichtelijker en werkt copy-pasten fijn als je zaken aan het uitbreiden bent.

Je krijgt al een hoop pointers dus denk dat je dat al een aardig eind op weg helpt. Je plan om eerst te starten met niet-kritische usecases is slim. Let daar ook even op wanneer je soort van stabiel komt (dus zelf een beetje door krijgt hoe t werkt en niet meer elke dag allerlei dingen loopt te versleutelen). Ga dan eens opletten hoevaak je HA moet herstarten of iets dergelijks wat dergelijke impact zou hebben dat je je last_changed variabele nodig zou hebben.

In mijn ervaring herstart HA zo weinig dat ik de moeite niet zou nemen om hier iets voor in te bouwen. Updates zijn de enige reden eigenlijk dat mijn HA herstart, verder zou ik het niet weten.

Let ook op dat je in de developer tools de mogelijkheid hebt om allerlei integraties te herladen (zonder dat je dus geheel HA opnieuw moet starten).

[Slinkos]

Pazo schreef op vrijdag 24 maart 2023 @ 16:12:
[...]


ja daar ben ik lang mee aan het klooien geweest. De standaard sensoren zijn de huidige opwekking, maar ik wilde, net zoals in de app / in Enlighten, de dagopbrengsten zien. Met de Riemann som en een Nutsmeter kan je dit bereiken. Even de hele post lezen, want ik had later een edit gemaakt. De Riemann som reset niet maar telt door, en daarom moet je ook nog een nutsmeter aanmaken (die doet de functie steeds resetten) voor elke micro (en die geef je weer op je legplan). Succes!

Is helemaal gelukt hoor :-) ik vind het een fijne toevoeging, dat ik er zelf niet op gekomen ben :-) thanks!

[Ora et Labora]

IKKE86 schreef op maandag 27 maart 2023 @ 16:16:
[...]


[...]


Is het jullie (of andereren) nog gelukt om zelf een sensor te maken met de kosten van het stroomverbruik van vandaag?

Zelf kom ik niet verder dan dit, maar dit heeft natuurlijk weinig zin als je tarief elk uur wijzigt:

YAML:

{{ (states('sensor.zonneplan_p1_electricity_consumption_today')|float * states('sensor.zonneplan_current_electricity_tariff')|float)|round(2) }} 

https://gathering.tweakers.net/forum/view_message/74001178

[Sicco92]

Ora et Labora schreef op dinsdag 28 maart 2023 @ 10:53:
[...]

https://gathering.tweakers.net/forum/view_message/74001178

Dat werkt dus niet als je elk uur een ander tarief hebt. Je tarief staat niet vast, dus kan je niet simpel tarief * optellend dagverbruik doen.
Eigenlijk zou je dus een cumulatieve sensor moeten hebben die elk uur verhoogd wordt met het huidige uurtarief * huidige verbruik in dat uur. Is vast iets voor te maken, maar ik ben het nog niet tegengekomen.

[Fishione]

Hallo,


Ik heb thuis een domotica systeem welk via een REST API kan gestuurd worden via bv een onderstaand commando.

http://192.168.1.250:1001...MemberID/MemberID/Functie

Zelf heb ik geen ervaring met configuratie in yaml

Onderdstaan heb ik al gevonden maar de server vraagt ook een login/username welke ik daar ergens moet tussenplaatsen.
Ook de configuratie aan een knop linken lukt met niet.

# Example configuration.yaml entry
rest_command:
example_request:
url: "http://example.com/"

Moesten er mensen zijn om me wat op weg te helpen kan ik het via trail en error wel in orde krijgen

[DjTjon]

Fishione schreef op dinsdag 28 maart 2023 @ 11:11:
Hallo,


Ik heb thuis een domotica systeem welk via een REST API kan gestuurd worden via bv een onderstaand commando.

http://192.168.1.250:1001...MemberID/MemberID/Functie

Zelf heb ik geen ervaring met configuratie in yaml

Onderdstaan heb ik al gevonden maar de server vraagt ook een login/username welke ik daar ergens moet tussenplaatsen.
Ook de configuratie aan een knop linken lukt met niet.


[...]


Moesten er mensen zijn om me wat op weg te helpen kan ik het via trail en error wel in orde krijgen

Ik gebruik het volgende voor de API van mijn zonnepanelen, deze maakt ook gebruik van Basic Authenticatie. Mogelijk kan je hier op verder borduren

YAML:

rest:
  - authentication: basic
    username: !secret Autarco_username
    password: !secret Autarco_password
    scan_interval: 120
    resource: https://my.autarco.com/api/power
    timeout: 30
    sensor:
      - name: "pv_now"
        value_template: "{{ value_json.stats.kpis.pv_now/1000 }}"
        unit_of_measurement: "kWh"
        device_class: energy

Edit: Kleine toevoeging, je kan ook een rest_command gebruiken, ik denk als ik zo jouw verhaal lees meer van toepassing is:
https://www.home-assistant.io/integrations/rest_command/

[Voor 8% gewijzigd door septillion op 28-03-2023 12:42. Reden: Denk aan de ' yaml' bij code-tags aub]

[Ora et Labora]

Sicco92 schreef op dinsdag 28 maart 2023 @ 11:08:
[...]

Dat werkt dus niet als je elk uur een ander tarief hebt. Je tarief staat niet vast, dus kan je niet simpel tarief * optellend dagverbruik doen.
Eigenlijk zou je dus een cumulatieve sensor moeten hebben die elk uur verhoogd wordt met het huidige uurtarief * huidige verbruik in dat uur. Is vast iets voor te maken, maar ik ben het nog niet tegengekomen.

In mijn geval werkt dat wel omdat ik de energy-cost van zonneplan als bron heb ingegeven in m'n onderdeel "energie". Dat zou ook kunnen met Nordpol.

De sensoren uit het script komen uit het onderdeel "energie" en zijn dus correct, zij het met enige vertraging.

[Voor 11% gewijzigd door Ora et Labora op 28-03-2023 11:35]

[Sicco92]

Ora et Labora schreef op dinsdag 28 maart 2023 @ 11:34:
[...]

In mijn geval werkt dat wel omdat ik de energy-cost van zonneplan als bron heb ingegeven in m'n onderdeel "energie". Dat zou ook kunnen met Nordpol.

De sensoren uit het script komen uit het onderdeel "energie" en zijn dus correct, zij het met enige vertraging.

[Afbeelding]

Ja, dat heb ik ook gedaan en dat werkt inderdaad prima. Het Energy Dashboard is inderdaad zo'n cumulerende 'sensor' en die werkt perfect met uurprijzen.
Ik zie alleen niet hoe die template van @TheFes hiermee verband houdt. Voor zover ik kan zien maakt deze template gebruik van sensors die zelf al de kosten goed bijhouden (bijvoorbeeld via de DSMR-integratie), en gebruikt het niet de data die het Energy Dashboard bijhoudt.

Hoe ziet jouw template sensor eruit?

[Xqlus1ve]

Als basis gateway / hub voor een Zigbee Sonoff setje, is een Sonof USB dongle P(CC2652P) dan het handigste of een Sonoff gateway bridge?

Een USB dongle zou op zolder in mij NAS moeten komen, de bridge kan ik op iedere willekeurige plaats neer zetten, het is een nieuwbouw huis waarbij ik al snel signaal verlies heb tussen de vloeren. Ik weet ook niet of er voordelen zijn over een bridge vs dongle.

[Gizz]

@Xqlus1ve als je redelijk wat bedrade zigbee-apparaatjes in je zigbee mesh netwerk zal hebben maakt de plaatsing van de coördinator niet echt uit. Dan zou ik voor de stick gaan.

[Ora et Labora]

Sicco92 schreef op dinsdag 28 maart 2023 @ 12:06:
[...]

Ja, dat heb ik ook gedaan en dat werkt inderdaad prima. Het Energy Dashboard is inderdaad zo'n cumulerende 'sensor' en die werkt perfect met uurprijzen.
Ik zie alleen niet hoe die template van @TheFes hiermee verband houdt. Voor zover ik kan zien maakt deze template gebruik van sensors die zelf al de kosten goed bijhouden (bijvoorbeeld via de DSMR-integratie), en gebruikt het niet de data die het Energy Dashboard bijhoudt.

Hoe ziet jouw template sensor eruit?

Ik gebruik deze sensoren:

YAML:

sensor.p1_meter_3c39e7231bc2_total_power_import_t1_cost',
sensor.p1_meter_3c39e7231bc2_total_power_import_t2_cost',
sensor.p1_meter_3c39e7231bc2_total_power_export_t1_compensation',
sensor.p1_meter_3c39e7231bc2_total_power_export_t2_compensation',
sensor.p1_meter_3c39e7231bc2_total_gas_cost'

De rest is nagenoeg hetzelfde. Volgens mij zijn dit de sensoren uit het energy-dashboard, het werkt in elk geval wel.

[Voor 12% gewijzigd door Ora et Labora op 28-03-2023 14:12]

[de Peer]

Toch een vraag over het al dan niet gebruik van de 'time pattern' trigger voor automations.

Mijn (voorbeeld)situatie: Ik heb een woonkamer met 1 lamp en 5 motion sensors. Alleen als alle motion sensors geen beweging meer detecteren moet de lamp uitgezet worden. Er zitten ook radar sensoren bij die ook aanwezigheid detecteren zonder beweging, dus de situatie dat alle sensoren geen aanwezigheid meer zien komt bijna niet voor als er iemand in de kamer aanwezig is. Ze zien je ook als je stil zit op de bank.

Hoe ik gewend ben dit af te handelen (in Domoticz) is door gebruik te maken van een 'time pattern' trigger die 1 x per minuut kijkt of alle sensoren uit zijn, op basis van de state dus. Zo ja ==> lamp uit.

dus:

Methode 1
Trigger: Time pattern 1 x per minuut
Conditions: (1) alle sensoren zijn uit, en (2) lamp staat aan
Action: lamp uit.

Maar time pattern wordt vaak als een slechte manier gezien omdat je onnodig 1440 keer per dag je conditions gaat checken. Het gebruik maken van events wordt gezien als de betere methode.

dus:

Methode 2
Trigger voor state change:
sensor1 (uit)
sensor2 (uit)
sensor3 (uit)
sensor4 (uit)
sensor5 (uit)
Conditions: (1) alle sensoren zijn uit, en (2) lamp staat aan
Action: lamp uit.

Echter methode 2 is toch niet heel veel efficienter dan methode 1? Methode 2 triggert namelijk ook heel vaak zonder dat er tot actie wordt over gegaan, omdat er meestal nog aanwezigheid in de kamer is.
en zeker als je de time pattern op 3 minuten zou zetten dan triggert hij nog maar 1440/3 x per dag, wat voor een moderne cpu natuurlijk peanuts (verwaarloosbaar) is.

Dus ik ben benieuwd of event-based dan nog steeds als 'beter' wordt gezien dan time(pattern)-based.

[Svennie]

interessante discussie, in dit specifieke geval time based, zeker als er 5 kinderen door de kamer rennen bij een feestje bv maar over het algemeen event based zou ik zeggen,

Ander voorbeeld: mijn bewegingssensor in de badkamer boven gaat maar een paar keer per dag af, daar is het verschil nogal groot, niet het beste voorbeeld wellicht aangezien je deze sowieso niet elke minuut zou checken

[Voor 39% gewijzigd door Svennie op 28-03-2023 14:22]

[Ora et Labora]

de Peer schreef op dinsdag 28 maart 2023 @ 14:16:
Toch een vraag over het al dan niet gebruik van de 'time pattern' trigger voor automations.

Mijn (voorbeeld)situatie: Ik heb een woonkamer met 1 lamp en 5 motion sensors. Alleen als alle motion sensors geen beweging meer detecteren moet de lamp uitgezet worden. Er zitten ook radar sensoren bij die ook aanwezigheid detecteren zonder beweging, dus de situatie dat alle sensoren geen aanwezigheid meer zien komt bijna niet voor als er iemand in de kamer aanwezig is. Ze zien je ook als je stil zit op de bank.

Hoe ik gewend ben dit af te handelen (in Domoticz) is door gebruik te maken van een 'time pattern' trigger die 1 x per minuut kijkt of alle sensoren uit zijn, op basis van de state dus. Zo ja ==> lamp uit.

dus:

Methode 1
Trigger: Time pattern 1 x per minuut
Conditions: (1) alle sensoren zijn uit, en (2) lamp staat aan
Action: lamp uit.

Maar time pattern wordt vaak als een slechte manier gezien omdat je onnodig 1440 keer per dag je conditions gaat checken. Het gebruik maken van events wordt gezien als de betere methode.

dus:

Methode 2
Trigger voor state change:
sensor1 (uit)
sensor2 (uit)
sensor3 (uit)
sensor4 (uit)
sensor5 (uit)
Conditions: (1) alle sensoren zijn uit, en (2) lamp staat aan
Action: lamp uit.

Echter methode 2 is toch niet heel veel efficienter dan methode 1? Methode 2 triggert namelijk ook heel vaak zonder dat er tot actie wordt over gegaan, omdat er meestal nog aanwezigheid in de kamer is.
en zeker als je de time pattern op 3 minuten zou zetten dan triggert hij nog maar 1440/3 x per dag, wat voor een moderne cpu natuurlijk peanuts (verwaarloosbaar) is.

Dus ik ben benieuwd of event-based dan nog steeds als 'beter' wordt gezien dan time(pattern)-based.

Je kunt ook een binary-sensor-group-helper aanmaken met hierin alle bewegingssensoren.
Dan een automatisering, als de groep de status "off" heeft voor X tijd, dan de lampen uit. Als er beweging wordt gedetecteerd heeft de groep de status "on".

[de Peer]

Ora et Labora schreef op dinsdag 28 maart 2023 @ 14:25:
[...]

Je kunt ook een binary-sensor-group-helper aanmaken met hierin alle bewegingssensoren.
Dan een automatisering, als de groep de status "off" heeft voor X tijd, dan de lampen uit. Als er beweging wordt gedetecteerd heeft de groep de status "on".

Ja goeie, maar zou dat het ook echt 'beter' maken, of lijkt dat vooral zo en gebeurt er achter de schermen het een en ander?
En alles wat met helpers kan zou ook in YAML moeten kunnen toch. Ik gebruik persoonlijk het liefst zo min mogelijk de GUI en helpers etc, op enkele uitzonderingen na.

In domoticz deed ik alles (en dat was best veel) via de time pattern methode. Ja dat is relatief inefficient want veel onnodige checks per dag. Echter de idle load van de RPi 3B was altijd onder de 4-5% dus waar hebben we het dan eigenlijk over. Volgens mij is die inefficientie dan niet erg relevant en is het vooral een theoretische discussie of een streven naar perfectionisme om zo min mogelijk onnodige 'checks' te hebben.

[Voor 37% gewijzigd door de Peer op 28-03-2023 14:42]

[Limbeckx]

nvm

[Voor 93% gewijzigd door Limbeckx op 28-03-2023 14:38]

[Svennie]

de Peer schreef op dinsdag 28 maart 2023 @ 14:35:
[...]

Ja goeie, maar zou dat het ook echt 'beter' maken, of lijkt dat vooral zo en gebeurt er achter de schermen het een en ander?
En alles wat met helpers kan zou ook in YAML moeten kunnen toch. Ik gebruik persoonlijk het liefst zo min mogelijk de GUI en helpers etc, op enkele uitzonderingen na.

achter de schermen wordt bij elk event van een van de 5 sensoren deze binary_sensor opnieuw geevalueerd. Dat zijn op een drukke dag dus meer acties dan eens per minuut evalueren en op rustige dag veel minder

[Ora et Labora]

de Peer schreef op dinsdag 28 maart 2023 @ 14:35:
[...]

Ja goeie, maar zou dat het ook echt 'beter' maken, of lijkt dat vooral zo en gebeurt er achter de schermen het een en ander?
En alles wat met helpers kan zou ook in YAML moeten kunnen toch. Ik gebruik persoonlijk het liefst zo min mogelijk de GUI en helpers etc, op enkele uitzonderingen na.

Grappig, ik gebruik juist zo min mogelijk YAML en bijna overal de GUI voor, heerlijk overzichtelijk.
Wat mij betreft maakt het het wel beter, want overzichtelijker. Achter de schermen gebeurd er constant wat, bij iedere detectie gebeurd er wat, bij iedere vrijgave ook. Een automatisering is constant aan het checken of hij aan de voorwaarde voldoet om te mogen uitvoeren, hoe dan ook.

In domoticz deed ik alles (en dat was best veel) via de time pattern methode. Ja dat is relatief inefficient want veel onnodige checks per dag. Echter de idle load was altijd onder de 4-5% dus waar hebben we het dan eigenlijk over. Volgens mij is die inefficientie dan niet erg relevant en is het vooral een theoretische discussie of een streven naar perfectionisme om zo min mogelijk onnodige 'checks' te hebben.

Ik heb bijvoorbeeld een automatisering met 17 "choose" acties en 287 regels yaml.
Al m'n automatiseringen gebruiken 2575 regels yaml en dan heb ik ook nog een hoop scripts en scene's.
En dit alles draait op een oude NUC met Proxmox waar ook Xpenology op draait en ondanks dat, draait het supersnel zonder hoge load en gebruikt tussen de 8-10 W/h.

[Voor 8% gewijzigd door Ora et Labora op 28-03-2023 14:53]

[Xqlus1ve]

Gizz schreef op dinsdag 28 maart 2023 @ 13:14:
@Xqlus1ve als je redelijk wat bedrade zigbee-apparaatjes in je zigbee mesh netwerk zal hebben maakt de plaatsing van de coördinator niet echt uit. Dan zou ik voor de stick gaan.

Momenteel heb ik niets bedraad zitten en ga ik beginnen met wat losse temp/humidity en bewegingssensoren, mijn Hue lampen blijven verbonden met de Hue bridge.

Dan is mogelijk de gateway bridge een betere oplosing om mee te starten. Qua compatibility en toepasbaarheid in HA maakt het niets uit tussen de dongle en bridge?

[septillion]

@de Peer Punt is dat je daar dus resolutie inlevert om het niet te vaak te pollen. Daarnaast, als je alle automations zo maakt ben je ze dus steeds aan het groeperen rond elke seconde/minuut/etc. Komt het steeds in golven. En ook als er dus niets gebeurd heb je triggers.

Mooie dat het op de achtergrond al event based is dat het dus relatief licht is terwijl het wel instantaan is.

En of je de UI wel of niet wilt gebruiken is een persoonlijke keuze waar ik in kan komen. Maar waarom geen helpers? Die kan je ook in yaml aanmaken en kunnen zaken wel makkelijk (of überhaupt mogelijk) maken.

[Voor 21% gewijzigd door septillion op 28-03-2023 16:37]

[septillion]

@Xqlus1ve Ligt aan welke bridge je wilt gebruiken en over welke integratie je denkt.

[Xqlus1ve]

septillion schreef op dinsdag 28 maart 2023 @ 16:40:
@Xqlus1ve Ligt aan welke bridge je wilt gebruiken en over welke integratie je denkt.

Sonof USB dongle P(CC2652P) vs Sonoff gateway bridge

[de Peer]

septillion schreef op dinsdag 28 maart 2023 @ 16:36:
@de Peer Punt is dat je daar dus resolutie inlevert om het niet te vaak te pollen.

Dat klopt, maar vaak is de resolutie niet zo belangrijk. Of hij nu elke 3 minuten kijkt of de verlichting uit mag of elke 10 seconden (of instantaan) is voor veel toepassingen niet belangrijk.
Bijvoorbeeld het laden van de auto. Na 10 uur laden mag hij instantaan stoppen maar hij mag ook best 1 x per 3 minuten kijken of hij al mag stoppen met laden. Voor die toepassingen is het niet belangrijk.

Daarnaast, als je alle automations zo maakt ben je ze dus steeds aan het groeperen rond elke seconde/minuut/etc. Komt het steeds in golven. En ook als er dus niets gebeurd heb je triggers.

Inderdaad. Maar de vraag is nu of dat ook een probleem is. Mijn domotica systeem werkt nu al 6 jaar op deze manier. De golven leiden niet tot een meetbaar hogere belasting van het systeem. Dus zijn het dan golven of druppels?
Ik begrijp je punt wel. Het is minder netjes, maar een echte reden waarom het 'slecht' zou zijn heb ik nog niet gehoord.

Mooie dat het op de achtergrond al event based is dat het dus relatief licht is terwijl het wel instantaan is.

Ja, in de meeste (niet alle) gevallen is dat lichter ja. Maar is lichter het enige criterium?
De methode met elke minuut polling heeft als voordeel dat je nooit een 'event' kunt missen want hij blijft telkens (elke minuut) controleren of er al aan bepaalde voorwaarden voldaan wordt.
Event missen zou kunnen door herstart HA, maar ook een korte internetstoring of een clouddienst (Buienradar, of dynamische tarieven leverancier) die er even 5 minuten uit ligt. Met polling via bijvoorbeeld time pattern vang je dit dan af.

Hoe kijk je hier naar?

En of je de UI wel of niet wilt gebruiken is een persoonlijke keuze waar ik in kan komen. Maar waarom geen helpers? Die kan je ook in yaml aanmaken en kunnen zaken wel makkelijk (of überhaupt mogelijk) maken.

Ok, daar moet ik nog verder in duiken dan. Op dat gebied ben ik nog onvoldoende ingelezen.

[septillion]

@Xqlus1ve Weet wel dat je bij de ZBBridge zelf de boel nog moet flashen. ook is hij in Z2M experimenteel en voor ZHA "not recommended" wegens wifi only.

DeConz valt natuurlijk af, dat werkt alleen met een ConBee.

[TheMystery]

Gisteren mijn iPhone geupdate naar iOS 16.4, na deze update werken notificaties met bijlagen niet meer, dit alleen via WiFi. Via mobiel netwerk werkt het wel.
Op een iPad met 16.4 geen problemen.

Op het ha forum topic gevonden met zelfde probleem maar helaas nog geen oplossing.
Wel dat een deinstallatie kon helpen maar bij mij werkte het toen 1x en daarna ook niet meer.
Dus voor anderen die nog niet ge-update hebben en waarvoor notificaties met bijlagen belangrijk vinden moeten misschien nog even niet updaten.

Notificaties zonder bijlagen blijven wel werken.

[Voor 4% gewijzigd door TheMystery op 28-03-2023 17:15]

[Slinkos]

TheMystery schreef op dinsdag 28 maart 2023 @ 17:15:
Gisteren mijn iPhone geupdate naar iOS 16.4, na deze update werken notificaties met bijlagen niet meer, dit alleen via WiFi. Via mobiel netwerk werkt het wel.
Op een iPad met 16.4 geen problemen.

Op het ha forum topic gevonden met zelfde probleem maar helaas nog geen oplossing.
Wel dat een deinstallatie kon helpen maar bij mij werkte het toen 1x en daarna ook niet meer.
Dus voor anderen die nog niet ge-update hebben en waarvoor notificaties met bijlagen belangrijk vinden moeten misschien nog even niet updaten.

Notificaties zonder bijlagen blijven wel werken.

Heeft hij misschien een nieuw device aangemaakt? Waardoor je entity id nu een _2 heeft?

[Faece]

Ik zou van de website : https://www.brafco.be/nl/huidige-maximumprijzen de propaan prijs <2000 liter via een scrap script willen importeren maar ik weet niet goed hoe ik dit moet doen.

YAML:

scrape:
  - resource: https://www.brafco.be/nl/huidige-maximumprijzen  
    sensor:
      - name: propaan
        select: .view-brandstofprijzen

Ik weet niet goed wat bij select moet komen

[Voor 0% gewijzigd door septillion op 29-03-2023 09:08. Reden: Denk aan de ' yaml' bij code-tags aub]

[TheMystery]

Slinkos schreef op dinsdag 28 maart 2023 @ 17:22:
[...]

Heeft hij misschien een nieuw device aangemaakt? Waardoor je entity id nu een _2 heeft?

Nee heb eerst de oude verwijderd, dus is opnieuw aangemaakt met zelfde naam.
Maar notificaties zonder afbeeldingen werken gewoon.

Workaround voor nu is local push uitzetten:
https://github.com/home-assistant/iOS/issues/2316

[Voor 12% gewijzigd door TheMystery op 28-03-2023 20:35]

[Seafarer]

FlashHeaven schreef op maandag 27 maart 2023 @ 20:26:
Hey allemaal, ik zou persoonlijk heel graag een Sonoff NSPanel Pro willen inbouwen in de muur net boven een lichtschakelaar. Nu moet je hier blauw en bruin (stroom) naartoe hebben lopen, maar lopen deze hier op dit moment nog niet. Wat is de beste manier om dit te realiseren of zijn er mensen die tips hebben?

Draad trekken vanuit de centraal doos?

[Slinkos]

FlashHeaven schreef op maandag 27 maart 2023 @ 20:26:
Hey allemaal, ik zou persoonlijk heel graag een Sonoff NSPanel Pro willen inbouwen in de muur net boven een lichtschakelaar. Nu moet je hier blauw en bruin (stroom) naartoe hebben lopen, maar lopen deze hier op dit moment nog niet. Wat is de beste manier om dit te realiseren of zijn er mensen die tips hebben?

Waar je lampen hangen zit meestal een centraaldoos waar je deze draden vandaan kan halen. Andere optie is snoer van een oud apparaat knippen en de uiteinden afstrippen. Dan kan je hem gewoon in het stopcontact steken.

[tlpeter]

de Peer schreef op dinsdag 28 maart 2023 @ 16:52:
[...]

Dat klopt, maar vaak is de resolutie niet zo belangrijk. Of hij nu elke 3 minuten kijkt of de verlichting uit mag of elke 10 seconden (of instantaan) is voor veel toepassingen niet belangrijk.
Bijvoorbeeld het laden van de auto. Na 10 uur laden mag hij instantaan stoppen maar hij mag ook best 1 x per 3 minuten kijken of hij al mag stoppen met laden. Voor die toepassingen is het niet belangrijk.

[...]

Inderdaad. Maar de vraag is nu of dat ook een probleem is. Mijn domotica systeem werkt nu al 6 jaar op deze manier. De golven leiden niet tot een meetbaar hogere belasting van het systeem. Dus zijn het dan golven of druppels?
Ik begrijp je punt wel. Het is minder netjes, maar een echte reden waarom het 'slecht' zou zijn heb ik nog niet gehoord.

[...]

Ja, in de meeste (niet alle) gevallen is dat lichter ja. Maar is lichter het enige criterium?
De methode met elke minuut polling heeft als voordeel dat je nooit een 'event' kunt missen want hij blijft telkens (elke minuut) controleren of er al aan bepaalde voorwaarden voldaan wordt.
Event missen zou kunnen door herstart HA, maar ook een korte internetstoring of een clouddienst (Buienradar, of dynamische tarieven leverancier) die er even 5 minuten uit ligt. Met polling via bijvoorbeeld time pattern vang je dit dan af.

Hoe kijk je hier naar?

[...]

Ok, daar moet ik nog verder in duiken dan. Op dat gebied ben ik nog onvoldoende ingelezen.

Je zou kunnen kijken of de Node-red integratie binnen HA voor jou beter werkt qua automatisering.
Ik doe een gedeelte binnen HA maar ook een gedeelte in Node-red.

[septillion]

@de Peer Voor deze situatie misschien niet. Maar voor het inschakelen bijvoorbeeld al wel. En bijvoorbeeld voor een doorloopruimte vind ik het ook al wel veel.

En ja, hoe meer rekenkracht je hebt hoe minder issues. Maar als alles zo zou moeten werken en ook nog eens direct heb je wel een issue. Want om voor je gevoel dan direct het licht aan te laten gaan zou je meerdere keren per seconde moeten pollen. En HA is event based, dus de event lopen op de achtergrond toch al Dus waarom zou je het dan niet gewoon netjes doen en dan echt weten wat er gebeurd dan domweg de vertraging voor lief nemen.

En met pollen kan je het net zo goed missen. Juist dan wel. Misschien niet bij deze sensoren maar als je een sensor hebt die maar kort een andere state heeft kan je dat juist missen. Event based kan niet gemist worden, anders is de state in HA überhaupt niet aangepast.

Levert overigens ook een beter te debuggen situatie op Immers heb je alleen een trace als er echt wat gebeurde.

Dus in dit geval is het niet echt fout maar onnodige bad practice.

[septillion]

tlpeter schreef op woensdag 29 maart 2023 @ 07:45:
[...]

Je zou kunnen kijken of de Node-red integratie binnen HA voor jou beter werkt qua automatisering.
Ik doe een gedeelte binnen HA maar ook een gedeelte in Node-red.

Potato, potahto Ook dat is in de bases gewoon event based. Dus mooi alternatief voor mensen die meer visueel denken of er al ervaring mee hebben. Maar voor beide moet je gewoon de basis van trigger, conditie en actie snappen naar mijn idee.

Voor het visuele ben ik dan ook nog steeds voorstander dat de flow weergave zoals in de automation trace ook weergegeven wordt in de automation editor

[-Casper]

tlpeter schreef op woensdag 29 maart 2023 @ 07:45:
[...]

Je zou kunnen kijken of de Node-red integratie binnen HA voor jou beter werkt qua automatisering.
Ik doe een gedeelte binnen HA maar ook een gedeelte in Node-red.

Ik denk voor iemand die zegt in YAML te willen werken omdat de GUI een chaos zou creëren, Node-RED geen goede oplossing zou zijn

[Ronker32]

Sinds eergisteren is mijn Energy Dashboard er mee opgehouden, om onduidelijke redenen. Ik gebruik de slimmelezer van Marcel Zuidwijk. Die heb ik gisteren opnieuw geconfigureerd, maar daar ligt het probleem niet. Ik kan gewoon slimmelezer.local bereiken en zie de data ook veranderen. In HA zie ik echter wat opmerkelijke dingen. Zo wordt er aangegeven dat er geen statistics beschikbaar zijn voor mijn sensor, maar als ik de history op zoek zie ik wel degelijk data. Volgens de Developer Tools is de device_classe en state_class wel correct lijkt me. Iemand enig idee hoe dit op te lossen of hoe dit beter te troubleshooten?

[septillion]

@Ronker32 Errors in de log? Klinkt een beetje alsof de DB kapot is gegaan.

[TheFes]

Ronker32 schreef op woensdag 29 maart 2023 @ 09:25:
Sinds eergisteren is mijn Energy Dashboard er mee opgehouden, om onduidelijke redenen. Ik gebruik de slimmelezer van Marcel Zuidwijk. Die heb ik gisteren opnieuw geconfigureerd, maar daar ligt het probleem niet. Ik kan gewoon slimmelezer.local bereiken en zie de data ook veranderen. In HA zie ik echter wat opmerkelijke dingen. Zo wordt er aangegeven dat er geen statistics beschikbaar zijn voor mijn sensor, maar als ik de history op zoek zie ik wel degelijk data. Volgens de Developer Tools is de device_classe en state_class wel correct lijkt me. Iemand enig idee hoe dit op te lossen of hoe dit beter te troubleshooten?

[Afbeelding]

[Afbeelding]

[Afbeelding]

Heb je al bij developer tools > statistics gekeken of er wellicht een issue met de sensor is?

[de Peer]

septillion schreef op woensdag 29 maart 2023 @ 09:05:
@de Peer Voor deze situatie misschien niet. Maar voor het inschakelen bijvoorbeeld al wel.

Oh ja maar ik gebruik voor 95% wel gewoon event-based automations natuurlijk. Dus sensoren inschakelen uiteraard nooit via polling.
Maar uitschakelen van iets bij geen detectie van beweging kan best via polling.

En met pollen kan je het net zo goed missen. Juist dan wel. Misschien niet bij deze sensoren maar als je een sensor hebt die maar kort een andere state heeft kan je dat juist missen.

Ja maar dat is dan ook niet hoe ik het gebruik. voor die situatie moet je events gebruiken inderdaad.
Maar polling kan handig zijn om te kijken of een apparaat daadwerkelijk in of uitgeschakeld is, als controlemechanisme.
Wat ik met de motion sensors altijd deed: langer dan 5 minuten geen beweging en de lamp staat aan? zet de lampen uit.
dat werkt dan na 5 minuten, maar ook na 10 minuten of na 3 uur. Het werkt dus ook als je een event (na precies die 5 minuten) gemist zou hebben om wat voor reden dan ook.

Event based kan niet gemist worden, anders is de state in HA überhaupt niet aangepast.

Als een cloud-dienst (bijvoorbeeld voor dynamische tarieven elektra) tijdelijk offline is, dan kun je toch een trigger missen?
Met polling niet, want je controleert dan bijvoorbeeld elk kwartier of er juist geanticipeerd is op de actuele tarieven.

Dus in dit geval is het niet echt fout maar onnodige bad practice.

Ja dat is wel waar. het is wat inefficient, maar dat is vooral een theoretisch verhaal. De daadwerkelijke effecten zijn verwaarloosbaar.

Idealiter werk je met alleen events, en hooguit hier en daar een polling-mechanisme om zeer kritische zaken te controleren en dan bij voorkeur niet per minuut maar per 15min bijvoorbeeld en alleen op de uren per dag dat het ook echt nodig is..

[de Peer]

tlpeter schreef op woensdag 29 maart 2023 @ 07:45:
[...]

Je zou kunnen kijken of de Node-red integratie binnen HA voor jou beter werkt qua automatisering.
Ik doe een gedeelte binnen HA maar ook een gedeelte in Node-red.

Dat vind ik helemaal niets. ik ben geen voorstander van visueel programmeren. Werkt niet voor mij. Geef mij maar code

[Ronker32]

septillion schreef op woensdag 29 maart 2023 @ 09:27:
@Ronker32 Errors in de log? Klinkt een beetje alsof de DB kapot is gegaan.

Geen bijzonderheden eerlijk gezegd, wat standaarderrors over Chromecast en Google Nest Audio die af en toe wat heartbeatproblemen hebben.

TheFes schreef op woensdag 29 maart 2023 @ 09:27:
[...]


Heb je al bij developer tools > statistics gekeken of er wellicht een issue met de sensor is?

Goede tip, daar had ik nog niet aan gedacht! Maar daar ook geen problemen, alles lijkt in orde. Ik heb gisteravond ook de entities al opnieuw toegevoegd aan het Energy Dashboard, maar ook dat had dus geen gewenst effect helaas.

[septillion]

Laat ik beginnen met, wil je de nuance wel horen of gewoon niet?

de Peer schreef op woensdag 29 maart 2023 @ 09:32:
Maar polling kan handig zijn om te kijken of een apparaat daadwerkelijk in of uitgeschakeld is, als controlemechanisme.

Naar mijn idee dus niet daar je een handiger (want direct) alternatief hebt zonder moeite.

Naar mijn idee dus vergelijkbaar met de bel uit zetten en elke half uur kijken of de postbode je pakket voor de deur in de kliko heeft gestopt. Werkt wel, maar waarom zou ik als ik een bel heb die niet te missen valt?

Het werkt dus ook als je een event (na precies die 5 minuten) gemist zou hebben om wat voor reden dan ook.

En dat is dus niet waar Heel HA is event based. Dus event gemist = HA niet bijgewerkt = polling gaat ook fout.

Als een cloud-dienst (bijvoorbeeld voor dynamische tarieven elektra) tijdelijk offline is, dan kun je toch een trigger missen?

Nee, want de trigger is er dan simpelweg niet geweest. Verandering van de state overigens ook niet dus pollen kan ook niet. En net als je met pollen voor die situatie robust kunt maken kan met met event based net zo.

In geval van het voorbeeld met het pakketje en de bel, als de bel niet zou werken als de postbode voor de deur stond zou de bel gaan zodra hij weer werkt. En zolang de bel niet werkt kan je ook niet checken of het pakketje er ligt.

Ja dat is wel waar. het is wat inefficient, maar dat is vooral een theoretisch verhaal. De daadwerkelijke effecten zijn verwaarloosbaar.

Inefficiënt zou ik het zelf niet noemen, het is een trade-off. En verwaarloosbaar is afhankelijk van wat je er onder verstaat. Bedoel, ik vind niet direct reageren, onoverzichtelijke logs en steeds moeten nadenken of iets met polling kan of niet etc in veel gevallen niet verwaarloosbaar. En zeker het dan weer delen van dat soort automations maakt het voor mensen die niet over dat laatste nadenken schept ook verwarring. Vandaar de ongenuanceerde vuistregel dat pollen niet smart is. Maar zoals bij elke vuistregel zijn er edge cases

en hooguit hier en daar een polling-mechanisme om zeer kritische zaken te controleren en dan bij voorkeur niet per minuut maar per 15min bijvoorbeeld en alleen op de uren per dag dat het ook echt nodig is..

Zeker voor kritische zou ik juist GEEN polling voor doen De events gebeuren altijd en daar kan je nagenoeg altijd op handelen.

Ofwel, voor dit geval, laat ik het omdraaien. Voor dit geval zie ik maar een kleine voordeel van pollen (enkele trigger) en meerder kleine voordelen voor event based (altijd hetzelfde, goed logs, geen vertraging). Beide klein, maar toch genoeg om voor mij te zeggen dat de vuistregel gewoon stand houdt

Maar als je het al hebt en kunt leven met de nadelen dan zeg ik, gewoon houden en niet delen

[Voor 6% gewijzigd door septillion op 29-03-2023 10:13]

[septillion]

@Ronker32 Al reboot (of op zijn minst restart van HA) gedaan?

[de Peer]

septillion schreef op woensdag 29 maart 2023 @ 09:59:
Laat ik beginnen met, wil je de nuance wel horen of gewoon niet?

Zeker wel! Want met deze post heb je me wel overtuigd denk ik. Dus dank daarvoor. Ik ga het nog even goed laten bezinken maar ik kan me hier wel in vinden.

Ik moet de boel nog omzetten van Domoticz naar HA dus een goed moment om nog minder te gaan 'Pollen'.

[Voor 13% gewijzigd door de Peer op 29-03-2023 10:23]

[Ronker32]

septillion schreef op woensdag 29 maart 2023 @ 10:02:
@Ronker32 Al reboot (of op zijn minst restart van HA) gedaan?

Ja, zowel gisteren als zojuist nog een keer. In mijn optiek is het meest vreemde dat er in het popup-scherm van de sensor geen 'statistics' beschikbaar zijn, maar bij doorklikken naar de history wel. Mijn utility meters worden overigens ook niet meer bijgewerkt.

Die worden dus wel bijgewerkt, maar dus alleen in de history en niet in het popup scherm. De data uit het popup-scherm komt ook niet overeen met de data uit de sensor..

[Voor 37% gewijzigd door Ronker32 op 29-03-2023 10:27]

[RobertMe]

septillion schreef op woensdag 29 maart 2023 @ 09:59:
[...]

Naar mijn idee dus niet daar je een handiger (want direct) alternatief hebt zonder moeite.

Naar mijn idee dus vergelijkbaar met de bel uit zetten en elke half uur kijken of de postbode je pakket voor de deur in de kliko heeft gestopt. Werkt wel, maar waarom zou ik als ik een bel heb die niet te missen valt?


[...]

En dat is dus niet waar Heel HA is event based. Dus event gemist = HA niet bijgewerkt = polling gaat ook fout.


[...]

Nee, want de trigger is er dan simpelweg niet geweest. Verandering van de state overigens ook niet dus pollen kan ook niet. En net als je met pollen voor die situatie robust kunt maken kan met met event based net zo.

In geval van het voorbeeld met het pakketje en de bel, als de bel niet zou werken als de postbode voor de deur stond zou de bel gaan zodra hij weer werkt. En zolang de bel niet werkt kan je ook niet checken of het pakketje er ligt.

De vergelijking met de postbode klopt natuurlijk niet helemaal . Een bel is geen state, maar een trigger, hetzelfde als dat in HA sowieso alle button varianten device triggers horen te zijn. De situatie zou moeten zijn met een state "pakketje bezorgd", en de state " pakketje bezorgd" werk je bij op basis van een "deurbel gaat" event. Maar op het moment dat de deurbel niet werkt of de postbode deze niet gebruikt wordt de state ook niet bijgewerkt. Dat is dus de situatie die jij schetst met "als het event niet werkt wordt de state ook niet bijgewerkt". Geen deurbel event/trigger betekent dan dat het pakketje niet bezorgd is. Soms kun je de state naderhand bijwerken (bv door buiten gaan te kijken voor het pakketje), soms kan dat niet.
Hetzelfde geldt voor het voorbeeld van @de Peer. Als door een (ver)storing niet de dynamische energietarieven opgehaald kunnen worden dan krijg je naderhand vanzelf een trigger als het wel weer werkt. Immers is de kans aanwezig (/groot) dat na de storing er een ander tarief is waardoor de state veranderd. Maar nog eerder doordat HA de entity door de verstoring als unavailable zal markeren, als de cloud API weer werkt dan zal er dus ook een state trigger zijn die van unavailable naar de huidige state gaat, omdat die gepollt kan worden.
Maar bv bewegingsmelders of contactsensoren via Zigbee/Z-Wave kun je helemaal niet pollen. Als HA daarvan een event mist v.w.b. aan/uit dan wordt de automation niet getriggerd maar ook de state niet bijgewerkt. Dus je kunt dan wel elke minuut pollen, maar je kijkt nog steeds naar de verkeerde state.
En dit verklaard ook waarom HA de last_change niet behoud over restarts. Hoe moet HA weten of de state uberhaupt niet veranderd is in de tijd dat deze offline is? Als HA 5 minuten niet werkt en ik doe net in die tijd het raam open dan weet HA dat niet, en dat raam kan vervolgens best uren de verkeerde / oude state behouden (net zoals dat in Domoticz kon, omdat die de state change niet gezien heeft). En HA weet dus ook niet of ik tijdens de reboot / storing het raam open heb gehad. Dus het scenario van bv "raam moet elke dag 1 uur geopend zijn voor ventileren" en vervolgens werkt HA 2 uur niet en net in die periode zet ik zelf het raam een uur open dan kan HA nooit weten dat het raam open is geweest.

En een oplossing met "pollen" pollt dus alleen de state in het domotica systeem, niet ee state van het daadwerkelijke ding (fysieke sensor of bv cloud API). Dus dat maakt het nogal onzinnig. En als bij Domoticz de state binnen Domoticz wel bijgewerkt kan worden naar dit geen trigger kan geven dan lijkt mij alleen dat al een uitstekend argument om Domoticz niet te gebruiken .

[septillion]

@RobertMe Klopt wel dat het iets genuanceerder is. Maar heb de bel nooit een state genoemd En vandaar de niet te missen bel, dat de bel gaat als deze wel werkt en een pakket bezorgd is, en het niet kunnen checken of een pakket bezorgd is zonder dat de bel werkt Randvoorwaarde die inderdaad allemaal impliciet voortkomen uit het feit dat de deurbel (het event) volledig bepaald of je kunt zien dat het pakket bezorgd is (state).

@algemeen
Nu zijn er wel wat sensoren (zowel fysiek als virtueel) die naast events ook pollen. Dit kan er voor zorgen dat een state weer eerder bekend is na een herstart of voor zaken die je moet rate limiten (bv energiemeters). Devices op batterijen doen dit zelden of erg weinig.

Maar ook is er dus een verschil tussen een sensor event en het event in HA, en sensor state en HA state. Vanuit HA reageer je op de laatste en kan je dus al nooit direct op het event reageren of direct naar de state kijken (er vanuit gaande dat je entiteiten gebruikt). Je laat HA dus al mooi alle heavy lifting incl unknown en unavailable states bijhouden. Dat zorgt er juist voor dat jij dat met het maken van een automation allemaal niet meer hoeft te doen

Dus @de Peer, helemaal in de basis heb je gelijk dat pollen zaken een extra laag van robustheid kunnen geven. Maar als het al mogelijk is voor dat type sensor doet HA dat op de achtergrond en kan je dat niet door een state in HA te pollen

[slow whoop]

TheMystery schreef op dinsdag 14 februari 2023 @ 20:53:
[...]


Ik heb dit al een aantal jaar draaien.
Je maakt eerst een basic config met je controller id welke in je controller te vinden is.
Hierna leert ie automatisch je zones en maakt er een schema van, hierin kun je per zone je sensors en actuators uithalen.
Een hr92 begint met id 04, een bdr91 met 13, sensor met 03, evofw stick heeft 18. De rest heb ik niet maar is misschien in de wiki te vinden of op het ha forum. Hiermee kun je denk ik al redelijk wat herkennen. Ik heb mijn hr92 in de garage gelegd die koud was, en zo heb ik ze allemaal geïdentificeerd.

Als je al je id’s hebt zet je deze in je known list aangezien er vaker corrupted pakketten ontvangen worden en hierdoor verkeerde entities in ha krijgt.

Ik heb ook een Evohome systeem en ik wilde meer inzicht krijgen in de warmtevraag die elke thermostaat van m'n CV-ketel vraagt. Die informatie kan ik wel real-time zien op het scherm van m'n Evohome thermostaat, maar kan ik niet loggen.

Ik heb daarom ook zo'n USB 868 MHz dongle met evofw3 gekocht en ben met de ramses_cc integratie aan de slag gegaan. Dat werkt best goed. Je kunt van elke ruimte de temperatuur zien en instellen, zonder gebruik te hoeven maken van de Evohome integratie, die via de Honeywell servers loopt. Zo kan ik dus alles lokaal houden. En het geeft ook inzicht in de warmtevraag en andere parameters van m'n CV-ketel, zoals ingestelde temperaturen, of de CV-ketel aan is, warmtevraag voor centrale verwarming of warm water, etc.

Het werkt zelf zo goed dat ik ook inzicht krijg in het Evohome systeem van de buren die een paar huizen verderop wonen. Ik kan al hun zones zien, en zelfs instellen. Nu heb ik alleen m'n eigen Evohome devices in mijn "known list" gezet, dus die van de buren zijn onzichtbaar in HA, maar kwaadwillenden zouden hier gemakkelijk misbruik van kunnen maken. Ik ben ook nog niet tegengekomen of dit te beveiligen valt. De USB dongle praat net zo makkelijk met mijn Evohome systeem als dat van een ander, zolang het maar in de buurt is. Daar is verder geen authenticatie voor nodig.

[Devil103]

Ik ben al een tijdje opzoek naar een grafische manier om het verbruik van vermogen in het huis in een oogopslag weer te geven. Daarvoor maak ik gebruik van het powerwheel card die mooi toont hoeveel elektricteit we verbruiken van het net en van de zonnepanelen.

Je ziet jammer genoeg enkel het verbruik van het volledige huis, niet van (grote) individuele gebruikers. Eigenlijk is er voorlopig maar één grote verbruiker en dat is de EV. Soms ook de airco's. Voor beide heb ik reeds vermogen sensoren beschikbaar in Home Assistant.

Nu vond ik gisteren EVCC en hun manier voor de verdeling van het stroomverbruik weer te geven mbv een horizontale grafiek best wel goed.
Klik hier voor hun screenshot / voorbeeld

Ik ben al aan het zoeken geweest in de bar graph ed maar heb nog niet echt iets gevonden. Iemand enig idee welke lovelace card iets gelijkaardigs kan maken?

[Sicco92]

Devil103 schreef op woensdag 29 maart 2023 @ 12:57:
Ik ben al een tijdje opzoek naar een grafische manier om het verbruik van vermogen in het huis in een oogopslag weer te geven. Daarvoor maak ik gebruik van het powerwheel card die mooi toont hoeveel elektricteit we verbruiken van het net en van de zonnepanelen.

Je ziet jammer genoeg enkel het verbruik van het volledige huis, niet van (grote) individuele gebruikers. Eigenlijk is er voorlopig maar één grote verbruiker en dat is de EV. Soms ook de airco's. Voor beide heb ik reeds vermogen sensoren beschikbaar in Home Assistant.

Nu vond ik gisteren EVCC en hun manier voor de verdeling van het stroomverbruik weer te geven mbv een horizontale grafiek best wel goed.
Klik hier voor hun screenshot / voorbeeld

Ik ben al aan het zoeken geweest in de bar graph ed maar heb nog niet echt iets gevonden. Iemand enig idee welke lovelace card iets gelijkaardigs kan maken?

apexcharts-card is enorm uitgebreid, daar zou je dit vast mee na kunnen maken. Hier kan je in ieder geval wat voorbeelden en mogelijkheden vinden voor bar charts: https://apexcharts.com/docs/chart-types/bar-chart/ (let wel op dat sommige standaard ApexCharts functies nog experimenteel zijn in apexcharts-card voor Home Assistant)

Zelf gebruik ik een sankey chart om mijn huidige verbruik op te splitsen. Deze kaart is flink veel minder werk om op te zetten. Ik vind de bar charts die jij hebt gevonden ook wel erg mooi eigenlijk, dus misschien ga ik wel eens proberen om zoiets in ApexCharts na te maken.

Overigens heb je ook deze card: Power Flow Card Plus. Deze lijkt op de kaart in het Energy Dashboard, maar biedt bijvoorbeeld ook ondersteuning voor individuele verbruikers. Misschien is dat ook nog wat voor je

[Voor 7% gewijzigd door Sicco92 op 29-03-2023 13:29]

[PnD]

bartbh schreef op donderdag 23 maart 2023 @ 21:20:
[...]
Hoe vaak gebruik je 'm? Ik heb de originele batterij wel een keer vervangen maar verder dan dat geen hele grote drain.

Hoe gebruik jij hem? In combinatie met een conbeeII en deconz? Ik krijg het niet opgelost. Naar een alternatief aan het kijken, maar nog niet gevonden.

De Aqara H1/D1 spreken me aan qua design, maar moet nog even uitzoeken of dit 100% een succes gaat zijn.

[TGILLY]

Ik zou graag HA icons willen toen in de "Secondary information" field in the Mushroom entitiy cards
De bedoeling is om op de button hieronder, icons (mdi:xxxxx) te tonen als er een device actief is. Alleen slaag ik er niet in om code te vinden waarmee ik die icons kan laten zien in dat field. Misschien lukt het helemaal niet. Ik heb iets gezien <ha_icon> maar dat krijg ik niet werkend


Bedankt

[CodeBaker]

@TGILLY bedoel je zoeits?

Django/Jinja:

{% if is_state('binary_sensor.garage_contact', 'closed') %}
  Garage deur is open
{% else %}
  Garage deur is dicht
{% endif %}

[Voor 1% gewijzigd door septillion op 29-03-2023 15:13]

[TGILLY]

CodeBaker schreef op woensdag 29 maart 2023 @ 14:25:
@TGILLY bedoel je zoeits?

Django/Jinja:

{% if is_state('binary_sensor.garage_contact', 'closed') %}
  Garage deur is open
{% else %}
  Garage deur is dicht
{% endif %}

Niet echt, eerder dit

Django/Jinja:

{% if is_state('binary_sensor.garage_contact', 'closed') %}
  mdi:garage-closed
{% else %}
  mdi:garage-open
{% endif %}

Dus eigenlijk een icoon laten zien in de text field

[Voor 0% gewijzigd door septillion op 29-03-2023 15:13]

[septillion]

@TGILLY Van code in plaatjes wordt nooit iemand blij

Maar heb je hier wat aan: TheFes in "Home Assistant: Open source Python3 home automation - deel 5"

[TGILLY]

septillion schreef op woensdag 29 maart 2023 @ 15:12:
@TGILLY Van code in plaatjes wordt nooit iemand blij

Maar heb je hier wat aan: TheFes in "Home Assistant: Open source Python3 home automation - deel 5"

Ik gebruik een template card

YAML:

  - type: custom:mushroom-template-card
    primary: Inkomhal
    secondary: '{{ state_attr(''climate.gelijkvloers'', ''current_temperature'') }} °C'
    icon: mdi:door-open
    entity: light.spotjes_inkomhal_l9
    tap_action:
      action: navigate
      navigation_path: /dashboard-mushroom/Inkomhal
    hold_action:
      action: toggle
    icon_color: |-
      {% if is_state('light.spotjes_inkomhal_l9','on') %}
       orange
      {% endif %}
    double_tap_action:
      action: more-info

Het is op field "secondary" (lijn 3) dat ik graag een icoon wil laten zien. Weet niet of het gaat eigenlijk...
@TheFes misschien

[Voor 0% gewijzigd door septillion op 29-03-2023 16:46. Reden: Denk aan de ' yaml' bij code-tags aub]

[Hmmbob]

Een icon op die lijn, dus niet als main icon?

Dat kan niet.

[TGILLY]

Hmmbob schreef op woensdag 29 maart 2023 @ 15:34:
Een icon op die lijn, dus niet als main icon?

Dat kan niet.

Inderdaad, niet main icon maar als icon op die lijn.
Via Dwains dashboard heb je entity cards waar je snel kan zien of er iets actief is (bv media player). Je kan het oplossen met badges maar je kan maar 1 badge per keer laten zien

[krijn1985]

TGILLY schreef op woensdag 29 maart 2023 @ 15:40:
[...]

Inderdaad, niet main icon maar als icon op die lijn.
Via Dwains dashboard heb je entity cards waar je snel kan zien of er iets actief is (bv media player). Je kan het oplossen met badges maar je kan maar 1 badge per keer laten zien

En als je de kleur van het icon aanpast op basis van actief of niet actief?

[TGILLY]

krijn1985 schreef op woensdag 29 maart 2023 @ 16:11:
[...]


En als je de kleur van het icon aanpast op basis van actief of niet actief?

Doe ik al voor het licht. Wil een icoontje laten zien als bv de radio speelt in die kamer..

[tlpeter]

TGILLY schreef op woensdag 29 maart 2023 @ 16:13:
[...]


Doe ik al voor het licht. Wil een icoontje laten zien als bv de radio speelt in die kamer..

Dat kan toch prima met een badge?

[TGILLY]

tlpeter schreef op woensdag 29 maart 2023 @ 16:15:
[...]

Dat kan toch prima met een badge?

Ja maar één badge, en wil er meerdere

[TheMystery]

slow whoop schreef op woensdag 29 maart 2023 @ 11:39:
[...]

Ik heb ook een Evohome systeem en ik wilde meer inzicht krijgen in de warmtevraag die elke thermostaat van m'n CV-ketel vraagt. Die informatie kan ik wel real-time zien op het scherm van m'n Evohome thermostaat, maar kan ik niet loggen.

Ik heb daarom ook zo'n USB 868 MHz dongle met evofw3 gekocht en ben met de ramses_cc integratie aan de slag gegaan. Dat werkt best goed. Je kunt van elke ruimte de temperatuur zien en instellen, zonder gebruik te hoeven maken van de Evohome integratie, die via de Honeywell servers loopt. Zo kan ik dus alles lokaal houden. En het geeft ook inzicht in de warmtevraag en andere parameters van m'n CV-ketel, zoals ingestelde temperaturen, of de CV-ketel aan is, warmtevraag voor centrale verwarming of warm water, etc.

Het werkt zelf zo goed dat ik ook inzicht krijg in het Evohome systeem van de buren die een paar huizen verderop wonen. Ik kan al hun zones zien, en zelfs instellen. Nu heb ik alleen m'n eigen Evohome devices in mijn "known list" gezet, dus die van de buren zijn onzichtbaar in HA, maar kwaadwillenden zouden hier gemakkelijk misbruik van kunnen maken. Ik ben ook nog niet tegengekomen of dit te beveiligen valt. De USB dongle praat net zo makkelijk met mijn Evohome systeem als dat van een ander, zolang het maar in de buurt is. Daar is verder geen authenticatie voor nodig.

Klopt daar zit helaas geen encryptie op, maar dan was de kans ook klein geweest dat het lokaal te bedienen is.

[TheFes]

TGILLY schreef op woensdag 29 maart 2023 @ 16:25:
[...]


Ja maar één badge, en wil er meerdere

Een emoji dan?

[TGILLY]

TheFes schreef op woensdag 29 maart 2023 @ 19:03:
[...]


Een emoji dan?

Geen slecht idee ! Dat werkt percies wel. Ga er eens mee aan de slag