Betaversion der openHAB-Bindings

rtrbt · March 2, 2020 at 15:38

So, Beta 20 ist im Post oben. Der Bug mit der IO-16, die seltsame Konfigurationsdarstellung usw. sollten gefixt sein.

StefanOHAN · March 2, 2020 at 19:23

Hallo Erik,

Thema on/offline Meldung „Thing“ Dämon.

Die Meldung „Bridge of [UID] went online “ sehe ich für alle Bricklets und den Masterbrick der über den Dämon verwaltet werden. Ich sehe aber keine Meldung dass der Dämon online geht.

Meine Rule nutze folgenden Trigger

Zitat

„Thing "tinkerforge:brickd:wifi2test" changed“

und schaltet eine der beiden LED des Dual-Button ein / aus.

Gerade eben musste ich feststellen dass die doch Rule funktioniert, auch wenn ich keine „online-Meldung“ des Thing-Dämon im Log sehe. Dass ich fälschlicherweise dachte die Rule funktioniere nicht mehr, hatte einen anderen Grund.

Beim neu anlegen der Things, hatte ich für den Dual-Button in der Konfiguration vergessen die beiden LED auf „Channel default on“ zu konfigurieren. Nachdem die LED‘s nicht auf die Zustandsänderung des Dämon reagierten, dachte ich es lag an der fehlenden Meldung im Log. Mit anpassen der Dual-Button Konfiguration waren die LED‘s auch wieder vorhanden und bei der Zustandsänderung des Dämon wurden sie ein / ausgeschaltet.

Sorry mein Fehler, Asche auf mein Haupt.

Beta 20 habe ich eingespielt, jetzt funktioniert das IO-16 (alt) und auch die Darstellung der Port Konfiguration des IO-16 / IO-16 2.0 / IO4 2.0 zeigt jetzt den richtigen Text an 🙂

Danke für die schnelle Reaktion 🙂

viele Grüße Stefan

StefanOHAN · March 2, 2020 at 19:26

Hallo Tim (Teddy)

danke für Dein Angebot bezüglich der „Taster-Abdeckungen“

In meiner aktuellen produktiven Openhab 1.9 Umgebung habe ich ein Bedienfeld mit einem LCD20x4 und einem Multitouch 3x4 Key-Pad. (siehe Bild unten, besteht aus Acryl 5mm, wurde mit einem Laser-Cutter bei einem Lokalen Acryl-Glas Handel hergestellt)

Diese Bedienfeld-V1 möchte ich mit der Umstellung meines Prod-System auf OpenHab2 komplett neu aufbauen und aktuelle Tinkerforge Komponenten integrieren.

Vom Aufbau würde ich wieder 5mm Acryl nutzen, die Bricklets würde auf einem Basis-UnterRahmen befestigt und mit einem „Abdeckrahmen“ mit entsprechenden Ausschnitt für die Bedienelemente geschützt.

Im groben würde folgenden Komponenten in diesem Bedienfeld verbaut sein

1x LCD 128x64

1x Multi-Touch mit 4x3 Key-Pad

1x NFC

1x Dual Button

1x Rotary Encoder

1x Rotary Poti

bis auf den Dual-Button sind es im Grunde nur entsprechende Ausschnitte / Bohrungen in der Bedienfeld-Abdeckung. Siehe die Grob-skizze unten.

Ich würde vermuten dass mir die reinen Abdeckungen ausreichen würden, hast Du auch ein Bild wie diese Abdeckungen ohne Gehäuse aussehen (evtl wenn sie auf dem Dual-Button liegen) ?

Selber steht mir kein 3D Drucker zur Verfügung.

Daher würde ich gerne auf Dein Angebot zurück kommen.

Jetzt und hier ein große Lob an das gesamte Tinkerforge TEAM 🙂

viele Grüße Stefan

bearbeitet March 2, 2020 at 19:35 von StefanOHAN

Teddy · March 2, 2020 at 19:39

Ähm ne nen Bild von den einzelnen Teilen hab ich jetzt so nicht zur Hand. Aber mit deinen Bildern kann ich mir schon ganz gut vorstellen was du brauchst. Ich ändere dir das Modell dann ab, ist nicht viel Aufwand. Ich würde aber sagen für die Besprechung der Einzelheiten ziehen wir entweder in den Projekte Thread um oder klären das per Mail. Das passt hier nicht so ganz in den OpenHab Thread

