Gladys 4 - Entwicklung des Arduino-Dienstes

[billona]

Hallo zusammen

Um Gladys 4 mit meiner Installation (hauptsächlich bestehend aus 433 MHz) kompatibel zu machen, bin ich gerade dabei, den Arduino-Dienst zu entwickeln.

Seite der Integrationen:

Seiten des Arduino-Dienstes:

Bisher ist die Oberfläche einfach und noch nicht fertig, aber ich arbeite daran. Ich muss mich auch um die Erkennung von Karten mithilfe des bereits vorhandenen USB-Dienstes kümmern.

Wenn ihr den Fortschritt des Codes sehen wollt, ist er auf meinem Repo verfügbar.

Ich wende mich also an euch, um eure Meinungen zu dem, was bereits erledigt ist, eure Ratschläge, die ihr mir geben könntet, oder jede andere Diskussion zu diesem Thema zu hören

[peb]

Hallo!

Das sind großartige Neuigkeiten zum Jahresbeginn!
Zuerst empfehle ich dir, einen PR auf dem GitHub von Gladys zu erstellen, damit alle Bescheid wissen, dass die Entwicklung des Arduino-Dienstes im Gange ist!

Die Frage ist: Wofür sollte dieser Arduino-Dienst geeignet sein? Für mich ist es ein Verbindungsglied zwischen Hardware (den Arduinos) und höherwertigen Diensten (433 MHz…)
Das würde es ermöglichen, auf einem bestimmten Arduino einen bestimmten Dienst laufen zu lassen. (man muss sehen, ob es möglich ist, n Dienste auf einem Arduino oder nur 1 zu haben).

Was denkst du?

Auf jeden Fall kannst du mich zu den Testern der Arduino-/433-MHz-Dienste zählen

[billona]

Vielen Dank für deine Antwort

@peb

Zuerst empfehle ich dir, einen PR auf dem GitHub von Gladys zu erstellen

Der PR ist erstellt, wir können vorwärts machen

@peb

Für mich ist es ein Connector zwischen Hardware (den Arduinos) und höheren Diensten (433 MHz…)

Ich bin deiner Meinung, meine Idee ist, pro Arduino ein Gerät zu haben, und für jedes Gerät „Untergeräte“, die die auf der Karte vorhandenen Dienste darstellen.

@peb

Man muss sehen, ob es möglich ist, n Dienste auf einem Arduino zu haben oder nur 1

Für mich ja, was ich mit Gladys 3 gemacht habe, war, dass ich verschiedene Sender/Empfänger an meinen Arduino angeschlossen hatte, und Gladys ein JSON an die Karte zurückgeschickt hat, mit dem Namen der auf der Karte aufzurufenden Funktion und anderen Parametern, je nach Anforderung.

Hier ist meine Karte mit Gladys 3. Wie du siehst, habe ich 2 IR-Leitungen (für ein LED-Band und für ein TV), einen Sender und einen Empfänger 433 MHz.

Also für mich ist es durchaus möglich, mehrere Dienste auf einer einzigen Karte zu haben, bleibt nur zu sehen, was am optimalsten ist

Was hältst du von dieser Lösung?

@peb

In jedem Fall kannst du auf mich als Tester für die Arduino-/433-MHz-Dienste zählen

Vielen Dank, das freut mich

[Tlse-vins]

Für mich auch,
Ich verwende einen Arduino mit einem 433-MHz-Sender für meinen TV-Lifter.

[peb]

@billona

Für mich ja, was ich mit Gladys 3 gemacht habe, war, dass ich verschiedene Sender/Empfänger mit meinem Arduino verbunden hatte, und Gladys ein JSON an die Karte zurückgeschickt hat, mit dem Namen der Funktion, die auf der Karte aufgerufen werden sollte, und anderen Parametern, je nachdem, was verlangt wurde.

Gute Idee mit den JSON-Nachrichten! Dann müsste man den Austausch der Nachrichten standardisieren und das Abstraktionsniveau des Arduino definieren.

