Betaversion der openHAB-Bindings

[StefanOHAN]

Hallo Erik,

ich habe am Wochenende meine Test-Konfiguration etwas erweitert.

+ Dual Button Bricklet 2.0

+ Isolator Bricklet → als „Kabel-Verlängerung 2 x 2m für das Humidity Bricklet 2.0

+ Remote Switch Bricklet 2.0 → mit einer Funksteckdose (TypA) und Fernbedienung (beides aus Eurem Shop)

+ Energy Monitor Bricklet samt 5A Stromwandler & Spannungstransformator

 

Vieles konnte ich noch nicht testen, die Funksteckdose kann per rule über das Remote-Switch-Bricklet ein und aus geschaltet werden.

Die Button und LED des Dual Button funktionieren auch soweit. Die mit den Energy-Monitor Channel verlinkten Items (Spannung/Strom/Leistung / Arbeit) funktionieren. Actions habe ich allerdings für diese Brickles noch nicht getestet.

 

Zum Remote Switch Bricklet 2.0

Laut Eurer Dokumentation

Zitat

 

„Nutzung als Empfänger

Funksteckdosen werden üblicherweise mit dazugehörigen Fernbedienungen geliefert. Diese Fernbedienungen kann das Remote Switch Bricklet 2.0 auslesen.

Dazu muss das Bricklet für einen Empfang des jeweiligen Typs konfiguriert werden. Anschließend können die empfangenen Signale ausgelesen werden.“

 

 

Hierzu hätte ich eine Frage:

können die Daten der Funksteckdosen-Fernbedienung nur per Aktion ausgelesen werden, oder gibt es auch die Möglichkeit über einen Channel die Fernbedienung aktiv zum Steuern einer Rule zu nutzen ?

 

Eine weiter Frage:

Ich habe mein vorhandenes Humidity Bricklet 2.0 über das Isolator-Bricklet (mit 2m Zuleitung + 2m Ableitung ) an das Masterbrick 2.1 angebunden (funktioniert). Es liegt jetzt neben einem TH-6148 Sensor.

Kann es sein, dass das Humidity Bricklet 2.0 und der TH-6148 Sensor, über 1,2 Grad Celsius Unterschied in der Messung liefern können ? (diese Temperatur Differenz wird auch über den Brickviewer angezeigt, es macht auch keinen Unterschied ob das Isolator Bricklet zwischen geschaltet ist oder nicht). Wenn ich meine beiden Humidity Bricklet 2.0 vergleiche, ist das Delta  maximal 0,25 Grad. 

 

Weiter mit dem Beta 18 Binding

Ich bin mir nicht sicher ob alles richtig funktioniert, da viele Rules die auf „Channel …. triggerd RELEASED „ konfiguriert waren (LCD128x64 / LCD 20x4), umgestellt werden müssen, da alle fast gleichzeitig beim Startup angelaufen sind und Unmengen Fehlermeldungen produziert haben.

Das muss ich mir in aller Ruhe nochmal anschauen und evtl auch ein paar Rules umbauen.

Eigenartig war jedoch, dass nach einigen (aber nicht allen) Restart / Reboot bei Rules die Action enthalten, Fehlermeldungen kamen, dass jene oder welche Action „is not a member of …“ ist.

Zitat

Rule 'Slider0-changed': 'brickletLCD128x64DrawText' is not a member of 'org.eclipse.smarthome.core.thing.binding.ThingActions';

 

Wenn ich den Log so anschaue, habe ich fast den Eindruck, dass teilweise Rules schon geladen sind, während das System noch dabei ist alle Tinkerforge Komponenten zu laden / initialisieren und dies dann zu Fehlermeldungen führt. Nach den letzten beiden Reboots kamen diese Fehlermeldungen nicht mehr, werde ich aber noch genau beobachten.

 

Den log:set TRACE org.eclipse.smarthome.binding.tinkerforge habe ich aktiviert.

 

Ich hoffe diese Woche abends die restlichen Rules bereinigen zu können, dann kann ich genaueres sagen.

 

Viele Grüße

 

Stefan

Update 11.2.2020: Bei einen kurzen check der Logfile (seit gestern Nacht) sind mir keine Error-Meldungen aufgefallen. 

Zum oben erwähnten Punkt dass teilweise die Rules schon geladen sind während das Tinkerforge Binding noch am initialisieren der TF Komponenten ist. Das Problem hatte ich auch schon in der Openhab 1 Version. 

Meine Frage: Meinst Du es wäre möglich pro TF-Dämon einen "Channel" einzubauen der einfach mitteilt wann das laden / Initialisieren aller TF Komponenten abgeschlossen ist ? Dann könnte man einfach die Rules so aufbauen dass diese erst reagieren wenn der Dämon Ready gemeldet hat.

Über die Openhab System-based triggers (System started) klappte das bei mir nie so richtig, da die Rules meist nicht komplett geladen waren wenn vom System "der System started" trigger kam. Aus der "Not" hatte ich damals einen Timer eingebaut.

bearbeitet February 11, 2020 at 07:51 von StefanOHAN

[rtrbt]

Moin

14 hours ago, StefanOHAN said:

können die Daten der Funksteckdosen-Fernbedienung nur per Aktion ausgelesen werden, oder gibt es auch die Möglichkeit über einen Channel die Fernbedienung aktiv zum Steuern einer Rule zu nutzen ?

Das geht nur über eine Rule, du kannst aber (z.b.) ein Switch-Item anlegen, dass du über die Rule steuerst, und das dann normal an Channels koppeln oder in anderen Rules verwenden.

14 hours ago, StefanOHAN said:

Kann es sein, dass das Humidity Bricklet 2.0 und der TH-6148 Sensor, über 1,2 Grad Celsius Unterschied in der Messung liefern können ?

1,2°C heißt, dass das Humidity Bricklet wärmer misst als der TH-6148? Dann liegt es eventuell an der eingestellten Sample Rate des Humidity Bricklets. Wenn die zu hoch ist, heizt es sich selbst auf.

14 hours ago, StefanOHAN said:

Meine Frage: Meinst Du es wäre möglich pro TF-Dämon einen "Channel" einzubauen der einfach mitteilt wann das laden / Initialisieren aller TF Komponenten abgeschlossen ist ? Dann könnte man einfach die Rules so aufbauen dass diese erst reagieren wenn der Dämon Ready gemeldet hat.

Das geht, ich setze es mal auf die TODO-Liste.

Was ich übrigens vergessen hatte zu erwähnen: Die Elektroden der Multi Touch Bricklets sind jetzt wieder state-basierte Channel, d.h. du musst wieder Items anlegen, wenn du in Regeln auf sie reagieren willst. Aufgrund der Art und Weise wie die Java-API intern funktioniert, bekomme ich das nicht sauber auf Trigger-Channel gemappt.

[rtrbt]

Anschlussfrage zu dem Initialisierungs-Channel: Würde es nicht reichen, wenn du in den Rules Thing-basierte Trigger benutzt? Zum Beispiel:

Thing "tinkerforge:brickletrgbledbutton:Enx" changed from INITIALIZING to ONLINE

Das sollte sowohl mit dem Brick Daemon, als auch mit den eigentlichen Devices funktionieren und hat den Vorteil, dass es auch passiert, wenn die Verbindung verloren ging und neu aufgebaut wurde. Also wenn du z.B. einen RGB LED Button hast, der immer eine Farbe haben soll, wenn gerade nichts anderes los ist, kannst du den Trigger benutzen um die Farbe zu setzen. Dann repariert sich das auch, wenn du das Bricklet (oder den ganzen Stack) vom Strom trennst und wieder anschließt.

[StefanOHAN]

Hallo Erik

ich habe soweit meine Test-Rules angepasst. Jetzt kommen nach dem System Reboot keine Fehlermeldungen mehr.

Nach dem der System-based trigger „System startet“ meldet, läuft ein Timer an der nach 60 sec das Item „Online“ vom Typ Contact auf Closed setzt. Alle relevanten Rules prüfen nun ab, ob das ITEM Online den Status Closed hat. Nur dann dürfen sie los legen.

Um keine „Error-Meldungen“ zu verpassen, habe ich noch das Add-ON „LogReader“ eingebunden und konfiguriert. Wenn eine neue Error-Meldung im Log erscheint gibt der Piezo Speaker einen kurzen Beep ab. Ich muss mal schauen dass ich auch die "offline-Meldungen" für den Dämon mit erfasse (aktuell werden nur "ERROR" berücksichtigt). 

Zum Thema Temperatur Mess-Differenz zwischen HumidityBricklet 2.0 und Sensor TH-6841

