Jump to content
theo

openhab Integration

Nächste Bricks/Bricklets mit openHAB Unterstützung  

23 members have voted

  1. 1. Nächste Bricks/Bricklets mit openHAB Unterstützung

    • Stepper
    • IMU
    • IMU 2.0
    • Accelerometer (fertig)
    • Analog In (fertig)
    • Analog In 2.0 (fertig)
    • Analog Out
    • Analog Out 2.0
    • GPS
    • Industrial Analog Out
    • Industrial Dual Analog In (fertig)
    • Laser Range Finder (fertig)
    • NFC/RFID
    • Color (fertig)


Recommended Posts

Hallo Theo,

leider lass ich mir nichts mitloggen (logging-persistance) hab ich gerade erst aktiviert. Wenn es wieder auftritt melde ich mich.

 

VG

Share this post


Link to post
Share on other sites

@Einstein Danke für den Tipp. Diese Vorgehensweise hätte aber zwei Probleme für mich.

Ich überwache 20 Pins (2 IO16-Bricklets).

Wenn ich für jeden Pin ein extra Shellbefehl aufrufen würde, hätte ich mehr als 7 Verbindungen, die LAN-Extension verträgt aber nur 7 Verbindungen.

Wickle ich alle Pins über ein Befehl ab, müsste ich die Ausgabe erst anständig parsen.

Deswegen werde ich lieber auf das offizielle Tinkerforge-Binding warten.

Share this post


Link to post
Share on other sites

Hi,

 

leider lass ich mir nichts mitloggen (logging-persistance) hab ich gerade erst aktiviert. Wenn es wieder auftritt melde ich mich

 

doch, lässt Du :-)

 

Schau mal im Verzeichnis "<openHabHome>/log". Dort findest Du eine Datei namens "openhab.log". Wenn Du openHAB über start_debug.xxx gestartet hast, wird noch wesentlich feingranularer gelogged.

 

Die Logging-Persistence-Extension ist eher dazu gedacht Daten Deiner Items zu exportieren. Die exportierten Daten könntet Du dann in weiteren System verwenden. Hat also mit dem von Theo angesprochenen Logging nichts zu tun.

 

Gruß,

 

Thomas E.-E.

Share this post


Link to post
Share on other sites

Die Unterstützung für das IO-16 Bricklet ist soweit fertig. Da man für das IO-16  für jeden Pin (derzeit) einen Konfigurationseintrag in der openhab.cfg braucht, arbeite ich im Moment an der Validierung der Konfiguration. Ich hoffe ich habe das bis zum Wochenende fertig.

 

@Stefan und @Einstein

Dann wäre es natürlich super wenn ihr einen aktuellen Snapshot des Bindings testen würdet.

 

Twitter: da jetzt längere Zeit nichts von mir zu hören war, habe ich mich entschlossen regelmäßig Zwischenstände der Entwicklung an dem Binding zu twittern unter @theo_weiss .

Alles was fertig ist werde ich weiterhin hier bekannt geben.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Hi Theo,

 

das hört sich sehr gut an. Vielen Dank. Ich freue mich schon auf das Testen.

Könntest du uns noch ein Beispiel geben, wenn du fertig bist, wie man ein IO16-Bricklet einbindet?

Share this post


Link to post
Share on other sites

Die Unterstützung für das IO-16 Bricklet ist soweit fertig. Da man für das IO-16  für jeden Pin (derzeit) einen Konfigurationseintrag in der openhab.cfg braucht, arbeite ich im Moment an der Validierung der Konfiguration. Ich hoffe ich habe das bis zum Wochenende fertig.

 

@Stefan und @Einstein

Dann wäre es natürlich super wenn ihr einen aktuellen Snapshot des Bindings testen würdet.

 

Twitter: da jetzt längere Zeit nichts von mir zu hören war, habe ich mich entschlossen regelmäßig Zwischenstände der Entwicklung an dem Binding zu twittern unter @theo_weiss .

Alles was fertig ist werde ich weiterhin hier bekannt geben.

 

Gruß,

Theo

 

hallo theo,

ich würde am we auch mal testen. wie stefan schon schrieb...hast du ein kleines beispiel?

