Home Assistant - Open source Python3 home automation

[martinvdm]

ThinkPadd schreef op zaterdag 24 februari 2018 @ 20:33:
Ik stuurde tot vandaag mijn Itho aan via DIY: Itho ventilatie aansturen via 868Mhz transmitter
Helaas had ik af-en-toe toch dat er een signaaltje miste, waardoor de afzuiging niet aan ging als ik stond te douchen. Heb er nu een Sonoff Dual (2x relay) tussen gezet om de snelheids draden van de Itho rechtstreeks te bedienen. Tasmota firmware op de Sonoff, aan MQTT knuppen en gaan met die banaan.

Onderstaand een waarheidstabel voor de standen van de relays behorend bij de snelheden van de Itho

	Relay 1	Relay 2
laag	Uit	Uit
middel	Aan	Uit
hoog	Uit	Aan

De stand van relay 1 bij stand 'hoog' is niet zo spannend, als die aan blijft staan terwijl 2 ook spanning heeft dan gaat de unit alsnog op hoog. De hoogste waarde overruled dus.

Ik heb een 'beslis' sensor waarin ik uit beide inputs (CO₂-sensor of temperatuur doucheleiding)de gewenste waarde stop (low/medium/high).

Sensor:

YAML:

- platform: template
  sensors:
    wants_mv:
      value_template: "{%- if is_state('input_select.wants_mv_co2_wnk', 'Hoog') or is_state('input_select.wants_mv_hum_bdk', 'Hoog') -%}high{%- elif is_state('input_select.wants_mv_co2_wnk', 'Middel') or is_state('input_select.wants_mv_hum_bdk', 'Middel') -%}medium{%- else -%}low{%- endif -%}"
      friendly_name: 'Itho snelheid'
      entity_id:
        - input_select.wants_mv_co2_wnk
        - input_select.wants_mv_hum_bdk

Onderstaande automation houdt die sensor in de gaten en past de snelheid van de Itho ventilatiebox aan indien nodig:

YAML:

alias: 800 - Itho ventilation control
trigger:
  platform: state
  entity_id: sensor.wants_mv
action:
  - service: script.turn_on
    data_template:
      entity_id: >
        {% if is_state("sensor.wants_mv", "high") %}
           script.itho_high
        {%- elif is_state("sensor.wants_mv", "medium") -%}
           script.itho_medium
        {%- elif is_state("sensor.wants_mv", "low") -%}
           script.itho_low
        {% else %}
           none
        {% endif %}

En de scripts.yaml:

YAML:

  itho_low:
    alias: Itho low speed
    sequence:
      - alias: Itho low speed
        service: switch.turn_off
        data:
          entity_id: 
          - switch.itho_medium
          - switch.itho_high
                    
  itho_medium:
    alias: Itho medium speed
    sequence:
      - alias: Itho turn off high
        service: switch.turn_off
        data:
          entity_id: switch.itho_high     
      - alias: Itho turn on medium
        service: switch.turn_on
        data:
          entity_id: switch.itho_medium

  itho_high:
    alias: Itho high speed
    sequence:
      - alias: Itho turn off medium
        service: switch.turn_off
        data:
          entity_id: switch.itho_medium     
      - alias: Itho turn on high
        service: switch.turn_on
        data:
          entity_id: switch.itho_high

Op deze manier altijd de gewenste ventilatie en nooit teveel

Ik had voor de Itho DIY een kaku acd1000 rechtstreeks op het relais board wat alleen de hoog stand aan onguur schakelde. Dat werkte prima maar vind de draadloze oplossing praktischere te meer omdat deze ook de bestaande Remote uit leest en daarmee de status in HA altijd overeen komt. Nog geen misser gehad. Wellicht een andere plek in huis voor de 868 c1101 module uitzoeken?

[martinvdm]

UltraSub schreef op zaterdag 24 februari 2018 @ 17:38:
[...]

Die namen worden in de ozw config weg geschreven en die wordt pas gesaved bij shut van openzwave. Hass leest bij starten van ozw die weer in incl waardes. Restart en het zou moeten werken.

Al gedaan idd, vreemd genoeg blijven ze zo heten, Maargoed ik kan er wel mee leven. Het werkt iig.

[ThinkPad]

martinvdm schreef op zaterdag 24 februari 2018 @ 21:11:
[...]

Ik had voor de Itho DIY een kaku acd1000 rechtstreeks op het relais board wat alleen de hoog stand aan onguur schakelde. Dat werkte prima maar vind de draadloze oplossing praktischere te meer omdat deze ook de bestaande Remote uit leest en daarmee de status in HA altijd overeen komt. Nog geen misser gehad. Wellicht een andere plek in huis voor de 868 c1101 module uitzoeken?

Remote heb ik niet, alleen een driestandenschakelaar bij de badkamer (die door HASS overbodig is).
Had de CC1101 eerst in de meterkast (en Itho op zolder). Sinds kort de CC1101 gewoon bovenop de Itho gelegd en ging al beter had ik het idee. Maar toch nog wel eens een schakeling gemist.

[breinonline]

Ik zit naar TOR te kijken als alternatief voor de https verbinding die ik nu heb. Nadeel: ik kan de iOS app niet meer gebruiken en verlies daardoor present detection via de app. Die zou dan van owntracks o.i.d. moeten komen. Iemand ervaring met TOR en presence detection op iOS?

[GekkePrutser]

breinonline schreef op zondag 25 februari 2018 @ 09:00:
Ik zit naar TOR te kijken als alternatief voor de https verbinding die ik nu heb. Nadeel: ik kan de iOS app niet meer gebruiken en verlies daardoor present detection via de app. Die zou dan van owntracks o.i.d. moeten komen. Iemand ervaring met TOR en presence detection op iOS?

Waarom zou je daar tor voor gebruiken? Dat lijkt me een vreemde keuze. Het zit mij persoonlijk te veel in de 'darknet' hoek.

Ik zou eerder een eigen VPN opzetten, op iOS kan je die ook nog eens "Always-On" maken, waardoor je altijd verbonden bent met je thuisnetwerk. Als bijkomend voordeel heb je ook nog eens veel betere privacy op open WiFi netwerken.

Algo is een zeer fijne gratis VPN server die perfect werkt met de always-on functionaliteit van iOS.

Alleen die presence detection ben je dan ook wel kwijt omdat je app altijd in range is Misschien kan dat ook wel met GPS detectie?

[ Voor 10% gewijzigd door GekkePrutser op 25-02-2018 10:43 ]

[PuckStar]

GekkePrutser schreef op zondag 25 februari 2018 @ 10:41:
[...]
Alleen die presence detection ben je dan ook wel kwijt omdat je app altijd in range is Misschien kan dat ook wel met GPS detectie?

Heb je thuis dan geen andere ip adres dan als je via de VPN buitenshuis verbinding maakt? Want dan kun je op basis van ip adres dus nog wel onderscheidt maken in of je thuis of niet thuis bent.

[GekkePrutser]

PuckStar schreef op zondag 25 februari 2018 @ 13:59:
[...]

Heb je thuis dan geen andere ip adres dan als je via de VPN buitenshuis verbinding maakt? Want dan kun je op basis van ip adres dus nog wel onderscheidt maken in of je thuis of niet thuis bent.

Dat is waar.. Ik heb mijn VPN zelf extern gehost dus ik heb sowieso een andere range dan.. Ik heb alleen nog geen HomeAssistant, zit nu een beetje te kijken naar de verschillende opties voor domotica. Vandaar dat ik hier terecht kwam. Want Domoticz vind ik zo 2005, het ziet er niet uit Verder naar Homey gekeken maar dat kan je niet gebruiken zonder de cloud en dat wil ik niet (privacy).

Ik denk trouwens aan de combinatie Home Assistant met Node-RED. Dat lijkt me ideaal.

[ Voor 14% gewijzigd door GekkePrutser op 25-02-2018 14:16 ]

[PuckStar]

GekkePrutser schreef op zondag 25 februari 2018 @ 14:02:
[...]


Dat is waar.. Ik heb mijn VPN zelf extern gehost dus ik heb sowieso een andere range dan.. Ik heb alleen nog geen HomeAssistant, zit nu een beetje te kijken naar de verschillende opties voor domotica. Vandaar dat ik hier terecht kwam. Want Domoticz vind ik zo 2005, het ziet er niet uit Verder naar Homey gekeken maar dat kan je niet gebruiken zonder de cloud en dat wil ik niet (privacy).

Ik denk trouwens aan de combinatie Home Assistant met Node-RED. Dat lijkt me ideaal.

Ik ken Node-RED niet maar Home Assistant is echt heel erg gaaf! Dus van harte welkom

[GekkePrutser]

PuckStar schreef op zondag 25 februari 2018 @ 14:27:
[...]

Ik ken Node-RED niet maar Home Assistant is echt heel erg gaaf! Dus van harte welkom

Node-RED is een javascript framework waarmee je grafisch kan 'programmeren'.



Niet dat ik problemen heb met tekstfiles (ik heb zelfs iOS apps ontwikkeld) maar dit lijkt me gewoon handiger dan met YAML files. Debuggen werkt ook heel mooi. Het heeft bovendien veel integraties die HomeAssistant niet allemaal heeft.

HASS wil ik dan gebruiken voor het overzicht enzo.. Ik heb net mijn Xbee binnen dus ik wou daar mee aan de slag, ik heb wat Ikea TRADFRI lampen en die controller van Ikea is echt rotzooi Raakt elke keer de communicatie kwijt, en als de stroom er af is geweest zijn alle instellingen weg. Dus vandaar dat ik dit project weer eens van stal had gehaald om nu echt eens naar te kijken.

[Verwijderd]

Ik doe hetzelfde, de simpele shit in homeassistant, de complexe zaken in node-red. Het feit dat je daar gewoon javascript kan typen in functies als het echt complexer wordt is super. Debuggen van je code is een tikje shit, dan moet je of met logstatements gaan werken of de functie splitten en naar debug nodes laten schrijven. Deployen van node-red is doodsimpel met docker.

Ik ben fan van homeassistant met z'n grote community en stevige ontwikkeling, maar die YAML-syntax voor de rules is redelijk shit eigenlijk. Wat dat betreft was pimatic echt stukken handiger, daar kon je de rules gewoon in een DSL-achtig taaltje met autocompletion in een soort C-syntax opbouwen. Als je wilde zat er een grafische editor in, niet super, maar doable.

Dit is wat mij betreft het enige grote nadeel van Homeassistant: complexe rules zijn onoverzichtigelijk en lastig op te bouwen, mede door de foutgevoeligheid van YAML en het gebrek aan autocompletion. De huidige editor vernaggelde eerder m'n rules dan wat anders

[ Voor 25% gewijzigd door Verwijderd op 25-02-2018 15:33 ]

[GekkePrutser]