Ja das Humidity-Bricklet gibt die um ca 1.2 Grad höher Temperatur als der TH-6841 Sensor aus.

Frage, was verstehst Du unter „hohen“ Sampel Rate ? Ich habe aktuell eine SampeRate von 0.1 und eine „Temperatur Moving Average Length“ von 5.

 

Zu Meiner Frage „Funksteckdosen Fernbedienung“ für Rule Steuerung nutzen.

Nachdem ich sah, dass beim betätigen der Fernbedienung im Log

Zitat

 

2020-02-11 21:19:49.114 [vent.ChannelTriggeredEvent] - tinkerforge:brickletremoteswitchv2:EB9:BrickletRemoteSwitchV2RemoteStatusAAvailable triggered

 

erscheint, wollte ich die Daten per Action „brickletRemoteSwitchV2GetRemoteStatusA“ auslesen.

Meine Rule sieht wie folgt aus:

 

Zitat

 

rule "teste-funksteckdosen-fernbedienung"

when

    Channel "tinkerforge:brickletremoteswitchv2:EB9:BrickletRemoteSwitchV2RemoteStatusAAvailable" triggered

then

    val rswitch1 = getActions("tinkerforge", "tinkerforge:brickletremoteswitchv2:EB9")

    val rsaction = rswitch1.brickletRemoteSwitchV2GetRemoteStatusA()

    logInfo("remoteswitch","RemoteControlstatus=" + rsaction + "<<")

end

 

 

leider funktioniert die Rule nicht. Siehe Fehlermeldung

Zitat

„2020-02-11 21:04:55.163 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'teste-funksteckdosen-fernbedienung': 'brickletRemoteSwitchV2GetRemoteStatusA' is not a member of 'org.eclipse.smarthome.core.thing.binding.ThingActions'; line 288, column 20, length 49

in Line 228 steht

Zitat

val rsaction = rswitch1.brickletRemoteSwitchV2GetRemoteStatusA()

Ich weiß leider auch nicht wo mein Fehler liegt.

 

Zu Deinem Vorschlag

vor 14 Stunden schrieb rtrbt:

Anschlussfrage zu dem Initialisierungs-Channel: Würde es nicht reichen, wenn du in den Rules Thing-basierte Trigger benutzt? Zum Beispiel:

Thing "tinkerforge:brickletrgbledbutton:Enx" changed from INITIALIZING to ONLINE

 

Das habe ich noch nicht probiert, ich denke dann müsste ich aber alle relevanten Bricklet auf diese Weise in einer Rule abfragen und über eine "Merker-Varialben / Item" den Status vorhalten. Das muss ich mal testen, ob ich damit in den Rules klar komme.

Deutlich einfacher wäre es wenn diese über den Dämon gemeldet wird 😉 

Ich werde das mal auf meine Wochenende Test-To-Do Liste setzten

 

Viele Grüße Stefan

P.S Die Log-Meldungen kann ich erst heute Abend in aller Ruhe kontrollieren

bearbeitet February 12, 2020 at 05:21 von StefanOHAN

[sihui]

Am 31.1.2020 um 16:00 schrieb rtrbt:

Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt.

Gerade mit der Beta 18 und einem Remote Switch Bricklet V1 getestet: funktioniert einwandfrei. Allerbesten Dank.

Dann kann ich jetzt bald mein Produktionssystem auf das neue Tinkerforge Binding umstellen .... 😀

[rtrbt]

Moin,

3 hours ago, StefanOHAN said:

Frage, was verstehst Du unter „hohen“ Sampel Rate ? Ich habe aktuell eine SampeRate von 0.1 und eine „Temperatur Moving Average Length“ von 5.

0.1 ist defintiv nicht hoch. Alles über dem Default von 1 hätte ich verstanden, so ists seltsam. Hast du eventuell ein drittes Thermometer, mit dem du messen kannst? Vielleicht liegt es ja garnicht am Humidity Bricklet, sondern an dem TH-6841.

Zu der RemoteSwitchActions-Sache: Da habe ich wohl nach dem Testen noch einen Bug eingebaut. Die Bricklets haben eigene Actions, der RemoteSwitchHandler meldet aber openHAB, dass sie nur die DefaultActions (also nichts) unterstützen. Der Fix kommt in die nächste Beta, sorry dafür.

3 hours ago, StefanOHAN said:

Das habe ich noch nicht probiert, ich denke dann müsste ich aber alle relevanten Bricklet auf diese Weise in einer Rule abfragen und über eine "Merker-Varialben / Item" den Status vorhalten. Das muss ich mal testen, ob ich damit in den Rules klar komme.

Deutlich einfacher wäre es wenn diese über den Dämon gemeldet wird 😉

Nur aus Interesse und damit ich weiß wie ich das eventuell modelliere: Was würdest du in Rules laufen lassen, die beim ersten Initialisieren vom Binding ausgeführt werden, aber nicht, wenn sich ein Device neu initialisiert?

[StefanOHAN]

Hallo Erik

zu Deiner Frage:

wie formuliere ich meinen Gedanken am besten.

Eigentlich wollte ich nur so eine Art „Statusmeldung“ dass der Dämon nach einem „Neustart/Reboot“ seinen Startup Prozess abgearbeitet hat.

Beispiel:

Das Humidity-Bricklet 2.0 ist über Dämon-A (z.B. WIFI) angebunden und liefert sehr früh nach einem Startup schon Daten.

Die zugehörige Rule soll ab einem Schwellwert auf dem LCD128x64 Daten ausgeben.

Das LCD128x64 ist über Dämon-B angebunden (z.B. Masterbrick per USB angeschlossen). In der Hochlaufphase kommt es vor, dass Dämon-A schon fertig alle Komponenten initialisiert hat, und dessen Brickles schon Daten lieferten, während Dämon-B noch beim initialisieren ist (da dieser für mehr Bricklets zuständig ist). Folge ist, dass Unmengen an Fehlermeldungen durch die Rules in das Log geschrieben werden.

Ein ähnliches Problem hatte und habe ich auch bei meiner Openhab1 Konfiguration (ca 15 TF Komponenten ).

Um diesen „Log-Spam“ zu umgehen und die Lesbarkeit des Log zu erhalten, habe ich damals (openhab1) einfach eine Timer-Rule eingebaut, die 60 Sekunden nach der „System Started“ Meldung ein ITEM mit Namen „SystemOnline“ vom Typ CONTACT auf Closed gesetzt hat.

Alle anderen Rule‘s fragten ab, ob „SystemOnline“ den Status CLOSED hat und nur wenn dieses den Status CLOSED hatte, durften die Rules „loslegen“.

Mit dieser Regel konnte ich zwar den Log-Spam beseitigen, aber gerade während der Test-Phase hat dies zu laaaaaaaangen Wartezeiten geführt.

Bei meiner Frage an Dich, war mein Hintergedanken diese statischen langen Wartezeiten durch den Timer verhindern zu können, in dem das Binding melden würden, wenn es seine Startup Routine abgearbeitet hat.

Deine Idee auf den Thing-Status zur reagieren, finde ich aber echt gut.

Beispiel wie ich meine Rule‘s „warte bis der TF-Dämon den Init-Lauf abgeschlossen hat“ aufbauen würde. (so ähnlich funktioniert es mit meiner Timer-Rule in openhab1).

Zitat

 

→> Item

CONTACT  TfinitOK  „TF Dämon init abgeschlossen [%s]“ (Gruppe)

 

Zitat

 

→> Rule's 

 

rule „aktion bei Startup-System“

when

System started

then

TfinitOK.sendCommand(OPEN)

end

 

rule „Rückmeldung Dämon Init ausgeführt“

when

Channel „tinkerforge:Dämon“ triggerd „init-abgeschlossen“

then

TfinitOK.sendCommand(CLOSED)

end

 

rule „dies ist einen Rule für eine beliebige Aufgabe“

when

Channel „tinkerforge:xyz“ triggerd

then

var a = 1 + 1

end

 

 

Mein Gedanke hat allerdings einen Haken.

Die Rückmeldung des Binding darf nicht auf die Vollständigkeit der Komponenten mit Status-Online ausgelegt sein, sondern darf nur melden dass der Initialisierungs-Prozess durchgelaufen ist, auch wenn Komponenten „offline“ sind.

 

Beispiel:

Ein Dämon kennt ein Bricklet das über eine Masterbrick der per RS485 Extention an den Masterbrick der per USB an das System angeschlossen ist.