StefanOHAN · March 3, 2020 at 16:43

Hallo Tim,

klar macht mehr Sinn das Thema über Privat Nachrichten zu klären, hab Dir hier über die Forum-Funktion einen PV-Nachricht gesendet, ich hoffe Sie ist angekommen.

viele Grüsse

Stefan

StefanOHAN · March 15, 2020 at 17:01

Hallo Erik,

kurzer Update

ich habe diese Woche meinen zusätzlichen Komponenten bekommen

1 x Air Quality Bricklet

1 x PTC V2 mit Sensor

durch den zusätzlichen Masterbrick war ich auch in der Lage ein altes Temperatur Bricklet (HW Version 1.1.0) in die Konfiguration auf zu nehmen.

Alle Bricklets funktionieren mit dem Binding und liefern Werte, allerdings habe ich bis jetzt noch keine Action mit diesen Bricklets getestet.

Ich vergleich gerade mal wie die verschieden Temperatur-Sensoren Daten liefern. Bist jetzt habe ich den Eindruck dass die Werte des PTC 2 die des Humidty V2 (Temperatur) und die des Air Quallity (Temperatur) sehr nahe zusammen liegen. Die TH-Sensoren liegen näher an den Werten des alten Temperatur Bricklets.

Was mir auch gut gefällt ist, dass am PTC V2 ein Offset eingestellt werden kann. Vermutlich werde ich einen Kombination aus Air Quallity Bricklet für innen, PTC & Humidity V2 Bricklet für Außen einsetzten.

viele Grüsse

Stefan

amos · March 20, 2020 at 17:01

Hallo Allerseits,

ich habe das Tinkerforge-binding in der Version 1 mit mehreren Typ A Steckdosen am laufen. Jetzt habe ich den Beispielen in diesem Thread folgend daran gemacht zu der V2 zu migrieren. Klappt mit der ersten Dose auch wunderbar - nur jede weitere mit dem selben Hauscode bleibt "uninitialized" Meine V1 Config sieht folgendermaßen aus:

tinkerforge:rs1.uid=v5k
tinkerforge:rs1.type=bricklet_remote_switch
tinkerforge:rs1.typeADevices=rsg1 rsg2 rsg3 rsg4 rsg5 rsg6

tinkerforge:rs_garten.uid=v5k
tinkerforge:rs_garten.subid=rsg1
tinkerforge:rs_garten.type=remote_switch_a
tinkerforge:rs_garten.houseCode=18
tinkerforge:rs_garten.receiverCode=1
tinkerforge:rs_garten.repeats=5

tinkerforge:rs_garten2.uid=v5k
tinkerforge:rs_garten2.subid=rsg2
tinkerforge:rs_garten2.type=remote_switch_a
tinkerforge:rs_garten2.houseCode=18
tinkerforge:rs_garten2.receiverCode=2
tinkerforge:rs_garten.repeats=6

usw.

