theo

Ein neuer Snapshot ist da: https://bintray.com/theoweiss/generic/download_file?file_path=org.openhab.binding.tinkerforge-2.5.0-12-SNAPSHOT.jar

Support für:

* LCD20x4

* OLED128x64

* OLED128x64V2

* OLED64x48

Die Bedienung des display-Channels ist genauso wie beim LCD128x64 https://github.com/theoweiss/openhab-tinkerforge2-configuration-examples#display.

Das LCD hat zusätzlich noch 3 Button-Channels. Actions für clearDisplay o.ä. werden nachgeliefert.

Beispielregeln gibt es noch keine, ihr könnt euch aber an den alten Beispielen orientieren: https://github.com/theoweiss/openhab2-tinkerforge-configuration-examples/blob/master/weatherstation/rules/tf.rules

Was dort mit "TFNUM<20>" formuliert ist, ist jetzt "{2,0}".

Viel Spaß damit.

Hallo Tinkerforger,

ich versuche das NFC Bricklet im Readermodus als Tag-Scanner zu verwenden.  Leider gelingt mir das Anhand des Beispielcodes aus der Doku nicht. Es kommt einfach kein Leseloop in Gang.

Ausserdem fehlt bei der readerStateChanged Methode die Doku für den "idle" Wert: readerStateChanged(int state, boolean idle)

Für das NFC/RFID Bricklet habe ich das Ganze analog zu eurem Beispiel hinbekommen. Dort wird der "idle" Wert verwendet um den Loop am Laufen zu halten.

Könnt ihr mir ein bisschen auf die Sprünge helfen.

Gruß,

Theo

Leider nur ein kurze Antwort von mir, da ich seit 2 Wochen und noch bis Ende April weniger Zeit habe, da ich gerade am Haus renovieren bin. Also auch nicht wundern, wenn Antworten etwas dauern.

- das NFC-Bricklet funktioniert noch nicht richtig, da habe ich Probleme mit dem TF-API, da muss ich noch die TinkerForger fragen wie das richtig gemacht wird.

- das LCD20x4 wird als nächstes kommen und dann die OLEDs (@onkelKalle)

- GPS V2 und das GPS kommen auf jeden Fall, das wird nicht so schwierig sein

@StefanOHAN ich bin sehr gespannt auf deine Tests mit dem 128x64 LCD Bricklet. Das NFC funktioniert leider noch nicht (siehe oben).

Zum Thema den Daten auf dem NFC-Tag: ich habe bisher nicht geplant die auszulesen, da es - soweit ich das verstehe - sehr Tag-spezifisch ist, wie die Daten auszuwerten sind. Ich könnte das aber in Zukunft über eine Action anbieten, so dass man das über ein Rule machen kann. Diese Regel muss dann nicht so generisch implementiert sein, da der Regelschreiber weiß welchen Tag-Typ er einsetzt. Prinzipiell ist dein Ansatz mit dem Passwort naheliegend, sollte aber soweit ich das verstehe nur mit einem Tag vom Typ Mifare Classic gemacht werden. Bei diesen Tags muss sich der Leser vor dem Zugriff auf die NDEF-Daten beim Tag authentifizieren (was das Binding aber bisher nicht kann, vielleicht kann ich das irgendwann mit Actions anbieten?). Andernfalls hast du das Problem, dass jeder Leser - also z.B. ein x-beliebiges Android Smartphone in der Nähe - die Passwort-Daten auslesen und kopieren kann. Frag mich jetzt nicht wie sicher die Mifare Sachen sind, soweit ich mich erinnere ist das auch nicht "bullet proof". Ums kurz zu sagen: auf die Schnelle wird das mit dem Binding nicht vernünftig zu realisieren sein.

Eine Liste der aktuell unterstützten Bricklets findet ihr jetzt hier: https://github.com/theoweiss/openhab-tinkerforge2-configuration-examples/blob/master/README.md

Und natürlich vielen Dank fürs Testen an @sihui, @Jerome. @peter.boehm, @onkelKalle und @StefanOHAN.

Der Frühlingsanfang-Snapshot mit Support für das Bricklet LCD128x64 ist da:

https://bintray.com/theoweiss/generic/download_file?file_path=org.openhab.binding.tinkerforge-2.5.0-11-SNAPSHOT.jar

