kyb Geschrieben March 30, 2015 at 18:49 Geschrieben March 30, 2015 at 18:49 So, die gesamte Soft- und Firmware ist jetzt auf dem aktuellsten Stand, zusätzlich eine OpenHAB Testinstanz die exklusiv auf das LED-Bricklet zugreift. Leider keine Besserung des Phänomens. Sobald ein Befehl von OpenHAB an das LED-Bricklet gesendet wurde, bleibt der brickd daueraktiv mit ca 20% CPU-Last. Die aktivitäts LED am MasterBrick ist im Dauerblinkmodus. Erst wenn ich über einen brickv den MasterBrick resette, hört das blinken auf und der brickd geht wieder in den normalen Modus. Sobald allerdings wieder ein OpenHAB-Befehl kommt, geht es wieder von vorne los. Zum testen habe ich ein lokales python-skript, welches alle LEDs an- und ausschaltet. Läuft das Skript ohne dass openHAB eine Verbindung zum Bricklet hat, erzeugt der brickd eine CPU-Last von 2-3%, nach Ende des Skripts geht der brickd wieder schlafen. Startet man das Skript, während openHAB eine Verbindung hat, so steigt die CPU-Last sofort wieder auf 20%, auch wenn vorher ein Reset des MasterBricks für Ruhe gesorgt hat. Es sieht irgendwie danach aus, als ob OpenHAB den brickd/das MasterBrick in eine Endlosschleife versetzt. Nächster Test wird sein, den MasterBrick an den RP 2 zu hängen, auf dem openHAB direkt läuft. Edit: Test beendet. Der brickd zeigt genau das gleiche Verhalten, auch wenn OpenHAB auf dem gleichen Rechner läuft wie der brickd. Gruss, Jens Zitieren
theo Geschrieben March 30, 2015 at 21:44 Autor Geschrieben March 30, 2015 at 21:44 Hi Jens, mein Verdacht ist, dass die FrameDuration 1 nicht gut ist. Ich habe mal ein Binding mit setFrameDuration(100) gebaut, was dem default entspricht. Du kannst das angepasste Binding hier herunterladen: https://bintray.com/artifact/download/theoweiss/generic/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT-led-button.jar Gruß, Theo Zitieren
kyb Geschrieben March 31, 2015 at 18:54 Geschrieben March 31, 2015 at 18:54 Hallo Theo, danke für die Hilfe. Mit dem neuen Binding geht die CPU-Auslastung auf unter 1% zurück und der Netzwerktraffic ist deutlich reduziert, aber immer noch permanent vorhanden. Allerdings funktioniert die Ansteuerung nun nicht mehr. Anbei die Debug-Ausgabe. 20:49:21.429 [DEBUG] [.t.internal.TinkerforgeBinding:713 ] - received command ON for item SZ_Led1 20:49:21.429 [ERROR] [.t.internal.TinkerforgeBinding:743 ] - COMMAND received OnOff command for non-SwitchActor 20:49:21.434 [DEBUG] [m.r.internal.engine.RuleEngine:285 ] - Executing rule 'SZ_Led_ON' 20:49:21.436 [iNFO ] [runtime.busevents :22 ] - SZ_Led1 received command ON 20:49:21.500 [DEBUG] [riptExtensionClassNameProvider:63 ] - Script actions have changed: ExecActionService, AudioActionService, PingActionService, TransformationActionService, HTTPActionService, 20:49:21.581 [DEBUG] [.t.internal.TinkerforgeBinding:713 ] - received command 0.0,0.0,100.0 for item SZ_Led1 20:49:21.581 [ERROR] [.t.internal.TinkerforgeBinding:756 ] - found no percenttype actor ONOFF for non-switch actor habe ich über zwei rules abgefangen, die die Helligkeit auf 0 bzw. 100 setzt für Ein-/Ausschalten. Neu ist die letzte Fehlermeldung "found no percenttype actor. Gruss, Jens Zitieren
theo Geschrieben March 31, 2015 at 19:52 Autor Geschrieben March 31, 2015 at 19:52 Mit dem neuen Binding geht die CPU-Auslastung auf unter 1% zurück und der Netzwerktraffic ist deutlich reduziert, aber immer noch permanent vorhanden. Allerdings funktioniert die Ansteuerung nun nicht mehr. Na dann ist ja alles im grünen Bereich 8-((. Scherz bei Seite. Was du mit den Rules zum Abfangen meinst, habe ich nicht verstanden. Kannst du vielleicht mal deine Konfiguration posten (items, rules, sitemap, openhab.cfg). Mal sehen was ich da kaputt gemacht habe. Was mir noch aufgefallen ist: ich sehe so eine ganze Latte ActionServices. Hast du viele Addons installiert? Zitieren
kyb Geschrieben March 31, 2015 at 20:35 Geschrieben March 31, 2015 at 20:35 Addons ist nur eines installiert, Dein aktuelles TF-Binding (ist ein Testsystem). tinkerforge.items (keine weiteren items) /* LED-Strips im Schlafzimmer */ Color SZ_Led1 (Colorize) {tinkerforge="uid=jG5, leds=0-255, colorMapping=rbg"} init.rules /* Deklariert und intialisiert einige globale Variablen */ /* Variablentypen */ import org.openhab.core.library.types.* /* Sollwertinitialisierung Fester Wert für den Fall, dass der letzte Wert nicht verfügbar ist */ rule SZ_Led_OFF when Item SZ_Led1 received command OFF then sendCommand(SZ_Led1,HSBType::BLACK) end rule SZ_Led_ON when Item SZ_Led1 received command ON then sendCommand(SZ_Led1,HSBType::WHITE) end Da das Ein- und Ausschalten über das Color-Item nicht funktioniert, setze ich die Helligkeit über die rules. sitemap default label="Main Menu" { Frame label="Inside Temperature" { Colorpicker item=SZ_Led1 icon="slider" } } openhab.cfg (alles deaktiviert, bis auf TF-Binding) tinkerforge:hosts=192.168.178.33 tinkerforge:refresh=60000 Kontakt zum Raspberry Pi B funktioniert, da eben der brickd aktiv wird. Gruss, Jens Zitieren
theo Geschrieben March 31, 2015 at 21:21 Autor Geschrieben March 31, 2015 at 21:21 OK. Danke. Ich spiel das mal durch und melde mich wieder. Gruß, Theo Zitieren
theo Geschrieben April 1, 2015 at 19:12 Autor Geschrieben April 1, 2015 at 19:12 Hallo Jens, ich habe den Fehler gefunden. Wenn die Zeit reicht, werde ich morgen ein gefixtes Binding haben. Gruß, Theo Zitieren
theo Geschrieben April 2, 2015 at 22:23 Autor Geschrieben April 2, 2015 at 22:23 Hallo Jens, hier gibt es einen neuen SNAPSHOT: https://bintray.com/artifact/download/theoweiss/generic/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT-led-button-2.jar Vielen Dank fürs Testen. Gruß, Theo Zitieren
kyb Geschrieben April 2, 2015 at 22:50 Geschrieben April 2, 2015 at 22:50 Hallo Theo, ich hab zu danken, für die schnelle Hilfe. Jetzt funktioniert es wieder. Ist nur ein kurzer Test, da ich übers WE wegfahre. Werde es erst nächste Woche in meine Haupt installation übernehmen. Nochmals Danke für die Behebung des Problems. Frohe Ostern, Jens Zitieren
theo Geschrieben April 2, 2015 at 22:58 Autor Geschrieben April 2, 2015 at 22:58 Hallo Jens, wow, das war schnell getestet. Was mir noch aufgefallen ist: "leds=0-255" hast du wirklich so viele LEDs? Wenn nicht würde ich mal versuchen die Anzahl anzupassen. FYI: ich werde die Tage noch versuchen die Switch-Funktionalität zu implementieren. Frohe Ostern auch von mir, Theo Zitieren
theo Geschrieben April 3, 2015 at 20:33 Autor Geschrieben April 3, 2015 at 20:33 Hallo macduff, in diesem SNAPSHOT ist auch die Dual Button Unterstützung: https://bintray.com/artifact/download/theoweiss/generic/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT-led-button-2.jar Hier findest du eine Dokumentation und eine Beispielkonfiguration: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/dualbutton Das Ganze hat jetzt doch noch etwas gedauert, es war gar nicht so einfach das richtig hinzubekommen. Ich hoffe jetzt funktioniert es wie dokumentiert. Viele Grüße, Theo Zitieren
theo Geschrieben April 3, 2015 at 20:58 Autor Geschrieben April 3, 2015 at 20:58 Noch ein paar Neuigkeiten: in dem SNAPSHOT binding sind noch weitere neue Features enthalten Support für das Joystick Bricklet: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/joystick Support für das Linear Poti Bricklet https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/linearpoti Dual Button Bricklet wurde ja bereits besprochen Alle Buttons (Dual Button, Button des Joystick Bricklets und die Buttons am LCD20x4 Bricklet unterstützen jetzt zwei konfigurierbare Modi, sie können sich als Schalter oder Taster verhalten (default ist immer Schalter). Eine Beschreibung gibt es für das DualButton Bricklet (siehe unten). Bei den beiden anderen Bricklets verhält es sich analog. Brick Daemon Authentisierung: dazu einfach in der openhab.cfg Zeile für die tinkerforge:hosts durch Doppelpunkt getrennt ein optionales Drittes Feld mit dem Passwort angeben: z.B. für 127.0.0.1 mit dem default port (deshalb leeres zweites Feld) und dem Passwort 1234. tinkerforge:hosts=127.0.0.1::1234 Ausserdem gibt es noch die neue TinkerForgeAction, dazu werde ich demnächst etwas Doku liefern. Eine Erklärung was openHAB Actions sind gibt es hier https://github.com/openhab/openhab/wiki/Actions. Wie immer bin ich für jede Rückmeldung dankbar. Zitieren
theo Geschrieben April 3, 2015 at 21:01 Autor Geschrieben April 3, 2015 at 21:01 @topi Ein deutlich verbessertes Beispiel für LCD20x4 rules findest du hier: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/blob/master/weatherstation/rules/tf.rules oder hier: http://www.tinkerforge.com/de/doc/Kits/WeatherStation/OpenHABOnREDBrick.html#starter-kit-weather-station-openhab-red-brick Zitieren
MacDuff Geschrieben April 5, 2015 at 17:34 Geschrieben April 5, 2015 at 17:34 sehr schön! danke. ich werde das die tage mal testen und getreulich berichten, wie es mir damit ergangen... md Hallo macduff, in diesem SNAPSHOT ist auch die Dual Button Unterstützung: https://bintray.com/artifact/download/theoweiss/generic/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT-led-button-2.jar Hier findest du eine Dokumentation und eine Beispielkonfiguration: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/dualbutton Das Ganze hat jetzt doch noch etwas gedauert, es war gar nicht so einfach das richtig hinzubekommen. Ich hoffe jetzt funktioniert es wie dokumentiert. Viele Grüße, Theo Zitieren
MacDuff Geschrieben April 6, 2015 at 18:00 Geschrieben April 6, 2015 at 18:00 Ging doch schneller als erwartet - und funktioniert. Ich verwende das Dual-Button-Bricklet zur Anzeige geöffneter Fenster. Ein max!-Fensterkontakt ist über eine openhab-Regel mit dem DB-Bricklet gekoppelt: rule "Window Contacts" when Item WZ_FK_1 changed or Item CB_FK_1 changed then if (WZ_FK_1.state == OPEN) { sendCommand(TF_LCD, String::format("TFNUM<10>WZ-FENSTER AUF")) sendCommand(TF_DB_1_LEDleft, ON) ... Das LCD 20x4 ist auch dabei. Das LCD-Backlight wird über das Motion Detector Bricklet getriggert, für einige Sekunden eingeschaltet und über einen Timer wieder ausgeschaltet. Allerdings geht das Backlight auch an, wenn der in meinem Aufbau ebenfalls integrierte Temperaturfühler (TF-Bricklet) einen neuen Wert liefert. Das legt zumindest das event.log nahe. Kann das sein? Generell ein paar Worte zu openhab auf dem Red Brick: Ich hatte anfangs mit FHEM auf fritzbox und Raspberry experimentiert, fand aber Performance und das GUI ziemlich furchtbar. Mit Openhab kriegt man natürlich wesentlich mehr Hardware unter einen Softwarehut. Super auch die direkte Integration von TF-Bricks und Bricklets mit dem RedBrick. Nach einigen Wochen Probieren mit RedBrick & openhab bereue ich den Umstieg nicht... aber Frustrationen gibt's natürlich auch. Ich denke, wenn openhab richtig abheben will, muss dringend was für die Dokumentation getan werden. Das Zusammenspiel von items, rules & sitemaps (plus anderem) kann durchaus komplex werden. Wenn man aber dauernd verstreute Beispiel-Dateien durchsuchen muss, um den gewünschten Funktionalitäten durch Trial & Error auf die Spur zu kommen (speziell bei rules), dann kostet das unheimlich viel Zeit und Nerven. Klar gibt es Hinweise auf xtend und xbase als Grundlagen für Rule-Syntax und Funktionen/Eigenschaften, aber die sind auch eher lausig dokumentiert. Naja -- das hat jetzt nix direkt mit TF zu tun. Nur ein Beispiel, in welche Abgründe einen die Begeisterung führen kann... jedenfalls mich als Nicht-Informatiker... - md Zitieren
theo Geschrieben April 7, 2015 at 19:45 Autor Geschrieben April 7, 2015 at 19:45 Hi MacDuff, Allerdings geht das Backlight auch an, wenn der in meinem Aufbau ebenfalls integrierte Temperaturfühler (TF-Bricklet) einen neuen Wert liefert. Das legt zumindest das event.log nahe. Kann das sein? Möglich ist alles, die Frage ist eher "Soll das sein": Nein. Um das zu debuggen sollte ich deine Konfiguration kennen und debug-Log haben. <logger name="org.openhab.binding.tinkerforge" level="DEBUG" /> Kann sein, du musst den log noch mehr eingrenzen, falls zuviel Output kommt. Was deine Kritik an openHAB betrifft gebe ich dir zu 100% recht. Die Dokumentation ist teilweise dünn und man muss sich durch hangeln. Das ist dann auch schon mal (sehr) frustrierend, das geht mir auch öfter so. Irgendwie bekommt man es meist trotzdem hin. Prinzipiell kann jeder, der einen Github-Acccount hat, das Wiki editieren, also erweitern oder verbessern. Die Hoffnung ist, das das möglichst viele Leute tun. Noch schöner fände ich einen technischen Redakteur zu haben, der einiges an Freizeit opfert. Für openhab2 / Eclipse Smarthome soll das auf jeden Fall besser werden. Der Hauptfokus von openhab2 ist die Usability. Der Vorteil von Eclipse Smarthome ist, dass auch Industriepartner dabei sind. Die können dann auch die Zeit von Hauptamtlichen Entwicklern Sponsoren, denn für reine Feierabendarbeit ist das Projekt und die Anforderungen - denke ich - mittlerweile zu groß. Was im speziellen xtext/xtend betrifft bin ich ganz deiner Meinung. Ich finde es ist für die Regelbeschreibung komplexerer Regeln nicht gut geeignet. Auch hier ist für openhab2 das Ziel die Regeln graphisch erstellen zu können. Was ich für mich noch interessanter finde ist die Einbettung von Skriptsprachen wie python, java-skript, groovy: dazu gab es kürzlich einen PullRequest, der vielversprechend aussieht: https://github.com/openhab/openhab/pull/2378 Gruß, Theo Zitieren
MacDuff Geschrieben April 11, 2015 at 07:02 Geschrieben April 11, 2015 at 07:02 Hallo Theo, das Problem konnte ich jetzt aktuell nicht weiter verfolgen, weil ich umziehe und erstmal alles abbauen muss. Evtl war da auch ein wild laufender Timer mit im Spiel... Bin sehr gespannt auf openhab2 und alles, was da mitkommen soll. Die Einbettung von Python wäre cool, mit Python kenn ich mich ganz passabel aus. Sicher fragt man sich immer wieder mal, wie man selbst mithelfen kann, wenn man sich schon so großzügig an der Arbeit anderer bedient... Zeit und Kompetenz sind die begrenzenden Faktoren, fürchte ich. Umsomehr Respekt für dein Engagement! schönes Wochenende, md Zitieren
theo Geschrieben April 13, 2015 at 19:37 Autor Geschrieben April 13, 2015 at 19:37 Ein Dankeschön an TinkerForge und gute Nachrichten für die openHAB-User! Dank eines weiteren großzügigen Hardware-Sponsorings durch die TinkerForger habe ich jetzt alle aktuell verfügbaren Bricks und Bricklets. Vielen Dank dafür an die TinkerForge-Macher und auch für die tolle unkomplizierte Zusammenarbeit! Das heißt für die openHAB-User, dass sich die Hardware-Unterstützung nach und nach weiter ausbaut und vervollständigt! Als erstes habe ich mir das Industrial Dual 0-20mA Bricklet, das PTC Bricklet und Solid State Relay Bricklet vorgenommen. Sollte jemand dringend ein anderes Bricklet/Brick brauchen, dann bitte gerne melden. Dann kann ich sehen was sich machen läßt. Für die oben genannten Bricklets gab es auch konkrete Anfragen. Viele Grüße, Theo Zitieren
Gast sihui Geschrieben April 13, 2015 at 19:58 Geschrieben April 13, 2015 at 19:58 Das sind ja hervorragende Nachrichten. Für mich ein Grund, zukünftig weitere TF Hardware in OH zu integrieren. Und danke noch einmal für das Binding, das war für mich letztes Jahr der Hauptgrund, auf TF und OH zu setzen. Gruß, Sigi Zitieren
theo Geschrieben April 19, 2015 at 13:36 Autor Geschrieben April 19, 2015 at 13:36 Ich habe gerade einen neuen SNAPSHOT mit Unterstützung für drei weitere Bricklets veröffentlicht. Das PTCBricklet, das Industrial Dual 0-20mA Bricklet und das Solid State Relay Bricklet sollten damit funktionieren. Beispielkonfigurationen könnt ihr hier finden: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples Der Download ist hier: https://bintray.com/artifact/download/theoweiss/generic/ptc/1/org.openhab.binding.tinkerforge-1.7.0-SNAPSHOT.jar Viel Spaß beim Testen. Rückmeldung wie immer erbeten. Gruß, Theo Zitieren
ChristianRiedl Geschrieben May 5, 2015 at 13:24 Geschrieben May 5, 2015 at 13:24 Hallo Theo, du hast mit der Tinkerforge openHab Integration einen tollen Job gemacht ! Ich bin eigentlich gewohnt die Dinge selbst aus dem vollen zu schnitzen. Allerdings komm ich mehr aus der Microsoft / C# Ecke. Die .NET Micro Framework Dinger gefallen mir aber bei weitem nicht so gut wie die Tinkerforge Module. Wollte ursprünglich auf dem RED Brick ein REST Service implementieren habe aber dann die Abkürzung mit openHab genommen. Zu meinem Glück fehlt mir noch der Support für den Piezo Speaker. Ist sicher kein sehr wichtiges Teil aber vielleicht hast du mal Zeit und Lust es piepsen zu lassen :-)) Beep(long duration, int frequency); Zitieren
theo Geschrieben May 5, 2015 at 22:09 Autor Geschrieben May 5, 2015 at 22:09 Hallo Christian, Dank dir für die Rückmeldung. Piepen wird kommen! Im Moment bin ich mit den openHAB 1.7 Release-Arbeiten beschäftigt, sobald das durch ist wird es neue Geräte geben. Der Piezo Speaker macht sicher Spaß, ich gebe Bescheid sobald es was zum Testen gibt. Gruß, Theo Zitieren
Sidi Geschrieben May 17, 2015 at 18:06 Geschrieben May 17, 2015 at 18:06 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. Guten Tag Ich möchte mir für meine Wohnung mit openHAB und Tinkerforge eine Steuerung für die Beleuchtung zusammenbauen. Später soll dann ev. noch Multimedia und Temperaturüberwachung dazu kommen. Die ersten Schritte habe ich schon mal bewältigt. Für die ersten Tests, läuft openHAB (1.7.0) auf einem Windows Rechner. Irgendwann soll es dann auf einen RaspberryPi, oder besser auf einen REDbrick. Es hat etwas Zeit und Recherche gebraucht, aber bis jetzt habe ich (mit sehr rudimentären Programmier-Kenntnissen) Intertechno Funksteckdosen und Dimmer ITDM-250 zum Funktionieren gebracht und mit dem Browser getestet. Ein/Aus bei den Funksteckdosen geht einwandfrei. Dimmen funktioniert grundsätzlich. Increase=Leuchte wird heller oder schaltet ein. Decrease=Leuchte wird dunkler (bis zur schwächsten Dimmstufe). Das Problem ist, dass keine Aus-Funktion verfügbar ist. Ausschalten geht auch bei direktem ansprechen aus dem Brick Viewer nicht. B Dimmer, DimValue=0, schaltet die Leuchte auf die schwächste Dimmstufe, aber nicht aus. Dasselbe passiert beim Ansprechen mit http://www.iot-remote.com . Kennt da jemand einen Lösungsansatz? openHAB scheint mir ein sehr vielversprechender Ansatz für IoT zu sein. Dahinter steckt eine Menge Arbeit für welche ich mich hier schon mal bedanken möchte. Grüsse Sidi Zitieren
Gast sihui Geschrieben May 29, 2015 at 19:29 Geschrieben May 29, 2015 at 19:29 Kennt da jemand einen Lösungsansatz? Als workaround könntest du den ITDM 250 mit den gleichen Parametern wie beim Dimmer noch einmal als Swich konfigurieren, klappt bei mir einwandfrei. Gruß, Sigi Zitieren
Ray Geschrieben August 11, 2015 at 19:02 Geschrieben August 11, 2015 at 19:02 Hallo Theo, ich wollte nur eine kurze Rückmeldung geben, dass das Openhab binding für das PTC Bricklet einwandfrei funktioniert. Danke für die Integration! Gruß Raimund 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.