photron

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. brickv_macos_2_4_20_snapshot_445ae07.dmg

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.

Tritt das Problem auch auf, wenn du den EPN510 vom Dual Relay Bricklet trennst? Oder muss der EPN510 wirklich geschaltet werden, damit das Problem auftritt? Was schaltet der EPN510 auf seiner Lastseite? Wie sieht deine Kabelführung aus? Hast du 230V Leitungen parallel zu Bricklet Kabeln liegen, so dass Störungen auf den 230V Leitungen sich auf die Bricklet Kabel übertragen können. Das könnte ein EMV Problem sein, dass also das schalten der Last eine Störung erzeugt die verlässlich den Stapel abschießt. Alternativ verursacht das Schalten der Last einen Spannungseinbruch der soweit durchschlägt, dass die Versorgung des Stapel kurzzeitig wegbricht, auch wenn du da ein 24V Netzteil dazwischen hast.

Klingt alles so als sollte das funktionieren können.

Ich nehme mal an du verwendet das Gefälle im Seil zum Herabrollen lassen des Wagens durch Schwerkraft. Sprich in dem Fall muss der Motor den Wagen bremsen durch langsames abwickeln der Schnur. Beim Heraufrollen zieht der Motor dann den Wagen über das Gefälle hinweg hoch. Da das Gefälle ja sehr gering ist trägt das Seil den Großteil des Gewichts des Wagens und der Zug auf der Schnur sollte gering sein. Da ist es fast egal was du an Motor nimmst, würde ich schätzen, so lange dieser nicht grundsätzlich zu schwach ist und mit ausreichend Kraft langsam genug laufen kann. DC Getriebemotor ist sicher keine falsche Wahl. Interessant sind da vielleicht auch andere Fragen. Muss der Motor immer unter Strom stehen, um den Wagen in der seiner Position zu halten? Oder hast du bei einem DC Getriebemotor genug Reibung im Getriebe, so das das Gewicht des Wagens die Schnur nicht abwickeln kann auch wenn der Motor stromlos ist? Oder ist das ein Schneckengetriebe? Wie ist es mit der Geräuschentwicklung? Ist das Surren eines DC Getriebemotor ein Problem? Aus welchem Material ist der Geist? Kann sich das mit Wasser vollsaugen im Regen? Wie schwer ist das ganze dann?

Das sollte nicht passieren. Mit den Zahlen/Versionen kann ich nichts anfangen. Die aktuelle WARP1 Firmware ist Version 1.2.4.

Also ist das eine Wechselwirkung zwischen Cumulocity Agent und Brick Daemon? Wenn du also den Cumulocity Agent deinstallierst anstelle von Brick Daemon dann läuft es auch it HAT Brick? Nein, dazu kannst du aber irgendeine Modbus TCP Bibliothek verwenden z.B. PyModbus. Für Modbus TCP brauchst du keine extra Hardware, da das einfach über die normale Netzwerkschnittstelle geht.