Smart Home Sensorik - welche Lösung ist sinvoll?

Allgemein
1

Hallo zusammen,

ich versuche mal kurz zu skizzieren was ich für ein Ziel verfolge, damit ihr besseren Blick bekommt, welche Antworten ich suche.

Ich möchte in erster Stufe ca. 50 bis 100 Sensoren im ganzem Haus platzieren, die an KNX Kabel angeschlossen werden sollten. Die Kabeln sind bereits stern- bzw. baumförmig verbunden bzw. verlegt und an die Zentrale zusammengeführt. Sie ergeben aktuell 2-3 separate Verbünde, die ggf. noch mit RJ11/12 Hubs zum einem großem Bus verbunden werden (können). Die Stromversorgung (5V) der Sensoren sollte zentral für alle Leitungen unabhängig von eingesetzten Controllern, RPi oder PC erfolgen.

Es sind überwiegend Bewegungs-, Präsenz-, Temperatur- und Luftfeuchtigkeitssensoren o.ä. geplant. D. h. praktisch reine Sensorik. Die Automatisierung und aktive Aktoren werden durch anderen Lösungen abgedeckt und (wahrscheinlich) mit HomeAssistent gesteuert.
Die Werte der Sensoren möchte ich über MQTT an die Zentrale übertragen und weiter verarbeiten. Die Kommunikation zu den Sensoren sollte über die Kabelleitungen erfolgen.

Es geht also um etwas größere Lösung mit vielen aber überwiegend gleichartigen Sensoren.

Solche Elemente wie Gehäusen für die Sensoren o.ä. sind erstmals irrelevant. Was aber schon wichtig ist, dass man es halbwegs profesionalisieren kann. D. h. ein Einsatz von Breadboard o.ä. soll maximal nur für Testzwecke nötig sein.

Ich habe inzwischen einige Sensoren von AZ Delivery gekauft und versucht sie testweise auszuprobieren. Leider mit mäßigen Erfolg. Die Dokumentation mit den eBooks ist zwar super, aber ich habe aber den Eindruck, dass sie nicht ganz aktuell sind. Die Testumgebung habe ich versucht mit RPi 2B und Raspbian trixie aufzubauen. Der vorgeschlagene Einsatz mit den Python-Bibliotheken ist in der Doku zwar klar beschrieben aber es fehlen die Vorbereitungsschritte wie z. B. initiale Erstellung der Python-Umgebung (venv). Anders gesagt die Befehle in eBooks funktionieren mit nackten OS bei mir leider nicht vollständig. Ich vermute, dass mir auch noch die Information fehlen, welche Kernel-Module für GPIO bzw. jeweiligen Sensoren geladen werden müssen.
Vor paar Jahren mit älterem OS könnte ich z. B. mehrere DHT22 auf einem Bus auf dieser RPi 2B erfolgreich testen. Auch die Bewegungssensoren (Ultraschall bzw. Infrarot) haben damals funktioniert. Mit dem neuen OS klappt es leider nicht mehr. Als Protokoll setzte ich aktuell auf 1-wire. D. h. i2c aufgrund der 4-adrigen Kabel und längeren Leitungen (über 2m) sind für meine Lösung nicht einsetzbar.

Da ich meine Ziellösung in Sicht habe, habe ich versucht mit dem Busmaster DS9490R und OWFS die Umgebung zu stabilisieren bzw. die Anbindung der Sensoren zu vereinfachen. Der Busmaster wird zwar sauber erkannt, aber die angeschlossene Sensoren leider nicht mehr. Vieleicht sind sie gar nicht kompatibel oder Treiber in Form von Kernel-Module fehlen.
Nach meiner Recherche ist der Einsatz von GPIO für größere Lösungen instabil und ein Einsatz vom Busmaster (für 1-wire) deutlich stabiler sein sollte und mit normalen PC realisierbar (=> Unabhängigkeit von Geräte mit GPIO). Eigene Erfahrungen zum Vergleich zwischen GPIO und USB-Busmaster habe ich aber noch nicht.

Meine angedachte Lösung ist eigentlich die Sensoren an den Kabel anzuschließen und mit dem Strom durch ein Trafo mit 5V zu versorgen. Dann über RJ11 bzw. RJ12 die Datenleitungen zentral über ein Hub mit dem USB-Busmaster zu verbinden und dann z. B. mit OWFS auszulesen. Danach sollte OWFS an MQTT die Daten übertragen, die wieder mit z. B. HA verarbeitet werden können.

Da aber meine Testumgebung offensichtlich nicht funktioniert, suche ich nach Alternativen. Vielleicht hat jemand aber Ideen woran es liegen könnte und meine angedachte Lösung doch noch umsetzbar ist.

