Poll

Nächste Bricks/Bricklets mit openHAB Unterstützung

Stepper
8 (20%)
IMU
0 (0%)
IMU 2.0
1 (2.5%)
Accelerometer (fertig)
0 (0%)
Analog In (fertig)
1 (2.5%)
Analog In 2.0 (fertig)
2 (5%)
Analog Out
0 (0%)
Analog Out 2.0
2 (5%)
GPS
4 (10%)
Industrial Analog Out
0 (0%)
Industrial Dual Analog In (fertig)
2 (5%)
Laser Range Finder (fertig)
0 (0%)
NFC/RFID
16 (40%)
Color (fertig)
4 (10%)

Total Members Voted: 21

Author Topic: openhab Integration  (Read 115098 times)

StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #465 on: April 17, 2019, 23:08:20 »
Hi Sihui,

ok verstanden, um es zu rekapitulieren, Du hast über paperui Configuration / Things / BrickletIO16 einen gpio als Input konfiguriert und dann die Verlinkung über die ITEM-TEXT-Datei durchgeführt. Habs gerade so getestet und ging.
Ich habe mich vorhin auf das Motion und den Multitouch zum testen beschränkt, den 16fach habe ich nicht mehr angefasst.

Um ehrlich zu sein, mich hat das Switch-Symbol irritiert. Ein Contact ist ein Item dass ich nicht über die Website bedienen kann, den Switch kann man aber bedienen. Was ich sagen will, auf einmal ist ein gpio Input unabhängig von seinem technischen Zustand über die Website bedienbar. Also kann man den Item-Zustand ändern (die logische Sicht) auch wenn die Technik dahinter eben nicht eine Änderung des Zustand erfahren hast. Ist das Sinnvoll ?
Spontan fällt mir ein Fensterkontakt ein. Das Fenster ist geschlossen, also hat das ITEM einen definierten Zustand (über den INPUT des GPIO), nun bediend jemand auf der Website das Switch-ITEM für den Fensterkontakt (dieser lässt sich auch vom Zustand ändern, hab es gerade getestet) und das Fenster wäre dann offen obwohl es geschlossen ist ? (müsste also eine Rule einführen die bei Zustandsänderung den realen Zustand prüft)

Es gibt aber noch immer den Effekt, dass ich über paperui/Control die Zustandsänderung des GPIO (Verbinde GPIO mit GND) und des Motiondedector (bewege Hand) sehe aber die Zustandsänderung über basicui/app eben nicht sehe, da behalten die ITEMS Ihren Zustand. An was kann das liegen ? (könnte das auch das Problem von Jerome sein ?)


(hab meinen alten Thread gelöscht um andere nicht mit meiner Fehlinterpretation zu verwirren)
« Last Edit: April 17, 2019, 23:31:49 by StefanOHAN »

sihui

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: openhab Integration
« Reply #466 on: April 18, 2019, 07:01:44 »
Um ehrlich zu sein, mich hat das Switch-Symbol irritiert.

In der Sitemap statt
Code: [Select]
Switch item=deinSwitchItemtype einfach
Code: [Select]
Text item=deinSwitchItemtype schreiben, dann ist es weg.
Programmiertechnisch in den Rules ist es ja egal ob man auf OPEN/CLOSED bei einem Contact Itemtype oder ON/OFF bei einem Switch Itemtype triggert.

Es gibt aber noch immer den Effekt, dass ich über paperui/Control

PaperUI ist eine reine Administrationsoberfläche und nicht für den täglichen Gebrauch gedacht, vor allen Dingen nicht das Control Tab. Das sieht man schon daran das ein Item mit einem Channel verlinkt sein muss um dort angezeigt zu werden. Items an sich ohne Verlinkung erscheinen dort erst gar nicht.

die Zustandsänderung über basicui/app eben nicht sehe, da behalten die ITEMS Ihren Zustand.

Das passiert manchmal und normalerweise kann man das beheben in dem man eine der folgenden Aktionen versucht:
1. openHAB neu starten
2. den Server neu starten
3. tmp und cache Ordner leeren
4. in den logs nach Fehlern suchen weil man irgendwo doch einen bisher Unentdeckten hat.

Manchmal reicht schon Punkt 1. zur Behebung.

StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #467 on: April 18, 2019, 07:55:26 »
Guten Morgen sihui

danke für die Tip's ich werde am Oster WE eine neue TestSession inclusive einbinden in Rules (hab ich momentan nur bei einigen Bricklets ausgeführt) starten.

Viele Grüsse
Stefan


StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #468 on: April 22, 2019, 21:27:30 »
Hallo sihui,  hallo Theo

Sihui, Du hattest recht, das Darstellungsproblem in der basicui war nach dem Neustart von Openhab2 behoben (ein Boot war nicht notwendig)

Aufgrund meiner Fehlinterpretation der letzten Tage, habe ich nochmal verschiedene Bricklets mit dem aktuellen Binding (2.5.0-12) getestet. Dieses mal nur über die Verlinkung der Channels in der ITEM-Text-Datei und das Einbinden in Rules. Als Trigger-Event in den Rules dient teilweise die Channels und teilweise die ITEM's

Die Vorgehensweise war immer die gleiche
1) Things über über die autodiscover Funktion suchen lassen
2) Things über "paperui > Configuration/Things/ konfiguriert" (soweit nötig)
3) Channels über die ITEM-TEXT-Datei mit einem passenden Item verlinkend

Ich weiß es ist wiedermal viel zu lesen, aber ich wollte Missverständnisse vermeiden.

MotionDedectorV2:
ITEM (Channel-Verlinkung über die ITEM-Text-Datei)
Switch-Item in der Item-Text-Datei mit dem (Switch) Channel verlinkt.
Bei Bewegung vor dem MotionDedector, änderte sich der ITEM-Status von OFF nach ON >> Funktion OK

Dimmer-Item in der Item-Text-Datei mit dem (Dimmer) Channel verlinkt.
Keine Funktion der LED bei betätigen des Dimmer ITEM (über basicui)
Es wird jedoch der veränderte %-Wert des ITEMS im Log und über „basicui“ angezeigt
Quote
>>2019-04-22 20:01:42.691 [nt.ItemStatePredictedEvent] - MotionDV2dr predicted to become 50<<

Rule
Version1: mit einem Item arbeiten, das über die ITEM-Text-Datei mit dem Channel verlinkt wurde >> Funktion OK

Version2: In einer Rule direkt mit dem Channel arbeiten (keine Funktion)
>>FRAGE: wie gehe ich in einer Rule mit dem Switch Channel des MotionDedectorV2 um, wenn ich den Zustand ON oder OFF auslesen will ??
Quote
when
       Channel "tinkerforge:motiondetectorV2:f4a5fb45:Hz1:motiondetected" triggered [<triggerEvent>]  ??
then
wie würde das Argument für das Trigger-Event lauten ?
ON/OFF und PRESSED/RELEASED haben nicht funktioniert (auch keinen Fehler im Log verursacht)

Die „Dimmer-Funktion“ der LED-ITEM's habe ich nicht mehr per Rule getestet, nachdem schon das Bedienen über die "basicui" nicht funktionierte

Multi-Touch
ITEM (Channel-Verlinkung über die ITEM-Text-Datei)
>>Switch-Item in der Item-Text-Datei mit einen den Channel(Switch) verlinken, hat funktioniert (verhält sich wie ein Switch, nicht wie ein Contact)

Rule: mit
Quote
>>when Channel "tinkerforge:multitouch:f4a5fb45:zvv:electrode0" triggered PRESSED then <<
wird eine Rule aufgerufen, funktioniert
Anmerkung zum Multi-Touch: Ich würde im Produktiv-System nur die Channel in den Rules verwenden, jedoch keine ITEM in der ITEM-Text-Datei verlinken. Diente hier nur zum Test.

16-FachIO
ITEM (hier wurde vorher über paperui / Configuration/Things/BrickletIO16 der GPIO als Input konfiguriert)
>>Switch-Item in der Item-Text-Datei mit einen der GPIO (Switch) Channel verlinkt, funktioniert
(beim Verbinden des GPIO Kontakt am Bricklet mit dem GND-Kontakt >> Änderung des Status ON/OFF)
Rule
Version1: mit einem Item arbeiten, das über die ITEM-Text-Datei mit dem GPIO-Channel verlinkt wurde >> Funktion OK

