Einstein Geschrieben October 24, 2013 at 18:08 Geschrieben 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 Zitieren
Stefan Geschrieben October 25, 2013 at 09:52 Geschrieben 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. Zitieren
teichsta Geschrieben October 28, 2013 at 13:08 Geschrieben 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. Zitieren
theo Geschrieben November 19, 2013 at 20:49 Autor Geschrieben 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 Zitieren
Stefan Geschrieben November 21, 2013 at 09:42 Geschrieben 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? Zitieren
Einstein Geschrieben November 21, 2013 at 22:47 Geschrieben 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 Zitieren
theo Geschrieben November 23, 2013 at 14:56 Autor Geschrieben 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 Zitieren
Stefan Geschrieben November 24, 2013 at 13:18 Geschrieben 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 Zitieren
theo Geschrieben November 24, 2013 at 14:49 Autor Geschrieben 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 Zitieren
theo Geschrieben November 24, 2013 at 18:44 Autor Geschrieben 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 Zitieren
Stefan Geschrieben November 25, 2013 at 11:08 Geschrieben November 25, 2013 at 11:08 Bei mir funktioniert jetzt alles. Vielen Dank Theo für das "Tinkerforge-Openhab-Binding". Es leistet super Arbeit. Zitieren
theo Geschrieben November 26, 2013 at 19:11 Autor Geschrieben 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 Zitieren
Einstein Geschrieben November 26, 2013 at 21:52 Geschrieben 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. Zitieren
Stefan Geschrieben January 7, 2014 at 20:46 Geschrieben 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 Zitieren
theo Geschrieben January 7, 2014 at 22:06 Autor Geschrieben 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 Zitieren
theo Geschrieben January 19, 2014 at 23:01 Autor Geschrieben 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 Zitieren
Unexpected Geschrieben January 20, 2014 at 18:54 Geschrieben 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 Zitieren
Stefan Geschrieben January 20, 2014 at 19:17 Geschrieben 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. Zitieren
theo Geschrieben January 20, 2014 at 19:35 Autor Geschrieben 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 Zitieren
Unexpected Geschrieben January 20, 2014 at 19:40 Geschrieben 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 Zitieren
Stefan Geschrieben January 20, 2014 at 21:54 Geschrieben 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. Zitieren
theo Geschrieben January 23, 2014 at 20:01 Autor Geschrieben 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. Zitieren
luxor Geschrieben January 29, 2014 at 09:34 Geschrieben January 29, 2014 at 09:34 Sehr cooles Projekt theo! Sag mal brauchst du immer Hardware damit du die Binding erweitern kannst? Zitieren
theo Geschrieben January 29, 2014 at 20:15 Autor Geschrieben 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. Zitieren
derAngler Geschrieben February 2, 2014 at 10:16 Geschrieben 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? Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.