Man könnte eine Art Nachricht haben:

{
  "service": "arduino-433-mhz",
  "message": {
    "value": "xxxx",
    "bbbb": "yyyy"
  }
}

Einige Fragen, die mir zur Erstellung des Dienstes einfallen:

Für die Konfiguration und Nutzung sollte Gladys 4 so plug and play wie möglich sein. Über die Web-Oberfläche kann man die angeschlossenen Arduinos identifizieren, und dann, wie geht es auf der Code-Seite weiter?

Enthält der Arduino bereits den Code, und in diesem Fall identifiziert Gladys über einen Nachrichtenaustausch, welche Dienste für diesen Arduino verwendet werden?

Muss man die Dienste manuell angeben? Sollte Gladys in der Lage sein, den Code in den Arduino hochzuladen? Wie soll man die Module codieren, damit sie so einfach wie möglich in einem einzigen Arduino kumulierbar sind?

Idealerweise hätte jedes Submodul eine Konfigurationsphase und eine Standardbetriebsphase.
In der Konfigurationsphase könnte man die benötigten Pins angeben (der In- und der Out-Pin für das 433 MHz), damit sich keine Module die Pins teilen.

So, so ein paar Ideen und Fragen im Vorbeigehen

[pierre-gilles]

Genial @billona danke für deine Nachricht und deine Entwicklung, das wird vielen Leuten Freude bereiten

Für den Teil mit dem Serialport/USB-Anschluss kannst du auf die Arbeit aufbauen, die bereits mit dem „usb“-Service von Gladys 4 gemacht wurde. Alle Verbindungen laufen über diesen Service, und die Routen zum Auflisten der USB-Ports existieren bereits.

Das Ziel ist es, einen Service zu haben, der so einfach wie möglich zu verwenden ist. Der Benutzer steckt seinen Arduino ein, sieht ihn in Gladys, und hoppla, mit einem Klick fügt der Benutzer ihn zu Gladys hinzu und es funktioniert.

Richtig, es wird notwendig sein, das Nachrichtenformat zu standardisieren, das von Gladys zum Arduino und umgekehrt gesendet wird. Für mich könnte dieses Nachrichtenformat sogar dasselbe sein wie das des MQTT-API-Formats.

Im Grunde ist ein Arduino wie ein Remote-Service. Ich sprach über die Architektur „Gladys Core/Gladys Pod“ im Manifest von Gladys 4, ein Arduino kann als Pod betrachtet werden, der Informationen hochlädt und Informationen an Gladys zurückgibt.

Siehe => Private, self-hosted smart home with AI | Gladys Assistant

[Spouet]

Hey Hey!
Super Neuigkeit!
Ich werde meine Mission diese Woche abschließen und dachte mir, dass dies vielleicht die Gelegenheit wäre, mich diesem Service zu widmen. Aber ich bin froh, dass du dich darum kümmerst, da ich nur C beherrscht.
Von meiner Seite aus ist dieser Service der Hauptbestandteil meiner Gladys-Installation. Arduino+433, ohne ihn habe ich keine Aktoren.
Und auf meinem Arduino habe ich:
Sende-/Empfänger 433MHz
Ein Temperatur-/Feuchtigkeitssensor DHT 22
Ein Luftqualitätssensor
ein HC-11-Modul, dessen Gegenstück ich an meinem Roomba angeschlossen habe

Ich verwalte also alle meine 433-Steckdosen, aber vor allem sende ich „dank“ JSON alle meine Informationen von meinen verschiedenen Temperatur-/Feuchtigkeitssensoren, Roomba-Infos usw.
Kurz gesagt, wie ich es sage, ist meine Installation ohne diesen Service nutzlos Deshalb habe ich Gladys 4 noch nicht getestet.

Kurz gesagt (ja, ja, noch einmal ) falls du Hilfe brauchst, könnte ich vielleicht helfen.

[JPL]