Version2: In einer Rule direkt mit dem Channel arbeiten (keine Funktion)
>>Frage: wie gehe ich in einer Rule mit einem (Switch) GPIO-Channel des des 16fach-IO um, wenn ich den Zustand ON oder OFF auslesen will (wenn dieser als INPUT konfiguriert ist) ?? Wie müsste das Channel-Argument lauten ?
Quote
when
       Channel "tinkerforge:io16:f4a5fb45:D8e:gpio0" triggered [<triggerEvent>]  ??
then

Generelle Frage: Wie kann ich in einer Rule den Status eines Channel‘s abfragen ?
Bei einem ITEM habe ich bisher
Quote
>>if (ITEM.state != ON)<<

dessen Status abfragen können, wie würde Status-Abfrage eines Channel aussehen ?
Quote
>>if (channel?? !=ON)<<

LCD128x64
ITEM (Channel-Verlinkung über die ITEM-Text-Datei) , je zwei Button, Slider, (TAB war mir nicht klar wie es unter paperui / Configuration/Things/ konfiguriert werden muss)
>> Slider >> ITEM-Typ Number >> über den Touchscreen können Wert des Number-ITEM verändert werden
>> Button >> ITEM-Typ Switch >> bei einmaligen betätigen kam im Log die Meldung Presses gefolgt von Released.
Das ITEM behielt auf "basicui" den Zustand ON, nach erneuten Betätigen änderte sich der ITEM-Status auf OFF (analoges Verhalten wie beim Multitouch)
Rule Teil1
Sowohl der Channel (Button) als auch der über die ITEM-Datei zu einem ITEM (Switch) verlinke Channel können als "Trigger" für die Rule eingesetzt werden.
Es wurden Button0 & Button1 & Slider0 sowie ein Text (Hello World) auf dem LCD128x64 erzeugt.
Bei betätigen der unterschiedlichen Button's konnten verschiedene Rule's ausgelöst werden
Getestete action des LCD128x64
   clearDisplay (löscht nur den Text)
   writeLine (schreibt einen Text)
   removeAllGUI (löscht alle Button & Slider)
   setGUIButton (erzeugt einen Button)
   setGUISlider (erzeugt einen Slider)
   setGUITabText (hier war mir nicht klar wie ich ihn unter Things konfigurieren muss, nicht getestet)
FRAGE: "Wie verändere ich die Helligkeit der Background-Beleuchtung ? Im Tinkerforge BrickViewer wird dies per Slider ausgeführt, kann es sein dass dieser noch fehlt ?

Rule Teil2
Gedanke: Sobald sich der Slider-Wert (ITEM-Typ-Number) verändert, sollte eine Rule gestartet werden, schlug aber fehl
 
Quote
>>"Number LCD128x64_SL0    "LCD128x4 Slid0 [%s]" (TestTF)  {channel="tinkerforge:lcd128x64:f4a5fb45:HQJ:slider0" }" in ITEM-TEST-DATEI
>
Quote
>"when Item LCD128x64_SL0 changed then ..." >> in Rule
Fehlermeldung im LOG
Quote
2019-04-22 19:33:04.510 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'LCD164-Slider': An error occurred during the script execution: index=0, size=0
Die Wert-Änderung des Number-ITEM wird jedoch im LOG und auch auf der "basicui" angezeigt
Quote
>>2019-04-22 19:36:17.164 [vent.ItemStateChangedEvent] - LCD128x64_SL0 changed from 8 to 31<< Log
Frage: Wo könnte hie der Fehler liegen ?


HumidityV2
ITEM (Channel-Verlinkung über die ITEM-Text-Datei) für den Humidity-Wert (Number-Item), Temperatur-Wert (Number-Item), Heater (Switch-ITEM) war erfolgreich
Rule: Bei Änderung des Item-Number Value wurde eine Rule gestartet
   " when Item HumV2H changed then..."
der Wert des Number-Item kann genutzt werden
Quote
(>> logInfo("Humv2", "Hum aenderung" + HumV2H.state ) <<)

