Home Assistant: Open source Python3 home automation - deel 5

[Mimiix]

Get!em schreef op donderdag 15 augustus 2024 @ 16:25:
Zigbee bulbs die zichzelf als router aanmelden zijn soms ook een probleem. Heb je die toevallig?

Dat Aqara plugs niet goed communiceren heb ik hier ook. in een separaat netwerk, hangt de controller en de aqara plug 30cm van elkaar, en de aqara verliest gewoon zijn connectie (gaat rood/blauw knipperen). Wisselt ongeveer elke 10 minuten.

Wat bedoel je met die eerste zin?

220v apparaten zijn altijd routers(hele kleine uitzonderingen daargelaten).
Je begrijpt dat meerdere netwerken zorgen voor meer ruis met het gevolg dat je nog meer issues krijgt?

Een zigbee netwerk is een mesh, geen point to point. Hoe groter hoe beter. Ruis op 2.4ghz maakt het gevoeliger.

[ Voor 7% gewijzigd door Mimiix op 15-08-2024 21:31 ]

[Get!em]

Mimiix schreef op donderdag 15 augustus 2024 @ 21:30:
[...]


Wat bedoel je met die eerste zin?

Dat lichtbronnen die zigbee ondersteunen andere routers zijn dan de routers als plug en inbouw schakelaar/dimmers.

Hij komt van de standaard zigbee wiki:

Avoid adding Zigbee lightbulbs to your hub in combination with other Zigbee devices, since the lightbulbs will try to act as routers, but unfortunately they only perform this role properly with other lightbulbs.

Ik hoor graag als je de je dat dit een mythe is.


In mijn voorbeeld dat ik een tweede zigbee netwerk heb: ja helaas, kan niet anders ivm een apart apparaat dat alleen als hub functioneert. Ik ken de nadelen en ik ken het mesh principe. Gaat om Plugwise. Mocht iemand daar een oplossing voor hebben, laat maar weten. Plugwise integreert prima in home assistant via ethernet, maar zigbee integration schijnt niet mogelijk te zijn en het maakt vrolijk zijn eigen netwerk naar de thermostaat.

[Mimiix]

Get!em schreef op donderdag 15 augustus 2024 @ 21:46:
[...]

Dat lichtbronnen die zigbee ondersteunen andere routers zijn dan de routers als plug en inbouw schakelaar/dimmers.

Hij komt van de standaard zigbee wiki:

[...]

Ik hoor graag als je de je dat dit een mythe is.


In mijn voorbeeld dat ik een tweede zigbee netwerk heb: ja helaas, kan niet anders ivm een apart apparaat dat alleen als hub functioneert. Ik ken de nadelen en ik ken het mesh principe. Gaat om Plugwise. Mocht iemand daar een oplossing voor hebben, laat maar weten. Plugwise integreert prima in home assistant via ethernet, maar zigbee integration schijnt niet mogelijk te zijn en het maakt vrolijk zijn eigen netwerk naar de thermostaat.

Mij is niet bekend dat er een verschil is. Heb je de link voor mij? Ik vraag het graag na.

Mbt plugwise, is het plugwise circle?

[Boinkie]

TheFes schreef op donderdag 15 augustus 2024 @ 16:20:
[...]


er zullen op basis van jouw input triggers aangemaakt worden in een automation.
Zoals met elke trigger in HA moeten die van false naar true gaan. Als je de automation aangemaakt hebt op het moment dat ze eigenlijk al gesloten zouden moeten zijn, dan gebeurt er tot morgen waarschijnlijk niets.

Verder is het hier in ieder geval vrij cloudy, dus dat zou er ook mee te maken kunnen hebben.

Je zou overigens ook hier naar kunnen kijken:
https://github.com/basbruss/adaptive-cover

Thanks, al heb ik het idee dat hij helemaal niet uitgevoerd wordt. Moet ik een blueprint nog ergens inzetten zodat hij bijvoorbeeld elk uur uitgevoerd wordt? Het lijkt nu alsof hij aan het begin van de dag naar de forecast kijkt en daar zijn actie op baseert. Terwijl net als vandaag bewolkt begint en vervolgens zonnig wordt. dan wil ik dat die naar beneden gaat op het moment dat de sun azimut voldaan wordt. (Dat is rond 13.15 uur vandaag)

[RudolfR]

maartend schreef op donderdag 15 augustus 2024 @ 20:29:
Ik vraag hem wederom, want ik krijg geen antwoord en ik kan het niet vinden. En durf niet meer te updaten;

Hoe krijg ik het volgende weg
The legacy API password is deprecated

In mijn configuration.yaml staat het volgende;

YAML:

  auth_providers:
   - type: legacy_api_password
     api_password: !secret http_password
#   - type: trusted_networks
#     trusted_networks:
#       - 192.168.2.0/24

Ik heb alles wel eens een # voor gezet, maar toen kwam ik er volledig niet meer in.

Documentatie staat hier:
https://www.home-assistant.io/docs/authentication/providers/

[RobertMe]

Boinkie schreef op donderdag 15 augustus 2024 @ 22:11:
[...]


Thanks, al heb ik het idee dat hij helemaal niet uitgevoerd wordt. Moet ik een blueprint nog ergens inzetten zodat hij bijvoorbeeld elk uur uitgevoerd wordt? Het lijkt nu alsof hij aan het begin van de dag naar de forecast kijkt en daar zijn actie op baseert. Terwijl net als vandaag bewolkt begint en vervolgens zonnig wordt. dan wil ik dat die naar beneden gaat op het moment dat de sun azimut voldaan wordt. (Dat is rond 13.15 uur vandaag)

Een blueprint is zoals @TheFes aangeeft gewoon een automation. En een automation heeft triggers, en zolang een trigger niet af gaat ("nu" wijzigt van false naar true) gebeurd er niks. Gezien jij de blueprint hebt ingesteld op "temperatuur komt boven de 3 graden" zal er dus waarschijnlijk niks gebeuren, alleen al omdat (zeer waarschijnlijk) de temperatuur nu boven de 3 graden is.
Het is dus geen "controleer elk uur of...", maar "zodra ...". En die "gebeurtenis" die is ingesteld bij de "zodra" treed nu niet op (maar heeft eerder plaatsgevonden). Je kunt dus eens wachten of die het morgen wel doet (dan zal de zon binnen de ingestelde azimuth komen, en de temperatuur boven de 3 graden zijn / geraken). Als die dan nog niet werkt zal de blueprint (/automation) wel een trigger op de temperatuur nodig hebben, en moet je dus eens even kijken hoe warm het nu is binnen, en de "Temperature threshold" een graadje hoger zetten, zodat als de temperatuur oploopt die wel een gebeurtenis heeft van "temperatuur was lager, en is nu hoger, dan X" (waarbij je nu op die screenshot dus "X is 3" hebt, en nouja, daarop zal nu geen "was lager dan 3, en is nu hoger dan 3" zijn, want het is "is al de hele tijd hoger dan 3").

[Get!em]

Mimiix schreef op donderdag 15 augustus 2024 @ 21:51:
[...]


Mij is niet bekend dat er een verschil is. Heb je de link voor mij? Ik vraag het graag na.

Mbt plugwise, is het plugwise circle?

Plugwise Adam HA en Lisa
https://www.plugwise.com/

Zigbee
https://docs2.hubitat.com...build-a-solid-zigbee-mesh

De tekst daarvan is vele malen herhaald en bevestigd op dicerse fora en waaronder

https://zigbee2mqtt.disco...ble-after-few-days/1693/4

[HuismAndré]

Get!em schreef op donderdag 15 augustus 2024 @ 21:46:
[...]

Dat lichtbronnen die zigbee ondersteunen andere routers zijn dan de routers als plug en inbouw schakelaar/dimmers.

Hij komt van de standaard zigbee wiki:

[...]

Ik hoor graag als je de je dat dit een mythe is.

Volgens mij klopt die uitleg niet. Zie hieronder hoe een Hue lamp als router fungeert voor 2 devices die geen lamp zijn.

[Antonio di]

Get!em schreef op donderdag 15 augustus 2024 @ 22:59:
[...]

Plugwise Adam HA en Lisa
https://www.plugwise.com/

Zigbee
https://docs2.hubitat.com...build-a-solid-zigbee-mesh

De tekst daarvan is vele malen herhaald en bevestigd op dicerse fora en waaronder

https://zigbee2mqtt.disco...ble-after-few-days/1693/4

Er zijn een paar merken Zigbee lampen die firmware hebben zonder "router" functie (Bijv. Sengled). De gedachte daarachter is dat de lamp ook nog steeds bedient wordt door een "domme" schakelaar. Zet je die domme schakelaar in UIT stand dan zou de lamp met router opeens niet meer als router kunnen functioneren. Het automatisch gemanaged Zigbee Netwerk zou dan op zoek moeten naar een nieuw Zigbee component met router (voor bijv. een batterij component) en het zou dan kunnen zijn dat de afstand daar naartoe te ver is voor een goed verbinding.
Ook bij Alarmsystemen met naast het 868MHz draadloze protocol ook nog een Zigbee coördinator, zie je vaak dat vanuit de Zigbee coördinator alleen specifieke componenten een router functie kunnen hebben, c.q., mogen optreden als router. Bijv. een Zigbee schakel-relais achter een domme schakelaar met altijd stroom (blauw en Bruine draad) mag dat wel als router optreden. Een Zigbee Lamp (met router functie) daar in tegen treedt niet op als router bij zo'n Alarmsysteem met een specifieke Zigbee Coördinator.
Hier zit weer de zelfde gedachte achter.
Climax Alarm/Smarthomes systemen (met vele re-brands) is daarvan een goed voorbeeld. De 868MHz met een (centraal) ster-netwerk wordt daar gebruikt voor de kritische Alarm componenten (constateer een indringing/inbraak) en het zou toch fijn zijn dat je domme lampen kan trigger AAN te gaan bij Alarmering door het Zigbee schakel-relais aan te sturen.

Deze Zigbee router functie wordt dus bepaald door de firmware van de Zigbee Coördinator (bijv.: Climax) en/of het/de Zigbee component(en).
Standaard Zigbee is dat 110-230V Zigbee componenten als router optreden. De door mij genoemde voorbeelden zonder "router functie" zijn dus uitzonderingen.
Draadloze Alarm systemen opzetten met Zigbee batterij sensoren en Zigbee 230v componenten met router functie met HA, is daarom niet aan te raden. Bij 230v stroomuitval zou dat Alarm via zo'n Zigbee Mesh-netwerk hoogstwaarschijnlijk niet meer (niet compleet) werken. Ook niet als je HA aangesloten is op een nood-accu-tje.

[ Voor 29% gewijzigd door Antonio di op 16-08-2024 00:12 ]

[Septillion]

@Get!em Inderdaad, mythe. Hier routen alle Ikea lampen prima en heb ook al jaren een sloot Aqara temperatuur sensoren. Mijn coördinator (CC2652RB op Z2M) hangt ook in de kelderkast maar lampen op zolder en achter in de tuin werken prima.

Zijn inderdaad wel wat uitzonderingen (was het niet Innr of Osram die alleen devices van zichzelf wil routen) maar gros is gewoon router.

[ Voor 10% gewijzigd door Septillion op 16-08-2024 08:02 ]

[HuismAndré]

@Antonio di Als je de layout van je Zigbee netwerk bekijkt dan zie je dat er heel erg veel redundante routes zijn tussen routers onderling. Dit zorgt ervoor dat bij het wegvallen van een router (bijvoorbeeld omdat je een lamp fysiek uitdoet (edit: aangepast voor de duidelijkheid)) er altijd nog alternatieve routes zijn. Dat is juist de kracht van een mesh netwerk. Die kracht verzwak je door tegen bepaalde (fase-nul gevoede) devices te zeggen "jij doet niet mee".

Als je al iets van logica zou moeten toepassen op "intermittent routers" dan zou je kunnen stellen "lampen mogen niet als eindrouter fungeren voor batterij gevoede apparaten" maar in het stukje van mijn netwerk dat ik een paar posts geleden toonde wordt ook die logica niet toegepast.

Ik heb wel het idee dat het ene systeem beter overweg kan met wegvallende routers dan het andere systeem. Daarom heb ik voor de verlichting thuis nog steeds een Hue netwerk (stuk voor stuk lampen die met een lichtnetschakelaar aan en uit worden gezet) en een Z2M netwerk voor de devices die (nagenoeg) altijd aanwezig zijn. Ik durf nog steeds niet alles over te zetten naar Z2M (en het feit dat alles nu al vele maanden compleet vrij van welke issue dan ook werkt helpt ook al niet die stap te nemen).