LCD128x64 ist ziemlich cool und bietet viele Möglichkeiten, deshalb ist die Erklärung diesmal etwas ausführlicher und openHAB Actions kommen ins Spiel. Ihr findet etwas Doku hier im README.md:

https://github.com/theoweiss/openhab-tinkerforge2-configuration-examples

Der einzige Nachteil ist, dass ihr vermutlich eine openHAB 2.5-SNAPSHOT Installation braucht um das Binding zu Testen. Mittlerweile haben sich einige Neuerungen an openHAB ergeben, so dass der Code vermutlich nur noch mit aktuellen Versionen läuft. Ich schreibe "vermutlich", da ich keine Zeit hatte das zu verifizieren. Wenn es also jemand ausprobiert, gerne Rückmeldung geben.

Viel Spaß beim Experimentieren.

Theo

Andreas,

ich vermute mittlerweile brauchst du mindestens eine openHAB 2.4 und ab meinem nächsten Snapshot vermutlich sogar openHAB 2.5.0-Snapshot Installation. Am besten machst du dir eine dedizierte Testinstallation.

Gruß,

Theo

Hallo Andreas,

es liegt vermutlich an 2.5.0-10. In 2.5 hat sich durch das Ende von ESH mittlerweile einiges verändert. Ich baue zwar auch gegen 2.5, aber das ist ein moving target. Bisher hat das, was ich baue mit 2.4 und vermutlich auch 2.5 funktioniert, aber das könnte gerade in den letzten zwei Wochen zerbrochen sein. Mir ist nicht ganz klar, was dein 2.5.0-10 ist. Wie hast du das installiert? Weißt du von wann der Build ist?

Gruß,

Theo

Hallo Stefan,

ja klar wird es Unterstützung für das LCD 128x64 geben. Über die Details muß ich allerdings noch etwas nachdenken.

Gruß,

Theo

Sehr cool! Wahnsinn.

Eine Frage hätte ich spontan: das IO-16 und das PTC-Bricklet, welche Aufgaben übernehmen die?

Ach und noch eine: wie schaffst du es alle Eingabemöglichkeiten mit 12 Tasten umzusetzen? Gibt es da eine Menu-Wechsel-Taste? Deine Rules würden mich schon interessieren - andere vermutlich auch. Hast du schon mal darüber nachgedacht, das in ein GitHub-Repo zu packen? Oder stehen deine Pins in der Rule, gibt es da überhaupt andere Möglichkeiten?

Auf jeden Fall vielen Dank fürs Teilen.

Gruß,

Theo

Hallo StefanOHAN,

deine Projektvorstellung werde ich mir gleich mal durchlesen.

Was ich durch das eintauschen des Motion-Dedector V2 gesehen habe, ist dass Du die 3 LED jetzt als Schalter (dimmbar) in der Konfiguration hast 

Leider haben die 3 LED bei ein oder ausschalten nicht reagiert (blieben dunkel) auch wenn die die Dimmung verstellt habe.

Ja da habe ich nur den Typ geändert, sonst ist noch keine Funktionalität implementiert, da ich noch sehen muss wie ich das mache. Denn mit dem TF-API kann ich nur alle drei LEDs gleichzeitig schalten. Das kann ich so nicht einfach auf openHAB-Channel abbilden.

Ich habe über 6 Stunden den 2-Stapel (der über die RS485 Extension angebunden ist) Spannungslos gelassen. Es wurde kein Offline für dessen Bricklets unter Things angezeigt. Nach dem Einschalten der Spannungsversorgung funktionierten aber alle Komponenten.

Das wird nicht OFFLINE gehen, da das TF-API in diesem Fall nur das connected aber nicht den disconnect meldet. Der BrickViewer verhält sich analog, das Bricklet bleibt sichtbar, bekommt aber keine Updates.

StefanOHAN,

probier doch mal aus ob mit diesem Snapshot dein rf485-Problem behoben ist:  https://bintray.com/theoweiss/generic/download_file?file_path=org.openhab.binding.tinkerforge-2.5.0-10-SNAPSHOT.jar

Hallo StefanOHAN,

danke fürs schnelle Feedback. Das klingt ja schon mal nicht so schlecht.

