Jump to content
rtrbt

Betaversion der openHAB-Bindings

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Edited by KlausGünther

Share this post


Link to post
Share on other sites

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

 

Edited by StefanOHAN

Share this post


Link to post
Share on other sites
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.

 

Edited by KlausGünther
Nachgtragen das der Lösungsansatz von StefanOHAN funktioniert hat.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Moin,

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

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...