Jump to content

rtrbt

Administrators
  • Content Count

    570
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by rtrbt

  1. Wäre hier nicht bekannt, zumindest als Client. Wenn du die Extension als Access Point verwenden willst, geht aber nur b/g.
  2. Moin, Wenn du wirklich nur bemerken willst, ob es regnet und dir eigentlich egal ist, wie viel, kannst du einen Regensensor, wie z.B. diesen hier benutzen. (Die findest du bestimmt auch irgendwo qualitativ hochwertiger). Du kannst damit entweder direkt den Widerstand an den zwe Kontakten des Sensors messen, oder benutzt den digitalen Ausgang von dem Zusatzboard mit einem geeigneten Bricklet. Das sieht so aus, als ob da ein Komparator drauf sitzt und du mit dem Potentiometer einstellen kannst, wann der auslöst.
  3. Moin, Du kannst dieses Script, das eigentlich für den RED-Brick ist, verwenden. Das sollte auch auf dem Pi funktionieren, du müsstest nur das Sudo-Passwort ändern.
  4. Im Handbuch steht auch (Seite 6): "Das Gerät dient NUR zum Einsatz von dreiphasigen Wechselstromstromnetzen mit Neutralleiter." Ich habe bei mir einen auf dem Tisch legen, den wir zwecks einfacherer Entwicklung nur einphasig verkabelt haben, der startet dann alle 30 Sekunden oder so neu.
  5. Die Sequenznummer kannst du in der Tat eher als Jobnummer betrachten. Die ist nur dafür da, ansonsten identisch aussehende Anfragen unterscheiden zu können. Den Bricklets ist egal, ob du die Reihenfolge der Sequenznummern einhältst oder nicht. Edit: 15 Zahlen, nur die 0 ist für Callbacks reserviert.
  6. Moin, So wie das Script aussieht, sollte das funktionieren: ipcon.connect blockiert, bis die Verbindung aufgebaut ist, deshalb ergibt das keinen Sinn, dass danach ein "Not connected"-Fehler kommt, kann ich mir dann nur so erklären, dass sich dein Brick Daemon beendet o.Ä. Teste mal folgendes: Mach den Brick Viewer auf, verbinde dich zu localhost (Mach dann am besten einen Screenshot vom Setup-Tab und häng ihn hier an), lass dann dein Script laufen, und sieh nach ob der Brick Viewer auch die Verbindung verliert. In jedem Fall kannst du mal ein Brick Daemon-Log anhängen. Der Log V
  7. Moin, Da gibt es mit der alten WiFi-Extension und einigen Routern tatsächlich Probleme. Siehe zum Beispiel dieser Thread. Ich habe hier mit dem extra Router für Wifi-Experimente getestet (eine alte Fritz-Box 7360 SL mit Fritz OS 06.33) und sowohl b/g/n, als auch nur g/n funktionieren. An dem Router kann ich leider nicht g auch deaktivieren um den Support für 802.11n zu testen, den der Wifi-Chip auf der Extension zumindest laut Datenblatt haben sollte, aber g/n geht aber von der Extension aus.
  8. Ich hoffe, du hast diese Warnung gelesen, ich vermute deine LEDs würden bei maximal 30 Hz ziemlich flackern und mehr ist wie beschrieben wirklich keine gute Idee. Falls du mit den niedrigen Schaltfrequenzen leben kannst, hast du das nächste Problem, dass du mit einer openHAB-Regel sauber ein 30 Hz Timing hinbekommen musst. Da sehe ich ehrlich gesagt schwarz. Du könntest stattdessen z.B. ein Pythonscript schreiben und mit openHABs Exec-Bindung ausführen. Dann darfst du aber nicht das Relay Bricklet parallel in openHAB benutzen (lies: nicht aus der Inbox als Thing übernehmen).
  9. Das ist eine gute Erklärung, die Platine hat da ja auch ziemlich viel Spiel. Gut das jetzt alles funktioniert!
  10. Das Pluviometer ist ein Reedschalter. Du kannst also, wenn du ein Multimeter oder Oszilloskop zur Hand hast, an die Kontakte gehen und dann Wasser nachgießen, du solltest dann bei jeder Wippenbewegung einen Impuls sehen. Statt des Wassers kannst du auch das Gehäuse vom Pluviometer abmachen (unten an den Befestigungsösen sind zwei Haken, die kannst du reindrücken, dann geht die ganze obere Verkleidung ab) und die Wippe von Hand betätigen. Wenn du von der Seite reinsiehst,siehst du den Magneten, der den Schalter auslöst. Wenn das auch nicht tut, kannst du die Leiterkarte mit dem Schalter a
  11. Moin, Steckt der Stecker des Pluviometers richtig? Du kannst den Sonnenschutz (siehe dieses Bild) komplett hochschieben, darunter müsste der Stecker des Pluviometers in der rechten Buchse stecken. Sieh dir mal die Kontakte an (das sind nur die zwei mittleren im Stecker), eventuell siehst du da was. Gruß, Erik
  12. Moin, Sorry dein Post ist hier etwas untergegangen. Den MQTT-Broker musst du selbst mitbringen, die Wallbox hat nur einen MQTT-Client Nein und Ja: Die Ladeleistung anpassen kannst du sowohl per MQTT, als auch über das Webinterface von minimal 6 Ampere bis zum konfigurierten Limit der Wallbox. Die Box kann aber nicht zwischen einphasigem und dreiphasigem Laden umschalten. Es kann aber sein, dass dein Auto selbst auf einphasiges Laden wechselt, wenn du den Ladestrom weit genug begrenzt, beim Zoe passiert das z.B. irgendwo zwischen 8 und 10 Ampere (habe den genauen Punkt gera
  13. Das sieht wieder genau nach dem Problem aus, das die Spezialversion fixen sollte: Alle 5 ThingHandler-Threads hängen wieder beim Versuch zu testen ob ein Bricket erreichbar ist. Bist du dir sicher, dass es die Version ist? ;) Wenn ja muss ich mir das nochmal in Ruhe ansehen, Multi-Threading ist kompliziert. Das kommt auf jeden Fall ganz oben auf die openHAB-Todo-Liste, wird aber wie gesagt noch etwas dauern, bis ich dazu komme.
  14. Bezüglich der Taktfrequenzen: Brick Daemon bis einschließlich 2.4.2 erwartet eine core-Clock von 250 MHz (die die du mit vcgencmd measure_clock core ausgelesen hast). Beim Pi Zero kannst du die Frequenz mit core_freq=250 in /boot/config.txt festlegen. Die Umbauarbeiten in 2.4.2 und 2.4.3 sind genau dafür da solche Probleme zu umgehen, der Pi skaliert nämlich die SPI-Clock mit der core_freq, d.h. wenn er auf 400 MHz läuft, läuft SPI so schnell, dass die Bricklets das nicht mehr verstehen. Das liegt vermutlich daran, dass der Brick Daemon für den Pi auch Stacks per USB unterstützt
  15. Das geht prinzipiell, es gibt aber (noch) keine Micropython-Bindings für die Bricklets, die du an den ESP-Brick anschließen kannst. Ich habe noch auf meiner TODO-Liste stehen, zu untersuchen ob wir Micropython-Bindings anbieten wollen, bzw. wie viel Aufwand das wäre die zu generieren.
  16. Das kommt ganz auf deine Paranoia an ;) Ich habe bei den openHAB-Bindings das gleiche Problem und bin da relativ aggressiv, lies ich konfiguriere immer alles neu, wenn ich mir nicht 100%ig sicher bin, dass alles passt. Ich versuche mal alle Komponenten aufzulisten, bei denen was schief gehen kann, frag nochmal wenn da irgendwelche Lücken sind. Es gibt: Einzelne Bricks/Bricklets: Die schicken beim Neustart ein Enumerate mit Connected. Das passiert z.b. wenn du die Firmware aktualisierst, oder aus anderen Gründen ein Brick(let) resettest. Den Stack, der neustartet wenn du USB ab
  17. Hi, Sorry this will take another few months. I've got a (slowly shrinking) heap of tasks with higher priority, and once that is done, I will port the binding to OH3 and finish it.
  18. Moin, @Martin Du suchst vermutlich diese Seite: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html (Der Download-Link darauf bringt dich nicht weiter, aber die ganze Dokumentation sollte hilfreich sein.) Die funktionieren bei mir beide. Nimm im Zweifel eher den zweiten, also den Anhang im Forum. Warst du eventuell nicht eingeloggt, als du versucht hast den runterzuladen? Das sollte eigentlich ohne Login gehen, aber vielleicht ist die Forensoftware da falsch konfiguriert. 2.1.26. Mir ist absolut unklar, was bei der Installation von skober19 dazu führt,
  19. Hi, You are correct, this is a bug in the unpack logic of multiple boolean arrays. Can you please test the attached version? Erik tinkerforge_ruby_bindings_2_1_27.zip
  20. Moin, Sorry für die späte Antwort, Weihnachtsurlaub und so. Das ist tatsächlich kein Bug im eigentlichen Sinne: post_connect wird nur einmal ausgeführt und zwar nachdem die Verbindung zum Brick Daemon steht (die wird nach der Verbindung zum Broker aufgebaut). Auf meiner "Nice-to-have"-Liste steht tatsächlich noch "configure" o.Ä. einzuführen, was dann nach jeder Neuverbindung zum Broker oder Brick Daemon ausgeführt werden würde, für genau solche Fälle. Das kann aber noch etwas dauern, bis ich dazu komme. Du kannst Mosquitto-Neustarts aber mitbekommen, indem du dich auf "$SYS/bro
  21. Moin, Ja, Port E ist der vom HAT selbst. Das Problem, dass du da hast scheint ein Bug in der aktuellen Version von Brick Daemon zu sein, ist z.B. hier schon mal aufgetaucht. @photron ist noch im Weihnachtsurlaub, aber in den nächsten Wochen fixen wir das. Edit: Als Work-Around kannst du auch probieren, ob Brick Daemon 2.4.1 bei dir das Problem nicht erzeugt. Der braucht aber udev oder ähnliches.
  22. Moin, Über die Reihenfolge hast du, wenn du Callbacks benutzt, keine Kontrolle, da die Bricklets asynchron zueinander laufen. Du kannst aber über das Topic gehen: Die Callbacks tauchen ja auf tinkerforge/callback/outdoor_weather_bricklet/SvZ/station_data bzw. tinkerforge/callback/outdoor_weather_bricklet/SvZ/sensor_data auf. D.h. du könntest mit jeweils einem Shellscript eins der Topics subscriben.
  23. Moin, Das ist interessant. Hat das Tab-Wechseln visuell noch funktioniert? Also dass der berührte Tab dann aktiv war, auch wenn dessen GUI vermutlich gefehlt hat, weil ja das Callback fehlte. Damit könnte man gut diagnostizieren, wo das schief gelaufen ist. Das kenne ich, da bin ich aber noch nicht hinterher gestiegen, man kommt hier ja zu nichts :D Nein, weil das bisher von meiner Seite aus "ungetestet" ist. Als nächstes steht sowieso der Wechsel zu openHAB 3 an, da muss ich das dann in Ruhe ausprobieren, wie das mit den Files ist. Bisher "unterstützt" ist
  24. Moin, Ich vermute, dass das nicht klappen wird: Diese Tierchips scheinen laut diesem Artikel alle auf einem Frequenzband von ungefähr 130 kHz zu laufen. Das NFC Bricklet arbeitet aber auf 13,56 MHz, weil die ganzen NFC-Standards auf der Frequenz liegen.
  25. Another thought: Does this happen if you downgrade to Brick Daemon 2.4.1? This version is too old to be available in the APT repository, however you can download it here: https://download.tinkerforge.com/tools/brickd/linux/brickd-2.4.1_armhf.deb
×
×
  • Create New...