rtrbt

Moin, Das ist ein WARP 1. WARP 2 gibt es erst seit ~ August 2021. Die EVSE-Fehlermeldung ist nicht wirklich ein Fehler. Was da pssiert ist, dass die Wallbox-Firmware beim Booten nachsieht, welche Firmware auf dem EVSE, also dem Ladecontroller, ist. Wenn das nicht die zur Wallbox-Firmware passende ist, wird umgeflasht. Du müsstest also danach eingerückte Ausgaben in die Richtung bekommen haben. Wenn alles geklappt hat ist die letzte Ausgabe "Firmware flashed successfully". Das klingt seltsam. Lad mal das Webinterface neu, geh dann auf System->Firmware-Aktualisierung und sieh nach was die Firmware-Version (die obere von beiden) ist. Flashe dann gleich die 1.3.2 (du musst nicht alle FIrmwares nacheinander flashen, immer direkt auf die aktuellste zu gehen ist am sinnvollsten). Falls das nicht funktioniert, ziehe bitte einmal einen Debug-Report + Ereignis-Log (unter System->Ereignis-Log) und häng beides hier an.

Fixed. The docs are generating right now.

@MiRo Please test the attached version of the bindings. For some reason "value has to change" was indeed set to true for the IO 4 2.0 and IO 16 2.0 Bricklets (and only those). tinkerforge_openhab_bindings_2_0_0_beta24_io16fix.zip

Der höchst ungenaue und inoffizielle Zeitplan sagt "Richtung Ende Januar". Das ist das aktuelle große Feature an dem wir arbeiten.

Das EVSE kann nur an ein CP-Signal und ein Schütz verkabelt werden. Da du aber sowieso in der Firmware des ESP Bricks rumhackst: Du kannst auf jeden Fall über die Bindings mit zwei EVSE Bricklets reden. Das ganze Firmware-drumherum ist darauf aber nicht ausgelegt. Eventuell kannst du aber ein DeviceModule für das zweite EVSE anlegen, da es anhand der Device-ID nach EVSEs sucht. Die Logik in tf_hal_get_tfp sollte clever genug sein, dass das DeviceModule dir erst das in Portreihenfolge erste EVSE und danach das zweite gibt. Du musst dann die APIs dann auf /evse2/ registrieren und eventuell das Frontend-Modul kopieren und die Pfade patchen. Das ist aber natürlich nicht offiziell unterstützt ;)

Moin, Tatsächlich teste ich meistens nur bis auf 360px runter. Dein iPhone hat mit einer Device Pixel Ratio von 2 nur 320px Breite. Zumindest die Änderung, damit der Button in der ersten Zeile bleibt ging relativ problemlos, sollte mit der nächsten Firmware kommen. Das Logo schiebt sich jetzt einfach etwas kleiner, wenn die Breite sonst nicht für beides reicht. Was leider nicht so einfach zu fixen ist, ist die X-Achsenbeschriftung der Stromzählergraphen. Da möchte ich nicht garantieren, dass ich den Aufwand investiere. Es gibt jetzt aber trotzdem ein Issue dafür, damit wir uns das nochmal in Ruhe ansehen: https://github.com/Tinkerforge/esp32-firmware/issues/93

