Home Assistant - Open source Python3 home automation

[HaTe]

studiodubio schreef op woensdag 18 januari 2017 @ 09:31:
Ik heb nu een aantal Z-wave deursensoren en bewegingsensor van Fibaro. Maar ik zoek een alternatief voor het dure Z-wave. Domotica moet wel leuk en betaalbaar blijven. Het moet dan wel 2-weg communicatie hebben, dus geen 433mhz protocol. Hebben jullie suggesties en praktijkervaringen?

Als je handig bent met Arduino kan je zelf sensoren maken met MySensors library voor Arduino: https://www.mysensors.org/

Per sensor ben je dan zo'n 5 euro kwijt

[ Voor 55% gewijzigd door HaTe op 18-01-2017 09:57 ]

[[RNMC] Viper]

UltraSub schreef op woensdag 18 januari 2017 @ 07:11:
Net eens even geupgrade van 33.1 > 36.1. Alles gaat goed, alles start netjes, geen foutmeldingen, zwave logs ook schoon. Maar helaas; mijn zwave schakelaars in de frontend werken niet meer. Als je een schakelaar aan of uit zet, dan zie je dat dat op zwave level gebeurt en er ook de goede melding terug komt. Hass zet de status echter vrijwel meteen weer terug naar de initiele stand (die dan dus afwijkt van de daadwerkelijke zwave status), waarna de switch dan niet meer te bedienen is omdat hass immers het verkeerde commando stuurt.

Jammer, for now maar even terug naar de snapshots.
Later nog eens proberen.

gebruik je ssl?

[UltraSub]

[RNMC] Viper schreef op woensdag 18 januari 2017 @ 21:57:
[...]

gebruik je ssl?

Je doelt op secure zwave? Ja, er is een network key in gebruik inderdaad voor twee devices.
Maar ook non-secure devices werken niet goed in de front-end.
En zwave zelf lijkt gewoon goed te werken. Sterker nog, situatieschetsje:

- Hass is gestopt
- Een secure device staat on
- Hass start
- Openzwave initialiseert volledig en gezond
- Hass rapporteert voor dat betreffende device on
- Switch dat device naar off
- Front-end switch gaat off
- Zwave logs laten zien dat het device een opdracht voor off krijgt, wordt uitgevoerd en zwave rapporteert de nieuwe off status.
- Hass switch gaat terug naar on (binnen enkele seconden), waarschijnlijk omdat hass denkt dat de switch niet gelukt is.

Ik zie dus op zwave level geen encryption errors. Die heb ik in het begin wel gehad, bleek dat hass de network key nog ergens anders leest, er is nog een options.xml, weet even uit mijn hoofd niet meer waar. Die twee moet ik nog symlinken.

/edit
Je triggered me wel, ik meen me te herinneren dat die tweede options.xml in een venv zat. Wellicht is die bij de upgrade overschreven. Zal ik eens nakijken. Alhoewel ik in die situatie wel errors had verwacht.

/edit 2
Terug gevonden in een oude chat welke twee options.xml er zijn:

code:

/srv/hass/lib/python3.5/site-packages/libopenzwave-0.3.1-py3.5-linux-x86_64.egg/config/options.xml
/srv/hass/src/python-openzwave/openzwave/config/options.xml

Mijn hass gebruikt dus de bovenste
Terwijl de rest van alle zwave config gewoon in de onderste staat en ook van daaruit wordt gelezen.
Beide options.xml hebben nu dezelfde network key dus. Wellicht na een upgrade overschreven, maar dat kan ik nu dus niet controleren, immers snapshots terug gezet en vandaag geen tijd om nog eens te upgraden.

[ Voor 94% gewijzigd door UltraSub op 19-01-2017 10:33 ]

[[RNMC] Viper]

😄

Bedoelde ssl voor frontend hass, kwam er achter dat hij hier met iOS devices niet meer ververst.

[ Voor 42% gewijzigd door [RNMC] Viper op 19-01-2017 11:17 ]

[UltraSub]

Nginx met self signed inderdaad.

[[RNMC] Viper]

Probeer eens zonder

[UltraSub]

Kan eens proberen. Maar denk dat het weinig gaat uithalen omdat het wel streamed en dus update.
Ik zal vanmiddag nog eens upgraden en kijken of ik verder kom.

[Rmg]

UltraSub schreef op vrijdag 20 januari 2017 @ 08:53:
Kan eens proberen. Maar denk dat het weinig gaat uithalen omdat het wel streamed en dus update.
Ik zal vanmiddag nog eens upgraden en kijken of ik verder kom.

in 34 is er iets met de websockets veranderd, liep ik ook tegen aan https://alienlabs.eu/2016/12/19/49/

[UltraSub]

Dat lijkt het te zijn geweest. Heb een --force-reinstall gedaan, en daarna kreeg ik een "reconnecting" in mijn frontend (wat ik bij de eerste upgrade dus niet had, die leek gewoon goed te streamen). Nginx config gefixed, en het draait nu. Eens kijken waar we nu weer tegenaan gaan lopen

https://community.home-as...ter-update-to-36-1/9943/8

/edit
Kut. iOS safari werkt dus niet. Connection lost, reconnecting.
Das wel ff een dingetje.

[ Voor 11% gewijzigd door UltraSub op 20-01-2017 12:41 ]

[[RNMC] Viper]

Loop ik hier ook tegen aan, dus maar even ssl eraf gegooid

[UltraSub]

No way dat ik ssl eraf ga slopen. Lekker, authenticatie voor je huis in plain text over het boze web
Las laatst ook ergens dat de iOS app die ooit uit zou moeten komen alleen een trusted certificate vreet. Roept iedereen natuurlijk letsencrypt, maar ik vind het erg verrot dat die 443 en 80 beiden nodig heeft om een certificaat te vernieuwen. Ik draai alles op hogere port ranges en er is meer wat ssl doet hier. Achterlijke beperking imho, iets waar ipv6 wel in zou helpen denk ik

[ThinkPad]

Het valt mij de laatste tijd op dat HASS naar mijn idee een hoop 'onzin' componenten toevoegt.
Ik doel dan op componenten zoals de 'ISS Sensor'.

Waar heb je dat in vredesnaam voor nodig in een domoticasetup? Laat ze zich focussen op de core en laat dit soort onzin achterwege Hoe krijg je je pakket volgestopt met allerlei bloatware
Als er iemand geïnteresseerd is om de positie van het ISS te weten, knal dat dan lekker met een eigen script erin ofzo.

[ Voor 6% gewijzigd door ThinkPad op 20-01-2017 16:10 ]

[Verwijderd]

ThinkPadd schreef op vrijdag 20 januari 2017 @ 16:05:
Het valt mij de laatste tijd op dat HASS naar mijn idee een hoop 'onzin' componenten toevoegt.
Ik doel dan op componenten zoals de 'ISS Sensor'.

Waar heb je dat in vredesnaam voor nodig in een domoticasetup? Laat ze zich focussen op de core en laat dit soort onzin achterwege Hoe krijg je je pakket volgestopt met allerlei bloatware
Als er iemand geïnteresseerd is om de positie van het ISS te weten, knal dat dan lekker met een eigen script erin ofzo.

Het begint soms inderdaad een beetje een rommeltje te worden. Ik ook de vele .x releases die er meestal gelijk achteraan komen stemt mij niet super positief.

[UltraSub]

ThinkPadd schreef op vrijdag 20 januari 2017 @ 16:05:
Het valt mij de laatste tijd op dat HASS naar mijn idee een hoop 'onzin' componenten toevoegt.
Ik doel dan op componenten zoals de 'ISS Sensor'.

Waar heb je dat in vredesnaam voor nodig in een domoticasetup? Laat ze zich focussen op de core en laat dit soort onzin achterwege Hoe krijg je je pakket volgestopt met allerlei bloatware
Als er iemand geïnteresseerd is om de positie van het ISS te weten, knal dat dan lekker met een eigen script erin ofzo.

Dat klopt niet wat je daar zegt. Een component wordt pas geladen als je het gebruikt. Zie het als een plug-in. Onzin het voorbeeld hierboven? Hell yes. Boeiend? Nope. Blijkbaar vond iemand het handig en heeft het geschreven. Dit is gewoon hoe het pakket in elkaar zit. Community driven open source. Als je het dan zo bouwt dat het geen bloating van de core is en het losgekoppeld is, dan is er geen enkel probleem.

Verwijderd schreef op vrijdag 20 januari 2017 @ 19:35:
[...]

Het begint soms inderdaad een beetje een rommeltje te worden. Ik ook de vele .x releases die er meestal gelijk achteraan komen stemt mij niet super positief.

Oneens. De markt is veranderd. Dit is steeds normaler aan het worden in de software wereld. Vroeger:
- plan wat je denkt nodig te hebben
- plan een release over maanden/kwartaal/nog langer
- halverwege het proces ben je aan het debuggen wat je aan het begin hebt gedaan omdat de specs doorlopend worden aangepast
- release wordt uitgesteld
- weer specs aanpassen, meer debuggen, enz
- repeat

Startups, jonge bedrijven, bedrijven die het roer om hebben gegooid:
- Sprint wordt gevuld uit de backlog, bestaande uit features en defects
- Sprint wordt zodanig gevuld dat wat erin zit ook af is in een sprint. 1 of 2 weken.
- Einde sprint is release. Haalt iets het niet dan valt het alsnog uit de sprint.

Resultaat, heel veel kleine fixes en features is een release. Precies aanwijsbaar wat er is aangepast, waarom en kan ook zo gefixed worden of er uit worden gehaald. Kleine brokken doen weinig pijn.

Nog een stap verder, CI; continous integration. Test code (een feature of defect), push, merge request, QA, merge naar dev, build van packages voor de development repos. Merge request van dev naar acc, QA door een peer, merge. Build packages voor acc repos. Repeat voor prod.
Resultaat, heel vaak naar prod met minor minor release levels verschil. Soms veel wijzigingen, soms weinig. Maar wel top geteste code en per wijziging terug te draaien. Bedrijven als Coolblue gaan dagelijks 100'en keren naar prod. Live. Met minieme versie wisselingen. Guess what works best.

