Integration Platform basierend auf ESP mit FHEM Modulen

Begonnen von saghonfly, 29 Mai 2020, 19:03:47

Vorheriges Thema - Nächstes Thema

saghonfly

Hallo,


schaut euch bitte mal dieses Github Projekt an welches es sich zum Ziel gemacht hat, möglichst günstig und einfach eine Komplettlösung für die Integration von verschiedensten Sensoren (später auch Aktoren) zu erstellen.
https://github.com/saghonfly/shrdzm/wiki


Das ganze steckt noch in den Kinderschuhen, wird aber stetig erweitert werden.

Mittlerweile gibt es dazu auch 2 Module für FHEM (SHRDZM, SHRDZMDevice).

Würde mich freuen wenn es ein paar Freiwillige gibt die sich das Projekt mal ansehen und entsprechend Rückmeldung geben um es letztendlich allgemein brauchbar zu machen.

Gruss
Saghonfly



Update: 23.06.2020
Die Einschränkung auf Sensoren wurde aus dem Konzept raus genommen. Vom Prinzip geht es nun generell um eine Integrations Plattform mit dem Fokus auf einer Ende-zu-Ende Lösung basierend auf ESP's, ESPNow und flexibler Integrations-Infrastruktur.



Update: 31.08.2020 (Version 0.3.0)
Implementierung Integration Style III (Mobile Integration) und SDS011 Beispiel hinzugefügt.



Update: 06.11.2020 (Version 0.3.1)
SmartMeter Siemens IM350 Device hinzugefügt.https://github.com/saghonfly/shrdzm/wiki/IM350

M.Schulze

Hallo,

ist ein interessantes Projekt, aber ...

Ich arbeite nebenbei schon länger an einer eigenen Platform für Sensoren und Geräte.

Erste Generation ist schon im Einsatz. Ist  aber fix compiliert. Modular nur auf Quell-Code Ebene. ESP8266 ist damit wegen begrenzter Hardware abgehakt. Basiert auch auf dem alten nonos-SDK. Leistungsfähig aber ohne Zukunft.

Zweite Generation (alpha) ist im Kern so aufgebaut wie ein WEB-Server, ja wie FHEM, Modular mit Kommandos und Modulen, statt fhem.cfg eine makerfile.cfg, standardisierte Callbacks im Modul, auch im Select-Loop, jedenfalls soweit meine C-Kenntnisse dies zulassen und soweit mir das sinnvoll erscheint.
Bei RegEx-C-Umsetzung und bei Implementierung von Multithreading ist da allerdings aktuell oft Schluss.

Meine Meinung:
Ich würde nicht zu viel Zeit investieren in solch ein auf Arduino Framework basierendes Projekt. Nicht zukunftssicher. Nicht für alle SoC (sofort) einsetzbar. Haben auch schon andere probiert (auch hier aus dem Forum, glaube ich)
Eher etwas mehr Entwicklungszeit einkalkulieren und es gleich richtig machen, einen leisungsfähigeren SoC (ESP-32), dann gleich mit ESP-IDF entwickeln. Dann sollte es zukünftig auch auf allen Linux SoCs laufen, wenn die Projekte (Module) doch größer werden.


MfG
Muss ich hier das Licht aus machen?

MadMax-FHEM

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)

PeMue

Hallo,

Zitat von: saghonfly am 29 Mai 2020, 19:03:47
Würde mich freuen wenn es ein paar Freiwillige gibt die sich das Projekt mal ansehen und entsprechend Rückmeldung geben um es letztendlich allgemein brauchbar zu machen.
den Ansatz mit den drei verschiedenen Integrationsmöglichkeiten finde ich interessant.
Allerdings unterscheidet sich die Variante I von der II nur durch den zwischengeschalteten MQTT Broker bzw. in IIa ist noch ein 433 MHz Empfänger mit dabei.
Was mich interessiert ist, ob die Möglichkeit des Batteriebetriebs besteht. Die ESP8266 sind m.E. für Batteriebetrieb nicht wirklich optimal.

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

saghonfly

#4
Hallo,

ZitatAllerdings unterscheidet sich die Variante I von der II nur durch den zwischengeschalteten MQTT Broker bzw. in IIa ist noch ein 433 MHz Empfänger mit dabei.
Ja, da hast du völlig recht.
Den Ansatz es modular aufzubauen ist Teil des Konzeptes.
Mit dem Gateway soll nur die Verbindung zu den Devices abstrahiert werden.
Ob dieses Gateway direkt (also seriell), über einen MQTT Wrapper oder/und über das noch geplante GSM Modul eingebunden werden soll ist dann von den Rahmenbedingungen des Einsatzes abhängig.
Befinden sich die Devices in unmittelbarer Nähe vom Server wo auch zB.: FHEM läuft, bietet sich die einfache serielle Variante an.
Im Falle das sich die Devices zB.: an einem ganz anderen Ort befinden (zum Beispiel in der Zweitwohnung), macht es Sinn diese über die MQTT Variante anzubinden.
Für eine mobile Variante ist die GSM Variante angedacht (Integration Style III). Dieses kann man dann zB.: im Auto mitführen und die Devices wären damit auch mobil.

