ESP8266-nrF24l01-Datensammler / Gateway (ohne MySensors)

Begonnen von Papa Romeo, 11 August 2020, 13:06:45

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 Alle
Benutzer-Aktionen

Papa Romeo

11 August 2020, 13:06:45 Letzte Bearbeitung: 14 August 2020, 06:42:58 von Papa Romeo
Was mich eigentlich schon eine ganze Weile nervt oder stört, ist, dass ich für Sensoren,  die mir z.B. Werte für Helligkeit, Feuchte, Temperatur udgl. über WLan liefern sollen,
in der Regel einen ESP, Wemos o.ä Modul einsetzen muss.

Ist ja an sich kein Problem, aber jeder dieser Sensoren nimmt dann natürlich immer eine IP-Adresse für sich in Anspruch und ich hab mir überlegt,
ob man das nicht anders gestalten könnte.

Eine IP mit jeder Menge Sensordaten...... Ergebnis ... das  ,,nRF24-WiFi-Gateway".

Vielleicht gibt es ja so etwas schon, da mir aber die Suche im Forum keine Ergebnisse gezeigt haben, die in etwa so etwas beschreiben und ich auch nicht weiß, ob dieses Modul überhaupt noch Interesse findet, da inzwischen einige User schon wieder dabei sind auf RF´s im Bereich unter 1 GHz umzustellen, werde ich mir erst einmal die Mühe der Dokumentation sparen, das Modul nur mal vorstellen, ein wenig beschreiben und ein paar Bilder einstellen.

Also kurz: Das Modul scannt die Gegend nach verfügbaren Sensoren.  Den Sensoren wurde vorher eine SensorID vergeben. Hinter dieser ID steht, um was für ein Sensor-Modul es sich handelt  (DHT, BME, BH usw.), welche Sensordaten es liefert (Feucht, Druck, Temperatur usw.), wie der Akku-Stand des Sensor´s ist (falls mit Akku oder Batterie betrieben) und in welchen Zeitabstand das Modul Daten sendet).

Die maximale Anzahl der Sensoren pro Gateway hab ich auf 30 festgelegt.

Die ,,Huckepackplatine" mit dem Display ist nur eine Option und für den Betrieb nicht erforderlich.
Über die Taster können allerdings dann hier die Informationen der Sensoren direkt abgerufen und auf dem Display angezeigt werden.
Die Übertragung der Daten an z.B. FHEM erfolgt über MQTT.

Bisher hab ich das Ganze mal mit 7 Sensoren in Betrieb, teils mit teilbestückten "Sensor-Config-Platinen" und teils im ,,fliegenden Aufbau".
Mit der voll bestückten ,,Sensor-Config-Platine", besteht die Möglichkeit z.B. die SensorID, den Sensortyp, die Sendezeit usw. über Jumper einzustellen.

So das war´s erst mal. Die Bilder sagen dann eventuell mehr.

LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Beta-User

#1
11 August 2020, 13:11:41
Zitat von: Papa Romeo am 11 August 2020, 13:06:45
Vielleicht gibt es ja so etwas schon, da mir aber die Suche im Forum keine Ergebnisse gezeigt haben, die in etwa so etwas beschreiben
Hmm, nRF24L+ war eigentlich der erste Transceiver-Chip, den MySensors unterstützt (zwischenzeitlich gibt es noch einige mehr), und WiFi-GW gibt's da auch schon lange (das kann man auch im MQTT-Modus betreiben)...

Hast du das Projektchen übersehen oder gibt es irgendwas, was man besser machen könnte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Papa Romeo

#2
11 August 2020, 13:23:38
My Sensors wollt ich eben nicht...aber schick mir mal nen Link.
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Beta-User

#3
11 August 2020, 13:47:11
Kannst mir ja bei Gelegenheit erläutern, warum du das nicht wolltest...

Doku zu MySensors ist insbesondere hier zu finden:
https://wiki.fhem.de/wiki/MySensors_Starter_Guide
https://www.mysensors.org/build
Da du auf den ESP8266 setzt: MySensors kann den nicht nur als GW nutzen, und v.a. für die Nodes kann man auch einige andere Microcontroller nehmen, wenn man z.B. wg. eines Displays mehr "Wums" braucht wie ein ATMega32. Dafür ist insbesondere auch die eigentliche Logik und der Transport-Layer getrennt, so dass es einfach ist, dann z.B. statt eines nRF24 auf einen LoRa-Transceiver zu wechseln (unterstellt, die Spannungspegel sind entsprechend adaptiert).