Die snapshots wieder von deiner webseite?

 

grüße

Share this post


Link to post
Share on other sites

So, ich habe den aktuellen Snapshot hochgeladen:  http://m1theo.org/wp-content/uploads/org.openhab.binding.tinkerforge-1.4.0-SNAPSHOT-io16-etal.jar

 

Zum Testen bitte keine kritischen Versuchsaufbauten oder empfindliche Elektronik verwenden, falls es noch Bugs im Binding gibt!!! Ich kann natürlich keine Haftung übernehmen!

 

Zum Installieren openHAB stoppen, aus der openHAB-Installation das bisherige TinkerforgeBinding entfernen (!) und durch das heruntergeladene ersetzen, openHAB wieder starten.

Der Snapshot funktioniert auch mit einem openHAB 1.3 Server, ihr müsst also nur das Binding austauschen.

 

Im Snapshot ist neu die Unterstützung für folgende Bricklets enthalten:

* Bricklet IO-16

* Bricklet Industrial Quad Relay

* Bricklet Industrial Digital In 4

 

Ausserdem werden weitere ItemTypes unterstützt:

* NumberItem

* SwitchItem

* ContactItem

 

Das neue DisconnectedHandling ist ebenso dabei.

 

Es gibt wenige Änderungen die nicht rückwärtskompatibel sind, das betrifft v.a. die Rules:

* LCDBacklight ist jetzt ein sub device von LCD20x4 Bricklet, die subId ist "backlight".

  Im Items file sieht das jetzt so aus:

  Switch TF_LCDBacklight        "LCDBacklight" { tinkerforge="uid=d4j, subid=backlight"}

 

* LCD20x4Button postet jetzt einen update anstatt eines commands, deshalb sieht eine Regel dafür jetzt z.B. so aus:

rule "Weatherstation LCD Backlight"

        when

                Item TF_Button0 received update

        then

        if (TF_Button0.state == ON)

                sendCommand(TF_LCDBacklight, ON)

            else

            sendCommand(TF_LCDBacklight, OFF)

end

 

* IndustrialQuadRelay sub id fängt jetzt bei 0 an. In einem früheren Snapshot war es 1-4, jetzt also 0-3.

 

 

Jetzt zur Konfiguration

=======================

 

Bricklet IO16

-------------

!! Im Unterschied zu allen bisherigen Devices muss hier für jeden Pin, den man verwenden will, ein Eintrag in der openhab.cfg sein!!

Da es sehr viele Konfigurationseinträge werden können und cut/paste-Fehler wahrscheinlich sind, bei Problemen im openhab-Logfile nach "ERROR" und ConfigurationExceptions suchen und openhab.cfg überprüfen.

 

IO16Bricklet Konfiguration die alle Pins betrifft (ist optional):

* debouncePeriod setzt die DebouncePeriod in Millisekunden der default ist 100.

z.B.

tinkerforge:io16.uid=efY

tinkerforge:io16.type=bricklet_io16

tinkerforge:io16.debouncePeriod=100

 

Das SubId-Schema sieht folgendermaßen aus: die SubIds beginnen entweder mit "in" oder "out", gefolgt vom Port "a" oder "b", gefolgt von der Pin-Nummer.

 

Pin als Input konfigurieren:

* type ist "iosensor"

* subid ist: in[ab][0-7]

* pullUpResistorEnabled: "true" oder "false", schaltet den Widerstand dazu oder eben nicht.

z.B.

tinkerforge:io16ina0.uid=efY

tinkerforge:io16ina0.subid=ina0

tinkerforge:io16ina0.type=iosensor

tinkerforge:io16ina0.pullUpResistorEnabled=true

 

Pin als Output konfigurieren:

* type ist "io_actuator"

* subid ist out[ab][0-7]

* defaultState: "true" oder "false" setzt den Port initial auf HIGH bzw. LOW.

z.B.

tinkerforge:io16outb0.uid=efY

tinkerforge:io16outb0.subid=outb0

tinkerforge:io16outb0.type=io_actuator

tinkerforge:io16outb0.defaultState=true

 

Eine zugehörige Items-Datei könnte so aussehen:

Contact ina0 "ina0 [MAP(en.map):%s]" {tinkerforge="uid=efY, subid=ina0"}

