Jump to content

kyb

Members
  • Gesamte Inhalte

    7
  • Benutzer seit

  • Letzter Besuch

kyb's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Moin Zusammen, hier mal 2 Vorschläge für evtl. Hardwarervisionen des Moisture Bricklets. Für V1.1 würde ich mir eine per API schaltbare LED wünschen. Auf diese Weise lässt sich sofort sehen, an welcher Stelle es zu trocken ist. Ich hab einen ähnlichen Sensor gebastelt der von einem Arduino überwacht wird. Wirds zu trocken, schaltet der einfach eine LED an. So sehe ich sofort, dass es Zeit ist zu giessen. Mit eurem Sensor muss ich mir was basteln oder die Sensoren beschriften und mir vom RasPi ne Mail schicken lassen. Für V2.0 würde ich eine andere Messmethode wünschen, da Strom durch feuchte Erde immer auch Korrosion bzw. galvanische Prozesse zur Folge hat. Eine Methode ohne Stromfluss durch die Erde wäre eine Frequenzmessung. Hierzu wird z.B. zum Kondensator, mit dessen Hilfe der Ausgangstakt eines NE555 festgelegt wird, der "Erdkondensator" parallel geschaltet. Die dielektrischen Eigenschaften von feuchter Erde unterscheiden sich von denen trockener Erde und somit ändert sich auch die Taktfrequenz des NE555. Der grosse Vorteil liegt eben darin, dass die Panels, die für den Erdkondensator in die Erde gesteckt werden müssen, elektrisch Isoliert sind und somit keine Korrosionsanfälligkeit aufweisen. Der Nachteil ist, dass der User selber testen muss, welche Frequenzen zu trocken und feucht gehören. Das funktioniert recht gut, ich habe so eine Schaltung mal auf dem Steckbrett aufgebaut (die Idee für die Schaltung ist nicht von mir ;-) BTW, könntet ihr noch in die aktuelle Doku aufnehmen, welche im Brickv angezeigten Werte nass und trocken entsprechen (also Min und Maxwerte)? So fehlt mir etwas die Einschätzung. (Entspricht der angezeigte Wert der Spannung über die beiden Schenkel in [mV]?). OK, ich könnte natürlich den Sensor kurz ins Wasser stecken, aber das fehlt irgendwie trotzdem in der Doku (oder habe ich es übersehen?) Gruesse, Jens
×
×
  • Neu erstellen...