Home Assistant: Open source Python3 home automation - deel 2

[Imperial Guard]

Laatste hand kunnen leggen op mijn energie verbruiken, gelukkig met wat hulp van een collega lees ik o.a. mijn puls van mijn watermeter uit maar daarbij weet ik ook wanneer de laatste puls was in ms.

In een template sensor binnen Home Assistant reken ik het uit naar l/min en l/h.
Iedere puls is bij mij 1 liter.

Zo heb ik een overzicht per dag, per week, per maand, totaal en contract periode van energie en water

[Voor 23% gewijzigd door Imperial Guard op 03-02-2020 21:26]

[skank]

the_cyberspace schreef op maandag 3 februari 2020 @ 16:41:
[...]


Ik maak inderdaad gebruik van een SSL certificaat in combinatie met een (sub)domeinnnaam. Om dit te regelen en te laten werken via HA maak ik gebruik van Nginx proxy manager. Uiteraard in HA ook het certificaat opgegeven in de configuration.yaml

Maar ik kan me eigenlijk niet voorstellen dat de Unifi integratie niet zou werken zonder SSL en domeinnaam. Domeinnaam heb ik puur omdat ik dan geen IP hoef te onthouden en SSL om de boel te beveiligen maar zonder dit zou het ook gewoon moeten werken.