Verwijderd schreef op zondag 25 februari 2018 @ 15:29:
Ik doe hetzelfde, de simpele shit in homeassistant, de complexe zaken in node-red. Het feit dat je daar gewoon javascript kan typen in functies als het echt complexer wordt is super. Debuggen van je code is een tikje shit, dan moet je of met logstatements gaan werken of de functie splitten en naar debug nodes laten schrijven. Deployen van node-red is doodsimpel met docker.

Ja dat ben ik dus ook van plan. Ik dacht dat debuggen juist handig was, maar ik heb het nog niet echt in de praktijk gebruikt. Alleen een demootje gehad van een collega

Gebruik je dan ook de hass.io image voor de pi? Of raspbian en dan handmatig homeassistant installeren? Ik weet niet of het met die hass.io ook zo makkelijk is om node-red te installeren, vandaar.

[dof]

ThinkPadd schreef op zaterdag 24 februari 2018 @ 20:33:
Ik stuurde tot vandaag mijn Itho aan via DIY: Itho ventilatie aansturen via 868Mhz transmitter
Helaas had ik af-en-toe toch dat er een signaaltje miste, waardoor de afzuiging niet aan ging als ik stond te douchen. Heb er nu een Sonoff Dual (2x relay) tussen gezet om de snelheids draden van de Itho rechtstreeks te bedienen. Tasmota firmware op de Sonoff, aan MQTT knuppen en gaan met die banaan.

Onderstaand een waarheidstabel voor de standen van de relays behorend bij de snelheden van de Itho

	Relay 1	Relay 2
laag	Uit	Uit
middel	Aan	Uit
hoog	Uit	Aan

De stand van relay 1 bij stand 'hoog' is niet zo spannend, als die aan blijft staan terwijl 2 ook spanning heeft dan gaat de unit alsnog op hoog. De hoogste waarde overruled dus.

Ik heb een 'beslis' sensor waarin ik uit beide inputs (CO₂-sensor of temperatuur doucheleiding)de gewenste waarde stop (low/medium/high).

Sensor:

YAML:

- platform: template
  sensors:
    wants_mv:
      value_template: "{%- if is_state('input_select.wants_mv_co2_wnk', 'Hoog') or is_state('input_select.wants_mv_hum_bdk', 'Hoog') -%}high{%- elif is_state('input_select.wants_mv_co2_wnk', 'Middel') or is_state('input_select.wants_mv_hum_bdk', 'Middel') -%}medium{%- else -%}low{%- endif -%}"
      friendly_name: 'Itho snelheid'
      entity_id:
        - input_select.wants_mv_co2_wnk
        - input_select.wants_mv_hum_bdk

Onderstaande automation houdt die sensor in de gaten en past de snelheid van de Itho ventilatiebox aan indien nodig:

YAML:

alias: 800 - Itho ventilation control
trigger:
  platform: state
  entity_id: sensor.wants_mv
action:
  - service: script.turn_on
    data_template:
      entity_id: >
        {% if is_state("sensor.wants_mv", "high") %}
           script.itho_high
        {%- elif is_state("sensor.wants_mv", "medium") -%}
           script.itho_medium
        {%- elif is_state("sensor.wants_mv", "low") -%}
           script.itho_low
        {% else %}
           none
        {% endif %}

En de scripts.yaml:

YAML:

  itho_low:
    alias: Itho low speed
    sequence:
      - alias: Itho low speed
        service: switch.turn_off
        data:
          entity_id: 
          - switch.itho_medium
          - switch.itho_high
                    
  itho_medium:
    alias: Itho medium speed
    sequence:
      - alias: Itho turn off high
        service: switch.turn_off
        data:
          entity_id: switch.itho_high     
      - alias: Itho turn on medium
        service: switch.turn_on
        data:
          entity_id: switch.itho_medium

  itho_high:
    alias: Itho high speed
    sequence:
      - alias: Itho turn off medium
        service: switch.turn_off
        data:
          entity_id: switch.itho_medium     
      - alias: Itho turn on high
        service: switch.turn_on
        data:
          entity_id: switch.itho_high

Op deze manier altijd de gewenste ventilatie en nooit teveel

Mooie oplossing Thanks, spreekt me wel aan want ik heb ook een Itho. En heb niet veel zin om weer een 868Mhz transmitter in te zetten (wil ik juist -met alle Homewizard spullen- vanaf, en douche is op derde verdieping).

Wat gebruik je voor 'beslis' sensor ?

[ThinkPad]

@dof Ik heb dus twee redenen waarom de Itho sneller/langzamer zou moeten:

1. CO₂ luchtkwaliteit in de woonkamer. Dit meet ik met een MH-Z19 aan een ESP8266
2. Douche wordt gebruikt. Ik heb een DS18B20 temperatuursensor op de warmwaterleiding geklemd. De sensor lees ik uit met een ESP8266

Vooral de CO₂ is handig. Ook wel schrikbarend hoe snel dat omhoog vliegt als je >2 mensen in huis hebt. Paar kaarsen aan en de luchtkwaliteit wordt ook vrij snel slecht trouwens.

Met de code van de beslis-sensor zorg ik dat naar beide inputs wordt gekeken en de hoogste waarde de baas is. Op die manier draait de Itho op de juiste snelheid wanneer nodig en laag als er niemand thuis is en douche niet gebruikt wordt.

Ik wil alleen de regel van de douche nog wat slimmer maken. De regel heb ik destijds zo gebouwd dat als de leiding >=40°C is, de fan 20 min. op 'hoog' moet gaan. Als één iemand gaat douchen is dat prima. Gaan we na elkaar, dan gaat bij de tweede persoon de fan al weer uit. Ik wil gaan tellen hoe lang de leiding boven de triggertemperatuur is. Zolang dat zo is moet de fan op 'hoog' blijven en afhankelijk van hoe lang de douche aan stond komt er uit die telling ook een nadraaitijd rollen.

Voor de complete configuratie, zie hier.

[ Voor 36% gewijzigd door ThinkPad op 25-02-2018 17:51 ]

[martinvdm]

ThinkPadd schreef op zondag 25 februari 2018 @ 17:46:
@dof Ik heb dus twee redenen waarom de Itho sneller/langzamer zou moeten:

1. CO₂ luchtkwaliteit in de woonkamer. Dit meet ik met een MH-Z19 aan een ESP8266
2. Douche wordt gebruikt. Ik heb een DS18B20 temperatuursensor op de warmwaterleiding geklemd. De sensor lees ik uit met een ESP8266

Vooral de CO₂ is handig. Ook wel schrikbarend hoe snel dat omhoog vliegt als je >2 mensen in huis hebt. Paar kaarsen aan en de luchtkwaliteit wordt ook vrij snel slecht trouwens.

Met de code van de beslis-sensor zorg ik dat naar beide inputs wordt gekeken en de hoogste waarde de baas is. Op die manier draait de Itho op de juiste snelheid wanneer nodig en laag als er niemand thuis is en douche niet gebruikt wordt.

Ik wil alleen de regel van de douche nog wat slimmer maken. De regel heb ik destijds zo gebouwd dat als de leiding >=40°C is, de fan 20 min. op 'hoog' moet gaan. Als één iemand gaat douchen is dat prima. Gaan we na elkaar, dan gaat bij de tweede persoon de fan al weer uit. Ik wil gaan tellen hoe lang de leiding boven de triggertemperatuur is. Zolang dat zo is moet de fan op 'hoog' blijven en afhankelijk van hoe lang de douche aan stond komt er uit die telling ook een nadraaitijd rollen.

Voor de complete configuratie, zie hier.

Wat voor behuizingen gebruik je voor die esp bordjes?

[ThinkPad]

martinvdm schreef op zondag 25 februari 2018 @ 18:17:
[...]

Wat voor behuizingen gebruik je voor die esp bordjes?

offtopic:
ThinkPadd in "CO2-meters voor in huis"
Die van de ketel bungelt ergens los op de grond

[breinonline]

GekkePrutser schreef op zondag 25 februari 2018 @ 10:41:
[...]

Waarom zou je daar tor voor gebruiken? Dat lijkt me een vreemde keuze. Het zit mij persoonlijk te veel in de 'darknet' hoek.

Daar is het vooral bekend van, maar echt niet de enige toepassing.

Ik zou eerder een eigen VPN opzetten, op iOS kan je die ook nog eens "Always-On" maken, waardoor je altijd verbonden bent met je thuisnetwerk. Als bijkomend voordeel heb je ook nog eens veel betere privacy op open WiFi netwerken.

Algo is een zeer fijne gratis VPN server die perfect werkt met de always-on functionaliteit van iOS.

VPN heb ik geen kaas van gegeten en het voordeel van tor is dat er een standaard add-in voor hass.io van is. Ik ben dan het 'lastige' https verhaal kwijt, kan alle poorten dichtzetten. Nadeel is dat de home assistant app op iOS dan niet meer werkt want je moet naar HASS via een tor browser. Die gebruik ik nu als presence detectie, dat gaat overigens via GPS en wifi.

[Verwijderd]

GekkePrutser schreef op zondag 25 februari 2018 @ 16:11:
Gebruik je dan ook de hass.io image voor de pi? Of raspbian en dan handmatig homeassistant installeren? Ik weet niet of het met die hass.io ook zo makkelijk is om node-red te installeren, vandaar.

Die hassio kan me gestolen worden, het hele concept bevalt me niet, dus ik heb alles gewoon handmatig geinstalleerd. Maarja wat heet installeren, docker run en gaan met die banaan.

[UltraSub]

GekkePrutser schreef op zondag 25 februari 2018 @ 16:11:
[...]

Ik weet niet of het met die hass.io ook zo makkelijk is om node-red te installeren, vandaar.

https://home-assistant.io/addons/
Hass.io werkt met addons. Node-red staat er niet bij zie ik. Ik denk dat je dus weg moet blijven bij hass.io

Verwijderd schreef op zondag 25 februari 2018 @ 21:44:
[...]


Die hassio kan me gestolen worden, het hele concept bevalt me niet, dus ik heb alles gewoon handmatig geinstalleerd. Maarja wat heet installeren, docker run en gaan met die banaan.

Mij bevalt het ook niet. Als je dan containers gaat doen, trek dan zoveel mogelijk uit elkaar. Een add-on zou gewoon een nieuwe container moeten zijn. That said, ik snap wel waarom hass.io er is, namelijk het gemakkelijk maken van een OOTB install voor mensen die iets minder tech-savy zijn. En dat heeft iets als een home-assistant wel nodig om te groeien. Het is nu nog erg developers for developers. Vind ik perfect, maar niet iedereen gaat dit snappen.
Maar goed, gelukkig ben je vrij om het te installeren hoe je wil. Mooi toch.

[kepler]

UltraSub schreef op zondag 25 februari 2018 @ 22:25:
[...]

https://home-assistant.io/addons/
Hass.io werkt met addons. Node-red staat er niet bij zie ik. Ik denk dat je dus weg moet blijven bij hass.io


[...]