Auch hier die Frage: Wie muss die Trigger-Bedinung lauten, dass ich eine Rule direkt über die Änderung der Channel-Werte ansteuern kann ?
Quote
>> when Channel "tinkerforge:humidityV2:f4a5fb45:Dfm:humidity" triggered [<triggerEvent>] then ..."
hier sollte auf die Änderung reagiert werden

Ich hoffe mein Wording ist soweit verständlich
Vieles hat funktioniert, bei einigem (vor allem das Nutzen von Channels als Trigger-Event funktionierte nicht immer). Ich hab zu dem Channel Trigger im Netz gesucht, aber nicht so richtig was gefunden (für die oben genannten "Unschärfen" )

viele Grüsse
Stefan

P.S.
Ich hab begonnen das LCD20x4 analog dem LCD128x64 zu testen, ich bin noch nicht fertig. Nur soweit, bis jetzt konnte ich weder einen Button nutzen, noch Text auf das Display schreiben. Einzig die Background-Beleuchtung konnte ich per Switch ein und aus schalten.
« Last Edit: April 23, 2019, 08:02:08 by StefanOHAN »

sihui

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: openhab Integration
« Reply #469 on: April 23, 2019, 06:59:42 »
Ich hab zu dem Channel Trigger im Netz gesucht, aber nicht so richtig was gefunden (für die oben genannten "Unschärfen" )

Ich kenne bis jetzt nur zwei Bindings die das unterstützen, Amazon Dash und Astro. Ob Theo das bei jedem Bricklet eingebaut hat oder es vom Binding generell unterstützt wird kann ich nicht sagen.

Zu deiner "Status"-Frage:

https://www.openhab.org/docs/configuration/rules-dsl.html#channel-based-triggers

Es gibt keinen fortlaufenden Status bei einem Channel Trigger. Der Trigger löst etwas aus und danach wird kein Status mehr upgedated.


StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #470 on: April 23, 2019, 08:22:36 »
Hallo sihui,

danke für Deine Antwort zum Thema Channel.

Ich hatte die Überlegung dass ich über eine Rule das Verhalten des 16-Fach-IO (als Input konfiguriert) aus openhab 1.x nachbaue. Also wenn der "Switch" (Physik des GPIO, als input konfiguiert) über die basicui / Sitemap betätigt wird, wird der Status des GPIO überprüft und nur wenn wirklich der Zustand des GPIO mit dem des Switch (auf der basicui) übereinstimmt wird dieser beibehalten, ansonsten geändert.

Wenn ich das richtig verstehe, kann ich das nicht über eine Status-Abfrage des channel ausführen, oder ?

Weißt Du wie sich das System beim Hochlaufen verhält ?
Ich meine wird eine Art Initialer Status übermittelt ?
Hintergrund der Frage ist das Beispiel eines Fensterkontakt.
Wenn das System gestartet wird, checke ich in der alten (1.9) Version alle Fensterkontakte und übermittle eine Nachricht auf mein Smartphone mit dem Hinweis dass das System neu gestartet wurde und ob alles Fenster geschlossen sind.
Ist das auch in der neuen Version möglich ? oder kann ich nur auf channel-Änderungen reagieren ?

sihui

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: openhab Integration
« Reply #471 on: April 23, 2019, 08:52:15 »
Also wenn der "Switch" (Physik des GPIO, als input konfiguiert) über die basicui / Sitemap betätigt wird
Es ist ein Input, wieso sollte man diesen aktiv per Switch ändern?
Du musst den Switch nicht als Schalter sehen, sondern als Status.

Wenn ich das richtig verstehe, kann ich das nicht über eine Status-Abfrage des channel ausführen, oder ?

Ich glaube das geht nicht. Allerdings habe ich es auch noch nie versucht. Der Channel Trigger ist ein momentaner Trigger und hat eigentlich in dem Sinne keinen Status.

Weißt Du wie sich das System beim Hochlaufen verhält ?
Ich meine wird eine Art Initialer Status übermittelt ?

Beim booten sind alle Zustände NULL oder UNDEF. Wenn du direkt nach dem Booten einen Status benötigst nimmt man dazu die Persistence und ein restoreOnStartup:

https://www.openhab.org/docs/configuration/persistence.html#predefined-strategies

Allerdings berücksichtigt das natürlich keine Änderungen des Zustandes während der Down Zeit von openHAB.