Ausgezeichnet: Ich finde, dieser Anfang ist vielversprechend. Ich warte auch auf die Entwicklung der 433-MHz-Technologie. Verstehe ich das richtig, dass die Erkennung des Arduinos (in meinem Fall ein Nano) automatisiert wird? Ich sollte also meine Box mit Sender-Empfänger anschließen und sie wird erkannt? Dann kann ich anschließend die Codes für die Geräte angeben, die ich erstellen möchte? (z. B. Beleuchtung im Wohnzimmer) Vielleicht sage ich Unsinn, da ich in diesem Bereich noch Anfänger bin, aber das wäre ein tolles Feature.
Glaubst du, du kannst bald einen Test zur Validierung herausbringen? (Aber nein, ich bin nicht ungeduldig…)
Danke und bis bald also

[Spouet]

Hallo,
@billona hast du Zeit gehabt, dich mit dem Thema zu beschäftigen?
Pouet!

[pierre-gilles]

@CamilleB Das ist das Ziel, eine einheitliche Arduino-API auf die gleiche Weise wie MQTT zu entwickeln.

Man muss Spezifikationen schreiben, bevor man mit der Entwicklung beginnt.

Man sollte prüfen, ob es nicht bereits Standards für die serielle Kommunikation gibt?

Es wird ein Dienst wie jeder andere sein, der bei Bedarf jedes Benutzers aktiviert wird

@CamilleB

Ich bin also super motiviert, euch zu helfen, wenn euch meine Ideen gefallen, um Tutorials zu Arduino zu erstellen und die Schnittstellen mit Gladys zu testen.

Top Zögere nicht, Tutorials zu dem zu erstellen, was du bereits in Gladys integriert hast (MQTT, Kamera), der Arduino-USB-Dienst scheint noch nicht begonnen worden zu sein…

[camille]

Hallo, ich übernehme meinen offiziellen Account @camille wieder. Der Account @CamilleB wird jetzt schlafen gehen

@pierre-gilles Man muss Spezifikationen schreiben, bevor man mit der Entwicklung beginnt.

Ich weiß nicht, worum es geht, aber wenn du Beispiele und den erwarteten Formalismus hast, kann ich versuchen, diesen Punkt voranzubringen.

@pierre-gilles Man sollte prüfen, ob es nicht bereits Standards für die serielle Kommunikation gibt?

Hier ist, was ich über serielle Kommunikation kenne …, wenn andere Personen korrigieren oder ergänzen möchten, freue ich mich auf euer Feedback …

Zu den am häufigsten verwendeten „seriellen“ Kommunikationstechniken, die sowohl von Arduino als auch in der Industrie verwendet werden, gehört das berühmte RS232-Protokoll (1960er Jahre), das in der Elektronik ein einfaches und weit verbreitetes Protokoll ist und es immer noch ist, I²C (1980er Jahre) und sein kleiner Bruder 1-Wire werden ebenfalls in der Elektronik häufig verwendet, um Peripheriegeräte (Speicher, A/D-Wandler, D/A-Wandler, Bus-Expander …) anzusprechen, SPI (1980er Jahre), das wie I²C in der Elektronik für den Datenaustausch mit Peripheriegeräten verwendet wird, LIN und CAN für die Automobil- und Industriebranche (nicht sehr gut für unsere Bedürfnisse geeignet, meiner Meinung nach) und USB (1990er Jahre), das sich vorstellen kann und jetzt ein Computerstandard ist.

Einige Beispiele:

• Die Temperatur-/Feuchtigkeitssensoren DHT11 und DHT22, die 433-MHz-Module verwenden 1-Wire
• Das RFID-Modul RC522, das W5100-Ethernet-Shield und sein SD-Kartenleser verwenden SPI
• Das Gyroskop und der Beschleunigungssensor GY-521, die Echtzeituhr DS3231, der Barometer MPL3115A2 verwenden I²C
• Die Kommunikation/ Programmierung mit den Arduinos erfolgt über die RS232-Verbindung mittels eines USB-UART

