Jump to content

rtrbt

Administrators
  • Content Count

    599
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by rtrbt

  1. Moin,

    Teste mal immer mit

    tinkerforge_mqtt --debug ... andere Flags

    Dann bekommst du mehr hilfreiche Ausgabe.

    Mich wundert folgendes:

    1 hour ago, Manuel Ziel said:

    Obwohl ich den Brocker schon länger, ohne SSL, auf dem Port 8883 laufen habe und nie den Port in tinkerforge_mqtt eingestellt habe hat es funktioniert

    Die Bindings verwenden als Default-Port immer die 1883, d.h. wenn du den Broker ohne Verschlüsselung auch auf der 8883 laufen hast, hätte das nie funktionieren dürfen, wenn du den Port nicht angibst. Teste bitte nochmal, wie das bei deaktiviertem TLS mit den Ports genau ist, also ob du, selbst wenn du in mosquitto.conf 8883 konfigurierst, du mit der Default-Einstellung der Bindings eine Verbindung bekommst. Dann wäre auch interessant, was passiert, wenn du explizit --broker-port 1883 oder --broker-port 8883 mitgibst.

    Die ganze SSL/TLS-Geschichte werde ich unabhängig davon in den nächsten Tagen hier nochmal durchtesten, bisher gab es da keine Beschwerden, aber auch kein positives Feedback, eventuell ist das also wirklich einfach kaputt und es hat bisher noch niemand gemerkt. Bis ich zum testen komme kann es aber noch etwas dauern, also durchaus erst nächste Woche oder so. Ich gebe Bescheid ;)

     

  2. Moin,

    Ich hatte dein Script falsch gelesen, eigentlich hätte ich schon sehen können, wo das Problem ist: Du hast im Script ja eine Endlosschleife und darin die for-Schleife, die die Spannungen durchgeht. Das Problem ist jetzt, dass nach einem Durchlauf der for-Schleife du auf eine Eingabe wartest und danach die Verbindung zum Brick Daemon schließt, dann aber wegen der Endlosschleife die nächste Runde Spannungssetzen machst, was aber nur klappt, wenn die Verbindung noch da ist.

    Du müsstest also die beiden letzten Zeilen aus der Schleife rausnehmen, wenn du die ganze Zeit die Spannungen durchlaufen willst, oder alternativ, wenn du immer auf einen Tastendruck warten willst vor der nächsten Runde lässt du das input("...") in der Schleife, dann würde ich aber den Text ändern, ist dann ja kein Exit mehr.

  3. Moin,

    Die MQTT-API steht soweit, ich bin gerade dabei sie zu dokumentieren. Ich bin optimistisch, dass das diese Woche fertig wird. Stand jetzt kannst du (neben nicht direkt ladebezogenen Dingen):

    • den aktuellen Zustand (ist ein Auto angeschlossen, wird geladen, usw.) auslesen
    • den Ladestrom in mA einstellen,
    • den Ladevorgang starten, stoppen und Autostart konfigurieren
    • Bei der Pro-Variante den Zähler auslesen

    Wenn du für deinen Anwendungsfall noch andere Features brauchst, wäre das sehr interessant zu wissen. Aktuell kann ich die API noch beliebig ändern, ohne dass ich funktionierende Software breche.

    OCPP wird mit der ersten Software-Version noch nicht kommen, Support dafür wird dann eins der Updates.

  4. 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.

  5. 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.

  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 Viewer (siehe Start-Menü) verbindet sich automatisch zum Brick Daemon. Im Menü oben gibt es den Punkt "Logfile" -> "View Log Directory", in dem Ordner sollten zwei Dateien liegen (brickd.log und brickd.ini). Häng die beiden mal auch an.

  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 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 aus dem Gehäuse ziehen, das ist nicht geklebt oder so. Vielleicht siehst du da einen Schaden.

  10. Moin,

    Sorry dein Post ist hier etwas untergegangen.

    On 1/8/2021 at 5:23 PM, Docmac said:

    1) Bzgl. PV Überschussladung - muss ich einen MQTT Server/Broker Rechner selbst vorhalten der die Daten aus Node Red o.ä verarbeitet oder ist so einer im Warp Charger Smart schon enthalten?

    Den MQTT-Broker musst du selbst mitbringen, die Wallbox hat nur einen MQTT-Client

    On 1/8/2021 at 5:23 PM, Docmac said:

    2) Umschalten 1phasig <-> 3phasiges Laden sowie Anpassung der Ladeleistung über MQTT möglich?

    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 gerade nicht im Kopf).

  11. 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.

  12. 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.

    On 1/4/2021 at 8:13 PM, lapawa said:

    dass brickd ständig write Zugriffe auf libusb ausführt. Und dies obwohl das HAT per SPI mit den Bricklets kommuniziert.

    Das liegt vermutlich daran, dass der Brick Daemon für den Pi auch Stacks per USB unterstützt. Das ist keine spezielle gestrippte Version, die nur SPI kann.

    On 1/4/2021 at 8:13 PM, lapawa said:

    dass die GPIO Exports beim Beenden von brickd nicht wieder beim Kernel abgemeldet werden.

    Das ist interessant, dazu muss ich @photron mal befragen.

    On 1/4/2021 at 8:13 PM, lapawa said:

    Zugriff auf die Zeitzonen datei /etc/localtime funktioniert nicht. Da sie nicht existiert.
    openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
    Ist dies ein Problem für brickd?

    Das sollte kein Problem sein, du hast ja ein HAT Zero, das hat sowieso keine RTC an Bord.

    On 1/4/2021 at 8:13 PM, lapawa said:

    Meine Frage hierzu: Kann der Kernel SPI Treiber das CS Timing nicht besser selbst erledigen? Clock und MasterOut kommt ja auch von dort, oder?

    Nein, weil der Kernel nicht genug CS-Pins unterstützt. Meines Wissens nur zwei. Ab Brick Daemon 2.4.2 umgehen wir sowieso das ganze Kernel-Interface und sprechen direkt mit dem BCM2835.

  13. 13 hours ago, Mausschieber said:

    Es gibt doch auch die Möglichkeit, auf einem ESP32 Micropython zu flashen. Ginge das wohl auch mit eurem ESP-Brick?

    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.

  14. 4 hours ago, piwo2 said:

    ich habe ein problem, eine definitve entscheigungsgrundlage zu haben, wann die bricks/bricklets WIRKLICH neu konfiguriert werden müsen

    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 abziehst und wieder dransteckst. Wenn alles andere noch läuft, solltest du im Moment des Stecker-ziehens ein Enumerate mit Disconnected für alle Bricks/Bricklets bekommen, auf jeden Fall bekommst du aber ein Enumerate mit Connected, wenn der Stack angeschlossen wird.
    • Der Brick Daemon. Wenn der neustartet oder du aus anderen Gründen die Verbindung verlierst, kannst du das über das connected btw. disconnected Callback mitbekommen.
    • Der MQTT-Broker. Das hängt etwas vom Broker ab, was passiert wenn du den neustartest. Bei mosquitto kannst du dich wie oben beschrieben auf $SYS/broker/version subscriben. (Achtung: In der Shell brauchst du Anführungszeichen oder musst das $ escapen, sonst wirds nichts)
    • Die MQTT-Bindings. Wenn die Bindings sich sauber beenden siehst du das unter "tinkerforge/callback/bindings/shutdown", falls sie crashen (und deshalb diesen Publish nicht schaffen würden) siehst du stattdessen "tinkerforge/callback/bindings/last_will". Wenn die Bindings (neu)starten bekommst du "tinkerforge/callback/bindings/restart", auf allen diesen Topics ist der Payload einfach null, da geht es ja nur um das Signal selbst. Den last_will bekommst du übrigens auch wenn der Broker (sauber) beendet wird.

    Wenn jetzt irgendeine Komponente neustartet, musst du im worst-Case alle Callbacks neu registrieren und aktivieren und alle Konfiguration der Bricks/Bricklets neusetzen. Es kann dir nämlich passieren, das z.b. der MQTT-Broker abschmiert, während der weg ist, aber der Stack neustartet, weil jemand ungünstig ans USB-Kabel gekommen ist oder so. Das bekommst du jetzt aber nicht mehr mit, d.h. wenn der Broker wieder kommt weißt du nicht was in der Zwischenzeit passiert ist.

    Andererseits kannst du natürlich Glück haben und der Broker-Neustart hat sonst nichts beeinflusst, dann kommen deine Daten weiterhin durch. WIe gesagt, das hängt von der Paranoia/den Robustheitsansprüchen hab.

    Ich würde folgendes machen: Baue dir in einem z.b. Pythonscript eine Initialisierungsfunktion pro Brick/Bricklet, die die Callbacks registriert und aktiviert und alles konfiguriert. und "glaube" den Daten nur, wenn die erfolgreich durchgelaufen ist. Wenn du jetzt in der Kette irgendeinen Crash/Neustart detektierst, führst du die Funktionen alle neu aus. Du kannst dann natürlich optimieren und wenn du einen einzelnen Brick(let) neustart siehst nur das eine Gerät neu initialisieren.

  15. 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.)

    12 hours ago, Martin said:

    zwar ein Link auf
    https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta23.zip
    (wobei "Die 23. Beta findet sich hier." nicht gerade optimal für eine Internet-Suche ist)
    Später dann z.B. unter
    https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/page/12/?tab=comments#comment-30294
    noch ein Anhang (https://www.tinkerunity.org/applications/core/interface/file/attachment.php?id=2096),
    der hier allerdings scheinbar nicht mehr vorhanden ist ("unavailable").

    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.

    12 hours ago, Martin said:

    Welches Java Binding soll verwendet werden?
    https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/?do=findComment&comment=31828
    Was denn nun? tinkerforge-2.1.26.jar oder 2.1.29?

    2.1.26. Mir ist absolut unklar, was bei der Installation von skober19 dazu führt, dass die Version nicht funktioniert.

    12 hours ago, Martin said:

    Für Debian/Ubuntu gibt es eine Tinkerforge Repository mit Java-Bindings

    Das bringt dich nicht weiter, du musst die Java-Bindings-Jar direkt mit in den addons-Ordner von openHAB ablegen.

    12 hours ago, Martin said:

    Vielleicht könnte man die openhab Bindings einfach auch hier verfügbar machen.
    Am besten wäre aber (wieder) ein "offizielles" OpenHAB Binding (am besten gleich für OpenHAB3).

    Das ist langfristig das Ziel, dafür muss das Binding nur erst "fertig" werden.

    Auch für die anderen im Thread: Ich weiß, dass sich das schon lange verschleppt, ich kann als schlechte Ausrede aber nur anbieten, dass ich halt als einziger daran entwickle und der Aufgabenhaufen mit höherer Priorität (Mikrocontroller-Bindings, ESP32-Brick-Firmware, Wallbox-Firmware) langsam aber sicher kleiner wird.

  16. 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/broker/version" registrierst, da gibt Mosquitto beim (Neu)Start die Versionsnummer aus.
     

  17. 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.

×
×
  • Create New...