Ist das auch in der neuen Version möglich ? oder kann ich nur auf channel-Änderungen reagieren ?

Grundsätzlich funktioniert openHAB2 genauso wie openHAB1, nur die Channels sind an Things gebunden und nicht mehr an Items.
Ich habe ein Update direkt nach dem Restart noch nie gebraucht (openHAB ist ja mal höchstens für 2 Minuten offline beim booten), deshalb kann ich dir nur ein paar grundsätzliche Hinweise geben:
System started Trigger:
https://www.openhab.org/docs/configuration/rules-dsl.html#system-based-triggers
in Zusammenhang mit einer Refresh Abfrage:
Code: [Select]
import org.eclipse.smarthome.core.types.RefreshType
...
sendCommand(ITEM_NAME, RefreshType.REFRESH)
Ob diese "org.eclipse.smarthome.core..." Imports allerdings noch in neueren Versionen von openHAB2 funktionieren weiß ich leider nicht, eventuell heißen diese jetzt wie früher "org.openhab.core..."

In der englischen Community gibt es massig Beispiele um offene Fenster oder Türen anzuzeigen, eine Variante wäre:
https://community.openhab.org/t/rule-to-count-open-windows/49919/8


StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #472 on: April 24, 2019, 08:11:12 »
Hallo sihui

danke für Deine Antworten.
Ich habe gestern mal kurz mit dem Refresh Beispiel von dir gespielt, es erscheint im Log die Meldung (wie Du vermutet hast) dass der Import nicht mehr benutzt wird. Es kommt aber beim Aufruf in einer Rule keine weiter Fehlermeldung.

Eines konnte ich beobachten, beim starten von Openhab werden die Items die mit den GPIO's Channels des 16-Fach IO verlinkt sind, initialisiert. Das muss ich aber nochmal genauer testen.

Du hast geschrieben:
Quote
Es ist ein Input, wieso sollte man diesen aktiv per Switch ändern?
Ich sehe das so, ein Programm muss immer so geschrieben sein, dass eine Fehlbedienung nicht möglich ist. Auch wenn in diesem Fall der Switch als Input (Status) dient, ist er bedienbar. Ich kann sicher Items nicht in Gruppen aufnehmen und sie dadurch unsichtbar lassen, oder alles nur über die SiteMap darstellen in der ich ITEMs anders darstellen kann. Es bleibt aber nur eine "Hilfslösung".

Meine vielen Fragen und Hinweise sollen Theo als Feedback bei seiner Binding Entwicklung helfen und auch einen anderen Blickwinkel auf die Nutzbarkeit eröffnen. Jetzt besteht noch die Möglichkeit Funktionen anzupassen.

Zum Thema "Status-Abfrage". Wenn ich die Tinkerforge Komponenten über MasterExtentions (IP / RS485) kopple kann es durchaus vorkommen dass es kurzfristig zu einem Verbindungsabbruch kommt (Teste dies ja gerade mit der RS485 Extention) wenn die Spannungsversorgung an der "Remote" angebundenen Extention weg bricht. Genau für diese Situation ist es aber schon wichtig zu wissen ob ich einen Status aktiv abfragen kann oder nicht.
Die PersistenzDB hilft hier nur wenig (ist ja ein Blick in die Vergangenheit).

Du kennst ja mein Ziel "100%" Hausautomation mit Tinkerforge und Openhab2, hierzu muss ich aber mit Remote-Angebunden Master-Bricks Arbeiten und auch sowas wie "Kommunikations-Ausfälle" abfangen.

Ich würde sagen vorerst kann nur Theo sagen wie er mit diesen Punkten umgegangen ist und wie seine Sichtweise ist.

viele Grüsse

Stefan

sihui

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: openhab Integration
« Reply #473 on: April 24, 2019, 08:14:36 »
Auch wenn in diesem Fall der Switch als Input (Status) dient, ist er bedienbar.

Wie schon geschrieben: als Text Item in die Sitemap einfügen, nicht als Switch, dann ist er nicht mehr bedienbar und dient ausschließlich als Statusanzeige.

theo

  • Sr. Member
  • ****
  • Posts: 316
    • View Profile
    • Twitter
Re: openhab Integration
« Reply #474 on: May 05, 2019, 21:25:31 »
Hallo Stefan, Sigi, André und Jerome,