wenn ich aber eine weitere Typ A Steckdose mit PaperUI anlege, funktioniert das nicht. Wenn ich bei der ersten (funktionierenden den Empfängercode ändere, spricht auch die korrespondierende Dose an. Wo liegt mein Fehler?

LG

Andreas

bearbeitet March 20, 2020 at 17:08 von amos

amos · March 20, 2020 at 17:15

vor 13 Minuten schrieb amos:

Hallo Allerseits,

ich habe das Tinkerforge-binding in der Version 1 mit mehreren Typ A Steckdosen am laufen. Jetzt habe ich den Beispielen in diesem Thread folgend daran gemacht zu der V2 zu migrieren. Klappt mit der ersten Dose auch wunderbar - nur jede weitere mit dem selben Hauscode bleibt "uninitialized" Meine V1 Config sieht folgendermaßen aus:

tinkerforge:rs1.uid=v5k
tinkerforge:rs1.type=bricklet_remote_switch
tinkerforge:rs1.typeADevices=rsg1 rsg2 rsg3 rsg4 rsg5 rsg6

tinkerforge:rs_garten.uid=v5k
tinkerforge:rs_garten.subid=rsg1
tinkerforge:rs_garten.type=remote_switch_a
tinkerforge:rs_garten.houseCode=18
tinkerforge:rs_garten.receiverCode=1
tinkerforge:rs_garten.repeats=5

tinkerforge:rs_garten2.uid=v5k
tinkerforge:rs_garten2.subid=rsg2
tinkerforge:rs_garten2.type=remote_switch_a
tinkerforge:rs_garten2.houseCode=18
tinkerforge:rs_garten2.receiverCode=2
tinkerforge:rs_garten.repeats=6

usw.

wenn ich aber eine weitere Typ A Steckdose mit PaperUI anlege, funktioniert das nicht. Wenn ich bei der ersten (funktionierenden den Empfängercode ändere, spricht auch die korrespondierende Dose an. Wo liegt mein Fehler?

LG

Andreas

sorry - das Problem hat sich durch ein reboot erledigt!

LG

amos · March 22, 2020 at 13:31

Am 3.2.2020 um 11:51 schrieb rtrbt:

Sorry, deinen Post hatte ich übersehen.

Was klappt dabei noch nicht? Die Command-Channels sind Strings statt Switches, da es keinen Rückkanal von den Steckdosen gibt: openHAB kann nicht abfragen, ob eine Dose gerade an oder aus ist, also kann ich bei einem Switch nicht den Initialzustand setzen. Command-Channels (die in der PaperUI Buttons erzeugen) sind intern String-Channels. Du kannst z.b. aus Rules StringCommands "ON" oder "OFF" schicken um die Dose zu schalten.

Hallo Erik,

wie muss der Befehl in einer Rule aussehen? Item.sendCommand(ON) funktioniert bei mir leider nicht.

LG

Andreas

rtrbt · March 23, 2020 at 08:06

Moin Andreas,

Item.sendCommand("ON")

sollte funktionieren.

amos · March 23, 2020 at 11:31

vor 3 Stunden schrieb rtrbt:
Moin Andreas,
Item.sendCommand("ON")
sollte funktionieren.

Hallo Erik,

funktioniert - vielen Dank!

LG

Jerome · March 26, 2020 at 17:56

Hallo

Ich glaube da ist ein Fehler im Industrial Dual Analog In beim Openhab im Brick Viewer funktioniert es einwandfrei.

Im Moment habe ich nur Channel 0 im Betrieb, trotzdem zeigt es im OpenHab bei beiden Channels das selbe an.

Kannst du das Bestätigen?

rtrbt · March 27, 2020 at 08:10

Moin,

Hast du das Problem mit einem Industrial Dual Analog In 1.0 oder 2.0? Ich habe es hier mit dem 2.0 getestet und es funktioniert so wie es soll. Hast du eventuell beide Channels auf das selbe Item registriert?

rtrbt · March 27, 2020 at 16:24

Moin,

Es gibt jetzt einen ersten Prototypen der openHAB-Dokumentation. Erstmal nur auf Englisch und noch ohne die allgemeinen Dinge wie Installationsanleitung, Beispiele usw.

Falls noch device-spezifische Dinge fehlen, oder euch etwas anderes auffällt, bitte melden.

Gruß,
Erik

Jerome · March 27, 2020 at 22:57

14 hours ago, rtrbt said:

Moin,

Hast du das Problem mit einem Industrial Dual Analog In 1.0 oder 2.0? Ich habe es hier mit dem 2.0 getestet und es funktioniert so wie es soll. Hast du eventuell beide Channels auf das selbe Item registriert?

Habe ich schon mehrmals überprüft, aber es ist 0 und 1. Die Version ist 2.0. Ich schaue nochmals.

StefanOHAN · March 29, 2020 at 09:22

Hallo Erik

ich habe mir für ein paar meiner Bricklest Deine neue Doku angeschaut, Sie gefällt mir gut.

Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen.

Hintergrund der Frage anhand des Remote Switch Bricklet betrachtet

Du schreibst:

Zitat

>>To switch a type A socket you have to give the house code, receiver code and the state (on or off) you want to switch to

Wenn ich jetzt nicht über das Forum Deine Beiträge gelesen hätte, wäre mir nicht klar gewesen dass ich bei dem Channel-verlinktem String-Item (für Socket-A), dem String-Item „on“ oder „off“ übergeben muss. (also als String)

Beispiel einer hilfreichen Zusatzinformation in der Dokumentation :

Zitat

Item >> String remoteSteckdose1 "gesendeter Befehl an [%s]" (TestFf) {channel="tinkerforge:remotesockettypea:21ec0b7d:RemoteSocketTypeACommand"}

Rule >> remoteSteckdose1.sendCommand(„on“)

Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht.

Generell bin ich für jeden Hinweis dankbar um Fehler zu finden oder zu vermeiden.

Ich könnte mir vorstellen, dass diese zusätzlichen Informationen / Beispiele Anfängern oder "Teilzeit" Openhab-Anwendern helfen würden (zumindest geht es mir so).

An dieser Stelle nochmal Danke an Deine tolle Arbeit

Viele Grüße

Stefan

rtrbt · March 30, 2020 at 09:03

Moin,

23 hours ago, StefanOHAN said:

Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen.

Beispiele sind eine interessante Frage, das ist nicht unbedingt bei jedem Device nötig, z.B. ein Temperatursensor funktioniert ja einfach so. Ich tendiere im Moment dazu, als Beispiel für jedes Bricklet nur das Grundgerüst, damit man die Actions benutzen kann zu generieren und zusätzlich die etwas komplizierteren Beispiele die teilweise ja hier im Thread schon gewachsen sind zu übernehmen.

Das Remote Switch ist ein schwieriger Fall. Ich muss dem Doku-Generator noch beibringen, mit den speziellen Devices (Den Sockets, aber auch der Wetterstation usw.) umzugehen. Prinzipiell ist die Doku aber korrekt, du kannst mit den Actions direkt schalten ohne eigene Devices anzulegen. Das ist nur schwieriger weil du händisch dafür sorgen musst, dass immer nur ein Schaltvorgang gleichzeitig läuft.

23 hours ago, StefanOHAN said:

Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht.

Bezüglich der REFRESHs: Das sollte eigentlich nicht mehr nötig sein, weil die Channel sich periodisch selbst aktualisieren. Hast du da noch Probleme bei irgendeinem Bricklet? Ich schreibe das trotzdem mal in die Doku, es gibt eventuell Anwendungsfälle, wo man das kontrollieren will, wann der Channel sich aktualisiert.

StefanOHAN · March 30, 2020 at 09:29

Hallo Erik,

ich gebe Dir recht man braucht nicht für jedes Bricklet ein Beispiel.

Das Remot Switch wäre eines, oder Hinweise wenn zum Ausführen ein Text-String an das Item übergeben werden muss.

Beim LCD 128x64 ClearDisplay schreibst Du in Deiner Doku dass ein beliebiger String übergeben werden kann, in dieser Art die Hinweise.

viele Grüsse

Stefan

matthiask · April 4, 2020 at 11:33

Hallo zusammen,

vielen Dank für die Entwicklung des Bindings.

Ich nutze ein Ledstrip Bricklet (V1) mit der Beta20 und kann über den Channel BrickletLEDStripLEDValues leider nur eine LED gleichzeitig setzen.
Aus meiner Sicht liegt das an der Klasse org.eclipse.smarthome.binding.tinkerforge.internal.device.Helper. In der Methode parseLED1Values wird die Variable nextInsert in der Schleife nicht erhöht.

Danke,
Matthias

rtrbt · April 8, 2020 at 11:09

Moin,

Beta 21 ist jetzt im Post oben. Bitte darauf achten, dass sie von den Java-Bindings (als Maven-Package, ist auch in der Zip enthalten) abhängen, die auch in das Addons-Verzeichnis gelegt werden müssen.

Die nächsten Wochen werde ich an einem anderen Projekt arbeiten müssen, das etwas dringender geworden ist. Die Bindings nähern sich aber sowieso langsam einem "fertigen" Zustand. Ich würde deshalb die Entwicklung für die nächsten Wochen erstmal ruhen lassen, und nur nach und nach die deutsche Dokumentation schreiben. Dabei sehe ich mir nochmal die Modellierung aller Devices an, und verpasse ihr einen Feinschliff, insbesondere für die möglichst einfache Verwendung mit Channels, da kompliziertere Anwendungsfälle mit Actions abgebildet werden können. Zum Beispiel werde ich den LEDStrip Values Channel so umstellen, dass man mit einem ColorPicker-Item alle angeschlossenen LEDs konfigurieren kann. Nebenbei kümmere ich mich dann auch darum, wie die Bindings nach dem Ende der Betaphase zur Verfügung gestellt werden (Lies: ob sie in die openHAB-Distribution integriert werden).

Was mir sehr helfen würde ist, wenn Ihr alle Bugs, die im Betrieb auftreten nochmal hier erwähnt, damit möglichst nichts übersehen wird.

@matthiask Sorry für die späte Antwort, du hast da vollkommen recht. Teste bitte nochmal mit Beta 21, da ist der Fix drin. Da du einer der mir bisher bekannten Nutzer des LED-Strip Bricklets bist: würde es dir für deinen Anwendungsfall reichen, wenn du alle LEDs auf einmal mit einem Color-Item kontrollieren könntest, oder machst du kompliziertere Dinge? Hast du dir schon die Actions des Bricklets angesehen?

Gruß und Frohe Ostern,
Erik

matthiask · April 9, 2020 at 15:04

Hallo @rtrbt,

danke für das schnelle Feedback.

Der Fix hat auf der einen Seite geholfen, d. h. ich kann jetzt mehrere LED's addressieren. Allerdings passt der Startindex nun nicht mehr, ich bekomme jetzt nur noch Zugriff auf jede dritte LED. Das liegt daran, dass die Methode parseLEDValueIndex nun mit 3 oder 4 multipliziert. Aus meiner Sicht war die vorherige Implementierung dieser Methode aus beta20 besser:

public static int parseLEDValueIndex(String string, Logger logger) {
		try {
            return Integer.valueOf(string.split(",")[0]);
        } catch (Exception e) {
            logger.warn("Could not parse LED Value command: {}", e.getMessage());
            return 0;
        }

Grundsätzlich fände ich es gut, wenn man auch über einen Colorpicker direkt zugreifen kann. Gerne umstellen.

Persönlich möchte ich auch die Einzel-LED's steuern, das mache ich aktuell über den String LEDValues (vielleicht müsste man den nicht unbedingt entfernen, wenn der Colorpicker kommt). Ich bin aber auch offen, die Steuerung über die Actions zu machen. Mit der vorhandenen Action brickletLEDStripSetRGBValues hatte ich probiert, habe damit aber keinen Erfolg gehabt und dann erstmal das String-Attribut mit einer Xtend-Function verwendet.

val org.eclipse.xtext.xbase.lib.Functions$Function6 setColorString = [
    int startIndex, int endIndex, int red, int green, int blue, org.openhab.core.library.items.StringItem tink_ledstrip |
        
        val String ledstrip = ""
        val ledcounter = 0
        val ledindex = startIndex - 1
        
        for(val i=startIndex-1;i<endIndex;i++){
                                                
            ledcounter++
            ledstrip = ledstrip +","+ String.valueOf(blue) + ","+String.valueOf(green)+","+String.valueOf(red)
            
            if (ledcounter % 16==0||ledindex+ledcounter==endIndex){
                ledstrip = String.valueOf(ledindex)+ledstrip
                sendCommand(tink_ledstrip,ledstrip)
                ledstrip = ""
                ledcounter = 0
                ledindex = i+1
            } 
        }
        
]
                                                
 
rule "Lamp LEDStrip Selector Inner" 
when
   Item TINK_LAMP_COLOR_INN changed
then
    var HSBType currentState
    currentState = TINK_LAMP_COLOR_INN.state
    
    var r = (currentState.getRed * 255 / 100).intValue
    var g = (currentState.getGreen * 255 / 100).intValue
    var b = (currentState.getBlue * 255 / 100).intValue
    
    //now setting the hsb value to tinkerforge ledstrip  
    setColorString.apply(9,13,r,g,b,TINK_LAMP_LED)
    setColorString.apply(16,20,r,g,b,TINK_LAMP_LED)
    setColorString.apply(23,28,r,g,b,TINK_LAMP_LED)
    setColorString.apply(31,35,r,g,b,TINK_LAMP_LED)
    setColorString.apply(38,42,r,g,b,TINK_LAMP_LED)  
      
end

Kommt zu den LED Strip Actions noch etwas mehr Doku bzgl. Parametern? Dann würde ich da nochmal weiter probieren.

Wenn ich mir noch was bzgl. Modellierung bei den Devices wünschen könnte...
Habe noch ein NFC/RFID Bricklet. Weiter oben im Thread war ein Beispiel bzgl. NFC Scan Loop. Ich finde die Xtend - Skripte grundsätzlich schon recht hakelig, da wäre das mit dem Timer und Tag nachlesen vielleicht ganz gut als openHAB Event modelliert...

Danke, Matthias

bearbeitet April 9, 2020 at 17:14 von matthiask

rtrbt · April 10, 2020 at 07:44

Moin,

Sorry, beim LEDValueIndex hast du vollkommen recht, da habe ich den Bug für das LED Strip V2 gefixt und es damit für das alte Bricklet wieder kaputt gemacht. Das LED Strip V2 addressiert auf Farb-Ebene.

16 hours ago, matthiask said:

Mit der vorhandenen Action brickletLEDStripSetRGBValues hatte ich probiert, habe damit aber keinen Erfolg gehabt und dann erstmal das String-Attribut mit einer Xtend-Function verwendet.

Was klappte mit der Action nicht?

16 hours ago, matthiask said:

Kommt zu den LED Strip Actions noch etwas mehr Doku bzgl. Parametern?

Findet sich hier

16 hours ago, matthiask said:

Habe noch ein NFC/RFID Bricklet. Weiter oben im Thread war ein Beispiel bzgl. NFC Scan Loop. Ich finde die Xtend - Skripte grundsätzlich schon recht hakelig, da wäre das mit dem Timer und Tag nachlesen vielleicht ganz gut als openHAB Event modelliert...

Es gab da mal die Überlegung, einen Simple-Mode direkt in die Firmware einzubauen, dann aber vermutlich nur für das neuere NFC-Bricklet oder einen eventuellen Nachfolger. (Der Flash ist schon recht voll, vorallem beim alten NFC-RFID). Deshalb würde ich da erstmal ungern eine openHAB-spezifische Lösung bauen.

Du kannst übrigens anstelle der Xtend-Skripte auch die experimentelle Rule-Engine verwenden, mit der du in diversen "richtigen" Programmiersprachen skripten kannst.

matthiask · April 12, 2020 at 06:50

Hallo Erik,

danke für Dein Feedback!

Am 10.4.2020 um 09:44 schrieb rtrbt:

Was klappte mit der Action nicht?

Beim Aufruf kommen immer Fehler. Die Parameterkonvertierung klappt nicht. Sowas wie

Rule 'Test Rule for Ledstrip': Primitive conversion failed: argument type mismatch

Die Action hat als Parameter 3x short[] für die Farben. Beim LedBricklet V2 ist es übrigens ein int[] genauso wie bei den anderen API-Beispielen aus der Tinkerforge-openHAB-Doku. Falls Du da noch einen Tip für mich hast... Wäre aber nicht schlimm, da ich mir erstmal mit dem String-Channel helfen kann.

Am 10.4.2020 um 09:44 schrieb rtrbt:

Es gab da mal die Überlegung, einen Simple-Mode direkt in die Firmware einzubauen, dann aber vermutlich nur für das neuere NFC-Bricklet oder einen eventuellen Nachfolger. (Der Flash ist schon recht voll, vorallem beim alten NFC-RFID). Deshalb würde ich da erstmal ungern eine openHAB-spezifische Lösung bauen.

Alles gut. Wenn ich mittels der klassischen Java-API zugreife (BrickletNFCRFID.StateChangedListener), klappt das Lesen der Tags dauerhaft einwandfrei. Wenn ich das Xtend Scan Loop Beispiel verwende, dann geht das Lesen des Tags einige Male, irgendwann kommen dann aber Fehler im Log und er liest die Tags nicht mehr.

2020-04-11 17:45:20.690 [ERROR] [org.quartz.core.JobRunShell         ] - Job DEFAULT.Timer 51 2020-04-11T17:45:20.687+02:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  <XFeatureCallImplCustom>.brickletNFCRFIDRequestTagID(<XCastedExpressionImpl>)
} ] threw an unhandled Exception:
java.lang.reflect.UndeclaredThrowableException: null
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [bundleFile:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [bundleFile:?]
Caused by: com.tinkerforge.InvalidParameterException: Got invalid parameter for function ID 1
        at com.tinkerforge.DeviceBase.sendRequest(DeviceBase.java:247) ~[?:?]
        at com.tinkerforge.BrickletNFCRFID.requestTagID(BrickletNFCRFID.java:163) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:36) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:42) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_152]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_152]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_152]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_152]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1175) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1150) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1136) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1081) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:861) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:231) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:458) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:239) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:201) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:29) ~[?:?]
        ... 4 more