Es ist diese letzte Verbindung, die für die Kommunikation zwischen Gladys und dem Arduino verwendet wird, wenn er per USB angeschlossen ist.
Die anderen Protokolle werden von den Sensoren/Peripheriegeräten verwendet, die vom Arduino verwaltet werden.

Als serieller Standard kenne ich nur den der Industrie, Modbus und seine kleinen Brüder Profibus, Jbus.
Das Prinzip ist einfach, ein Master (Gladys) fragt oder steuert Slaves (Arduinos) ab.
Die Nachrichten bestehen aus dem Frame für den Master: [Slave-Adresse], [Funktionscode], [Daten], [CRC] und für den Slave, falls erforderlich, aus dem Antwort-Frame: [Slave-Adresse], [Funktionscode], [Daten], [CRC].

Der Funktionscode und das CRC entsprechen einer Norm.

Es gibt Bibliotheken, die Modbus für Arduinos verwalten.

Dennoch muss ein Modbus-Master von Gladys programmiert werden, ich weiß nicht, ob das einfach zu machen ist und vor allem wünschenswert ???

Meine Meinung:

1. Das scheint mir viel Arbeit für etwas zu sein, das am Ende für einen Endbenutzer kompliziert zu verwenden sein könnte.
   Trotzdem bin ich bereit, über das Thema zu diskutieren und zu sehen, ob jemand andere Vorschläge für bestehende serielle Standards hat oder ob ihr denkt, dass Modbus eine gute Idee wäre.

2. Ich bleibe bei der Einfachheit der Topics, die von MQTT verwendet werden. Wenn wir die gleichen Ideen wiederverwenden, müssten wir nur die Topics mit den Daten senden/empfangen.

Auf Gladys-Seite gibt es bereits etwas und dasselbe gilt für Arduino.

Der „setup“-Tab könnte so aussehen mit einer automatischen Erkennung der angeschlossenen Arduinos

Was den „device“-Tab betrifft, müsste nicht viel geändert werden (die gleiche Struktur wie bei MQTT beibehalten)

Gleiches gilt, sagt mir, ob ich spinne oder ob es eine gute Idee ist.

3. Letzter Punkt, ich habe für einen meiner früheren Jobs ein Projekt entwickelt, bei dem es notwendig war, mehrere Slave-Module mit relativ geringen Datenströmen zu kommunizieren. Ich hatte RS232 verwendet und einfach die Philosophie von Modbus, aber viel einfacher. Das heißt, ich habe Frames mit einer Kennung für jeden Slave, Befehle und Abfragen gesendet und dann hat jeder Slave mir geantwortet.
   Es gab kein CRC, weil es nicht notwendig war, und es war sehr einfach (der Beweis, ich konnte es tun )
   Daher könnte eine andere Lösung die Entwicklung unseres eigenen Standards sein, was denkt ihr?

@pierre-gilles Top Zögere nicht, Tutorials über das zu erstellen, was du bereits in Gladys integriert hast (MQTT, Kamera)

Ich schaue, was bereits existiert, und mache mich an die Arbeit …

[pierre-gilles]

@camille Oula, du bist ja weit weg in der Analyse

Als ich von API-Spezifikationen sprach, ist das Einzige, was definiert werden muss, das Format der Nachrichten. Die serielle Kommunikation ist bereits geregelt, es handelt sich um USB, das funktioniert von alleine.

Beispiel in Gladys 3: Sobald ein neuer Sensorwert empfangen wird

Wenn du einen Temperatursensor mit der ID = 1 hattest (die IDs waren Ganzzahlen in Gladys 3), und die Temperatur 20°C beträgt, dann würde der Arduino den folgenden Wert per USB senden:

{ 
  "devicetype": 1,
  "value": 20
} 

Einfach so

Die Wahl von JSON ist fragwürdig. Man könnte ein anderes Format übernehmen, wenn es einfachere und weniger aufwendige Standards für einen Arduino gibt.

