Het Grote OpenHAB topic - deel 1

[SiErRa]

Die %nogwat zijn string formats. Dus hoe geef je de staat van een item weer als een regel tekst.

Dit is optioneel bij een item, dus als je dat bij je item definities niet hebt, dan heb je niet hetzelfde issue.
Naast items kan dit zo uit het hoofd volgens mij ook in sitemaps zitten.

[Klein_Kipje]

Bovenste zorgt voor storing in het habpanel, onderste niet (natuurlijk)

DateTime CurrDateTime "Vandaag [MAP(astro.map):%1$tA]"

DateTime CurrDateTime "Vandaag:%1$tA]"

Let wel, in de basicui / sitemap etc werkt het wel gewoon, het gaat gewoon om de 'storing' dat bij het panel steeds connections lost voorkomt.

Is het ook mogelijk om vertalingen door te voeren in de orginele bestanden ipv met een .map te werken ?

[GENETX]

Misschien is het ook handig om de astro.map te posten.

Het lijkt wel meer problemen op te leveren overigens:
https://community.openhab...p-transformation/27818/28
https://community.openhab...hown-in-habpanel/19518/25

Nu zou het soort van gefikst moeten zijn dus, maar wellicht heb je een uitzondering te pakken.

Je kan echter nog één ding proberen. In OpenHAB zit in het Paper UI ook ergens een optie om de locale in te stellen. Deze is default in het engels, Maar NL-nl zou wellicht de oplossing kunnen zijn voor je probleem. Note, ik heb dat zelf niet geprobeerd.

In alle andere gevallen zou ik even een topic openen, of report doen in de tweede link, dat dit nog nie tlijkt te werken.

Direct doorvoeren lijkt me een vrij complexe operatie. Grote kans dat het ergens onderwater wordt toegepast... Ik bedenk me echter dat ik nog een hack heb . De eerste betas van OpenHAB hadden ook nog een format error. Ik heb daarin een tweede string item aangemaakt welke ik display:
https://github.com/GENETX...er/conf/rules/uifix.rules

Wellicht kun je ook zoiets toepassen, al weet ik niet of (en hoe) je een mapping hier aan toe kan voegen. Anders kan je ook makkelijk met een dag comparison te doen en dan die string juist te vullen. Wat code:
https://github.com/GENETX...r/conf/rules/gerwin.rules

Hoe dan ook, ik zou het sowieso even melden op het OpenHAB forum zodat iemand het kan gaan fixen.

[ Voor 35% gewijzigd door GENETX op 19-10-2017 09:10 ]

[Klein_Kipje]

Ik ben ondertussen overgestapt naar een oude pc met ubuntu 16.x vanwege de schrijf/lees toestanden op een rasp. Gelijk alles ingesteld in NL taal en dat werkt gewoon.

Verder nu bezig om het astro en rules de buitenverlichting laten aangaan savond en smorgens.

[PlayItHard1989]

Deze week was ik verder aan de slag gegaan met Openhab 2 om deze verder te integreren met KNX en de rest van de verschillende dingen in huis.

Nu heb ik na een update en wat config updates gemerkt dat er ineens een grote delay was met de commando's naar de KNX bus. Na wat troubleshooting bleek openhab de KNX bus te spammen met een massa telegrams, dus heb ik maar beslist om alles volledig opnieuw in te stellen.

Eens opnieuw ingesteld nog altijd, al is het iets minder, een delay met acties naar de bus. Via de openhab community heb ik een nieuwere test versie (1.11) van de KNX binding terug gevonden die de situatie nog iets verbeterde.

Maar ik blijf nog altijd met het probleem zitten dat Openhab een telegram dubbel verstuurd naar de bus. Alsook krijg ik volgende meldingen in de log files:

code:

Autorefresh: Cannot read value for item 'Light_GF_Bureau' from KNX bus: no confirmation reply received for L-Data.req from 1.1.251 to 1/0/4, low priority hop count 6 repeat tpdu 00 00: timeout

en

code:

Value '0' could not be sent to the KNX bus using datapoint 'command DP 1/3/7 Light_GF_Bureau_Spots, DPT main 0 id 5.001, low priority' - giving up after second try: no confirmation reply received for L-Data.req from 1.1.251 to 1/3/7, low priority hop count 6 repeat tpdu 00 80 00

Iemand enig idee hoe dit op te lossen valt?

[teaser]

PlayItHard1989 schreef op woensdag 1 november 2017 @ 18:45:
Maar ik blijf nog altijd met het probleem zitten dat Openhab een telegram dubbel verstuurd naar de bus. Alsook krijg ik volgende meldingen in de log files:

code:

Autorefresh: Cannot read value for item 'Light_GF_Bureau' from KNX bus: no confirmation reply received for L-Data.req from 1.1.251 to 1/0/4, low priority hop count 6 repeat tpdu 00 00: timeout

en

code:

Value '0' could not be sent to the KNX bus using datapoint 'command DP 1/3/7 Light_GF_Bureau_Spots, DPT main 0 id 5.001, low priority' - giving up after second try: no confirmation reply received for L-Data.req from 1.1.251 to 1/3/7, low priority hop count 6 repeat tpdu 00 80 00

Iemand enig idee hoe dit op te lossen valt?

Heb je al eens een capture gedaan van de bus in de bus of group monitor in ETS? Zoja, wat zie je hier dan? Hoeveel telegrams per seconde? Veel dubbele telegrams?
Hoe ziet je bustopologie eruit? Welke IP interface heb je?

Bij het opstarten spamt OpenHab altijd de bus even met een hoop read requests, dat is niet abnormaal. Maar dit mag zeker niet blijven duren.

[PlayItHard1989]

Dubbele telegrams krijg ik enkel wanneer er een commando naar de bus verzonden wordt. Bustopologie is 1 lijn met daar alle componenten op.

Als IP interface gebruik ik de Weinzierl 730, deze heeft de mogelijkheid om 5 tunnels tegelijkertijd toe te laten dus geen enkel probleem om ETS en OpenHAB samen te gebruiken.

[ice-T106]

Misschien HabPanel ook maar toevoegen aan de OP. Is toch wel 1 van de mooie pluspunten van OpenHab naar mijn idee.
Draai het nu op een Android tablet in Fully Kiosk Browser. Om bijvoorbeeld het scherm pas aan te laten gaan als de front camera beweging detecteert.

Zou nu nog een wat grotere (liefst witte) tablet die ik aan de muur kan bevestigen. Hoeft alleen maar HapPanel in Fully Kiosk te draaien. Iemand nog een betaalbare tip?

[CyBeRSPiN]

ice-T106 schreef op maandag 13 november 2017 @ 16:00:
Misschien HabPanel ook maar toevoegen aan de OP. Is toch wel 1 van de mooie pluspunten van OpenHab naar mijn idee.
Draai het nu op een Android tablet in Fully Kiosk Browser. Om bijvoorbeeld het scherm pas aan te laten gaan als de front camera beweging detecteert.

Gaaf! Waar heb je die hangen en hoe bevalt dat? Gebruik je het als dashboard of ook om zaken te schakelen?

[ice-T106]

Heb heb nu nog niet op zij definitive plek hangen (want nog op zoek naar grotere (witte) tabel). Maar komt bij de thermostaat en de bediening van de afzuiging (in de woonkamer) te hangen. Kan ik mooi de stroom kabel door de buis trekken van 1 van die twee. Is een combinatie van status, controle en camera beelden nu, dus kom al snel plek te kort bij 1 screen .

[Klein_Kipje]

Er is op het openhab forum een topic hierover ook met tips voor betaalbare tablet en allerlei tips/hints om ze tegen de wand aan te hangen/plakken.

Ik loop tegen het volgende aan:

Ik heb een aantal rules om mijn buitenlicht aan en uit te doen icm met de astrobinding. licht gaat aan als de zon opkomt
Channel 'astro:sun:05149f62:rise#event' triggered START

Dit werk perfect, kan ik zien in mijn events.log het enigste is dat dit bv een aantal dagen goed werkt en vervolgens 'gebeurt' dit niet meer. net of de astrobinding niet meer werkt. Maar in mijn basic UI panel wordt de tijden van zonsopgang en ondergang wel gewoon aangepast.

[ice-T106]

@Klein_Kipje Heb je toevallig OpenHab 2.1? Staat hier namelijk in het topic als een bekend issue dan.

[Klein_Kipje]

@ice-T106 Ik heb idd openhab2.1, ff zoeken dan. Bedankt!

[siepeltjuh]

@Klein_Kipje Misschien kun je elevation gebruiken? Zodra deze onder 5º komt laat ik de lamp inschakelen en om middernacht laat ik hem uitzetten. Werkt vergelijkbaar als zonsopkomst/ondergang. In de praktijk bevalt me het moment van inschakelen ook beter dan zonsondergang.

code:

Number      buiten_zon_elevation        "Elevatie [%.2f º]"     <sun>           (_grpBuiten, _grpAstro)     { channel="astro:sun:local:position#elevation" }

[Klein_Kipje]

Het gaat eigenlijk niet zozeer om welk channel ik gebruik. Als ik sunset of sunrise of zoiets gebruik gaat dit ook goed, ik zie in mijn event.log dat als dat channel voorbijkomt het licht gewoon aangaat, maar op een gegeven moment komt het channel niet meer langs, net of de binding gestopt is met werken

[ice-T106]

Ik gebruik ook gewoon sunrise en sunset maar dan met OpenHab 2.0 en nog geen issues gehad.

[ice-T106]

Dit heb ik nu al eerste versie van mijn tablet interface.
Main woonkamer Dashboard:

Extra power dashboard:

[pepijn-dik]

hey Iedereen,


ik heb een vraag ik wil een ac dimmer gaan kopen:

http://www.benl.ebay.be/i...1db128:g:WT4AAOSwYlRZGXXF


deze komt dan aan een arduino uno te hangen met een ethernet board.
nu zou ik deze graag aan mijn openhab2 willen kopelen.

zelf ben ik erg nieuw in dit gebied nu na weken op google zoeken en youtube filmpjes kijken kom ik er nog steeds niet uit.

dacht zelf dat mqqt de beste oplossing is

Hoop dat iemand mij zou kunnen helpen hier mee heb ondertussen de helft van dit topic gelezen en zover ik zag ging het nog niet hier over

[GENETX]

Je link doet het niet. Maar hoe dan ook, het klinkt als een mateloos ingewikkeld hobby bob project waar veel tijd in gaat zitten. Waarom pak je niet gewoon een kant en klare oplossing zoals ikea tradfri of een setje milight?

Edit, ik zie dat je het al eerder gevraagd had
pepijn-dik in "Het Grote OpenHAB topic - deel 1"