Zu IIa, ja....ist eigentlich nur ein Zusatz der nur deshalb dazugekommen ist weil ich mir ein zusätzliches Gateway sparen wollte um 433MHz Zwischensteckdosen bzw. Funkfernsteuerungen einzubinden.
Passt zugegebenermaßen nicht ganz ins Konzept und da bin ich mir selbst nicht sicher ob das Zukunft hat...

ZitatWas mich interessiert ist, ob die Möglichkeit des Batteriebetriebs besteht. Die ESP8266 sind m.E. für Batteriebetrieb nicht wirklich optimal.
Die Devices für die Sensoren sind prinzipiell für Batteriebetrieb gedacht, das Gateway eher nicht. Ich denke aber, das hast du damit nicht gemeint?
Leider ist es auch richtig, das die ESP's generell nicht sehr sparsam sind.
Mit dem Ansatz die ESP's so lange wie möglich im DeepSleep zu halten (stimmt, auch dabei sind sie nicht sooo sparsam) und nur für wenige Millisekunden hochzufahren um die Messung zu machen bzw. über ESPNow ohne allzu großen Overhead die Daten abzuschicken, hält sich der Stromverbrauch in Grenzen.
Versuche haben gezeigt, das ein ESP-12 mit einem DHT-22, einem Intervall von 2 Minuten und einem 18650-Akku mit 2.4 Ah, ca. drei bis vier Monate durchhält.
Hier sehe ich allerdings noch viel potential für Verbesserungen.

Die Gründe warum derzeit ESP's als Hardware und ESPNow als Transport verwendet wird ist dem derzeit unschlagbaren Preis eines 'Komplettsets' geschuldet bzw. dem einfachen Aufbaus dessen.


Gruss
Erich


sash.sc

Sprich das ganze baut auf espnow auf, und ist nicht mehr kompatibel zum normalen WLAN. Man braucht auf jeden Fall ein eigenes Gateway.
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

saghonfly

Hallo,

ZitatSprich das ganze baut auf espnow auf, und ist nicht mehr kompatibel zum normalen WLAN. Man braucht auf jeden Fall ein eigenes Gateway.

Ja, die Kommunikation zwischen den Sensoren (bzw. der Devices welche die Sensoren auslesen) und dem Gateway ist ESPNow.
Die Einbindung des Gateways ist dann flexibel.

Gruss
Erich

balli1187

Hab's nur kurz überflogen aber sehe jetzt keinen Vorteil gegenüber Tasmota oder ESPeasy (auch wenn ich letzteres nie genutzt hab).

Was kann diese Firmware, was die genannten nicht können?
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

Papaloewe


Gisbert

Hallo Saghonfly,

ich hatte deinen Thread erst gesehen, nachdem ich Interesse für ESP-Now bekundet habe.
Anscheinend bist du ein Experte in diesen und anderen Dingen und kannst mir gelegentlich unter die Arme greifen.

Im Moment kann ich das Projekt aus Zeitgründen noch nicht starten, würde mich aber bei Zeiten melden, ich hoffe, das geht in Ordnung.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

PeMue

Zitat von: Papaloewe am 15 Juni 2020, 21:25:08
BATTERIEBETRIEB!
Ist ESP8266 und Batteriebetrieb nicht ein Widerspruch in sich?

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

MadMax-FHEM

Zitat von: PeMue am 16 Juni 2020, 07:55:09
Ist ESP8266 und Batteriebetrieb nicht ein Widerspruch in sich?

Gruß Peter

Wenn man diesem Video glauben darf, dann nicht generell: https://www.youtube.com/watch?v=6NsBN42B80Q  ;)

Allerdings ist es dann halt eigentlich kein ESP/WLAN mehr, sondern halt eine "eigene lowpower Kommunikation"...
...also wieder Gateway...

Dann ist der Unterschied zu z.B. mySensors nicht mehr wirklich gegeben bzw. wäre mir dann (aktuell) durch die bestehende Integration von z.B. mySensors das "lieber"...

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)

balli1187

Zitat von: Papaloewe am 15 Juni 2020, 21:25:08
BATTERIEBETRIEB!
Tasmota unterstützt mittlerweile den deepsleep des ESP.
https://tasmota.github.io/docs/DeepSleep/

Damit sill Batteriebetrieb im allgemeinen möglich sein.
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

MadMax-FHEM

Zitat von: balli1187 am 16 Juni 2020, 08:52:04
Tasmota unterstützt mittlerweile den deepsleep des ESP.
https://tasmota.github.io/docs/DeepSleep/

Damit sill Batteriebetrieb im allgemeinen möglich sein.

Ja aber dennoch mit sehr überschaubarer Laufzeit, weil eben zur Kommunikation immer noch: WLAN, Verbidung mit AP etc. nötig sind was eben lange/länger dauert und mehr Strom braucht als das "simple" ESP-Now...

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

Na ja, wenn WLAN im Spiel ist, ist das ganze eben energieintensiv, von daher dürfte dieses ESPNow Vorteile gg. der Tasmota-Lösung haben.

Ich sehe einen weiteren Vorteil der ESPNow-Lösung: das GW kann auch seriell angeschlossen werden, man braucht also keine "klassische" (W)-LAN-Infrastruktur.

Trotzdem wird auch ESPNow vermutlich nie die Batterie-Performance haben, die man mit MySensors oder AskSin++ erreichen kann - und mit der NRF52-Plattform gäbe es für MySensors auch eine "lötfreie" bzw. "lötreduzierte" Variante...

