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
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?
My Sensors wollt ich eben nicht...aber schick mir mal nen Link.
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...
..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
:) 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 .
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.... ;) ::)
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
...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
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)...
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 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
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
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
...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
;D Ja, die Welt ist groß...
Aber auch das ZigBee-Zeug ist - vor allem, wenn man die tasmota2zigbee verwendet - jedenfalls mAn. nicht soooo easy, wie rr725 behauptet.
Zum einen ist das auf der Auswertungsseite (zumindest in FHEM) "speziell", zum anderen scheinen die ID's sich bei jedem Pair-Vorgang zu ändern, und zu guter Letzt haben die alle - zumindest bisher - auch kein Display...
(Das hätten dann die BT-Vertreter ;) ). Aber das war hier ja auch nicht das Thema...
Zitat von: Beta-User am 21 Dezember 2020, 12:49:46
;D Ja, die Welt ist groß...
Aber auch das ZigBee-Zeug ist - vor allem, wenn man die tasmota2zigbee verwendet - jedenfalls mAn. nicht soooo easy, wie rr725 behauptet.
Zum einen ist das auf der Auswertungsseite (zumindest in FHEM) "speziell", zum anderen scheinen die ID's sich bei jedem Pair-Vorgang zu ändern, und zu guter Letzt haben die alle - zumindest bisher - auch kein Display...
ähm....doch ist es easy.....meine ambitionen auf zigbee umzurüsten. ich hatte bisher ccu, fhem, ha bridge. 433, 868 mhz zeugs,la crosse, etc.
das alles synchron und auf aktuelle stände zu halten ist mir mittlerweile zu lästig geworden- nebst sicherungen von dem zeugs.
also abspecken ist angesagt.
tasmota2zigbee...keine ahnung. hab mich nie mit befasst.
wie gesagt sonoff zigbee bridge mit tasmota. mqtt aktivieren. und in nodered einen broker angelegt. dann steht der auzswertung nichts mehr im weg. und ob sich die ID´s ändern ?! Wieso sollte man die Geräte öfters pairen- und wenn, wer arbeitet mit ID´s ?! Topic heisst das Zauberwort- eine Eigenschaft die sich nie ändert. Man sollte sich schon mit einer Thematik befassen, bevor man es in Negative zieht :-)
Zitat von: rr725 am 21 Dezember 2020, 14:09:11
tasmota2zigbee...keine ahnung. hab mich nie mit befasst.
Ah, ok. Ich habe auch diese Bridge, aber eben mit tasmota geflasht, die Originalfirmware habe ich nie gesehen, wollte nicht das Risiko eingehen, dass das Ding "nach Hause telefoniert"... ::)
Und wenn man zigbee2tasmota verwendet, ändern sich eben die Topics (oder zumindest die interne Gerätereferenz, die auf dem ESP verwaltet wird, was in der Auswertung der Infos auf's selbe rausläuft), falls man nochmal pairt - alle anderen Lösungen, die ich kenne, machen das nicht (zigbee2mqtt und deconz).
(Wir sollten das aber nicht hier vertiefen, kannst ja den Weg über nodered auch mal im ZigBee oder MQTT-Bereich beschreiben, falls es jemand nachbauen will. Aber auch mit zigbee2mqtt oder deconz ist ZigBee-Sensorik stressfrei (Aktorik leider nicht unbedingt, was aber weniger an der jeweiligen Software liegen dürfte!))