Home Assistant: Open source Python3 home automation - deel 4

[Hmmbob]

Septillion schreef op dinsdag 30 maart 2021 @ 09:59:
[...]

Ligt het aan mij of is de waarschuwing weer verdwenen?

Ik denk optie 1

[JayOne]

sOid schreef op dinsdag 30 maart 2021 @ 10:42:
@JayOne @Septillion Misschien begrijp ik het verkeerd, maar een local API dicht zetten, dan is het toch niet local? Dat kan toch alleen als ze over the air firmware updates naar hun devices kunnen pushen? Of zie ik iets over het hoofd?

Zie hiervoor hoe je lan-control aanzet.

[Hmmbob]

sOid schreef op dinsdag 30 maart 2021 @ 10:42:
@JayOne @Septillion Misschien begrijp ik het verkeerd, maar een local API dicht zetten, dan is het toch niet local? Dat kan toch alleen als ze over the air firmware updates naar hun devices kunnen pushen? Of zie ik iets over het hoofd?

Er zijn wel meer systemen die "met de cloud lullen" maar ook een local API heeft. Dat is wat hier bedoeld wordt: dmv een "over the air" update via die cloud, is het locale stukje dichtgezet.

[llevering]

Over ESPHome vs Tasmota. Ik gebruik beide. De verdeling is 'toevallig' ontstaan maar heeft wel een rode draad. Devices waarvoor een template is in Tasmota (of beter gezegd een template bekend is op de blakadder website) draaien daarop. Als het iets is dat custom dan draait het op ESPHome.