Aber sei's drum, es könnte eine Alternative für "Löteinsteiger" sein, von daher: Willkommen im Club!

Zitat von: saghonfly am 29 Mai 2020, 19:03:47
Mittlerweile gibt es dazu auch 2 Module für FHEM (SHRDZM, SHRDZMDevice).
Ein separates GW-Modul wird man dafür wohl brauchen, aber wir können uns gerne auch austauschen, ob man MYSENSORS_DEVICE ggf. "aufbohren" kann, um diese Art Client zu bedienen. Tendenziell würde ich heute aber dazu raten, schlicht MQTT2_DEVICE als Client zu nutzen, das kann das Meiste von alleine, wenn man die übergebenen Daten entsprechend aufbereitet.
Falls da Gesprächsbedarf besteht: Einfach melden.
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

saghonfly

#15
Hallo,

danke erstmal für diese ersten Anregungen, Fragen und auch validen Bedenken.
Ich versuch im Folgenden auf diese einzugehen.
Bitte verzeiht wenn ich was übersehen haben sollte bzw. trotzdem Fragen/Bedenken offen bleiben sollten.

ZitatBATTERIEBETRIEB!
Tatsächlich steht das ganz oben auf der Motivationsliste.
Dies ist auch einer der Gründe auf ESPNow zu setzen. Mit diesem Ansatz ist es möglich, innerhalb von ein paar hundert Millisekunden die Messung sowie den Datentransfer abzuarbeiten.
Den Rest der Zeit legt sich das Device dann schlafen.
Bei den ESP's ist das 2.4GHz Funkmodul auch schon eingebaut was wiederum zum ESP geführt haben.
Das Argument das ESP's an sich nicht sehr Stromsparend sind, ist valide (das gilt auch für den DeepSleep Mode). Ein paar Monate hält heute ein Sensor-Device durch (mit einem billigen 2.4Ah 18650-Akku), angedachte Optimierungen bei der Up-Time sollten das aber noch verbessern.

Zitatich hatte deinen Thread erst gesehen, nachdem ich Interesse für ESP-Now bekundet habe.
Anscheinend bist du ein Experte in diesen und anderen Dingen und kannst mir gelegentlich unter die Arme greifen.

Im Moment kann ich das Projekt aus Zeitgründen noch nicht starten, würde mich aber bei Zeiten melden, ich hoffe, das geht in Ordnung.
Als Experte würde ich mich nicht sehen, versuche es aber besser zu verstehen und bestmöglich zu benutzen.  :)
Selbstverständlich gebe ich mein Wissen diesbezüglich gerne weiter, bin aber sehr daran interessiert wenn sich jemand findet der auch Tipps für die optimale Benutzung geben kann.

ZitatIch sehe einen weiteren Vorteil der ESPNow-Lösung: das GW kann auch seriell angeschlossen werden, man braucht also keine "klassische" (W)-LAN-Infrastruktur.
Ja, die Gateways machen die Abstraktion zur Infrastruktur. Die Sensor-Devices selbst sind von dieser unabhängig.
Die Sensor-Devices werden letztendlich nur mit dem gewünschten Gateway gepaart und brauchen diesbezüglich auch keine Konfiguration.

ZitatEin separates GW-Modul wird man dafür wohl brauchen, aber wir können uns gerne auch austauschen, ob man MYSENSORS_DEVICE ggf. "aufbohren" kann, um diese Art Client zu bedienen.
Das mit den eigenen FHEM Modulen ist [bisher zumindest] Absicht.
Ein Ziel des Projektes war es auch bestmöglich eine End-zu-End Lösung anzubieten.
Mit den FHEM Modulen soll die Einbindung in die gewählte Hausautomatisierungslösung auch bestmöglich von der Infrasturkturentscheidung getrennt sein.
Ich würde diese derzeit eher als Komfortfunktion sehen. Eine 'native' Einbindung direkt über seriell oder MQTT ist auch möglich aber dann halt nicht in einem Modul gekapselt.
Inwieweit man das MYSENSORS_DEVICE aufbohren könnte, kann ich nicht beurteilen, finde die Idee aber interessant.

Beste Grüße
Erich


Beta-User

Zitat von: saghonfly am 16 Juni 2020, 15:42:07
Das mit den eigenen FHEM Modulen ist [bisher zumindest] Absicht.
Ein Ziel des Projektes war es auch bestmöglich eine End-zu-End Lösung anzubieten.
Mit den FHEM Modulen soll die Einbindung in die gewählte Hausautomatisierungslösung auch bestmöglich von der Infrasturkturentscheidung getrennt sein.
Ich würde diese derzeit eher als Komfortfunktion sehen. Eine 'native' Einbindung direkt über seriell oder MQTT ist auch möglich aber dann halt nicht in einem Modul gekapselt.
Inwieweit man das MYSENSORS_DEVICE aufbohren könnte, kann ich nicht beurteilen, finde die Idee aber interessant.
Zwischenzeitlich hatte ich einen kurzen Blick auf das Wiki und die Erläuterung zu den Modulen. Von daher scheint da einiges an spezifischer Funktionalität drin zu sein, die es eher erschwert, da was gemeinsames zu machen.
Spontan war mein Eindruck, dass es (zwischenzeitlich) nicht besonders glücklich ist, das von externen (MQTT-) libs abhängig zu machen. Eine Lösung, die eher in Richtung MQTT2-Module ginge, wäre vermutlich aus Usersicht einfacher, aber dazu müßtest du vermutlich den Code nochmal entsprechend überarbeiten.