Es gibt btw. noch ein Projekt, das ESP-Now-basiert rein mit ESP8266 arbeitet (und dann den nRF24L+ spart): https://forum.fhem.de/index.php/topic,111654
Allerdings dürften bei der gezeigte nRF+pa+lna-Variante die praktisch zu erzielenden Reichweiten höher sein, und das gilt noch extremer, wenn man den in der 2.300m-Variante beschafft...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Papa Romeo

#4
11 August 2020, 15:30:05
..hab mir das "MySensors" mal ein "bisschen" angeschaut. Auch andere Anleitung im Netz...hat allerdings meine Meinung bestärkt....dürfen und sollen andere nutzen.
Ich werde und will mich vorerst mit dieser Materie nicht mehr auseinandersetzen bzw. anfreunden...man muss einfach nicht überall dabei sein...sorry.

LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Beta-User

#5
11 August 2020, 15:58:48
 :) Brauchst dich nicht zu entschuldigen.
Dachte nur, es ist ggf. einfacher, als das Rad (teilweise) neu zu erfinden... Aber das hat ja manchmal auch seinen Reiz ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Papa Romeo

#6
11 August 2020, 19:55:39
Zitat von: Beta-User am 11 August 2020, 15:58:48
... einfacher, als das Rad (teilweise) neu zu erfinden... Aber das hat ja manchmal auch seinen Reiz ;D .

..so isses und manchmal passt das Rad halt auch einfach nicht.... ;) ::)
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

sash.sc

#7
26 August 2020, 13:34:22
Nur zum Verständniss für mich.

Du spannst mit deinem Gateway ein seperates WLAN auf,fängst damit die Sensoren ein  und lässt alles über 1. IP Adresse laufen ?

Oder wie darf ich das verstehen ?!?!?!

Gruß
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Papa Romeo

#8
26 August 2020, 19:35:17 Letzte Bearbeitung: 26 August 2020, 19:38:47 von Papa Romeo
...genau so...

Alle Sensoren die sich in der Umgebung des Gateway befinden übergeben unter einer vorher festgelegten Sensor-ID ihre Mess-/Sensordaten an Dieses.

Mein Testsystem hat z.B. die IP xxx.xxx.1.77 und ist mit dieser in FHEM/ Node-RED eingebunden und die Daten können dann dort weiter verarbeitet werden.
Das Gateway erkennt auch welcher Sensor (BME, DHT, MQ usw.) die Daten sendet und weiß somit auch welche Daten zu erwarten sind.

Ich hab das mit MySensors wohl mal gelesen, weiß aber nicht wie es da aussieht bzw. ob es da auch so funktioniert.

Das Ganze war eine Idee für eine Firma, die ihre Maschinen auf einer etwas größeren Fläche verteilt hat, um diese auf einfache Weise nur zu überwachen
(Druck, Drehzahl, Füllstände, Stückzahlen, Betriebsstunden usw.) und bestimmte Faktoren der Sensoren sollte so einfach wie möglich vom Bedienpersonal für den entsprechenden Anwendungsfall geändert (Jumper) werden können.

LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Beta-User

#9
27 August 2020, 10:55:44
OK, langsam wird auch klarer, warum MySensors in diesem Fall nicht deine Wahl war...
Zitat von: Papa Romeo am 26 August 2020, 19:35:17
Ich hab das mit MySensors wohl mal gelesen, weiß aber nicht wie es da aussieht bzw. ob es da auch so funktioniert.
Das funktioniert (fast) genauso: Das GW sammelt alles ein, was an dieses geschickt wird, kann dabei allerdings auch durch "repeater"-Nodes unterstützt werden, so dass ggf. auch weiter entfernte Nodes erreicht werden können (eine Art mesh, das übrigens bei jedem Start einer Node auch "self-healing" ausgelegt ist).
In FHEM passiert auch das meiste automatisch: Man legt im Sketch fest, welche "Typen" an Sonsoren oder Aktoren es gibt und "präsentiert" diese dem GW, FHEM legt dann die passenden Datenstrukturen an (z.B. heißen dann Temperaturwerte "temperature" oder "temperature12"). Hat man Bedarf für was anderes als die Beispiel-Sketche (oder will die kombinieren), besteht die "Schwierigkeit" also im Wesentlichen darin, im Sketch festzulegen, was wann unter welchem Datentyp gesendet werden soll. Das klappt aber mit etwas Übung im Prinzip mit allem, wofür sich eine Arduino-Lib findet (ich habe z.B. auch schon mit digitalen (SPI-) Widerständen gespielt und anderen Temperartur-Sensoren als DS18B20/DHTnn)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Papa Romeo