/edit
Met andere woorden, dit stemt mij juist heel vrolijk. Zolang ze de core maar losgekoppeld houden van al die zut als ISS. Zeg nou zelf, niet normaal het tempo hoe er ook nuttige componenten mee uit komen. En hoe snel bugs worden gefixed.

[ Voor 4% gewijzigd door UltraSub op 20-01-2017 19:55 ]

[ANdrode]

UltraSub schreef op vrijdag 20 januari 2017 @ 14:48:
No way dat ik ssl eraf ga slopen. Lekker, authenticatie voor je huis in plain text over het boze web
Las laatst ook ergens dat de iOS app die ooit uit zou moeten komen alleen een trusted certificate vreet. Roept iedereen natuurlijk letsencrypt, maar ik vind het erg verrot dat die 443 en 80 beiden nodig heeft om een certificaat te vernieuwen. Ik draai alles op hogere port ranges en er is meer wat ssl doet hier. Achterlijke beperking imho, iets waar ipv6 wel in zou helpen denk ik

Letsencrypt (eigenlijk: ACME) heeft/definieert meerdere manieren om te valideren. Als je bijvoorbeeld de dns challenge gebruikt heb je geen poort 443 + 80 nodig.
Volgens mij voor jou geen probleem om dit ff in te stellen, wel meer effort dan 1x per 3 maanden de andere dienst even stoppen

En de websocket problemen blijven dus bestaan als nginx de connectie afhandelt?

[UltraSub]

ANdrode schreef op vrijdag 20 januari 2017 @ 21:40:
[...]


Letsencrypt (eigenlijk: ACME) heeft/definieert meerdere manieren om te valideren. Als je bijvoorbeeld de dns challenge gebruikt heb je geen poort 443 + 80 nodig.
Volgens mij voor jou geen probleem om dit ff in te stellen, wel meer effort dan 1x per 3 maanden de andere dienst even stoppen

Interessante link zeg. Thanks! Dat kost inderdaad wel ff wat werk denk ik. Maar is wel mooi. Moet ik eens in duiken.

En de websocket problemen blijven dus bestaan als nginx de connectie afhandelt?

Nee, het werkt hier op de MacBook met Safari en Chrome vlekkeloos. Andere browsers nog niet getest. Op iOS is het echter wel een probleem. De frontend werkt gewoon, maar in het begin staat er reconnecting. En hij streamed dus niet. Soms moet je refreshen. Bloedirritant natuurlijk. Maar al blij dat het wel gewoon werkt. Hoef ik tenminste niet meteen terug. Een collega van me draait echter 0.36 en zegt dat hij het probleem niet heeft met nginx. Verschil; die draait een letsencrypt cert, ik draai self signed. Misschien is dat het probleem.. later verder onderzoeken.

[Verwijderd]

UltraSub schreef op vrijdag 20 januari 2017 @ 19:54:
[...]

Waar het mij omgaat is de toename van .x releases en de wat mij betreft niet al te nuttige componenten. Dit haalt de snelheid uit het project. In plaats van bezig zijn met 'laten we het core verbeteringen noemen' is men bezig met het integreren/onderhouden van die niet nuttige componenten. Elke release gaan er een aantal van die componenten stuk of moet men met het ontwikkelen rekening houden dat ze er zijn. Na de release mag men dan weer brandjes blussen omdat ze iets vergeten zijn aan te passen.

Ik vind dat zonde en ik denk niet dat het houdbaar is op de lange termijn. Of je nu aan het scrummen, aan het watervallen of aan [insert method here] bent, het vertraagd de boel.

[UltraSub]

Ik zie je punt en ga daar inderdaad gedeeltelijk in mee. Dat is inderdaad gewoon een feit bij sommige componenten. Maar voor zo'n ISS ding, no way dat ze daar rekening mee gaan houden als er een wijziging in de core nodig is. Dan zie je in de release notes: breaking change, ISS doet niet meer. Heb je het dan bijvoorbeeld over influx, dan wordt het al anders ja. Dat kun je niet zomaar breken. En toch, ik heb het pull request gevolgd, er is gewoon gebroken.

Maar ben het met je eens dat het in the end inderdaad niet helpt. Hoe mooi je het ook bouwt. Steeds meer exoten is gewoon niet goed. Ik reageerde meer op Thinkpad's post die suggereert dat al die schijt components de boel bloaten, dat is niet zo, en op jouw post, dat releases erg hard gaan.

[Fonta]

Volgens mij kan je met letsencrypt ook via alleen poort 443 werken:
./certbot-auto renew --no-self-upgrade --standalone --standalone-supported-challenges tls-sni-01
Zoals hier staat: http://disq.us/p/1amnjes

[ Voor 11% gewijzigd door Fonta op 21-01-2017 02:37 ]

[Verwijderd]

UltraSub schreef op vrijdag 20 januari 2017 @ 23:07:
Ik zie je punt en ga daar inderdaad gedeeltelijk in mee. Dat is inderdaad gewoon een feit bij sommige componenten. Maar voor zo'n ISS ding, no way dat ze daar rekening mee gaan houden als er een wijziging in de core nodig is. Dan zie je in de release notes: breaking change, ISS doet niet meer. Heb je het dan bijvoorbeeld over influx, dan wordt het al anders ja. Dat kun je niet zomaar breken. En toch, ik heb het pull request gevolgd, er is gewoon gebroken.

Maar ben het met je eens dat het in the end inderdaad niet helpt. Hoe mooi je het ook bouwt. Steeds meer exoten is gewoon niet goed. Ik reageerde meer op Thinkpad's post die suggereert dat al die schijt components de boel bloaten, dat is niet zo, en op jouw post, dat releases erg hard gaan.

Het 'bloat' wel degelijk de boel, in de code base zitten al die componenten. De enige reden waarom ze er 'minder/geen' last van hebben als ze het niet updaten is omdat ze geen vooraf gecompileerde taal gebruiken. In het geval van de ISS, je zult past merken dat het stuk is op het moment dat het gebruikt wordt.

[ANdrode]

Verwijderd schreef op zaterdag 21 januari 2017 @ 08:36:
[...]


Het 'bloat' wel degelijk de boel, in de code base zitten al die componenten. De enige reden waarom ze er 'minder/geen' last van hebben als ze het niet updaten is omdat ze geen vooraf gecompileerde taal gebruiken. In het geval van de ISS, je zult past merken dat het stuk is op het moment dat het gebruikt wordt.

Het grootste deel van de bloat door componenten zal uiteindelijk zitten in de libraries die ze nodig hebben. Bij componenten die je niet actief gebruikt worden deze niet geinstalleerd en valt het dus mee. Het hele project is wbt grootte (lines of code) redelijk beperkt.

En het onderhouden van de componenten haalt inderdaad wat snelheid uit het project. Tegelijkertijd krijg je door wat er bij de componenten nodig is een goed beelt van de requirements aan de core, dus je zal sowieso de ontwikkeling van de componenten een beetje moeten volgen als je de core implementeert.

[UltraSub]

ANdrode schreef op vrijdag 20 januari 2017 @ 21:40:
[...]

En de websocket problemen blijven dus bestaan als nginx de connectie afhandelt?

Update, met een valid certificate werkt het ook op iOS. Het was dus de self-signed wat de connection loss veroorzaakte. Even snel een letsencrypt cert geregeld, en nu werken alle browsers goed via nginx.

[UltraSub]

Wat wel bloed irritant begint te worden, en ik had gehoopt dat de .36 update daar wellicht een oplossing voor zou bieden, als ik hass stop en daarna weer start is mijn aeotec gen5 stick dood. Enige wat dan helpt is de stick fysiek verwijderen en terug steken. Hass starten en alles ok.

Na een stop rapporteert de stick 0 devices. Ook in ozwcp. Na "reboot" van de stick gewoon alle devices terug. Domoticz en ozwcp restarten kan ik tig keer doen, kan ik het niet reproduceren. Hass stop is 9 uit 10x stick dood. Erg irritant met een product wat je moet restarten als je iets wil wijzigen.

Zit ik al een tijdje over te denken.. maar ik heb de ozwcp_xxxx.xml in de hass dir gesymlinked naar de ozwcp_xxxx.xml in de openzwave dir zodat de namen altijd kloppen. Hass had daar altijd schrijfrechten. Toen hass een paar keer die xml compleet om zeep had geholpen heb ik hass geen schrijfrechten meer gegeven op dat bestand. Hij hoeft daar immers alleen te lezen wat de config is was de redenatie. Nu begin ik me langzaam af te vragen of dit de reden zou kunnen zijn? Iemand daar ervaring mee?

[DRAFTER86]

UltraSub schreef op zondag 22 januari 2017 @ 10:17:
Wat wel bloed irritant begint te worden, en ik had gehoopt dat de .36 update daar wellicht een oplossing voor zou bieden, als ik hass stop en daarna weer start is mijn aeotec gen5 stick dood. Enige wat dan helpt is de stick fysiek verwijderen en terug steken. Hass starten en alles ok.

Na een stop rapporteert de stick 0 devices. Ook in ozwcp. Na "reboot" van de stick gewoon alle devices terug. Domoticz en ozwcp restarten kan ik tig keer doen, kan ik het niet reproduceren. Hass stop is 9 uit 10x stick dood. Erg irritant met een product wat je moet restarten als je iets wil wijzigen.

Zit ik al een tijdje over te denken.. maar ik heb de ozwcp_xxxx.xml in de hass dir gesymlinked naar de ozwcp_xxxx.xml in de openzwave dir zodat de namen altijd kloppen. Hass had daar altijd schrijfrechten. Toen hass een paar keer die xml compleet om zeep had geholpen heb ik hass geen schrijfrechten meer gegeven op dat bestand. Hij hoeft daar immers alleen te lezen wat de config is was de redenatie. Nu begin ik me langzaam af te vragen of dit de reden zou kunnen zijn? Iemand daar ervaring mee?