Vermutlich wäre MQTT2_DEVICE heute schon flexibel genug, auch die speziellen setter abzubilden, allerdings wäre das dann eher eine Art offenes Konstrukt, was eher nicht zur allg. Architektur paßt.
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

saghonfly

#17
Status-Update
  • Mittlerweile ist Integration Style III (Mobile Integration) implementiert.
    Hierfür wird ein SIM800 GSM-Modul direkt mit dem SHRDZMGateway verbunden.
    Damit ist es möglich, die SHRDZMDevices mobil zu verwenden (zB.: im Wohnmobil).
  • Im Prinzip werden nun auch Aktore unterstützt. Dies ist aber noch in einem sehr rudimentären Zustand und wenn es jemanden jetzt schon interessiert dann bitte melden da die Dokumentation noch nicht auf neuestem Stand ist.
  • Ein recht umfangreiches Beispiel für die Verwendung des SDS011 (Feinstaubsensor) mit optionalem Upload zu OpenSenseMap ist hinzugekommen. Die Schaltung ist so aufgebaut das diese Solarbetrieben läuft und damit eine permanente Stromversorgung nicht notwendig ist.



Nähere Information gibt es auf https://github.com/saghonfly/shrdzm/wiki

Billy

#18
Zitat von: saghonfly am 31 August 2020, 19:27:21
Status-Update
  • Mittlerweile ist Integration Style III (Mobile Integration) implementiert.
    Hierfür wird ein SIM800 GSM-Modul direkt mit dem SHRDZMGateway verbunden.
    Damit ist es möglich, die SHRDZMDevices mobil zu verwenden (zB.: im Wohnmobil).
  • Im Prinzip werden nun auch Aktore unterstützt. Dies ist aber noch in einem sehr rudimentären Zustand und wenn es jemanden jetzt schon interessiert dann bitte melden da die Dokumentation noch nicht auf neuestem Stand ist.

Die Anwendung Integration Style III mit SIM800 GSM-Modul finde ich äußerst interessant.
Ist es möglich den Sonoff Basic als Aktor einzubinden, indem man die SHRDZMDevice.ino.generic.bin auf den Sonoff flasht?

Um zum Beispiel den Kühlschrank im Gartenhaus/Ferienhaus einschalten zu können?

Vielen Dank für deine Mühe ist ein tolles Projekt.
Gruss Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

saghonfly

ZitatDie Anwendung Integration Style III mit SIM800 GSM-Modul finde ich äußerst interessant.
Ist es möglich den Sonoff Basic als Aktor einzubinden, indem man die SHRDZMDevice.ino.generic.bin auf den Sonoff flasht?

Um zum Beispiel den Kühlschrank im Gartenhaus/Ferienhaus einschalten zu können?

Vielen Dank für deine Mühe ist ein tolles Projekt.
Gruss Billy

Hallo Billy,

einen Sonoff mit SHRDZM flashen zu können ist vorerst eigentlich nicht angedacht. Dazu gibt es auch viel bessere Lösungen wie Tasmota oder ESPURNA.
Den Anwendungsfall ein Gerät irgendwo außerhalb des lokalen Netzwerks zu schalten, würde ich eher über einen handelsüblichen Wifi Router mit Sim Karte und geflashen Tasmota machen.
Über z.B.: MQTT (natürlich secure) mache ich das bei mir.

Gruss

saghonfly

#20
Kleines Update zum SHRDZM Projekt speziell für User aus Österreich...

Mittlerweile sind auch Smartmeter als eigener Sensortype im SHRDZM implementiert.
Besonders in Österreich sind die Smartmeter mit verschiedenen Schnittstellen als auch unterschiedlichen Protokollen im Einsatz.

Die Integration versucht all diese verschiedenen Smartmeter sowie Protokolle zu unterstützen.

Da jeder Typ und auch Stromnetzbetreiber ausgetestet werden muss, findet Ihr anbei eine Liste des aktuellen Status.

Wenn sich jemand aus den noch nicht Grün oder Schwarz gekennzeichneten Gebieten/Smartmetern dafür interessiert das mal mit einem fertigen Modul auszutesten, dann bitte melden.



TheTrumpeter

Hab' mir das vor einiger Zeit mal angesehen und auf die "Merkliste" gesetzt. Wollte es nun ausprobieren, da wg. SmartMeter für mich relevant. Leider scheint das Projekt von GitHub verschwunden zu sein?
Gibt es eine Möglichkeit an die Dateien zu kommen?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Papaloewe

Das Thema Smartmeter habe ich mit Tasmota sehr elegant lösen können.
Schau mal hier: https://tasmota.github.io/docs/Smart-Meter-Interface/

Gisbert

Zitat von: Papaloewe am 14 März 2022, 13:48:27
Das Thema Smartmeter habe ich mit Tasmota sehr elegant lösen können.
Schau mal hier: https://tasmota.github.io/docs/Smart-Meter-Interface/

Hallo Papaloewe (bin mir nicht sicher, ob ich deinen richtigen Namen nennen darf),

