Betaversion der openHAB-Bindings

[rtrbt]

Das dürfte an der Namensänderung liegen, die ich machen musste. Da jetzt intern alles anders heißt (z.b. ein Stepper Brick nicht mehr nur Stepper), betrachtet openHAB das als andere Devices. Die alten musst du vermutlich löschen und neu anlegen, sorry dafür!

Edit: @sihui Diese Warnung sehe ich bei mir auch immer, habe noch auf der TODO-Liste rauszufinden, was da das Problem ist. Funktionieren tuts ja anscheinend auch so.

[sihui]

vor 18 Stunden schrieb rtrbt:

Funktionieren tuts ja anscheinend auch so.

Ja, ohne Probleme bis jetzt.

Falls ich ein wenig mehr Zeit habe die nächsten Tage werde ich mal das neue Binding in meiner Produktionsumgebung einsetzen.

[KlausGünther]

vor 19 Stunden schrieb rtrbt:

Die alten musst du vermutlich löschen und neu anlegen, sorry dafür!

Das waren weit über 5min arbeit.....Du kannst Du also vorstellen wie das den kompletten Tag versaut hat ;-)

Spaß beiseite, ich hatte mir schon so etwas gedacht, ich wollte nur sicherstellen das es auch so ist und nicht
irgendwas am System im Eimer ist oder spinnt.

Läuft bisher - und das ist ja das tolle an OH, einfach neu verlinken - soweit ich das sagen kann stabil und ohne
Probleme.

[KlausGünther]

Jetzt habe ich einen ganz spannenden Fehler 😡

Nachdem heute Nacht für mehrere Stunden das komplette TF System nicht erreichbar war,
ist das heute Abend wieder passiert. Dann habe ich gesehen, dass ALLE TF Bausteine DOPPELT in
der Inbox sind....löschen kann man sie nicht, die tauchen umgehend wieder auf......
Und damit es ganz spannend wird, nur jeweils eines der Things geht online....

Ratlos.....

bearbeitet December 22, 2019 at 20:28 von KlausGünther

[StefanOHAN]

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

Zitat

Switch LCD20x4_light "Backlight [%s]" (TestTF) { channel="tinkerforge:brickletlcd20x4:f80007d9:vyU:BrickletLCD20x4Backlight"}

 

Zitat

meine Rule Befehle :

LCD20x4_light.sendCommand(OFF) << funktioniert nicht

LCD20x4_light.sendCommand(ON)  << funktioniert

 

Zitat

2019-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

 

bearbeitet December 23, 2019 at 10:57 von StefanOHAN

[KlausGünther]

Am 23.12.2019 um 11:45 schrieb StefanOHAN:

@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.

 

 

Dann habe ich ja was zu googlen wie das geht :-) Aber ich denke damit komme ich mal weiter. EDIT: SO GING

 

Erst mal ALLEN vorab schöne Weihnachten und an Erik einen Herzlichen Gruss und Dickes Dankeschön für die geleistete arbeit.

 

bearbeitet December 28, 2019 at 11:34 von KlausGünther
Nachgtragen das der Lösungsansatz von StefanOHAN funktioniert hat.

[sihui]

Am 19.12.2019 um 15:44 schrieb rtrbt:

Support für die Remote Switch Bricklets ist jetzt drin

Der Vollständigkeit halber hier jeweils ein Beispiel für Typ A und Typ B (Typ C habe ich leider nicht):
 

rule "remoteswitch socket A"
when
    Item Socket_A received command
then
    val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master:abc")
    if (receivedCommand==ON) {
        remoteActions.brickletRemoteSwitchSwitchSocketA(12 as short, 2 as short, 1 as short)
    }
    else {
        remoteActions.brickletRemoteSwitchSwitchSocketA(12 as short, 2 as short, 0 as short)
    }
end

rule "remoteswitch Socket B"
when
    Item Socket_B received command
then
    val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master:abc")
    if (receivedCommand==ON) {
        remoteActions.brickletRemoteSwitchSwitchSocketB(123456, 3 as short, 1 as short)
    }
    else {
        remoteActions.brickletRemoteSwitchSwitchSocketB(123456, 3 as short, 0 as short)
    }
end

@rtrbt, vielen Dank! Falls du nach den Feiertagen mal ein wenig Zeit übrig hast: wie kann ich die Anzahl der Schaltwiederholungen (Repeats) erhöhen? Mein Remoteswitch Bricklet braucht immer statt 5 etwa 10 Wiederholungen um sauber zu schalten.

Besten Dank.

[KlausGünther]

Hallo Zusammen,

es ist jetzt mehrfach passiert, dass "augenscheinlich" das TF Binding ausgestiegen ist und eines oder mehrer Bricklets keine Daten mehr gesendet haben bzw. die nicht ankamen.

Es half dann auf dem kurzen Wege nur der Neustart. Das ganze ging auch jeweils über mehrer Stunden, also nicht nur ein paar Minuten.

Eric kannst Du da noch mal gucken ?

 

Grüße
Stefan

[StefanOHAN]

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
brickletLCD128x64RemoveAllGUI

Piezo 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üße

Stefan