Mij bevalt het ook niet. Als je dan containers gaat doen, trek dan zoveel mogelijk uit elkaar. Een add-on zou gewoon een nieuwe container moeten zijn. That said, ik snap wel waarom hass.io er is, namelijk het gemakkelijk maken van een OOTB install voor mensen die iets minder tech-savy zijn. En dat heeft iets als een home-assistant wel nodig om te groeien. Het is nu nog erg developers for developers. Vind ik perfect, maar niet iedereen gaat dit snappen.
Maar goed, gelukkig ben je vrij om het te installeren hoe je wil. Mooi toch.

Er is een, onofficiële, addon voor: https://community.home-as...-ha-bridge-and-gogs/23247

En ik ben blij met Hassio, weinig verstand van Linux maar wel interesse in home automation

[NovapaX]

UltraSub schreef op zondag 25 februari 2018 @ 22:25:
[...]

https://home-assistant.io/addons/
Hass.io werkt met addons. Node-red staat er niet bij zie ik. Ik denk dat je dus weg moet blijven bij hass.io


[...]

Mij bevalt het ook niet. Als je dan containers gaat doen, trek dan zoveel mogelijk uit elkaar. Een add-on zou gewoon een nieuwe container moeten zijn. That said, ik snap wel waarom hass.io er is, namelijk het gemakkelijk maken van een OOTB install voor mensen die iets minder tech-savy zijn. En dat heeft iets als een home-assistant wel nodig om te groeien. Het is nu nog erg developers for developers. Vind ik perfect, maar niet iedereen gaat dit snappen.
Maar goed, gelukkig ben je vrij om het te installeren hoe je wil. Mooi toch.

Een add-on is dan ook gewoon een aparte docker container.
Maar inderdaad, als je zelf weet hoe je docker installeert, of überhaupt weet wat docker is. En je zelf al iets van een always-on server / rpi hebt en beheert dan ben je inderdaad niet primair de doelgroep.
Hoewel ik dat wel allemaal weet en heb, maar ook gewoon hass.io op mijn RPi heb draaien omdat het zo verrekte makkelijk is. (Maar dan wel met ssh toegang en een eigen home-assistant-polymer repo in /share zodat ik ook nog wat kan bijdragen aan de ontwikkeling ervan. )
Ik geloof namelijk heel sterk in het concept en de gedachte achter hass.io. Het kan op die manier gewoon verschrikkelijk toegankelijk gemaakt worden. (maar er ontbreekt nog flink wat aan de UI/UX kant, waar ik dan weer zo mijn ideeen over heb.)

[ Voor 8% gewijzigd door NovapaX op 25-02-2018 22:51 ]

[UltraSub]

NovapaX schreef op zondag 25 februari 2018 @ 22:48:
[...]

Een add-on is dan ook gewoon een aparte docker container.

Toch ja? Dan is het best mooi. Had verder geen zin om uit te zoeken of het extra containers waren, maar blijkbaar had ik dat toch even moeten doen dus.

Maar inderdaad, als je zelf weet hoe je docker installeert, of überhaupt weet wat docker is. En je zelf al iets van een always-on server / rpi hebt en beheert dan ben je inderdaad niet primair de doelgroep.

Inderdaad.

Hoewel ik dat wel allemaal weet en heb, maar ook gewoon hass.io op mijn RPi heb draaien omdat het zo verrekte makkelijk is. (Maar dan wel met ssh toegang en een eigen home-assistant-polymer repo in /share zodat ik ook nog wat kan bijdragen aan de ontwikkeling ervan. )

Als je begrijpt waar je mee bezig bent dan snap ik dat. Ken er meer die dit zo doen terwijl ze makkelijk het hele concept zelf zouden kunnen draaien.

Ik geloof namelijk heel sterk in het concept en de gedachte achter hass.io. Het kan op die manier gewoon verschrikkelijk toegankelijk gemaakt worden. (maar er ontbreekt nog flink wat aan de UI/UX kant, waar ik dan weer zo mijn ideeen over heb.)

Dat is precies de opzet, en daar ben ik het mee eens. Ik ga nerveus worden als ze dat soort dingen de only way gaan maken. Maar daar kan ik me niets bij voorstellen, dat het zover zou komen. Is het totaal de community en developers niet naar.

[Verwijderd]

UltraSub schreef op zondag 25 februari 2018 @ 22:25:
Mij bevalt het ook niet. Als je dan containers gaat doen, trek dan zoveel mogelijk uit elkaar. Een add-on zou gewoon een nieuwe container moeten zijn. That said, ik snap wel waarom hass.io er is, namelijk het gemakkelijk maken van een OOTB install voor mensen die iets minder tech-savy zijn. En dat heeft iets als een home-assistant wel nodig om te groeien. Het is nu nog erg developers for developers. Vind ik perfect, maar niet iedereen gaat dit snappen.
Maar goed, gelukkig ben je vrij om het te installeren hoe je wil. Mooi toch.

Wat me er nog minder aan bevalt is dat het in feite de principes van Docker breekt. Het hele management van de docker omgeving had vanuit een container moeten gebeuren, de opzet vereist defacto dat ik m'n huidige opzet compleet wis, hass.io moet installeren en dan m'n eigen containers er maar bij in moet prutsen. Vervolgens zit ik aan hass.io op de host vast. Het is niet erg portable en dat is nou zo'n beetje de kern van Docker.

Ze hadden van de host weg moeten blijven, hass.io had een container moeten zijn die tegen de swarm/kubernetes/whatever API van de host aanpraat. Niet een compleet OS om wat docker containers te managen. Dat ze dáárna een standaard Ubuntu/whatever image bakken die zo op de SD-kaart van een raspberry te plaatsen waarbij dat marginale stukje config op de host al plaats heeft gevonden: ala.

Daarnaast is de naamgeving die sterk lijkt op HA en het gebrek aan scheiding in de documentatie voldoende om behoorlijk wat verwarring te zaaien.

De grotere winst voor gebruikersvriendelijkheid zit denk ik ergens anders: begin met het toevoegen van devices en rules in de GUI en dan op een beetje fatsoenlijke manier. Die YAML-syntax is voor mij als tech-savy gebruiker al onhandig: foutgevoelig, geen autocompletion en je weet niet welke properties/methods op een device worden ge-exposed en het maken van complexe rules met geneste voorwaarden is nauwelijks te doen, erg onoverzichtelijk

[ Voor 10% gewijzigd door Verwijderd op 26-02-2018 08:04 ]

[trekker22]

twijfel tussen hass.io of zelf opnieuw beginnen met Rasbian en dan handmatig installeren. Zit openzwave er tegenwoordig geheel in of moet je ook los doen als je geen hass.io gebruikt?

En HomeBridge als addon via hass.io klinkt ook erg leuk, dat handmatig installeren op hassbian is me nooit fatsoenlijk gelukt...

[ Voor 26% gewijzigd door trekker22 op 26-02-2018 08:37 ]

[lolgast]

Nieuwe update van HA is beschikbaar, 0.64. Eerste stap voor Homekit integratie is gemaakt zo te zien, maar de supported devices is nog erg karig. Vooralsnog blijft het dus noodzakelijk om Homebridge te blijven draaien ipv dit via Homekit te doen.

[NovapaX]

Verwijderd schreef op maandag 26 februari 2018 @ 07:58:
[...]


Wat me er nog minder aan bevalt is dat het in feite de principes van Docker breekt. Het hele management van de docker omgeving had vanuit een container moeten gebeuren, de opzet vereist defacto dat ik m'n huidige opzet compleet wis, hass.io moet installeren en dan m'n eigen containers er maar bij in moet prutsen. Vervolgens zit ik aan hass.io op de host vast. Het is niet erg portable en dat is nou zo'n beetje de kern van Docker.

Hoezo? Voor zover ik uit de build-scripts kan opmaken is de Hassio supervisor is gewoon een aparte docker container. Het enige wat niet in docker draait is de host-control (voor shutdown/reboot).

Ze hadden van de host weg moeten blijven, hass.io had een container moeten zijn die tegen de swarm/kubernetes/whatever API van de host aanpraat. Niet een compleet OS om wat docker containers te managen. Dat ze dáárna een standaard Ubuntu/whatever image bakken die zo op de SD-kaart van een raspberry te plaatsen waarbij dat marginale stukje config op de host al plaats heeft gevonden: ala.

Dat is dus precies wat er is gedaan. Een image bakker waarop de twee docker containers (hass en de hassio supervisor) automatisch starten, en het hostcontrol script is geïnstalleerd.

Dit is het script om hassio op een generieke host te installeren. https://github.com/home-a...er/install/hassio_install

Volgens mij is het niet meer dan de docker container, wat startup-scripts en de host-control service.

Daarnaast is de naamgeving die sterk lijkt op HA en het gebrek aan scheiding in de documentatie voldoende om behoorlijk wat verwarring te zaaien.

De grotere winst voor gebruikersvriendelijkheid zit denk ik ergens anders: begin met het toevoegen van devices en rules in de GUI en dan op een beetje fatsoenlijke manier. Die YAML-syntax is voor mij als tech-savy gebruiker al onhandig: foutgevoelig, geen autocompletion en je weet niet welke properties/methods op een device worden ge-exposed en het maken van complexe rules met geneste voorwaarden is nauwelijks te doen, erg onoverzichtelijk

Met dat laatste ben ik het inderdaad helemaal mee eens, maar het kost nou allemaal vreselijk veel tijd... en het mag nix kosten he! Ook al kun je niet coden, dan nog zou je bij kunnen dragen door bijvoorbeeld de documentatie de verduidelijken of iets dergelijks....

[ Voor 10% gewijzigd door NovapaX op 26-02-2018 09:58 ]

[ANdrode]

NovapaX schreef op zondag 25 februari 2018 @ 22:48:
[...]
Ik geloof namelijk heel sterk in het concept en de gedachte achter hass.io. Het kan op die manier gewoon verschrikkelijk toegankelijk gemaakt worden. (maar er ontbreekt nog flink wat aan de UI/UX kant, waar ik dan weer zo mijn ideeen over heb.)

offtopic:
Ik denk dat die hulp (als je zonder continua aan de hand gehouden te worden kan werken en dat kan je zo te lezen wel) zeker erg gewaardeerd wordt. Voor zover ik het zie is er wel veel support aan de backend kant wat betreft developers die meehelpen maar valt dit aan de frontend kant tegen

[MrAngry]

Verwijderd schreef op maandag 26 februari 2018 @ 07:58:
en je weet niet welke properties/methods op een device worden ge-exposed

Hier liep ik als beginnende hobbyist ook al tegenaan, heb ik het goed begrepen dat de beste manier om daar achter te komen is om op github in de documentatie of code van het betreffende device te gaan graven? Of is er nog een simpelere manier om het uit te vragen?

[Psycho_Mantis]

Lekker dan, upgrade naar 0.64 en nu is ineens mijn config invalid op het mysensors stukje
Werkte eerst prima voor de upgrade (0.63.0) en zijn zo ver ik weet helemaal geen breaking changes op?