Ik ben nog niet zo bekend met de Open Zwave stack (Vind het maar een ondoorzichtig geheel), maar ik heb exact dezelfde setup (Gen5 stick, Raspberry Pi, Raspbian, geïnstalleerd met de All in One Installer), en hier werkt het perfect, HASS restarten is geen enkel probleem.
Laat maar even weten als ik iets voor je kan checken.

Hier nog steeds aan het stoeien met de Qubino dimmer, vandaag maar weer eens een poging doen om de i2/i3 inputs aan de praat te krijgen

[UltraSub]

Heb er maar eens een issue voor aangemaakt, lijkt me niet echt normaal:
https://github.com/home-assistant/home-assistant/issues/5501

[[RNMC] Viper]

UltraSub schreef op zondag 22 januari 2017 @ 10:17:
Wat wel bloed irritant begint te worden, en ik had gehoopt dat de .36 update daar wellicht een oplossing voor zou bieden, als ik hass stop en daarna weer start is mijn aeotec gen5 stick dood. Enige wat dan helpt is de stick fysiek verwijderen en terug steken. Hass starten en alles ok.

Na een stop rapporteert de stick 0 devices. Ook in ozwcp. Na "reboot" van de stick gewoon alle devices terug. Domoticz en ozwcp restarten kan ik tig keer doen, kan ik het niet reproduceren. Hass stop is 9 uit 10x stick dood. Erg irritant met een product wat je moet restarten als je iets wil wijzigen.

Zit ik al een tijdje over te denken.. maar ik heb de ozwcp_xxxx.xml in de hass dir gesymlinked naar de ozwcp_xxxx.xml in de openzwave dir zodat de namen altijd kloppen. Hass had daar altijd schrijfrechten. Toen hass een paar keer die xml compleet om zeep had geholpen heb ik hass geen schrijfrechten meer gegeven op dat bestand. Hij hoeft daar immers alleen te lezen wat de config is was de redenatie. Nu begin ik me langzaam af te vragen of dit de reden zou kunnen zijn? Iemand daar ervaring mee?

Hmm heb hier geen last van, wat is je setup?

Heb hier een mac mini 2014

[UltraSub]

Check ff het issue dat ik heb aangemaakt hierboven, staat alles in

/edit
Overigens even geprobeerd, hass schrijfrechten gegeven, en inderdaad hij verandert de xml. Even door een diff tool gegooid, maar eigenlijk niets spannends, alleen updaten van de current values enz. Errors zijn gelijk echter, dus maar weer read-only gemaakt.

Slaat eigenlijk ook nergens op, dat voor een config verandering van hass altijd het hele zwave network wordt herstart. Daar zouden ze iets aan moeten doen

[ Voor 85% gewijzigd door UltraSub op 22-01-2017 11:25 ]

[ANdrode]

UltraSub schreef op zondag 22 januari 2017 @ 10:17:
Wat wel bloed irritant begint te worden, en ik had gehoopt dat de .36 update daar wellicht een oplossing voor zou bieden, als ik hass stop en daarna weer start is mijn aeotec gen5 stick dood. Enige wat dan helpt is de stick fysiek verwijderen en terug steken. Hass starten en alles ok.

Linux? Werkt een sofwarematige reset van de USB poort niet, via het device (voorbeeldje)? Dat is ook geen oplossing maar scheelt lichaamsbeweging

[UltraSub]

ANdrode schreef op zondag 22 januari 2017 @ 15:44:
[...]


Linux? Werkt een sofwarematige reset van de USB poort niet, via het device (voorbeeldje)? Dat is ook geen oplossing maar scheelt lichaamsbeweging

Hmm, eigenlijk best een goed idee
Straks eens proberen.

/edit
Damn, dat werkt helaas niet. Reset commando blijft tot in de lengte der dagen hangen. Bummer.

[ Voor 11% gewijzigd door UltraSub op 22-01-2017 17:06 ]

[ANdrode]

UltraSub schreef op zondag 22 januari 2017 @ 16:49:
[...]
/edit
Damn, dat werkt helaas niet. Reset commando blijft tot in de lengte der dagen hangen. Bummer.

Ik weet niet of dat script klopt hoor . Maar het kan natuurlijk zo zijn dat de stick in een compleet verkeerde interne staat terecht komt.

Wat het linux commando doet is volgens mij alleen het herinitialiseren van de linux kant van het verhaal. Zie kernel log (dmesg uitvoer)

[UltraSub]

ANdrode schreef op zondag 22 januari 2017 @ 20:00:
[...]


Ik weet niet of dat script klopt hoor . Maar het kan natuurlijk zo zijn dat de stick in een compleet verkeerde interne staat terecht komt.

Wat het linux commando doet is volgens mij alleen het herinitialiseren van de linux kant van het verhaal. Zie kernel log (dmesg uitvoer)

Ik voer niet zomaar iets uit natuurlijk, heb er wat print statements in gezet eerst. Volgens mij zou het moeten werken, heb echter niet de pip open getrokken om echt alles door te lopen. Ik ga er vanuit dat .reset() ook daadwerkelijk een reset uit voert.
To be continued

[KirovAir]

Voor de mensen met een el cheapo rf-link transceiver; dit wip-component werkt voor mij als een zonnetje. Heb hass nu draaien met mijn bestaande kiku apparaten.
https://github.com/home-assistant/home-assistant/pull/4547

[PuckStar]

Voor wie veel zwave devices heeft is dit wellicht een interessant artikel: https://drzwave.wordpress...e-networks-for-consumers/

[UltraSub]

Zit wat te stoeien met rest switches. Besloten om mijn greenwave rommel op een eigen zwave netwerk te houden. Heb toch nog domoticz ernaast draaien, doet die maar lekker dat netwerk met al die timeouts
Dus Hass gaat zijn data daar maar halen, doe ik al een hele tijd voor de P1 data, werkt gewoon goed en betrouwbaar. Zelfde even gedaan voor een paar stroommetingen van greenwave dozen, en toen bedacht ik dat het ook wel handig zou zijn om een punt uit en aan te kunnen zetten. Wordt eigenlijk nooit gebruikt, maar hee, because we can, right.

https://home-assistant.io/components/switch.rest/

YAML:

- platform: rest
  name: Humax Decoder
  resource: http://x.x.x.x/json.htm?type=command&param=switchlight&idx=474&switchcmd=On
  body_on: ?
  body_off: ?
  username: !secret domoticz_user
  password: !secret domoticz_password
  authentication: basic

Nog niet getest, maar dat gaat natuurlijk niet werken zo. Hoe ga ik in dit geval om met body_on en body_off? Iemand een voorbeeld (weet dat er hier een aantal zitten die ook integreren met Domoticz, of dat hebben gedaan), dat scheelt me een hoop restarts waarschijnlijk

/edit
Hmm. Dat wordt sowieso shit. "is_on_template" vind ik wel nodig om de status ook echt te tracken, maar dat is voor Domoticz een andere url. Das wat we noemen niet echt handig, die api

[ Voor 9% gewijzigd door UltraSub op 25-01-2017 17:08 ]

[sjorsjes]

Ik heb ook een selfsigned certificate draaien van let's encrypt. Deze loopt inmiddels bijna af en wilde hem vernieuwen, maar toen kreeg ik deze errors. Iemand hier bekend mee?

Update command:

code:

./certbot-auto renew --quiet --no-self-upgrade --standalone --standalone-supported-challenges http-01

Repsonse:

code:

renewal config file {} is missing a required file reference
Renewal configuration file /etc/letsencrypt/renewal/<domeinnaam>.duckdns.org-0002.conf is broken. Skipping.
renewal config file {} is missing a required file reference
Renewal configuration file /etc/letsencrypt/renewal/<domeinnaam>.duckdns.org-0001.conf is broken. Skipping.
expected /etc/letsencrypt/live/<oude-domeinnaam>.duckdns.org/cert.pem to be a symlink
Renewal configuration file /etc/letsencrypt/renewal/<oude-domeinnaam>.duckdns.org.conf is broken. Skipping.
renewal config file {} is missing a required file reference
Renewal configuration file /etc/letsencrypt/renewal/<domeinnaam>.duckdns.org.conf is broken. Skipping.

[UltraSub]

@sjorsjes; kijk hier eens? Misschien kom je daar verder mee.

[sjorsjes]

Thx, ik zal vanavond eens checken!

[Yelti]

UltraSub schreef op woensdag 25 januari 2017 @ 16:14:
Zit wat te stoeien met rest switches. Besloten om mijn greenwave rommel op een eigen zwave netwerk te houden. Heb toch nog domoticz ernaast draaien, doet die maar lekker dat netwerk met al die timeouts
Dus Hass gaat zijn data daar maar halen, doe ik al een hele tijd voor de P1 data, werkt gewoon goed en betrouwbaar. Zelfde even gedaan voor een paar stroommetingen van greenwave dozen, en toen bedacht ik dat het ook wel handig zou zijn om een punt uit en aan te kunnen zetten. Wordt eigenlijk nooit gebruikt, maar hee, because we can, right.

https://home-assistant.io/components/switch.rest/

YAML:

- platform: rest
  name: Humax Decoder
  resource: http://x.x.x.x/json.htm?type=command&param=switchlight&idx=474&switchcmd=On
  body_on: ?
  body_off: ?
  username: !secret domoticz_user
  password: !secret domoticz_password
  authentication: basic

Nog niet getest, maar dat gaat natuurlijk niet werken zo. Hoe ga ik in dit geval om met body_on en body_off? Iemand een voorbeeld (weet dat er hier een aantal zitten die ook integreren met Domoticz, of dat hebben gedaan), dat scheelt me een hoop restarts waarschijnlijk

/edit
Hmm. Dat wordt sowieso shit. "is_on_template" vind ik wel nodig om de status ook echt te tracken, maar dat is voor Domoticz een andere url. Das wat we noemen niet echt handig, die api

Ben wel benieuwd naar je code als je het werkende hebt.

[UltraSub]

Yelti schreef op maandag 30 januari 2017 @ 09:22:
[...]


Ben wel benieuwd naar je code als je het werkende hebt.