En
pepijn-dik in "Het Grote OpenHAB topic - deel 1"

Je zal met custom spul natuurlijk weinig vinden. Maar er is natuurlijk genoeg over mqtt te vinden. Ik zou het gewoon rustig opbouwen in stapjes. Eerst direct een lamp dimmen of laten pulseren. Dan daar een mooie functie voor maken. En pas vervolgens een API bakken om dat extern te doen met openhab. Het hoeft ook geen mqtt te zijn he. Een REST api werkt ook makkelijk, al is dat minder flexibel.

Maar je zal het zelf moeten doen. En denk wel goed na of je custom spul wil inzetten voor zoiets essentieels als verlichting. Als deze eerste stap al niet lekker loopt dan zou ik verder kijken to be honest. Domotica is nogal mission critical

[ Voor 69% gewijzigd door GENETX op 18-11-2017 08:25 ]

[PlayItHard1989]

Ik heb nog wat verder gezocht over het probleem met de dubbele telegrams en ben op volgende post gestoten: https://community.openhab.org/t/oh2-knx-1-9-binding-read-from-knx-results-in-a-write/19020/32

Blijkbaar een probleem dat al even meegaat.

Iemand die hier een omweg/oplossing voor gevonden heeft?

[teaser]

Dat probleem is niet nieuw nee.
Zelf heb ik er geen last van momenteel (doet zich wel voor hier). Als het problematisch wordt, dan bekijk ik het wel eens.

[CyBeRSPiN]

Eindelijk mn OpenHAB config weer wat aandacht gegeven. MQTT toegevoegd zodat ik dsmr-reader en OpenTherm Gateway metingen rechtstreeks kan tonen.
(helaas wel weer alles from scratch want kon niet vanaf 2.0 rc release naar 2.1 stable via apt)

Erg gaaf toch wel. Nu allerlei extra mogelijkheden, kan nu triggeren op het tappen van warm water (gebruiken we enkel in de badkamer), binnenkort aansturing van de afzuiging automatiseren

Ook eindelijk mijn werk aan een nieuwe binding voor Denon / Marantz receivers afgerond, de eerste tests zien er goed uit. Viel me vies tegen hoeveel werk het was, en nog hoop te doen denk ik om het officieel te mogen pushen naar de repo (documentatie, code standards etc). Maar geeft wel voldoening dat anderen er ook plezier van gaan hebben.

Wil binnenkort iets gaan maken zodat de melding dat de wasmachine/droger klaar is ook het bedrag voor stroom vermeldt, stukje bewustwording om minder in de droger te doen

OpenHAB is lastig om te leren, maar toch wel echt volwassen als je naar de Rules kijkt. Bijv. kunnen differentieren of een update van een item door een knop kwam of door een normale update van waarde. (if Item x received command ... vs if Item x received update).

[ Voor 3% gewijzigd door CyBeRSPiN op 24-11-2017 16:06 ]

[Bigs]

Is er iemand die z'n 'domme' elektriciteitsmeter uitleest naar OpenHAB adhv een 1000 imp/kWh ledje? Ik heb al wat onderdelen als een ESP8266 en photodiodes liggen, maar ben er nog niet uit hoe ik het aan ga pakken. Het doel is om in OpenHAB het actuele energieverbruik in Watt te kunnen zien en daarvan geschiedenis bij te houden. kWh's zie ik op de meter wel

[CyBeRSPiN]

Bigs schreef op vrijdag 24 november 2017 @ 16:31:
Is er iemand die z'n 'domme' elektriciteitsmeter uitleest naar OpenHAB adhv een 1000 imp/kWh ledje? Ik heb al wat onderdelen als een ESP8266 en photodiodes liggen, maar ben er nog niet uit hoe ik het aan ga pakken. Het doel is om in OpenHAB het actuele energieverbruik in Watt te kunnen zien en daarvan geschiedenis bij te houden. kWh's zie ik op de meter wel

Ik denk dat je eerst een grotere uitdaging hebt voordat je richting OpenHAB wat te pushen hebt
Volgens mij valt het vies tegen. In YouLess pulsteller/elektriciteitsmeter staat een kant en klare pulsteller beschreven, die kost net zoveel als het (sneller dan gepland) plaatsen van de slimme meter die je waarschijnlijk toch wel krijgt binnen afzienbare tijd.

[Bigs]

Mwa met 15 jaar softwareontwikkeling waaronder een deel embedded moet het wel lukken het tellen van pulsjes lukt wel. Waar ik vooral mee zit is hoe ik de waarde in OpenHAB ga opslaan en waar/hoe ik het actuele wattage ga bepalen.

Het makkeijkste is om al het rekenwerk op de ESP te doen en het wattage via MQTT naar OpenHAB te sturen, maar dan mis ik de mogelijkheid om in de toekomst kWh’s in OpenHAB bij te houden.

[CyBeRSPiN]

Bigs schreef op vrijdag 24 november 2017 @ 18:21:
Mwa met 15 jaar softwareontwikkeling waaronder een deel embedded moet het wel lukken het tellen van pulsjes lukt wel. Waar ik vooral mee zit is hoe ik de waarde in OpenHAB ga opslaan en waar/hoe ik het actuele wattage ga bepalen.

Het makkeijkste is om al het rekenwerk op de ESP te doen en het wattage via MQTT naar OpenHAB te sturen, maar dan mis ik de mogelijkheid om in de toekomst kWh’s in OpenHAB bij te houden.

Ah ok
Nou ik zou wel die ESP gebruiken om per vaste hoeveelheid pulsen (honderd/duizend pulsen) een los bericht te sturen en dat dan gebufferd via MQTT te pushen (naast het actuele verbruik).
En dan in OpenHAB item_kWh += (0.)1 te doen.
En parallel daaraan het actuele ‘wattage’ (is dat een eenheid?) op de ESP bepalen (pulsen per vaste tijdseenheid) en op MQTT te zetten om zo veel mogelijk het actuele verbruik te zien.

[GENETX]

Vermogen , maar er zijn natuurlijk heel veel technici de nederlandse taal verketteren door het constant over voltage, amperage en wattage te hebben in plaats van spanning, stroom en vermogen