Wenn nach einem Reboot die Spannungsversorgung des „abgesetzten Masterbrick-Stapel“ nicht mehr funktioniert und der Dämon nur eine Meldung absetzten würde wenn alle Bricklets die er kannte und kennt online sind, würde es bedeuten dass obige Rule „Rückmeldung Dämon Init ausgeführt“ erst aktiv wird, wenn ALLE Komponenten wieder online sind. Somit würden alle Rule‘s die diese positive Rückmeldung benötigen, auf ewig inaktiv bleiben.

Da stellt sich die Frage, was und wann soll der Dämon nun melden ?

Zitat

 

>> init abgeschlossen ??

>> init abgeschlossen mit Fehlern

 

 

Ich bin mir jetzt echt nicht sicher ob Dein Vorschlag in der Hochlauf-Phase auf die Online-Meldungen der Bricklets zu reagieren nicht sinnvoller wäre.

 

Das ist jetzt viel Text zu lesen, ich wusste aber nicht wie ich es (Inklusive der möglichen Probleme) beschreiben soll.

 

Viele Grüße

 

Stefan

[rtrbt]

Hm das robust zu bauen ist schwierig. Ich würde bei deinem Humidity+LCD-Beispiel folgendes versuchen:

Ein Switch-Item, das du mit einer Rule schaltest, wenn der Humidity-Threshold zu hoch ist oder wieder darunter fällt. Dann dazu eine Rule, die sowohl darauf reagiert, wenn das LCD initialisiert ist, als auch wenn das Humidity-Item schaltet und in der Regel mit der Thing-Status-Action als erstes prüft, ob das LCD online ist, und wenn nicht den Wert anzeigt:

rule "LCD-Humidity"
when
    Thing <LCD-UID> changed from INITIALIZING to ONLINE or Item <humidity-threshold-item> changed
then
    var thingStatusInfo = getThingStatusInfo("lcd-uid")
    if ((thingStatusInfo == null) || (thingStatusInfo.getStatus().toString() != "ONLINE")) {
        return
    }

    //lcd-actions holen, wert anzeigen
end

Vorteil ist, dass du dann sofort einen aktuellen Wert auf dem LCD bekommst, wenn es online ist (oder wieder neu online kommt weil die Verbindung kurz weg war, oder Stromausfall oder was auch immer), aber die Rule auch nur dann läuft. Das ist natürlich je nach Menge der Bricklets relativ viel Rule-Code den du schreiben/kopieren musst.

[StefanOHAN]

Hallo Erik

ich glaub ich hab das ganze viel zu kompliziert erklärt.

Dein Vorschlag ist wesentlich eleganter als mein ursprüngliches Ansinnen.

Ich wollte einfach nur verhindern, dass während der Hochlauf-Phase viele Fehlermeldungen produziert werden und gleichzeitig meine „brute-force“ Lösung mit dem Wait-Timer nicht mehr benötigt wird.

Deine Idee gefällt mir echt gut, ich werde Sie am Wochenende mal in den Rules mit Action versuchen einzubauen.

Eigentlich könntest Du das mit dem Dämon Initialisierungs-Channel jetzt schon von Deiner To-Do Liste streichen, denn Dein Vorschlag gefällt mir viel besser als mein Ursprungs-Gedanke.

 

Zum neuen Binding B18

Bis jetzt habe ich keine Error‘s im Log gefunden.

Es gab nur eine Warn-Meldung, die aber unkritisch ist

Zitat

[core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'tinkerforge:brickletlcd128x64:HQJ' takes more than 5000ms.

Einen TimeOut des Dämon hab ich bis jetzt auch noch keinen gesehen, nachdem der letzte Reboot aber erst gut 24 Stunden her ist, werde ich das Thema noch weiter beobachten.

Zum Thema Mess-Unterschiede Humidity Bricklet vs TH-6841, ich hab meinen zweiten TH-6841 neben das Humidity Bricklet gelegt, muss aber noch abwarten bis sich dieser an die Raumtemperatur angepasst hat (war bis eben noch im Kühlschrank 😉 )

 

Viele Grüße Stefan

bearbeitet February 13, 2020 at 07:57 von StefanOHAN

[StefanOHAN]

Hallo Erik

ich habe jetzt auf Basis Deines Vorschlag bezüglich „Thing-Status“ meine StartUp-Rules umgebaut. Es hat sich einfach umsetzen lassen 🙂

Meine Rule reagieren jetzt auf Zustands-Änderungen von

>> Thing Bricklet

>> Thing Masterbrick

>> Thing Dämon

Es klappt sowohl der Thing Trigger um eine Rule zu aktivieren, als auch die Status-Abfrage mit „getThingStatusInfo“.

Mit Deiner Vorgehensweise ist man viel flexibler und kann individueller auf „Ausfälle“ und "Ladezeiten" (beim StartUp) reagieren.

Ich ziehe offizielle meine Anfrage nach einer Dämon Initialisierung-Channel zurück 🙂

 

Weiter mit meiner „Temperatur Mess-Differenz“ Problematik

Ich habe jetzt die beiden TH-6148 und das Humidity 2.0 über die letzten Tage verschiedenen Temperaturen ausgesetzt (15 Messzeitpunkte).

Die Temperatur-Differenz ist nicht linear und ich kann keine kläre Linie erkennen. Der Unterschied liegt zwischen 0 und 1,5 Grad.

Hintergrund meiner Frage:

Ich berechne mit den Messwerten (Temperatur / relative Luftfeuchte) die absolute Luftfeuchte innen/außen und eine Rule steuert darüber das Lüftungsverhalten. In meiner Rule habe ich eine Messtoleranz (innen/außen Sensor) von 2,5% berücksichtigt.

Kannst Du sagen welche Sensoren-Typen genauer sind, ich vermute mal der Humidity 2.0, oder ?

 

Viele Grüße

Stefan

[riro]

Hallo Forum,

habe den Thread gelesen und vielleicht einen Link zu einer Anleitung übersehen. 🙂 Ich würde gerne das Outdoor Weather Bricklet in Betrieb nehmen. Anhand den Beispielen von anderen Bricklets erahne ich wie das geht. Bevor ich Stunden lang rumprobiere hier meine Frage: Hat jemand das Outdoor Weather Bricklet in Betrieb genommen und könnte seine items für OH hier posten? (Das Bricklet ist im Paper UI schon online. Es wird sich wohl um diese Actions drehen: brickletOutdoorWeatherGetStationData, brickletOutdoorWeatherGetSensorData).

Dankeschön!

[StefanOHAN]

Hallo riro

ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz.

Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann der letzte Datensatz empfangen wurde.

Wenn Du die Outdoor Weather Station hast, dürfte das vorgehen ähnlich sein, nur dass diese mehr Daten übermittelt als der TH-6148 Sensor.

Als erstes muss Du den Sensor Identifier (für den TH-6148) oder den Station Identifier (für die WS-6147) ermitteln.

Das kannst Du über den Brickviewer oder du legt ein entsprechendes „String-Item“ mit dem passenden Channel des Outdoor Weather bricklet an. Die benötigten Channel findest Du im Konfigurations-Menue des Outdoor Weather Brickelt (Thing)

Es kann etwas dauern bis dir dann über das Sting-Item der passende Identifier angezeigt wird.

Beispiel meines ITEM‘s zum auslesen der Sensoren ID

Zitat

String OWS_Sens_ID       "Outdoor Wetter > Sensoren ID [%s]" (TestTF)  {channel="tinkerforge:brickletoutdoorweather:E4v:BrickletOutdoorWeatherSensorIdentifiers"}

 

Weiter mit anlegen/erzeugen des Sensor als „Thing“

Unter Paperui / Configuration / Thing, analog als ob du einen weitern Thinkerforge Dämon anlegen willst („MANUALLY ADD THING“)

Hier werden dir alle möglichen Thing-Optionen des Tinkerforge-Binding aufgelistet. (siehe Bild unten)

Wenn Du wie ich den TH-6148 Sensor hast, wähle diesen aus.

Über das folgende Menü kannst Du nun die Grundkonfiguration des Sensor ausführen.

 

1) unter Bride Selection / Select a Bridge >> „brickletoutdoorweather ….“ auswählen

2) unter Configuration Parameter die ID des Sensor eintragen

3) speicher und schon wirst du ein neues Thing unter Configuration finden.

 

Wenn Du nur Temperatur / Humidity / Last Change Daten haben möchtest benötigst Du keine Action da reichen entsprechende ITEM-Channel Verlinkungen in der ITEM Datei aus.

 

Zitat

 

Number S2HumIn_MA  "Luftfeuchte [%.2f %%]" (TestTF)  {channel="tinkerforge:outdoorweathersensor:54f35462:OutdoorWeatherSensorHumidity"}

