Möglichkeiten und Hardware teile, für abstandsmessung mit fhem Überwachung

Begonnen von rbs, 31 Oktober 2019, 12:31:25

Vorheriges Thema - Nächstes Thema

rbs

Hallo liebe Gemeinde,
Bisher nutze ich fhem überwiegend mit raspberry und homematic Komponenten für alles möglich im eigenen Haus.
Nun suche ich nach Möglichkeiten in einem anderen Bereich und dachte dabei ebenfalls an die Möglichkeit, das mit fhem zu realisieren.  Daher meine Frage hier:

Ich suche nach geeigneten Hardware Komponenten und ansteuerungsmöglichkeiten um kostengünstig eine größere Anzahl von abstandssensoren anzusteuern und zu überwachen.
Diese Sensoren sollen jeweils im ungefähren Abstand erkennen ob ein Fahrzeug oder anderes Hindernis in ca. 1 bis 2 Meter fester Entfernung vorhanden sind.
Immer wenn vor einem der mehreren Sensoren solch ein Hindernis erkannt wird, möchte ich dieses event mit fhem dann triggern
Ich habe im netz nun Sensoren gefunden, die man an einen raspbery anschließen kann, suche aber bestenfalls eine Möglichkeit mehrere Sensoren mit einen mal auszulesen. So wie z.b. Funk Faktoren wie Steckdosen, Thermometer usw von homematic.

Hat jemand Tipps über mögliche sensoren die man gleichzeitig dann mit fhem abfragen kann ohne für jeden Sensor einen eigenen raspberry zu benutzen?
Vielleicht gibt es vergleichbare Projekte die ich bisher noch nicht gefunden habe?
Fur Tipps danke ich im voraus

MadMax-FHEM

https://forum.fhem.de/index.php/topic,89857.0.html

Oder auf Basis eines EPS8266 dann per WLAN integrieren, dazu braucht der Entfernungsmesser aber eine Steckdose...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Fast dieselbe Hardware, aber andere Implementierung:

https://www.mysensors.org/build/parking

Wenn du viele hast, würde ich aber empfehlen, ein Kabel dazwischenzuschalten statt auf Funk zu setzen, allerdings dann mit CAN-Transceivern; siehe https://www.mysensors.org/build/rs485.

Grundsätzlich: FHEM arbeitet optimalerweise Event-basiert, "auslesen" klingt nach pollen; kann man auch, aber besser ist es, wenn ein Gerät eine Zustandsänderung aktiv (und unverzüglich) meldet.
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

rbs

Danke für Eure Antworten.  Da habe ich erstmal etwas Lesestoff.
Mit audurino habe ich noch keine Erfahrung,  aber die Sensoren schaue ich mir mal an. Ja es sollen möglichst viele gleichzeitig eingesetzt werden können.  10 Minimum, können aber gerne auch in der Theorie bis 200 gerne sein.
Und ja, es soll nur ein event getriggert werden in dem Moment wenn ein Hindernis erkannt wird und wenn es wieder weg wäre.  Alles weitere möchte ich in fhem dann behandeln können

pjakobs

mein Tip ist: such Dir eine der gängigen ESP8266 Plattformen (NodeMCU etc) und pack Tasmota drauf.
Damit kannst Du die üblichen Ultrashall Entfernungsmesser direkt ansprechen und per Regel z.B. beim Unterschreiten einer Entfernung ein Signal per MQTT schicken.
Der Vorteil der fertigen ESP8266 Plattformen ist, dass sie problemlos mit 5V betrieben werden können.

pj

Beta-User

Bis zu 200 Parkplätze, das klingt spannend und nach meinem Empfinden definitiv nicht nach was, was man mit "WLAN-Gedönse" lösen sollte. Fängt damit an, dass die Dinger je nach Programmierung einen AP aufspannen, wenn kein AP beim Start verfügbar ist. Das kann man vielleicht noch lösen (und sollte man auch, wenn man meint, das sei eine gute Idee). Was man aber nicht verhindern kann, ist dass jeder mit etwas krimineller Energie sich einen ESP aus der Dose holen kann und den Speicher (einschließlich WLAN-Koordinaten) auslesen...

Dann lieber ein dummes Kabel, das es erlaubt, die ganze Übertragungstechnik irgendwo unterzubringen, wo man den Kram auch abschließen kann. Und via Kabel lassen sich die Teile auch mit Strom versorgen. Bei der Menge ist aber dringend zu empfehlen, auf "Basteleien" möglichst zu verzichten oder wenigstens entsprechende Platinen zu verwenden.

Btw.: MySensors@RS485 kann afaik auch nur 128 Knoten, also bis zu 127 Parkplätze (theoretisch gingen auch mehr, aber dann muß man mehrere Sensoren (childID's) auf einen Arduino (oder andere MCU) legen, was viel schwerer zu warten sein dürfte). Will heißen: man würde mehrere Stränge benötigen, also mehrere (optimalerweise LAN-) GW's, was aber auch kein Ding ist...
Wenn Funk: Mit LoRa-Sensoren (Rfm96) müßten auch die in solchen Bauwerken üblichen Hindernisse wie Betondecken zu überwinden sein, dann gingen auch (bei 1 Node= 1 Parkplatz) bis zu 253 Parkplätze über ein GW.
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

rbs

Danke danke für die ganzen Tipps. Ich finde das Projekt sehr interessant und will mal sehen was ich da selbst umgesetzt bekomme. In Anbetracht der theoretischen Menge versuche ich gleich von Anfang an den richtigen Weg einzuschlagen. Funk Lösungen waren natürlich echt cool, weil einfacher zu installieren,  aber mit Kabel wird das wie ihr schon sagt eher auf die Menge besser und zuverlässiger sein. Ich werde mir die Hinweise von euch mal alle zu Gemüte führen und dann versuchen einen testveruch mit wenigen Sensoren einmal umzusetzen