#10
27 August 2020, 12:19:32
Zitat von: Beta-User am 27 August 2020, 10:55:44
In FHEM passiert auch das meiste automatisch: Man legt im Sketch fest, welche "Typen" an Sonsoren oder Aktoren es gibt und "präsentiert" diese dem GW, FHEM legt dann die passenden Datenstrukturen an (z.B. heißen dann Temperaturwerte "temperature" oder "temperature12"). Hat man Bedarf für was anderes als die Beispiel-Sketche (oder will die kombinieren), besteht die "Schwierigkeit" also im Wesentlichen darin, im Sketch festzulegen, was wann unter welchem Datentyp gesendet werden soll.

..das war natürlich auch ein Grund, warum hier eine andere Lösung her musste. Der "IT-Verantwortliche" sprich "Betriebselektriker" ist nicht sehr bewandert im Bereich
"Hausautomation" bzw. FHEM o.dgl. und meine Zeit ist auch begrenzt um jetzt ständig in die Firma meines Bekannten zu rennen und neue Sensoren einzurichten.

Mein Test-System läuft natürlich u.a. auch auf FHEM, aber dort hätte das keinen Sinn gemacht.

Mit Node-RED funktioniert das aber super. Damit kommt er bisher ganz gut klar und kann ohne Probleme neue Sensoren einbinden und diese auf dem Dashboard darstellen.

---> Sensor wählen --> Frei Sensor-ID vergeben --> Wiederholzeit einstellen --> einschalten ....den Rest macht der GW. In Node-Red noch einen neuen Baustein anlegen und die Daten sind da.

Ich bin eigentlich auch erst durch dieses Projekt auf Node-RED gekommen und muss sagen... so was von simpel...und ich denke ich werde wahrscheinlich, soweit möglich, mit der Zeit eventuell auf dieses System umstellen...zumindest erst einmal tiefer damit befassen.


LG

Papa Romeo

...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

sash.sc

#11
27 August 2020, 12:41:09
Die Sensoren die sich über WLAN auf dein Gateway einklinken haben die ein bestimmtes Datenformat oder mqtt oder wie ist die Firmware aufgebaut? Oder wird dort espeasy oder tasmota oder sonst was benutzt?

Gruß Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Papa Romeo

#12
27 August 2020, 13:10:12
Hallo Sascha,

die Verbindung zwischen den Sensoren und dem GW läuft über die nRF24L01er unter Anwendung der RadioHead Lib. Zwar auch 2,4 GHZ aber nicht "WLan".

Die Verbindung zwischen FHEM, Node-RED o. dgl. und dem Gateway läuft über WLan (ESP12).

Die Daten werden über MQTT, in Einzelwerten und im JSON-Format übertragen.

Die Sketche für GW und Sensoren sind selber geschrieben.


LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

rr725

#13
21 Dezember 2020, 12:24:59
ich rüste mittlerweile all meine bisherigen Temperatur/Luftfeuchtigkeit/Helligkeitssensoren etc. auf Zigbee um.
Kostengünstig, Laufen mit einer Knopfzelle ewig, und mit einer Sonoff (Tasmota) Zigbee Bridge ist bisher alles zu pairen- egal von welchem Hersteller.
Sehr kurze Reaktionszeiten innerh. Node-Red.
Nur zu empfehlen

Papa Romeo

#14
21 Dezember 2020, 12:39:20
...ist bestimmt interessant, wenn man sich mit nochmal einem weiteren System rumschlagen will... ;) ;D :P ::)
...dewegen wollte ich ja "MySensors" nicht....nicht weil es nicht gut ist...steht außer Frage....nein weil man sich wieder in einen neue Materie einarbeiten muss
Wer so etwas gerne tut wird sich dann auch für die Systeme entscheiden...das hier ist nur eine Alternative...schnell...einfach...mit bisher genutztem Wissen zu machen.

LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary
Drucken
Nach oben Seiten1 2 Alle
Benutzer-Aktionen