Ik post zeker als ik het werkend heb, maar al lang niks meer aan gedaan. Geen tijd, en als ik tijd heb heb ik geen zin, enz

[sjorsjes]

UltraSub schreef op woensdag 25 januari 2017 @ 17:10:
@sjorsjes; kijk hier eens? Misschien kom je daar verder mee.

Bleek kwestie te zijn dat er geen rechten waren om /etc/letsencrypt/renewal te lezen

[wmn79]

PuckStar schreef op donderdag 5 januari 2017 @ 12:30:
[...]
Gisteren bezig geweest om te zorgen dat als ik mijn HUE dimmer knopjes indruk er ook nog iets anders aan/uit gaat via HASS. Erg leuk/handig .
Nu kan ik met de HUE dimmer Aan knop ook gelijk een lamp die op de kaku zit aangesloten aan laten gaan.

Kan je eens uitleggen hoe je dat gedaan hebt? Lijkt mij ook wel interessant nl om te gaan gebruiken.

[Fonta]

wmn79 schreef op woensdag 1 februari 2017 @ 01:33:
[...]

Kan je eens uitleggen hoe je dat gedaan hebt? Lijkt mij ook wel interessant nl om te gaan gebruiken.

Kan je simpelweg doen met een stukje automation met een trigger op een state change.
https://home-assistant.io/getting-started/automation/

[PuckStar]

wmn79 schreef op woensdag 1 februari 2017 @ 01:33:
[...]

Kan je eens uitleggen hoe je dat gedaan hebt? Lijkt mij ook wel interessant nl om te gaan gebruiken.

Dat kan ook echter dan gebeurd het ook als je bijvoorbeeld een andere automation je lampen aan laat gaan.
Als je alleen automation wilt wanneer daadwerkelijk een knop op de dimmer is ingedrukt zul je daar een trigger op moeten zetten.

De sensor (/6 moet natuurlijk het id zijn van jouw dimmer):

YAML:

- platform: rest
  resource: http://192.168.1.xx/api/YOUR-API-KEY/sensors/6
  value_template: '{{ value_json.state.buttonevent }}'
  name: 'Hue Dimmer On'
  scan_interval: 2

En de trigger voor On:

YAML:

  trigger:
  - platform: state
    entity_id: sensor.hue_dimmer_on
    to: "1002"

en Off was volgens mij 2002 of misschien 1000. Moet je effe nakijken.
En bij action kun je natuurlijk doen wat je zelf wilt.

Trouwens met de All4HUE app heb ik ook 2 zaken extra ingesteld:
1) Als ik de Dimmer op Off druk gaan zowel de woonkamer als tuinlampen uit (in tegenstelling tot dat je binnen Hue zelf maar 1 ruimte kunt selecteren voor Aan/Uit). Bij On gaan alleen de woonkamer lampen aan.
2) Als ik de Dimmer op Off druk duurt het 8 seconden voordat de lampen echt uitgaan. Dan heb ik nog tijd om bij de gang te komen terwijl het licht is (dimmer zit niet bij de deur).

En misschien vind iemand dit ook nog interessant:
Heel soms zet iemand op de overloop toch even hard via de knop de lamp aan (terwijl die normaal gesproken via een sensor gaat), in dat geval gaat de lamp dus op full brightness aan.
Deze automation zet hem dan snel weer minder fel (en ook weer uit na 1 minuut):

YAML:

- alias: 'Overloop Ging Hard aan'
  trigger:
  - platform: numeric_state
    entity_id: light.hue_white_lamp_4
    value_template: '{{ state.attributes.brightness }}'
    above: 253
  action:
    - service: light.turn_on
      data: 
        entity_id: light.hue_white_lamp_4
        color_temp: 353
        brightness: 1
    - delay:
        minutes: 1
    - service: light.turn_off
      data: 
        entity_id: light.hue_white_lamp_4

[ThinkPad]

De blog van Nicky is ook wel interessant om bijv. een Hue motion sensor in HASS te krijgen: Nicky's TweakBlog: Home Assistant: Philips Hue Motion Sensor

Werkt perfect, ik heb twee Hue motion sensors in gebruik en heb m'n Z-Wave bewegingssensoren weggedaan.

[PuckStar]

ThinkPadd schreef op woensdag 1 februari 2017 @ 16:05:
De blog van Nicky is ook wel interessant om bijv. een Hue motion sensor in HASS te krijgen: Nicky's TweakBlog: Home Assistant: Philips Hue Motion Sensor

Werkt perfect, ik heb twee Hue motion sensors in gebruik en heb m'n Z-Wave bewegingssensoren weggedaan.

Yes! En ik had die vertaald (en nog wat aangepast) en op de community site gezet alwaar je ook weer vragen/tips van anderen kunt vinden (zoals batterij status in Hass laten zien).
https://community.home-as...-lux-temp-and-motion/5532

[ThinkPad]

Batterijniveau is wel leuk ja, die heb ik nu nog niet. Kan ik daar gelijk een notify op zetten als ze bijna leeg zijn.

[Crp]

Heeft er iemand ervaring met Home Assistant op een Synology NAS (DS214play).
https://home-assistant.io...ed/installation-synology/

Ik heb tutorial gevolgd van de website, en ik denk dat het allemaal gelukt is. Alleen krijg ik bij het starten van de service een error. bij het uitvoeren van de commando:
"$ sudo /volume1/homeassistant/hass-daemon start"

Krijg ik terug: "sudo: unable to execute /volume1/homeassistant/hass-daemon: No such file or directory"
De hass-daemon file staat in de directory en alles is aanwezig wat in deze script staat.

[UltraSub]

Niet doen. Zoiets hoort op een eigen afgezonderd ding. Je vraagt erom uiteindelijk gedonder te krijgen. Koop een rasp. Doet 3W. op deze manier wordt je afhankelijk van iemand die aan het packagen is, en daarnaast, straks komt er een syno update of een andere app en die helpt de boel vakkundig om zeep. Zit je dan, met lampen die het niet meer doen of zo
Echt niet. Snap niet dat mensen dit doen. Tenzij het een container is op die syno, dan is het geïsoleerd, maar dan nog zou ik dat draaien als platform wat 90% van de mensen draait vanwege support, tot je goed bekend bent met hoe dingen werken.

[Crp]

UltraSub schreef op woensdag 1 februari 2017 @ 18:42:
Niet doen. Zoiets hoort op een eigen afgezonderd ding. Je vraagt erom uiteindelijk gedonder te krijgen. Koop een rasp. Doet 3W. op deze manier wordt je afhankelijk van iemand die aan het packagen is, en daarnaast, straks komt er een syno update of een andere app en die helpt de boel vakkundig om zeep. Zit je dan, met lampen die het niet meer doen of zo
Echt niet. Snap niet dat mensen dit doen. Tenzij het een container is op die syno, dan is het geïsoleerd, maar dan nog zou ik dat draaien als platform wat 90% van de mensen draait vanwege support, tot je goed bekend bent met hoe dingen werken.

Ja als dit niet lukt dan ga ik het ook op een Rpi gedaan. Ik wilde gewoon voorkomen een 2de apparaat te moeten hebben als mn Nas het op de achtergrond kan draaien. Je kan nog wel eens gelijk hebben over dat een DSM update alles om zeep gaat helpen.Ik had dit graag ook in Docker gedaan maar jammer genoeg ondersteund mijn NAS dat niet. Ik dacht dat de support ook wel beter zou zijn, totdat ik tegen dit probleem aanliep en ik er maar 2 forumposts over kon vinden die DSM gerelateerd waren en ook niet echt een oplossing boden. Ik ga het denk ik afbreken en verder op een Rpi.

Toch hoop ik er nog wel achter te komen wat het probleem nu is, als is het gewoon uit nieuwsgierigheid

[wmn79]

PuckStar schreef op woensdag 1 februari 2017 @ 15:29:
[...]

Dat kan ook echter dan gebeurd het ook als je bijvoorbeeld een andere automation je lampen aan laat gaan.
Als je alleen automation wilt wanneer daadwerkelijk een knop op de dimmer is ingedrukt zul je daar een trigger op moeten zetten.

De sensor (/6 moet natuurlijk het id zijn van jouw dimmer):

YAML:

- platform: rest
  resource: http://192.168.1.xx/api/YOUR-API-KEY/sensors/6
  value_template: '{{ value_json.state.buttonevent }}'
  name: 'Hue Dimmer On'
  scan_interval: 2

En de trigger voor On:

YAML:

  trigger:
  - platform: state
    entity_id: sensor.hue_dimmer_on
    to: "1002"

en Off was volgens mij 2002 of misschien 1000. Moet je effe nakijken.
En bij action kun je natuurlijk doen wat je zelf wilt.

Trouwens met de All4HUE app heb ik ook 2 zaken extra ingesteld:
1) Als ik de Dimmer op Off druk gaan zowel de woonkamer als tuinlampen uit (in tegenstelling tot dat je binnen Hue zelf maar 1 ruimte kunt selecteren voor Aan/Uit). Bij On gaan alleen de woonkamer lampen aan.
2) Als ik de Dimmer op Off druk duurt het 8 seconden voordat de lampen echt uitgaan. Dan heb ik nog tijd om bij de gang te komen terwijl het licht is (dimmer zit niet bij de deur).

Top dank je wel, had al wel op basis van de state van de lampen geprobeerd meerdere kamers aan te zetten maar daar zat nogal vertraging in door de polling interval. Nu kan ik hem bijvoorbeeld ook als switch gaan gebruiken als we naar bed gaan en dus van veel de stroom eraf mag. Vanavond maar even puzzelen.

edit: Off is bij mij 4002

[ Voor 19% gewijzigd door wmn79 op 01-02-2017 20:59 ]

[UltraSub]

Crp schreef op woensdag 1 februari 2017 @ 20:30:
[...]