[rtrbt]

Moin,

Ich bin diese Woche noch im Urlaub, sehe mir das alles mal nächste Woche an.

[omiT]

Hallo zusammen,

1) beim LCD20x4 kann ich die Beobachtung von StafenOHAN bestätigen, das Backlight lässt sich nicht mehr ausschalten.

2) Beim Barometer Bricklet fehlt der Kanal für die Temperatur. Der Kanal für AirPressure und für Altitude wird angezeigt. Das Binding von Theo hatte auch alle drei Kanäle. Kann man den Temperaturkanal noch ergänzen? Das wäre toll!

Liebe Grüße

Timo 

[rtrbt]

Moin,

Der Temperaturkanal beim Barometer 1.0 fehlt, da das eigentlich nur ein interner Wert des Sensors ist, der nicht wirklich genau ist. Deshalb heißt die entsprechende API-Funktion auch getChipTemperature. Es gibt auch kein Callback dazu, d.h. der Wert würde sich nicht automatisch aktualisieren.

Um die anderen Rückmeldungen kümmere ich mich diese Woche, mal wieder danke fürs Testen

[rtrbt]

Moin,

Das LCD20x4-Backlight-Problem habe ich gefunden, das war unpraktisch konfiguriert, sollte mit der nächsten Beta wieder funktionieren.

On 1/5/2020 at 7:44 PM, StefanOHAN said:

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 ?

1) Wäre mir nicht bewusst.

2) Das passiert ab Firmware-Version 2.0.2 des Bricklets, zumindest innerhalb des Bricklet-Speichers, es ist aber durchaus möglich, dass meine openHAB-Implementierung da noch einen Bug hat. Das ist aber wegen folgendem nicht schlimm:

3) Ich habe da nochmal drüber nachgedacht und bin zu folgendem Schluss gekommen: Den Handler für das Outdoor Weather Bricklet habe ich von Hand geschrieben, d.h. da habe ich mehr Möglichkeiten, deshalb kann ich das nochmal komplett anders bauen. Das Bricklet bleibt eine Bridge, bekommt aber zusätzlich einen Channel, der eine Liste von bekannten Sensor- und Station-IDs zurückgibt. (Das ist die Liste die das Bricklet selbst hält, d.h. die wird automatisch nach 12 Stunden bereinigt wenn eine ID verschwindet). Die Sensoren und Stationen werden dann nicht mehr automatisch in die Inbox gelegt, sondern ähnlich zum Brick Daemon vom Nutzer hinzugefügt, die "echte" ID ist dann nur eine Konfiguration, als UID (im openHAB-Sinne) wird eine ausgewürfelt oder ausgewählt (wie bei Brick Daemons). Wenn sich dann eine ID durch Batteriewechsel ändert muss nur die konfigurierte ID des Devices geändert werden, das Device bleibt das selbe -> alle Channel-Verlinkungen, Rules usw. funktionieren weiter.

On 1/5/2020 at 7:44 PM, StefanOHAN said:

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)

Da gibt es theoretische Überlegungen, aber noch nichts konkretes.

On 1/2/2020 at 5:40 PM, KlausGünther said:

es ist jetzt mehrfach passiert, dass "augenscheinlich" das TF Binding ausgestiegen ist und eines oder mehrer Bricklets keine Daten mehr gesendet haben bzw. die nicht ankamen.

Es half dann auf dem kurzen Wege nur der Neustart. Das ganze ging auch jeweils über mehrer Stunden, also nicht nur ein paar Minuten.

Erik kannst Du da noch mal gucken ?

Hm steht in den openHAB-Logs dazu etwas interessantes? Eventuell hilft auch ein Brick Daemon Log.

[StefanOHAN]

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

Zitat

 

var String dummystring1 =""

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:f80007d9:HQJ")
dummystring1 = lcdActions128x64.brickletLCD128x64GetTouchPosition()

 

Fehler im Log:

Zitat

2020-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

Zitat

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:f80007d9:HQJ")
DummyText1.sendCommand(lcdActions128x64.brickletLCD128x64GetTouchPosition())

Fehler im Log

Zitat

2020-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-7 

Zitat aus Euer Beschreibung:

 

Zitat

 

void 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üße

Stefan

[photron]

21 hours ago, StefanOHAN said:

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-7 

Ja ist es. Es gibt 6 Slider. Der Fehler ist korrigiert. Danke für den Hinweis.

[rtrbt]

21 hours ago, StefanOHAN said:

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 ?

Du bekommst aus der Action eine Map<String, Object>, aus der du mit .get("keyname") Daten rausholen kannst. Um die Keys rauszufinden kannst du folgendes machen:

logInfo("test", "TouchPosition" + lcdActions128x64.brickletLCD128x64GetTouchPosition().toString())

dann wird sowas hier ausgegeben: TouchPosition{x=65, y=43, pressure=1, age=0}

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.

[StefanOHAN]

Hallo Erik

die Auswertung der brickletLCD128x64GetTouchPosition hat wunderbar geklappt.
Es kam nur ein kleiner Fehler für "age"

Zitat

2020-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

Zitat

Rule 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.
    