Laut TF-Doku sollte das mit dem RS485 mit meinem Code in beiden Fällen funktionieren (https://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/RS485_Extension.html#rs485-busmodifikation). Ich werde das mal testen, ich habe ein RS485 hier.

Für das mit dem Switch/Contact sehe ich keine schnelle Lösung, da muss ich etwas in den OH-Innereien kramen.

Gruß,

Theo

Hallo Borg,

danke, das hat schon geholfen. Ich habe einfach die Zeilen im Code getauscht und zuerst auf input konfiguriert, dann funktioniert es. Übrigens scheint es das IO16v2 an dieser Stelle nicht so genau zu nehmen, denn dort hatte ich bei gleichem Code das Problem nicht.

Gruß,

Theo

Helau! Neuer Snapshot mit Support für:

io16

io16v2

io4

io4v2

loadcellv2

Die GPIO Konfiguration ist im PaperUI am Channel (nicht am Thing), dort könnt ihr "input" oder "output" konfigurieren und auch alles Weitere.

Ausserdem hat sich einiges an der Konfiguration bestehender Bricklets geändert: CallbackPeriod und Threshold werden jetzt - wenn vorhanden - an den Channels und nicht am Thing konfiguriert.

Ansonsten gibt es sehr viele Änderungen unter der Decke, Regressions sind also nicht unwahrscheinlich.

https://bintray.com/theoweiss/generic/download_file?file_path=org.openhab.binding.tinkerforge-2.5.0-9-SNAPSHOT.jar

Ich bin wirklich gespannt auf euere Testergebnisse.

So wie ich das verstehe, ist das eigentlich coole an TriggerChannels vom Typ system.rawbutton, dass es dafür ein profile gibt und es damit möglich ist ohne eine Rule einen Channel (z.B. einen RelayChannel) mit dem Button zu verknüpfen. Siehe:

https://www.openhab.org/docs/configuration/items.html#profiles

Instead of using this Rule, you can also use the rawbutton-toggle-switch Profile in combination with Multi-Channel Linking:

 

Color Bedroom_Light { channel="hue:0210:1:bulb1:color", channel="serialbutton:button:mybutton:button" [profile=rawbutton-toggle-switch] }

This will make your Rule obsolete. So with Profiles, you can significantly reduce the amount of Rules you need for your Smart Home which helps you to keep your configuration short and clear.

Hallo TF-Team,

wenn ich mit dem Java-Binding versuche die InputValueCallbackConfiguration des io4V2 zu setzen, bekomme ich folgende Fehlermeldung:

error: got invalid parameter for function 6

Die Gegenprüfung mit dem shell-Binding zeigt das gleiche Problem:

air:tinkerforge theo$ ./tinkerforge call io4-v2-bricklet G2j set-input-value-callback-configuration 1 500 false
tinkerforge call io4-v2-bricklet <uid> set-input-value-callback-configuration: error: got invalid parameter for function 6

Gruß,

Theo

@Ingenieur super!

Konfiguration kannst du über das configureTemplate implementieren und über das config-Array in der Device-Konfiguration anlegen. Siehe z.B.:

  "temperaturev2":{
    "bricklet": "BrickletTemperatureV2",
    "className": "TemperatureV2Bricklet",
    "brickletConfig": "TemperatureV2DeviceConfig",
    "package": "temperaturev2",
    "deviceType": "temperatureV2",
    "callbackChannels": "true",
    "hasConfig": "true",
    "configureTemplate": "ConfigureTemperatureV2.mvel",
    "config": [
      {
        "name": "statusLEDConfig",
        "type": "Integer",
        "ohtype": "integer",
        "ohmultiple": "false",
        "converter": "Integer.parseInt",
        "getter": "getStatusLEDConfig",
        "default": "3",
        "min": "0",
        "max": "3",
        "description": "Status LED<![CDATA[<br>]]>Between 0=>OFF), 1=>ON, 2=>HEARTBEAT, 3=>STATUS; default is 3=>STATUS."
      }
    ],

Hallo StefanOHAN,

danke für das Testen!

zu1) das OutdoorWeather Bricklet ist noch nicht unterstützt. Der Code, der da ist ist veraltet. Ich hab vergessen, dass wieder rauszunehmen.

zu2) Die Multitouch Channels sind  TriggerChannels vom Typ system.rawbutton mehr dazu findest du u.a. hier: https://www.openhab.org/docs/configuration/items.html#_2-x-binding-configuration