Ja als dit niet lukt dan ga ik het ook op een Rpi gedaan. Ik wilde gewoon voorkomen een 2de apparaat te moeten hebben als mn Nas het op de achtergrond kan draaien. Je kan nog wel eens gelijk hebben over dat een DSM update alles om zeep gaat helpen.Ik had dit graag ook in Docker gedaan maar jammer genoeg ondersteund mijn NAS dat niet. Ik dacht dat de support ook wel beter zou zijn, totdat ik tegen dit probleem aanliep en ik er maar 2 forumposts over kon vinden die DSM gerelateerd waren en ook niet echt een oplossing boden. Ik ga het denk ik afbreken en verder op een Rpi.

Toch hoop ik er nog wel achter te komen wat het probleem nu is, als is het gewoon uit nieuwsgierigheid

Goede insteek

[wmn79]

Even een korte vraag: kan ik in plaats van dit

YAML:

trigger:
  platform: sun
  event: sunset
  offset: "-00:15:00"
condition:
  condition: state
  entity_id: group.lichten
  state: 'off'
action:
  - service: light.hue_activate_scene
    data:
      group_name: "Woonkamer"
      scene_name: "Helder"
  - service: light.hue_activate_scene
    data:
      group_name: "Eetkamer"
      scene_name: "Helder"
  - service: light.hue_activate_scene
    data:
      group_name: "Keuken"
      scene_name: "Volle sterkte"

Ook dit gebruiken?

YAML:

trigger:
  platform: sun
  event: sunset
  offset: "-00:15:00"
condition:
  condition: state
  entity_id: group.lichten
  state: 'off'
action:
  - service: light.hue_activate_scene
    data:
      group_name: 
        - "Woonkamer" 
        - "Eetkamer"
      scene_name: "Helder"
  
  - service: light.hue_activate_scene
    data:
      group_name: "Keuken"
      scene_name: "Volle sterkte"

Of kan het nog efficiënter?

[PuckStar]

Welke fysieke (zwave?) knop gebruiken jullie om je alarm mee aan/uit te zetten?

[tyfoon_2]

PuckStar schreef op maandag 6 februari 2017 @ 17:51:
Welke fysieke (zwave?) knop gebruiken jullie om je alarm mee aan/uit te zetten?

Ik doe dat met de RFID tag reader: http://www.hashop.nl/Zipato-Mini-RFiD-Keypad

[tyfoon_2]

PuckStar schreef op woensdag 1 februari 2017 @ 15:29:

YAML:

- alias: 'Overloop Ging Hard aan'
  trigger:
  - platform: numeric_state
    entity_id: light.hue_white_lamp_4
    value_template: '{{ state.attributes.brightness }}'
    above: 253

Het is mij nog nooit gelukt om een value_template succesvol te gebruiken als trigger. Mijn workaround is altijd er een (binary) sensor van te maken en die op state te testen. Je weet zeker dat deze goed werkt?

[PuckStar]

tyfoon_2 schreef op dinsdag 7 februari 2017 @ 12:52:
[...]


Het is mij nog nooit gelukt om een value_template succesvol te gebruiken als trigger. Mijn workaround is altijd er een (binary) sensor van te maken en die op state te testen. Je weet zeker dat deze goed werkt?

Het werkt 100% maar het kan wel zo'n 5 a 10 seconden duren voordat HUE en HASS doorhebben dat de lamp er weer is (want als je die uitzette was hij dus helemaal uit het netwerk) en dus naar brightness 1 gaat.

[lolgast]

Sinds dit weekend ook begonnen met Home Assistant. Ik kom van Pimatic, dus het is nogal een ommezwaai. Pimatic blijft voorlopig wel draaien, wil stukje bij beetje Z-Wave spullen kopen om de KAKU te vervangen.

Nu ben ik begonnen met een dimmer op een plek waar nog geen domotica zat. Gekozen voor een Fibaro Dimmer 2, de FGD212. Nu heb ik hier twee vragen over. De dimmer zit als volgt aangesloten:

^Klikbaar
S1 zit dus op schakelaar 1, S2 zit op schakelaar 2. Sx heb ik gesplitst en naar elke schakelaar een kabel. Vond ik logisch . Het probleem: S1 schakelt de lamp en werkt als een tiet. Signaal komt netjes aan bij HASS. S2 doet helemaal niets . Nul,nul signaal. Ook als ik S2 verbind met de Sx van schakelaar 1 gebeurd er niets. S1 verbinden met Sx van schakelaar 2 schakelt ook de lamp. Geen kabelbreuk in Sx is. Heb de kabel van S2 al een keer vervangen, maar niets.

Opzich kan ik hier mee leven, het was een nice to have, maar ik vind het wel vreemd. Als er een oplossing is zou het mooi zijn

Doh! Bedankt @Kroontje , Het staat inmiddels aan. Was dus optie 26

code:

Node003, Value::Set - COMMAND_CLASS_CONFIGURATION - The function of 3-way switch - 26 - 1 - 3-way switch function for S2 enabled

Andere probleem: Mijn lampen knipperen af en toe sinds deze dimmer. Hiervoor gebruikte ik een dimmer van Gira zelf op de lampen en dat ging perfect. Er zitten 3 halogeen lampen van 42Watt p/s achter, dus dat zou het probleem niet moeten zijn. Als ik de dimmer op meer dan 50% zet is het knipperen over. Zou ik hiervoor een Fibaro bypass moeten aanschaffen? Heb zelf niet het idee dat het door de lampen komt eigenlijk maar zeker ook vanwege probleem 1 twijfel ik over de dimmer..

[ Voor 5% gewijzigd door lolgast op 08-02-2017 10:07 ]

[Kroontje]

lolgast schreef op woensdag 8 februari 2017 @ 09:12:
Sinds dit weekend ook begonnen met Home Assistant. Ik kom van Pimatic, dus het is nogal een ommezwaai. Pimatic blijft voorlopig wel draaien, wil stukje bij beetje Z-Wave spullen kopen om de KAKU te vervangen.

Nu ben ik begonnen met een dimmer op een plek waar nog geen domotica zat. Gekozen voor een Fibaro Dimmer 2, de FGD212. Nu heb ik hier twee vragen over. De dimmer zit als volgt aangesloten:
[afbeelding]
^Klikbaar
S1 zit dus op schakelaar 1, S2 zit op schakelaar 2. Sx heb ik gesplitst en naar elke schakelaar een kabel. Vond ik logisch . Het probleem: S1 schakelt de lamp en werkt als een tiet. Signaal komt netjes aan bij HASS. S2 doet helemaal niets . Nul,nul signaal. Ook als ik S2 verbind met de Sx van schakelaar 1 gebeurd er niets. S1 verbinden met Sx van schakelaar 2 schakelt ook de lamp. Geen kabelbreuk in Sx is. Heb de kabel van S2 al een keer vervangen, maar niets.

Opzich kan ik hier mee leven, het was een nice to have, maar ik vind het wel vreemd. Als er een oplossing is zou het mooi zijn

Andere probleem: Mijn lampen knipperen af en toe sinds deze dimmer. Hiervoor gebruikte ik een dimmer van Gira zelf op de lampen en dat ging perfect. Er zitten 3 halogeen lampen van 42Watt p/s achter, dus dat zou het probleem niet moeten zijn. Als ik de dimmer op meer dan 50% zet is het knipperen over. Zou ik hiervoor een Fibaro bypass moeten aanschaffen? Heb zelf niet het idee dat het door de lampen komt eigenlijk maar zeker ook vanwege probleem 1 twijfel ik over de dimmer..

De S2 dien je te activeren in de parameters van de dimmer dacht ik, advanced parameter 28 volgens de manual.

Andere probleem: Mijn lampen knipperen af en toe sinds deze dimmer. Hiervoor gebruikte ik een dimmer van Gira zelf op de lampen en dat ging perfect. Er zitten 3 halogeen lampen van 42Watt p/s achter, dus dat zou het probleem niet moeten zijn. Als ik de dimmer op meer dan 50% zet is het knipperen over. Zou ik hiervoor een Fibaro bypass moeten aanschaffen? Heb zelf niet het idee dat het door de lampen komt eigenlijk maar zeker ook vanwege probleem 1 twijfel ik over de dimmer..

Die issues ervaar ik niet, niet met LED of met halogeen. Heb je auto-calibration al eens uitgevoerd? Parameter 13

Die bypass is voor zover ik weet voor laag wattage LED verlichting..

[ Voor 15% gewijzigd door Kroontje op 08-02-2017 10:11 ]

[lolgast]

Kroontje schreef op woensdag 8 februari 2017 @ 09:48:
[...]

De S2 dien je te activeren in de parameters van de dimmer dacht ik, advanced parameter 28 volgens de manual.


[...]

Die issues ervaar ik niet, niet met LED of met halogeen. Heb je auto-calibration al eens uitgevoerd? Parameter 13

Die bypass is voor zover ik weet voor laag wattage LED verlichting..

Bedankt voor het meedenken!
Auto calibration is twee keer uitgevoerd. De eerste keer na aansluiten en de tweede keer heb ik gisteravond nog gedaan omdat ik de knipper problemen heb. Hij heeft wel waardes aangepast na de laatste keer, maar het probleem blijft.

Het vervelende/verwarrende is dat het niet continu is. Nu ik er over nadenk, het zou misschien ripple-control kunnen zijn.. Zal vanavond eens wat beter opletten. Mijn vriendin viel het gisteren op dat het op hetzelfde moment als inschakelen straatverlichting was namelijk

[ThinkPad]

lolgast schreef op woensdag 8 februari 2017 @ 10:29:
[...]
Mijn vriendin viel het gisteren op dat het op hetzelfde moment als inschakelen straatverlichting was namelijk

Flikkerende LED lampen tijdens TF/CAB (daltarief) signaal

[lolgast]

ThinkPadd schreef op woensdag 8 februari 2017 @ 10:32:
[...]

Flikkerende LED lampen tijdens TF/CAB (daltarief) signaal

Ik had er inmiddels ook aan gedacht ja. Zou toch wel een tegenvaller zijn, want dat ga ik natuurlijk niet aan mijn vriendin uitgelegd krijgen

Ik kan nog testen om de dimmer zonder nuldraad aan te sluiten, maar daar verwacht ik niet veel van.

[Yelti]

