Guten Tag
Hat jemand von euch Erfahrung betreffend der Nutzung von I/O‘s insbesondere auf einem Repeater. Unterstützt MeshCore überhaupt die Kontrolle von I/O‘s? Und falls ja, würden diese z.B. über die CLI aktiviert bzw. konfiguriert? Ich setze RAK Hardware ein (RAK4630) welche über physische I/O’s direkt auf dem Board verfügt. Ich bedanke mich im Voraus für Tipps oder auch für Himweise, wo ich Informationen zu diesem Thema finden kann.
L.G. HB9DTZ
Soweit ich sehe, sind getGpio() und setGpio() bei den wenigsten Boards implementiert.
Die Implementierung in der CLI ist heute nur im Sensor drin:
Sieht also schlecht aus in der offiziellen Firmware. Der Repeater kann heutzutage keine GPIOs per CLI steuern.
Ganz herzlichen Dank für diese Info! Dann werde ich dies anders zu lösen versuchen. Die Idee war, an einem, aus MeshCore Sicht interessanten Standort ein anderes Gerät resetten zu können. (Diese Möglichkeit hätte das Aufstellen eines Repeaters an diesem Standort gerechtfertigt) 
.
Mit dem richtigen Board wäre das ja grundlegend möglich. Da ich selber auch so ein Projekt im Kopf hätte werde ich das am Wochenende mal durch spielen und die Details dann hier mit euch teilen.
Vielleicht könnte man die GPIO Steuerung auf einem Client realisieren und diesen ein paar Meter vom Repeater hinlegen? Dann wäre die Funktion vorhanden und trotzdem ein Repeater da?
@Felix Von dir sehen wir im Netz eine ganze Anzahl an Repeatern mit der Bezeichnung „Lampe xy“… Nun haben wir uns gefragt, ob du mit diesen Repeatern deine Lampen steuerst (und vielleicht etwas zur Frage in diesem Thread beisteuern könntest) oder ob du Repeater an irgendwelchen Lampen aufgehängt hast .
L.G. Christoph
Habe da leider auch nie weiter gemacht. Meiner Recherche nach können das bis jetzt nur drei Boards (tiny_relay, rak3x72, heltec_ct62) und das auch nur in der Sensor Rolle.
@HB9DTZ Ich könnte mit AI aber schon mal eine Repeater Version bauen die das könnte. Was genau müsste das können,wie möchtest du das ansteuern? Mit Nachrichten, oder mit Terminal Befehlen?
@Felix , der man der 1000 Repater (), baut glaube ich repeater in billige Solar-Lampen. Ist gar keine schlechte Idee, da bekommt man eigentlich sehr billig fast alles was man braucht für einen Repeater.
Irgendwie war meine Frage einigermassen doof, auf einen Repeater kann man ja keine Nachricht senden 
Ich versuche mal eine Version zu bauen auf welcher man GPIO mit einfachen Befehlen setzen kann. Zum Beispiel:
Hallo chix
Ja, bei Ali gibts diverse All-in-one Solarlampen für ca. 8.-. Momentan teste ich diese und noch ein paar andere Varianten mit verschiedenen Ladekontrollern.
Solange Sonne da ist, reichen diese ca. 1W-Panel längstens. Nun stellt sich aber die Frage, welches auch bei Bewölkung/Nebel noch genügend herausholt. Das werde ich in den diesen Tagen sehen.
Im Test sind 2 Lampen-Typen: 4Stück mit 5V-Panel und 1x mit 5,5V-Panel
zudem 2x 6V (D5), 1x 12V/20W und 1x 18V/4W je mit dem CN3971
Ladekontroller: CD42, TP4056, BQ25606 und CN3971
Bisherige Erkenntnisse:
Der CN3971 mit den 5V-Panels ist nicht optimal, dieser ist der in dieser Kategorie das Schlusslicht.
Der BQ25606 ist bei den Lampen aktuell leicht vorne.
Monokristaline Panels bringen wesentlich mehr als Polykristaline. Insbesondere bei schlechtem Licht. Die Lampen mit den kleinen Mono-Panels sind die meisten besser dran als die wesentlich grösseren Poly-Panel.
Zur Hardware: Xiao Wio NRF, Laderegeler und Panel wie beschrieben, Batterie ca. 1200 mAh, BMS, Diode, wenn nötig (CN3971), siehe Schema
PS:
was der Chinese an Panel-Leistung angibt ist fast immer falsch:
10x10cm = 1dm2 = ca. 2 Watt.
Alles andere ist Fantasie.
LG Felix
Danke Felix für deine Erläuterungen über deine Lampen. Ich wünsche dir weiterhin viel Spass bei deinen Experimenten mit den Solarpanels!
@chix Fragen sind nie doof. Schön, dass du dich auch damit befasst!
Die Anwendung, welche ich im Kopf habe, ist die “out of band” Kontrolle von ferngesteuerten Amateurfunkanlagen. Diese werden normalerweise über eine IP-Verbindung (Richtfunk, LTE, Starlink) kontrolliert und genutzt. Beim Ausfall dieser Verbindung(en) möchte ich über LoRa z.B. einen Reset durchführen können oder den Status von Anlageteilen (z.B. Solarstromversorgung) abfragen können.
Ob dies von einem Client aus über Messages, Terminalbefehle oder sogar von I/O zu I/O erfolgt (also, wenn man auf dem einen Board einen Taster betätigt, welcher auf dem anderen Board eine LED / ein Relais schaltet), ist nicht so relevant.
Ideal wäre es, wenn man dazu RAK Boards verwenden könnte, weil es in der RAK WisMesh Welt viele schöne modular bestückbare Basisboards mit diversen ebenso schönen I/O Zusatzboards gibt. Ich habe für Test schon diverse Boards (RAK13001 / RAK13002) organisiert und auch in den WisMesh Pocket Geräten gibt es freie Slots, welche Erweiterungen wie z.B. Zusatztasten im Client ermöglichen würden.
Welche Rolle genutzt wird, ist ebenfalls nicht so relevant, ich würde für diese Aufgabe ein jeweils eigenes Board einsetzen, welches nicht noch andere Aufgaben wahrnehmen muss.
Schön wäre auch, wenn man remote zusätzliche Spannungen messen könnte, wie z.B. die einer externen grossen Solarbatterie.
In anderen Bereichen habe ich mich auch intensiv mit AI gestützter Programmierung befasst aber im Bereich der Gerätefirmware habe ich noch absolut keine Erfahrung sammeln können.
L.G. Christoph
Hallo Christoph
Wäre da nicht MeshTastic die bessere Wahl ?
Du könntest wahrscheinlich über MQTT Daten in beide Richtungen senden.
Andererseits experimentiere ich in diesem Moment damit, dass ich die Daten (Batterie-Spannung (weitere sind vorhanden, werte ich aber momentan nicht aus)) meiner Repeater via MQTT in den Home Assistant rein bekomme und dort auswerte. Hurra, es funktioniert.
Beim FakeTec-Board (selbstbau) gibt es die Möglichkeit, bis zu 3 MosFET auf dem Board unterzubringen. Frag mich aber nicht, wie diese dann effektiv angesteuert werden.
Ursprünglich wurde dieses Board ja auch für MT entwickelt…
Zudem können über I2C diverse Sensoren ausgelesen werden. Das funktioniert mit MC gut. Mein Repeater auf der Blasenfluh hat zB. einen BME280-Sensor (Temperatur, Luftfeuchtigkeit und Luftdruck).
LG Felix
Hallo Felix
Ja, MT wäre bezüglich der Funktionen erheblich flexibler. Aber ich möchte eine robuste Übertragung, welche bei Bedarf auch funktioniert. Gerne möchte ich auch das tolle Repeaternetz nutzen, welches die MC Community in den letzten Monaten aufgebaut hat. Und diesbezüglich hat MC aus meiner Sicht deutliche Vorteile. Deshalb werde ich mich auf MC konzentrieren und diese Funktion nötigenfalls mit einem externen ESP realisieren.
L.G. und gute Nacht
Hallo Christoph
du könntest auch LoRaWAN einsetzen, mit dem Vorteil, dass ch-weit eine gute Abdeckung vorhanden ist und du so einfach die gewünschten Daten in dein homesystem runterziehen könntest; gut binary packen und beim Empfang im payload-decoder auseinande klamüseln und weiter verwerten.
Der gelegentliche Reset wäre über eine downlink message möglich.
viel Spass, urs
Hallo Urs
Da hast du vollkommen recht, das würde gut funktionieren. Ich würde mich jedoch wieder in eine unerwünschte Abhängigkeit eines Providers sowie diverser Services begeben. Und genau diesen Fall, nämlich den Ausfall irgend eines nicht von mir beeinflussbaren Netzelementes möchte ich abdecken.
Deshalb gefällt mir MeshCore so und deshalb möchte ich diese Möglichkeit irgendwann ausprobieren. Und ja, es geht auch etwas um „der Weg ist das Ziel“ . Man kann so vieles fertig kaufen… mich reizt die Herausforderung, Dinge selber zu bauen und die Funktion zu erleben und zu verstehen.
Schönes Weekend allerseits 
Hallo Christoph
Ich denke es sollte möglich sein, den Companion für die Übertragung von aufbereiteten Texten (Befehle: z.B. Relais A Ein/Aus oder Daten) zu nutzen. Dafür müsste m.E. das bestehende ‘Companion Radio Protocol’ (CRP) verwendet werden.
Physikalisch läuft das CRP bestimmt über eine UART / USB-Serielle Schnittstelle des Meshcore Radios (ist eine Annahme von mir, müsste verifiziert werden!)
Die Aufbereitung und Bereitstellung der analogen/digitalen Daten hätte mit einem zusätzlichen Controller zu erfolgen.
Das Ganze ist mit erheblichem Aufwand (Analyse des Codes, Programmierung) verbunden - würde aber die Möglichkeit der Übertragung unterschiedlichster Daten und die Unabhängigkeit von Netzbetreibern etc. bedeuten!
Wünsche dir Energie und Erfolg!
LG, Paul
Hallo Paul.
Ja, der von dir beschriebene Ansatz dürfte recht zuverlässig zum Erfolg führen. ich habe das CRP bereits in einem Tool verwendet, welches Kontakte pflegen- und Duplikate des ersten Byte des öffentlichen Schlüssels finden kann. Damit kann man auch Messages an den eigenen Client einfach auslesen, ohne im Code mit Schlüsseln zu “hantieren”.
Man benötigt dann einen externen Controller, welcher einen USB Host zur Verfügung stellt und welcher (deswegen) auch nicht so energieeffizient sein könnte wie gewünscht.
Ich werde den Ansatz von CHIX weiterverfolgen und den Code um die notwendige Prozedur ergänzen, damit ich die I/O’s der RAK Hardware direkt nutzen kann.
In diesem Zusammenhang habe ich auch Tests einer “Replay-Attacke” durchgeführt (Messages an der Luftschnittstelle als IQ Daten aufzeichnen und mittels eines Vektorsignalgenerators wieder abspielen). Diese Tests sind aus Sicht des Use-Cases erfolgreich verlaufen, die Messages wurden vom Empfänger nicht ausgewertet. Das MeshCore Protokoll beinhaltet genügend Mechanismen, dass solche Angriffe erfolglos bleiben und daher keine weiteren Schutzmassnahmen auf der Anwendungsebene erfordern (z.B. rolling keys etc.).
Damit wird ein zusätzlicher Controller umsomehr überflüssig.
Ich halte euch auf dem Laufenden, sofern ich in diesem Thema weiterkomme
L.G. Christoph
L.G. Christoph
Es gibt zB. von LuckFox, Lichee und Sipeed so Daumennagelgrosse Linux-Bördchen. Darauf läuft Python etc. Damit könnte man evtl. etwas machen…
Mein Lichee zieht ca. 150-200 mA
Auf dem Lichee habe ich aktuell ein Ubuntu-risc64 22.04 Linux drauf.
Das hier (wiki) ist das grössere Board, es gibt noch wesentlich kleinere und günstigere, siehe Links unten.
übrigens Python gibts auch für den NRF52840
Danke Felix für die Tipps und die Links für die Hardware!
150 mA sind natürlich im Vergleich zu einem normalen Repeater viel… allerdings würde so eine „appliance“ mit Relais und Sensoren auch vom Netz gespiesen und lediglich eine Pufferbatterie für den Betrieb bei Stromausfall beinhalten. Auch eine Relaisspule zieht im Vergleich zum Repeater viel. Für meinen Anwendungsfall würde ich die Relais über den NC Kontakt beschalten, so dass sie normalerweise die Last eingeschaltet lassen. Bei einer Altivierung der Relais wäre das lediglich für ein paar Sekunden, um die Speisung für einen Reset zu unterbrechen.
Den Tipp mit Python für nRF werde ich mir näher anschauen.
L.G.
Kennst du Solid-State Relais? Da kannst du auch mit einem ESP32, Arduino, Raspberry oder sonstigen Mikrokontollern sehr grosse Lasten schalten. Hier mal ein Beispiel, ein NC gibst sicher auch, muss ich mal raus suchen. SSR-40DD 40A Solid State Relais DC zu DC - Bastelgarage Elektronik Online Shop
Für externe Batterien sind Spannungs- und Strommessungen sind Heute schon möglich, ich habe zum Beispiel einen INA260 in einem meiner Repeater. Der läuft bereits mit dem heutigen Release von MeshCore einwandfrei. Anlöten, neu booten, fertig, dann kann man den im Remote Management unter Telemetry auslesen. Ina260 Erkennungs sensor modul niedrige Leistung hohe oder niedrige Seitens pannung Strom leistungs sensor Strom leistungs sensor tragbares Modul - AliExpress 502
Was meiner Meinung nach wirklich fehlt ist auf einem Repeater via MeshCore einen GPIO auf einem RAK aktivieren und deaktivieren zu können, der Rest ist dann nur noch etwas löten. Werde das bei Gelegenheit mal mit CursorAI versuchen, kann einfach noch nicht sagen wann ich diesen Moment finde.