Ik heb in de m`n Unifi controller overigens wel een aparte user aangemaakt die alleen leesrechten heeft. Maar de integratie zou ook moeten werken met je standaard username en wachtwoord waarmee je inlogt. Neem aan dat je een controller hebt draaien? En gebruik je de laatste firmware voor je USG?

ik heb ook een aparte user opgezet met leesrechten en system status rechten
ik heb idd een controller runnen en laatste firmware usg

Ik krijg wel heel veel meldingen zoals nu

Failed to access health info: api.err.NoSiteContext
21:23 custom_components/unifigateway/sensor.py (ERROR) - bericht kwam voor het eerst om 15:27 en verschijnt 2106 malen
Failed to perform <function Controller._read at 0x7212f150> due to api.err.NoSiteContext
21:23 custom_components/unifigateway/sensor.py (WARNING) - bericht kwam voor het eerst om 15:27 en verschijnt 2104 malen
Failed to perform <function Controller._read at 0x7212f150> due to api.err.LoginRequired
18:27 custom_components/unifigateway/sensor.py (WARNING) - bericht kwam voor het eerst om 15:27 en verschijnt 2 malen
Failed to access health info: HTTPSConnectionPool(host='192.168.99.3', port=8443): Max retries exceeded with url: /api/login (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x70568ed0>: Failed to establish a new connection: [Errno 111] Connection refused'))
18:26 custom_components/unifigateway/sensor.py (ERROR)
Failed to perform <function Controller._read at 0x7212f150> due to HTTPSConnectionPool(host='192.168.99.3', port=8443): Max retries exceeded with url: /api/s/default/stat/health (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x70568b70>: Failed to establish a new connection: [Errno 111] Connection refused'))
18:26 custom_components/unifigateway/sensor.py (WARNING)

ik zie nu net ook drops in mn netwerk

https://ibb.co/dDBYkF0

Zeggen die stukjes log je iets?
Waarom werkt het bij mij niet en bij jou wel
Gebruik jij een cloudkey gen of bv RPI voor je controller (als dat iets kan betekenen)

[Stampre]

Stampre schreef op zondag 2 februari 2020 @ 20:15:
[...]


Als ik het goed begrijp is dit dus USB0:

input: []
serial:
- /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AO3ZOKEY-if00-port0
- /dev/ttyUSB0
- /dev/ttyAMA0
~ $
~ $ audio:

Voor de volledigheid, ik heb een p1 kabel rechtstreeks op mijn pi aangesloten zonder esp bordje oid ertussen. Dat zou volgend mij moeten kunnen. Ik heb de MQTT broker geinstalleerd en deze is zichtbaar bij de integraties (dan hoef ik daar toch niets meer met integraties te doen?)

daarna heb ik in de config gezet:
platform: DSMR

Zo had ik het in de uitleg gelezen maar ik heb het idee dat ik hier nu nog een aantal stappen mis.

Ik ben na 4 avonden prutsen aan het eind van mijn opties. Onderstaand mijn configuration yaml. Iik heb mqtt broker geinstalleerd via de addon en verder nergens iets ingesteld. Kabel heb ik van RObbshop en net getest op mijn laptop. Dat zou moeten werken. Wat mis ik, of wat moet ik nog extra installeren. Gouden tip=eeuwige roem

# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
# base_url: example.duckdns.org:8123

# Text to speech
tts:
- platform: google_translate

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
customize: !include customize.yaml

sensor:
- platform: rova
zip_code: 8043??
house_number: ??
name: Rova
monitored_conditions:
- bio
- paper
- plastic
- residual


platform: dsmr
port: /dev/ttyUSB0
dsmr_version: 5

[Hmmbob]

Stampre schreef op maandag 3 februari 2020 @ 22:17:
[...]


Ik ben na 4 avonden prutsen aan het eind van mijn opties. Onderstaand mijn configuration yaml. Iik heb mqtt broker geinstalleerd via de addon en verder nergens iets ingesteld. Kabel heb ik van RObbshop en net getest op mijn laptop. Dat zou moeten werken. Wat mis ik, of wat moet ik nog extra installeren. Gouden tip=eeuwige roem

# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
# base_url: example.duckdns.org:8123

# Text to speech
tts:
- platform: google_translate

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
customize: !include customize.yaml

sensor:
- platform: rova
zip_code: 8043??
house_number: ??
name: Rova
monitored_conditions:
- bio
- paper
- plastic
- residual


platform: dsmr
port: /dev/ttyUSB0
dsmr_version: 5

Kan je je code in [ code] blocks zetten? Yaml is spatie gevoelig

[Stampre]

Hmmbob schreef op maandag 3 februari 2020 @ 22:42:
[...]

Kan je je code in [ code] blocks zetten? Yaml is spatie gevoelig

Hier of in het algemeen?

[Hmmbob]

Stampre schreef op maandag 3 februari 2020 @ 22:43:
[...]


Hier of in het algemeen?

In het algemeen, en als je hier geen code blocks gebruikt zien wij je yaml niet juist

[Stampre]

Hmmbob schreef op maandag 3 februari 2020 @ 22:44:
[...]

In het algemeen, en als je hier geen code blocks gebruikt zien wij je yaml niet juist

oef, dan moet ik eerst uitzoeken hoe dat werkt

[Hmmbob]

Stampre schreef op maandag 3 februari 2020 @ 22:47:
[...]


oef, dan moet ik eerst uitzoeken hoe dat werkt

Wat, code blocks?

Willekeurig voorbeeld post: https://gathering.tweakers.net/forum/view_message/61327590

Yaml indentation? Altijd per twee spaties. Goed kijken naar voorbeeld code en je snapt het vanzelf

[Stampre]

Hmmbob schreef op maandag 3 februari 2020 @ 22:54:
[...]

Wat, code blocks?

Willekeurig voorbeeld post: https://gathering.tweakers.net/forum/view_message/61327590

Yaml indentation? Altijd per twee spaties. Goed kijken naar voorbeeld code en je snapt het vanzelf

Je hebt de eeuwige roem! Je triggerde mij met dr spaties. De fout zat in gekopieerde code, daardoor miste ik een spatie voor platform... nou op naar de volgende hobbel.

[Meelobee]

Meelobee schreef op maandag 3 februari 2020 @ 08:39:
[...]

code:

name_template: "{{ 'dagen' if states.sensor.papier_2.attributes.days |int > 1 else '1 dag' }}"

Garbage sensor nou helemaal netjes werkend;
[Afbeelding]

code:

        name_template: >-
          {%- if is_state("sensor.papier_2", "0")%} 
          Vandaag
          {% elif is_state("sensor.papier_2", "1")%}
          Morgen{% else %}
          {{ states.sensor.papier_2.attributes.days }} dagen
          {%- endif %}

Een betere variant, geeft op de knop 'Vandaag' & 'Morgen' aan, in plaats van 1 dag & 0 dagen.

[martinvdm]

Stampre schreef op maandag 3 februari 2020 @ 23:20:
[...]

Je hebt de eeuwige roem! Je triggerde mij met dr spaties. De fout zat in gekopieerde code, daardoor miste ik een spatie voor platform... nou op naar de volgende hobbel.

Wat een yaml lint al niet kan doen, steek die maar in je zak @Hmmbob
Ohja @Stampre
Haal je code regelmatig door http://www.yamllint.com/

[Jeltel]

Of gebruik Visual Studio Code, met de Home Assistent extensie. Dan krijg je gelijk code verificatie en geeft VSC aan als je een spatie mist.
En je hebt auto complete van extensies en allerlei attributen van de yaml code.

[Voor 24% gewijzigd door Jeltel op 04-02-2020 09:40]

[rroetenberg]

Ik ben bezig met de migratie van Domoticz naar Home Assistant. Nu wil ik onderhand mijn slimme meter uitlezen. Echter zie ik de DSMR reader van de Github, maar ik zie ook de integratie met Home Assistant.

Kan iemand mij vertellen wat precies de verschillen zijn? En waarom ik beter de externe DSMR Reader zou kunnen gebruiken?

[Nnoitra]

rroetenberg schreef op dinsdag 4 februari 2020 @ 08:27:
Ik ben bezig met de migratie van Domoticz naar Home Assistant. Nu wil ik onderhand mijn slimme meter uitlezen. Echter zie ik de DSMR reader van de Github, maar ik zie ook de integratie met Home Assistant.

Kan iemand mij vertellen wat precies de verschillen zijn? En waarom ik beter de externe DSMR Reader zou kunnen gebruiken?

Als je de documentatie van beide hebt gelezen weet je al wat de verschillen zijn...
Indien mogelijk; DSMR_Reader gebruiken, data die je in HASS wil hebben door laten sturen (vanuit DSMR_Reader) en dat niet ook weer in HASS z'n database opslaan.

[Repsect]

Hmmbob schreef op zondag 2 februari 2020 @ 14:18:
[...]

Al geprobeerd met extra quotes? (geen idee of dat echt verschil gaat maken, maar dat zou mijn volgende debug stap zijn)

YAML:

  templates:
    icon_color: >
      if (state === 'on') return "rgb(253, 216, 53)";
      return "rgb(68, 115, 158)";

Thanks, met quotes werkt het wel. MAARrrr...

... Als je de exacte RGB kleur pakt, kleurt ie nog steeds te licht blauw. Ik heb met Colorizer de HSV/HSB lightness 1 tandje lager gezet, waarmee de RGB veranderd van (68, 115, 158) naar (68, 114, 157) en dan krijg je wel de donkerblauwe kleur te zien.

YAML:

input_boolean.scene_uit:
  templates:
    icon_color: >
      if (state === 'on') return "rgb(253, 216, 53)";
      return "rgb(68, 114, 157)";

[Hmmbob]

Repsect schreef op dinsdag 4 februari 2020 @ 09:45:
[...]


Thanks, met quotes werkt het wel. MAARrrr...

... Als je de exacte RGB kleur pakt, kleurt ie nog steeds te licht blauw. Ik heb met Colorizer de HSV/HSB lightness 1 tandje lager gezet, waarmee de RGB veranderd van (68, 115, 158) naar (68, 114, 157) en dan krijg je wel de donkerblauwe kleur te zien.

YAML:

input_boolean.scene_uit:
  templates:
    icon_color: >
      if (state === 'on') return "rgb(253, 216, 53)";
      return "rgb(68, 114, 157)";

[Afbeelding]

Fijn dat het werkt. Bijzonder dat de kleuren er niet goed uitkomen - die rgb waardes kwamen rechtstreeks uit mijn Home Assistant CSS bron. Top dat het nu lukt!

[D3vilke]

Ik heb recent een een raspberry pi 4 gekocht, en wou hierop hass.io zetten. Ik connecteer hem via een ethernet kabel, maar toch vind ik hem niet op mijn netwerk.
Op het scherm komen ook de volgende foutmeldingen:

IPv6: ADDCONF (NETDEV_UP): wlan0: link is not ready
brcmfmac: power management disabled

Iemand enig idee hoe ik dit kan oplossen?

Ik heb al geprobeerd van het hass.io opnieuw te installeren op de sd kaart, maar dat lijkt geen oplossing te bieden. Op internet vond ik dat het opgelost zou kunnen worden door IPV6 af te zetten op de router, maar dat zou ik toch liever niet doen...

[Hmmbob]

D3vilke schreef op dinsdag 4 februari 2020 @ 10:35:
Ik heb recent een een raspberry pi 4 gekocht, en wou hierop hass.io zetten. Ik connecteer hem via een ethernet kabel, maar toch vind ik hem niet op mijn netwerk.
Op het scherm komen ook de volgende foutmeldingen:

IPv6: ADDCONF (NETDEV_UP): wlan0: link is not ready
brcmfmac: power management disabled

Iemand enig idee hoe ik dit kan oplossen?

Ik heb al geprobeerd van het hass.io opnieuw te installeren op de sd kaart, maar dat lijkt geen oplossing te bieden. Op internet vond ik dat het opgelost zou kunnen worden door IPV6 af te zetten op de router, maar dat zou ik toch liever niet doen...

Die meldingen hebben er zo goed als zeker niets mee te maken. Je beschrijft dat je ethernet gebruikt (netwerkkabel), dus dat wlan0 (Wireless LAN -> WiFi) niet gereed is, is een melding die je kan negeren. Ook de power management lijkt me niet per se een probleem te zijn.

Ik denk dat je je probleem elders moet zoeken. Weet je zeker dat je de instructies stap-voor-stap en tot de letter gevolgd hebt?

Kijk anders ook even in je router of je kan vinden welk IP adress hij gekregen heeft.

[Voor 3% gewijzigd door Hmmbob op 04-02-2020 10:50]

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 09:42:
Als je de documentatie van beide hebt gelezen weet je al wat de verschillen zijn...
Indien mogelijk; DSMR_Reader gebruiken, data die je in HASS wil hebben door laten sturen (vanuit DSMR_Reader) en dat niet ook weer in HASS z'n database opslaan.

Wat is daar het voordeel van dan? Ontkoppelen van HA en de meting?

Heb het zelf laatst juist direct gekoppeld om extra componenten te vermijden. Nou ja direct, ser2net moest er wel tussen.

[Cpt_ZakLamP]

Mocht iemand nog afval integratie zoeken voor Reinigingsdienst Waardlanden Ik heb het component voor 'acv' aangepast zodat deze voor waardlanden werkt:

https://github.com/m11tch/waardlanden-hass-component

Is overigens vrij eenvoudig aan te passen voor andere afvalverwerkers die met het ximmio platform werken.

Kwestie van onderstaande aanpassen:

sensor.py

code:

DEFAULT_COMPANYCODE = '942abcf6-3775-400d-ae5d-7380d728b23c'
DEFAULT_HEADERS = {
    'User-Agent': "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36",
    'Referer': 'https://www.waardlanden.nl/particulieren/afvalinzameling/afvalkalender

Zou overigens ook uitgebouwd kunnen worden tot component met ondersteuning voor alle verwerkers die ximmio platform gebruiken, maar daar heb ik geen tijd voor

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 10:52:
[...]

Wat is daar het voordeel van dan? Ontkoppelen van HA en de meting?

Heb het zelf laatst juist direct gekoppeld om extra componenten te vermijden. Nou ja direct, ser2net moest er wel tussen.

Nou, zie/lees de documentatie van beide eens?
DSMR_reader is vele malen uitgebreider en heeft standaard z'n eigen database.
Het HASS component is basic, erg basic. En door alles in de HASS database, en dit niet te tweaken, te zetten gaat je logbook/history binnen no time zo traag als dikke stront door een trechter worden. En je database groeit als kool. Zet je het uit/tweak je het, dan verlies je je historie.

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 11:00:
Nou, zie/lees de documentatie van beide eens?

De dooddoener van documentatie lezen is altijd populair, maar daarmee krijg je alleen mee wat de maker bescheven heeft. Natuurlijk lees je dat vooraf (deels) door, maar dat geeft zelden een juiste richting.
De overwegingen om bepaalde combinaties van componenten te maken is er één die meestal op ervaring gebaseerd is.
Het is juist die praktijkervaring van combinaties die de meerwaarde geeft aan dit soort topics, logischerwijs komt men daar dan ook naar vragen.

DSMR_reader is vele malen uitgebreider en heeft standaard z'n eigen database.
Het HASS component is basic, erg basic. En door alles in de HASS database, en dit niet te tweaken, te zetten gaat je logbook/history binnen no time zo traag als dikke stront door een trechter worden. En je database groeit als kool. Zet je het uit/tweak je het, dan verlies je je historie.

Met de history van HASS heb ik nog niet zoveel ervaring, moet inderdaad zeggen dat ik daar nog wel een kuub vraagtekens bij had. Bij Domoticz had je daar weinig last mee, alleen werd historie gewoon opgeruimd wat ook weer vervelend is. Dit is sowieso nog wel een stukje uitzoekwerk voor mij want ik ben net over naar ASS.

DSMR ziet er veel uitgebreider uit, maar uiteindelijk zie ik in HASS ook gewoon verbruik en grafiekjes. De vraag is dan waarom uitgebreider beter is.
Het zou betekenen dat hij z'n eigen database moet gaan bijhouden, dat kan niet op de PI die nu ser2net draait want dan fik je de kaart door. Ofwel, die moet dan ook op de NAS in een dockje. Maar die images worden dan weer 3rd party beheerd en mag je weer afwachten voor hoelang die maker daar zin in heeft. Dan is een linux image en dan zelf installeren wellicht nog veiliger. De PI kan dan een slaafje zijn wat alleen maar de informatie doorgeeft zoals nu.
Onder de streep heb je dan wel meerdere extra componenten en systemen die ondersteund moeten blijven, onderhoud nodig hebben en hun eigen nukken kunnen hebben. En dan heb ik alsnog niet alle informatie bij elkaar in één systeem.

Ofwel, ik wil je best geloven dat DSMR reader de betere keuze is, maar er zit wel een dusdanig flinke keerzijde aan dat ik meer onderbouwing nodig heb dan je uit de documentatie kunt halen.

[Kodess]

Gonadan schreef op dinsdag 4 februari 2020 @ 11:44:
Het zou betekenen dat hij z'n eigen database moet gaan bijhouden, dat kan niet op de PI die nu ser2net draait want dan fik je de kaart door.

Ik draai DSMR Reader nu bijna 4 jaar op een Pi, terwijl zijn database op zijn SD kaart staat (elk uur een backup naar dropbox). Hij leeft nog. Heeft ook meerdere keren stroom verloren waarna hij gewoon weer prima aanging.

[Gonadan]

Kodess schreef op dinsdag 4 februari 2020 @ 11:56:
[...]

Ik draai DSMR Reader nu bijna 4 jaar op een Pi, terwijl zijn database op zijn SD kaart staat (elk uur een backup naar dropbox). Hij leeft nog. Heeft ook meerdere keren stroom verloren waarna hij gewoon weer prima aanging.

Met een v5 meter? Op zich moet een goed kaartje het lang kunnen volhouden, maar ik doe het liever niet meer. M'n Domoticz heeft het ook erg lang vol gehouden nadat ik er een goede kaart in gestopt had, maar als ik kan kiezen doe ik liever alles in dockjes en opslag op de NAS. Dan is het ook makkelijk te onderhouden en repareren.

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 11:44:
[...]

De dooddoener van documentatie lezen is altijd populair, maar daarmee krijg je alleen mee wat de maker beschreven heeft. Natuurlijk lees je dat vooraf (deels) door, maar dat geeft zelden een juiste richting.
De overwegingen om bepaalde combinaties van componenten te maken is er één die meestal op ervaring gebaseerd is.
Het is juist die praktijkervaring van combinaties die de meerwaarde geeft aan dit soort topics, logischerwijs komt men daar dan ook naar vragen.

Laat ik er eens mee beginnen dat ik niet heb gezegd dat DSMR_Reader de betere keuze is (tis wel m'n persoonlijke voorkeur)
Prima dat je "documentatie moet lezen" een dooddoener vind, maar daar hoor je wel mee te beginnen.
Daaruit kun je prima de functionaliteit en dus ook de verschillen halen.
Wil je de grafieken, kosten overzicht en historie? Dan is de keus makkelijke. Wil je alleen data in HomeAssistant, dan ga je voor de Hass integratie.Vervolgens kun je zelf grafieken in elkaar knutselen.
Geen rocket science lijkt me. Wat het beste is, dat is afhankelijke van je eigen wensen/eisen/mogelijkheden.

Met de history van HASS heb ik nog niet zoveel ervaring, moet inderdaad zeggen dat ik daar nog wel een kuub vraagtekens bij had. Bij Domoticz had je daar weinig last mee, alleen werd historie gewoon opgeruimd wat ook weer vervelend is. Dit is sowieso nog wel een stukje uitzoekwerk voor mij want ik ben net over naar ASS.

Elke seconde data; dat gaat flink in de papieren lopen.
De HASS functies "historie" en "logboek" lezen elke keer je database uit. Hoe groter je database, hoe langer dat gaat duren. Er is wel een 'auto purge' mogelijkheid, maar dan ben je alles van vóór die datum kwijt. Als je verbruik over X periode wilt vergelijken met periode Y.. Niet handig.

DSMR ziet er veel uitgebreider uit, maar uiteindelijk zie ik in HASS ook gewoon verbruik en grafiekjes. De vraag is dan waarom uitgebreider beter is.

Of uitgebreider beter is, hangt dus af van wensen/eisen. En als je die weet kun je dus de documentatie er naast leggen en gaan afvinken

Het zou betekenen dat hij z'n eigen database moet gaan bijhouden, dat kan niet op de PI die nu ser2net draait want dan fik je de kaart door. Ofwel, die moet dan ook op de NAS in een dockje. Maar die images worden dan weer 3rd party beheerd en mag je weer afwachten voor hoelang die maker daar zin in heeft. Dan is een linux image en dan zelf installeren wellicht nog veiliger. De PI kan dan een slaafje zijn wat alleen maar de informatie doorgeeft zoals nu.

Die afhankelijkheid van 3rd parties, die heb je toch al; waarom niet nog ééntje er bij?
Maar gezien Postgress zelf z'n docker containers beheert, zou ik me niet druk maken over toekomstige ondersteuning.

Onder de streep heb je dan wel meerdere extra componenten en systemen die ondersteund moeten blijven, onderhoud nodig hebben en hun eigen nukken kunnen hebben. En dan heb ik alsnog niet alle informatie bij elkaar in één systeem.

Voordeel van modulair is dan weer wel dat is component X brak is, component Y in principe gewoon door blijft draaien. Outage van Hass geeft je geen gat in je stroom/gas verbruik (history).
En de belangrijkste gegevens (actueel- en totaalverbruik) kun je zo doorlussen naar HASS zodat je daar in kunt zien. Wil je meer, dan switch je naar de DSMR_reader interface.

Maar nogmaals; wat de beste optie is.. dat bepaal je zelf.

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 12:15:
Laat ik er eens mee beginnen dat ik niet heb gezegd dat DSMR_Reader de betere keuze is (tis wel m'n persoonlijke voorkeur)

Dan behoeft je initiële post nog wat meer nuance denk ik.

Prima dat je "documentatie moet lezen" een dooddoener vind, maar daar hoor je wel mee te beginnen.
Daaruit kun je prima de functionaliteit en dus ook de verschillen halen.
Wil je de grafieken, kosten overzicht en historie? Dan is de keus makkelijke. Wil je alleen data in HomeAssistant, dan ga je voor de Hass integratie.Vervolgens kun je zelf grafieken in elkaar knutselen.
Geen rocket science lijkt me. Wat het beste is, dat is afhankelijke van je eigen wensen/eisen/mogelijkheden.

HASS heeft ook gewoon grafieken en historie, alleen de kosten zou je missen. In de documentatie staat echter niets over alle andere overwegingen die wel degelijk van belang zijn voor de keuze.

Elke seconde data; dat gaat flink in de papieren lopen.
De HASS functies "historie" en "logboek" lezen elke keer je database uit. Hoe groter je database, hoe langer dat gaat duren. Er is wel een 'auto purge' mogelijkheid, maar dan ben je alles van vóór die datum kwijt. Als je verbruik over X periode wilt vergelijken met periode Y.. Niet handig.

Klopt, maar als je een beetje domoticanetwerk hebt met allerlei sensoren dan heb je toch evengoed al een continue stroom van informatie? Als HASS daar serieus moeite mee heeft, is het dan überhaupt wel een geschikt product?

Die afhankelijkheid van 3rd parties, die heb je toch al; waarom niet nog ééntje er bij?
Maar gezien Postgress zelf z'n docker containers beheert, zou ik me niet druk maken over toekomstige ondersteuning.

[...]
Voordeel van modulair is dan weer wel dat is component X brak is, component Y in principe gewoon door blijft draaien. Outage van Hass geeft je geen gat in je stroom/gas verbruik (history).
En de belangrijkste gegevens (actueel- en totaalverbruik) kun je zo doorlussen naar HASS zodat je daar in kunt zien. Wil je meer, dan switch je naar de DSMR_reader interface.

Het principe van modulair is goed inderdaad, maar ik let wel op de afhankelijkheden in de keten.
De keten is nu: ser2net -> HASS. Gaat één van de twee stuk dan heb ik een probleem.
Ga ik voor DSMR in dockjes krijg ik DSMR en de maker van de docker image als extra risico's. Aangezien de DSMR docker images niet door de maker zelf ondersteund worden moet je maar afwachten hoe lang zij daar zin in hebben. In open source land is dat gewoon heel lastig te voorspellen.

Maar als ik het goed begrijp suggereer jij om puur voor de database een container op te zetten? Dat klinkt dan wel weer als een goed idee. Dan zou ik wel DSMR reader direct op de PI moeten installeren, maar daar valt nog wel mee te leven. Of ik doe daar alsnog alleen maar de datalogger.

Maar nogmaals; wat de beste optie is.. dat bepaal je zelf.

Zekers, maar velen hier hebben al meer ervaring met bepaalde zaken dan ik. Lijkt me dus verstandig daar gebruik van te maken toch?

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 12:28:
[...]

Dan behoeft je initiële post nog wat meer nuance denk ik.

Zou kunnen idd

HASS heeft ook gewoon grafieken en historie, alleen de kosten zou je missen. In de documentatie staat echter niets over alle andere overwegingen die wel degelijk van belang zijn voor de keuze.

Je kunt idd grafieken in Hass tevoorschijn toveren. In DSMR_Reader zijn ze 'out of the box' beschikbaar.
En daar is keuze moment 1: gemak of knutselen.

Klopt, maar als je een beetje domoticanetwerk hebt met allerlei sensoren dan heb je toch evengoed al een continue stroom van informatie? Als HASS daar serieus moeite mee heeft, is het dan überhaupt wel een geschikt product?

Hangt wederom van je wensen/eisen af.
Welke data kun je wel/niet missen als HASS ff stuk is, of aan het rebooten is?
En wat is een acceptabel hoeveelheid aan het missen van die data?
Keuze momentje 2: wil je stroom/gas verbuik blijven monitoren als HASS ff niet werkt?

Het principe van modulair is goed inderdaad, maar ik let wel op de afhankelijkheden in de keten.
De keten is nu: ser2net -> HASS. Gaat één van de twee stuk dan heb ik een probleem.
Ga ik voor DSMR in dockjes krijg ik DSMR en de maker van de docker image als extra risico's. Aangezien de DSMR docker images niet door de maker zelf ondersteund worden moet je maar afwachten hoe lang zij daar zin in hebben. In open source land is dat gewoon heel lastig te voorspellen.

Als dat een wens/eis is (hey, weer een keuze momentje ) kun je DSMR_Reader ook op de Pi zetten en de database in een Docker.

Maar als ik het goed begrijp suggereer jij om puur voor de database een container op te zetten? Dat klinkt dan wel weer als een goed idee. Dan zou ik wel DSMR reader direct op de PI moeten installeren, maar daar valt nog wel mee te leven. Of ik doe daar alsnog alleen maar de datalogger.

Dat hangt dus af van je wensen/eisen
Maar volgens mij kan dat idd op die manier (vraag me ff niet hoe )
Ik doe het namlijk net andersom; DSMR_Reader in een container en een normale PostgreSQL installatie
Met alleen de datalogger heb je volgens mij alsnog ergens een volledige installatie nodig.

Zekers, maar velen hier hebben al meer ervaring met bepaalde zaken dan ik. Lijkt me dus verstandig daar gebruik van te maken toch?

Zit ook zeker wat in, maar iedereen zal op basis van eigen ervaring en setup zeggen wat het beste (voor hem/haar) is.
Wil je weten wat volgens "ons" het beste voor jou is, dan is het wel heel erg handig als we weten wat je wensen/eisen en ook mogelijkheden (oa hardware) zijn.

Als je puur en alleen getalletje in HASS wilt zien en data-retentie je niet boeit, dan is DSMR_Reader niet de beste keus. Wil je inzicht in kosten en toffe grafiekjes, dan weer wel.

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 13:05:
Je kunt idd grafieken in Hass tevoorschijn toveren. In DSMR_Reader zijn ze 'out of the box' beschikbaar.
En daar is keuze moment 1: gemak of knutselen.

Die snap ik niet. In HASS had ik ook gewoon direct grafieken, in je geschiedenis of als widget als je dat wilt. Wat moet je daarvoor knutselen dan?

Buiten het feit dat in de basis eerst alles aan elkaar geknutseld moet worden natuurlijk.

Hangt wederom van je wensen/eisen af.
Welke data kun je wel/niet missen als HASS ff stuk is, of aan het rebooten is?
En wat is een acceptabel hoeveelheid aan het missen van die data?
Keuze momentje 2: wil je stroom/gas verbuik blijven monitoren als HASS ff niet werkt?

Een gaatje is geen ramp. DSMR kan net zo goed stuk zijn of even rebooten als HASS dat kan hebben, daar zie ik geen verschil.
Daarnaast zou het ook kunnen dat m'n NAS moet rebooten en dan moeten sowieso alle containers plat.

Toch heb je wel iets getriggerd. Ik had namelijk recent besloten dat mijn domoticasoftware niet meer te veel zelf moet gaan regelen. In die zin ben ik van visie veranderd.
Ik merk namelijk dat het toch gewoon knutselwerk blijft, of je nu wilt of niet. Ik wil dus componenten die goed zijn in waar ze voor gemaakt zijn, en binnen dat doel autonoom kunnen opereren. (denk aan licht -> Hue, verwarming -> Honeywell, media -> Harmony, zwave -> euh???)
De domoticasoftware, in dit geval dan HASS, is dan een overkoepelende dirigent die wat extraatjes kan bieden en meer inzicht kan geven. Hij is echter puur een extraatje en niet noodzakelijk voor de werking van de basis.

Neem ik mijn vernieuwde visie erbij dan heb je gelijk, dan moet ik DSRM nemen omdat die goed is in p1 uitlezen en die zoveel mogelijk autonoom laten werken.

Als dat een wens/eis is (hey, weer een keuze momentje ) kun je DSMR_Reader ook op de Pi zetten en de database in een Docker.


[...]
Dat hangt dus af van je wensen/eisen
Maar volgens mij kan dat idd op die manier (vraag me ff niet hoe )
Ik doe het namlijk net andersom; DSMR_Reader in een container en een normale PostgreSQL installatie
Met alleen de datalogger heb je volgens mij alsnog ergens een volledige installatie nodig.

Klopt, maar die zou dan op m'n NAS kunnen draaien waardoor de meterkast PI puur een doorgeefluik zou blijven.

Zit ook zeker wat in, maar iedereen zal op basis van eigen ervaring en setup zeggen wat het beste (voor hem/haar) is.
Wil je weten wat volgens "ons" het beste voor jou is, dan is het wel heel erg handig als we weten wat je wensen/eisen en ook mogelijkheden (oa hardware) zijn.

Als je puur en alleen getalletje in HASS wilt zien en data-retentie je niet boeit, dan is DSMR_Reader niet de beste keus. Wil je inzicht in kosten en toffe grafiekjes, dan weer wel.

Ik heb een aantal wensen/kaders:
• niet te complex, goed onderhoudbaar. (dockjes helpen daarbij omdat je software en data/configuratie kunt scheiden en zij de updates regelen)
• historie wil ik graag langere tijd kunnen bewaren, ook op enig detailniveau (niet alleen voor p1, ook voor vermogen uit zwave)
• goede verwachting qua continuïteit. Dus githubjes kunnen wel, mits het onderhouden wordt. Het sterft van de één keer bouwen, nooit meer fixen, projecten. Daar word ik niet blij van.
• mijn NAS is de primaire host, dus dat blijft te allen tijde de SPoF. De verschillende PI's die ik heb houd ik het liefst zo simpel en lichtgewicht mogelijk.
• HASS heeft inzicht in alle componenten, maar hoeft niet alles te weten van die componenten. Hij moet wel een regisseur kunnen blijven zonder al te veel knutselwerk.

Sowieso heb ik nog wel een hoop te leren wat HASS betreft. Het hele Zwave verhaal is ook al een hel geweest om aan de praat te krijgen.

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 13:34:
Die snap ik niet. In HASS had ik ook gewoon direct grafieken, in je geschiedenis of als widget als je dat wilt. Wat moet je daarvoor knutselen dan?

okay, ik zal dat nuance-dingetje eens proberen
Ik bedoelde de wat meer gelikte en uitgebreidere grafieken. Die in HASS zijn vrij simpel en beperkt en voor een widget moet je weer (extra) knutselen.
Die geschiedenis functie icm de HASS integratie was voor mij dus een afknapper. Er wordt, zeker met DSMR5, zoveel data in je HASS database gedumpt dat het ophalen van de geschiedenis na een paar uur al tergend traag is. Ook al is het niet vaak, maar als ik de geschiedenis ff in wil zien wil ik niet een kwartier moeten wachten voordat alles geladen is
Je kunt wel regelmatig purgen of de data niet opslaan, maar de vraag is of dat dan wel weer matcht met je eisen/wensen.

Toch heb je wel iets getriggerd.

WhoopWhoop!

Ik had namelijk recent besloten dat mijn domoticasoftware niet meer te veel zelf moet gaan regelen. In die zin ben ik van visie veranderd.
Ik merk namelijk dat het toch gewoon knutselwerk blijft, of je nu wilt of niet. Ik wil dus componenten die goed zijn in waar ze voor gemaakt zijn, en binnen dat doel autonoom kunnen opereren. (denk aan licht -> Hue, verwarming -> Honeywell, media -> Harmony, zwave -> euh???)
De domoticasoftware, in dit geval dan HASS, is dan een overkoepelende dirigent die wat extraatjes kan bieden en meer inzicht kan geven. Hij is echter puur een extraatje en niet noodzakelijk voor de werking van de basis.

Dan zitten we aardig op dezelfde lijn
Voor mij is HASS het centrale punt wat alles aanstuurt en waar de data die ik (zoveel mogelijk) realtime in wil zien verzamelt word.
DSMR_Reader stuurt het actuele en totale verbruik van gas/elektra door naar HASS, maar HASS schrijft het niet weg naar z'n eigen database.
Voor mij is dat een win-win; Ik heb alle data zichtbaar in één scherm/applicatie (HASS) en voor gedetailleerde informatie en het kunnen vergelijken van periodes (week/maand/jaar) maak ik een uitstapje naar de DSMR_Reader interface.

Neem ik mijn vernieuwde visie erbij dan heb je gelijk, dan moet ik DSMR nemen omdat die goed is in p1 uitlezen en die zoveel mogelijk autonoom laten werken.
[...]
Klopt, maar die zou dan op m'n NAS kunnen draaien waardoor de meterkast PI puur een doorgeefluik zou blijven.

Correctomundo

Ik heb een aantal wensen/kaders:
• niet te complex, goed onderhoudbaar. (dockjes helpen daarbij omdat je software en data/configuratie kunt scheiden en zij de updates regelen)
• historie wil ik graag langere tijd kunnen bewaren, ook op enig detailniveau (niet alleen voor p1, ook voor vermogen uit zwave)
• goede verwachting qua continuïteit. Dus githubjes kunnen wel, mits het onderhouden wordt. Het sterft van de één keer bouwen, nooit meer fixen, projecten. Daar word ik niet blij van.
• mijn NAS is de primaire host, dus dat blijft te allen tijde de SPoF. De verschillende PI's die ik heb houd ik het liefst zo simpel en lichtgewicht mogelijk.
• HASS heeft inzicht in alle componenten, maar hoeft niet alles te weten van die componenten. Hij moet wel een regisseur kunnen blijven zonder al te veel knutselwerk.

DSMR_Reader zelf is een behoorlijk volwassen project dat regelmatig updates krijgt. En ook al zou het stil komen te liggen; zolang de DSMR standaard niet aangepast of uitgefaseerd wordt blijft het wel werken

De container van Xirixiz is meestal redelijk snel bij met nieuwe DSMR_Reader versies; ff nieuwe image downloaden, restarten en gaan met die banaan.

DSMR_Reader heeft een prima lange termijn data retentie mogelijkheid zonder dat je DB over z'n nek gaat.
En DSMR_Reader kan actueel/totaal verbruik doorgeven aan HASS zodat je daar ook (beperkt) inzicht hebt.

Met de HASS integration heb je weliswaar niet het hele container verhaal + afhankelijkheden, maar met name de lange termijn data historie is een dingetje. Alleen daarom valt ie al af.
Dus ja, voor jou lijkt me DSMR_Reader de beste keus

[Repsect]

Driek schreef op woensdag 29 januari 2020 @ 20:32:
[...]

Die kleurtjes van scenes krijg ik ook niet voor elkaar. Volgens mij omdat ze niet echt een aan status hebben.
Mocht je een oplossing hebben hoor ik het graag.

Het is uiteindelijk gelukt met input booleans en Custom-UI.

Handleiding voor de geïnteresseerden:

1. Copy state-card-custom-ui.html,state-card-custom-ui.html.gz, state-card-custom-ui-es5.html en state-card-custom-ui-es5.html.gz naar /www/custom-ui folder zoals beschreven staat in de manual van Custom-UI.
2. Load custom-ui in je configuration.yaml:
   
   YAML:
   

   customizer:
     custom_ui: local

3. Maak input booleans aan voor al je scenes. Ik heb 5 scenes (uit, gedimd, normaal, extra en maximaal). Plaats de input booleans ook in je configuration.yaml file:
   
   YAML:
   

   input_boolean:
     scene_uit:
       name: Uit
       initial: off
       icon: mdi:lightbulb-off-outline
     scene_gedimd:
       name: Gedimd
       initial: off
       icon: mdi:candle
     scene_normaal:
       name: Normaal
       initial: off
       icon: mdi:lightbulb-outline
     scene_extra:
       name: Extra
       initial: off
       icon: mdi:lightbulb-on-outline
     scene_maximaal:
       name: Maximaal
       initial: off
       icon: mdi:car-light-high

4. In je scenes.yaml file maak je je scenes aan en zorg je dat de juiste input booleans aan gezet worden en de andere uit bij activatie van de betreffende scene:
   
   YAML:
   

   # Uit
   - name: Uit
     entities:
       group.binnenverlichting: off
       input_boolean.scene_uit: on
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Gedimd
   - name: Gedimd
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 1
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 1
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 25    # 10%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 1
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: on
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Normaal
   - name: Normaal
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 51    # 20%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 51    # 20%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 64    # 25%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 64    # 25%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: on
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Extra
   - name: Extra
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 102   # 40%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 128   # 50%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 166   # 65%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 102   # 40%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: on
       input_boolean.scene_maximaal: off
   
   # Maximaal
   - name: Maximaal
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 255   # 100%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: on

5. In de customize.yaml file maak je conditions voor de icoon kleurtjes (geel bij aan, donkerblauw bij uit):
   
   YAML:
   

   input_boolean.scene_uit:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_gedimd:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_normaal:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_extra:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_maximaal:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";

6. In ui-lovelace.yaml maak je vervolgens een Glance card waarbij je als entity de input booleans gebruikt. Met de tap action roep je de scene aan:
   
   YAML:
   

   - type: glance
     title: Scenes
     show_state: false
     entities:
       - entity: input_boolean.scene_uit
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.uit
       - entity: input_boolean.scene_gedimd
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.gedimd
       - entity: input_boolean.scene_normaal
         tap_action: 
           action: call-service
            service: scene.turn_on
            service_data:
              entity_id: scene.normaal
       - entity: input_boolean.scene_extra
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.extra
       - entity: input_boolean.scene_maximaal
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.maximaal

Het resultaat:


Uiteraard kan je dit allemaal aanpassen naar je eigen scenes en kleurtjes .

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 14:14:
[...]
okay, ik zal dat nuance-dingetje eens proberen
Ik bedoelde de wat meer gelikte en uitgebreidere grafieken. Die in HASS zijn vrij simpel en beperkt en voor een widget moet je weer (extra) knutselen.

Welnee, met drie klikken heb je hem. En als je meer eisen hebt gewoon even YAML'en. Daar ontkom je met HASS toch al niet aan ben ik onderhand achter.

Die geschiedenis functie icm de HASS integratie was voor mij dus een afknapper. Er wordt, zeker met DSMR5, zoveel data in je HASS database gedumpt dat het ophalen van de geschiedenis na een paar uur al tergend traag is. Ook al is het niet vaak, maar als ik de geschiedenis ff in wil zien wil ik niet een kwartier moeten wachten voordat alles geladen is
Je kunt wel regelmatig purgen of de data niet opslaan, maar de vraag is of dat dan wel weer matcht met je eisen/wensen.

Kan je ook selectief data verwijderen? Ik heb namelijk best wat vervuiling in m'n geschiedenis/log en snel is hij sowieso al niet vind ik. Als DSMR hem dan nóg trager gaat maken moet ik daar wel iets mee.

Dan zitten we aardig op dezelfde lijn
Voor mij is HASS het centrale punt wat alles aanstuurt en waar de data die ik (zoveel mogelijk) realtime in wil zien verzamelt word.
DSMR_Reader stuurt het actuele en totale verbruik van gas/elektra door naar HASS, maar HASS schrijft het niet weg naar z'n eigen database.
Voor mij is dat een win-win; Ik heb alle data zichtbaar in één scherm/applicatie (HASS) en voor gedetailleerde informatie en het kunnen vergelijken van periodes (week/maand/jaar) maak ik een uitstapje naar de DSMR_Reader interface.

Dan moet ik nog even uitzoeken hoe je dat voorkomt, staat vast in de documentatie.

DSMR_Reader zelf is een behoorlijk volwassen project dat regelmatig updates krijgt. En ook al zou het stil komen te liggen; zolang de DSMR standaard niet aangepast of uitgefaseerd wordt blijft het wel werken

De container van Xirixiz is meestal redelijk snel bij met nieuwe DSMR_Reader versies; ff nieuwe image downloaden, restarten en gaan met die banaan.

DSMR_Reader heeft een prima lange termijn data retentie mogelijkheid zonder dat je DB over z'n nek gaat.
En DSMR_Reader kan actueel/totaal verbruik doorgeven aan HASS zodat je daar ook (beperkt) inzicht hebt.

Met de HASS integration heb je weliswaar niet het hele container verhaal + afhankelijkheden, maar met name de lange termijn data historie is een dingetje. Alleen daarom valt ie al af.
Dus ja, voor jou lijkt me DSMR_Reader de beste keus

DSMR Reader zelf ben ik ook niet zo bang voor, meer de 3rd party tooltjes. Zo had ik die van Xirixiz ook al gevonden, maar zag meteen een fork van ualex73 die dan beter up to date zou zijn. Met dat soort projecten is het altijd maar afwachten wat het doet.
Daarnaast heb ik ook slechte ervaringen met het native installeren van software op de Pi (domoticz, pihole). Ik loop toch best vaak tegen issues aan dat het niet meer vlekkeloos werkt. Kan ook aan mij liggen hoor, maar ik heb het gevoel dat als ik aan het OS niets hoef te doen en verder alleen docker draai het toch allemaal stabieler zou moeten blijven.

Het voordeel van een docker is wel weer dat het makkelijker zou moeten zijn om de versies gelijk te houden. Je kunt gewoon images wisselen wanneer het je uit komt zonder configuratie of dataverlies. Ben alleen huiverig wat het met je database doet als je later toch een keer van image moet wisselen.

[Driek]

Repsect schreef op dinsdag 4 februari 2020 @ 14:24:
[...]


Het is uiteindelijk gelukt met input booleans en Custom-UI.

Handleiding voor de geïnteresseerden:

1. Copy state-card-custom-ui.html,state-card-custom-ui.html.gz, state-card-custom-ui-es5.html en state-card-custom-ui-es5.html.gz naar /www/custom-ui folder zoals beschreven staat in de manual van Custom-UI.
2. Load custom-ui in je configuration.yaml:
   
   YAML:
   

   customizer:
     custom_ui: local

3. Maak input booleans aan voor al je scenes. Ik heb 5 scenes (uit, gedimd, normaal, extra en maximaal). Plaats de input booleans ook in je configuration.yaml file:
   
   YAML:
   

   input_boolean:
     scene_uit:
       name: Uit
       initial: off
       icon: mdi:lightbulb-off-outline
     scene_gedimd:
       name: Gedimd
       initial: off
       icon: mdi:candle
     scene_normaal:
       name: Normaal
       initial: off
       icon: mdi:lightbulb-outline
     scene_extra:
       name: Extra
       initial: off
       icon: mdi:lightbulb-on-outline
     scene_maximaal:
       name: Maximaal
       initial: off
       icon: mdi:car-light-high

4. In je scenes.yaml file maak je je scenes aan en zorg je dat de juiste input booleans aan gezet worden en de andere uit bij activatie van de betreffende scene:
   
   YAML:
   

   # Uit
   - name: Uit
     entities:
       group.binnenverlichting: off
       input_boolean.scene_uit: on
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Gedimd
   - name: Gedimd
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 1
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 1
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 25    # 10%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 1
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: on
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Normaal
   - name: Normaal
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 51    # 20%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 51    # 20%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 64    # 25%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 64    # 25%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: on
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: off
   
   # Extra
   - name: Extra
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 102   # 40%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 128   # 50%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 166   # 65%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 102   # 40%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: on
       input_boolean.scene_maximaal: off
   
   # Maximaal
   - name: Maximaal
     entities:
       light.fibaro_system_fgd212_dimmer_2_level_10:   # Eettafel
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_8:    # Kookeiland
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_4:    # Trap
         state: on
         brightness: 255   # 100%
       light.fibaro_system_fgd212_dimmer_2_level_6:    # Woonkamer
         state: on
         brightness: 255   # 100%
       input_boolean.scene_uit: off
       input_boolean.scene_gedimd: off
       input_boolean.scene_normaal: off
       input_boolean.scene_extra: off
       input_boolean.scene_maximaal: on

5. In de customize.yaml file maak je conditions voor de icoon kleurtjes (geel bij aan, donkerblauw bij uit):
   
   YAML:
   

   input_boolean.scene_uit:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_gedimd:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_normaal:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_extra:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";
   input_boolean.scene_maximaal:
     templates:
       icon_color: >
         if (state === 'on') return "rgb(253, 216, 53)";
         return "rgb(68, 114, 157)";

6. In ui-lovelace.yaml maak je vervolgens een Glance card waarbij je als entity de input booleans gebruikt. Met de tap action roep je de scene aan:
   
   YAML:
   

   - type: glance
     title: Scenes
     show_state: false
     entities:
       - entity: input_boolean.scene_uit
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.uit
       - entity: input_boolean.scene_gedimd
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.gedimd
       - entity: input_boolean.scene_normaal
         tap_action: 
           action: call-service
            service: scene.turn_on
            service_data:
              entity_id: scene.normaal
       - entity: input_boolean.scene_extra
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.extra
       - entity: input_boolean.scene_maximaal
         tap_action: 
           action: call-service
           service: scene.turn_on
           service_data:
             entity_id: scene.maximaal

Het resultaat:
[Afbeelding]

Uiteraard kan je dit allemaal aanpassen naar je eigen scenes en kleurtjes .

nice, zal het eens bekijken.
En je kan nu op de icoontjes klikken zodat de scnenes "aan gaan"

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 14:48:
Kan je ook selectief data verwijderen? Ik heb namelijk best wat vervuiling in m'n geschiedenis/log en snel is hij sowieso al niet vind ik. Als DSMR hem dan nóg trager gaat maken moet ik daar wel iets mee.

Selectief data verwijderen zal met het handje, in de database zelf, moeten voor zover ik weet.
DSMR gooit dus in principe elke seconde data in de database. Als je al DSMR_Reader + PostgreSQL hebt draaien hoeft het (voor mij) niet in de HASS database; ik zat binnen no-time op 15GB!

Dan moet ik nog even uitzoeken hoe je dat voorkomt, staat vast in de documentatie.

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

DSMR Reader zelf ben ik ook niet zo bang voor, meer de 3rd party tooltjes. Zo had ik die van Xirixiz ook al gevonden, maar zag meteen een fork van ualex73 die dan beter up to date zou zijn.

Xirixiz zit inmiddels op versie 3.2.0, ualex73 op 3.1.1
Maar het is dus geen "tooltje" heh, alleen de 'core' applicatie zelf, in een container. Zit weinig hocus-pocus omheen.

Met dat soort projecten is het altijd maar afwachten wat het doet.
Daarnaast heb ik ook slechte ervaringen met het native installeren van software op de Pi (domoticz, pihole). Ik loop toch best vaak tegen issues aan dat het niet meer vlekkeloos werkt. Kan ook aan mij liggen hoor, maar ik heb het gevoel dat als ik aan het OS niets hoef te doen en verder alleen docker draai het toch allemaal stabieler zou moeten blijven.

Het voordeel van een docker is wel weer dat het makkelijker zou moeten zijn om de versies gelijk te houden. Je kunt gewoon images wisselen wanneer het je uit komt zonder configuratie of dataverlies. Ben alleen huiverig wat het met je database doet als je later toch een keer van image moet wisselen.

Ik heb niet het idee dat de ondersteuning snel weg zal vallen, en an sich zou je nog jaren met de huidige versie kunnen draaien. Of als het je echt te lang duurt kun je altijd nog ff aan de studie om zelf containers te maken

Qua config zou je met het wisselen van een image (van xirixiz naar ualex73 en vice versa) mogelijk wat kwijt kunnen raken. Maar zolang de core gewoon DSMR_reader is, zal je je database gewoon kunnen blijven gebruiken, inclusief de config die daar in staat. Het is namelijk de applicatie die dit regelt, niet de container.

En als je de DSMR_reader container update, dan wél de changelog van DSMR_Reader lezen!

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 15:04:
Selectief data verwijderen zal met het handje, in de database zelf, moeten voor zover ik weet.
DSMR gooit dus in principe elke seconde data in de database. Als je al DSMR_Reader + PostgreSQL hebt draaien hoeft het (voor mij) niet in de HASS database; ik zat binnen no-time op 15GB!


[...]

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

Grappig, je kan hem ook gewoon aan Postgress hangen dus zit je netto weer op hetzelfde.
Overigens zie ik dat hij automatisch al zou moeten purgen volgens de default, dat is vreemd want ik had het gevoel dat je prima een paar weken terug kon kijken.

Overigens is het datamodel dan gewoon heel slecht ontworpen als het met een beetje meetpunten al naar 15GB knalt. Dan is hij inderdaad gewoon niet berekend op metingen maar echt puur als logboek bedoeld.

[...]

Xirixiz zit inmiddels op versie 3.2.0, ualex73 op 3.1.1
Maar het is dus geen "tooltje" heh, alleen de 'core' applicatie zelf, in een container. Zit weinig hocus-pocus omheen.

De wijze waarop het geïnstalleerd is en reageert op bepaalde parameters laat wel wat verschillen zien. In die zin is het wel iets meer dan alleen maar DSMR in een wrapper. Maar goed, als ik mij zou verdiepen zou ik ook m'n eigen image kunnen maken.
Het toont echter wel meteen aan hoe dat gaat met die projecten. Iemand beweert het beter te doen maar dat valt dan toch ineens wel weer tegen als je hem al een tijdje moet onderhouden.

[...]

Ik heb niet het idee dat de ondersteuning snel weg zal vallen, en an sich zou je nog jaren met de huidige versie kunnen draaien. Of als het je echt te lang duurt kun je altijd nog ff aan de studie om zelf containers te maken

Qua config zou je met het wisselen van een image (van xirixiz naar ualex73 en vice versa) mogelijk wat kwijt kunnen raken. Maar zolang de core gewoon DSMR_reader is, zal je je database gewoon kunnen blijven gebruiken, inclusief de config die daar in staat. Het is namelijk de applicatie die dit regelt, niet de container.

Sowieso ook maar eens kijken naar die opslag van HASS. Het lijkt nu gewoon sqlite te zijn en dat is voor het steviger DB-werk natuurlijk minder geschikt. Kan ook al zou ik DSMR los trekken evengoed lonen om daar eens te optimaliseren.

En als je de DSMR_reader container update, dan wél de changelog van DSMR_Reader lezen!

duh

[Nnoitra]

Gonadan schreef op dinsdag 4 februari 2020 @ 15:34:

Grappig, je kan hem ook gewoon aan Postgress hangen dus zit je netto weer op hetzelfde.
Overigens zie ik dat hij automatisch al zou moeten purgen volgens de default, dat is vreemd want ik had het gevoel dat je prima een paar weken terug kon kijken.

Overigens is het datamodel dan gewoon heel slecht ontworpen als het met een beetje meetpunten al naar 15GB knalt. Dan is hij inderdaad gewoon niet berekend op metingen maar echt puur als logboek bedoeld.

Even wat verduidelijken lijkt me nu wel ff handig.
Ja, je kunt HASS idd ook naar een PostgreSQL laten schrijven maar toch is dat net ff wat anders.
Die 15GB had ik toen ik de HASS integration DSMR gebruikte. Die schrijft gewoon elke seconde data weg en je hebt nogal wat seconden per dag, laat staan in 10 dagen

DSMR_Reader daarentegen schrijft initieel dezelfde shitload aan data weg, maar kan daar door de retentie functionaliteit beter mee omgaan om het niet uit de klauwen te laten lopen.
Na <x tijd> gooit ie wel een shitload weg, maar belangrijke meetpunten (een paar per uur geloof ik) blijven bewaard zodat je met 'minimale' middelen een historisch overzicht hebt en kunt houden.

HASS gooit dus alles ouder dan <x tijd> weg, maar tot die tijd is het explosief groeien.

De wijze waarop het geïnstalleerd is en reageert op bepaalde parameters laat wel wat verschillen zien. In die zin is het wel iets meer dan alleen maar DSMR in een wrapper.

Qua docker-compose bestand ziet het er aardig identiek uit. Xirixiz is alleen wat verder met het meegeven van environment variables. En dat zijn weer variabelen die 'gewoon' in DSMR_Reader zitten (en die je anders handmatig zou moeten zoeken/aanpassen). Dus nog steeds geen extra eigen hocus-pocus er omheen

Sowieso ook maar eens kijken naar die opslag van HASS. Het lijkt nu gewoon sqlite te zijn en dat is voor het steviger DB-werk natuurlijk minder geschikt. Kan ook al zou ik DSMR los trekken evengoed lonen om daar eens te optimaliseren.

Afhankelijk van de hoeveel data die je wilt bewaren en hoe snel het binnen komt kan SQLite idd prima zijn.
DSMR data door HASS zelf in z'n eigen SQLite database te laten schrijven, da's wellicht iets minder optimaal. Maar HASS dat laten doen zou ik dus sowieso afraden.

[balk]

Gonadan schreef op dinsdag 4 februari 2020 @ 15:34:
[...]

Grappig, je kan hem ook gewoon aan Postgress hangen dus zit je netto weer op hetzelfde.
Overigens zie ik dat hij automatisch al zou moeten purgen volgens de default, dat is vreemd want ik had het gevoel dat je prima een paar weken terug kon kijken.

Overigens is het datamodel dan gewoon heel slecht ontworpen als het met een beetje meetpunten al naar 15GB knalt. Dan is hij inderdaad gewoon niet berekend op metingen maar echt puur als logboek bedoeld.

[...]

De wijze waarop het geïnstalleerd is en reageert op bepaalde parameters laat wel wat verschillen zien. In die zin is het wel iets meer dan alleen maar DSMR in een wrapper. Maar goed, als ik mij zou verdiepen zou ik ook m'n eigen image kunnen maken.
Het toont echter wel meteen aan hoe dat gaat met die projecten. Iemand beweert het beter te doen maar dat valt dan toch ineens wel weer tegen als je hem al een tijdje moet onderhouden.

[...]

Sowieso ook maar eens kijken naar die opslag van HASS. Het lijkt nu gewoon sqlite te zijn en dat is voor het steviger DB-werk natuurlijk minder geschikt. Kan ook al zou ik DSMR los trekken evengoed lonen om daar eens te optimaliseren.

[...]

duh

Ik ben recent van de ualex74 naar de xirixiz docker overgestapt ivm met een environment dingetje. Omdat ik een externe postgres db gebruik én omdat dsmr-reader zijn settings ook in die db opslaat was dat 5 minuten werk. Dus, als 1 van de 2 er mee kapt ben je zo over.

Dsmr-reader heeft retentie functies die toegespitst zijn op verbruiksdata. Op de lange termijn is het vooral relevant hoeveel je op een bepaalde dag hebt gebruikt, niet zo zeer in welk uur of minuut. Hass.core schoont dat niet zo mooi op. Die gooit alles na x tijd weg. Andere relevante lange termijn data bewaar ik in influxdb.

[martinvdm]

Inmiddels lees ik a pagina’s over DSMR reader. Ik gebruik het al jaren en ben het met @Nnoitra volledig eens. Ook ik draai in Docker de Xirixiz image. Dit draait top. Rechtstreeks in home assistant resulteerde bij mij ook in gb’s logging db van HA. Maargoed; laten we dit topic wel gebruiken voor Home Assistant en niet er een DSMR Reader topic van maken

[Gonadan]

Nnoitra schreef op dinsdag 4 februari 2020 @ 16:36:
Even wat verduidelijken lijkt me nu wel ff handig.
Ja, je kunt HASS idd ook naar een PostgreSQL laten schrijven maar toch is dat net ff wat anders.
Die 15GB had ik toen ik de HASS integration DSMR gebruikte. Die schrijft gewoon elke seconde data weg en je hebt nogal wat seconden per dag, laat staan in 10 dagen

DSMR_Reader daarentegen schrijft initieel dezelfde shitload aan data weg, maar kan daar door de retentie functionaliteit beter mee omgaan om het niet uit de klauwen te laten lopen.
Na <x tijd> gooit ie wel een shitload weg, maar belangrijke meetpunten (een paar per uur geloof ik) blijven bewaard zodat je met 'minimale' middelen een historisch overzicht hebt en kunt houden.

HASS gooit dus alles ouder dan <x tijd> weg, maar tot die tijd is het explosief groeien.

Dan komt het er dus op neer dat HASS überhaupt geen rollup mechanisme in de data heeft, dan klopt mijn eerdere conclusie wel dat het alleen maar als logboek bedoeld is.
Er zijn echter ook best een hoop sensoren waarvan langere termijn trends wou willen zien, bijvoorbeeld temperatuur of stroomverbruik. Hoe los je dat dan op in HASS?
Die InfluxDB integratie waar @balk het over heeft ziet er dan wel interessant uit, maar is dat ook de juiste keuze?

Hoe meer ik met HASS doe des te vaker ben ik eerst teleurgesteld dat out of the box zo weinig kan/goed geregeld is. Maar ook hoe meer ik dan in tweede instantie erachter kom dat er componenten beschikbaar zijn die het beter kunnen oplossen dan andere tools out of the box hebben. Herkenbaar?

Het enige waar ik dan wel huiverig voor ben is weer die keten van afhankelijkheden. Straks heb ik tien dockjes draaien met allemaal stukjes HASS.

[Timpje]

Imperial Guard schreef op maandag 3 februari 2020 @ 21:18:
Laatste hand kunnen leggen op mijn energie verbruiken, gelukkig met wat hulp van een collega lees ik o.a. mijn puls van mijn watermeter uit maar daarbij weet ik ook wanneer de laatste puls was in ms.

In een template sensor binnen Home Assistant reken ik het uit naar l/min en l/h.
Iedere puls is bij mij 1 liter.

Zo heb ik een overzicht per dag, per week, per maand, totaal en contract periode van energie en water

[Afbeelding]

[Afbeelding]

[Afbeelding]

Mag ik vragen welke watermeter jij thuis hebt en welke hadware je gebruikt hebt voor het uitlezen van de 1 liter puls? Ik heb een watermeter van Vitens (Sensus 620), die bied helaas niet een "mooie" mogelijkheid tot uitlezen. Nu kwam ik dit topic tegen: https://www.circuitsonline.net/forum/view/message/1484447#1484447. Vroeg mij af of jij ook zo iets gebruikt. Wil eigenlijk ook graag de watermeter in gaan lezen, maar ben er nog niet helemaal uit hoe ik dat ga doen ...

[martinvdm]

Gonadan schreef op dinsdag 4 februari 2020 @ 19:18:
[...]

Dan komt het er dus op neer dat HASS überhaupt geen rollup mechanisme in de data heeft, dan klopt mijn eerdere conclusie wel dat het alleen maar als logboek bedoeld is.
Er zijn echter ook best een hoop sensoren waarvan langere termijn trends wou willen zien, bijvoorbeeld temperatuur of stroomverbruik. Hoe los je dat dan op in HASS?
Die InfluxDB integratie waar @balk het over heeft ziet er dan wel interessant uit, maar is dat ook de juiste keuze?

Hoe meer ik met HASS doe des te vaker ben ik eerst teleurgesteld dat out of the box zo weinig kan/goed geregeld is. Maar ook hoe meer ik dan in tweede instantie erachter kom dat er componenten beschikbaar zijn die het beter kunnen oplossen dan andere tools out of the box hebben. Herkenbaar?

Het enige waar ik dan wel huiverig voor ben is weer die keten van afhankelijkheden. Straks heb ik tien dockjes draaien met allemaal stukjes HASS.

Home assistant is naar mijn idee nooit gebouwd om een lange termijn logging database te zijn. Influxdb is een time series database wat veel beter om gaat dit soort data. Ik gebruik het ook en dit werkt naast de interne database van ha.

[Gonadan]

martinvdm schreef op dinsdag 4 februari 2020 @ 19:42:
Home assistant is naar mijn idee nooit gebouwd om een lange termijn logging database te zijn. Influxdb is een time series database wat veel beter om gaat dit soort data. Ik gebruik het ook en dit werkt naast de interne database van ha.

Dat zou goed kunnen hoor, het is gewoon even wennen. Ik kom van Domoticz die al dat soort dingen er standaard wel in had, maar ook weer met beperkingen.
De leer-/knutselcurve van HASS lijkt wat dat betreft wat steviger.

[Meelobee]

Repsect schreef op dinsdag 4 februari 2020 @ 14:24:
[...]

Het is uiteindelijk gelukt met input booleans en Custom-UI.

Repsect! Erg nice, maakt Scenes net weer wat beter! Dank voor de uitgebreide uitleg

[Meelobee]

Meelobee schreef op maandag 3 februari 2020 @ 23:50:
[...]
Een betere variant, geeft op de knop 'Vandaag' & 'Morgen' aan, in plaats van 1 dag & 0 dagen.

Voor de volledigheid hier de uitleg voor de volledige card:

Benodigd:

Garbage Collection component - via [HACS] of [Github]
Card Templater - via [HACS] of [Github]
Card-Mod - via [HACS] of [Github] (De 'mod-card' optie gebruiken vanwege de horizontal-stack, zie documentatie.)

code:

card:
  cards:
    - card:
        entity: sensor.papier_2
        name_template: >-
          {%- if is_state("sensor.papier_2", "0")%} Vandaag {% elif
          is_state("sensor.papier_2", "1")%} Morgen {% else %} {{
          states.sensor.papier_2.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/papier.png
          '1': /local/images/trash_card/papier.png
          '2': /local/images/trash_card/papier_bw.png
        type: picture-entity
      entities:
        - sensor.papier_2
      type: 'custom:card-templater'
    - card:
        entity: sensor.gft_rest
        name_template: >-
          {%- if is_state("sensor.gft_rest", "0")%} Vandaag {% elif
          is_state("sensor.gft_rest", "1")%} Morgen {% else %} {{
          states.sensor.gft_rest.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/gft_rest.png
          '1': /local/images/trash_card/gft_rest.png
          '2': /local/images/trash_card/gft_rest_bw.png
        type: picture-entity
      entities:
        - sensor.gft_rest
      type: 'custom:card-templater'
    - card:
        entity: sensor.pmd
        name_template: >-
          {%- if is_state("sensor.pmd", "0")%} Vandaag {% elif
          is_state("sensor.pmd", "1")%} Morgen {% else %} {{
          states.sensor.pmd.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/pmd.png
          '1': /local/images/trash_card/pmd.png
          '2': /local/images/trash_card/pmd_bw.png
        type: picture-entity
      entities:
        - sensor.pmd
      type: 'custom:card-templater'
  type: horizontal-stack
style: |
  ha-card {
    radius: 10px;
    text-align: center
  }
type: 'custom:mod-card'

Geeft dit als resultaat:


De afbeeldingen zijn in kleur als de status morgen of vandaag is, anders zijn ze zwart/wit.

[ANdrode]

Gonadan schreef op dinsdag 4 februari 2020 @ 19:55:
[...]
Dat zou goed kunnen hoor, het is gewoon even wennen. Ik kom van Domoticz die al dat soort dingen er standaard wel in had, maar ook weer met beperkingen.
De leer-/knutselcurve van HASS lijkt wat dat betreft wat steviger.

Home assistant zit meer richting (set van) microservice dan richting monolith.

offtopic:
Elke instantie van een platform is een server onder een microkernel

[Imperial Guard]

Timpje schreef op dinsdag 4 februari 2020 @ 19:39:
[...]


Mag ik vragen welke watermeter jij thuis hebt en welke hadware je gebruikt hebt voor het uitlezen van de 1 liter puls? Ik heb een watermeter van Vitens (Sensus 620), die bied helaas niet een "mooie" mogelijkheid tot uitlezen. Nu kwam ik dit topic tegen: https://www.circuitsonline.net/forum/view/message/1484447#1484447. Vroeg mij af of jij ook zo iets gebruikt. Wil eigenlijk ook graag de watermeter in gaan lezen, maar ben er nog niet helemaal uit hoe ik dat ga doen ...

Ik heb zelf ook een Sensus 620 watermeter, deze watermeter heeft een mooie metalen plaatje wat bij water afname roteert. Iedere rotatie is 1 liter.

Ik vang de pulsen af met een 24V industriële naderingsschakelaar. Aangezien ik een 24V voeding in mijn schakelkastje heb voor de niveau meting in de put was de keuze dus makkelijk gemaakt voor 24V.

Natuurlijk kan een ESP geen 24V aan en schakel ik een solidstate relais (elektronisch relais zonder mechanisch contact wat erg snel kan schakelen en veel schakelingen aankan) het relais voed ik met de - van de 24V op de A2 en de A1 voed ik met het schakeldraad wat vanaf de naderingsschakelaar komt.

Het schakel contact 13/14 van het relais ligt aan de GND en de D1 van mijn Wemos mini.

Iedere opgaande flank tel ik met een debounce van 100ms en volgende puls kan ik pas tellen wanneer er eerst weer een negatieve flank is geweest.

Tevens tel ik het aantal milliseconden van de pulsen achter elkaar waarmee ik de flow in l/h en l/min mee bepaal.

Mocht je meer info nodig hebben hoor ik wel

[Koepert]

Meelobee schreef op dinsdag 4 februari 2020 @ 20:44:
[...]


Voor de volledigheid hier de uitleg voor de volledige card:


Geeft dit als resultaat:

[Afbeelding]
De afbeeldingen zijn in kleur als de status morgen of vandaag is, anders zijn ze zwart/wit.

Dit soort dingen maken HA in mijn ogen zo gaaf.. alleen ik ben een totale noob op dit gebied, dus je code is erg volledig, maar voor mij is er nog van alles mis mee

- Waar sla ik de afbeeldingen op zodat de card ze kan gebruiken (of Hoe, sla ik ze daar op)
- Hoe maak ik die sensoren voor PMD aan etc?

Nu draai ik momenteel HA op een Rpi 1.. *die lag er nog en ik wilde kijken of ik Domoticz of dit leuker zou vinden. dus daar komt wellicht een groot deel van probleem vandaan dat mn leercurve ook vrij steil is..

[Meelobee]

Koepert schreef op dinsdag 4 februari 2020 @ 21:42:
[...]


Dit soort dingen maken HA in mijn ogen zo gaaf.. alleen ik ben een totale noob op dit gebied, dus je code is erg volledig, maar voor mij is er nog van alles mis mee

- Waar sla ik de afbeeldingen op zodat de card ze kan gebruiken (of Hoe, sla ik ze daar op)
- Hoe maak ik die sensoren voor PMD aan etc?

Nu draai ik momenteel HA op een Rpi 1.. *die lag er nog en ik wilde kijken of ik Domoticz of dit leuker zou vinden. dus daar komt wellicht een groot deel van probleem vandaan dat mn leercurve ook vrij steil is..

De leercurve is sowieso steil, ik ben sinds eind september 2019 met HA bezig en voel me nog steeds een enorme noob. Met deze kaart ben ik meerdere avonden zoet geweest, Googlen, HA docs lezen, prutsen met code, navragen in Discord en op fora omdat het niet werkt, etc. Maar dat is eigenlijk best leuk en hoort er voor mij wel een beetje bij. Des te leuker is het als het dan eenmaal goed werkt

Voor wat betreft je vragen;

De afbeeldingen kan je hier vinden: https://1drv.ms/u/s!AlaBg5xBef-IgrQsS4SBZOKK_N4QkQ?e=KXbGW5
Uitpakken naar je config/www folder (als je geen www folder in je config folder hebt kan je die handmatig aanmaken.)
Ik heb zelf om het wat duidelijker te houden subfolders [/images/trash_card/] In de code is dat dan: ' /local/images/trash_card/papier.png' (/local = /config/www)

Hoe je ze op die locatie krijgt kan op meerdere manieren.
- Met 'Configurator' kan je vanuit HA bestanden toevoegen vanaf computers op je netwerk en je kan er ook yaml bestanden mee bewerken.
- Met Samba Share installeren, dan kan je de afbeeldingen kopieren vanaf je pc naar HA.
Zowel Configurator als Samba Share staan in de Add-on store (Hass.io --> add-ons)

De sensors komen uit de Garbage Card component (zie link in vorige post) die moet je eerst handmatig of via HACS toevoegen aan HA. Als je die geinstalleerd hebt kan je de sensors als integrations aanmaken (Die manier gebruik ik), of ze handmatig in je configuration.yaml zetten.

Edit: Video tutorial voor installatie van configurator & Samba share.

[Sebastiaan001]

Meelobee schreef op dinsdag 4 februari 2020 @ 22:21:
[...]

De afbeeldingen kan je hier vinden: https://1drv.ms/u/s!AlaBg5xBef-IgrQsS4SBZOKK_N4QkQ?e=KXbGW5

Thanks voor de plaatjes! Deze ga ik gebruiken, heb je toevallig ook een met GFT?

Edit: Ik zie nu dat je een combi gft/rest hebt. Heb hem nu zelf wat aangepast.

[Voor 11% gewijzigd door Sebastiaan001 op 04-02-2020 22:47]

[wesley2004]

Meelobee schreef op dinsdag 4 februari 2020 @ 22:21:
[...]


De leercurve is sowieso steil, ik ben sinds eind september 2019 met HA bezig en voel me nog steeds een enorme noob. Met deze kaart ben ik meerdere avonden zoet geweest, Googlen, HA docs lezen, prutsen met code, navragen in Discord en op fora omdat het niet werkt, etc. Maar dat is eigenlijk best leuk en hoort er voor mij wel een beetje bij. Des te leuker is het als het dan eenmaal goed werkt

Voor wat betreft je vragen;

De afbeeldingen kan je hier vinden: https://1drv.ms/u/s!AlaBg5xBef-IgrQsS4SBZOKK_N4QkQ?e=KXbGW5
Uitpakken naar je config/www folder (als je geen www folder in je config folder hebt kan je die handmatig aanmaken.)
Ik heb zelf om het wat duidelijker te houden subfolders [/images/trash_card/] In de code is dat dan: ' /local/images/trash_card/papier.png' (/local = /config/www)

Hoe je ze op die locatie krijgt kan op meerdere manieren.
- Met 'Configurator' kan je vanuit HA bestanden toevoegen vanaf computers op je netwerk en je kan er ook yaml bestanden mee bewerken.
- Met Samba Share installeren, dan kan je de afbeeldingen kopieren vanaf je pc naar HA.
Zowel Configurator als Samba Share staan in de Add-on store (Hass.io --> add-ons)

De sensors komen uit de Garbage Card component (zie link in vorige post) die moet je eerst handmatig of via HACS toevoegen aan HA. Als je die geinstalleerd hebt kan je de sensors als integrations aanmaken (Die manier gebruik ik), of ze handmatig in je configuration.yaml zetten.

Edit: Video tutorial voor installatie van configurator & Samba share.

Super die volledige uitleg.
Ik ga er het weekend mee stoeien.

Is het met de sensoren nu zo dat het vaste dagen zijn van ophalen, of haalt hij de data ergens op?
Want als het vaste dagen zijn en er is iets van een feestdag ofzo dan klopt dit vaak
Hoe werkt dit?

[Sebastiaan001]

wesley2004 schreef op dinsdag 4 februari 2020 @ 22:37:
[...]


Super die volledige uitleg.
Ik ga er het weekend mee stoeien.

Is het met de sensoren nu zo dat het vaste dagen zijn van ophalen, of haalt hij de data ergens op?
Want als het vaste dagen zijn en er is iets van een feestdag ofzo dan klopt dit vaak
Hoe werkt dit?

Hij haalt de ophaal dagen van je lokale vuilnis bedrijf op via een API. Hier kan je het lezen: https://github.com/pippyn/Home-Assistant-Sensor-Afvalbeheer

[Meelobee]

Sebastiaan001 schreef op dinsdag 4 februari 2020 @ 23:00:
[...]


Hij haalt de ophaal dagen van je lokale vuilnis bedrijf op via een API. Hier kan je het lezen: https://github.com/pippyn/Home-Assistant-Sensor-Afvalbeheer

Nee dat is niet de sensor die ik gebruik.De sensor die ik gebruik kan je toevoegen en aanpassen via Integrations. Het is dus eigenlijk niet echt een afvalbeheer sensor, maar meer een soort timer.

[Voor 3% gewijzigd door Meelobee op 04-02-2020 23:36]

[Hmmbob]

Meelobee schreef op dinsdag 4 februari 2020 @ 23:26:
[...]


Nee dat is niet de sensor die ik gebruik.De sensor die ik gebruik kan je toevoegen en aanpassen via Integrations. Het is dus eigenlijk niet echt een afvalbeheer sensor, maar meer een soort timer.

[YouTube: Home Assistant Garbage Sensor as Integration]

Ah, maar dat is een custom_component die je eerst handmatig of via HACS moet installeren:

repo: https://github.com/bruxy70/Garbage-Collection
Lijst met HACS integraties: https://hacs.xyz/docs/default_repositories

---

En voor mensen die de PostNL integratie gebruikten: die is nu echt over&uit: in release 0.105 verdwijnt deze uit Home Assistant omdat de PostNL API het niet meer toestaat om gebruikt te worden.

https://github.com/home-assistant/home-assistant/pull/30902

[Voor 22% gewijzigd door Hmmbob op 05-02-2020 07:54]

[Meelobee]

Hmmbob schreef op woensdag 5 februari 2020 @ 07:43:
[...]

Ah, maar dat is een custom_component die je eerst handmatig of via HACS moet installeren:

Zoals aangegeven in een van mn vorige posts

Meelobee schreef op dinsdag 4 februari 2020 @ 20:44:
[...]
Benodigd:

Garbage Collection component - via [HACS] of [Github]

[maartend]

Dit is geen wat moet ik kopen vraag maar toch een beetje.

Hoe is jullie ervaring met Xiamo Roborock en HA? Makkelijk te intergreren en dan routines aan te geven? Als in ; if niemand thuis, then doe je rondje. En dan ook bijv. voor verschillende kamers waar ik hem wel moet zetten, behalve als dat ding kan traplopen.

edit ; Robodock. Komt omdat ik dit een geweldig festival vond.

[Voor 9% gewijzigd door maartend op 05-02-2020 12:22]

[Aurora]

maartend schreef op woensdag 5 februari 2020 @ 11:52:
Dit is geen wat moet ik kopen vraag maar toch een beetje.

Hoe is jullie ervaring met Xiamo Robodock en HA? Makkelijk te intergreren en dan routines aan te geven? Als in ; if niemand thuis, then doe je rondje. En dan ook bijv. voor verschillende kamers waar ik hem wel moet zetten, behalve als dat ding kan traplopen.

Xiamo Robodock, de nieuwe tegenhanger van de Xiaomi Roborock. Ik heb daar wel eens van gehoord inderdaad Maar even serieus, ja, dat is allemaal mogelijk met HA. Hier kun je veel inspiratie uithalen: https://community.home-as...xiaomi-vacuum-card/110266

[maartend]

Aurora schreef op woensdag 5 februari 2020 @ 12:11:
[...]
https://community.home-as...xiaomi-vacuum-card/110266

Had ik idd gelezen, maar ging me ook over de vraag of het ook goed werkt.

[Markos]

Ik ben momenteel een beetje aan het azen op een gebruikte Toon thermostaat die ik wil rooten en wil gebruiken met Hassio. Maar ik vroeg me af of er alternatieven zijn die even goed of beter zijn? Ik ben nu vooral geneigd naar Toon vanwege het scherm maar ik kan natuurlijk ook een andere slimme thermostaat gebruiken i.c.m. een simpele tablet aan de muur. Het lijkt mij nog steeds dat Toon de beste optie is, maar ik ben benieuwd wat jullie mening hierover is. Ik heb een slimme meter in de meterkast.

[Aurora]

maartend schreef op woensdag 5 februari 2020 @ 12:23:
[...]

Had ik idd gelezen, maar ging me ook over de vraag of het ook goed werkt.

Yes, bij mij werkt het lekker en stabiel!

[skank]

the_cyberspace schreef op maandag 3 februari 2020 @ 12:09:
[...]

Wat gaat er bij jouw dan precies mis want hier werkt het gewoon. Moet alleen VPN stukje weer even fixxen gezien ik daarmee heb lopen rommelen in m`n USG