code:

Testing configuration at /home/homeassistant
/.homeassistant 
ERROR:homeassistant.config:Invalid config for [mysensors]: length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_in_prefix']. Got None length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_out_prefix']. Got None. (See /home/homeassistant/.homeassistant/configuration.yaml, line 139). Please check the docs at https://home-assistant.io/components/mysensors/ 
ERROR:homeassistant.setup:Setup failed for mysensors: Invalid config. 
Failed config 
mysensors: 
gateways: [source /home/homeassistant/.homeassistant/configuration.yaml:140] 
    - baud_rate: 115200 
      device: /dev/ttyUSB1 
  optimistic: False 
  persistence: True 
  retain: True 
  version: 2.0 

General Errors: 
- Setup failed for mysensors: Invalid config. 
Successful config (partial) mysensors:

edit:

Ben niet de enige dus:
https://github.com/home-a...me-assistant/issues/12683

Een paar optional values zijn ineens required.

[ Voor 6% gewijzigd door Psycho_Mantis op 26-02-2018 11:28 ]

[lolgast]

Lijkt erop alsof hij verplicht dat topic_in_prefix en topic_out_prefix geconfigureerd zijn? Ik gebruik dat onderdeel niet, dus geen idee

[DvD77]

ThinkPadd schreef op zondag 25 februari 2018 @ 17:46:
@dof Ik heb dus twee redenen waarom de Itho sneller/langzamer zou moeten:

1. CO₂ luchtkwaliteit in de woonkamer. Dit meet ik met een MH-Z19 aan een ESP8266
2. Douche wordt gebruikt. Ik heb een DS18B20 temperatuursensor op de warmwaterleiding geklemd. De sensor lees ik uit met een ESP8266

Vooral de CO₂ is handig. Ook wel schrikbarend hoe snel dat omhoog vliegt als je >2 mensen in huis hebt. Paar kaarsen aan en de luchtkwaliteit wordt ook vrij snel slecht trouwens.

Met de code van de beslis-sensor zorg ik dat naar beide inputs wordt gekeken en de hoogste waarde de baas is. Op die manier draait de Itho op de juiste snelheid wanneer nodig en laag als er niemand thuis is en douche niet gebruikt wordt.

Ik wil alleen de regel van de douche nog wat slimmer maken. De regel heb ik destijds zo gebouwd dat als de leiding >=40°C is, de fan 20 min. op 'hoog' moet gaan. Als één iemand gaat douchen is dat prima. Gaan we na elkaar, dan gaat bij de tweede persoon de fan al weer uit. Ik wil gaan tellen hoe lang de leiding boven de triggertemperatuur is. Zolang dat zo is moet de fan op 'hoog' blijven en afhankelijk van hoe lang de douche aan stond komt er uit die telling ook een nadraaitijd rollen.

Voor de complete configuratie, zie hier.

Waarom meet je de douche niet met een temp/vochtigheid meter ? Werkt hier prima. Zodra de vochtigheid toeneemt gaat de ventilatie op max, en als deze weer onder bepaalde waarde komt schakelt hij over naar low.

[ThinkPad]

DvD77 schreef op maandag 26 februari 2018 @ 12:01:
[...]


Waarom meet je de douche niet met een temp/vochtigheid meter ? Werkt hier prima. Zodra de vochtigheid toeneemt gaat de ventilatie op max, en als deze weer onder bepaalde waarde komt schakelt hij over naar low.

Dan moet ik een sensor in de badkamer plaatsen. Die sensor moet ook stroom hebben (of ik moet regelmatig de batterijen vervangen). En heeft even tijd nodig voordat de vochtigheid genoeg is gestegen. Het duurt nu misschien een minuutje en dan springt de fan al aan.

En met vaste waardes heb je het risico dat de fan heel lang blijft draaien als de buitenlucht ook aardig vochtig is. Je zuigt lucht af, maar die moet ook aangevuld worden. Als dat via een rooster van buiten komt dan trek je dus ook weer vochtige lucht naar binnen.

Ik had nu al temperatuursensoren op de aanvoer- en retourleiding van de ketel ivm CV-tuning dus een derde sensor op de tapwaterleiding was een kleine moeite.

[ Voor 12% gewijzigd door ThinkPad op 26-02-2018 12:15 ]

[kepler]

ThinkPadd schreef op maandag 26 februari 2018 @ 12:09:
[...]

Dan moet ik een sensor in de badkamer plaatsen. Die sensor moet ook stroom hebben (of ik moet regelmatig de batterijen vervangen). En heeft even tijd nodig voordat de vochtigheid genoeg is gestegen. Het duurt nu misschien een minuutje en dan springt de fan al aan.

En met vaste waardes heb je het risico dat de fan heel lang blijft draaien als de buitenlucht ook aardig vochtig is. Je zuigt lucht af, maar die moet ook aangevuld worden. Als dat via een rooster van buiten komt dan trek je dus ook weer vochtige lucht naar binnen.

Ik had nu al temperatuursensoren op de aanvoer- en retourleiding van de ketel ivm CV-tuning dus een derde sensor op de tapwaterleiding was een kleine moeite.

Ik ga het binnenkort instellen, maar geen mogelijkheid om warmwaterleiding te 'meten'. Ik ben van plan het idd met vochtigheid meter te doen, en de vochtigheid buiten en in de woonkamer ook te gebruiken als parameters.

[NovapaX]

Psycho_Mantis schreef op maandag 26 februari 2018 @ 11:26:
Lekker dan, upgrade naar 0.64 en nu is ineens mijn config invalid op het mysensors stukje
Werkte eerst prima voor de upgrade (0.63.0) en zijn zo ver ik weet helemaal geen breaking changes op?

code:

Testing configuration at /home/homeassistant
/.homeassistant 
ERROR:homeassistant.config:Invalid config for [mysensors]: length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_in_prefix']. Got None length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_out_prefix']. Got None. (See /home/homeassistant/.homeassistant/configuration.yaml, line 139). Please check the docs at https://home-assistant.io/components/mysensors/ 
ERROR:homeassistant.setup:Setup failed for mysensors: Invalid config. 
Failed config 
mysensors: 
gateways: [source /home/homeassistant/.homeassistant/configuration.yaml:140] 
    - baud_rate: 115200 
      device: /dev/ttyUSB1 
  optimistic: False 
  persistence: True 
  retain: True 
  version: 2.0 

General Errors: 
- Setup failed for mysensors: Invalid config. 
Successful config (partial) mysensors:

edit:

Ben niet de enige dus:
https://github.com/home-a...me-assistant/issues/12683

Een paar optional values zijn ineens required.

De fix is al gemaakt en wordt opgenomen in 0.64.1 (dat zal vanavond wel zijn)
https://github.com/home-assistant/home-assistant/pull/12687

[Possible]

Ik krijg nog steeds mijn Xiaomi Vacuum cleaner niet aan de praat met 0.64 Meer mensen die dit ervaren? Volgens de forums zou het opgelost moeten zijn namelijk. 0.61 werkte het allemaal prima.

code:

Got exception while fetching the state: No response from the device
13:20 components/vacuum/xiaomi_miio.py (WARNING)
Got error when receiving: timed out
13:20 components/vacuum/xiaomi_miio.py (ERROR)
Updating xiaomi_miio vacuum took longer than the scheduled update interval 0:00:20
13:20 helpers/entity_platform.py (WARNING)

Ip adres klopt gewoon (ik kan hem bedienen met de Mi home app)

[ Voor 61% gewijzigd door Possible op 26-02-2018 13:29 ]

[metbril]

Possible schreef op maandag 26 februari 2018 @ 13:27:
Ik krijg nog steeds mijn Xiaomi Vacuum cleaner niet aan de praat met 0.64 Meer mensen die dit ervaren?
Ip adres klopt gewoon (ik kan hem bedienen met de Mi home app)

Er lijkt wel meer kapot te zijn, lees de commentaren maar:

https://community.home-as...-homekit-bmw-august/44834

[Cyw00d]

Psycho_Mantis schreef op maandag 26 februari 2018 @ 11:26:
Lekker dan, upgrade naar 0.64 en nu is ineens mijn config invalid op het mysensors stukje
Werkte eerst prima voor de upgrade (0.63.0) en zijn zo ver ik weet helemaal geen breaking changes op?

code:

Testing configuration at /home/homeassistant
/.homeassistant 
ERROR:homeassistant.config:Invalid config for [mysensors]: length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_in_prefix']. Got None length of value must be at least 1 for dictionary value @ data['mysensors']['gateways'][0]['topic_out_prefix']. Got None. (See /home/homeassistant/.homeassistant/configuration.yaml, line 139). Please check the docs at https://home-assistant.io/components/mysensors/ 
ERROR:homeassistant.setup:Setup failed for mysensors: Invalid config. 
Failed config 
mysensors: 
gateways: [source /home/homeassistant/.homeassistant/configuration.yaml:140] 
    - baud_rate: 115200 
      device: /dev/ttyUSB1 
  optimistic: False 
  persistence: True 
  retain: True 
  version: 2.0 

General Errors: 
- Setup failed for mysensors: Invalid config. 
Successful config (partial) mysensors:

edit:

Ben niet de enige dus:
https://github.com/home-a...me-assistant/issues/12683

Een paar optional values zijn ineens required.

Ik heb een update van HassIO gedaan vanaf werk, maar HA/PI is niet meer bereikbaar sindsdien, straks eens kijken wat er fout gegaan is

[Psycho_Mantis]

Achja het is teminste niet zoals Domoticz, die zowat stilstaat in de ontwikkeling

Bugs worden gelukkig zeer snel weer opgelost.

[dof]

rbregt schreef op maandag 26 februari 2018 @ 14:48:
[...]

Er lijkt wel meer kapot te zijn, lees de commentaren maar:

https://community.home-as...-homekit-bmw-august/44834

Ja, ik zie ineens ook allerlei log foutmeldingen van internals waar ik met m'n vingers niet aan gezeten heb.
Maar balloob heeft 0.64.1 al beloofd. We wachten wel even af.

[NovapaX]

dof schreef op maandag 26 februari 2018 @ 16:03:
[...]


Ja, ik zie ineens ook allerlei log foutmeldingen van internals waar ik met m'n vingers niet aan gezeten heb.
Maar balloob heeft 0.64.1 al beloofd. We wachten wel even af.

Wat voor foutmeldingen zijn dat dan? En is er nog iets stuk daardoor?

[lolgast]

Bij mij gaat het ook niet helemaal lekker. Lijkt eerst te struikelen over REST-sensors, en daardoor loopt alles uiteindelijk vertraging op. Ben as we speak de docker-image van 0.63.3 weer aan het starten

Update: Ik durf wel te beweren dat er een fout in 0.64 zit. Draai nu met de oude versie een stuk stabieler, 0 fouten in de log ipv 40 in 1 minuut.

