Posts by Gnom

Dazu gibts doch jede Menge Videos. Das hier dürfte einige Informationen geben.

Ansonsten googel mal nach "Andreas Spiess" der hat auch einige Videos zu LoRa gemacht.

Was soll denn dein "Systemmonitor" monitoren? Die Gehäusetemperatur? Hm, dafür ist ein Pi am 100-Watt-Anschluss völlig unterdimensioniert. Du solltest in deinen PC besser einen Quad-CPU-80-Kern-Xeon-Rechner fürs Monitoring einbauen.

Scherz beiseite - einen "Klein-PC" in einen PC einzubauen, um irgendwas zu monitoren... das ist doch wahrscheinlich überdimensioniert.

Dafür genügt gewöhnlich ein Mikrocontroller - ein Arduino zum Beispiel oder wenn die Anforderungen weiter gehen, ein ESP.

UDP mag einen Ticken schneller sein - aber im Fall von Sensordaten... hm. Wäre sicher nicht besonders nützlich, wenn falsche Pakete ankommen. Bevor du einen Programmteil schreibst, der prüft, ob die übertragenen Daten überhaupt korrekt sind, nimm lieber gleich TCP. Wenn dein Netzwerk mal länger als 20 ms braucht, wird dir UDP auch nicht helfen. Außerdem dürfte der Zeitunterschied zwischen den beiden bei 6000 Bytes kaum nennenswert sein.

Die Übertragungsraten im WLAN sind gewöhnlich so hoch, dass die geringe Datenmenge hier keine große Rolle spielt. Entscheidend ist im Zweifel der Protokolloverhead. Aber generell hast du - sofern dein WLAN stabil läuft - kein Problem, die 20 ms zu halten. Die Antworteit liegt im Normalfall unter 2 ms. Bei MQTT kann ich nicht sagen, welchen Overhead das Protokoll und der Broker produzieren. Eine Socket-Verbindung dürfte aber hier ohne größere Verluste laufen.

Aber bevor du hier eine Abschließende Antwort erwartest, die du nicht bekommen wirst, probier es doch einfach aus. In der Zeit, die du hier mit Fragen verplemperst, könntest du schon Gewissheit aus eigenen Tests haben.

Erzähl eine Romane. Deine Aussage, der Pi sei für sowas zu langsam, ist falsch.

Unsinn. Der Pi hat eine maximale Latenz von gewöhnlich max 2 ms - mit einem Echtzeitpatch sogar unter 100 µs. Das Problem ist eher die Netzwerkverbindung als der Pi.

Dann sieh dir mal die Dokumentationen zum Tschernobyl-Unfall an. Ein paar Sekunden hätten vielleicht genügt, um das zu verhindern. Da wäre "Das Netzwerk ist vorübergehend nicht erreichbar" wirklich sehr unpraktisch. Und wenn du mal die Notabschaltung einer Druckmaschine (mehrere Tonnen bewegter Walzen) erlebt hast, die verhindert, dass dem Arbeiter der Arm abgerissen wird, dann denkst du anders.

Quote from Rasp-Berlin

Das kannst du bei einem PI vergessen.

So schnell ist der nicht, das er sicher alle 0.02s die Daten entgegennehmen kann.

Er soll nicht alle 0,02 Sec Daten entgegennehmen, sondern auf Anforderung soll die Antwort nach 0,02 Sec da sein.

Abgeshen davon... warum sollte er das nicht können bei 1-2 ms Antwortzeiten?

Die Frage ist eher,wie verlässlich die Antwortzeit sein muss und was passiert, wenn die Antwort doch mal länger dauert. Für die Schnellabschaltung eines Kernkraftwerks würde ich mich nicht auf 20 ms Antwortzeit über WLAN verlassen.

Wenn du WLAN benutzt und sagst, dass ein Router nicht immer erreichbar ist, wie sollst du dann 20 ms erreichen? Also, ein funktionierendes WLAN musst du schon haben, sonst kann das ja nichts werden.

Ein sauberes WLAN sollte eigentlich im Bereich von maximal 2-3 ms liegen. Aber selbst wenn ein WLAN da ist, kannst du dich nicht wirklich drauf verlassen.

Technisch gesehen ist wohl das gängige Vorgehen, eine Socketverbindung aufzubauen.

Ich würds einfach mal ausprobieren und die Antwortzeiten aufzeichnen.