@Terdious, du bist doch Arduino-Experte, ist die ArduinoJson-Bibliothek schwer zu verwenden? Gibt es Alternativen oder Standards? (Allerdings sieht es laut dem GitHub von ArduinoJson so aus, als wäre es solide und leicht!)

Wenn wir bei JSON bleiben, könnte man in Gladys 4 ein Format wie folgt vorstellen:

{
   "message_type": "device.new-state",
   "device_feature": "temperature-salon",
   "value": 20
} 

Genau das muss definiert werden für jeden Anwendungsfall das Nachrichtenformat!

[billona]

Hallo,

Aufgrund der vielen Arbeit in den letzten Wochen hatte ich keine Zeit, mich um die Entwicklung des Dienstes zu kümmern. Jetzt, da ich im Homeoffice bin, kann ich mich wieder dem Code widmen.

Wie besprochen mit @peb, sollten wir die verschiedenen Nachrichtenformate auflisten (433 MHz, IR, Display…). Die Idee wäre, die Schnittstelle entsprechend der Hardware des Nutzers zu generieren.

Zum Beispiel: Wenn der Nutzer einen 433-MHz-Sender möchte, erscheint ein Feld, in dem er die Nummer des DATA-Pins eingeben kann. Dadurch könnte das System möglicherweise einen an den Nutzer und seine Konfiguration angepassten Arduino-Code generieren.

Und anschließend müssten die Geräte auf herkömmliche Weise konfiguriert werden. Was haltet ihr davon?

Übrigens könnte eine weitere Idee für eine Funktion sein, Arduino per WLAN (ESP8266?) zu nutzen, um Geräte remote zu steuern.

[camille]

Hallo,

Super, wenn du das Thema wieder voranbringen kannst. Wenn du einen Tester brauchst, lass es mich wissen.

Zu deinem Beispiel,

@billona Zum Beispiel: Wenn der Benutzer einen 433-MHz-Sender benötigt, erscheint ein Feld, in dem er die Nummer des DATA-Pins eingeben kann. Dadurch könnte das System möglicherweise in der Lage sein, einen an den Benutzer und dessen Konfiguration angepassten Arduino-Code zu generieren.

Ich finde es interessant, dass generischer Arduino-Code erzeugt werden kann (das geht in die Richtung, dass möglichst viele Personen GLADYS und deren Peripheriegeräte ohne spezifische Kenntnisse nutzen können). Allerdings sehe ich hier eine Grenze oder vielmehr eine Komplexität darin, dies auf eine große Anzahl verschiedener Peripheriegeräte und auch auf die verschiedenen Arduino-Modelle anzuwenden.

Ich finde die Idee dennoch sehr interessant. Wenn man zum Beispiel den Arduino UNO nimmt, müsste man in diesem Fall versuchen, einen Standard für die Zuordnung von Pins zu erstellen, bei dem bestimmte Pins bestimmten Funktionen vorbehalten sind und die anderen nach Bedarf verfügbar sind.

Zum Beispiel: Die Pins D10, D11, D12 und D13 wären nur für SPI reserviert, A4 und A5 für I²C, D1 und D2 für USB.

Was denkst du? Spiegelt das deine Idee wider?

[VonOx]

@billona ich denke, die Verwaltung der ESPs ist mit dem MQTT-Dienst interessant.

@camille ich weiß nicht, ob du PlatformIO für VSCode kennst. Es ermöglicht dir, generischen Code zu schreiben, unabhängig vom Typ der Karte. Es verwaltet die Zuordnung in Abhängigkeit von der Karte, die du anschließt.

[camille]

Hallo @VonOx, danke für die Infos, ich kannte Platformio nicht, das sieht aus wie ein sehr nettes IDE, das Debugging fehlte mir tatsächlich in der Arduino IDE, die Hilfe zu den Funktionen und die kontinuierliche Kompilierung ist sehr hilfreich. Kurz gesagt, ein echter IDE.
Auch wenn die Arduino IDE gerade dabei ist, ein Arduino-Debugging zu entwickeln, das derzeit in der Prototypenphase ist …