To be honest, I am out of ideas. As a last resort: Can you test the WiFi client mode with another access point? (If you don't have one available you could use one WiFi extension in AP mode and connect the other one to it) Maybe there is a firmware update available for your AP? If nothing of this helps, we can offer you to either exchange the extensions for new ones (but as the issue occurs with both extensions, I would not expect this to magically solve it) or you can of course return the extensions.

Der neue NFC-Modus funktioniert theoretisch ohne Rules: Der Modus ist eine Konfiguration des Bricklets, wenn du den auf "Simple" stellst, bekommt das Thing drei neue Channel, für Tag-ID, Tag-Typ und die Zeit wann ein Tag zuletzt gesehen wurde. Die befüllen sich automatisch, wenn du ein Tag dranhältst. Ja. Du kannst dann auch die neue Funktionalität des Bricks benutzen: es gibt einen "Bricklets Enabled"-Channel mit dem du die angeschlossenen Bricklets an und abschalten kannst.

Wir haben das Problem gefunden: Der Bug tritt nur bei E-Paper Bricklets auf, die den neueren Treiberchip (den SSD1680) verwenden. Ich hatte hier erst nur mit der alten Version getestet (dem SSD1675A), da klappt auch dein zweites Programm ohne Probleme. Ich bzw. @borg melden uns nochmal, wenn wir mehr wissen.

Jain, es kann passieren, dass der Windsensor sich zum Großteil nicht dreht, aber wegen einer Böe alle 10, 20 Sekunden immer mal kurz. Das kannst du natürlich als kein Wind betrachten, der Sensor misst das aber erstmal so.

Ich habe dein Programm mal getestet, mit dem E-Paper Bricklet hier funktioniert es und der DrawStatus springt auch zurück auf Idle. Trotzdem folgende Fragen: Kannst du mit dem Brick Viewer mehrmals zeichnen? Hast du eventuell mehrere Instanzen von deinem Programm, oder dein Programm und Brick Viewer gleichzeitig laufen und die stören sich gegenseitig?

Moin Stefan, Das Problem nach dem ersten Start riecht noch nach irgendwelchen Cache-Problemen, bzw. was ich auch schon beobachten konnte: Manchmal passt beim ersten Start die Reihenfolge aus Thing erstellen und Rules ausführen nicht. Wenn das aber nicht nochmal auftaucht, würde ich das erstmal hinnehmen. Der Reset ist noch nicht in der Doku, weil ich vergessen habe, die auf dem Server neuzubauen, sollte heute noch kommen. Der korrekte Weg ihn auszuführen sollte val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQJ") lcdActions128x64.brickletLCD128x64Reset() sein.

Damit der Böenwert auch auf 0 geht, muss es wirklich perfekt Windstill sein. Ich habe das hier kurz getestet: Wenn man den Windsensor ein Messintervall, also die 45 bis 50 Sekunden lang festhält geht der Wert auf 0, wenn man dann eine Umdrehung des Sensors macht und danach weiter festhält, werden es 0,3. Das hängt ganz davon ab welche Software du benutzt. Der Brick Viewer löscht Stations nie. Du könntest aber in einem eigenen Programm eine Station löschen, wenn sie z.B. länger als 5 Minuten nicht empfangen wurde.

Hi, The new firmwares only fix unrelated problems, for example 2.1.5 fixes the LED issue you've found. Yeah, this does not look perfect. Are the WiFi problems also happening with the other extension? If yes, I would assume that they are not caused by bad soldering. Some questions to find out on which level this is broken: If you configure an extension to the Client + AP mode the status LED should be blinking continously. When the stack becomes unresponsive, does the LED still blink? When a stack becomes unresponsive, and you plug in a USB cable, can you still reach the stack on localhost via USB? Did you only postpone TFP connections or also pings etc? Another idea: Does this also happen if you don't connect the stack to your network at all, but instead only use its access point?

Moin, Stand jetzt funktioniert das in der Tat nicht. Androids Host-based Card Emulation API gibt leider vor, dass die IDs rotieren, siehe z.B. hier: https://stackoverflow.com/questions/19764476/host-based-card-emulation-with-fixed-card-id Eventuell können wir in der Zukunft einen Work-Around in die Wallbox-Firmware einbauen, aber das kann und will ich erstmal nicht versprechen. Damit das nicht in Vergessenheit gerät, habe ich ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/90

I'm currently trying to reproduce this. So far the WiFi connection still works. Is this just some dirt or a bit of solder? Can you scrape it away? (Just to make sure this does not short-circuit anything)

Flashing Master Bricks works with the (non-M1) Macbook, that we have here. We've ordered an M1 Macbook (sooner or later we would have to test some things with one anyway), but this will take a while.

You can use a GPIO connector like this one: https://www.berrybase.de/en/new/gpio-edge-erweiterung-gpio-adapter-f-252-r-raspberry-pi?c=2413 and plug it between the Pi and the HAT. In the HAT Bricks schematic you can see with GPIOs are not used by the HAT: https://raw.githubusercontent.com/Tinkerforge/hat-brick/master/hardware/hat-schematic.pdf (the yellow rectangle to the right is the GPIO connector). To reference the numbers to the physical position of a pin, use for example this: https://i0.wp.com/maxembedded.com/wp-content/uploads/2014/07/Raspberry-Pi-GPIO-Layout-Model-B-Plus.png

Ein Weihnachtswunder: https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip Das wird voraussichtlich die letzte Beta, bzw. falls keine kritischen Bugs darin sind ist es die "fertige" Version der openHAB-2-Bindings. Die Liste von oben ist soweit abgearbeitet. Außerdem neu ist Support für die seit der letzen Beta erschienenen Bricklets: - Industrial Dual AC Relay - Industrial PTC - IMU 3.0 sowie ein deutlich einfacherer Modus für das NFC-Bricklet (der aber nur Tag-IDs liest). Für die neuen Motor-Treiber-Bricklets gibt es keinen Support, das war zeitlich nicht drin und die Verwendung wäre ähnlich unkomfortabel wie die der alten Motor-Treiber gewesen. Wichtig: In der Zip ist eine noch nicht veröffentlichte Version der Java-Bindings enthalten. Die ist notwendig um die teilweise neue API zu verwenden. Bei einem Update von einer älteren Bindingsversion bitte die 2.1.26er Jar löschen. Mit der aktuellen Version und openHAB 2.5.9 scheint es auch zu funktionieren, die Bricks und Bricklets in einer .things-Datei zu definieren. Hier ein Beispiel: Bridge tinkerforge:brickd:laptop [host="192.168.178.147"] Thing tinkerforge:brickletmultitouch:zwL "Multitouch" (tinkerforge:brickd:laptop) [uid="zwL", proximityEnabled=false]

This seems to be the problem here. If the extension is configured only as client, the status LED stops blinking if the extension is connected. The code is event driven, so when you disable and enable the status LED, what really happens is that the connection between the WiFi events and the LED state is severed or (re)connected. The issue is now, that no event from the WiFi code is generated if the extension is already connected and when you re-enable the LED the state is never changed. Interestingly, when disabling the LED, it is then shut off manually. We've added the same work-around for the enable function (first toggle the LED on, then reconnect it to the WiFi events). This is not perfect, because if the WiFi state would cause the LED to stay off and you disable and re-enable the LED it will stay on, but I think this behaviour better fits the user expectations better, as the LED should light up when you call enable... in any case. This is another issue. Do you have any more information about this? But the LED problem should indeed be unrelated.

Irgendetwas in die Richtung haben wir geplant, es gab aber noch kein Issue. Jetzt schon: https://github.com/Tinkerforge/esp32-firmware/issues/88

Stimmt, hatte ein Zaunpfahlproblem. Noch ein Grund mehr auf der Ladecontroller-Seite nachzusehen.

Das ist ein Fehler mit dem DC-Schutzmodul. Du kannst die ganzen Fehlerzustände übrigens schöner aufbereitet auf der Ladecontroller-Unterseite sehen.

Hi, How is your extension configured? The methods work for me. Does the attached script print the same messages with your extension? (Remember to change the UID ;) ) $ ruby test.rb LED true Press key to disable LED LED false Press key to enable LED LED true Press key to exit test.rb

Ah sehr gut, das Mosquitto local-only-Problem wäre was ich spontan geraten hätte. Deshalb die Frage nach Broker und Version. Ich füge das mal der FAQ hinzu. https://github.com/Tinkerforge/esp32-firmware/issues/85 Man beachte wann ich das Issue angelegt habe, vor allem in Relation zu meinem Post weiter oben ;)