Bei 2-3 Metern kannst du sonst vielleicht auch auf ESP NOW zurückgreifen oder auf 868 MHz-Funkverbindungen oder Bluetooth. Entscheidend ist, in welchem Netzwerk du die geringsten Störungen hast. WLAN und ESP NOW stören sich ggf. mit anderen WLAN-Netzen. Bluetooth benutzt den gleichen Frequenzbereich und ist deshalb auch nicht viel besser. 868 MHz hat geringe Reichweiten und ist daher nicht so extrem störanfällig. Allerdings sind die Übertragungsraten eingeschränkt, so dass es mit 20 ms bei 3 KB Daten auch schon eng wird.

Wenn alles über ein Realis läuft, geht es mit einem Shelly. Ich hatte es so verstanden, dass es zwei verschiedene Kontakte gibt für öfffnen und schließen. Jedenfalls hast du oben geschrieben, dass es zwei Kontakte sind.

Shelly 1 ist richtig. Ich hab auf die Schnelle das X1 auf der Verpackung gesehen - das ist aber nur der Hinweis auf die Einzelpackung - es gibt noch einen Dreierpack davon.

Ich benutze die Shelly-Software (Shelly Pilot). Da kann man sehr schön Buttons auf dem Display anordnen. Man könnte aber auch einen HTML-Link benutzen.

Daann ist das Einfachste ein Shelly X1 Wifi-Schalter. Denn kannst du in deinem WLAN mit einem einfachen HTML-Befehl für eine frei programmierbare Zeit einschalten und so das Tor öffnen (einen zweiten zum Schließen). Du kannst dafür entsprechende Icons mit der zugehörigen Software auf dein Handydisplay legen. Kostet 20 € und funktioniert nach meinen Erfahrungen einwandfrei.

Quote from wusa

... sollte dein Frage eigentlich beantworten.

Ich will nicht ewig Zeit verbringen mit Suchen und Schauen wie es dann funktioniert. Da weiß ich selber, dass schneller im Auto was passiert als mir lieb ist.

Du sagtest aber, du willst zwei Straßen vorher schon auf dem Handy einen Knopf drücken. Also gewöhnlich muss man das Ding dann erst mal in die Hand nehmen, aktivieren, Pincode eingeben oder Fingerabdruck scannen, die Anwendung starten oder den passenden Bildschirm wählen und da irgendwo draufdrücken, dann ggf. die Antwort abwarten, um zu sehen, ob Das Tor die Nachricht auch bekommen hat.

Mein Vorschlag mit Bluetooth war mehr so gemeint: Du baust eine Schaltung mit einem Mikrocontroller, die über eine Bluetooth-Verbindung mit dem Handy ins Internet kommt und dein Garagentor steuert. Diese Schaltung mit einem Taster und LED-Anzeige kannst du am Armaturenbrett befestigen. Ein paar Hundert Meter vor zuhause drückst du drauf und wenn das Tor zurückmeldet, dass es den Befehl erhalten hat, leuchtet die LED grün. Bluetooth muss dazu am Handy natürlich immer an sein.

Alternativ kannst du es auch völlig unabhängig vom Handy machen mit einem GSM-Modul und einem billigen Datentarif. 1NCE macht ein sehr spezielles Angebot für sehr geringe Datenmengen - das ist genau für solche Anwendungen gedacht. 10 € für 500 MB bei 10 Jahren Laufzeit. Das reicht locker. Dann brauchst du gar nicht mit dem Handy rumdaddeln.

Quote from Bracew

So ist es. Ich fahre auf mein Grundstück, stehe vor der Garage, mein Smartphone bekommt WLAN aus dem Hausnetz und schalte dann erst am Smartphone.

Ja, so ist das risikolos. Aber "schon 2 Straßen früher kurz auf dem Handy einen 'Knopf' drücken", wie es wusa formuliert hat, ist was anderes.

Dann gehörst du zu den Leuten, die während der Fahrt auf den Handy rumdaddeln? Oder willst du am Straßenrand anhalten, um dein Garagentor zu öffenn... dann würdest du nichts gewinnen...

Wenn hier jemand den Glühbirne wechseln will, kommt sofort der Hinweis, dass das nur eine zertifizierte Sicherheitsfachkraft machen darf, weil 230 V lebensgefährlich sind... aber von unterwegs im Auto das Garagentor per Handy öffnen.... da sagt keiner was.

Also, das sollte man wengstens so auslegen, dass es mit einem Knopfdruck im Auto getan ist - irgendwie über Bluetooth-Verbindung zum Handy und Weiterleitung des Steuersignals von dort übers Internet.