das scheint aber schwerer Stoff zu sein; mir wird schwindelig beim Durchscrollen der Seite. Meinst du, dass du mir bei der Einrichtung, am besten persönlich, helfen kannst?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

saghonfly

Zitat von: TheTrumpeter am 14 März 2022, 13:09:03
Hab' mir das vor einiger Zeit mal angesehen und auf die "Merkliste" gesetzt. Wollte es nun ausprobieren, da wg. SmartMeter für mich relevant. Leider scheint das Projekt von GitHub verschwunden zu sein?
Gibt es eine Möglichkeit an die Dateien zu kommen?

Hallo,

das Projekt wird umgezogen bzw. neu aufgezogen.

Wenn du an den Daten der Smartmeter Kundenschnittstelle interessiert bist, kannst du dir eine meiner überschüssigen Platinen ansehen.
Die sind soweit fertig zusammengebaut und unterstützen MBus, P1-seriell sowie Infrarot-Schnittstelle.
Eine einzelne Platine zu fertigen war nicht sinnvoll daher habe ich jetzt ein paar übrig die ich über willhaben.at abgebe.

TheTrumpeter

Zitat von: saghonfly am 15 März 2022, 10:12:44
Die sind soweit fertig zusammengebaut und unterstützen MBus, P1-seriell sowie Infrarot-Schnittstelle.
Habe Netz NÖ, der neue Zähler kommt erst in 2-3 Monaten, aber lt. Vorabinformationen müsste es ein Sagemcom sein, der lt. Deinen Infos von früher unterstützt wird.

Zitat von: saghonfly am 15 März 2022, 10:12:44
Eine einzelne Platine zu fertigen war nicht sinnvoll daher habe ich jetzt ein paar übrig die ich über willhaben.at abgebe.
Hab' grad nix gefunden, hast Du einen Link bzw. die Artikelnummer für mich?

Wie komm' ich an die SW? Oder ist die Platine inkl. µC?
(Hatte eigentlich vor einen "M-Bus-SlaveClick" von MikroElectronica zu kaufen und mit einem vorhandenen Wemos D1 Mini Pro zu verbinden, der dann nach der Zählerumstellung "frei wird".)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Zitat von: TheTrumpeter am 17 März 2022, 10:39:44
Habe Netz NÖ, der neue Zähler kommt erst in 2-3 Monaten, aber lt. Vorabinformationen müsste es ein Sagemcom sein, der lt. Deinen Infos von früher unterstützt wird.
Hab' grad nix gefunden, hast Du einen Link bzw. die Artikelnummer für mich?

Sagemcom in NÖ (bzw. alle in NÖ von der EVN verbauten Smartmetern) hat MBus Schnittstelle. ja, diese Smartmeter werden unterstützt.

Zitat von: TheTrumpeter am 17 März 2022, 10:39:44
Wie komm' ich an die SW? Oder ist die Platine inkl. µC?
(Hatte eigentlich vor einen "M-Bus-SlaveClick" von MikroElectronica zu kaufen und mit einem vorhandenen Wemos D1 Mini Pro zu verbinden, der dann nach der Zählerumstellung "frei wird".)

Die Platine ist natürlich voll bestückt und der ESP (bzw. die Firmware am ESP) der drauf verbaut ist, übernimmt die Entschlüsselung und Extrachieren der vom Smartmeter gelieferten Werte.
Dadurch das ein ESP drauf verbaut ist, geht dieser dann auch direkt ins eigene WLAN wo er diese extrachierten Daten dann als MQTT Message bzw. als REST Service zur Verfügung stellt.
Ein zusätzlicher Raspi oder so ist nicht notwendig da der ESP ja die Firmware zum Enschlüsseln bereits implementiert hat.

Um die Platine bei willhaben.at zu finden, am besten unter "SmartMeter Kundenschnittstelle" suchen...Ich habe aber nur noch ein paar Platinen da wie gesagt eine 'Überproduktion' die ich auf diesem Weg loswerden möchte...

TheTrumpeter

Zitat von: saghonfly am 17 März 2022, 13:28:08
Um die Platine bei willhaben.at zu finden, am besten unter "SmartMeter Kundenschnittstelle" suchen...Ich habe aber nur noch ein paar Platinen da wie gesagt eine 'Überproduktion' die ich auf diesem Weg loswerden möchte...
Hab's gefunden... was hastt Du da für einen ESP drauf bzw. anders gefragt ist da eine Schnittstelle für eine externe Antenne drauf? Da wo das Modul läuft, hat es mit der eingebauten Antenne nicht ausreichend Empfang.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Im Normalfall mach ich einen ESP-12S drauf.
Alternativ einen ESP-07 mit externer Antenne wäre aber auch möglich.

TheTrumpeter

#29
Also mit einem ESP-07 würd' ich so ein Ding nehmen, Antenne brauche ich nicht, habe ich selbst ausreichend.

Nachtrag: Gehäuse brauch' ich eigentlich auch nicht, weil ich sowieso noch einen kleinen AC-DC-Wandler ins Gehäuse packen will.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Zitat von: TheTrumpeter am 18 März 2022, 09:27:37
Also mit einem ESP-07 würd' ich so ein Ding nehmen, Antenne brauche ich nicht, habe ich selbst ausreichend.

Nachtrag: Gehäuse brauch' ich eigentlich auch nicht, weil ich sowieso noch einen kleinen AC-DC-Wandler ins Gehäuse packen will.