Maar ik zou gewoon beide berekenen op de ESP en dan ook beiden doorsturen, tenminste, ik neem aan dat je meerdere kanalen kan aanmaken. Vervolgens gewoon zorgen dat je in OpenHAB 2 number items hebt (of eventueel nog meer, om bijvoorbeeld ook dagverbruik bij te houden.

Helemaal ideaal is om de data via OpenHAB ook naar InfluxDB te loggen. Dan kun je met Grafana een mooi dashboard aanmaken, waarbij je data van meerdere intervallen kan agregeren/middelen en daar evt een berekening op los laten om het verbruik in kWh te krijgen per uur, dag, week, maand, you name it.

[Bigs]

Dubbel opslaan is eigenlijk wel voor de hand liggend. Ik ga ermee aan de slag. Blog post volgt.. ooit

[fjux]

Bigs schreef op zaterdag 25 november 2017 @ 17:52:
Dubbel opslaan is eigenlijk wel voor de hand liggend. Ik ga ermee aan de slag. Blog post volgt.. ooit

Ik stuur met mijn ESP 2 waardes door hiervoor.

1x huidig wattage (berekend op de ESP)
1x aantal pulsen sinds vorige verzending van data.

Je weet hoeveel khh iedere puls is dus kun je ook je totale verbruik meten!

Maar dinsdag krijg ik een slimme meter dus dat wordt de boel ombouwen naar P1!

[supersook]

Even een cross-post vanuit het [Xiaomi / Aqara] Ervaringen & discussie topic: zijn er hier Tweakers die de Xiaomi Binding onder OpenHAB gebruiken, en zo ja, wat zijn jullie ervaringen?

Zelf heb ik een groeiende OpenHAB setup waarin oa. de volgende elementen samen komen: SonOff (via MQTT), OTGW & MySensors (ESP met nrf24+ nodes).

Als iemand nog een goede suggestie heeft voor een vervanging van de inbouwschakelaars door iets wat ik via OpenHAB kan uitlezen/aansturen (met behoud van de lokale functie), dan hou ik me aanbevolen!

[paQ]

Ik heb na 3 dagen klooien, eindelijk een BT gordijn motor aan de praat in openHab2, middels een csrmesh script.
Nu is het de bedoeling dat dit in Homekit terecht komt. Via homebdrige is dit nog wel een dingetje kom ik achter, is het niet? Is er iemand die een goede tutorial weet, want het is me een beetje gaan duizelen
Het is overigens alleen dit ene item in een poepiesimpele sitemap.


KHIDW&*^W&*D%^W*& ik zie nu pas dat homebridge-openhab gewoon BAM homebrdige overschreven heeft! takke... kan ik weer opnieuw inrichten

[ Voor 24% gewijzigd door paQ op 03-12-2017 23:06 ]

[GENETX]

OpenHAB 2.2 is ook uit: https://github.com/openhab/openhab-distro/releases

Echter, mogelijk heb ik binnenkort ook iemand nodig die de TS wil overnemen. OpenHAB is bij mij toch soms iets te instabiel en ik vind de ontwikkelingen relatief traag gaan. Home Assistant maakt grote sprongen en is nu wel op het niveau dat ik er op over zou kunnen/willen stappen. De eerste integratietests daarvoor heb ik al genomen en zijjn positief (als in, alle apparatuur werkt en benodigde functionaliteit lijkt te werken).

[SiErRa]

supersook schreef op zondag 26 november 2017 @ 18:59:
Als iemand nog een goede suggestie heeft voor een vervanging van de inbouwschakelaars door iets wat ik via OpenHAB kan uitlezen/aansturen (met behoud van de lokale functie), dan hou ik me aanbevolen!

Ik zie eigenlijk drie varianten, Zigbee light link, zoals de oplossing van Busch Jaeger: https://www.busch-jaeger....ontrol/zigbee-light-link/

+ past mooi als je dit schakelmateriaal al hebt
+ kan zowel op batterij als eigen stroomkring
- Lijkt alleen echt mooi te werken met de Zigbee binding, die nog niet echt af is, en je er een usb-stick in je OpenHAB server voor nodig hebt. Via de Hue binding is het beperkt, omdat het net als een afstandbediening wordt gezien.
- Duur

De andere optie zijn Z-Wave modules achter je schakelmateriaal

+ huidig schakelmateriaal blijft behouden
+ Z-Wave binding is inmiddels wel stabiel
- inbouwen is heel krap
- blauwe draad nodig achter je schakelaars (die zit er standaard niet)

Tenslotte iets bedraads als KNX (maar daar heb ik niet zoveel kaas van gegeten).

[Mars Warrior]

GENETX schreef op woensdag 20 december 2017 @ 22:06:
OpenHAB 2.2 is ook uit: https://github.com/openhab/openhab-distro/releases
Echter, mogelijk heb ik binnenkort ook iemand nodig die de TS wil overnemen. OpenHAB is bij mij toch soms iets te instabiel en ik vind de ontwikkelingen relatief traag gaan. Home Assistant maakt grote sprongen en is nu wel op het niveau dat ik er op over zou kunnen/willen stappen. De eerste integratietests daarvoor heb ik al genomen en zijjn positief (als in, alle apparatuur werkt en benodigde functionaliteit lijkt te werken).

Helemaal gelijk. 1x 6 maanden een update vs elke 2 weken. OH2 vordert maar langzaam en blijft een beetje een waterhoofd, zeker vergeleken met de Python basis van HASS/HAAS of wat de afkorting tegenwoordig ook is

Ik blijf ook maar aanklooien met OH2 icm met de WoningApp van Apple. Zo instabiel als wat. Moet soms meerdere keren per dag opnieuw koppelen. Waardeloos dus. En dat is niet het enige probleem met OH2.

Echter geen idee of HASS/HAAS nu zoveel eenvoudiger is. Met die snelle ontwikkelingen gebeurt het ook vaak dat een nieuwe versie het niet meer doet door 'braking changes'.

Maar jij gaat dus in ieder geval de overstap wagen. Ben benieuwd naar je ervaringen.
Wordt het een big boom of ga je (als dat kan) parallel draaien en stapsgewijs over?

[GENETX]

Eenvoudiger is het niet om alles naar mijn hand te zetten. Zeker qua config is OpenHAB wel beter, maar ik denk dat AppDaemon veel goedmaakt voor het schrijven en onderhouden van rules. Een aantal zaken zijn wel erg mooi, zoals de google calenderar integratie, die ik met openhab nooit lekker werkend kreeg.

Updaten doe ik sowieso manueel als ik tijd heb, dus die breaking changes zijn voor mij geen issue en misschien juist wel goed voor de snelle ontwikkeling. of k in een keer overga weet ik nog niet. Hangt er van af hoe snel ik de basiszaken geautomatiseerd heb, dat ik tijdelijk een aantal zaken manueel moet doen is niet zo erg iig.

En terwijl ik dit type crasht openhab weer eens

[ Voor 4% gewijzigd door GENETX op 22-12-2017 15:19 ]

[Mars Warrior]

GENETX schreef op vrijdag 22 december 2017 @ 15:19:
En terwijl ik dit type crasht openhab weer eens

Ik ken het, en daarna doet iha mijn Woning koppeling het niet mee en moet ik opnieuw koppelen.

Maar goed. Toch ook eens kijken wat HASS is. Met MQTT kan ik hopelijk al eenvoudig wat dingetjes koppelen om te zien hoe eea werkt.

Ik zie dat ze ook een panel hebben voor aan de wand. Leuk!

[supersook]

SiErRa schreef op vrijdag 22 december 2017 @ 13:54:
[...]


Ik zie eigenlijk drie varianten, Zigbee light link, zoals de oplossing van Busch Jaeger: https://www.busch-jaeger....ontrol/zigbee-light-link/

+ past mooi als je dit schakelmateriaal al hebt
+ kan zowel op batterij als eigen stroomkring
- Lijkt alleen echt mooi te werken met de Zigbee binding, die nog niet echt af is, en je er een usb-stick in je OpenHAB server voor nodig hebt. Via de Hue binding is het beperkt, omdat het net als een afstandbediening wordt gezien.
- Duur

De andere optie zijn Z-Wave modules achter je schakelmateriaal

+ huidig schakelmateriaal blijft behouden
+ Z-Wave binding is inmiddels wel stabiel
- inbouwen is heel krap
- blauwe draad nodig achter je schakelaars (die zit er standaard niet)

Tenslotte iets bedraads als KNX (maar daar heb ik niet zoveel kaas van gegeten).

Dank voor je reactie SiErRa!

De Z-Wave variant van Busch-Jaeger was de enige echt goede optie die ik kon vinden, maar wel lekker aan de prijs helaas (en inmiddels obsolete volgens mij). De Zigbee variant was ik nog niet tegen gekomen, dus die zal ik eens nader bekijken . Uiteraard pas bruikbaar als de binding volwassen is.

KNX of achterbouw modules zijn geen fijne retrofit wat mij betreft. Eigenlijk snap ik niet dat hier niet meer aanbod in is, want ik zie dit toch wel als redelijk gat in de markt

Edit: goeiendag, die nieuwe Zigbee Light-link variant van Busch-Jaeger is een factor 2 duurder dan de Z-Wave variant (knop voor op de inbouwmodule kost ongeveer hetzelfde als de inbouwmodule zelf). Ziet er wel een heel stuk strakker uit, dat dan weer wel

[ Voor 17% gewijzigd door supersook op 22-12-2017 16:52 ]

[CyBeRSPiN]

Eindelijk de moeite genomen om HomeKit uit te proberen. Werkt lekker!
"Hé Siri, zet de kerstboom aan!"

Nu kijken hoe goed de geofencing werkt, heb switches aangemaakt die ik aan/uit zet als iemand aankomt/vertrekt.

[Bigs]

supersook schreef op vrijdag 22 december 2017 @ 16:09:
[...]


Dank voor je reactie SiErRa!

De Z-Wave variant van Busch-Jaeger was de enige echt goede optie die ik kon vinden, maar wel lekker aan de prijs helaas (en inmiddels obsolete volgens mij). De Zigbee variant was ik nog niet tegen gekomen, dus die zal ik eens nader bekijken . Uiteraard pas bruikbaar als de binding volwassen is.

KNX of achterbouw modules zijn geen fijne retrofit wat mij betreft. Eigenlijk snap ik niet dat hier niet meer aanbod in is, want ik zie dit toch wel als redelijk gat in de markt

Edit: goeiendag, die nieuwe Zigbee Light-link variant van Busch-Jaeger is een factor 2 duurder dan de Z-Wave variant (knop voor op de inbouwmodule kost ongeveer hetzelfde als de inbouwmodule zelf). Ziet er wel een heel stuk strakker uit, dat dan weer wel

Kijk even wat je met een KNX opstelling kwijt zou zijn voor zo'n knop + actor, dan is dit best een koopje

[ice-T106]

@GENETX Ik draait nog OpenHab 2.1 op een windows machine en heb eigenlijk nog nooit een crash gehad. Heb jij enig idee wat de crashes aan jouw kant veroorzaakt?

[GENETX]

Soms een java segfault. Ik zit zelfs nog op 2.0 dacht ik. Misschien ligt het ook wel aan de rest van de server, had eat weing geheugen. Nu ik wat swap er bij heb lijkt het weer mee te vallen.

Maar begin nu zelf wel de kracht van HA en de community te zien. Een aantal dingen werken gewoon zoveel beter dan OH. OH heeft wel andere leuke features, die HA mist, maar HA geeft me net wat meer. Graphs, webcams, google home en de google agenda componenten werken in HA echt wel retestrak. Straks gaat mn thermostaatschema gewoon in de agenda, idem voor de wekker. Kan ik ze direct aanpassen als het moet. Dat is quasi onmogelijk op een mooie manier in OH.

Ze staan nu ongeveer gelijk in mijn beleving, maar HA zal OH toch snel inhalen vermoed ik. Als ik kijk hoe karig de graphs update is bij OH, dan merk ik dat men blijft aanmodderen ipv dingen echt naar een hoger plan tilt. De architectuur is best goed on OH, maar de transitie naar 2 gaat wel erg brak. Na een jaar zit de deurbel nog steeds niet in de rfxcom 2 binding bijvoorbeeld...

[ Voor 22% gewijzigd door GENETX op 02-01-2018 09:32 ]

[supersook]

Bigs schreef op donderdag 28 december 2017 @ 22:03:
[...]

Kijk even wat je met een KNX opstelling kwijt zou zijn voor zo'n knop + actor, dan is dit best een koopje

True

Zojuist kwam ik een nieuwe speler in de markt tegen obv. Z-Wave: NEO Coolcam NAS - SC01ZE - 1 Light Switch. Is er ook in een 2-knops uitvoering. Wel een blauwe draad nodig, maar dat is vaak nog wel te organiseren .

Heeft in dezelfde serie ook nog een Fibaro-like plug (met power monitoring?), PIR sensor, deur/raam sensor en een water-sensor.

Voor die prijs ga ik het wel avonturen. Iemand nog een goede suggestie voor een Z-Wave controller voor de Raspberry Pi?

[ice-T106]

GENETX schreef op dinsdag 2 januari 2018 @ 09:25:
[...]
De architectuur is best goed on OH, maar de transitie naar 2 gaat wel erg brak. Na een jaar zit de deurbel nog steeds niet in de rfxcom 2 binding bijvoorbeeld...

Dit kan ik bevestigen. Helft met de UI en later toch weer config files doen is echt onhandig. Verder ben ik wel blij mee. Habpanel ziet er mooi uit en de meeste domotica systemen werken (nog) niet met de PlugWise USB stick.

[GENETX]

klopt, dat is het grote gemis in HA, ik hoop dat de mqtt tool blijft werken met HA...

[ Voor 5% gewijzigd door GENETX op 02-01-2018 12:07 ]

[CyBeRSPiN]

@GENETX heb je (veel) Z-wave in je setup? Is er een mooie ZWave configuratie in HA zoals OpenHAB dat heeft?

Mn config in OpenHAB wordt steeds mooier, maar ik zie ook dat HA een veel actievere community heeft, en een (denk ik) focus op zoveel mogelijk releases en nieuwe features in tegenstelling tot OH die vooral super stabiel wil blijven en een strakke architectuur wil behouden.

Heb net een nieuwe binding gesubmit, ben benieuwd hoe lang het gaat duren voordat ie een review krijgt..

Tegelijkertijd ook benieuwd naar hoe HA gaat uitpakken met mn spullen.

[ Voor 7% gewijzigd door CyBeRSPiN op 02-01-2018 14:46 ]

[GENETX]

Ik heb heel weinig, lees 0, z-wave in mijn setup.

[Mars Warrior]

GENETX schreef op dinsdag 2 januari 2018 @ 09:25:
[...] Graphs, webcams, google home en de google agenda componenten werken in HA echt wel retestrak. Straks gaat mn thermostaatschema gewoon in de agenda, idem voor de wekker. Kan ik ze direct aanpassen als het moet. Dat is quasi onmogelijk op een mooie manier in OH.

Mijn 1ste setup met OH is uit 2014. Als ik nu zie hoeveel er is verbetert (makkelijker, mooier, robuuster) dan vind ik dat zwaar tegenvallen. Je blijft maar wachten op volgende releases...

Ze staan nu ongeveer gelijk in mijn beleving, maar HA zal OH toch snel inhalen vermoed ik. Als ik kijk hoe karig de graphs update is bij OH, dan merk ik dat men blijft aanmodderen ipv dingen echt naar een hoger plan tilt. De architectuur is best goed on OH, maar de transitie naar 2 gaat wel erg brak. Na een jaar zit de deurbel nog steeds niet in de rfxcom 2 binding bijvoorbeeld...

Er is ooit een bedrijf geweest dat een prachtige charts uitbreiding had voor OH (opensource zelfs), maar dat is destijds door Koning Keizer Kai geweigerd als uitbreiding op OH. En nu nog is het karig wat je kunt.

Als ik de bindings vergelijk (sourcecode) dan is het wel heel erg duidelijk hoe omslachtig de OH bindings zijn (heel veel Java meuk), en hoe krachtig de python/yaml combi is. Stukken korter en leesbaarder.

Maar ja. Java en weinig code is een beetje teveel gevraagd. Wat dat betreft heb ik nu een aantal dingen zoals RFXCom in NodeRed zitten. Daar wordt wel alles ondersteund. Daarna door naar MQTT en hoppa OH in.

Verder heb ik al maanden een NUCje voor de transitie van OH1 naar OH2, maar ben dus ook al maanden bezig met OH2. Maar ik kom er maar niet uit. Probleem na probleem na probleem. Als het niet crashed (icm HomeKit), dan doet bepaalde functionaliteit het het weer eens niet. OH2 is voor mij een beetje een waterhoofd aan het worden. Topzwaar, complex, traag en resource vretend (OH vraagt bijna 1GB RAM).

Door dit soort ervaringen ga ik denk ik HA op de NUC draaien. Als ik dan toch overnieuw moet beginnen, dan meteen maar zo. Domotica moet namelijk werken, en niet ik

[GENETX]

Mars Warrior schreef op vrijdag 22 december 2017 @ 14:04:
Maar jij gaat dus in ieder geval de overstap wagen. Ben benieuwd naar je ervaringen.
Wordt het een big boom of ga je (als dat kan) parallel draaien en stapsgewijs over?

Het is een big boom geworden uiteindelijk. Wel had ik al rustig de UI klaargemaakt met wat componenten. Maarja, doel van home automation is uiteraard het automation deel. En dat heb ik grotendeels in een weekendje gefixt met ~500 regels python code in AppDaemon.

Initieel natuurlijk wat bugs, PEBCAK, maar het ging verbazingwekkend makkelijk toen ik het wat door kreeg. In een weekendje had ik alle functioanliteit, behalve de thermostaat (moet eerst weer wat data verzamelen) werkend in HA die ik ook in OpenHAB had verzmameld door de jaren heen.

Mijn ervaringen verder zijn erg goed met Home Assistant:

Pro's:
- Betere support voor apparatuur. Zaken als de RFXCOM en Google Home zijn zoveel beter, maar ook bijvoorbeeld de mijn TV die nu wel netjes rapoorteerd met feedback.
- Rules met AppDaemon in python zijn echt een verademing
- Mooiere interface imho

Con's:
- Opzet van OpenHAB vindt ik nog altijd wel beter in de basis
- Configuratie van HA is soms wel erg bloated en kent vervelende restricties, OpenHAB is wat schoner en beter te configureren in de basis, behalve het classic vs paper UI deel dan...
- Vaker kleine updates met breaking changes, dus zal er iets vaker mee bezig moeten. Echter, ik update niet automatisch om ellende te voorkomen.

Hoe dan ook, ik ben zeer tevreden en ik denk dat een aantal zaken in HA gewenning zullen zijn voor mij. Maar de basis: ondersteuning voor apparatuur en gemak van automatiseren zijn in HA echt wel veel beter.

[Klein_Kipje]

Wie zou me eens willen helpen (via dm) om MQTT - esp easy met een dht22 aan te praat te krijgen?

Ik lees overal dat eht heel makkelijk is maar ik krijg het niet voor elkaar maar om heel het topic nu te vervuilen met mijn simpele gevraag lijkt me wat overbodig. Ik kan (als het werkt) wel een beknopte handleiding tikken zodat de kennis niet verloren gaat.

[HyperBart]

Grmbl grrmmbl, godver...

Rules, de syntax daarvan en echt sommige rare onhebbelijke dingen blijven toch nog wel een pak frustratie opleveren hier.

In casu wil ik hier op basis van weer-informatie wat dingen doen, specifiek dat als de beschrijving van het weer wordt geupdated (cloudy, sunny, rainy, snowing) dat er dan wat wordt afgetrapt, omwille van de hier beschreven en verdere uitleg.

code:

Pseudocode

Als weerconditie een waarde gesend krijgt

dan

Doe check of weerconditie gelijk is aan zonnig,partieel zonnig
als waar dan stuur 1 naar KNX adres 1/0/0

doe check of weersconditie gelijk is aan winderig
als waar dan stuur 1 naar KNX adres 1/0/1

doe check of weersconditie gelijk is aan vriezen
als waar dan stuur 1 naar knx adres 1/0/2

Maar wat een ellende, ik slaag er zelfs nog niet om die regel af te laten trappen.

Ik heb volgende items gedefined (allemaal nog redelijk WIP):

code:

//Number   number_Weather_Temperatuur   "Temperature [%.2f °C]"   {weather="locationId=thuis, type=temperature, property=current",knx="9.001:8/2/203", autoupdate="false"}
Number   number_Weather_Luchtvochtigheid      "Humidity [%d %%]"        {weather="locationId=thuis, type=atmosphere, property=humidity",knx="9.007:8/2/204", autoupdate="false"}

DateTime datetime_Weather_LastUpdate       "Last update [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"        {weather="locationId=thuis, type=condition, property=lastUpdate"}


Number   number_Weather_Windsnelheid   "Windspeed [%.2f km/h]"   {weather="locationId=thuis, type=wind, property=speed"}
Number   number_Weather_Windrichting   "Wind direction [%s]"   {weather="locationId=thuis, type=wind, property=direction"}


Number   number_Weather_Regen   "Rain [%.2f mm/h]"   {weather="locationId=thuis, type=precipitation, property=rain"}
Number   number_Weather_NeerslagProbability   "Precip probability [%d %%]"   {weather="locationId=thuis, type=precipitation, property=probability"}


// clouds
Number   number_Weather_Bewolking   "Clouds [%.0f %%]"   {weather="locationId=thuis, type=clouds, property=percent"}


String   text_Weather_HuidigeStatus        "Condition [%s]"      {weather="locationId=thuis, type=condition, property=text"}

En dacht met volgende rule toch al wat moeten zien voorbij vliegen:

code:

import org.openhab.core.library.types.*

rule "Check if it's sunny and set values on KNX accordingly
when
    Item datetime_Weather_LastUpdate changed
then
    logInfo("RULE", "text_Weather_HuidigeStatus - Weather condition has changed")
end

Ik heb ook al changed vervangen door "recieved update" maar dat zet ook geen zoden aan de dijk. Omdat ik dacht dat er op basis van strings niet geëvalueerd kan worden ben ik al gaan prutsen met de datetime_Weather_LastUpdate in de hoop dat ik die WEL zou zien veranderen maar ho maar daar krijg ik ook geen trigger op.

Echt dat hele rules systeem blijf ik echt GIGANTISCH onhandig en moeilijk vinden. Wat doet ik fout?

[Dennis]

HyperBart schreef op woensdag 21 februari 2018 @ 16:53:
Ik heb ook al changed vervangen door "recieved update" maar dat zet ook geen zoden aan de dijk.

Ik hoop dat je received update hebt gebruikt?

[HyperBart]

Dennis schreef op donderdag 22 februari 2018 @ 15:50:
[...]

Ik hoop dat je received update hebt gebruikt?

Ja, ik weet hoe received wordt geschreven , das een typo'tje

[Dennis]

@HyperBart Ik heb die fout zelf een keer gemaakt, dus had je er niet om veroordeeld hoor.

Dat grapje met evaluatie op basis van strings heb ik volgens mij gewoon werkend gehad in OpenHAB2, dat zal ik vanavond of anders morgen eens voor je controleren.

Verder ben je ook nog een " vergeten in de naam van je rule (of is dat ook alleen hier op het forum?). Check anders eens in je logfile of die property überhaupt wijzigt.

rule "Check if it's sunny and set values on KNX accordingly"

[HyperBart]

Dennis schreef op donderdag 22 februari 2018 @ 16:22:
@HyperBart Ik heb die fout zelf een keer gemaakt, dus had je er niet om veroordeeld hoor.

None taken

Verder ben je ook nog een " vergeten in de naam van je rule (of is dat ook alleen hier op het forum?). Check anders eens in je logfile of die property überhaupt wijzigt.

Ongelooflijk, echt ongelooflijk.

[Dennis]

Het probleem met dit soort dingen is dat je er blind voor wordt... zo vaak ook zelf meegemaakt en achteraf denk je: hoe heb ik dat niet kunnen zien?!

Maar fijn dat het opgelost is. Ik begrijp je frustratie wel, je zou willen dat OpenHAB wat meer foutmeldingen laat zien. Overigens dacht ik ook dat zodra je een rule file wijzigt, je in de logfile kunt zien of hij succesvol wordt geladen of niet.

Ik moet mijn eigen OpenHAB weer eens maken. Nu de KNX steeds beter begint te werken en de Satel Integra ook goed gekoppeld is, is het wel leuk om te integreren met andere dingen, zoals HEOS. .

[CyBeRSPiN]

Ik gebruik sinds kort de VSCode plug-in om files te editen. Syntax wordt meteen gecheckt, werkt erg fijn!
Grote kans dat dit foutje was opgemerkt dan.

https://community.openhab...e-openhab-extension/30205

[dabachata]

Nieuw Topic, waarvan ik denk dat veel OpenHAB gebruikers het ook interessant vinden:
dabachata in "Centrale Verwarming Zonering / Zoneverwarming"

Misschien een heel cool idee voor goedkope zonerings-oplossing voor centrale verwarming/stadsverwarming, en ook compleet onafhankelijk van merk thermostaat (en ketel).

Thermo Elektrische Actuatoren (gangbaar bij vloerverwarming) aansluiten op je radiatoren, en deze actuatoren aansturen via Sonoff. Goedkoop, betrouwbaar en platform-onafhankelijk.
De Sonoff kan dan weer aangestuurd worden via domotica en naar wens gekoppeld worden aan een combinatie van temperatuursensoren, bewegingssensoren en raam-/deursensoren, tijdschemas, geolocatie smartphone (plus eventueel weergegevens als buitentemperatuur, invallend zonlicht, windkracht en -richting)

Zo'n €25 per radiator ipv de €70+ opties van bijvoorbeeld Tado en Honeywell. En die dure opties zijn dan ook nog eens platform-afhankelijk..

Van stand volledig dicht naar volledig open duurt wel zo'n drie minuten.

Om sterke temperatuurschommelingen in de te verwarmen ruimte tegen te gaan als de aanvoertemperatuur hoog ligt, kan je extra het volgende overwegen (uitgaande van die 3 minuten omschakeling):
Stand 0: Sonoff Altijd uit (Sonoff uit, Valve vol dicht)
Stand 1: Sonoff afwisselend 45s aan en 135s uit. (Valve klein beetje open?)
Stand 2: Sonoff afwisselend 90s aan en 90s uit. (Valve half open?)
Stand 3: Sonoff afwisselend 135s aan en 45s uit. (Valve ver open?)
Stand 4: Sonoff Altijd aan (Sonoff continue aan, Valve vol open)
(Geen idee wat deze extra regulerings-optie doet met de levensduur van je Sonoff en Actuator gezien de vele omschakelingen ...)

Wel handig als je dan ook een slimme thermostaat hebt waarmee je ook via domotica de ketel aan kan sturen als je CV hebt. Voor stadsverwarming speelt dit natuurlijk niet.

Omdat dit een domotica/platform onafhankelijke oplossing is, graag reageren via dit topic:
dabachata in "Centrale Verwarming Zonering / Zoneverwarming"

Idee komt oorspronkelijk van hier:
https://community.openhab.org/t/any-trv-suggestions/36723/30

[teaser]

Pfff ik moet toch ook even mijn ei kwijt... @HyperBart je bent niet de enige met frustraties.

Inderdaad, die rule engine is soms zo frustrerend. Uren sukkelen om de simpelste dingen werkend te krijgen, en het ligt altijd aan de stomste dingen. Uiteindelijk steek ik dan 20 debug regels in mijn rule om te zien waar hij komt en waar niet... Het is veel en veel trial and error, en dat vind ik echt geen professionele manier om home automation aan te pakken. Als software engineer in het dagelijkse leven ben ik heel wat anders gewend. En voor mijn huisgenoten is het ook niet ideaal als er weeral iets niet werkt omdat ik mijn rules maar halfslachtig heb kunnen testen.

Daarnaast moet je ook nog eens sysadmin zijn. Je draait basically een productieserver met een hoop services op (OpenHab, Grafana, InfluxDB, wie weet wat nog allemaal). Dat moet allemaal gebackupped worden, die data moet geconsolideerd/gepurged worden zodat je database niet uit zijn voegen barst, je moet security opzetten... Nog eens een halftime job erbij. En mijn ervaring met Linux is al niet super, ik schud niet in 1-2-3 een backup script uit men mouw. Ik sukkel al om de backup share op mijn NAS gemount te houden.

Eigenlijk wil ik gewoon zoveel mogelijk logica stabiel kunnen draaien zonder er naar om te moeten kijken. Een RPI blijft geen jaren draaien zonder af en toe eens wat housekeeping te doen. Als over 5 jaar iets breekt en ik heb niet meteen zin om het op te lossen wil ik niet in een 'dom' huis zitten voor dagen of weken.
Hoe zien jullie dat?

[ Voor 11% gewijzigd door teaser op 11-03-2018 17:03 ]

[CyBeRSPiN]

@teaser met de open source systemen van nu blijft het knutselen en houtje touwtje.
Mochten we ooit verhuizen dan gaat alles er uit, het is alleen overdraagbaar aan een andere nerd/tweaker

Moet wel zeggen dat openHAB hier echt rock-solid draait, al bijna 4 jaar. Maar mocht die pc ooit stuk gaan dan is dat zonder mijn hulp niet meer werkend te krijgen.

[teaser]

Dat het knutselgehalte er zijn wist ik voor ik eraan begon. Maar ik had de impact fout ingeschat.

Mijn insteek was: solide basissysteem (KNX in mijn geval) dat altijd werkt. Alle drukknoppen werken, verlichting schakelt op aanwezigheidssensoren, maar niets meer. Daarboven de 'leuke' logica en de visualisatie. Bv 's nachts gaan de lichten gedimd aan ipv op volle sterkte.

Maar nu blijkt dat ik die 'leuke' laag daarboven al snel zou missen. En dan heb ik nog niet eens erg veel logica erin steken, het meeste is nog 'todo'. Een smart home went rapper dan je denkt

Top dat jouw systeem al zolang stabiel draait @CyBeRSPiN. Maar een pc is ook al wel een graadje stabieler dan een RPI. Is het Linux of Windows trouwens? Mijn RPI draait nu wel al van SSD trouwens na de crash van eind vorig jaar.

[HyperBart]

teaser schreef op zondag 11 maart 2018 @ 19:27:
Dat het knutselgehalte er zijn wist ik voor ik eraan begon. Maar ik had de impact fout ingeschat.

Mijn insteek was: solide basissysteem (KNX in mijn geval) dat altijd werkt. Alle drukknoppen werken, verlichting schakelt op aanwezigheidssensoren, maar niets meer. Daarboven de 'leuke' logica en de visualisatie. Bv 's nachts gaan de lichten gedimd aan ipv op volle sterkte.

Maar nu blijkt dat ik die 'leuke' laag daarboven al snel zou missen. En dan heb ik nog niet eens erg veel logica erin steken, het meeste is nog 'todo'. Een smart home went rapper dan je denkt

Top dat jouw systeem al zolang stabiel draait @CyBeRSPiN. Maar een pc is ook al wel een graadje stabieler dan een RPI. Is het Linux of Windows trouwens? Mijn RPI draait nu wel al van SSD trouwens na de crash van eind vorig jaar.

Ik moet ook wel zeggen dat het hier echt superstrak stabiel draait. Geen blipje wordt gemist. Draait hier als VM op ESXi, influxdb en grafana op een aparte VM en OpenHAB ook.

Maar ja voor de rest idd tot in zelfs domme if-jes toch maar een debug regel gooien omdat je anders niks weet of toch maar zit te denken ‘zou het...’.

Ben benieuwd naar de LM die ik binnenkort voort DMX ga inschakelen.

[teaser]

HyperBart schreef op zondag 11 maart 2018 @ 22:16:
Ben benieuwd naar de LM die ik binnenkort voort DMX ga inschakelen.

Ha, jij hebt LM besteld? Ben ik ook wel benieuwd naar. Na al die ophemeling door @tss68nl zie ik dat bijna als een mythisch ding

[tss68nl]

teaser schreef op maandag 12 maart 2018 @ 07:41:
[...]

Ha, jij hebt LM besteld? Ben ik ook wel benieuwd naar. Na al die ophemeling door @tss68nl zie ik dat bijna als een mythisch ding

Hey teaser,

Volgens mij heb je wel een aantal posts van mij gemist over de LM

Een LM is eigenlijk gewoon een PLC met Lua erop geinstalleerd. Er zijn wel wat leuke schermen gerealiseerd om te kunnen programmeren, maar....het is geen toverdoos. Waar ik tegen aan loop:

• Lua is single threaded, al start de LM wél meerdere losse threads. Dat heeft als nadeel dat ieder event in zijn eigen thread draait, en dus geen variabelen/memory deelt.
• Ze gebruiken een Redis store voor het persistent opslaan van gegevens. Dit is redelijk snel (write/read) met ongeveer 1/100ste van een seconde, maar veel te langzaam om even 30 keer achter elkaar een variabele te updaten in high-speed oplossingen zoals bijvoorbeeld DMX. Je hebt dus een strategie nodig voor het opslaan en uitlezen van variabelen.
• Doordat Lua allemaal single thread is.... zijn ook je persistent scripts eigenlijk gewoon scripts die iedere seconde worden gedraaid. Vergt een aparte aanpak. Schril contrast met bijvoorbeeld Node.js waar alles juist event gebaseerd is.
• Visualisatie? Ja, ze hebben 3 verschillende mogelijkheden ingebouwd, maar allemaal missen ze wel iets.
  Voor iemand die het gewoon goed gefixt wil hebben, wordt ik een beetje gestoord van de opties en besteed ik teveel tijd om alle 3 de manieren helemaal uit te pluizen.
• Debuggen? Tjah, er zijn geen frameworks etc zoals in visual studio voor .NET. Debuggen bestaat bij mij uit een zelf geschreven logging routine die logt naar de LM log / errorlog en warnings schermen. Op basis van de setting (runtime, verbose, etc) bepaal je wat er allemaal doorgegeven wordt.

Wat ik dan wél weer waardeer in een LM:

• Ik krijg wel alles redelijk makkelijk voor elkaar.
• Bijvoorbeeld een Netatmo integratie geschreven (op basis van een voorbeeld, maar dat kon veel beter) in een dag.
• Ik heb een Denon versterker via Telnet aangesloten, en een Sony TV via een http interface en wat telnet. Beide paar uurtjes en het werkt vanaf scratch.
• Heb een eigen DMX controller geschreven die voldoet aan mijn standaard. Stuur 80 kanalen aan, 40x per seconde, en kan echt perfect vloeiende overgangen programmeren.
• Haal weersvoorspellingen van Wunderground.
• Er is ook een mogelijkheid data te loggen en grafieken te maken....maar... ik heb een apart systeem op basis van MSSQL draaien waarmee ik dat soort dingen oplos.
• Een hoop logische modules (AND/OR & veel complexer) schrijf je in notime en is een mooie aanvulling op je systeem.
• Je kan heel makkelijk met programmacode objecten aanmaken, configureren, voorzien van tags etc. Ik heb meestal een json configfile voor bijvoorbeeld al m'n DMX/KNX objecten.... en een routine zorgt voor de correcte aanmaak van alle objecten, tags en event hooks aan de code die de functionaliteit geeft.
• Tags op groepadressen (heel KNX specifiek) kan je weer gebruiken om via events code aan te hangen.
  Zeer krachtig concept.
• ...
• Er is nog zeer veel mogelijk met plugins en eigen visualisatie engines etc. Maar daar ben ik gewoon nog niet voldoende in gedoken. Ik moet eens gaan sparren met een aantal mensen van OpenRB om te kijken of ik mijn eigen visualisatieconcept in LM als module/plugin kan bouwen/aanbieden.

Dus het is een beetje tweeledig... je kan ongeveer alles, maar het programmeren blijft....programmeren en voelt een beetje spartaans.

Ik heb eigenlijk nooit het idee dat hij niet doet wat ik wil, anders dan dat ik Lua een vreselijke taal vind met rare mechanieken. Doe mij maar C# of Java. Ik kom er ook meestal wel uit, maar dat is wel op basis van logging. Dat ding gaat niets voor je oplossen iig.

Wil je echt een plug & play logica + visualisatie, dan kijk je beter naar een Gira X1. Het nadeel is dat je beperkt bent in wat Gira vrijgeeft (dus integratie van http/telnet/netatmo apis etc kan je op je buik schrijven), maar het voordeel is dat je met een aantal simpele visuele bouwblokken toch wat leuks kan maken.

Verder blijven alle visualisaties behelpen qua bruikbaarheid, omdat je eerst een app moet openen op je telefoon. Homekit (van Apple) is anders omdat dat geintegreerd zit in het OS (lockscreen zelfs) en in Siri wat met één druk op de knop al je commandos aanneemt.

Het grootste nadeel van Homekit integratie is dat het een Linux installatie van eibd en 85 halffabrikaten in 16 versies nodig heeft waar eibd op zijn beurt weer op gebaseerd is, onderhouden door 17 jarige mannetjes die inmiddels een beter doel in hun leven hebben gevonden. Ik heb het ooit werkend gehad...maar de nieuwe omgeving installeren heeft me al 4 volle dagen linux-stress bezorgd en een werkend systeem is nog steeds niet in zicht Wat een achterlijk gedrocht hebben we toch gecreëerd door allerlei afhankelijkheden van pakket naar subpakket te introduceren. Maak gewoon een build met alles er in dat het ook echt werkt! Alsof ik voor ieder sub-pakket een andere versie wil nemen als dat de originele bouwer op z'n computer had staan Meestal werkt het dan toch niet

Tot zover het zijspoor Linux. En ja, ik snap dat het allemaal aan mij ligt en de rest van de wereld er geen problemen mee heeft, maar Linux is niets voor mij. Luxepoppetje

LM = leuk speelgoed, maar geen toverdoos

[teaser]

tss68nl schreef op maandag 12 maart 2018 @ 10:45:
[...]
Volgens mij heb je wel een aantal posts van mij gemist over de LM

Misschien. Als ze in het KNX topic stonden heb ik ze op zijn minst wel gelezen

Click&drag logica ben ik zeker niet naar op zoek. Het moet flexibel genoeg blijven. Dat is ook de kracht van OpenHAB (om wat on topic te blijven): alles is mogelijk, en het meeste wat je zoekt bestaat ook al. En van wat proggen ben ik uiteraard niet vies. Het is alleen de manier waarop. Ik probeer nu een beetje uit te vissen of een LM beter aan mijn verwachtingen voldoet, zonder eerst een grote investering te doen. Maar ik heb al gezien dat openrb een demo heeft op hun website, dus die moet ik ook nog eens proberen. Maar in ieder geval geef je al een aantal hoopgevende punten aan.

Zou er niet beter een LogicMachine topic gestart worden?

[CyBeRSPiN]

@teaser gebruik je VScode met de OpenHAB extensie?
Dat werkt verrassend goed, omdat de rules syntax real-time gecheckt wordt met de OpenHAB server.

Heb daarmee zelfs nog wat foutjes gefixt in mn (opzich werkende) bestaande rules.

[teaser]

Ja, maar ook dat is niet helemaal foutloos hoor. Nadat ik dit weekend een upgrade had gedaan naar OH 2.2.0.1 kreeg ik opeens een fout op de eerste regel van een hoop scripts. Bugje blijkbaar

[HyperBart]

Ja, echt makkelijk wordt het er niet op, dan denk je even alles gevonden te hebben en met HTTP binding aan de slag te kunnen; WRONG!

Iemand hier nog wat zinnigs op te melden? https://community.openhab...binding-data-binary/41722
@GENETX misschien?

[CyBeRSPiN]

@HyperBart zie community.

Die configuratie met exec.things en dan zo Item naar channel mappen ken ik trouwens niet, zou best kunnen dat het daar fout gaat.
Lijkt erop dat je :output (de Channel van je Exec "Thing") bent vergeten.

[ Voor 89% gewijzigd door CyBeRSPiN op 15-03-2018 15:37 ]

[HyperBart]

Ja blijkbaar moet dat met die binding zo in OH2, god ik word echt wild dat dit soort dingen echt niet eenvoudiger te doen is, ik snap ECHT niet dat dit allemaal zo moeilijk moet zijn en dat je ook nergens wat meer "live" kan debuggen.

[GENETX]

@HyperBart ik ben blij dat ik tegenwoordig Home Assistant draai en middels AppDaemon gewoon python kan kloppen

[HyperBart]

Ja ik zag zo ergens iets voorbij komen ja, zit jij niet in het foute topic ?

Join die thread maar even zodat die JSON hier eindelijk werkt!

[HyperBart]

@GENETX en @CyBeRSPiN

Oef, er toch uit geraakt uiteindelijk, bleek toch een escaping/single quote issue te zijn.

Weten jullie trouwens of je met één item wat ik populeer (in dit geval die JSON) ik op basis van dat item meerdere "subitems" kan maken?

De reden waarom ik het vraag is dat ik nu per waarde die ik wil extracten uit de JSON wel telkens een call kan doen via CURL en dan JSONPATH kan loslaten op die respons, maar dat wil dan zeggen dat ik een amplify van X heb waarbij X gelijk is aan het aantal items wat ik wil displayen, das niet bepaald efficiënt.

Of moet ik dan toch weer met rules aan de slag?

[CyBeRSPiN]

@HyperBart gewoon met rules aan de slag. Dat wordt ook een achtbaanrit, maar als het eenmaal werkt dan werkt het

[HyperBart]

Tenenkrommend, niks minder niks meer.

VSCode geïnstalleerd, dan denk ik "nou ja prima, mijn folder openen waar al mijn items en rules folders en alle andere zut in staan".

Probeer je wat te Intellisense'en, gooit die een of andere vage error ("Error while connecting to openHAB REST API." dat de Host nog geset moet worden, nou ja prima, geef je daar een IP in samen met het poort nummer.

Moet je blijkbaar via een of andere CTRL SHIFT P combinatie het window eens reloaden en tadaa alles werkt

This extension is available on the Visual Studio Marketplace -> https://marketplace.visua...emName=openhab.openhab605
You can also install it manually:

Download openhab-0.1.0.vsix from this release page582 on your hard drive
Open command line in the same folder you downloaded the extension
Type the following command:
code --install-extension openhab-0.1.0.vsix
Open Visual Studio Code
Open openhab configuration (openHAB-conf) folder
Enjoy! :wink:

[teaser]

Voorlopig ploeteren we nog maar wat verder in het moeras van de OpenHAB rules

Ik ben momenteel het script verder aan het uitwerken voor het zetten van de globale 'presence' vlag, die moet aangeven of er iemand in huis is of niet. Deze is onstaan in de kerstperiode voor het schakelen van de kerstverlichting zo gauw er iemand thuis is, en uiteraard uitschakelen als er niemand is (ik hield ook rekening met de periode in de dag, zodat de verlichting niet de hele nacht bleef branden etc, maar dit doet er hier even niet toe).
Dit is gebaseerd op de data van een aantal bewegingsmelders die ik in huis heb: inkomhal, traphal, badkamer, berging en toilet - maar (voorlopig) geen in de leefruimtes en slaapkamers. Dus ik moest het doen met een vrij lange timeout om te voorkomen dat de presence weer OFF ging als je bv een tijdje in de living zit. Dat de presence 's nachts OFF ging als iedereen in de slaapkamers ligt was geen probleem omdat de kerstverlichting 's nacht toch uit ging. Maar uiteraard is dat voor andere toepassingen niet goed genoeg, dus bedacht ik ondertussen hoe ik dat kon verbeteren.

Nu kwam ik gisteren opeens op een simpel maar geniaal idee. Hopelijk heeft iemand anders er ook iets aan. Het is namelijk zo dat je altijd via de inkomhal passeert om het huis te verlaten. Voor de slaapkamers (en ook voor de living bij ons) moet je altijd eerst minstens een verdieping hoger zijn, zodat er altijd een sensor in de traphal wordt getriggered voordat je de slaapkamer binnen gaat. Dus in plaats van na de laatste bewegingsdetectie + timeout de presence af te zetten, kijk ik nu eerst welke sensor het laatste getriggered werd. Is dit niet de sensor van de inkomhal, dan gebeurt er niets.

Hieronder enkele van de items, en als belangrijkste de gPresence groep die een OR is van alle items in de groep:

code:

Switch Presence_TOI                 "Aanwezigheid toilet"           (gLogic, gPresence)     { knx="<2/0/0" }
...
Switch Presence_H0                  "Aanwezigheid H0"               (gLogic, gPresence)     { knx="<13/0/0" }
Switch Presence_H1                  "Aanwezigheid H1"               (gLogic, gPresence)     { knx="<13/0/1" }
Switch Presence_H2                  "Aanwezigheid H2"               (gLogic, gPresence)     { knx="<13/0/2" }

Group:Switch:OR(ON, OFF)    gPresence       "Aanwezigheidsdetectie" (All)

Belangrijk is dat deze items al na enkele seconden geen beweging te hebben gezien OFF gaan.

Hieronder het script. De globale var lastPresenceDetected kan hier waarschijnlijk nog weggewerkt worden door naar de update time van het laatst getriggerde item te kijken.

code:

val int minutesBeforeAbsence = 60

var DateTime lastPresenceDetected

rule "GlobalPresenceOn"
when
    Item gPresence changed to ON
then
    //logDebug("GlobalPresenceOn", "Presence detected")
    lastPresenceDetected = now
    
    if (Logic_PresenceMode.state != ON)
        Logic_PresenceMode.sendCommand(ON)
    if (Logic_AbsenceMode.state != OFF)
        Logic_AbsenceMode.sendCommand(OFF)
end

rule "GlobalPresenceOff"
when
    Item System_DelayedStart changed to ON or
    Time cron "0 */5 * * * ? *"
then
    if (System_DelayedStart.state == OFF) { return; }
    if (gPresence.state == OFF && lastPresenceDetected !== null)
    {
        var lastTriggeredItem = gPresence.members.sortBy[lastUpdate].last
        logDebug("GlobalPresenceOff", "Last presence updated: {}", lastTriggeredItem.name)
        if (lastTriggeredItem == Presence_H0)
        {
            val absence = if (now.minusMinutes(minutesBeforeAbsence) > lastPresenceDetected) ON else OFF
            val presence = if (absence == ON) OFF else ON
            logDebug("GlobalPresenceOff", "Presence: {}", presence)

            if (Logic_PresenceMode.state != presence)
                Logic_PresenceMode.sendCommand(presence)
            if (Logic_AbsenceMode.state != absence)
                Logic_AbsenceMode.sendCommand(absence)
        }
    }
end

Momenteel hangen er nog geen functies vast aan het globale presence item, eenmaal ik dit stabiel en betrouwbaar heb ga ik er wel functies als 'alles uit' aan vasthangen.

[Klein_Kipje]

Ik heb dit gedaan via of alle telefoons zijn aangemeld op AP (via unify server op een rasp zero).
bv
Buitenlicht om 11 uur savonds uit als alle telefoons 'thuis' zijn. anders elk kwartier kijken en dan uit gaan.

Kan ik volgend jaar ook gebruiken om de kerstboom aan te schakelen.

[HyperBart]

Mja, maar bv voor een iPhone geldt dat niet, die sluit zijn wifi connectie af als hij in scherm-uit-mode gaat.

[teaser]

Helemaal stabiel lijkt me dat toch niet. Ik zet 's nacht doorgaans ook mijn wifi af, dan moet je daar ook weer rekening mee gaan houden. Of als je dead spots in huis hebt, of je batterij gaat plat... Aanwezigheid van telefoons zou ik enkel ondersteunend gebruiken, en dan zou ik ook eerder voor geolocation kiezen. Dat lijkt me iets stabieler.

[HyperBart]

Mja, maar ja, hoe doe je het anders betrouwbaar? Op basis van een BLE tag die je in je lijf inplant? Op basis van beweging?

Ik zit me daar ook al een tijdje suf over te piekeren hoor.

[CyBeRSPiN]

Volgens mij is de beste manier om apps te gebruiken op je telefoons die op basis van een geofence een event uitsturen.
Zelf begonnen om HomeKit aan de praat te krijgen, maar krijg het niet goed werkend met 2 apple accounts.
Met iPhones zou je dan in theorie klaar zijn, want met homekit kun je schakelaars aan/uit zetten bij vertrek/aankomst van personen. En er is standaard support voor automation als "wanneer de laatste persoon vertrekt..." en "wanneer de eerste persoon thuiskomt..".

Heb ook eea gezien op basis van OwnTracks.org, dat zou ook voor Android moeten werken.

[HyperBart]

Ja, dat werkt hier dus wel prima, soms een beetje laat maar ik denk er sterk aan om een dummy schakelaar te maken en die te flippen in homekit als iemand thuis komt of de laatste vertrekt. Het moet niet altijd instant zijn als ik vertrek. Thuis komen is dan wel wat fijner als het snel is want bv. de buitenverlichting wordt daar op geschakeld.

@GENETX en @CyBeRSPiN , ik heb het trouwens werkend gekregen, de SMA omvormer in OpenHAB:

Volgende items kan je dus uitlezen met een iets of wat recente SMA omvormer (SB)

code:

Number number_SMA_DCVermogenA "DC Vermogen A [%.0f]"    <solarplant>
Number number_SMA_DCVermogenB "DC Vermogen B [%.0f]"    <solarplant>

Number number_SMA_DCSpanningA "DC Spanning A [%.0f]"    <solarplant>
Number number_SMA_DCSpanningB "DC Spanning B [%.0f]"    <solarplant>

Number number_SMA_DCStroomA "DC Stroom A [%.0f]"    <solarplant>
Number number_SMA_DCStroomB "DC Stroom B [%.0f]"    <solarplant>

Number number_SMA_ACVermogen "AC Vermogen [%.0f]"    <solarplant>
Number number_SMA_ACNetfrequentie "AC Netfrequentie [%.0f]"    <solarplant>

Number number_SMA_ACFasestroomFaseL1 "AC Fasestroom L1 [%.0f]"    <solarplant>
Number number_SMA_ACFasespanningFaseL1 "AC Fasespanning L1 [%.0f]"    <solarplant>

Number number_SMA_ACPVOpwekkingVermogenPVOpwekking "AC PV Opwekking Totaal [%.0f]"    <solarplant>



Number number_SMA_DayYield "Day Yield [%.0f]"    <solarplant>

Tof natuurlijk, nu zou je in theorie de SMA helemaal kunnen disconnecten met een firewall van het internet en de Sunny Portal en je data persistence'en in InfluxDB en Grafana... Ik denk niet dat ik 'm ga firewallen maar de data in Grafana krijgen is natuurlijk altijd

Wel nog één functioneel issue wat ik moet oplossen: sessiebeheer. Ik moet nu een ingelogde sessie op de SMA open laten staan in Chrome om het SID te kunnen blijven gebruiken en dat is na een herstart van de betreffende machine niet zo handig want dan moet ik manueel even sessies gaan herstarten en SID's gaan verwerken.

[teaser]

HyperBart schreef op maandag 19 maart 2018 @ 16:28:
Mja, maar ja, hoe doe je het anders betrouwbaar? Op basis van een BLE tag die je in je lijf inplant? Op basis van beweging?

Ik zit me daar ook al een tijdje suf over te piekeren hoor.

Ik heb onlangs een blog gelezen over een gast die zich daar ook suf heeft over gepiekerd. Best interessante principes wat die toepast.

[Dylantje2]

Bigs schreef op vrijdag 24 november 2017 @ 16:31:
Is er iemand die z'n 'domme' elektriciteitsmeter uitleest naar OpenHAB adhv een 1000 imp/kWh ledje? Ik heb al wat onderdelen als een ESP8266 en photodiodes liggen, maar ben er nog niet uit hoe ik het aan ga pakken. Het doel is om in OpenHAB het actuele energieverbruik in Watt te kunnen zien en daarvan geschiedenis bij te houden. kWh's zie ik op de meter wel

Kheb geen openhab, maar ben aan het meelezen..[ gebruik domoticz ]
Ik zag een binding van Xiaomi?
Als die werkt kun je heel simpel een deurcontact van xiaomi open maken, en daaraan 2 draadjes solderen.
Die naar je schakelaar....
En je behoudt je huidige schakelaars..
Kost wel euroootje of 8 :-)
En werkt perfect