[ Voor 26% gewijzigd door lolgast op 26-02-2018 19:13 ]

[dof]

NovapaX schreef op maandag 26 februari 2018 @ 18:53:
[...]

Wat voor foutmeldingen zijn dat dan? En is er nog iets stuk daardoor?

Nah, wat meldingen die ik nog niet eerder zag (meen ik). Maar bij mij draait alles gewoon dus waarschijnlijk iets onschuldigs.

[UltraSub]

Possible schreef op maandag 26 februari 2018 @ 13:27:
Ik krijg nog steeds mijn Xiaomi Vacuum cleaner niet aan de praat met 0.64 Meer mensen die dit ervaren? Volgens de forums zou het opgelost moeten zijn namelijk. 0.61 werkte het allemaal prima.

code:

Got exception while fetching the state: No response from the device
13:20 components/vacuum/xiaomi_miio.py (WARNING)
Got error when receiving: timed out
13:20 components/vacuum/xiaomi_miio.py (ERROR)
Updating xiaomi_miio vacuum took longer than the scheduled update interval 0:00:20
13:20 helpers/entity_platform.py (WARNING)

Ip adres klopt gewoon (ik kan hem bedienen met de Mi home app)

Draai hem eens met de hand in debug mode onder het hass environment?

code:

mirobo -d --ip <x.x.x.x> --token <secret> info

[Possible]

UltraSub schreef op maandag 26 februari 2018 @ 20:01:
[...]

Draai hem eens met de hand in debug mode onder het hass environment?

code:

mirobo -d --ip <x.x.x.x> --token <secret> info

Werkt dit ook met een hassio ?

[NovapaX]

lolgast schreef op maandag 26 februari 2018 @ 18:57:
Bij mij gaat het ook niet helemaal lekker. Lijkt eerst te struikelen over REST-sensors, en daardoor loopt alles uiteindelijk vertraging op. Ben as we speak de docker-image van 0.63.3 weer aan het starten

Update: Ik durf wel te beweren dat er een fout in 0.64 zit. Draai nu met de oude versie een stuk stabieler, 0 fouten in de log ipv 40 in 1 minuut.

Maar welke fout? Welke meldingen kreeg je.
Zonder een ietwat gedetailleerdere beschrijving wordt het wat moeilijk om problemen op te lossen natuurlijk.

[lolgast]

Hij staat alleen op warning, dus ik heb geen idee. Geen zin om er in te duiken ook vanavond. Zoals ik zei, hij begon met REST-sensor timeouts, vervolgens Tado, Aqara, input_boolean en eigenlijk alle andere sensors die ik heb.

[Trebbors]

Sinds kort ook begonnen met Home Assistant op Hassio.IO. Ik probeer het in basis een beetje te begrijpen en aan te leren. Ik zit nu een tijdje te prutsen met de Daikin.

Via de volgende items de Daikin toevoegen aan de configuration.yaml geeft geen consequente output.
https://home-assistant.io/components/sensor.daikin/
https://home-assistant.io/components/climate.daikin/
Ik heb beide afzonderlijk en tegelijkertijd toegevoegd gehad.

Soms worden zowel binnen- als buiten temparatuur weergegeven in de balk boven. Zelfs wanneer ik - inside_temperature en - outside_temperature weg haal bij de sensor.
Ik heb twee keer Daikin staan onder de kop 'klimaat'. Ook als ik 'climate' hernoem naar 'climate test'.
Na het weghalen van beide Daikin configuratie-items en een volledige herstart bleef de Daikin weergegeven worden op het dashboard en zelfs bestuurbaar.

Ik heb ook nog geen verschil gezien tussen de optie serverbeheer - herstarten en host system reboot.
De vier herlaad opties zijn volgens mij niet van toepassing na een configuration wijziging.

Het gaat me meer om de logica te begrijpen, de uiteindelijke configuratie komt wel daarna.

edit:
Na het geheel opschonen van de configuration.yaml zie ik de Daikin en losse sensors terug russen de entiteiten. Deze zal ik dus ook moeten opschonen..

[ Voor 27% gewijzigd door Trebbors op 26-02-2018 23:03 ]

[Gaiber]

Ik ben bezig met presence detection op kamerniveau dmv room assistant icm met een aantal Raspberry pi zero w. Het werkt goed als ik m'n telefoon als ble beacon instel maar dit kost batterij. Heeft iemand een goede ble beacon/ibeacon die aan je sleutelbos kan en instelbaar is in oa uitzendtijd? De nut3 werkt helaas niet goed hier.

[Sypher]

Gaiber schreef op dinsdag 27 februari 2018 @ 04:55:
Ik ben bezig met presence detection op kamerniveau dmv room assistant icm met een aantal Raspberry pi zero w. Het werkt goed als ik m'n telefoon als ble beacon instel maar dit kost batterij. Heeft iemand een goede ble beacon/ibeacon die aan je sleutelbos kan en instelbaar is in oa uitzendtijd? De nut3 werkt helaas niet goed hier.

Ik heb hetzelfde draaien maar dan met HappyBubbles Presence Server met Node-Red + MQTT op m'n Zeroes. Voor tracking gebruik ik mijn Mi Band 2.

Werkt ideaal en de "beacon" (discoverable) feature kost amper meer batterij dan normaal, hoef hem sowieso maar eens per 3-4 weken op te laden.

[trekker22]

Iemand de neocam motion sensor icm HA? Benieuwd of die correct Lux meet. Wil op wc motion en Lux meten voor schakelen.

[lolgast]

Volgens mij klopte die niet nee. Heb hem hier op de kast gehad, maar is verkocht dus kan het niet meer controleren

[trekker22]

lolgast schreef op dinsdag 27 februari 2018 @ 10:00:
Volgens mij klopte die niet nee. Heb hem hier op de kast gehad, maar is verkocht dus kan het niet meer controleren

zie dat die ook alleen batterij powered is... Dan wordt het denk ik toch maar een duurdere Fibaro met alles er op en eraan.

[Yelti]

Sypher schreef op dinsdag 27 februari 2018 @ 08:02:
[...]


Ik heb hetzelfde draaien maar dan met HappyBubbles Presence Server met Node-Red + MQTT op m'n Zeroes. Voor tracking gebruik ik mijn Mi Band 2.

Werkt ideaal en de "beacon" (discoverable) feature kost amper meer batterij dan normaal, hoef hem sowieso maar eens per 3-4 weken op te laden.

Ik gebruik hetzelfde systeem, echter ik ben overgestapt van zero's naar de ontvangers van happybubbles zelf.
Kreeg mijn pi's niet 100% stabiel.
Kan je je node red config eens delen?

Verder gebruik ik nu een amazefit bip smartwatch ipv de mi band.
Werkt ook goed

[lolgast]

Voor ik zelf ontzettend moeilijk ga denken, vraagje:
Ik gebruik een Hue Motion sensor, die behalve Hue lampen ook Z-Wave geschakelde lampen schakelt. Dat gaat prima, maar ik wil hem slimmer maken. Dat wil zeggen, van meer in Hue geconfigureerde factoren afhankelijk. De Motion wordt nu elke 2 seconde via REST uitgelezen op beweging, en als er na 17:00 uur beweging is gaan de lampen aan. Dat was prima, maar de dagen worden langer . De Hue lampen snappen dit, want er zit ook een LUX-sensor in.
Die LUX-waarde schakelt een json value in de Hue bridge, state.dark true/false. Die wil ik dus in mijn HA, geen probleem. Maar, en nu komt hij, vraag ik me af of het mogelijk is dat de REST-sensor om beweging te detecteren alleen pollt als de value_json.state.dark true is. Dat scheelt doelloos pollen namelijk

[koelkast]

lolgast schreef op dinsdag 27 februari 2018 @ 11:03:
Voor ik zelf ontzettend moeilijk ga denken, vraagje:
Ik gebruik een Hue Motion sensor, die behalve Hue lampen ook Z-Wave geschakelde lampen schakelt. Dat gaat prima, maar ik wil hem slimmer maken. Dat wil zeggen, van meer in Hue geconfigureerde factoren afhankelijk. De Motion wordt nu elke 2 seconde via REST uitgelezen op beweging, en als er na 17:00 uur beweging is gaan de lampen aan. Dat was prima, maar de dagen worden langer . De Hue lampen snappen dit, want er zit ook een LUX-sensor in.
Die LUX-waarde schakelt een json value in de Hue bridge, state.dark true/false. Die wil ik dus in mijn HA, geen probleem. Maar, en nu komt hij, vraag ik me af of het mogelijk is dat de REST-sensor om beweging te detecteren alleen pollt als de value_json.state.dark true is. Dat scheelt doelloos pollen namelijk

Kan je niet 'gewoon' een template sensor aanmaken die 'high lux' of 'low lux' inschakelt? Of is dat niet wat je bedoelt?

[lolgast]

@koelkast
Nee dat bedoel ik niet, de waarde waar HA naar moet kijken interesseert me geen biet, dat wordt gewoon true/false. Wat ik bedoel (hopelijk duidelijk):
Er is een REST-sensor om de beweging te pollen uit de Hue bridge. Dit gebeurt elke 2 seconde
Er is een REST-sensor om de LUXwaarde te pollen uit de Hue bridge. Dit gebeurt elke 2 seconde

Als de REST-sensor voor de LUXwaarde = false, hoeft de beweging in principe niet gepollt te worden, want de lampen moeten toch uit blijven. Dus ik zoek naar een mogelijkheid om die sensor pas in te schakelen bij het triggeren van LUXwaarde = true

Hoe minder polls, hoe groter de kans dat HA stabiel blijft draaien. Is de gedachte

[RudolfR]

Ik zag dit kortgeleden in de Home Assistant discord voorbij komen:

https://github.com/Rocka84/pushing-hue

Een script om te installeren op de bridge om wijzigingen te pushen naar HA.

Gaat misschien wat ver in om dit in te regelen als oplossing voor bovenstaande, maar vond 't wel tweakerwaardig genoeg om hier te delen.

[lolgast]

Inderdaad net iets te veel van het goede

[ny-hardcore]

lolgast schreef op dinsdag 27 februari 2018 @ 11:03:
Voor ik zelf ontzettend moeilijk ga denken, vraagje:
Ik gebruik een Hue Motion sensor, die behalve Hue lampen ook Z-Wave geschakelde lampen schakelt. Dat gaat prima, maar ik wil hem slimmer maken. Dat wil zeggen, van meer in Hue geconfigureerde factoren afhankelijk. De Motion wordt nu elke 2 seconde via REST uitgelezen op beweging, en als er na 17:00 uur beweging is gaan de lampen aan. Dat was prima, maar de dagen worden langer . De Hue lampen snappen dit, want er zit ook een LUX-sensor in.
Die LUX-waarde schakelt een json value in de Hue bridge, state.dark true/false. Die wil ik dus in mijn HA, geen probleem. Maar, en nu komt hij, vraag ik me af of het mogelijk is dat de REST-sensor om beweging te detecteren alleen pollt als de value_json.state.dark true is. Dat scheelt doelloos pollen namelijk

