StefanOHAN
-
Gesamte Inhalte
189 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
7
Posts erstellt von 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
-
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
ZitatString 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.
ZitatNumber 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
-
1
-
1
-
-
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
-
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
-
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
-
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
Zitat2020-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:
Zitatrule "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
Zitatval 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 ONLINEDas 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
-
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.
ZitatRule '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.
-
Hallo Erik,
anbei die Konfiguration (ist analog der Brickviewer Ansicht).
Ich hoffe dass man erkennen kann dass der zweite Masterbrick über RS485 Extention mit dem ersten Masterbrick verbunden ist.
Brick-Dämon1 , direkt am Raspberry Pi angeschlossen Position FW HW Modell-ID HAT-Brick Raspi GPIO 2.0.1 1.0.0 111.0 LCD128x64 A 2.0.7 1.0.0 298.0 Multi Touch 2.0 B 2.0.0 1.0.0 2129.0 Motion Detector 2.0 C 2.0.2 1.0.0 292.0 Rotary Encoder 2.0 D 2.0.4 1.0.0 294.0 Humidity Brickelt 2.0 E 2.0.6 1.0.0 283.0 Frei F Rotary Poti 2.0 G 2.0.0 1.0.0 2140.0 Outdoor Weather H 2.0.4 1.0.0 288.0 Master Brick 2.1 Per USB 0 2 . 4 . 10 2.1.0 13.0 IO-16 A 2.0.6 1.1.0 28.0 IO-4 B 2.0.4 1.0.0 2111.0 LCD20x4 Bricklet 1.2 C 2.0.6 1.2.0 212.0 Frei D Master Brick 2.1 per RS485 verbunden 0 2 . 4 . 10 2.1.0 13.0 IO-16 2.0 A 2.0.2 1.0.0 2114.0 IO-16 B 2.0.6 1.1.0 28.0 Indust Quad Relay 2.0 C 2.0.3 1.0.0 2102.0 Indust Quad Relay 2.0 D 2.0.3 1.0.0 2102.0 RS485 Extention (Slave) Ext0 im Stapel des MB RS485 Extention (Master) Ext0 Brick-Dämon-2 / per WLAN über AVM mit Raspberry verbunden Position FW HW Modell-ID Master Brick 2.1 0 2 . 4 . 10 1.0.0 2145.0 Piezo Speaker 2.0 A 2.0.2 1.0.0 284.0 Indust Dual Relay B 2.0.3 284.0 2.0.3 E-Paper 296x128 C 2.0.1 1.0.0 2146.0 Indust Digital In-4 2.0 D 2.0.2 1.0.0 2100.0 WIFI Extentision 2.0 Ext0 Aktuell noch nicht ist das NFC und der Remote-Switch Bricklet angeschlossen
Sollte die Konfiguration nicht lesbar/verständlich sein, sag bitte bescheit, dann werde ich einen Screenshot des Brickviewer posten.
viele Grüsse
Stefan
P.S. hatte gestern/heute morgen 3 mal den Reconnect
-
Hallo Erik,
nur ganz kurz.
Ja beim Aufbau meinte ich, dass auf meinem Raspberry Pi das HAT-Brick aufgesteckt ist und ein Masterbrick über den USB-Port mit dem gleichen Raspberry verbunden ist (eigentlich sind es zwei Masterbrick da über eine RS485 Extention ein weiter Masterbrick im Verbund ist).
Ich versuche heute Abend mal einen Snapshot aus dem Brickviewer zu machen da dürfte man schön sehen was alles angebunden ist.
Du schreibst
ZitatBezüglich der Ausfälle: Ich vermute, dass das Binding da noch zu aggressiv ist
Frage: Hast du in den letzten Bindings die "aggressivität" der Überwachung verändert ?
viele Grüsse
Stefan
-
Hallo Erik
heute Abend (3.2.2020) habe ich wie von dir empfohlen über die Karaf-Konsole den erweiterten Log aktiviert.
Zitat„log:set TRACE org.eclipse.smarthome.binding.tinkerforge“
Eine parallel Überprüfung der „Logs“ nach Error und Brickmaster, zeigten keine verdächtigen Einträge.
Ich habe mir noch mal überlegt was ich in den letzten Tagen alles geändert haben.
Die Hardware Konfiguration der über UBS/HAT angeschlossenen Masterbricks / Bricklets hat sich seit Anfang November nicht geändert. Erstmals aufgefallen ist mir das offline gehen des Dämon ab dem Binding 16.
Mal schau‘n was der Trace für Ergebnisse bringt.
Thema EdgeCount per Channel Link
Danke für den Hinweis, wenn ich in der Rule vorher einen REFRESH auf das ITEM des verlinkten EdgeCount ausführe, kommt ein Ergebnis.
ZitatNumber P0Countg7y "Pin0 IO4 Counter IO4-V2 [%s]" (TestTF){ channel="tinkerforge:brickletio4v2:G7y:BrickletIO4V2EdgeCountPin0"}
>>
P0Countg7y.sendCommand(REFRESH)
Beim EdgeCount Test ist mir zufällig folgende DEBUG-Meldung aufgefallen, die immer erscheint wenn ich einen der BUIButton des LCD128x64 betätigte.
Hat dies einen Bedeutung ? (die Rule funktioniert auf jedem Fall)
Zitat2020-02-03 20:04:06.957 [DEBUG] [ernal.TinkerforgeChannelTypeProvider] - Could not find device info for channelTypeUID system:rawbutton: null.
Ansonsten lief das System tagsüber ohne Störung
Erste Error Meldungen ab 20:33Uhr
Meldungen aus dem Log
Zitat2020-02-03 20:33:41.423 [DEBUG] [forge.internal.handler.DeviceHandler] - Failed checking reachability of 6kMKrA: Did not receive response in time for function ID -1
2020-02-03 20:33:41.434 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6kMKrA' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable. 2020-02-03 20:35:38.854 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6kMKrA' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)
020-02-03 20:36:46.009 - 'tinkerforge:brickmaster:6kMKrA' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
von 20:32Uhr bis 20:40Uhr kamen mehrfach diese Meldungen, leider konnte ich keine weiteren Kommentare im Log finden, die etwas aufschlussreicher gewesen wären. Die restliche Nacht lief alles ohne Ausfall.
Heute morgen das gleich Spiel erst geht die Bridge kurz offline und dann wieder online, und nach einigen Minuten ein längere Ausfall der soweit führte, dass sich die Background Light des LCD128x64 und LCD20x4 einschlaten (ohne dass eine Rule auf die Displays neue werte schreiben)
Die relevanten teile der Logfile Auszuge hänge ich als txt Datei an (ich hoffe er ist lesbar), leider ist er nicht besonder aussagekräftig
Es ist immer nur der Dämon betroffen der für das HAT-Brick und den per USB angeschlossenen Masterbrick zuständig ist.
Kann es sein dass die Kombination
Raspi -> USB->Masterbrick1->RS485->Masterbrick2
Raspi -> HAT-Brick
Probleme bereiten kann ? Diese Konfiguration läuft aber schon mindestens 3-4 Monate.
Der Masterbrick der per WIFI-Extention angebunden ist, ist nicht betroffen.
Benötigst Du einen Detail Info zur Konfiguration ? Haben Masterbrick / HAT-Brick logfile die nutzbar wären ?
Macht es Sinn zu testen ob mit einer älteren Binding Version ähnliche Fehler auftauchen ?
viele Grüsse
Stefan
-
Hallo Erik
kurzer Update zu meinem Test von Gestern, heute Morgen (3.2.2020, ab 5:23Uhr) ging wieder kurzfristig die Verbindung zu den per USB Angeschlossenen Masterbrick‘s & dem HAT verloren. (die Dämon‘s habe ich nach dem einspielen des Beta 17 neue eingerichtet). Die beiden Masterbrick sind per RS485-Extention miteinander verbunden (ist aber seit Beginn der Testreihen so). Der Dämon der für das WIFI angebundene Masterbrick zuständig ist, ist nicht ausgefallen.
Zitat2020-02-03 05:23:23.104 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.
2020-02-03 05:23:23.122 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.
2020-02-03 05:23:30.630 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.
2020-02-03 05:24:23.140 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)
2020-02-03 05:24:23.270 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)
2020-02-03 05:24:23.250 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)
2020-02-03 05:24:23.380 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-02-03 05:24:23.411 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-02-03 05:24:24.238 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
Im Log konnte ich keine weiteren Ausfälle feststellen, allerdings läuft das System erst ca 20 Stunden ohne einen Reboot.
Ich werde heute Abend in jede Rule eine Event-loginfo Meldung einbauen, dann sehe ich ja ob es öfters vorkommt.
Diese Mal haben keine Rules die per Channel Trigger angesteuert werden reagiert, allerdings haben sich die Background Beleuchtung des LCD 128x64 & LCD 20x4 eingeschaltet.
Kannst Du das mit dem Connetion Lost bitte nochmal checken ?
Viele Grüße
Stefan
@omiT
das mit dem Blinken der LED kann ich nicht beantworten, hier ist Erik der Spezialist
-
Hallo Erik
für das Beta 17 habe ich alles zurück gesetzt, alle Things entfernt, alle Dämon‘s gelöscht, das alte Binding über Console entfernt, sowie einen Update meines Openhabian-System ausgeführt.
Beim StartUp des System mit dem neuen Binding ist mir folgende Meldung aufgefallen
Zitat2020-02-01 16:07:55.220 [INFO ] [ernal.TinkerforgeChannelTypeProvider] - Failed to download latest versions: null
Frage: ist das eine Funktion die noch nicht aktiv ist ? Oder welche Aufgabe hat diese ?
Bis jetzt funktionieren alle meine Test-Rules (zumindest konnte ich keine Error-Meldungen im Log finden).
Einzig für EdgeCount der „per Channel mit einem Item“ verlinkt ist, bekomme ich noch immer 0 als Ergebnis, kann aber daran liegen dass ich diesen evlt. falsch nutze.
Der EdgeCount den ich über die Action aufrufe, hat für das „IO-16 Bricklet V1“ , „IO-16 Bricklet 2.0“ , „IO-4 Bricklet 2.0“ und „Industrial Digital In 4 Bricklet 2.0“ einwandfrei funktioniert.
(Wie von Dir empfohlen hab ich für das „IO-16 Bricklet V1“ von „short“ auf „int“ umgestellt)
Einen komischen Effekt habe ich beim „Multi Touch Bricklet 2.0“ (mit der alten V1 Version habe ich es nicht getestet), egal welche Elektroden-Taste ich berühre, es kommt immer für alle (die nicht berührt wurden) Elektroden die Meldung „triggered RELEASED. Ist das so gewollt ? (ich verwende Euer Key-Pad 3x4)
Zitat2020-02-01 21:06:13.636 [vent.ChannelTriggeredEvent] - tinkerforge:brickletmultitouchv2:KyQ:BrickletMultiTouchV2Electrode0 triggered RELEASED
Frage: Meinst Du es würde zu viel Last verursachen wenn ich die für das IO-16 / IO-4 den „Update Interval“ von 1000ms auf 250ms verkürze ? Wenn ich diese als Input für angeschlossene „Taster“ zum Lichtschalten verwende sind 1000ms etwas lange. Ich würde maximal dies für 2 x IO-16 anwenden.
ausgeführte Test‘s siehe unten
viele Grüße Stefan
PS: werde heute das Isolator / Remote Switch / Energy Monitor / Dual-Button Bricklets für weiter Test bestellen
Test 2 Februar 2020 System Raspberry Pi 3 Model B Rev 1.2 OS-Version Linux OPENHABBIANPI3 4.19.93-v7 OpenHAB Version openHAB 2.5.1-2 Tinkerforge-Binding B17 technische Daten Brick / Bricklets ausgeführte Test‘s Typ HW
VersionModell
IDFW
VersionItem
Channel-VerlinkungRule über
Item TriggerRule über
Channel TriggerAction in Rule E-Paper 296x128 1.0.0 2146.0 2.0.1 ok nicht getestet nicht getestet FillDisplay / DrawText Multi Touch2.0 1.0.0 2129.0 2.0.0 ok ok ok nicht getestet Rotary Poti 2.0 1.0.0 2140.0 2.0.0 ok ok nicht getestet nicht getestet Rotary Encoder 2.0 1.0.0 294.0 2.0.4 ok ok nicht getestet nicht getestet Humidity 2.0 1.0.0 283.0 2.0.6 ok ok nicht getestet nicht getestet Outdoor Weather Bricklet 1.0.0 288.0 2.0.4 ok (mit 2 x TH6148) ok nicht getestet nicht getestet Motion Detector 2.0 1.0.0 292.0 2.0.2 ok ok ok nicht getestet LCD 128x64 1.0.0 298.0 2.0.7 ok ok TouchGesture DrawText / SetGUITabText /
SetGUIButton / SetGUISlider /
SetGUITabSelected /
RemoveGUITab /
RemoveGUIButton /
RemoveGUISlider /
RemoveAllGUI / ClearDisplay /
GetTouchPositionLCD 20x4 1.2.0 212.0 2.0.6 ok ok ok ClearDisplay Industrial Dual Relay 1.0.0 284.0 2.0.3 ok ok nicht getestet nicht getestet Industrial Quad Relay 2.0 1.0.0 2102.0 2.0.3 ok ok nicht getestet nicht getestet Digital In 4 (2.0) 1.0.0 2100.0 2.0.2 ok ok nicht getestet getEdgeCount IO-16 Bricklet 1.1.0 28.0 2.0.6 ok ok nicht getestet getEdgeCount IO-16 Bricklet 2.0 1.0.0 2114.0 2.0.2 ok ok nicht getestet getEdgeCount IO-4 V2 1.0.0 2111.0 2.0.4 ok ok nicht getestet getEdgeCount Piezo Speaker 2.0 1.0.0 2145.0 2.0.2 ok ok nicht getestet SetAlarm / GetAlarm /
SetBeep / GetBeep /
UpdateFrequency /
UpdateVolumeTinkerforge HAT Brick 1.0.0 111.0 2.0.1 nicht getestet nicht getestet nicht getestet nicht getestet Tinkerforge Master Brick 2.1.0 13.0 2.4.10 nicht getestet nicht getestet nicht getestet nicht getestet -
Hallo Erik
danke für das Feedback
Eine kleine Unschärfe ist mich noch aufgefallen (nichts schlimmes)
Für „Dual Relay V2“ kann ich die Status-LED nicht abschalten (paperui / Configuration / Things ) umschalten auf Heartbeat geht, nur das ausschalten nicht.
Beim Stöbern in Eurem Shop ist mir das „Isolator-Bricklet“ aufgefallen und ich stellte mir die Frage ob ich es etwas zweckentfremden kann.
Frage:
1) funktionieren mit Deinem Binding Bricklets, die über das Isolatro-Bricklet angeschlossen sind ?
2) lassen sich nur die Bricklets an das IsolatorBricklet anschließen die als Beispiel in Euer Doku genannt werden , oder können generell alle Bricklets (7-polige V2-Versionen) angeschlossen werden ?
3) gibt es eine Einschränkung der verwendeten Leitungslängen ? Also Zuleitung und Ableitung je 2 Meter ?
Hintergrund der Fragen ist, dass ich noch immer versuche einen etwas schwierig zu erreichenden Masterbrick ab zu lösen.
Könnte ich das Istolator-Bricklet evlt zur „Leitungsverlängerung“ nutzen ?
Viele Grüße
Stefan
-
Hallo Erik
Die Abfrage der Alarm-Action mit GetAlarm und der Auswertung des Value mit .get("durationRemaining") as long hat wunderbar geklappt.
Mir ist allerdings zufällig aufgefallen das der Brick-Dämon der für die per USB angeschlossen Masterbricks und des HAT zuständig ist kurz ausgefallen ist.
Aufgefallen ist mir das nur, da eine meiner Test Rule‘s ohne mein Zutun das DualRelais on und off schaltet.
Ich vermutet es hing damit zusammen dass alle Button des LCD128x64 „triggerd RELEASED meldeten
Zitat2020-01-29 05:22:01.647 [vent.ChannelTriggeredEvent] - tinkerforge:brickletlcd128x64:HQJ:BrickletLCD128x64GUIButton0 triggered RELEASED
alle Bricklets die über diesen Dämon angesprochen werden, meldeten dass Sie wieder online gingen
Zitat2020-01-29 05:22:00.670 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:f80007d9' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect. 2020-01-29 05:22:00.846 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:f80007d9' changed from OFFLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect. to ONLINE
Dieser Effekt ist nicht so schön, denn es könnte sich auf Rules auswirken. (z.B. es reagierte auch die Rule die als Channel-Trigger die TouchPosition nutzt)
Gesehen habe ich dies bis jetzt nur einmal.
Im Event-Log der letzten 2 Tage (in diesem Zeitraum habe ich das System nicht gebootet) fand ich keine weitere Meldung für dieser Art des brick-Dämon.
Frage: gibt es irgend einen TimeOut der evlt. zu schnell reagierte und daher diesen Fehler verursachte ? Wenn du den Zeitstempel anschaust ist das gerade mal im 200ms Bereich abgelaufen.
Viele Grüße
Stefan
-
Hallo Erik
zum getEdgeCount IO-16 V1 ich habe mal versucht mit short das ganze zu testen. Es kommt aber noch immer der Fehler. .
Zitatval currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as short
Zitat2020-01-27 19:07:11.513 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short
Um sicher zu gehen, dass mir kein Config Fehler unterlaufen ist, habe ich noch mal unter Things geprüft, wie der korrekte Channel / Port lautet.
Zitat„ val ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:D8e")“
Thing Eintrag >> tinkerforge:brickletio16:D8e:BrickletIO16EdgeCountPin0
Mit long hatte ich gestern anstelle von int getestet, das hat auch nicht geklappt.
Zum Piezo Alarm,
Ja das Item „PiezoAlarm“ nutze ich für den Alarm Channel.
Kaum habe ich den SendCommand für das Einschalten des AlarmChannel entfernt und nur die SetAlarm Action in der Rule aufgerufen, hat es wunderbar geklappt.
Ich dachte, ich muss den Alarm erst über den AlarmChannel „einschalten“, das war mein Fehler
Super jetzt passt meine Rule
Abschalten einer laufenden Alarm-Action geht einfach indem ich den AlarmChannel per SendCommand auf OFF setzte.
Frage, kann ich eigentlich abfragen ob gerade eine „Alarm“-Action aktiv ist ? Oder muss ich mir selber über Variablen einen Merker setzten ?
Viele Grüße Stefan
-
Hallo omiT
anbei mein Beispiel für den Motion Detector V2 Test
Die LED habe ich über eine ITEM-Datei verlinkt, ich nutze diese in meiner Test-Rule für die Anzeige wann einen Bewegung erkannt wurde und diese wieder beendet wurde.
Eintrag in "meiner" Item-Datei
ZitatNumber MDLED_links "SignalLED links Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2TopLeftIndicator"}
Number MDLED_rechts "SignalLED rechts Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2TopRightIndicator"}
Number MDLED_unten "SignalLED unten Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2BottomIndicator"}
Zum spielen gibt es 2 Rules, eine die bei Bewegung „erkannt“ die LED erst mit 25% dann mit 100% Leistung einschaltet. Und eine die bei „Ende“ Bewegung die LED in umgekehrter Reihenfolge wieder auf Leistung 0% abschaltet.
Der Thread::sleep(100) dient nur dazu, dass ich erkennen kann ob ein Unterschied zwischen 25% und 100% Leistung bei den LED zu erkennen ist.
Der sleep ist hier etwas uncool, da Du Gefahr läufst, dass die erste Rule noch einen Sleep abwartet während bereits ein Trigger für die zweite Rule gestartet wurde. Aber zum testen geht´s 😉
Zitatrule "motionDedect-on-t"
when
Channel "tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2MotionDetected" triggered
then
MDLED_links.sendCommand(25)
Thread::sleep(100)
MDLED_rechts.sendCommand(25)
MDLED_links.sendCommand(100)
Thread::sleep(100)
MDLED_unten.sendCommand(25)
MDLED_rechts.sendCommand(100)
Thread::sleep(100)
MDLED_unten.sendCommand(100)
end
rule "motionDedect-off-t"
when
Channel "tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2DetectionCycleEnded" triggered
then
LCD20x4_light.sendCommand(OFF)
MDLED_links.sendCommand(0)
Thread::sleep(100)
MDLED_rechts.sendCommand(0)
Thread::sleep(100)
MDLED_unten.sendCommand(0)
end
Die Channel-Information für
BrickletMotionDetectorV2MotionDetected / DetectorV2DetectionCycleEnded
findest Du wie die channel‘s für die LED‘s unter paperui / Configuration / Things / MotionDetector
Wenn Du die Items & Rule‘s entsprechende Deinen Channel-Thing-Daten anpasst, sollte es klappen.
Grüsse Stefan
-
1
-
-
Hallo Erik
heute habe ich mal versucht alle meine angeschlossenen Bricklets mit dem B16-Binding zu testen (aber nicht alle möglichen Actions).
Folgendes ist mir dabei aufgefallen.
>>„Industrial Digital In 4 Bricklet 2.0“
Frage: Kann es sein, dass Du keine Action für „getEdgeCount(int channel, boolean resetCounter)“ mehr vorgesehen hast ?
Bei den IO-16-V1 / IO-16-V2 / IO-4-V2 & „Industrial Digital In 4 V2“ hatte der mit dem EdgeCount verlinkte Number-Item immer den Werte 0
Ich vermute es ist noch das Problem das Du in Deinem Post vom 28.10.2019 beschrieben hast, oder ?
ZitatZitat: „Das funktioniert leider noch nicht automatisch, da der Edge Count kein Callback hat, ich also den Getter benutzen muss. Der wird aber nur ausgeführt, wenn du dem Item ein Refresh-Command schickst. Solche Werte automatisch zu aktualisieren steht noch auf der TODO-Liste. „
Die Action getEdgeCount funktionierte für das IO-4 V2 und das IO-16-V2 (es wurde ein Wert ausgegeben), für das IO-16 V1 hingegen nicht.
Basis der Rule war ein Vorschlag den Du am 15.11.2019 auf meine Frage zur getEdgeCount Action gemacht hast.
Diesen habe ich entsprechend für die 3 verschieden IO-Bricklets angepasst
Hier das Beispiel für das IO-16-V1
Zitatval ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:D8e")
val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as int
Ich bekomme (nur) für das IO-16 V1 folgende Fehlermeldung im Log
Zitat2020-01-26 16:55:19.065 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short
Technische Daten zu meinem IO-16-V1
ZitathardwareVersion
1.1.0
modelId
28.0
Zum den Action (Alarm) des Piezo Speaker V2 hätte ich eine Frage
Die Grundkonfiguration für den Beep und den Alarm sind doch unabhängig von Action‘s „brickletPiezoSpeakerV2SetBeep“ und brickletPiezoSpeakerV2SetAlarm, oder ?
Ich habe mit dem „brickletPiezoSpeakerV2SetAlarm“ in den Rules ein Problem. Aber komischerweise nur mit dem Alarm nicht mit dem Beep.
Wenn ich in einer Rule über brickletPiezoSpeakerV2SetAlarm versuche den Alarm zu verändern, ändert sich nur kurz die „Startfrequenz“ auf dem Wert den ich mit der Action übergebe, aber nach ca 0,1-0,2 Sekunden kommt der Alarm so wie er über der Thing „Configure channel“ voreingestellt ist.
Zitatrule "Dummy-interner-Alarm-mit Piezo"
when
Item P0Ig7y changed to ON
then
val piezoActions = getActions("tinkerforge", "tinkerforge:brickletpiezospeakerv2:KGL")
if (PiezoAlarm.state == OFF ) {
PiezoAlarm.sendCommand(ON)
piezoActions.brickletPiezoSpeakerV2SetAlarm(1000,2500,100,1000,2,10000)
}
end
Ich hätte einen Alarm mit 1000Hz Startfrequenz, der jede Sekunde in 100 Hz Schritten bis 2500 Hz ansteigt und dies 10 Sekunden lang andauert. Es kommt aber nur ein kurzer 1000 Hz Ton dann fällt er wieder auf die Channel-Konfiguration zurück (Startfrequenz = 200Hz, Endfrequenz = 1000Hz, StepSize = 100 , StepDelay = 100 , DefaultVolumen = 1 , Duration = 5000)
Wo liegt der Fehler in meiner Rule ?
Einen Frage zu den Channel des MultiTouch V2
Generell funktionieren bei mir die mit ITEM-Verlinken Channel, diese kann ich auch problemlos in Rules verwenden.
Kann es sein, dass die Channel nicht direkt in einer Rule als Trigger genutzt werden können ?
Ich sehe auch im Log keine Meldung wenn ich eine der Tasten berühre (ich nutze Eurer 3x4 Tastenfeld).
Ich habe in der Rule Channel verwendet die mit einem Item verlinkt waren und Channel die nicht mit einem Item verlinkt waren.
Zitatrule "Dummy-Multitouch&E-Paper2"
when
Channel "tinkerforge:brickletmultitouchv2:KyQ:BrickletMultiTouchV2Electrode0" triggered
then
logInfo("Multitouch", "1TEST----------------------------------------TEST")
logInfo("Multitouch", "2TEST----------------------------------------TEST")
logInfo("Multitouch", "3TEST----------------------------------------TEST")
logInfo("Multitouch", "4TEST----------------------------------------TEST")
end
Was ich auch echt gut finde ist die Firmware/Update und HW Info die das neue Binding bereitstellt.
Viele Grüße
Stefan
Anbei meine Testliste
Binding Version B16 Typ Item-Channel-Verlinkung Item in Rule Channel in Rule Action in Rule E-Paper296x128 ok nicht getestet nicht getestet FillDisplay / DrawText Multitouch V2 ok ok keine Funktion nicht getestet Rotary Poti V2 ok ok nicht getestet nicht getestet Rotary Encoder V2 ok ok nicht getestet nicht getestet Humidity Bricklet V2 ok ok nicht getestet nicht getestet Outdoor Weather Bricklet ok (mit 2 x TH6148) ok nicht getestet nicht getestet Motion Detector V2 ok ok ok nicht getestet LCD 128x64 ok ok ok verschiedene LCD 20x4 ok ok ok brickletLCD20x4ClearDisplay Dual Relay V2 ok ok nicht getestet nicht getestet Industrial QuadRelay V2 ok ok nicht getestet nicht getestet Industrial Digital In4 V2 ok ok nicht getestet kein getEdgeCount ? IO-16 V1 ok ok nicht getestet Problem mit getEdgeCount IO-16 V2 ok ok nicht getestet getEdgeCount IO-4 V2 ok ok nicht getestet getEdgeCount Piezo Speaker V2 ok ok nicht getestet Problem PiezoSpeakerV2SetAlarm -
Hallo Erik
kurze Rückmeldung zum neuen B16 Binding
Gestern abend habe ich das Binding eingespielt, zuvor alle Things aus der Konfiguration entfernt und erneut hinzugefügt. Alle verlinkten Items und "Channel"-Aufrufen in Rules usw angepasst.
Auf dem ersten Blick funktionieren alle Rules und alle (angepassten) verlinkten Items.
Das Problem mit den "vergessenen" ID der Sensoren ist auch behoben (habe 3 x ,incl Spannung-Abschaltung, rebootet). Zusätzlich habe ich einen weiteren TH-6148-Sensor in die Konfiguration aufgenommen und verlinkt, hat wunderbar geklappt.
Auch die Fehlermeldung (No value present) die ich in meinem letzten Post beschrieben habe ist nicht mehr aufgetaucht.
Nachdem ich aktuell 2 Tinkerforge-Stack angeschlossen habe ( 1x WIFI-Extention , 1xUSB) , habe ich auch das Umstecken des Piezo-Speaker vom Masterbrick-USB-angeschlossen, zum Masterbrick-WIFI-Extention angeschlossen, getestet. Nachdem Boot nur die Konfiguration angepasst ("configuration/things/edit/tinkerforge:brickletpiezospeakerv2" über die Auswahl der "Bridge Selection") und der Speaker war wieder online ohne dass ich Verlinkungen der Items ändern musste (super Funktion).
Zwei Fragen hätte ich noch
1) Bezüglich "Schema für ThingUID" : Ich habe die beiden Brick-Daemons (für WIFI & USB angeschlossene Master-Bricks) nicht "entfernt und neu hinzugefügt", nur die restlichen Tinkerforge-Things. Frage: könnte dies evtl später zu Problemen führen, bis jetzt funktioniert alles.
2) wie oft/wann wird denn der "Sensor/Station Identifiers" des OutDoor Weather aktualisiert ? Nachdem ich den zweiten TH-6148-Sensor aktiviert hatte, könnte ich zwar über den Brickviewer dessen ID lesen, und mit dieser dann den Sensor in die Konfiguration einbinden, jedoch zeigte mir "Sensor Identifiers" nur die ID des bereits aktiven an. Nach ca 10 min habe ich das System 1 x rebootet (incl Stromabschaltung), danach wurden beide ID angezeigt. Wie gesagt den zweiten Sensor konnte ich funktionsfähig einbinden obwohl dessen ID noch nicht im Sensor-Identifier angezeigt wurde.
Deine Binding-Funktionen sind echt super, danke nochmal
Am WE werde ich weiter Testen
viele Grüsse
Stefan
-
Hallo Erik
ich habe heute Abend das neue B15 Binding eingespielt.
Nach dem Neustart erschienen anschließend im Log viele Fehlermeldungen diverser actions, diese waren nach einem reboot mit trennen der Spannungsversorgung aber behoben.
Das Backlight des LCD20x4 kann jetzt per Rule wieder ein uns ausgeschaltet werdenDie umgebaute Funktion für das Outdoor Weather Bricklet funktioniert (teilweise).
Ich konnte das neue Thing „Tinkerforge Outdoor Weather Temperature/Humidity Sensor TH-6148„ hinzufügen, sowie den Sensor mit der passenden ID konfigurieren.
Die Freude war aber nur von kurzer Dauer, nach einem Reboot incl. Stromabschaltung, wurde mir das Thing als „UNINITIALIZED - BRIDGE_UNINITIALIZED “ angezeigt.Wenn ich unter configuration / things/edit/tinkerforge:outdoorweathersensor >>Bridge Selection<<
nachschaue, wird das Outdoorweather-Bricklet mit korrekter Thing-ID und Bricklet-ID im Menü angezeigt. Auch ein erneutes Abspeichern in diesem edit Menü änderte nicht am Status.Als nach ca. 10 Minuten noch immer die „ UNINITIALIZED – BRIDGE_UNINITIALIZED“ für das Thing angezeigt wurde, habe ich dieses aus der OpenHAB Konfiguration entfernt und neu hinzugefügt. Danach wurde das Thing als online angezeigt und die Sensor-Daten wurden an die „neu“ mit den Channel verlinkten Items übertragen. Das ganze habe ich 2x ausgeführt, der Fehler war reproduzierbar.
Frage: Kannst du mal schauen, wie sich das System bei Dir verhält ?Das neu verlinken der Items konnte ich im zweiten Versuch zwar vermeiden, ich musste aber ebenso das Thing aus der Konfiguration entfernen und neu hinzufügen (hierbei habe ich dann die alte Thing-ID wieder eingetragen). Es wäre unschön, wenn man nach einem Reboot mit „abschalten der Spannungsversorgung“ so eingreifen müsste.
Die beiden neuen String-Item des Outdoor Weather Bricklet funktionieren, ich habe je ein String-Item für die Sensor und Station Identifiers angelegt. Nachdem ich keine Station habe wurde auch keine ID anzeigt, für den Sensor wurde die ID korrekt angezeigt.
Ich vermute das String-Item, das ich für den Station-Identifier anlegte und verlinkte habe, verursachte diese Fehlermeldung in Log (ich habe nur einen Sensor, aber für Sensor und Station je ein verlinktes Item).
Zitat2020-01-22 21:25:01.585 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tinkerforge:brickletoutdoorweather:f80007d9:E4v': No value present
java.util.NoSuchElementException: No value present
Oder wie interpretierst Du diese Meldung im Log ?
Viele GrüßeStefan
-
Hallo Erik
die Auswertung der brickletLCD128x64GetTouchPosition hat wunderbar geklappt.
Es kam nur ein kleiner Fehler für "age"Zitat2020-01-20 21:00:00.999 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'test touch position': Could not cast 0 to java.lang.Integer; line 239, column 15, length 30
ZitatRule Zeile 239 >> val age = touchPos.get("age") as Integer
Hab dann nochmal bei Euch in die Java-Beispiele geschaut >>age – Typ: long, Einheit: 1 ms, Wertebereich: [0 bis 232 - 1]<< und long hat es geklappt.
Zitatval age = touchPos.get("age") as long
Ich sehe schon, ich muss mich etwas mehr mit Java beschäftigen 🙂
Nochmals Danke 🙂
viele Grüsse
Stefan
-
Hallo Erik,
dieses Woche habe ich nicht soviel getestet, eine Frage hätte ich aber zu einer Action für das LCD128x64
Wie kann ich die Daten aus der Action .brickletLCD128x64GetTouchPosition()
nutzen ? Was müsste ich im Aufruf ändern, dass ich die 4 Rückgabewerte in rule‘s nutzen kann ?Ich habe versucht die Daten einer String Variablen oder einem String Item zu zuweisen, es kam immer ein Fehler. Wenn ich die Action ohne eine Zuweisung (String/Variablen) aufrufe kommt kein Fehler, allerdings sehe ich auch kein Ergebnis.
Meine beiden Aufrufen :
a) mit Variablen
Zitatvar String dummystring1 =""
val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:f80007d9:HQJ")
dummystring1 = lcdActions128x64.brickletLCD128x64GetTouchPosition()Fehler im Log:
Zitat2020-01-19 09:52:19.092 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Display Menue-Aufbau': An error occurred during the script execution: Could not invoke method: org.eclipse.xtext.xbase.lib.StringExtensions.operator_plus(java.lang.String,java.lang.String) on instance: null
b) mit Item-String
Zitatval lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:f80007d9:HQJ")
DummyText1.sendCommand(lcdActions128x64.brickletLCD128x64GetTouchPosition())
Fehler im LogZitat2020-01-19 09:59:06.641 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Display Menue-Aufbau': An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,org.eclipse.smarthome.core.types.Command) on instance: null
Hinweis zu Eurer Dokumentation:
Kann es Sein dass Euch in der Java-Beispiel Doku ein kleiner Fehler unterlaufen ist ?
In der Parameter-Liste steht als Wertebereich für den Index 0-5 (also 6 Slider) in der in der Textbeschreibung steht dass bis zu 8 Slider benutzt werden können Index 0-7Zitat aus Euer Beschreibung:
Zitatvoid BrickletLCD128x64.setGUISlider(int index, int positionX, int positionY, int length, int direction, int value)
Parameter: index– Typ: int, Wertebereich: [0 bis 5]
positionX– Typ: int, Wertebereich: [0 bis 128]
positionY– Typ: int, Wertebereich: [0 bis 64]
length– Typ: int, Wertebereich: [8 bis 128]
direction– Typ: int, Wertebereich: Siehe Konstanten
value– Typ: int, Wertebereich: [0 bis 120]
Es können bis zu 8 Slider genutzt werden (Index 0-7).
Viele GrüßeStefan
-
Hallo Erik,
ich habe über die Feiertage mit dem B14 Binding etwas weiter getestet (hauptsächlich Actions).Abgesehen mit dem Backlight LCD20x4 Problem und der Sensor TH-6148 unschärfe ist das System stabil durchgelaufen.
Folgende Action habe ich getestet.
LCD128x64 : alle unten aufgelisteten Action haben funktioniert
brickletLCD128x64SetGUIButton / brickletLCD128x64RemoveGUIButton
brickletLCD128x64SetGUISlider / brickletLCD128x64RemoveGUISlider
brickletLCD128x64DrawText / brickletLCD128x64ClearDisplay
brickletLCD128x64RemoveAllGUIPiezo V2: alle unten aufgelisteten Action haben funktioniert
brickletPiezoSpeakerV2SetBeep / brickletPiezoSpeakerV2SetAlarm
brickletPiezoSpeakerV2UpdateVolume / brickletPiezoSpeakerV2UpdateFrequency
Zwei unschöne Sachen sind mir beim „Outdoor Weather Bricklet“ in Verbindung mit dem „Outdoor Weather Temperature/Humidity Sensor TH-6148“ aufgefallen.Beide Punkte scheinen bei Euch bekannt zu sein (hab verschiedene Einträge im Forum gefunden), machen es aber problematisch das Weather Bricklet und den TH-6148 sinnvoll in Openhab einzusetzen.
1) Der Sensor ändert willkürlich nach einem Batterie-tausch seine ID. Dies hat zur Folge, dass man Channel-Verlinkung zu Items oder Rules anpassen muss. Dies ist ein echtes KO Kriterium. >>„never touch an running system“<<
2) Das „Outdoor Weather Bricklet“ merkt sich die alte ID des TH-6148 und zeigt somit den TH-6148 jeweils mit der alten und neuen ID als eigenständiges Thing an. Die alte-ID lässt sich nur entfernen wenn man das System stromlos macht und zuvor das „Outdoor Weather Bricklet“ samt Sensor & Sensor-Leichen aus der Openhab Konfiguration entfernt und das System erneut neu startet.
Dazu hätte ich drei Fragen:
1) gibt es kompatiblen Sensor zum TH-6148 dessen ID man Konfigurieren kann ? (ich vermute der TH-6148 wurde nicht von Euch entwickelt, sondern zugekauft)2) Im Post „https://www.tinkerunity.org/topic/4543-id-des-th-6148-temperatursensors/?tab=comments#comment-26305“ wird auf das Problem der „Sensor Leichen“ hingewiesen. „Borg“ meinte er würde es auf seine ToDo Liste setzten (das Löschen der Sensor Leichen). Ist Dir Bekannt ob nach 24h diese Leichen automatisch weg sind ? (hat bei mir nicht geklappt)
3) siehst Du eine Möglichkeit das Binding so umzubauen, dass zumindest keine neue Verlinkung / Rule Anpassung statt finden muss, wenn die Batterie des Sensor getauscht wurde ?
Aktuell wird der Sensor als eigenständiges Thing angezeigt, eventuell wäre es eine Option dass die 3 Channel des Sensor als Channel‘s direkt über das „Outdoor Weather Bricklet“-Thing dargestellt und erst dort mit den ID des Sensoren verknüpft werden (ähnlich dem IO-16, dort können auch die 16-Ports einzeln konfiguriert werden).
Sicher müsste man dann die Anzahl der möglichen Sensoren die über diese Methode eingebunden werden, auf eine kleiner Stückzahl reduzieren (5-10?) um das ganz bedienbar zu halten.Eigentlich wollte ich mit dem „Outdoor Weather Bricklet“ und dem TH-6148 ein etwas schwierig zu erreichenden Masterbrick ablösen.
Das müsste ich nicht, wenn der „FW-Update“ nicht das betätigen der Boot und Reset-Taste am Masterbrick erfordern würde.Frage: Gibt es eine Planung den FW-Update des Masterbrick zukünftig anderes zu gestalten, ähnlich dem es HAT ? (also ohne betätigen des beiden Tasten)
Den Masterbrick könnte ich auch ablösen wenn es längere Leitungen geben würde. In einem alten Post (aus dem Jahr 2012) ist zu lesen, dass die Leitungslänge abhängig vom Bus ist und daher begrenzt ist. Hat sich da mit den neuen 7 Pol Bricklets etwas geändert (mir würden 3 Meter lange Leitungen reichen)
siehe Archiv Post
https://www.tinkerunity.org/topic/40-maximale-l%C3%A4nge-f%C3%BCr-ein-bricklet-kabel/#msg192
dort wird von möglichen 4x3m am Masterbrick gesprochen (leider kann man nicht mehr erkennen von wem der Post stammt)---
Den Punkt mit dem nicht ausschaltbaren Backlight es LCD 20x4 habe ich ja bereits vor ein paar tagen gepostet (lässt sich ein aber nicht mehr ausschalten)
Viele GrüßeStefan
-
Hallo Erik,
gestern habe ich etwas mit dem neuen 14er Binding getestet und die Actions Cleardisplay für LCD20x4 und 128x64 in eine Rule eingebaut, hat funktioniert.
Kannst Du Dir aber bitte noch mal das 20x4 LCD anschauen ?
Aktuell kann ich zwar das Backgroundlight einschalten aber nicht mehr ausschalten (über den Brickviewer lässt es sich ausschalten). Es macht keinen Unterschied ob ich dies per Rule oder ../paperui/control versuche.(ich hoffe nicht dass ich einen Tippfehler hatte)
Mein Item sieht wie folgt aus
ZitatSwitch LCD20x4_light "Backlight [%s]" (TestTF) { channel="tinkerforge:brickletlcd20x4:f80007d9:vyU:BrickletLCD20x4Backlight"}
Zitatmeine Rule Befehle :
LCD20x4_light.sendCommand(OFF) << funktioniert nicht
LCD20x4_light.sendCommand(ON) << funktioniert
Zitat2019-12-22 20:42:10.751 [ome.event.ItemCommandEvent] - Item 'LCD20x4_light' received command OFF
2019-12-22 20:42:10.766 [nt.ItemStatePredictedEvent] - LCD20x4_light predicted to become OFF
2019-12-22 20:42:10.777 [vent.ItemStateChangedEvent] - LCD20x4_light changed from ON to OFF
Mir ist aufgefallen, dass in Deiner Binding-Doku zwar eine Action für >>brickletLCD20x4IsBacklightOn<< gibt, aber keine für OFF. In der Tinkerforge Doku mit dem Java-Beispielen gibt es jedoch eine. >>BrickletLCD20x4.backlightOff()
Kann dies die Ursache sein ?
Ich werde über die Feiertage weiter testen
@KlausGünther :
ich hatte ein ähnliches Problem, nachdem Hinzufügen des "Masterbrick"-Things waren diese mehrfach unter Things vorhanden (immer die gleiche ID). Als ich den Dämon gelöscht, das Binding über die "openhab-cli console" deinstalliert und openhab zurück gesetzt hatte, war der Fehler weg und ist nicht mehr aufgetreten (dies ist jetzt 3 Tage her). Ich hätte mal vermutet dass sich openhab irgendwo "verschluckt" hatte.
viele Grüsse und frohes Fest
Stefan
-
Hallo Erik,
ich werde mich dieses WE gleich mal ans Testen machen.
Das mit der mehr Schreibarbeit ist ok, Hauptsache man kann die Actions nutzen.
Viele Grüsse, ein frohes Fest und ein gesundes und glückliches Jahr 2020
Stefan
Betaversion der openHAB-Bindings
in Allgemeine Diskussionen
Geschrieben
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.
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