: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)
/u/1002033/crop5a1d6e8df24f6_cropped.png?f=community)
What's the speed of dark?
:strip_icc():strip_exif()/u/4202/crop59500930db0d0_cropped.jpeg?f=community)
Maar waarom DSMR reader er tussen als de slimme meter ook gewoon rechtstreeks zijn "zooi" in InfluxDB kan dumpen (bijvoorbeeld, https://github.com/pcmvan...er-reading-store-influxdb)?
Ik wil het zo simpel en plat mogelijk houden zonder al teveel afhankelijkheden van elkaar. Vandaar mijn gedachte om voor nu InfluxDB en Chronograf in aparte containers te draaien en alles wat direct in InfluxDB data kwijt kan dat ook te laten doen... zo beperk ik het aantal laagjes er tussen, geen DSMR + MQTT + onnodige belasting op Hass nodig lijkt me met hetzelfde resultaat.
Overigens werk ik nu ook alleen met includes, 60% van de data welke Home Assistant logt gebruik ik niet en wil ik dus ook niet in een database terug zien (motion sensor triggers e.d.), alleen maar verspilde ruimte
Ik ben een voorstander van "als het er uit kan... dan zal ik het niet nalaten ook".
[ Voor 15% gewijzigd door R2D2 op 29-01-2019 11:55 ]
Je kan ook je slimme meter direct met het DSMR component in HA hangen en dan HA de waarden naar InfluxDB laten schrijven, scheelt weer wat laagjes... (ik nam aan dat je DSMR reader gekozen had vanwege de extra info ten opzichte van DSMR component). Op deze manier hou je een modulaire opzet waarin HA de baas is hoe jouw data eruit ziet (je kan bijvoorbeeld template sensoren toevoegen om data te veranderen of namen te veranderen ect). Ik vermoed dat je ook de waarden van P1 in HA wilt zien, dus moet je op de een of andere manier toch DSMR met HA koppelen.:
[...]
Maar waarom DSMR reader er tussen als de slimme meter ook gewoon rechtstreeks zijn "zooi" in InfluxDB kan dumpen (bijvoorbeeld, https://github.com/pcmvan...er-reading-store-influxdb)?
Ik wil het zo simpel en plat mogelijk houden zonder al teveel afhankelijkheden van elkaar. Vandaar mijn gedachte om voor nu InfluxDB en Chronograf in aparte containers te draaien en alles wat direct in InfluxDB data kwijt kan dat ook te laten doen... zo beperk ik het aantal laagjes er tussen, geen DSMR + MQTT + onnodige belasting op Hass nodig lijkt me met hetzelfde resultaat.
Overigens werk ik nu ook alleen met includes, 60% van de data welke Home Assistant lot gebruik ik niet en wil ik dus ook niet in een database terug zijn, alleen maar verspilde ruimte
Ik ben een voorstander van "als het er uit kan... dan zal ik het niet nalaten ook".
Ik doe het zoals ik hier heb beschreven.:
[...]
Daarom vraag ik wat je probeert te bereiken. Maar probeer het anders eens met de Moment-node.
[...]
Uiteraard!
[Afbeelding]
De events: deconz_event is een events: all-node die in dit geval specifiek naar deCONZ (en dus ZigBee) events luistert. Je ziet daarboven de groene msg-node. Die laat het complete msg-object zien. Zo ziet het er bijvoorbeeld uit als ik m'n Tradfri-afstandsbediening bedien:
[Afbeelding]
Zo kan ik zien welk id de actie heeft getriggerd (tradfri_remote_control) en wat de actie was (boven: knop 5, long press, start, onder: knop 5, long press, end). Daarna ga ik verder met automatiseren
[ Voor 9% gewijzigd door wmn79 op 29-01-2019 15:30 ]
Is een optie maar ik snap niet helemaal waarom ik OF DSMR OF HassIO nodig heb om data in InfluxDB te stoppen als ik die data ook gewoon rechtstreeks met een Python script de database in kan pompen.
DSMR is wat mij betreft echt overkill in mijn situatie waar ik ALLE data in 1 oplossing specifiek voor dat doeleinde (inzicht / analytics qua verbruik) wil vangen. Ik hoef die data dus niet in Home Assistant te hebben, die wil ik namelijk echt en alleen houden voor automatisering / smart devices... niet om data te loggen of weer te geven in een dashboard waar het me 9 van de 10 keer toch alleen maar in de weg zit
Vanavond maar eens zien of wat ik in mijn hoofd heb zitten ook daadwerkelijk mogelijk is.
Maar waarom via MQTT en Chronograf naar InfluxDB terwijl Home Assistant ook direct zelf zijn data weg kan schrijven in een InfluxDB? Gaat het om normalisatie o.i.d?
[ Voor 19% gewijzigd door R2D2 op 29-01-2019 13:58 ]
Waarom vraag je het dan in het HA forum:
[...]
Is een optie maar ik snap niet helemaal waarom ik OF DSMR OF HassIO nodig heb om data in InfluxDB te stoppen als ik die data ook gewoon rechtstreeks met een Python script de database in kan pompen.
DSMR is wat mij betreft echt overkill in mijn situatie waar ik ALLE data in 1 oplossing specifiek voor dat doeleinde (inzicht / analytics qua verbruik) wil vangen. Ik hoef die data dus niet in Home Assistant te hebben, die wil ik namelijk echt en alleen houden voor automatisering / smart devices... niet om data te loggen of weer te geven in een dashboard waar het me 9 van de 10 keer toch alleen maar in de weg zit
Vanavond maar eens zien of wat ik in mijn hoofd heb zitten ook daadwerkelijk mogelijk is.
[...]
Als je data alleen in InfluxDB wilt zonder HA of wat dan ook, pak dan gewoon je Python ding. Ik geef alleen maar aan dat vanuit modulair en architectuurtechnisch het mooier is om het via HA te laten lopen.
Ik gebruik mijn HA als 'smart' portal voor al mijn apparatuur en heb ik HA graag de baas om data representatie etc
MQTT is tussen HA en een losse DSMR reader en heb je niet nodig als je het DSMR component van HA gebruikt.
[ Voor 15% gewijzigd door XanderHuisman op 29-01-2019 14:08 ]
Omdat ik de HA data wel de database in wil hebben NAAST de data uit de slimme meter:
[...]
Waarom vraag je het dan in het HA forum
Als je data alleen in InfluxDB wilt zonder HA of wat dan ook, pak dan gewoon je Python ding. Ik geef alleen maar aan dat vanuit modulair en architectuurtechnisch het mooier is om het via HA te laten lopen.
En ik snap niet helemaal wat er mooier is aan modulair en architectuurtechnisch oogpunt om je data via een tussenpunt een database in te pompen terwijl ze ook prima los van elkaar in dezelfde database kunnen schrijven. Zal misschien mijn gebrek aan kennis zijn als front-end developer maar het lijkt mij een onnodige en overbodige stap.
Simpel voorbeeld, als HA plat gaat na een update en ik niet meteen de tijd heb dat te fixen (gaat de vrouw niet leuk vinden maar dat terzijde ;-)) zou dat betekenen dat ik ook gaten ga krijgen in mijn verbruiksdata van de slimme meter.
De vraag was dus of men ervaring had met Hass.io icm InfluxDB / Chronograf. Die slimme meter data een database in duwen kan nooit heel ingewikkeld zijn, het ging mij er vooral om of Home Assistant dat een beetje fatsoenlijk doet.
Wij gebruiken het beiden dus op een andere manier
[ Voor 11% gewijzigd door R2D2 op 29-01-2019 14:21 ]
MQTT zorgt er ook voor dat je devices fysiek op een andere plek kan plaatsen. De machine met HA hoeft dan niet direct naast je meter te staan
Ik gebruike Telegraf en vergiste mij even in de naam. Lijkt ook op elkaar
Het is in mijn geval een legacy keuze. Paar redenen om erbij te blijven:
- Tijdseries normaliseren (vast interval, ook voor sensoren die 'erg vaak' meten)
- Telegraf kan vanaf meerdere inputs naar InfluxDB schrijven, ik gebruikte ook collectd.
- Batching, waardoor er minder vaak geschreven wordt naar disk
- Geen white/blacklisting nodig, niet afhankelijk van changes in InfluxDB component of hass componenten
- P1 logging direct vanaf MQTT terwijl er destijds (?) geen goede P1-over-MQTT support was in hass
En dat mijn data nu dit formaat heeft zorgt er voor dat ik even moet kijken hoe ik dit oplos nadat home assistant die json_attributes echt weghaalt.
[ Voor 17% gewijzigd door ANdrode op 29-01-2019 14:23 ]
Valide punt, ik heb het geluk dat ie er echt praktisch naast hangt dus dat is geen probleem waar ik last van heb.:
[...]
MQTT zorgt er ook voor dat je devices fysiek op een andere plek kan plaatsen. De machine met HA hoeft dan niet direct naast je meter te staan
Een goede reden om Telegraf er ook maar bij te pakken nu ik dat zo lees. Het zal uiteindelijk wel de gehele TICK stack worden om alle data te collecten via de diverse bronnen.
wat als je hem zo doet dan?:
Ik zit vanavond al een tijdje te stoeien met een deel van mijn "wekker radio script" maar het lukt nog niet echt.
Wat ik wil is dat wanneer de input_boolean "alarm_clock_radio" aan gaat, het scrip triggert dat eerst het nieuws afgespeeld moet worden op een Google Home Mini en als die stream (mp3 file) klaar is, alle speakers (die in een groep staan), een radiozender gaan afspelen.
Ik gebruik hiervoor onderstaande automation:
code:
#################################### ##### Alarm clock radio nieuws ##### #################################### - alias: alarm_clock_radio_news initial_state: true trigger: - platform: state entity_id: input_boolean.alarm_clock_radio to: 'on' action: - service: media_player.play_media data: entity_id: media_player.bed media_content_id: http://content1a.omroep.nl/urishieldv2/l27m44da28976221d353005c4f58c9000000.08492bf5d589d7d55b72331f0eb8ba04/nos/radionieuws/nosnieuws_bulalg.mp3 media_content_type: 'music' - service: media_player.volume_set data: entity_id: media_player.chris volume_level: 0.15 #################################### ##### Alarm clock radio muziek ##### #################################### - alias: alarm_clock_radio_music initial_state: true trigger: - platform: state entity_id: media_player.bed to: 'idle' action: - data: entity_id: input_boolean.turn_on service: input_boolean.play_slam_mixmarathon - data: entity_id: input_boolean.turn_off service: input_boolean.alarm_clock_radio
De input_boolean "play_slam_mixmarathon" werkt prima als ik deze handmatig activeer, de correcte stream gaat aan op alle speakers.
Probleem is echter dat bovenstaande automation niet verder lijkt te komen omdat die de trigger van media_player.bed die naar "idle" gaat, niet herkend...
In de dev-state zie ik hem wel degelijk gewoon naar "idle" gaan, maar er gebeurt niets
Ziet iemand de fout misschien ?
Ik draait v0.86.3 van hass.
YAML:
1
2
3
| - platform: state entity_id: media_player.bed from: 'playing' |
@lubbertkramer das een hele lap code voor 1 lampje 
Als ik het goed begrijp heb je en een deurcontact, motion sensor en een wandschakelaar.
Waarom dan een motion en deurcontact?
De timer is er voor om te zorgen dat het licht niet te snel uit gaat?
Heb hier enkel een motion gehad in de wc, maar daar was de waf factor niet voldoende voor helaas, dus die heb ik maar weer oldskool dom gemaakt..
Als ik het goed begrijp heb je en een deurcontact, motion sensor en een wandschakelaar.
Waarom dan een motion en deurcontact?
De timer is er voor om te zorgen dat het licht niet te snel uit gaat?
Heb hier enkel een motion gehad in de wc, maar daar was de waf factor niet voldoende voor helaas, dus die heb ik maar weer oldskool dom gemaakt..
Contact doet het licht aan bij deur openen en bij weer openen uit. De motion is er als backup aangezien de deur niet altijd dicht is en zorgt ervoor dat tijdens sommige lange sessies op de kleine kamer het licht aanblijft. Als backup is er nog altijd de xiaomi schakelaar:) Daarnaast maak ik gebruik van scènes door het hele huis om vooral se lichtsterkte te bepalen voor bepaalde tijden.:
@lubbertkramer das een hele lap code voor 1 lampje
Als ik het goed begrijp heb je en een deurcontact, motion sensor en een wandschakelaar.
Waarom dan een motion en deurcontact?
De timer is er voor om te zorgen dat het licht niet te snel uit gaat?
Heb hier enkel een motion gehad in de wc, maar daar was de waf factor niet voldoende voor helaas, dus die heb ik maar weer oldskool dom gemaakt..
De WAF maar ook acceptatie van familie etc is hier prima sinds de switch van (super)Homey naar HA en er meer stabiliteit is. Al draait de homey nog wel.
Veel voor een lampje maar zelf de structuur dan meestal complexer ook door de rest van de woning, dit was een simpel voorbeeld.
[ Voor 7% gewijzigd door lubbertkramer op 29-01-2019 20:58 ]
:strip_icc():strip_exif()/u/8817/DSC05697_70x70-2.jpg?f=community)
Omdat niet iedereen in het Zigbee2mqtt topic zit post ik het hier ook maar even:
Zigbee2mqtt 1.1 is zojuist gereleased!
Release notes: https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.1.0
Zigbee2mqtt 1.1 is zojuist gereleased!
Release notes: https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.1.0
:strip_icc():strip_exif()/u/77131/crop5d0893753034a_cropped.jpeg?f=community)
Ik ben bezig met mijn Lovelace layout te maken, maar is de enige manier om de cards in te delen de custom layout-card optie te gebruiken? 
:strip_icc():strip_exif()/u/34345/crop604df19f86683.jpg?f=community)
:strip_icc():strip_exif()/u/198189/crop67ecf5f08705a_cropped.jpg?f=community)
Is het dan nu officieel dat de Weather Underground API niet meer werkt? Tot vanmorgen had ik nog sensoren, nu niet meer 
Nevermind, werkt nog steeds Die weten ook niet wat ze willen daar volgens mij. Zou toch per 1-1-2019 dichtgezet worden
Nevermind, werkt nog steeds
Die weten ook niet wat ze willen daar volgens mij. Zou toch per 1-1-2019 dichtgezet worden
[ Voor 35% gewijzigd door lolgast op 30-01-2019 10:57 ]
/u/398995/crop6493fca3906db_cropped.png?f=community)
Klopt, officieel vanaf 1-1-2019 ... Ik heb in December de switch gemaakt naar Dark Sky:
Is het dan nu officieel dat de Weather Underground API niet meer werkt? Tot vanmorgen had ik nog sensoren, nu niet meer
Nevermind, werkt nog steeds
Van Darksky mis ik dat ze geen goede beschrijving van de voorspelling van de dag hebben. Dit bedoel ik, daarvan laat ik de 1d-variant elke ochtend als bericht versturen zodat ik weet wat ik kan verwachten vanaf de auto naar kantoor en terug:
[...]
Klopt, officieel vanaf 1-1-2019 ... Ik heb in December de switch gemaakt naar Dark Sky
:strip_icc():strip_exif()/u/246251/20111031_7308_koen_rijpkema.jpg?f=community)
Ik mis vooral insolation (instralingsgegevens) om te bepalen hoeveel de PV panelen zouden moeten opbrengen.:
[...]
Van Darksky mis ik dat ze geen goede beschrijving van de voorspelling van de dag hebben. Dit bedoel ik, daarvan laat ik de 1b-variant elke ochtend als bericht versturen zodat ik weet wat ik kan verwachten vanaf de auto naar kantoor en terug
[Afbeelding]
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community)
Die haal ik via Buienradar (Zonintensiteit 85 W/m2), niet om mijn PV panelen te bereken want die heb ik niet, maar om te bepalen of de rolluiken in de zomer dicht moeten of niet
Werkte behoorlijk betrouwbaar afgelopen zomer!
Ik besef me dat ik hier niet meer op heb gereageerd. Maar dan moet je de vermeldingen in de core.entity_registry verwijderen van de oude naam. Dan maakt hij de sensoren aan met de nieuwe naam
* lolgast vindt dat entity_registry nog steeds een k*t systeem
Klopt inderdaad, maar die gasten hebben er geen verstand van
Nee serieus, HA hamert nogal op een 'edit het maar in de UI, dan blijven wij lekker aankloten in .storage/core.*_registry'-methode. Die entity_registry zou ooit in het leven geroepen zijn om sensor namen te 'reserveren' voor devices die kwijt zouden raken en je opnieuw moet toevoegen. Maar laten we eerlijk zijn, hoe vaak komt het voor dat je een device kwijtraakt en er op precies dát moment eenzelfde device de vrijgekomen naam zou gebruiken? Echt nooit. In mijn ogen is die entity_registry een oplossing voor een probleem wat niet bestaat.
@Thoit hieronder: Ik denk dat je opzoek bent naar Device Class
Nee serieus, HA hamert nogal op een 'edit het maar in de UI, dan blijven wij lekker aankloten in .storage/core.*_registry'-methode. Die entity_registry zou ooit in het leven geroepen zijn om sensor namen te 'reserveren' voor devices die kwijt zouden raken en je opnieuw moet toevoegen. Maar laten we eerlijk zijn, hoe vaak komt het voor dat je een device kwijtraakt en er op precies dát moment eenzelfde device de vrijgekomen naam zou gebruiken? Echt nooit. In mijn ogen is die entity_registry een oplossing voor een probleem wat niet bestaat.
@Thoit hieronder: Ik denk dat je opzoek bent naar Device Class
[ Voor 9% gewijzigd door lolgast op 30-01-2019 15:01 ]
:strip_exif()/u/655449/crop5a9913c48b11c_cropped.gif?f=community)
@lolgast Nee, die kan ik niet gebruiken voor custom sensors volgens mij. Gebruik ze wel veel bij mijn standaard sensoren.
@JayOne Dat is inderdaad de manier die ik bedoelde. Had gehoopt dat er misschien in Lovelace iets zou zitten om gelijk naar een attribute van een sensor te kunnen verwijzen Scheelt namelijk weer een hoop bestandjes aanpassen e.d.
@JayOne Dat is inderdaad de manier die ik bedoelde. Had gehoopt dat er misschien in Lovelace iets zou zitten om gelijk naar een attribute van een sensor te kunnen verwijzen
Scheelt namelijk weer een hoop bestandjes aanpassen e.d.
Hi All,
heeft er iemand ervaring met sturen van commando's naar Fully Kiosk Browser?
ik heb een dedicated tablet aan de muur hangen (Amazon Fire HD gen
met daarop fully kiosk browser.
Ik wil het scherm triggeren om aan te gaan bij een specifiek event. nu test ik het met een switch.
als ik volgende url in mijn browser plak, dan werkt de trigger:
http://192.168.1.149:2323...=json&password=mypassword
Als ik een switch in HA configureer als volgt en uitvoer dan gebeurt er helemaal niks:
heeft er iemand ervaring met sturen van commando's naar Fully Kiosk Browser?
ik heb een dedicated tablet aan de muur hangen (Amazon Fire HD gen
met daarop fully kiosk browser.Ik wil het scherm triggeren om aan te gaan bij een specifiek event. nu test ik het met een switch.
als ik volgende url in mijn browser plak, dan werkt de trigger:
http://192.168.1.149:2323...=json&password=mypassword
Als ik een switch in HA configureer als volgt en uitvoer dan gebeurt er helemaal niks:
YAML: configuration.yaml
1
2
3
4
5
6
| switch 2: - platform: command_line switches: tablet_display_on: command_on: "/usr/bin/curl -X POST http://192.168.1.149:2323/?cmd=triggerMotion&type=json&password=mypassword" friendly_name: "tablet display on" |
Ik gok dat het mis gaat door de POST ipv GET in je 'command_on'. Ik zou zelf overigens een Rest command gebruiken: https://www.home-assistant.io/components/rest_command/:
Hi All,
heeft er iemand ervaring met sturen van commando's naar Fully Kiosk Browser?
ik heb een dedicated tablet aan de muur hangen (Amazon Fire HD gen
Ik wil het scherm triggeren om aan te gaan bij een specifiek event. nu test ik het met een switch.
als ik volgende url in mijn browser plak, dan werkt de trigger:
http://192.168.1.149:2323...=json&password=mypassword
Als ik een switch in HA configureer als volgt en uitvoer dan gebeurt er helemaal niks:
YAML: configuration.yaml
Helaas, geen resultaat.
Vind het persoonlijk wel bijzonder, lijkt wel alsof het "signaal" gewoonweg niet binnenkomt...
Martinvdm = TechJunky.nl
:strip_exif()/u/20659/crop68b0a63d5da15.gif?f=community)
He who laughs last thinks slowest! | ▶️ Youtube | 🌐 TechJunky.nl | ☀️ 3000Wp PV | Ford Explorer EV Ext
:strip_icc():strip_exif()/u/105389/Letter%2520D%2520-%252060x60%2520rev%25202.jpg?f=community)
WHAAAAAAAA!!!! Hier heb ik 2 dagen en nachten naar lopen zoeken!!! Stom, heb nooit gezien dat ze uit gezet waren/konden worden! Je kan ze overigens ook makkelijk aanzetten onder /dev-state. Als de automation op off staat, dan staat hij uit:
@trekker22 Natuurlijk kan dat
En via /dev-service kun je o.a. automations beheren qua status[Afbeelding]
Do not argue with a fool. He will drag you down to his level and beat you with experience.
Uhmm.. het werkt niet
Voor elektra werkt alles wel en voor gas krijg ik wel de "Dag totaal" en de "Total", maar het huidige verbruik
In de "Home › Consumption › Gas consumption ›" zie ik wel een 'current delivered' staan, maar verder kom ik 'm niet tegen.
Welk reading field gebruiken jullie voor die "dsmr/reading/gas_currently_delivered"? Want "gas_currently_delivered" lijkt niet goed te zijn. Of moet ik die nog ergens toevoegen?
Sarcasm is my superpower! What's yours?
Mijn configuratie is als volgt::
[...]
[...]
Uhmm.. het werkt niet
Voor elektra werkt alles wel en voor gas krijg ik wel de "Dag totaal" en de "Total", maar het huidige verbruik
In de "Home › Consumption › Gas consumption ›" zie ik wel een 'current delivered' staan, maar verder kom ik 'm niet tegen.
Welk reading field gebruiken jullie voor die "dsmr/reading/gas_currently_delivered"? Want "gas_currently_delivered" lijkt niet goed te zijn. Of moet ik die nog ergens toevoegen?
Day consumption (as JSON) configuration
code:
1
2
3
4
5
| [mapping] electricity1 = electricity1 electricity2 = electricity2 electricity_merged = electricity_merged gas = gas |
Telegram (as JSON) configuration
code:
1
2
3
4
5
6
7
8
9
10
11
12
| [mapping] id = id timestamp = timestamp electricity_currently_delivered = electricity_currently_delivered electricity_delivered_1 = electricity_delivered_low electricity_delivered_2 = electricity_delivered_normal electricity_tariff = electricity_tariff phase_currently_delivered_l1 = phase_currently_delivered_l1 phase_currently_delivered_l2 = phase_currently_delivered_l2 phase_currently_delivered_l3 = phase_currently_delivered_l3 extra_device_timestamp = gas_timestamp extra_device_delivered = gas_delivered |
Sorry, ik heb geen gas in huis, dus ook geen gas meter...:
[...]
[...]
Uhmm.. het werkt niet
Voor elektra werkt alles wel en voor gas krijg ik wel de "Dag totaal" en de "Total", maar het huidige verbruik
In de "Home › Consumption › Gas consumption ›" zie ik wel een 'current delivered' staan, maar verder kom ik 'm niet tegen.
Welk reading field gebruiken jullie voor die "dsmr/reading/gas_currently_delivered"? Want "gas_currently_delivered" lijkt niet goed te zijn. Of moet ik die nog ergens toevoegen?
Dat is de 'dag totaal', die werkt inderdaad.
Die eerste is een timestamp en die tweede het totale gas verbruik tot op dat moment.
Ik wil dus het actuele verbruik, net als wat bij elektriciteit kan en wat de DSMR add-on van Hass.io kan.
De waarde is er dus wel in DSMR Reader, maar ik krijg 'm er niet uit.
Dat
werkt dus niet.
Ik heb een v5
Binnen DSMR Reader is het actuele gas verbruik ook wel bekend.
Op de "/admin/dsmr_consumption/gasconsumption/" pagina is de "Currently delivered" waarde dan ook te zien.
Wat echter niet lukt, en wat volgens @UTMachine en @Zandpad mogelijk moest zijn met een kleine topic aanpassing, is deze waarde met MQTT naar Hass pushen.
Na wat zoeken blijkt DSMR Reader het dus toch écht niet te kunnen exporteren.
Net als de Hass DSMR sensor component voert de Reader berekeningen uit om op basis van het verschil tussen timestamp 1 & 2 tot een actueel verbruik te komen.
Reader kan deze waarde dan wél in z'n eigen interface tonen, maar in tegenstelling tot het Hass component niet versturen.
[ Voor 35% gewijzigd door Nnoitra op 31-01-2019 00:45 ]
Sarcasm is my superpower! What's yours?
Heb je daarvoor geen DSMR v5 meter nodig? V2 en v4 rapporteren volgens mij veel minder frequent voor gas
@Nnoitra Andere aanpak en misschien niet zoals je hem wilt, maar ach Ik kan hem niet testen want ik heb geen v5 meter, maar voor elektriciteit werkt het prima
https://dsmr-reader.readthedocs.io/nl/latest/api.html#id14
Ik gebruik de API om elke eerste van de maand de huidige totalen op te halen en die te versturen. Hoef ik niet met mijn hoofd in meterkast te hangen
@Nnoitra Andere aanpak en misschien niet zoals je hem wilt, maar ach
Ik kan hem niet testen want ik heb geen v5 meter, maar voor elektriciteit werkt het prima https://dsmr-reader.readthedocs.io/nl/latest/api.html#id14
Ik gebruik de API om elke eerste van de maand de huidige totalen op te halen en die te versturen. Hoef ik niet met mijn hoofd in meterkast te hangen
[ Voor 70% gewijzigd door lolgast op 31-01-2019 07:20 ]
Die specifieke call is voor electriciteit en er is geen gas variant beschreven.:
@Nnoitra Andere aanpak en misschien niet zoals je hem wilt, maar ach
https://dsmr-reader.readthedocs.io/nl/latest/api.html#id14
Daarnaast lijkt Reader alles eerst in z'n database te gooien en vanaf daar beschikbaar te maken voor MQTT/Rest.
En omdat het actuele gas verbruik 'on the fly' berekend lijkt te worden, staat het niet in de database en is het niet te exporteren.
Sarcasm is my superpower! What's yours?
Build van Hassio volgt altijd later na de release, hoelang er tussen zit was altijd wel een paar dagen tussen maar had de vraag even @ discord gedaan voor @JBS maar kan dat hier ook delen (lijkt mij). Hier kun je dus zien welke versie als stable is -> https://s3.amazonaws.com/hassio-version/stable.json of beta https://s3.amazonaws.com/hassio-version/beta.json
Edit:
Update commando zou zijn
code:
1
| hassio ha update --version=0.86.4 |
[ Voor 16% gewijzigd door lubbertkramer op 31-01-2019 15:11 ]
Hier ook geüpdatet. Enkel wat wijzigingen van time naar time-pattern benodigd. Fijn dat HASS nu op mobiel een stuk sneller start omdat Lovelace de standaard is geworden.
/u/137180/TS4YTL60R.png?f=community)
Ik gebruik de DSMR reader die in home assistant zit en daarmee heb ik zowel de gasmeter stand als mede het verbruik van de laatste 5 minuten.:
[...]
Dat is de 'dag totaal', die werkt inderdaad.
[...]
Die eerste is een timestamp en die tweede het totale gas verbruik tot op dat moment.
Ik wil dus het actuele verbruik, net als wat bij elektriciteit kan en wat de DSMR add-on van Hass.io kan.
De waarde is er dus wel in DSMR Reader, maar ik krijg 'm er niet uit.
Dat
[...]
werkt dus niet.
[...]
Ik heb een v5
Binnen DSMR Reader is het actuele gas verbruik ook wel bekend.
Op de "/admin/dsmr_consumption/gasconsumption/" pagina is de "Currently delivered" waarde dan ook te zien.
Wat echter niet lukt, en wat volgens @UTMachine en @Zandpad mogelijk moest zijn met een kleine topic aanpassing, is deze waarde met MQTT naar Hass pushen.
Na wat zoeken blijkt DSMR Reader het dus toch écht niet te kunnen exporteren.
Net als de Hass DSMR sensor component voert de Reader berekeningen uit om op basis van het verschil tussen timestamp 1 & 2 tot een actueel verbruik te komen.
Reader kan deze waarde dan wél in z'n eigen interface tonen, maar in tegenstelling tot het Hass component niet versturen.
[edit]
sorry je wist al dat het kon
aan de hand van jou en op internet knutsel ik dit in elkaar; de automation wordt getriggerd maar geen response:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| initial_state: 'on'
trigger:
platform: event
event_type: click
event_data:
entity_id: sensor.double_switch_keuken_schuifdeur_links_click
action:
- service: mqtt.publish
data:
topic: 'zigbee2mqtt/group_spots_kozijn/set'
payload_template: >
{% if trigger.event.data['click'] == 'left' %}
'{"state":"ON"}'
{%- else -%}
'{"state":"OFF"}'
{%- endif %} |
Kennelijk komt hij nu altijd in de ELSE uit. Hoe kan ik nou makkelijk inspecteren wat de waarde van trigger.event.data['click'] is? En heb ik wel de goede. In de states staat wel gewoon dit:
sensor.double_switch_keuken_schuifdeur_links_click
battery: 100
voltage: 3085
linkquality: 70
click: left
friendly_name: double_switch_keuken_schuifdeur_links_click
icon: mdi:toggle-switch
Echt makkelijk debuggen is het niet in HASS
En entiteiten mogen niet meer beginnen of eindigen met een underscore
"There is that sort of assumption by the government that we're all driving around at 8 o'clock in the morning to be really annoying"
~ James May
:strip_icc():strip_exif()/u/2026/DSC_2281.jpg?f=community)
Ik gebruik HA 0.86.4 i.c.m. Homekit, alleen heb ik sinds kort problemen bij het activeren van b.v. de Homekit scene weltrusten die al mijn Hue en Tradfri lampen uit zou moeten schakelen, het probleem is dat random lampen aan blijven staan.
Als ik al mijn lampen in een keer uitschakel via HA zelf of via de Hue app, dan werkt het prima.
Ik zie de volgende fouten terug in de log na het uitvoeren van de scene:
Ik heb .homekit.state al eens verwijderd en Homekit opnieuw geconfigureerd, maar het probleem blijft bestaan.
De Hue hub is constant bereikbaar.
Iemand tips voor me?
Als ik al mijn lampen in een keer uitschakel via HA zelf of via de Hue app, dan werkt het prima.
Ik zie de volgende fouten terug in de log na het uitvoeren van de scene:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| 2019-02-01 09:51:17 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step
result = coro.throw(exc)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/service.py", line 287, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/hue/light.py", line 411, in async_turn_off
await self.light.set_state(**command)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/lights.py", line 112, in set_state
json=data)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/bridge.py", line 69, in request
) from None
aiohue.errors.RequestError: Error requesting data from 172.16.1.9: [Errno 104] Connection reset by peer
2019-02-01 09:51:17 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step
result = coro.throw(exc)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/service.py", line 287, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/hue/light.py", line 411, in async_turn_off
await self.light.set_state(**command)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/lights.py", line 112, in set_state
json=data)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/bridge.py", line 69, in request
) from None
aiohue.errors.RequestError: Error requesting data from 172.16.1.9: [Errno 104] Connection reset by peer
2019-02-01 09:51:17 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step
result = coro.throw(exc)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/service.py", line 287, in _handle_service_platform_call
await getattr(entity, func)(**data)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/hue/light.py", line 411, in async_turn_off
await self.light.set_state(**command)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/lights.py", line 112, in set_state
json=data)
File "/srv/homeassistant/lib/python3.5/site-packages/aiohue/bridge.py", line 69, in request
) from None
aiohue.errors.RequestError: Error requesting data from 172.16.1.9: [Errno 104] Connection reset by peer
2019-02-01 09:51:17 ERROR (MainThread) [homeassistant.components.hue.light] Unable to reach bridge 172.16.1.9 (Error requesting data from 172.16.1.9: [Errno 104] Connection reset by peer) |
Ik heb .homekit.state al eens verwijderd en Homekit opnieuw geconfigureerd, maar het probleem blijft bestaan.
De Hue hub is constant bereikbaar.
Iemand tips voor me?
ik snap enigszins wat je bedoeld. Echter hoe laat ik een sensor die in de dev-state van waarde zie veranderen:
- deze waarde verandering oppakken als event (dus moet het via event of toch als state?)
- hoe krijg ik de click waarde er uit?
Want nu wordt hij ook niet eens getriggerd zie ik vanuit het logbook. Trouwens de sensors is een zigbee2mqtt sensor maar staat dus netjes via de integrations in het entiteiten overzicht.
Zo'n dingen zijn volgens mij nauwelijks in de docs van hass terug te vinden? (vroeger best wel wat geprogrammeerd maar zie ik echt vaak niet hoe te beginnen :-) )
https://imgur.com/a/cQP3Ab6
hierboven is die netjes in dev-state te zien en pakt die mooi de wisselende waardes op. Hoe pak ik dit op in een eigen automation?
[ Voor 8% gewijzigd door trekker22 op 01-02-2019 11:26 ]
Dit topic is gesloten.