[CyBeRSPiN]

@Dylantje2 beetje late reactie
Met een esp8266 heb je al WiFi, dus die met MQTT aan OpenHAB koppelen ligt meer voor de hand.

[Dylantje2]

CyBeRSPiN schreef op vrijdag 13 april 2018 @ 19:43:
@Dylantje2 beetje late reactie
Met een esp8266 heb je al WiFi, dus die met MQTT aan OpenHAB koppelen ligt meer voor de hand.

mmm lijkt erop dat ik helemaal mis zit...zat/.
Ging ergens over een schakelaar...

Maar goed..
Dan toch.............
Wat is beter Openhab of Domoticz

[teaser]

Dylantje2 schreef op vrijdag 13 april 2018 @ 21:05:
[...]
Wat is beter Openhab of Domoticz

Beide systemen hebben hun voor- en nadelen. Welke van de 2 beter is voor jouw is dus een persoonlijke vraag. Probeer beiden eens uit zou ik zeggen.

[Dylantje2]

teaser schreef op zondag 15 april 2018 @ 10:40:
[...]Beide systemen hebben hun voor- en nadelen.

Tsja bedankt voor de uitleg....
Maar juist als je een leercurve aanhoudt van een paar maanden, wat je in mijn ogen echt wel nodig hebt, voordat je ze beiden echt snapt...
Lijkt het me voor een leek zoals ik, niet echt te overzien..