Is nog niet helemaal naar wens maar dat komt nog:

https://prnt.sc/qwsse6

Is gelukt, lan wan, wlan en www gaan nu
hoe doe ik die vpn , updates en meldingen?
en de ping?

[maartend]

Aurora schreef op woensdag 5 februari 2020 @ 12:24:
[...]


Yes, bij mij werkt het lekker en stabiel!

Thnx. En heb jij dan de EU versie? Zit te denken ver de S50 nl.

[Aurora]

maartend schreef op woensdag 5 februari 2020 @ 13:27:
[...]

Thnx. En heb jij dan de EU versie? Zit te denken ver de S50 nl.

Ja ik heb de S50, EU versie. Nooit een probleem mee gehad. Nou ja, het enige vervelende is dat als je gebruik gaat maken van zone cleaning, je de deuren altijd moet openhouden. Logisch voor de ruimte waar hij naar toe moet, maar ik bedoel ook voor andere ruimtes waar de robot (toevallig) langsrijdt of schoonmaakt. Een gesloten deur wordt logischerwijs gezien als een muur/obstakel, maar dat houdt hij vast wanneer je de volgende keer naar de ruimte achter die deur verwijst. Ook al staat die deur dan al open. Met andere woorden, hij bepaalt vooraf of hij bij die coördinaten kan komen op basis van eerdere scans.