lolgast schreef op woensdag 8 februari 2017 @ 11:16:
[...]

Ik had er inmiddels ook aan gedacht ja. Zou toch wel een tegenvaller zijn, want dat ga ik natuurlijk niet aan mijn vriendin uitgelegd krijgen

Ik kan nog testen om de dimmer zonder nuldraad aan te sluiten, maar daar verwacht ik niet veel van.

Ik heb hetzelfde voor met de fibaro.
Echter geen problemen met een qubino dimmer.

[PuckStar]

Yelti schreef op donderdag 9 februari 2017 @ 10:45:
[...]

Ik heb hetzelfde voor met de fibaro.
Echter geen problemen met een qubino dimmer.

Met de qubino dimmer heb je wel 3 draden nodig toch?

[Yelti]

PuckStar schreef op donderdag 9 februari 2017 @ 10:47:
[...]

Met de qubino dimmer heb je wel 3 draden nodig toch?

Yep, idd 3 draden nodig.

Maar dat lijkt me in de meeste gevallen geen probleem.

[PuckStar]

Yelti schreef op donderdag 9 februari 2017 @ 11:18:
[...]

Yep, idd 3 draden nodig.

Maar dat lijkt me in de meeste gevallen geen probleem.

nou bij oudere huizen wel hoor. ik heb er overal maar 2 .

[Yelti]

PuckStar schreef op donderdag 9 februari 2017 @ 11:43:
[...]

nou bij oudere huizen wel hoor. ik heb er overal maar 2 .

Komen je stroomtoever (2 draden) en je lamp(2draden) toe in dezelfde inbouwdoos?
Dan is gemakkelijk om dit aan te passen, indien niet begrijp ik je wel.

Voor mij is de qubino de betere dimmer tov de fibaro (op zwave security klasse na dan).

[lolgast]

Hmm nu maak je me aan het twijfelen om toch een Qubino te proberen. Ik had eigenlijk bedacht om maar Hue lampen in de dim-lamp te gooien. Die zijn er blijkbaar niet gevoelig voor. Over die Qubino had ik ook al negatieve verhalen gelezen m.b.t. TF

Edit: Met of zonder nuldraad maakt geen verschil bij mij trouwens. Heb ook nog een hercalibratie met 1 lamp gedaan en daarna de rest erin gedraaid, ook geen verschil

[ Voor 25% gewijzigd door lolgast op 09-02-2017 12:32 ]

[Yelti]

lolgast schreef op donderdag 9 februari 2017 @ 12:02:
Hmm nu maak je me aan het twijfelen om toch een Qubino te proberen. Ik had eigenlijk bedacht om maar Hue lampen in de dim-lamp te gooien. Die zijn er blijkbaar niet gevoelig voor. Over die Qubino had ik ook al negatieve verhalen gelezen m.b.t. TF

Edit: Met of zonder nuldraad maakt geen verschil bij mij trouwens. Heb ook nog een hercalibratie met 1 lamp gedaan en daarna de rest erin gedraaid, ook geen verschil

Wat bedoel je met TF?

[lolgast]

Yelti schreef op donderdag 9 februari 2017 @ 12:53:
[...]

Wat bedoel je met TF?

ToonFrequent. Het signaal van de netbeheerder waardoor de lampen knipperen.

[UltraSub]

Yelti schreef op donderdag 9 februari 2017 @ 11:18:
[...]

Yep, idd 3 draden nodig.

Maar dat lijkt me in de meeste gevallen geen probleem.

Ook in een nieuwer huis is dat niet echt leuk om te doen hoor. Heb van het meeste foto's, maar toch zijn er dozen waarin ik het niet zomaar geregeld krijg om daar een blauwe draad bij te krijgen.

[Yelti]

UltraSub schreef op donderdag 9 februari 2017 @ 14:25:
[...]

Ook in een nieuwer huis is dat niet echt leuk om te doen hoor. Heb van het meeste foto's, maar toch zijn er dozen waarin ik het niet zomaar geregeld krijg om daar een blauwe draad bij te krijgen.

Bij mij is het zo:

Op 1 plaats na komt de L en de N draad toe in de lasdoos.
Vandaaruit vertrekt er ook een kabel naar de lamp toe( ook L en N).
Hiermee is het perfect mogelijk om het 3 draadsprincipe te gebruiken, mits de nodige lasklemmen.

In het andere geval is het meestal mogelijk om het 3-draads principe te implementeren mits bekabeling in/aan de lamp aan te passen, uiteindelijk komt daar altijd een L en N draad toe waarbij 1 onderbroken wordt.
Je kan misschien ook je dimmer in/aan de lamp plaatsten.

Ik ben geen profesionele electricien, dus kan er naast zitten.

[lolgast]

Inhoudelijke HASS vraag, voor de verandering:
Ik vind de ingebakken Denon/Marantz module niet erg prettig, plus ik ben maar in een paar dingen geïnteresseerd dus ik bouw het zelf wel. Ik loop alleen tegen 1 probleem aan . Ik heb een input_select gemaakt waarmee ik de receiver wil in-/uitschakelen. Het zou natuurlijk mooi zijn als dit veld automatisch de daadwerkelijke status overneemt wanneer de receiver met hand bedient wordt. Dat is gelukt, zie hieronder voor de code.

Input_Select

YAML:

marantz_power:
  name: Marantz Power
  options:
   - Aan
   - Uit
  icon: mdi:power

Sensor die de status ophaalt

YAML:

- platform: command_line
  command: curl -s http://192.168.0.4/goform/formMainZone_MainZoneXmlStatusLite.xml | awk -F '[<>]'  '/Power/{print $5}'
  name: 'Marantz Power'

Code om status te vertalen naar de Input_Select

YAML:

alias: 007 - Marantz Power Sync
#hide_entity: True
trigger:
  platform: state
  entity_id: sensor.marantz_power
action:
  service: input_select.select_option
  entity_id: input_select.marantz_power
  data_template:
    option: >
      {% if is_state('sensor.marantz_power', 'ON') %}
        Aan
      {% elif is_state('sensor.marantz_power', 'OFF') %}
        Uit
      {% endif %}

Voor de volledigheid ook automation script gemaakt die de receiver respectivelijk aan of uit zetten als het Input_Select gebruikt wordt. Tot zo ver dus een gelukkig mens. Máár, als HASS herstart wordt krijg het Input_Select automagisch de eerste optie, niet de laatst onthouden optie. En omdat de sensor niet wijzigt wordt de automation trigger niet afgeschoten, waardoor de sensor dus op OFF staat maar de Input_Select gezellig op Aan. Nadeel hiervan is dat ik hem dus zogenaamd eerst uit moet zetten voordat hij weer aan kan.

Hier komt de daadwerkelijk vraag: Kan ik de sensor op een soort $NULL stand forceren bij een herstart van HASS?

---

Edit: Ik lees nu net over MQTT, ik denk dat dat in ieder geval een oplossing kan zijn. Even kijken hoe dat werkt

[ Voor 3% gewijzigd door lolgast op 09-02-2017 23:03 ]

[UltraSub]

Publish op mqtt met retain. Bij een hass restart subscribed de sensor opnieuw en krijgt dan meteen de laatste message gepushed van de bus in dat topic.

Overigens, ik gebruik denon_avr en die werkt best goed en snel moet ik zeggen.

[ny-hardcore]

Shameless self plug, 3-axis remote control.
6 vlakken te koppelen aan een actie in hass.

YouTube: Mysensors 3-axis remote control.

https://community.home-as...od-cube-magic-cube/9965/8

[ Voor 3% gewijzigd door ny-hardcore op 09-02-2017 22:27 ]

[lolgast]

UltraSub schreef op donderdag 9 februari 2017 @ 20:00:
Publish op mqtt met retain. Bij een hass restart subscribed de sensor opnieuw en krijgt dan meteen de laatste message gepushed van de bus in dat topic.

Overigens, ik gebruik denon_avr en die werkt best goed en snel moet ik zeggen.

Thanks, zal van het weekend eens in dat MQTT duiken. Zag al dat het meer tijd ging kosten dan 'even gauw instellen'.

De problemen met de knipperende lampen zijn opgelost, heb inderdaad maar gewoon Hue lampen gehaald. Dacht mooi de fibaro dimmer in scene mode (optie 28) te zetten zodat de stroom niet uitgeschakeld wordt als de schakelaar gebruikt wordt, maar zo makkelijk is het natuurlijk weer niet.....
Morgen de schakeldraad maar uit de fibaro halen in de hoop dat hij dan gewoon alleen z-wave signaal stuurt zonder zelf de stroomtoevoer naar de hue lampen te onderbreken.

[PuckStar]

PuckStar schreef op maandag 6 februari 2017 @ 17:51:
Welke fysieke (zwave?) knop gebruiken jullie om je alarm mee aan/uit te zetten?

Iemand anders nog ideeën tips?

[Yelti]

PuckStar schreef op vrijdag 10 februari 2017 @ 13:50:
[...]


Iemand anders nog ideeën tips?

Afhankelijk wat je nodig hebt:

Puur trigger

- fibaro button
- philio button
- verschillende plakschakelaars

Effectief hoog/laag schakelen van input

- Qubino 1d relay.

voor zover bij mij bekend.

[ Voor 25% gewijzigd door Yelti op 10-02-2017 14:02 ]

[PuckStar]

Yelti schreef op vrijdag 10 februari 2017 @ 13:57:
[...]


Je hebt verschillende mogelijkheden:
- fibaro button
- philio button
- verschillende plakschakelaars

JA zoiets begreeo ik , maar was dus benieuwd naar wat jullie precies gebruiken en of je er goeie ervaring mee hebt.
Ik zoek uiteraard goedkoop maar betrouwbaar.

[Yelti]

PuckStar schreef op vrijdag 10 februari 2017 @ 14:02:
[...]

JA zoiets begreeo ik , maar was dus benieuwd naar wat jullie precies gebruiken en of je er goeie ervaring mee hebt.
Ik zoek uiteraard goedkoop maar betrouwbaar.