Das Platinen Layout würde dann halt so aussehen.
Anstelle einen ESP-12 musst du dir halt einen ESP-07 vorstellen.

Ob das Layout für dein neues Gehäuse mit AC/DC Wandler passt musst du dann wissen...

TheTrumpeter

Zitat von: saghonfly am 18 März 2022, 11:04:34
Ob das Layout für dein neues Gehäuse mit AC/DC Wandler passt musst du dann wissen...
Mein aktuelles Modul mit IR-Lesekopf habe ich einfach in eine kleine Aufputz-Verteilerdose gepackt (https://www.hornbach.at/shop/Feuchtraum-Kabelabzweigkasten-H-75-x-B-45-x-T-36-mm-grau/3893700/artikel.html). Da ist das IR-Modul drin, ein Wemos D1 mini Pro mit externer Antenne und eben der AC/DC-Wandler.
Wenn Dein Modul da auch reinpasst, verwende ich es gleich weiter, weil schon die Bohrung für die externe Antenne vorhanden ist und der AC/DC-Wandler ordentlich reingeklebt ist. Ansonsten besorg' ich mir eben eine größere Dose. Das muss im Schaltschrank ja weder einen Schönheitspreis gewinnen noch möglichst klein sein.

Soll ich Dich bei Willhaben zwecks der weiteren Abwicklung kontaktieren?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Zitat von: TheTrumpeter am 18 März 2022, 11:14:48
Mein aktuelles Modul mit IR-Lesekopf habe ich einfach in eine kleine Aufputz-Verteilerdose gepackt (https://www.hornbach.at/shop/Feuchtraum-Kabelabzweigkasten-H-75-x-B-45-x-T-36-mm-grau/3893700/artikel.html). Da ist das IR-Modul drin, ein Wemos D1 mini Pro mit externer Antenne und eben der AC/DC-Wandler.
Wenn Dein Modul da auch reinpasst, verwende ich es gleich weiter, weil schon die Bohrung für die externe Antenne vorhanden ist und der AC/DC-Wandler ordentlich reingeklebt ist. Ansonsten besorg' ich mir eben eine größere Dose. Das muss im Schaltschrank ja weder einen Schönheitspreis gewinnen noch möglichst klein sein.

Soll ich Dich bei Willhaben zwecks der weiteren Abwicklung kontaktieren?

Hallo,

ja, am Besten du schreibst mich über willhaben an.

Gruss
saghonfly

TheTrumpeter

#33
Zitat von: saghonfly am 18 März 2022, 15:14:51
Hallo,

ja, am Besten du schreibst mich über willhaben an.

Gruss
saghonfly
So, seit etwas über 1 Woche ist der Smartmeter verbaut. Habe dann auch gleich das Lesegerät angesteckt und siehe da, es sind sofort Daten gekommen, die vermutlich wegen dem falschen Schlüsselcode "kryptisch" bzw. falsch ausgeschaut haben. Aber immerhin waren Daten da.

Gerade habe ich den richtigen Schlüssel erhalten und eingetragen. Seitdem kommen keine Daten mehr an, Reboot habe ich auch gemacht.
(Den Schlüssel habe ich aus dem PDF vom Netzbetreiber einfach reinkopiert, Anfang und Ende stimmt und auch die Zählernummer stimmt mit der im Text vom Netzbetreiber überein.)

Ansonsten habe ich an den Einstellungen nichts geändert. Was mache ich falsch???


EDIT: Zumindest kommt jetzt mal:
Zitat(0)lasterror=Invalid data
(1)uptime=0000:00:09:34

Das habe ich mit dem "falschen Schlüssel" auch schon vereinzelt gesehen, vielleicht wird's ja noch?



NOCHMAL EDIT:
Ok, es komme Werte, aber die schauen um nix besser aus als mit dem falschen Schlüssel... schaut immer noch "komisch" aus.
Und was ich auch nicht verstehe (das war schon mit dem falschen Schlüssel so), warum gibt es machmal Werte mit den "Nummern" und manchmal "Klartext"?
Zeitweise kommt:
1.7.0 847676431 2022-06-17 13:50:52
1.8.0 4037382110 2022-06-17 13:50:52
2.7.0 3227230352 2022-06-17 13:50:52
2.8.0 353220025 2022-06-17 13:50:52
31.7.0 40374 2022-06-17 13:50:52
32.7.0 32957 2022-06-17 13:50:52
51.7.0 31376 2022-06-17 13:50:52
52.7.0 461 2022-06-17 13:50:52
71.7.0 28430 2022-06-17 13:50:52
72.7.0 51208 2022-06-17 13:50:52

Und zeitweise dann:
counter_power_usage_in 2863029653 2022-06-17 13:56:23
counter_power_usage_out 1724724349 2022-06-17 13:56:23
counter_reading_p_in 2080494736 2022-06-17 13:56:23
counter_reading_p_out 2581819405 2022-06-17 13:56:23
counter_reading_q_in 3191748529 2022-06-17 13:56:23
counter_reading_q_out 3382683497 2022-06-17 13:56:23


Grad am Zähler geschaut:
1.8.0 ist 120,11 kWh
2.8.0 ist 7,21 kWh

Muss ich die Werte noch irgendwie "umrechnen" wie in https://www.netz-noe.at/Download-(1)/Smart-Meter/218_9_SmartMeter_Kundenschnittstelle_lektoriert_14.aspx auf Seite 8 angedeutet? Ich hätte erwartet, dass das alles automatisch passiert  :-[

Und irgendwie ändern sich die Werte sehr selten, hätte erwartet, dass zumindest einzelne Werte alle 5 Sekunden "zappeln" müssten, stattdessen "bewegt" sich frühestens nach 5 Minuten was? Grad hat sich die Uptime beispielsweise nach 7min aktualisiert, die übrigen Werte sind unverändert.
(Ich hole die Daten mittels HTTPMOD über die REST-Adresse alle 5 Sekunden ab, auch wenn ich die Seite im Browser aufrufe, sehe ich immer dieselben Daten.)

Zu Hilfe :-)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Hi,

mach mal zur Sicherheit ein OTA update auf die aktuelle Entwicklungsversion.

http://shrdzm-dev.pintarweb.net/upgrade.php

Wenn du danach auch noch bei den Settings beim Parameter 'sendRawData' ein YES reinschreibst, sollten die Rohdaten so wie sie vom Smartmeter kommen, auch angezeigt werden.
Diese sollten wir uns dann mal ansehen...

Gruss
saghonfly

TheTrumpeter

#35
Zitat von: saghonfly am 17 Juni 2022, 14:19:40
mach mal zur Sicherheit ein OTA update auf die aktuelle Entwicklungsversion.
Oh, plötzlich wird die Uptime alle 5 Sekunden aktualisiert...

Als "lasterror" kommt:
(0)lasterror=No supported SmartMeter Type identified - No end Byte found
(1)uptime=0000:00:04:45
(2)data=FF680101C053FF000146DB085340065905EC1F3181F800000011003C38B884E357F60C032CEEBCD2B3ADFE2F15C6F35C2F4C3C5D7514AD3031511E7B14989A8A0E19FDC627425116B3240D51E3C8206E0F66302DD14A30AB7B206115F4C7B30064343A92FBDE7D1FF0B2CA0940A1F7F879CA2B3C1F30DC57EA4031B802FED811F63F623D1D2C1EB0945A44589D58EED8272FC42673F4DCDF7F2DC46CC3172A055D8B9927


Und manchmal:
(0)lasterror=checksum error
(1)data=6800016853FF000167DB085341471000EC1F3181F8200000F16318E7D422D0D1F3626C0CD8E5C4C07C9302EC5EB243D10732A29800A3A84FA65FFC8EBD40EBDA547969D647C055B6830190CA7126C5025CF05E0018935AACE161570A5E6355B2FAABBAC95369ABDA8E861CA9376029EB1617CA56949348A56DF6302EAFEF3749709BA140FA5A1F18AE55ED1303CAC2990C70C5BF405F46ED71BF7310250612C11F48B7E1F9148F046DC1405C5E5EEF76EC9FA8285673332C8685B535602C6D4340B5F974147B4303DBF54F798660003E29D8D5325A03004D5853886FD1639D18E0E16E200D0F7CC09D16360008C14D1820D7715202A4E2DA8552CF7EC840ED69C28D5EB516D00D0D6802FF110167CCDE5C6E109528ED0316FF


Werte kommen noch keine, aber vorhin hat's auch einige Minuten gedauert, bis was gekommen ist, vielleicht dauert das?


PS: Der Smartmeter wird im Kundenportal von NetzNÖ immer noch als "nicht kommunikativ" angezeigt, aber die P1-Schnittstelle sollte unabhängig davon funktionieren, oder?


EDIT: Bisher keine Änderung, nur Uptime und Fehlermeldungen.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

Hab' mir mal die Daten ein bisschen anschaut, bei einem "Consistency Error" hatte ich beispielsweise folgenden Datenstring:

6801016853FF000167DB088241475905FC1F3181F82000002247FF98E52D0E69D75D4DE865924953686422C7278CC58269D1EA3320D8145BD2DDA6C98AA74961FDD60290E0AA59205D996C2B4D158DB970A42B54C09C4ABAF868FEB0E7E4B05792BD687507130EDAD817FCB9163FB071A0260B101982047041E2399817B73AEE4A712D0BC6B96D1AE8935AD47302760A02B5F33543EE002D97067F8278EE66DD2C4F717AB15E4238AD6B66C47696101CC45455F830B626B94B5006B8FD8063DDE6CBD9558EB60030AF6C88D41FD6E9454BFCE92064A7B3F242D38A5A4584FEB812284EF43DCA76B73864C679F28280A0A4D5E4020CDA20CFD3BE0260F12AD0E4543FD040911668080D6853FF11016757064B2D4F8A53A2BF16

Wenn ich mir das so anschau' und mit dem vergleiche wie es eigentlich aussehen sollte, scheint es so als ob mein Smartmeter etwas "undeutlich spricht":
Die ersten 4 Byte sollten sein:
68FAFA68
Bei mir kommt aber:
68010168

Das darauffolgende 53FF000167DB08 ist wieder da, demnach müsste "8241475905FC1F31" der SystemTitle sein, gefolgt vom "81F820", sodass "00002247" der FrameCounter wäre.

Danach sollten eigentlich 508 Byte an Daten folgen, dann 2 Byte Checksumme und die letzten 2 Byte sollten 16 sein.
Im Frame oben sind aber nur noch 506 Byte Daten, wenn dann 2 Checksumme sind, die 16 am Ende stimmen sogar.

Habe mir einen 2. Frame bei "Consistency Error" angeschaut, da ist es sehr ähnlich, am Beginn ist wieder "68010168" und am Ende auch "16", zwischendrin finden sich auch die "53FF000167DB08" sowie "81F820", aber die Daten sind wieder nicht vollständig (nur 502 Byte).
6801016853FF000167DB085341475905EC1F2081F8200000E5FA8E766253809E8A76C01C88511982E7086E18DD1D1E65F0881BA2DE10BD0A5F3909FB3AF1498812C14CDF5B86BBE8BC2260DC2906797F973D6A70CEF3F3E6CBF1FCF814E9FC788E9BC10E1DB2E157C3B32CBA0E78F66A6B9724896AA14EF1E900AA45FABC1269A6A38AEECD8C004E727DE2983AAF5ADF90436B0EA871E5F75637E71FA84550C6009E7D5B623A0BB6B00027578800C006847E73068B091B83CFB8A3ED90D3192476E891C0352C2B7BA9C653E208DE0582F8B38256E86936ECED498565458D4484A800E314168C77D17D800B292A1C5F6EECE73AA25576A44B02D6CE9BE1BEA1D688C6B716680D0D4053FF110167BAF557C0818CC3058A16
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Hallo,

du scheinst einen Smartmeter von EVN zu haben, der aktuell eine fehlerhafte Firmware drauf hat.
Schau mal da...https://www.photovoltaikforum.com/thread/157476-stromz%C3%A4hler-kaifa-ma309-welches-mbus-usb-kabel/?postID=2582715#post2582715
Allerdings erklärt das noch nicht warum deine Rohdaten unterschiedliche Längen und Strukturen haben.
Die Kabelverbindung passt und die Stromversorgung vom Modul ist ausreichend (mind.  1A mit gutem Micro-USB Kabel)?

TheTrumpeter

#38
Zitat von: saghonfly am 18 Juni 2022, 06:09:02
du scheinst einen Smartmeter von EVN zu haben, der aktuell eine fehlerhafte Firmware drauf hat.
Schau mal da...https://www.photovoltaikforum.com/thread/157476-stromz%C3%A4hler-kaifa-ma309-welches-mbus-usb-kabel/?postID=2582715#post2582715
Tja, mich haben sie aber (noch) nicht darüber informiert, werde mich gleich mal dort melden...

Zitat von: saghonfly am 18 Juni 2022, 06:09:02
Allerdings erklärt das noch nicht warum deine Rohdaten unterschiedliche Längen und Strukturen haben.
Die Kabelverbindung passt und die Stromversorgung vom Modul ist ausreichend (mind.  1A mit gutem Micro-USB Kabel)?
1A ja, aber kein Micro-USB-Kabel/Netzteil, sondern ein kleiner AC/DC-Wandler.

Die Einstellungen passen? (Habe daran nichts geändert.)



NACHTRAG:
Vorhin konnte dann wieder was entschlüsselt werden, aber die Werte passen nicht annähernd:
1.7.0 3201308517 2022-06-18 06:44:07
1.8.0 2805745822 2022-06-18 06:44:07
2.7.0 697141817 2022-06-18 06:44:07
2.8.0 948242367 2022-06-18 06:44:07
31.7.0 384.04 2022-06-18 06:44:07
32.7.0 53730 2022-06-18 06:44:07
51.7.0 588.22 2022-06-18 06:44:07
52.7.0 7495 2022-06-18 06:44:07
71.7.0 88.86 2022-06-18 06:44:07
72.7.0 47297 2022-06-18 06:44:07
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

saghonfly

Zitat von: TheTrumpeter am 18 Juni 2022, 06:48:38
Die Einstellungen passen? (Habe daran nichts geändert.)
Ja, die Einstellungen sollten passen...

Deine Rohdaten scheinen aber durch eine Störung nicht richtig übertragen zu werden.
Kann am Smartmeter selbst, an der Kabelverbindung, an der Stromversorgung oder am Modul liegen.

Schreib mich bitte nochmal über willhaben an dann schicke ich dir ein Referenzgerät inklusive Kabel um die Sache einzuschränken.

TheTrumpeter

Alles klar, Danke. Hab' Dich gerade angeschrieben.

Das Modul samt Kabel stammt ja von Dir, ich hab' nur noch das Netzteil drangelötet.
Kabel habe ich schon mehrmals ab- und angesteckt, das hat an der Situation nichts geändert.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

So, offenbar ist mein Netzteil die Problemursache. Habe mehrere Stück vom gleichen Typ problemlos im Einsatz, ev. hat das eine Teil einen "Schaden" oder die anderen Anwendungen sind nicht so sensibel.
Läuft nun vorüberehend mit einem Handynetzteil bis ich passenden Ersatz gefunden habe.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

yellowpinky

Zitat von: saghonfly am 29 Mai 2020, 19:03:47
Hallo,


schaut euch bitte mal dieses Github Projekt an welches es sich zum Ziel gemacht hat, möglichst günstig und einfach eine Komplettlösung für die Integration von verschiedensten Sensoren (später auch Aktoren) zu erstellen.
https://github.com/saghonfly/shrdzm/wiki



Ist deine Lösung auf github nicht mehr verfügbar?