Aber zurück zum Mapping und zum generischen Code, ich sehe nicht ganz, wo das im Platformio IDE zu finden ist (ich habe es nur installiert und ein bisschen damit herumgespielt, aber ich werde weitermachen, falls du Infos dazu hast, würde mir das Zeit sparen).
Aber das Problem bleibt meiner Meinung nach für Gladys bestehen, denn wenn man dem Benutzer die Möglichkeit gibt, Pins für seine Peripheriegeräte auszuwählen, ohne ihn einzuschränken, könnte es Nebenwirkungen geben.
Was denkst du?

[billona]

Hallo,

Nach einer unruhigen Nacht voller Gedanken (und Kaffee ) konnte ich beim Entwickeln vorankommen. Ich schreibe diese kleine Nachricht, um alle Punkte zu beschreiben, die mir in den Sinn gekommen sind. Ich würde gerne eure Meinung zum Fortschritt dieses Dienstes hören.

1. Wie sieht das Frontend aus?

Ich habe mir zwei Seiten vorgestellt:

• Setup

Auf dieser Seite wird eine Liste der USB-Ports angezeigt, und man kann angeben, an welchem Port eine Karte angeschlossen ist, um sie zu registrieren und in die Geräteseite zu übertragen.

• Gerät

Jedes Gerät entspricht einer Karte. Jede Karte wird mit « Untergeräten » ausgestattet sein, die die mit der Karte verbundene Ausrüstung darstellen (433MHz, IR, …)

2. Der Arduino-Code

Darüber habe ich lange nachgedacht, denn das ist ein wichtiger Punkt. Jeder Benutzer muss den richtigen Arduino-Code haben. Deshalb habe ich an einen « universellen » Code gedacht, der speziell für den Dienst ist. Je mehr Geräte berücksichtigt werden, desto wichtiger wird der Code. Die Besonderheit ist, dass jedes Gerät seinen « Unterdienst » hat und dieser Unterdienst nur einen Code-Ausschnitt aufruft, was die Belastung der Karte verringert.

3. Die Standardisierung der an die Karte zu sendenden JSON-Daten

Zur Kommunikation braucht man unbedingt einen Standard. Dieser wird wie folgt aussehen:

{
    "service": "der Dienst des Untergeräts",
    "message": {
        "DATA_PIN": "der Daten-Pin",
        "code": "Der zu sendende Code"
    }
} 

Derzeit werde ich mich hauptsächlich auf die « Sende »-Module konzentrieren, da diese meiner Meinung nach am einfachsten für erste Ergebnisse sind.

4. Der aktuelle Entwicklungsstand

Ich bin natürlich immer noch am Entwickeln, aber mein Code ist immer noch hier verfügbar, falls jemand mir seine Kritik geben möchte

@camille

Zum Beispiel: Die Pins D10, D11, D12 und D13 wären nur für SPI reserviert, A4 und A5 für I²C, D1 und D2 für USB.

Was denkst du? Entspricht das deiner Idee?

Ehrlich gesagt hatte ich eher vor, dem Benutzer direkt den Typ seiner Karte und die betreffenden Pins abzufragen, um den Code entsprechend zu generieren. Aber ich denke, die Frage stellt sich nicht mehr, wenn alles in Ordnung ist, um mit einem universellen Code zu beginnen.

Vielen Dank im Voraus für euer Feedback

[camille]

@billona

ich werde mir den Code ansehen und dir dann Feedback geben.

Ich bin zu 100% für die Idee des universellen Codes, der die Verwaltung der Schnittstelle mit Gladys ermöglicht. Das ist für mich die beste Lösung.

Deine Idee, den Typ der Arduino-Karte abzufragen, ist gut. Ich denke, das wäre im Fenster „Gerät“?
Wenn ich es richtig verstanden habe, wählt man in diesem Tab den Typ des angeschlossenen Geräts (433 MHz, …) und den Typ des Arduino aus?

In diesem Fall würden die Pins für die Kommunikation automatisch vom System reserviert werden