2020-04-11 17:45:20.705 [ERROR] [org.quartz.core.ErrorLogger         ] - Job (DEFAULT.Timer 51 2020-04-11T17:45:20.687+02:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  <XFeatureCallImplCustom>.brickletNFCRFIDRequestTagID(<XCastedExpressionImpl>)
} ] threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception.
        at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [bundleFile:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [bundleFile:?]
Caused by: java.lang.reflect.UndeclaredThrowableException
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[?:?]
        ... 1 more
Caused by: com.tinkerforge.InvalidParameterException: Got invalid parameter for function ID 1
        at com.tinkerforge.DeviceBase.sendRequest(DeviceBase.java:247) ~[?:?]
        at com.tinkerforge.BrickletNFCRFID.requestTagID(BrickletNFCRFID.java:163) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:36) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:42) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_152]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_152]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_152]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_152]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1175) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1150) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1136) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1081) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:861) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:231) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:458) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:239) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:201) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:29) ~[?:?]
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[?:?]
        ... 1 more
2020-04-11 17:45:21.677 [ERROR] [org.quartz.core.JobRunShell         ] - Job DEFAULT.Timer 52 2020-04-11T17:45:21.668+02:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  <XFeatureCallImplCustom>.brickletNFCRFIDRequestTagID(<XCastedExpressionImpl>)
} ] threw an unhandled Exception:
java.lang.reflect.UndeclaredThrowableException: null
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [bundleFile:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [bundleFile:?]
Caused by: com.tinkerforge.InvalidParameterException: Got invalid parameter for function ID 1
        at com.tinkerforge.DeviceBase.sendRequest(DeviceBase.java:247) ~[?:?]
        at com.tinkerforge.BrickletNFCRFID.requestTagID(BrickletNFCRFID.java:163) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:36) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:42) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_152]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_152]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_152]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_152]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1175) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1150) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1136) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1081) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:861) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:231) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:458) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:239) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:201) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:29) ~[?:?]
        ... 4 more