@Septillion Mijn Z2M netwerk in de loods heeft 4 Osram devices (2 lampen en 2 x stopcontactjes) die fungeren als router voor diverse andere devices. Alleen is er geen enkel end device dat een Osram apparaat als end router gebruikt. In de showroom hangt een Hue bewegingsmelder met als dichtstbijzijnde router een Osram stopcontactje (8 meter vrije lucht). Echter gebruikt de bewegingsmelder een veel verder weg geplaatste Tint lichtschakelaar als eindrouter (verder weg als in 7 meter en 2 stalen wanden verder dan dat Osram stopcontactje). Ook een ander Osram stopcontactje dat dichterbij zit wordt niet gekozen.

[RobertMe]

HuismAndré schreef op vrijdag 16 augustus 2024 @ 08:54:
Dit zorgt ervoor dat bij het wegvallen van een router (bijvoorbeeld omdat je het licht uitdoet) er altijd nog alternatieve routes zijn.

Als je de lamp uit zet blijft die prima als router fungeren. Het probleem ontstaat pas als je ee stroom er vanaf haalt.

Daarom heb ik voor de verlichting thuis nog steeds een Hue netwerk (stuk voor stuk lampen die met een lichtnetschakelaar aan en uit worden gezet)

Dit zou je ook gewoon niet moeten doen. Niet alleen omdat het je Zigbee netwerk sloopt. Maar ook omdat je ze dan niet meer automatisch aan kunt zetten (tenzij je een slimme schakelaar voor slimme lampen zet). En daarnaast na het inschakelen je weer te maken krijgt met het power on gedrag van de lampen. Ergo: ze nemen een default state aan. Waarbii het vast even duurt voordat ze bereikbaar zijn en je de state kunt aanpassen. Dus wat is dan nog het nut van slimme lampen? Dan heb je IMO voldoende aan een slimme schakelaar (of dimmer).

[Mimiix]

Get!em schreef op donderdag 15 augustus 2024 @ 22:59:
[...]

Plugwise Adam HA en Lisa
https://www.plugwise.com/

Zigbee
https://docs2.hubitat.com...build-a-solid-zigbee-mesh

De tekst daarvan is vele malen herhaald en bevestigd op dicerse fora en waaronder

https://zigbee2mqtt.disco...ble-after-few-days/1693/4

Ik heb het nagevraagd , ik laat het weten als ik wat hoor. Hubitat is (mijn inziens) geen officiële authoriteit op dit gebied.

Wat betreft de plugwise: Ik kan niets vinden in deCONZ wat betreft device requests. Dat betekend in feite dat ik niet weet of hij werkt of niet. Dat hij niet direct werkt, snap ik want deCONZ werkt met een whitelist.

Als je hem koppelt aan deCONZ, kan je een device request aanvragen en als het apparaat netjes Zigbee is zou ie moeten werken.

[HuismAndré]

RobertMe schreef op vrijdag 16 augustus 2024 @ 09:01:
[...]

Als je de lamp uit zet blijft die prima als router fungeren. Het probleem ontstaat pas als je ee stroom er vanaf haalt.

En precies dat is natuurlijk wat ik bedoel (verderop in mijn verhaal komt dat ook naar voren):

Daarom heb ik voor de verlichting thuis nog steeds een Hue netwerk (stuk voor stuk lampen die met een lichtnetschakelaar aan en uit worden gezet)

Ik had er even "fysiek" bij moeten zetten om het nog wat te verduidelijken.

Ik heb thuis 55 Zigbee lampen die het gros van de tijd geen licht geven. Als ik die allemaal onder spanning zou houden dan zou dat onnodig 10-15W+ aan sluipverbruik toevoegen. Het Hue netwerk wordt door dat aan/uit schakelen niet gesloopt (want dan zou ik deze methode uiteraard niet gebruiken).