Plakschakelaars van POPP vreten batterijen, dus raad ik af.
Ik denk dat de fibaro button(de rode:) ) het gemakkelijkste te integreren is.
Een plakschakelaar is eenvoudiger om meerdere zaken aan te koppelen.

Zeker controleren of deze door open z-wave ondersteund wordt.

[lolgast]

PuckStar schreef op vrijdag 10 februari 2017 @ 13:50:
[...]


Iemand anders nog ideeën tips?

Ik heb van de week een Aeon Labs minimote aangeschaft en aan HASS gekoppeld. Daar kun je 8 scenes mee bedienen, en hij is behoorlijk klein. Wellicht kun je daar wat mee? Of de nieuwe Fibaro KeyFob

---

Edit: Zonder schakeldraad doet de Fibaro Dimmer 2 het niet. Morgen als test de nuldraad verbinden op de plek van de schakeldraad in de hoop dat hij niet doorbrand. Kijken of hij dan wel schakelsignaal geeft. Of heeft iemand al ervaring?
Ik wil hem dus eigenlijk stand alone maken, zonder fysieke lamp erachter.

Edit2: De Dimmer 2 vervangen voor een Relay Switch 2x1.5. De Dimmer 2 blijkt altijd weerstand nodig te hebben om te functioneren, waardoor hij niet als domme draadloze schakelaar kan dienen. De Relay Switch kan dat wel. Nadeel van de Relay Switch is dat hij geen scenes heeft, alleen 2x ON en 2x OFF. Geen dubbelklik functie of iets in die trant

[ Voor 51% gewijzigd door lolgast op 11-02-2017 16:31 ]

[-LA-]

Voor de mensen met KlikAanKlikUit schakelaars/verlichting, 0.38.1 is gereleased met RFLink support. Werkt subliem

[lolgast]

Thx, net meteen bijgewerkt!

Zit wel een beetje in twijfel of ik de software voor de 433MHz support op deze pi ga uitrollen, of dat ik de koppeling naar Pimatic laat bestaan tot alle KAKU spullen zijn vervangen. Dat gaat geen maanden duren denk ik en ben bang dat het fout gaat en ik HASS opnieuw moet installeren

[HaTe]

Meer mensen last van dat de states en services "Dev-Tools" paginas niet meer laden in de web interface met de nieuwe versie 0.38.1?
Heb net al 0.37.1 geïnstalleerd, waar het wel weer werkt. Daarna toch maar weer 0.38.1 geprobeerd, maar hier laden ze toch echt niet!

[ Voor 42% gewijzigd door HaTe op 12-02-2017 23:49 ]

[PuckStar]

Weet iemand hoe ik een condition op NOT kan hebben?

Ik wil eigenlijk het volgende, waarbij IS NOT ik zelf even heb getypt maar dus (naar mijn weten) niet zo werkt.
- condition: state
entity_id: media_player.tv_lukas__sascha
state IS NOT: 'playing'

[Fonta]

-LA- schreef op zondag 12 februari 2017 @ 17:01:
Voor de mensen met KlikAanKlikUit schakelaars/verlichting, 0.38.1 is gereleased met RFLink support. Werkt subliem

Kan je RFLink gebruiken icm een rfxtrx module?

PuckStar schreef op zondag 12 februari 2017 @ 23:34:
Weet iemand hoe ik een condition op NOT kan hebben?

Ik wil eigenlijk het volgende, waarbij IS NOT ik zelf even heb getypt maar dus (naar mijn weten) niet zo werkt.
- condition: state
entity_id: media_player.tv_lukas__sascha
state IS NOT: 'playing'

Wat is de status als hij niet aan het spelen is? Kan je die status niet gebruiken?

[ Voor 46% gewijzigd door Fonta op 12-02-2017 23:50 ]

[UltraSub]

HaTe schreef op zondag 12 februari 2017 @ 22:41:
Meer mensen last van dat de states en services "Dev-Tools" paginas niet meer laden in de web interface met de nieuwe versie 0.38.1?
Heb net al 0.37.1 geïnstalleerd, waar het wel weer werkt. Daarna toch maar weer 0.38.1 geprobeerd, maar hier laden ze toch echt niet!

Browser cache. Hier zelfde gehad. Op de mac was het gewoon een reload waarna ik geprompt werd voor mijn api password. Daarna werkte het.

[Verwijderd]

PuckStar schreef op zondag 12 februari 2017 @ 23:34:
Weet iemand hoe ik een condition op NOT kan hebben?

Ik wil eigenlijk het volgende, waarbij IS NOT ik zelf even heb getypt maar dus (naar mijn weten) niet zo werkt.
- condition: state
entity_id: media_player.tv_lukas__sascha
state IS NOT: 'playing'

Door een NOT conditie toe te voegen, waarin je de playing conditie zet. De NOT zit op het zelfde niveau als AND en OR.

[lolgast]

PuckStar schreef op zondag 12 februari 2017 @ 23:34:
Weet iemand hoe ik een condition op NOT kan hebben?

Ik wil eigenlijk het volgende, waarbij IS NOT ik zelf even heb getypt maar dus (naar mijn weten) niet zo werkt.
- condition: state
entity_id: media_player.tv_lukas__sascha
state IS NOT: 'playing'

Je zou een template kunnen gebruiken in de condition. Als die waarde false is voert hij hem ook niet uit.

---

Ik zit ook met een raadsel. Onderstaande zorgt ervoor dat de verlichting aangaat, dus dat is mooi. Ik merkte van de week tijdens het testen al dat de verlichting aan sprong als ik hem uit zette dus ik heb de condition ingebouwd. Vannacht om 3 uur echter stond de verlichting alsnog aan...

YAML:

alias: Tuinverlichting Zonsondergang
trigger:
  platform: state
  entity_id: sun.sun
  state: below_horizon
condition:
  condition: time
  before: '22:00:00'
action:
  service: switch.turn_on
  entity_id: switch.pimatic_verlichting_tuin

Maar eerste gevoel zegt dat dit komt omdat het na 0:00 weer vóór 22:00 uur is. Wat theoretisch ook klopt natuurlijk. Ik wil echter proberen te voorkomen te veel statische gegevens in te moeten voeren.
Een andere oorzaak zou kunnen zijn dat de trigger state naar to moet. Iemand die met de goede richting in kan helpen

@Thinkpad: Sorry my bad, ik zet de verlichting met de hand uit als ik naar bed ga. Die bepaal ik dus zelf

[ Voor 24% gewijzigd door lolgast op 13-02-2017 08:22 ]

[ThinkPad]

Als dit je enige regel is voor de tuinverlichting, dan is het logisch dat het blijft branden. Je zegt op regel 10 namelijk alleen: switch.turn_on. Nergens zeg je dat het ook weer uit moet gaan. Je moet dus nog een regel maken waarmee je definieert wanneer het licht weer uit moet.

[Kroontje]

lolgast schreef op maandag 13 februari 2017 @ 08:17:
[...]

Je zou een template kunnen gebruiken in de condition. Als die waarde false is voert hij hem ook niet uit.

---

Ik zit ook met een raadsel. Onderstaande zorgt ervoor dat de verlichting aangaat, dus dat is mooi. Ik merkte van de week tijdens het testen al dat de verlichting aan sprong als ik hem uit zette dus ik heb de condition ingebouwd. Vannacht om 3 uur echter stond de verlichting alsnog aan...

YAML:

alias: Tuinverlichting Zonsondergang
trigger:
  platform: state
  entity_id: sun.sun
  state: below_horizon
condition:
  condition: time
  before: '22:00:00'
action:
  service: switch.turn_on
  entity_id: switch.pimatic_verlichting_tuin

Maar eerste gevoel zegt dat dit komt omdat het na 0:00 weer vóór 22:00 uur is. Wat theoretisch ook klopt natuurlijk. Ik wil echter proberen te voorkomen te veel statische gegevens in te moeten voeren.
Een andere oorzaak zou kunnen zijn dat de trigger state naar to moet. Iemand die met de goede richting in kan helpen

@Thinkpad: Sorry my bad, ik zet de verlichting met de hand uit als ik naar bed ga. Die bepaal ik dus zelf

En bijvoorbeeld zo?

code:

  trigger:
    platform: sun
    event: sunset
    offset: "-00:45:00"

Zie voorbeeld.

[lolgast]

Kroontje schreef op maandag 13 februari 2017 @ 08:38:
[...]

En bijvoorbeeld zo?

code:

  trigger:
    platform: sun
    event: sunset
    offset: "-00:45:00"

Zie voorbeeld.

Hmm dat klinkt eigenlijk wel logisch. Op die manier komt de trigger maar een keer voor, ipv gedurende de gehele sunset tijd zoals ik hem nu had ingesteld.
Heb het aangepast, gaan we het vanavond wel zien

[Yelti]

lolgast schreef op woensdag 8 februari 2017 @ 10:29:
[...]

Bedankt voor het meedenken!
Auto calibration is twee keer uitgevoerd. De eerste keer na aansluiten en de tweede keer heb ik gisteravond nog gedaan omdat ik de knipper problemen heb. Hij heeft wel waardes aangepast na de laatste keer, maar het probleem blijft.

Het vervelende/verwarrende is dat het niet continu is. Nu ik er over nadenk, het zou misschien ripple-control kunnen zijn.. Zal vanavond eens wat beter opletten. Mijn vriendin viel het gisteren op dat het op hetzelfde moment als inschakelen straatverlichting was namelijk

Misschien wat laat, maar er is een instelling bij de parameters die dit zou moeten tegengaan.
Dit weekend achtergekomen, maar niet getest.

[lolgast]

Yelti schreef op maandag 13 februari 2017 @ 09:25:
[...]
Misschien wat laat, maar er is een instelling bij de parameters die dit zou moeten tegengaan.
Dit weekend achtergekomen, maar niet getest.

Ik was teruggegaan naar de winkel inderdaad om even te overleggen en advies te vragen en daar gaf de medewerker ook aan dat hem iets bijstond dat er een instelling voor zou zijn, maar hij wist zo even niet welke.
Ben thuis aan de slag gegaan om even een test opstellinkje te maken met de Dimmer 2, maar heb gisteravond niet kunnen vinden welke instelling dat dan zou zijn.