Ik zou meer denken aan wat heeft Domoticz wel, wat Openhab niet heeft.dus de exhte missers.
Of misschien juist andersom, wat kan Openhab, wat Domoticz niet kan.
Protocollen verschillen, hardware gemis enz
enz enz

[GENETX]

En check dan ook Home Assistant. Domoticz is in mijn ogen echt inferieur aan OpenHAB en HA. Check eerst vooral elke hardware je kan aansturen, maw, kun je überhaupt de hardware aansturen die je wilt. Maar wij eten niet welke hardware je hebt, dus dat kun je enkel zelf.

Verder is even spelen meer dan genoeg om een eerste indruk te krijgen. Ook dat is met name eigen voorkeur.

In short:
OpenHAB lijkt het stabielste en behoorlijk professioneel. Kun je ook het meest naar eigen smaak zetten. Is echter relatief traag met ontwikkeling en steile curve.
Home Assistant: razendsnel in ontwikkeling en heeft volgens mij de breedte ondersteuning. Updates hebben daardoor wel breaking changes. Ook steille curve, met AppDaemon kun je wel erg goed geavanceerde automations maken.
Domoticz: Antiek, vol losse gare scripties, niet customizable. Blocky maakt programmeren wel iets makkelijker, maar voor OpenHAB is daar ook een plugin voor: HABmin. maw, persoonlijk heeft Domoticz enkel nadelen tov de rest.