En een condition in HA op basis van de sun.sun ? Heeft een attribute met de stand boven/onder de horizon. Die gebruik ik voor de beweging sensor buiten en de lampen automatisch in de woonkamer. .

[code]
alias: motion detected
trigger:
platform: state
entity_id: binary_sensor.motion_2
from: 'off'
to: 'on'
condition:
condition: or
conditions:
- condition: template
value_template: '{{ states.sun.sun.attributes.elevation < 3.5 }}'
- condition: state
entity_id: 'group.presence'
state: 'not_home'
action:
- delay: 00:00:01
- service: notify.telegram
data:
title: ''
message: Motion detected!
data:
photo:
- url: !secret foscam_url
caption: 'Motion detected!'
[/code]


niet goed gelezen.

[ Voor 20% gewijzigd door ny-hardcore op 27-02-2018 14:16 ]

[lolgast]

Dat wil ik niet, want dan is Hue nog steeds niet leidend. Hue zie ik als losstaand systeem welke zonder interactie van HA gewoon moet functioneren. Dat ik overige apparaten kan schakelen naar aanleiding van Hue is top, maar als HA stuk gaat moet Hue gewoon blijven werken zoals het werkt.

Ten eerste omdat ik van mening ben dat Hue best een volwassen systeem is en ten tweede om ruzie met mijn vrouw te voorkomen

[RudolfR]

En zelf een python-script schrijven om motion te pollen bij de hue-api?
Aan dat script geef je de huidige lux-waarde mee, zodat het script overdag simpelweg 'false' teruggeeft.
Als het donker is doe je een request naar de hue-api en retourneer je de werkelijk waarde.

https://home-assistant.io...-of-templating-in-command

Wordt de status van hue per device/sensor opgevraagd, of is er één request/repsons voor alle devices in het netwerk. Als dat laatste het geval is, dan is deze optimalisatie zinloos...

[koelkast]

trekker22 schreef op dinsdag 27 februari 2018 @ 09:57:
Iemand de neocam motion sensor icm HA? Benieuwd of die correct Lux meet. Wil op wc motion en Lux meten voor schakelen.

Jazeker, ik gebruik hem inclusief luxmeting in HA. Je moet echter wel even wat aan de Z-Wave instellingen veranderen, anders is het niet nauwkeurig genoeg. Nu ben ik tevreden.
Het veranderen van die instellingen zal allicht gevolgen hebben voor de batterijduur, maar dat zien we wel weer.

[lolgast]

We liggen nog niet helemaal op een lijn, of ik snap je niet. Ik wil de mogelijkheid om een sensor uit te schakelen (poll beweging) naar aanleiding van de status van een andere sensor (poll lux).
Natuurlijk kan dat met Python, want dan bouw je in je script gewoon een if/else in voordat je de beweging poll uitvoert. Maar ik ben vooral benieuwd of die functie niet gewoon in HA zit.

Ik zou nog een automation kunnen maken: If lux is laag-genoeg -> create file with sensor in it -> homeassistant.restart. Maar dat is niet wenselijk omdat de rest dan niet werkt in de tussentijd

[ANdrode]

lolgast schreef op dinsdag 27 februari 2018 @ 15:51:
We liggen nog niet helemaal op een lijn, of ik snap je niet. Ik wil de mogelijkheid om een sensor uit te schakelen (poll beweging) naar aanleiding van de status van een andere sensor (poll lux).
Natuurlijk kan dat met Python, want dan bouw je in je script gewoon een if/else in voordat je de beweging poll uitvoert. Maar ik ben vooral benieuwd of die functie niet gewoon in HA zit.

Even een achterliggende vraag: Waar wordt die state bewaard?

Polled hue bridge de sensor wanneer de state opgevraagd wordt (synchroon) of bewaard de hue bridge intern de state van de sensor en verstuurd de sensor deze regelmatig (voor sync) en wanneer er activiteit is?

De bridge pollen zou ik geen probleem vinden namelijk

[lolgast]

Hoe de bridge aan zijn waardes komt weet ik niet, maar alle states staan gewoon in de bridge en zijn op te vragen via de api van de bridge.

Ik ben ook niet bang dat de bridge het te zwaar voor zijn kiezen krijgt. HA wordt alleen steeds voller en als ik 18 uur per dag doelloos elke 2 seconde een poll verstuur waar ik niets aan heb, vraag ik me af of dat ook slimmer kan. Vandaar de vraag

[Hmmbob]

Dat zit niet standaard in HA.

[ThinkPad]

@lolgast Ik heb hier net afgelopen weekend de boel over de kop gegooid vanwege eigenlijk dezelfde reden.
Voorheen had ik geen rules in Hue en pollde ik ook elke 2s de beide motion sensors (2 requests) en de lux sensoren van beide motion sensors (nog eens twee requests). In totaal dus elke 2s 4 requests
In HASS had ik de regels (motion + lux <threshold = lamp aan) en dus ook de aansturing. Dit was irritant, want met een beetje snel lopen stond ik al halverwege de kamer voordat:
- HASS via de Hue bridge had doorgekregen dat er motion was
- HASS aan de bridge had teruggekoppeld dat het licht aan moest

Ik heb steeds meer Hue/TRADFRI lampen en heb nu dus de slimmigheid in de bridge gemaakt.
Via de app kan dat, maar je kunt ook lekker zelf klieren via de CLIP API, helemaal niet zo moeilijk: Nicky's TweakBlog: Home Assistant: Philips Hue Motion Sensor

Ik heb beide motion sensors gecombineerd tot één virtuele sensor. Die laatste lees ik uit in HASS.
Verder heb ik nog wat non-Hue lampen, ik poll nu één Hue lamp die eigenlijk in al m'n Hue-scenes wel aan staat.

Op die manier heb ik nog maar twee requests en de interval daarvan heb ik teruggebracht naar elke 30s.
Dat is snel genoeg voor mij, ik heb nu immers gelijk licht doordat de meeste lampen (Hue) al aanspringen.

En alles wat ik verder nog vanuit HASS > Hue wil (scene zetten) doe ik gewoon met een simpel curl commando. Heb mijn bijgewerkte config nog niet gesynced naar m'n Bitbucket, kijk hier dus even voor een voorbeeldje: M.v.Veelen in "Domoticz - open source domotica systeem - deel 3"

Scheelt een shitload aan requests op een dag richting de bridge en het licht gaat nu nog sneller aan ook

[ Voor 26% gewijzigd door ThinkPad op 27-02-2018 17:44 ]

[oohh]

lolgast schreef op maandag 26 februari 2018 @ 08:53:
Nieuwe update van HA is beschikbaar, 0.64. Eerste stap voor Homekit integratie is gemaakt zo te zien, maar de supported devices is nog erg karig. Vooralsnog blijft het dus noodzakelijk om Homebridge te blijven draaien ipv dit via Homekit te doen.

Homekit werkt vooralsnog bij mij niet. Ik heb het op een Raspberry Pi 2 en Raspberry Pi 3 in Docker geprobeerd. Zal wel in een volgende iteratie gefixt worden.

[Faece]

Ik wil appdaemon installeren op mijn synology via putty. Maar als ik sudo pip install appdaemon doe, dan installeert hij tot er een error komt : aiohttp requires Python >3.4.2 but he running python is 2.7.12.

In mijn packages heb ik echter wel python3 geinstalleerd staan.

Ik dacht dan via sudo pip install python3-pip python3 te installen, maar dat werkt ook niet. Iemand die een idee heeft ? Veel info gevonden, maar geen oplossing ...

[RudolfR]

Ik gok zoiets:

Waarschijnlijk heb je een speciale pip voor python3. (pip3)

Of je moet pip starten met de juiste versie van python:

code:

python3 -m pip install

[lolgast]

@ThinkPad Ik heb even na zitten denken over hoe mij dit gaat helpen, maar ik heb geen idee Ik heb maar 1 Motion sensor waarvan ik drie verschillende sensoren wil hebben. Die kan ik niet combineren via een virtuele sensor.

Máár, ik heb wel iets anders bedacht Ik ga de complete /api/sensors van de Hue bridge gewoon exporteren naar een file en haal daar met sensoren alle informatie uit. Eens zien hoe dat gaat

[Faece]

RudolfR schreef op dinsdag 27 februari 2018 @ 20:43:
Ik gok zoiets:

Waarschijnlijk heb je een speciale pip voor python3. (pip3)

Of je moet pip starten met de juiste versie van python:

code:

python3 -m pip install

"python3": command not found

Ik heb inderdaad pip3 nodig, maar weet niet hoe dit te installeren

[ Voor 9% gewijzigd door Faece op 27-02-2018 20:47 ]

[Trebbors]

Trebbors schreef op maandag 26 februari 2018 @ 22:21:
Sinds kort ook begonnen met Home Assistant op Hassio.IO. Ik probeer het in basis een beetje te begrijpen en aan te leren. Ik zit nu een tijdje te prutsen met de Daikin.

Via de volgende items de Daikin toevoegen aan de configuration.yaml geeft geen consequente output.
https://home-assistant.io/components/sensor.daikin/
https://home-assistant.io/components/climate.daikin/
Ik heb beide afzonderlijk en tegelijkertijd toegevoegd gehad.

Soms worden zowel binnen- als buiten temparatuur weergegeven in de balk boven. Zelfs wanneer ik - inside_temperature en - outside_temperature weg haal bij de sensor.
Ik heb twee keer Daikin staan onder de kop 'klimaat'. Ook als ik 'climate' hernoem naar 'climate test'.
Na het weghalen van beide Daikin configuratie-items en een volledige herstart bleef de Daikin weergegeven worden op het dashboard en zelfs bestuurbaar.

Ik heb ook nog geen verschil gezien tussen de optie serverbeheer - herstarten en host system reboot.
De vier herlaad opties zijn volgens mij niet van toepassing na een configuration wijziging.

Het gaat me meer om de logica te begrijpen, de uiteindelijke configuratie komt wel daarna.

edit:
Na het geheel opschonen van de configuration.yaml zie ik de Daikin en losse sensors terug russen de entiteiten. Deze zal ik dus ook moeten opschonen..

Wie zou mij van advies willen voorzien?

[martinvdm]

Faece schreef op dinsdag 27 februari 2018 @ 20:46:
[...]


"python3": command not found

Ik heb inderdaad pip3 nodig, maar weet niet hoe dit te installeren

Probeer dit eens http://domoticx.com/synol...-manager-pip-installeren/
Houdt wel rekening met het feit dan python 3.4 end of life is in de volgende release van ha.

[balk]

kepler schreef op maandag 26 februari 2018 @ 12:45:
[...]

Ik ga het binnenkort instellen, maar geen mogelijkheid om warmwaterleiding te 'meten'. Ik ben van plan het idd met vochtigheid meter te doen, en de vochtigheid buiten en in de woonkamer ook te gebruiken als parameters.

