Neues Modul: ELV MobileAlerts

Begonnen von MarkusF, 01 November 2017, 16:39:11

Vorheriges Thema - Nächstes Thema

MarkusF

Hallo,

ich nutze schon länger FHEM und möchte auf jeden Fall danke für diese gute Software an alle Entwickler sagen. Vor allem für das gute Forum und das Wiki, die mir bisher jede Frage beantworten konnten.
Daher bin ich froh, dass mein erster Post direkt ein Beitrag zu FHEM selber sein kann.

Ich habe ein Modul entwickelt, dass es ermöglicht Mobile Alerts von ELV (https://www.elv.de/ip-wettersensoren-system.html) und TFA WeatherHub direkt in FHEM anzubinden.
Ich möchte mich hier auch bei Markus Fritze (mfritze) bedanken. Dieser hat das Protokoll entschlüsselt und ein Modul in Python (https://github.com/sarnau/MMMMobileAlerts) für MQTT entwickelt. Auf seine Leistung setzt mein FHEM-Modul auf.

Die Installation erfolgt mit:
Wenn man dauerhaft Updates haben will, kann man mit
update add https://raw.githubusercontent.com/markusfeist/FhemMobileAlerts/master/controls_mobilealerts.txt
das Repository zu den normalen Updates hinzufügen.
(ACHTUNG im Juni gab es eine Änderung in der mitgenutzten TcpServerUtils.pm. Daher wenn das letzte Update älter ist, ein "update" und "shutdown restart" durchführen.)


Konfiguration der Gateways:

       
  • get <name> config
  • Ermitteln GatewayId aus den Readings
  • set <name> initgateway <GatewayId>
Module für die Geräte werden im Raum MOBILEALERTS automatisch angelegt.

Eine genaue Anleitung mit weiteren Details ist hier hinterlegt: https://github.com/markusfeist/FhemMobileAlerts

Ich würde mich sehr über Feedback freuen, vor allem ob ich soweit alle Bedingungen für die FHEM Modulentwicklung eingehalten haben.

Eines muss ich allerdings vorweg schicken. Ich werde wahrscheinlich größeren Support für das Modul fast nur am Wochenende leisten können. Also wenn meine Antwort auf ein Problem länger dauert, bitte nicht verärgert sein.

Also viel Spaß beim Testen.

Viele Grüße
Markus

History:
01.11.2017 - erste Version
05.11.2017 - Attribut actCycle ergänzt
11.11.2017 - Der "ActionDetector" läuft nur noch in Abhängigkeit von ActCycle
12.11.2017 - Bugfix, dass Werte direkt nach Autocreate angezeigt werden.
                    - Überarbeitung readingsBulkUpdateIfChanged und readingsBulkUpdate
16.11.2017 - Bugfix negative Werte
17.11.2017 - Sensor MA10320PRO ergänzt
                    - Reading eventCount für MA10650
19.11.2017 - Neues Attribut "expert"
                    - Readings bekommen Timestamp von der Message (nicht mehr wann die Message eingetroffen ist)
01.12.2017 - MA10450 und TFA30.3312.02 hinzugefügt
                    - Das Reading lastMsg wird bei unbekannten Sensoren immer angezeigt.
14.12.2017 - Regenangabe in mm und event "rain" für MA10650 ergänzt.
                    - Dokumentation für Readings ergänzt.
07.01.2018 - Sensor WL2000 ergänzt.
06.02.2018 - Added Attribut directionInt for MA10660
28.07.2018 - Zusätzliche Werte im Define um Temperatur- und Luftfeutigkeitswerte zu korrigieren.
28.08.2018 - Fehlerkorrektur Perl Warnings
                   - Sensor TFA 30.3060.01 ergänzt.
29.08.2018 - Sensor MA10120PRO ergänzt.
08.10.2018 - Für Sensor MA10320PRO Temperaturbereich für negative Temperaturen angepasst.
10.12.2018 - "---" (off limit) für Humidity mit Nachkommastellen ergänzt.
07.03.2019 - Attribut allowfrom ergänzt.
28.04.2019 - Prüfung der Checksumme ergänzt (damit sollten unbekannte/ungültige Geräte verschwinden).
05.01.2020 - Endlich Änderung für MA10880 eingecheckt und batteryState ergänzt.

ToDos:

       
  • Nach Autocreate direkt die ersten Werte anzeigen
  • Batteriestatus
  • Regensensor mm Angaben (Niederschlag letzte Stunde)
  • Attribut ob alle Readings oder nur die notwendigen
  • Setzen der Event-Time auf den Zeitpunkt, an dem das Gateway das Event empfangen hat und nicht, wann es es weitergeschickt hat.

costa2

Hallo Markus.

Ich habe die Module schon vor vielen Tagen auf Github gefunden und gleich in fhem integriert, sie laufen seit dem absolut fehlerlos.

Vielen Dank dafür,

Volker
RPI3, Nanocul 433 MHz, 433 MHz Steckdosen, DVB-T Stick für 868 MHz TX Sensoren, MOBILE ALERTS Sensoren und Gateway

Amenophis86

Meinst du es ist möglich mit deinem Modul einen CUL als Gateway zu nutzen, dass man dieses nicht noch extra kaufen muss? Wenn ich richtig verstehe ist es aktuell ja so, dass die Sensoren die Daten ans Gateway schicken, dieses an FHEM und FHEM entweder sie blockt, oder weiterleitet ja nach Einstellung. Frage ist dann, werden die Daten vom Gateway noch aufbereitet, oder kommen sie so an, dass man mit einem CUL das Gateway simulieren kann ähnlich einem Jeelink/LaCrosse für die nicht MA Variante.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

FHEM-User22

Hallo,
klingt sehr interessant.

Die Temperaturfühler sehen den LaCrosse/Technoline TX29IT/TX37IT Serie usw. sehr ähnlich. Sind das die selben oder softwaremäßig verändert?

Grüße
FHEM-User22
FHEM auf Raspberry Pi und Proxmox und... und.... und....

costa2

#4
Die LaCrosse/Technoline TX Serie unterscheidet sich auch von der Hardware her von den LaCrosse/Technoline Mobile Alerts Sensoren.

Volker
RPI3, Nanocul 433 MHz, 433 MHz Steckdosen, DVB-T Stick für 868 MHz TX Sensoren, MOBILE ALERTS Sensoren und Gateway

FHEM-User22

Dankeschön.

Wäre zu schön gewesen.

FHEM auf Raspberry Pi und Proxmox und... und.... und....

costa2

#6
Obwohl,
der TX37 hat zumindest die gleiche Größe wie der MA10200.

Es wäre interessant zu wissen, ob die TX Sensoren auch eine DeviceID senden, ähnlich der von den MA Sensoren = (0315a011111)

RPI3, Nanocul 433 MHz, 433 MHz Steckdosen, DVB-T Stick für 868 MHz TX Sensoren, MOBILE ALERTS Sensoren und Gateway

MarkusF

Ich würde auch mal vermuten klappt nicht. Die Seite von TechnoLine http://www.techome.de/klima-wetter-umwelt/index.html trennt diese Sensoren in zwei Bereiche auf. Überprüfen kann ich es aber leider nicht. Bei meinem Modul müsste allerdings wenn der Sensor vom MobileAlerts Gateway angenommen wird, ein Gerät mit einer unbekannten ID auftauchen und darauf könnte man dann aufsetzen. Also müsste jemand mal einen TX Sensor in die Nähe eines Gateways bringen.

MarkusF

Zitat von: Amenophis86 am 02 November 2017, 07:02:40
Meinst du es ist möglich mit deinem Modul einen CUL als Gateway zu nutzen, dass man dieses nicht noch extra kaufen muss?
Ich würde es tippen, dass es möglich ist. Ich würde mal frei vermuten, dass die Geräte auch ziemlich einfach nur die Zeichenkette per Funk senden, die auch das Gateway verschickt. Die Geräte senden auch einfach die Signale raus. Sie sind weder mit einem Gateway gepairt noch sonst irgendwas. Auch das Gateway scheint einfach alle MobileAlerts Signale anzunehmen und weiterzuleiten. Also wenn jemand ein Modul 50_MOBILEALERTSCUL schreibt und die Zeichenkette aus dem Funkverkehr dann weiterleitet könnte es klappen.
Ich werde es allerdings auf absehbare Zeit nicht sein. Ich habe zu einem keinen CUL (bisher arbeite ich mit einem HMLAN-Gateway, MAX-Cube und MobileAlerts Gateway), zum anderen habe ich leider keine Erfahrung mit Funkprotokollen bzw. dem Knacken davon.

Viele Grüße
Markus

Amenophis86

Ahnung davon habe ich leider auch nicht, Zeit noch weniger, Interesse daran schon. Aber vielleicht wird ja jemand auf den Thread aufmerksam und möchte sich dran machen. Warten wir einfach mal ab :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

costa2

#10
Hallo Markus.

ZitatToDos:

    Nach Autocreate direkt die ersten Werte anzeigen
    Batteriestatus

Den Batteriestatus halte ich für einen Fake.
Aus folgendem Grund.
Wenn ich die Batterie aus einem Sensor entferne, kommen zwar keine aktuellen Daten mehr in der APP an, die Batterie wird aber weiterhin als "Gut" angezeigt.

Ich habe das mit einem dummy, notify und watchdog auf den txCounter gelöst, so wird mir im Tablet UI zumindest angezeigt, ob der Sensor noch online ist oder nicht.

define Wkrone_on dummy
attr Wkrone_on alias Krone
attr Wkrone_on devStateIcon absent:measure_battery_50@red present:measure_battery_100@green
attr Wkrone_on room MOBILEALERTS
attr Wkrone_on setList present absent
attr Wkrone_on userReadings battery { ReadingsVal("Wkrone_on","state",0) ;;}


define Wkrone_off notify Wkrone.txCounter:.* set Wkrone_on present
attr Wkrone_off room MOBILEALERTS

define Wkrone_off_2 watchdog Wkrone_on 00:08:00 SAME { fhem("set Wkrone_on absent");;;;fhem("setstate Wkrone_off_2 defined")}
attr Wkrone_off_2 room MOBILEALERTS


Eventuell ist der Code etwas umständlich, aber er funktioniert.

Volker
RPI3, Nanocul 433 MHz, 433 MHz Steckdosen, DVB-T Stick für 868 MHz TX Sensoren, MOBILE ALERTS Sensoren und Gateway

MarkusF

Hallo,

der Battriestatus ist wahrscheinlich kein Fake. Zumindest bei einigen Geräten nicht. Ich hatte mal eine defekten MA10230, der hatte in zwei Wochen einen Batteriesatz ausgeleert (ELV hat den problemlos getauscht). Nach einer Woche hatte er LOW-Battery in der App angezeigt.
Ich habe jetzt aber noch ein Attribut actCycle (angelehnt an die Homematic Geräte) eingebaut. Es gibt keinen ActionDetector, aber ein Reading actStatus. Damit braucht man keinen Dummy mehr und mit einer ReadingsGroup, z.B.:

define rg.actStatus readingsGroup .*:actStatus

bekommt man dann den Status.

Viele Grüße
Markus

costa2

#12
Ja, okay, ein userReading "battery" habe ich auch schon drin.
Das bringt aber nicht viel, da die Readings ja nicht aktualisiert werden, wenn der Sensosor sich nicht mehr meldet, z.B. wenn die Batterie leer ist.

Kann man die Aktualisierungszeit des actCycle auch erhöhen?
Egal was ich eingebe, sie bleibt bei einer Minute.


Edit:
Nun habe ich es verstanden.
Der actCycle gibt vor bis spätestens wann sich der Sensor melden soll, 001:30 wären also 1,5 Stunden.
Nur ist es nötig diesen Zustand jede Minute abzufragen?

Ps, Rückmeldung:
Der MA 10350 Wasserdetektor funktioniert auch, getestet von einem Kollegen.

Gruß,
Volker
RPI3, Nanocul 433 MHz, 433 MHz Steckdosen, DVB-T Stick für 868 MHz TX Sensoren, MOBILE ALERTS Sensoren und Gateway

obelix221

Hi,

das klingt ja super interessant. Insbesondere ist das Intervall mit 7 Minuten deutlich länger als mit den normalen Technoline / LaCrosse Sensoren.
Da hat mich schon immer der sehr kurze Updatezyklus gestört. Das probiere ich aus, und dann werden meine LaCrosse Sensoren rückgebaut.

Danke...
RPi3 als FHEM-Server, 868 MHz CUL, 433 MHz Transmitter, Homematic Aktoren und Sensoren, Yamaha AVR, Logitech Harmony, Fritzbox, Logitech SB, 433 MHz Steckdosen, HUE, EnOcean

MarkusF

Hallo Volker,

zum actCycle: Ich habe jetzt ersteinmal eingebaut, dass ein Event nur kommt, wenn sich der Status auch ändert. Das mit der Minute ändere ich auch noch. Ich kann ja berechnen, wann der nächste Check nötig ist, aber dazu komme ich wahrscheinlich erst am Wochenende.

Viele Grüße
Markus