Ben zelf een par maanden geleden van OH naar HA gestapt en dat bevalt. HA komt alles afwegend net wat beter uit de bus dan OpenHAB, maar dat is krap aan. Wel heeft HA meer momentum en vermoed datdeze verder gaat uitlopen.

[ Voor 115% gewijzigd door GENETX op 15-04-2018 12:42 ]

[Dylantje2]

GENETX schreef op zondag 15 april 2018 @ 12:30:
Domoticz: Antiek,

MM pas een paar jaar oud..
Blijft wel actueel met veel updates en counting qua hardware..
Of hoe bedoel je antiek?


De rest bedankt voor je toelichting..
Zoals ik denk, het zal dus meer een kwestie van voorkeur en ervaring zijn?


Maar dan toch..
Kan ik bijv. al mijn devices omzetten naar een ader systeem?
Stel dat ik van domoticz naar Ha wil gaan..
Of start ik helemaal op 0??

[GENETX]

Waarschujnlijk kun je alle systemen gewoon meenemen. HA heeft ontiegelijk veel support, maar dat zal je dus even moeten uitzoeken. Probleem van Domoticz is niet zozeer oud zijn, OpenHAB is nog ouder, maar het oogt zo antiek in mijn beleving. Verder heb ik can domoticz gewoon altijd de indruk (maar kan het.mis hebben) dat de software in de basis gewoon niet lekker is, het voelt altijd een beetje houtje-touwtje, ductape en tiewraps. HA en OH hebben imho meer visie en een degelijke opzet om makkelijk nieuwe uitbreidingen toe te kunnen voegen.