Für die Arduino-Einstellungen denke ich ebenfalls, dass es die richtige Lösung ist, den USB-Port auszuwählen. Aber wenn man einen Arduino an den Raspi anschließt, gibt es dann eine besondere Anzeige, die den USB-Port von anderen unterscheidet? Oder anders gefragt, wenn ich einen Arduino und ein anderes Gerät anschließe, gibt es dann etwas, das verhindert, dass man sich vertut und den USB-Port des Arduino auswählt?

Nochmals vielen Dank für deine Arbeit,

[billona]

@camille

Deine Idee, den Arduino-Typ zu fragen, ist gut, ich denke, das wäre im „Geräte“-Fenster?
Wenn ich es richtig verstanden habe, wählt man in diesem Tab den Typ des angeschlossenen Geräts (433 MHz, …) und den Arduino-Typ?

Ja, so etwas hatte ich im Sinn, man muss nur sehen, wie man es organisiert.

@camille

In diesem Fall würden die Pins, die für die Kommunikation relevant sind, automatisch vom System reserviert werden

Da würde ich vorsichtig sein mit dem Begriff „automatisch“. Meine ursprüngliche Idee war, dem Benutzer die Wahl zu lassen. Er verkabelt sein Gerät, wie er möchte. Zum Beispiel kann er sich entscheiden, den Daten-Pin des 433 auf Pin 12 zu setzen… oder 13, das liegt bei ihm.

In jedem Fall, wenn er seine Wahl getroffen und seinen Arduino angeschlossen hat, wird ihm jedes Mal, wenn er ein Gerät hinzufügt, gefragt, welchen Pin er gewählt hat. So wird, wenn die Arduino-Funktion aufgerufen wird, ihm als Parameter nicht nur das zu sendende Signal, sondern auch der Pin, an den gesendet werden soll, übergeben. Dadurch wird der Code etwas vereinheitlicht

@camille

Für die Arduino-Einstellungen, denke ich auch, dass es die richtige Lösung ist, über den USB-Port auszuwählen. Aber wenn man einen Arduino an den Raspi anschließt, gibt es eine besondere Anzeige, die den USB-Port von den anderen unterscheidet? Oder anders gesagt, wenn ich einen Arduino und ein anderes Peripheriegerät anschließe, gibt es etwas, das verhindert, dass ich mich vertue und den USB-Port des Arduinos wähle?

Aktuell nein. Um die USB-Ports aufzulisten, gehe ich direkt über den USB-Dienst, und dieser liefert derzeit nur eine Information: comPath. Derzeit mache ich das manuell: Ich aktualisiere die Liste und schaue, welcher Port hinzugefügt wird, wenn ich meinen Arduino anschließe.

Dann habe ich mich entschieden, dass nur ein Arduino an den Raspi angeschlossen wird. Auf diese Weise kann ich den USB-Pfad der Karte ohne Mehrdeutigkeit in der Tabelle t_variables der Datenbank speichern. Man kann zwar immer noch darüber nachdenken, weitere per WLAN hinzuzufügen, wie zuvor erwähnt, aber für einen Anfang fand ich es einfacher, es so zu machen. Was denkst du?

Auf jeden Fall danke für deine Unterstützung! Ich freue mich sehr auf eine erste funktionierende Version

[Reno]

Hallo,

Ich habe Ihre verschiedenen Austausche in diesem Thread gesehen und mich gefragt, warum man einen Arduino verwenden muss, wenn die Raspberry Pi in der Lage ist, all diese Geräte selbst zu verwalten.

Daher denke ich, dass ich etwas übersehen habe. Könnten Sie mir mehr darüber erzählen?

Eine meiner Ideen (für später, wenn ich Zeit habe) wäre es, einen etwas generischen Python-Service zu erstellen, der es ermöglicht, die Ein- und Ausgänge der Raspberry anzusprechen und mit Gladys über MQTT zu kommunizieren.
Ich habe das Gefühl, dass das ein bisschen dem entspricht, was Sie bereits tun, oder?