photron

Don't worry, the problem is just that MSVC2010 is quite old and has some quirks that you run into now. The C/C++ bindings don't handles those correctly right now. Please add these 3 lines in ip_connection.c at line 55: #if defined _MSC_VER && _MSC_VER < 1900 #define snprintf _snprintf #endif

The PyQt5_sip dependency problem might be related to this line in requirements.txt PyQt5 == 5.11.3 Try changing that to PyQt5 == 5.15.6 or just to PyQt5

No, the problem is with PyQt5_sip, but the version numbers confuse me.

Sorry, I didn't think this through. You're compiling the code as C++. The problem is including stdbool.h there. It should not be included at all for C++ because its a C header. Please remove the stdbool.h file again and change line 24 in ip_connection.h from this #if (!defined __cplusplus && defined __GNUC__) || (defined _MSC_VER && _MSC_VER >= 1600) to this #if !defined __cplusplus && (defined __GNUC__ || (defined _MSC_VER && _MSC_VER >= 1600)) then try again.

VS2010 doesn't support modern C/C++ standards. It just lacks stdbool.h support. Please add the attached stdbool.h file to the same directory that contains ip_connection.h. stdbool.h

Are you using the pre-build .dmg we provide for download? Or are you running brickv from source? If you're using the pre-build .dmg this might be some kind of packaging bug. If you're running from source, then I'm confused. Does it say "OpenGL library not found. Disabling 3D view." in the bottom on the brickv window? You can see from the code here, that this message is triggered by the ctypes.util.find_library('OpenGL') call returning None: https://github.com/Tinkerforge/brickv/blob/2e4a03ec4d5429144febe7d4a4eb2ed3e0503dd8/src/brickv/render_widget.py#L42 https://github.com/Tinkerforge/brickv/blob/2e4a03ec4d5429144febe7d4a4eb2ed3e0503dd8/src/brickv/render_widget.py#L100 So I don't really understand why that call works if you try it by hand, but doesn't seem to work in brickv. If you're currently using the pre-build .dmg, could you try running from source to see if this makes a difference?

Ich kann das hier auch nachstellen. Da haben wir einen Bug eingebaut. Sorry! Wir gehen dem nach. Danke fürs melden.

Auf welchem Commit in esp32-firmware Repository arbeitest du denn? Das ist interessant. Wir gehen dem gleich mal nach. Nicht das wir im Zuge des Umbaus da einen Bug eingefangen haben.

Ich kann In JavaScript (Node.js und Browser) folgendes hinschreiben: rs232.write('\xAA\x00\x00\x20\x00\x01\x00\x04\x25'.split('')) und das sendet die Daten wie erwartet.

I don't have macOS 12 at hand for testing. It works on macOS 10.15.7. We're using just Qt with directly loading the low level operating system OpenGL library. This is due to problems with the wrapping of the QtOpenGL module in PyQt at the time of developing this code. You can find the relevant code here: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/render_widget.py Try running this two lines in Python on you Mac: import ctypes.util ctypes.util.find_library('OpenGL') I assume that the find_library call returns None for you, meaning it cannot find the system's OpenGL library. It's unclear to me why. In the long run we might just switch from OpenGL to Qt3D for this.

Wenn du in Brick Viewer oder den Python Bindings einfach "AA 80 00 00 80" hinschreibst, dann wird dadurch ein A, ein A, ein Leerzeichen, eine Null, eine Null und so weiter gesendet. Für das RS485 Bricklet hat Brick Viewer eine Hex Modus für das Senden. Das hat Brick Viewer allerdings nicht für das RS232 Bricklet 2.0. Ich nehme das mal auf die TODO Liste mit auf das nachzubessern. Aktuell kannst du daher über Brick Viewer keine Binärdaten über das RS232 Bricklet 2.0 senden. In deine Python Programm musst du aber einfach nur die Daten passend hinschreiben. Anstelle von "AA 80 00 00 80" kannst du "\xAA\x80\x00\x00\x80" hinschreiben in Python und dann tut das was du möchtest.

Ich habe die Idee mal hier aufgenommen: https://github.com/Tinkerforge/esp32-firmware/issues/76 Interessant wäre dazu mal deinen Anwendungsfall zu hören, damit wir die Umsetzung besser planen können.

Wir haben auf dem HAT Brick vor kurzem den RTC Chip gewechselt, weil der alte nicht mehr zu bekommen war. Aktualisiere bitte die Firmware des HAT Bricks auf die neueste Version 2.0.3. Dann brauchst du Brick Viewer 2.4.20. Dann kannst du auf dem HAT Brick Tab den RTC Driver von PCF8523 auf DS1338 umstellen. Danach am Besten den ganzen Aufbau einmal vom Strom trennen. Danach sollte die RTC dann funktionieren.

Sorry, das ist beides leider technisch nicht möglich. Die aktuelle Elektronik der Wallbox unterstütz das Verriegeln einer Typ2 Dose nicht. Als NFC Leser setzen wir in der Wallbox unser NFC Bricklet ein. Es ist nicht vorgesehen einen externen NFC Leser anzubinden

Nein, da war ein Fehler im Programm für den Fall das es von der Kommandozeile gestartet wurde. Den habe ich behoben.