[Warmaster88]

Meelobee schreef op dinsdag 4 februari 2020 @ 23:26:
[...]


Nee dat is niet de sensor die ik gebruik.De sensor die ik gebruik kan je toevoegen en aanpassen via Integrations. Het is dus eigenlijk niet echt een afvalbeheer sensor, maar meer een soort timer.

[YouTube: Home Assistant Garbage Sensor as Integration]

Thanks voor de perfectie uitleg, ik ben nog een complete HA noob, maar ik ben er na wat stoeien ook uitgekomen!

[maartend]

Aurora schreef op woensdag 5 februari 2020 @ 13:38:
[...]


Ja ik heb de S50, EU versie. Nooit een probleem mee gehad. Nou ja, het enige vervelende is dat als je gebruik gaat maken van zone cleaning, je de deuren altijd moet openhouden. Logisch voor de ruimte waar hij naar toe moet, maar ik bedoel ook voor andere ruimtes waar de robot (toevallig) langsrijdt of schoonmaakt. Een gesloten deur wordt logischerwijs gezien als een muur/obstakel, maar dat houdt hij vast wanneer je de volgende keer naar de ruimte achter die deur verwijst. Ook al staat die deur dan al open. Met andere woorden, hij bepaalt vooraf of hij bij die coördinaten kan komen op basis van eerdere scans.