Zitat

val age = touchPos.get("age") as long

Ich sehe schon, ich muss mich etwas mehr mit Java beschäftigen 🙂  

Nochmals Danke  🙂

viele Grüsse

Stefan

[rtrbt]

Moin,

Beta 15 ist jetzt im Post oben. Das Outdoor Weather Bricklet funktioniert jetzt wie hier beschrieben:

On 1/15/2020 at 4:24 PM, rtrbt said:

Den Handler für das Outdoor Weather Bricklet habe ich von Hand geschrieben, d.h. da habe ich mehr Möglichkeiten, deshalb kann ich das nochmal komplett anders bauen. Das Bricklet bleibt eine Bridge, bekommt aber zusätzlich einen Channel, der eine Liste von bekannten Sensor- und Station-IDs zurückgibt. (Das ist die Liste die das Bricklet selbst hält, d.h. die wird automatisch nach 12 Stunden bereinigt wenn eine ID verschwindet). Die Sensoren und Stationen werden dann nicht mehr automatisch in die Inbox gelegt, sondern ähnlich zum Brick Daemon vom Nutzer hinzugefügt, die "echte" ID ist dann nur eine Konfiguration, als UID (im openHAB-Sinne) wird eine ausgewürfelt oder ausgewählt (wie bei Brick Daemons). Wenn sich dann eine ID durch Batteriewechsel ändert muss nur die konfigurierte ID des Devices geändert werden, das Device bleibt das selbe -> alle Channel-Verlinkungen, Rules usw. funktionieren weiter.

Außerdem habe ich das Problem mit der Bridge Selection gefunden, sodass jetzt keine Fehler mehr auftauchen, wenn man die in den Thing-Einstellungen editiert. Das heißt, dass man jetzt konfigurierte Bricks und Bricklets zwischen Brick Daemons (und damit auch Stapeln) verschieben kann. Im Moment führt das noch dazu, dass dann in der Inbox noch ein Thing zu viel auftaucht, das fixe ich in der nächsten Beta.

Die Firmware-Update-Logik funktioniert jetzt über die Interfaces die openHAB dafür bietet, d.h. dass jetzt die Firmware-Version und ob es ein Update gibt in den Eigenschaften der Things steht.

Das Backlight des LCD20x4 sollte jetzt auch korrekt funktionieren.

On 1/20/2020 at 9:36 PM, StefanOHAN said:

Es kam nur ein kleiner Fehler für "age"

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.
    

Ich sehe schon, ich muss mich etwas mehr mit Java beschäftigen 🙂 

Hm und ich sollte keine Typen raten sondern auch in der Doku nachsehen.

[StefanOHAN]

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 werden

Die 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). 

Zitat

2020-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üße

Stefan
 

[rtrbt]

Moin,

Das war ein etwas dämlicher Fehler meinerseits: Das Bricklet vergisst ja bei einem Reboot alle Sensoren/Stationen, damit kam aber der Code nicht klar, das ist mir durch die Tests gerutscht. Der Fix kommt heute noch. Das zweite Problem habe ich damit auch gleich erschlagen.

[rtrbt]

So, Beta 16 ist im Post oben. Ich habe das Schema für ThingUIDs geändert, die führen jetzt nicht mehr die ID des Brick Daemon mit. Damit funktioniert der Wechsel eines Things von einem Brick Daemon zu einem anderen zuverlässig und ohne duplizierte Inboxeinträge. Allerdings müssen deshalb alle Things nochmal neu erstellt werden, diesmal hoffentlich zum letzten mal.

[StefanOHAN]

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

 

 

bearbeitet January 24, 2020 at 06:58 von StefanOHAN

[rtrbt]

2 hours ago, StefanOHAN said:

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.

Das sollte kein Problem sein, die ThingUID des Brick Daemons habe ich nicht verändert.

2 hours ago, StefanOHAN said:

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.

Da gibt es leider kein Callback für, also wird die Liste im Moment nur aktualisiert, wenn openHAB danach ist, oder du händisch ein Refresh-Command schickst. Auf der TODO-Liste steht noch das allgemein über den Scheduler von openHAB zu lösen, das Problem haben ja einige Bricklets.

[KlausGünther]

Als ich gelesen habe "bitte noch mal neu verlinken" war meiner erster Gedanke "bitte nicht schon wieder". Muss aber sagen,
das was Du da gemacht hast lohnt sicht. Allein das man die Wetterstation mal eben neu verlinken kann über Up/Down ist
das schon wert. Von Bricklets und Bricks munter durcheinander tauschen und dann nur mal eben wieder die zugehörige
Bridge zu ändern mal gar nicht zu reden.
Astrein! 😁

[sihui]

Am 26.12.2019 um 17:38 schrieb sihui:

@rtrbt, vielen Dank! Falls du nach den Feiertagen mal ein wenig Zeit übrig hast: wie kann ich die Anzahl der Schaltwiederholungen (Repeats) erhöhen? Mein Remoteswitch Bricklet braucht immer statt 5 etwa 10 Wiederholungen um sauber zu schalten.

Gibt es zu dem Thema Repeats eine Lösung?