Ik regel mijn ventilatie op twee parameters:
1) na 1 minuut ww tappen op hoog vermogen (badkamer is de enige gebruiker van ww van de CV)
2) indien humdelta is high: blijf nog een kwartier aan, of zolang nodig is.

Humdelta? Dat is het verschil tussen de absolute humidity nu en de laagste waarde van de afgelopen vier uur.

Ik wilde eerst ook met twee sensoren regelen, maar de twee sensoren geven nooit dezelfde waarde. Nu neem ik de laagste waarde van de badkamer vochtigheid in de afgelopen 4 uur, uit influxdb.

code:

- platform: influxdb
  host: localhost
  username: admin
  password: admin
  queries:
    - name: "minhum"
      unit_of_measurement: 'mg/m3'
      value_template: '{{ value | round(1) }}'
      group_function: min
      where: '"property" = ''abshumidity'' AND "sublocation" = ''badkamer'' and time > now() - 4h'
      measurement: 'sensors'
      #field: tmp
      database: sensors

Afgehandeld in appdaemon

[ Voor 4% gewijzigd door balk op 28-02-2018 07:02 ]

[lolgast]

Trebbors schreef op dinsdag 27 februari 2018 @ 21:39:
[...]


Wie zou mij van advies willen voorzien?

Het is met niet helemaal duidelijk wat je nu bedoelt. Maak je gebruik van de groups waardoor er sensoren verborgen zouden moeten zijn, of zou altijd alles zichtbaar moeten zijn op het moment?
De entity_registry.yaml heeft mij ook al een keer parten gespeeld. Vooralsnog zie ik de meerwaarde er niet echt van in, heb nog nooit een sensor gehad die ineens een andere naam had. Trouwens, dat is niet waar. Sinds het bestaan van de entity_registry.yaml heb ik nu twee keer gehad dat mijn Aqara sensoren een _2 achter de naam hadden. Kon ik ze weer verwijderen uit die lijst...

---

Verdergaande op mijn Hue Bridge verhaal. Dit werkt echt goed vind ik Ik heb een shell_command gemaakt die de export maakt en zorgt dat de file niet te groot wordt. Normaliter zou je denken, waarom append je in hemelsnaam om vervolgens de records te verwijderen, maar als je niet append is de file soms leeg en geven de sensoren die de file uitlezen errors

YAML:

hue_export: 'output=$(curl -sS http://192.168.0.187/api/uWi-HmQEct8sMnriB2mQKjMFowaQtYVjTk-gLp4p/sensors); echo $output >> /config/export/hue_export.json; echo "$(tail -n 5 /config/export/hue_export.json)" > /config/export/hue_export.json'

Deze automation triggert het uitlezen van de bridge elke 2 seconden

YAML:

alias: Export Hue Api
initial_state: 'on'
trigger:
  platform: time
  seconds: '/2'
action:
  service: shell_command.hue_export

Een de sensoren om het uit lezen (een als voorbeeld)

YAML:

platform: file
file_path: /config/export/hue_export.json
value_template: '{{ value_json["24"]["state"]["daylight"] }}'
name: 'Hue Motion Keuken Daylight'
scan_interval: 1

[RudolfR]

Die scan_interval kan volgens mij naar 2. Nu ziet ie 50% van de gevallen zeker geen verandering.

Waar zit nu de winst, snellere reactijden van hue, of minder polling?
Wat is het voordeel van deze request via een bestand te laten lopen?
Eén request voor al je sensoren?

Is die api-key geen gevoelige informatie?

[kepler]

balk schreef op woensdag 28 februari 2018 @ 06:55:
[...]

Ik regel mijn ventilatie op twee parameters:
1) na 1 minuut ww tappen op hoog vermogen (badkamer is de enige gebruiker van ww van de CV)
2) indien humdelta is high: blijf nog een kwartier aan, of zolang nodig is.

Humdelta? Dat is het verschil tussen de absolute humidity nu en de laagste waarde van de afgelopen vier uur.

Ik wilde eerst ook met twee sensoren regelen, maar de twee sensoren geven nooit dezelfde waarde. Nu neem ik de laagste waarde van de badkamer vochtigheid in de afgelopen 4 uur, uit influxdb.

code:

- platform: influxdb
  host: localhost
  username: admin
  password: admin
  queries:
    - name: "minhum"
      unit_of_measurement: 'mg/m3'
      value_template: '{{ value | round(1) }}'
      group_function: min
      where: '"property" = ''abshumidity'' AND "sublocation" = ''badkamer'' and time > now() - 4h'
      measurement: 'sensors'
      #field: tmp
      database: sensors

Afgehandeld in appdaemon

Nice, ziet er goed uit. Wel iets wat ik zelf nooit zou kunnen maken, daar heb ik te weinig programmeer kennis voor

Ik heb Netatmo thuis, die op twee plekken luchtvochtigheid meet. Die waardes wilde ik gebruiken samen met vochtigheidmeter in de badkamer. Badkamer raam zit meestal dicht, dus de lucht die de badkamer in wordt gezogen komt uit het huis zelf

Simpel neergezet wil ik zoiets in een Automation zetten.

IF badkamer > netatmo AND > 60% THEN afzuiging_max
IF badkamer < netatmo OR <60% THEN afzuiging_uit

60% beetje willekeurig gekozen, moet ik nog ff exact bepalen.

Ik wacht nog op wat sensoren uit China en dan ga ik alles inbouwen en inregelen in HA. Ik wil hem ook nog gaan koppelen aan de CO2 meting van de Netatmo voor de huiskamer. Zoals gezegd ben ik wat programmeren en HA betreft echt een newbie, dus ik ben benieuwd hoe lang het duurt voordat ik het (goed) werkend heb Ik laat het tzt wel weten!

[lolgast]

RudolfR schreef op woensdag 28 februari 2018 @ 11:08:
Die scan_interval kan volgens mij naar 2. Nu ziet ie 50% van de gevallen zeker geen verandering.

Waar zit nu de winst, snellere reactijden van hue, of minder polling?
Wat is het voordeel van deze request via een bestand te laten lopen?
Eén request voor al je sensoren?

Is die api-key geen gevoelige informatie?

Die 1 seconde laat ik staan, want anders heb je kans dat je vlak voor het verversen van de file er een scan plaatsvind. Dan loop je 2 keer vertraging op. Scenario:

code:

10:00:00:0 -> filescan. Beweging: False
10:00:00:1 -> Bridgescan to File. Beweging: False
10:00:00:2 -> Beweging: True
10:00:02:0 -> filescan. Beweging: False
10:00:02:1 -> Bridgescan to File. Beweging: True
10:00:04:0 -> filescan. Beweging: True

Dan duurt het bijna 4 seconde voor je wijziging wordt opgepikt
Voordeel is inderdaad dat er maar 1 query is met alle data erin. Of dat echt een voordeel is weet ik niet hoor, maar zo voelt het wel

Vwb de api-key. Had je iets in gedachte nu je in het bezit bent van de mijne? Volgens mij moet ik dan wel wat meer info lekken voordat iemand daar iets aan heeft

[Morphix]

Vraagje voor de mensen die HA in Docker draaien.

Een tijdje geleden viel de stroom even van mijn systeem met een hard reset als gevolg. Sindsdien werkt HA niet meer. Ik gebruik docker-compose en map mijn homeassistant folder als volume onder /config. Elke keer als ik de container start wordt (in de container) /config gevuld met de default (first start) HA bestanden; met andere woorden, mijn config bestanden worden niet geladen.

Ook als ik mijn (lokale) homeassistant folder als volume onder een willekeurige directory zet (eg. /homeassistant) worden de default HA bestanden in die directory gezet in de container.

Iemand een idee waar dit aan kan liggen?

[lolgast]

Rechten issue op de map? Deel je docker-compose anders even

[balk]

kepler schreef op woensdag 28 februari 2018 @ 11:13:
[...]

Nice, ziet er goed uit. Wel iets wat ik zelf nooit zou kunnen maken, daar heb ik te weinig programmeer kennis voor

Ik heb Netatmo thuis, die op twee plekken luchtvochtigheid meet. Die waardes wilde ik gebruiken samen met vochtigheidmeter in de badkamer. Badkamer raam zit meestal dicht, dus de lucht die de badkamer in wordt gezogen komt uit het huis zelf

Simpel neergezet wil ik zoiets in een Automation zetten.

IF badkamer > netatmo AND > 60% THEN afzuiging_max
IF badkamer < netatmo OR <60% THEN afzuiging_uit

60% beetje willekeurig gekozen, moet ik nog ff exact bepalen.

Ik wacht nog op wat sensoren uit China en dan ga ik alles inbouwen en inregelen in HA. Ik wil hem ook nog gaan koppelen aan de CO2 meting van de Netatmo voor de huiskamer. Zoals gezegd ben ik wat programmeren en HA betreft echt een newbie, dus ik ben benieuwd hoe lang het duurt voordat ik het (goed) werkend heb Ik laat het tzt wel weten!

Ik zou (badkamer-netatmo)>drempel doen, anders zal de ventilatie aan gaan bij een miniem verschil. Ik gebruik ook absolute vochtigheid om de temperatuursafhankelijkheid uit te sluiten. Als het warm is in de badkamer kan de RV lager zijn maar de absV hoger.

Programmeren is overigens niet mijn werk ofzo, Google is mijn steun en toeverlaat bij elke regel code ik weet wel iets van meet en regelkunde en procestechniek

[kepler]

balk schreef op woensdag 28 februari 2018 @ 12:50:
[...]

Ik zou (badkamer-netatmo)>drempel doen, anders zal de ventilatie aan gaan bij een miniem verschil. Ik gebruik ook absolute vochtigheid om de temperatuursafhankelijkheid uit te sluiten. Als het warm is in de badkamer kan de RV lager zijn maar de absV hoger.

Programmeren is overigens niet mijn werk ofzo, Google is mijn steun en toeverlaat bij elke regel code ik weet wel iets van meet en regelkunde en procestechniek

Dat is een goede, ga ik ook meenemen Eerst maar simpel beginnen en dan langzaam uitbreiden

Ik gebruik vooral veel voorbeelden die ik dan weer aanpas. Het aanpassen lukt prima, maar echt zelf iets opbouwen is (nog) iets teveel van het goede. Ik heb een technische opleiding gedaan, dus daar heb ik ooit wel iets met programmeren e.d. gedaan (Matlab, Visual Basic, FEM, Labview). Maar dat is allemaal lang geleden en nooit dagelijks gebruikt.

[Morphix]

lolgast schreef op woensdag 28 februari 2018 @ 11:36:
Rechten issue op de map? Deel je docker-compose anders even

code:

version: '3'

networks:
  proxy:
    external: true
  internal:
    external: false