immerhin habe ich es jetzt geschafft eure Postings zu lesen. Leider ist meine Baustelle von Entrümpeln + Streichen zu einer Kernsanierung mutiert. Daher werde ich in nächster Zeit weniger zu TF + openHAB kommen als mir lieb ist, es wird aber weiter gehen.
Ein großes Problem scheinen mir die Trigger-Channels zu sein. Diese sind eine tolle Sache, da man sich die üblichen Rules sparen kann, die z.B. einen Schalter mit einer Lampe verbinden. Die Zauberworte sind hier "Profile" und "Multichannel Linking" und "Channel Type". Die "Channel Types" die ich im Binding für TriggerChannels verwende sind soweit ich mich erinnere alles system.rawbutton. Doku und ein Beispiel zu TriggerChannels findet ihr hier: https://www.openhab.org/docs/configuration/items.html#profiles

Ein konkretes Beispiel wäre: du willst mit einem Button am LCD Bricklet dessen Backlight an/aus schalten. Dazu musst du nur ein Item für die Hintergrundbeleuchtung anlegen (nicht für den Button, das geht mit TriggerChannels gar nicht!) und in dessen Item-Konfiguration sowohl den Backlight-Channel als auch den ButtonChannel referenzieren. Dazu kommt noch eine passende "profile" Konfiguration, z.B. "rawbutton-toggle-switch". Beim Doku Link findet ihr dieses Beispiel, dass ihr einfach auf das LCD-Bricklet übertragen könnt:

Code: [Select]
Color Bedroom_Light { channel="hue:0210:1:bulb1:color", channel="serialbutton:button:mybutton:button" [profile="rawbutton-toggle-switch"] }

Gruß,
Theo

StefanOHAN

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: openhab Integration
« Reply #475 on: May 07, 2019, 12:37:56 »
Hallo Theo
danke für den Hinweis, ich bin momentan leider auf Achse und kann frühestens am WE weiter testen.

Viele Grüsse

Stefan

theo

  • Sr. Member
  • ****
  • Posts: 316
    • View Profile
    • Twitter
Re: openhab Integration
« Reply #476 on: May 08, 2019, 21:31:05 »
Hallo André,

Code Contributions sind herzlich willkommen.
Eine erste Entwickler-Doku gibt es jetzt hier: https://github.com/theoweiss/tinkerforge-client-codegen im README.md

Gruß,
Theo

andiikaa

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: openhab Integration
« Reply #477 on: May 17, 2019, 10:12:13 »
Hallo Theo,

danke für die Mühe. Die Sachen, welche ich benötigte, musste ich erstmal noch in das OH1 Binding implementieren.
Ich schau mal, wie ich die Zeit finde, um am OH2 Binding mitzuwirken. Momentan habe ich viel zu tun und leider auch nicht mehr lange Zugriff auf die Bricklets.

Gruß,
André

Jerome

  • Newbie
  • *
  • Posts: 11
    • View Profile
    • HeliosBox
Re: openhab Integration
« Reply #478 on: May 18, 2019, 18:17:45 »
MotionSensor V2 funktioniert nun einwandfrei mit dem Element Switch

Code: [Select]
Switch MotionSensor "Motion [%s]" <motion> { channel="" }
Danke

***

Sobald mal Zeit da ist wäre ich froh um die Unterstützung für das GPS Bricklet und das korrigieren der Angaben von dem BarometerBricklet.

Schönes Wochenende

rak

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: openhab Integration
« Reply #479 on: May 26, 2019, 17:17:29 »
Hallo OH Gemeinde,

ich bin schon lange aktiv in der OH community und dort auch unter RAK erreichbar. Ich betreibe 2 OH Anlagen und möchte gerne mit Tinkerforge nun mein Wohnmobil smart machen.

Ich lese mich noch ein wenig ein. Die Hardware ist da und läuft auch schon mit dem BrickViewer. Nächster Schritt ist einen neuen Pi3B+ aufzusetzen mit OH und brickd (beides in jeweils einem Docker Container) und dann das Binding mal in Angriff nehmen.

Ich freue mich hier mit euch an dem Thema weiter zu kommen.

Gruss
Ralf