^Klikbaar
Sowieso lukt het niet eens om de 2e schakelaar als aparte schakelaar te gebruiken. Heb de volgende parameters aangepast:

code:

20. Switch type - Toggle switch
26. The function of 3-way switch - 1 - 3-way switch function for S2 enabled
28. Scene activation functionality - 1 - functionality activated 
32. On/Off mode - 1 - on/off mode enabled (dimming is not possible)

Als ik switch 2 (op de foto nog niet aangesloten) omzet dan krijg ik een andere sceneID (die overeenkomt met de tabel van parameter 28 in de handleiding), maar in Home Assistant schakelt toch S1 . Ook gaat de lamp gewoon aan/uit.

[Yelti]

lolgast schreef op maandag 13 februari 2017 @ 09:38:
[...]

Ik was teruggegaan naar de winkel inderdaad om even te overleggen en advies te vragen en daar gaf de medewerker ook aan dat hem iets bijstond dat er een instelling voor zou zijn, maar hij wist zo even niet welke.
Ben thuis aan de slag gegaan om even een test opstellinkje te maken met de Dimmer 2, maar heb gisteravond niet kunnen vinden welke instelling dat dan zou zijn.
[afbeelding]
^Klikbaar
Sowieso lukt het niet eens om de 2e schakelaar als aparte schakelaar te gebruiken. Heb de volgende parameters aangepast:

code:

20. Switch type - Toggle switch
26. The function of 3-way switch - 1 - 3-way switch function for S2 enabled
28. Scene activation functionality - 1 - functionality activated 
32. On/Off mode - 1 - on/off mode enabled (dimming is not possible)

Als ik switch 2 (op de foto nog niet aangesloten) omzet dan krijg ik een andere sceneID (die overeenkomt met de tabel van parameter 28 in de handleiding), maar in Home Assistant schakelt toch S1 . Ook gaat de lamp gewoon aan/uit.

De parameter voor het flikkeren is 38.
Ivm het schakelen van de 2 inputs, dacht ik ooit gelezen te hebben dat je hem moet excluden en terug includen, maar ben niet 100% zeker.

[BROSSIE]

lolgast schreef op maandag 13 februari 2017 @ 08:17:
[...]

Je zou een template kunnen gebruiken in de condition. Als die waarde false is voert hij hem ook niet uit.

---

Ik zit ook met een raadsel. Onderstaande zorgt ervoor dat de verlichting aangaat, dus dat is mooi. Ik merkte van de week tijdens het testen al dat de verlichting aan sprong als ik hem uit zette dus ik heb de condition ingebouwd. Vannacht om 3 uur echter stond de verlichting alsnog aan...

YAML:

alias: Tuinverlichting Zonsondergang
trigger:
  platform: state
  entity_id: sun.sun
  state: below_horizon
condition:
  condition: time
  before: '22:00:00'
action:
  service: switch.turn_on
  entity_id: switch.pimatic_verlichting_tuin

Maar eerste gevoel zegt dat dit komt omdat het na 0:00 weer vóór 22:00 uur is. Wat theoretisch ook klopt natuurlijk. Ik wil echter proberen te voorkomen te veel statische gegevens in te moeten voeren.
Een andere oorzaak zou kunnen zijn dat de trigger state naar to moet. Iemand die met de goede richting in kan helpen

@Thinkpad: Sorry my bad, ik zet de verlichting met de hand uit als ik naar bed ga. Die bepaal ik dus zelf

Je zou bij je condition iets kunnen doen als:

YAML:

condition:
  condition: time
  before: '22:00:00'
  after: '16:00:00'

zie ook https://home-assistant.io...arted/scripts-conditions/ het laatste voorbeeld.

[lolgast]

Yelti schreef op maandag 13 februari 2017 @ 09:51:
[...]

De parameter voor het flikkeren is 38.
Ivm het schakelen van de 2 inputs, dacht ik ooit gelezen te hebben dat je hem moet excluden en terug includen, maar ben niet 100% zeker.

Thx, ik ga het vanavond proberen! Weet je toevallig ook of het inderdaad mogelijk is geen on/off signaal te versturen, of gaat dat automatisch met de S2 optie dadelijk?
Inmiddels zitten er namelijk Hue lampen in en die mogen niet zonder spanning staan..

BROSSIE schreef op maandag 13 februari 2017 @ 09:53:
[...]


Je zou bij je condition iets kunnen doen als:

YAML:

condition:
  condition: time
  before: '22:00:00'
  after: '16:00:00'

zie ook https://home-assistant.io...arted/scripts-conditions/ het laatste voorbeeld.

Bedankt, ik heb nu eerst de optie van Kroontje doorgevoerd, maar dit kan ook nog. Zoals aangegeven wil ik alleen voorkomen te veel fixed waardes in te stellen, want dan ga je een beetje voorbij aan het doel van de variabele sunset

[ Voor 38% gewijzigd door lolgast op 13-02-2017 10:27 ]

[Fonta]

lolgast schreef op maandag 13 februari 2017 @ 10:25:
[...]
Bedankt, ik heb nu eerst de optie van Kroontje doorgevoerd, maar dit kan ook nog. Zoals aangegeven wil ik alleen voorkomen te veel fixed waardes in te stellen, want dan ga je een beetje voorbij aan het doel van de variabele sunset

Als je variabel wilt, dan zal je 2 regels voor automation moeten aanmaken of een OR regel.
Op dit moment heb ik het als onderstaande gedaan omdat ik ook iets langer na zonsopkomst de trigger wou. (Al zou dit ook allemaal in een OR moeten kunnen.)

YAML:

alias: Turn on light hallway on movement after sunset
trigger:
  platform: template
  value_template: "{{ is_state('switch.motion_hallway', 'on') }}"
condition:
  condition: sun
  after: sunset
  # Optional offset value
  after_offset: "-1:00:00"
action:
  service: light.turn_on
  entity_id: light.hallway
  data:
    brightness: 125

en deze:

YAML:

alias: Turn on light hallway on movement before sunset
trigger:
  platform: template
  value_template: "{{ is_state('switch.motion_hallway', 'on') }}"
condition:
  condition: sun
  before: sunrise
  # Optional offset value
  before_offset: "0:30:00"
action:
  service: light.turn_on
  entity_id: light.hallway
  data:
    brightness: 100

[bart4444]

Werk bij jullie de waarschuwing nog als iemand verkeerd heeft ingelogd. En ook de Ipban functie werk bij mij niet meer.

Ik gebruik momenteel home assistent 38.2

[PuckStar]

lolgast schreef op maandag 13 februari 2017 @ 10:25:
[...]

Bedankt, ik heb nu eerst de optie van Kroontje doorgevoerd, maar dit kan ook nog. Zoals aangegeven wil ik alleen voorkomen te veel fixed waardes in te stellen, want dan ga je een beetje voorbij aan het doel van de variabele sunset

Ik gebruik voor de zon de elevation ipv offset want "Solar elevation automations can cope with offsets from sunset / sunrise as the seasons change better than using a time based offsets."

Voor de tuin heb ik deze 2 automations want in de winter hoeven ze niet al om 16u aan als het donker wordt, dus dan kijkt hij naar de tijd 19:30, en in de zomer is het wanneer het donker wordt (dus de elevation -3.5).

[code=yaml]
- alias: 'Lights on as the sun gets dimmer and after 19:30 - Tuin'
trigger:
platform: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: -3.5
condition:
condition: and
conditions:
- condition: state
entity_id: light.hue_white_1_tuin
state: 'off'
- condition: state
entity_id: light.hue_white_2_terras
state: 'off'
- condition: state
entity_id: light.hue_white_3_schuur
state: 'off'
- condition: time
after: '19:30:00'
action:
- service: light.turn_on
data:
entity_id: light.hue_white_2_terras
color_temp: 353
brightness: 99
transition: 600
- delay:
seconds: 10
- service: light.turn_on
data:
entity_id: light.hue_white_1_tuin
color_temp: 353
brightness: 74
transition: 600
- delay:
seconds: 10
- service: light.turn_on
data:
entity_id: light.hue_white_3_schuur
color_temp: 353
brightness: 160
transition: 600

- alias: 'Lights on as its 19:30 and the sun dimmed - Tuin'
trigger:
platform: time
after: '19:30:00'
condition:
condition: and
conditions:
- condition: state
entity_id: light.hue_white_1_tuin
state: 'off'
- condition: state
entity_id: light.hue_white_2_terras
state: 'off'
- condition: state
entity_id: light.hue_white_3_schuur
state: 'off'
- condition: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
below: -3.5
action:
- service: light.turn_on
data:
entity_id: light.hue_white_2_terras
color_temp: 353
brightness: 99
transition: 600
- delay:
seconds: 10
- service: light.turn_on
data:
entity_id: light.hue_white_1_tuin
color_temp: 353
brightness: 74
transition: 600
- delay:
seconds: 10
- service: light.turn_on
data:
entity_id: light.hue_white_3_schuur
color_temp: 353
brightness: 160
transition: 600
[/code=yaml]

De delays van 10sec heb ik trouwens omdat ik merkte dat als ze tegelijk aan moesten dat niet altijd goed ging, misschien omdat ze wat verder in de tuin zitten.

[lolgast]

Daar zou ik ook nog eens naar kunnen kijken inderdaad ja. De verlichting gaat nu wel vroeg aan.

Maar voorlopig wil ik eerst die *vul woord in* Fibaro Dimmer 2 aan de gang hebben. Gisteravond ook weer een tijd bezig geweest, maar ik krijg het niet voor elkaar om S2 als aparte schakelaar te schakelen. Heb de dimmer al verwijderd uit OZWCP, gereset naar factory en opnieuw gekoppeld, maar helaas. Ook de parameters via HASS ingesteld ipv via OZWCP, maar dat ding wil niet wat ik wil. Hij blijft met S2 de S1 switch (en dus ook de load) bedienen. Super frustrerend, want volgens mij moet het vrij simpel zijn