Het lijkt me dat dit met behulp van deursensors (open/dicht) toch wel in te programeren valt via HA. Maar oke, ik heb gewoon 1 grote woonkamer en verder drempels. Dus is voor mij niet van toepassing.

Afijn, thns voor alle duidelijkheid, ik ga er mee aan de slag

[Aurora]

maartend schreef op woensdag 5 februari 2020 @ 13:54:
[...]

Het lijkt me dat dit met behulp van deursensors (open/dicht) toch wel in te programeren valt via HA.

Ik snap niet waarom ik hier niet zelf op gekomen ben Vast omdat ik eraan gewend ben de deuren open te houden, net zoals de eetkamer stoelen op tafel plaatsen en legoblokjes van de vloer te halen alvorens te starten. Ik neem die deursensoren nu mee! Thanks!

[Davey400]

whiner schreef op donderdag 21 november 2019 @ 16:28:
[...]


Het hoeft geen 100 euro te kosten, zoek op ali maar naar dahua cameras.
je hebt ze al van 30 euro, deze ondersteunen allemaal de open standaarden onvif / RTSP .

Op jouw advies 3 Dahua's gekocht, de C22P.
RTSP lukt inderdaad eenvoudig; still ben ik nog even aan het zoeken en ik vraag het me af, omdat ik op basis van een portscan alleen 554 voorbij zie komen.

