:fill(white):strip_exif()/i/2002871478.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2001890515.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2006976478.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000583077.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000809464.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000629918.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2002131643.jpeg?f=thumbmini)
Dat valt wel mee. Wat ik vaak deed is mijn code in 'custom_components' plaatsen en zodoende wordt het prima geladen. Dit gaat voor de code van HA zelf, in geval van dezelfde naamgeving.ANdrode schreef op zaterdag 31 december 2016 @ 16:30:
[...]
Daarnaast vind ik het wennen dat alle plugins deel zijn van home assistant. Het is lastig om een third party module te installeren.
:strip_exif()/u/85127/Iron-Man-Avatar_small.gif?f=community){kind=avatar}
Eens, maar dat komt vanzelf. Je ziet nu al dat de initial versies van influxdb component zijn geschreven om snel integratie te hebben, maar inderdaad niet door een expert. Degene met het pull request nu heeft er duidelijk meer verstand van. Is gewoon een kwestie van tijd, en inherent aan open source met deze ontwikkelsnelheid.
Nee, dat is goed afgehandeld. Custom_components. Wat je daar neer zet wordt gewoon ingelezen. Third party modules? Als die er zijn, zoals je nu waarschijnlijk bedoeld, dan zou dat raar zijn. Waarom wordt er dan geen pull request gemaakt om die module te distribueren? Waarschijnlijk omdat ze niet door de CI tests heen komen
En dan moet je je afvragen of je ze wel wil draaien als het zo slecht is. Maar goed, je hebt het in eigen hand met hass, als jij het wil, zet het in custom_components en ze worden gewoon geladen. Als je er een aangepaste versie in zet van iets wat standaard ook al in hass zit, dan overruled de versie in custom_components de gedistribueerde versie overigens.Dat doen ze toch? Pas als er iets in de config wordt gezet wat een component aanspreekt trekken ze het automatisch binnen, inclusief dependencies met de juiste versies.
Een voorbeeld, dsmr.py:
Python:
1
| REQUIREMENTS = ['dsmr_parser==0.4'] |
Zodra je in je config - platform: dsmr gebruikt wordt dsmr.py aangesproken, wat vervolgens de dependencies afhandelt.
Wat vind je dan een bende, de manier zoals het gaat werken in de nieuwe situatie (neem dan even mee waar het vandaan komt en hoe seriously broken het daar nu is) of bedoel je code technisch?
Tsja.. Dat ga je houden met database integraties. Het project is zo jong, je kunt nu nog niet alles voorzien en het er meteen in verwerken. Je gaat 200% zeker tegen refactoring aanlopen, en zodra het niet stateless is kan dat een keer pijn gaan doen, zoals nu.
De andere optie is 2 jaar vooruit proberen te kijken in de tijd, maar dat gaat je nooit lukken. Als je zo vroeg in een project stapt dat zo snel gaat (en dat gaat zo hard omdat ze dus niet bang zijn voor een refactor, en agile werken) dan moet je beseffen dat het links en rechts een keer pijn kan gaan doen.
[ Voor 3% gewijzigd door UltraSub op 01-01-2017 16:03 ]
:strip_icc():strip_exif()/u/31772/crop601c5b0229c42_cropped.jpeg?f=community)
/u/27131/crop61572b353fff1_cropped.png?f=community)
En post het geheel dan even in een yaml-code blok op het forum. Spaties in de uitlijning kunnen ook een hoop ellende veroorzaken, dat kunnen we nu niet nagaan 
WP: Mitsubishi Ecodan PUHZ-SHW112YAA, ERSC-VM2C, Procon ┃ PV: 4800Wp, SolarEdge SE5K, 15x JAM60S17/320, ZW 15º ┃ WTW: Zehnder Q600 ┃ SH: Home Assistant, Proxmox, Intel NUC 8i5 Mini
/u/226077/crop5ef8bc098bbf3_cropped.png?f=community)
Gisteren avond de stoute schoenen aangetrokken en na eerste een image getrokken te hebben van de sd card met win32 disk imager, heb ik de hassbian image erop gegooid.
Installatie op die manier werkte feilloos.
Echter ben ik even daarna toch weer terug gegaan naar Domoticz, ik heb daarin al het een en ander gebouwd voor automatisering en daarnaast ook wat switches om bijvoorbeeld me pc en tv aan/uit te zetten.
Hoe ik dit ging doen kon ik niet zo snel vinden in HA.
Het was dan ook al vrij laat, en wou gewoon "welterusten" zeggen tegen siri
Nu heb ik me net wat meer in zitten lezen en het moet toch allemaal wel mogelijk zijn.
Daarom ben ik op dit moment toch weer HA op de sd card aan het zetten
Wat mij overigens op viel is dat elke keer als HA start, hij opnieuw de Nest package probeert te installeren.
Iemand enig idee waarom hij dit doet?
Edit:
Dit zie ik in de console voorbij komen elke keer als HA opstart:
code:
1
2
3
| Jan 05 12:15:43 raspberrypi hass[1105]: 17-01-05 12:15:43 INFO (Thread-1) [homeassistant.util.package] Attempting install of http://github.com/technicalpickles/python- nest/archive/e6c9d56a8df455d4d7746389811f2c1387e8cb33.zip#python-nest==3.0.3 |
[ Voor 13% gewijzigd door Fonta op 05-01-2017 12:17 ]
:strip_icc():strip_exif()/u/8817/DSC05697_70x70-2.jpg?f=community)
Ik vind Athom er ook interessant uit zien echter:
1. ik vind het best prijzig
2. als ik lees dat bijv. de RF afstand erg beperkt is ben ik toch blij dat ik erg een goeie RF zender en ontvanger van maar een paar dollar heb aangesloten op mijn pi.
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.
[ Voor 16% gewijzigd door PuckStar op 05-01-2017 12:31 ]
WP: Mitsubishi Ecodan PUHZ-SHW112YAA, ERSC-VM2C, Procon ┃ PV: 4800Wp, SolarEdge SE5K, 15x JAM60S17/320, ZW 15º ┃ WTW: Zehnder Q600 ┃ SH: Home Assistant, Proxmox, Intel NUC 8i5 Mini
:strip_icc():strip_exif()/u/54837/falling.jpg?f=community)
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community)
Sorry, maar nee
Als er iets beroerde grafieken heeft om dat soort verbruik te tonen, dan is het Domoticz wel Voor maand en jaarverbruik heeft het één of ander wiebelig horizontaal lijntje i.p.v. fatsoenlijke staafgrafieken waar je tenminste in één opslag wat aan kunt zien. Heb daar ooit (in mijn Domoticz periode) nog eens een feature request voor ingeschoten (incl. wat mock-ups die ik had gemaakt in JsFiddle) maar is nooit wat mee gedaan door de ontwikkelaar. Vergeet ook niet dat elk jaar de zomer-/wintertijd bug weer terugkomt en je een uur aan data dan gewoon 'kwijt' bent in de grafieken.Tijd om Domoticz een keer los te gaan laten joh
Ik duwde P1 eerst naar InfluxDB en dan grafiekje er van maken in Grafana. Maar dat had voor mij ook wat manco's (script wat ik gebruikte kreeg ik het niet aan de praat om CRC van een telegram te laten checken, waardoor er soms extreem hoge verbruiken in de DB kwamen te staan. Maar iemand met beetje Python-skills kan dat wel fixen). En InfluxDB kan niet groeperen per maand. Heb nu dsmr-reader draaien, werkt ook wel leuk. Grafiekjes zijn ook nog niet alles, geef ik eerlijk toe. Maar de ontwikkelaar heeft al aangegeven dat hij zich daar wel in kan vinden en de boel over de kop gaat gooien. Uitlezen gaat erg goed omdat hij controle op CRC heeft ingebouwd op mijn verzoek. Back-end is PostgreSQL.
Waarom je de P1 in HASS zou willen snap ik ook niet. Misschien één veld (actueel verbruik o.i.d.) zodat je het kunt gebruiken in regels (geen idee met wat voor insteek), maar qua grafieken e.d.? Nee.
[ Voor 19% gewijzigd door ThinkPad op 06-01-2017 09:31 ]
Klopt allemaal. Er is an sich ook geen probleem.
Ik moet alleen even snel stabiliteit hebben, juist omdat P1 geen speeltuin is vind ik. Dan rustig als er een keer tijd is die metingen op mqtt gooien en dan kijken wat je er verder mee wil.
De eigen component waar ik het over heb is de backend. De long term archiving solution. Daar zou ik graag Elasticsearch zien om verschillende redenen.
Huh.. ik kan bij report toch echt gewoon netjes een verbruik zien per maand.:
[...]
Sorry, maar nee
Zijn er betere oplossingen? Hell yes, maar daar wil ik goed over nadenken en niet zomaar weer wat in elkaar steken waar ik achteraf anders mee om had moeten/willen gaan.
Al lang gedaan manTijd om Domoticz een keer los te gaan laten joh
Als ik hass en domoticz op een rasp zou draaien had ik dit ook nooit gedaan. Ik creeer nu gewoon tijd.
Wat je hierboven beschrijft is mijn punt. Ik blijf niet migreren van oplossing naar oplossing, ik zoek eerst precies uit wat ik wil.
Dat dat ook niet voor de komende 10 jaar is snap ik, maar dit is ook niks. Na een maand tegen manco's in je oplossing aanlopen en dan of een gat hebben of data migreren.- Omdat het kan, ik wil een single portal waarin alles terug te vinden is indien nodig.
- Ik wil inderdaad kunnen kijken wat mijn actuele verbruik is.
- Automations zie ik nu voor P1 verbruik ook nog niet. Misschien iets in de trant van "als verbruik langer > x stuur bericht", maar dat is niet mijn doel.
https://home-assistant.io...leshooting-configuration/
Waarschijnlijk iets met spaties.
Haal het even door de hass config check en je komt er snel genoeg achter.
Dat vind ik nou ook. Liefst geen gedoe met meerdere portals/websites.
Vraagje van mij kant:
Weet iemand hoe je deze:
Veranderd in:
[ Voor 21% gewijzigd door Fonta op 06-01-2017 16:01 ]
Verwijderd
.. ik snap je punt niet.. Waarom zou je een component willen maken? ES heeft toch ook een HTTP API, of hebben ze die verwijderd? Toen ik met ES aan het spelen was gebruikte ik eenvoudig de HTTP API om mijn P1 data er in te krijgen. Ik heb daar 0,0 voor hoeven maken.
Moet wel toegeven dat voor mij heeft Excel/Google Sheets uiteindelijk gewonnen.
/u/304801/crop5bea8a2cd3d1a_cropped.png?f=community)
Ik zie hier meerdere keren terug kopen dat een aantal Domoticz gebruikers zijn "overgelopen " naar Hass. Nu ben ik inmiddels een jaar gebruiker van Domoticz en heb ik nog wel eens wat stabiliteits problemen met me Z-wave netwerk die zich vertalen in Timeouts, en traag netwerk.
is dit iets wat jullie ook ondervinden in Hass? of is Hass veel stabieler hiermee?
Daarnaast heb ik ook een OTGW (open therm gateway: http://otgw.tclcode.com/), helaas zie ik deze niet terug komen in de componentenlijst van Hass. Heeft iemand hier een koppeling met een OTGW? of wat hebben jullie voor de CV ketel aansturing.
Hass ziet er erg netjes uit mogelijk is het een mooi alternatief voor Domoticz voor mij.
" naar Hass. Nu ben ik inmiddels een jaar gebruiker van Domoticz en heb ik nog wel eens wat stabiliteits problemen met me Z-wave netwerk die zich vertalen in Timeouts, en traag netwerk.is dit iets wat jullie ook ondervinden in Hass? of is Hass veel stabieler hiermee?
Daarnaast heb ik ook een OTGW (open therm gateway: http://otgw.tclcode.com/), helaas zie ik deze niet terug komen in de componentenlijst van Hass. Heeft iemand hier een koppeling met een OTGW? of wat hebben jullie voor de CV ketel aansturing.
Hass ziet er erg netjes uit mogelijk is het een mooi alternatief voor Domoticz voor mij.
[ Voor 32% gewijzigd door luigi87 op 06-01-2017 16:40 ]
- leeg -
Je begrijpt me inderdaad verkeerd:
[...]
.. ik snap je punt niet.. Waarom zou je een component willen maken? ES heeft toch ook een HTTP API, of hebben ze die verwijderd? Toen ik met ES aan het spelen was gebruikte ik eenvoudig de HTTP API om mijn P1 data er in te krijgen. Ik heb daar 0,0 voor hoeven maken.
Moet wel toegeven dat voor mij heeft Excel/Google Sheets uiteindelijk gewonnen.
Ik wil gewoon dat, net zoals er nu een influxdb integratie (dus een component) is, ook een ES integratie is. Als je dat netjes wil maken, dan maak je een component. Ik wil niet influx hoeven draaien als ik al een goed onderhouden ES heb draaien. En daarnaast ben ik goed bekend met ES en niet met influx. Leuk om wat mee te spelen, maar heb ik nu geen zin in
Dat staat dus los van P1 data, dat is maar een voorbeeld in deze.
Natuurlijk heeft ES overigens een http api, daar kan alles mee. Voor P1 zou je dus best een script kunnen draaien dat alle data rechtstreeks post naar ES of Influx. Maar waarom zou je een los script draaien als zaken goed geregeld zijn (of kunnen worden) met een domotica pakket. En dat is eigenlijk wat de dsmr component in hass nu ook al regelt, de metingen beschikbaar maken in hass, waarna de volgende integratie (influx in dit voorbeeld) de data doorzet naar influx. Of als er een ES component is naar ES.
Zoveel wegen die naar Rome leiden, maar om voor ieder dingetje dat je wil een los script te maken gaat alle doelen voorbij denk ik. Dat moet een last resort zijn, als je iets afwijkends wil. En dat is nu mijn "probleem", in hass is het nog niet goed genoeg geregeld en nog onderhevig aan veel refactors. En dat is voor mij ongewenste stabiliteit in data vergaring van P1.
Dus ja, ik zou dat met een script naar influx of ES kunnen posten. Geen probleem. Maar ik wil integratie
OTmon draaien en die laten outputten naar MQTT. Hass plukt wat je nodig hebt van de bus.:
Ik zie hier meerdere keren terug kopen dat een aantal Domoticz gebruikers zijn "overgelopen
is dit iets wat jullie ook ondervinden in Hass? of is Hass veel stabieler hiermee?
Daarnaast heb ik ook een OTGW (open therm gateway: http://otgw.tclcode.com/), helaas zie ik deze niet terug komen in de componentenlijst van Hass. Heeft iemand hier een koppeling met een OTGW? of wat hebben jullie voor de CV ketel aansturing.
Hass ziet er erg netjes uit mogelijk is het een mooi alternatief voor Domoticz voor mij.
YAML:
1
2
3
4
5
6
| - platform: mqtt state_topic: "events/central_heating/otgw/setpoint" name: "otgw_setpoint" qos: 0 unit_of_measurement: '°C' value_template: '{{ value }}' |
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| - alias: 'CH setpoint to saving on no movement' # Movement changed to off, set CH to saving hide_entity: True trigger: platform: state entity_id: input_boolean.is_movement_lower_floor to: 'off' action: # Change setpoint to saving mode service: mqtt.publish data_template: topic: "actions/otgw/setpoint" retain: true payload: '18' |
/edit
Overigens, als je nu shit hebt in je zwave netwerk, ga je dat ook krijgen met hass. Zowel Domoticz als Hass gebruiken gewoon openzwave. Gewoon zwave problemen onderzoeken en oplossen dus.
[ Voor 30% gewijzigd door UltraSub op 06-01-2017 16:58 ]
Hier ben ik het wel mee eens. HASS gebruikt ook gewoon OpenZWave, net als Domoticz.
Verschil is alleen dat het bij Domoticz meegecompileerd is en bij elke update van Domoticz dus ook automatisch wordt bijgewerkt. Bij HASS staat het los van elkaar en is daardoor wat stabieler heb ik het idee. Heb HASS al een keer of 6 bijgewerkt sinds ik het draai, maar OpenZWave nog nooit. Heb ook zoiets van: "Waarom zou ik, als het allemaal prima draait?".
Maar daarom kun je HASS nog wel gewoon een keer proberen natuurlijk
Mijn ervaring met Z-Wave is vooral dat je voor bekende merken en niet al te nieuwe Z-Wave modules moet gaan. Heb eens een Qubino dimmer gehad die vrij nieuw was. Heel geklooi om parameters goed te zetten zodat alle inputs werden gedetecteerd e.d. En dan nog soms gekke dingen. Module uiteindelijk verkocht (ik was er echt compleet klaar mee) en een 2 jaar oudere Qubino module gebruikt. Includen en gelijk werken zonder ook maar één probleem
[ Voor 21% gewijzigd door ThinkPad op 06-01-2017 19:12 ]
We denken hetzelfde, maar we praten langs elkaar
Mijn idee is om HA te laten regelen waar hij goed in is. Waar hij niet goed in is gaat hij ook niet doen. Uiteindelijk komt er een andere interface voor.
RED heb ik al een paar keer naar gekeken, maar ik kom tijd tekort. Leek me eerder al een mooie oplossing inderdaad.
Jah, die uurtjes ken ik
Dat is het enige wat ik in mijn eerdere post aangaf. Even de P1 terug naar Domoticz omdat ik niet het beruchte "uurtje" heb en snel stabiliteit wil. Denkt ThinkPad meteen dat ik terug ben naar Domoticz
Ik maak met data gewoon even pas op de plaats omdat ik denk dat er betere oplossingen zijn. Zoals je zelf ook al beschrijft. Maar ik wil dat wel van te voren uitwerken, zodat ik niet nog 5x switch van architectuur. Dus tot die tijd zoek ik gewoon zonder er verder tijd in te steken een logger. Goh, laat ik nou toevallig nog een VM hebben die toch nog Domoticz draait (maar verder niks meer doet) die alle history ook nog heeft van P1. Dan is toch logisch dat je met 2 klikken die logging terug activeert.
Het antwoorden op de reacties hier heeft me inmiddels al meer tijd gekost
Agree. Ben ik inmiddels ook wel achter. Troep in je netwerk veroorzaakt veel shit. Een van de redenen dat ik niet eens begin aan die Fibaro Button, terwijl ik die wel zou kunnen gebruiken.:
[...]
Mijn ervaring met Z-Wave is vooral dat je voor bekende merken en niet al te nieuwe Z-Wave modules moet gaan. Heb eens een Qubino dimmer gehad die vrij nieuw was. Heel geklooi om parameters goed te zetten zodat alle inputs werden gedetecteerd e.d. En dan nog soms gekke dingen. Module uiteindelijk verkocht (ik was er echt compleet klaar mee) en een 2 jaar oudere Qubino module gebruikt. Includen en gelijk werken zonder ook maar één probleem
:strip_icc():strip_exif()/u/219593/lamas_60x60icon.jpg?f=community)
WP: ME PUHZ-SW75YAA + ERST30D-VM2ED | Solar: 17x TSM-340-DE06M.08 (5780Wp ~6200kWh), Azimuth 179°, Hellingshoek: 34° | PC specs
:strip_exif()/u/113667/ja-man.gif?f=community)
/u/145971/logotnet.png?f=community)
ofwel:
code:
1
2
3
4
5
6
7
8
9
| [code = yaml]
- alias: 'light off with sunset'
trigger:
- platform: sun
event: sunset
action:
service: light.turn_on
entity_id: light_white_lamp_4
[/code] |
Plak dat in je bericht en het werkt
Je kan ook code-tags binnen code-tags gebruiken
[ Voor 9% gewijzigd door GENETX op 07-01-2017 16:27 ]
Is het niet:
YAML:
1
2
3
4
5
6
7
| - alias: 'light on with sunset' trigger: platform: sun event: sunset action: service: light.turn_on entity_id: light.hue_white_lamp_4 |
Ben zelf ook nog geen YAML expert, maar zo heb ik het ongeveer staan...
Influx is aanvullend. Standaard is sqlite, beter (en makkelijk te doen) is mysql of postgresql. Maar helemaal vervangen door influx kan niet (ook niet logisch, is anders).
Over je status vraag. Klik op de sensor. Zie je staan hoe lang geleden is gerapporteerd. (De grafiek die je daar ziet komt overigens hit de 3 genoemde databases.
Over je status vraag. Klik op de sensor. Zie je staan hoe lang geleden is gerapporteerd. (De grafiek die je daar ziet komt overigens hit de 3 genoemde databases.
top!, wat een mega programma trouwens, dit is wat Domoticz nooit zal kunnen worden.:
Influx is aanvullend. Standaard is sqlite, beter (en makkelijk te doen) is mysql of postgresql. Maar helemaal vervangen door influx kan niet (ook niet logisch, is anders).
Over je status vraag. Klik op de sensor. Zie je staan hoe lang geleden is gerapporteerd. (De grafiek die je daar ziet komt overigens hit de 3 genoemde databases.
E - I - N - D - E - L - I- J - K deftige MQTT sensor integratie
Maar ik kan dus MYSQL doen voor HASS samen met influx voor de sensors?
edit: hmm misschien beter de sensors rechtstreeks INFLUX laten invullen (ik gebruik nog node red ook)
[ Voor 11% gewijzigd door A1AD op 07-01-2017 21:53 ]
- Deze advertentie is geblokkeerd door Pi-Hole -
Wel jammer dat je voor grafana toch weer zoiets als influxdb nodig hebt.
Dan heb je al mysql draaien... Kan je er nog een db naast gaan zetten.
De reden dat ik van sqlite naar mysql ben gegaan is omdat ik locks op de db errors kreeg
Dan heb je al mysql draaien... Kan je er nog een db naast gaan zetten.
De reden dat ik van sqlite naar mysql ben gegaan is omdat ik locks op de db errors kreeg
Voor de RFXCOM heb ik op de pi waar de rfxcom aangesloten zit een python script draaien dat het RF signaal naar een MQTT topic vertaald.
De rest zoals samsung smart tv wordt via Node-red omgezet naar MQTT. (node-red
)
- Deze advertentie is geblokkeerd door Pi-Hole -
:strip_exif()/u/66072/dj.gif?f=community)
:strip_exif()/u/206557/captain-obvious.gif?f=community)
:strip_icc():strip_exif()/u/53553/hiddink.jpg?f=community)
Sterkte, dat betrof namelijk die door mij gewraakte ZMNHDD1:
[...]
Heb eens een Qubino dimmer gehad die vrij nieuw was. Heel geklooi om parameters goed te zetten zodat alle inputs werden gedetecteerd e.d. En dan nog soms gekke dingen. Module uiteindelijk verkocht (ik was er echt compleet klaar mee) en een 2 jaar oudere Qubino module gebruikt. Includen en gelijk werken zonder ook maar één probleem
Heb op die plek nu een ZMNHDA2 dimmer in gebruik en die werkt als een trein, de i2 input werkte gelijk na includen. En op andere plekken de ZMNHAA2 (schakelaar, geen dimmer) in gebruik en daar ook nul problemen mee.
[ Voor 12% gewijzigd door ThinkPad op 08-01-2017 11:26 ]
Of rechtstreeks met een plug-in (zelf niet getest nog).
https://github.com/widarl...b/logstash/inputs/mqtt.rb
* UltraSub likes your thinking
https://github.com/widarl...b/logstash/inputs/mqtt.rb
* UltraSub likes your thinking
[ Voor 13% gewijzigd door UltraSub op 08-01-2017 15:28 ]
Een stap minder is vaak beter:
Of rechtstreeks met een plug-in (zelf niet getest nog).
https://github.com/widarl...b/logstash/inputs/mqtt.rb
* UltraSub likes your thinking
In mijn geval wil ik de tussenstap hebben als het gaat om sensoren die "vaak, maar onregelmatig" data aanleveren. Ik krijg elke 2 tot 8 seconden een meting door. Elke meting opslaan is zonde, dat kan telegraf/collectd/statsd/... prima normaliseren.
* ANdrode kent ES goed maar logstash niet: Zou je daar een metrics filter voor gebruiken?
In mijn casus denk ik nu aan een bus structuur voor de flow van de data. Want minder coupling is beter:
sensor -> mqtt (onregelmatig)
mqtt -> "statsd voor mqtt" (bestaat niet) -> mqtt (vast interval)
mqtt -> influxdb|logstash|telegraf
Dit heeft alleen zin als er meer dan één consumer van de geaggregeerde data is
Om je vraag te beantwoorden: Dat heeft puur met acceptatie te maken van mijn wederhelft + aanhang. Ik bedien zelf alles via horloge / telefoon of laat het automatisch verlopen. Zij willen (ook nog) een fysieke schakelaar behouden.
De fysieke schakelaars die we hebben gehad icm X10 (KaKu) met dim functionaliteit zijn op zijn zachts gezegd niet geaccepteerd door hun werking. En dat is nu juist de werking zoals jij en ik hem hebben beschreven.
als het echt niet anders kan moet ik denk ik mijn wederhelft maar wegdoen
voordat het zover komt kijk ik liever even naar een alternatief
Verwijderd
Misschien een tussen oplossing die wel door de 'beugel' kan.:
[...]
Om je vraag te beantwoorden: Dat heeft puur met acceptatie te maken van mijn wederhelft + aanhang. Ik bedien zelf alles via horloge / telefoon of laat het automatisch verlopen. Zij willen (ook nog) een fysieke schakelaar behouden.
De fysieke schakelaars die we hebben gehad icm X10 (KaKu) met dim functionaliteit zijn op zijn zachts gezegd niet geaccepteerd door hun werking. En dat is nu juist de werking zoals jij en ik hem hebben beschreven.
als het echt niet anders kan moet ik denk ik mijn wederhelft maar wegdoen
Zo'n Qubino heeft 3 inputs Daarvan is 1 voor de ' lamp zelf ', die andere twee kun je opvangen in je gekozen domotica oplossing.
De schakelaar in je muur vervangen je door een duo pulsdrukker op. De linker wipper regelt de lamp zoals we reeds beschreven hadden, maar de rechter wipper gaat gelijk naar dim niveau X (uiteraard helpt het bij de acceptatie als de wederhelft X bepaalt). Nogmaals drukken is uit.
Je zou ook kunnen overwegen om beide drukkers te verbinding met input 2 en 3, dan kun je twee verschillende dim niveaus in stellen.
Je voorkomt hier mee het, aan doen, en dan nogmaals dimmen door gelijk naar een voor ingesteld dim niveau te gaan.
/u/98547/crop5db2a7ff7f697_cropped.png?f=community)
Ik zou de spatie achter chat_id weghalen en achter de : zetten.
Zoals ook op de website staat:
Zoals ook op de website staat:
[ Voor 40% gewijzigd door Fonta op 11-01-2017 23:31 ]
/u/274737/1424346450_beer_.png?f=community)
Ik heb behoorlijk moeite met de eerste configuratie van Home Assistant in combinatie met een z-wave.me usb stick.
Ik heb sowieso het idee dat ik of iets heel erg fout doe of mijn installatie van hass werkt niet volledig, te beginnen bij de beginpagina van hass. Daarin staat het welkomsvenster met de volgende tekst:
Ik heb sowieso het idee dat ik of iets heel erg fout doe of mijn installatie van hass werkt niet volledig, te beginnen bij de beginpagina van hass. Daarin staat het welkomsvenster met de volgende tekst:
Ik zet in de configuration.yml vervolgens een hekje voor #introduction, ik restart home-assistant met sudo systemctl restart home-assistant en de welkomspagina krijg ik nog altijd.
WP: Mitsubishi Ecodan PUHZ-SHW112YAA, ERSC-VM2C, Procon ┃ PV: 4800Wp, SolarEdge SE5K, 15x JAM60S17/320, ZW 15º ┃ WTW: Zehnder Q600 ┃ SH: Home Assistant, Proxmox, Intel NUC 8i5 Mini
Heb je dat vanuit het hass env gedaan? Die pip install? Want dan zou hij daar automatisch moeten landen niet zou je --target niet nodig moeten hebben.
Interessant issue ja.
Zelf vandaag eindelijk tijd gevonden om ff mijn ELK stack opnieuw op te zetten. Dus ik trek de machine naar binnen waar hass op draait, wtf, dumpt die echt gigantisch logging in syslog. Why the hell dumpen ze dat niet naar de log die ze al hebben in .homeassistant
Dus ik zoeken naar hass en syslog, kom ik een platform tegen waarbij je een notify kunt doen naar syslog. Why, het ding logt al alles daar naar toe
Iemand die weet hoe ik dit gemakkelijk bij stuur? Ik vind niet dat dit in syslog hoort, dit hoort in de eigen logs. Ook makkelijker grokken (afgezien van de shit multi-line stack traces die ik waarschijnlijk gewoon ga droppen). Misschien tijd dat iemand een log4j feature gaat op pakken
/edit
En damn, zwave is chatty. Wist ik, al eerder gezien met domoticz, maar toch, als je het visualiseert is toch wel ff anders. Arme sd card gebruikers denk ik dan
Interessant issue ja.
Zelf vandaag eindelijk tijd gevonden om ff mijn ELK stack opnieuw op te zetten. Dus ik trek de machine naar binnen waar hass op draait, wtf, dumpt die echt gigantisch logging in syslog. Why the hell dumpen ze dat niet naar de log die ze al hebben in .homeassistant
Dus ik zoeken naar hass en syslog, kom ik een platform tegen waarbij je een notify kunt doen naar syslog. Why, het ding logt al alles daar naar toe
Iemand die weet hoe ik dit gemakkelijk bij stuur? Ik vind niet dat dit in syslog hoort, dit hoort in de eigen logs. Ook makkelijker grokken (afgezien van de shit multi-line stack traces die ik waarschijnlijk gewoon ga droppen). Misschien tijd dat iemand een log4j feature gaat op pakken
/edit
En damn, zwave is chatty. Wist ik, al eerder gezien met domoticz, maar toch, als je het visualiseert is toch wel ff anders. Arme sd card gebruikers denk ik dan
[ Voor 8% gewijzigd door UltraSub op 14-01-2017 21:32 ]
Verwijderd
Dan zet je die logging toch uit?:
/edit
En damn, zwave is chatty. Wist ik, al eerder gezien met domoticz, maar toch, als je het visualiseert is toch wel ff anders. Arme sd card gebruikers denk ik dan
WP: Mitsubishi Ecodan PUHZ-SHW112YAA, ERSC-VM2C, Procon ┃ PV: 4800Wp, SolarEdge SE5K, 15x JAM60S17/320, ZW 15º ┃ WTW: Zehnder Q600 ┃ SH: Home Assistant, Proxmox, Intel NUC 8i5 Mini
WP: ME PUHZ-SW75YAA + ERST30D-VM2ED | Solar: 17x TSM-340-DE06M.08 (5780Wp ~6200kWh), Azimuth 179°, Hellingshoek: 34° | PC specs
WP: ME PUHZ-SW75YAA + ERST30D-VM2ED | Solar: 17x TSM-340-DE06M.08 (5780Wp ~6200kWh), Azimuth 179°, Hellingshoek: 34° | PC specs
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.
Jammer, for now maar even terug naar de snapshots.
Later nog eens proberen.
Ik moet ook nog steeds upgraden. Zit nog op 32.1 Maar er zijn in de tussentijd redelijk wat breaking changes geweest meen ik en ik ga binnenkort ook verhuizen dus laat het eerst as is. Ik moet waarschijnlijk toch de Z-Wave modules excluden en weer includen, dus alles ligt dan over de kop. Ik ga in het nieuwe huis wel weer nadenken over upgraden 
Maar er zijn in de tussentijd redelijk wat breaking changes geweest meen ik en ik ga binnenkort ook verhuizen dus laat het eerst as is. Ik moet waarschijnlijk toch de Z-Wave modules excluden en weer includen, dus alles ligt dan over de kop. Ik ga in het nieuwe huis wel weer nadenken over upgraden
[ Voor 10% gewijzigd door ThinkPad op 18-01-2017 09:14 ]
Dit topic is gesloten.