Het power-on gedrag stel je zo in dat alles werkt zoals je onder normale omstandigheden mag verwachten (ook handig als Opa en Oma komen oppassen). Alle schakelhardware blijft onveranderd (hebben we bij het ontwerp van ons huis aardig geclusterd ontworpen, inclusief centraal geschakelde stopcontacten voor sfeerverlichting e.d.), bedienen op originele manier blijft mogelijk maar ook geautomatiseerd dingen regelen (bijvoorbeeld op een bewolkte dag) blijft probleemloos mogelijk (dan zet je gewoon 's ochtends even alle bewuste schakelaars aan).

Een Hue lamp wordt binnen 1-2 seconden na het fysiek aanschakelen herkend in het netwerk. Dus een eventuele automatisering via HA wordt met een kleine vertraging uitgevoerd. Daar kan ik prima mee leven. Ik gebruik de diverse states (inclusief "unavailable") voor het activeren van automatiseringen. Zo zal de lichtschakelaar in de slaapkamer, naast het fysiek voeden van de plafondverlichting, ook radio (overdag) of TV en bedlampjes (bedtijd) aanschakelen zodra de state van unavailable naar on gaat.

[RobertMe]

HuismAndré schreef op vrijdag 16 augustus 2024 @ 10:59:
[...]

En precies dat is natuurlijk wat ik bedoel (verderop in mijn verhaal komt dat ook naar voren):

[...]


Ik heb thuis 55 Zigbee lampen die het gros van de tijd geen licht geven. Als ik die allemaal onder spanning zou houden dan zou dat onnodig 10-15W+ aan sluipverbruik toevoegen. Het Hue netwerk wordt door dat aan/uit schakelen niet gesloopt (want dan zou ik deze methode uiteraard niet gebruiken).

Het power-on gedrag stel je zo in dat alles werkt zoals je onder normale omstandigheden mag verwachten (ook handig als Opa en Oma komen oppassen). Alle schakelhardware blijft onveranderd (hebben we bij het ontwerp van ons huis aardig geclusterd ontworpen, inclusief centraal geschakelde stopcontacten), bedienen op originele manier blijft mogelijk maar ook geautomatiseerd dingen regelen (bijvoorbeeld op een bewolkte dag) blijft probleemloos mogelijk (dan zet je gewoon 's ochtends even alle bewuste schakelaars aan).

Een Hue lamp wordt binnen 1-2 seconden na het fysiek aanschakelen herkend in het netwerk. Dus een eventuele automatisering via HA wordt met een kleine vertraging uitgevoerd. Daar kan ik prima mee leven. Ik gebruik de diverse states (inclusief "unavailable") voor het activeren van automatiseringen. Zo zal de lichtschakelaar in de slaapkamer, naast het fysiek voeden van de plafondverlichting, ook radio (overdag) of TV en bedlampjes (bedtijd) aanschakelen zodra de state van unavailable naar on gaat.

Ik persoonlijk vind dat maar een rare "oplossing". Sure, de lampen voegen natuurlijk sluipverbruik toe dus helemaal afschakelen kan om die reden een voordeeltje geven. Maar lampen die "knipperen" omdat ze met de verkeerde state aangaan (leuke wakeup light, eerst op zeg 50% aan, of power on op 1% en dan 's avonds steeds dat de lampen op een zeer zwakke helderheid gaan branden en dan fel gaan branden. Ik heb nu op de slaapkamerdeur het "koelkasteffect" dat ik de eeur open doe en mij afvraag of het licht wel uit was geweest, zo snel gaat het aan). En je moet nu dus (incidenteel) ook het licht aan zetten zodat de automations kunnen werken? Bv 's avonds moet je in de woonkamer als het donker wordt eerst zelf de schakelaar om zetten, immers werkt anders de automation niet.

En schakelaars kun je natuurlijk prima slim maken. Van pulsdrukkers op batterijen die je op de plek van de oude schakelaar hangt tot modules die je achter de bestaande schakelaar plaatst (IIRC heeft Hue er een op batterijen die je puur op de in- en uotgang van de bestaande schakelaar aansluit?).

En v.w.b. energieverbruik. Effectief krijg je dan vaak alsnog dat je 's morgens de schakelaar aan zet en 's avonds uit? Dus de besparing is dan alleen 's nachts? En ik kan op de slaapkamer 's nachts met de knop bij het bed (een deel van) de spotjes (gedimd) aan doen. Dan kan in jou situatie ook niet "want de schakelaar staat uit".

Enige wat jij nu dus hebt is dat de lampen automatisch een scene aannemen, maar aan/uit kunnen ze niet altijd / blijft gedeeltelijk iets dat je zelf doet / moet doen. Daar vind ik, in het totaalplaatje, dan weinig " home automation / smart home" aan. Als ik alsnog elke dag een schakelaar aan/uit moet zetten omdat het anders uberhaupt niet werkt.

Edit:
En als je de lampen in een groep niet individueel aanstuurt kun je net zo goed een slimme schakelaar / relais of dimmer plaatsen, met gewoon domme lampen. Ook nog eens een stuk goedkoper (waardoor het sluip verbruik van de module wel weer meevalt in de totale kosten).

[ Voor 4% gewijzigd door RobertMe op 16-08-2024 11:12 ]

[HuismAndré]

RobertMe schreef op vrijdag 16 augustus 2024 @ 11:10:
[...]

Ik persoonlijk vind dat maar een rare "oplossing". Sure, de lampen voegen natuurlijk sluipverbruik toe dus helemaal afschakelen kan om die reden een voordeeltje geven. Maar lampen die "knipperen" omdat ze met de verkeerde state aangaan (leuke wakeup light, eerst op zeg 50% aan, of power on op 1% en dan 's avonds steeds dat de lampen op een zeer zwakke helderheid gaan branden en dan fel gaan branden. Ik heb nu op de slaapkamerdeur het "koelkasteffect" dat ik de eeur open doe en mij afvraag of het licht wel uit was geweest, zo snel gaat het aan). En je moet nu dus (incidenteel) ook het licht aan zetten zodat de automations kunnen werken? Bv 's avonds moet je in de woonkamer als het donker wordt eerst zelf de schakelaar om zetten, immers werkt anders de automation niet.

In de slaapkamer doen we fysiek het licht aan als we op bed gaan en via Hue button het licht uit als we gaan slapen. Als iemand er 's nachts uit gaat dan gaat het licht aan op 1% (en alleen aan de kant van de button die dan ingedrukt wordt). Dus situaties waarbij je getrakteerd wordt op 100% verlichting midden in de nacht komen niet voor (kwestie van goed nadenken over de inrichting en programmering).

En v.w.b. energieverbruik. Effectief krijg je dan vaak alsnog dat je 's morgens de schakelaar aan zet en 's avonds uit?

Gedeeltelijk. Slaapkamers zijn een goed voorbeeld. Als je de slaapkamer binnenkomt (overdag of 's nachts) dan zet je de lichtschakelaar aan (en verlichting en andere periferie doet wat het moet doen horend bij het dagdeel in kwestie). Ben je de laatste die de slaapkamer verlaat dan zet je de lichtschakelaar uit. Dit vermindert het sluipverbruik van de plafondverlichting met een factor 3 zonder noemenswaardig ongemak. In de huiskamer staat overdag alleen de ringverlichting (centraal geschakelde stopcontacten) en de keukenverlichting fysiek aan. De andere verlichting wordt fysiek alleen aangeschakeld als we gaan eten of als het schemerig wordt (we zijn actief genoeg dat ons dat nog wel lukt). De automatisering kijkt ondertussen of het wel terecht is dat de verlichting brandt (lichtmeting op 2 posities in de huiskamer). Ook daar wordt op deze manier het standby verbruik zeker gehalveerd.

Er zijn ook ruimtes waar we dat aan/uit schakelen maar vervelend vinden (doorloopruimtes bijvoorbeeld). Zo gaat de verlichting in de hal, op de overloop en in de pantry altijd automatisch aan en uit dmv bewegingssensoren (die spaarzame 24/7 gevoede lampen zijn waarschijnlijk een belangrijke backbone voor het Hue netwerk). Idem bij de buitenverlichting boven de voordeur en de achterdeur. We kiezen dus echt selectief waar we volledig ontzorgd willen worden en waar we vinden dat het indrukken van een schakelaar geen onoverkoombare horde is..

[RobertMe]

Laatst stond in de release notes iets dat je templates kon binden aan een device (zodat op de device pagina ook die template entity staat). Maar kan dit ook in de YAML? In de UI zie ik wel een optie ervoor bij het aanmaken van een nieuwe template sensor, maar in de docs zie ik nikd v.w.b. de YAML (enige hit op device is de device_class, en de andere opties lijken er ook niet op).

[TheFes]

RobertMe schreef op vrijdag 16 augustus 2024 @ 12:50:
Laatst stond in de release notes iets dat je templates kon binden aan een device (zodat op de device pagina ook die template entity staat). Maar kan dit ook in de YAML? In de UI zie ik wel een optie ervoor bij het aanmaken van een nieuwe template sensor, maar in de docs zie ik nikd v.w.b. de YAML (enige hit op device is de device_class, en de andere opties lijken er ook niet op).

Nee, kan alleen met GUI created template entities

[RobertMe]

TheFes schreef op vrijdag 16 augustus 2024 @ 12:51:
[...]


Nee, kan alleen met GUI created template entities

...

Enig idee of dat wel op de planning staat? Klinkt nu niet als iets dat alleen via de UI kan omdat....

[TheFes]

RobertMe schreef op vrijdag 16 augustus 2024 @ 12:52:
[...]

...

Enig idee of dat wel op de planning staat? Klinkt nu niet als iets dat alleen via de UI kan omdat....

Reactie van Frenck op vergelijkbare vragen tijdens de beta periode (in het Discord beta channel)

Been looking into this
And then I realized the current UI-only feature is correct
To work with devices, the the entity has to originate from the UI (we need to be able to identify them uniquely from the config entry). When using YAML, that is not the case
so we can't do anything with the device at that point

[RobertMe]

TheFes schreef op vrijdag 16 augustus 2024 @ 14:07:
[...]


Reactie van Frenck op vergelijkbare vragen tijdens de beta periode (in het Discord beta channel)

[...]

Maar... waarom kun je dan wel andere zaken via die UI doen? Ik kan wel de naam, icon, area, labels (, ...?) aanpassen in de UI van een YAML entity. Die moeten dan toch ook (uniek) gelinkt kunnen zijn aan de entry uit de YAML.

En dat lost ook meteen het "hoe weet je device id?" probleem op. Als je via de UI het device instelt kan dat gewoon middels een dropdown.
Of de gebruiker zoekt gewoon ergens anders het device id op en zet die zelf in de YAML. Device triggers in de YAML kun je immers ook kinda alleen maar in de UI maken en dan "Show YAML", en eey, daar staat het device id ook al, dat je dus ook in de YAML zou kunnen gebruiken om een template entity te koppelen aan een device.

And last but not least. Nu is de feature nogal beperkt? Want de entity die ik nu wilde koppelen gebruikt triggers (/"trigger based template"), en die kun je helemaal niet aanmaken in de UI als ik het goed zie?

[TheFes]

RobertMe schreef op vrijdag 16 augustus 2024 @ 14:15:
[...]

Maar... waarom kun je dan wel andere zaken via die UI doen? Ik kan wel de naam, icon, area, labels (, ...?) aanpassen in de UI van een YAML entity. Die moeten dan toch ook (uniek) gelinkt kunnen zijn aan de entry uit de YAML.

En dat lost ook meteen het "hoe weet je device id?" probleem op. Als je via de UI het device instelt kan dat gewoon middels een dropdown.
Of de gebruiker zoekt gewoon ergens anders het device id op en zet die zelf in de YAML. Device triggers in de YAML kun je immers ook kinda alleen maar in de UI maken en dan "Show YAML", en eey, daar staat het device id ook al, dat je dus ook in de YAML zou kunnen gebruiken om een template entity te koppelen aan een device.

And last but not least. Nu is de feature nogal beperkt? Want de entity die ik nu wilde koppelen gebruikt triggers (/"trigger based template"), en die kun je helemaal niet aanmaken in de UI als ik het goed zie?

Geen idee, misschien heeft @Frenck tijd en zin om meer toelichting te geven

[hufkes]

Septillion schreef op maandag 12 augustus 2024 @ 17:55:
@hufkes Volgens mij is het ook wel echt een heftige migratie. Dus als het process ook nog 100% is zou ik het zeker nog wel een dagje aankijken...

Mmm, we zijn nu 5 dagen verder en ik zie op geen enkele wijze verbering in het migratie proces, HA server blijft onbereikbaar (time out). Log file van HA blijft wel appenden met de MQTT berichten die binnenkomen, maar nergens iets van een reactie, ook geen recorder.migration berichten oid.

Met "top" op de synology commandline lijkt het alsof mariaBD wel continu bezig is:

De file NAS_name.Err.1 onder blijft groeien, maar ik haal daar niet uit dat hij daadwerkelijk voortgang maakt?

code:

---TRANSACTION (0x7effcf9c0b80), ACTIVE 401593 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 6, OS thread handle 139636977931968, query id 3246 NAS_Synology 192.168.10.232 home-assistant Statistics
SELECT states_meta.metadata_id, states_meta.entity_id
FROM states_meta
WHERE states_meta.entity_id IN ('input_select.dryer_state_machine')
Trx read view will not see trx with id >= 59630188, sees < 59630181
--------
FILE I/O
--------
Pending flushes (fsync): 0
2528060 OS file reads, 2476660 OS file writes, 87874 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
---
LOG
---
Log sequence number 1293505442913
Log flushed up to   1293505442913
Pages flushed up to 1293505243762
Last checkpoint at  1293505243762
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 50331648
Dictionary memory allocated 182616
Buffer pool size   994
Free buffers       0
Database pages     256
Old database pages 0
Modified db pages  254
Percent of dirty pages(LRU & free pages): 98.833
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 1, flush list 0
Pages made young 91921, not young 2681770
0.00 youngs/s, 0.00 non-youngs/s
Pages read 2527933, created 132291, written 2418503
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 256, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
8 read views open inside InnoDB
state: sleeping
----------------------------
END OF INNODB MONITOR OUTPUT
============================

Kan het zijn dat de migratie echt nog bezig is, of loopt hij ergens op vast? Wat zou er gebeuren als ik de docker container gewoon stop en opnieuw start?

De WAF factor is gedaald tot een absoluut dieptepunt... Ik zou het prima vinden wanneer alle historische data weg zou zijn, maar nog langer een niet werkend HA systeem dat kan echt niet

[oltk]

hufkes schreef op vrijdag 16 augustus 2024 @ 18:42:
[...]

De WAF factor is gedaald tot een absoluut dieptepunt... Ik zou het prima vinden wanneer alle historische data weg zou zijn, maar nog langer een niet werkend HA systeem dat kan echt niet

Beetje mosterd na de maaltijd. Maar als je het weer up and running hebt zou ik (als ik jou was) investeren in een herstelplan voor calamiteiten zoals dit. Denk aan:
- een backup van HA
- een complete backup van jouw docker container / VM etc
- een backup van je database
én
- reserve hardware. Denk hierbij aan een reserve apparaat waarop je HA kan draaien, als jouw normale apparaat ineens de geest heeft gegeven en mogelijk een Zigbee coordinator (zelfde type als wat je nu hebt draaien)

Been there. Seen that. En helaas: done that.

Edit: Kan je bij jouw configuration.yaml?
Je kan overwegen om de verwijzing naar jouw database weg te halen en opnieuw te starten? vertrekkende van de veronderstelling dat de migratie van jouw huidige database niet meer spontaan afgerond wordt. Die is corrupt geraakt. Overigens: dit heb ik niet zelf ooit getest, dus geheel zonder enige kennis van zaken wat er gebeurt.

Edit2: ik heb ook afgeleerd meteen de nieuwe versie te installeren. Ik wacht tot .2 of .3 uit is. In sommige gevallen wacht ik een hele maand als ik het niet vertrouw. Ook al kan ik vrij snel een backup terugzetten: ik zit er niet op te wachten.

[ Voor 27% gewijzigd door oltk op 16-08-2024 20:16 ]

[brogel]

Na al de eerdere berichten over zigbee hier wil ik daar toch ook eens van gebruik gaan maken.
Welke USB stick raden jullie aan?

[RobertMe]

brogel schreef op vrijdag 16 augustus 2024 @ 23:22:
Na al de eerdere berichten over zigbee hier wil ik daar toch ook eens van gebruik gaan maken.
Welke USB stick raden jullie aan?

Welke software wil je gaan gebruiken? Deconz werkt alleen met de Conbee. ZHA geeft voorkeur aan (/werkt beter met?) de Silicon labs gebaseerde sticks zoals de SkyConnect (van Nabu Casa aka "HA zelf") of Sonoff E. Zigbee2mqtt werkte tradiitoneel altijd met Texax Instruments sticks (zoals de Sonoff P), de Silicon Labs chips (SkyConnect & Sonoff E bv dus) zijn lang experimental geweest, maar ik meen dat dat intussen niet meer zo is?

En dan nog de vraag: wil je uberhaupt een USB stick? Er is ook een oplossing die je zowel via USB, ethernet (incl. Power over Ethernet) als wifi (niet aan te raden gok ik) kunt gebruiken. En die is ook nog eens beschikbaar in 2 uitvoeringen voor of de Texas Instruments chip, of de Silicon Labs chip.

Zelf altjid Zigbee2mqtt gebruikt, "tegenwoordig" met een Sonoff P. Zou ik nu een moeten kopen zou ik zeer serieus die via ethernet overwegen.

[Clumsy Smurf]

Er is een nieuwe update uit, 2024.8.2
Hiermee is bij mij de Daikin-integratie (lokale verbonden) hersteld.
Volgens mij waren er hier meer die er problemen mee hadden.
link

[ Voor 22% gewijzigd door Clumsy Smurf op 17-08-2024 07:42 ]

[Uberprutser]

Septillion schreef op donderdag 21 september 2023 @ 09:48:
Als je NSPanel HA Blueprint draait zoals hierboven kan je dat dus gewoon doen door een actie te maken. Op zich mag fallback dan wel aan blijven als je wilt maar bij geen Wifi zal het dan anders reageren (push = direct relais).

Mijn eerste NSPanel was "ontploft" kort na mijn vraag en een paar weken terug 2 nieuwe gekocht en nog maar een poging gewaagd. Ontwikkeling van de blueprint is echt een hele vooruitgang; eerst lukte het mij niet om ble tracker actief te krijgen, geheugen issues, zodat ik mijn M5Stack Atoms kon weg doen. Nu zijn beide NSPanels een ble bridge en heb ik de Atoms niet meer nodig. Die hingen aan een korte USB kabel met een adapter op zichtbare plaatsen. Niet zoals je het wil hebben ondanks dat de WAF hier in huis geen ding is. Ander voordeel is dat mijn ble sensors opeens langer met hun batterijen doen. Na een maand nog steeds 100%. Kan toeval zijn maar firmware van de sensoren heb ik niet aangepast in de tussentijd.

Enige wat niet soepel gaat is updaten van ESP Home met het NSPanel. Eerst ESP Home, dan device, dan blueprint en daarna nog eens TFT. Misschien kan dit makkelijker maar zover ben ik nog niet gekomen.

Vandaag eens een schema maken wat ik allemaal nog wil toevoegen aan HA en ga vanaf scratch beginnen. Gisteren een extra HA aangemaakt om dingen uit te proberen. Genoeg halve projecten liggen en maar eens een plan maken om het allemaal werkend te krijgen.

[Devke]

Nieuwe ronde nieuwe kansen, Ik probeer met onderstaande code een sensor te maken die omzettingsverlies van een thuisbatterij uitdrukt in euro's

YAML:

# Maken van een eigen sensor waarin de omzettingsverlies kosten van een
# TB staan opgeslagen in euros
template:
  variables:
  - name: TerugLeverBoete
    value: "0,11"
  - sensor:
    - name: OmzettingsverliesKosten
      unique_id: berekenomzettingsverlies_var
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set OMZETTINGSVERLIESkWh = states('sensor.omzettingsverlies')|float %}
        {% set BOETE = TerugLeverBoete | float %}
        {{ (OMZETTINGSVERLIESkWh * BOETE) | round(2) }}

Ben echt een beginner en moet het hebben van zoeken op HA site hoe je iets zou kunnen programmeren.
Ik krijg binnen de test omgeving (ontwikkelingstools) de foutmelding:

UndefinedError: 'TerugLeverBoete' is undefined

Ik doe toch iets niet goed. Wat?

[brogel]

RobertMe schreef op zaterdag 17 augustus 2024 @ 00:02:
[...]

Welke software wil je gaan gebruiken? Deconz werkt alleen met de Conbee. ZHA geeft voorkeur aan (/werkt beter met?) de Silicon labs gebaseerde sticks zoals de SkyConnect (van Nabu Casa aka "HA zelf") of Sonoff E. Zigbee2mqtt werkte tradiitoneel altijd met Texax Instruments sticks (zoals de Sonoff P), de Silicon Labs chips (SkyConnect & Sonoff E bv dus) zijn lang experimental geweest, maar ik meen dat dat intussen niet meer zo is?

En dan nog de vraag: wil je uberhaupt een USB stick? Er is ook een oplossing die je zowel via USB, ethernet (incl. Power over Ethernet) als wifi (niet aan te raden gok ik) kunt gebruiken. En die is ook nog eens beschikbaar in 2 uitvoeringen voor of de Texas Instruments chip, of de Silicon Labs chip.

Zelf altjid Zigbee2mqtt gebruikt, "tegenwoordig" met een Sonoff P. Zou ik nu een moeten kopen zou ik zeer serieus die via ethernet overwegen.

Bedankt voor de uitgebreide uitleg!
Is er een voordeel tussen beide versies,TI of SL en Zigbee2MQTT of ZH?
Ethernet is zeker een meerwaarde omdat de HA server in de kelder staat, dus via ethernet naar boven komen is een meerwaarde.

Ik kijk nu bijvoorbeeld naar de 'SLZB-06p7', op Zigbee2MQTT.
is dit iets goed? Of raad je een andere aan?

Ik had ook begrepen dat meerdere ZB sticks mogelijk is? Dus kan eventueel in de kelder een extra stick in de server steken voor de apparaten in de kelder.
Heb je misschien een advies voor een simpele USB versie?

[RobertMe]

brogel schreef op zaterdag 17 augustus 2024 @ 13:47:
Is er een voordeel tussen beide versies,TI of SL en Zigbee2MQTT of ZH?

Verschillen in de soorten/merken chips durf ik niet te zeggen, behalve dat software support. ZHA vs Zigbee2mqtt: ZHA is denk ik makkelijker, doordat het volledig geïntegreerd zit in HA ("core"). Zigbee2mqtt is losse software, waarbij je ook nog eens een MQTT broker nodig hebt. Grootste voordeel van Z2M is wel dat deze (veel) meer apparaten ondersteund en normaliter ook sneller ondersteund.

Ethernet is zeker een meerwaarde omdat de HA server in de kelder staat, dus via ethernet naar boven komen is een meerwaarde.

Evt kun je dat ook met een USB verlengkabel bereiken. En het gebruik daarvan valt sowieso aan te raden omdat USB poorten zo nu en dan wat verstoring geven op de RF signalen van Zigbee. Een USB verlengkabel van een paar CM lost dat al op. Zelf heb ik mijn HA systeem ook in de kelder staan, maar wel onder de trap, met 2x een 3m USB verlengkabel waardoor de Zigbee en ZWave stick effectief in hoogte bijna tegen het plafond van de beneden verdieping hangen.

Ik kijk nu bijvoorbeeld naar de 'SLZB-06p7', op Zigbee2MQTT.
is dit iets goed? Of raad je een andere aan?

Zo op het eerste gezicht lijkt dat in de basis die te zijn wat ik bedoelde, met ethernet en al. Het specifieke model (TI vs SL chip) moet je dan zelf even kijken. Volgens mij zijn er in dit op in het Z2M topic hier op het forum ook wel wat ervaringen te vinden met deze stick (het "merk" dan).

Ik had ook begrepen dat meerdere ZNB sticks mogelijk is? Dus kan eventueel in de kelder een extra stick in de server steken voor de apparaten in de kelder.
Heb je misschien een advies voor een simpele USB versie?

Zigbee (en ZWave) werken op basis van mesh. Elk apparaat dat op 230V is aangesloten (lampen, tussenstekkers, ...) werken daardoor als repeater/router. Bereik is uiteindelijk dus een non issue, zolang je onderweg maar voldoende repeaters/routers/230V apparaten hebt. Twee sticks als in controllers valt daardoor ook af te raden. Je creëert dan twee netwerken die langs elkaar door werken en dus ook 2 aparte "mesh netwerken" (waardoor je in beide netwerken dus voldoende repeaters/routers moet hebben). Wat eventueel wel kan, als je niet voldoende repeaters/routers hebt is een stick (de USB varianten van TI kunnen dit AFAIK sowieso met een andere firmware, die ethernet variant mogelijk ook) gebruiken als router. De stick gedraagt zich dan puur als een repeater/router om de signalen door te geven maar heeft geen functie v.w.b. de aansturing (je configureert deze niet in Z2M of zo, als zijnde "de USB stick", dat kan dan ook niet). Deze stick kun je dan ook gewoon in een USB (power) adapter (lees: telefoonlader/...) steken, ergens in het stopcontact stoppen, en joinen in je netwerk zoals je met elk Zigbee apparaat doet. En dan doet die dus het bereik uitbreiden. Maar dat is dus alleen nodig als je niet genoeg apparaten hebt die als router dienst doen, dus niet genoeg Zigbee lampen / tussenstekkers /inbouwmodules/... (/alles op Zigbee dat op 230V is aangesloten i.p.v. een batterij).

[Septillion]

@Devke Ook al is het een leuk idee, variables is geen onderdeel van een template sensor...

Ook altijd of een default aan een float-filter toevoegen of zorgen voor goede availability

YAML:

template:
  - sensor:
      name: Omzettingsverlies Kosten
      unique_id: omzettingsverlies_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set verlies = states('sensor.omzettingsverlies')|float %}
        {% set boete = 0.11 %}
        {{ (verlies * boete) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

Enige is nog, ik zie geen verband tussen omzetverlies en terugleverboete? Of is een naam wat onhandig gekozen?

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 14:19:
@Devke Ook al is het een leuk idee, variables is geen onderdeel van een template sensor...

Ook altijd of een default aan een float-filter toevoegen of zorgen voor goede availability

YAML:

template:
  - sensor:
      name: Omzettingsverlies Kosten
      unique_id: omzettingsverlies_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set verlies = states('sensor.omzettingsverlies')|float %}
        {% set boete = 0.11 %}
        {{ (verlies * boete) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

Enige is nog, ik zie geen verband tussen omzetverlies en terugleverboete? Of is een naam wat onhandig gekozen?

Thnx. Klopt je hebt gelijk. Omzettingsverlies zie ik als "weggegooide kWh's" om de batterij te vullen. Als ik die kWh's het net ingepompt had dan had ik er nog een vergoeding voor gehad. Dus gooi die eigenlijk ook weg nu. Naam misschien niet handig gekozen maar wellicht nu wat duidelijker 😊.

[Septillion]

@Devke Ahh, zo. Dan is de term "boete" de verwarrende, zou ik daar gewoon "terugleververgoeding" schrijven.

[Gynnad]

Ik zit al even te stoeien, maar ik krijg het maar niet voor elkaar - ik wil graag als een chip laten zien indien er afval binnen 7 dagen wordt opgehaald, bijv. hieronder voor PMD, echter werkt de conditie niet - het maakt niet uit welke waarde ik invoer het heeft geen effect.

Ik zou sensor.eerstvolgende kunnen gebruiken - maar vind die weergave net een stukje minder. Iemand hoe enig idee hoe ik het voor elkaar zou kunnen krijgen om zoiets te krijgen als 'PMD over 3 dagen' en alleen getoond indien dit binnen 7 dagen is?

YAML:

type: custom:mushroom-chips-card
chips:
  - type: conditional
    conditions:
      - condition: numeric_state
        entity: sensor.pmd
        below: 7
    chip:
      type: entity
      entity: sensor.pmd
      icon: mdi:recycle
      use_entity_picture: false

[Septillion]

@Gynnad Bevat sensor.pmd wel alleen een getal? Volgens mij bevat het bij de meeste integraties dan een datum. Dus dan kan je niet simpelweg zeggen dat die kleiner dan 7 moet zijn.

Wel hebben bij mij de afval-entiteiten een Days_until attribute met aantal dagen tot ophalen. Helaas ondersteund zowel de conditional chip-card als de standaard conditional card als de visibility option niet om state of numeric state op een attribute te doen.

Dan zal je dus moeten zorgen met bijvoorbeeld een template sensor dat aantal dagen tot ophalen werkelijk in de state van een entity staat.

[Gynnad]

Septillion schreef op zaterdag 17 augustus 2024 @ 15:28:
@Gynnad Bevat sensor.pmd wel alleen een getal? Volgens mij bevat het bij de meeste integraties dan een datum. Dus dan kan je niet simpelweg zeggen dat die kleiner dan 7 moet zijn.

Wel hebben bij mij de afval-entiteiten een Days_until attribute met aantal dagen tot ophalen. Helaas ondersteund zowel de conditional chip-card als de standaard conditional card als de visibility option niet om state of numeric state op een attribute te doen.

Dan zal je dus moeten zorgen met bijvoorbeeld een template sensor dat aantal dagen tot ophalen werkelijk in de state van een entity staat.

Standaard spuugt ie inderdaad een datum uit, hij heeft inderdaad wel de Days_until, maar die kun je dus niet direct gebruiken, dat is jammer.

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 14:46:
@Devke Ahh, zo. Dan is de term "boete" de verwarrende, zou ik daar gewoon "terugleververgoeding" schrijven.

Hele stuk code bijna af. Echter hij geeft binnen HA de volgende foutmelding:



als ik de volgende code weg haal bij ontwikkelingstool binnen HA gaat het goed:

YAML:

# Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
template:
  - sensor:
    - name: Gemiste TLV
      unique_id: gemiste_TLV
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

Zie jij het foutje? Aparte is dat na herstart van HA dat er in de logfiles geen fouten zijn en dat er ook geen sensoren erbij aangemaakt zijn. Ja ik heb de juiste configuration.yaml nu aangepast. Dubbelcheck gedaan

[ Voor 54% gewijzigd door Devke op 17-08-2024 16:09 ]

[Septillion]

@Devke Je error is over "omzettingsverlies" maar daar toon je geen yaml van.

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 16:32:
@Devke Je error is over "omzettingsverlies" maar daar toon je geen yaml van.

My mistake. Ik laat de hele configuration.yaml wel zien. Zijn een paar regels extra. Daarin staat de uitbreiding ook m.b.t. je vanmiddag al een keer op gereageerd hebt.

YAML:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template:
  - sensor:
    - name: Omzettingsverlies
      unique_id: doorreken_var
      unit_of_measurement: "kWh"
      device_class: energy
      state: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out')|float %}
        {{ (TARGET - SOURCE) | round(2) }}
      availability: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in') %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out') %}
        {{ TARGET |is_number and SOURCE }}
        # Bereken de bespaarde terugleverboete door de batterij plaatsing
template:
  - sensor:
    - name: BespaardeTLB
      unique_id: Bespaarde_TLB
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set geladen_kWh_Bat = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set TLB = 0.1015 %}
        {{ (geladen_kWh_Bat * TLB) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_energy_in')|is_number }}

# Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
template:
  - sensor:
    - name: Gemiste TLV
      unique_id: gemiste_TLV
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

# Bereken de afschrijvingskosten op basis van het aantal cycli uitgevoerd
template:
  - sensor:
    - name: Afschrijvings Kosten
      unique_id: afschrijvings_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set aantal_cycli_verbruikt = states('sensor.battery_sim_hw_battery_cycles')|float %}
        {% set cycli_kosten = 0.235 %}
        {{ (aantal_cycli_verbruikt * cycli_kosten) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_cycles')|is_number }}

Haal ik de code weg m.b.t. gemiste_TLV dan krijg ik onderstaande, wat me opvalt is dat bij Availability nu een getal staat ipv True:

[ Voor 8% gewijzigd door Devke op 17-08-2024 16:47 ]

[Septillion]

@Devke Op elk niveau mag een key maar één keer voorkomen (tenzij het in een list gestopt is, dus vooraf gegaan wordt door een - ). Dus op root mag je maar 1x template: hebben staan. Alle sensoren komen daar als list onder.

En bij "omzettingsverlies' check je alleen TARGET of het netjes een nummer is, voor SOURCE vergeet je dat.

Ik meen dat een unique id geen hoofdletters mag bevatten maar zeker doe ik dat even niet meer.

Als laatste wel even checken of het entity id van "Omzettingsverlies" werkelijk sensor.omzettingsverlies geworden is. Normaal doet HA dat op basis van de naam maar als er al een andere bestaat ofzo kan het een andere naam kiezen.

Krijg je:

YAML:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template:
  - sensor:
      name: Omzettingsverlies
      unique_id: omzettingsverlies
      unit_of_measurement: "kWh"
      device_class: energy
      state: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out')|float %}
        {{ (TARGET - SOURCE) | round(2) }}
      availability: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in') %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out') %}
        {{ TARGET |is_number and SOURCE|is_number }}
        # Bereken de bespaarde terugleverboete door de batterij plaatsing

  - sensor:
      name: BespaardeTLB
      unique_id: bespaarde_tlb
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set geladen_kWh_Bat = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set TLB = 0.1015 %}
        {{ (geladen_kWh_Bat * TLB) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_energy_in')|is_number }}

  # Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
  - sensor:
      name: Gemiste TLV
      unique_id: gemiste_tlv
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

  # Bereken de afschrijvingskosten op basis van het aantal cycli uitgevoerd
  - sensor:
      name: Afschrijvings Kosten
      unique_id: afschrijvings_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set aantal_cycli_verbruikt = states('sensor.battery_sim_hw_battery_cycles')|float %}
        {% set cycli_kosten = 0.235 %}
        {{ (aantal_cycli_verbruikt * cycli_kosten) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_cycles')|is_number }

Nu mag je onder sensor: ook meerdere sensors hangen maar dan heb je nu eigenlijk een dubbele lijst. Daarom zet ik die dan ook niet in een list.

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 16:59:
@Devke Op elk niveau mag een key maar één keer voorkomen (tenzij het in een list gestopt is, dus vooraf gegaan wordt door een - ). Dus op root mag je maar 1x template: hebben staan. Alle sensoren komen daar als list onder.

En bij "omzettingsverlies' check je alleen TARGET of het netjes een nummer is, voor SOURCE vergeet je dat.

Ik meen dat een unique id geen hoofdletters mag bevatten maar zeker doe ik dat even niet meer.

Als laatste wel even checken of het entity id van "Omzettingsverlies" werkelijk sensor.omzettingsverlies geworden is. Normaal doet HA dat op basis van de naam maar als er al een andere bestaat ofzo kan het een andere naam kiezen.

Krijg je:

YAML:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template:
  - sensor:
      name: Omzettingsverlies
      unique_id: omzettingsverlies
      unit_of_measurement: "kWh"
      device_class: energy
      state: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out')|float %}
        {{ (TARGET - SOURCE) | round(2) }}
      availability: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in') %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out') %}
        {{ TARGET |is_number and SOURCE|is_number }}
        # Bereken de bespaarde terugleverboete door de batterij plaatsing

  - sensor:
      name: BespaardeTLB
      unique_id: bespaarde_tlb
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set geladen_kWh_Bat = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set TLB = 0.1015 %}
        {{ (geladen_kWh_Bat * TLB) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_energy_in')|is_number }}

  # Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
  - sensor:
      name: Gemiste TLV
      unique_id: gemiste_tlv
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

  # Bereken de afschrijvingskosten op basis van het aantal cycli uitgevoerd
  - sensor:
      name: Afschrijvings Kosten
      unique_id: afschrijvings_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set aantal_cycli_verbruikt = states('sensor.battery_sim_hw_battery_cycles')|float %}
        {% set cycli_kosten = 0.235 %}
        {{ (aantal_cycli_verbruikt * cycli_kosten) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_cycles')|is_number }

Nu mag je onder sensor: ook meerdere sensors hangen maar dan heb je nu eigenlijk een dubbele lijst. Daarom zet ik die dan ook niet in een list.

Die omzettingssensor bestond al. Dat hele stukje code mbt SOURCE en TARGET was al weken werkende bestaande code namelijk.

Wat ik gedaan heb vandaag is de nieuwe code eronder geplakt in de configuration.yaml
Daarna HA opnieuw gestart om dat bestand opnieuw te laden. Ik ga de boel checken en de code overnemen zoals jij hem er nu hebt staan. Weer wat geleerd. Dankjewel!

Er zit alleen nog een UNEXPECTED } in. Lol. Ding houdt je bezig ;-P

[Septillion]

@Devke Kan wel zijn dat je al weken het stukje had, maar goed werken deed het niet

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 17:39:
@Devke Kan wel zijn dat je al weken het stukje had, maar goed werken deed het niet

Kijk. Hier doet ie het goed mijn inzien 😊

[ Voor 3% gewijzigd door Devke op 17-08-2024 18:10 ]

[Ortep]

Op de eindeloze weg van automatiseringen ben ik ook begonnen met het open en dicht doen van mijn lamellen. Daar heb ik de volgende motor voor:
https://moeshouse.com/pro...in-motorized-blinds-motor

Pairen met z2m ging prima, bedienen ook.
Ik kan de minimum postie aanpassen en ook de maximum. Alles kan open en dicht.

Wat ik alleen onhandig vind is dat 0% helemaal dicht is, maar 100% ook, maar dan de andere kant op.
Ze zijn maximaal open bij 50%

Ik kan nu roepen: He Google, lamellen dicht, open of half dicht. Maar ja, de ene dicht is dicht, de open is ook dicht, en de half dicht is open.

Is er een methode om aan di posities namen te geven? BV:

0% -> Links
50% -> Open
100% -> Rechts

Ik heb al aan scripts gedacht die die namen hebben. Maar dat vind ik onhandig met de integratie met Google Home

Maar dan moet ik iets roepen van He Google activeer Lamellen Links. Ik snap dat zelf wel, maar anderen kunnen daar wat meer moeite mee hebben.

Een andere optie is maar de ene helft te gebruiken. Dus wat nu 0->50 is te begrenzen als min en mag. Dan kan je open en dicht gebruiken. Maar dan kan je niet de lamellen de andere kant op zetten.

[ Voor 9% gewijzigd door Ortep op 17-08-2024 20:31 ]

[hufkes]

oltk schreef op vrijdag 16 augustus 2024 @ 20:01:
[...]

Beetje mosterd na de maaltijd. Maar als je het weer up and running hebt zou ik (als ik jou was) investeren in een herstelplan voor calamiteiten zoals dit. Denk aan:
- een backup van HA
- een complete backup van jouw docker container / VM etc
- een backup van je database
én
- reserve hardware. Denk hierbij aan een reserve apparaat waarop je HA kan draaien, als jouw normale apparaat ineens de geest heeft gegeven en mogelijk een Zigbee coordinator (zelfde type als wat je nu hebt draaien)

Been there. Seen that. En helaas: done that.

Edit: Kan je bij jouw configuration.yaml?
Je kan overwegen om de verwijzing naar jouw database weg te halen en opnieuw te starten? vertrekkende van de veronderstelling dat de migratie van jouw huidige database niet meer spontaan afgerond wordt. Die is corrupt geraakt. Overigens: dit heb ik niet zelf ooit getest, dus geheel zonder enige kennis van zaken wat er gebeurt.

Edit2: ik heb ook afgeleerd meteen de nieuwe versie te installeren. Ik wacht tot .2 of .3 uit is. In sommige gevallen wacht ik een hele maand als ik het niet vertrouw. Ook al kan ik vrij snel een backup terugzetten: ik zit er niet op te wachten.

Haha, ik heb gelukkig wel goede backups en alles, (afgezien van een werkende 2e zigbee stick dan, een SMLIGHT SLZB-06 staat nog de verlanglijst) dus dat is het probleem niet. Wel een probleem is het wanneer agv een reguliere update je hele HA onderuit gaat, en je dan volgens het verhaal maar heel veel geduld moet hebben! Wat ik niet begrijp is dat een migratie zo ingrijpend zou moeten zijn? Waarom niet eerst een kopie maken en als dat gelukt is pas overschakelen? Dan mag het zelfs dagen duren en kun je bij evt problemen alsnog blijven werken.

En dan kiezen ze voor een proces met 0,0 feedback dat er ook nog eens voor zorgt dat je huis niet meer werkt zoals voor de update. Als je weet dat een dergelijk migratie mss wel meerdere dagen in beslag neemt, dan ga je toch niet zomaar zonder daar duidelijk over te zijn de boel platgooien? Geen mogelijkheid om uit te stellen of over te slaan.

Beetje jammer, want zo'n bijzondere opstelling heb ik helemaal niet volgens mij, een redelijk nieuwe synology NAS, HA & MQTT in docker en native MariaDd voor de data. Dat werd toen ik met HA begon duidelijk geadviseerd ivm corruptie van de de standaard SQL oplossing. Ofwel er is iets heel bijzonders met mijn gegevens, ofwel deze opstelling is nooit getest. Heb ik de migratie uberhaupt echt nodig? Op basis waarvan, ik zit nog lang niet aan max INT aantal regels in enige tabel, en dan kun je ook nog met purge zorgen dat dat geen probleem wordt... En als ik dan wil afbreken cq. opnieuw opstarten dan wordt dat tegengehouden omdat de migratie nog loopt... ja hè hè..

Inmiddels heb ik dus na 6 dagen "wachten" de boel afgebroken en weer hersteld, maar nergens een idee of logregel die aangeeft waarom het fout ging. Geen terugkoppeling anders dan dat hij aan de tabel state_attribute is begonnen en daar dus na al die tijd nog niet mee klaar is. Geen handleiding om e.e.a. igv problemen zelf na te lopen of met een paar SQL opdrachten buiten HA om te regelen. Geen manier om te kijken of hij nu op bv. 3% of 98% was. Geen checks vooraf of beschikbaar memory irt de hoeveelheid dat bv een slecht plan is. Gewoon jammer en m.i. geen weldoordachte keuze. Bij een echt bedrijf met niet techsavy klanten zou dit echt tot onmiddellijke leegloop van klanten leiden.

Overigens, met 2024.08.2 lijkt HA in safe mode niet meer zo compleet vast te lopen als voorheen, die blijft nu enigszins bruikbaar zodat basis functionaliteit zoals lampen weer werken.

Oh en ja, ik kan gelukkig prima bij alle configuratiebestanden, maar een ouder docker image terugzetten werkte ook gewoon.

[einde rant]
Maar goed, ook met de 08.2 dus nog geen échte oplossing

[Vaevictis_]

Septillion schreef op vrijdag 16 augustus 2024 @ 07:56:
@Get!em Inderdaad, mythe. Hier routen alle Ikea lampen prima en heb ook al jaren een sloot Aqara temperatuur sensoren. Mijn coördinator (CC2652RB op Z2M) hangt ook in de kelderkast maar lampen op zolder en achter in de tuin werken prima.

Zijn inderdaad wel wat uitzonderingen (was het niet Innr of Osram die alleen devices van zichzelf wil routen) maar gros is gewoon router.

Sonoff zbmini extreme (zonder n) is een endpoint device flink balen want heb er een aantal van.

[Septillion]

@Devke maar je availability template rendert dus geen false als alleen je source geen getal is geworden. Die moet daar dus ook een is_number op om het netjes af te vangen.

[Pejdref]

Ortep schreef op zaterdag 17 augustus 2024 @ 20:29:
Op de eindeloze weg van automatiseringen ben ik ook begonnen met het open en dicht doen van mijn lamellen. Daar heb ik de volgende motor voor:
https://moeshouse.com/pro...in-motorized-blinds-motor

Pairen met z2m ging prima, bedienen ook.
Ik kan de minimum postie aanpassen en ook de maximum. Alles kan open en dicht.

Wat ik alleen onhandig vind is dat 0% helemaal dicht is, maar 100% ook, maar dan de andere kant op.
Ze zijn maximaal open bij 50%

Ik kan nu roepen: He Google, lamellen dicht, open of half dicht. Maar ja, de ene dicht is dicht, de open is ook dicht, en de half dicht is open.

Is er een methode om aan di posities namen te geven? BV:

0% -> Links
50% -> Open
100% -> Rechts

Ik heb al aan scripts gedacht die die namen hebben. Maar dat vind ik onhandig met de integratie met Google Home

Maar dan moet ik iets roepen van He Google activeer Lamellen Links. Ik snap dat zelf wel, maar anderen kunnen daar wat meer moeite mee hebben.

Een andere optie is maar de ene helft te gebruiken. Dus wat nu 0->50 is te begrenzen als min en mag. Dan kan je open en dicht gebruiken. Maar dan kan je niet de lamellen de andere kant op zetten.

Je kunt automatiseringen maken die op bepaalde woorden/zinnen reageren (als trigger), is dat iets waar je het mee kunt oplossen?

[Devke]

Septillion schreef op zaterdag 17 augustus 2024 @ 21:18:
@Devke maar je availability template rendert dus geen false als alleen je source geen getal is geworden. Die moet daar dus ook een is_number op om het netjes af te vangen.

Inmiddels werkt het zover ik tot nu toe wens. Zal een screen hieronder plakken. Het gaat met name om het financiële gedeelte dus.

Zie net dat het euro teken achter het getal staat haha. Valt me nu pas op 🙈

Wederom dank voor je hulp en uitleg!

[ Voor 4% gewijzigd door Devke op 17-08-2024 21:30 ]

[Ortep]

Pejdref schreef op zaterdag 17 augustus 2024 @ 21:27:
[...]


Je kunt automatiseringen maken die op bepaalde woorden/zinnen reageren (als trigger), is dat iets waar je het mee kunt oplossen?

Aan zoiets had ik al gedacht. Ik noemde al de scripts met de juiste namen. Maar dan moet ik in de Google home app een script activeren dat dan de juiste dingen doet. En dan daar ook de juiste key words in zetten.

Het voelt gammel om op meerdere plaatsen dat te gaan moeten regelen.

Ik vind het vreemd dat daar geen standaard oplossing voor is.

Dit speelt bij iedere vorm van lamellen. Vertikaal of horizontaal.

Twee kanten zijn dicht, het midden is open.

[Mylotec]

Hellow,

Heb in een slaapkamer een airco toestel hangen van Innova. Heb deze geïntegreerd in HA.
Nu wens ik de setpoint in te stellen via node red maar weet niet goed hoe ik dit moet doen.
Er is geen 'kant en klare" entity ID waarmee ik de temperatuur kan instellen.

Bedoeling is om via KNX de temperatuur (en al de rest) te kunnen instellen.

Als ik naar ontwikkel hulpmiddelen -> acties -> zoek naar climate zie ik het volgende

Kan er mij iemand helpen hoe ik deze kan koppelen in node red?

[ Voor 26% gewijzigd door Mylotec op 18-08-2024 01:59 ]

[Septillion]

Devke schreef op zaterdag 17 augustus 2024 @ 21:29:
[...]
Zie net dat het euro teken achter het getal staat haha. Valt me nu pas op 🙈

Ja, het is de standaard voor HA om unit of measurement er altijd achter te zetten. Wat dat betreft is geld een vreemde eend in de bijt.

Als het je echt stoort zou je een attribute met "mooie weergave" toe kunnen voegen. Iets als:

YAML:

# Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
  - sensor:
      name: Gemiste TLV
      unique_id: gemiste_tlv
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}
      attributes:
        pretty: >-
          € {{ this.state|replace('.', ',') if this.state|is_number else '-' }}

En op je dashboard geef je dan het attribute weer.

YAML:

type: entities
entities:
  - type: attribute
    entity: sensor.gemiste_tlv
    attribute: pretty

[Septillion]

@Mylotec Als het goed is heb je daar een "call service" node voor waarmee je dan climate.set_temperature mee kan aanroepen.

Voor diepere NodeRed vragen zie dan Node-RED - grafisch 'programmeren' (bijv. voor domotica).

[Faece]

Heeft iemand ervaring met het afspelen van een spotify playlist ?
ik maakte bij devtools actions deze code aan.

[quote]

YAML:

action: spotcast.start
data:
  limit: 20
  force_playback: false
  random_song: false
  repeat: "off"
  shuffle: false
  offset: 0
  ignore_fully_played: false
  entity_id: media_player.ruimte1
  uri: spotify:playlist:37i9dQZF1DWWn9pcJIAKFl
  country: BE
  start_volume: 40
 

maar ik krijg deze error te zien

Failed to perform the action spotcast.start. Could not find spotify media player.

ik heb spotify connect bij add-ons geinstalleerd en ook de spotify integration

[Septillion]

@hufkes Ik zie dat in 2024.8.2 ook weer een DB migratie fix zit. Misschien dat als je backup terug uitrolt en dan direct een update naar 8.2 probeert dat het dan nu wel gaat?

[AWEF]

Voor de mensen die een Ecoflow device in HA hebben zitten, er schijnt een issue te zijn met de hassio-ecoflow-cloud integratie (via HACS). Er loopt een issue op de git pagina (https://github.com/tolwi/hassio-ecoflow-cloud/issues/283). Het issue lijkt in eerste instantie te gaan over de Delta Pro maar lijkt alle ondersteunde devices te raken. Ik heb zelf een PowerStream en deze vertoont hetzelfde gedrag.

[hufkes]

Septillion schreef op zondag 18 augustus 2024 @ 12:27:
@hufkes Ik zie dat in 2024.8.2 ook weer een DB migratie fix zit. Misschien dat als je backup terug uitrolt en dan direct een update naar 8.2 probeert dat het dan nu wel gaat?

Heb ik gedaan en staat al weer een volle dag te rammelen, lijkt niet dat het beter gaat. Mijn .Err log-file is zo langzamerhand groter dan de datafiles...

Iemand die hier nog iets zinnigs uit kan halen? Het lijkt mij "gewone" log-items te zijn? Iets van SBFspot, een query van DBeaver vanaf mijn PC, iets van de plug van de wasmachine.
Maar dan ook nog zaken mbt die migratie over BIGINT? Het lijkt dus naar mijn idee dat hij toch wel bezig is, maar compleet onduidelijk voor mij on te zien of er ook voortgang is.

code:

------------
TRANSACTIONS
------------
Trx id counter 59630574
Purge done for trx's n:o < 59630571 undo n:o < 0 state: running
History list length 50
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 59630573, ACTIVE 75919 sec inserting
mysql tables in use 1, locked 1
1 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 39, OS thread handle 140079423436480, query id 20591 NAS_Synology 192.168.10.232 SBFspotUser Update
INSERT IGNORE INTO Inverters VALUES(3005988527,'SB3.6-1AV-41 527','Sunny Boy 3.6','04.01.15.R',0,0,0,0,0,0,'','',0)
---TRANSACTION (0x7f66d81c6880), ACTIVE 76438 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 26, OS thread handle 140079553328832, query id 19824 NAS_Synology 192.168.10.232 home-assistant Statistics
SELECT states_meta.metadata_id, states_meta.entity_id
FROM states_meta
WHERE states_meta.entity_id IN ('input_select.washing_machine_state_machine')
Trx read view will not see trx with id >= 59630573, sees < 59630390
---TRANSACTION (0x7f66d81c5d80), ACTIVE 65229 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 24, OS thread handle 140079423690432, query id 36239 PC_werkkmr 192.168.10.201 dev Sending data
SELECT x.* FROM `home-assistant`.schema_changes x
LIMIT 0, 200
Trx read view will not see trx with id >= 59630574, sees < 59630390
---TRANSACTION (0x7f66d81c4780), not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION (0x7f66d81c3c80), ACTIVE 76437 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 9, OS thread handle 140079554090688, query id 19826 NAS_Synology 192.168.10.232 home-assistant Statistics
SELECT states_meta.metadata_id, states_meta.entity_id
FROM states_meta
WHERE states_meta.entity_id IN ('input_select.washing_machine_state_machine')
Trx read view will not see trx with id >= 59630573, sees < 59630390
---TRANSACTION (0x7f66d81c3180), ACTIVE 76436 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 8, OS thread handle 140079687550656, query id 19829 NAS_Synology 192.168.10.232 home-assistant Statistics
SELECT states_meta.metadata_id, states_meta.entity_id
FROM states_meta
WHERE states_meta.entity_id IN ('input_select.dryer_state_machine')
Trx read view will not see trx with id >= 59630573, sees < 59630390
---TRANSACTION (0x7f66d81c2680), ACTIVE 76437 sec starting index read
mysql tables in use 1, locked 0
0 lock struct(s), heap size 1128, 0 row lock(s)
MariaDB thread id 7, OS thread handle 140079687804608, query id 19828 NAS_Synology 192.168.10.232 home-assistant Statistics
SELECT states_meta.metadata_id, states_meta.entity_id
FROM states_meta
WHERE states_meta.entity_id IN ('input_select.dryer_state_machine')
Trx read view will not see trx with id >= 59630573, sees < 59630390
---TRANSACTION 59630390, ACTIVE 86678 sec fetching rows
mysql tables in use 2, locked 2
124478 lock struct(s), heap size 12083320, 2987245 row lock(s)
MariaDB thread id 5, OS thread handle 140079888877248, query id 418 NAS_Synology 192.168.10.232 home-assistant copy to tmp table
ALTER TABLE state_attributes MODIFY attributes_id BIGINT NOT NULL AUTO_INCREMENT
--------
FILE I/O
--------
Pending flushes (fsync): 0
3820464 OS file reads, 2484150 OS file writes, 89079 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
---
LOG
---
Log sequence number 1298633634812
Log flushed up to   1298633634812
Pages flushed up to 1298633394058
Last checkpoint at  1298633394058
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 50331648
Dictionary memory allocated 182616
Buffer pool size   993
Free buffers       0
Database pages     256
Old database pages 0
Modified db pages  255
Percent of dirty pages(LRU & free pages): 99.222
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 0, flush list 0
Pages made young 110780, not young 3202335
0.00 youngs/s, 0.00 non-youngs/s
Pages read 3820428, created 130742, written 2424980
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 256, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
5 read views open inside InnoDB
state: sleeping
----------------------------
END OF INNODB MONITOR OUTPUT
============================

Proces MariaDB continu op 1 CPU volle 100%

code:

 PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND
12471 mysql     20   0 2130.0m  16.1m 100.0 0.428   1292:54 S /usr/local/mariadb10/bin/mariadbd --basedir=/usr/loca+

Van de quadcore, dus totaalgebruik van de NAS ligt op ongeveer 27% CPU continu.

In de HA logfiles zie ik dus al sinds gistermorgen niets meer over migration, laatste melding was

code:

2024-08-17 11:09:39.525 WARNING (Recorder) [homeassistant.components.recorder.migration] Modifying columns attributes_id in table state_attributes. Note: this can take several minutes on large databases and slow machines. Please be patient!

Daarna alleen maar reguliere meldingen die samenhangen met het feit dat de recorder niet is gestart:

code:

Template variable warning: 'None' has no attribute 'last_changed' when rendering '{{ is_state("binary_sensor.

Dit betreft een trigger obv een template, iemand misschien een idee hoe ik daar een availability aan mee kan geven zonder de trigger hier weg te halen en helemaal als losse entity te maken?

YAML:

{{ is_state("binary_sensor.nhr_pc_ping", "on") and (as_timestamp(now()) - as_timestamp(states.counter.nout_speelt_op_de_pc.last_changed) > 60 ) }}

Gezien de hoeveelheid meldingen moet ik misschien helemaal een andere trigger verzinnen, deze evalueert natuurlijk iedere ms agv wijziging van timestamp(now) terwijl dat helemaal niet nodig is.

[Septillion]

@hufkes Dan zou ik toch eens op Github aankloppen. Misschien los issue omdat dit me specifiek voor MariaDB lijkt.

Qua template, kan je die eens in zijn geheel posten?

[hufkes]

Wanneer de PC van mijn zoon online komt, start ik een tellertje die iedere minuut een counter increased, dit werkte goed, maar nu is natuurlijk vanwege dat de recorder niet loopt geen .last_changed.
De ,0 heb ik toegevoegd vanwege de melding "geen default", dat lijkt ook te werken want ik zie nu tenminste alleen nog de melding dat hij geen timestamp uit None kan halen en niet meer de melding over geen default.

Ooit had ik heel blue gewoon een trigger op iedere minuut staan, maar daar wilde ik vanaf. Nu dus een while loop met delay van een minuut totdat hij uit gaat.

YAML:

alias: Nout - count time PC
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.nhr_pc_ping
    to: "on"
  - platform: state
    entity_id:
      - input_boolean.ha_started
    to: "on"
    for:
      seconds: 30
  - alias: "Fallback: pc on and counter not changed > 1min"
    platform: template
    value_template: >-
      {{ is_state("binary_sensor.nhr_pc_ping", "on") and (as_timestamp(now()) -
      as_timestamp(states.counter.nout_speelt_op_de_pc.last_changed, 0) > 60 )
      }}
condition:
  - condition: state
    entity_id: input_boolean.ha_started
    state: "on"
action:
  - repeat:
      sequence:
        - data: {}
          target:
            entity_id: counter.nout_speelt_op_de_pc
          action: counter.increment
        - delay:
            minutes: 1
      while:
        - condition: state
          entity_id: binary_sensor.nhr_pc_ping
          state: "on"
mode: single

[Clumsy Smurf]

Ik heb een teller die bij elke true waarde moet gaan optellen.
Het scriptje werkt opzich, echter is het zo dat mijn boolen input alleen een true waarde stuurd en nooit een false, hierdoor werkt mijn script niet, is er iemand die een idee heeft of het ook mogelijk is om een script te maken die optelt bij elke true waarde (zonder false)?

[Septillion]

@Clumsy Smurf Wat stuurt die input_boolean dan aan? Want zonder hem uit te zetten valt er niets te tellen. Want nee, dan is er geen verandering.

En als het je alleen om het moment te doen is (soort pulsen tellen) zou een input_button logischer zijn.

[Septillion]

@hufkes Ah, ja, dat is nu wel logisch ja. Zou je op kunnen lossen door eerst te checken of iets bestaat maar goed, dan vang je alleen een uitzonderlijke situatie als nu af.

Voor de automation, persoonlijk zou ik gewoon niet loopen maar alleen de starttijd opslaan. Daarna kan je dus gewoon berekenen hoe lang dat geleden is. Eventueel gooi je die berekening weer in een template sensor.

[Clumsy Smurf]

@Septillion het is een module die aangesloten is op KNX.
Het gaat om een regen meter, die bij elke vaste hoeveelheid een puls aan stuurt.
Het is dus inderdaad een puls teller wat ik wil maken, zodat ik kan zien hoeveel regen er die dag gevallen is.
Ik vermoed dat als ik hem in HA omzet naar button, ik hetzelfde zal hebben?
Als dit niet mogelijk is in HA, moet ik een andere oplossing gaan zoeken in KNX.

[ Voor 11% gewijzigd door Clumsy Smurf op 18-08-2024 15:20 ]

[Septillion]

@Clumsy Smurf Maar uit zichzelf zal een KNX geen helper (inpuit_boolean) aan, dus dat moet jij gedaan hebben.... Dus hoe heb je dat gedaan?

En nee, buttons hebben geen state. Die kennen alleen een event.

[Clumsy Smurf]

@Septillion

sorry is een 'binary_sensor'

YAML:

  - name: "Neerslag bakje [s]" 
    state_address: "5/2/1" 
    sync_state: false

maar dat heeft volgens mij geen invloed op de werking van het script.

[ Voor 5% gewijzigd door Septillion op 18-08-2024 15:34 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Septillion]

@Clumsy Smurf Ahh, maar hoe komt die dan in HA?

Want als iets alleen maar een "aan" puls stuurt is een binary_sensor simpelweg het verkeerde datatype voor HA. De mooiste oplossing zou dus zijn dat wel in het juiste type te gieten

[Clumsy Smurf]

@Septillion Dan ben ik benieuwd wat dan wel de juiste sensor is, en waarom dan die ipv van de 'binary_sensor'

Want misschien dat mijn denk wijze er dan verkeerd over is en heb ik meer fout staan?

[ Voor 28% gewijzigd door Clumsy Smurf op 18-08-2024 15:28 ]

[Septillion]

@Clumsy Smurf Nog even zitten kijken, helaas lijkt de KNX integratie geen exhte ondersteuning te hebben voor het juiste type. Want zoals gezegd een button of een event zou een juist type zijn Maar de "button" in de KNX integratie lijkt alleen te zijn om iets naar KNX te sturen.

Maar je zou de KNX binary_sensor wel moeten kunnen voorzien van een reset_after. Als je deze nu gewoon eens op 1 seconde zet.

[Clumsy Smurf]

Dank u @Septillion ik ga er mee aan de slag

[sypie]

Ik heb op mijn dashboard een dag en datum ingesteld op een kaart. Waarschijnlijk zorgt die voor een melding van "invalid config". Ik heb alleen even geen idee wat ik aan moet passen.

De code in de kaart waar de dag en datum staat is als volgt:

YAML:

- type: custom:mushroom-template-card
        primary: >-
          {{ (as_timestamp(now()) | timestamp_custom('%e')) }} {% set mon =
          ["januari", "februari", "maart", "april", "mei", "juni", "juli",
          "augustus", "september", "oktober", "november", "december"] %}{{
          (mon[now().month-1])}} 2024

EDIT: Bovenstaande code vervangen door onderstaande. Geen idee of het er beter van wordt, dit is wat ChatGPT me terug gaf.

YAML:

primary: >
  {% set maanden = {
    'January': 'januari',
    'February': 'februari',
    'March': 'maart',
    'April': 'april',
    'May': 'mei',
    'June': 'juni',
    'July': 'juli',
    'August': 'augustus',
    'September': 'september',
    'October': 'oktober',
    'November': 'november',
    'December': 'december'
  } %}
  {{ now().strftime('%d') }} {{ maanden[now().strftime('%B')] | lower }} {{ now().strftime('%Y') }}

Dit staat er in mijn sensors.yaml:

YAML:

 - platform: time_date
    display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'date_time_utc'
      - 'date_time_iso'
      - 'time_date'
      - 'time_utc'
      [s]- 'beat'[/s]

De dag en datum werkt normaal, het is dus niet iets wat de boel breekt maar ik ik zou graag de terugkerende melding weg willen hebben en dit oplossen.

EDIT: beat hoort niet thuis in het rijtje blijkt nu. ChatGPT heeft me de foutmelding helder en duidelijk uitgelegd. Probleem opgelost bij dezen.

[ Voor 28% gewijzigd door sypie op 18-08-2024 20:12 . Reden: Waarom heb ik niet eerder aan ChatGPT gedacht? ]

[Mylotec]

Ik kom nog even terug op mijn vraag omtrent de het sturen van de temperatuur;

Is het mogelijk om via automations de waarde door te geven naar de airco?



Hoe kan ik zorgen dat de waarde van het mqtt bericht in doelwaarde komt? Kan er hier een variabele toegevoegd worden?

[Septillion]

@Mylotec Ook al kan het in HA wel in een automation met wat template magie, zou ik zelf eerst die MQTT waarde als sensor in HA trekken. HA is er namelijk meer op gebouwd om eerst van de individuele zaken als abstractie binnen HA te brengen en dan daarmee weer te werken. Dan kennen zaken ook maar mooi één contactpunt met HA.

Waar komt die MQTT waarde vandaan? En is daar niet al een echte integratie voor?

Zo niet, zou ik hem eerst als MQTT sensor toevoegen.

[Septillion]

@sypie En de snippet met beat kwam zeker ook uit ChatGPT? Volgens mij kan je toch nog steeds beter gewoon de documentatie lezen dan ChatGPT vragen voor HA.

Ennuh, gebruik je die sensor die je aanmaakt dan ook nog ergens? Want in die template van je mushroom card heb je hem niet nodig...

[dabachata]

@RobertMe Hier dan on-topic wat betreft Home Assistant en USB Zigbee Dongle, naar aanleiding van mijn eerdere posts op de Zuinige Server forum:

dabachata in "Het grote zuinige server topic - deel 3" &
dabachata in "Het grote zuinige server topic - deel 3"

De Sonoff Zigbee 3.0 E USB dongle is First Pick Zigbee USB Coordinator op de site waar allerlei Zigbee sensoren en adapters uitgebreid worden getest. Al vaker bezocht omdat daar te vinden is wat de betere mmWave Human Presence sensoren zijn, en ik kwam daar in een review van zo'n mmWave presence sensor de link naar onderstaande overzicht tegen:
https://smarthomescene.co...-for-home-assistant-2023/
Daar las ik ook dat de EFR32MG21 nieuwer en krachtiger was dan andere opties.

De in hetzelfde overzicht ook benoemde SMLight SLZB-07 was minder makkelijk te bestellen, dus voor de aangeraden Sonoff dongle gekozen.

Naar aanleiding van jouw reactie even gezocht of ik mij niet vergist in mijn keuze voor de aangeraden op Silcon Labs EFR32MG21 gebaseerde Dongle ipv de Second Pick op Texas Instruments CC2652P gebaseerde dongle heb ik net gekeken naar welke USB Dongle ZHA ondersteund en kwam gelukkig onder t kopje "Recommended Zigbee radio adapters and modules" op https://www.home-assistant.io/integrations/zha/ de Sonoff Zigbee 3.0 E helemaal bovenaan tegen.

Met simpele instructies erbij om zonodig de nieuwste firmware op de dongle te flashen leek me de Sonoff Zigbee 3.0 E de beste optie om aan te schaffen
https://smarthomescene.co...fr32mg21-zigbee-adapters/

[TheFes]

Devke schreef op zaterdag 17 augustus 2024 @ 16:39:
[...]

My mistake. Ik laat de hele configuration.yaml wel zien. Zijn een paar regels extra. Daarin staat de uitbreiding ook m.b.t. je vanmiddag al een keer op gereageerd hebt.

YAML:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template:
  - sensor:
    - name: Omzettingsverlies
      unique_id: doorreken_var
      unit_of_measurement: "kWh"
      device_class: energy
      state: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out')|float %}
        {{ (TARGET - SOURCE) | round(2) }}
      availability: >-
        {% set TARGET = states('sensor.battery_sim_hw_battery_energy_in') %}
        {% set SOURCE = states('sensor.battery_sim_hw_battery_energy_out') %}
        {{ TARGET |is_number and SOURCE }}
        # Bereken de bespaarde terugleverboete door de batterij plaatsing
template:
  - sensor:
    - name: BespaardeTLB
      unique_id: Bespaarde_TLB
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set geladen_kWh_Bat = states('sensor.battery_sim_hw_battery_energy_in')|float %}
        {% set TLB = 0.1015 %}
        {{ (geladen_kWh_Bat * TLB) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_energy_in')|is_number }}

# Bereken welke inkomsten mis gelopen zijn door het omzetten van energie door een batterij
template:
  - sensor:
    - name: Gemiste TLV
      unique_id: gemiste_TLV
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set omzettingsverlies_kWh = states('sensor.omzettingsverlies')|float %}
        {% set TLV = 0.165 %}
        {{ (omzettingsverlies_kWh * TLV) | round(2) }}
      availability: >-
        {{ states('sensor.omzettingsverlies')|is_number }}

# Bereken de afschrijvingskosten op basis van het aantal cycli uitgevoerd
template:
  - sensor:
    - name: Afschrijvings Kosten
      unique_id: afschrijvings_kosten
      unit_of_measurement: "€" 
      device_class: monetary
      state: >-
        {% set aantal_cycli_verbruikt = states('sensor.battery_sim_hw_battery_cycles')|float %}
        {% set cycli_kosten = 0.235 %}
        {{ (aantal_cycli_verbruikt * cycli_kosten) | round(2) }}
      availability: >-
        {{ states('sensor.battery_sim_hw_battery_cycles')|is_number }}

Haal ik de code weg m.b.t. gemiste_TLV dan krijg ik onderstaande, wat me opvalt is dat bij Availability nu een getal staat ipv True:

[Afbeelding]

Je hebt bij die eerste sensor een YAML comment bij je template staan. Die wordt nu gewoon als text mee genomen in je template en je availability template werkt zo dus niet.

[Tazzios]

Is het alleen bij mij of is het bij meer mensen dat de grafieken allemaal een uur afwijken.
Meeste grafieken tonen per uur de data en als laatste uur zie ik nu 9:00 i.p.v. 10:00.

Tijdzone staat goed ingesteld maar toont "(GMT+1:00) Amsterdam" dit zou nu toch 2:00 moeten zijn?

[TheFes]

Tazzios schreef op maandag 19 augustus 2024 @ 10:23:
Is het alleen bij mij of is het bij meer mensen dat de grafieken allemaal een uur afwijken.
Meeste grafieken tonen per uur de data en als laatste uur zie ik nu 9:00 i.p.v. 10:00.

Tijdzone staat goed ingesteld maar toont "(GMT+1:00) Amsterdam" dit zou nu toch 2:00 moeten zijn?

Heb je het over het Energy Dashboard? Daar zie je alleen totalen per uur, dus het lopende uur zie je het. Het laatste complete uur is van 9:00 tot 10:00 en die zie je in het energy dashboard dus bij 09:00 staan.

[Septillion]

@dabachata Grootste nadeel van de ZBDongle-E is voor mij dat de firmware niet open is. Volgens mij zijn de grootste issues tegenwoordig wel verholpen. Maar feit dat hij nieuwer is zegt in de electronica geen drol

[Septillion]

@TheFes Dat commentaar had ik zelfs nog gemist Dan rendert hij al helemaal nooit false...

[ Voor 29% gewijzigd door Septillion op 19-08-2024 11:29 ]

[Tazzios]

@TheFes
Ik bedoel deze grafieken: https://www.home-assistant.io/dashboards/statistics-graph/ (met period: hour)

Om 10:30 verwacht ik een laatste waarde te zien kunnen zien van 10:00 maar zie dus 9:00 staan, volgens mij gaat er iets mis de zomertijd oid.

[ Voor 3% gewijzigd door Tazzios op 19-08-2024 11:31 ]

[TheFes]

Tazzios schreef op maandag 19 augustus 2024 @ 11:30:
@TheFes
Ik bedoel deze grafieken: https://www.home-assistant.io/dashboards/statistics-graph/ (met period: hour)

Om 10:30 verwacht ik een laatste waarde te zien kunnen zien van 10:00 maar zie dus 9:00 staan, volgens mij gaat er iets mis de zomertijd oid.

Statistics graphs gebruiken hetzelfde idee als op het energy dashboard, en gebruiken dus ook alleen maar hele uren, tenzij de period 5minute gebruikt wellicht.

[Tazzios]

@TheFes het duurde even maar snap je nu. Ik dacht dat hij bij temperatuur de waarde van elk 00 minuten zou tonen. maar hij middelt voor de waarde van 10:00 10:00t/m10:59. Dus is pas na 11:00 10:00 zichtbaar.

maandagochtend.

[TheFes]

@Hmmbob @Septillion
De History Stats documentatie en templating documentatie is aangepast (today_at() > today_at('00:00'))

[ Voor 9% gewijzigd door TheFes op 19-08-2024 12:16 ]

[edwin2021]

Septillion schreef op maandag 19 augustus 2024 @ 11:16:
@dabachata Grootste nadeel van de ZBDongle-E is voor mij dat de firmware niet open is. Volgens mij zijn de grootste issues tegenwoordig wel verholpen. Maar feit dat hij nieuwer is zegt in de electronica geen drol

Welke zigbee zou dan jouw voorkeur hebben?

[Septillion]

@edwin2021 Voor mij dus nog steeds een TI variant.

[DDoubleU]

Hallo,

Ik heb pas geüpdatet naar Core 8.2 en merk dat sindsdien m'n gasverbruik niet meer tevoorschijn in het Energy dashboard (P1-meter via DSMR Reader). Voor mij is dat op dit moment geen probleem omdat m'n gasverbruik in deze periode uiterst minimaal is. Enige tijd geleden was daarover hier sprake waarbij er manueel bepaalde objecten hernoemd moesten worden (dacht ik?). Geldt dat nog steeds of is er een nieuwe versie in de pijplijn waarbij dit kortelings automatisch geadresseerd zou moeten worden?

Alvast bedankt!

[Eärendil]

@DDoubleU Er is iets veranderd aan de DSMR integratie waardoor de sensor-entity vervangen is door een nieuwe:

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

[TheFes]

Dat zou echter niet gebeurd moeten zijn als je direct van 2024.7.4 of lager naar 2024.8.2 gegaan bent

[DDoubleU]

Eärendil schreef op maandag 19 augustus 2024 @ 14:32:
@DDoubleU Er is iets veranderd aan de DSMR integratie waardoor de sensor-entity vervangen is door een nieuwe:

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

Bedankt!!

TheFes schreef op maandag 19 augustus 2024 @ 15:06:
Dat zou echter niet gebeurd moeten zijn als je direct van 2024.7.4 of lager naar 2024.8.2 gegaan bent

Da's vreemd, want ik ben van 2024.7.3 naar 2024.8.2 gegaan en ik heb al 2 dagen geen enkele registratie van gasafname, terwijl dit gisteren wel het geval moet zijn geweest.

[TheFes]

DDoubleU schreef op maandag 19 augustus 2024 @ 15:21:
[...]


Bedankt!!


[...]


Da's vreemd, want ik ben van 2024.7.3 naar 2024.8.2 gegaan en ik heb al 2 dagen geen enkele registratie van gasafname, terwijl dit gisteren wel het geval moet zijn geweest.

De fix zat al in 2024.8.1 maar blijkbaar gaat dat toch fout dan.
Weet je inmiddels wel hoe je het op moet lossen?

[DDoubleU]

Hi,

Ik gebruik de scripts van https://github.com/jdeneef/ha_buienalarm om van Buienalarm een sensor te hebben die aangeeft of er regenval is binnen een welbepaalde termijn. Dit werkt allemaal goed, maar ik zou er graag een uitbreiding op voorzien zodat ik van die welbepaalde termijn (bijvoorbeeld binnen 30 minuten) de maximum (maximale verwachte regenval) kan achterhalen. Op die manier kan een een notification verzenden die de intensiteit (motregen, lichte/matige/zware regenval) kan melden enige tijd voor aanvang.



Daartoe heb ik een helper aangemaakt die de maximum zou moeten berekenen. Op zich krijgt die telkens een correcte waarde, maar toch werkt m'n automation niet.



De trigger voor de automation is een andere sensor die van off naar on sprint wanneer er binnen de termijn regen voorspelt is (deze werkt sowieso correct).



Ik krijg enkel meldingen voor motregen (max < 0.5) terwijl dat er vaak ook een hogere intensiteit geregistreerd was. Heeft iemand een idee van wat er zou kunnen mislopen?

Alvast bedankt!

Relatief klein dus voeg hem samen met het grote topic.

Tip voor hier, zorg dat je plaatjes leesbaar zijn. Of nog beter, plaats de yaml van de automation ipv een plaatje.

[ Voor 9% gewijzigd door Septillion op 20-08-2024 10:53 . Reden: Klikbare plaatjes ]

[prutsger]

TheFes schreef op maandag 19 augustus 2024 @ 15:52:
[...]


De fix zat al in 2024.8.1 maar blijkbaar gaat dat toch fout dan.
Weet je inmiddels wel hoe je het op moet lossen?

Ik heb precies hetzelfde probleem kwam ik vanochtend achter, fijn dat in dit topic al zo snel oplossingen worden gedeeld. Ik zit nog op 2024.8.1 en in eerste instantie leek het verwijderen van de oude entiteit en de nieuwe hernoemen naar de oude geen oplossing. Ik zie nu wel vandaag tussen 13:00 en 14:00 uur een piek van 4,1m3 wat heel goed het totale verbruik sinds 10 augustus, toen het probleem ontstaan is, zou kunnen zijn. Ik zal in de gaten houden hoe het loopt vanaf nu. Even wachten tot er weer iemand moet douchen want de cv is natuurlijk uit. Expres maar 1 van de kids in de modder gooien zo


Ah even verder gelezen en dat zou het inderdaad moeten zijn:

Only a few days missing, but the first stat within the energy dashboard will be a spike the first time containing all the usage of the past days.

https://github.com/home-a...1#issuecomment-2289560466

[ Voor 14% gewijzigd door prutsger op 19-08-2024 16:07 ]

[noo]

DDoubleU schreef op maandag 19 augustus 2024 @ 15:21:
[...]


Bedankt!!


[...]


Da's vreemd, want ik ben van 2024.7.3 naar 2024.8.2 gegaan en ik heb al 2 dagen geen enkele registratie van gasafname, terwijl dit gisteren wel het geval moet zijn geweest.

Dat issue zit in de 'DSMR' integratie (https://www.home-assistant.io/integrations/dsmr), terwijl jij zo te lezen de 'DSMR Reader' integratie (https://www.home-assistant.io/integrations/dsmr_reader/) gebruikt? Die laatste gebruik ik ook en ik heb geen problemen met gas data op 2024.8.2.

[ Voor 9% gewijzigd door noo op 19-08-2024 16:31 ]

[skank]

Is het iemand gelukt om bv de camera van de tablet te gebruiken en te streamen?
Ik heb een tablet met fully kiosk (plus) en normaal vermoed ik, moet ik die camera kunnen start/stoppen met streamen.

Met wat googlen kom ik op het feit als ik http://ip:2323/?cmd=getCamshot&password=xxxxxxxxxxxx
ingeef, ik wel een screenshot kan zien, maar niet streamen.

Geen idee of dit iemand gelukt is of lukt?

Pas op, dit is iets anders dan een andere camera streamen naar de tablet he.

Edit: Net ook dit gevonden, maar eerst es proberen
https://github.com/home-assistant/core/issues/121495

[ Voor 10% gewijzigd door skank op 19-08-2024 19:49 ]

[vonkkie]

skank schreef op maandag 19 augustus 2024 @ 19:45:
Is het iemand gelukt om bv de camera van de tablet te gebruiken en te streamen?
Ik heb een tablet met fully kiosk (plus) en normaal vermoed ik, moet ik die camera kunnen start/stoppen met streamen.

Met wat googlen kom ik op het feit als ik http://ip:2323/?cmd=getCamshot&password=xxxxxxxxxxxx
ingeef, ik wel een screenshot kan zien, maar niet streamen.

Geen idee of dit iemand gelukt is of lukt?

Pas op, dit is iets anders dan een andere camera streamen naar de tablet he.

Edit: Net ook dit gevonden, maar eerst es proberen
https://github.com/home-assistant/core/issues/121495

als ik naar fullu kiosk integratie ga bij devices kan ik gewoon live kijken via de cam

[skank]

vonkkie schreef op maandag 19 augustus 2024 @ 19:54:
[...]


als ik naar fullu kiosk integratie ga bij devices kan ik gewoon live kijken via de cam

Idem, hoewel het daar schokt.
Bovendien terwijl ik kijk, als ik dan naar de state van die camera kijk, blijft hij op idle staan? Vreemd
Ik probeer het werkend te krijgen met deze code maar lukt dus niet.

YAML:

- type: vertical-stack
        cards:
          - type: conditional
            conditions:
              - condition: state
                entity: camera.galaxy_tab_s3
                state: idle
            card:
              type: picture
              tap_action:
                action: call-service
                service: camera.turn_on
                target:
                  entity_id: camera.galaxy_tab_s3
              image: /local/camera.jpg
          - type: conditional
            conditions:
              - condition: state
                entity: camera.galaxy_tab_s3
                state: streaming
            card:
              type: vertical-stack
              cards:
                - show_name: true
                  show_icon: false
                  type: button
                  tap_action:
                    action: call-service
                    service: camera.turn_off
                    target:
                      entity_id: camera.galaxy_tab_s3
                  name: Stop
                  entity: camera.galaxy_tab_s3
                - type: custom:webrtc-camera
                  entity: camera.galaxy_tab_s3

[ Voor 10% gewijzigd door skank op 19-08-2024 20:41 ]

[roelofz]

Hoi,

Ik heb hier al even lopen zoeken maar kan het niet zelf maken.
Ik ben net een beetje bezig met HA, snap wel een woordje scripten en YAML, maar moet er een beetje mee op gang komen.

Ik wil op een dag dat het boven de 25 graden wordt, de vloerkoeling s'ochtends vroeg al aanzetten tot dat de zon onder gaat. Dus eigenlijk moet bij zonsopgang de verwachting uitgelezen worden en daarna niet meer (ik las iets over een template waarbij dit doorlopend gemeten wordt, als ook aangepast, dat is voor mij juist niet nodig).

Ik wil dit op basis van openweathermap doen.

Ik zou dit in een trigger willen vatten, zodat ik op basis van een paar triggers (het gaat mij hier echt alleen om de max temp verwachting, rest kan ik zelf wel (denkt hij :-) ) acties kan bepalen.
Dit kan vast mooier, ik zag een choose voorbeeld (waar ene Gijs vorig jaar mee geholpen is), maar dat kreeg ik niet aan de praat, vanwege de extra complexiteit, mooi, maar te mooi voor mij...

Nu begrijp ik dat er ook eea is veranderd, zie templates noemen, maar hoop dat ik een trigger - action obv trigger kan maken, zodat het niet te complex wordt.
Ik heb geen werkende voorbeelden, dus hoop dat jullie mij met een trigger kunnen helpen, waarmee ik het spoor verder zelf op kan bouwen.

Alvast dank voor jullie hulp!

[GaMbiNo]

roelofz schreef op maandag 19 augustus 2024 @ 22:16:
Hoi,

Ik heb hier al even lopen zoeken maar kan het niet zelf maken.
Ik ben net een beetje bezig met HA, snap wel een woordje scripten en YAML, maar moet er een beetje mee op gang komen.

Ik wil op een dag dat het boven de 25 graden wordt, de vloerkoeling s'ochtends vroeg al aanzetten tot dat de zon onder gaat. Dus eigenlijk moet bij zonsopgang de verwachting uitgelezen worden en daarna niet meer (ik las iets over een template waarbij dit doorlopend gemeten wordt, als ook aangepast, dat is voor mij juist niet nodig).

Ik wil dit op basis van openweathermap doen.

Ik zou dit in een trigger willen vatten, zodat ik op basis van een paar triggers (het gaat mij hier echt alleen om de max temp verwachting, rest kan ik zelf wel (denkt hij :-) ) acties kan bepalen.
Dit kan vast mooier, ik zag een choose voorbeeld (waar ene Gijs vorig jaar mee geholpen is), maar dat kreeg ik niet aan de praat, vanwege de extra complexiteit, mooi, maar te mooi voor mij...

Nu begrijp ik dat er ook eea is veranderd, zie templates noemen, maar hoop dat ik een trigger - action obv trigger kan maken, zodat het niet te complex wordt.
Ik heb geen werkende voorbeelden, dus hoop dat jullie mij met een trigger kunnen helpen, waarmee ik het spoor verder zelf op kan bouwen.

Alvast dank voor jullie hulp!

Ik denk dat je dan twee triggers nodig hebt:

Trigger 1:
Zonsopgang
Voorwaarde:
Voorspelling temperatuur 25 of hoger
Actie:
Vloerkoeling aan

Trigger 2:
Zonsondergang
Actie:
Vloerkoeling uit

Je kan het in twee automatiseringen doen. Dat is het makkelijkst maar ik zou het in 1 doen. Maar dan moet je beide triggers een uniek ID geven. En beide acties alleen laten uitvoeren wanneer getriggered door de bijbehorende trigger.

[ Voor 6% gewijzigd door GaMbiNo op 20-08-2024 08:30 ]

[sypie]

Septillion schreef op maandag 19 augustus 2024 @ 10:00:
@sypie En de snippet met beat kwam zeker ook uit ChatGPT? Volgens mij kan je toch nog steeds beter gewoon de documentatie lezen dan ChatGPT vragen voor HA.

Ennuh, gebruik je die sensor die je aanmaakt dan ook nog ergens? Want in die template van je mushroom card heb je hem niet nodig...

Nee, die snippet met beat kwam volgens mij ergens van een online tutorial die ik gevolgd had. Naar aanleiding van de melding die ik kreeg heb ik ChatGPT ingeschakeld, ik ben zelf niet van het programmeren maar knippen en plakken lukt me prima.

En nee, die sensor heb ik vandaag uitgeschakeld in sensors.yaml. Alles bleef netjes werken zoals het zou moeten. Kennelijk heb ik die eens ergens voor gebruikt of willen gebruiken en daarna laten staan. Ik zal 'm geheel verwijderen uit de yaml.

Dank in ieder geval voor de headsup.