[Voor 7% gewijzigd door Davey400 op 05-02-2020 16:22]

[hansgrave]

Markos schreef op woensdag 5 februari 2020 @ 12:24:
Ik ben momenteel een beetje aan het azen op een gebruikte Toon thermostaat die ik wil rooten en wil gebruiken met Hassio. Maar ik vroeg me af of er alternatieven zijn die even goed of beter zijn? Ik ben nu vooral geneigd naar Toon vanwege het scherm maar ik kan natuurlijk ook een andere slimme thermostaat gebruiken i.c.m. een simpele tablet aan de muur. Het lijkt mij nog steeds dat Toon de beste optie is, maar ik ben benieuwd wat jullie mening hierover is. Ik heb een slimme meter in de meterkast.

Ik ben dik tevreden met de geroote Toon icm met Home Assistant. Via de Home Assistant tegel op de Toon kan ik veel gebruikte switchen bedienen. Enige minpunt kan zijn de snelheid van de Toon, soms reageert het scherm vertraagd. Dit heeft te maken met het beperkte geheugen icm de geïnstalleerde apps uit de Toonstore

[DaLass]

Meelobee schreef op dinsdag 4 februari 2020 @ 20:44:
[...]


Voor de volledigheid hier de uitleg voor de volledige card:

...