2020-04-11 17:45:21.714 [ERROR] [org.quartz.core.ErrorLogger         ] - Job (DEFAULT.Timer 52 2020-04-11T17:45:21.668+02:00: Proxy for org.eclipse.xtext.xbase.lib.Procedures$Procedure0: [ | {
  <XFeatureCallImplCustom>.brickletNFCRFIDRequestTagID(<XCastedExpressionImpl>)
} ] threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception.
        at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [bundleFile:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [bundleFile:?]
Caused by: java.lang.reflect.UndeclaredThrowableException
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[?:?]
        ... 1 more
Caused by: com.tinkerforge.InvalidParameterException: Got invalid parameter for function ID 1
        at com.tinkerforge.DeviceBase.sendRequest(DeviceBase.java:247) ~[?:?]
        at com.tinkerforge.BrickletNFCRFID.requestTagID(BrickletNFCRFID.java:163) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:36) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.device.BrickletNFCRFIDActions.brickletNFCRFIDRequestTagID(BrickletNFCRFIDActions.java:42) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_152]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_152]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_152]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_152]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1175) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1150) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1136) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1081) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:861) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:231) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:458) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:239) ~[?:?]
        at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:215) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:201) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.ClosureInvocationHandler.doInvoke(ClosureInvocationHandler.java:46) ~[?:?]
        at org.eclipse.xtext.xbase.interpreter.impl.AbstractClosureInvocationHandler.invoke(AbstractClosureInvocationHandler.java:29) ~[?:?]
        at com.sun.proxy.$Proxy1678.apply(Unknown Source) ~[?:?]
        at org.eclipse.smarthome.model.script.internal.actions.TimerExecutionJob.execute(TimerExecutionJob.java:48) ~[?:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[?:?]
        ... 1 more

Danke, viele Grüße
Matthias

StefanOHAN · April 13, 2020 at 14:37

Hallo Erik,

ich habe das neue Beta-21 Binding eingespielt, nach einem System (OS/Openhab) update funktioniert „fast“ alles wieder.

Folgende Punkte sind mir aufgefallen

>> LCD 128x64

Wenn ich einen einzelnen Tab mit der action „lcdActions128x64.brickletLCD128x64RemoveGUITab(3)“ löschen will (es ist egal ob Tab 0 / 1 / 2 oder 3)

erhalte ich folgende Fehlermeldung (mit der alten Beta-20 gab es da keine Probleme)

Zitat

„[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Display Menue-Aufbau': Expected response of 8 byte for function ID 39, got 9 byte instead“

Wenn ich hingegen alle Tabs mit „lcdActions128x64.brickletLCD128x64RemoveGUITab(255)“ lösche, gibt es keine Fehlermeldung und alle Tabs werden gelöscht.

Remove „GUIbutton“ und Remove „GUISlider“ funktionieren ohne Probleme.

>> brickletIO16GetEdgeCount (nur für das alte IO-16 hw-Version 1.1.0)

das auslesen des EdgeCount funktioniert, jedoch bekomme ich den alten Fehler wenn ich den EdgeCount zurücksetzen will.

Für das IO-16 Bricklet 2.0 / Industrial Digital In 4 Bricklet 2.0 / IO-4 Bricklet 2.0 funktioniert es ohne Probleme.

Wo liegt mein Fehler ? (ich habe nach der neuen Doku erst einen short dann auf verdacht mit einen int gearbeitet)

>> Aufruf in der Rule Version A mit short

Zitat

val ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:wip")

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1, true).get("count") as short

>> Aufruf in der Rule Version B mit int

Zitat

val ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:wip")

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1, true).get("count") as int