Let wel, ik heb Domoticz ook getest ooit, mede omdat iedereen zo lovend was. Maar toen ik het met eigen ogen aanschouwde was mijn eerste indruk: "wat is dit voor loshangend raapseltje losse scripts, en waarom is de rest hier in hemelsnaam zo enthousiast over??"

[ Voor 10% gewijzigd door GENETX op 15-04-2018 17:35 ]

[teaser]

Dylantje2 schreef op zondag 15 april 2018 @ 11:50:
Tsja bedankt voor de uitleg....
Maar juist als je een leercurve aanhoudt van een paar maanden, wat je in mijn ogen echt wel nodig hebt, voordat je ze beiden echt snapt...
Lijkt het me voor een leek zoals ik, niet echt te overzien..

Ik zou meer denken aan wat heeft Domoticz wel, wat Openhab niet heeft.dus de exhte missers.
Of misschien juist andersom, wat kan Openhab, wat Domoticz niet kan.
Protocollen verschillen, hardware gemis enz
enz enz

Je hoeft je er echt geen maanden in te verdiepen om een beetje een feeling te krijgen van welk systeem jou het best ligt.
De harde specs zoals welke systemen worden ondersteund kun je makkelijk terugvinden op de websites van de systemen. Ook hier weer is het persoonlijk. Ook al ondersteunt de ene 50 verschillende protocollen/toestellen en de andere maar 20, als de 3 die jou interesseren tussen die 20 zitten en niet tussen die 50 is de keuzen snel gemaakt. Voor mij persoonlijk bv: Domoticz ondersteunt geen KNX, dus die viel sowieso al af omdat ik overal KNX in huis heb.