Tnx voor de uitleg. Ik probeer nu deze ook in mijn HA te krijgen, maar krijg de code er nog niet goed in. In neem aan dat deze in de raw editor van de lovelace UI moet komen? Hoe heb je die er dan precies instaan? Ik heb voor het gemak maar even een nieuwe pagina aangemaakt en gepoogd om deze onder de cards eronder te krijgen, maar ik krijg de config niet opgeslagen omdat hij het schijnbaar niet eens is met de spaties voor elke regel, wat ik ook probeer.

[sterremos]

ontwikkelingen volgen zich snel op. is er al een "verbetere" manier om zigbee in HA te hebben.
Heb een conbee Denconz stick voor mijn Ikea en Xiaomi te koppelen.
lijkt nu dat deze overleden is en moet vervangen worden.

Dus ben benieuwd of er iets nieuw is en goed te installeren in HA

[RudolfR]

@sterremos

Zigbee2mqtt misschien?

Wat mij betreft kan er nog steeds niks tippen aan Deconz; raspbee was money well spent; doet alles wat ik wil kunnen doen met zigbee.
Ook de integratie met HA is buitengewoon goed.

[Meelobee]

DaLass schreef op woensdag 5 februari 2020 @ 17:26:
[...]

Tnx voor de uitleg. Ik probeer nu deze ook in mijn HA te krijgen, maar krijg de code er nog niet goed in. In neem aan dat deze in de raw editor van de lovelace UI moet komen? Hoe heb je die er dan precies instaan? Ik heb voor het gemak maar even een nieuwe pagina aangemaakt en gepoogd om deze onder de cards eronder te krijgen, maar ik krijg de config niet opgeslagen omdat hij het schijnbaar niet eens is met de spaties voor elke regel, wat ik ook probeer.

Je kan de code copy/pasten in een manual card;

Lovelace menu (Rechts bovenin) > Configure UI > + Knop rechts onderin > Manual Card > De bestaande code (type: '') selecteren en daar de nieuwe code overheen plakken. (Als je de bestaande code eerst weghaalt sluit de kaart, vandaar selecteren en eroverheen plakken.)

[whiner]

Davey400 schreef op woensdag 5 februari 2020 @ 16:01:
[...]

Op jouw advies 3 Dahua's gekocht, de C22P.
RTSP lukt inderdaad eenvoudig; still ben ik nog even aan het zoeken en ik vraag het me af, omdat ik op basis van een portscan alleen 554 voorbij zie komen.

Ik heb geen ervaring met dit type dahua, er is wel een site waar je alle URL kan vinden van rtsp camera's , https://www.ispyconnect.com/man.aspx?n=china ispy is ook een app die je kan installeren, deze genereerd dan de URL voor je.

[slommer]

Hi volg dit topic al een tijd uit nieuwsgierigheid en zag de HVC voorbij wat me handig lijkt (net verhuisd en kan niet wennen aan het ophaal schema hier).
Heb het installed via HACS en erna de hvcgroep.
Heb alles in me configuration.yaml geplaats en stukje in groups.yaml.
Ik krijg in het overview scherm netjes afvalophaaldagen te zien. Alleen niet zoals het moet.
Hij geeft als error: Entity not available: sensor.hvc_groep_gft
en dat voor alle 4.
Iemand een tip waar te zoeken of een goeie handleiding voor een starter?

Thanks

[Imperial Guard]

Meelobee schreef op dinsdag 4 februari 2020 @ 20:44:
[...]


Voor de volledigheid hier de uitleg voor de volledige card:

Benodigd:

Garbage Collection component - via [HACS] of [Github]
Card Templater - via [HACS] of [Github]
Card-Mod - via [HACS] of [Github] (De 'mod-card' optie gebruiken vanwege de horizontal-stack, zie documentatie.)

code:

card:
  cards:
    - card:
        entity: sensor.papier_2
        name_template: >-
          {%- if is_state("sensor.papier_2", "0")%} Vandaag {% elif
          is_state("sensor.papier_2", "1")%} Morgen {% else %} {{
          states.sensor.papier_2.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/papier.png
          '1': /local/images/trash_card/papier.png
          '2': /local/images/trash_card/papier_bw.png
        type: picture-entity
      entities:
        - sensor.papier_2
      type: 'custom:card-templater'
    - card:
        entity: sensor.gft_rest
        name_template: >-
          {%- if is_state("sensor.gft_rest", "0")%} Vandaag {% elif
          is_state("sensor.gft_rest", "1")%} Morgen {% else %} {{
          states.sensor.gft_rest.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/gft_rest.png
          '1': /local/images/trash_card/gft_rest.png
          '2': /local/images/trash_card/gft_rest_bw.png
        type: picture-entity
      entities:
        - sensor.gft_rest
      type: 'custom:card-templater'
    - card:
        entity: sensor.pmd
        name_template: >-
          {%- if is_state("sensor.pmd", "0")%} Vandaag {% elif
          is_state("sensor.pmd", "1")%} Morgen {% else %} {{
          states.sensor.pmd.attributes.days }} dagen {%- endif %}
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/trash_card/pmd.png
          '1': /local/images/trash_card/pmd.png
          '2': /local/images/trash_card/pmd_bw.png
        type: picture-entity
      entities:
        - sensor.pmd
      type: 'custom:card-templater'
  type: horizontal-stack
style: |
  ha-card {
    radius: 10px;
    text-align: center
  }
type: 'custom:mod-card'

Geeft dit als resultaat:

[Afbeelding]
De afbeeldingen zijn in kleur als de status morgen of vandaag is, anders zijn ze zwart/wit.

Hoe heb jij die plaatjes lokaal op je server staan?

Ik krijg ze met geen enkele mogelijkheid te zien.
Ze staan bij mij onder www->images->afval en dan bijv GFT.png en ik zou verwachten dus /local/images/afval/GFT.png maar het werkt helaas niet

[Hmmbob]

Home Assistant 0.105.0 is uit.

[Dacuuu]

Hmmbob schreef op woensdag 5 februari 2020 @ 22:48:
Home Assistant 0.105.0 is uit.

De ontwikkeling gaat hard zeg!

[DaLass]

Meelobee schreef op woensdag 5 februari 2020 @ 20:24:
[...]


Je kan de code copy/pasten in een manual card;

Lovelace menu (Rechts bovenin) > Configure UI > + Knop rechts onderin > Manual Card > De bestaande code (type: '') selecteren en daar de nieuwe code overheen plakken. (Als je de bestaande code eerst weghaalt sluit de kaart, vandaar selecteren en eroverheen plakken.)

Die had ik over het hoofd gezien, dankje. Daarmee heb ik de card kunnen toevoegen.
Ik heb er wel wat modificaties op uitgevoerd, aangezien ik gebruik maak van het Rova component uit Home Assistant, die geeft alleen een datum terug.

Ik heb daarom 3 sensoren gemaakt die op basis van de huidige datum een berekening maken hoeveel dagen het nog duurt voordat de bakken geleegd worden:

code:

  - platform: template
    sensors:
      rova_bio_remainingdays:
        value_template: '{{ ((as_timestamp(states.sensor.rova_bio.state) - as_timestamp(now())) | int /60/1440) | round(0) }}'
        unit_of_measurement: 'Days'
        entity_id: sensor.date
      rova_paper_remainingdays:
        value_template: '{{ ((as_timestamp(states.sensor.rova_paper.state) - as_timestamp(now())) | int /60/1440) | round(0) }}'
        unit_of_measurement: 'Days'
        entity_id: sensor.date
      rova_plastic_remainingdays:
        value_template: '{{ ((as_timestamp(states.sensor.rova_plastic.state) - as_timestamp(now())) | int /60/1440) | round(0) }}'
        unit_of_measurement: 'Days'
        entity_id: sensor.date

Deze sensoren heb ik vervolgens gebruikt in de door jou gebouwde card:

code:

card:
  cards:
    - card:
        entity: sensor.rova_paper
        name_template: >-
          {%- if is_state("sensor.rova_paper_remainingdays", "0")%} Vandaag {%
          elif is_state("sensor.rova_paper_remainingdays", "1")%} Morgen {%
          elif is_state("sensor.rova_paper_remainingdays", "unknown")%} Niet
          bekend {% else
          %} {{ states.sensor.rova_paper_remainingdays.state }} dagen {%- endif
          %}
        show_name: true
        show_state: false
        image: /local/images/trash_card/papier_bw.png
        state_image:
          '0': /local/images/trash_card/papier.png
          '1': /local/images/trash_card/papier.png
        type: picture-entity
      entities:
        - sensor.rova_paper
      type: 'custom:card-templater'
    - card:
        entity: sensor.rova_bio
        name_template: >-
          {%- if is_state("sensor.rova_bio_remainingdays", "0")%} Vandaag {%
          elif is_state("sensor.rova_bio_remainingdays", "1")%} Morgen {%
          elif is_state("sensor.rova_bio_remainingdays", "unknown")%} Niet
          bekend {% else
          %} {{ states.sensor.rova_bio_remainingdays.state }} dagen {%- endif %}
        show_name: true
        show_state: false
        image: /local/images/trash_card/gft_bw.png
        state_image:
          '0': /local/images/trash_card/gft.png
          '1': /local/images/trash_card/gft.png
        type: picture-entity
      entities:
        - sensor.rova_bio
      type: 'custom:card-templater'
    - card:
        entity: sensor.rova_plastic
        name_template: >-
          {%- if is_state("sensor.rova_plastic_remainingdays", "0")%} Vandaag {%
          elif is_state("sensor.rova_plastic_remainingdays", "1")%} Morgen {%
          elif is_state("sensor.rova_plastic_remainingdays", "unknown")%} Niet
          bekend {% else %} {{ states.sensor.rova_plastic_remainingdays.state }}
          dagen {%- endif %}
        show_name: true
        show_state: false
        image: /local/images/trash_card/pmd_bw.png
        state_image:
          '0': /local/images/trash_card/pmd.png
          '1': /local/images/trash_card/pmd.png
        type: picture-entity
      entities:
        - sensor.rova_plastic
      type: 'custom:card-templater'
  type: horizontal-stack
style: |
  ha-card {
    radius: 10px;
    text-align: center
  }
type: 'custom:mod-card'

Wat nog meer anders is, is dat niet alle data vanuit de Rova goed uitgelezen kan worden in het voren. De PMD bak wordt bijvoorbeeld maar 1x per 4 weken geleegd, en momenteel geeft de API de datum nog niet terug voor de volgende leging, omdat die net deze week geweest is. Daarom heb ik toegevoegd dat bij een state "unknown", de tekst "Niet bekend" moet worden.

Tot slot de uitdaging van de plaatjes, die deden het niet. Mijn GFT bak mag over 4 dagen aan de weg, dus ik heb een state_image aangepast naar waarde "4" en toen kreeg ik wel een plaatje. Omdat bij "0" of "1" een kleuren plaatje mag komen, en bij alle overige een zwart/wit plaatje, heb ik state_image "2" verwijderd en daarvoor in de plaats een normale image toegevoegd met de zwart/wit afbeelding. Die wordt vervolgens overschreven met een kleuren-exemplaar als de state in "1" of "0" veranderd.

Imperial Guard schreef op woensdag 5 februari 2020 @ 22:35:
[...]


Hoe heb jij die plaatjes lokaal op je server staan?

Ik krijg ze met geen enkele mogelijkheid te zien.
Ze staan bij mij onder www->images->afval en dan bijv GFT.png en ik zou verwachten dus /local/images/afval/GFT.png maar het werkt helaas niet

Waarschijnlijk zie je ze niet omdat de state niet overeenkomt met de dagen die resterend zijn voor de leging. Als je daarmee speelt, krijg je ze wel te zien. Dat is ook de reden dat ik het anders heb opgelost, zoals hierboven. Ik kreeg ze namelijk ook eerst niet te zien, nu wel.

[Voor 6% gewijzigd door DaLass op 05-02-2020 23:24]

[Imperial Guard]

DaLass schreef op woensdag 5 februari 2020 @ 23:19:
[...]


[...]

Waarschijnlijk zie je ze niet omdat de state niet overeenkomt met de dagen die resterend zijn voor de leging. Als je daarmee speelt, krijg je ze wel te zien. Dat is ook de reden dat ik het anders heb opgelost, zoals hierboven. Ik kreeg ze namelijk ook eerst niet te zien, nu wel.

Ik heb er ook geen steeds aangekoppeld:

code:

type: 'custom:mod-card'
style: |
  ha-card {
    radius: 8px;
    text-align: center
  }
card:
  type: horizontal-stack
  cards:
    - card:
        entity: sensor.waste_next_grey
        name_template: '{{ states.sensor.waste_next_grey.state }}'
        show_name: true
        show_state: false
        state_image:
          '0': local/Papier.png
        type: picture-entity
      entities:
        - sensor.waste_next_grey
      type: 'custom:card-templater'
    - card:
        entity: sensor.waste_next_green
        name_template: '{{ states.sensor.waste_next_green.state }}'
        show_name: true
        show_state: false
        state_image:
          '0': /Papier.png
        type: picture-entity
      entities:
        - sensor.waste_next_green
      type: 'custom:card-templater'
    - card:
        entity: sensor.waste_next_paper
        name_template: '{{ states.sensor.waste_next_paper.state }}'
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/afval/GFT.jpg
        type: picture-entity
      entities:
        - sensor.waste_next_paper
      type: 'custom:card-templater'
    - card:
        entity: sensor.waste_next_packages
        name_template: '{{ states.sensor.waste_next_packages.state }}'
        show_name: true
        show_state: false
        state_image:
          '0': /local/images/afval/GFT.jpg
        type: picture-entity
      entities:
        - sensor.waste_next_packages
      type: 'custom:card-templater'

[silver323]

Dacuuu schreef op woensdag 5 februari 2020 @ 22:52:
[...]


De ontwikkeling gaat hard zeg!

En de 105.1 staat ook alweer klaar..

[Dacuuu]

silver323 schreef op donderdag 6 februari 2020 @ 08:04:
[...]


En de 105.1 staat ook alweer klaar..

Als ik 1 ding weet, update HA nooit op de 1e dag Ik update pas vaak een week later ofzo.

[Mark de Vaal]

Dacuuu schreef op donderdag 6 februari 2020 @ 08:33:
[...]


Als ik 1 ding weet, update HA nooit op de 1e dag Ik update pas vaak een week later ofzo.

Met deze snelheid kan je een week later ook niet updaten ivm een nieuwere versie.

[DaLass]

Imperial Guard schreef op donderdag 6 februari 2020 @ 08:03:
[...]


Ik heb er ook geen steeds aangekoppeld:

...
[/code]

Als ik je goed begrijp wil je dus geen afwijkende afbeeldingen op basis van het resterend aantal dagen? In dat geval dien je "state_image" weg te halen en alleen de "image" tag te gebruiken met het pad naar het plaatje, dan heb je een statische afbeelding. "state_image" is handig als je een dynamische afbeelding wilt, op basis van de status.

Als je naar mijn code kijkt, zie je boven "state_image" ook een "image" regel staan, dat is dan voldoende voor jou, uiteraard wel met het pad naar je eigen plaatje. de "stage_image" regel kan dan weg.

[Voor 12% gewijzigd door DaLass op 06-02-2020 09:40]

[Thoit]

Dacuuu schreef op donderdag 6 februari 2020 @ 08:33:
[...]


Als ik 1 ding weet, update HA nooit op de 1e dag Ik update pas vaak een week later ofzo.

Wat eerder ook al eens werd gezegd, als iedereen zo denkt blijven we natuurlijk stil staan. Ja ik heb ook al meerdere keren HomeAssistant kapot gehad door updates en ben wat terughoudender geworden, maar het is wel mooi dat er zo actief ontwikkeld wordt.

Enige wat ik nog graag zou willen is de Z-wave integratie in een aparte container. Z-wave2MQTT werkt niet lekker hier dus dat is voor mij nog steeds geen optie.

[gertvdijk]

Thoit schreef op donderdag 6 februari 2020 @ 09:49:
Enige wat ik nog graag zou willen is de Z-wave integratie in een aparte container. Z-wave2MQTT werkt niet lekker hier dus dat is voor mij nog steeds geen optie.

Werkt prima hier. Wat gaat er mis? Wel een recente versie met OZW 1.6 gepakt? Auto discovery in HA blijft een beetje brak wel.

[Dacuuu]

Thoit schreef op donderdag 6 februari 2020 @ 09:49:
[...]


Wat eerder ook al eens werd gezegd, als iedereen zo denkt blijven we natuurlijk stil staan. Ja ik heb ook al meerdere keren HomeAssistant kapot gehad door updates en ben wat terughoudender geworden, maar het is wel mooi dat er zo actief ontwikkeld wordt.

Enige wat ik nog graag zou willen is de Z-wave integratie in een aparte container. Z-wave2MQTT werkt niet lekker hier dus dat is voor mij nog steeds geen optie.

Ontwikkeling is juist goed! Ik bedoel dat ik altijd even wacht met updaten, want er is vaak iets kapot gesloopt wat binnen een dag weer gefixt word met een nieuwe update. En zo ook vanochtend dus..

En bedoel je geen Zigbee2mqtt?

[Thoit]

gertvdijk schreef op donderdag 6 februari 2020 @ 09:56:
[...]

Werkt prima hier. Wat gaat er mis? Wel een recente versie met OZW 1.6 gepakt? Auto discovery in HA blijft een beetje brak wel.

Sinds ik met Z-wave2MQTT begonnen was had ik geregeld dat daarna mijn gewone Z-wave network niet meer wilde starten. Alleen een update zorgde ervoor dat het weer kon starten. Hierdoor heb ik het maar gelaten voor wat het was.

In Z-wave2MQTT kreeg ik de devices niet te zien bijvoorbeeld.

[Davey400]

Dacuuu schreef op donderdag 6 februari 2020 @ 08:33:
[...]


Als ik 1 ding weet, update HA nooit op de 1e dag Ik update pas vaak een week later ofzo.

Daarom is de nieuwe optie 'safe mode' natuurlijk fantastisch; als alles crashed kun je op deze manier makkelijker terug.
Nu maar fingers crossed dat het zaakje niet klapt bij de upgrade náár 105....
(Tot nu toe bij mij geen problemen met updates in het verleden trouwens.)

[Davey400]

Hmmbob schreef op woensdag 5 februari 2020 @ 22:48:
Home Assistant 0.105.0 is uit.

Van het onderliggende HassOS is ook een nieuwe release: 3.9
https://github.com/home-a...g-system/releases/tag/3.9

[CAP-Team]

HassOS had ik gisteren al geüpdate

[stijn1309]

Ik heb mijn Zigbee netwerk uitgebreid met enkele IKEA lampen. Deze IKEA lampen dienen als repeater m.b.t. het Zigbee netwerk.

Nu had ik soms dat de bewegingssensor op zolder geen tot slecht bereik had. Doordat ik nu een lamp op de 1ste verdieping heb en een lamp op zolder zelf (Welke altijd goed reageren), dacht ik dat die bewegingssensor ook beter zou gaan werken door deze "repeaters".

Nu heb ik die network map card geinstalleerd en zie ik dat alle niet IKEA apparaten (Xiaomi bijvoorbeeld) nog steeds rechtstreeks verbinding maakt naar de Zigbee stick en niet eens een lijntje opzet naar de lampen etc. terwijl de lampen onderling wel verbinden met elkaar.

Moet ik dan die overige spullen opnieuw verbinden of moet ik deze even triggeren door het sync knopje even in te drukken? Wat is jullie ervaring?

[DeadMetal]

Hoe lang geleden heb je dit gedaan? Ik dacht eens begrepen te hebben dat het soms enkele uren of dagen duurt voordat het mesh netwerk zichzelf optimaliseert, maar ik kan het mis hebben.

[Voor 3% gewijzigd door DeadMetal op 06-02-2020 13:12]

[zoeperman]

Het kan wel een paar dagen duren voor je zigbee netwerk weer geoptimaliseerd is. Ik las ergens dat de ikea lampen ook niet helemaal optimaal zijn voor repeater met xiaomi spul.

[Davey400]

Camera's:

Originele bericht:
Ik wil op 3 plekken in huis simpelweg snel kunnen kijken wat de situatie is. Een simpele camera volstaat dus voor mij; de Picture Glance Card doet precies wat het moet doen: Standaard een redelijk recente afbeelding, bij er op klikken een live stream.

Een tijdje met de Android IP webcam gespeeld. Werkt perfect, behalve dat de telefoons niet stabiel blijven en ze het dus té vaak niet doen. Ook leuke aanvullende features.

Op basis van zoeken in dit topic (en het vorige) 3 Dahua camera's gekocht (C22p).
RTSP werkt prima, maar helaas ondersteunen deze geen still image, iets wat wel nodig is om de camera's via de normale integratie te kunnen gebruiken.
M.a.w.: deze gaan denk ik weer terug.

Iemand een suggestie voor een goedkope camera die wel direct in HA te gebruiken is, en vanuit Nederland te bestellen is?

Ik ben er niet van afhankelijk voor beveiliging o.i.d.; aanvullende opties zijn dus leuk, maar niet nodig.


Edit:
Aha.
Soms is het zo simpel. Ik hou van HA. 😍

Manual card:

YAML:

type: picture-entity
entity: camera.garagedeur
camera_view: live[/quote]

En hoppa: gewoon alle cards met live view!

[Voor 11% gewijzigd door Davey400 op 06-02-2020 14:07]

[kepler]

Davey400 schreef op donderdag 6 februari 2020 @ 11:03:
[...]

Daarom is de nieuwe optie 'safe mode' natuurlijk fantastisch; als alles crashed kun je op deze manier makkelijker terug.
Nu maar fingers crossed dat het zaakje niet klapt bij de upgrade náár 105....
(Tot nu toe bij mij geen problemen met updates in het verleden trouwens.)

Safe mode is echt een goede! Paar keer gehad dat ik met 1 typo, en vergeten configuration check, mijn HA niet meer opstartte

[silver323]

Zo valt me nu op dat er voldoende updates te doen zijn.
Wat is een logische volgorde?

Home Assistant Core 0.105.1
You are currently running version 0.104.3

Supervisor 199
You are currently running version 198

Operating System 3.9
You are currently running version 2.12

[stijn1309]

DeadMetal schreef op donderdag 6 februari 2020 @ 13:12:
Hoe lang geleden heb je dit gedaan? Ik dacht eens begrepen te hebben dat het soms enkele uren of dagen duurt voordat het mesh netwerk zichzelf optimaliseert, maar ik kan het mis hebben.

zoeperman schreef op donderdag 6 februari 2020 @ 13:23:
Het kan wel een paar dagen duren voor je zigbee netwerk weer geoptimaliseerd is. Ik las ergens dat de ikea lampen ook niet helemaal optimaal zijn voor repeater met xiaomi spul.

Ik denk dat het nu zo'n 2 weken heb draaien...

Als ik één van de bewegingssensoren eens een reset geef en opnieuw koppel, dan ben ik niets kwijt in mijn config toch? aangezien hij dezelfde naam behoud etc?

[JayOne]

silver323 schreef op donderdag 6 februari 2020 @ 14:11:
Zo valt me nu op dat er voldoende updates te doen zijn.
Wat is een logische volgorde?

Home Assistant Core 0.105.1
You are currently running version 0.104.3

Supervisor 199
You are currently running version 198

Operating System 3.9
You are currently running version 2.12

Wanneer 0.104.3 al een tijdje stabiel bij je draait, zou ik eerst gaan voor het operating system. Dan een paar dagen tot een week kijken of het systeem nog steeds stabiel is en dan overgaan op 0.105.X

Maak voor het updaten van de OS wel een backup (en bewaar die backup buiten de Hass omgeving).

Voor zover ik weet wordt de Supervisor automatisch geupdate.

[rorie]

Kan je een schakelaar direct aansluiten op een Shelly en de status hiervan uitlezen via MQTT? Met als doel een lamp te kunnen schakelen via een schakelaar die aangesloten is op de Shelly maar de lamp dus niet. Hiermee zou ik met behulp van zigbee2mqtt vanaf een wandschakelaar mijn nachtlampjes kunnen aanzetten die aangesloten zijn op een Ikea slimme stekker.

[Kodess]

rorie schreef op donderdag 6 februari 2020 @ 16:28:
Kan je een schakelaar direct aansluiten op een Shelly en de status hiervan uitlezen via MQTT? Met als doel een lamp te kunnen schakelen via een schakelaar die aangesloten is op de Shelly maar de lamp dus niet. Hiermee zou ik met behulp van zigbee2mqtt vanaf een wandschakelaar mijn nachtlampjes kunnen aanzetten die aangesloten zijn op een Ikea slimme stekker.

ja

[JBS]

rorie schreef op donderdag 6 februari 2020 @ 16:28:
Kan je een schakelaar direct aansluiten op een Shelly en de status hiervan uitlezen via MQTT? Met als doel een lamp te kunnen schakelen via een schakelaar die aangesloten is op de Shelly maar de lamp dus niet. Hiermee zou ik met behulp van zigbee2mqtt vanaf een wandschakelaar mijn nachtlampjes kunnen aanzetten die aangesloten zijn op een Ikea slimme stekker.

Als het niet per se met een een bestaande schakelaar wilt doen, heeft bijvoorbeeld Aqara ook een diversiteit aan knoppen die je op een gewenste plek op de muur kunt plakken?

Alternatief kan anders nog zijn een Aqara raam/deurcontact aan een schakelaar solderen en op basis van de Aqara sensor een lamp schakelen.

[Voor 9% gewijzigd door JBS op 06-02-2020 16:52]

[Imperial Guard]

Goh het is me gelukt maar is er ook de mogelijkheid om de card groter te maken zodat mijn tekst ook beter past in onderstaande afbeelding?

[Voor 3% gewijzigd door Imperial Guard op 06-02-2020 17:42]