Number S2TemIn_MA  "Temperatur [%.2f °C]" (TestTF)  {channel="tinkerforge:outdoorweathersensor:54f35462:OutdoorWeatherSensorTemperature"}

DateTime S2Last_MSG   "Letzte Meldung Funksensor [%1$tA, %1$td.%1$tm.%1$tY %1$tT]" (TestTF)  {channel="tinkerforge:outdoorweathersensor:54f35462:OutdoorWeatherSensorLastChange"}

 

 

Beim TH 6148 Sensor gibt es etwas zu beachten. Nach einem Batterie Tausch erzeugt er eine neu ID (gibt hierzu einen Post von Erik), und diese musst du dann über das „Konfiguraion‘s Menue“ des Thing TH-6148 anpassen (siehe oben Punkt2).

An den rules oder der Item-Channel-Verlinkung musst Du nichts anpassen.

 

Ich hoffe diese mini Anleitung hilft Dir

 

viele Grüsse Stefan

 

 

bearbeitet February 20, 2020 at 07:28 von StefanOHAN

[riro]

Hallo Stefan,

vielen Dank für die phantastische Anleitung!

Habe das so umgesetzt:

// .items für das TF OutdoorWeatherBricklet via Tinkerforge2.0 Binding

String TF_OutdoorWeather_SensorID                                                         "TF OutdoorWeather: Sensor ID [%s]"                                       {channel="tinkerforge:brickletoutdoorweather:xyz:BrickletOutdoorWeatherSensorIdentifiers"}
Number:Temperature TF_OutdoorWeatherSensorTemperature                                     "Temperatur Balkon [%.1f °C]"         <temperature>                       {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorTemperature"}
Number:Dimensionless TF_OutdoorWeatherSensorHumidity                                      "Luftfeuchte Balkon [%.0f %%]"        <humidity>                          {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorHumidity"}
DateTime TF_OutdoorWeatherSensorLastChange                                                "Letzte Meldung FunkSensor [%1$tA, %1$td.%1$tm.%1$tY %1$tT]" <date>       {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorLastChange"}


String                 TF_OutdoorWeather_StationID                                        "TF OutdoorWeather: Stations ID [%s]"                                             {channel="tinkerforge:brickletoutdoorweather:xyz:BrickletOutdoorWeatherStationIdentifiers"}
Number:Temperature     TF_OutdoorWeatherStationWS6147OutdoorWeatherStationTemperature     "Temperatur Hof [%.1f °C]"            <temperature>                               {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationTemperature"}
Number:Dimensionless   TF_OutdoorWeatherStationWS6147OutdoorWeatherStationHumidity        "Luftfeuchte Hof [%.0f %%]"           <humidity>                                  {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationHumidity"}
Number:Speed           TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindSpeed       "Windgeschwindigkeit"                 <wind>                                      {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationWindSpeed"}
Number:Speed           TF_OutdoorWeatherStationWS6147OutdoorWeatherStationGustSpeed       "Windböengeschwindigkeit"             <wind>                                      {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationGustSpeed"}
String                 TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindDirection   "Windrichtung"                        <wind>                                      {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationWindDirection"}
Number:Length          TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall        "Niederschlag [%.1f]"                 <rain>                                      {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationRainFall"}
Number:Dimensionless   TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall_test   "Niederschlag 1/10 mm [%s]"                                                       {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationRainFall"}
Switch                 TF_OutdoorWeatherStationWS6147OutdoorWeatherStationBatteryLow      "Batterie Wetterstation ist leer"     <lowbattery>                                {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationBatteryLow"}
DateTime               TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange      "Letzte Meldung FunkStation [%1$td.%1$tm.%1$tY  %1$tH:%1$tM:%1$tS]" <date>        {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationLastChange"}

und die passende Sitemap:

Frame label="Tinkerforge OutdoorWeatherStation und Sensor" {
    // Paper UI: Autodetect von Bricklets
    // Sensor und Station via Brick Viewer ermitteln oder per OH und String Item anzeigen lassen
    // via PaperUI: Manually add Thing, als Bridge OutdoorWeatherBricklet wählen, Sensor oder StationID eintragen
    // Damit ist ein Thing angelegt. Daraus Items erzeugen und eine Sitemap anpassen
    Default item=TF_OutdoorWeather_SensorID
    Default item=TF_OutdoorWeatherSensorTemperature valuecolor=[TF_OutdoorWeatherSensorLastChange=="NULL"="lightgray", TF_OutdoorWeatherSensorLastChange>90="lightgray", >=25="red", >=15="orange", >=10="green", 0="silver", <0="purple", <10="blue"]
    Default item=TF_OutdoorWeatherSensorHumidity
    Text item=TF_OutdoorWeatherSensorLastChange valuecolor=[TF_OutdoorWeatherSensorLastChange>120="orange", TF_OutdoorWeatherSensorLastChange>300="red"] //visibility=[TF_OutdoorWeatherSensorLastChange>30]

    Default item=TF_OutdoorWeather_StationID
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationTemperature valuecolor=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange=="NULL"="lightgray", TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>90="lightgray", >=25="red", >=15="orange", >=10="green", 0="silver", <0="purple", <10="blue"]
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationHumidity
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall label="Niederschlag [%.1f mm]" //Automatische Konvertierung m in mm via UOM, Achtung 1/10 mm?
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall_test label="Niederschlag [%s]" 
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindSpeed 
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationGustSpeed 
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindDirection
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange  valuecolor=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>120="orange", TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>300="red"] //visibility=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>30]
    Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationBatteryLow 
    }

Die Regenmenge und die Geschwindigkeiten müssen noch passend umgerechnet werden. Z.B. wird die Regenmenge laut Doku (https://www.tinkerforge.com/de/doc/Software/Bricklets/OutdoorWeather_Bricklet_Java.html) in 1/10 mm ausgegeben. Das bekommt OpenHAB natürlich nicht mit. Leider braucht man dafür wieder eine Rule oder JS Function ... wenn das das Binding selbstständig machen würde. 😉

Bisher habe ich die Wetterstation (oder alle Tinkerforge Sensoren) per MQTT angebunden. Die Werte umformatieren sowie die Werte umrechnen ist sehr aufwendig. Das liegt aber an meiner fehlenden Erfahrung und der sehr "lockeren" Doku über Variablentypen und Konversion von OH.

Dieses Binding macht das auf jeden Fall einfacher und übersichtlicher. Jede Rule weniger in OH ist toll!

Vielen Dank!

PS: Beim Text Item "OutdoorWeatherSensorLastChange" soll die Textfarbe gemäß der Zeit seit der letzten Aktualisierung gesetzt werden. Das Binding gibt diese Zeit aber als Zeitstempel und nicht in Sekunden seit der letzten Aktualisierung aus (wie es das Bricklet selber eigentlich laut BrickViewer tut.) Deswegen kann das so noch nicht funktionieren.

PS: Habe heute morgen OpenHAB neu gestartet. Nun flirrt diese Meldung durch die Logs, obwohl alles funktioniert ...

==> /var/log/openhab2/openhab.log <==

2020-02-21 09:42:17.959 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:17.966 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:18.961 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:18.967 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:19.962 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:19.969 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:20.963 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

2020-02-21 09:42:20.970 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.

 

bearbeitet February 21, 2020 at 08:48 von riro
Fehler bei LastChange beschrieben, Log eingefügt

[StefanOHAN]

Hallo Riro, (hallo Erik)

freut ich dass meine mini Anleitung geholfen hat 🙂

Ich selbst nutzte nur lieber Rules als .js 

Bezüglich Deiner Fehlermeldung, da müsstest Du Dich hier im Post an "Erik" wenden, er erstellt das Binding (ist ja noch in der BETA-Phase) . Er kann besser beurteilen ob diese WARN Meldung kritisch ist oder nicht.

Ich gehe da manchmal brute-force vor und lösche den Dämon und richtig Ihn wieder neu ein (nur aufpassen dass du Dir die alte Dämon - ID merkst, dass du diese beim neu Anlegen des Dämon eintragen kannst, sonst würden alle Deine LinkChannel nicht mehr funktionieren >> ID ist Bestandteil des Channel).

 

Viele Grüsse

 

Stefan

[rtrbt]

Moin,

@StefanOHAN

On 2/17/2020 at 8:09 AM, StefanOHAN said:

Ich habe jetzt die beiden TH-6148 und das Humidity 2.0 über die letzten Tage verschiedenen Temperaturen ausgesetzt (15 Messzeitpunkte).

Die Temperatur-Differenz ist nicht linear und ich kann keine kläre Linie erkennen. Der Unterschied liegt zwischen 0 und 1,5 Grad.

Hintergrund meiner Frage:

Ich berechne mit den Messwerten (Temperatur / relative Luftfeuchte) die absolute Luftfeuchte innen/außen und eine Rule steuert darüber das Lüftungsverhalten. In meiner Rule habe ich eine Messtoleranz (innen/außen Sensor) von 2,5% berücksichtigt.

Kannst Du sagen welche Sensoren-Typen genauer sind, ich vermute mal der Humidity 2.0, oder ?

Da würde ich mich eher auf die TH-6148 verlassen, zumindest wenn sie weniger messen als das Humidity. Temperatur-Messung ist überraschend schwierig und das Humidity hat prinzipiell ein Problem mit der Selbsterwärmung des Prozessors.

@riro

On 2/20/2020 at 4:41 PM, riro said:

Die Regenmenge und die Geschwindigkeiten müssen noch passend umgerechnet werden. Z.B. wird die Regenmenge laut Doku (https://www.tinkerforge.com/de/doc/Software/Bricklets/OutdoorWeather_Bricklet_Java.html) in 1/10 mm ausgegeben. Das bekommt OpenHAB natürlich nicht mit. Leider braucht man dafür wieder eine Rule oder JS Function ... wenn das das Binding selbstständig machen würde.

Verlass dich da mal nicht 100%ig auf die Java-Doku. Ich habe das für openHAB so gebaut, dass möglichst immer in der Basis-SI-Einheit ausgegeben wird, das vereinfacht die Generation der Bindings. Bei der Regenmenge ist das leider etwas unhandliche Meter. Du kannst in der Sitemap aber auch mit einem Transformation-Service umrechnen, vermutlich mit der JavaScript-Transformation, es sei denn dir reicht es, ein paar Intervalle auf jeweils einen Wert umzubiegen, dann tuts auch die Scale-Transformation.

On 2/20/2020 at 4:41 PM, riro said:

PS: Beim Text Item "OutdoorWeatherSensorLastChange" soll die Textfarbe gemäß der Zeit seit der letzten Aktualisierung gesetzt werden. Das Binding gibt diese Zeit aber als Zeitstempel und nicht in Sekunden seit der letzten Aktualisierung aus (wie es das Bricklet selber eigentlich laut BrickViewer tut.) Deswegen kann das so noch nicht funktionieren.

Das liegt daran, dass das Binding die Callbacks des Bricklets benutzt. LastChange ist dann der Zeitpunkt, wann auch immer das letzte Callback ankam. Ich überlege mir mal, ob ich ins Binding noch eine Möglichkeit einbaue, das als relative Zeit zu bekommen, aber ich fürchte, du musst dir mit einer Rule mit Time-Based-Trigger behelfen.

On 2/20/2020 at 4:41 PM, riro said:

PS: Habe heute morgen OpenHAB neu gestartet. Nun flirrt diese Meldung durch die Logs, obwohl alles funktioniert ...

Das ist nichts kritisches, du hast da noch einen alten Handler rumfliegen, der versucht die Station/Sensor-IDs zu aktualisieren, obwohl das entsprechende Thing gelöscht ist. Das ist ein Bug, der mit der nächsten Beta behoben sein sollte.

Gruß,
Erik

[Maxicko]

Am 17.2.2020 um 08:09 schrieb StefanOHAN:

Weiter mit meiner „Temperatur Mess-Differenz“ Problematik

Ich habe jetzt die beiden TH-6148 und das Humidity 2.0 über die letzten Tage verschiedenen Temperaturen ausgesetzt (15 Messzeitpunkte).

Die Temperatur-Differenz ist nicht linear und ich kann keine kläre Linie erkennen. Der Unterschied liegt zwischen 0 und 1,5 Grad.

Hintergrund meiner Frage:

Ich berechne mit den Messwerten (Temperatur / relative Luftfeuchte) die absolute Luftfeuchte innen/außen und eine Rule steuert darüber das Lüftungsverhalten. In meiner Rule habe ich eine Messtoleranz (innen/außen Sensor) von 2,5% berücksichtigt.

Kannst Du sagen welche Sensoren-Typen genauer sind, ich vermute mal der Humidity 2.0, oder ?

 

Viele Grüße

Stefan

 

Hi Stefan,

hab das Humidity 2 auch im Einsatz und leider das gleiche Problem. Ich verwende die Werte dennoch und rechne über eine rule die Werte nach unten.
Was mir inzwischen mehr Sorgen bereitet, sind die Werte des Air Quality Bricklet. Dort habe ich ebenfalls zu hohe Werte.
Wobei mich da mehr stört, dass der Luftdruck deutlich zu niedrig (60hPa Differenz) ausgegeben wird.

An der Stelle wollte ich allerdings vorsichtig fragen, ob du deine Berechnung zur absoluten Luftfeuchte hier als open-source preisgeben kannst, bzw. willst?
Bin grad an der gleichen Sache und es würde mir zumindest ein paar graue Haare ersparen...

Vielen Dank im Voraus und VG
Max

[StefanOHAN]

Hallo Maxicko,

ich will mich nicht mit fremden Federn schmücken, die Berechnung für die absolute Luftfeuchte habe ich im OpenHAB Forum gefunden.

Den Link selber hab ich nicht mehr, aber den Org Text. Diese Rule ist die Basis meiner Rule, ich hab sie nur noch um einige funktionen erweitert.

Zitat

import org.openhab.core.persistence.*
import org.openhab.core.library.*
import org.openhab.core.items.*
import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*
import org.joda.time.*
import java.lang.Math.*

rule "Luftfeuchte"
    when
     Item KG_Temp changed or
     Item KG_Feuchte changed or
     Item Netatmo_Outdoor_Temperature changed or
     Item Netatmo_Outdoor_Humidity changed or
     System started
   then
    // Variablen
    var Number temp_in = KG_Temp.state as DecimalType        //Innentemperatur in Grad Celsius
    var Number temp_out = Netatmo_Outdoor_Temperature.state as DecimalType                //Außentemperatur in Grad Celsius

    var Number abs_hum_in = 0
    var Number abs_hum_out = 0
    var Number td_in = 0
    var Number td_out = 0
    
    var Number rel_hum_in = KG_Feuchte.state as DecimalType            //relative Feuchte Innen
    var Number rel_hum_out = Netatmo_Outdoor_Humidity.state as DecimalType            //relative Feuchte Außen
    
        // Konstanten
    val gas_const = 8314.3
    val mol = 18.016
    var Number ab = 0
    var Number sdd = 0
    var Number dd = 0
    var Number v = 0
    var Number a_out = 0
    var Number b_out = 0
    
    // Parameter a, b
    // wenn T>=0: a = 7.5, b = 237.3 (dies wird wohl immer von den Innenraum zutreffen)
    // wenn T<0:  a = 7.6, b = 240.7 (dies kann für die Außerntemperatur zutreffen)

    val a_in=7.5
    val b_in=237.3        
    if (temp_out >= 0) {
        a_out=7.5
        b_out=237.3    
    } else {
        a_out=7.6
        b_out=240.7        
    }
    
    // Formeln
    // Sättingungsdampfdruck:    SDD = 6.1078 * 10^((a*temp)/(b+temp))
    // Dampfdruck:                DD = rel_hum * 100 / SDD
    // Absolute Feuchte:        AF = 10^5 * mol / gas_const * DD / (temp + 273.15)
    // Taupunkt:                TD = b*v/(a-v) mit v = log10(DD / 6.1078)
    
    // absolute Innenfeuchte
    ab = ((a_in * temp_in) / (b_in + temp_in)).doubleValue()
    sdd = 6.1078 * Math::pow(10, ((a_in * temp_in) / (b_in + temp_in)).doubleValue())
    dd = rel_hum_in / 100 * sdd
    v = Math::log10((dd/6.1078).doubleValue())
    abs_hum_in = Math::pow(10, 5) * mol / gas_const * dd / (temp_in + 273.15)
    
    // absolute Außenfeuchte
    ab = ((a_out * temp_out) / (b_out + temp_out)).doubleValue()
    sdd = 6.1078 * Math::pow(10, ((a_out * temp_out) / (b_out + temp_out)).doubleValue())
    dd = rel_hum_out / 100 * sdd
    v = Math::log10((dd/6.1078).doubleValue())
    abs_hum_out = Math::pow(10, 5) * mol / gas_const * dd / (temp_out + 273.15)

    logInfo("Luftfeuchte", "Abs. Luftfeuchte - in: " + abs_hum_in + " g/m3, out: " + abs_hum_out + " g/m3")

    if (abs_hum_in > abs_hum_out) // && (Kellerlueftung.state == OPEN) //wenn innen feuchter als außen, dann lüften
       
    {
     // lüften, Fenster öffnen
        logInfo("Luftfeuchte", "Keller lüften")
    //sendCommand(Kellerlueftung, CLOSED)
    postUpdate(Kellerlueftung,"CLOSED")
 
    } else if ((abs_hum_in <= abs_hum_out) // && (Kellerlueftung.state == CLOSED)
     {
        // nicht lüften, Fenster schließen
        logInfo("Luftfeuchte", "Kellerfenster schließen")
    // sendCommand(Kellerlueftung, OPEN)
    postUpdate(Kellerlueftung,"OPEN")    
    }

    
end

Sowohl sendCommand als auch postUpdate scheinen keine Änderung zu bewirken. Das Item habe ich so konfiguriert.

>> Achtung das Item Kellerlueftung muss in Contact sein !!!
>> Achtung normal müsste man noch den Luftdruck berücksichtigen, nachdem aber die Sensoren auf einer ähnlichen höhe montiert sind, kann dies vernachlässigt werden

das ganze war noch für openhab1, vermutlich kannst Du jetzt die meisten Imports weg lassen.

Um sicher zu gehen dass dies Berechnung korrekt ist, habe ich mit verschiedenen Temperatur und Luftfeuchte Werten über einen Website (die Berechnung der absoluten Luftfeuchte anbot) die Ergebnisse überprüft. Es waren nur vernachlässigbare Abweichungen fest zu stellen.

viele Grüsse

 

Stefan

[rtrbt]

Moin,

Beta 19 ist jetzt im Post oben. Größtes neues Feature ist, dass die bisher fehlenden Bricklets jetzt auch unterstützt werden. Die seriellen Schnittstellen und CAN-Bricklets haben jeweils einen Trigger-Channel, der benachrichtigt, dass neue Daten vorhanden sind, die dann mit einer Action abgeholt werden können. Das RS485-Bricklet kann außerdem als Modbus Master verwendet werden, dabei müssen im Gegensatz zur Java-API keine Callbacks benutzt werden, die Read/Write-Funktionen blockieren, bis ein Ergebnis vorhanden ist. Hier eine Beispiel-Rule dazu, die diesen Modbus-Stromzähler ausliest und die Werte auf einem LCD128x64 anzeigt.

import java.util.ArrayList

val readValue = [ Integer addr |
    val rs = getActions("tinkerforge", "tinkerforge:brickletrs485:RSS")
    val result = rs.brickletRS485ModbusMasterReadInputRegisters(1, addr, 2)
    val exceptionCode = result.get("exceptionCode") as int
    if (exceptionCode != 0) {
        return -1
    }
    val inputRegisters = result.get("inputRegisters") as int[]
    var upper = inputRegisters.get(0) as int
    val lower = inputRegisters.get(1) as int
    upper = upper << 16               
    upper = upper + lower
    return Float.intBitsToFloat(upper)    
]

rule "Show Power"
when
    Time cron "0/5 * * * * ?"
then
    val lcd = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HP7")
    val names = newArrayList('Total ', 'Import', 'Export', 'Total ', 'Import', 'Export')
    val units = newArrayList('W', 'W', 'W', 'kWh', 'kWh', 'kWh')
    val addrs = newArrayList(53, 1281, 1283, 343, 73, 75)
    val ArrayList<String> lines = newArrayList()
    lines.add(new String(""))

    for(var i = 0; i < 6; i++) {
        val value = readValue.apply(addrs.get(i))
        val line = "%s  %7.2f %s".format(names.get(i), value, units.get(i))
        if(i == 3)
            lines.add("")
        lines.add(line)        
    }
    lcd.brickletLCD128x64ClearDisplay()
    for(var i = 0; i < lines.length(); i++) {
       lcd.brickletLCD128x64WriteLine(i, 0, lines.get(i))
    }
    lcd.brickletLCD128x64DrawBufferedFrame(false)
end

 

Die NFC- und NFC-RFID-Bricklets werden jetzt auch unterstützt, allerdings nur mit der selben API wie auch die anderen Bindings. Das heißt, dass der Zustandsautomat zum Auslesen von Tags in Rules umgesetzt werden muss. Ich habe als Beispiel mal das jeweilige ScanForTags-Beispiel der Bricklets portiert. Als Trigger wird hier noch ein Druck auf einen RGB-LED-Button verwendet (einmal, danach scannt die Regel permanent). Da könnte man alternativ sinnvollerweise darauf reagieren, dass das NFC(-RFID)-Bricklet online kommt.

NFC-RFID:

import java.util.List;
import java.util.stream.Collectors;

rule "NFC"
when
    Item UnX_State changed or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered "PRESSED"
then
    val stateVal = UnX_State.state as Number
    val int state = stateVal.intValue

    val nfc = getActions("tinkerforge", "tinkerforge:brickletnfcrfid:unX")
    val rgb = getActions("tinkerforge", "tinkerforge:brickletrgbledbutton:Enx")

    if (state == 128) { //Idle
        rgb.brickletRGBLEDButtonSetColor(255, 127, 0)
        nfc.brickletNFCRFIDRequestTagID(2)
    } else if (state == 194) { //Error (typically no tag found)
        rgb.brickletRGBLEDButtonSetColor(255, 0, 0)
        nfc.brickletNFCRFIDRequestTagID(2 as short)
    } else if (state == 130) { //Tag ID Ready
        logInfo("NFC", "tag id ready")
        val ret = nfc.brickletNFCRFIDGetTagID()
        val tagType = ret.get("tagType")
        val tagID = ret.get("tid") as List<Short>
        val tagLength = ret.get("tidLength")
        val tag = String.join(" ", tagID.stream().limit(tagLength).map([i | String.format("0x%02X", i)]).collect(Collectors.toList()));
        logInfo("NFC", "tag id:" + tag)
        rgb.brickletRGBLEDButtonSetColor(0, 255, 0)
        createTimer(now.plusSeconds(1), [|nfc.brickletNFCRFIDRequestTagID(2 as short)])
    }
end

und NFC:

import java.util.List;
import java.util.stream.Collectors;


rule "NFC"
when
    Item HoG_State changed or Channel "tinkerforge:brickletrgbledbutton:Enx:BrickletRGBLEDButtonButton" triggered "PRESSED"
then
    val stateVal = newState as Number
    val int state = stateVal.intValue

    val nfc = getActions("tinkerforge", "tinkerforge:brickletnfc:HoG")
    val rgb = getActions("tinkerforge", "tinkerforge:brickletrgbledbutton:Enx")

    if (state == 128) {
        rgb.brickletRGBLEDButtonSetColor(255, 127, 0)
        nfc.brickletNFCReaderRequestTagID()
    } else if (state == 194) {
        rgb.brickletRGBLEDButtonSetColor(255, 0, 0)
        nfc.brickletNFCReaderRequestTagID()
    } else if (state == 130) {
        logInfo("NFC", "tag id ready")
        val ret = nfc.brickletNFCReaderGetTagID()
        val tagType = ret.get("tagType")
        val tagID = ret.get("tagID") as List<Integer>
        val tag = String.join(" ", tagID.stream().map([i | String.format("0x%02X", i)]).collect(Collectors.toList()));
        logInfo("NFC", "tag id:" + tag)
        rgb.brickletRGBLEDButtonSetColor(0, 255, 0)
        createTimer(now.plusSeconds(1), [|nfc.brickletNFCReaderRequestTagID()])
    }
end

 

Die Bindings benutzen jetzt außerdem wieder das ältere Java-Typ-Schema für alte Bricklets. Die Umsetzung des neuen Schemas (das alle Integers kleiner 32 Bit auf int mappt) war nur unvollständig und hat die Generierung verkompliziert. Außerdem ist so die Java-Dokumentation hilfreicher. Nachteil ist, dass in den Rules immer mal unoffensichtlich nach short gecastet werden muss, wie z.b. bei der NFC-RFID-Rule.

Gruß,
Erik

[Maxicko]

Am 20.1.2020 um 16:25 schrieb rtrbt:

Das heißt, dass die Keys "x", "y", "pressure" und "age" sind. Du könntest dann z.B. sowas hier bauen:

rule "test"
when
    Channel "tinkerforge:brickletlcd128x64:6c8d2c7d:HQ6:BrickletLCD128x64TouchPosition" triggered
then
    val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:6c8d2c7d:HQ6")
    val touchPos = lcdActions128x64.brickletLCD128x64GetTouchPosition()
    val x = touchPos.get("x") as Integer
    val y = touchPos.get("y") as Integer
    val pressure = touchPos.get("pressure") as Integer
    val age = touchPos.get("age") as Integer

    if (x < 64 && y < 32) {
        logInfo("test", "oben links")
    } else if (x < 64 && y >= 32) {
        logInfo("test", "unten links")
    } else if (x >= 64 && y < 32) {
        logInfo("test", "oben rechts")
    } else {
        logInfo("test", "unten rechts")
    }
end

Die Regel gibt aus, ob in welchem Viertel des Displays eine Berührung war.

Hi Erik,

versuch das gerade mit TouchGesture und stelle mich vermutlich etwas zu blöd an...

when
                Channel "tinkerforge:brickletlcd128x64:KYL:BrickletLCD128x64TouchGesture" triggered
        then
                val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:ac8b6ac8:KYL")
                val TouchGesture = lcdActions128x64.brickletLCD128x64GetTouchGesture()
                val Gesture1 = TouchGesture.get("gesture") as Integer

                if (Gesture1 = 0) {
                        if (Display1_Page.state > 1) {
                                Display1_Page.postUpdate(Display1_Page.state - 1) }
                        }
                if (Gesture1 = 1) {
                        if (Display1_Page.state < 5) {
                                Display1_Page.postUpdate(Display1_Page.state + 1) }
                        }
end

Bei jedem Wisch auf dem Display wird "Instance is not an BrickletLCD128x64Actions class." geloggt.
Leider habe ich dazu nicht viel gefunden und hoffe hier einen Tipp zu bekommen.

Vielen Dank und Gruß

Max

 

[rtrbt]

Moin,

Du läufst da gerade in diesen Bug. Wenn du openHAB neustartest, nachdem du das Binding aktualisiert und eine Weile gewartet hast, damit openHAB die neue Version einmal geladen hat, sollte das Problem nicht mehr auftreten.

[StefanOHAN]

Hallo Max

jetzt mal unabhängig von Eriks Hinweis bezüglich des Restart.

Kann es sein, dass Du noch mit einem alten Binding arbeitest ?

Wenn ich das richtig sehe enthält Dein Channel noch die ID des TF-Dämons. Erik hat in den verschiedenen Bindings das System ein paar mal umgebaut, mal waren die „Dämon-ID‘s“ Bestandteil des Channel, mal nicht. In den letzten Bindings ist die Dämon-ID nicht mehr Bestandteil des Channel. Dieser Umbau hat zur Folge dass Du Deine Channel-Verlinkung der Item‘s und auch die Rule‘s mit Channel Trigger auf die neue Schreibweise anpassen musst.

 

Welche Binding Version hast Du ?

 

Dein Aufruf (siehe markiert, Deine Dämon-ID )

Zitat

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:ac8b6ac8:KYL")

Mein Aufruf (gilt für Binding Beta18/19)

Zitat

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQJ")

 

viele Grüße Stefan

bearbeitet March 1, 2020 at 11:21 von StefanOHAN

[StefanOHAN]

Hallo Erik,

wow ich war ganz erstaunt als ich sah, dass Du auch am Sonntag die Forum-Einträge liest. Alle Achtung

Beim Update auf Beta 19 hatte ich für ein Bricklet einen Fehler die ich nicht beheben konnte.

Alle Bricklets bis auf ein „altes“ IO-16 (HW Version 1.1.0 /FW Version 2.0.3 ) gingen wieder online. Um einen Fehler auszuschließen, habe ich anschließend alle Things inklusive der Tinkerforge Dämons deinstalliert und anschließend das System neu gestartet. Auch dann konnte ich das IO-16 nicht online nehmen. Es erschien im Log immer folgende Fehlermeldung

 

Zitat

2020-02-29 15:33:36.077 [DEBUG] [forge.internal.handler.DeviceHandler] - Initializing wip

2020-02-29 15:33:36.078 [DEBUG] [forge.internal.handler.DeviceHandler] - Removing old manual update handler for wip

2020-02-29 15:33:36.357 [DEBUG] [forge.internal.handler.DeviceHandler] - Failed to initialize wip: Got invalid parameter for function ID 15

2020-02-29 15:33:36.359 [TRACE] [.internal.handler.BrickDaemonHandler] - Timeout for device tinkerforge:brickletio16:wip

2020-02-29 15:33:36.360 [DEBUG] [forge.internal.handler.DeviceHandler] - Checking reachability of wip

2020-02-29 15:33:36.368 [DEBUG] [forge.internal.handler.DeviceHandler] - wip is not in bootloader mode.

2020-02-29 15:33:36.369 [DEBUG] [forge.internal.handler.DeviceHandler] - Done checking reachability of wip

2020-02-29 15:33:36.370 [DEBUG] [forge.internal.handler.DeviceHandler] - wip was not already online. Reinitializing

Erst nach einem Restart von Openhab konnte ich das IO-16 aus der Konfiguration entfernen.

Das IO-16 2.0 und das IO-4 2.0 ließen sich ohne Probleme online nehmen.

Weiter ist mir aufgefallen, das sich bei der Port Konfiguration des IO-16 / IO-4 (HW 2.0) die Darstellung fehlerhaft ist.

Immer wenn ich auswähle „output (Initial low)“ und dies speichere, erscheint bei erneutem Aufruf der Port Konfiguration der Text „Add or search“. In der Übersicht des IO-16 Thing wird angezeigt dass der Port als Output Konfiguriert ist, aber mit Status Low / High

Es ist auch egal ob ich über Firefox oder Chrome das versuche. (siehe auch Bild im Anhang)

 

Weiter Frage: Hast Du die Online/Offline Meldungen der Things / Dämon usw verändert ?

Ich habe mir eine Rule gebaut, die das off und online gehen der beiden „Dämon‘s“ (WIFI & USB/HAT) überwacht.

Offline Meldungen kommt für Things & Dämon, jedoch sehe ich im Log nur noch die „changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE“ Meldung für die Things (Bricklets) aber nicht mehr für den Dämon. Somit funzt meinen Rule zur Überwachung der Dämons nicht mehr.

(Übrigens seit Deinem Beta18 Update hatte ich keine „Ungeplanten“ Dämon Aussetzer mehr)

 

Bis jetzt sind keine weiteren Fehler bei „alten“ Rule‘s / Things aufgefallen.

 

Weiter mit dem Test des Tinkerforge NFC Bricklet (HW Version 1.0.0 / Modell-ID 286 / FW Version 2.0.1)

Das Auslesen der TAG-ID hat beim zweiten Anlauf funktioniert.

Nachdem ich nicht so ein JAVA Fachman bin, verstehe ich nicht so ganz was die beiden Zeilen

Zitat

 

val stateVal = newState as Number

val int state = stateVal.intValue

 

in Deinem Beispiel bedeuten.

Sie haben bei mir einen Fehler im Log verursacht.

 

Zitat

2020-03-01 10:49:02.019 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'lese TAG': The name 'newState' cannot be resolved to an item or type; line 9, column 20, length 8

 

Nachdem ich für den NFC-Status aber ein „Number-Item“ mit dem entsprechenden Channel verlinkt habe, habe ich Deine Rule auf diese „Item-Status-Abfrage“ umgebaut und die Rule hat funktioniert.

Frage: Was ist die Aufgabe des „newState“ value ?

Ich sehe schon um das NFC optimal nutzen zu können, müsste ich tiefere JAVA Kenntnisse haben, denn Deine Zeilen aus der Beispiel Rule

 

Zitat

 

        val tagID = ret.get("tagID") as List<Integer>

        val tag = String.join(" ", tagID.stream().map([i | String.format("0x%02X", i)]).collect(Collectors.toList()));

 

 

sind für mich schon fast „grosses JAVA Kino“ 😉 

 

Bis auf ein paar ältere 10-polige V1 Bricklets (Humidity / Temperatur / Industrial Quad Relais / Dual-Relais /PTC ) die noch in meiner Produktiv Umgebung verbaut sind, habe ich alle mir zur Verfügung stehenden Brickles in meine Test eingebunden. Ich hoffe diese alten Bricklets auch mit dem neuen Binding funktionieren, dies sehe ich aber erst wenn ich die Prod Umgebung von Openhab 1.9 auf 2.x umstelle.

 

Ich würde noch zwei weiter Bricklets testen, aber beide sind leider nicht über Euren Shop verfügbar

a) das neue „Servo-Brick“ dass sich noch in Entwicklung befindet (wird es auch vom Binding unterstützt ?)

b) das PTC-Bricklet 2.0 (ist aktuell nicht verfügbar)

 

Was mir Echt gut gefällt ist, Euer Dual-Button-Bricklet 2.0

Frage: Gibt es eine passende „Taster-Abdeckung“?

Wenn man diese in ein Paneel einbaut, wäre es viel schöner wenn man eine Abdeckung dafür hätte.

Ich werde noch weiter an den Rule‘s Testen und berichten.

Viele Grüße

Stefan

 

P.S.

Ich weiß ich werde mir jetzt den Unmut vieler Openhab 2.x User zuziehen, aber bei großen Umgebung finde ich die alte, über einen Thing-Datei Konfiguration, übersichtlicher. Welche Negativen Auswirkungen hätte die Nutzung einer "Thing" Konfiguration's Datei anstelle der GUI  ?

Wird es auch mal eine Anleitung geben, wie ich diese Tinkerforge  Thing‘s Datei anlegen müsste ?

bearbeitet March 1, 2020 at 11:17 von StefanOHAN

[Maxicko]

vor 10 Stunden schrieb StefanOHAN:

Hallo Max

jetzt mal unabhängig von Eriks Hinweis bezüglich des Restart.

Kann es sein, dass Du noch mit einem alten Binding arbeitest ?

Wenn ich das richtig sehe enthält Dein Channel noch die ID des TF-Dämons. Erik hat in den verschiedenen Bindings das System ein paar mal umgebaut, mal waren die „Dämon-ID‘s“ Bestandteil des Channel, mal nicht. In den letzten Bindings ist die Dämon-ID nicht mehr Bestandteil des Channel. Dieser Umbau hat zur Folge dass Du Deine Channel-Verlinkung der Item‘s und auch die Rule‘s mit Channel Trigger auf die neue Schreibweise anpassen musst.

 

Welche Binding Version hast Du ?

Hi Stefan,

bin auf Binding-Version 18. Dein Tipp war der Richtige.
Ohne Daemon-ID geht es nun. Aber an der Stelle muss ich erwähnen, dass das mit derDaemon-ID so in der Readme zu Binding18 steht.
Bekomme im Log noch die Meldung:

The method brickletLCD128x64GetTouchGesture(ThingActions) from the type BrickletLCD128x64Actions refers to the missing type Object

Scheint aber dennoch zu funktionieren.

Vielen Dank für die schnelle Hilfe!

VG
Max

[rtrbt]

Moin,

20 hours ago, StefanOHAN said:

wow ich war ganz erstaunt als ich sah, dass Du auch am Sonntag die Forum-Einträge liest. Alle Achtung

Ja, da ist beim einen neuen Tab aufmachen das von Arbeit trainierte Muskelgedächtnis mit mir durchgegangen

21 hours ago, StefanOHAN said:

Alle Bricklets bis auf ein „altes“ IO-16 (HW Version 1.1.0 /FW Version 2.0.3 ) gingen wieder online. Um einen Fehler auszuschließen, habe ich anschließend alle Things inklusive der Tinkerforge Dämons deinstalliert und anschließend das System neu gestartet. Auch dann konnte ich das IO-16 nicht online nehmen.

Das habe ich mir gerade mal angesehen, da gab es noch einen Konfigurationsfehler, ist behoben, kommt in die nächste Beta. Der seltsamen Anzeige der Konfiguration muss ich mal noch nachgehen, das konnte ich hier gerade reproduzieren.

 

21 hours ago, StefanOHAN said:

Hast Du die Online/Offline Meldungen der Things / Dämon usw verändert ?

Die Meldungen nicht, nur wann ich einen Daemon als offline betrachte. Das sollte aber nicht die Nachrichten verschlucken, dass er wieder online geht. Sehe ich mir mal an. Frage dazu: Hast du, wenn du die "changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE"-Meldungen siehst davor die Ausgabe "Bridge of [UID] went online"? (Wenn du das DEBUG-Log an hast)

 

21 hours ago, StefanOHAN said:

Nachdem ich nicht so ein JAVA Fachman bin, verstehe ich nicht so ganz was die beiden Zeilen

Quote

 

val stateVal = newState as Number

val int state = stateVal.intValue

 

in Deinem Beispiel bedeuten.

Das ist openHAB-Magie: Wenn man als Trigger auf den geänderten Zustand eines Items wartet, dann ist newState eine implizit definierte Variable, die man einfach benutzen kann. Das ist hier dokumentiert. Du kannst stattdessen auch [Itemname].state verwenden, dann sollte es funktionieren.

21 hours ago, StefanOHAN said:

Ich sehe schon um das NFC optimal nutzen zu können, müsste ich tiefere JAVA Kenntnisse haben, denn Deine Zeilen aus der Beispiel Rule

 

Quote

 

        val tagID = ret.get("tagID") as List<Integer>

        val tag = String.join(" ", tagID.stream().map([i | String.format("0x%02X", i)]).collect(Collectors.toList()));

 

 

sind für mich schon fast „grosses JAVA Kino“ 😉 

Da benutze ich die Java-8-Streams. tagID ist eine Liste von Integer (eigentlich von Bytes, aber Java kann keine vorzeichenlosen Bytes), String.join klebt eine Liste von Strings mit dem ersten Parameter als Trenner (hier einfach ein Leerzeichen) zusammen. Der zweite Parameter ist die Umwandlung von der Integer-Liste in eine Liste von Strings, die jeweils 0x und dann zwei Hexadezimalziffern sind. Das hätte man auch als Schleife schreiben können, aber da die Rules so schlecht im Herleiten von Typen für Variablen (für Schleifenzähler usw) sind, deshalb die ganzen Casts, wie auch das "as List<Integer>", sonst versteht openHAB nicht, welchen Typ tagID hat, habe ich da lieber einen Stream genommen.

22 hours ago, StefanOHAN said:

Bis auf ein paar ältere 10-polige V1 Bricklets (Humidity / Temperatur / Industrial Quad Relais / Dual-Relais /PTC ) die noch in meiner Produktiv Umgebung verbaut sind, habe ich alle mir zur Verfügung stehenden Brickles in meine Test eingebunden. Ich hoffe diese alten Bricklets auch mit dem neuen Binding funktionieren, dies sehe ich aber erst wenn ich die Prod Umgebung von Openhab 1.9 auf 2.x umstelle.

Die sollten alle funktionieren.

 

22 hours ago, StefanOHAN said:

Ich würde noch zwei weiter Bricklets testen, aber beide sind leider nicht über Euren Shop verfügbar

a) das neue „Servo-Brick“ dass sich noch in Entwicklung befindet (wird es auch vom Binding unterstützt ?)

b) das PTC-Bricklet 2.0 (ist aktuell nicht verfügbar)

a) Wird unterstützt werden, da sind wir aber noch in der Prototypenphase.
b) Die sollte es bald wieder geben, sind schon produziert.

22 hours ago, StefanOHAN said:

Ich weiß ich werde mir jetzt den Unmut vieler Openhab 2.x User zuziehen, aber bei großen Umgebung finde ich die alte, über einen Thing-Datei Konfiguration, übersichtlicher. Welche Negativen Auswirkungen hätte die Nutzung einer "Thing" Konfiguration's Datei anstelle der GUI  ?

Wird es auch mal eine Anleitung geben, wie ich diese Tinkerforge  Thing‘s Datei anlegen müsste ?

Das habe ich selbst noch nicht probiert, sollte aber eigentlich funktionieren. Wenn ich die Dokumentation überarbeite, schreibe ich eventuell eine Anleitung.

 

12 hours ago, Maxicko said:

Aber an der Stelle muss ich erwähnen, dass das mit derDaemon-ID so in der Readme zu Binding18 steht.

Hm, stimmt, das behebe ich mal.

Danke für das Feedback!
Erik

[Teddy]

vor 22 Stunden schrieb StefanOHAN:

Was mir Echt gut gefällt ist, Euer Dual-Button-Bricklet 2.0

Frage: Gibt es eine passende „Taster-Abdeckung“?

Wenn man diese in ein Paneel einbaut, wäre es viel schöner wenn man eine Abdeckung dafür hätte.

Hi Stefan,

eine out-off-the-box Abdeckung gibt es leider nicht kaufen oder zumindest haben wir noch keine gefunden. Ich habe allerdings mir mal was mit dem 3D Drucker gebaut.Das war allerdings ein ganzes Gehäuse mit Tastereinsetzen. Wenn du mir beschreibst oder irgendwie zeigst wie du dir so einen Einbau in dein Panel vorstellst kann ich das Model vielliecht abändern und auch für dich drucken falls du keinen Drucker hast. 

 

Grüße Tim

bearbeitet March 2, 2020 at 09:50 von Teddy