services:
  db:
    image: postgres:alpine
    restart: always
    networks:
      - internal
    volumes:
      - dbhassvol:/var/lib/postgresql/data

  hass:
    image: homeassistant/home-assistant:latest
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${HOME}/projects/home-assistant:/config
    ports:
      - 8123:8123
    networks:
      - internal
      - proxy
    labels:
      - traefik.backend=hass
      - traefik.frontend.rule=[...]
      - traefik.docker.network=proxy
      - traefik.port=8123
    devices:
      - /dev/ttyUSB0:/dev/zwave:rwm
    depends_on:
      - db

volumes:
  dbhassvol:
    driver: local

Traefik (reverse proxy) is op dit moment niet actief, maar dat zou verder niet zoveel uit moeten maken.

[lolgast]

@Morphix Hmm, ik zie opzich niets geks. Je zou nog kunnen proberen om dit toe te voegen aan je hass-service

code:

environment:
  - PUID=1026
  - PGID=100

En dan uiteraard even de uid en gid van de user die rechten heeft op je '${HOME}/projects/home-assistant' folder

[Psycho_Mantis]

blijkbaar is 0.64.1 al uitgebracht, ondanks er nog geen release notes zijn. Eens kijken of deze wat beter draait.

[dof]

Psycho_Mantis schreef op woensdag 28 februari 2018 @ 14:31:
blijkbaar is 0.64.1 al uitgebracht, ondanks er nog geen release notes zijn. Eens kijken of deze wat beter draait.

De release notes staan even verderop onder release notes 0.64. 't Is beschouwd als minor release.
Draait bij mij zonder problemen so far.

[ThinkPad]

lolgast schreef op woensdag 28 februari 2018 @ 10:50:
[...]

Verdergaande op mijn Hue Bridge verhaal. Dit werkt echt goed vind ik
<code>

Weet je ook hoe ik de bridge leegtrek naar een sensor en op basis van die sensor weer nieuwe sensoren kan maken? Jouw oplossing is ook best leuk, maar heb een SSD in m'n thuisserver zitten, elke 2s een file wegschrijven gaat niet bevorderlijk zijn voor de levensduur vrees ik.

Dus sensor.hue_bridge

En dan een sensor.motion_woonkamer die z'n informatie weer ophaalt uit die sensor.

[RudolfR]

Morphix schreef op woensdag 28 februari 2018 @ 14:05:
[...]

code:

version: '3'

networks:
  proxy:
    external: true
  internal:
    external: false

services:
  db:
    image: postgres:alpine
    restart: always
    networks:
      - internal
    volumes:
      - dbhassvol:/var/lib/postgresql/data

  hass:
    image: homeassistant/home-assistant:latest
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${HOME}/projects/home-assistant:/config
    ports:
      - 8123:8123
    networks:
      - internal
      - proxy
    labels:
      - traefik.backend=hass
      - traefik.frontend.rule=[...]
      - traefik.docker.network=proxy
      - traefik.port=8123
    devices:
      - /dev/ttyUSB0:/dev/zwave:rwm
    depends_on:
      - db

volumes:
  dbhassvol:
    driver: local

Traefik (reverse proxy) is op dit moment niet actief, maar dat zou verder niet zoveel uit moeten maken.

Werkt die expansie van die ${HOME} wel? Ik geef altijd absolute paden op voor docker-compose. (v2)

[lolgast]

@ThinkPad Hoe haal jij hem leeg dan?

Ik heb namelijk ook lopen hannesen met 'fetch-multiple-json-values-and-present-them-as-attributes' maar dat lijkt niet te lukken omdat bijvoorbeeld de temperatuur en lux sensoren achter verschillende sensor-nummers zitten.
Ik schrijf overigens gewoon naar HDDs weg, dus die schrijfacties kunnen me gestolen worden. De databases worden toch ook geüpdatet

[ThinkPad]

@lolgast Ik weet het al weer, voor mijn YouLess LS120 liep ik tegen hetzelfde aan: vanuit één JSON array had ik meerdere waarden (5 stuks) nodig. Maar 5x HTTP-request naar dat arme ding vond ik toen ook al geen idee.

Ik gebruik een custom component 'jsonrest' er voor: https://community.home-as...n-a-template-sensor/20490

Die propt alles in één sensor (ls120_json), in m'n automations kan ik dan states.sensor.ls120_json.attributes.list[0].pwr aanwijzen.

Zal daar nog even mee stoeien, of ik dat component ook voor Hue kan inzetten.

Edit @lolgast gelukt Idd met die jsonrest component (zie linkje).

sensors.yaml:

YAML:

- platform: jsonrest
  resource: http://192.168.6.20/api/mijnapikey/sensors/
  method: GET
  name: 'hue_json'
  scan_interval: 30

- platform: template
  sensors:
    temp_woonkamer:
      friendly_name: "Temperatuur woonkamer"
      value_template: '{{ states.sensor.hue_json.attributes["10"]["state"].temperature | float / 100 }}'

Op die manier kun je met maar één call de hele bridge leegtrekken

[ Voor 29% gewijzigd door ThinkPad op 28-02-2018 15:32 ]

[kepler]

barrymossel schreef op donderdag 22 februari 2018 @ 14:37:
[...]

Je hebt gelijk, hij opent geen extra tabbladen. Maar nog steeds wel in de standaard browser, waar andere tabbladen geopend staan.
Toch/dus wil ik nog steeds gewoon werken in een native app, net zoals ik Facebook, NS, NU, Buienradar, 9292 etc. in een native app fijner vind.

Zoiets misschien? https://community.home-as...ncher-for-android/44876/5

[lolgast]

@ThinkPad Die jsonrest.py sensor maakt bij mij echt alles kapot Geeft de volgende error: NameError: name 'self' is not defined. Hij download ook een pycache file, die vervolgens weer gebruikt lijkt te worden door alle andere sensoren in HA, die ook niet meer functioneren. Schrijfacties uitgeschakeld voor HA op /custom_components, geen pycache file, maar ook geen sensors
Denk dat ik er morgenavond nog eens goed voor ga zitten

[ThinkPad]

Balen. Misschien hebben ze de code inmiddels al weer bijgewerkt. Heb mijn versie even geupload: https://pastebin.com/XZw551Jy

[Oulewappeur]

Hi allemaal,

Heeft iemand een goed voorbeeld hoe ik mijn UI van HASS.io kan aanpassen?

Ik heb diverse sensoren(synology, dsmr, en toekomstige waarschijnlijk nog meer) die ik apart in een kader of een tabje wil weergeven, maar met de informatie online wordt ik niet echt wijzer.

[Fonta]

Oulewappeur schreef op woensdag 28 februari 2018 @ 17:37:
Hi allemaal,

Heeft iemand een goed voorbeeld hoe ik mijn UI van HASS.io kan aanpassen?

Ik heb diverse sensoren(synology, dsmr, en toekomstige waarschijnlijk nog meer) die ik apart in een kader of een tabje wil weergeven, maar met de informatie online wordt ik niet echt wijzer.

https://github.com/f0nt4/...configuration/groups.yaml

Is inmiddels al een beetje verouderd, maar is volgens mij voldoende om je verder te helpen.

[Morphix]

lolgast schreef op woensdag 28 februari 2018 @ 14:22:
@Morphix Hmm, ik zie opzich niets geks. Je zou nog kunnen proberen om dit toe te voegen aan je hass-service

code:

environment:
  - PUID=1026
  - PGID=100

En dan uiteraard even de uid en gid van de user die rechten heeft op je '${HOME}/projects/home-assistant' folder
[afbeelding]

Ik draai Docker Toolbox OSX dus de setup is misschien wat ingewikkelder dan normaal. Maargoed, zowel 'id' van mijn Mac user, als 'id' van docker-machine doen niets anders.

Zelfs als ik letterlijk het command van de home-assistant installation guide overneem blijf ik het probleem houden.

@RudolfR
Yes, dat komt uit op de juiste directory in terminal. Maar ook als ik de volledige path opgeef in docker helpt het niet.

Mijn config files worden simpelweg niet gelezen, danwel overschreven en ik begrijp niet waarom.

ls -l op configuration.yaml (vanuit docker-machine)

code:

-rw-r--r--    1 root     root          1788 Feb 26 20:47 configuration.yaml

[Imperial Guard]

Met welke camera's hebben jullie een goede ervaring binnen Hass?

Ik ben opzoek naar twee betaalbare camera's voor buiten waarvan één bij de voordeur die eigenlijk op een relatief korte afstand opnames moet maken +- max 1 meter. En de ander wil ik ter hoogte van de veranda plaatsen die gericht op de poort staat.

Bij de voordeur zat ik te denken aan een compacte dome camera.

[Faece]

martinvdm schreef op dinsdag 27 februari 2018 @ 22:12:
[...]

Probeer dit eens http://domoticx.com/synol...-manager-pip-installeren/
Houdt wel rekening met het feit dan python 3.4 end of life is in de volgende release van ha.

Wat bedoel je met end of life ? Als ik appdaemon geinstalleerd wil krijgen, moet ik zowiezo op 1 of andere manier python >3.4 er op krijgen. als ik hem laat uitpakken verwijst hij steeds naar "configparser in ./python2.7" , terwijl python 3.4.2 als package we zou moeten geinstalleerd zijn.
Installeren van appdaemon wordt steeds geaborted op aihttp requires python 3.4.2 maar ik zit dus blok ...

[martinvdm]

Imperial Guard schreef op woensdag 28 februari 2018 @ 21:33:
Met welke camera's hebben jullie een goede ervaring binnen Hass?

Ik ben opzoek naar twee betaalbare camera's voor buiten waarvan één bij de voordeur die eigenlijk op een relatief korte afstand opnames moet maken +- max 1 meter. En de ander wil ik ter hoogte van de veranda plaatsen die gericht op de poort staat.

Bij de voordeur zat ik te denken aan een compacte dome camera.

Foscam. Hass.io niet maar binnen Home assistant werkt het prettig vind ik. Alhoewel ik alleen live beeld en snapshots e.d aan stuur en niet echt functies vanuit ha aanspreek voor wat betreft opnemen, zoom of andere zaken.

[martinvdm]

Faece schreef op woensdag 28 februari 2018 @ 21:36:
[...]


Wat bedoel je met end of life ? Als ik appdaemon geinstalleerd wil krijgen, moet ik zowiezo op 1 of andere manier python >3.4 er op krijgen. als ik hem laat uitpakken verwijst hij steeds naar "configparser in ./python2.7" , terwijl python 3.4.2 als package we zou moeten geinstalleerd zijn.
Installeren van appdaemon wordt steeds geaborted op aihttp requires python 3.4.2 maar ik zit dus blok ...

Ik ben geen bekende met appdeamon of überhaupt installeren op een synology, maar als je geen docker kunt draaien dan zou ik eerder naar een pi kijken. Veel tutorials zijn hierop gebaseerd. voor wat betreft python; Home assistant zal met de volgende versie python 3.4 schrappen als supported versie.