[Verwijderd]

Hi,

I have a question related to pilight and KlikAanKlikUit (KUKA):
- I have (starting in openHAB1.8) succesfully setup one of my lightswitches (this before I move to openHAB 2.0 and have to also convert my 1.8 settings)
- I see, in the CMD tool logging, that the KUKA light switch has received the ON/OFF command
- Nothing happens though with the light.
- I have setup pi-light conf file as explained in this forum (using the local IP adress, port 5000, and 1000 ms delay.
- If I check my ICS-1000 KAKU station display I see nothing when I switch the openHAB light switch. I do see a message on the display if I use the normal KUKA switch or my phone-app

What I am doing wrong? Does openHAB work with the ICS-1000 of KUKA?

Any help is welcome...

[GENETX]

Well, OpenHAB directly communicated with pilight, pilight then communicates with the switches. The ICS-1000 should be bypassed as this setup is actually replacing it.

As it is pilight who does the actual control of the switches, you first need to make sure that the pilight configuration is correct. Note that you need to enter the switches into the pilight configuration as well! See https://manual.pilight.org/index.html# . By default, pilight would have port 5001 for the web interface.

So, first check whether pilight on its own works correctly, only then get back to OpenHAB. If you need help with pilight, you are best off using the forums of pilight.org .


Note, this is a dutch website and generally English is not allowed/accepted here, but that's up to the moderators. You can always have a look at the official OpenHAB forums.

[ Voor 31% gewijzigd door GENETX op 13-05-2018 11:07 ]

[SiErRa]

Wel rustig hier de laatste tijd, iedereen helemaal tevreden met OpenHAB of over overgestapt naar iets anders?

Maar in ieder geval, OpenHAB 2.3 is uit: https://www.openhab.org/b...-openhab-2-3-release.html

- Eindelijk goede ondersteuning, en automatisch omrekenen van eenheden. Wel mooi uitgewerkt vind ik.
- Google Assistant support
- KNX plugin is nu echt OpenHAB 2

Helaas is de 2.0 versie van de DSMR plugin net niet meegekomen, hangt nog op wat reviewcommentaar.
Maar de 1.0 versie werkt ook prima.

Zelf de laatste tijd weinig mee bezig geweest, maar alles draait stabiel.

[Loekie]

Hier tevreden, net verhuisd en nog niet toegekomen aan inbouwen van schakelaars etc, maar verschillende plugin-modules hebben al weer een nieuwe bestemming gevonden en heb (tijdelijk) een scene voor de vloerpomp(die overbodig draait in de zomer) aangemaakt om een duty-cycle van 15m/dag te doen.

Zit nog te denken over het zelf uitdokteren van zone-verwarming(vloerverwarming beneden, radiatoren boven) ivm studeerkamer/kinderkamers boven.

[CyBeRSPiN]

Hier draait het ook nog steeds superstabiel. Afgelopen tijd weinig nieuws toegevoegd, niks hoeven fixen.
Zit met schuin oog naar Home Assistant te kijken, maar is me nog net te experimenteel. Heb de indruk dat je bij elke (wekelijkse?) update weer moet huiveren of alles nog naar behoren werkt. Ook niet helemaal overtuigd van YAML als configuratie. Maar duidelijk is wel dat dat project veel meer tractie heeft in de open source wereld.

[TriLithium]

Kan iemand mij helpen met mijn startende OpenHAB ervaringen? De nodige items werken prima, IKEA Tradfri aan de praat, Marantz en elv Max! bindingen doen het ook, items doen ook dingen. Maar de JSON en MQTT data van de Youless en OTGW komen niet op het UI binnen

Eerst de Youless JSON:
Item regels van de nodige bronnen lopen copy pasten natuurlijk, maar deze lijken mij prima als ik de uitvoer op de JSON parser pagina kijk. Krijg ook geen meldingen in openhab.log van fouten en ook JSONPath Transformation lijkt geen fouten te vinden.

Items file:

code:

Number VT_Http_YouLess_Total         "Stroomverbruik totaal [%,.3f kWh]"         <energy>    { http="<[http://192.168.1.190/a?f=j:10000:JSONPATH($.cnt)]" }
Number VT_Http_YouLess_Current       "Stroomverbruik actueel [%,.0f Watt]"       <energy>    { http="<[http://192.168.1.190/a?f=j:10000:JSONPATH($.pwr)]" }
Number VT_Http_YouLess_Signal        "Stroomverbruik signaal [%.0f %%]"          <energy>    { http="<[http://192.168.1.190/a?f=j:10000:JSONPATH($.lvl)]" }

Output van de Youless:

code:

{"cnt":"33459,599","pwr":213,"lvl":83,"dev":"","det":"•","con":"*","sts":"","raw":0}

Ook de OTGW met MQTT houd zich erg stil op het BasicUI, MQTT lijkt te werken met een enkel test topic van ergens een tutorial, ook weet de OTGW zijn dat kwijt te kunnen en kan ik met mosquitto_sub de topics voorbij zien komen,

Items file:

code:

Number  OTGW_room_temperature           "Room Temperature [%.1f ºC]"         { mqtt="<[mosquitto:events/central_heating/otmonitor/roomtemperature:state:JSONPATH($.value):.*\"name\".*]" }
Number  OTGW_boiler_water_temperature   "Boiler Water Temperature [%.1f ºC]" { mqtt="<[mosquitto:events/central_heating/otmonitor/boilerwatertemperature:state:JSONPATH($.value):.*\"name\".*]" }
Number  OTGW_return_water_temperature   "Return Water Temperature [%.1f ºC]" { mqtt="<[mosquitto:events/central_heating/otmonitor/returnwatertemperature:state:JSONPATH($.value):.*\"name\".*]" }
Number  OTGW_setpoint                   "Ingestelde temp. [%.1f ºC]"         { mqtt="<[mosquitto:events/central_heating/otmonitor/setpoint:state:JSONPATH($.value):.*\"name\".*],>[mosquitto:actions/otmonitor/setpoint:command:*:default]" }
Number  OTGW_control_setpoint           "Control Setpoint [%.1f ºC]"         { mqtt="<[mosquitto:events/central_heating/otmonitor/controlsetpoint:state:JSONPATH($.value):.*\"name\".*]" }

Mosquitto_sub -t 'events/central_heating/#':

code:

events/central_heating/otmonitor/returnwatertemperature {"value": 57.00}
events/central_heating/otmonitor/boilerwatertemperature {"value": 62.00}
events/central_heating/otmonitor/returnwatertemperature {"value": 56.00}
events/central_heating/otmonitor/roomtemperature {"value": 24.12}
events/central_heating/otmonitor/roomtemperature {"value": 24.14}
events/central_heating/otmonitor/roomtemperature {"value": 24.12}
events/central_heating/otmonitor/boilerwatertemperature {"value": 61.00}
events/central_heating/otmonitor/roomtemperature {"value": 24.13}
events/central_heating/otmonitor/returnwatertemperature {"value": 55.00}

Sitemap:

code:

sitemap Demo {

    Frame label="Elektriciteit verbruik" {
        Text item=VT_Http_YouLess_Current icon="energy"
        Text item=VT_Http_YouLess_Signal icon="energy"
        Text item=VT_Http_YouLess_Total icon="energy"
    }
    Frame label="Heating" {
        Text    item=OTGW_room_temperature
        Text    item=OTGW_boiler_water_temperature
        Text    item=OTGW_return_water_temperature
        Text    item=OTGW_setpoint
        Text    item=OTGW_control_setpoint
    }
}

Wat mis ik nog? Zal wel iets simpels zijn maar ik ben na de nodige zoektochten een beetje lam geslagen over wat nog nodig mag zijn.

[GENETX]

CyBeRSPiN schreef op maandag 18 juni 2018 @ 10:04:
Hier draait het ook nog steeds superstabiel. Afgelopen tijd weinig nieuws toegevoegd, niks hoeven fixen.
Zit met schuin oog naar Home Assistant te kijken, maar is me nog net te experimenteel. Heb de indruk dat je bij elke (wekelijkse?) update weer moet huiveren of alles nog naar behoren werkt. Ook niet helemaal overtuigd van YAML als configuratie. Maar duidelijk is wel dat dat project veel meer tractie heeft in de open source wereld.

Dat los ik op door niet tweewekelijks up te daten . Net als een BIOS van je PC, dont fix it if it aint broken. Dat geldt misschien nog meer voor home automation. Maar hetzelfde deed ik ook met openHAB.

[SiErRa]

TriLithium schreef op woensdag 20 juni 2018 @ 22:06:
Kan iemand mij helpen met mijn startende OpenHAB ervaringen? De nodige items werken prima, IKEA Tradfri aan de praat, Marantz en elv Max! bindingen doen het ook, items doen ook dingen. Maar de JSON en MQTT data van de Youless en OTGW komen niet op het UI binnen

Wat mis ik nog? Zal wel iets simpels zijn maar ik ben na de nodige zoektochten een beetje lam geslagen over wat nog nodig mag zijn.

Gebeurd er wel iets in je events.log?
En als je op het zelfde topic op mosquitto zelf iets in schiet?

Ik heb het idee dat er ergens iets mis is in je mqtt binding configuratie.

[TriLithium]

Wat zou ik moeten zien in de event log? Kwa deze items blijft het leeg. Zou ik van elke change op een mqtt topic een event log moeten voorbij zien komen?

Edit:
Klein debug sessie gedaan, als ik deze tutorial volg en het einde van het testen doe dan krijg ik wel info op de UI en zie ook een "ItemStateChangedEvent" in de eventlog. Dus MQTT lijkt mij te werken.

Vind het heel vreemd dat ook mijn Youless items niet werken, welke tcp JSONpath acties zijn.

[ Voor 53% gewijzigd door TriLithium op 23-06-2018 16:22 ]