Switch outb0 "outb0" {tinkerforge="uid=efY, subid=outb0"}

 

Entsprechend in der Sitemap-Datei:

Text item=ina0

Switch item=outb0

 

Bricklet Industrial Digital In 4

--------------------------------

Gruppierung wird vom Binding nicht unterstützt.

 

Optional kann in openhab.cfg die debouncePeriod gesetzt werden.

* debouncePeriod setzt die DebouncePeriod in Millisekunden der default ist 100.

z.B.

tinkerforge:inddi4.uid=efY

tinkerforge:inddi4.type=bricklet_industrial_digital_4in

tinkerforge:inddi4.debouncePeriod=100

 

Die subIds sind in[0-3].

 

Eine zugehörige Items-Datei könnte so aussehen:

Contact ID1 "ID1 [MAP(en.map):%s]" {tinkerforge="uid=dq3, subid=in0"}

Contact ID2 "ID2 [MAP(en.map):%s]" {tinkerforge="uid=dq3, subid=in1"}

Contact ID3 "ID3 [MAP(en.map):%s]" {tinkerforge="uid=dq3, subid=in2"}

Contact ID4 "ID4 [MAP(en.map):%s]" {tinkerforge="uid=dq3, subid=in3"}

 

Entsprechend in der Sitemap-Datei:

Text item=ID1

Text item=ID2

Text item=ID3

Text item=ID4

 

 

Bricklet Industrial Quad Relay

------------------------------

Gruppierung wird vom Binding nicht unterstützt.

 

Konfiguration in der openhab.cfg wird nicht benötigt.

 

Die subIds sind relay[0-3].

 

Eine zugehörige Items-Datei könnte so aussehen:

Switch QR1 "QR1" {tinkerforge="uid=eQj, subid=relay0"}

Switch QR2 "QR2" {tinkerforge="uid=eQj, subid=relay1"}

Switch QR3 "QR3" {tinkerforge="uid=eQj, subid=relay2"}

Switch QR4 "QR4" {tinkerforge="uid=eQj, subid=relay3"}

 

Entsprechend in der Sitemap-Datei:

Switch item=QR1

Switch item=QR2

Switch item=QR3

Switch item=QR4

 

@Stefan und @Einstein: vielen Dank fürs Testen.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Vielen Dank Theo.

 

Funktionieren bei dir alle Pins? Bei mir funktionieren die Pins a0 und a7, a[1-6] funktionieren nicht. Die Pins b[0-7] habe ich noch nicht ausgetestet.

Dies kann sehr viele verschiedene Gründe haben. Falls bei dir alles problemlos funktioniert, werde ich ausführlichere Tests durchführen.

 

Da alle anderen Dinge im openhab weiter problemlos funktionieren, kannst du, meiner Meinung nach, das Binding schon committen.

 

openhab.cfg

tinkerforge:hosts=192.168.178.23

tinkerforge:io16ina0.uid=io2
tinkerforge:io16ina0.subid=ina0
tinkerforge:io16ina0.type=iosensor
tinkerforge:io16ina0.pullUpResistorEnabled=true

tinkerforge:io16ina1.uid=io2
tinkerforge:io16ina1.subid=ina1
tinkerforge:io16ina1.type=iosensor
tinkerforge:io16ina1.pullUpResistorEnabled=true

tinkerforge:io16ina2.uid=io2
tinkerforge:io16ina2.subid=ina3
tinkerforge:io16ina2.type=iosensor
tinkerforge:io16ina2.pullUpResistorEnabled=true

tinkerforge:io16ina4.uid=io2
tinkerforge:io16ina4.subid=ina4
tinkerforge:io16ina4.type=iosensor
tinkerforge:io16ina4.pullUpResistorEnabled=true

tinkerforge:io16ina5.uid=io2
tinkerforge:io16ina5.subid=ina5
tinkerforge:io16ina5.type=iosensor
tinkerforge:io16ina5.pullUpResistorEnabled=true

tinkerforge:io16ina6.uid=io2
tinkerforge:io16ina6.subid=ina6
tinkerforge:io16ina6.type=iosensor
tinkerforge:io16ina6.pullUpResistorEnabled=true