Wenn es groß und bunt werden und den ESP trotzdem nicht überlasten soll , dann schau mal nach Nextion. Die sind zwar nicht die blligsten, aber dafür gerade von einem µC sehr gut ansteuerbar. Die Grafik wird auf dem Display gespeichert, nur die variablen Daten wie Temperatur usw. werden seriell an das Display übertragen. Touchbedienung geht auch.

Dieser Pixtend-Controller erscheint mir völlig überteuert. Sowas brauchst du auch gar nicht, wenn du "nur" eine Pumpe, vier Ventile und drei Sensoren steuern willst.

Für die Hardware ist entscheidend, wie das ganze mit der Außenwelt bzw. dem Benutzer kommunizieren soll. Willst du einen Bildschirm, Maus und Tastatur zur Bedienung? Dann wäre ein Pi wahrscheinlich das beste. Soll alles übers Web mit einem Browser gesteuert werden? Dann bietet sich ein ESP32 an. Oder läuft das Ding weitgehend autark? Dann reicht wahrscheinlich auch ein kleiner Arduino.

Vielleicht kannst du uns etwas genauer beschreiben, was diese Steuerung machen soll. Was meinst du mit "komplexe" Pumpe? Wozu dient der Schrittmotor in dem Zusammenhang? Welche Bedienelemente sind nötig - brauchst du neben den Sensoren noch irgendwelche Knöpfchen, Eingabemöglichkeiten, Anzeigen?

Vielleicht genügt es, wenn du ìn Zeile 60 die Kommentarstriche entfernst?

Deiner Beschreibung nach sind bei dir der Widerstand R1 und der NTC genau vertauscht. Das führt dazu, dass die Berechnungen sich alle undrehen. Tausch die mal um, dann könnte es gehen.

Es geht darum, vorne Fehler zu verhindern, damit man sie nicht hinten wieder rausprüfen muss. Wenn du den ganzen Tag dämliche Teile nach Listen aus Regalen nimmst und in die Wanne wirfst, wirst du irgendwann so meschugge, dass du nur noch Fehler machst. Und der, der den Mist hinten prüft, hat das gleiche Problem.

Wenn man mit einem Scanner die Tätigkeit des Konfektionierers unterstützt, so dass er Flüchtigkeitsfehler erkennt und beheben kann und sich vielleicht sogar weniger stark konzentrieren muss, bringt das enorme Vorteile.

Ich verstehe nicht, warum hier einige Leute diesen Ansatz mit Gewalt kaputtreden wollen.

Quote from Outlaw

Statt dem weiter oben vorgeschlagenen Gewicht könnte man auch den Gesamtpreis zur Kontrolle nehmen.

Das schützt dich doch nicht davor, dass jemand ein gescanntes Teil nicht in den Korb legt...

Wobei ich es nach wir vor für völlig unangeebracht halte, hier Extremfälle zu konstruieren, die trotz Scanner noch zu Fehlern führen.

Soll ich beim Extremklettern ein Seil zur Sicherung verwenden?

Nein, das ist eine schlechte Lösung, das Seil könnte ja reißen!

Dieses Kabel ist ein "normales" Drehstrom-Kabel - also 4 Adern sind belegt mit 3 x Phase und 1 x Neutralleiter?

Könntest du dann nicht einfach einen Powerline-Adapter verwenden?

- Erstens werd ich wohl noch selbst wissen, wo bei meinen eigenen Lösungen die Mängel sind und zweitens frage ich mich, warum du dich angegriffen fühlt, wenn ich meine eigene Lösung kritisiere. Hast du meinen Text nicht gelesen? Oder nicht verstanden? Oder hast du was getrunken?

- "Mein" Code, von dem du bezweifelst, dass er "einfacher wäre", ist genau das Beispiel, das ich wegen seiner Kompliziertheit in Frage stelle. "MEINE" Lösung ist um Längen einfacher.

Du fühlst dich - aus mir nicht erfindlichen Gründen - offenbar angegriffen und haust nun wie wild um dich. Wenn du das nötig hast, nur zu. Ich finds lächerlich.

PS: Der TO hat übrigens oben geschrieben, dass meine Lösung für ihn passend ist - dem ist nichts hinzuzufügen - schon gar nicht dein Gezeter.

Quote from Rasp-Berlin

Oder ist es dir zu primitiv, zwei Zahlen miteinander zu vergleichen?

Meine Lösung aus #4 ist ein schlichter Vergleich von Zahlen. Und das hat nichts mit primitiv, sondern mit zweckmäßig zu tun.

Primitiv ist höchstens dein gesamter Beitrag.