zu3) Da ist mindestens die Channel-Definition falsch, da muss ich was fixen.

Wenn du nur openHAB verkorkst hast, dann musst du nicht den pi neu aufsetzen, es sollte reichen:

apt-get remove --purge openhab2
apt-get install openhab2

Für openhabian bin ich da aber nicht ganz sicher, vielleicht weiß da Sigi @sihui mehr?

Das mit der Projektbeschreibung ist super! Poste es doch unter Projektvorstellungen und schick uns in diesem Thread einen Hinweis darauf. Ich bin gespannt.

Gruß,

Theo

Hi Erik,

Ok, das war es. Ich hatte auch schon sowas vermutet und auf meinem Rechner nach laufenden Programmen (openHAB) gesucht und da lief nichts. Jetzt hab ich mit lsof noch nach offenen Verbindungen zum brickd gesucht und gefunden. Da war noch eine openHAB Testinstallation auf einem Pi, die remote am brickd hing :-((

Jetzt funktioniert alles wie es soll.

Sorry für die Umstände.

Gruß,

Theo

Hier noch ein Screencast auf dem das NFC/RFID Problem zu sehen ist:

https://m1theo.de/ncloud/index.php/s/GFxnQrgkKgJtqA4

Hallo Erik,

das Problem ist reproduzierbar. Den Log habe ich angehängt.

Gruß,

Theo

brickv_nfc_debug.log

Das mit dem Fusion Style ist schon mal viel besser, das sollte der Default sein. Optimal wären gestaffelte Tabs.

@omiT: das LCD 20X4 kommt auf jeden Fall. Die Idee mit der sitemap ist gut aber vermutlich nicht machbar. Ich behalte das mal im Hinterkopf, zunächst wird es aber Funktionalität vergleichbar zu der im alten Binding sein.

@amos + @sihui: das Remote Switch Bricklet wird kommen, am Ende sollen alle Bricklets unterstützt werden. Das Remote Switch ist, wie auch auch das Outdoor Weather, schwieriger einzubinden, wird deshalb noch etwas dauern.

@peter_tau: das PtcV2 ist bereits unterstützt. LoadCellV2 ist vermutlich einfach, das kann ich im nächsten Snapshot machen. RemoteSwitchV2 wird zusammen mit dem RemoteSwitch kommen.

IO16 ist in der Mache.

Hallo photron,

ein Problem, dass schon der bisherige Brick Viewer hatte, ist der einreihige Tabreiter. Bei vielen Bricklets kann man nichts mehr erkennen (siehe Anhang).

Die NFC/RFID Bricklet View fängt das "flackern" an sobald ich mein Typ 2 Tag auflege und Scan drücke. Die Load steigt auf 100% CPU.

Sonst sieht es gut aus.

Gruß,

Theo

Hallo StefanOHAN,

das klingt ja sehr cool! Hast du irgendwo einen Blog oder sowas über das Projekt? Die Details würden mich schon sehr interessieren, da könnte ich sicher auch noch was lernen.

Und ja, dass IO16 kommt, ich habe schon angefangen. Danach ist das 20x4 dran, dann sollte für dein Projekt alles beieinander sein, oder?

Gruß,

Theo

@StefanOHAN, danke für das Testen.

>> muss man immer beim Austausch eines Binding auch über die „openhab-cli console“ das Binding erst entfernen (ich war mir nicht sicher ob es da einen anderen Weg gibt)?

Ehrlich gesagt bin ich mir da auch nicht so sicher. Ich vermute es könnte auch über das PaperUI funktioneren. Ich denke hier ist @sihui der Fachmann, oder Sigi?

>> Wann meinst Du dass Du das 16-Fach I/O in einer  Binding-Version integriert hast ?

Ok ich nehme mir jetzt das IO16 Bricklet vor. Auch wenn ich es nicht so mag, da es schwieriger ist das in OH zu modellieren, da die Konfiguration bestimmt ob ein Pin ein Sensor oder ein Aktor ist: billige Hardware => teuere Software.