tinkerforge:io16ina7.uid=io2
tinkerforge:io16ina7.subid=ina7
tinkerforge:io16ina7.type=iosensor
tinkerforge:io16ina7.pullUpResistorEnabled=true

 

items.items

Contact c1 "c1 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina0"}
Contact c2      "c2 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina1"}
Contact c3      "c3 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina3"}
Contact c4      "c4 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina4"}
Contact c5     "c5 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina5"}
Contact c6      "c6 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina6"}
Contact c7      "c7 [MAP(en.map):%s]" {tinkerforge="uid=io2, subid=ina7"}

 

default.sitemap

Text item=c1
Text item=c2
Text item=c3
Text item=c4
Text item=c5
Text item=c6
Text item=c7

Share this post


Link to post
Share on other sites

Hallo Stefan,

 

vielen Dank für deine Rückmeldung.

Ich kann deine Beobachtung nachvollziehen. Ursache ist, ich setze bei setPortInterrupt die falsche Maske, nämlich genau für Port 1 und 7. Beim Testen war wohl der BrickViewer so nett das für mich zu korrigieren ;-).

Ich gebe Bescheid wenn es ein gefixtes Binding zum download gibt.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Super das freut mich.

Ich bin gespannt auf @Einsteins Rückmeldung.

Als nächstes habe ich mir das "Joystick Bricklet" und das "Linear Poti" vorgenommen, dann ist ist das "Voltage/Current" dran.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Super das freut mich.

Ich bin gespannt auf @Einsteins Rückmeldung.

Als nächstes habe ich mir das "Joystick Bricklet" und das "Linear Poti" vorgenommen, dann ist ist das "Voltage/Current" dran.

 

Gruß,

Theo

 

Hallo Theo,

läuft bisher soweit ganz gut, jedoch hab ich aktuell etwas stress und komm erst am wochenende zum testen.

Vielen Dank schonmal für deine Arbeit.

Share this post


Link to post
Share on other sites

Hallo Theo,

 

ich bin endlich zum ausführlicheren Testen gekommen.

 

Nach ein paar Stunden, manchmal auch erst nach ein paar Tagen, fangen die IO16-Input-Items wild an zu wechseln. Wenn ich mit Brickv die Ports wieder auf Pull-Up einstelle, Openhab läuft weiter, ist wieder alles in Ordnung. Ich vermute, dass sich das Brick reconnected hat, laut Log gab es Timeouts, und dabei werden nicht wieder die Pull-Ups gesetzt. Kann dies sein?

 

Werden eigentlich ausschließlich die Callbacks von dem IO16 Bricklet benutzt oder wird als Backup auch in einem Zeitintervall manuell geschaut, welchen Status die Input-Ports haben?

 

Vielen Dank,

Stefan

Share this post


Link to post
Share on other sites

Hallo Stefan,

 

vielen Dank fürs Testen!

Ich versuche das mit dem reconnect nachzustellen (gib mir ein paar Tage).

 

Zusätzlich zu den Callbacks werden die Werte auch regelmäßig abgefragt. Du kannst den Refresh mit "tinkerforge:refresh=(Wert in Millisekunden)" in openhab.cfg setzen, der default ist 60000.

 

Gruß,

Theo

Share this post


Link to post
Share on other sites

Hallo Stefan,

 

ich konnte das Problem nachstellen und den Fehler fixen.

Es gibt jetzt ein gefixtes Binding unter http://m1theo.org/wp-content/uploads/org.openhab.binding.tinkerforge-1.4.0-SNAPSHOT-io16-etal-fix-1.jar .

Allerdings arbeite ich noch daran, dass für outgoing ports nach dem Reconnect unabhängig vom aktuellen Zustand der default Zustand wieder hergestellt wird. Ich denke es sollte der aktuelle Zustand bleiben.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

Hallo theo,

 

ich möchte openhab auch einmal ausprobieren und wollte da einmal fragen, ob ihr auch eine ARM Version habt? Diese Version kann ich auf dem Raspberry Pi leider nicht benutzen:

 

openhab-designer-linux-1.3.1.zip openHAB Designer (Linux 32-bit) Featured

 