Stimmt, beim Outdoor Weather Bricklet gibt es nur das Callback Beispiel. Normalerweise gibt es auch immer ein Simple Beispiel das mit einem Getter Aufruf arbeitet. Zum Beispiel, das hier für das Ambient Light Bricklet 3.0: https://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLightV3_Bricklet_PHP.html#simple So ein Beispiel fehlt für das Outdoor Weather Bricklet. Ich nehme das mal auf die TODO Liste auf.

Wenn du deinen RED Brick schon neu aufsetzt, warum nimmst du dann nicht die aktuelle Image Version 1.15? Dann solltest du auch deinen Brick Viewer aktualisieren auf 2.4.20. Das wird wahrscheinlich das Problem nicht beheben, aber so suchen wir dann wenigstens nicht nach alten, bereits behobenen Problemen. Die Fehlermeldung ist über einen internen Fehler auf dem RED Brick bei der Abfrage der Modeminformationen. Die kannst nicht verstehen, die ist für uns und nicht für dich gedacht. Das Modem das du einsetzt hat aber schon mal an einem RED Brick funktioniert, oder?

Teste mal bitte die angehängte Version. tabletop_weather_station_demo-1.1.2+snapshot~5ec7525_all.deb

Standardmäßig wird die Stdout-Ausgabe des Programms aufgezeichnet, außer du hast das absichtlich ausgestellt. Die Logdatei findest du im Brick Viewer im Log-Abschnitt des Programms unter Continuos als stdout.log. Was steht da drin? Du musst nur die UIDs der Bricklets anpassen die in deinem Programm auch wirklich verwendet werden.

Die PHP Beispiele sind nicht als CGI-Programme gedacht, sondern als Kommandozeilen-Programme. Im CGI Modus darf ein PHP Programm maximal 30 Sekunden laufen, ansonsten wird es abgebrochen. Alle Callback Beispiele laufen aber bis du sie per Tastendruck abbrichst. Daher ist es nicht verwunderlich, wenn du Probleme mit einem Callback Beispiel im CGI Modus hast. Für den CGI Modus sind Callbacks ungeeignet, weil du nicht auf einen Callback warten kannst/willst. Dort solltest du Getter verwenden. Also solltest du dir die Simple Beispiele ansehen. Dort musst du dann diese Zeile entfernen, die das Beispiel davon abhält sich zu beenden bevor du das mit einem Tastendruck gestattest. fgetc(fopen('php://stdin', 'r'));

Das erklärt einiges... Am besten machst du deine Schleife in deinem Code der IPConnection.connect() aufruft anstatt IPConnection.php zu verändern. Aber eigentlich sollte das gar nicht nötig sein. Bei einem "Connection timed out" Fehler würde ich erwarten, dass die IP Adresse die du angegeben hast überhaupt nicht erreichbar ist, z.B. weil sie falsch ist oder ein Routing-Problem vorliegt, so dass diese von deiner Disk Station aus gar nicht erreichbar ist. Kannst du von der Disk Station aus 192.168.178.39 per ping erreichen? Oder ist auf der Disk Station vielleicht eine Firewall eingerichtet die ausgehenden Netzwerkverkehr blockiert? Oder ist das PHP auf der Disk Station beschränkt und darf keine Netzwerkverbindung aufbauen?

Welche Version der PHP Bindings verwendest du? Die Zeilennummern passen nicht zur aktuellen Version 2.1.29. Teste mal bitte mit 2.1.29. Ich kann auf die Schnelle kein PHP 5.3 auftreiben. Ich habe das Problem versucht in einem Docker Container mit PHP 5.5.38 nachzustellen, aber es funktioniert hier. Dein eigentliches Problem ist, dass die WIFI Extension nicht unter 192.168.178.39 erreichbar zu sein scheint. Kannst du den Stapel unter 192.168.178.39 mit Brick Viewer erreichen? Den zweiten Fehler den du dann siehst kann ich nicht nachvollziehen. Es scheint keine Verbindung zu bestehen dennoch versuchen die Bindings eine Nachricht auf einen geschlossenen Socket zu senden. Eigentlich sollte Tinkerforge\Device->sendRequest in diesem Fall Tinkerforge\IPConnection->send gar nicht aufrufen.

Du hast die SD Karte vom alten in den neuen RED Brick getauscht? Dann sollte das weiter funktionieren. Hast du vielleicht den Stapel nicht ordentlich auf den neuen RED Brick gesteckt? Kannst du mal die Logs der Programme selbst zeigen. Der Ausschnitt des Brick Daemon Logs beinhaltet keine Probleme und nicht interessantes.

Okay, I see your problem now. You have to use SetMonoflop(true, 5000) OR SetState(false). But you're using both in sequence. This doesn't do the correct thing. You need to use a case structure in your while loop. In the true case it contains SetMonoflop(true, 5000) in the false case it contains SetState(false). I created a new LabVIEW example to demonstrate this: https://www.tinkerforge.com/en/doc/Software/Bricklets/SolidStateRelayV2_Bricklet_LabVIEW.html#monoflop

Your problem is that you use SetMonoflop now for turning the heater on AND off. You need to call SetMonoflop(true, 5000) repeatedly to turn the header on and keep it on You need to call SetState(false) once to turn the heater off.