Home Assistant - Open source Python3 home automation

[Luc S]

Ik stuit zojuist op dit topic en ben erg onder de indruk van hoe Home Assistant eruit ziet en wat het kan. De opmerkingen over de eindeloze mogelijkheden overtuigde me om me hier eens in te gaan verdiepen.

Sorry voor het lange verhaal maar ik zou aan jullie als ervaringsdeskundigen willen vragen om eens te kijken naar mijn 'platform' en mij te vertellen of Home Assistant een optie voor me is. Ik maak namelijk maar weinig gebruik van standaard accessoires maar ik kan wel redelijk python3 programmeren.

Een jaar geleden heb ik een eigen PyQt4 applicatie geschreven (met GUI op 7" RPi touchscreen) om mijn huis te automatiseren. Inmiddels is het echter een redelijk complex geheel aan het worden, zo heb ik nu ook een memory lekje ergens waar ik niet helemaal uit kom.

Ik koos voor een eigen PyQt applicatie omdat ik met goedkope onderdelen zelf mijn huis wilde automatiseren en beveiligen zonder afhankelijk te zijn van andere instanties/online portals of dure hardware. Tijdens een flinke verbouwing heb ik zowat overal loze leidingen aangebracht omdat ik in dit soort projecten een hekel heb aan hardware waar een batterij in moet.

Ik heb een PiFace Digital2 op mijn Raspberry Pi2 zitten waar magneetschakelaars, bewegingssensors en lasers+lichtsensors aan hangen die gezamenlijk mijn alarmsysteem vormt. Als ik via de GUI het alarm inschakel, start de zelfgemaakte python3 'alarmservice' en wordt er geluisterd naar waarde veranderingen in die componenten. Bij een waarde verandering wordt een functie in de PyQt applicatie gestart;

1. In de GUI van de applicatie gaat een timer lopen omdat je je PIN moet ingeven
2. Er worden 3 foto's gemaakt via een IP-cam en in een temp folder opgeslagen
3. Als de zon onder is, gaan de lampen aan in gedimde modus
4. Als je geen PIN ingeeft worden de foto's via Telegram naar mijn telefoon gestuurd, gaan de lichten knipperen en wordt er een alarmtoon afgespeeld. Schakel je het alarm netjes uit dan worden de foto's verwijdert

Verder heb ik;

• een OTGW waar ik mijn temperatuur uit lees en geef ik met een icoontje weer of het vlammetje en/of de pomp aan is
• AM2301 sensors voor buitenklimaat en binnenluchtvochtigheid
• MiLight lampen die ik via de GUI kan besturen
• Homebridge geïnstalleerd met een custom plugin zodat ik via Apple HomeKit kan praten met mijn PyQt4 applicatie (zo kan ik tegen Siri zeggen dat ik naar bed ga en worden alle lampen uitgeschakeld en wordt het alarm ingeschakeld )
• net mijn eerste prototype klaar om de draaistok van de luxaflex te vervangen door een stappen motor (de service hiervoor zal overigens op een andere RPi draaien omdat stappen motors een hoop GPIO pinnen nodig hebben als je ze los van elkaar wilt kunnen besturen)

Ik zou Home Assistant dus moeten kunnen triggeren en voeden met o.a. eigen python3 services. Kan iemand me vertellen o.b.v. bovenstaande of het zinvol voor me is vanmiddag nog een Raspberry Pi3 te gaan kopen om mijn systeem om te bouwen naar Home Assistant?

[lolgast]

Ik ben wel klaar met die Fibaro Dimmer, dus heb me verdiept in de wondere wereld van het automatisch aanmaken van een certificaat terwijl poort 443 niet geforward wordt naar HASS, want daar draait andere apparatuur op bij mij. Bij een Synology gaat dat heel makkelijk, bij een RPi wat lastiger . Ik ben er nogal even mee bezig geweest, dus onderstaande om wellicht een ander te helpen.
Bij onderstaande is het een vereiste dat je domein bij Transip is geregistreerd en ga ik er vanuit dat je de AIO-installer van HASS hebt gebruikt, vandaar dat alles onder de user homeassistant gebeurd..

1. Maak een API aan bij Transip, die kan via https://www.transip.nl/cp/account/api/. Als extra veiligheid tegen misbruik van je API maak je gebruik van whitelisting om IP-adressen toestemming tot je API te geven. Vul hier het public IP van je RPi in.

2. SSH naar je RPi, wissel naar de homeassistant gebruiker en ga naar de home dir

code:

sudo su -s /bin/bash homeassistant
cd ~

3. Download dehydrated, dit script kan automatisch certificaten opvragen zonder poort 443 nodig te hebben. Open daarna de nieuwe map.

code:

git clone https://github.com/lukas2511/dehydrated.git
cd dehydrated

4. Download de API van Transip en pak deze uit naar de submap Transip

code:

wget https://api.transip.nl/downloads/transapi_transip.nl_v5_2.tar.gz
tar -xvzf transapi_transip.nl_v5_2.tar.gz Transip

5. Pas de ApiSettings.php file aan met je persoonlijke gegeven -> username en API toevoegen (onderaan, zet je gegevens tussen de quotes!)

code:

nano Transip/ApiSettings.php

6. Download de hook om dehydrated gebruik te laten maken van de Transip API. Verplaats de gedownloade bestanden vervolgens naar de rootmap van dehydrated.

code:

git clone https://github.com/sigio/dehydrated-transip-dns-validator.git
mv ./dehydrated-transip-dns-validator/*.php /home/homeassistant/dehydrated/

7. Pas van de hook bestanden de config.inc.php aan met je domeinnaam

code:

nano config.inc.php

8. Maak een config-file aan, welke dehydrated gebruikt om je standaard gegevens uit te lezen. Je hebt in feite alleen regel 85 nodig, maar ik plak hem altijd helemaal. Al is het maar om te begrijpen wat hij kan

code:

nano config

code:

########################################################
# This is the main config file for dehydrated          #
#                                                      #
# This file is looked for in the following locations:  #
# $SCRIPTDIR/config (next to this script)              #
# /usr/local/etc/dehydrated/config                     #
# /etc/dehydrated/config                               #
# ${PWD}/config (in current working-directory)         #
#                                                      #
# Default values of this config are in comments        #
########################################################

# Resolve names to addresses of IP version only. (curl)
# supported values: 4, 6
# default: <unset>
#IP_VERSION=

# Path to certificate authority (default: https://acme-v01.api.letsencrypt.org/directory)
#CA="https://acme-v01.api.letsencrypt.org/directory"

# Path to certificate authority license terms redirect (default: https://acme-v01.api.letsencrypt.org/terms)
#CA_TERMS="https://acme-v01.api.letsencrypt.org/terms"

# Path to license agreement (default: <unset>)
#LICENSE=""

# Which challenge should be used? Currently http-01 and dns-01 are supported
#CHALLENGETYPE="dns-01"

# Path to a directory containing additional config files, allowing to override
# the defaults found in the main configuration file. Additional config files
# in this directory needs to be named with a '.sh' ending.
# default: <unset>
#CONFIG_D=

# Base directory for account key, generated certificates and list of domains (default: $SCRIPTDIR -- uses config directory if undefined)
#BASEDIR=$SCRIPTDIR

# File containing the list of domains to request certificates for (default: $BASEDIR/domains.txt)
#DOMAINS_TXT="${BASEDIR}/domains.txt"

# Output directory for generated certificates
#CERTDIR="${BASEDIR}/certs"

# Directory for account keys and registration information
#ACCOUNTDIR="${BASEDIR}/accounts"

# Output directory for challenge-tokens to be served by webserver or deployed in HOOK (default: /var/www/dehydrated)
#WELLKNOWN="/var/www/dehydrated"

# Default keysize for private keys (default: 4096)
#KEYSIZE="4096"

# Path to openssl config file (default: <unset> - tries to figure out system default)
#OPENSSL_CNF=

# Program or function called in certain situations
#
# After generating the challenge-response, or after failed challenge (in this case altname is empty)
# Given arguments: clean_challenge|deploy_challenge altname token-filename token-content
#
# After successfully signing certificate
# Given arguments: deploy_cert domain path/to/privkey.pem path/to/cert.pem path/to/fullchain.pem
#
# BASEDIR and WELLKNOWN variables are exported and can be used in an external program
# default: <unset>
#HOOK=

# Chain clean_challenge|deploy_challenge arguments together into one hook call per certificate (default: no)
#HOOK_CHAIN="no"

# Minimum days before expiration to automatically renew certificate (default: 30)
#RENEW_DAYS="30"

# Regenerate private keys instead of just signing new certificates on renewal (default: yes)
#PRIVATE_KEY_RENEW="yes"

# Create an extra private key for rollover (default: no)
#PRIVATE_KEY_ROLLOVER="no"

# Which public key algorithm should be used? Supported: rsa, prime256v1 and secp384r1
#KEY_ALGO=rsa

# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL=JE_EMAIL_ADRES

# Lockfile location, to prevent concurrent access (default: $BASEDIR/lock)
#LOCKFILE="${BASEDIR}/lock"

# Option to add CSR-flag indicating OCSP stapling to be mandatory (default: no)
#OCSP_MUST_STAPLE="no"

9. Tijdens het testen kun je van bovenstaande, regel 19 vervangen voor https://acme-staging.api.letsencrypt.org/directory. Dit is de test-omgeving van Lets Encrypt waardoor je niet geblokkeerd wordt na te veel aanvragen door het eventuele testen. Niet vergeten weer terug te wijzigen
Voor zowel de staging-omgeving als de live omgeving van LE moet je je registreren en akkoord gaan met de voorwaarden, dit doe je via

code:

dehydrated/dehydrated --register --accept-terms

10. Heb je dat gedaan, dan zou je met onderstaande je certificaat moeten kunnen aanvragen. Ze worden aangemaakt in de map /home/homeassistant/dehydrated/certs/sub.domain.nl/

code:

dehydrated/dehydrated --cron --domain sub.domain.nl --hook dehydrated/hook-dns-transip-api.php --challenge dns-01

11. Om ervoor te zorgen dat het certificaat niet verloopt (LE-certificaten zijn 90 dagen geldig) zonder een nieuwe aan te maken kun je een cronjob maken. Ik moest hiervoor crontab installeren onder homeassistant, wat faalde maar vervolgens wel werkt. Zonder deze install kon ik niets opslaan onder deze user. Installeer via

code:

pip install crontab

Maak vervolgens een cronjob via

code:

crontab -e

De eerste keer dat je dat doet moet je een editor kiezen. Ik gebruik eigenlijk altijd nano, maar kies wat je wilt. Als cronjob vul je onderaan (met je eigen subdomain!) in

code:

37 4 4 * * /home/homeassistant/dehydrated/dehydrated --cron --domain sub.domain.nl --hook /home/homeassistant/dehydrated/hook-dns-transip-api.php --challenge dns-01 >> /home/homeassistant/dehydrated/logs/cronjob.log

Deze taak start om 4:37 AM, op de 4e dag van elke maand. Een output wordt gemaakt in de map logs (welke je zelf even aan moet maken), zodat je kunt controleren of de aanvraag ook gelukt is.
Een certificaat van LE wordt vernieuwd als het 30 dagen of minder geldig is, dus elke 2 maanden zou je een nieuwe moeten krijgen.

Niet vergeten je configuration.yaml even aan te passen

YAML:

http:
  api_password: !secret http_password
  base_url: !secret base_url
  server_port: !secret serverport
  ssl_certificate: !secret ssl_fullchain
  ssl_key: !secret ssl_privkey
  trusted_networks:
    - 127.0.0.1
    - 192.168.0.0/23
    - 10.10.0.0/24
#  use_x_forwarded_for: true
  ip_ban_enabled: true
  login_attempts_threshold: 3

secrets.yaml

YAML:

ssl_fullchain: /home/homeassistant/dehydrated/certs/sub.domain.nl/fullchain.pem
ssl_privkey: /home/homeassistant/dehydrated/certs/sub.domain.nl/privkey.pem

Je HASS zou na een restart via HTTPS benaderbaar moeten zijn

[Yelti]

Luc S schreef op dinsdag 14 februari 2017 @ 13:43:
Ik stuit zojuist op dit topic en ben erg onder de indruk van hoe Home Assistant eruit ziet en wat het kan. De opmerkingen over de eindeloze mogelijkheden overtuigde me om me hier eens in te gaan verdiepen.

Sorry voor het lange verhaal maar ik zou aan jullie als ervaringsdeskundigen willen vragen om eens te kijken naar mijn 'platform' en mij te vertellen of Home Assistant een optie voor me is. Ik maak namelijk maar weinig gebruik van standaard accessoires maar ik kan wel redelijk python3 programmeren.

Een jaar geleden heb ik een eigen PyQt4 applicatie geschreven (met GUI op 7" RPi touchscreen) om mijn huis te automatiseren. Inmiddels is het echter een redelijk complex geheel aan het worden, zo heb ik nu ook een memory lekje ergens waar ik niet helemaal uit kom.

Ik koos voor een eigen PyQt applicatie omdat ik met goedkope onderdelen zelf mijn huis wilde automatiseren en beveiligen zonder afhankelijk te zijn van andere instanties/online portals of dure hardware. Tijdens een flinke verbouwing heb ik zowat overal loze leidingen aangebracht omdat ik in dit soort projecten een hekel heb aan hardware waar een batterij in moet.

Ik heb een PiFace Digital2 op mijn Raspberry Pi2 zitten waar magneetschakelaars, bewegingssensors en lasers+lichtsensors aan hangen die gezamenlijk mijn alarmsysteem vormt. Als ik via de GUI het alarm inschakel, start de zelfgemaakte python3 'alarmservice' en wordt er geluisterd naar waarde veranderingen in die componenten. Bij een waarde verandering wordt een functie in de PyQt applicatie gestart;

1. In de GUI van de applicatie gaat een timer lopen omdat je je PIN moet ingeven
2. Er worden 3 foto's gemaakt via een IP-cam en in een temp folder opgeslagen
3. Als de zon onder is, gaan de lampen aan in gedimde modus
4. Als je geen PIN ingeeft worden de foto's via Telegram naar mijn telefoon gestuurd, gaan de lichten knipperen en wordt er een alarmtoon afgespeeld. Schakel je het alarm netjes uit dan worden de foto's verwijdert

Verder heb ik;

• een OTGW waar ik mijn temperatuur uit lees en geef ik met een icoontje weer of het vlammetje en/of de pomp aan is
• AM2301 sensors voor buitenklimaat en binnenluchtvochtigheid
• MiLight lampen die ik via de GUI kan besturen
• Homebridge geïnstalleerd met een custom plugin zodat ik via Apple HomeKit kan praten met mijn PyQt4 applicatie (zo kan ik tegen Siri zeggen dat ik naar bed ga en worden alle lampen uitgeschakeld en wordt het alarm ingeschakeld )
• net mijn eerste prototype klaar om de draaistok van de luxaflex te vervangen door een stappen motor (de service hiervoor zal overigens op een andere RPi draaien omdat stappen motors een hoop GPIO pinnen nodig hebben als je ze los van elkaar wilt kunnen besturen)

Ik zou Home Assistant dus moeten kunnen triggeren en voeden met o.a. eigen python3 services. Kan iemand me vertellen o.b.v. bovenstaande of het zinvol voor me is vanmiddag nog een Raspberry Pi3 te gaan kopen om mijn systeem om te bouwen naar Home Assistant?

Het alarm stuk zou ik laten zoals het is, de rest kan je met HASS doen.
Een pi heb je nooit te veel

Kan je wat meer info geven over je bewegingssensoren/lasers?
Ben wel benieuwd.

[ThinkPad]

lolgast schreef op woensdag 15 februari 2017 @ 17:43:
Ik ben wel klaar met die Fibaro Dimmer, dus heb me verdiept in de wondere wereld van het automatisch aanmaken van een certificaat terwijl poort 443 niet geforward wordt naar HASS, want daar draait andere apparatuur op bij mij.
[...]

Volgens mij kun je sinds een aantal weken geleden ook gebruik maken van 'DNS validation' bij LetsEncrypt. Als ik het goed begrijp moet je dan een TXT-record aan het domein hangen en hoef je dan geen poorten enzo te openen: http://serverfault.com/qu...-dns-challenge-validation

[lolgast]

ThinkPadd schreef op donderdag 16 februari 2017 @ 10:24:
[...]

Volgens mij kun je sinds een aantal weken geleden ook gebruik maken van 'DNS validation' bij LetsEncrypt. Als ik het goed begrijp moet je dan een TXT-record aan het domein hangen en hoef je dan geen poorten enzo te openen: http://serverfault.com/qu...-dns-challenge-validation

Dat is precies wat hierboven staat uitgelegd inderdaad. Het TXT-record moet iedere keer een andere inhoud hebben, met behulp van de API wordt deze aangemaakt, vervolgens gechecked en weer verwijderd

Edit: Vandaar dat in de code van het aanvragen van het certificaat de challenge ook op dns-01 staat

[ Voor 7% gewijzigd door lolgast op 16-02-2017 10:27 ]

[ThinkPad]

lolgast schreef op donderdag 16 februari 2017 @ 10:26:
[...]

Dat is precies wat hierboven staat uitgelegd inderdaad. Het TXT-record moet iedere keer een andere inhoud hebben, met behulp van de API wordt deze aangemaakt, vervolgens gechecked en weer verwijderd

Edit: Vandaar dat in de code van het aanvragen van het certificaat de challenge ook op dns-01 staat

Te snel gelezen, excuses Na horizontaal scrollen zag ik inderdaad 'dns-01' staan in de code.

[Luc S]

Yelti schreef op donderdag 16 februari 2017 @ 10:00:
[...]


Het alarm stuk zou ik laten zoals het is, de rest kan je met HASS doen.
Een pi heb je nooit te veel

Kan je wat meer info geven over je bewegingssensoren/lasers?
Ben wel benieuwd.

Nou moet ik eerlijk bekennen dat ik nou net met die lasers wat uit de bocht ben gevlogen met de hobby

Ik heb in de lichtstraat boven de keuken aan de ene kant 2 lasers en aan de andere kant 2 lichtsensors gemonteerd die gestuurd worden door de PiFace Digital. Met een script kan je de PiFace Digital laten luisteren op een digitale pin en een trigger bouwen op een waarde wijziging. Zo is tevens de bewegingssensor aangesloten. Ik voorzie de componenten ook van stroom via de PiFace Digital 30 seconden nadat ik het alarm inschakel (de RPi trekt dat tot nu toe nog goed).

Deze onderdelen heb ik gebruikt:
Laser: http://www.tinytronics.nl/shop/Red-laser-5V-650nm-wire
Lichtsensor: http://www.tinytronics.nl...ch/Licht-Sensor-Module-V3
Bewegingssensor: http://www.tinytronics.nl...on-Sensor-Detector-Module

Dit is de GUI waarin je gelocked bent op het moment dat het alarm aan staat (voor mijn eigen veiligheid zeg ik maar even dat dit niet mijn huis is die ik met sketchup heb nagemaakt ):


En dit is hoe de componenten in de lichtstraat zitten (ben nog zoekende naar een nette afwerking):
Lasers:


Lichtsensoren:


De bewegingsmelder hangt nog los in de hal boven de meterkast, dus die laat ik even achterwege wat foto's betreft.

[Yelti]

Luc S schreef op donderdag 16 februari 2017 @ 16:42:
[...]


Nou moet ik eerlijk bekennen dat ik nou net met die lasers wat uit de bocht ben gevlogen met de hobby

Ik heb in de lichtstraat boven de keuken aan de ene kant 2 lasers en aan de andere kant 2 lichtsensors gemonteerd die gestuurd worden door de PiFace Digital. Met een script kan je de PiFace Digital laten luisteren op een digitale pin en een trigger bouwen op een waarde wijziging. Zo is tevens de bewegingssensor aangesloten. Ik voorzie de componenten ook van stroom via de PiFace Digital 30 seconden nadat ik het alarm inschakel (de RPi trekt dat tot nu toe nog goed).

Deze onderdelen heb ik gebruikt:
Laser: http://www.tinytronics.nl/shop/Red-laser-5V-650nm-wire
Lichtsensor: http://www.tinytronics.nl...ch/Licht-Sensor-Module-V3
Bewegingssensor: http://www.tinytronics.nl...on-Sensor-Detector-Module

Dit is de GUI waarin je gelocked bent op het moment dat het alarm aan staat (voor mijn eigen veiligheid zeg ik maar even dat dit niet mijn huis is die ik met sketchup heb nagemaakt ):
[afbeelding]

En dit is hoe de componenten in de lichtstraat zitten (ben nog zoekende naar een nette afwerking):
Lasers:
[afbeelding]

Lichtsensoren:
[afbeelding]

De bewegingsmelder hangt nog los in de hal boven de meterkast, dus die laat ik even achterwege wat foto's betreft.

Ik neem aan dat je de lasers dan gebruikt om te bepalen of er iemand via de lichtstraat binnenbreekt?

Wel n mooie gui

[UltraSub]

Whoah..



Kost geen knoop zo te zien. Maar als je 20 lasers in huis wil dan is dat natuurlijk niet te doen met 20 pi's. Is dat niet draadloos te maken op een of andere manier met een mqtt integratie of zo

[Yelti]

UltraSub schreef op vrijdag 17 februari 2017 @ 10:58:
Whoah..

[afbeelding]

Kost geen knoop zo te zien. Maar als je 20 lasers in huis wil dan is dat natuurlijk niet te doen met 20 pi's. Is dat niet draadloos te maken op een of andere manier met een mqtt integratie of zo

Moet wel te doen zijn met een esp8266.
5v psu/stepdown/transistor en je geraakt er wel

[HaTe]

UltraSub schreef op vrijdag 17 februari 2017 @ 10:58:
Whoah..

[afbeelding]

Kost geen knoop zo te zien. Maar als je 20 lasers in huis wil dan is dat natuurlijk niet te doen met 20 pi's. Is dat niet draadloos te maken op een of andere manier met een mqtt integratie of zo

Arduino's met de mysensors library zijn denk ik een goede optie. Heb zo ook zelf een bewegingsmelder gemaakt. Zie zie niet in waarom die moeilijker zou zijn met een lichtsensor.

[Luc S]

Yelti schreef op vrijdag 17 februari 2017 @ 10:27:
[...]

Ik neem aan dat je de lasers dan gebruikt om te bepalen of er iemand via de lichtstraat binnenbreekt?

Wel n mooie gui

Ja, beetje hoog mission impossible gehalte natuurlijk Ik vond het zo cool toen ik het werkend had gekregen (aan het begin van de hobby) dat ik koste wat kost er iets mee wilde doen in huis

[UltraSub]

En terecht. Is ook cool. Zie de oprit al voor me als beetje mistig is
Denk dat een inbreker zich 2x bedenkt.

[tyfoon_2]

Heeft iemand al iets geprobeerd met die openALPR of Microsoft FACE componenten? Zo ja, wat zijn de ervaringen?

[UltraSub]

tyfoon_2 schreef op zaterdag 18 februari 2017 @ 09:25:
Heeft iemand al iets geprobeerd met die openALPR of Microsoft FACE componenten? Zo ja, wat zijn de ervaringen?

Nog niet geprobeerd. Camera's hangen daar ook niet echt ideaal voor. Is een leuk spielereitje hier als ik ermee aan de gang zou gaan, meer niet. Zie er ook geen use case voor eigenlijk.

[Yelti]

Luc S schreef op vrijdag 17 februari 2017 @ 22:02:
[...]


Ja, beetje hoog mission impossible gehalte natuurlijk Ik vond het zo cool toen ik het werkend had gekregen (aan het begin van de hobby) dat ik koste wat kost er iets mee wilde doen in huis

Had het idee dat je ze misschien zou gebruikt hebben als directional sensors, om richting van beweging te bepalen .
Zou dit kunnen gebruiken omdat motion sensors met mijn katten bijna waardeloos zijn :-)

[Luc S]

Yelti schreef op zaterdag 18 februari 2017 @ 14:38:
[...]

Had het idee dat je ze misschien zou gebruikt hebben als directional sensors, om richting van beweging te bepalen .
Zou dit kunnen gebruiken omdat motion sensors met mijn katten bijna waardeloos zijn :-)

Ik heb hier ook een kat rondlopen en zat dus met hetzelfde probleem. Ik heb er daarom voor gekozen alle manieren om hier binnen te komen te monitoren, bij alle deuren en ramen zit een goedkope magneet schakelaar in de kozijnen gemonteerd. Deze zitten ook aan de alarm service: https://www.kiwi-electron...ct-schakelaar-deur-sensor

Ik had wel het voordeel dat we een nieuwe vloer met vloerverwarming neer gingen leggen afgelopen jaar dus ik kon overal een loze leiding uit laten komen.

[ny-hardcore]

Luc S schreef op vrijdag 17 februari 2017 @ 22:02:
[...]


Ja, beetje hoog mission impossible gehalte natuurlijk Ik vond het zo cool toen ik het werkend had gekregen (aan het begin van de hobby) dat ik koste wat kost er iets mee wilde doen in huis

Was de lichtsenser naast de laser en een reflector aan de overzijde niet makkelijker geweest qua bekabeling? Dus laser via reflector kaatsen op sensor naast de laser?

[UltraSub]

ny-hardcore schreef op zaterdag 18 februari 2017 @ 22:52:
[...]

Was de lichtsenser naast de laser en een reflector aan de overzijde niet makkelijker geweest qua bekabeling? Dus laser via reflector kaatsen op sensor naast de laser?

Goed punt, dacht ik hier ook al aan...

[Luc S]

ny-hardcore schreef op zaterdag 18 februari 2017 @ 22:52:
[...]

Was de lichtsenser naast de laser en een reflector aan de overzijde niet makkelijker geweest qua bekabeling? Dus laser via reflector kaatsen op sensor naast de laser?

Heb ik overwogen maar dan heb je teveel ruimte over naast de reflector, een persoon met slank postuur zou zich dan zonder problemen kunnen laten afdalen

[Yelti]

Luc S schreef op zondag 19 februari 2017 @ 18:07:
[...]


Heb ik overwogen maar dan heb je teveel ruimte over naast de reflector, een persoon met slank postuur zou zich dan zonder problemen kunnen laten afdalen

En dan dwalen mijn gedachten af naar 1 laser, meerdere spiegels en 1 ontvanger...
Ga eens nadenken over iets met reflectors.

[bob-nwk]

Wow, wist niet dat er zo'n actief HA topic was op Tweakers, deze blijven we ook maar even volgen

[bob-nwk]

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!

Probeer je browsercache eens te wissen en te manual refreshen (shift+F5). Waarschijnlijk heb je dan alles weer terug (ik had hetzelfde namelijk).

[bob-nwk]

bart4444 schreef op maandag 13 februari 2017 @ 17:56:
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

Klopt, werkt op 0.38.3 helaas ook nog niet.
is gelogd op Github, de ontwikkelaar gaat er mee aan de slag: https://github.com/home-assistant/home-assistant/issues/6093

[bob-nwk]

Iemand ervaring met de combinatie HA en de Broadlink RM Pro toevallig?
http://www.ibroadlink.com/rm/

Ik hoop deze morgen te ontvangen

[ Voor 14% gewijzigd door bob-nwk op 20-02-2017 21:59 ]

[ThinkPad]

bob-nwk schreef op maandag 20 februari 2017 @ 21:58:
Iemand ervaring met de combinatie HA en de Broadlink RM Pro toevallig?
http://www.ibroadlink.com/rm/

Ik hoop deze morgen te ontvangen

Deze al gezien?

https://home-assistant.io/components/switch.broadlink/
https://home-assistant.io/components/sensor.broadlink/

Er is al ondersteuning blijkbaar. Zelf geen ervaring mee.

[bob-nwk]

ThinkPadd schreef op dinsdag 21 februari 2017 @ 08:50:
[...]

Deze al gezien?

https://home-assistant.io/components/switch.broadlink/
https://home-assistant.io/components/sensor.broadlink/

Er is al ondersteuning blijkbaar. Zelf geen ervaring mee.

Zeker, toch bedankt.
Ik sta in de startblokken. Echter heeft PostNL nog wat tijd nodig blijkbaar. Sinds zaterdag is de status ongewijzigd: " The item has been processed in the country of destination."

[trekker22]

HASS database is in een paar maanden gegroeid naar 2,5 GB???

zoveel switches en sensors heb ik toch niet. eens zoeken naar wat mogelijk is!

[Verwijderd]

trekker22 schreef op dinsdag 21 februari 2017 @ 20:55:
HASS database is in een paar maanden gegroeid naar 2,5 GB???

zoveel switches en sensors heb ik toch niet. eens zoeken naar wat mogelijk is!

Geen purge aan staan?

[balk]

ThinkPadd schreef op dinsdag 21 februari 2017 @ 08:50:
[...]

Deze al gezien?

https://home-assistant.io/components/switch.broadlink/
https://home-assistant.io/components/sensor.broadlink/

Er is al ondersteuning blijkbaar. Zelf geen ervaring mee.

Hoe werken al die presence detection modules via modems? Ik neem aan via ping? Ik merkte dat mijn telefoon (Nexus 5X) z'n wifi uit gooit als het scherm een tijdje uit is. En dan slechts af en toe even komt kijken. Daarom heb ik een BT LE dongle in m'n Paay zitten en dat lijkt wel betrouwbaar te zijn. Of doet HASS dit anders dan Domoticz? Dit is overigens ook wel een aardige.

[TD-er]

Hmm, zag net dit voorbij komen en dacht even op hun site kijken, krijg ik ineens allemaal Cloudflare meldingen

Error 1014 Ray ID: 335d44e1fa9b2c4e • 2017-02-23 20:01:19 UTC
CNAME Cross-User Banned
What happened?
You've requested a page on a website that is part of the Cloudflare network. The host is configured as a CNAME across accounts on Cloudflare, which is prohibited by security policy.
[...]

Nu weet ik wat een CNAME is en wat Cloudflare ongeveer zou moeten zijn, maar geen idee wat hier aan de hand is?

[Sypher]

balk schreef op donderdag 23 februari 2017 @ 20:54:
[...]

Hoe werken al die presence detection modules via modems? Ik neem aan via ping? Ik merkte dat mijn telefoon (Nexus 5X) z'n wifi uit gooit als het scherm een tijdje uit is. En dan slechts af en toe even komt kijken. Daarom heb ik een BT LE dongle in m'n Paay zitten en dat lijkt wel betrouwbaar te zijn. Of doet HASS dit anders dan Domoticz? Dit is overigens ook wel een aardige.

Ligt er aan, die van UniFi checkt de lijst van verbonden clients. Helaas duurt het daarin ~20 minuten voor je weg bent wat voor mijn use-case niet handig is. Ik ben gisteren overgeschakeld op OwnTracks + NMAP maar dit leverde weer false positives op dus die weer even uitgezet. Bijkomende voordeel van OwnTracks is dat ik ook de accu status van m'n telefoon door HASS in de gaten kan houden

Sowieso is het jammer dat hij HASS presence detection geldt dat de laatste rapportage juist is. Zegt OT dat je thuis bent en je andere check (NMAP, Ping whatever) van niet dan geldt dat. Resulteert vervolgens leuk in een ping-pong tussen thuis-niet thuis-thuis.

[balk]

Sypher schreef op vrijdag 24 februari 2017 @ 08:22:
[...]

Sowieso is het jammer dat hij HASS presence detection geldt dat de laatste rapportage juist is. Zegt OT dat je thuis bent en je andere check (NMAP, Ping whatever) van niet dan geldt dat. Resulteert vervolgens leuk in een ping-pong tussen thuis-niet thuis-thuis.

Waarom is het zo ingewikkeld? Ik wil gewoon betrouwbare presence detection
HASS zou eigenlijk een 2 uit 3 of 4 uit 5 voting moeten hebben; dus als je volgens nmap en OwnTracks thuis bent en volgens BT niet, dan ben je dus thuis.

Ik denk nu in twee richtingen:
1) op mijn android telefoon (en die van mijn vrouw) op de achtergrond een MQTT client draaien die elke 5 minuten een bericht uitstuurt. Als we thuis zijn zal dit aankomen en dus geregistreerd worden. Als we de deur uit zijn niet. Maar ik kan geen app vinden die dat kan.
2) een scriptje draaien op m'n Paay die bovenstaand doet plus pingen naar tcp/ip en BT adressen en dan 4 uit 5 voting doet en daarmee elke x minuten HASS bijwerkt.

[Yelti]

balk schreef op vrijdag 24 februari 2017 @ 15:27:
[...]

Waarom is het zo ingewikkeld? Ik wil gewoon betrouwbare presence detection
HASS zou eigenlijk een 2 uit 3 of 4 uit 5 voting moeten hebben; dus als je volgens nmap en OwnTracks thuis bent en volgens BT niet, dan ben je dus thuis.

Ik denk nu in twee richtingen:
1) op mijn android telefoon (en die van mijn vrouw) op de achtergrond een MQTT client draaien die elke 5 minuten een bericht uitstuurt. Als we thuis zijn zal dit aankomen en dus geregistreerd worden. Als we de deur uit zijn niet. Maar ik kan geen app vinden die dat kan.
2) een scriptje draaien op m'n Paay die bovenstaand doet plus pingen naar tcp/ip en BT adressen en dan 4 uit 5 voting doet en daarmee elke x minuten HASS bijwerkt.

Eenmaal mijn huidige setup stabiel werkt ben ik ook van plan om iets gelijkaardig te implementeren.
Mijn idee gaat voorlopig naar volgnde opzet:
- stap 1: onmiddelijke detectie via pir sensoren.(op z-wave netwerk)
- stap 2: locatie pinning dmv bluetooth beacons en happy bubbles ibeacon detectoren.

Vertrouw gsm's niet vanwege energiebesparingen die BT of Wifi uitschakelen na x tijd en ook extra batterydrain.

ibeacons kunnen evt verwerkt worden in een armband zodat dit ook werkt als je je gsm niet bijhebt.

Ben op zoek naar n alternatief voor de beacons (bvb smartwatch/fintesstracker) maar nog niks anders gevonden.

[ Voor 7% gewijzigd door Yelti op 24-02-2017 16:03 ]

[Tim Schuhmacher]

Voor Android kun je Llama gebruiken, je kunt dan met een kleine vertraging na disconnect van een specifieke wifi een url aanroepen. Daarmee kun je vast is hass afwezig aangeven. On connect, kun je weer je aanwezigheid aangeven.

En je kunt met een extra variable in llama uitsluiten dat je met een korte disconnect niet direct weg bent.

[balk]

Tim Schuhmacher schreef op vrijdag 24 februari 2017 @ 17:09:
Voor Android kun je Llama gebruiken, je kunt dan met een kleine vertraging na disconnect van een specifieke wifi een url aanroepen. Daarmee kun je vast is hass afwezig aangeven. On connect, kun je weer je aanwezigheid aangeven.

En je kunt met een extra variable in llama uitsluiten dat je met een korte disconnect niet direct weg bent.

Llama of Tasker idd. Dus de telefoon actief uit laten zenden "ik ben er!". Nadeel van alleen PIR is dat als je 's avonds laat op de bank hangt en een film kijkt de PIR geen beweging meer detecteert waarna je in de kou komt te zitten

[UltraSub]

balk schreef op vrijdag 24 februari 2017 @ 18:36:
[...]

Llama of Tasker idd. Dus de telefoon actief uit laten zenden "ik ben er!". Nadeel van alleen PIR is dat als je 's avonds laat op de bank hangt en een film kijkt de PIR geen beweging meer detecteert waarna je in de kou komt te zitten

And there is your fix

[balk]

UltraSub schreef op vrijdag 24 februari 2017 @ 19:00:
[...]

And there is your fix

of iets anders passiefs op de bank (denk iPad, laptop, etc). Bovendien, hoe weet HASS of ik Netflix ofzo gebruik op mijn Sony TVtje? Ik denk toch dat ik meerdere PIRs zal moeten gaan gebruiken.

Mijn grootste wens is: verwarming uit als ik naar bed ga, en niet een half uur er voor of er na. Nog een mogelijkheid is om een lamp als master switch aan te wijzen. Als ik die uit doe (en er was beweging in de uren er voor) dan is het bed tijd

[UltraSub]

Was inderdaad wat kort door de bocht ja
Maar qua tv is makkelijk. Stroomverbruik meten.

[Fonta]

Hier heb ik simpelweg een scene ingesteld die alles uit zet. "Hé siri, welterusten" roepen zorgt ervoor dat de pc afsluit, de verwarming op 16 graden ingesteld wordt, alle lampen uit gaan en de lampjes op de nachtkastjes aan gaan.
Zodra ik dan lig roep ik tegen siri dat het licht in de slaapkamer uit moet.

Met presence detection in de vorm van bluetooth beacons zou je er voor kunnen zorgen dat hass weet waar je in huis bent. Zo zou je iets kunnen maken dat als het na x:xx is en je voor x minuten in de slaapkamer bent, alles uitgeschakeld wordt. Maar dan moet je wel altijd je telefoon of een andere beacon continue bij je dragen.

[PuckStar]

balk schreef op vrijdag 24 februari 2017 @ 15:27:
[...]

Waarom is het zo ingewikkeld? Ik wil gewoon betrouwbare presence detection
HASS zou eigenlijk een 2 uit 3 of 4 uit 5 voting moeten hebben; dus als je volgens nmap en OwnTracks thuis bent en volgens BT niet, dan ben je dus thuis.

Zo werkt HASS al.
Als 1 van de devices thuis is, ben je thuis. Geldt ook voor de group.tracker_all.
Andersom dus niet. Als 1 van de devices weg valt is het niet dat je gelijk niet thuis bent.

Ik ga zelf denk ik voor 2 oplossingen.
1 is Bluetooth en Wifi presence (maar is onbetrouwbaar want wifi van de telefoon gaat vaak vanzelf uit snachts (ja zelfs met de instelling dat hij dat niet moet doen) en BT is een te kort bereik (heb nu alleen BT op de pi3 zelf namelijk).
Als je wel verder wilt met wifi zijn Owntracks en FIND interessant om te bekijken. Ik heb het beide werkend gekregen met HASS maar gebruik het niet meer.
2 is een fysieke knop die we indrukken als we thuis komen of van huis weggaan. Dat is om het alarm dus in te stellen (aan/uit).
Ik gebruik optie 1 wel om het alarm al uit te schakelen voordat ik de deur open doe. Als dat niet werkt (of ik ben het zelf niet ) dan zal na x seconden dat de deur open gaat (deur sensor) het alarm afgaan, tenzij de knop (die redelijk verstopt zit) ingedrukt wordt.

PIR's heb ik weinig aan omdat we 2 katten hebben.
Ik heb nog geen oplossing bedacht dat het alarm er op gaat als we naar bed gaan, maar ik denk dat dat iets met Tasker wordt (als ik mijn phone op stil zet (dus ga slapen) dan schakelt tasker het HASS alarm aan.
Ik zat nog aan bedsensoren te kijken maar vind het te priegelig enzo eruit zien. Maar wie weet ooit .

@Iedereen er is weer een update van HASS waar wellicht wat interessants voor je bij zit.
Onder andere een configuratie panel is volgens mij iets waar velen op zitten te wachten. Hoewel het nog in de kinderschoenen staat is het een begin .
https://home-assistant.io...el-and-state-restoration/

[PuckStar]

Misschien dat iemand me even hierbij kan helpen. Ik heb qubino gemaild maar hun antwoord vind ik niet echt duidelijk.

Ik heb dus een elektrische vloerverwarming met een bijbehorende thermostaat. Nu wil ik daar ook een zwave qubino module op aansluiten maar het is me niet helemaal duidelijk hoe ik dat moet gaan doen.

Handleiding thermostaat vloerverwarming: http://imageshack.com/i/pmPZLNplj
Handleiding qubino thermostaat: http://imageshack.com/i/poqwqX7oj
Waar moet ik nou de Q van de qubino op aansluiten? Ik zou denken op dezelfde draad die aan N3 zit van de thermostaat. Klopt dat? En in welke volgorde moet dat dan?
any help appreciated

[[RNMC] Viper]

Naar mijn idee moet op de Q een load (bruin) worden aangesloten, dus in jou geval de L2. Daarmee schakel je dan je thermostaat. Ik weet niet wat er zou gebeuren met je thermostaat als je de vloerverwarming zelf gaat schakelen, dus aansluiten op L4.

Op soortgelijke manier heb ik mijn vloerverwarmingspomp aangesloten. Mijn Qubino schakelt dan via harde schakelaar of via zwave mijn pomp aan/uit. Mijn volgende stap wordt dat ik deze laat reageren op temperatuur, dit moet ik nog automatiseren in hass.

[ Voor 13% gewijzigd door [RNMC] Viper op 01-03-2017 10:34 ]

[PuckStar]

[RNMC] Viper schreef op woensdag 1 maart 2017 @ 10:31:
Naar mijn idee moet op de Q een load (bruin) worden aangesloten, dus in jou geval de L2. Daarmee schakel je dan je thermostaat. Ik weet niet wat er zou gebeuren met je thermostaat als je de vloerverwarming zelf gaat schakelen, dus aansluiten op L4.

Op soortgelijke manier heb ik mijn vloerverwarmingspomp aangesloten. Mijn Qubino schakelt dan via harde schakelaar of via zwave mijn pomp aan/uit. Mijn volgende stap wordt dat ik deze laat reageren op temperatuur, dit moet ik nog automatiseren in hass.

hmm maar op L2 staat continu stroom, dus dat is de stroom input voor de thermostaat.
Als ik daar de qubino tussen zet kan ik inderdaad wellicht de thermostaat schakelen echter het is een thermostaat met display etc. die normaal gesproken dus altijd op spanning staat. op het display kun je dan vervolgens je temperatuur instellen (of programma laten "afspelen").
dus volgens mij moet de thermostaat altijd op spanning staan dmv L2.

Op N3 komt spanning te staan (na meten, want aanvankelijk dacht ik dat er op L4 spanning zou komen) als de normale thermostaat de vloerverwarming aan zet. Vandaar dat ik aan L4, of N3 zat de denken.
[EDIT: de handleiding blijkt niet helemaal overeen te komen met de werkelijkheid (zie dit plaatje http://imageshack.com/i/poN6N8waj) want N3 en L4 bestaan niet, dat is in werkelijkheid L3 en N4. Vandaar dat ik dus stroom meet op N3 (wat in werkelijkheid L3 is). Lekker verwarrend dus.

Ik wil erg voorzichtig zijn om niet kapot te maken uiteraard.

[ Voor 9% gewijzigd door PuckStar op 01-03-2017 11:58 ]

[Yelti]

PuckStar schreef op woensdag 1 maart 2017 @ 11:01:
[...]

hmm maar op L2 staat continu stroom, dus dat is de stroom input voor de thermostaat.
Als ik daar de qubino tussen zet kan ik inderdaad wellicht de thermostaat schakelen echter het is een thermostaat met display etc. die normaal gesproken dus altijd op spanning staat. op het display kun je dan vervolgens je temperatuur instellen (of programma laten "afspelen").
dus volgens mij moet de thermostaat altijd op spanning staan dmv L2.

Op N3 komt spanning te staan (na meten, want aanvankelijk dacht ik dat er op L4 spanning zou komen) als de normale thermostaat de vloerverwarming aan zet. Vandaar dat ik aan L4, of N3 zat de denken.
[EDIT: de handleiding blijkt niet helemaal overeen te komen met de werkelijkheid (zie dit plaatje http://imageshack.com/i/poN6N8waj) want N3 en L4 bestaan niet, dat is in werkelijkheid L3 en N4. Vandaar dat ik dus stroom meet op N3 (wat in werkelijkheid L3 is). Lekker verwarrend dus.

Ik wil erg voorzichtig zijn om niet kapot te maken uiteraard.

Volgens mij is het als volgt.

L2 = L Qubino
N1= N Qubino
L3 = Q Qubino
N4 = N Qubino

Als het een AC pomp is, maakt L en N weinig uit.
De Qubino zal enkel de fase draad onderbreken vandaar dat de N4 en N1 een gemeenschappelijk punt zijn.

Is het de bedoeling dat zowel de qubino gaat schakelen als je thermostaat?
Normaal is het de bedoeling dat de qubino als enigste gebruikt wordt.

[ Voor 5% gewijzigd door Yelti op 01-03-2017 12:53 ]

[[RNMC] Viper]

Ik begrijp uit het verhaal dat het om eletrische verwarming gaat, dus er is geen pomp.

De Q van je Qubino komt tussen de load zijde van je apparaat, dus ofwel L2 om de thermostaat te schakelen, ofwel L3(of in jouw geval N3, blijkbaar verkeerd aangeduid) om de weerstand in je vloer te schakelen.

Wat voor spanning heb je gemeten op L(N)3?

[ Voor 8% gewijzigd door [RNMC] Viper op 01-03-2017 17:31 ]

[PuckStar]

Yelti schreef op woensdag 1 maart 2017 @ 12:49:
[...]


Volgens mij is het als volgt.

L2 = L Qubino
N1= N Qubino
L3 = Q Qubino
N4 = N Qubino

Als het een AC pomp is, maakt L en N weinig uit.
De Qubino zal enkel de fase draad onderbreken vandaar dat de N4 en N1 een gemeenschappelijk punt zijn.

Is het de bedoeling dat zowel de qubino gaat schakelen als je thermostaat?
Normaal is het de bedoeling dat de qubino als enigste gebruikt wordt.

Het zou toch fijn zijn als ik het via beide kan doen. Immers qubino kan alleen op afstand via bijv. HASS, maar als ik even direct de verwarming wil schakelen is de thermostaat wel handig.

[RNMC] Viper schreef op woensdag 1 maart 2017 @ 17:27:
Ik begrijp uit het verhaal dat het om eletrische verwarming gaat, dus er is geen pomp.

De Q van je Qubino komt tussen de load zijde van je apparaat, dus ofwel L2 om de thermostaat te schakelen, ofwel L3(of in jouw geval N3, blijkbaar verkeerd aangeduid) om de weerstand in je vloer te schakelen.

Wat voor spanning heb je gemeten op L(N)3?

klopt elektrische vloerverwarming (http://www.quickheat-floor.nl/quickheat-floor_basic en deze thermostaat http://www.quickheat-floo...Quickheat_klokthermostaat).
Ik heb alleen met een simpel testertje gemeten, dus een oranje lampje .

Ik denk ook dat ik met L3 wel goed zit, maar om dan ook nog de thermostaat te kunnen gebruiken kan ik dan die draden samen laten komen?
Kan ik gewoon 1 draadje vanaf Q bij L3 erin stoppen? of kan dat problemen geven als zowel de thermostaat als de qubino signaal erover willen sturen. Stroom zal niet optellen toch?

[[RNMC] Viper]

Wat is de spanning die uit L3 komt?

Welke Qubino thermostaat versie heb je, on/off of pwn?

Draadje erbij? parallel zetten? dan weten ze niet van elkaar dat ze bezig zijn.

[ Voor 48% gewijzigd door [RNMC] Viper op 01-03-2017 17:57 ]

[PuckStar]

[RNMC] Viper schreef op woensdag 1 maart 2017 @ 17:52:
Wat is de spanning die uit L3 komt?

Welke Qubino thermostaat versie heb je, on/off of pwn?

Draadje erbij? parallel zetten? dan weten ze niet van elkaar dat ze bezig zijn.

als de thermostaat de vloerverwarming aan zet (omdat het dus kouder is dan de opgegeven temperatuur) dan komt er 230V door L3.
Ik heb deze Qubino: pricewatch: Qubino Thermostaat ZMNHIA2

Ik begrijp dat als ik draadje erbij leg ze niet van elkaar weten dat ze bezig zijn, maar kan het kwaad als ze allebei (theoretisch, want in de praktijk zal ik waarschijnlijk de gewone thermostaat niet gebruiken en gewoon zo laag instellen dat hij nooit aan gaat) willen aansturen? aansturen lijkt simpelweg te bestaan uit 230V naar de verwarming knallen.

Ik heb hier 2 opties getekend die wellicht mogelijk zijn: http://imageshack.com/i/pnXH8g5Jp
Het is een draw.io drawing https://tinyurl.com/husa8qx

Fijn dat jullie meedenken trouwens! Paar keer gemaild met Qubino maar die stuurt vooral aan op het alleen gebruiken van hun qubino.

[tyfoon_2]

@PuckStar je hebt er niet zoveel aan , maar dat is de reden waarom ik voor deze ben gegaan. Ik kwam er destijds ook niet uit met de quibino (op basis van de schema's/handleiding). Dus maar voor het gemak gegaan.

[[RNMC] Viper]

Je zou bijna zeggen dat je de output van je thermostaat kunt gebruiken als input schakelaar op je qubino en dat je vloer op de Q van je qubino zetten en dan naar blauw doorschakelen, dan doet de qubino het werk en de thermostaat is schakelaar.

Zover ik het nu begrijp is de thermostaat een tijdschakelaar/ temperatuur schakelaar. Je vloer is de weerstand.

[ Voor 19% gewijzigd door [RNMC] Viper op 01-03-2017 20:43 ]

[PuckStar]

[RNMC] Viper schreef op woensdag 1 maart 2017 @ 20:42:
Je zou bijna zeggen dat je de output van je thermostaat kunt gebruiken als input schakelaar op je qubino en dat je vloer op de Q van je qubino zetten en dan naar blauw doorschakelen, dan doet de qubino het werk en de thermostaat is schakelaar.

Zover ik het nu begrijp is de thermostaat een tijdschakelaar/ temperatuur schakelaar. Je vloer is de weerstand.

Zoiets als dit bedoel je? http://imageshack.com/i/pm7jIS6rp
Maar er komt dus alleen stroom output van de thermostaat als die het te koud vind. dus dan zou ik die zo hoog moeten zetten dat die altijd aan staat, zodat vervolgens de qubino het nog zelf kan aansturen.
Maar dan ontgaat me het hele nut van de thermostaat en kan ik die er net zo goed helemaal tussen uithalen toch?

Ik zou toch denken dat ik net als met mijn rolluikschakelaar waar ik ook een qubino ernaast heb aangesloten en ik het zowel via zwave als de harde schakelaar het rolluik kan aansturen dit ook mogelijk zou moeten zijn met de vloerverwarming....

[tyfoon_2]

PuckStar schreef op woensdag 1 maart 2017 @ 21:56:
[...]

Maar dan ontgaat me het hele nut van de thermostaat en kan ik die er net zo goed helemaal tussen uithalen toch?

Daar kwam ik ook op uit; In principe heeft de Quibino alle intelligentie die je nodig hebt. Via automations aansturen en verder geen extra thermostaat nodig. Het enige extra dat de Heat-it boven de quibino heeft is een display en de kans om handmatig aan te passen. Ik kan je vertellen dat ik nooit handmatig de vloerverwarming van de badkamer verander. Vergeet niet dat als deze hoger zet het een paar uur kan duren voordat deze daadwerkelijk op deze temperatuur is. Hieronder mijn automation. Je ziet hij start om 3:00 en dan is ie om een uur of 7:00 ca 18-19 (tuurlijk afhankelijk van de buiten temp).

- alias: Bathroom heat on
initial_state: True
hide_entity: False
trigger:
platform: time
after: '03:00:00'
condition:
condition: and
conditions:
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
- sat
- sun
- condition: state
entity_id: input_boolean.summer
state: "off"
- condition: state
entity_id: input_select.Occupancy
state: "Home"
action:
- service: climate.set_temperature
entity_id: climate.badvloer_thermostat
data:
temperature: "22"

[PuckStar]

tyfoon_2 schreef op woensdag 1 maart 2017 @ 22:05:
[...]


Daar kwam ik ook op uit; In principe heeft de Quibino alle intelligentie die je nodig hebt. Via automations aansturen en verder geen extra thermostaat nodig. Het enige extra dat de Heat-it boven de quibino heeft is een display en de kans om handmatig aan te passen. Ik kan je vertellen dat ik nooit handmatig de vloerverwarming van de badkamer verander. Vergeet niet dat als deze hoger zet het een paar uur kan duren voordat deze daadwerkelijk op deze temperatuur is. Hieronder mijn automation. Je ziet hij start om 3:00 en dan is ie om een uur of 7:00 ca 18-19 (tuurlijk afhankelijk van de buiten temp).

- alias: Bathroom heat on
initial_state: True
hide_entity: False
trigger:
platform: time
after: '03:00:00'
condition:
condition: and
conditions:
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
- sat
- sun
- condition: state
entity_id: input_boolean.summer
state: "off"
- condition: state
entity_id: input_select.Occupancy
state: "Home"
action:
- service: climate.set_temperature
entity_id: climate.badvloer_thermostat
data:
temperature: "22"

Ja daar heb je wel een punt betreft vaak aan en uit zetten. Maar omdat ik las dat deze verwarming heel snel kan opwarmen dacht ik ok dan kan ik die ook wel 30min voordat ik in de ruimte ga zitten het ding aan zetten, en dus eventueel via de touchpad thermostaat.
Ik vroeg me trouwens nog af of het dan echt wel zo energiebesparend is als dit ding een paar uur iets van 600W trekt. Is stroom zoveel goedkoper dan gas? En omdat je met gas wel snel warmte krijgt.....

Hmm dus misschien toch zonde dat ik die 135 euro thermostaat erbij heb gekocht. Misschien kan ik die nog terug sturen.

Maar zou het fout (als in kortsluiting of stukmaken van de vloer) kunnen gaan als ik toch de output van de thermostaat op dezelfde draad aansluit als vanaf de qubino? Dus zoals in het eerste plaatje wat ik getekend had.

[ Voor 5% gewijzigd door PuckStar op 01-03-2017 22:38 ]

[tyfoon_2]

Nee, als je geld wilt besparen dan is een elektrische vloerverwarming niet de beste optie...Is dat je enige verwarming in die ruimte? Zoals je ziet in mijn automation gebruik ik hem alleen in de winter en als ik thuis ben. Onder de ca 15 graden voelt zon vloer echt koud ook al is de ruimte 20 of meer. Dan is het fijn. Zodra het warmer gaar worden buiten dan gaat ie uit.

[Yelti]

PuckStar schreef op woensdag 1 maart 2017 @ 21:56:
[...]

Zoiets als dit bedoel je? http://imageshack.com/i/pm7jIS6rp
Maar er komt dus alleen stroom output van de thermostaat als die het te koud vind. dus dan zou ik die zo hoog moeten zetten dat die altijd aan staat, zodat vervolgens de qubino het nog zelf kan aansturen.
Maar dan ontgaat me het hele nut van de thermostaat en kan ik die er net zo goed helemaal tussen uithalen toch?

Ik zou toch denken dat ik net als met mijn rolluikschakelaar waar ik ook een qubino ernaast heb aangesloten en ik het zowel via zwave als de harde schakelaar het rolluik kan aansturen dit ook mogelijk zou moeten zijn met de vloerverwarming....

Als je ze beiden wilt aansluiten moet je ze naast elkaar laten werken, dus allebei de weerstand laten aansturen.
Voor zover ik zie schakelt de qubino op temperatuur en heeft deze geen aan/uit(wel off/auto) functie waardoor je de thermostaat niet kan gebruiken als manuele schakeleaar.
Indien dit wel zo is(kan je snel uitproberen in HASS) zou je de thermostaat op I2 kunnen aansluiten en in hass de qubino laten aan/uit schakelen.

[[RNMC] Viper]

PuckStar schreef op woensdag 1 maart 2017 @ 21:56:
[...]

Zoiets als dit bedoel je? http://imageshack.com/i/pm7jIS6rp
Maar er komt dus alleen stroom output van de thermostaat als die het te koud vind. dus dan zou ik die zo hoog moeten zetten dat die altijd aan staat, zodat vervolgens de qubino het nog zelf kan aansturen.
Maar dan ontgaat me het hele nut van de thermostaat en kan ik die er net zo goed helemaal tussen uithalen toch?

Ik zou toch denken dat ik net als met mijn rolluikschakelaar waar ik ook een qubino ernaast heb aangesloten en ik het zowel via zwave als de harde schakelaar het rolluik kan aansturen dit ook mogelijk zou moeten zijn met de vloerverwarming....

Dit kan niet, die qubino heeft altijd line nodig om te kunnen reageren, en zover ik het bergijp schakelt die thermostaat de output uit zodra het warm genoeg is.

Yelti schreef op donderdag 2 maart 2017 @ 09:39:
[...]


Als je ze beiden wilt aansluiten moet je ze naast elkaar laten werken, dus allebei de weerstand laten aansturen.
Voor zover ik zie schakelt de qubino op temperatuur en heeft deze geen aan/uit(wel off/auto) functie waardoor je de thermostaat niet kan gebruiken als manuele schakeleaar.
Indien dit wel zo is(kan je snel uitproberen in HASS) zou je de thermostaat op I2 kunnen aansluiten en in hass de qubino laten aan/uit schakelen.

Dit idee had ik er ook bij, Qubino het werk laten doen en de thermostaat de qubino laten schakelen.

Maar zoals je al aangeeft, ik zou kijken om de thermostaat helemaal weg te doen (geld terug?) en dit stuk te automatiseren. De Qubino weet de temperatuur Hass je locatie, lekker combineren deze.

[PuckStar]

Yelti schreef op donderdag 2 maart 2017 @ 09:39:
[...]


Als je ze beiden wilt aansluiten moet je ze naast elkaar laten werken, dus allebei de weerstand laten aansturen.
Voor zover ik zie schakelt de qubino op temperatuur en heeft deze geen aan/uit(wel off/auto) functie waardoor je de thermostaat niet kan gebruiken als manuele schakeleaar.
Indien dit wel zo is(kan je snel uitproberen in HASS) zou je de thermostaat op I2 kunnen aansluiten en in hass de qubino laten aan/uit schakelen.

De qubino is wel een On/Off schakelaar. Dus volledig uit of volledig aan. Eigenlijk net als de thermostaat.

Ik heb ze nog eens gemaild met als voorstel dit schema: http://imageshack.com/i/pmzmjLhGj
En zijn reactie is het volgende:
Regarding to schematic you sent me it should work. In that case you could heat with both thermostats.
But before doing that you could speak with some electrician. Because I would recommend putting some relays inside this wiring, so outputs of thermostats would be insulated and not wired directly. Or fuses at the output of both thermostats
But still I cannot assure you this will work correctly in theory it should work
Nu weet ik niet of 1 van jullie begrijpt wat hij bedoelt en mij dat in gewoon Nederlands kan uitleggen?

Waarom ik me er nog niet helemaal bij wil neerleggen dat ik enkel met de Qubino zou werken is omdat ik het erg prettig vind om de thermostaat te kunnen regelen mocht er iets met zwave/home assistant zijn.
Net als dat ik nog een Dimmer knop heb voor de Hue lichten

[Yelti]

PuckStar schreef op donderdag 2 maart 2017 @ 15:55:
[...]

De qubino is wel een On/Off schakelaar. Dus volledig uit of volledig aan. Eigenlijk net als de thermostaat.

Ik heb ze nog eens gemaild met als voorstel dit schema: http://imageshack.com/i/pmzmjLhGj
En zijn reactie is het volgende:
Regarding to schematic you sent me it should work. In that case you could heat with both thermostats.
But before doing that you could speak with some electrician. Because I would recommend putting some relays inside this wiring, so outputs of thermostats would be insulated and not wired directly. Or fuses at the output of both thermostats
But still I cannot assure you this will work correctly in theory it should work
Nu weet ik niet of 1 van jullie begrijpt wat hij bedoelt en mij dat in gewoon Nederlands kan uitleggen?

Waarom ik me er nog niet helemaal bij wil neerleggen dat ik enkel met de Qubino zou werken is omdat ik het erg prettig vind om de thermostaat te kunnen regelen mocht er iets met zwave/home assistant zijn.
Net als dat ik nog een Dimmer knop heb voor de Hue lichten

Jij spreekt toch over ZMNHIA2 he, want er zijn vershillende thermostaten met verschillende mogelijkheden.
Zet gerust eens je volledige handleiding online.

Volgens mij gaat het ON/OFF over: OFF = relay uit, ON= regelen volgens ingestelde temperaturen en dus niet relais aan, een heel belangrijke nuance
Het is namelijk hierdoor dat je extra thermostaat niet kunt gebruiken als sturing.

ivm zijn uitleg:
Hij vertrouwt het niet 100% dat je 1 weerstand aanstuurt met 2 apparaten.
Daarom stelt hij voor om de Qubino en je thermostaat te gebruiken om een appart relais aan te sturen zodat er door de qubino en thermostaat geen hoge stromen lopen, een andere oplossing is gebruik maken van zekeringen, bij te hoge/verkeerde stromen/kortsluiting ( voor zo ver dit mogelijk is) gaat de zekering defect.

[-LA-]

Heeft iemand hier ervaring met de RFLink? Zoja, weet iemand hoe je die connection panel kan verbergen?

code:

rflink.connection_status:
  hidden: true

Werkt in ieder geval niet namelijk....

[Yelti]

-LA- schreef op dinsdag 7 maart 2017 @ 19:34:
Heeft iemand hier ervaring met de RFLink? Zoja, weet iemand hoe je die connection panel kan verbergen?

code:

rflink.connection_status:
  hidden: true

Werkt in ieder geval niet namelijk....

Kan je dit niet in een group stoppen en deze onzichtbaar maken?

[savale]

Ik draai HASS al vrijwel vanaf de eerste versies en het is ongelooflijk gaaf om te zien wat er allemaal weer bijgeklust wordt met iedere versie.
Mocht er interesse zijn:

ik heb een paar eigen modules gemaakt die draaien op mijn RPI HASS:
- klik aan klik uit support (heeft wel de kaku executable nodig)
- DS18B20 temp sensor module
- light sensor module voor RPI (weet even uit mijn hoofd niet welke sensor)
- example ssh command module

[nknoors]

savale schreef op woensdag 8 maart 2017 @ 14:43:
Mocht er interesse zijn:

ik heb een paar eigen modules gemaakt die draaien op mijn RPI HASS:
- klik aan klik uit support (heeft wel de kaku executable nodig)
- DS18B20 temp sensor module
- light sensor module voor RPI (weet even uit mijn hoofd niet welke sensor)
- example ssh command module

Ik heb zeker interesse, ben nu net aan het stoeien met kaku

[-LA-]

Yelti schreef op woensdag 8 maart 2017 @ 13:18:
[...]

Kan je dit niet in een group stoppen en deze onzichtbaar maken?

Heb al wat gevonden: https://github.com/home-assistant/home-assistant/pull/6475

[UltraSub]

Wat aan het klooien met een rest sensor voor Strava. Om het aantal rest calls te beperken dacht ik een sensor te maken die een json binnen krijgt, die vervolgens te hiden en met template sensors de verschillende benodigde velden eruit te parsen. Maar ik krijg het niet voor elkaar.

code:

{{ states.sensor.strava_ultrasub.state }}

Retourneert:

JSON:

{
  "biggest_ride_distance": value,
  "biggest_climb_elevation_gain": value,
  "recent_ride_totals": {
    "count": value,
    "distance": value,
    "moving_time": value,
    "elapsed_time": value,
    "elevation_gain": value,
    "achievement_count": value
  },
  <snip>
}

code:

{{ states.sensor.strava_ultrasub.state.biggest_ride_distance }}

Empty result

value_json er voor; unknown value_json
payload_json er in; ook unknown

Voor Domoticz bijvoorbeeld doe ik het met value_json, maar dat zijn geen template sensors maar echt rest sensors:

code:

{{ value_json.result[0].CounterToday.split()[0] }}

Wat zie ik hier over het hoofd? Ik begin te vermoeden dat die state die ik terug krijg wordt gezien als een string en niet als json.

code:

{{ states.sensor.strava_ultrasub.state[10] }}

Retourneert de 11e value in de result set namelijk.

[savale]

nknoors schreef op woensdag 8 maart 2017 @ 16:20:
[...]

Ik heb zeker interesse, ben nu net aan het stoeien met kaku

eerst moet je zorgen dat je de kaku executable hebt gebouwd:
Maybe, just maybe, someone cares.: Lampen schakelen met een Raspberry Pi

en zet deze vervolgens in /usr/local/bin

dan moet je deze file aanmaken:
/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/kaku.py

code:

""" Demo platform that has two fake switches. """
from homeassistant.components.switch import SwitchDevice
from homeassistant.const import DEVICE_DEFAULT_NAME
import os

# pylint: disable=unused-argument
def setup_platform(hass, config, add_devices_callback, discovery_info=None):
    """ Find and return demo switches. """
    add_devices_callback([
        KakuSwitch(config, False)
    ])


class KakuSwitch(SwitchDevice):
    """ Provides a demo switch. """
    def __init__(self, config, state):
        self._name = config.get("name")
        self._state = state
        self.switch_id = config.get("switch_id")

    @property
    def should_poll(self):
        """ No polling needed for a demo switch. """
        return False

    @property
    def name(self):
        """ Returns the name of the device if any. """
        return self._name

    @property
    def current_power_mwh(self):
        """ Current power usage in mwh. """
        if self._state:
            return 100

    @property
    def today_power_mw(self):
        """ Today total power usage in mw. """
        return 1500

    @property
    def is_on(self):
        """ True if device is on. """
        return self._state

    def turn_on(self, **kwargs):
        """ Turn the device on. """
        self._state = True
        self.update_ha_state()
        os.system("kaku M " + str(self.switch_id) + " on")
        os.system("kaku M " + str(self.switch_id) + " on")

    def turn_off(self, **kwargs):
        """ Turn the device off. """
        self._state = False
        self.update_ha_state()
        os.system("kaku M " + str(self.switch_id) + " off")
        os.system("kaku M " + str(self.switch_id) + " off")

vervolgens deze entry in je configuration.yaml

code:

switch:
  platform: kaku
  name: schakelaar
  switch_id: 11

de naam kun je zelf aanpassen en met het switch id kun je ze uit elkaar houden. En tada je kan je klik aan klik uit bedienen vanuit hass

[nknoors]

Thx!

[ThinkPad]

Wat gebruik je dan als een transmitter? Want bovenstaande is toch niet nodig als je een RFXcom gebruikt Dan kun je switch.rfxtrx gebruiken.

[-LA-]

...of switch.rflink, ben je er ook voor 4 tientjes

(https://www.nodo-shop.nl/nl/21-rflink-gateway)

[sompie1]

als je een nieuwe component aanmaakt is het ook beter dat je deze in je eigen config folder maakt en dus niet in /usr/local/lib/python3.4/dist-packages/homeassistant/components/switch
Je maakt gewoon in je .homeassistant folder een nieuwe map /custom_components/switch en daar zet je je nieuwe component in.
Anders als je hass update is je component weg

[Verwijderd]

sompie1 schreef op donderdag 9 maart 2017 @ 13:12:
als je een nieuwe component aanmaakt is het ook beter dat je deze in je eigen config folder maakt en dus niet in /usr/local/lib/python3.4/dist-packages/homeassistant/components/switch
Je maakt gewoon in je .homeassistant folder een nieuwe map /custom_components/switch en daar zet je je nieuwe component in.
Anders als je hass update is je component weg

Hoewel dat in 99.99% van de gevallen de juiste keus is, was het ook altijd zo dat een custom_component geen discovery kan gebruiken. Zou kunnen dat het ondertussen veranderd is, die wie weet praat ik poep.

Ik meen ook altijd dat de custom_components voor de HA eigen code gaan, dus dan kun je aanpassingen maken aan hun eigen code.

[ThinkPad]

Ik heb een rule om mijn verlichting aan te zetten bij beweging + lux onder grenswaarde. Ik zou daarin graag de brightness van Hue lampen mee willen geven. Ik heb dit geprobeerd:

YAML:

action:
  - service: light.turn_on
    entity_id: light.hue_lamp_1
    brightness: 115
  - service: light.turn_on
    entity_id: light.hue_lamp_2
    brightness: 115

Maar dan kreeg ik een foutmelding (exacte melding weet ik niet meer, het was iets dat brightness daar niet gebruikt mocht worden).

Ik heb het nu via een scene lopen, in de scene geef ik de brightness mee en in de rule roep ik dan de scene aan, maar dat heeft als nadeel dat de scene elke keer wordt aangeroepen als we even stil hebben gezeten en er weer motion is. Als je de lamp dus handmatig naar een lagere waarde dimt, dan springt hij telkens weer terug, heel irritant.

Iemand een idee hoe ik éénmalig die brightness mee kan geven en hij daarna de aangepaste waarde wel in tact laat en pas bij een volgende keer (volgende avond) die originele brightness weer pakt? Of zou ik het kunnen voorkomen door wel met scene te werken en in de rule te controleren of de lamp uit staat? Als de lamp dan aan staat voert hij de brightness dan niet opnieuw door lijkt mij.

[ Voor 3% gewijzigd door ThinkPad op 10-03-2017 11:09 ]

[Verwijderd]

ThinkPadd schreef op vrijdag 10 maart 2017 @ 11:08:
...

code:

condition:
 staat lamp 1 uit en/of lamp 2 uit
  action:
    service: light.turn_on
    entity_id:
      - light.lamp1
      - light.lamp2
    data:
      brightness: 150
      rgb_color: [255, 0, 0]

Volgens mij moet er een 'data' tussen.

[ThinkPad]

Thanks @Verwijderd.

En stel dat lamp1 op 150 moet en lamp2 op 87 ? Dan zit ik wel aan een scene vast denk ik?

[lolgast]

ThinkPadd schreef op vrijdag 10 maart 2017 @ 11:18:
Thanks @Verwijderd.

En stel dat lamp1 op 150 moet en lamp2 op 87 ? Dan zit ik wel aan een scene vast denk ik?

Of 2 actions onder elkaar zetten . Maar mijn voorkeur zou dan uitgaan naar een scene, dan blijft het wat overzichtelijker vind ik persoonlijk

[Verwijderd]

ThinkPadd schreef op vrijdag 10 maart 2017 @ 11:18:
Thanks @Verwijderd.

En stel dat lamp1 op 150 moet en lamp2 op 87 ? Dan zit ik wel aan een scene vast denk ik?

Twee acties inderdaad. Scene kan ook.

Ik ben voorkeur om het in de regels te houden en geen scenes. Vind ik overzichtelijker. Als het niet werkt, of niet zo werkt als ik verwacht is mijn eerste insteek toch om in de regel te kijken en niet in de scene.

Maar aangezien het om hue lampen gaat, zou ik de bridge het verzoek rechtstreeks sturen. Dan gaan je lampen tegelijk aan. HA stuurt ze afzonderlijk aan, dat merk je misschien nog niet met twee lampen maar met meerdere wel.

[breinonline]

Ik heb gisteren de Rasberry Pi 3 opnieuw geïnstalleerd. Ik had al eerder een poging gedaan de bestaande installatie te draaien volledig van USB stick, maar dat mislukte. Daarnaast liep de database steeds vol en wilde ik daarom SQLite verlaten en MySQL installeren maar ook dat wilde niet lukken. Daarom ben ik overnieuw begonnen met een Raspbian installatie met losse HASS installatie. Dat ging verassend goed (heb ik voorheen ook 3x geprobeerd en ging op de een of andere manier mis). Ik draai nu de PI3, zonder miniSD kaart, volledig van USB stick.

Toen liep ik ertegenaan dat niet alles uit de (gekopieerde) oude installatie werkte. De standaard MQTT wilde niet werken (foutmelding) wat het voorheen wel deed. Daardoor kreeg ik een paar statusgegevens van de Pi niet in beeld. Dat dacht ik op te lossen door mosquitto te installeren (en dat is gelukt) maar nu krijg ik een foutmelding over de sensors. Ik snap niet waar het mis gaat, voorheen werkte het wel. Ik heb nu het volgende staan:

configuration.yaml

YAML:

sensor:
- platform: systemmonitor
  resources:
    - type: memory_use_percent
    - type: processor_use

groups.yaml

YAML:

  RaspberryPi:
    name: Raspberry Pi status
    entities:
      - sensor.cpu_use
      - sensor.cpu_temperature
      - sensor.ram_use

De foutmelding is de volgende:


Iemand een idee wat er mis zou kunnen gaan?

[ThinkPad]

Kijk eens op de commandline of je daar fouten ziet (met journalctl kun je volgen wat HASS uitspuugt). Het precieze commando weet ik niet precies voor de Pi, bij mij is het journalctl -f -u hass | grep ERROR

---

Vraagje, ik ben bezig om mijn Itho ventilatiebox in HASS aan te sturen over MQTT, nu ben ik bezig met een input_select maar hij respecteert de initial waarde niet. Als ik HASS herstart, dan staat de dropdown gewoon weer op de waarde die ik als laatste gekozen had.

YAML:

itho_ventilatie:
  name: Ventilatiesnelheid
  options:
   - Laag
   - Middel
   - Hoog
  initial: Laag
  icon: mdi:fan

Hij moet dus naar 'Laag' gaan na een herstart van HASS, maar als ik 'Middel' kies en HASS herstart, dan staat hij nog steeds op 'Middel'.

Iemand een idee wat ik verkeerd doe? De rules die ik aan de input_select gekoppeld heb, zijn tijdelijk verwijderd. Zelfs met alleen bovenstaande pakt hij dus die initial al niet. Er is geen MQTT met retain o.i.d.

[ Voor 17% gewijzigd door ThinkPad op 12-03-2017 09:52 ]

[Verwijderd]

ThinkPadd schreef op zondag 12 maart 2017 @ 09:48:...

Hij moet dus naar 'Laag' gaan na een herstart van HASS, maar als ik 'Middel' kies en HASS herstart, dan staat hij nog steeds op 'Middel'.

Iemand een idee wat ik verkeerd doe? De rules die ik aan de input_select gekoppeld heb, zijn tijdelijk verwijderd. Zelfs met alleen bovenstaande pakt hij dus die initial al niet. Er is geen MQTT met retain o.i.d.

Zou het aan de nieuwe (v0.39) State restoration kunnen liggen?

[ThinkPad]

Verwijderd schreef op zondag 12 maart 2017 @ 10:48:
[...]


Zou het aan de nieuwe (v0.39) State restoration kunnen liggen?

Goed gevonden. Helaas kan ik nergens vinden hoe ik dat voor deze input_select dan uit moet zetten Je zou verwachten dat hij die initial wel respecteert, maar dat doet hij dus niet.

[breinonline]

ThinkPadd schreef op zondag 12 maart 2017 @ 09:48:
Kijk eens op de commandline of je daar fouten ziet (met journalctl kun je volgen wat HASS uitspuugt). Het precieze commando weet ik niet precies voor de Pi, bij mij is het journalctl -f -u hass | grep ERROR

No journal files were found

Upgrade naar 0.40 levert een nieuwe entry in de log op:

Unable to prepare setup for platform sensor.systemmonitor: Could not install all requirements.

Maar dat geeft mij eerlijk gezegd geen beter aanknopingspunt....

[ Voor 23% gewijzigd door breinonline op 12-03-2017 14:32 ]

[wmn79]

breinonline schreef op zondag 12 maart 2017 @ 13:54:
[...]

No journal files were found

Upgrade naar 0.40 levert een nieuwe entry in de log op:

[...]
Maar dat geeft mij eerlijk gezegd geen beter aanknopingspunt....

Je had niet toevallig een sensor systemmonitor in je configuratie die ook keek naar de MicroSD oid? Dat doordat die weg is die niet meer weergegeven kan worden?

[breinonline]

Nee, alleen RAM usage, cpu temp + usage.

Inmiddels heb ik een andere fout opgelost en heb er een andere aanwijzing voor terug in de log:

Not initializing sensor.systemmonitor because could not install dependency psutil==5.1.3

. Dat klinkt wat concreter, ga eens even googlen of ik daar wat mee kan.

update: sudo apt-get install python-psutil werkt wel om wat te installeren, maar lost het probleem niet op.

[ Voor 15% gewijzigd door breinonline op 12-03-2017 20:56 ]

[ThinkPad]

Verwijderd schreef op zondag 12 maart 2017 @ 10:48:
[...]


Zou het aan de nieuwe (v0.39) State restoration kunnen liggen?

Gelukt. Extra rule gemaakt die bij herstart van HASS de input_select op 'Laag' zet:

YAML:

alias: Ventilatie op laag bij herstart HASS
trigger:
  platform: event
  event_type: homeassistant_start
action:
  service: input_select.select_option
  data:
    entity_id: input_select.itho_ventilatie
    option: Laag

Bedankt @infernix voor de tip

[ Voor 11% gewijzigd door ThinkPad op 12-03-2017 21:05 ]

[UltraSub]

Maar waarom wil je dat eigenlijk? Is toch juist handig als je restart en hij komt terug met de waarde voor restart?

[ThinkPad]

Omdat de Itho geen terugkoppeling naar HASS geeft over de juiste stand, het is 'fire-and-forget' met die transmitter.
Met deze automation weet ik altijd dat hij teruggaat naar 'Laag' als HASS start. Na een paar seconden zal hij op de MQTT-bus een waarde doorkrijgen van de CO₂-sensor en zal een rule triggeren om hem op de juiste snelheid behorende bij die luchtkwaliteit te zetten

[UltraSub]

Okidoki!

[PuckStar]

nknoors schreef op woensdag 8 maart 2017 @ 23:35:
Thx!

Of dit:

YAML:

switch:
  - platform: rpi_rf
    gpio: 17
    switches:
      kaku1:
        code_on: 1048597
        code_off: 1048596

Als je zoiets aansluit:https://www.aliexpress.com/item/1set-RF-module-433-Mhz-superheterodyne-receiver-and-transmitter-Support-ASK-OOK-small-size-low-power/32571703475.html

Ik weet niet precies wat die executable en al die stappen die savale noemt allemaal als voordeel heeft, maar ik heb het dus vrij simpel opgezet door die dingen aan te sluiten en voor het Zend gedeelte die code in de config gezet.

[BROSSIE]

Ik heb een probleem en ik kom er niet achter waar ik de fout maak.
Ik heb een lamp die op een bepaald moment aangaat op basis van de stand van de zon. Uit gaat op basis van de stand van de zon. Alleen dat uitgaan van de lamp mag alleen uitgaan na 7.15 en gaat altijd uit na 8.15.

YAML:

- alias: 'Lamp oprit aan'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    below: 1.5
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'off'
      - condition: time
        after: '16:00:00'
        before: '21:30:00'
  action:
    service: switch.turn_on
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit 7-8'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    above: 1
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'on'
      - condition: time
        after: '07:15:00'
        before: '08:15:00'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit na 8:15'
  trigger:
    platform: time
    after: '08:15:00'
  condition: 
    condition: state
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
    state: 'on'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

's ochtends gaat de lamp niet uit. Iemand een idee wat ik hier fout doe?

[PuckStar]

BROSSIE schreef op dinsdag 14 maart 2017 @ 22:33:
Ik heb een probleem en ik kom er niet achter waar ik de fout maak.
Ik heb een lamp die op een bepaald moment aangaat op basis van de stand van de zon. Uit gaat op basis van de stand van de zon. Alleen dat uitgaan van de lamp mag alleen uitgaan na 7.15 en gaat altijd uit na 8.15.

YAML:

- alias: 'Lamp oprit aan'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    below: 1.5
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'off'
      - condition: time
        after: '16:00:00'
        before: '21:30:00'
  action:
    service: switch.turn_on
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit 7-8'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    above: 1
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'on'
      - condition: time
        after: '07:15:00'
        before: '08:15:00'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit na 8:15'
  trigger:
    platform: time
    after: '08:15:00'
  condition: 
    condition: state
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
    state: 'on'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

's ochtends gaat de lamp niet uit. Iemand een idee wat ik hier fout doe?

EDIT: nevermind. ik zal effe verder nadenken

Je kan in ieder geval deze condition er uit halen want wat maakt het uit of de lamp al uit zou staan.
condition:
condition: state
entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
state: 'on'

Ik zie dat ik switches op deze manier doe:

YAML:

    - service: switch.turn_off
      data: 
        entity_id: switch.xxxx

Dus misschien kun je dat ook proberen met data: enzo.

[ Voor 11% gewijzigd door PuckStar op 14-03-2017 23:26 ]

[Verwijderd]

BROSSIE schreef op dinsdag 14 maart 2017 @ 22:33:
Ik heb een probleem en ik kom er niet achter waar ik de fout maak.
Ik heb een lamp die op een bepaald moment aangaat op basis van de stand van de zon. Uit gaat op basis van de stand van de zon. Alleen dat uitgaan van de lamp mag alleen uitgaan na 7.15 en gaat altijd uit na 8.15.

Wat is precies je doel met deze regels? Ik vind het wat aparte regels.Ik neem aan dat je met de elevation een bepaald licht niveau wil bereiken zodat je voorkomt dat de lampen te vroeg/te laat aangaan.

Hoe het lijkt op mij is:

• Als je tussen 16:00 en 21:30 een bepaald lichtniveau bereikt (door de stand van de zon) dag mag een lamp aan gaan, die dan de hele nacht aan staat.
• Bereikt het lichtniveau tussen 16:00 en 21:30 niet het gewenste niveau gaat de lamp nooit aan
• Tussen 7:15 en 8:15 mag die alleen uit (mocht die aanstaan) en lichtniveau X
• Na 8:15 moet de lamp uit, mocht hij aanstaan. Ongeacht het lichtniveau.

Ik ben nieuwsgierig wat je wilt bereiken. Ik zou verwachten iets als: als het donker wordt lamp, wordt het licht lamp uit.. maar lamp mag hoe dan ook om 8.15 uit?

[UltraSub]

Fibaro keyfob aangeschaft. Met de recente pull requests op openzwave is die supported. Werkt ook. However, No value assigned als je een knop in drukt. Verder gezocht, blijkt dat zwave scène support toch nog behoorlijk kinderschoenties verhaal is in openzwave.

https://github.com/OpenZWave/open-zwave/pull/1125
Python-openzwave opnieuw gepulled, bovenstaande patches erin, recompile. Zelfde issue:

code:

2017-03-14 20:46:14.888 Detail, Node020,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x14, 0x02, 0x98, 0x40, 0x3d
2017-03-14 20:46:14.888 Info, Node020, Received SecurityCmd_NonceGet from node 20
2017-03-14 20:46:14.888 Info, NONCES: 0x1c, 0x9a, 0x4b, 0xee, 0x59, 0x3e, 0x6b, 0x53
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, NONCES: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
2017-03-14 20:46:14.888 Info, Node020, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x14, 0x0a, 0x98, 0x80, 0x1c, 0x9a, 0x4b, 0xee, 0x59, 0x3e, 0x6b, 0x53, 0x05, 0x01, 0x83:
2017-03-14 20:46:14.897 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2017-03-14 20:46:14.897 Detail,   ZW_SEND_DATA delivered to Z-Wave stack
2017-03-14 20:46:14.913 Detail,   Received: 0x01, 0x07, 0x00, 0x13, 0x01, 0x00, 0x00, 0x02, 0xe8
2017-03-14 20:46:14.914 Detail,   ZW_SEND_DATA Request with callback ID 0x01 received (expected 0x01)
2017-03-14 20:46:14.934 Detail, Node020,   Received: 0x01, 0x1f, 0x00, 0x04, 0x00, 0x14, 0x19, 0x98, 0x81, 0xe7, 0x5c, 0xda, 0x19, 0x07, 0x9c, 0xe0, 0x05, 0x8a, 0x85, 0xf4, 0x02, 0xe3, 0x67, 0x1c, 0x38, 0x47, 0x22, 0x0c, 0x31, 0x44, 0x8a, 0x25, 0x1c
2017-03-14 20:46:14.934 Info, Raw: 0x98, 0x81, 0xe7, 0x5c, 0xda, 0x19, 0x07, 0x9c, 0xe0, 0x05, 0x8a, 0x85, 0xf4, 0x02, 0xe3, 0x67, 0x1c, 0x38, 0x47, 0x22, 0x0c, 0x31, 0x44, 0x8a, 0x25, 0x1c
2017-03-14 20:46:14.934 Detail, Node020, Decrypted Packet: 0x00, 0x5b, 0x03, 0x08, 0x80, 0x02
2017-03-14 20:46:14.934 Detail, 
2017-03-14 20:46:14.934 Info, Node020, Received Central Scene set from node 20: scene id=2 in 7680 seconds. Sending event notification.
2017-03-14 20:46:14.934 Warning, Node020, No ValueID created for Scene 2

Valt me sowieso op dat python-openzwave niet echt actief te noemen is

[thrust15]

BROSSIE schreef op dinsdag 14 maart 2017 @ 22:33:
Ik heb een probleem en ik kom er niet achter waar ik de fout maak.
Ik heb een lamp die op een bepaald moment aangaat op basis van de stand van de zon. Uit gaat op basis van de stand van de zon. Alleen dat uitgaan van de lamp mag alleen uitgaan na 7.15 en gaat altijd uit na 8.15.

YAML:

- alias: 'Lamp oprit aan'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    below: 1.5
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'off'
      - condition: time
        after: '16:00:00'
        before: '21:30:00'
  action:
    service: switch.turn_on
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit 7-8'
  trigger:
    platform: numeric_state
    entity_id: sun.sun
    value_template: '{{ state.attributes.elevation }}'
    above: 1
  condition: 
    condition: and
    conditions:
      - condition: state
        entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
        state: 'on'
      - condition: time
        after: '07:15:00'
        before: '08:15:00'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

- alias: 'Lamp oprit uit na 8:15'
  trigger:
    platform: time
    after: '08:15:00'
  condition: 
    condition: state
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
    state: 'on'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

's ochtends gaat de lamp niet uit. Iemand een idee wat ik hier fout doe?

De trigger triggered alleen op een state change van onder naar boven de threshold (in jouw geval zon stand) komt. De trigger is waarschijnlijk al geweest. De automation is alleen niet uitgevoerd door je condition waardoor hij alleen op je tweede automation triggered (die om 08:15:00).
Dus eigenlijk moet je 2 triggers definiëren, 1 op 07:15, en 1 op elevation. Met after 07:14:59 als condition en ook sun elevation als condition.

Je tweede automation dat hij sowieso uitmoet om 08:15:00 heb je ook nodig

YAML:

 
- alias: 'Lamp oprit uit 7-8'
  trigger:
    - platform: template
      value_template: '{{states.sun.sun.attributes.elevation > 1}}'
    - platform: time
      after: '07:15:00'
  condition: 
    condition: and
    conditions:
      - condition: time
        after: '07:14:59'
        before: '08:15:00'
      - condition: template
        value_template: '{{states.sun.sun.attributes.elevation >= 1}}'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

Ik heb sun even als template gedaan omdat ik daar zelf handiger mee ben

[BROSSIE]

Verwijderd schreef op woensdag 15 maart 2017 @ 06:41:
[...]


Wat is precies je doel met deze regels? Ik vind het wat aparte regels.Ik neem aan dat je met de elevation een bepaald licht niveau wil bereiken zodat je voorkomt dat de lampen te vroeg/te laat aangaan.

Hoe het lijkt op mij is:

• Als je tussen 16:00 en 21:30 een bepaald lichtniveau bereikt (door de stand van de zon) dag mag een lamp aan gaan, die dan de hele nacht aan staat.
• Bereikt het lichtniveau tussen 16:00 en 21:30 niet het gewenste niveau gaat de lamp nooit aan
• Tussen 7:15 en 8:15 mag die alleen uit (mocht die aanstaan) en lichtniveau X
• Na 8:15 moet de lamp uit, mocht hij aanstaan. Ongeacht het lichtniveau.

Ik ben nieuwsgierig wat je wilt bereiken. Ik zou verwachten iets als: als het donker wordt lamp, wordt het licht lamp uit.. maar lamp mag hoe dan ook om 8.15 uit?

Het doel is precies zoals je beschreven hebt, alleen moet ik nog een regel toevoegen voor als de lamp om 21:30 nog niet aan staat om deze aan te zetten. Echter kwam ik er achter dat de lamp niet uit ging, heb ik deze regel nog niet gemaakt.

PuckStar schreef op dinsdag 14 maart 2017 @ 23:15:
[...]

EDIT: nevermind. ik zal effe verder nadenken

Je kan in ieder geval deze condition er uit halen want wat maakt het uit of de lamp al uit zou staan.
condition:
condition: state
entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0
state: 'on'

Ik zie dat ik switches op deze manier doe:

YAML:

    - service: switch.turn_off
      data: 
        entity_id: switch.xxxx

Dus misschien kun je dat ook proberen met data: enzo.

Bedankt voor het mee denken

thrust15 schreef op woensdag 15 maart 2017 @ 10:26:
[...]


De trigger triggered alleen op een state change van onder naar boven de threshold (in jouw geval zon stand) komt. De trigger is waarschijnlijk al geweest. De automation is alleen niet uitgevoerd door je condition waardoor hij alleen op je tweede automation triggered (die om 08:15:00).
Dus eigenlijk moet je 2 triggers definiëren, 1 op 07:15, en 1 op elevation. Met after 07:14:59 als condition en ook sun elevation als condition.

Je tweede automation dat hij sowieso uitmoet om 08:15:00 heb je ook nodig

YAML:

 
- alias: 'Lamp oprit uit 7-8'
  trigger:
    - platform: template
      value_template: '{{states.sun.sun.attributes.elevation > 1}}'
    - platform: time
      after: '07:15:00'
  condition: 
    condition: and
    conditions:
      - condition: time
        after: '07:14:59'
        before: '08:15:00'
      - condition: template
        value_template: '{{states.sun.sun.attributes.elevation >= 1}}'
  action:
    service: switch.turn_off
    entity_id: switch.fibaro_system_fgs223_double_relay_switch_2_0

Ik heb sun even als template gedaan omdat ik daar zelf handiger mee ben

Ik ga dit eens uitproberen. Het klnkt wel logisch als de automation alleen triggered als hij boven de triggerwaarde komt. Bedankt.

[Verwijderd]

BROSSIE schreef op woensdag 15 maart 2017 @ 15:42:

Waarom niet gewoon < elevation x lamp aan, hoger dan elevation y lamp uit?

Die paar watt die je wint met de lamp later aan/uit te zetten is te verwaarlozen denk ik en zo maakt het de regeltjes heel wat eenvoudiger.

[BROSSIE]

Verwijderd schreef op woensdag 15 maart 2017 @ 15:54:
[...]


Waarom niet gewoon < elevation x lamp aan, hoger dan elevation y lamp uit?

Die paar watt die je wint met de lamp later aan/uit te zetten is te verwaarlozen denk ik en zo maakt het de regeltjes heel wat eenvoudiger.

Dat maakt het leven wel makkelijker, echter is daarnaast het doel om ook een stukje veiligheid te creeren door aanwezigheid te simuleren.

[PuckStar]

BROSSIE schreef op woensdag 15 maart 2017 @ 17:15:
[...]


Dat maakt het leven wel makkelijker, echter is daarnaast het doel om ook een stukje veiligheid te creeren door aanwezigheid te simuleren.

Doordat elevation elke dag anders is simuleer je al aardig aanwezigheid. Immers het zal niet elke dag exact om dezelfde tijd aan en uit gaan. En dat is juist waar dieven op zouden kunnen letten.

[Verwijderd]

BROSSIE schreef op woensdag 15 maart 2017 @ 17:15:
[...]


Dat maakt het leven wel makkelijker, echter is daarnaast het doel om ook een stukje veiligheid te creeren door aanwezigheid te simuleren.

Volgens mij moet dit werken.

code:

  trigger:
  - elevation shizzle. 
  action:
  - delay: '00:{{ (range(10, 30)|random|int) }}:00'
  - service: switch.turn_on
    entity_id: switch.mijnlampje

code:

  trigger:
  - elevation shizzle. 
  action:
  - delay: '00:{{ (range(10, 30)|random|int) }}:00'
  - service: switch.turn_off
    entity_id: switch.mijnlampje

[breinonline]

breinonline schreef op zondag 12 maart 2017 @ 20:44:
Nee, alleen RAM usage, cpu temp + usage.

Inmiddels heb ik een andere fout opgelost en heb er een andere aanwijzing voor terug in de log:

[...]
. Dat klinkt wat concreter, ga eens even googlen of ik daar wat mee kan.

update: sudo apt-get install python-psutil werkt wel om wat te installeren, maar lost het probleem niet op.

Oplossing gevonden in deze post. Handmatig psutil installeren werkte

[UltraSub]

Iemand die AppleTV aan de gang heeft op 0.40.0? Die push functionaliteit is hier kapot. Werkte eerder goed (0.38.2). Omdat het historisch gezien erg lang duurde voor er een 0.40.1 was dacht ik dat er weinig bugs waren in deze release. Nu maar even disabled en een topic ingeschoten, gebruikte het niet echt. Die devver fixed dat wel ff

Kodi ook weer eens ff geprobeerd vandaag maar die doet hier hetzelfde als toen ik begon met 0.34 nog wat; zegt altijd "off".