openhab Integration

Einstein · October 24, 2013 at 18:08

Hallo Theo,

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

VG

Stefan · October 25, 2013 at 09:52

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

teichsta · October 28, 2013 at 13:08

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.

theo · November 19, 2013 at 20:49

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

Stefan · November 21, 2013 at 09:42

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?

Einstein · November 21, 2013 at 22:47

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

theo · November 23, 2013 at 14:56

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

Stefan · November 24, 2013 at 13:18

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

theo · November 24, 2013 at 14:49

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

theo · November 24, 2013 at 18:44

So, ein gefixtes Binding ist hochgeladen. Download wie bisher unter http://m1theo.org/wp-content/uploads/org.openhab.binding.tinkerforge-1.4.0-SNAPSHOT-io16-etal.jar .

Gruß,

Theo

Stefan · November 25, 2013 at 11:08

Bei mir funktioniert jetzt alles.

Vielen Dank Theo für das "Tinkerforge-Openhab-Binding". Es leistet super Arbeit.

theo · November 26, 2013 at 19:11

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

Einstein · November 26, 2013 at 21:52

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.

Stefan · January 7, 2014 at 20:46

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

theo · January 7, 2014 at 22:06

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

theo · January 19, 2014 at 23:01

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

Unexpected · January 20, 2014 at 18:54

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

Stefan · January 20, 2014 at 19:17

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.

theo · January 20, 2014 at 19:35

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

Unexpected · January 20, 2014 at 19:40

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

Stefan · January 20, 2014 at 21:54

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.

theo · January 23, 2014 at 20:01

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.

luxor · January 29, 2014 at 09:34

Sehr cooles Projekt theo!

Sag mal brauchst du immer Hardware damit du die Binding erweitern kannst?

theo · January 29, 2014 at 20:15

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.

derAngler · February 2, 2014 at 10:16

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?

openhab Integration

Recommended Posts

Link zu diesem Kommentar

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

theo

Posted Images

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Join the conversation