Alleen een bordje met temperatuur sensoren en eentje met twee pulstellers draaien nog op Tasmota, omdat ik toen ESPHome nog niet kende. Die wil ik nog weleens overzetten omdat ik dan wat makkelijker custom dingen kan doen (de rules van Tasmota liggen mij niet zo, terwijl C lambda's in ESPHome makkelijker afgaan). Dat is echter puur smaak gedreven. En het feit dat ik een half jaar denk die moet ik eens overzetten zegt genoeg over de beperkte verwachtte voordelen .

[scorpion303]

peetgate schreef op dinsdag 23 maart 2021 @ 23:50:
[...]


Kijk eens naar filters: https://www.home-assistant.io/integrations/filter/

Je kunt hiermee filters aanmaken die bewerkingen doen met je data. Je zou bijvoorbeeld eentje kunnen maken die outliers er uit filtert. Je moet dan wel even goed kijken wat er gebeurt met de data die dan wel geschreven wordt. Wordt het afgekapt boven een bepaalde waarde? Of krijg je misschien zelfs een nulwaarde?

Dank voor de tip! Ik heb even naar filters gekeken, maar dit zag er toch net iets te complex uit voor mijn 'probleem' (het eens per maand ontvangen van onrealistische gas verbruiks waarden via dsmr-reader).

Ik heb toch zelf maar even wat extra templates ingesteld. Deze zouden alle foutieve waarden (naar mijn mening) moeten afvangen.

YAML:

# configuration.yaml 

# templates
- platform: template
  sensors:
    # extra '_clean' template waarde voor huidig gasverbruik om te voorkomen dat spikes (groter dan 
    # 1 m3 of minder dan -1 m3 per vijf minuten) vanuit DSMR-reader mijn grafieken verprutsen
    dsmr_consumption_gas_currently_delivered_clean:
      friendly_name: Gas huidig verbruik
      unit_of_measurement: m³
      icon_template: 'mdi:fire'
      value_template: >
        {% if (states('sensor.dsmr_consumption_gas_currently_delivered')|float < 1) and (states('sensor.dsmr_consumption_gas_currently_delivered')|float > -1) %}
          {{ (states('sensor.dsmr_consumption_gas_currently_delivered'))|float }}
        {% else %}
          0
        {% endif %}
    # extra '_clean' template waarde voor gas dagverbruik om te voorkomen dat spikes (groter dan 100 m3 - of minder dan -100 m3 per dag) vanuit DSMR-reader mijn grafieken verprutsen
    dsmr_day_consumption_gas_clean:
      friendly_name: Gas dagverbruik 
      unit_of_measurement: m³
      icon_template: 'mdi:counter'
      value_template: >
        {% if (states('sensor.dsmr_day_consumption_gas')|float < 100) and (states('sensor.dsmr_day_consumption_gas')|float > -100) %}
          {{ (states('sensor.dsmr_day_consumption_gas'))|float }}
        {% else %}
          0
        {% endif %}
    # extra '_clean' template waarde voor gaskosten om te voorkomen dat spikes (groter dan EU 75 - of minder dan EU -75 per dag) vanuit DSMR-reader mijn grafieken verprutsen
    dsmr_day_consumption_gas_cost_clean:
      friendly_name: Gas kosten
      unit_of_measurement: €
      icon_template: 'mdi:currency-eur'
      value_template: >
        {% if (states('sensor.dsmr_day_consumption_gas_cost')|float < 75) and (states('sensor.dsmr_day_consumption_gas_cost')|float > -75) %}
          {{ (states('sensor.dsmr_day_consumption_gas_cost'))|float }}
        {% else %}
          0
        {% endif %}
    # extra '_clean' template waarde voor totale energiekosten om te voorkomen dat spikes (groter dan EU 150 - of minder dan EU -150 per dag) vanuit DSMR-reader mijn grafieken verprutsen
    dsmr_day_consumption_total_cost_clean:
      friendly_name: Energie kosten
      unit_of_measurement: €
      icon_template: 'mdi:currency-eur'
      value_template: >
        {% if (states('sensor.dsmr_day_consumption_total_cost')|float < 150) and (states('sensor.dsmr_day_consumption_total_cost')|float > -150) %}
          {{ (states('sensor.dsmr_day_consumption_total_cost'))|float }}
        {% else %}
          0
        {% endif %}
    # extra '_clean' template waarden voor gasmeterstand om te voorkomen dat spikes (tellerstand ineens 400m3 hoger dan tellerstand-maandgemiddelde) vanuit DSMR-reader mijn grafieken verprutsen
    dsmr_consumption_gas_delivered_clean:
      friendly_name: Gas meterstand
      unit_of_measurement: m³
      icon_template: 'mdi:fire'
      value_template: >
        {% if (states('sensor.dsmr_consumption_gas_delivered')|float - states('sensor.dsmr_consumption_gas_delivered_30day_average')|float < 400) %}
          {{ (states('sensor.dsmr_consumption_gas_delivered'))|float }}
        {% else %}
          NaN          
        {% endif %}

[sOid]

Hmmbob schreef op dinsdag 30 maart 2021 @ 10:47:
[...]

Er zijn wel meer systemen die "met de cloud lullen" maar ook een local API heeft. Dat is wat hier bedoeld wordt: dmv een "over the air" update via die cloud, is het locale stukje dichtgezet.

Ah op die manier. Irritant dat dat kan. Blij dat ik met uitzondering van Nest alles écht lokaal heb draaien. Denk ik

[Septillion]

@sOid Local API sluit een cloud niet uit. Het was geen local only API.

@Mozart Is dat de integration of de addon? Maar anderzijds het is nog steeds gewoon een list met devices

@Hmmbob Nu is hij er wel weer natuurlijk. Alleen maar om mij voor gek te zetten

[Demo]

Het grote voordeel van ESPHome vind ik vooral dat je het in dezelfde 'taal' configureert (dan bedoel ik niet YAML, maar de terminologie van sensors, entities etc) en dat de entiteiten direct worden gedetecteerd. Het alternatief zou voor mij MQTT zijn en dat is best een gekloot als het niet automagisch gepubliceerd wordt via je config-topic.
@Mozart ik zie in jouw screenshot octoprint staan, gebruik je een ESP om hem aan en uit te zetten? Heb je in Octoprint ook de HA-plugin in gebruik, of heb je geen MQTT?

[Sp33dFr34k]

Demo schreef op dinsdag 30 maart 2021 @ 11:16:
Het alternatief zou voor mij MQTT zijn en dat is best een gekloot als het niet automagisch gepubliceerd wordt via je config-topic.

Gewoon

code:

setoption19 1

toch?

[Mars Warrior]

Sp33dFr34k schreef op dinsdag 30 maart 2021 @ 11:26:
[...]
Gewoon

code:

setoption19 1

toch?

Nope, niet meer met de Tasmota integratie voor HA, zie: https://tasmota.github.io/docs/Home-Assistant/
Dus geen MQTT autodiscovery meer, ondanks dat alles nog wel over MQTT loopt natuurlijk.

Alle Tasmota devices/sensoren zitten dus in hun eigen Tasmota integratie scherm.

[Mozart]

Demo schreef op dinsdag 30 maart 2021 @ 11:16:
Het grote voordeel van ESPHome vind ik vooral dat je het in dezelfde 'taal' configureert (dan bedoel ik niet YAML, maar de terminologie van sensors, entities etc) en dat de entiteiten direct worden gedetecteerd. Het alternatief zou voor mij MQTT zijn en dat is best een gekloot als het niet automagisch gepubliceerd wordt via je config-topic.
@Mozart ik zie in jouw screenshot octoprint staan, gebruik je een ESP om hem aan en uit te zetten? Heb je in Octoprint ook de HA-plugin in gebruik, of heb je geen MQTT?

Ja, ik gebruik een esphome om de power op de printer te regelen, daarnaast heb ik een MQTT koppeling met octoprint zelf:

Septillion schreef op dinsdag 30 maart 2021 @ 11:00:
@sOid Local API sluit een cloud niet uit. Het was geen local only API.

@Mozart Is dat de integration of de addon? Maar anderzijds het is nog steeds gewoon een list met devices

@Hmmbob Nu is hij er wel weer natuurlijk. Alleen maar om mij voor gek te zetten

Het is de integration en die heeft dus al een filter in de integration zelf

[ Voor 20% gewijzigd door Mozart op 30-03-2021 11:43 ]

[Sp33dFr34k]

Mars Warrior schreef op dinsdag 30 maart 2021 @ 11:36:
[...]

Nope, niet meer met de Tasmota integratie voor HA, zie: https://tasmota.github.io/docs/Home-Assistant/
Dus geen MQTT autodiscovery meer, ondanks dat alles nog wel over MQTT loopt natuurlijk.

Alle Tasmota devices/sensoren zitten dus in hun eigen Tasmota integratie scherm.

Ah, omdat je MQTT zei, wist niet eens dat er een integratie was. Zie dat dat ook de way to go is nu, aangezien MQTT op development halted staat. Goed om te weten... Dus Tasmota integratie of overstappen naar ESPHome... hmmm...

[Mars Warrior]

Septillion schreef op dinsdag 30 maart 2021 @ 10:07:
@lolgast Ze hebben in ieder geval goed hun best gedaan om van een mug een olifant te maken Meeste zijn drogredenen (stability of SPoF) of komen gewoon met andere nadelen (leesbaarheid van berichten vs kort zijn). Of ze hadden zelf gewoon een brakke MQTT implementatie...

Het zijn wel erg veel drogredenen ja, en de nadelen zijn ze vergeten

Natuurlijk zijn sockets/grpc sneller dan mqtt, al kan mqtt ook over websockets. Dat ga je bij 100.000 berichten / seconde ook echt wel merken, zowel in respons als in bandbreedte, maar dat zijn dingen die nooit van toepassing zullen zijn op een HA omgeving. Die paar berichtjes die dan of 1 of 5ms duren gaan het verschil niet maken voor de gebruiker met zijn 1GBit netwerk.

Voor mij zijn grote voordelen van de MQTT route dat ik mijn Tasmota devices:
- Kan delen tussen meerdere HA instanties
- De devices in verschillende netwerken kunnen zitten, dus niet enkel in mijn eigen LAN
- Ik buiten HA om ook eea kan besturen

Nogmaals, niets tegen ESPhome en wil heb zeker ook nog proberen want Tasmota kent ook gekke beperkingen. Maar MQTT is wat mij betreft daar geen onderdeel van.

De UI voor ESPHome is een stuk mooier en flexibeler, maar die heb ik tot nu toe nog nooit echt nodig gehad, dus heb ik tot nu toe niet als beperking van Tasmota (Admin) gezien.

Dat Nabu Casa nu ESPHome heeft 'overgenomen' omdat de ontwikkelaar ermee gestopt is, is wel heel fijn voor alle gebruikers van ESPHome.

[Mars Warrior]

Sp33dFr34k schreef op dinsdag 30 maart 2021 @ 11:47:
[...]
Ah, omdat je MQTT zei, wist niet eens dat er een integratie was. Zie dat dat ook de way to go is nu, aangezien MQTT op development halted staat. Goed om te weten... Dus Tasmota integratie of overstappen naar ESPHome... hmmm...

De autodiscovery voor HA staat op halted, maar alles gaat nog over MQTT
Als gebruiker merk je er dus niks van...

[Demo]

Mozart schreef op dinsdag 30 maart 2021 @ 11:40:
[...]

Ja, ik gebruik een esphome om de power op de printer te regelen, daarnaast heb ik een MQTT koppeling met octoprint zelf:
[Afbeelding]

Nice, er zitten wat features en bugfixes van mij in die plugin Ik heb dit weekend een PR gedaan om snapshots van de camera naar een MQTT topic te sturen en die als camera in HA te publiceren.

Mars Warrior schreef op dinsdag 30 maart 2021 @ 12:00:
[...]

De autodiscovery voor HA staat op halted, maar alles gaat nog over MQTT
Als gebruiker merk je er dus niks van...

Als het al werkt niet nee, maar als je het nog moet configureren of een nieuw apparaat wil toevoegen moet je dat dus met de hand doen?
Dat gezegd hebbende, mijn Shelly's draaien ESPHome en zitten in muren en plafonds, dat is voor mij een belangrijkere reden om niet over te stappen naar Tasmota dan een feature meer of minder

[Vorkie]

Maar wat is er mis met Mosquitto als MQTT broker en deze in HA koppelen...

Waarom moeten er allemaal fancy integrations gemaakt worden die schijnbaar het juist alleen maar lastiger maken

[Mars Warrior]

Demo schreef op dinsdag 30 maart 2021 @ 12:12:
[...]
Als het al werkt niet nee, maar als je het nog moet configureren of een nieuw apparaat wil toevoegen moet je dat dus met de hand doen?
Dat gezegd hebbende, mijn Shelly's draaien ESPHome en zitten in muren en plafonds, dat is voor mij een belangrijkere reden om niet over te stappen naar Tasmota dan een feature meer of minder

Je hoeft niks met de hand te doen. De integratie ziet automatisch je Tasmota devices, dus je entiteiten komen vanzelf in HA terecht.

[Septillion]

Demo schreef op dinsdag 30 maart 2021 @ 12:12:
Als het al werkt niet nee, maar als je het nog moet configureren of een nieuw apparaat wil toevoegen moet je dat dus met de hand doen?

Nee, nu loopt het standaard via de Tasmota integratie. Moet het zelf ook nog weer testen. Ik deed eens een testje tijdens de beta periode en dat beviel nog niet echt, dus hier draait alles nog via SO19.

Heb zelf dus ook nooit echt begrepen wat er mis is met MQTT auto discovery en/of waarom dat niet gewoon daar gefixt is.

[Mars Warrior]

Vorkie schreef op dinsdag 30 maart 2021 @ 12:16:
Maar wat is er mis met Mosquitto als MQTT broker en deze in HA koppelen...

Waarom moeten er allemaal fancy integrations gemaakt worden die schijnbaar het juist alleen maar lastiger maken

Geen idee.
MQTT is voor mij al jaren de enige stabiele integratie binnen HA geweest zonder breaking changes:
- Tasmota voor alles over WiFi
- Zigbee2mqtt voor alles over Zigbee
- Zwave2mqtt voor alles over zwave
- DSMR Reader voor mijn slimme meter

De directe, custom integraties ontgaan mij ook, maar waarschijnlijk hebben de ontwikkelaars hier goede redenen voor die ik niet ken...

De MQTT Auto Discovery is gewoon een puik idee geweest in het verleden

[ Voor 15% gewijzigd door Mars Warrior op 30-03-2021 12:28 ]

[barrymossel]

lolgast schreef op dinsdag 30 maart 2021 @ 09:28:
[...]

Omdat ESPHome en HA via een API communiceren, wat een snellere communicatie betekent dan via http/mqtt

Merkbaar sneller?

[lolgast]

barrymossel schreef op dinsdag 30 maart 2021 @ 13:10:
[...]

Merkbaar sneller?

Nee. Maar mijn (wifi) netwerk is ook gewoon in orde Maargoed, opzich snap ik het argument wel want het gaat van ESP-device -> Ha ipv ESP-device -> MQTT Broker -> HA.

Dat het geen significante verbetering oplevert is wel logisch, want van <1ms naar <1ms merkt niemand denk ik

[TheFes]

Ik heb een tijdje geleden ook al mijn Tasmota devices omgezet naar ESPHome.
Waren vooral lampen en slimme stopcontactschakelaars.
Ik had al ESPHome voor Frenck's slimme deurbel, en had ook een aantal Shelly 1's naar ESPHome omgezet omdat ik die als detached switch werken, en ik dan in de config een fallback voor als HA niet werkt mee kan nemen.

Omdat MQTT alleen voor Tasmota in gebruik was, vond ik het wel fijn om alle Tasmota devces om te zetten naar ESPHome zodat ik ook geen MQTT meer nodig had.

Verder vind ik het wel fijn dat het makkelijk via YAML zelf aan te passen is, iets wat ik inmiddels wel redelijk in de vingers heb.

[mr3000]

Ik wil graag een keuze gaan maken voor thermostaat in mijn nieuwe huis welke ik over een maandje ga betrekken. Momenteel zit er een toon in het huis. maar wil eigelijk zoveel mogelijk gaan doen via een home assistant en een tablet tegen de muur. De vraag is even hoeveel meerwaarde heeft de toon dan nog. Natuurlijk komt er al een hoop info uit een toon.

wat is jullie ervaring. Toon, Nest of iets anders? Een nest zou voornamelijk esthetisch zijn.

[-Casper]

mr3000 schreef op dinsdag 30 maart 2021 @ 14:06:
Ik wil graag een keuze gaan maken voor thermostaat in mijn nieuwe huis welke ik over een maandje ga betrekken. Momenteel zit er een toon in het huis. maar wil eigelijk zoveel mogelijk gaan doen via een home assistant en een tablet tegen de muur. De vraag is even hoeveel meerwaarde heeft de toon dan nog. Natuurlijk komt er al een hoop info uit een toon.

wat is jullie ervaring. Toon, Nest of iets anders? Een nest zou voornamelijk esthetisch zijn.

Even googlen. Er zijn zat mensen die hun Toon hebben geroot en zo integreren met home assistant

[barrymossel]

lolgast schreef op dinsdag 30 maart 2021 @ 13:13:
[...]

Nee. Maar mijn (wifi) netwerk is ook gewoon in orde Maargoed, opzich snap ik het argument wel want het gaat van ESP-device -> Ha ipv ESP-device -> MQTT Broker -> HA.

Dat het geen significante verbetering oplevert is wel logisch, want van <1ms naar <1ms merkt niemand denk ik

Eerlijkheid gebiedt mij te zeggen dat ik daardoor ook geneigd ben naar ESPHome over te gaan. Aan de andere kant heb ik MQTT vooralsnog nodig voor Zigbee2MQTT (ZHA heeft (nog) geen ondersteuning een van mijn devices). En ik weet niet of ik op nog meer YAML zit te wachten. Automations ben ik regelmatig mee bezig, dus dan leer je het wel een beetje. De ESPHome devices zet je eenmalig op en dan moet het werken. Dus eenmalig een uurtje voor al m'n devices met wat opzoekwerk. Als ik dan de volgende keer weer een device moet instellen, dan kan ik weer alles opnieuw opzoeken (ben de jongste niet meer).

Zodra ze met een GUI komen om standaard zaken in te stellen ben ik om. Denk ik...

[Dacuuu]

Mars Warrior schreef op dinsdag 30 maart 2021 @ 12:22:
[...]

Geen idee.
MQTT is voor mij al jaren de enige stabiele integratie binnen HA geweest zonder breaking changes:
- Tasmota voor alles over WiFi
- Zigbee2mqtt voor alles over Zigbee
- Zwave2mqtt voor alles over zwave
- DSMR Reader voor mijn slimme meter

De directe, custom integraties ontgaan mij ook, maar waarschijnlijk hebben de ontwikkelaars hier goede redenen voor die ik niet ken...

De MQTT Auto Discovery is gewoon een puik idee geweest in het verleden

mosquitto mqtt draait hier ook rocksolid. En het is zo klein en rechttoe rechtaan dat het werkelijk nog nooit een hike-up gehad heeft hier. En MQTT is ook makkelijk via andere dingen te integreren, tasker bijvoorbeeld op android. En mosquitto hoef ik ook nooit te herstarten, heerlijk.

[JayOne]

barrymossel schreef op dinsdag 30 maart 2021 @ 15:21:
[...]

Eerlijkheid gebiedt mij te zeggen dat ik daardoor ook geneigd ben naar ESPHome over te gaan. Aan de andere kant heb ik MQTT vooralsnog nodig voor Zigbee2MQTT (ZHA heeft (nog) geen ondersteuning een van mijn devices). En ik weet niet of ik op nog meer YAML zit te wachten. Automations ben ik regelmatig mee bezig, dus dan leer je het wel een beetje. De ESPHome devices zet je eenmalig op en dan moet het werken. Dus eenmalig een uurtje voor al m'n devices met wat opzoekwerk. Als ik dan de volgende keer weer een device moet instellen, dan kan ik weer alles opnieuw opzoeken (ben de jongste niet meer).

Zodra ze met een GUI komen om standaard zaken in te stellen ben ik om. Denk ik...

Dat is het mooie van ESPHome. Je kopieert gewoon de yaml (paar kleine aanpassingen qua naam) en je hebt weer een device ingesteld. Alles binnen de GUI van ESPHome binnen HA (als je het als addon draait).

[Demo]

JayOne schreef op dinsdag 30 maart 2021 @ 16:00:
[...]

Dat is het mooie van ESPHome. Je kopieert gewoon de yaml (paar kleine aanpassingen qua naam) en je hebt weer een device ingesteld. Alles binnen de GUI van ESPHome binnen HA (als je het als addon draait).

Nog beter, je maakt per type device (Wemos bordje, Shelly) een generieke config met wat variabelen, dan hoef je per device alleen nog maar de device id en friendly name in te stellen, die config te includen en een paar regeltjes device-specifieke configuratie toe te voegen.

shelly1-common.yaml

YAML:

esphome:
  name: ${device_name}
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_psk

logger:
  level: info
  # baud_rate: 460800

# Enable Home Assistant API
api:
  password: !secret api_pass

ota:
  password: !secret ota_pass
  safe_mode: True

time:
  - platform: homeassistant
    id: hass_time
    timezone: 'Europe/Amsterdam'

binary_sensor:
  - platform: status
    id: '${device_name}_status'
    name: "${device_friendly} status"

  - platform: gpio
    pin:
      number: GPIO5
      #mode: INPUT_PULLUP
      #inverted: True
    name: '${device_friendly} switch'
    filters:
      - delayed_on: 10ms
      - delayed_off: 10ms
    on_press:
      then:
        - light.toggle: '${device_name}_light'
    internal: true
    id: '${device_name}_switch'

sensor:
  - platform: wifi_signal
    name: '${device_friendly} WiFi-signaal'
    id: '${device_name}_wifi'
    update_interval: 60s
  - platform: uptime
    name: "${device_friendly} uptime"
    id: ${device_name}_uptime
    update_interval: 60s

switch:
  - platform: restart
    id: '${device_name}_restart'
    name: '${device_friendly} restart'

text_sensor:
  - platform: version
    id: '${device_name}_version'
    name: '${device_friendly} version'

output:
  - platform: gpio
    pin: GPIO4
    id: '${device_name}_relay'

light:
  - platform: binary
    name: '${device_friendly}'
    output: '${device_name}_relay'
    id: '${device_name}_light'

shelly1_1.yaml

YAML:

substitutions:
  device_name: 'shelly1_1'
  device_friendly: 'Shelly1 1'

<<: !include shelly1-common.yaml

[Toppertje]

Toppertje schreef op maandag 29 maart 2021 @ 21:37:
Nadat ik in Home assistant continue een laadrondje bij de temperatuurmeter kreeg, heb ik geprobeerd de raspberry pi opnieuw op te starten, echter kreeg ik daarna geen contact...niks.
USB stick eruit en in de PC, krijg ik de melding: "De schijf is tegen schrijven beveiligd".
Toen ik op internet las dat de USB stick dan wel eens corrupt geraakt kan zijn heb ik nu een schone installatie van HA OS op een SSD gezet en ingeplugd, echter start de boel niet op en krijg ik geen contact.

Iemand de gouden tip om de boel weer aan de praat te krijgen?

Iemand een idee wat dit probleem zou kunnen veroorzaken en hoe ik het op kan lossen?

[Hmmbob]

mr3000 schreef op dinsdag 30 maart 2021 @ 14:06:
Ik wil graag een keuze gaan maken voor thermostaat in mijn nieuwe huis welke ik over een maandje ga betrekken. Momenteel zit er een toon in het huis. maar wil eigelijk zoveel mogelijk gaan doen via een home assistant en een tablet tegen de muur. De vraag is even hoeveel meerwaarde heeft de toon dan nog. Natuurlijk komt er al een hoop info uit een toon.

wat is jullie ervaring. Toon, Nest of iets anders? Een nest zou voornamelijk esthetisch zijn.

Ja, Toon rooten en gaan. Misschien kan @mAiden88 je helpen (geen garantie), of je in ieder geval op weg helpen.

[Hmmbob]

Demo schreef op dinsdag 30 maart 2021 @ 16:23:
[...]
Nog beter, je maakt per type device (Wemos bordje, Shelly) een generieke config met wat variabelen, dan hoef je per device alleen nog maar de device id en friendly name in te stellen, die config te includen en een paar regeltjes device-specifieke configuratie toe te voegen.

shelly1-common.yaml

YAML:

esphome:
  name: ${device_name}
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_psk

logger:
  level: info
  # baud_rate: 460800

# Enable Home Assistant API
api:
  password: !secret api_pass

ota:
  password: !secret ota_pass
  safe_mode: True

time:
  - platform: homeassistant
    id: hass_time
    timezone: 'Europe/Amsterdam'

binary_sensor:
  - platform: status
    id: '${device_name}_status'
    name: "${device_friendly} status"

  - platform: gpio
    pin:
      number: GPIO5
      #mode: INPUT_PULLUP
      #inverted: True
    name: '${device_friendly} switch'
    filters:
      - delayed_on: 10ms
      - delayed_off: 10ms
    on_press:
      then:
        - light.toggle: '${device_name}_light'
    internal: true
    id: '${device_name}_switch'

sensor:
  - platform: wifi_signal
    name: '${device_friendly} WiFi-signaal'
    id: '${device_name}_wifi'
    update_interval: 60s
  - platform: uptime
    name: "${device_friendly} uptime"
    id: ${device_name}_uptime
    update_interval: 60s

switch:
  - platform: restart
    id: '${device_name}_restart'
    name: '${device_friendly} restart'

text_sensor:
  - platform: version
    id: '${device_name}_version'
    name: '${device_friendly} version'

output:
  - platform: gpio
    pin: GPIO4
    id: '${device_name}_relay'

light:
  - platform: binary
    name: '${device_friendly}'
    output: '${device_name}_relay'
    id: '${device_name}_light'

shelly1_1.yaml

YAML:

substitutions:
  device_name: 'shelly1_1'
  device_friendly: 'Shelly1 1'

<<: !include shelly1-common.yaml

Pinned vanwege goed en duidelijk voorbeeld, tof!

[mr3000]

-Casper schreef op dinsdag 30 maart 2021 @ 14:53:
[...]

Even googlen. Er zijn zat mensen die hun Toon hebben geroot en zo integreren met home assistant

Dat was ook niet zozeer de vraag. meer of een geroote toon veel meerwaarde bied boven een nest bijvoorbeeld.

[DaLass]

mr3000 schreef op dinsdag 30 maart 2021 @ 16:59:
[...]

Dat was ook niet zozeer de vraag. meer of een geroote toon veel meerwaarde bied boven een nest bijvoorbeeld.

Aangezien de Toon er al hangt, biedt de (geroote) Toon in ieder geval op financieel gebied een meerwaarde, want die hoef je dus niet meer aan te schaffen.

Ik gebruik m eigenlijk alleen voor het uitlezen van de P1 data, de connectie naar mijn Z-Wave rookmelders en (sinds december) incidenteel voor verwarmen als de airco's het op een ijskoude dag niet trekken (wat nog niet gebeurd is).

Wat wil je kunnen met je thermostaat en HA? Dat zou volgens mij bepalend moeten zijn voor welke je dan moet kiezen.

[mr3000]

DaLass schreef op dinsdag 30 maart 2021 @ 17:06:
[...]

Aangezien de Toon er al hangt, biedt de (geroote) Toon in ieder geval op financieel gebied een meerwaarde, want die hoef je dus niet meer aan te schaffen.

Ik gebruik m eigenlijk alleen voor het uitlezen van de P1 data, de connectie naar mijn Z-Wave rookmelders en (sinds december) incidenteel voor verwarmen als de airco's het op een ijskoude dag niet trekken (wat nog niet gebeurd is).

Wat wil je kunnen met je thermostaat en HA? Dat zou volgens mij bepalend moeten zijn voor welke je dan moet kiezen.

Was meer vanuit toekomst perspectief gedacht. nu is het puur aansturen van tempratuur. Maar kan me heel goed voorstellen dat ik vrij snel meer wil kunnen doen zoals uitlezen van data.

[Visitor.q]

mr3000 schreef op dinsdag 30 maart 2021 @ 14:06:
Ik wil graag een keuze gaan maken voor thermostaat in mijn nieuwe huis welke ik over een maandje ga betrekken. Momenteel zit er een toon in het huis. maar wil eigelijk zoveel mogelijk gaan doen via een home assistant en een tablet tegen de muur. De vraag is even hoeveel meerwaarde heeft de toon dan nog. Natuurlijk komt er al een hoop info uit een toon.

wat is jullie ervaring. Toon, Nest of iets anders? Een nest zou voornamelijk esthetisch zijn.

Ik heb evaring met een Nefit Easy die via een custom integration de temperatuur (setpoint en actueel), status (bv verwarmen, standby) laat uitlezen als sensor en allerlei entities als switches aanbiedt, bv vakantiestand, warm water, etc.

[sOid]

@mr3000 De Nest-integratie is een gedrocht. Het werkt, maar is veel werk om op te zetten. Qua hardware vind ik het echt een prachtding. Bediening en interface zijn ook goed. Maar ik zou 'm vanwege Google en API-geklooi niet opnieuw kopen.

[mAiden88]

mr3000 schreef op dinsdag 30 maart 2021 @ 14:06:
Ik wil graag een keuze gaan maken voor thermostaat in mijn nieuwe huis welke ik over een maandje ga betrekken. Momenteel zit er een toon in het huis. maar wil eigelijk zoveel mogelijk gaan doen via een home assistant en een tablet tegen de muur. De vraag is even hoeveel meerwaarde heeft de toon dan nog. Natuurlijk komt er al een hoop info uit een toon.

wat is jullie ervaring. Toon, Nest of iets anders? Een nest zou voornamelijk esthetisch zijn.

Als je voor een Toon gaat, wil ik natuurlijk wel helpen met het rooten en het integreren in Home Assistant. Root duurt maximaal uurtje, ik zorg ervoor dat Toon geroot is, geactiveerd is, voorzien is van de meest recente software versie.. Ik ben zelf lid van het TSC Team, dit team bedenkt en maakt alle apps en root mogelijkheden op Toon.

Thanks voor de tag @Hmmbob

[Vorkie]

@mr3000 Je kan inderdaad met een Toon die vrij is veel meer

Uitlezen P1 (zie je ook hoeveel je terugstuurt als je zonnepanelen hebt)
https://github.com/cyberjunky/home-assistant-toon_smartmeter



En natuurlijk thermostaat, inclusief de 4(5) tegeltjes met "weg, slapen, thuis, comfort)
https://github.com/cyberjunky/home-assistant-toon_climate



Deze boilerstatus heb ik zelf niet in gebruik: Nou ja, toch maar even ingesteld
https://github.com/cyberj...sistant-toon_boilerstatus

[ Voor 14% gewijzigd door Septillion op 31-03-2021 10:49 . Reden: Plaatje verkleint ]

[DaLass]

mr3000 schreef op dinsdag 30 maart 2021 @ 21:43:
[...]

Was meer vanuit toekomst perspectief gedacht. nu is het puur aansturen van tempratuur. Maar kan me heel goed voorstellen dat ik vrij snel meer wil kunnen doen zoals uitlezen van data.

Als ik in jouw schoenen zou staan, zou ik dan voor nu lekker die Toon laten hangen en deze eventueel (laten) rooten, en dan later eens kijken of je deze nog wilt vervangen of niet, nadat je klaar bent in je huis. Dat geld voor een nieuwe thermostaat vliegt eruit bij een verhuizing/verbouwing.

[Sine]

Toppertje schreef op maandag 29 maart 2021 @ 21:37:
... nu een schone installatie van HA OS op een SSD gezet en ingeplugd, echter start de boel niet op en krijg ik geen contact.

Iemand de gouden tip om de boel weer aan de praat te krijgen?

Is je usb-sata controller wel geschikt voor een pi4 (als je die gebruikt) de pi4 is nogal kieskeurig wat dat betreft.

[Hmmbob]

DaLass schreef op woensdag 31 maart 2021 @ 08:21:
[...]

Als ik in jouw schoenen zou staan, zou ik dan voor nu lekker die Toon laten hangen en deze eventueel (laten) rooten, en dan later eens kijken of je deze nog wilt vervangen of niet, nadat je klaar bent in je huis. Dat geld voor een nieuwe thermostaat vliegt eruit bij een verhuizing/verbouwing.

Dit inderdaad. Ik zie zelf geen meerwaarde van een Nest over een gerootte Toon.

Ik gebruik hem inderdaad ook als thermostaat (natuurlijk) en om de P1 gegevens uit te lezen. Daarnaast laat ik een kaartje van mijn locatie zien op 1 van de tiles en heb ik een custom RSS feed met wat standaard gegevens (wat benzine prijzen, mijn locatie ook weer) draaien. Ook kan de verlichting worden bediend via emulated hue.

(linkjes naar mijn relevante github config)

[ Voor 49% gewijzigd door Hmmbob op 31-03-2021 08:56 ]

[haborym]

Ik ben in gevecht met DSMRLogger. Ik heb die draaien bij mijn slimme meter en deze stuurt ook via MQTT de waardes door.

In de config heb ik een sensor aangemaakt

code:

  - platform: mqtt
    name: "Energy Returned T1"
    state_topic: "p1meter/energy_returned_tariff1"
    unit_of_measurement: "kWh"
    value_template: "{{ value_json.energy_returned_tariff1 | round(3) }}"

De waarde die ik in HA te zien krijg is: [{'value': 1.549, 'unit': 'kW'}] kW

Als ik kijk naar de waarde die binnen komt om MQTT : {"power_returned": [{"value": 1.601, "unit": "kW"}]}

Ik ben in gevecht maar kom er niet uit. Ik vermoed dat ik een denkfout maak waar ik niet achter kom

Iemand ervaring?

[Septillion]

@haborym Denk dat je ook een copy past foutje hebt gemaakt dus ik ga even alleen uit van 'energy_returned_tariff1' en dat deze dus gelijk is aan 'power_returned'.

YAML:

  - platform: mqtt
    name: "Energy Returned T1"
    state_topic: "p1meter/energy_returned_tariff1"
    unit_of_measurement: "kWh"
    value_template: "{{ value_json.energy_returned_tariff1[0].value | round(3) }}"

[haborym]

Septillion schreef op woensdag 31 maart 2021 @ 09:51:
@haborym Denk dat je ook een copy past foutje hebt gemaakt dus ik ga even alleen uit van 'energy_returned_tariff1' en dat deze dus gelijk is aan 'power_returned'.

YAML:

  - platform: mqtt
    name: "Energy Returned T1"
    state_topic: "p1meter/energy_returned_tariff1"
    unit_of_measurement: "kWh"
    value_template: "{{ value_json.energy_returned_tariff1[0].value | round(3) }}"

Je hebt gelijk. Gaat om deze sensor.

code:

  - platform: mqtt
    name: "Energy Returned T1"
    state_topic: "p1meter/energy_returned_tariff1"
    unit_of_measurement: "kWh"
    value_template: "{{ value_json.energy_returned_tariff1 | round(3) }}"

[Koepert]

Dit voelt als een hele domme vraag.. maar here we go.

Ik gebruik de HA addon NGINX Proxy Manager.

Daarin heb ik een duckdns domein, op het hoofddomein doorverwezen naar HA, zodat ik die extern kan benaderen. Dus

code:

xxx.duckdns.org >> xxx.xxx.:8123

Kun je dan met datzelfde domein ook doorverwijzen naar ANDERE interne IPs?

Dus bijvoorbeeld:

code:

duckdns.org/finance >> Firefly intern URL
duckdns.org/management >> Proxmox beheerpagina

?

Of werkt dat niet en ben je daar een eigen domein voor nodig?

[Septillion]

@haborym Dan zie het antwoord voor de oplossing

Graag niet topic report gebruiken om te antwoorden

[Septillion]

@Koepert Geen ervaring mee maar volgens mij is dat nu juist het idee van NGINX Proxy Manager?

[haborym]

@Septillion
Ik maak er vanmorgen een zooitje van. Heb denk ik wat extra koffie nodig .

Even opnieuw starten;

Dit is mijn sensor:

code:

  - platform: mqtt
    name: "Energy Returned T1"
    state_topic: "p1meter/energy_returned_tariff1"
    unit_of_measurement: "kWh"
    value_template: "{{ value_json.energy_returned_tariff1 | round(3) }}"

Dit komt binnen op MQTT: {"power_returned": [{"value": 1.601, "unit": "kW"}]}

Dit komt terug in HA : Power Returned [{'value': 2.252, 'unit': 'kW'}] kW


HIerbij het plaatje uit HA.

Wellicht maakt dit mijn vraag wat overzichtelijker.

[ Voor 1% gewijzigd door Septillion op 31-03-2021 10:48 . Reden: Plaatje verkleint ]

[Septillion]

haborym schreef op woensdag 31 maart 2021 @ 10:21:
@Septillion
Ik maak er vanmorgen een zooitje van. Heb denk ik wat extra koffie nodig .

Denk nog steeds Heb het antwoord namelijk al gegeven in mijn eerste reactie Ook mix je weer 'energy_returned_tariff1' en 'power_returned'. Dus ik zeg, koffie pakken en nog eens lezen

[gri-]

Ik ben op zoek naar een luchtvochtigheidssensor voor in de badkamer om automatisch de ventilator te regelen via home assistant.

Ik had nog een multisensor 6 van aeotec, alleen op batterijen update die niet erg vaak.
Nu heb ik er een powerbank aangehangen, maar die trekt hij in een paar dagen leeg.
Ben nog van plan om te kijken of ik daar iets aan kan verbeteren met de config, maar dat lijkt beperkt.

Ik wil dus eigenlijk een sensor:
- alleen luchtvochtigheid is prima.
- snel verandering in luchtvochtigheid opmerken zodat de ventilator niet pas aan gaat als je aan het afdrogen bent.
- op batterijen of te voeden met de powerbank.
- liefst z-wave (heb ik al) of iets zonder dat ik een nieuwe stick nodig heb, maar dit is minder belangrijk dan de vorige punten.

Heeft iemand van jullie daar een aanrader voor?

[sOid]

Koepert schreef op woensdag 31 maart 2021 @ 09:57:
Dit voelt als een hele domme vraag.. maar here we go.

Ik gebruik de HA addon NGINX Proxy Manager.

Daarin heb ik een duckdns domein, op het hoofddomein doorverwezen naar HA, zodat ik die extern kan benaderen. Dus

code:

xxx.duckdns.org >> xxx.xxx.:8123

Kun je dan met datzelfde domein ook doorverwijzen naar ANDERE interne IPs?

Dus bijvoorbeeld:

code:

duckdns.org/finance >> Firefly intern URL
duckdns.org/management >> Proxmox beheerpagina

?

Of werkt dat niet en ben je daar een eigen domein voor nodig?

Dat hangt van de mogelijkheden bij DuckDNS af. Kun je bijvoorbeeld xxx.duckdns.org/finance aanmaken? Zo ja, dan wel. Zo nee, dan heb je een eigen domein nodig.

NGINX zorgt voor interne afhandeling, niet voor de bron-URL. Je kunt dus zowel xxx.duckdns.org als /finance en /management naar exact hetzelfde IP laten verwijzen. NGINX handelt dat dan intern af.

Gewoon een domeintje kopen, kost je een tientje per jaar of zo

Edit: overigens moet je afvragen of je dit überhaupt wil. Want zowel /finance als /management zijn interne diensten neem ik aan. Lijkt me niet verstandig om die beschikbaar te maken voor WAN.

gri- schreef op woensdag 31 maart 2021 @ 11:32:
Ik ben op zoek naar een luchtvochtigheidssensor voor in de badkamer om automatisch de ventilator te regelen via home assistant.

Ik had nog een multisensor 6 van aeotec, alleen op batterijen update die niet erg vaak.
Nu heb ik er een powerbank aangehangen, maar die trekt hij in een paar dagen leeg.
Ben nog van plan om te kijken of ik daar iets aan kan verbeteren met de config, maar dat lijkt beperkt.

Ik wil dus eigenlijk een sensor:
- alleen luchtvochtigheid is prima.
- snel verandering in luchtvochtigheid opmerken zodat de ventilator niet pas aan gaat als je aan het afdrogen bent.
- op batterijen of te voeden met de powerbank.
- liefst z-wave (heb ik al) of iets zonder dat ik een nieuwe stick nodig heb, maar dit is minder belangrijk dan de vorige punten.

Heeft iemand van jullie daar een aanrader voor?

Ik kan de Aqara temperatuursensor aanraden. Kost geen zak, registreert het snel. Maar is wel Zigbee, dus weet niet of dat een optie voor je is. Knoopcelbatterijtje gaat ook dik een jaar mee.

[ Voor 4% gewijzigd door sOid op 31-03-2021 12:48 ]

[Septillion]

@sOid DuckDNS doet toch gewoon wat de naam zegt, doet de DNS. Dus zorgt alleen voor de resolve van xxx.duckdns.org naar ip. Poorten en path kijkt het niet naar, dat is voor de werkelijke server achter het ip om af te handelen. Of is ik dan iets?

En juist dDNS met gewoon een domeintje is lastiger...

[Hmmbob]

nginx of Traefik zijn hier geschikte oplossingen inderdaad. maar ik dnek dat we afdwalen

[sOid]

Septillion schreef op woensdag 31 maart 2021 @ 12:54:
@sOid DuckDNS doet toch gewoon wat de naam zegt, doet de DNS. Dus zorgt alleen voor de resolve van xxx.duckdns.org naar ip.

Ik ken DuckDNS alleen van naam, dus ik weet niet precies wat wel en niet kan. Maar als je xxx.duckdns.org/bla kunt aanmaken dan kan NGINX het verder afhandelen.

Poorten en path kijkt het niet naar, dat is voor de werkelijke server achter het ip om af te handelen. Of is ik dan iets?

Dat klopt, maar voor zover ik weet moet NGINX wel een sub/slug kúnnen controleren. Ik denk niet dat het mogelijk is om NGINX zo te configueren dat 'ie /finance goed doorverwijst terwijl /finance niet bij je DNS is aangemaakt. Maar ik kan het mis hebben.

Ik dat geval zou het voldoende zijn om alleen hoofddomein aan te maken en kun je lukraak elke slug gebruiken en via NGINX verder laten afhandelen.

En juist dDNS met gewoon een domeintje is lastiger...

Dat is zeker zo. Maar ja, hoe vaak krijg in de praktijk een ander IP toegewezen? Bij mijn huidige provider is dat ongeveer 1x per half jaar. Bij mijn vorige provider had ik 8 jaar dezelfde.

Ik verwijs nu alles met een CNAME door naar mijn dDNS-URL (die dDNS-URL wordt automatisch aangemaakt door m'n Mikrotik router).

Voor de grap even geprobeerd om een van m'n DNS records te verwijderen. En ook geprobeerd om extra NGINX-config aan te maken (met bla.mijndomein.nl) zonder die record aan DNS toe te voegen. Dan krijg ik meteen een foutmelding van NGINX:

code:

   Domain: bla.mijndomein.nl
   Type:   dns
   Detail: DNS problem: NXDOMAIN looking up A for bla.mijndomein.nl -
   check that a DNS record exists for this domain

[golles]

sOid schreef op woensdag 31 maart 2021 @ 13:41:
[...]

Ik ken DuckDNS alleen van naam, dus ik weet niet precies wat wel en niet kan. Maar als je xxx.duckdns.org/bla kunt aanmaken dan kan NGINX het verder afhandelen.


[...]

Dat klopt, maar voor zover ik weet moet NGINX wel een sub/slug kúnnen controleren. Ik denk niet dat het mogelijk is om NGINX zo te configueren dat 'ie /finance goed doorverwijst terwijl /finance niet bij je DNS is aangemaakt. Maar ik kan het mis hebben.

Ik dat geval zou het voldoende zijn om alleen hoofddomein aan te maken en kun je lukraak elke slug gebruiken en via NGINX verder laten afhandelen.


[...]

Dat is zeker zo. Maar ja, hoe vaak krijg in de praktijk een ander IP toegewezen? Bij mijn huidige provider is dat ongeveer 1x per half jaar. Bij mijn vorige provider had ik 8 jaar dezelfde.

Ik verwijs nu alles met een CNAME door naar mijn dDNS-URL (die dDNS-URL wordt automatisch aangemaakt door m'n Mikrotik router).

Voor de grap even geprobeerd om een van m'n DNS records te verwijderen. En ook geprobeerd om extra NGINX-config aan te maken (met bla.mijndomein.nl) zonder die record aan DNS toe te voegen. Dan krijg ik meteen een foutmelding van NGINX:

code:

   Domain: bla.mijndomein.nl
   Type:   dns
   Detail: DNS problem: NXDOMAIN looking up A for bla.mijndomein.nl -
   check that a DNS record exists for this domain

nginx kan zowel met subdomeinen als subfolders werken. Het enige wat je moet doen is de duckdns naar je externe ip verwijzen waar nginx draait. Dan moet je nginx zo configureren dat hij het verder afhandeld. SWAG, waar wij allebei veel plezier van hebben heeft voor beide types voorbeelden: https://github.com/linuxserver/reverse-proxy-confs

DDNS zelf doen is niet zo heel moeilijk hoor er zijn voor veel systemen wel (bash/python) scriptjes te vinden die je kan gebruiken. Ik heb zelf 1 gemaakt voor directadmin en die trigger ik dmv een automation als deze sensor veranderd: https://www.home-assistant.io/integrations/dnsip/

[drice]

sOid schreef op woensdag 31 maart 2021 @ 12:46:
Ik kan de Aqara temperatuursensor aanraden. Kost geen zak, registreert het snel. Maar is wel Zigbee, dus weet niet of dat een optie voor je is. Knoopcelbatterijtje gaat ook dik een jaar mee.

Ik heb nu de Sonoff sensoren alleen die vallen redelijk snel uit en zijn daarna dood. Zijn die Aqara sensoren veel beter dan Sonoff?

[sOid]

golles schreef op woensdag 31 maart 2021 @ 13:53:
[...]


nginx kan zowel met subdomeinen als subfolders werken. Het enige wat je moet doen is de duckdns naar je externe ip verwijzen waar nginx draait. Dan moet je nginx zo configureren dat hij het verder afhandeld. SWAG, waar wij allebei veel plezier van hebben heeft voor beide types voorbeelden: https://github.com/linuxserver/reverse-proxy-confs

Nou, dat heb ik dus net geprobeerd! Dus inderdaad een extra config aangemaakt voor SWAG/NGINX, zonder daadwerkelijke DNS-record aan te maken. En dat gaat dus fout.

Misschien doordat ik het heb getest met subdomein ipv subfolder, kan zijn dat daar nog verschil in zit.

[sOid]

drice schreef op woensdag 31 maart 2021 @ 13:56:
[...]


Ik heb nu de Sonoff sensoren alleen die vallen redelijk snel uit en zijn daarna dood. Zijn die Aqara sensoren veel beter dan Sonoff?

Ik heb geen ervaring met Sonoff, dus ik kan het niet vergelijken. Maar ik kan je wel vertellen dat ik dik tevreden ben met de Aqara sensoren. Het enige is dat de waardes soms niet helemaal kloppen, maar daar valt mee te leven voor mijn gebruik.

[golles]

sOid schreef op woensdag 31 maart 2021 @ 13:56:
[...]

Nou, dat heb ik dus net geprobeerd! Dus inderdaad een extra config aangemaakt voor SWAG/NGINX, zonder daadwerkelijke DNS-record aan te maken. En dat gaat dus fout.

Misschien doordat ik het heb getest met subdomein ipv subfolder, kan zijn dat daar nog verschil in zit.

Een subdomein moet inderdaad een eigen (of wildcard) DNS record hebben, voor subfolders maakt dat niet uit, omdat het domein hetzelfde is.

[Hmmbob]

Volgens mij had duckDNS ook wildcard voor subdomeinen?

Dus dat https://finance.***.duckdns.org wortd doorverwezen naar hetzelfde IP als https://***.duckdns.org

[ Voor 5% gewijzigd door Hmmbob op 31-03-2021 14:25 ]

[sOid]

golles schreef op woensdag 31 maart 2021 @ 14:11:
[...]

Een subdomein moet inderdaad een eigen (of wildcard) DNS record hebben, voor subfolders maakt dat niet uit, omdat het domein hetzelfde is.

Ah! Wat geleerd vandaag!

Nou ja, ik werk liever met subdomeinen. En ik heb wildcardfobie van m'n IT-collega's overgenomen, haha. Al is dat voor een thuisomgeving natuurlijk allemaal niet zo spannend.

[Dutchess_Nicole]

Nou mijn avontuur met Hass begint al goed:

Ik heb een paar maanden terug een hoopje SD kaartjes besteld: 5 Samsung EVO Plus 32GB kaartjes.
Wat aan de goedkope kant, dat wel. Maar ik had toch alleen nog maar een Pihole en Unifi controller erop draaien (plus wat smokepings voor mijn internet monitoring maar dat is pas later interressant)

Kreeg ik vandaag dus mijn nieuwe Pi 3B+ binnen en de PoE hat die ik erbij neem zodat ik hem in mijn switch kan prikken en klaar toch?

Niet dus.

Homeassistant op zich bootte goed op. Alleen werkt het netwerk gedeelte niet omdat hij bij default ingesteld is om op de untagged vlan 1 zijn DHCP gegevens te krijgen.

Die heb ik niet. De enige apparaten die daarop terecht komen zijn de Unifi dingen, en de controller zelf, waardoor de autodiscovery kan werken. Maar daar draait geen DHCP etc... op.

Dus ik voeg een tagged interface toe zodat de Hass Pi zijn adresje kan ophalen, dat werkt na een beetje frutselen (Ik ben ifupdown gewend. nmcli raak ik nooit aan) wel en ik heb de vlan tagged interface.

Rebootje en ik ben blij! Apparaat verschijnt in de unifi controller met het adres dat ik heb opgegeven! Kat in 't bakkie! Even naar homeassistant.local en... unreachable...? IP? Ook niks. Ping geeft ook geen antwoord dus... wtf?

Na veel hannessen heb ik de Pi dus op mijn bureau gekregen met een PoE patch die maar even via de muur loopt en ik kijk via de HDMI link van mijn monitor naar wat het ding nou aan het doen is.

Wat blijkt nou, de Pi start netjes op en de HassOS boot volledig. Normaal zou er daarna een update rondje plaatsvinden van alle containers ed die erin zitten.

Daar gaat het mis bij dit ding. De updates triggeren zoveel IO/CPU of iets anders (top gaf CPU aan) dat de hele Pi stallt en volledig stil komt te liggen. Hetzelfde gebeurt met raspbian als ik een apt update doe. Zelfde stall.

Ik heb verschillende SD kaarten geprobeerd en zelfs vanaf USB booten maar geen geluk.

Ik was zo blij om met Hass aan de slag te gaan... maar ik zal eerst de Pi moeten terugsturen, een nieuwe krijgen en hopen dat die wel goed werkt... Teleurstellend begin zeg maar.

[sOid]

@Dutchess_Nicole Zo! Balen dat het zo ingewikkeld gaat. Aangezien je het over Unifi e.d hebt... Heb je niet ook een NAS of NUC staan waarop je HA kunt draaien?

[royalt123]

Dat is vervelend maar ik begrijp 1 ding niet waarom je jezelf moeilijk maakt door netwerk tag instellen etc inplaats van gewoon op switch juiste vlan native/untagged zet?

En probeer ook op ip te connecteren inplaats van homeassistant.local.

Hopelijk breng 2de pi meer geluk want home assistant is echt geweldig.

Dutchess_Nicole schreef op woensdag 31 maart 2021 @ 18:42:
Nou mijn avontuur met Hass begint al goed:

Ik heb een paar maanden terug een hoopje SD kaartjes besteld: 5 Samsung EVO Plus 32GB kaartjes.
Wat aan de goedkope kant, dat wel. Maar ik had toch alleen nog maar een Pihole en Unifi controller erop draaien (plus wat smokepings voor mijn internet monitoring maar dat is pas later interressant)

Kreeg ik vandaag dus mijn nieuwe Pi 3B+ binnen en de PoE hat die ik erbij neem zodat ik hem in mijn switch kan prikken en klaar toch?

Niet dus.

Homeassistant op zich bootte goed op. Alleen werkt het netwerk gedeelte niet omdat hij bij default ingesteld is om op de untagged vlan 1 zijn DHCP gegevens te krijgen.

Die heb ik niet. De enige apparaten die daarop terecht komen zijn de Unifi dingen, en de controller zelf, waardoor de autodiscovery kan werken. Maar daar draait geen DHCP etc... op.

Dus ik voeg een tagged interface toe zodat de Hass Pi zijn adresje kan ophalen, dat werkt na een beetje frutselen (Ik ben ifupdown gewend. nmcli raak ik nooit aan) wel en ik heb de vlan tagged interface.

Rebootje en ik ben blij! Apparaat verschijnt in de unifi controller met het adres dat ik heb opgegeven! Kat in 't bakkie! Even naar homeassistant.local en... unreachable...? IP? Ook niks. Ping geeft ook geen antwoord dus... wtf?

Na veel hannessen heb ik de Pi dus op mijn bureau gekregen met een PoE patch die maar even via de muur loopt en ik kijk via de HDMI link van mijn monitor naar wat het ding nou aan het doen is.

Wat blijkt nou, de Pi start netjes op en de HassOS boot volledig. Normaal zou er daarna een update rondje plaatsvinden van alle containers ed die erin zitten.

Daar gaat het mis bij dit ding. De updates triggeren zoveel IO/CPU of iets anders (top gaf CPU aan) dat de hele Pi stallt en volledig stil komt te liggen. Hetzelfde gebeurt met raspbian als ik een apt update doe. Zelfde stall.

Ik heb verschillende SD kaarten geprobeerd en zelfs vanaf USB booten maar geen geluk.

Ik was zo blij om met Hass aan de slag te gaan... maar ik zal eerst de Pi moeten terugsturen, een nieuwe krijgen en hopen dat die wel goed werkt... Teleurstellend begin zeg maar.

[Dutchess_Nicole]

Ik heb een NASje ja, maar dat is er zo 1 waar je geen docker etc... op kan draaien.
Het is een RS 819. Geen plusje, volgens mij kan ik de RAM ervan niet eens uitbreiden.

Behalve dat niet echt nee. Ik heb een server draaien maar dat ding loopt al op z'n laatste poten dus daar wil ik niet ook nog eens dit bovenop stapelen.
Jammer, gewoon nog even wachten.

royalt123 schreef op woensdag 31 maart 2021 @ 19:05:
Dat is vervelend maar ik begrijp 1 ding niet waarom je jezelf moeilijk maakt door netwerk tag instellen etc inplaats van gewoon op switch juiste vlan native/untagged zet?

En probeer ook op ip te connecteren inplaats van homeassistant.local.

Hopelijk breng 2de pi meer geluk want home assistant is echt geweldig.


[...]

Omdat ik een management vlan heb waar ik management tools op zet. HASS is nou precies iets wat in het management netwerk thuishoort. Alle apparaten die erbij horen zitten in hun eigen IoT netwerk en die kunnen dus vanuit mgmt benaderd worden.

Netwerk segmentatie dus.

[ Voor 50% gewijzigd door Dutchess_Nicole op 31-03-2021 19:11 ]

[mr3000]

mAiden88 schreef op woensdag 31 maart 2021 @ 07:44:
[...]


Als je voor een Toon gaat, wil ik natuurlijk wel helpen met het rooten en het integreren in Home Assistant. Root duurt maximaal uurtje, ik zorg ervoor dat Toon geroot is, geactiveerd is, voorzien is van de meest recente software versie.. Ik ben zelf lid van het TSC Team, dit team bedenkt en maakt alle apps en root mogelijkheden op Toon.

Thanks voor de tag @Hmmbob

Tof dan gaan we zeker voor de Toon, zie hier naast jouw reactie een hoop andere reacties welke dit onderbouwen. Super.

[golles]

sOid schreef op woensdag 31 maart 2021 @ 15:06:
[...]

Ah! Wat geleerd vandaag!

Nou ja, ik werk liever met subdomeinen. En ik heb wildcardfobie van m'n IT-collega's overgenomen, haha. Al is dat voor een thuisomgeving natuurlijk allemaal niet zo spannend.

Ik vind subdomeinen ook prettiger, het typt ook makkelijker app.domein ipv domein/app (en waarschijnlijk pakt de history/auto complete van je browser het al na het typen van 2 of 3 teken).

Ik had eerst ook wildcard, maar dat stond me ook niet aan, daarom heb het veranderd, ik heb zelfs multi level subdomains (bv. ha.huis.domein.nl), waarbij het 1e subdomein (huis in dit voorbeeld) naar mijn huis gaat en daar nginx de multi level afhandeld voor de applicaties die ik open heb staan.

[icecreamfarmer]

Hmmbob schreef op zondag 28 maart 2021 @ 20:35:
Ik heb weinig verschil gemerkt in cpu belasting met zwavejs2mqtt - ding staat nog steeds bijna niets te doen.

Was je opgevallen dat zijn post aangepast was van zwave2mqtt naar zwavejs2mqtt?

Heb jij dat ook werkend in NodeRed gekregen?
Heb nu dit geinstalleerd: https://flows.nodered.org/node/node-red-contrib-zwavejs2mqtt
maar geen idee hoe ik het moet gebruiken om bv info te krijgen of de rolluiken dicht zijn.

De andere is deze: https://flows.nodered.org/node/node-red-contrib-zwave-js
maar die werkt niet met de mqtt versie, hij weigert te installeren.

[sOid]

golles schreef op woensdag 31 maart 2021 @ 21:29:
[...]

Ik vind subdomeinen ook prettiger, het typt ook makkelijker app.domein ipv domein/app (en waarschijnlijk pakt de history/auto complete van je browser het al na het typen van 2 of 3 teken).

Ik had eerst ook wildcard, maar dat stond me ook niet aan, daarom heb het veranderd, ik heb zelfs multi level subdomains (bv. ha.huis.domein.nl), waarbij het 1e subdomein (huis in dit voorbeeld) naar mijn huis gaat en daar nginx de multi level afhandeld voor de applicaties die ik open heb staan.

Kun je het op die manier eigenlijk ook intern opzetten? Dus bijvoorbeeld influxdb.huis.domein.nl, dat dan alleen via je LAN bereikbaar is, terwijl huis.domein.nl wel openstaat voor de buitenwereld?

[Hmmbob]

icecreamfarmer schreef op woensdag 31 maart 2021 @ 21:43:
[...]


Heb jij dat ook werkend in NodeRed gekregen?
Heb nu dit geinstalleerd: https://flows.nodered.org/node/node-red-contrib-zwavejs2mqtt
maar geen idee hoe ik het moet gebruiken om bv info te krijgen of de rolluiken dicht zijn.

De andere is deze: https://flows.nodered.org/node/node-red-contrib-zwave-js
maar die werkt niet met de mqtt versie, hij weigert te installeren.

Ik gebruik geen node-red.

[icecreamfarmer]

Hmmbob schreef op woensdag 31 maart 2021 @ 22:04:
[...]

Ik gebruik geen node-red.

Misschien moet ik hier omheen programmeren dan.
Hoe haal jij bv de status van een zwave apparaat op?

[Hmmbob]

icecreamfarmer schreef op woensdag 31 maart 2021 @ 22:13:
[...]


Misschien moet ik hier omheen programmeren dan.
Hoe haal jij bv de status van een zwave apparaat op?

Met zwavejs2mqtt

[ Voor 18% gewijzigd door Hmmbob op 31-03-2021 22:20 ]

[icecreamfarmer]

Hmmbob schreef op woensdag 31 maart 2021 @ 22:20:
[...]

Met zwavejs2mqtt

Ja dat snap ik. Maar ik wil bv controleren of de rolluiken al open zijn voordat ik een commando verstuur.
Hoe voer ik die check uit?

[Hmmbob]

icecreamfarmer schreef op woensdag 31 maart 2021 @ 22:32:
[...]


Ja dat snap ik. Maar ik wil bv controleren of de rolluiken al open zijn voordat ik een commando verstuur.
Hoe voer ik die check uit?

Mijn cover entity (cover.zolder) heeft als attributen o.a. een current_position. 0 is dicht, weet zo even niet wat open is (kind slaapt) maar daar zou je iets mee kunnen.

Eerlijk gezegd interesseert me de huidige positie niet als ik het commando verstuur? Als ik verstuur dat hij dicht moet maar nog niet dicht is, dan gaat hij dicht. Is hij al wel dicht? Dan gebeurt er niets - ondanks dat het commando verstuurd wordt dus. De cover reageert simpelweg niet

edit volgende ochtend: current_position: 100 is volledig open.

[ Voor 6% gewijzigd door Hmmbob op 01-04-2021 09:11 ]

[royalt123]

Ja dat kan zeker, ik doet het zo bij mij.
Voor extern toegang : toepassingnaam.domain.be = WAN IP
Voor intern toegang: toepassingnaam.intern.domain.be = Intern IP.

Wildcard voor intern domain en gewone voor extern.

Ik draai wel eigen dns server voor intern domain dns resolving. Je kan ook zonder doen dus via registar dns maar dan weet iedereen intern ip.

Ik gebruik reverse proxy op synology nas, dat werkt uitstekend met automatisch certificaat renew en wan ip change voor dns record.
Alle interne toepassing heeft dan mooi https connectie :-)

1 nadeel aan mijn methode is dat url voor intern en extern niet hetzelfde is, je kan dat wel doen maar dan moet je alle dns record insteken op interne dns server.

sOid schreef op woensdag 31 maart 2021 @ 21:53:
[...]

Kun je het op die manier eigenlijk ook intern opzetten? Dus bijvoorbeeld influxdb.huis.domein.nl, dat dan alleen via je LAN bereikbaar is, terwijl huis.domein.nl wel openstaat voor de buitenwereld?

[ Voor 8% gewijzigd door royalt123 op 31-03-2021 23:50 ]

[icecreamfarmer]

Hmmbob schreef op woensdag 31 maart 2021 @ 22:41:
[...]

Mijn cover entity (cover.zolder) heeft als attributen o.a. een current_position. 0 is dicht, weet zo even niet wat open is (kind slaapt) maar daar zou je iets mee kunnen.

Eerlijk gezegd interesseert me de huidige positie niet als ik het commando verstuur? Als ik verstuur dat hij dicht moet maar nog niet dicht is, dan gaat hij dicht. Is hij al wel dicht? Dan gebeurt er niets - ondanks dat het commando verstuurd wordt dus. De cover reageert simpelweg niet

edit volgende ochtend: current_position: 100 is volledig open.

Ik heb ook een half open stand als scene ingesteld staan. Dan moet hij open of dicht niet triggeren.
En ik wil een check invoeren dat ze allemaal open moeten staan voordat sommige functie sop basis van de zon getriggered worden. Dit zodat de glazenwasser zijn werk kan doen.

In een andere vraag, heeft iemand dit ding:
pricewatch: MCO Home MCOHome Multi-Sensor A8-9

Zo ja werkt hij goed en is het scherm eventueel ook uit te zetten?

[Koepert]

Dank allen voor de info Hele discussie losgemaakt.

- duckdns.org/management werkte niet
- management.xx.duckdns.org wel.
- Finance heb ik om genoemde reden idd maar vanaf gezien. Was ook meer PoC dan nuttig
- Management wel actief zodat ik extern bij mn proxmox zou kunnen als t moet... afhankelijk van wat er met de hardware is..omdat NGINX in HA draait die op die proxmox draait maar just in case. Heb geen spare device atm, anders NGINX toch maar eens overzetten naar een los device.

[golles]

Koepert schreef op donderdag 1 april 2021 @ 10:09:
Dank allen voor de info Hele discussie losgemaakt.

- duckdns.org/management werkte niet
- management.xx.duckdns.org wel.
- Finance heb ik om genoemde reden idd maar vanaf gezien. Was ook meer PoC dan nuttig
- Management wel actief zodat ik extern bij mn proxmox zou kunnen als t moet... afhankelijk van wat er met de hardware is..omdat NGINX in HA draait die op die proxmox draait maar just in case. Heb geen spare device atm, anders NGINX toch maar eens overzetten naar een los device.

Goed bezig, we gingen misschien ook een beetje off topic :-)

Kun je nginx niet naast HA draaien, bijvoorbeeld in proxmox? Dat zou qua afhankelijkheden ook beter zijn, als HA down is wil je je nginx niet down is. Het hoeft niet perse een andere machine te zijn.

Wat misschien ook handig is om te doen is om je nginx alleen open te zetten voor bepaalde IP adressen of alleen Nederlandse IP's toestaan en/of een auth_basic eroverheen gooien. Dit maakt het openzetten naar het hele internet weer een klein beetje veiliger

[golles]

sOid schreef op woensdag 31 maart 2021 @ 21:53:
[...]

Kun je het op die manier eigenlijk ook intern opzetten? Dus bijvoorbeeld influxdb.huis.domein.nl, dat dan alleen via je LAN bereikbaar is, terwijl huis.domein.nl wel openstaat voor de buitenwereld?

Haha nu wordt het voor mij wel iets moeilijker om hier goed op te antwoorden, ik denk dat je dan geen DNS records op je server wilt hebben voor influx.huis zodat het internet het niet kan vinden. Dan zou je thuis eigen DNS entries moeten maken voor die adressen en die naar je lokale machine ip verwijzen, volgens mij moet dat wel werken.

Je kan het ook wel in je server DNS opnemen en dan in nginx checken of het van een lokale ip (ip ranges van docker en je huis netwerk(en)) komt en dan toelaten, anders 444 terug sturen naar de client.

[Hmmbob]

icecreamfarmer schreef op donderdag 1 april 2021 @ 09:45:
Ik heb ook een half open stand als scene ingesteld staan. Dan moet hij open of dicht niet triggeren.
En ik wil een check invoeren dat ze allemaal open moeten staan voordat sommige functie sop basis van de zon getriggered worden. Dit zodat de glazenwasser zijn werk kan doen.

Check. Dan zou ik dus aan de gang gaan met de attributes "current_position: xx". Die zou ik er niet 1-op-1 in hard coden, want soms als ik zeg "ga 50% open" is de echte waarde 51 of 49% ofzo. Dat zal met een template moeten, en misschien is dan de is_state_attr functie handig:

https://www.home-assistan...ration/templating/#states

[sOid]

golles schreef op donderdag 1 april 2021 @ 10:54:
[...]


Haha nu wordt het voor mij wel iets moeilijker om hier goed op te antwoorden, ik denk dat je dan geen DNS records op je server wilt hebben voor influx.huis zodat het internet het niet kan vinden. Dan zou je thuis eigen DNS entries moeten maken voor die adressen en die naar je lokale machine ip verwijzen, volgens mij moet dat wel werken.

Je kan het ook wel in je server DNS opnemen en dan in nginx checken of het van een lokale ip (ip ranges van docker en je huis netwerk(en)) komt en dan toelaten, anders 444 terug sturen naar de client.

Thanks Ik heb Pihole draaien en volgens mij kan dat ook zorgen voor lokale DNS afhandeling. Samen met nginx moet dat denk ik wel werken. Binnenkort 's naar kijken!

[Dutchess_Nicole]

sOid schreef op donderdag 1 april 2021 @ 11:49:
[...]

Thanks Ik heb Pihole draaien en volgens mij kan dat ook zorgen voor lokale DNS afhandeling. Samen met nginx moet dat denk ik wel werken. Binnenkort 's naar kijken!

Dat kan inderdaad. Dat kun je instellen op Local DNS -> DNS Records:



Eigenlijk best simpel

[DennusB]

Hier ook mensen die hun setup via Nabu Casa aan Google Assistant hebben hangen? Ik heb hier allemaal flows die in huis verlichting triggeren aan de hand van beweging, helderheid, stand van de zon etc. Dus als ik nu roep "Okay Google, doe verlichting in de eetkamer aan", dan gaat dat goed, maar een minuut later gaat het weer uit door die flow. Hoe vangen jullie zoiets af?

[TheFes]

DennusB schreef op donderdag 1 april 2021 @ 13:05:
Hier ook mensen die hun setup via Nabu Casa aan Google Assistant hebben hangen? Ik heb hier allemaal flows die in huis verlichting triggeren aan de hand van beweging, helderheid, stand van de zon etc. Dus als ik nu roep "Okay Google, doe verlichting in de eetkamer aan", dan gaat dat goed, maar een minuut later gaat het weer uit door die flow. Hoe vangen jullie zoiets af?

Wat bedoel je met een flow? Een automation in HA?

[DennusB]

TheFes schreef op donderdag 1 april 2021 @ 13:16:
[...]


Wat bedoel je met een flow? Een automation in HA?

Sorry, Node-Red!

[Koepert]

golles schreef op donderdag 1 april 2021 @ 10:47:
[...]


Kun je nginx niet naast HA draaien, bijvoorbeeld in proxmox? Dat zou qua afhankelijkheden ook beter zijn, als HA down is wil je je nginx niet down is. Het hoeft niet perse een andere machine te zijn.

Volgende probleem.. Ik dacht begin met de 'minst spannende' management.xxx dus. alleen dat SSL is dus al ' in gebruik' omdat ik die bij HA al geactiveerd had (credentials NGINX hetzelfde gehouden). Is dat kwestie SSL verwijderen bij de ene, wachten, activeren bij de andere, of moet ik dan op HA nog iets actief verwijderen of juist migreren?

[denuz]

DennusB schreef op donderdag 1 april 2021 @ 13:05:
Hier ook mensen die hun setup via Nabu Casa aan Google Assistant hebben hangen? Ik heb hier allemaal flows die in huis verlichting triggeren aan de hand van beweging, helderheid, stand van de zon etc. Dus als ik nu roep "Okay Google, doe verlichting in de eetkamer aan", dan gaat dat goed, maar een minuut later gaat het weer uit door die flow. Hoe vangen jullie zoiets af?

Dat heeft niet zoveel te maken met Home Assistant of Google Assistant. Dit heeft alles te maken met je automations in Node-Red en past daarmee beter in dat topic. Je zult iets van een input boolean moeten maken, dat als je handmatig(in dit geval via google assistant) je verlichting schakelt het niet meer automatisch gebeurd

[Toppertje]

Sine schreef op woensdag 31 maart 2021 @ 08:47:
[...]


Is je usb-sata controller wel geschikt voor een pi4 (als je die gebruikt) de pi4 is nogal kieskeurig wat dat betreft.

Dank voor je reactie, ik gebruik een Pi3, inmiddels met een nieuwe 32Gb USB-stick overnieuw begonnen, gelukkig was ik nog niet zo lang bezig.

Nu loop ik alleen bij het installeren van HACS aan tegen de volgende foutmelding: config flow could not be loaded. Zoekactie op google levert bijzonder weinig op, iemand die dit eerder heeft meegemaakt en een oplossing heeft?

[Sine]

Hmnein, zegt mij helemaal niks.

Eigenlijk ook nooit problemen gehad met de hass images, zeker niet op de pi3

[RevellNL]

RevellNL schreef op zondag 28 maart 2021 @ 21:36:
Ik probeer mijn HomeKit integratie werkend te krijgen maar kom er niet uit. Ik heb de integratie aangezet in mijn HA Core install (Docker) en vervolgens op mijn iPhone de gegenereerde QR-code van de aangemaakte HomeKit Bridge binnen HA ook gescand.

So far, so good. Alles binnen de HomeKit app op mijn iPhone ook ingesteld in de juiste ruimtes e.d. maar, het lijkt erop dat alles slechts 10 seconden werkt waarna alles ong. 1 minuut op "Not Responding" komt te staan. Vervolgens werkt het weer ong. 10 seconden om daarna weer 1 minuut op "Not Responding" te staan.

Ik heb al rondgezocht en kwam veel tegen over IGMPv3 wat roet in het eten kan gooien, echter ook met dit overal uit te zetten binnen mijn netwerk blijven de issues zich voordoen.

Iemand hier ervaring mee? Siri vragen om de lichten uit te zetten in de hoop dat ik binnen het 10-seconden window zit is nou niet echt een fijne ervaring..

Ik heb zojuist de boosdoener gevonden! Ik had op mijn EdgeRouter X zowel de mDNS Reflector als de mDNS Repeater aan staan, ik heb de Reflector zojuist uitgezet en alles draait stabiel en blijft bereikbaar!

[aex351]

Voor degene die gebruik maken van de Neerslag Card (Buienalarm en/of Buienradar grafiek). Ik heb deze doorontwikkeld naar de Neerslag App. Dit is een alles-in-één oplossing (front-end + back-end) en daardoor redelijk uniek in de wereld van Home Assistant.

• https://github.com/aex351/home-assistant-neerslag-app

De custom sensors van de Neerslag Card zijn nu verwerkt in een Home Assistant integratie. Dit is volledig via de interface te configureren. Zo kan je nu via de interface je latitude en longitude per sensor beheren of gebruik maken van de ingebouwde locatie gegevens van Home Assistant. Deze integratie bevat ook de Neerslag Card.

Volgende stap is om wellicht ook extra sensors toe te voegen. Bijvoorbeeld om aan te geven dat het gaat regenen. En over hoeveel minuten het gaat regenen. etc. Dat kan je dan in je automation gebruiken. Bijvoorbeeld om een push notificatie te krijgen om je mobiel of om de zonnescherm naar binnen te halen.

Migratie pad van Neerslag Card naar Neerslag App (heel simpel):
Wil je gebruik maken van de Neerslag App, verwijder dan eerst de Neerslag Card. Ook is het handig om de custom sensors te verwijderen, want de Neerslag App maakt daar geen gebruik van.

[water_escape]

Begrijp ik nu dat ik het beste even alle weer gerelateerd onderdelen moet verwijderen en daarna deze in te stellen?

En klopt het dat ik hem niet in HACS zie, ondank je beschrijving dat hij via HACS te downloaden is?

This is the recommended option and also allows for easy updates.

Add this repository to HACS;
Add the Neerslag App in the Home Assistant Community Store;
Add the Neerslag App as an Integration in Home Assistant (config/integration).

aex351 schreef op vrijdag 2 april 2021 @ 00:10:
Voor degene die gebruik maken van de Neerslag Card (Buienalarm en/of Buienradar grafiek). Ik heb deze doorontwikkeld naar de Neerslag App. Dit is een alles-in-één oplossing (front-end + back-end) en daardoor redelijk uniek in de wereld van Home Assistant.

• https://github.com/aex351/home-assistant-neerslag-app

De custom sensors van de Neerslag Card zijn nu verwerkt in een Home Assistant integratie. Dit is volledig via de interface te configureren. Zo kan je nu via de interface je latitude en longitude per sensor beheren of gebruik maken van de ingebouwde locatie gegevens van Home Assistant. Deze integratie bevat ook de Neerslag Card.

Volgende stap is om wellicht ook extra sensors toe te voegen. Bijvoorbeeld om aan te geven dat het gaat regenen. En over hoeveel minuten het gaat regenen. etc. Dat kan je dan in je automation gebruiken. Bijvoorbeeld om een push notificatie te krijgen om je mobiel of om de zonnescherm naar binnen te halen.

Migratie pad van Neerslag Card naar Neerslag App (heel simpel):
Wil je gebruik maken van de Neerslag App, verwijder dan eerst de Neerslag Card. Ook is het handig om de custom sensors te verwijderen, want de Neerslag App maakt daar geen gebruik van.

[Afbeelding]

[ Voor 9% gewijzigd door water_escape op 02-04-2021 08:42 ]

[Hmmbob]

RevellNL schreef op donderdag 1 april 2021 @ 23:18:
[...]


Ik heb zojuist de boosdoener gevonden! Ik had op mijn EdgeRouter X zowel de mDNS Reflector als de mDNS Repeater aan staan, ik heb de Reflector zojuist uitgezet en alles draait stabiel en blijft bereikbaar!

Lol, dus toch mDNS

[Hmmbob]

aex351 schreef op vrijdag 2 april 2021 @ 00:10:
Voor degene die gebruik maken van de Neerslag Card (Buienalarm en/of Buienradar grafiek).

[Afbeelding]

Hier thuis zou de grootste PAF behaald worden als er niet 2 maar 1 lijntje is, die dan wel de gegevens van beiden bevat. Oftewel: zou het in te bouwen / configureren zijn dat de card het gemiddelde van de twee sensoren pakt, als deze allebei data bevatten?

Zeg maar Buienalarm geeft 2mm, Buienradar geeft 6mm, de card heeft 1 lijn met 4mm?

[TheMystery]

aex351 schreef op vrijdag 2 april 2021 @ 00:10:
Voor degene die gebruik maken van de Neerslag Card (Buienalarm en/of Buienradar grafiek). Ik heb deze doorontwikkeld naar de Neerslag App. Dit is een alles-in-één oplossing (front-end + back-end) en daardoor redelijk uniek in de wereld van Home Assistant.

• https://github.com/aex351/home-assistant-neerslag-app

De custom sensors van de Neerslag Card zijn nu verwerkt in een Home Assistant integratie. Dit is volledig via de interface te configureren. Zo kan je nu via de interface je latitude en longitude per sensor beheren of gebruik maken van de ingebouwde locatie gegevens van Home Assistant. Deze integratie bevat ook de Neerslag Card.

Volgende stap is om wellicht ook extra sensors toe te voegen. Bijvoorbeeld om aan te geven dat het gaat regenen. En over hoeveel minuten het gaat regenen. etc. Dat kan je dan in je automation gebruiken. Bijvoorbeeld om een push notificatie te krijgen om je mobiel of om de zonnescherm naar binnen te halen.

Migratie pad van Neerslag Card naar Neerslag App (heel simpel):
Wil je gebruik maken van de Neerslag App, verwijder dan eerst de Neerslag Card. Ook is het handig om de custom sensors te verwijderen, want de Neerslag App maakt daar geen gebruik van.

[Afbeelding]

Ik heb hem even geinstalleerd via hacs en als integration toegevoegd.
Hierna via integrations geconfigureerd, maar als ik hem dan aan mijn dachtbord wil toevoegen staat de kaart er niet bij en als ik handmatig de kaart toevoeg zegt ie niet beschikbaar is.

moeten we nog handmatig een dashboard resource aanmaken?

[RevellNL]

Hmmbob schreef op vrijdag 2 april 2021 @ 08:37:
[...]

Lol, dus toch mDNS

Ja, een overdaad aan mDNS instellingen blijkbaar

[barrymossel]

Zojuist zie ik in een grafiek de tijd in de middag getoond worden als 00:15 p.m. Buiten dat ik dat nog nooit gezien heb en best wel vreemd vind (in Amerika is het toch ook gewoon 12:15 p.m.?), kan ik zo 1-2-3 niet vinden waar dat op gebaseerd is en hoe dit aan te passen is.

Iemand een idee waar ik moet kijken?

[Septillion]

@barrymossel 00:15 PM is inderdaad wel erg bijzonder. Maar (irritant genoeg) pakt HA de notatie van het device / browser waarin je zit.

[barrymossel]

Septillion schreef op vrijdag 2 april 2021 @ 09:50:
@barrymossel 00:15 PM is inderdaad wel erg bijzonder. Maar (irritant genoeg) pakt HA de notatie van het device / browser waarin je zit.

Ik zie net dat het aan de mini-graph-card ligt. Op andere plekken gaat het wel goed. Is schijnbaar alleen in de grafiekjes.



Vond het in eerste instantie vreemd dat er zoveel licht was midden in de nacht...

---edit---
Op te lossen met:

YAML:

hour24: true

[ Voor 5% gewijzigd door barrymossel op 02-04-2021 09:57 ]

[golles]

aex351 schreef op vrijdag 2 april 2021 @ 00:10:
Voor degene die gebruik maken van de Neerslag Card (Buienalarm en/of Buienradar grafiek). Ik heb deze doorontwikkeld naar de Neerslag App. Dit is een alles-in-één oplossing (front-end + back-end) en daardoor redelijk uniek in de wereld van Home Assistant.

• https://github.com/aex351/home-assistant-neerslag-app

De custom sensors van de Neerslag Card zijn nu verwerkt in een Home Assistant integratie. Dit is volledig via de interface te configureren. Zo kan je nu via de interface je latitude en longitude per sensor beheren of gebruik maken van de ingebouwde locatie gegevens van Home Assistant. Deze integratie bevat ook de Neerslag Card.

Volgende stap is om wellicht ook extra sensors toe te voegen. Bijvoorbeeld om aan te geven dat het gaat regenen. En over hoeveel minuten het gaat regenen. etc. Dat kan je dan in je automation gebruiken. Bijvoorbeeld om een push notificatie te krijgen om je mobiel of om de zonnescherm naar binnen te halen.

Migratie pad van Neerslag Card naar Neerslag App (heel simpel):
Wil je gebruik maken van de Neerslag App, verwijder dan eerst de Neerslag Card. Ook is het handig om de custom sensors te verwijderen, want de Neerslag App maakt daar geen gebruik van.

[Afbeelding]

Goed bezig!

oooppppppppppppppppppppppppppppppppppppppppp