Alt Alternativlösung habe ich mich überlegt paar ESP32 o.ä. von AZ-delivery auszuprobieren und nach deren Anleitungen es zu testen. Leider fehlt mir die Info, ob ein ESP32 größere Anzahl von Sensoren bedienen kann. Wenn man an die Anzahl der PINs von GPIO angewiesen ist, wird die Anzahl der Sensoren stark eingeschränkt. Wenn man aber mehrere Sensoren über ein GPIO-PIN bedienen kann, könnte es ggf. funktionieren. Ich hoffe jemand kann mir zu diesen Aspekt sichere Info liefern.
Wenn es geht, werde ich gerne auch mit den ESP nur per Kabel kommunitieren wollen.

Die Frage ist, ob solche Kombination von mehreren ESPs und größeren Anzahl der Sensoren überhaupt technisch realisierbar ist.

Vielleicht hat jemand auch andere Ideen in welcher Richtung sowas gehen könnte. Auch ein Einsatz von anderen Protokollen wie z. B. ModBus statt 1-wire wäre denkbar.

Viele Grüße
bauherr

2

Hallo Bauherr,

erst mal “Willkommen im Forum”!

So wie es aussieht, hast du momentan mehrere Baustellen. Keine Kommunikation mit den Bauteilen, keine Bibliotheken für die Treiber und Datentransfer über mehrere Ebenen.

Eine einfache Möglichkeit 1-wire Sensoren auszulesen ist sie an einen ESP zu hängen.

Auf der Seite von ESP Home findet man fast immer den passenden Code für alle möglichen Sensoren.

Man gibt an, um welchen Sensor es sich handelt, und alle benötigten Bibliotheken werden automatisch eingebunden.

Das Ganze würde ich schrittweise aufbauen/testen:

  • ESP flashen (in HA oder über die Website)
  • Einen Sensor anschließen
  • Den Sensor im ESP einrichten
  • Über HA auslesen
  • Weitere Sensoren hinzufügen

Ein ESP hat bis zu 16 Pins an die man Sensoren anschließen kann.

An mehreren Pins kann man mit I2C je Pin bis zu 8 Porterweiterungen mit jeweils 16 Pins anschließen.

Oder man nimmt mehrere ESP, je Sensor -Typ einen.

Wenn man die Sensoren direkt an einen ESP anschließt und diesen in HA einbindet, hat man den Vorteil, dass das alles sauber läuft und tausend mal getestet wurde. Man hat nur eine Schnittstelle und die ist sauber konfiguriert und dokumentiert.

3

Danke für die schnelle Antwort!

Ja, so ist es leider. Deswegen will ich das passende HW für die Testumgebung besorgen, die dann später auch im Betrieb einsetzbar werden kann.

ESPHome bzw. Auslesen von ESP kann wahrscheinlich auch ohne HA passieren? Ich sehe geade, dass ESPHome eine Server Komponente hat, die das Auslesen erledigen könnte. Ein direkte Kommunikation zwischen HA und Sensoren plane ich nicht ein.

Kann man aber nicht an einen PIN mehere Sensoren anschließen? Mit RPi2B und deren GPIO war es kein Problem. Etwas baumförmige Kabelsalat ein Kabel an GPIO anschließen und das wars.

Die Kabelleitungen müssen auch verschiedene Senoren bedienen können, mind. solange gleiches Protokoll verwendet wird und die Adern immer gleiche Funktion haben.

Ok. Aber wie verbinde ich die PINs an ein 4-adrigen Kabel wo mehere Sensoren angeschlossen sind? Wenn ich nur 4 Adern habe, wird die Verwendung von meheren PINs nichts brongen, da sie zum Schluss ohnehin über ein Kabel laufen werden.

Anders gesagt, wenn man bei 1-wire bleiben könnte, musste das gesamte Konstrukt mit 2 PINs für Datenübertragung lösbar sein. (VCC und GND wird später ohnehin ohne ESP o.ä.)

D. h. ein ESP wäre physikalisch reichen müssen bzw. fehlt mir kein Grund warum es hardwareseitg ein Problem sein sollte. Wenn es aber softwareseitig bzw. wegen Performance sonvoller ist mehere ESP (z. B. pro Sensorart eins) einzusetzen, dann ok. Dann mussten aber auch mehere ESPs gleiche Leitung nutzen können.

Dies glaube ich sofort. Leider passt mir die Architektur nicht. Eine direkte Verbindungen zwischen IoT und Steuerungsinstanz sehe ich sichertstechnisch zu risikoreich. Für Lab, Testumgebung oder um was schnell auszuprobieren ist es für mich ok, aber in produktiven Betrieb werde ich sowas nicht tun.