Dann werde ich erst einmal die Windows Version ausprobieren :)

 

Grüße

Unex

Share this post


Link to post
Share on other sites

Hallo Theo,

 

vielen Dank. Ich kann es nur wiederholen, das TinkerForge-Binding ist echt super.

 

@Unexpected

Der openhab Designer dient nur zur Erstellung der Konfiguration, dies kann man auch über einen Texteditor machen bzw. die Konfiguration über Windows erstellen und dann auf den anderen Rechner kopieren. Die openhab-runtime müsste auch auf der ARM-Plattform laufen.

Share this post


Link to post
Share on other sites

Hallo Unex,

 

schön, dass du dich für openHAB interessierst.

 

@Stefan: gerade als ich abschicken wollte kam dein Beitrag. Danke fürs Einspringen, Unex Frage ist damit eigentlich schon beantwortet. Ich schicke trotzdem noch ab, da ich einige Links reingepackt habe.

 

Die openHAB Runtime und die Bindings laufen auf dem PI. Den Designer brauchst du nur um deine Konfiguration zu erstellen. Der ist zur Laufzeit auf dem PI nicht nötig, und auch nicht so gut aufgehoben, da er etwas mehr Ressourcen braucht.

 

Pack die Runtime und die gewünschten Bindings/Addons auf dem Pi, erstelle die Konfiguration auf deinem Windows Rechner, schieb sie auf den PI und starte die Runtime.

Mit allgemeinen Fragen zu openHAB bist du auf den openHAB Mailinglisten noch besser aufgehoben:

auf Deutsch: http://knx-user-forum.de/openhab/

auf Englisch: https://groups.google.com/forum/#!forum/openhab

 

Installations und Konfigurationsanleitung findest du im Wiki: https://github.com/openhab/openhab/wiki/Quick-Setup-an-openHAB-Server

Hier findest du einiges zu openHAB auf dem PI: https://github.com/openhab/openhab/wiki/Hardware-FAQ

 

Gruß,

Theo

Share this post


Link to post
Share on other sites

Hallo theo,

hallo Stefan,

 

danke für eure Erklärungen. Das hatte ich wohl falsch verstanden.

 

Dann werd ich das mal ausprobieren! :)

 

Grüße

Unex

Share this post


Link to post
Share on other sites

Allerdings arbeite ich noch daran, dass für outgoing ports nach dem Reconnect unabhängig vom aktuellen Zustand der default Zustand wieder hergestellt wird. Ich denke es sollte der aktuelle Zustand bleiben.

 

Hast du in dem ersten Satz default Zustand und aktueller Zustand vertauscht und meinst:

"Allerdings arbeite ich noch daran, dass für outgoing ports nach dem Reconnect unabhängig vom default Zustand der aktuelle Zustand wieder hergestellt wird. Ich denke es sollte der aktuelle Zustand bleiben."

 

Dies fände ich auch besser.

Share this post


Link to post
Share on other sites

Danke für die Klarstellung. Genauso habe ich es gemeint. Bisher wird der default Zustand wieder hergestellt, anstatt der Beibehaltung des aktuellen Zustands.

Eine gute Lösung habe ich bisher noch nicht, da ich im Binding nicht zwischen Reconnect und "Device ist neu" unterscheiden kann.

Share this post


Link to post
Share on other sites

Danke Luxor.

Ja, ich brauch die Hardware schon. Entwickeln im reinen "Blindflug" wäre doch etwas schwierig. Manches merkt man erst beim Ausprobieren (diese Erfahrung habe ich gerade (wieder?) mit dem Remote Switch Bricklet gemacht).

Ausserdem macht es einfach mehr Spaß! Das Ganze nach getaner Arbeit in Aktion zu sehen ist es auch eine kleine Belohnung.

Share this post


Link to post
Share on other sites

Hallo,

 

ich beobachte dein Projekt mit Interesse.

 

Auf der Liste der unterstützten Bricklets fehlen mir eigentlich nur noch 2 x Stück:

1. Remote Switch Bricklet

2. Motion Detection Bricklet

 

Hast du zufälligerweise geplant für eins der beiden (oder beide) Bricklets in naher Zukunft ein Binding zu schreiben?

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