theo Geschrieben January 31, 2015 at 20:43 Autor Geschrieben January 31, 2015 at 20:43 Neues gibt es auch für den Brick DC. Support für Dimmer, Rollershuter and Number items. Ausserdem kann die Geschwindigkeit auch über einen Prozentwert gesetzt werden. Ausführliche Doku und Download-Link gibt es hier. https://github.com/theoweiss/openhab/issues/1 PS: Wer Brick DC und B-Dimmer verwenden will muss diese Version des Bindings installieren. https://bintray.com/artifact/download/theoweiss/generic/remoteswitch/1/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT.jar Zitieren
derAngler Geschrieben February 1, 2015 at 14:26 Geschrieben February 1, 2015 at 14:26 Also ich muss dir meinen Respekt für deine Arbeit hier aussprechen theo. Wirklich klasse! Ich selbst habe auch mal mit openhab experimentiert, leider hat mich die GUI sehr enttäuscht. Das sieht auf dem Tablet, bzw. im Browser immernoch sehr altmodisch aus. Weißt du wann hier mal was neues kommt? Zitieren
theo Geschrieben February 1, 2015 at 21:03 Autor Geschrieben February 1, 2015 at 21:03 Vielen Dank. Ja bei der Android App bewegt sich gerade etwas. Vorgestern hat Kai einen Screenshot getwittert https://twitter.com/kaikreuzer/status/561209718119886848/photo/1 . Soweit ich weiß gibt es im Moment neben HabDroid auch noch eine weitere openHAB App im App-Store. Insgesamt ist bei openHAB gerade grundlegendes im Gange, seit ca. einem 3/4 Jahr ist die openHAB2 Entwicklung im Gange. Da wird vieles von Grund auf neu gemacht. Dabei steht Benutzerfreundlichkeit im Fokus, z.B. auch durch durchgehende Konfiguration mit Web GUI's (auch für die Rules). Ausserdem wird es Autodiscover für Devices geben. Da die Kernkomponenten von openHAB seit einiger Zeit als "Eclipse Smarthome" Projekt weitergeführt werden, gibt es mittlerweile auch Beteiligung von Firmen an der Weiterentwicklung. openHAB2 bedeutet für das TinkerForge Binding eine Reimplementierung von vielen Teilen. Das wird noch ein paar Monate dauern bis ich soweit bin, aber ich freue mich schon drauf. Gruß, Theo Zitieren
Gast sihui Geschrieben March 8, 2015 at 12:37 Geschrieben March 8, 2015 at 12:37 Leider ist das für mich ein völliger Blindflug, da ich kein solches Gerät habe. Deshalb wäre es nett, wenn z.B. @sihui (Sigi) das Binding testen könnte. Hallo Theo, ich bitte tausendmal um Entschuldigung, ich habe diesen Eintrag wegen falscher Benachrichtigungseinstellungen im Forumsprofil nicht gesehen. Ich habe direkt nach dem Lesen getestet, leider funktioniert der Dimmer so wohl noch nicht. Es tut sich beim sliden gar nichts, weder wird die Lampe ein- oder ausgeschaltet noch lässt sie sich dimmen. Anbei poste ich mal alles was ev. zur Fehlerbehebung führen könnte, sollte mehr erforderlich sein bitte kurz melden. Zuerst die Konfiguration: .items: Dimmer Dimmer_OG_XYZ_Schlafzimmer "Dimmer XYZ" (OG_XYZ_Schlafzimmer) { tinkerforge="uid=ooc, subid=XYZ_decke_dimmer, step=1" } .sitemap: Slider item=Dimmer_OG_XYZ_Schlafzimmer openhab.cfg: tinkerforge:rs1.uid=ooc tinkerforge:rs1.type=bricklet_remote_switch tinkerforge:rs1.typeBDevices=XYZ_decke XYZ_decke_dimmer flutlicht dachueberstand wp_it_itr1500_2 wp_it_itr1500_3 wp_it_itr1500_4 tinkerforge:rs_og_XYZ_schlafzimmer2.uid=ooc tinkerforge:rs_og_XYZ_schlafzimmer2.subid=XYZ_decke_dimmer tinkerforge:rs_og_XYZ_schlafzimmer2.type=remote_switch_b tinkerforge:rs_og_XYZ_schlafzimmer2.address=2052123 tinkerforge:rs_og_XYZ_schlafzimmer2.unit=1 Dann ein Teil der logs: events.log: 2015-03-08 13:15:29 - Dimmer_OG_XYZ_Schlafzimmer received command 0 2015-03-08 13:15:33 - Dimmer_OG_XYZ_Schlafzimmer received command 100 Auch Zwischenschritte scheinen hier anzukommen: 2015-03-08 13:07:27 - Dimmer_OG_XYZ_Schlafzimmer received command 57 openhab.log: 2015-03-08 13:15:29.986 [ERROR] [.t.internal.TinkerforgeBinding] - found no percenttype actor 2015-03-08 13:15:33.678 [ERROR] [.t.internal.TinkerforgeBinding] - found no percenttype actor request.log: 192.168.2.XX - - [08/Mar/2015:12:15:29 +0000] "POST /rest/items/Dimmer_OG_XYZ_Schlafzimmer HTTP/1.1" 201 0 192.168.2.XX - - [08/Mar/2015:12:15:30 +0000] "GET /rest/sitemaps/wss3/OG_XYZ_Schlafzimmer HTTP/1.1" 200 0 192.168.2.XX - - [08/Mar/2015:12:15:30 +0000] "GET /rest/sitemaps/wss3/OG_XYZ_Schlafzimmer HTTP/1.1" 200 0 192.168.2.XX - - [08/Mar/2015:12:15:33 +0000] "POST /rest/items/Dimmer_OG_XYZ_Schlafzimmer HTTP/1.1" 201 0 Danke und sorry noch einmal, Gruß, Sigi Zitieren
theo Geschrieben March 9, 2015 at 20:38 Autor Geschrieben March 9, 2015 at 20:38 Hallo Sigi, vielen Dank für die Rückmeldung. Komisch ist, dass bei dir der Slider einen Prozentwert schickt anstatt ein IncreaseDecrease. Ich melde mich wenn ich schlauer bin. Gruß, Theo Zitieren
Gast sihui Geschrieben March 9, 2015 at 20:47 Geschrieben March 9, 2015 at 20:47 Komisch ist, dass bei dir der Slider einen Prozentwert schickt anstatt ein IncreaseDecrease. Das war ein entscheidender Hinweis: aus der bisher ausprobierten App Habdroid wird ein Prozentwert geschickt und das Dimmen funktioniert nicht, aus der gerade ausprobierten Browseroberfläche (die ich normalerweise nie nutze) wird ein Increase/Decrease geschickt und das Dimmen funktioniert. Alleine die optische Darstellung ist ja auch unterschiedlich: in Habdroid wird ein "richtiger" Slider dargestellt, in der Browseroberfläche "nur" zwei Button, einer eben für increase, einer für decrease. Gruß, Sigi Zitieren
theo Geschrieben March 9, 2015 at 20:57 Autor Geschrieben March 9, 2015 at 20:57 Super, danke fürs debuggen! Ich hatte nur mit dem Browser getestet. Natürlich sollten sich die GUI's nicht unterschiedlich verhalten. Ich werde das weiterleiten und sehen ob es einen Workaround für das Binding gibt. Gruß, Theo Zitieren
Gast sihui Geschrieben March 9, 2015 at 20:59 Geschrieben March 9, 2015 at 20:59 ... und das Dimmen funktioniert. Ich muss das in den nächsten Tagen noch einmal in Ruhe ausprobieren ... Beim ersten Dimmversuch konnte ich in groben Helligkeitsstufen rauf und runterdimmen. Bei gerade durchgeführten weiteren Tests passiert folgendes: wenn ich auf decrease gehe wird die angeschlossene Lampe sofort ausgeschaltet, egal welche Helligkeitsstufe vorher eingestellt war. Auf increase fängt die Lampe an rauf und runter zu dimmen bis ich wieder auf decrease gehe, dann stoppt sie und bleibt auf dieser Helligkeitsstufe. Ich gehe mal davon aus das ist eine Eigenart des verwendeten Dimm-Modules, eines ITDM 250 von Intertechno. Ich melde mich mit einem Update sobald ich etwas mehr Zeit habe das noch einmal auszuprobieren. Grundsätzlich scheint aber die Implementation des Dimmens gelungen zu sein! Danke, Gruß, Sigi Zitieren
theo Geschrieben March 9, 2015 at 21:43 Autor Geschrieben March 9, 2015 at 21:43 Da gab es noch einen Bug im Dimmer UI, der mittlerweile gefixt ist: https://github.com/openhab/openhab/pull/2127. Ich vermute es ist besser, du machst deine Tests mit einer 1.7-SNAPSHOT Runtime: https://openhab.ci.cloudbees.com/job/openHAB/ Gruß, Theo Zitieren
Gast sihui Geschrieben March 10, 2015 at 16:33 Geschrieben March 10, 2015 at 16:33 Ich vermute es ist besser, du machst deine Tests mit einer 1.7-SNAPSHOT Runtime: https://openhab.ci.cloudbees.com/job/openHAB/ Ein "quick and dirty" Test mit 1.7 Snapshot statt 1.62 hat leider keinen Erfolg gebracht, es kommen Fehlermeldungen. 2015-03-10 17:30:34.104 [iNFO ] [.service.AbstractActiveService] - Tinkerforge Refresh Service has been started 2015-03-10 17:30:34.244 [ERROR] [c.t.a.impl.AbstractClassMirror] - resource is empty: java:/Objects/org.openhab.action.tinkerforge.internal.TinkerForge Ich werde mich mal am WE dran setzen und mit etwas mehr Ruhe und Zeit weitertesten. Gruß, Sigi Zitieren
theo Geschrieben March 10, 2015 at 21:01 Autor Geschrieben March 10, 2015 at 21:01 Da steht was von org.openhab.action.tinkerforge, hast du vielleicht das Binding mit der Action verwechselt? Ab 1.7 wird es noch eine tinkerforge.action geben, das ist ein eigenes Plugin, das Actions für die Verwendung in Rules hinzufügt. Die Doku dafür ist noch nicht online, kommt aber noch. Das Action-Plugin braucht auch das passende Tinkerforge-Binding aus dem 1.7-SNAPSHOT Paket. Das kannst du gerne anstatt des Bintray Downloads verwenden, es enthält auch die Dimmerfunktionalität (die ist mittlerweile in den master branch gemerged) und noch einige weitere Features. Ich werde die Tage noch etwas dazu posten. Verwirrt? Zitieren
Gast sihui Geschrieben March 15, 2015 at 15:35 Geschrieben March 15, 2015 at 15:35 ... hast du vielleicht das Binding mit der Action verwechselt? Yes, Sir. Das kommt von "quick and dirty", man sollte so etwas in Ruhe machen und nicht mal eben zwischendurch. Ergebnis des heutigen Tests mit aktuellem 1.70 Snapshot, heute heruntergeladen: Browser: - drücken auf increase schaltet das Dimmmodul auf der vorherig gewählten Helligkeitsstufe ein -> korrekt. - Drücken auf decrease schaltet das Dimmmodul aus -> nicht korrekt. - Erneutes drücken auf increase schaltet wieder ein, ein weiterer Druck auf increase lässt den Dimmer die Helligkeitsstufe rauf und runterlaufen bis ein erneutes Drücken auf increase die gewählte Stufe stoppen lässt und dort verbleibt dann auch die Helligkeit -> fast korrekt. - einmaliges drücken von decrease schaltet wieder aus -> nicht korrekt. Android App Habdroid: null Funktion (wahrscheinlich, wie wir zuvor schon festgestellt haben, weil kein increase/decrease gesendet wird sondern Prozentwerte gemäß eingestelltem Slider). Mein Fazit: ich bin der festen Überzeugung, dass das Dimmen so korrekt funktioniert und die oben festgestellten "Fehlfunktionen" an der Eigenart meines Dimmmodules liegen. Da dieses Intertechno das einzige Dimmmodul ist, welches sowohl mit dem originalen Lichtschalter (wichtig für WAF=wife acceptance factor) als auch mit LED-Lampen verwendet werden kann, habe ich mir noch keine weiteren Dimmer zugelegt. Außerdem ist es auch sonst über den Originalschalter nur so zu bedienen wie auch über das Binding: Einschalten, sofort wieder ausschalten, einschalten: Dimmstufen laufen rauf und runter, ausschalten: Dimmer stoppt, wieder einschalten: Dimmer hat die gewählte Helligkeitstufe. Falls es in Zukunft noch andere Module gibt, die beides (Originalschalter und LED) in sich vereinen werde ich mir dieses kaufen und weitertesten. Ansonsten kann ich mit der jetzigen Funktionsweise (bis auf Nichtfunktion der Android App) erst einmal gut leben und möchte hiermit noch einmal [glow=red,2,300]einen großen Dank ausbringen[/glow] für deine fortwährende Arbeit an den Tinkerforge bindings: ich habe aufgrund der guten Integration in Openhab bereits einige Tinkerforge Module im Einsatz, steuere damit einige Lampen, das Garagentor, die Terassenmarkise usw. Schönes WE, Gruß, Sigi Zitieren
theo Geschrieben March 16, 2015 at 20:29 Autor Geschrieben March 16, 2015 at 20:29 Hallo Sigi, vielen Dank für das ausführliche Testen! Sehr gefreut habe ich mich auch über dein positives Feedback zum Binding. Danke dafür. Es ist für mich natürlich auch wichtig zu wissen, ob das Binding verwendet wird, noch besser für was und was noch fehlt oder nicht funktioniert. Immer her damit. Wegen der Android App habe ich schon eine Anfrage ins openHAB Forum gepostet und hoffe auf eine Antwort. Sobald ich schlauer bin gebe ich dir Bescheid. Gruß, Theo Zitieren
MacDuff Geschrieben March 17, 2015 at 07:17 Geschrieben March 17, 2015 at 07:17 Dem Lob darf ich mich anschließen. Ich baue mir gerade ein Openhab-System aus TF und Max!-Komponenten (Heizungssteuerung) zusammen. Auf TF-Seite sind Temperatur-, AmbientLight-, LCD-, Motion-, Remote-Switch-Bricklets im Einsatz. Funktioniert alles einwandfrei. Nun... würde ich gerne Max!-Fensterkontakte mit dem Dual-Button-Bricklet zusammenschalten -- wir sind unterm Dach und ich stelle mir eine Warnlampe vor, die beim Verlassen der Wohnung leuchtet, falls eines der Dachfenster geöffnet ist. Besteht die Chance, dass dieses Bricklet zu den bestehenden TF-Bindings hinzugefügt wird? beste Grüße, macduff Zitieren
Gast sihui Geschrieben March 17, 2015 at 16:37 Geschrieben March 17, 2015 at 16:37 ... noch besser für was und was noch fehlt oder nicht funktioniert. Immer her damit. Das ist einfach: Bei mir läuft Openhab auf einem RPi2 mit folgender Tinkerforge Hardware: Industrial Digital 4 IN Bricklet zum Messen des Wasserstandes der Zisterne (über mehrere Masseschleifen die durch den entsprechenden Wasserstand geschaltet werden) Industrial Digital 4 IN Bricklet zur Erkennung des geöffneten oder geschlossenen Garagentores. Industrial Quad Relay Bricklet zum Steuern des Garagentores, angeschlossen an den externen Eingängen des Garagentoröffners Industrial Quad Relay Bricklet zum Steuern der Markise mit "Hardware Hack", also eine günstige gebrauchte Fernbedienung von Somfy aus der Bucht mit parallel zu den Tastern gelöteten Verbindungen zum Relay. Remote Switch Bricklet zum Steuern einiger Lampen und - bis jetzt - einem Dimmer auf 433 Mhz Der Rest ist Z-Wave auf 866 Mhz Basis, wo ich Rückmeldungen der Aktoren brauche (einige Steckdosen, Bewegungsmelder, Rauchmelder, Alarmanlage). Was nicht funktioniert? Nichts, außer vielleicht meinem Dimmer, aber wir haben ja schon festgestellt das es an den Eigenheiten des Dimmmoduls liegt. Ansonsten habe ich immer fast alles auf Anhieb zum Laufen gebracht mit Hilfe dieses und anderer Foren und einigen Code Snipplets die ich für meine Bedürfnisse angepasst habe. Ich bin rundum zufrieden mit der Kombination OH, TF und Z-Wave. Zu Beginn (vor ca. einem halbem Jahr) habe ich FHEM und NetIO ausprobiert, das funktioniert zwar auch ganz gut, bietet aber nicht die Vielfältigkeit und einfach Konfiguration der jetzigen Zusammenstellung. ... ich stelle mir eine Warnlampe vor, die beim Verlassen der Wohnung leuchtet, falls eines der Dachfenster geöffnet ist. Kannst du dafür kein Industrial Digital 4 IN Bricklet nehmen? Meines meldet mir über Mikroschalter am Garagentor den Zustand AUF oder ZU. Gruß, Sigi Zitieren
Stefan Geschrieben March 18, 2015 at 11:38 Geschrieben March 18, 2015 at 11:38 Hi Theo, das IO16-Bricklet macht bei mir etwas Probleme. Nach einer gewissen Zeit stimmen die Werte nicht mehr. Öffne ich jetzt den Brick Viewer dann flippen die Zustände mehrere Male pro Sekunde von Low auf High und wieder zurück. Wenn ich ich für einen der Ports (A und B) einen Pin wieder mit dieser Option einstelle Direction: Input Config: Pull-Up , dann werden wieder für alle Pins an diesem Port die korrekten Werte angezeigt. Leider gehen durch Brick Viewer bedingt, aber die Output Pins verloren. Es wäre super, wenn du dir es mal anschauen könntest. Zitieren
theo Geschrieben March 19, 2015 at 20:35 Autor Geschrieben March 19, 2015 at 20:35 Hallo macduff, das Dual-Button-Bricklet ist so gut wie fertig, ein erster Wurf ist schon in 1.7.0-SNAPSHOT drin. Ich schau gerade noch mal über den Code. Ich werde dir Bescheid geben wenn es was zu testen gibt. Gruß, Theo Zitieren
theo Geschrieben March 19, 2015 at 20:40 Autor Geschrieben March 19, 2015 at 20:40 Hallo Stefan, was bedeutet "stimmen die Werte nicht mehr"? Kannst du das etwas genauer beschreiben, damit ich weiß was ich testen muss. Wenn du im laufenden Betrieb den Brick Viewer aufschaltest kann es sein, dass etwas durcheinander gerät. Soweit mir bekannt ist spätestens beim Disconnect des Brick Viewers, werden alle Callback-Listener gelöscht. Soweit ich das verstanden habe wird das in einer der kommenden Brick Viewer Versionen gefixt sein. Gruß, Theo Zitieren
theo Geschrieben March 19, 2015 at 20:44 Autor Geschrieben March 19, 2015 at 20:44 Hallo Sigi, klingt nach einem coolen Aufbau. Vermutlich wären für die Dimmer auch Z-Wave Geräte besser geeignet. Die Baumarktgeräte haben mich nicht überzeugt, eben weil der Rückkanal fehlt. Das Remote Bricklet gefällt mir, ich hätte dafür aber lieber eine Firmware, die z.B. Remote Temperatursensoren (am liebsten von TF) auslesen kann. Gruß, Theo Zitieren
MacDuff Geschrieben March 20, 2015 at 08:43 Geschrieben March 20, 2015 at 08:43 prima, ich bin auf stand-by... md Hallo macduff, das Dual-Button-Bricklet ist so gut wie fertig, ein erster Wurf ist schon in 1.7.0-SNAPSHOT drin. Ich schau gerade noch mal über den Code. Ich werde dir Bescheid geben wenn es was zu testen gibt. Gruß, Theo Zitieren
Stefan Geschrieben March 22, 2015 at 13:09 Geschrieben March 22, 2015 at 13:09 was bedeutet "stimmen die Werte nicht mehr"? Die Werte haben irgendwelche Werte. Diese stimmen nicht unbedingt mit den anliegenden überein. Dies tritt vor dem Öffnen von Brick Viewer ein. Danach öffne ich Brick Viewer und sehe, dass die einzelnen Pins ganz schnell von Low auf High und wieder zurück springen, vermutlich geht die Einstellung Pull-Up irgendwie verloren. Zitieren
kyb Geschrieben March 29, 2015 at 20:00 Geschrieben March 29, 2015 at 20:00 So, tach zusammen. Zuerst mal ein dickes Lob für die gleistete Arbeit, die es echt simpel macht, die TF-Bausteine in Openhab einzubinden. Jetzt bin ich bei der Einbindung meines LED-Bricklets auf eine Unannehmlichkeit gestossen, bei der ich jedoch nicht genau weiss, ob es am Binding oder an Tinkerforge selber liegt. Folgendes Setup: Raspberry Pi 2 mit Openhab sowie einem Masterbrick mit Barometer und Humidity Bricklet Raspberry Pi B mit Masterbrick und 2 LED-Bricklets, wobei zur Zeit nur eines angesprochen wird. Verbunden sind die beiden über Netzwerk via Powerline Adapter. Openhab v1.6.2 mit dem zugehörigen Tinkerforge-Binding Es funktioniert alles, ich kann den LED-Strip über Openhab ein- und ausschalten sowie die Farbe und Helligkeit ändern. Soweit so gut, nur sorgt das ganze für einen extremen Netzwerktraffic, sobald das Binding von Openhab fertig ist mit der Initialisierung. Dadurch erzeugt der Brickd auf dem RP B für eine ständige hohe CPU-Auslastung. Das Einfügen von tinkerforge:refresh=60000 in die openhab.cfg zeigt keine Wirkung. Daher die Frage, ob bzw. wie der Netzwerktraffic auf ein vernünftiges Mass reduziert werden kann? Gruss, Jens Zitieren
theo Geschrieben March 29, 2015 at 20:35 Autor Geschrieben March 29, 2015 at 20:35 Hallo Jens, ich habe gerade mal in den Code geschaut. Ich setze die Frameduration fest auf 1ms, in der Annahme, dass kein FrameRenderedListener() eingehängt ist. Ganz sicher bin ich mir über das richtige Vorgehen hier aber nicht. Das könnte vielleicht dann hohe Load für den Brickd erzeugen, wenn du parallel zu openHAB den Brick Viewer geöffnet hast. Gruß, Theo Zitieren
theo Geschrieben March 29, 2015 at 21:53 Autor Geschrieben March 29, 2015 at 21:53 Mir ist noch was aufgefallen. Welche LED's verwendest du? Ich habe Übersehen, dass das API erweitert wurde. Das openHAB binding unterstützt deshalb bisher nur den default WS2801 Chip. Keine Ahnung wie sich das auswirkt, wenn du andere LED's hast. Ich werde das baldmöglichst nachziehen. Zitieren
kyb Geschrieben March 29, 2015 at 22:15 Geschrieben March 29, 2015 at 22:15 Hallo Theo, danke für die schnelle Antwort. Ich verwende die WS2801. Der Netzwertraffic ist leider unabhängig davon, ob noch ein brickv läuft. Falls ich irgendwas testen kann, lass es mich wissen. Ich werde morgen ein reduziertes Setup erstellen, um eine Testumgebung zu haben. Gruss, Jens 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.