Dies sollte aber nicht das Problem sein, wenn eine diekte Verbindung mit HA durch ESPHome Server möglich wird, ist die Isolation der Softwarekomponenten und betroffenen Kommunikationsschichten nur die Frage der Zeit. Auf dieser Ebene komme ich (so die Hoffnung :wink: schon alleine klar.

Nur hardwarenahe Komunikation ist wohl die Stelle, wo es bei mir hackt (hier fett markiert)

HW Sensor → Kabel → HW Controller → Anschluss → HW Software/Protokoll → Software/Anwendung A → Anwendung B → Anwendung … → HA

Nachtrag: Ich sehe gerade, dass ESP nativ auch MQTT bedienen kann. D.h. sowas wie ESP Server o.ä. wäre gar nicht nötig. ESP müsste nur MQTT Nachrichten schicken.

Viele Grüße
Bauherr

4

Ok, etwas Recherche und man kommt der Lösung näher.

Hier ist ein Beispiel wie man über serielen Anschluss mehere Sensoren bedienen kann. Bzw. 1-Wire simulieren.

Da ESP dierkt mit MQTT Server komunitieren kann, kommt man schon dem Ziel nährer.

Es bleibt zwar noch die Vermeidung von WLAN und ggf. Skalirung der 1-Wire Buse mit ESPs aber es klingt schon vielversprechend.

Hat aber jemand noch Idee, ob man es auch ohne ESP lösen kann?

Z.B. mit solchem Adapter wie

  • CP2102 USB zu TTL Konverter HW-598
  • oder UART-TTL USB Adapter für 3,3V und 5V

Kennt jemand sowas? Welche Software auf Linux wäre in der Lage den serielen Device zu bedinen?

Man könnte es dann einfach auf irgenein PC einschließen oder an eine VM mappen und mit einer Software ablesen.

Damit könnte man sich die Fumelei mit den Board etc sparen. Einfach ein “USB-Stick” und das war’s.

Viele Grüße
Bauherr

5

Mit dem USB-Stick, bzw der Software dazu kenne ich mich leider nicht aus. Ich nehme halt gerne ESPs. Da muss ich mich um die Software nicht kümmern. Ich sage dem ESPHome einfach, dass ich den DS18B20 an Pin x habe und das war’s.

2 „Gefällt mir“
6

Jede serielle Konsole auf Linux kann das auslesen: Minicom. Aber nicht unbedingt sinnvolle Zeichen darstellen, je nachdem was übertragen wird.

Jedes Python Programm kann das mit wenigen Zeilen Code auslesen.

Aber: Solche UART Verbindungen mit TTL Pegel können nicht ewig lang sein. Also wenn Du jetzt 20 Meter Kabel verlegst, dürfte es Schwierigkeiten geben. Das gilt selbstverständlich auch für I2C.

Und: Die Gegenseite muss auch UART sprechen. Ein Sensor, im Sinne von, ein Sensor Chip spricht normalerweise I2C oder SPI. Aber nicht UART. Die Übersetzung in UART macht dann ein Mikrocontroller.

p.s.: Man kann UART auch nicht an mehrere Geräte gleichzeitig anschließen. Mit I2C geht das, mit UART nicht. Bei UART sprechen jeweils 2 Endstellen miteinander, bei I2C gibt es einen Master, der die Kommunikation initiiert und mehrere Slaves von denen sich einer angesprochen fühlt und antwortet.

7

Ok. Alles klar. Dann sollten softwareseitig keine große Probleme geben.

Dies ist schon ein Problem. Mein längste Busleitung könnte ca. 30-35m lang sein woran weitere leitungen angeschlossen sind. Liegt es an dem TTL Pegel?

D. h. die übliche Sensoren vonb AZ-Delivery sprechen nicht UART?

Ich habe meine Tests nur über ein GPIO PIN von RPi gemacht und da hat es alles soweit geklappt. Ich könnte mit ca. 3m langen Kabel und drei DHT22 die Werte problemlos mit 1-wire auslesen. Welches Protokoll GPIO nutzt also UART/I2C/SPI weiß ich leider nicht. Das erfolgreiche Test war aber auschlaggeben, dass ich eben die Kabel (EIB Y-(ST)-Y 2x2x0,8) baumförmig verlegt habe. D. h. kein Kabel pro Sensor.

Da ich nur 4-Adern habe und 2 schon für die Spannung gehen, bleiben also nur 2 Adern für irgendwelche Kommunikation.

Formel schon, aber es gibt durchaus einsätze, wie man über UART mehere Slaves bedienen kann.

Letztendlich ist es aber wahrscheinlich auch nicht vernünftig realisierbar.

Über I2C brauche ich gar nicht nachzudenken, da bei 2m Länge praktisch Schluss ist bzw. keine 30m mit bereits verlegtem Kabel realisierbar ist.

Welche Einsätze wurdes Du bei solcher Kabelverlegung vorschlagen?

So ein Adapter bzw. ESP werde ich sicherlich noch ausprobieren aber langsam fehlen mir die Ideen.

Das Softwareprotokoll 1-wire kann an einem Bus einige Sensoren händeln und 50m langen Kabel sollte kein Problem ist. Vom Prinzip wäre also 1-wire eingentlich einsetzbar. Schliließ mit KNX oder Modbus funktioniert es mit 4 adrigen Kabel problemlos.

Viele Grüße
Bauherr

8

Wie ich vorher schon ausgeführt hatte, hänge die Sensoren mit 1-wire an einen ESP32, lese die Werte ein und sende sie hin wo immer du willst.

Wie du die Daten dann weiterverarbeitest ist dann völlig offen.

Ich habe übrigens immer noch nicht verstanden, wieso du die Daten erst von den Sensoren zu OWFS, dann mit MQTT zu HA schicken willst?

Wenn sie letztendlich in HA verarbeitet werden sollen, dann kannst du sie doch gleich mittels ESP an HA übergeben. Das spart einiges an Schnittstellen und damit an Fehlermöglichkeiten.

1 „Gefällt mir“
9

Servus
Wenn ich lese “baumförmig verlegt” dann kanns auch mit 1Wire Probleme geben. 1Wire hat lieber Bustopologie als Stern..
1 Wire kriegst bei AZDelivery nur die Temperatursensoren. Weiters würde ich den Bus bei größeren Längen und Lasten nicht an einen uC Pin hängen sondern einen ordentlichen 1Wire Buskoppler nehmen.
Schau mal bei Esera - da gibts das passende Equipment.

Eine Alternative die noch nicht geannnt wurde wäre die existierende Verkabelung nur zur Stromversorgung zu nehmen und mit lokalen ESPs zu arbeiten- pro Messtelle einen. Da bist dann völlig offen und kannst jedem Sensor geben was er sich wünscht.

Was ich aber nicht verstehe: Wenn du schon eine KNX Verkabelung hast, warum nimmst dann nicht KNX ?? Insbesondere für Aktoren wäre das doch das richtige und jeder ESP/Shelly was weiß ich Bastelei hinsichtlich Zuverlässigkeit haushoch überlegen.

gruß
bb

10

Das Problem ist aber noch etwas früher. In dem Hardware-Protokoll der die Daten in 1-wire übersetzen soll. Es geht darum, ob 50 Sensoren, die an einer Leitung hängen überhaupt verarbeitet werden können.

Mit ESP werde ich es aber ausprobieren. Mir wäre aber lieber ganz normalen PC zu nutzen und die Leitungen an USB weiterzugeben und sie dann mit ganz normeler VM zu verarbeiten.

Letztendlich geht es mir um die Sicherheit des gesamten Netzwerks, der Komponenten usw.

Ich möchte in erster Linie die HW-Schicht von SW-Schicht sauber trennen. Deswegen habe ich erst OWFS als der ersten Layer definiert, der als einzige Komponente mit den Sensoren kommunitieren kann.

Durch ein Übername von solchen Sensoren (die oft auch draußen plaztiert werden) oder deren Leitungen wäre einfache Angriffsszenario, da der Zutritt zu dieser Komponenten nicht besonders geschützt ist. Bei WLAN ist es noch schlimmer, da nicht mehr ein Zutritt zu Gerät nötig ist.

Wenn ich in der Lage werde an solche Leitung eigenes Gerät einzuschließen und das System hinter dem Sensor bzw,. der Leitung zu übernehmen, dann hätte Kontrolle über alles was dran Angeschloßen ist. Wenn man noch weiter denkt und z. B. Aktoren für Alarmanlagen oder Stromsteuerung etc. damit verbindet, kann man ggf. noch mehr Schaden einrichten.

In unserem Beispiel wäre also HA einer der wichtigsten Komponenten, da er viel Kontrolle hat und damit höheren Schutzbedarf hat.

Trennung der Schichten für Transport, Kommunikation etc. ermöglicht auch für jeder Schicht eigene Sicherheitsmaßnahmen zu etabilieren und sie zu überwachen. Auch deren Austwausch und Wartung jeweiligen Layers/Kompontenten ohne “alles” zu aktualisieren und betten, dass alles gut läuft hat klaren Vorteil. Man kann einfach MQTT durch was anderes ersetzten, HA durch iBroker o.ä. Einfach nur, weil die Schnitstellen dies ermöglichen und nicht “alles” geändert werden muss. Aber ja, es wird deutlich komplexer und dadurch fehleranfällig.

In unseren Beispiel die Aufnahme von MQTT vor dem HA ermöglicht diese Daten auch für andre Zwecke zu verwenden. Z. B. Statistiken sammeln ohne ein Kontakt mit dem HA haben müssen. Oder einfach an den Nachbarn schicken, wenn auf seinem Grundsückt Feuerstelle erkannt wurde usw…

Mit der MQTT Schicht kann man verschidene Zonen bauen, DMZ von Internen Netz trennen etc.

Das WLAN an ESP ermöglich den von der Straße einfach das Gerät zu erreichen. Natürlich hat man Verschlüsselung etc. nutzen und es ist immer erst mal nur ein Client. Aber einfache DoS Angriff auf das WLAN wird schon ggf. die Komunikation von Sensoren beinflussen. Wenn davon die Alarmanlage abhängig ist, kann sie gestört werden.

Ich will aber nicht zu viel ins die Tiefen gehen, da es hier nicht das Thema ist. Ich hoffe aber, dass Du jetzt versteht was ich mit der Trennung etc meine. Es kommt einfach an, welches Sicherhets-Level für die geplante Lösung akzeptabell ist.

Dies stimmt vollkommen. Nur die Sicherheit solcher Lösung ist sehr überschaubar und die Möglichkeiten eingeschränkt.

11

Es ist eigentlich eine Leitung, wo weitere Kabel dran hängen. Von der Topolgie wäre es genau genommen “Bus”. Solche Buse habe ich handvolll und ich könnte sie separat als einzelne 1-wire Buse betreiben.

Die Bewegungssensoren u.ä. von AZ-delivery werden mit 1-wire nicht funktionieren?

Nach einem Buskoppler habe ich schon nachgedacht. Schlißlich habe ich schon versucht mit dem DS9490R es auszuprobieren, was als Busmaster dem Buskoppler sehr nah kommt. Deren Preise sind aber mit ca. 90 Euro pro Stück nicht ganz günstig. Letztentlich wenn man deren Spezifikation liest, ist es nichts anders als das was wir hier diskutieren (s.u.). Für den Betrieb werde ich vielleicht es sogar nehmen. Erst muss ich aber die Testumgebung architektonisch aufbauen, zum Laufen bringen und die Ziellösung testen können.

Datenschnittstelle:

  • Industrial 1-Wire Bus (5V, 1-Wire Data und Masse (GND), Funktionserdung (FE))

  • USB 2.0 Full Speed Compatible, FT232R USB UART, Virtual Com Port (VCP), Type B-Buchse

1-Wire-Bus – unterstützte Bausteine:

  • Standard 1-Wire Bus Funktionen

  • Parasitär Betrieb wird unterstützt (2-Leiter Betrieb ohne 5V Spannungsversorgung)

  • DS2480R+ 1-Wire Serial Line Driver

Man muss den aber auch an einem Rechner noch per USB anbinden, also ganz so viel bringt er leider momentan nicht. Natürlich gewisse Stabilität und Zuverläßigkeit schon. Deswegen ist sowas bei mir noch auf der Lister aber eher in der Ziellösung bzw. im Betrieb.

Danke für den Hinweis. Ja dies ist mir auch schon als Lösung aufgefallen. Aber eher wenn es nichts anderes gehen sollte. Die Kommunikation über WLAN sehe ich als ungeeignet. Bei ca. 70 Sensoren (d.h. auch gleicher Menge ESPs) wird das Funknetz stark belastet. Aber ja, man kann mehere Funkkanäle nutzen, paar Sensoren an ein ESP koppeln usw. Es ist aber für größere Menge “Clients” einfach semi geeignet. Abgesehen von möglichen Störfaktoren und der Strahlung. Paar weitere WLAN-Router bräuchte man dann auch noch…

KNX passt für mich nicht wegen Lizenzkosten und Preisen der Geräte/Sensoren. Es gibt zwar einfachere Lizenz für ca. 90 (?) Euro, aber wenn ich mich nicht irre auf 50 Aktoren eingeschränkt. Ein Sensor fängt schon gerne bei 50 Euro an. Das gesamte Software läuft noch auf Windows, was für mich schwer automatisiertbar ist.
Ansonsten die Aktoren für die Steuerung von Stromleitungen o.ä. habe ich schon im Betrieb und es funktioniert zuverläßig. Deren Austausch wäre die Kostenrahmen schon deutlich springen.
Es fehlt mir eben die Sensorik, die das Input für die Aktoren sein sollte :confused:
Deswegen habe ich hier gefragt, da die Community immer viel Erfahrung und gute Ideen hat.

12

Natürlich nicht, wie denn auch ??
Das einzige was am 1Wire Bus funktioniert sind 1Wire Sensoren. Az hat da nur die DS18B20 im Angebot.
Von 1Wire gibt native es im wesentlichen nur Temperatur/Spannungs Sensoren sowie Digital I/O, Counter und Memory
Wenn du was anders messen möchtest mußt du basteln oder eben fertig Bausteine kaufen. Da liegts auch gleich mal bei 50€
Im übrigen ist 1Wire nur für langsame Datenübertragung geeignet und es bietet keine Interrupts. d.h. wenn du
einen Bewegungsmelder an einen 1 Wire Digital /I/O hängst so müßtest du diesen permanent pollen. Da bist dann schnell mal bei einer Latenz im Sekundenberich und das ist noch optimistisch geschätzt

Sorry, net bös sein, aber du bist kein fake oder was ?
oben fabulierts du irgendwas über Angriffsvectoren am Bussystem weiter unten hast Angst das du mit ein paar popeligen Sensoren dein WLAN überlastest ?

greez
bb

13

Nein.

Ich hab mir den Link angesehen. Das sind die üblichen Sensoren von Aliexpress. Qualitätsniveau: 2 Stufen unter der U-Bahn. Das ist das Billigste vom Allerbilligsten :slight_smile: Also genau das, was man Dir hier im Forum empfehlen würde.

Diese Sensoren sprechen teilweise gar kein Protokoll sondern müssen von einem Mikrocontroller ausgewertet werden. Beispielsweise der Ultraschallsensor, der eine Flanke steigen lässt, wenn das ausgesendete Ultraschallsignal empfangen wurde. Die Zeitmessung muss ein Mikrocontroller machen. Der Link ist einfach eine zusammengewürfelte Box aus Aliexpress Sensoren. Der BMP Sensore beispielsweise kann nur I2C oder SPI. Das sind Sensor Module, die für eine Strecke von wenigen cm ausgelegt sind. Deine Gedanken über 1 Wire sind insofern obsolet, als einige dieser Sensoren von sich aus bestimmt nicht 1 Wire unterstützen.

Wenn Du die Daten über eine längere Strecke senden möchtest, musst Du die Daten der Sensoren erst verarbeiten, d.h. von einem Mikrocontroller auslesen lassen, dann weiterverpacken und über ein anderes Protokoll senden. Das erfordert auch Hardware, um die Daten zu übersetzen. Egal ob Ethernet, irgendein Bus oder was auch immer - die benötigen alle irgendeinen Driver Chip.

Du siehst also: Billig und fertig gibt es nicht. Es gibt manchmal billig+schlecht+fertig. Es gibt teuer+fertig. Es gibt billig + Du musst extrem viel Zeit investieren.

Eine Alarmanlage, die sich auch so nennen darf, nutzt meines Wissens Frequency Hopping. So einfach sollte sie nicht zu stören sein. Man muss dazu schon mehrere Frequenzen gleichzeitig stören.

14

Ok… d.h. ich bin wohl komplett falsch abgebogen… und denke an einer Lösung (1-wire) die praktisch kein Sinn für mich macht.

Ich bin kein Fake oder eine KI :slight_smile:
Wie ich am Anfang geschrieben habe, mein hardwarenahes Wissen ist überschaubar und wie man sieht, fehlen mir gewisse Grundlagen auf physikalischen Layer.
Womit ich mich aber gut auskenne ist alles ab OSI Model Layer 3+. D.h. kein Elektroniker sonder eher Informatiker. Btw: Mit Angriffsvectoren kenne ich mich tatsächlich gut aus :wink:

15

Danke für die klare Antworten!

Wie schon im vorherigen Post geschrieben, dann liege ich vollkommen falsch mit meinem Einsatz und muss mich konzeptionell noch sich mit dem Thema auseinander setzen.
Jetzt verstehe ich warum die Verwendung von z. B. ESPs durchaus viel besser wäre als 1-wire mit Busmaster…

16

Ich sehe, das ist eine Antwort auf mein Posting, aber ich habe nie behauptet, dass ESP32 besser wäre. Weder hier noch in irgendeinem anderen Posting in diesem oder einem anderen Forum…

Deine Ambition bestimmte Kabel über längere Strecken zu nutzen, erfordert sehr viel Zeit und technisches Know How.

Als Hardware Grundlage denkbar wären: RS485/Modbus bzw. CAN-Bus. Beide sind vom Strombedarf her ok. Das typische Ethernet verbraucht gern mal paar hundert Milliwatt pro Gerät.

17

Dies habe ich auch nicht behauptet. Es ist nur meine Interpretation. Dein Hinweis darauf, dass man die Sensoren von einen Mikrokontroller ausgelesen werden müssen, hat mich in die Richtung von ESP gebracht. Der wäre in der Lage verschidene Arten von Sensoren auszulesen. Unabhängig davon ob es I2C, SPI o.ä. wäre. Ich habe gehoft, dass es eben so ein Busmaster mit 1-wire hinbekommt. Da lige ich aber eben falsch.

Modbus habe ich auch schon in meinem ersten Beitrag als Möglichkeit erwähnt. Schließlich muss es nur in die bestehende Verkablung passen.
Von Sensoren möchte ich überwigend Präsenz-, Bewegung- und Abstandsensoren, um z. B. geöffnete Fenster zu erkennen. Temperatur- Feuchtigkeit u.ä. wäre eher ein Beifang, da reicht ein pro Geschoss aus und ggf. noch was BZ o.ä. Räumen.
Wäre Modbus für solche Sensoren geeignet?

18

Ich wüsste nichts, was dagegen spricht. Aber ich glaube nicht, dass außer für industrielle Zwecke, es diese Lösung bereits gibt: also Sensor → Mikrocontroller → Modbus

Dazu muss der Mikrocontroller nämlich vorher den Sensor kennen - d.h. wie die Kommunikation mit genau dem Sensor abläuft. Das muss programmiert werden (oder worden sein). Und erst dann kann er diese Informationen umwandeln in Modbus.

Dazu bedarf es sowohl Hardware (Modbus Chip), als auch Firmware.

Ich habe vorher aus Neugier mal kurz einen Modbus Chip mir angesehen - der hat bis zu 32 Transceiver am Bus unterstützt. Das würde bedeuten, dass wenn Du mehr Geräte haben willst, die an derselben 2 adrigen Leitung hängen, jedes End-Gerät mehrere Sensoren angeschlossen haben müsste. Ungefähr so:

3 Sensoren A, B, C → 1 Mikrocontroller M → Selber Modbus B
2 Sensoren D, E → 1 Mikrocontroller N → Selber Modbus B
usw..

Der Chip aus dem Beispiel braucht 5V. Das bedeutet, dass wenn Deine Stromversorgung 5V ist, es Probleme geben kann. Wegen langer Leitung → Spannungsverlust bzw. weil man die Spannung nicht mehr filter kann. Besser wäre eine etwas höhere Spannung, min. 6V die dann runterreguliert wird auf 5V.

p.s.: Hier ein Modbus Aufsatz für Raspberry Pico (nicht Pi!)

2-channel RS485 module for Raspberry Pi Pico, SP3485 transceiver - buy at BerryBase

Er benötigt nur 3,3V Versorgungsspannung.

19

Danke für Deine Antwort!

Ich melde mich zwar etwas später, aber ich wollte erst paar Sachen ausprobieren.
Inzwischen ist ein Pico angekommen und ich könnte einige Sensoren soweit erfolgreich testen. Hier muss ich sagen, dass Pico ganz feine Sache ist und das Programmieren mit Micropython sehr bequemen ist.

Was ich gemerkt habe, kommunizieren die Sensoren, die ich aktuell plane über UART und ich wohl nach den PINs max. 4 Sensoren nativ an Pico anschließen könnte.

Wenn ich es aber richtig verstanden habe, wird der Adapter mir zwar die Menge der UART Sensoren pro Kabel auf 2 einschränken aber dafür im Pico sie als Modbus Elemente nativ bereitstellen. D. h. im Pico werde ich praktisch nur Modbus sprechen müssen. Richtig?

Das bedeutet, dass ich an jeweiligen Kabelenden ein Pico anschließe und an diesen Pico bis 2 UART Sensoren. Über das Pico schicke ich dann über Modbus die Informationen weiter zur Zentrale und werte sie entsprechen aus. Z. B. durch anderes Gerät der netzwerkfähig ist, Modbus RTU versteht und weiter an z. B. an MQTT-Server senden kann?

Was ich noch nicht herausgefunden habe ist, wie ich die Picos mit Strom versorge. Ist dafür der PIN 37 mit 3,3V gedacht? Worüber kommt GND? der USB Anschluss macht da wenig Sinn, da ich sonst weiteren Adapter brauchen werde.
Wurde man diese Sensoren eher über Pico oder lieber separat mit Strom versorgen?
Das Thema Stromversorgung will ich aber noch nicht zu tief angehen, es geht eher mehr um das Prinzip.

Soviel zu Zwischenstand. Ich versuche es nächstes mal etwas mit Plänen zu visualisieren und dann schauen wir mal, ob ich was gelernt habe :wink:

Viele Grüße
bauherr

20

https://www.raspberrypi.com/documentation/microcontrollers/images/pico-2-r4-pinout.svg

Hier sieht man das Pinout des Pico. Man hat 2 UART Schnittstellen UART0 und UART1. (Diese kann man zwischen 2 Pins hin/herschalten.)

Der RS485 Aufsatz nutzt genau diese 2 UART Schnittstellen, um Daten umzuwandeln. D.h. man schreibt auf die UART Schnittstelle irgendeinen seriellen Output und der Aufsatz gibt es dann aus über das angeschlossene Kabel. Das wiederum heißt, man kann keinen UART Sensor anschließen, weil die Ausgänge ja belegt sind.

Jedenfalls fast… es gibt für alles eine Lösung.
Wenn ich auf die Herstellerseite für den Aufsatz blicke: https://www.waveshare.com/pico-2ch-rs485.htm

sehe ich, dass das Modul GP0+GP1 bzw GP4+GP5 vom Pico nutzt (GP steht wahrscheinlich für GPIO, general purpose in/out, damit ich hier auch was für die Bildung mache :p).
GP0/1 ist UART0. GP4/5 ist UART1.

Was man z.B. machen könnte ist UART1 am Pico auf GP8/9 zu legen. (Wie gesagt, das lässt sich umschalten). Dann würde das Aufsteckmodul immer noch versuchen über GP4/5 zu kommunizieren, und man könnte auf GP8/9 einen Sensor anschließen. Das Aufsteckmodul würde dann weiterhin GP0/1 nutzen können für eine RS485 Verbindung, aber keine zweite Verbindung herstellen können (unter Verwendung von GP4/5, weil dort intern nichts angeschlossen ist).
Wenn man das so macht, würde ich GP4/5 so konfigurieren, dass der TX Pin einen Pull-Up hat. Und der RX Pin ebenfalls einen Pull-Up. Um das angeschlossene Modul nicht zu verwirren.

2te Lösungsmöglichkeit, komplizierter:
Man kann mittels PIO am Raspberry Pico beliebige Pins in UART Pins konvertieren, sogenanntes Software UART. Das ist aber schon fortgeschrittenes Zeug.

Ich weiß nicht wie Du auf 4 kommst. UART besteht aus RX und TX. Es gibt 4 Pins: nämlich 2 RX/TX Paare. RX steht für Receive, TX für Transmit. Das gehört beides zur selben UART Schnittstelle.
Es gibt nur 2 UARTs auf dem Pico. Damit könntest Du nur 2 Sensoren anschließen (wenn sonst nichts angeschlossen wäre). Es gibt aber auch sowas wie Multiplexer/Demultiplexer… (Das wäre der 3te Lösungsvorschlag). Man kann beliebige Eingänge mit einem zusätzlichen Chip auf verschiedene Ausgänge routen. D.h. man kann aus 1 UART => 6 UARTs machen oder 8, je nachdem wieviele Ausgänge der Multiplexer hat. Nutzen kann man dann aber nur 1 Ausgang jeweils, nicht alle gleichzeitig. Man könnte also zuerst mit Sensor A reden, dann mit Sensor B usw…
D.h. Du kannst Lösung 1 + 3 kombinieren, um mit mehreren Sensoren am selben Pico zu sprechen, das erfordert aber einen De-/Multiplexer.

Ich bin zufällig noch auf das gestossen:

Ich denke der macht auch RS485 aus TTL.

2 Stück von dem (1x für RX, 1x für TX) sollten einen 8 Kanal Multiplexer ergeben.

Der Empfänger kann auch ein Pico sein, wieder mit Modbus Modul. Der Pico kann die Daten direkt über USB dann z.B. weitergeben.

Wenn Du Pin 37 nutzt, musst Du vorher den internen DC/DC Konverter abschalten über den 3V3_EN Pin. Normalerweise speist man 5V auf VBUS ein. Die 3,3V werden dann über den auf dem Board verbauten DC/DC erzeugt. Es gibt da ein eigenes PDF das erklärt “how to power raspberry pico”. Das Board hat mehrere GND Pins. Jeder hat denselben Zweck.
Man kann natürlich auch alternativ über USB Strom zuführen.

Hängt von der Art des Sensors ab. Sensoren die extrem penibel auf Spannungsschwankungen reagieren, würde man über 5V → eigener LDO versorgen. Ansonsten kann man auch die 3V3 Schiene des Pico nehmen.

p.s.: Abschließend: ich würde das RS485 Modul auf Aliexpress nehmen (dann brauch ich nix rumkonfigurieren) + das an UART0 anschließen. Dann würde ich auf UART1 die Multiplexer Boards anschließen. (Das wird dann afaik mit 3 Signalen gesteuert, man brauch also nochmal 3 zusätzliche GPIOs pro Multiplexer Board). Und die Sensoren dann an die beiden Multiplexer Boards.
pps.: Korrektur: ich selbst würds natürlich ganz anders machen, ich würde ein eigenes Board entwickeln mit anderen Chips und ohne Kabelsalat.