>>Fehlermeldung

Zitat

2020-04-13 15:33:38.137 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'teste edgecount': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

für mich sieht das nach so einen Type-Casting Problem von JAVA aus. Aber wie müsse ich es richtig eintragen ?

Noch ein Hinweis zur Deiner neuen Dokumentation:

In Deiner neuen Doku für das NFC-Bricklet ist mir bei dem Beispiel ein kleiner Fehler aufgefallen.

Dort steht in Zeile 15

Zitat

>>val stateVal = newState as Number

müsste es nicht lauten

Zitat

>>val stateVal = newState.state as Number

Weiter schreibst du als Kommentar im Beispiel

Zitat

„For this example create an item linked to the state channel of your NFC Bricklet“

könnte Du im Beispiel noch zusätzlich hinweisen, dass es sich bei „newState“ (in Zeile 15) um diese linked item handelt ?

Ansonsten funktioniert soweit alles wie gehabt.

Viele Grüße

Stefan

bearbeitet April 13, 2020 at 14:43 von StefanOHAN

rtrbt · April 20, 2020 at 13:20

Moin,

@StefanOHAN

Dein LCD128x64-Problem war ein Firmware-Bug: DIe Bindings nutzen die neue Version der Java-Bindings, die explizit die Länge der Antwortpakete prüft. Das LCD hat aber fälschlicherweise bei dem remove eines spezifischen Tabs nicht wie von den Bindings erwartet ein leeres Paket zurückgeschickt, sondern die Nummer des Tabs mit hineingeschrieben. Das war ein Byte zuviel, deshalb die Fehlermeldung.

Bei dem IO-16 1.0 musst du den Parameter für GetEdgeCount nach short casten, dann sollte es funktionieren:

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(1 as short, true).get("count") as short

Das NFC-Beispiel sehe ich mir nochmal an, danke dafür!

@matthiask

Das muss ich mir nochmal in Ruhe ansehen, war die letzte Woche im Urlaub. Ich melde mich dazu nochmal.

Gruß,
Erik

Betaversion der openHAB-Bindings

Recommended Posts

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

rtrbt

StefanOHAN

StefanOHAN

Posted Images

Join the conversation