photron

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.

I assume you use SetMonoflop(false, 5000) to turn off the heater. This will turn of the heater for 5 seconds then turn it back on again. This is bad. You need to use SetState(false) to turn off the heater and keep it off.

Da kommt gerade etwas Bewegung in die Sache: https://github.com/Tinkerforge/generators/pull/58

I assume you're using a control to represent the UID, just the same as our examples do. A control will not keep changes that you make to its value by default. You have to tell the control to use the current value as its default value. To do this change the control to the UID you want, then open the context menu of that control and select "Data Operations" followed by "Make Current Value Default". Now save the file. The next time you open it the control will contain the changed UID. You can also replace the control with a constant to archive the same result. The difference is that the constant will not show up on the front panel.

I assume you use the SetState function of the Solid State Relay Bricklet 2.0. I assume you call SetState(true) once to turn the heater on and SetState(false) once to turn it off. To avoid that the heater stays on if your LabVIEW program stops working you can use the SetMonoflop function instead. If you call SetMonoflop(true, 5000) then the Solid State Relay Bricklet 2.0 will switch on for 5000 milliseconds and then switch itself off again. So instead of calling SetState(true) once to turn the heater on you call SetMonoflop(true, 5000) every second instead. This results in constantly extending the time the relay stays on, essentially keeping it on constantly as long as you keep calling SetMonoflop(true, 5000) again before the 5000 milliseconds expire. To turn off the relay you just call SetState(false) once. This turns the relay off and aborts any pending monoflop. This way the relay will turn itself off 5000 milliseconds after your LabVIEW program stopped working, bringing you system to a safe state.

Das kommt höchstwahrscheinlich daher, dass wir in Brick Viewer 2.4.19 geändert haben wie die Liste der seriellen Schnittstellen erstellt wird. Seit dieser Version nutzen wir da eine Hilfsfunktion von PySerial zu. Da scheint es aber einen Bug zu geben, der Apple M1 Macs betrift, der aber in PySerial 3.5 behoben sein soll. Wir liefern Brick Viewer aber mit PySerial 3.4 aus. Teste bitte die angehängte Version, die jetzt mit PySerial 3.5 kommt. Admin-Edit: Veraltete brickv-Version entfernt

Brick Logger 2.1.8 Reuse thread in timer to avoid slow memory leak Fix device list clearing on config loading Fix slow memory leak in data tab Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.20 Hide unused custom line ending controls in hex mode in RS485 Bricklet plugin Reuse thread in Data Logger timer to avoid slow memory leak Fix Data Logger device list clearing on config loading Fix slow memory leak in Data Logger data tab Add firmware version column to Health Monitor dialog Improve udev rule compatibility on Linux Add support for RTC driver config to HAT Brick plugin Add support for simple mode to NFC Bricklet plugin Increase required PySerial version to 3.0 Add support for flashing ESP32 (Ethernet) Bricks Downloads: Windows, Linux, macOS

Brick Logger 2.1.8 Thread im Timer wird wiederverwendet um langsames Speicherleck zu vermeiden Löschen der Geräteliste beim Laden einer Config repariert Langsames Speicherleck im Data-Tab repariert Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.20 Unnötige Zeilenendeneinstellungen werden im Hex-Modus des RS485 Bricklet Plugins ausgeblendet Thread im Data-Logger-Timer wird wiederverwendet um langsames Speicherleck zu vermeiden Löschen der Data-Logger-Geräteliste beim Laden einer Config repariert Langsames Speicherleck im Data-Logger-Data-Tab repariert Firmware-Versions-Spalte zum Health Monitor hinzugefügt udev-Regel-Kompatibilität unter Linux verbessert Unterstützung für RTC-Treiber-Einstellung zum HAT-Brick-Plugin hinzugefügt Unterstützung für Simple-Mode zum NFC-Bricklet-Plugin hinzugefügt Benötige PySerial Version auf 3.0 erhöht Unterstützung für das Flashen von ESP32 (Ethernet) Bricks hinzugefügt Downloads: Windows, Linux, macOS

Du setzt mit dem Monoflop das Value auf true, oder? Wenn das hängenbleibt dann, musst du es schaffen den Master Brick so abzuschießen, das der Pin der das Relais schaltet im true Zustand hängen bleibt und dadurch das Relais geschaltet bleibt. Das passt aber nicht dazu, dass du sagst der Stapel startet neu. Denn dann sollte das Relais wieder in den Standardzustand false zurückgehen. Da kann ich dir jetzt leider auch nicht viel mehr zu raten als die Störung durch die 230V Seite zu beseitigen, sorry.