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 (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 (https://github.com/sarnau/MMMMobileAlerts)) für MQTT entwickelt. Auf seine Leistung setzt mein FHEM-Modul auf.
Die Installation erfolgt mit:
Laden in FHEM mit
update all https://raw.githubusercontent.com/markusfeist/FhemMobileAlerts/master/controls_mobilealerts.txt (https://raw.githubusercontent.com/markusfeist/FhemMobileAlerts/master/controls_mobilealerts.txt)
Das Modul ist jetzt Bestandteil des FHEM-SVN wird also mit dem normalen Update geladen- define <name> MOBILEALERTSGW <Freier-Port>
Wenn man dauerhaft Updates haben will, kann man mit
update add https://raw.githubusercontent.com/markusfeist/FhemMobileAlerts/master/controls_mobilealerts.txt (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 (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 anzeigenBatteriestatusRegensensor mm Angaben (Niederschlag letzte Stunde)Attribut ob alle Readings oder nur die notwendigenSetzen der Event-Time auf den Zeitpunkt, an dem das Gateway das Event empfangen hat und nicht, wann es es weitergeschickt hat.
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
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.
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
Die LaCrosse/Technoline TX Serie unterscheidet sich auch von der Hardware her von den LaCrosse/Technoline Mobile Alerts Sensoren.
Volker
Dankeschön.
Wäre zu schön gewesen.
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)
Ich würde auch mal vermuten klappt nicht. Die Seite von TechnoLine http://www.techome.de/klima-wetter-umwelt/index.html (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.
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
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 :)
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 MOBILEALERTSEventuell ist der Code etwas umständlich, aber er funktioniert.
Volker
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
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
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...
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
Super, Markus
Ansonsten laufen die Module fehlerfrei.
Volker
Hallo zusammen,
ich kann leider das Gateway in fhem nicht anlegen.
Nach einem
define MobileAlert_GW MOBILEALERTSGW 9001
bekomme ich die Meldung:
Cannot load module MOBILEALERTSGW
und im Log habe ich folgende Fehlermeldung:
2017.11.10 19:26:42 1: reload: Error:Modul 50_MOBILEALERTSGW deactivated:
Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 466, near "1)"
BEGIN not safe after errors--compilation aborted at ./FHEM/50_MOBILEALERTSGW.pm line 574.
2017.11.10 19:26:42 0: Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 466, near "1)"
BEGIN not safe after errors--compilation aborted at ./FHEM/50_MOBILEALERTSGW.pm line 574.
Any ideas?
Danke & VG
Obelix
Cannot load module MOBILEALERTSGW,
deutet eigentlich darauf hin, dass fhem keine Rechte hat das Modul zu laden.
Wie hast Du es denn installiert?
Per FTP in den Ordner FHEM kopiert?
Ansonsten, mach doch mal folgende Einstellungen in der Smartphone APP. (Anhang)
Ach, ja und den Gateway mal neu starten.
Volker
Hi Volker,
habe die Module so installiert, wie im ersten Posting beschrieben. Die Berechtigungen habe ich auch bereits im Filesystem überprüft.
Meinem Verständnis nach, ist bei dem define noch gar kein Connect zum eigentlichen GW erforderlich. Man richtet nur den Listener auf dem FHEM Server ein. Hat also noch nichts mit der APP und den Einstellungen zu tun.
Die Fehlermeldung im Log und die entsprechende Code Zeile deutet meiner Meinung eher darauf hin, dass in dem übergebenen Hash in der betroffenen Subroutine, zu viele Parameter übergeben werden.
Hmmm...??
An einen Fehler im Modul glaube ich eher nicht, denn bei mir und einem Kollegen läuft es einwandfrei.
Glaube ich ja auch nicht direkt. Aber vielleicht ist an meiner Umgebung etwas anders/ speziell, was das Modul noch nicht abfängt.
Installier dir mal http://www.weatherdirect.com/downloads/GatewayAdminInstall.exe (Windows) und sieh nach, was das zu deinen Gateway Einstellungen ausspuckt.
Hi Volker,
Was würde das Tool für Infos liefern, die bei der Analyse weiterhelfen könnten?
In der APP sehe ich bereits mein GW und die Daten von 7 Temp und Feuchtigkeitssensoren.
VG
Obelix
P.S. Ich verfolge bei der Installation von SW eher den Ansatz: weniger ist mehr, um unnötige Sicherheitslücken zu vermeiden.
Es zeigt dir unter Anderem, ob dein Proxyserver wirklich aktiv ist, der Haken unten links muss drin sein und IP und Port des fhem Servers müssen stimmen.
Hmm...Der Virenschutz sagt nicht sicher.
Aus Deinem Screenshot sehe ich auch keine relevanten Daten, die ich nicht auch in der App einstellen könnte, auch eigentlich nicht ob der Proxyserver läuft, sondern nur wo er laufen sollte.
...und ich glaube ja auch nicht, dass ein Proxyserver bei mir läuft, denn dafür müsste ja meinem Verständnis nach der Listener auf dem Fhem Server laufen, der über den define...Befehl angelegt wird.
...und genau das define Kommando scheitert.
Danke aber auf jeden Fall für Deine intensive Unterstützung.
..weitere Ideen..?
@Volker: übrigens gibt es bei Dir Abweichungen lt Deinen Screenshots bei der IP Adresse des Proxys/Fhem-Servers zwischen App und Windows-tool.
Richtig.
Oben ist die IP meines PC, in der Mitte die IP des Gateways und unten der Proxyserver meines Raspis auf dem Fhem läuft.
Ohne den Proxy werden die Daten nicht zu fhem umgeleitet
Aber nach einem Neustart des Gateway aktiviert die MOBILEALERTSGW.pm den Proxy automatisch.
So sollte es zumindest sein.
Ps.
Das Tool ist frei von Viren.
Ja,...das ist mir klar.
Aber die IP Adresse Deines FHEM Servers ist in der App x.x.x.20 und im Windows Tool x.x.x.32, oder?
Ach so, das meinst Du.
In der APP ist es die WLan Ip und das andere die Lan IP des Raspberry, nun habe ich die IPs aber angepasst.
Macht aber keinen Unterschied, wichtig ist der Port.
PS. Port.
Kann es sein, dass dein Port 9001 in der Fritz schon durch etwas Anderes belegt ist?
Hallo,
den Fehler hatte ich während der Entwicklung auch, aber umgekehrt. Am 30.6. wurde die TcpServerUtils.pm geändert. In der alte Version hatte die Funktion TcpServer_Close einen Parameter. Die neue dann zwei. Also einfach mal "update" eingeben. Dabei sollte dann u.a. auch die TcpServerUtils.pm geupdated werden.
Nach einem "shutdown restart" sollte dann das Modul laufen.
Viele Grüße
Markus
Oh, man. :-[
Stimmt, so war es beim Kollegen ebenfalls.
Das war mir ganz entfallen.
Wir haben stundenlang per WhatsApp darüber gegrübelt, nach einem fhem Update lief es dann.
Yep, das war's. :D
Vielen Dank....funktioniert prächtig.
Jetzt baue ich meine Jeelink/ LaCrosse- Infrastruktur zurück.
Freut mich zu hören. Ich habe gerade ein Update hochgeladen. Jetzt läuft der "ActionDetector-Timer" nur noch in Abhängigkeit von actCycle (also nicht mehr jede Minute).
Nun tut sich aber gar nichts mehr, ist das richtig?
Der Status wird nur geupdated, wenn er sich ändert. Da er ja nur noch geupdated wird, wenn eine Nachricht reinkommt bzw. ein actCycle erreicht wird, ist es wahrscheinlich sinnvoller, es bei jeder Nachricht zu updaten egal ob der Wert sich ändert?
Hallo Markus.
Es funktioniert trotzdem,
ich habe einen actCycle von 000:15 eingegeben, die Batterie entfernt, nach 16 Minuten "actStatus dead" obwohl sich die Zeit des actStatus vorher seit Gestern 21 Uhr nicht geändert hatte.
Es spricht somit eigentlich nichts dagegen es bei dieser Version zu belassen.
Volker
Ich habe es jetzt doch mal überarbeitet. Also readingsBulkUpdateIfChanged und readingsBulkUpdate im Code gegengeprüft. Prinzipiell habe ich im Gateway jetzt meist readingsBulkUpdateIfChanged drin und beim Gerät meist readingsBulkUpdate.
Das alte Verhalten bekommt man aber auch wieder eingestellt mit:
attr TYPE=MOBILEALERTS event-on-change-reading .*
attr TYPE=MOBILEALERTS timestamp-on-change-reading .*
Das wird beim Autocreate auch als Default bei den Attributen gesetzt.
Dies ist auch Grund warum ich es geändert habe. Soll doch der Anwender entscheiden, was besser passt ;)
Zusätzlich wird beim Autocreate jetzt auch direkt mit dem Wert gestartet. Also es startet nicht mehr mit dem State ??.
Viele Grüße
Markus
Hallo Markus,
vielen Dank erstmal für Dein tolles FHEM Modul für die Mobile Alerts Sensoren.
Deine Arbeit war der Grund für mich einen Pi anzuschaffen und FHEM zu installieren.
Nun habe ich es innerhalb von ein paar Stunden erfolgreich geschafft meine Sensoren einzubinden und auch gplots zu erstellen. Nun ist mir aber aufgefallen, das nur Positive Werte rüberkommen, also eine tatsächliche Temperatur von - 0.4 Grad wird als 0.4 angezeigt. Somit sind natürlich auch meine Plots falsch.
Desweiren hab ich festgestellt das nur über einen Tag ein Plot angelegt werden kann. Ich würde dies gern über mehrere Wochen/Monater machen .
Wäre schön wenn Du oder ein anderer Spezialist mir weiterhelfen könnte.
Gruß Andreas
Das ist natürlich dumm.
Es ist mir noch nicht aufgefallen, da die tiefste Temperatur hier genau null Grad war.
Oder war sie doch tiefer und wurde nur 0°C als Tiefstwert registriert, da negative Werte ignoriert werden?
Im Logfile sieht es tatsächlich danach aus.
Das wäre natürlich der Supergau für mich, da ich meine Palmenheizung damit steuere, die soll erst bei -8°C anspringen.
2017-11-14_01:15:54 Saussen temperature: 0
2017-11-14_01:15:54 Saussen humidity: 93
2017-11-14_01:22:54 Saussen temperature: 0
2017-11-14_01:22:54 Saussen humidity: 93
2017-11-14_01:29:55 Saussen temperature: 0.1
2017-11-14_01:29:55 Saussen humidity: 93
2017-11-14_01:43:58 Saussen temperature: 0.4
2017-11-14_01:43:58 Saussen humidity: 92
2017-11-14_01:50:59 Saussen temperature: 0.5
2017-11-14_01:50:59 Saussen humidity: 92
2017-11-14_01:57:59 Saussen temperature: 0.6
2017-11-14_01:57:59 Saussen humidity: 92
2017-11-14_02:05:00 Saussen temperature: 0.8
2017-11-14_02:05:00 Saussen humidity: 92
2017-11-14_02:12:01 Saussen temperature: 0.9
2017-11-14_02:12:01 Saussen humidity: 93
2017-11-14_02:19:03 Saussen temperature: 0.9
2017-11-14_02:19:03 Saussen humidity: 93
2017-11-14_02:26:04 Saussen temperature: 0.9
2017-11-14_02:26:04 Saussen humidity: 93
2017-11-14_02:33:05 Saussen temperature: 0.9
2017-11-14_02:33:05 Saussen humidity: 93
2017-11-14_02:40:06 Saussen temperature: 0.8
2017-11-14_02:40:06 Saussen humidity: 94
2017-11-14_02:47:07 Saussen temperature: 0.6
2017-11-14_02:47:07 Saussen humidity: 94
2017-11-14_02:54:08 Saussen temperature: 0.5
2017-11-14_02:54:08 Saussen humidity: 94
2017-11-14_03:01:09 Saussen temperature: 0.3
2017-11-14_03:01:09 Saussen humidity: 94
2017-11-14_03:08:10 Saussen temperature: 0.1
2017-11-14_03:08:10 Saussen humidity: 94
2017-11-14_03:15:11 Saussen temperature: 0
2017-11-14_03:15:11 Saussen humidity: 94
2017-11-14_03:22:12 Saussen temperature: 0
2017-11-14_03:22:12 Saussen humidity: 94
2017-11-14_03:29:13 Saussen temperature: 0.1
2017-11-14_03:29:13 Saussen humidity: 94
@ Andreas
Die Plots gehen in der Grundeinstellung über 24 Stunden, mit den grünen Pfeilen oben, kannst Du aber zurückblättern.
Hallo,
ich habe gerade eine Korrektur hochgeladen. Damit klappen dann auch die negativen Werte. Hier war es (leider) noch nicht so kalt, dass ich negative Werte hatte. Wegen der Graphen, normalerweise steht neben dem obersten Graph links (gilt für alle Graphen auf der FHEM-Seite bzw. im FHEM-Raum) eine "Pluslupe", "Minuslupe" und ein bzw. zwei Pfeile. Mit diesen vier Icon kann man den Graph zoomen bzw. den Ansichtszeitraum verändern.
Viele Grüße
Markus
Vielen Dank, Markus.
Ich habe es gleich mal eingepflegt.
Im Laufe des Tages folgt der Test im Gefrierschrank.
Volker
Alles Gut.
2017-11-16_10:27:59 Wkrone temperature: 7.7
2017-11-16_10:35:00 Wkrone temperature: 8
2017-11-16_10:49:02 Wkrone temperature: -13.9
Volker
Hi,
der Regensensor MA10650 wird zwar erkannt, aber noch nicht ausgewertet, richtig?
Wird erkannt und ausgewertet. Allerdings ist der Code dazu ungetestet (da ich keinen Regensensor habe) und lediglich nach der Dokumentation https://github.com/sarnau/MMMMobileAlerts/blob/master/MobileAlertsGatewayBinaryUpload.markdown (https://github.com/sarnau/MMMMobileAlerts/blob/master/MobileAlertsGatewayBinaryUpload.markdown) geschrieben.
Also wenn es klappt bitte einmal melden. Wenn es nicht klappt, bitte das Attribut lastMsg auf 1 setzen und mir den Inhalt des (dann entstehenden) Readings lastMsg zum Gerät und was dort an sich stehen sollte schicken.
Viele Grüße
Markus
Hat heute leider nicht geregnet...
Hier mal das Listing
NAME MA_080745895962
NR 533
STATE T: 6.2 C: 7
TYPE MOBILEALERTS
READINGS:
2017-11-16 11:34:59 actStatus alive
2017-11-15 16:09:13 deviceType MA10650
2017-11-16 15:55:20 lastEvent 172800
2017-11-15 16:09:13 lastEvent1 19
2017-11-15 16:09:13 lastEvent1String 19 s
2017-11-15 16:09:13 lastEvent2 6
2017-11-15 16:09:13 lastEvent2String 6 s
2017-11-15 16:09:13 lastEvent3 1524
2017-11-15 16:09:13 lastEvent3String 1524 s
2017-11-15 16:09:13 lastEvent4 1558
2017-11-15 16:09:13 lastEvent4String 1558 s
2017-11-15 16:09:13 lastEvent5 3
2017-11-15 16:09:13 lastEvent5String 3 s
2017-11-15 16:09:13 lastEvent6 3
2017-11-15 16:09:13 lastEvent6String 3 s
2017-11-15 16:09:13 lastEvent7 41
2017-11-15 16:09:13 lastEvent7String 41 s
2017-11-15 16:09:13 lastEvent8 0
2017-11-15 16:09:13 lastEvent8String 0 d
2017-11-16 15:55:20 lastEventString 2880 m
2017-11-16 15:55:20 lastMsg e15a0da6ae25080745895962001f403e00078b40c013c006c5f4c616c003c003c02900000000d200000000000000000000000000000000000000000000000037
2017-11-16 15:55:20 lastRcv 2017-11-16 15:54:38
2017-11-16 15:55:20 state T: 6.2 C: 7
2017-11-16 15:55:20 temperature 6.2
2017-11-16 15:55:20 temperatureString 6.2°C
2017-11-15 16:09:13 triggered 0
2017-11-16 15:55:20 txCounter 31
Und hier dazu was Mobilealerts dazu weiß (falls das hilfreich ist)
14.11.2017 16:18:06 1,8 mm
14.11.2017 16:17:47 1,5 mm
14.11.2017 16:17:40 1,3 mm
14.11.2017 15:52:29 1,0 mm
14.11.2017 15:26:43 0,8 mm
14.11.2017 15:26:40 0,5 mm
14.11.2017 15:26:37 0,3 mm
14.11.2017 15:25:54 0,0 mm
Gruß Andreas
Ich hab den auch bei Conrad-Connect angemeldet. Der Vergleich zeigt, der Count 7 stimmt und die Temperatur stimmt auch. Also könnten die ganzen anderen Readings raus.
Zitat von: MarkusF am 16 November 2017, 04:39:07
Hallo,
ich habe gerade eine Korrektur hochgeladen. Damit klappen dann auch die negativen Werte. Hier war es (leider) noch nicht so kalt, dass ich negative Werte hatte. Wegen der Graphen, normalerweise steht neben dem obersten Graph links (gilt für alle Graphen auf der FHEM-Seite bzw. im FHEM-Raum) eine "Pluslupe", "Minuslupe" und ein bzw. zwei Pfeile. Mit diesen vier Icon kann man den Graph zoomen bzw. den Ansichtszeitraum verändern.
Viele Grüße
Markus
Hallo Markus, vielen Dank für die prompte Umsetzung. Nun hoffe ich das es nächste Nacht nochmal runtergeht unter Null. Aktuell hängt es grade bei + 0.6 ° C
Danke auch an Dich und Costa für den Tip. Nun hab ich noch ne kleine Frage:
kann man den Wertintervall irgendwo einstellen ? Mobile Alerts schickt ja alle 7 min Daten. In meinen Diagrammen sind aber meine ich nicht so kurze Zeitintervalle enthalten ?
Gruß Andreas
P.S. Warum muss ich hier immer den Robotertest und die Sicherheitsfrage beantworten bei jedem Post ? Das nervt doch schon etwas...
Schön zu hören mit dem Regensensor. Einer mehr der geht.
Der Counter 7 kommt hin. 7 x 0,258 = 1,806 mm. Der letzte Wert vor 48 Stunden passt auch. Jetzt muss ich mir aber noch Gedanken machen. Wie ich so etwas in einen Graph bekomme. Ich denke dass einfachste ist, wenn ich auf den bisher noch nicht ausgewerteten 2Bit Wert bei der Temparatur gehe. Dort bekomme ich anscheinend mit, ob es ein Idle-Aufruf ist oder einer mit wirklichem Wert und kann bei einem wirklichem Wert ein Event mit dem mm-Wert erzeugen.
Was wäre als Reading sinnvoll? Niederschlag in der letzten Stunde? Niederschlag in der aktuelle Stunde?
Wegen der zusätzlichen Readings. Ich würde sie nicht wegmachen wollen, allerdings ein Schalter "expert" ähnlich wie die Homematic kann ich dann einbauen. Bei "expert"=1 kommt dann alles. Bei 0 nur die Basiswerte bzw. aktuellen Werte. Das wird aber wahrscheinlich erst am Wochenende was.
Wegen der Messwerte:
Also bei mir kommen diese "schön" im Abstand:
2017-11-16_19:59:20 MA_0213fd84b8c0 txCounter: 3131
2017-11-16_19:59:20 MA_0213fd84b8c0 temperature: 17.1
2017-11-16_19:59:20 MA_0213fd84b8c0 temperatureString: 17.1°C
2017-11-16_19:59:20 MA_0213fd84b8c0 prevTemperature: 15.6
2017-11-16_19:59:20 MA_0213fd84b8c0 T: 17.1
2017-11-16_19:59:20 MA_0213fd84b8c0 lastRcv: 2017-11-16 19:52:38
2017-11-16_20:06:21 MA_0213fd84b8c0 txCounter: 3132
2017-11-16_20:06:21 MA_0213fd84b8c0 temperature: 16.7
2017-11-16_20:06:21 MA_0213fd84b8c0 temperatureString: 16.7°C
2017-11-16_20:06:21 MA_0213fd84b8c0 prevTemperature: 17.1
2017-11-16_20:06:21 MA_0213fd84b8c0 T: 16.7
2017-11-16_20:06:21 MA_0213fd84b8c0 lastRcv: 2017-11-16 19:59:40
2017-11-16_20:13:29 MA_0213fd84b8c0 txCounter: 3133
2017-11-16_20:13:29 MA_0213fd84b8c0 prevTemperature: 16.7
2017-11-16_20:13:29 MA_0213fd84b8c0 lastRcv: 2017-11-16 20:06:34
2017-11-16_20:20:30 MA_0213fd84b8c0 txCounter: 3134
2017-11-16_20:20:30 MA_0213fd84b8c0 temperature: 16.8
2017-11-16_20:20:30 MA_0213fd84b8c0 temperatureString: 16.8°C
2017-11-16_20:20:30 MA_0213fd84b8c0 T: 16.8
2017-11-16_20:20:30 MA_0213fd84b8c0 lastRcv: 2017-11-16 20:13:42
2017-11-16_20:27:31 MA_0213fd84b8c0 txCounter: 3135
2017-11-16_20:27:31 MA_0213fd84b8c0 temperature: 17
2017-11-16_20:27:31 MA_0213fd84b8c0 temperatureString: 17°C
Das ist allerdings ein Sensor wo nicht so viel los ist, deswegen kommt zwischendurch nur:
017-11-16_17:59:25 MA_0213fd84b8c0 txCounter: 3114
2017-11-16_17:59:25 MA_0213fd84b8c0 lastRcv: 2017-11-16 17:53:20
2017-11-16_18:06:26 MA_0213fd84b8c0 txCounter: 3115
2017-11-16_18:06:26 MA_0213fd84b8c0 lastRcv: 2017-11-16 18:00:22
2017-11-16_18:13:28 MA_0213fd84b8c0 txCounter: 3116
2017-11-16_18:13:28 MA_0213fd84b8c0 lastRcv: 2017-11-16 18:07:23
2017-11-16_18:20:29 MA_0213fd84b8c0 txCounter: 3117
2017-11-16_18:20:29 MA_0213fd84b8c0 lastRcv: 2017-11-16 18:14:22
2017-11-16_18:27:30 MA_0213fd84b8c0 txCounter: 3118
2017-11-16_18:27:30 MA_0213fd84b8c0 lastRcv: 2017-11-16 18:21:24
Wenn man den Graph sauberer haben will, muss man dann die Attribute "event-on-change-reading" und "timestamp-on-change-reading" wegnehmen. Alternativ kann man die Readings, die in den Plot gehen in das Attribut "event-on-update-reading" nehmen, z.B. "attr <Gerät> event-on-update-reading temperature,humidity" Dann kommt bei jedem Event auch ein Temperatur- und Luftfeuchtewert.
Ein Problem bleibt allerdings, was man schön an der Zeile:
2017-11-16_18:27:30 MA_0213fd84b8c0 lastRcv: 2017-11-16 18:21:24
sieht.
Das Gateway hat das Signal um 18:21:24 empfangen. Es kam wurde aber erst um 18:27:30 gesendet.
Da kann ich ggf. was noch mit CHANGETIME machen, da muss ich mich aber auch erste einarbeiten.
Viele Grüße
Markus
Ich glaube Niederschlag der letzten Stunde wäre gut. Den Schalter expert halte ich für eine gute Idee.
Hallo,
mein Vater hat Sensoren von MobileAlerts in Verwendeung. Diese hatte ich bis dato über httpmod angebunden und habe nun mal dein schickes neue Modul in Betrieb genommen. Die meisten Sensoren haben auf Anhieb funktioniert. Allerdings setzt er einen MA10320PRO ein, der aktuell noch nicht erkannt wird. Hier ein List vom device:
Internals:
DEF 093a732dda8f
DeviceID 093a732dda8f
LASTInputDev MobileAlertsGW
MSGCNT 2038
MobileAlertsGW_MSGCNT 2038
MobileAlertsGW_TIME 2017-11-17 10:07:01
NAME MA_093a732dda8f
NR 133
STATE ???
TYPE MOBILEALERTS
READINGS:
2017-11-12 07:26:16 actStatus switchedOff
2017-11-12 07:32:17 deviceType Unknown - 09 d6
2017-11-17 10:07:01 lastMsg d65a0ea66f1a093a732dda8f279200d200c84a2900d000c88a2b0dd0000bd2b0010ad2b00106d20000000000000000000000000000000000000000000000001c
2017-11-17 10:07:01 lastRcv 2017-11-17 10:05:51
Attributes:
lastMsg 1
room MOBILEALERTS
Brauchst du noch weitere Informationen, um den Sensor auch mit einzubinden?
Vielen Dank
Ronny
Normalerweise bräuchte ich noch die Werte aus der MobileAlertsApp. Die Message sieht aber genauso aus, wie für den MA10300. Das wären 21,0 Grad am Sensor, 20,0 Grad am Kabel und 41% Luftfeuchte. Wenn mir nichts dazwischen kommt (den Sourcecode habe ich schon angepasst, aber ein Test steht noch aus, das kann ich erst zu Hause wieder), gibt es heute Nacht oder morgen dann das Update.
Viele Grüße
Markus
Der MA10320PRO ist ergänzt.
Viele Grüße
Markus
Hallo,
habt ihr eine Idee wie ich den zweiten Wert noch bekomme?
MA 10450
Hat wer eine Idee?
Zurzeit kommen diese Sachen an:
Internals:
CHANGED
DEF xxxxxxx
DeviceID xxxxxxx
LASTInputDev MobileAlertsGW
MSGCNT 26
MobileAlertsGW_MSGCNT 26
MobileAlertsGW_TIME 2017-12-01 17:09:36
NAME MA_0f0282f8d7a7
NR 121
STATE 19°C
TYPE MOBILEALERTS
READINGS:
2017-12-01 00:55:05 actStatus switchedOff
2017-12-01 00:43:01 deviceType Unknown - 0f d2
2017-12-01 00:43:01 humidity 9999
2017-12-01 00:43:01 humidityString ---
2017-12-01 17:09:28 lastRcv 2017-12-01 17:09:28
2017-12-01 16:57:27 state T: 19 H: 9999
2017-12-01 16:57:27 temperature 19
2017-12-01 16:57:27 temperatureString 19°C
2017-12-01 00:43:01 triggered 0
2017-12-01 17:09:28 txCounter 121
Attributes:
DbLogExclude .*
alias Temperatur
event-on-change-reading .*
icon temp_temperature
room MOBILEALERTS
stateFormat temperatureString
timestamp-on-change-reading .*
verbose 5
Grüße,
Ole
Hallo zusammen,
bin neu hier und habe in diesem wunderbaren Forum schon sehr viele und gute Tipps gefunden. Möchte mich an der Stelle auch mal bei denen bedanken, die da richtig viel Arbeit reinstecken und FHEM so gut machen!
Ja leider habe ich jetzt die Not ein paar Fachleute zu fragen. Habe TFA Sensoren des Typs 30.3312.02 (Temp und Luftfeuchte), das sind die Pro Varianten.
Eingebunden über die REST API und Mobile Alerts. Der Gateway ließ sich hervorragend initialisieren, allerdings passen die Daten der Sensoren nicht.
Was habe ich gemacht: da mir die TFA als baugleiche Sensoren zum MA10200 erschienen, habe ich die 51_MOBILEALERTS.pm umgestrickt und die ID 0e d8 der TFA reingeschrieben.
Temperatur, txCounter, lastRcv passen, allerdings nicht die Feuchtigkeit....
Würde gerne die Decodierung selbst anpassen, mir fehlt aber das Wissen wie ich das tun kann.
actStatus switchedOff 2017-12-01 17:23:34
deviceType TFA30.3312.02 2017-12-01 17:26:17
humidity 73 2017-12-01 17:53:02
humidityString 73% 2017-12-01 17:53:02
lastMsg d85a2188eb1c0e137a0f1242452e80ea83493400e783271e00e683041e0000000000000000000000000000000000000000000000000000000000000000000077 2017-12-01 17:53:02
lastRcv 2017-12-01 17:52:59 2017-12-01 17:53:02
state T: 23.4 H: 73 2017-12-01 17:53:02
temperature 23.4 2017-12-01 17:53:02
temperatureString 23.4°C 2017-12-01 17:53:02
triggered 1 2017-12-01 17:46:54
txCounter 1326 2017-12-01 17:53:02
sollte aber sein:
Temperatur: 23.4 °C
Luftfeuchte: 84.1 %
Messung: 2017-12-01 17:52:59
Ist jemand in der Lage mir den entscheidenden Hinweis zu geben?
Vielen Dank und Gruß
Hallo Ole,
da brauche ich die Message. Also das Attribut lastMsg setzen und mir das Reading lastMsg schicken. (Dort ist auch die Geräte ID drin, also einfach per PM oder mit X statt der ID.) Ich hätte da schon die Vermutung, dass der Wert dort ist wo bei anderen Sensoren die Luftfeuchtigkeit ist, will es aber prüfen.
Hallo Jürgen (ich hoffe Jürgen ist ok),
habe den Wert wahrscheinlich schon gefunden. Die Luftfeuchtigkeit ist bei deinem Sensor im Gegensatz zu den anderen mit Nachkommastellen. Voraussichtlich komme ich morgen Nachmittag dazu es einzubauen. Ich schicke dir dann auch den Link auf den genauen Diff.
Viele Grüße
Markus
Zitat von: MarkusF am 01 Dezember 2017, 19:29:21
Hallo Ole,
da brauche ich die Message. Also das Attribut lastMsg setzen und mir das Reading lastMsg schicken. (Dort ist auch die Geräte ID drin, also einfach per PM oder mit X statt der ID.) Ich hätte da schon die Vermutung, dass der Wert dort ist wo bei anderen Sensoren die Luftfeuchtigkeit ist, will es aber prüfen.
Hallo Jürgen (ich hoffe Jürgen ist ok),
habe den Wert wahrscheinlich schon gefunden. Die Luftfeuchtigkeit ist bei deinem Sensor im Gegensatz zu den anderen mit Nachkommastellen. Voraussichtlich komme ich morgen Nachmittag dazu es einzubauen. Ich schicke dir dann auch den Link auf den genauen Diff.
Viele Grüße
Markus
Hallo Markus,
anbei die Daten
actStatus
switchedOff
2017-12-01 00:55:05
deviceType
Unknown - 0f d2
2017-12-01 00:43:01
humidity
9999
2017-12-01 00:43:01
humidityString
---
2017-12-01 00:43:01
lastMsg
d25a21c260160f0282f8d7a7009100c840c900c940cf2d0000000000000000000000000000000000000000000000000000000000000000000000000000000075
2017-12-01 21:58:08
lastRcv
2017-12-01 21:58:08
2017-12-01 21:58:08
state
T: 20 H: 9999
2017-12-01 21:58:08
temperature
20
2017-12-01 21:58:08
temperatureString
20°C
2017-12-01 21:58:08
triggered
0
2017-12-01 00:43:01
txCounter
145Grüße,
Ole
Hallo,
habe es schon geschafft und die beiden Sensoren MA10450 und TFA30.3312.02 ergänzt.
Die Änderung die im Sourcecode für den TFA30.3312.02 nötig waren, waren diese hier: https://github.com/markusfeist/FhemMobileAlerts/commit/b4389344dbf19b01c8b3a9b96dbf22c31ec940e7?diff=unified (https://github.com/markusfeist/FhemMobileAlerts/commit/b4389344dbf19b01c8b3a9b96dbf22c31ec940e7?diff=unified)
Viele Grüße
Markus
Hallo Markus,
vielen Dank! Das ging ja sehr fix. Die Sensoren funktionieren einwandfrei. Und endlich kann ich das Senden der Daten ins Internet einstellen ;-)
So, und nun wird schon wieder ein Sensor mehr von FHEM unterstützt.
Nochmals danke für deine klasse Arbeit und vor Allem deine schnelle Hilfe!
Gruß Jürgen
Hallo Markus,
danke für deinen Einsatz, jetzt läuft es Rund und alles wird Ordnungsgemäß angezeigt.
Mit besten Grüßen,
Ole
Gern geschehen. Aktuell bastle ich für den Regensensor an einer vernünftigen Anzeige. Irgendwie scheint aber auch in der Idle-Message ein Wert zur Wippe drin zu sein. Naja inzwischen habe ich mir auch einen Regensensor bestellt. Sobald der da ist, komme ich dort hoffentlich weiter.
Viele Grüße
Markus
Hallo,
ich habe gerade den Code für den Regenmesser erweitert und entsprechende Attribute und ein Event "rain" ergänzt. Zusätzlich habe ich die Dokumentation für die "Readings" ergänzt. Das ganze wird jetzt auch durch ein CI-System regelmäßig geprüft. Also ich hätte jetzt aktuell keine weiteren Ideen (bis auf den Wert für die Batterie, wobei dort habe ich noch überhaupt keinen Plan). Bin also für Ideen offen.
Die nächsten Sachen wären also noch die Dokumentation auf GitHub ausbauen (z.B. um Beispiele, wie man Graphen anlegt) und das ganze in FHEM SVN zu bringen, wenn niemand hier Probleme mit dem Modul hat.
Viele Grüße
Markus
Hallo,
die Module sind jetzt auch im SVN von FHEM selber. Mit
update delete https://raw.githubusercontent.com/markusfeist/FhemMobileAlerts/master/controls_mobilealerts.txt
kann man den Update von github aus abschalten.
Viele Grüße
Markus
Hallo Markus,
danke, danke hat auf Anhieb funktioniert!
Nur eine kleine Frage (Schönheitsfehler):
Die Sensoren wurden automatisch mit der Bezeichnung "MA_0224548a5853" also MA und Id angelegt. Kann man diese Bezeichnung in Fhem umbennen z.B. "TempPool" ?
Danke nochmals und LG
Wie wäre es mit
rename? ;)
Zitat
Internal command: rename
rename
rename <oldname> <newname>
Benennt ein Gerät von <oldname> in <newname>, einschliesslich der Attribute, um. Das globale Ereignis "RENAMED" wird erstellt, Lesen Sie bitte den Abschnitt "notify" durch um Details zu erfahren.
Beispiel:
rename FHT_1234 fht.kitchen
In Deinem Fall also
rename MA_0224548a5853 TempPool
Ja, danke. Den Befehl kenne ich schon, da aber die Bezeichnung automatisch generiert wurde, habe ich es nicht gewagt sie so zu ändern.
Es funktioniert aber.
Jetzt musste ich aber noch folgendes feststellen:
In fhem funktioniert alles wie vorgesehen. Die Android App zeigt mir jedoch seit der Fhem Installation keine Aktualisierungen mehr. Sollte dies ja auch weiterhin funktionieren?
Edit: Nach Eingabe "forward 1" funktioniert auch das.
LG
Alternativ kann man auch, bevor man den Sensor in Betrieb nimmt mit:
define <gewünschter Name> MOBILEALERTS <ID vom QR-Codeaufkleber des Sensors in Kleinbuchstaben>
direkt mit dem gewünschten Namen anlegen. Das automatische Anlegen mit anschließenden 'rename' ist in meinen Augen aber wesentlich komfortabler, da kein Tippfehler beim Code möglich ist. (Den Namen benutze ich natürlich nicht, um die Werte dem Sensor zuzuordnen, lediglich den Wert vom Define, also quasi den QR-Code vom Sensor.)
Viele Grüße
Markus
Hallo Markus!
Da jetzt alles gut läuft, werde ich morgen den MA10700 in Betrieb nehmen und dann berichten. Sollte kompatibel sein.
Danke nochmals und
LG Walter
Hallo Markus,
nunmehr wie in GitHub erwünscht, der MA10700 getestet:
Funktionierte auf Anhieb tadellos. Nachstehend das Reading zur Information.
Readings
actStatus switchedOff 2017-12-19 10:46:04
deviceType MA10300/MA10700 2017-12-19 10:41:00
humidity 51 2017-12-19 10:41:00
humidityString 51% 2017-12-19 10:41:00
lastRcv 2017-12-19 10:48:00 2017-12-19 10:48:00
state In T: 19.7 H: 51 Out T: 19.4 2017-12-19 10:48:00
temperatureIn 19.7 2017-12-19 10:48:00
temperatureOut 19.4 2017-12-19 10:48:00
temperatureStringIn 19.7°C 2017-12-19 10:48:00
temperatureStringOut 19.4°C 2017-12-19 10:48:00
triggered 0 2017-12-19 10:41:00
txCounter 16 2017-12-19 10:48:00
Danke und
LG Walter
Hallo Walter,
schön zu hören und danke für die Rückmeldung. Dann werde ich mal heute Abend die Dokumentation anpassen. (Jetzt muss nur noch jemand mit dem Fenstersensor MA10800 mal testen, dann weiß ich dass alles soweit schon mal klappt.)
Viele Grüße
Markus
Hallo!
Ich habe im "STATE" manchmal den Taupunkt dabei (nachgerechnet - stimmt auch), manchmal nicht. Im FileLog scheint er immer auf. Ich verwende ihn auch für die Graphik.
Ich glaube jedoch er kommt nicht von der Device sondern aus einer anderen Taupunktberechnung von mir im System?
"STATE T: 16.1 H: 52 D: 6.2"
Ist das so?
LG Walter
Hallo,
der Taupunkt kommt nicht von meinem Modul. Ich bin aber gerade auf das Modul dewpoint gestoßen (https://wiki.fhem.de/wiki/Dewpoint (https://wiki.fhem.de/wiki/Dewpoint)). Wenn dieses da ist und im define der Name auf das Gerät passt, sollte der Taupunkt genauso auftauchen. Das dürfte auch die Erklärung sein, warum es mal klappt und mal nicht. Im Gerät dewpoint werden die Geräte über einen regulären Ausdruck gewählt. Ich tippe mal, wo der nicht auftaucht, passt der Name nicht zum regulären Ausdruck.
Aber der Hinweis ist gut ich werde dewpoint auch in mein fhem einbauen.
Viele Grüße
Markus
Hallo!
Da wir ja hier von der gleichen Hardware sprechen, eine Frage dazu:
Hat schon jemand Erfahrung mit einem Sensor im Tiefkühler (-21°). Im Kühlschrank (2-7°) bis dato kein Problem.
LG
Moin MarkusFZitat... Jetzt muss nur noch jemand mit dem Fenstersensor MA10800 mal testen, dann weiß ich dass alles soweit schon mal klappt.
Hat sofort funktioniert. Super !!!
Siehe Anhang
Danke für die Rückmeldung. Jetzt weiß ich, dass mindestens alles wenigstens einmal mit echten Daten durchlaufen ist.
Viele Grüße
Markus
Moin MarkusF
Habe einen keinen BUG im Modul: MOBILEALERTSGW / attr stateFormat.
Wenn ich dort GW_001D8C0EF7D9_lastSeen | GW_001D8C0EF7D9_proxy das eingebe bekomme ich ein Lampen Icon.
Wenn ich dort GW_001D8C0EF7D9_lastSeen | GW_001D8C0EF7D9_proxy das eingebe bekomme ich die Werte der Readings.
Für kann man auch alles andere nutzen mit dem selben Effekt.
Vielen Dank für deine Erweiterung Markus.
Ich habe damit bereits drei Mobile Alerts Sensoren erfolgreich eingebunden.
Ich hab aber noch einen unbekannten Sensortyp, den Luftgütemonitor WL2000 von Technoline. (Die ID des Sensors fängt mit 05 an.)
Der liefert die Innentemperatur, die Luftfeuchte Innen, eine Angabe für die Luftgüte in PPM (co2 äquivalent). Des Weiteren verfügt der Luftgütemonitor über einen Außensensor, der Temperatur misst.
Ein Beispiel für eine empfangene lastMsg ist "da5a50e9eb1e[ID]1f37404180d70a330009404500d20a34000917000000000000000000000000000000000000000000000000000000000000000036"
Die Temperaur des Außensenders (6,5°C) wird korrekt dekodiert, aber als Innentemperatur angezeigt.
Die Werte für die Innentemperatur 21,5°C, Luftfeuchte Innen (51%) und CO2 äquivalent (450ppm) werden nicht dekodiert.
Eine Dokumentation liegt im Github zu diesem Sensor leider nicht vor, ich hab aber mal versucht herauszufinden, welche Angaben wie kodiert sind:
Bytes 0 und 1 sind mit Sicherheit der transmission counter,
Bytes 2 und 3 sind die Außentemperatur in 1/10 °C
Bytes 4 und 5 sind die Innentemperatur in 1/10 °C
Bytes 6 und 7 sind die Luftfeuchte Innen (ohne Nachkommastellen)
Bytes 8 und 9 CO2 Äquivalent in 1/50 PPM (die 450 ppm werden also als 9 kodiert)
Bytes 10 und 11 Außentemperatur vorher
Bytes 12 und 13 Innentemperatur vorher
Bytes 14 und 15 Luftfeuchte innen vorher
Wie bei den anderen Sensoren in der Dokumentation werden jeweils nur die letzten Bits eines Words verwendet.
Über eine Aufnahme des Sensors in deine Erweiterung würde ich mich sehr freuen.
Viele Grüße,
Michael
Hallo Michael (roemmic9),
danke für die Informationen und die Analyse soweit. Damit war das Einbinden des WL2000 leicht. Es sollte dann morgen irgendwann im normalen fhem "update" sein. Für Ungeduldige: update all https://markusfeist.github.io/FhemMobileAlerts/repository/master/controls_mobilealerts.txt.
Hallo Michael,
wegen dem stateFormat. An sich habe ich in meinem Modul dort gar nichts programmiert ;). Es nutzt dort die normalen fhem Funktionen. Allerdings da ich dort nichts gefunden habe, was das auslösen kann, will ich es bei mir nachstellen.
Allerdings wenn ich bei mir folgendes im stateFormat setze:
"GW_001D8C0E1EEF_lastSeen | GW_001D8C0E1EEF_proxy"
kommt als STATE raus:
"2018-01-07 17:26:19 | on"
Deine Schilderung würde aber ein Ergebnis "on" im State bedeuten.
Kannst du mir daher ein "list" vom Gateway schicken, also die Ausgabe von "list <Gatewayname>", wenn das stateFormat gesetzt ist.
Viele Grüße
Markus
Moin MarkusF
Internals:
CFGFN /opt/fhem/cfg/MobileAlert.cfg
DEF 8085
FD 13
NAME MobileAlertsGateway
NR 582
PORT 8085
STATE on | 2018-01-08 13:56:47
TYPE MOBILEALERTSGW
READINGS:
2018-01-04 16:21:55 GW_001D8C0EF7D9_config 0003001d8c0ef7d900ba00c0a8b20501c0a8b205ffffff00c0a8b2014d4f42494c45414c455254532d47617465776179007777772e646174613139392e636f6d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013139322e3136382e3137382e33000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f95c0a8b201
2018-01-04 13:45:29 GW_001D8C0EF7D9_ip 192.168.178.5
2018-01-08 13:56:47 GW_001D8C0EF7D9_lastSeen 2018-01-08 13:56:47
2018-01-04 13:45:29 GW_001D8C0EF7D9_proxy on
2018-01-04 13:45:29 GW_001D8C0EF7D9_proxyname 192.168.178.3
2018-01-04 13:45:29 GW_001D8C0EF7D9_proxyport 8085
2018-01-04 13:51:06 GW_001D8C0EF7D9_serial 800EF7D9
2018-01-04 13:45:29 Gateways 001D8C0EF7D9
Attributes:
forward 1
group SystemTelemetrie
room System
stateFormat GW_001D8C0EF7D9_proxy | GW_001D8C0EF7D9_lastSeen
Bitte schön, Gerne
Habe stateFormat der Optik :) wegen umgetauscht, das Spielt aber keine Rolle.
Hallo Michael,
habe die Stelle gefunden. Es betrifft quasi jedes State (egal von welchen Modul), dass ein Blank beinhaltet und dessen Inhalt mit einem Wert für ein Icon beginnt.
(Deswegen konnte ich es auch nicht nachstellen, ich hatte es mit "GW_001D8C0EF7D9_lastSeen | GW_001D8C0EF7D9_proxy" probiert. Der "Fehler" tritt aber nur bei "GW_001D8C0EF7D9_proxy | GW_001D8C0EF7D9_lastSeen" auf.)
Die Ursache ist in der 01_FHEMWEB.pm in der Funktion "sub FW_dev2image($;$)". Dort wird bei der Suche nach dem Icon in Zeile 2701 der Befehl:
$state =~ s/ .*//; # Want to be able to have icons for "on-for-timer xxx"
aufgeführt. Im Prinzip heißt es für die Iconsuche, ignoriere alles nach dem ersten Blank. Also aus "on | 2018-01-08 13:56:47" wird "on". Deswegen klappt " GW_001D8C0EF7D9_proxy | GW_001D8C0EF7D9_lastSeen" ein Icon " " gibt es nicht. Dem Kommentar nach ist es sogar Absicht.
Ich würde vorschlagen es einfach mit "GW_001D8C0EF7D9_proxy | GW_001D8C0EF7D9_lastSeen" zu machen oder devStateIcon mit ".*:gibtsnicht" oder was ähnlichen zu belegen. Das erste führt dazu, das nach "on ..." gesucht wird und das zweite, dass nach einem Icon "gibtsnicht" gesucht wird. Wenn kein Icon gefunden wird, wird einfach der Text angezeigt.
Viele Grüße
Markus
Hallo Markus,
vielen Dank für die Integration des WL2000. Es funktioniert alles prima.
Gruß,
Michael
Hallo Markus!
Nur der Vollständigkeit halber:
Auch der Sensor MA10101 (Kabeltemperatursensor) funktioniert tadellos. Wird als MA 10100 ausgewiesen.
Danke und LG
Danke für die Info. Ich habe gerade die Dokumentation und das Reading DeviceType geupdated. Allerdings lade ich das erst mit der nächsten Änderung mit hoch. (Klappt ja auch ohne Anpassung.)
Viele Grüße
Markus
Moin MarkusF
Ich habe einen Wunsch wenn möglich.
Kannst du beim Windmesser MA10660
den Dezimalwert für die Windrichtung
in ein Reading mit zu Verfügung stellen.
Hallo Michael,
kein Problem. Ich habe es gerade ins svn hochgespielt (hatte noch ein paar andere kleine Änderungen). Der neue Wert heißt directionInt. Es sollte morgen irgendwann per update verfügbar sein. Eine neugierige Frage muss ich aber stellen, was ist der Anwendungsfall.
Viele Grüße
Markus
Moin MarkusF
Vielen Dank für die schnelle Unsetzung.
ZitatEine neugierige Frage muss ich aber stellen, was ist der Anwendungsfall.
Ich hatte unter Fhem versucht, eine nach meinen Wünschen Oberfläche auf mein Tablet zu Zaubern :).
Nun versuche ich es mit ioBroker und das Widget für die Windrichtung verlangt einen Zahlenwert.
Hallo MarkusF
Bin mir nicht ganz Sicher. :-[
Stimmt denn der directionInt Wert?
sh Anlage
Zitat von: Michael am 07 Februar 2018, 07:17:54
Moin MarkusF
Vielen Dank für die schnelle Unsetzung.
Ich hatte unter Fhem versucht, eine nach meinen Wünschen Oberfläche auf mein Tablet zu Zaubern :).
Nun versuche ich es mit ioBroker und das Widget für die Windrichtung verlangt einen Zahlenwert.
Du musst directionInt nehmen und mit 22.5 (glaube ich) multiplizieren...
Gesendet von meinem SM-G935F mit Tapatalk
Moin RoBra81
ZitatDu musst directionInt nehmen und mit 22.5 (glaube ich) multiplizieren...
Das stimmt, habe Ich jetzt auch mit einem userReading (directionDegree) umgesetzt.
In meinem Wunsch vom 06.Feb.2018 hatte ich mich Falsch ausgedrückt.
Hatte eigendlich die Gradzahl gemeint.
Ist mein Fehler.
Sorry!
Hallo,
stimmt directionInt ist quasi der direkte Zahlenwert vom Sensor (0 = N, 1 = NNO, 2 = NO, 3 = ONO, 4 = O, ..., 12 = W, 13 = WNW, 14 = NW, 15 = NNW). Im Prinzip alle 22,5 Grad plus eins. Wenns mit userReading klappt, würde ich es dann so lassen.
Viele Grüße
Markus
Hallo guten Morgen,
wie auf Seite 2 dieses Posts habe ich bei dem Anlegen ebenfalls Probleme mit dem Modul.
Ich habe mit update 50_MOBILEALERTSGW.pm und update 51_MOBILEALERTS.pm die Module in FHEM geladen und einen Neustart gemacht. In der App habe ich den Proxy aktiviert und ihm den Port 8006 zugewiesen. Danach einen Neustart des GW durchgeführt. Die grüne LED blinkt dauerhaft ab und zu die rote. Es werden seit dem aktivieren des Proxy keine Daten mehr an die App gesendet. Nach dem Anlegen in FHEM erhalte ich nun folgenden Fehler:
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Initialize redefined at ./FHEM/50_MOBILEALERTSGW.pm line 20.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Define redefined at ./FHEM/50_MOBILEALERTSGW.pm line 41.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_GetUDPSocket redefined at ./FHEM/50_MOBILEALERTSGW.pm line 52.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Get redefined at ./FHEM/50_MOBILEALERTSGW.pm line 89.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Set redefined at ./FHEM/50_MOBILEALERTSGW.pm line 145.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Undef redefined at ./FHEM/50_MOBILEALERTSGW.pm line 264.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Attr redefined at ./FHEM/50_MOBILEALERTSGW.pm line 280.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Fingerprint redefined at ./FHEM/50_MOBILEALERTSGW.pm line 295.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Write redefined at ./FHEM/50_MOBILEALERTSGW.pm line 303.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_Read redefined at ./FHEM/50_MOBILEALERTSGW.pm line 312.
2018.05.10 09:02:22 1: PERL WARNING: Subroutine MOBILEALERTSGW_NonblockingGet_Callback redefined at ./FHEM/50_MOBILEALERTSGW.pm line 495.
2018.05.10 09:02:22 1: reload: Error:Modul 50_MOBILEALERTSGW deactivated:
Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
2018.05.10 09:02:22 0: Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
2018.05.10 09:04:09 1: reload: Error:Modul 50_MOBILEALERTSGW deactivated:
Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
2018.05.10 09:04:09 0: Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
Kann mir jemand mit diesem Fehler helfen?
Viele Grüße Marko
Der Fehler:
Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
spricht dafür, dass eine alte TcpServerUtils.pm (vor irgendwann Juli letzten Jahres) im System ist. (Die andere Möglichkeit, dass sich die TcpServerUtils.pm geändert hat, kann ich ausschließen, da ein vorhin angestoßener CI Lauf von meinem Modul erfolgreich war.) Dies kann man einfach mit update check prüfen. Ich würde dann zu einem generellen
update
ohne Parameter und anschließenden
shutdown restart
raten, da die TcpServerUtils.pm auch von anderen Modulen (ich meine auch fhem Web) genutzt wird und ein update TcpServerUtils.pm zu einem unnutzbaren System führen könnte.
Viele Grüße
Markus
Zitat von: MarkusF am 11 Mai 2018, 05:58:40
Der Fehler:
Too many arguments for main::TcpServer_Close at ./FHEM/50_MOBILEALERTSGW.pm line 530, near "1 )"
spricht dafür, dass eine alte TcpServerUtils.pm (vor irgendwann Juli letzten Jahres) im System ist. (Die andere Möglichkeit, dass sich die TcpServerUtils.pm geändert hat, kann ich ausschließen, da ein vorhin angestoßener CI Lauf von meinem Modul erfolgreich war.) Dies kann man einfach mit update check prüfen. Ich würde dann zu einem generellen
update
ohne Parameter und anschließenden
shutdown restart
raten, da die TcpServerUtils.pm auch von anderen Modulen (ich meine auch fhem Web) genutzt wird und ein update TcpServerUtils.pm zu einem unnutzbaren System führen könnte.
Viele Grüße
Markus
Danke für den Hinweis. Es läuft nun wie geplant!
Danke für das Modul und Deine Arbeit.
Marko
Hallo,
ich habe Probleme das Modul in FHEM einzurichten.
Welchen Port muß ich benutzen??
Mein FHEM läuft unter der IP 192.168.25.4 an Port 8083.
In der Mobilealerts APP wird mir Port 8003 für den Gateway angezeigt. Ist das der Port den ich nehmen muß?
define MobileAlertsGateway MOBILEALERTSGW 8003
Vielleicht kann mir einer bei der Frage helfen.
Danke.
Hallo,
der Port ist egal. Er muss halt auf dem Rechner frei sein und dem Gateway als Proxyserverport mitgeteilt werden. Wenn fhem nicht als root läuft (und man nichts in der Systemkonfiguration ändern will) sollte man keine Nummer kleiner 1024 nehmen.
Die Konfiguration im Gateway erfolgt entweder über die App oder nachdem das Modul eingerichtet ist mit:
get <Modulname> config
set <Modulname> initgateway <Gateway ID aus den Readings>
set <Modulname> rebootgateway <Gateway ID>
Rein technisch macht das Modul nichts anderes wie einen Server auf dem Port zu starten. Daher ist dieser egal, muss halt dann auf dem Gateway gleich sein, damit dieses dann den Server auch anspricht.
Man kann also 8003 nehmen und sollte man hier auch. Es würde die weitere Konfiguration mit den set-Befehlen sparen, da der fhem-Server auch schon als Proxyserver IP eingetragen ist.
Viele Grüße
Markus
Hallo Markus,
ich glaube ich weiß, warum es bei mir nicht funktioniert.
Ich betreibe mein FHEM in einem Synology Docker Container.
Da hat FHEM die 172.17.0.3 und das wird durch die Port-Eintellungen irgendwie in das Hautptnetz (bei mir 192.168.25.xxx) weitergereicht. Ich habe den Port 8003 auch entsprechend hinzugefügt und im MobileAlerts-Gateway die 172.17.0.3 (mein FHEM) eingetragen. Aber vermutlich geht das so doch nicht.
Hast du dazu vielleicht auch eine Idee??
Gruß Andreas
Habe mal den thread überflogen.
Man braucht immer noch das MA Gateway?
Nicht zu empfangen mit nem cul für 868Mhz?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Hallo Andreas,
wenn da noch ein Docker Container zwischen ist (leider habe ich keine Synology und kann es so nicht Schritt für Schritt sagen), muss man folgendes machen:
- Auf der Synology einen Port in den Docker Container zu 8003 aufmachen
- Mit der App das Gateway auf die Synology mit dem Port der Synology aufmachen
Als Test kann man mal von einem Rechner außerhalb der Synology ein:
telnet <Synology-IP> <Port> machen. Dort einfach mal:
GET / HTTP/1.1<Enter><Enter> eingeben.
Es sollte so etwas rauskommen:
mf@client:~$ telnet 192.168.1.2 8090
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Connection closed by foreign host.
Die Konfiguration des Gateways vom Modul aus, scheidet dabei leider aus (bzw. wäre kompliziert freizuschalten), da dafür UDP Aufrufe und Broadcasts verwendet werden, um die Gateways zu finden und einzustellen.
Hallo Sascha,
ja man braucht für das Modul des Gateway, bzw. anders gesagt das Modul setzt das Gateway voraus.
Man kann ggf. das entschlüsselte Protokoll nutzen (es sieht ziemlich Hardwarenah aus, mich würde wundern, wenn es ganz anders aussehen würde), aber leider weiß ich nicht, wie man Funkverkehr entsprechend mitschneiden und entschlüsseln kann.
Wenn es dafür ein gutes Tutorial gibt, würde ich es durchaus mal probieren. Seit Donnerstag habe ich auch eine NanoCul (als Ersatz für ein MAX Lan Gateway).
Viele Grüße
Markus
Hallo Markus,
das mit dem Port habe ich ja schon eingestellt.
Mein Telent Test ergibt die gleichen Werte wie bei dir.
Mein Testsensor wird auch automatisch in FHEM erstellt.
Es kommen aber keine neuen Werte im Sensor an.
Der actStatus steht auf switchedOff. Das ist irgendwie komisch.
Das MobileAlerts Gateway kann ich ja über die iPhone App konfigurieren.
Hast du noch einen Tip?
Gruß Andreas
Zitat von: MarkusF am 10 Juni 2018, 15:15:04
Hallo Andreas,
wenn da noch ein Docker Container zwischen ist (leider habe ich keine Synology und kann es so nicht Schritt für Schritt sagen), muss man folgendes machen:
- Auf der Synology einen Port in den Docker Container zu 8003 aufmachen
- Mit der App das Gateway auf die Synology mit dem Port der Synology aufmachen
Als Test kann man mal von einem Rechner außerhalb der Synology ein: telnet <Synology-IP> <Port> machen. Dort einfach mal: GET / HTTP/1.1<Enter><Enter> eingeben.
Es sollte so etwas rauskommen:
mf@client:~$ telnet 192.168.1.2 8090
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Connection closed by foreign host.
Die Konfiguration des Gateways vom Modul aus, scheidet dabei leider aus (bzw. wäre kompliziert freizuschalten), da dafür UDP Aufrufe und Broadcasts verwendet werden, um die Gateways zu finden und einzustellen.
Hallo Sascha,
ja man braucht für das Modul des Gateway, bzw. anders gesagt das Modul setzt das Gateway voraus.
Man kann ggf. das entschlüsselte Protokoll nutzen (es sieht ziemlich Hardwarenah aus, mich würde wundern, wenn es ganz anders aussehen würde), aber leider weiß ich nicht, wie man Funkverkehr entsprechend mitschneiden und entschlüsseln kann.
Wenn es dafür ein gutes Tutorial gibt, würde ich es durchaus mal probieren. Seit Donnerstag habe ich auch eine NanoCul (als Ersatz für ein MAX Lan Gateway).
Viele Grüße
Markus
Hallo Markus.
Dank dir die Antwort.
So aus dem Bauch heraus gedacht :
Ich glaube nicht, dass die die Sensorenhardware neu erfinden werden.
Ich denke, dass die evtl. Nur am auftrat was gemacht haben.
Man kann den nano cul in einem Modus schalten (set raw x...), wo der in Event Monitor dir alles ungefiltert raus schmeißt. Der nano cul muss aber im slowrf Modus laufen.
Es muss natürlich noch die frequenz passen (433/868).
Wobei ich denke, ohne jetzt nachgelesen zu haben, dass die ma Sensoren auf 868Mhz arbeiten, so wie die LaCrosse Sensoren.
Gruß Sascha
Nachtrag :technoline LaCrosse arbeitet mit nem jeelink bzw LaCrosse Gateway. Vielleicht braucht man das.
Zitat von: ottoplanet am 10 Juni 2018, 17:57:04
Hallo Markus,
das mit dem Port habe ich ja schon eingestellt.
Mein Telent Test ergibt die gleichen Werte wie bei dir.
Mein Testsensor wird auch automatisch in FHEM erstellt.
Es kommen aber keine neuen Werte im Sensor an.
Der actStatus steht auf switchedOff. Das ist irgendwie komisch.
Das MobileAlerts Gateway kann ich ja über die iPhone App konfigurieren.
Hast du noch einen Tip?
Gruß Andreas
Hallo Markus,
jetzt geht es bei mir doch.
Vielen Dank für die Mühe.
Gruß Andreas
Moin MarkusF
Ich hätte einen Vorschlag. :-[
Könntest du für die Temperatur und Luftfeuchtigkeit in der Form (currTemp/currHum)
bei den Attributes oder Internals mit aufnehmen?
Hallo,
technisch möglich wäre es. Aber als Attribut wäre es total unpassend. Einmal sind Attribute eher was für die Konfiguration, zusätzlich würde jede Änderung dort ein save nötig machen und die Werte landen in der fhem.cfg, wo die nicht hingehören.
Internals wäre denkbar, allerdings ich sehe es eher als interne Werte an und gesichert werden die auch nicht.
Also ist in meinen Augen readings der richtige Ort. Und auch https://wiki.fhem.de/wiki/DevelopmentModuleIntro (https://wiki.fhem.de/wiki/DevelopmentModuleIntro) im Wiki gibt mir recht:
ZitatDaten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt. Sie geben den Status des Gerätes wieder und erzeugen Events innerhalb von FHEM auf die andere Geräte reagieren können.
In Bezug auf die beiden Werte habe ich dort aber ein Problem mit dem Mehrwert. Die Readings temperature und humidity geben an sich genau das wieder.
Ein Mehrwert in Bezug auf eine Vereinheitlichung sehe ich dort auch nicht. Ich habe mich dort gerade an vorhandene Namen angelehnt (z.B. von MAX und Homematic). Das sieht man auch gut daran, dass das Modul dewpoint (https://wiki.fhem.de/wiki/Dewpoint (https://wiki.fhem.de/wiki/Dewpoint)) ohne Probleme sofort lief.
Also ist mir kein Grund ersichtlich, warum ich es anpassen sollte (und ohne Grund will ich Werte nicht doppelt ausgeben).
Viele Grüße
Markus
Moin MarkusF
Vielen Dank für deine Ausführung.
Zitat... (und ohne Grund will ich Werte nicht doppelt ausgeben).
An doppelte Werte hatte ich auch nicht gedacht.
ZitatIch habe mich dort gerade an vorhandene Namen angelehnt (z.B. von MAX und Homematic). Das sieht man auch gut daran, dass das Modul dewpoint (https://wiki.fhem.de/wiki/Dewpoint) ohne Probleme sofort lief.
Auch bei den LaCrosse Device läuft das dewpoint Modul ohne Probleme.
Nur zum bessen Verständnis.
Der Vorschlag war in Anlehnung der LaCrosse Device gedacht.
ZitatInternals wäre denkbar, allerdings ich sehe es eher als interne Werte an und gesichert werden die auch nicht.
Dort gibt es die möglichkeit, sh. Auszug der Commandref.
Zitat
Define
define <name> LaCrosse <addr> [corr1...corr2]
addr is a 2 digit hex number to identify the LaCrosse device.
corr1..corr2 are up to 2 numerical correction factors (corr1 for the temperature and corr2 for the humidity), which will be added to the respective value to calibrate the device.
Das soll jetzt aber
kein Versuch des Überreden's sein, sondern nur eine Erklärung meines Vorschlag's.
Ach so: corr... zur Korrektur von Werten, nicht curr... für den aktuellen Wert.
Dafür könnte es tatsächlich Anwendungsfälle geben, wäre auch nicht doppelt. Im Define bzw. Attributen wäre das auch der richtige Platz, wenn es Lacrosse im Define macht, mache ich es auch so, es werden allerdings mindestens vier Werte (jeweils zwei für In und Out). Mal schauen, was sich dort am Wochenende machen lässt.
Viele Grüße
Markus
Die Änderung ist ins svn von fhem eingecheckt. Sollte morgen an sich per update abrufbar sein.
Der define ist um bis zu vier optionale Werte (corrTempIn, corrHumIn, corrTempOut, corrHumOut) erweitert.
Viele Grüße
Markus
Hallo,
habe folgendes TFA-Gerät das zwar erkannt wird aber nicht ausgewertet werden kann.
Es handelt sich um TFA 30.3060.01.IT. Es zeigt 4x Temp und 4x Feuchtigkeit an und funktioniert natürlich an App und Gateway.
lstMsg: ea5b77c3a72e1135b8017d8712fb00ee083c00bc085100c7084b00eb083c00ee083c00bc085100c7084b00eb083c1b000000000000000000000000000000001f
DeviceType:
Unknown - 11 ea
wird erkannt als MA_1135b8017d87
Werte aus der App:
ID
1135B8017D87
Zeitpunkt
18.08.2018 08:58:47
Temp In
23,5 C
Hum In
60%
Temp 1
23,8 C
Hum 1
60%
Temp 2
18,8 C
Hum 2
81%
Temp 3
19,9 C
Hum 3
75%
vielleicht kann man das ja noch einbinden. Besten Dank!
Moin MarkusF
Und auch ich habe noch einen MA10120Pro der hinzugefügt werden könnte?
Zitat
deviceType Unknown - 01 d2
lastMsg d25b784fe8160104b30513ee000241058f23811627ff1bc01228d3b0142bd3c00e32d3c01735d300000000000000000000000000000000000000000000000043
Hallo,
rüste ich gerne nach. Ich bin allerdings aktuell im Urlaub unterwegs und habe keine Entwicklungsumgebung dabei, daher wird es mindestens eine Woche dauern.
Viele Grüße
Markus
Moin MarkusF
Keine Panik.
Einen schönen Urlaub, das geht auf alle Fälle vor.
Zitat von: Girgl am 18 August 2018, 09:09:38
Hallo,
habe folgendes TFA-Gerät das zwar erkannt wird aber nicht ausgewertet werden kann.
Es handelt sich um TFA 30.3060.01.IT. Es zeigt 4x Temp und 4x Feuchtigkeit an und funktioniert natürlich an App und Gateway.
Hallo,
ich habe auch so einen TFA 30.3060.01.IT und bereits zum laufen gebracht. Nun habe ich aber keine Ahnung, wie ich die erweiterte Datei "unter die Leute" bringen kann.
Sie hängt nun an diesem Post.
Viele Grüße,
Henning
Hallo Henning,
habe Deine Datei gerade gegen das vorhandene getauscht und schon läuft es. VIELEN DANK für die Arbeit. Ist es Absicht dass im Logfile die lstMsg mitgeloggt wird. Bei den anderen MobileAlerts ist das nicht der Fall.
Ist es eigentlich möglich die bisher aufgelaufenen und nicht dechiffrierten Daten, nachträglich zu dechiffrieren?
Auszug aus dem Logfile...
2018-08-25_22:55:14 MA_1135b8017d87 txCounter: 6418
2018-08-25_22:55:14 MA_1135b8017d87 temperature1: 22.8
2018-08-25_22:55:14 MA_1135b8017d87 temperatureString1: 22.8°C
2018-08-25_22:55:14 MA_1135b8017d87 temperatureIn: 22.6
2018-08-25_22:55:14 MA_1135b8017d87 temperatureStringIn: 22.6°C
2018-08-25_22:55:14 MA_1135b8017d87 humidityIn: 58
2018-08-25_22:55:14 MA_1135b8017d87 humidityStringIn: 58%
2018-08-25_22:55:14 MA_1135b8017d87 In T: 22.6 H: 58 1 T: 22.8 H: 58 2 T: 18.9 H: 83 3 T: 19.7 H: 78
2018-08-25_22:55:14 MA_1135b8017d87 lastMsg: ea5b81c2322e1135b8017d87191200e4083a00bd085300c5084e00e2083a00e5083a00bd085300c5084e00e108391a0000000000000000000000000000000029
2018-08-25_22:55:14 MA_1135b8017d87 lastRcv: 2018-08-25 22:55:14
2018-08-25_23:02:17 MA_1135b8017d87 txCounter: 6419
2018-08-25_23:02:17 MA_1135b8017d87 lastMsg: ea5b81c3d92e1135b8017d87191300e4083a00bd085300c5084e00e2083a00e4083a00bd085300c5084e00e2083a1a0000000000000000000000000000000053
2018-08-25_23:02:17 MA_1135b8017d87 lastRcv: 2018-08-25 23:02:17
2018-08-25_23:09:16 MA_1135b8017d87 txCounter: 6420
2018-08-25_23:09:16 MA_1135b8017d87 temperatureIn: 22.5
2018-08-25_23:09:16 MA_1135b8017d87 temperatureStringIn: 22.5°C
2018-08-25_23:09:16 MA_1135b8017d87 In T: 22.5 H: 58 1 T: 22.8 H: 58 2 T: 18.9 H: 83 3 T: 19.7 H: 78
2018-08-25_23:09:16 MA_1135b8017d87 lastMsg: ea5b81c57c2e1135b8017d87191400e4083a00bd085300c5084e00e1083a00e4083a00bd085300c5084e00e2083a1b0000000000000000000000000000000079
2018-08-25_23:09:16 MA_1135b8017d87 lastRcv: 2018-08-25 23:09:16
2018-08-25_23:16:15 MA_1135b8017d87 txCounter: 6421
2018-08-25_23:16:15 MA_1135b8017d87 temperatureIn: 22.4
2018-08-25_23:16:15 MA_1135b8017d87 temperatureStringIn: 22.4°C
2018-08-25_23:16:15 MA_1135b8017d87 humidityIn: 59
2018-08-25_23:16:15 MA_1135b8017d87 humidityStringIn: 59%
2018-08-25_23:16:15 MA_1135b8017d87 In T: 22.4 H: 59 1 T: 22.8 H: 58 2 T: 18.9 H: 83 3 T: 19.7 H: 78
2018-08-25_23:16:15 MA_1135b8017d87 lastMsg: ea5b81c71f2e1135b8017d87191500e4083a00bd085300c5084e00e0083b00e4083a00bd085300c5084e00e1083a1a000000000000000000000000000000001d
2018-08-25_23:16:15 MA_1135b8017d87 lastRcv: 2018-08-25 23:16:15
Moin Heng
Das ist nicht gerade Super hier eine geänderte Version Anzuhängen.
Besser wäre es gewesen wenn du deine Änderungen MarkusF mitteilst,
da er der Modulautor ist.
Das verhindert,
1. das es hier Unterschiedliche Version gibt.
2. deine Ergänzungen beim nächsten Update verloren geht,
es sei denn man schliesst die MobileAlerts.pm aus.
Etwas Zeit hat doch jeder bis MarkusF soweit ist. ;)
Hallo Michael, Hallo Markus,
ja, das war blöd von mir und ich bereue es auch schon sehr.
Mein Beweggrund war folgender:
Ich habe Fhem erst vor ein paar Monaten entdeckt und bin sofort aus Markus' Modul gestoßen. Da ich die App von MobileAllerts bzw TFA nicht besonders gelungen finde war ich sehr froh, dass es diese gelungene Alternative gibt.
Nach kurzer Zeit wurde ich gierig und wollte alle meine Sensoren in das System einbinden. So habe ich schließlich den TFA 30.3060.01.IT für mich lokal hinzugefügt. Später stieß ich dann auf diesen Thread und sah, dass offensichtlich auch Andere so eine Erweiterung suchen. Und habe die Datei ins Forum gestellt.
Leider hatte ich nicht bemerkt, dass Markus bereits eine neue Version von 51_MOBILEALERTS.pm veröffentlicht hatte. Meine Änderung basierte auf Version 16104 2018-02-06 19:11:13 und funktionierte ohne Probleme. So habe ich mir gestern "auf die Schnelle" ein Fhem-Update durchgeführt und meine Erweiterung dort eingepflegt und offensichtlich nicht genug getestet.
Ja nun steht sie da im Forum und ich würde sie am liebsten wieder zurück holen. Aber nun ist die Büchse der Pandora nun mal offen.
Das Phänomen, was Girgl beobachtet, ich meine die getraceten Raw-Daten lastMsg, tritt bei mir nicht auf. Ist es möglich, dass Du das Attribut lastMsg auf 1 gesetzt hast?
Bei mir macht das neue Feature mit corrTemp... und corrHum... ein paar Warnings im LogFile.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 710.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 715.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 720.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 724.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 727.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 730.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 250.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 254.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 652.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 656.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 660.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 664.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 668.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 672.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 308.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 312.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 316.
2018.08.26 11:30:57 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 319.
Die Warnings kommen direkt nach shutdown restart. Da corrTemp... und corrHum... ja optional sein sollen habe ich diese Parameter in der Definition nicht gesetzt. Habt Ihr auch solche Meldungen?
Viele Grüße,
Henning
Hallo Henning,
ja lstMsg war auf 1 gesetzt.
Und... (Auszug aus Logfile)
2018.08.26 22:54:41 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4552.
2018.08.26 22:58:26 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 308.
2018.08.26 22:58:26 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 312.
2018.08.26 22:58:26 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 316.
2018.08.26 22:58:26 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 319.
2018.08.26 22:58:26 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 652.
2018.08.26 22:58:27 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 656.
2018.08.26 22:58:27 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 660.
2018.08.26 22:58:27 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 664.
2018.08.26 22:58:27 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 668.
2018.08.26 22:58:27 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/51_MOBILEALERTS.pm line 672.
...habe ich auch. Bin absoluter Neuling und kann Dir bei der Fehlersuche leider nicht weiter helfen.
Im Übrigen bin ich der Meinung dass Du nicht wirklich was falsch gemacht hast. Du hast deutlich darauf hingewiesen, dass die Datei ein erweitertes Original und somit nicht vom "fhem-feed" stammt. Das es bei Updates überschrieben wird sollte jedem Nutzer klar sein. Mir hat's weitergeholfen.
Mfg
Hallo,
die PERL Warnings sind mein Fehler. Ich habe den gerade korrigiert. Er hat sich aber auch nur auf die Logs ausgewirkt, deswegen haben meine automatischen Tests nichts gefunden. Ebenfalls habe ich den TFA30.3060.01.IT eingebaut. Es ist fast nur eine Kopie von Girgls Code. Danke für die Zulieferung.
Die Änderungen habe ich soeben ins svn eingecheckt. Sollte morgen früh verfügbar sein.
Für Ungeduldige kann man die Version schon jetzt mit:
update all https://markusfeist.github.io/FhemMobileAlerts/repository/master/controls_mobilealerts.txtziehen.
Sobald ich den MA10120Pro drin habe, werde ich für die Dokumentation hier: https://github.com/sarnau/MMMMobileAlerts (https://github.com/sarnau/MMMMobileAlerts) einen Pull-Request machen.
Ansonsten wenn man Erweiterungen hat, hat es sich hier wohl eingebürgert Diffs zu schicken.
Für mich gerne auch angepasste Module oder Pull-Requests gegen den Branch Develop auf https://github.com/markusfeist/FhemMobileAlerts (https://github.com/markusfeist/FhemMobileAlerts).
Wenn man es hier nicht veröffentlichen will, gerne auch als PM.
Wegen dem MA10120Pro bräuchte ich noch Hilfe.
Den Rahmen habe ich soweit schon gebaut.
Allerdings mit den Werten habe ich Probleme. Wenn ich die Message:
d25b784fe8160104b30513ee000241058f23811627ff1bc01228d3b0142bd3c00e32d3c01735d300000000000000000000000000000000000000000000000043
wie gewohnt zerlege. (Unter Berücksichtigung, dass der MA10120PRO zwei Tempereaturwerte liefern müsste.)
Bekomme ich die Temperaturen:
26,1 Grad Innen (ist ja noch OK),
-22,1 Grad Außen(??),
27,8 Grad Innen letzter Wert (ein bißchen schneller Wechsel),
Overflow Außen letzter Wert (könnte stimmen, da zweiter Messwert, aber eher unwahrscheinlich)
(Im Detail:
d2=Packet Header
5b784fe8=Timestamp
16=Packet Länge
0104b30513ee = ID
0002 = Tx Counter
4105 = 26,1
8f23 = -22.1
8116 = 27,8
27ff = Overflow
...=vermutlich "Schrott" (ist bei vielen Sensoren so)
43 = Prüfsumme)
Daher würde ich Tippen:
26,1 Grad Innen
27,8 Grad Außen
stimmt das? (Also mit der App überein?)
Ich bräuchte also die Werte zu der Message damals (2018-08-18 18:57:12) oder eine andere Message mit den passenden Werten aus der App.
Ansonsten "lastMsg" wird automatisch geloggt, wenn das Gerät nicht bekannt ist. Um den (ggf. damals gelogten) Wert loszuwerden einfach:
set <Modulename> clear readingsausführen. Dann werden alle Readings gelöscht. (Beim nächsten Empfang sind diese dann wieder da.)
Wegen der bisher aufgelaufenen Messages:
Das Modul MobileAlerts (also das das Gateway darstellt) hat eine undokumentierte Funktion:
set <Gateway> debuginsert <Msg>Also z.B.:
set MAGateway debuginsert ea5b77c3a72e1135b8017d8712fb00ee083c00bc085100c7084b00eb083c00ee083c00bc085100c7084b00eb083c1b000000000000000000000000000000001fDiese Funktion benutzte ich für die Durchführung von automatisierten Tests. Man könnte also die Messages alle aus der Log-Datei rausziehen und dann per Skript über das Telnet Interface vom FHEM einfügen z.B. mit
perl /opt/fhem/fhem.pl 7072 "set MAGateway debuginsert ea5b77c3a72e1135b8017d8712fb00ee083c00bc085100c7084b00eb083c00ee083c00bc085100c7084b00eb083c1b000000000000000000000000000000001f". Da der Timestamp aus der Message genommen wird, wird auch in der Logdatei der richtige Zeitpunkt gespeichert.
Allerdings ergeben sich folgende Nachteile:
- Das Modul zeigt natürlich bis zum nächsten richtigen Wert dann einen alten Wert an
- Die Protokolldatei ist danach ggf. falsch sortiert (also alte Timestamps ggf. vor aktuellen). Hier muss man dann noch korrigieren
Viele Grüße
Markus
Moin MarkusF
ZitatBekomme ich die Temperaturen:
26,1 Grad Innen (ist ja noch OK),
-22,1 Grad Außen(??),
Das stimmt so schon, habe nämlicht den Temp Sensor gegen einen LDR Sensor getauscht. :-[
LDR Sensor : https://www.elektronik-kompendium.de/sites/bau/0110301.htm (https://www.elektronik-kompendium.de/sites/bau/0110301.htm)
Aber werde am Freitag od. Samstag mit einem Orginal MA10120Pro die Msg hier einstellen.
Natürlich noch mit den alten Modul.
Schon mal Vielen Dank.
Hallo Michael,
ist nicht unbedingt nötig. Ich fand halt nur die Werte unplausibel, aber sie waren ja doch richtig. Ansonsten würden ich die Werte dafür verwenden den Testfall für den Sensor auszubauen.
Ich habe gerade die Anpassung ins svn gebracht. Morgen früh wäre dann auch der MA10120PRO drin.
Viele Grüße
Markus
Hallo Markus,
ich habe ein kleines Problem mit meinem MA10320PRO. Der Kabelsensor ist für einen Temperaturbereich -50.0°C bis +110.0°C spezifiziert https://files.elv.com/Assets/Produkte/11/1190/119083/Downloads/119083_ma_10320_proseries_um.pdf (https://files.elv.com/Assets/Produkte/11/1190/119083/Downloads/119083_ma_10320_proseries_um.pdf).
Den Sensor betreibe ich knapp oberhalb 100°C. Leider wird in Fhem dann eine negative Temperatur angezeigt.
2018-10-07 14:01:37 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 24.1 H: 46 Out T: -100.1
2018-10-07 14:01:37 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f4741a0922c90102d0385b00f184170a2e00ef440d0a2e0de7083500670851006e0850008f084500e608341a0000000000000000000000000000000051
2018-10-07 14:01:37 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 24.6 H: 46 Out T: -101.5
2018-10-07 14:01:37 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f54c1a0922c90102d0385c80f644090a2e00f184170a2e0dd737c700610853006d0850008f084500eb08351a0000000000000000000000000000000060
2018-10-07 14:08:38 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 25 H: 46 Out T: -101.7
2018-10-07 14:08:38 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f6231a0922c90102d0385d80fa04070a2e80f644090a2e0de508350071084f006f084f0093084400e608351a000000000000000000000000000000000a
2018-10-07 14:08:38 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 25.5 H: 45 Out T: -100.6
2018-10-07 14:08:38 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f6fa1a0922c90102d0385e80ff84120a2d80fa04070a2e0de9083400670852006c0850008f084500e908351a000000000000000000000000000000002d
2018-10-07 14:15:39 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 25.8 H: 44 Out T: -101.6
2018-10-07 14:15:39 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f7d21a0922c90102d0385f810244080a2c80ff84120a2d0de408350073084f8072084f0094084400e508351b000000000000000000000000000000005a
2018-10-07 14:15:39 MOBILEALERTS OG.SaZ.Fuehler.thk In T: 26 H: 45 Out T: -101.3
2018-10-07 14:15:39 MOBILEALERTS OG.SaZ.Fuehler.thk lastMsg: d65bb9f8a91a0922c90102d038600104840b0a2d810244080a2c0deb083500610852006c0850008f084500eb08351b0000000000000000000000000000000027
Mobile Alerts kommt damit zurecht:
https://measurements.mobile-alerts.eu/ (https://measurements.mobile-alerts.eu/)
07.10.2018 13:56:36 24,1 C 104,7 C 46,0%
07.10.2018 14:00:12 24,6 C 103,3 C 46,0%
07.10.2018 14:03:47 25,0 C 103,1 C 46,0%
07.10.2018 14:07:22 25,5 C 104,2 C 45,0%
07.10.2018 14:10:58 25,8 C 103,2 C 44,0%
07.10.2018 14:14:33 26,0 C 103,5 C 45,0%
Ich würde mich sehr freuen, wenn Du mir helfen könntest.
Viele Grüße,
Henning
Hallo,
schon witzig, wie die die Temperatur codieren um ein Bit zu sparen. Danke auf jeden Fall für die Messwerte und Nachrichten.
Naja bisher war die Annahme, dass das vorderste Bit es bestimmt. Damit wäre eine Temperatur von 0.0° - 102.3°C und -102.4°- -0.1°C möglich. Ich habe im Code jetzt den Umbruch bei 110°C (statt 102,3°C) gesetzt. Damit sind 0.0 - 110.0°C und -94.7°- -0.1°C möglich. Da der beste (bekannte) Sensor nur auf -50,0°C runtergeht, dürfte das kein Problem ergeben.
Die Änderung ist ins svn eingecheckt und sollte morgen per Update verfügbar sein.
Viele Grüße
Markus
Hallo Markus,
danke für die schnelle Bearbeitung.
Viele Grüße,
Henning
Moin MarkusF
Habe einen seltsamme Luftfeutigkeit von über 100%. :o
deviceType : TFA30.3312.02
Hallo,
kannst du mal das Attribut lastMsg auf 1 stellen und mir den Inhalt des Readings lastMsg und den aktuell in der App oder auf dem Gerät angezeigten Wert zukommen lassen. (Gerne auch per Nachricht oder mit ausgeixter Adresse des Geräts.)
Viele Grüße
Markus
Moin MarkusF
Komme leider erst heute dazu.
In der APP : 95,3
In Fhem (lastMsg) :
d85bfc1f631cxxxxxxxxxxxx3cb5001e03bad2001e03bbd2001e03b9d20000000000000000000000000000000000000000000000000000000000000000000079
Hallo,
ich bin leider in den letzten Tagen auch nicht dazu gekommen. Also die Nachricht würde zu 95,4 decodiert werden. Da die zwei Historienwerte 95,5 und 95,3 sind würde ich mal vermuten der Wert in der App ist schon der nächste oder davor gewesen. Leider fehlt der Wert, als 102,3 angezeigt wurde. Der Wert ist allerdings wirklich was besonderes. Es wäre genau 1111111111 in Binär Schreibweise. Ich würde mal vermuten, dass so etwas ein Overflow bei dem Wert mit Nachkommastelle dargestellt wird. Kannst du in der Historie in der App nachschauen, ob es damals einen Overflow gab?
Viele Grüße
Markus
Moin MarkusF
Zu dem Zeitpunkt 24.11.2018 15:43 hat Fhem: 102,3 und die APP: OFL% angezeigt.
Selbst heute 04.12.2018 sind OFL% Daten in der APP.
Ich denke :o es wird nicht an deinen Modul liegen.
Hallo,
doch etwas liegt es schon an meinem Modul, ich habe ja extra Stellen, wo ich den Overflow behandle. Jetzt weiß ich auch, wie sich dieser bei Pro-Hygrometern darstellt und kann es ergänzen, dass auch hier Overflow dargestellt wird. Das Update kommt aber leider wahrscheinlich erst nächste Woche, da ich im Moment woanders stark eingebunden bin und der Fehler wahrscheinlich eher nicht so kritisch ist.
Viele Grüße
Markus
Moin MarkusF
Vielen DankZitat... und der Fehler wahrscheinlich eher nicht so kritisch ist.
Dem ist so.
ZitatDas Update kommt aber leider wahrscheinlich erst nächste Woche, ...
Das
leider ist, glaube ich falsch gewählt.
Man kann froh sein das sich Leute freiwillig den Stress an tun.
Hallo,
ich habe gerade das Update ins svn geladen. Morgen sollte es dann auch ein "Off Limit" geben.
Viele Grüße
Markus
Moin MarkusF
Habe heute wieder einen nicht logischen Wert. :o
Sehe dir mal bitte die Readings an.
In der App -> OFL%
lastMsg -> d85c17f6bd1cxxxxxxxxxxxx0d93001d2fffd2001d2fffd2001d2fffd20fd3700910d3700919d300000000000000000000000000000000000000000000000068
Modulversion :
51_MOBILEALERTS.pm 17948 2018-12-10 17:44:26Z MarkusF
50_MOBILEALERTSGW.pm 16104 2018-02-06 19:11:13Z MarkusF
Hallo,
sieht jetzt im Reading gut aus. 9999 habe ich als Platzhalterzahl für Off-Limit gesetzt. Im Text steht richtig "---". Also genau die Abbildung für Off-Limit, wie ich sie hinterlegt habe. Also genau die gleiche Anzeige wie in der App. (Das einzige was ich am überlegen bin, ist ggf. konfigurierbar zu machen, dass Off-Limit Werte den letzten Wert nicht überschreiben.)
Viele Grüße
Markus
Hallo,
leider vielleicht etwas offtopic:
Habe derzeit noch eine analoge Temperaturüberwachung. (Thermo/Hygro-meter in jedem Raum)
Ich besitze ein Einfamilienhaus und würde gerne von mindestens sechs Räumen (SZ/Kind1/K2/Buero/WZ/Keller) die Temperatur überwachen und in einer existierenden FHEM-Instanz integrieren.
Soviel ich verstanden habe könnte ich dieses Vorhaben relativ kostengünstig mit dem TFA WeaterHub realisieren? (Gateway u. Display im Wohnzimmer, Luftlinie zu einzelnen Zimmer max. 15m)
Würdet Ihr mir zu dieser Anschaffung raten? Sind die Module bereits einsatzbereit? (kann natürlich dann auch gerne meine Erfahrungen posten)
Danke!
lg
Michi
Verwende Gateway ohne Display mit 7 Modulen (Raum, Gefrierschrank, Kühlschrank, Pool ....) seit ca. 2 Jahren - bis auf einen Ausfall - problemlos!
Fhem Modul funktioniert ausgezeichnet und macht die Geräte erst sinnvoll.
LG
Zitat von: MarkusF am 21 Dezember 2018, 20:42:32
Hallo,
sieht jetzt im Reading gut aus. 9999 habe ich als Platzhalterzahl für Off-Limit gesetzt. Im Text steht richtig "---". Also genau die Abbildung für Off-Limit, wie ich sie hinterlegt habe. Also genau die gleiche Anzeige wie in der App. (Das einzige was ich am überlegen bin, ist ggf. konfigurierbar zu machen, dass Off-Limit Werte den letzten Wert nicht überschreiben.)
Viele Grüße
Markus
Wenn letzter Wert nicht überschrieben (999) wird, kann man sehr rasch einen Ausfall erkennen. Bei Anzeige letzter Wert wird die Ausfallerkennung sicher länger dauern.
LG
Hallo,
also zur Produktionsreife. Ich setzte es auch problemlos schon lange bei mir mit vielen Sensoren ein, allerdings nur fünf Typen. Am besten auf die Seite https://fhem.de/commandref_DE.html#MOBILEALERTS (https://fhem.de/commandref_DE.html#MOBILEALERTS) oder hier schauen https://github.com/markusfeist/FhemMobileAlerts/blob/master/README.md (https://github.com/markusfeist/FhemMobileAlerts/blob/master/README.md) da habe ich die Geräte aufgelistet, von dennen ich mindestens Testdaten hatte. Kann aber auch sein, dass es mit anderen Geräten klappt. Die TFA und MobileAlerts Geräte sind wie es aussieht häufig nur ein anderes Gehäuse. Da wäre ich für Feedback dankbar. Bisher konnte ich auch immer schnell neues nachrüsten. Dann brauche ich aber die Nachricht und die dazu passende Anzeige in der APP. (In den nächsten Wochen werde ich wahrscheinlich aber auf richtig neues, was kein akuter Fehler ist, eher langsam reagieren, das wird aber Ende Februar wieder besser.)
Wegen dem Überschreiben: Wenn mache ich es konfigurierbar (soweit habe ich mich schon entschlossen), default wäre das bisherige Verhalten. Die Erreichbarkeit kann man eh am besten über actCycle regeln, testen. An der Stelle kommt ja eine Nachricht an, der Messwert ist nur halt außerhalb des messbaren Bereichs. Erkennen wird man das aber dann auch am Timestamp der letzten Änderung können.
(Wobei das Verhalten bei MobileAlerts auch nicht so ganz einheitlich ist, bei Geräten z.B. Stationen, die einen gesonderten Sensor haben, kommt ein OFL auch wenn der mobile Sensor nicht sendet, z.B. weil die Batterie erschöpft ist (bzw. die Kälte nicht verträgt)).
Viele Grüße
Markus
Hallo,
habe sieben Sensoren (Temp. u. Feuchte) seit einer Woche in Betrieb. (1 Station mit 4 Sensoren [Starter-Set mit KLIMA@HOME Funk-Thermo-Hygrometer WEATHERHUB] und drei einzelne [30.3303.02])
Bisher sehr positive Erfahrungen mit der Integration in FHEM, das einzige was ich bis jetzt noch nicht eingerichtet habe, ist das Auslesen des Batteriestatus. (geht wahrscheinlich nur bei den einzelnen Sensoren, oder?)
Zur Hardware vom Starterset (30.3312.02) ist zu sagen, das die Halterung für die Sensoren, wenn diese aufgestellt sind, nicht unbedingt überzeugt. (neigt nach vorne und somit ist Wert schwer vom Display abzulesen)
Wisst Ihr ob es auch einen Sensor für die Sonneneinstrahlung gibt?
Danke!
lg
Michi
Hallo,
zum Batteriestatus, steht im ersten Beitrag:
ToDos: Batteriestatus
Problem ist, dass das Binärprotokoll mehr oder weniger durch Raten entschlüsselt worden ist. Leider weiß niemand welches Bit jetzt der Batteriestatus ist. Ich habe schon mal mit einem Labornetzteil probiert, aber den Punkt nicht gefunden. Also warte ich aktuell darauf, daß tatsächlich eine Batterie sich leert.
Einen Sensor von Mobilealerts für die Sonneneinstrahlung kenne ich nicht. Wenn müsste der dann auch erst noch einprogrammier werden.
Viele Grüße
Markus
Hallo!
GELÖST:"Laufende Neuanlage von Sensoren bei Internetausfall"
Folgendes konnte ich nach einem Ausfall des Internets seitens des Providers - nicht Totalausfall, sondern immer wieder kurzfristig vorhanden - festestellen:
MOBILEALERTSGW
Sensors
Initialized
Sensors_192.168.178.40_2709
Connected
Sensors_192.168.178.40_2712
Connected
Sensors_192.168.178.40_2715
Connected
Sensors_192.168.178.40_2720
Connected
Sensors_192.168.178.40_2723
Connected
Sensors_192.168.178.40_2724
Connected
Sensors_192.168.178.40_2726
Connected
Sensors_192.168.178.40_2731
Connected
Sensors_192.168.178.40_2734
Connected
Sensors_192.168.178.40_2738
Connected
Sensors_192.168.178.40_2739
Connected
Sensors_192.168.178.40_2740
Connected
Sensors_192.168.178.40_2745
Connected
Sensors_192.168.178.40_2746
Connected
Sensors_192.168.178.40_2748
Connected
Sensors_192.168.178.40_2749
Connected
Sensors_192.168.178.40_2751
Connected
Sensors_192.168.178.40_2752
Connected
Sensors_192.168.178.40_2754
Connected
Sensors_192.168.178.40_2756
Connected
Sensors_192.168.178.40_2757
Connected
Sensors_192.168.178.40_2760
Connected
Sensors_192.168.178.40_2761
Connected
Sensors_192.168.178.40_2765
Connected
Sensors_192.168.178.40_2785
Connected
Sensors_192.168.178.40_2789
Connected
Sensors_192.168.178.40_2791
Connected
Sensors_192.168.178.40_2792
Connected
Sensors_192.168.178.40_2796
Connected
Sensors_192.168.178.40_2798
Connected
Sensors_192.168.178.40_2800
Connected
Sensors_192.168.178.40_2803
Connected
Sensors_192.168.178.40_2808
Connected
Sensors_192.168.178.40_2813
Connected
Sensors_192.168.178.40_2815
Connected
Sensors_192.168.178.40_2818
Connected
Sensors_192.168.178.40_2822
Connected
Sensors_192.168.178.40_2823
Connected
Sensors_192.168.178.40_2824
Connected
Sensors_192.168.178.40_2829
Connected
Sensors_192.168.178.40_2831
Connected
Sensors_192.168.178.40_2832
Connected
Sensors_192.168.178.40_2833
Connected
Sensors_192.168.178.40_2841
Connected
Sensors_192.168.178.40_2844
Connected
Sensors_192.168.178.40_2847
Connected
Sensors_192.168.178.40_2848
Connected
Sensors_192.168.178.40_2852
Connected
Sensors_192.168.178.40_2855
Connected
Sensors_192.168.178.40_2857
Connected
Sensors_192.168.178.40_2859
Connected
dazu die Internals von einem:
Internals:
BUF
CONTENT_LENGTH 320
NAME Sensors_192.168.178.40_2709
NR 1410
PEER 192.168.178.40
PORT 2709
SNAME Sensors
SSL
STATE Connected
TEMPORARY 1
TYPE MOBILEALERTSGW
READINGS:
2019-01-20 02:11:32 state Connected
Attributes:
room hidden
Grundsätzlich läuft alles (seit langem) sehr gut und es funktioiert auch alles weiterhin.
LG
Edit: Nach einem shutdown - restart ist alles wieder weg und alles in Ordnung!!!
Danke
Hallo Zusammen,
mir ist vor kurzem ein Sensor kaputt gegangen. Dieser wurde mittlerweile durch den Baugleichen ersetzt. Um die Messreihe und die Temperaturkurve vom alten Sensor nicht zu verlieren habe ich nun die logzeilen vom alten Logfile in den neuen Logfile kopiert und den Txcounter durchgängig nummeriert. Leider kommt im Gplot trotzdem nur der Graph mit den Daten des neuen Sensors.
Wie schaffe ich es das Gplot meint die Logzeilen sind durchgängig vom aktuellen Sensor und ich wieder eine durchgängige Kurve seit 1.1.19 erhalte ?
Gruß Andreas
Moin,
ich halte schon länger die Mobile Alerts im Auge, da u.a. auch angekündigte Produkte (z.B.Pflanzensensor) interessant klingen. Bisher hat mich die Aktualisierungsrate von 7min abgehalten, die das Gateway braucht, bis es die Daten die die Cloud sendet - die Daten werden jedoch schneller vom Sensor zum Gateway übertragen.
Mir war bereits die Lösung über die Cloud bekannt, fand ich aber nicht gut, da die Daten aus meinem Umfeld herausgegeben werden und die Frage war, was passiert, wenn die Cloud nicht mehr unterstützt wird. Zum Glück bin ich nun über das Modul gestolpert und bin darüber sehr erfreut, dass die Lösung büer die Cloud nicht mehr notwendig ist.
Bevor ich jedoch mir nun die Komponenten kaufe und diese über das Modul einbinde, bin ich leider nicht schlau aus div. Foreneinträgen und diesem Eintrag schlau geworden, wie es sich mit der Aktualisierungsrate mit dem Modul verhält. Ich hab gelesen, dass das Modul die Information auslesen kann, wie der ActCycle ist. Gibt es hierbei eine Möglichkeit die Reaktionszeit durch das Modul oder durch einen Hack zu erhöhen?
Mich interessiert die höhere Reaktionszeit insbesondere für den Regensensor und den Windsensor, da hierbei eine Reaktionszeit von 7min zu lang sein können, z.B. Einfahren von Markisen oder Fenster schließen per Fensterantrieb. Sicherlich nett wäre, wenn die Reaktionszeit für die WL2000 kurz wäre, da über die Luftgüte (CO2-Äquivalenz) die kontrollierte Wohnungslüftung (=KWL) gesteuert werden kann. Die Reaktionszeit für Temperatur oder Luftfeuchtigkeit kann für mich ruhig eine gewisse Trägheit haben, da hierbei eine Lösung über andere Komponenten erfolgt oder eine zeitnahe Information nicht zwingend sein muss. Könntet ihr mir hierbei mit einer Rückmeldungen und Erfahrungen weiterhelfen?
Hallo,
also die Reaktionszeit ist durchaus sehr unterschiedlich je Gerät. Das Gateway sendet tatsächlich nur ca. alle sieben Minuten oder bis es eine gewisse Anzahl von Nachrichten hat, es sei denn, es bekommt eine Nachricht, dass es sofort senden soll. Dies ist wohl beim Regen, Wind, Wasser, Alarm und Pro Sensor so:
ZitatThe gateway caches packages from sensors and only uploads them to the cloud server every few minutes. The exceptions are Window/Door/Water/Sound sensors and Pro-Sensors, which force a transmission. Pushing the button on the Gateway also forces a transmit of all received packages to the cloud.
Ich kann es nur für den Regenmesser bestätigen. Jedes Mal wenn die Wippe fählt, gibt es eine Meldung im Netz, sonst meldet sich der Sensor ca. alle zwei Stunden.
Hier gibt es eine gute Übersicht:
http://www.mobile-alerts.eu/index.php/pages/zusatzsensoren (http://www.mobile-alerts.eu/index.php/pages/zusatzsensoren)
Beim Regenmesser zur Markiesensteuerung wäre ich aber trotzdem vorsichtig, bei leichten Niesel könnte es bauartbedingt dazu kommen, dass die Wippe erst spät auslöst, die Markiese ggf. aber schon feucht ist.
Noch etwas wegen dem ActCycle im Modul. Das ist kein ActCycle, der irgendwie ausgelesen wird, es ist ein einstellbarer Wert, ab wann ein Alarm gegeben werden soll, wenn keine Nachricht vom Sensor kam.
Aktuell unterstützt das Modul auch nur die angegebenen Sensoren. Den WL2000 habe ich aktuell nicht drin. Natürlich rüste ich gerne nach, dafür brauche ich dann aber die Nachrichten (das Modul legt bei unbekannten Geräten ein Gerät in fhem an, dass die Infos hat) und die realen Werte zur Nachricht (entweder abgelesen oder aus der App (dafür hat das Modul eine Forward Einstellung, dass die Daten parallel doch in die Cloud gehen).
Ich hoffe die Infos helfen ein bisschen.
Viele Grüße
Markus
Hallo,
ich habe da ein Problem mit dem MA Gateway. Dies hängt, ebenso wie der Fhem Server in einem Intranet, also kein lokales Netz.
Somit bekomme ich folgende Fehlermeldung im FHEM LOG:
Connection refused from the non-local address 141.xxx.xxx.xxx:2846, as there is no working allowed instance defined for it
Dabei wird jedesmal der Port hochgezählt.
Ein allowfrom gibt es leider beim MobileAltersGateway Modul nicht.
Außerdem ist mir aufgefallen, wenn ich beim GW ein getconfig mache, dass ein zusätzliches Device MA_GW_XXX_UDPPORT erstellt wird.
Ist das normal und was kann ich damit anfangen???
Sensoren werden nicht automatisch erkannt, manuel kann ich diese anlegen (wenn ich die HEXID ausschließlich mit Kleinbuchtstaben anlege -vermutlich ein Feature und kein Bug :-;
Messdaten werden aber trotzdem nicht übermittelt.
Hat jemand eine gute Idee, wie ich das Gatway und die Sensoren zum laufen bekomme.
Ein vergleichbares System mit lokalen Adressen (192.168.xxx.xxx) funktionert problemlos.
Gruß an alle Wissende
Siggi
Hallo nochmal,
habe die Lösung meines Problems gefunden:
habe die Zeile 37 der Perlmoduls 50_MOBILEALERTSGW.pm geändert:
$hash->{AttrList} = "forward:0,1 " . $readingFnAttributes; hin zu $hash->{AttrList} = "forward:0,1 " . "allowfrom " . $readingFnAttributes;
Nun kann ich die erlaubte IP Adressse einpflegen und schon funktioniert es.
Bitte an MarkusF: Da Du ja dieses Modul pflegst, könntest Du bitte das allowfrom mit einpflegen. Wäre toll von Dir.
Siggi
Hallo,
ich dachte ich hätte es schon gestern geschrieben. Vermutlich hat aber das Sende nicht geklappt.
Ich habe heute früh das Update in SVN geladen. Sollte also spätestens morgen per Update kommen.
Wegen ..._UDPPORT: Das ist der Server, der benutzt wird um die Antworten der Gateways auf die Konfigurationsanfrage zu bekommen. Das läuft ja über UDP. Die Gateways antworten auf die UDP Anfrage (per Broadcast oder gezielt an die IP) mit einem UDP Paket mit allen Informationen. Der Server wird (natürlich) erst gestartet, wenn er auch wirklich gebraucht werden könnte. An sich sollte er in der GUI auch nicht sichtbar sein (war er hoffentlich auch nicht) und wenn nur per LIST auftauschen.
Viele Grüße
Markus
Hallo Markus,
danke für die schnelle Reaktion.
Und ja, der ...UDPPort ist nur kurzzeitig im Room hidden sichtbar gewesen.
Gruß
Siggi
Hallo Markus
Ich habe mal eine dumme Frage. ::)
Beim Windmesser MA10660 wird als Reading windSpeed und gustSpeed ausgegeben.
Was ist das für eine Einheit (m/s od. km/h) ?
Habe das IE schon durchstöber aber leider nichts gefunden. :o
Viele Dank
Hallo,
die Frage ist nicht dumm. Es ist m/s. Ich muss eh den automatisierten Test auf github anpassen, da erweitere ich auch direkt die Dokumentation.
Viele Grüße
Markus
Hallo,
hätte da mal ne Frage wegen dem Modul.
Hatte ja mal eine Anleitung geschrieben wie man die Sensoren über HttpMod in fhem einbindet.
Finde das mit dem Modul eine super Sache und habe es jetzt auch schon einige Zeit in Fhem am laufen.
Habe bei mir zuhause 7 Sensoren für temp und feuchte und diese Wetterstation mit dem Display.
Alles funktioniert und ist gut.
Außer das Fhem mir seit einiger Zeit immer etliche Mobile Alertsgeräte anlegt die ich nicht besitze!
Aktuell sind es 111 (hundertelf) Geräte plus Logfiles die nicht mir gehören!
hatte sie vor ein paar Wochen mal alle aus Fhem gelöscht, aber sie kommen wieder.
Hab mich mal in die App eingeloggt ob sie dort auch sind, aber in der App sind nur meine Sensoren die ich habe hinterlegt.
Hat jemand sowas ähnliches? Oder das gleiche problem?
Hallo,
an sich dürfte es nur zwei Ursachen dafür geben.
- Einmal es gibt MobileAlerts Geräte in der Umgebung (z.B. beim Nachbarn), dies ist aber bei 111 eher unwahrscheinlich.
- Es kommen Nachrichten so verstümmelt an, dass sie wie neue Geräte aussehen und vom Gateway akzeptiert werden. Daher würde ich vermuten, dass auch nicht mehrfach Daten zum gleichen Geräte kommen?
Die kaputten Nachrichten würden mich interessieren. Kannst du mal verbose=5 beim Gateway Modul setzen und mir die Daten aus der Zeile:
<Gatewayname> MOBILEALERTSGW: Data for <Geräte ID>: <Daten>
für ein solches Gerät schicken.
(Gerne auch als PM, bitte aber auf jeden Fall mit der ID.)
Hintergrund ist aktuell mache ich dort keine Prüfsummenprüfung, da ich davon ausgehe, dass das Gateway es macht (bei mir habe ich obwohl auch einiges anderes im Funk unterwegs ist, bisher kein einziges nicht vorhandenes Gerät). Ich will schauen, ob die Prüfung helfen würde.
Sonst hilft nur Autocreate abschalten (siehe auch https://wiki.fhem.de/wiki/Autocreate (https://wiki.fhem.de/wiki/Autocreate) ). Als ignoreTypes muss man dann MA_.* hinzufügen. Die Geräte kann man dann manuell mit:
define <Irgendein Name> MOBILEALERTS <Geräte ID von der Karte in Kleinbuchstaben>erzeugen.
Dann hat man im Endeffekt auch den Stand von der APP. Die zeigt einfach alle Infos von den Geräten an, die registriert sind.
(Datenschutztechnisch ist MobileAlerts quasi eine Katastrophe. Alle Gateways schicken einfach alle Sensoren in Reichweite auf dem Server. Jeder der die Geräte ID hat, kann vom Server auf Werte des Sensors zugreifen. Es gibt weder ein Pairing noch ein richtiger Account.)
Viele Grüße
Markus
Hallo,
ich hab jetzt mal mit copy & paste die 111 Sensoren + Logfiles gelöscht!
delete MA_7cf27cf87cf8,MA_7d047d067d04,MA_7d107d147d10,MA_7d207d217d20,MA_7d2c7d2f7d2c,MA_7d357d367d35,MA_7d387d3d7d38,MA_7d407d447d40,MA_7d497d4a7d49,MA_7d4f7d517d4f,MA_7d567d587d56,MA_7d5a7d5f7d5a,MA_7d637d667d63,MA_7d667d6c7d6c,MA_7d717d747d71,MA_7d797d7a7d79,MA_7d7e7d827d7e,MA_7d877d887d87,MA_7d8c7d907d8c,MA_7d907d957d95,MA_7d987d9e7d98,MA_7da07da37da0,MA_7da57dac7da5,MA_7dac7db17dac,MA_7db27db97db9,MA_7db87dbe7dbe,MA_7dc07dc77dc7,MA_7dca7dcc7dca,MA_7dd37dd57dd3,MA_7dd67dda7dd6,MA_7de17de37de1,MA_7de27de77de7,MA_7dee7df17dee,MA_7df37df57df3,MA_7dfc7dff7dfc,MA_7e017e037e01,MA_7e097e0d7e09,MA_7e0d7e117e0d,MA_7e167e1b7e16,MA_7e1b7e1e7e1b,MA_7e267e287e26,MA_7e277e2c7e27,MA_7e337e367e33,MA_7e357e3a7e35,MA_7e3f7e447e3f,MA_7e447e477e44,MA_7e4b7e517e51,MA_7e537e547e53,MA_7e5b7e5f7e5b,MA_7e5b7e627e5b,MA_7e677e6d7e67,MA_7e6d7e6f7e6d,MA_7e777e7a7e77,MA_7e7a7e7d7e7a,MA_7e857e887e85,MA_7e867e8b7e86,MA_7e937e967e93,MA_7e977e987e97,MA_7ea17ea47ea1,MA_7ea17ea67ea1,MA_7ead7eb27ead,MA_7eb17eb37eb1,MA_7ebd7ec17ebd,MA_7ebe7ebf7ebe,MA_7ec97ecd7ec9,MA_7ecb7ece7ecb,MA_7ed57eda7eda,MA_7ed67edc7ed6,MA_7ee57ee87ee5,MA_7ee87ee97ee8,MA_7ef17ef67ef1,MA_7ef47ef77ef4,MA_7efd7f037f03,MA_7f007f057f00,MA_7f0e7f117f0e,MA_7f0f7f127f0f,MA_7f187f1e7f1e,MA_7f1b7f207f1b,MA_7f297f2c7f29,MA_7f2c7f2d7f2c,MA_7f357f3a7f35,MA_7f387f3b7f38,MA_7f417f477f47,MA_7f437f497f43,MA_7f537f557f53,MA_7f547f567f54,MA_7f5e7f647f5e,MA_7f5f7f637f5f,MA_7f6e7f717f6e,MA_7f6f7f707f6f,MA_7f7a7f7e7f7e,MA_7f7b7f7e7f7b,MA_7f847f8b7f8a,MA_7f897f8c7f89,MA_7f947f9a7f94,MA_7f967f997f96,MA_7fa27fa77fa2,MA_7fa57fa77fa5,MA_7fae7fb47fb4,MA_7fb37fb47fb3,MA_7fbf7fc17fbf,MA_7fc07fc27fc0,MA_7fc97fcf7fc9,MA_7fcc7fd07fcc,MA_7fd87fde7fd8,MA_7fd97fdc7fd9,MA_7fe87fe97fe8,MA_7fea7feb7fea,MA_7ff27ff77ff2,MA_7ff67ff97ff6,MA_ffffffffffff
delete FileLog_MA_7d107d147d10,FileLog_MA_7d207d217d20,FileLog_MA_7d2c7d2f7d2c,FileLog_MA_7d357d367d35,FileLog_MA_7d387d3d7d38,FileLog_MA_7d407d447d40,FileLog_MA_7d497d4a7d49,FileLog_MA_7d4f7d517d4f,FileLog_MA_7d567d587d56,FileLog_MA_7d5a7d5f7d5a,FileLog_MA_7d637d667d63,FileLog_MA_7d667d6c7d6c,FileLog_MA_7d717d747d71,FileLog_MA_7d797d7a7d79,FileLog_MA_7d7e7d827d7e,FileLog_MA_7d877d887d87,FileLog_MA_7d8c7d907d8c,FileLog_MA_7d907d957d95,FileLog_MA_7d987d9e7d98,FileLog_MA_7da07da37da0,FileLog_MA_7da57dac7da5,FileLog_MA_7dac7db17dac,FileLog_MA_7db27db97db9,FileLog_MA_7db87dbe7dbe,FileLog_MA_7dc07dc77dc7,FileLog_MA_7dca7dcc7dca,FileLog_MA_7dd37dd57dd3,FileLog_MA_7dd67dda7dd6,FileLog_MA_7de17de37de1,FileLog_MA_7de27de77de7,FileLog_MA_7dee7df17dee,FileLog_MA_7df37df57df3,FileLog_MA_7dfc7dff7dfc,FileLog_MA_7e017e037e01,FileLog_MA_7e097e0d7e09,FileLog_MA_7e0d7e117e0d,FileLog_MA_7e167e1b7e16,FileLog_MA_7e1b7e1e7e1b,FileLog_MA_7e267e287e26,FileLog_MA_7e277e2c7e27,FileLog_MA_7e337e367e33,FileLog_MA_7e357e3a7e35,FileLog_MA_7e3f7e447e3f,FileLog_MA_7e447e477e44,FileLog_MA_7e4b7e517e51,FileLog_MA_7e537e547e53,FileLog_MA_7e5b7e5f7e5b,FileLog_MA_7e5b7e627e5b,FileLog_MA_7e677e6d7e67,FileLog_MA_7e6d7e6f7e6d,FileLog_MA_7e777e7a7e77,FileLog_MA_7e7a7e7d7e7a,FileLog_MA_7e857e887e85,FileLog_MA_7e867e8b7e86,FileLog_MA_7e937e967e93,FileLog_MA_7e977e987e97,FileLog_MA_7ea17ea47ea1,FileLog_MA_7ea17ea67ea1,FileLog_MA_7ead7eb27ead,FileLog_MA_7eb17eb37eb1,FileLog_MA_7ebd7ec17ebd,FileLog_MA_7ebe7ebf7ebe,FileLog_MA_7ec97ecd7ec9,FileLog_MA_7ecb7ece7ecb,FileLog_MA_7ed57eda7eda,FileLog_MA_7ed67edc7ed6,FileLog_MA_7ee57ee87ee5,FileLog_MA_7ee87ee97ee8,FileLog_MA_7ef17ef67ef1,FileLog_MA_7ef47ef77ef4,FileLog_MA_7efd7f037f03,FileLog_MA_7f007f057f00,FileLog_MA_7f0e7f117f0e,FileLog_MA_7f0f7f127f0f,FileLog_MA_7f187f1e7f1e,FileLog_MA_7f1b7f207f1b,FileLog_MA_7f297f2c7f29,FileLog_MA_7f2c7f2d7f2c,FileLog_MA_7f357f3a7f35,FileLog_MA_7f387f3b7f38,FileLog_MA_7f417f477f47,FileLog_MA_7f437f497f43,FileLog_MA_7f537f557f53,FileLog_MA_7f547f567f54,FileLog_MA_7f5e7f647f5e,FileLog_MA_7f5f7f637f5f,FileLog_MA_7f6e7f717f6e,FileLog_MA_7f6f7f707f6f,FileLog_MA_7f7a7f7e7f7e,FileLog_MA_7f7b7f7e7f7b,FileLog_MA_7f847f8b7f8a,FileLog_MA_7f897f8c7f89,FileLog_MA_7f947f9a7f94,FileLog_MA_7f967f997f96,FileLog_MA_7fa27fa77fa2,FileLog_MA_7fa57fa77fa5,FileLog_MA_7fae7fb47fb4,FileLog_MA_7fb37fb47fb3,FileLog_MA_7fbf7fc17fbf,FileLog_MA_7fc07fc27fc0,FileLog_MA_7fc97fcf7fc9,FileLog_MA_7fcc7fd07fcc,FileLog_MA_7fd87fde7fd8,FileLog_MA_7fd97fdc7fd9,FileLog_MA_7fe87fe97fe8,FileLog_MA_7fea7feb7fea,FileLog_MA_7ff27ff77ff2,FileLog_MA_7ff67ff97ff6,FileLog_MA_ffffffffffff
Hab gesehen das bei fast allen Sensoren die Batterien am ende war`n.
Hab die mal durch neue ersetzt und warte jetzt mal ab. Könnte es sein das die leeren Batterien den ganzen Quatsch ausgelöst haben?
Seit Kurzem habe ich ein Problem mit meinen Mobile Alterts Sensoren. Es werden Sensoren gefunden, die tats. nicht existieren. Batterien habe ich geprüft und eigentlich müssten sie noch in Ordnung sein. Außerdem tauchen im Log alle 7 Minuten (düfte der Aktualisierungszyklus des Moduls sein) folgende Meldungen, gefolgt von einem Freeze von gut 30 Sekunden, auf:
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:33 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader d0 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c0 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c8 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
2019.04.20 14:08:34 2: sy_MobileAlerts MOBILELAERTS: For id 02 and packageHeader c2 is no decoding defined.
Das Problem mit den neu angelegten Sensoren ließe sich ja noch mit einem entsprechenden Eintrag in der "autocreate" unterbinden. Dann würden auch die genannten Logeinträge verschwinden. An dem Freeze ändert dies jedoch nichts. Der bleibt in jedem Fall alle 7 Minuten für 30 Sekunden erhalten.
Weiß jemand rat?
Also Autocreate ausschalten und die fehlerhaften Geräte auch löschen kann schon helfen, da er weniger macht, wenn das Gerät nicht da ist.
Eine Bitte hätte ich allerdings, kannst du von einem der nicht vorhandenen Geräte, mal das Reading lastMsg mir geben. Ich will prüfen, ob die Prüfsumme korrekt ist. Wenn diese falsch ist, kann ich das ganze schon vorher ausfiltern und damit das System weniger belasten.
Wobei ich die 30 Sekunden Wartezeit seltsam finde. An sich macht er nach dem Parse nicht mehr viel. Er versucht nur die HTTP Message nach MobileAlerts dann noch weiterzuleiten (wenn dies eingeschaltet ist), allerdings ist der Aufruf an sich asynchron...
Ggf. mal probieren beim Gateway das Attribut forward auf 0 stellen.
Viele Grüße
Markus
Danke für die Rückmeldung.
Zitat von: MarkusF am 24 April 2019, 12:35:49
Eine Bitte hätte ich allerdings, kannst du von einem der nicht vorhandenen Geräte, mal das Reading lastMsg mir geben. Ich will prüfen, ob die Prüfsumme korrekt ist. Wenn diese falsch ist, kann ich das ganze schon vorher ausfiltern und damit das System weniger belasten.
Gerne. Hier ein paar Beispiele von den "neuen" Devices:
- d05ca040c11402400c20421002000021000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000002
- c25ca041001202000c6002001000005000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002e
- c05ca048041002420400461902480000002500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000022
- c25ca048001202100c04000000000040020000c10a201a0000000000000000000000000000000000000000000000000000000000000000000000000000000020
Zitat von: MarkusF am 24 April 2019, 12:35:49
Wobei ich die 30 Sekunden Wartezeit seltsam finde. An sich macht er nach dem Parse nicht mehr viel. Er versucht nur die HTTP Message nach MobileAlerts dann noch weiterzuleiten (wenn dies eingeschaltet ist), allerdings ist der Aufruf an sich asynchron...
Aber ich bin mir ziemlich sicher, dass es am Gateway liegt. Sobald ich das Gateway vom Strom trenne treten die Freezes nicht mehr auf. Auch treten die Freezes immer im Zusammenhang mit dem Datenabruf beim Gateway auf.
Vielleicht noch wichtig zur Info. Die Freezes traten erst nach einem Neuaufsetzen des FHEM-Raspberry auf. Das Neuaufsetzen des Systems habe ich aber auch vorher gelegentlich schon gemacht, ohne dass dadurch die Freezes entstanden wären. Werden ggf. noch irgendwelche Linuxpakete benötigt, auf die ich prüfen müsste (in Commandref steht nichts hierzu)?
Und falls irgendwelche Infos aus beispielsweise VERBOSE 5 erforderlich sind bitte bescheid sagen. Da tauchen bei VERBOSE 5 für das Gatway verdammt viele Einträge auf und ich weiß leider nicht, worauf es ggf. ankäme. Die Einträge im Log ziehen sich übrigens in etwa über die gesamte Freeze-Zeit von gut 30 Sekunen hin. Und es wird auch erwähnt, dass meine regulären Funksensoren gefunden wurden obwohl ich bei denen zu Testzwecken mal die Batterien entnommen habe (keine Ahnung ob das von Bedeutung ist).
Zitat von: MarkusF am 24 April 2019, 12:35:49
Ggf. mal probieren beim Gateway das Attribut forward auf 0 stellen.
Das ist bereits seit Anfang an aktiv.
Danke für die Beispiele.
Bei den Nachrichten sind tatsächlich die Checksummen falsch. Ich habe eine Prüfung der Checksumme eingebaut und das Modul ins SVN hochgeladen. Es sollte morgen mit Update verfügbar sein, dann werden die Nachrichten von den komischen Geräten ziemlich schnell verworfen und dürften das System nicht mehr belasten.
Ich hoffe damit erledigt sich das Problem.
Viele Grüße
Markus
Danke für die Verbesserung am Modul. Der "Filter" funktioniert super. Es werden jetzt keine falschen und unnötigen Sensoren mehr angelegt.
Das Problem mit den 30-sekündigen Freezes alle 7 Minuten hat sich dadurch jedoch noch nicht erledigt, tritt also weiterhin auf. Was mich wundert ist, dass es dieses Problem früher nicht gab. Ich habe aber keine Idee mehr, wo ich noch nach dem Grund suchen soll.
Schade. Ich dachte das würde helfen, ist ja wesentlich weniger Last bei den Messages und beim Autocreate. Kannst du mir mal ein Log in Stufe 5 vom Freeze schicken. Vielleicht sehe ich noch was.
Viele Grüße
Markus
Das Log werde ich nachreichen. Wird aber mindestens bis zum Wochenende dauern. Vorher komme ich leider nicht dazu.
So. Ich habe das Log mal als TXT-Datei angefügt. Ist mit über 8.000 Zeilen ein bisschen größer.
Habe vorher auch das System noch einmal neu aufgesetzt und mögliche daraus resultierende Fehlerquellen auszuschließen. Leider ohne Erfolg.
Hallo,
entschuldige, dass ich so spät antworte. Kam leider in letzter Zeit nicht dazu. Das Log zeigt, dass Daten für mehrere Monate kommen. Also meine Vermutung ist, die Quittung kommt einfach zu spät und so staut es sich auf. Ich habe jetzt mal umgestellt. Er quittiert erst und verarbeitet dann in FHEM.
Das ganze ist im svn und sollte morgen per Update verfügbar sein.
Viele Grüße
Markus
Hallo Markus.
Zitat von: MarkusF am 17 Mai 2019, 20:31:00
Hallo,
entschuldige, dass ich so spät antworte. Kam leider in letzter Zeit nicht dazu.
Überhaupt kein Ding. Schließlich bist du es, der seine Freizeit für meine Probleme opfert.
Zitat von: MarkusF am 17 Mai 2019, 20:31:00Das Log zeigt, dass Daten für mehrere Monate kommen. Also meine Vermutung ist, die Quittung kommt einfach zu spät und so staut es sich auf. Ich habe jetzt mal umgestellt. Er quittiert erst und verarbeitet dann in FHEM.
Das ganze ist im svn und sollte morgen per Update verfügbar sein.
Viele Grüße
Markus
Vielen Dank für das Update. Läuft jetzt wieder alles super. Keine Freezes mehr. ;D
Gruß
Rudy
Hallo Markus,
ich gehörte zu den glücklichen (?) Gewinnern, die bei der diesjährigen IFA in Berlin am Stand von Conrad Electronic einen 4Fach Schalter Technoline Ma10880https://www.conrad.de/de/p/techno-line-ma-10880-funksender-frequenz-868-mhz-reichweite-max-im-freifeld-100-m-1761710.html (https://www.conrad.de/de/p/techno-line-ma-10880-funksender-frequenz-868-mhz-reichweite-max-im-freifeld-100-m-1761710.html)
gewonnen haben. Dieser wurde auch sofort nach dem Einlesen des QR-Codes und Drücken eines Tasters per autocreate als MA_151a17bbe751 angelegt.
Hier ein List vom Device:
Internals:
CFGFN
DEF 151a17bbe751
DeviceID 151a17bbe751
FUUID 5d8a4dad-f33f-a47a-cbe5-3691f8f3d8aafe2a
LASTInputDev MobileAlertsGW
MSGCNT 7
MobileAlertsGW_MSGCNT 7
MobileAlertsGW_TIME 2019-09-24 21:27:25
NAME MA_151a17bbe751
NR 178
STATE T: -9999
TYPE MOBILEALERTS
OLDREADINGS:
READINGS:
2019-09-24 19:52:33 actStatus switchedOff
2019-09-24 19:09:00 deviceType Unknown - 15 ce
2019-09-24 21:27:10 lastMsg ce5d8a6e0e12151a17bbe7514019114a09020400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003f
2019-09-24 21:27:10 lastRcv 2019-09-24 21:27:10
2019-09-24 21:22:38 state T: -9999
2019-09-24 21:22:38 temperature -9999
2019-09-24 21:22:38 temperatureString ---
2019-09-24 21:22:38 triggered 1
2019-09-24 21:27:09 txCounter 25
Attributes:
event-on-change-reading .*
lastMsg 1
room MOBILEALERTS
timestamp-on-change-reading .*
Wäre des deiner Meinung nach mit vertretbarem Aufwand machbar, diesen Schalter in dein MobileAlerts Modul zu integrieren, ich finde ihn ziemlich interessant, weil er wie gesagt 4 Tasten mit jeweils 3, (1Xkurz,2Xkurzund 1Xlang)also insgesamt 12 Schaltmöglichkeiten bietet.
Ich hänge nochmal einen Auszug aus dem Logfile hier an, mit dem was passiert wenn man Taste 1 (grün) drückt.
2019-09-24_21:27:09 MA_151a17bbe751 txCounter: 25
2019-09-24_21:27:09 MA_151a17bbe751 lastMsg: ce5d8a6e0d12151a17bbe7514019114a09020400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003e
2019-09-24_21:27:09 MA_151a17bbe751 lastRcv: 2019-09-24 21:27:09
2019-09-24_21:27:10 MA_151a17bbe751 lastMsg: ce5d8a6e0e12151a17bbe7514019114a09020400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003f
2019-09-24_21:27:10 MA_151a17bbe751 lastRcv: 2019-09-24 21:27:10
Danke im Voraus fürs anschauen
Gruß Thomas
Hallo Thomas,
gerne baue ich das ein. Der Aufwand hält sich auch in Grenzen, ich muss nur die Nachricht decodieren können. Mit deinen Infos kann ich schon mal eine Erkennung für den Typ MA10880 einbauen.
Aktuell sieht die Nachrichten für mich so aus:
ce: Header
5d8a6e0d: Timestamp
12: Packetlänge
151a17bbe751: ID des Gerätes
4019: TX Counter (=25+sofortiges versenden)
114a090204: ?? vermutlich ist hier die Taste codiert.
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000: Füller
3e: Prüfsumme
Das ?? wäre also zu klären. Kannst du mal Nachrichten für den Druck auf die anderen Tasten und die anderen "Druckvarianten" (also zweimal kurz + lang) schicken?
Viele Grüße
Markus
Hallo,
erstmal danke das du dir die Mühe machen willst :).
Das steht im Logfile, wenn ich die Taste 2 (orange) kurz drücke:
2019-09-25_21:57:17 MA_151a17bbe751 txCounter: 26
2019-09-25_21:57:17 MA_151a17bbe751 triggered: 1
2019-09-25_21:57:17 MA_151a17bbe751 temperature: 9999
2019-09-25_21:57:17 MA_151a17bbe751 temperatureString: OLF
2019-09-25_21:57:17 MA_151a17bbe751 T: 9999
2019-09-25_21:57:17 MA_151a17bbe751 lastMsg: ce5d8bc69d12151a17bbe751401a210a4a0204000000000000000000000000000000000000000000000000000000000000000000000000000000000000000039
2019-09-25_21:57:17 MA_151a17bbe751 lastRcv: 2019-09-25 21:57:17
2019-09-25_21:57:18 MA_151a17bbe751 lastMsg: ce5d8bc69e12151a17bbe751401a210a4a020400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003a
2019-09-25_21:57:18 MA_151a17bbe751 lastRcv: 2019-09-25 21:57:18
Taster 3 (rot) kurz:
2019-09-25_22:02:48 MA_151a17bbe751 txCounter: 27
2019-09-25_22:02:48 MA_151a17bbe751 lastMsg: ce5d8bc7e812151a17bbe751401b310a0a4304000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017
2019-09-25_22:02:48 MA_151a17bbe751 lastRcv: 2019-09-25 22:02:48
2019-09-25_22:02:49 MA_151a17bbe751 lastMsg: ce5d8bc7e912151a17bbe751401b310a0a4304000000000000000000000000000000000000000000000000000000000000000000000000000000000000000018
2019-09-25_22:02:49 MA_151a17bbe751 lastRcv: 2019-09-25 22:02:49
Taster 4 (gelb) kurz
2019-09-25_22:05:48 MA_151a17bbe751 txCounter: 28
2019-09-25_22:05:48 MA_151a17bbe751 temperature: 26.6
2019-09-25_22:05:48 MA_151a17bbe751 temperatureString: 26.6°C
2019-09-25_22:05:48 MA_151a17bbe751 T: 26.6
2019-09-25_22:05:48 MA_151a17bbe751 lastMsg: ce5d8bc89c12151a17bbe751401c410a0a034500000000000000000000000000000000000000000000000000000000000000000000000000000000000000005e
2019-09-25_22:05:48 MA_151a17bbe751 lastRcv: 2019-09-25 22:05:48
2019-09-25_22:05:49 MA_151a17bbe751 lastMsg: ce5d8bc89d12151a17bbe751401c410a0a034500000000000000000000000000000000000000000000000000000000000000000000000000000000000000005f
2019-09-25_22:05:49 MA_151a17bbe751 lastRcv: 2019-09-25 22:05:49
Taster 1 (grün) lang gedrückt:
2019-09-25_22:08:16 MA_151a17bbe751 txCounter: 29
2019-09-25_22:08:16 MA_151a17bbe751 temperature: -9999
2019-09-25_22:08:16 MA_151a17bbe751 temperatureString: ---
2019-09-25_22:08:16 MA_151a17bbe751 T: -9999
2019-09-25_22:08:16 MA_151a17bbe751 lastMsg: ce5d8bc93012151a17bbe751401d13cb0a0305000000000000000000000000000000000000000000000000000000000000000000000000000000000000000047
2019-09-25_22:08:16 MA_151a17bbe751 lastRcv: 2019-09-25 22:08:16
2019-09-25_22:08:17 MA_151a17bbe751 lastMsg: ce5d8bc93112151a17bbe751401d13cb0a0305000000000000000000000000000000000000000000000000000000000000000000000000000000000000000048
2019-09-25_22:08:17 MA_151a17bbe751 lastRcv: 2019-09-25 22:08:17
2019-09-25_22:08:19 MA_151a17bbe751 txCounter: 30
2019-09-25_22:08:19 MA_151a17bbe751 lastMsg: ce5d8bc93312151a17bbe751401e114c0a030500000000000000000000000000000000000000000000000000000000000000000000000000000000000000004a
2019-09-25_22:08:19 MA_151a17bbe751 lastRcv: 2019-09-25 22:08:19
2019-09-25_22:08:20 MA_151a17bbe751 lastMsg: ce5d8bc93412151a17bbe751401e114c0a030500000000000000000000000000000000000000000000000000000000000000000000000000000000000000004b
2019-09-25_22:08:20 MA_151a17bbe751 lastRcv: 2019-09-25 22:08:20
Taster2 (orange) lang:
2019-09-25_22:10:30 MA_151a17bbe751 txCounter: 31
2019-09-25_22:10:30 MA_151a17bbe751 temperature: 9999
2019-09-25_22:10:30 MA_151a17bbe751 temperatureString: OLF
2019-09-25_22:10:30 MA_151a17bbe751 T: 9999
2019-09-25_22:10:30 MA_151a17bbe751 lastMsg: ce5d8bc9b612151a17bbe751401f230ccb0305000000000000000000000000000000000000000000000000000000000000000000000000000000000000000061
2019-09-25_22:10:30 MA_151a17bbe751 lastRcv: 2019-09-25 22:10:30
2019-09-25_22:10:31 MA_151a17bbe751 lastMsg: ce5d8bc9b712151a17bbe751401f230ccb0305000000000000000000000000000000000000000000000000000000000000000000000000000000000000000062
2019-09-25_22:10:31 MA_151a17bbe751 lastRcv: 2019-09-25 22:10:31
Taster 3 (rot) lang:
2019-09-25_22:12:36 MA_151a17bbe751 txCounter: 32
2019-09-25_22:12:36 MA_151a17bbe751 lastMsg: ce5d8bca3412151a17bbe7514020330c0bc405000000000000000000000000000000000000000000000000000000000000000000000000000000000000000072
2019-09-25_22:12:36 MA_151a17bbe751 lastRcv: 2019-09-25 22:12:36
2019-09-25_22:12:37 MA_151a17bbe751 lastMsg: ce5d8bca3512151a17bbe7514020330c0bc405000000000000000000000000000000000000000000000000000000000000000000000000000000000000000073
2019-09-25_22:12:37 MA_151a17bbe751 lastRcv: 2019-09-25 22:12:37
Taster 4 (gelb) lang:
2019-09-25_22:14:51 MA_151a17bbe751 txCounter: 33
2019-09-25_22:14:51 MA_151a17bbe751 temperature: 78
2019-09-25_22:14:51 MA_151a17bbe751 temperatureString: 78°C
2019-09-25_22:14:51 MA_151a17bbe751 T: 78
2019-09-25_22:14:51 MA_151a17bbe751 lastMsg: ce5d8bcabb12151a17bbe7514021430c0b04c600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b
2019-09-25_22:14:51 MA_151a17bbe751 lastRcv: 2019-09-25 22:14:51
2019-09-25_22:14:52 MA_151a17bbe751 lastMsg: ce5d8bcabc12151a17bbe7514021430c0b04c600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c
2019-09-25_22:14:52 MA_151a17bbe751 lastRcv: 2019-09-25 22:14:52
Taster 1 (grün) 2Xkurz (lt. App doppelt):
2019-09-25_22:18:07 MA_151a17bbe751 txCounter: 35
2019-09-25_22:18:07 MA_151a17bbe751 lastMsg: ce5d8bcb7f12151a17bbe7514023128e0b0406000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063
2019-09-25_22:18:07 MA_151a17bbe751 lastRcv: 2019-09-25 22:18:07
2019-09-25_22:18:08 MA_151a17bbe751 lastMsg: ce5d8bcb8012151a17bbe7514023128e0b0406000000000000000000000000000000000000000000000000000000000000000000000000000000000000000064
2019-09-25_22:18:08 MA_151a17bbe751 lastRcv: 2019-09-25 22:18:08
Taster 2 (orange) 2Xkurz:
2019-09-25_22:21:05 MA_151a17bbe751 txCounter: 36
2019-09-25_22:21:05 MA_151a17bbe751 temperature: 9999
2019-09-25_22:21:05 MA_151a17bbe751 temperatureString: OLF
2019-09-25_22:21:05 MA_151a17bbe751 T: 9999
2019-09-25_22:21:05 MA_151a17bbe751 lastMsg: ce5d8bcc3112151a17bbe7514024220e8c0406000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028
2019-09-25_22:21:05 MA_151a17bbe751 lastRcv: 2019-09-25 22:21:05
2019-09-25_22:21:06 MA_151a17bbe751 lastMsg: ce5d8bcc3212151a17bbe7514024220e8c0406000000000000000000000000000000000000000000000000000000000000000000000000000000000000000029
2019-09-25_22:21:06 MA_151a17bbe751 lastRcv: 2019-09-25 22:21:06
Taster 3 (rot) 2Xkurz:
2019-09-25_22:23:10 MA_151a17bbe751 txCounter: 37
2019-09-25_22:23:10 MA_151a17bbe751 lastMsg: ce5d8bccae12151a17bbe7514025320e0c8506000000000000000000000000000000000000000000000000000000000000000000000000000000000000000037
2019-09-25_22:23:10 MA_151a17bbe751 lastRcv: 2019-09-25 22:23:10
2019-09-25_22:23:11 MA_151a17bbe751 lastMsg: ce5d8bccaf12151a17bbe7514025320e0c8506000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038
2019-09-25_22:23:11 MA_151a17bbe751 lastRcv: 2019-09-25 22:23:11
und last but not least, Taster 4 (gelb) 2Xkurz:
2019-09-25_22:25:47 MA_151a17bbe751 txCounter: 38
2019-09-25_22:25:47 MA_151a17bbe751 temperature: 52.6
2019-09-25_22:25:47 MA_151a17bbe751 temperatureString: 52.6°C
2019-09-25_22:25:47 MA_151a17bbe751 T: 52.6
2019-09-25_22:25:47 MA_151a17bbe751 lastMsg: ce5d8bcd4b12151a17bbe7514026420e0c0587000000000000000000000000000000000000000000000000000000000000000000000000000000000000000067
2019-09-25_22:25:47 MA_151a17bbe751 lastRcv: 2019-09-25 22:25:47
2019-09-25_22:25:49 MA_151a17bbe751 lastMsg: ce5d8bcd4d12151a17bbe7514026420e0c0587000000000000000000000000000000000000000000000000000000000000000000000000000000000000000069
2019-09-25_22:25:49 MA_151a17bbe751 lastRcv: 2019-09-25 22:25:49
das wars und mir bleibt jetzt nur nochmal besten Dank für deine Mühe zu sagen
Gruß Thomas
Hall Markus,
ich hatte etwas Zeit und habe selber nochmal nachgeforscht. Für mich ergibt sich aus dem Codeblog beginnend mit dem TXCounter direkt aus den ersten beiden Zahlen nach dem Counter (im Codeblog jeweils die Zahlen an Position 5 und 6) die Logik der Taster.
die Zahl nach dem TXCounter gibt den Taster an: 1 = Taste Grün(Taste1), 2 = Taste Orange(Taste2), 3 = Taste Rot(Taste3) und 4 = Taste Gelb(Taste4)
die Zahl danach ( im Codeausschnitt an Position 6) die Art des Tastendrucks 1 = kurz, 2 = 2xkurz, 3 = lang.
In Langform: ich habe die jeweiligen Tastendrücke zu unterschiedlichen Zeiten gemacht und die entsprechenden Codeausschnitte untereinander kopiert:
GRÜN
kurz
4019114a090204
402a114f0f0507
mit den ersten 4 Zahlen kann ich nichts anfangen, ich denke die fünfte Zahl beschreibt den Taster:hier grün(Taster 1)
die sechste Zahl beschreibt die Art: hier kurz einfach (Zahl 1), den Rest kann ich wieder nicht deuten.
lang
401d13cb0a0305
402b13d00f0507
sieht für mich dann so aus: Die fünfte Zahl beschreibt wieder den Taster (grün, Taster 1)
und die sechste Zahl, die 3 steht hier für langen Tastendruck
2Xkurz
4023128e0b0406
402c12910f0507
würde dementsprechend: die fünfte Zahl wieder Taster (grün, 1) und die sechste Zahl, die 2 steht für 2x gedrückt
ORANGE
kurz
4027210e4d0507
401a210a4a0204
wäre nach meiner Logik, die fünfte Zahl (2) für Taster (orange, 2) und die sechste Zahl,hier die 1 wieder für kurz gedrückt
lang
4028230ece0507
401f230ccb0305
sieht dann so aus: fünfte Zahl für Taster 2 (orange) und sechste Zahl die 3 für langen Tastendruck
2Xkurz
4029220e8f0507
4024220e8c0406
passt auch und ergibt als fünfte Zahl die 2 für orange und als sechste Zahl die 2 für 2x gedrückt
ROT
kurz
401b310a0a4304
402d31110f4607
passt auch ins Schema:die 3 als fünfte Zahl für Taster 3 (rot) und die sechste Zahl die 1 für kurz gedrückt.
4020330c0bc405
402e33110fc707
ergibt dasselbe, die fünfte Zahl (3) für taster rot und die sechste, die Zahl 3 für langen tastendruck
4025320e0c8506
402f32110f8807
auch hier: die fünfte Zahl die 3 für Taster Rot und die sechste Zahl, die 2 für 2x gedrückt
GELB
kurz
401c410a0a0345
403041110f0848
auch hier: die fünfte Zahl die 4 für Taster Gelb (4) und die sechste Zahl, die 1 für kurzen Tastendruck
lang
4021430c0b04c6
403143110f08c9
entspricht auch dem Schema: die fünfte Zahl die 4 für Taster Gelb (4) und die sechste Zahl, die 3 für langen Tastendruck
4026420e0c0587
Schema passt:die fünfte Zahl die 4 für Taster Gelb (4) und die sechste Zahl, die 2 für 2x gedrückt
Ich hoffe ich habe nichts falsch gemacht und das ganze hilft weiter.
Hallo Thomas,
da hast du schon die Analyse für mich gemacht.
Ich habe soweit das Modul um "Channels" erweitert und soweit die Decodierung eingebaut. Das Verhalten ist damit wie ein Schalter bei der Homematic.
Bevor ich es in fhem direkt hochlade, kannst du mal in fhem mit:
update all https://markusfeist.github.io/FhemMobileAlerts/repository/develop/controls_mobilealerts.txt
shutdown restart
die neue Version testen. (Grobe Fehler die zu einem Absturz führen könnten dürften nicht drin sein, da diese durch die automatischen Tests abgefangen werden, es geht darum ob die Tasten wirklich richtig erkannt werden.)
Viele Grüße
Markus
Hallo Markus,
danke für die Modulerweiterung, funktioniert soweit schon sehr gut, 2 Sachen sind mir dennoch aufgefallen.
1. Nachdem update des Modules wurden nach jeweiligen Tastendrücken die neuen Devices MA_151a17bbe751_Btn_01 bis MA_151a17bbe751_Btn_04 angelegt. Soweit so gut, allerdings wurde ca.2 Stunden später ein weiteres Device MA_151a17bbe751_Btn_00 angelgt, welches natürlich gar nicht vorhanden ist.
2. In den neuen Devices MA_151a17bbe751_Btn_01 bis ..._Btn_04 wird im state immer das reading trigger_cnt mit angehängt. Im Hauptmodul stehen die states meiner Meinung nach korrekt, jeweils nur mit short, log und DblShort
Zur Verdeudlichung habe ich mal
A) ein List des Gesamtdevices mit den ...Btn_00 bis Btn_04
Internals:
CHANGED
DEF 151a17bbe751
DeviceID 151a17bbe751
FUUID 5d8a4dad-f33f-a47a-cbe5-3691f8f3d8aafe2a
LASTInputDev MobileAlertsGW
MSGCNT 26
MobileAlertsGW_MSGCNT 26
MobileAlertsGW_TIME 2019-09-29 15:35:39
NAME MA_151a17bbe751
NR 42
STATE MA_151a17bbe751_Btn_03 DblShort
TYPE MOBILEALERTS
channel_00 MA_151a17bbe751_Btn_00
channel_01 MA_151a17bbe751_Btn_01
channel_02 MA_151a17bbe751_Btn_02
channel_03 MA_151a17bbe751_Btn_03
channel_04 MA_151a17bbe751_Btn_04
OLDREADINGS:
READINGS:
2019-09-29 12:44:17 actStatus switchedOff
2019-09-29 11:55:20 deviceType MA10880
2019-09-29 15:35:24 lastMsg ce5d90b31c12151a17bbe751403d3214128a0d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000041
2019-09-29 15:35:24 lastRcv 2019-09-29 15:35:24
2019-09-29 15:35:23 state MA_151a17bbe751_Btn_03 DblShort
Attributes:
event-on-change-reading .*
lastMsg 1
room MOBILEALERTS
timestamp-on-change-reading .*
B) ein List des Devices MA_151a17bbe751_Btn_00
Internals:
CFGFN
DEF 151a17bbe751_00
FUUID 5d909d32-f33f-a47a-1694-231b8893a5604d23
NAME MA_151a17bbe751_Btn_00
NR 192
STATE Short_2
TYPE MOBILEALERTS
chanNo 00
device MA_151a17bbe751
CHANGED:
Short_1
trigger_cnt: 1
Short_2
trigger_cnt: 2
CHANGEDWITHSTATE:
CHANGETIME:
2019-09-29 13:56:00
2019-09-29 13:56:00
2019-09-29 13:56:01
2019-09-29 13:56:01
READINGS:
2019-09-29 13:56:01 state Short_2
2019-09-29 13:56:01 trigger_cnt 2
Attributes:
und C) ein list des Devices MA_151a17bbe751_Btn_03 um zu zeigen das eben an den state DblShort der trigger_cnt angehangen wird
Internals:
CFGFN
DEF 151a17bbe751_03
FUUID 5d907db6-f33f-a47a-8c9b-84def6a407118010
NAME MA_151a17bbe751_Btn_03
NR 61
STATE DblShort_4
TYPE MOBILEALERTS
chanNo 03
device MA_151a17bbe751
CHANGED:
Short_1
trigger_cnt: 1
Short_2
trigger_cnt: 2
DblShort_3
trigger_cnt: 3
DblShort_4
trigger_cnt: 4
CHANGEDWITHSTATE:
CHANGETIME:
2019-09-29 11:47:32
2019-09-29 11:47:32
2019-09-29 11:47:33
2019-09-29 11:47:33
2019-09-29 15:35:23
2019-09-29 15:35:23
2019-09-29 15:35:24
2019-09-29 15:35:24
READINGS:
2019-09-29 15:35:24 state DblShort_4
2019-09-29 15:35:24 trigger_cnt 4
Attributes:
angehangen.
Vielleicht kannst du da ja noch ein paar Korrekturen vornehmen.
Viele Grüße
Thomas
Hallo,
zu 1: Wegen dem Button 0, dass scheint dann wohl die Statusmeldung zu sein, dass das Gerät noch existiert. Ich ignoriere jetzt im Source alle Buttons kleiner 1 und größer 4.
zu 2: Das ist genauso wie Homematic, wo ich mich angelehnt habe. Als Beispiel von einen Homematic 6 Fach-Taster:
Ein Listauszug vom Gerät:
Internals:
DEF 21787F
FUUID 5c5f1db6-f33f-6a3d-c706-9db8b39311f5a9e6
...
STATE CUL_HM_HM_PB_6_WM55_21787F_Btn_04 Short
TYPE CUL_HM
channel_01 CUL_HM_HM_PB_6_WM55_21787F_Btn_01
channel_02 CUL_HM_HM_PB_6_WM55_21787F_Btn_02
channel_03 CUL_HM_HM_PB_6_WM55_21787F_Btn_03
channel_04 CUL_HM_HM_PB_6_WM55_21787F_Btn_04
channel_05 CUL_HM_HM_PB_6_WM55_21787F_Btn_05
channel_06 CUL_HM_HM_PB_6_WM55_21787F_Btn_06
...
READINGS:
...
2019-09-29 18:28:17 state CUL_HM_HM_PB_6_WM55_21787F_Btn_04 Short
und dem Channel zur Taste:
Internals:
DEF 21787F04
FUUID 5c5f1db6-f33f-6a3d-b081-1a80bc6889c450cd
NAME CUL_HM_HM_PB_6_WM55_21787F_Btn_04
NOTIFYDEV global
NR 108
NTFY_ORDER 50-CUL_HM_HM_PB_6_WM55_21787F_Btn_04
STATE Short 1_54 (to ccu)
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_PB_6_WM55_21787F
peerList ccu_Dummy,
READINGS:
...
2019-09-29 18:28:17 state Short 1_54 (to ccu)
2019-09-29 18:28:17 trig_aes_ccu ok:54
2019-09-29 18:28:17 trigger Short_54
2016-12-23 19:44:01 triggerTo_CUL_HM_HM_LC_Sw1PBU_FM_209CF1 Short_4_ack
2016-12-26 16:51:27 triggerTo_HM_4AA9AF Short_1_ack
2019-09-29 18:28:17 trigger_cnt 54
...
Es fehlt lediglich das "(to ...)". Das liegt aber daran, da ich dort nichts direkt vergleichbares habe. (Es gibt dort mindestens "to broadcast", wenn das Gerät noch nicht gepeert ist.)
Daher würde ich dort nichts ändern um einfach analog zu sein. (Hat sich schon positiv bei den Temperaturen ausgewirkt, da ich möglichst analog war, hat das Modul dewpoint, dass ich vorher nicht kannte, direkt funktioniert.)
Die 1. Änderung ist soweit schon auf github. Wenn das OK von dir kommt, füge ich es dann direkt nach fhem ein.
Viele Grüße
Markus
Hallo,
ich habe gestern noch ein Update gezogen und in den letzten 24 Stunden des öfteren mal in unterschiedlichen Varianten geschaltet, dabei habe ich keinerlei Verhaltensauffälligkeiten und auch keine sinnfreien Logeinträge feststellen können. Für mich ist das damit dann so in Ordnung und ich freue mich das ich den Schalter jetzt neben meinen Temperatursensoren einsetzen kann.
Vielen Dank und hoffentlich ein langes Wochenende nach dem Feiertag :)
Gruß Thomas
Hallo,
ich bin am überlegen mir die MA 10410 Funkuhr zu kaufen um damit die Systemzeit des Rasperrys zu setzen, kann mir hier jemand sagen ob die Uhrzeit von der MA 10410 Funkuhr mitkommt ?
Mfg Mani
Hallo Mani,
kurze Antwort: Nein.
Lange Antwort: In den Nutzdaten haben wir bei der Wetterstation keine Lücke also keinen Platz für die Uhrzeit. Generell wird zwar bei jedem Datensatz ein Timestamp gesendet und zwar wann der Empfangen wurde. Aber dieser ist einmal veraltet (war ja wann empfangen wurde, das Gateway sendet den Satz ggf. erst sieben Minuten später) und das Gateway bezieht die Uhrzeit aus der letzten Anfrage bzw. der ersten Init-Anfrage, wenn es frisch Strom bekommt. Damit beim Einsatz meines Moduls vom FHEM-Server bzw. beim normalen Einsatz vom Server von MobileAlerts.
Viele Grüße
Markus
Hallo,
ich habe hier einen (wohl relativ neuen) Luftdruckmonitor MA10238, den das MobileAlerts-FHEM-Modul wohl noch nicht kennt.
Mißt und sendet 3 Werte: Luftdruck, Temperatur, Luftfeuchte.
Hersteller ist TechnoLine.
Erhältlich bei ELV
https://de.elv.com/mobile-alerts-luftdruckmonitor-ma10238-251110?fs=3890491188&c=0 (https://de.elv.com/mobile-alerts-luftdruckmonitor-ma10238-251110?fs=3890491188&c=0)
Vielleicht erbarmt sich MarkusF der Sache und schaut die Daten an ? (das wäre ganz super und meine Große Hoffnung :)
Vielen Dank !!!
FHEM list:
Internals:
CFGFN
DEF 18073ebbc97f
DeviceID 18073ebbc97f
FUUID 5efcc911-f33f-b6d7-06cb-bb6270f9219d5e07
LASTInputDev MobileAlertsGW
MSGCNT 456
MobileAlertsGW_MSGCNT 456
MobileAlertsGW_TIME 2020-07-03 17:10:09
NAME MA_18073ebbc97f
NR 121200
STATE
TYPE MOBILEALERTS
READINGS:
2020-07-01 20:15:19 actStatus switchedOff
2020-07-01 19:34:07 deviceType Unknown - 18 e0
2020-07-03 17:10:07 lastMsg e05eff4a4f2418073ebbc97f4001c801033027ef01032f27f00306080b0b0c00000000000015000000000000000000000000000000000000000000000000003f
2020-07-03 17:10:07 lastRcv 2020-07-03 17:10:07
Attributes:
event-on-change-reading .*
room MOBILEALERTS
timestamp-on-change-reading .*
FHEM device log:
2020-07-03_16:04:07 MA_18073ebbc97f lastMsg: e05eff3ad72418073ebbc97f4001bd01042e27f301042e27f3020507070808000000000000380000000000000000000000000000000000000000000000000047
2020-07-03_16:04:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:04:07
2020-07-03_16:10:07 MA_18073ebbc97f lastMsg: e05eff3c3f2418073ebbc97f4001be01042f27f301042e27f30204070708080000000000002e0000000000000000000000000000000000000000000000000028
2020-07-03_16:10:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:10:07
2020-07-03_16:16:07 MA_18073ebbc97f lastMsg: e05eff3da72418073ebbc97f4001bf01042f27f201042f27f3020508080909000000000000ee0000000000000000000000000000000000000000000000000057
2020-07-03_16:16:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:16:07
2020-07-03_16:22:07 MA_18073ebbc97f lastMsg: e05eff3f0f2418073ebbc97f4001c001042f27f101042f27f2030608090a0a0000000000000a0000000000000000000000000000000000000000000000000061
2020-07-03_16:22:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:22:07
2020-07-03_16:28:07 MA_18073ebbc97f lastMsg: e05eff40772418073ebbc97f4001c101032f27f101042f27f1030608090a0a000000000000150000000000000000000000000000000000000000000000000054
2020-07-03_16:28:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:28:07
2020-07-03_16:34:07 MA_18073ebbc97f lastMsg: e05eff41df2418073ebbc97f4001c201042f27f101032f27f1030508090a0a00000000000015000000000000000000000000000000000000000000000000003d
2020-07-03_16:34:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:34:07
2020-07-03_16:40:07 MA_18073ebbc97f lastMsg: e05eff43472418073ebbc97f4001c301042f27f101042f27f1030508090a0a00000000000038000000000000000000000000000000000000000000000000004c
2020-07-03_16:40:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:40:07
2020-07-03_16:46:07 MA_18073ebbc97f lastMsg: e05eff44af2418073ebbc97f4001c401032f27ef01042f27f104070a0b0c0c0000000000002e0000000000000000000000000000000000000000000000000034
2020-07-03_16:46:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:46:07
2020-07-03_16:52:07 MA_18073ebbc97f lastMsg: e05eff46172418073ebbc97f4001c501032f27ef01032f27ef0406090b0c0c000000000000150000000000000000000000000000000000000000000000000001
2020-07-03_16:52:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:52:07
2020-07-03_16:58:07 MA_18073ebbc97f lastMsg: e05eff477f2418073ebbc97f4001c601032f27f101032f27ef020407090a0a02020202020215000000000000000000000000000000000000000000000000006d
2020-07-03_16:58:07 MA_18073ebbc97f lastRcv: 2020-07-03 16:58:07
2020-07-03_17:04:07 MA_18073ebbc97f lastMsg: e05eff48e72418073ebbc97f4001c701032f27f001032f27f10305080a0a0b010101010101b8000000000000000000000000000000000000000000000000007a
2020-07-03_17:04:07 MA_18073ebbc97f lastRcv: 2020-07-03 17:04:07
2020-07-03_17:10:07 MA_18073ebbc97f lastMsg: e05eff4a4f2418073ebbc97f4001c801033027ef01032f27f00306080b0b0c00000000000015000000000000000000000000000000000000000000000000003f
2020-07-03_17:10:07 MA_18073ebbc97f lastRcv: 2020-07-03 17:10:07
dazu passende Historie auf iOS (TechnoLine MA-App):
siehe PNG im Anhang
Hallo,
die Anpassung für den MA10238 sind im SVN von fhem eingecheckt und sollten morgen per Update verfügbar sein.
Danke für die ausführlichen Daten.
Ansonsten der Sensor hat eine Besonderheit, der txCounter ist (wie beim Windsensor) 3 Byte statt 2 Byte.
Daher hätte ich die Bitte, wenn die Batterie dann später mal leer geht, kann ich dann bitte erneut eine Message bekommen?
Es geht mir darum herauszubekommen, ob der Wert für die Batterie auch an der gleichen Stelle ist.
(Die Doku für das Repository MMMMobileAlerts schreibe ich in den nächsten Wochen.)
Viele Grüße
Markus
Wow, das ging ja mehr als fix, keine 24h nach meinem Post. Vielen Dank Markus :)
Konnte es natürlich nicht erwarten und habe die beiden Module aus deinem Github heruntergeladen.
Nach Neuanlegen des Device läuft erstmal alles super !
Ich beobachte jetzt mal noch ein paar Tage und berichte dann final.
Bezgl. Batteriemeldung: Ich suche mal ein paar schwache aus meiner Recyclingbox (als Homematicer hat man die ja immer gut gefüllt ;) ) und versuche die Batteriemeldung vom MA10238 zu provozieren.
Nochmal vielen, vielen Dank Markus :)
Hallo Markus,
hier die Daten bei LowBat (mit Konstanter simuliert, Sensor wird mit 2x AAA betrieben)
1.) unterhalb 2,5V zeigt LCD-Display sowie dein FHEM-Modul richtigerweise "batteryState: low" an, in der App wird der Sensor gelb hinterlegt, aber "Batterie" wird in App weiterhin als "Gut" angezeigt.
FHEM list @2,5V:
Internals:
DEF 18073ebbc97f
DeviceID 18073ebbc97f
FUUID 5f00bac0-f33f-b6d7-5db4-cada769f42030c30
LASTInputDev MobileAlertsGW
MSGCNT 188
MobileAlertsGW_MSGCNT 188
MobileAlertsGW_TIME 2020-07-07 19:07:01
NAME MA_Luftdruck_Temp_WoZi
NR 730
STATE T: 23.8 H: 50 A: 1013.1
TYPE MOBILEALERTS
READINGS:
2020-07-04 20:18:48 actStatus switchedOff
2020-07-07 19:06:59 airPressure 1013.1
2020-07-07 19:06:59 airPressureString 1013.1hPa
2020-07-07 19:06:59 batteryState low
2020-07-04 19:22:06 deviceType MA10238
2020-07-07 19:06:59 humidity 50
2020-07-07 19:06:59 humidityString 50%
2020-07-07 19:06:59 lastMsg e05f04abb32418073ebbc97fc0000200ee32279300ef3127920000000000000101010101017c000000000000000000000000000000000000000000000000001c
2020-07-07 19:06:59 lastRcv 2020-07-07 19:06:59
2020-07-07 19:06:59 state T: 23.8 H: 50 A: 1013.1
2020-07-07 19:06:59 temperature 23.8
2020-07-07 19:06:59 temperatureString 23.8°C
2020-07-07 19:06:59 triggered 1
2020-07-07 19:06:59 txCounter 2
Attributes:
event-on-change-reading .*
event-on-update-reading .*
icon weather_barometric_pressure
lastMsg 1
room MOBILEALERTS
timestamp-on-change-reading .*
2.) unterhalb 2,1V wird im LCD Display anstelle Temperatur "nC" angezeigt, bei %RH gar nichts mehr, Luftdruck weiterhin ein Wert. Die App wechselt auf "Batterie Wechseln", Werte für T und H auf "OFL""
FHEM list @2,1V:
Internals:
DEF 18073ebbc97f
DeviceID 18073ebbc97f
FUUID 5f00bac0-f33f-b6d7-5db4-cada769f42030c30
LASTInputDev MobileAlertsGW
MSGCNT 192
MobileAlertsGW_MSGCNT 192
MobileAlertsGW_TIME 2020-07-07 19:31:01
NAME MA_Luftdruck_Temp_WoZi
NR 730
STATE T: 93.8 H: 9999 A: 1012.7
TYPE MOBILEALERTS
READINGS:
2020-07-04 20:18:48 actStatus switchedOff
2020-07-07 19:30:59 airPressure 1012.7
2020-07-07 19:30:59 airPressureString 1012.7hPa
2020-07-07 19:30:59 batteryState low
2020-07-04 19:22:06 deviceType MA10238
2020-07-07 19:30:59 humidity 9999
2020-07-07 19:30:59 humidityString ---
2020-07-07 19:30:59 lastMsg e05f04b1532418073ebbc97fc0000683aaff278f00ec322790040404040404000000000000a00000000000000000000000000000000000000000000000000000
2020-07-07 19:30:59 lastRcv 2020-07-07 19:30:59
2020-07-07 19:30:59 state T: 93.8 H: 9999 A: 1012.7
2020-07-07 19:30:59 temperature 93.8
2020-07-07 19:30:59 temperatureString 93.8°C
2020-07-07 19:30:59 triggered 1
2020-07-07 19:30:59 txCounter 6
Attributes:
event-on-change-reading .*
event-on-update-reading .*
icon weather_barometric_pressure
lastMsg 1
room MOBILEALERTS
timestamp-on-change-reading .*
und hier noch die Log-Daten zum ganzen Procedere:
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi txCounter: 0
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi batteryState: ok
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi temperature: 24
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi temperatureString: 24°C
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi humidity: 49
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi humidityString: 49%
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi airPressure: 1013
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi airPressureString: 1013hPa
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi T: 24 H: 49 A: 1013
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi lastMsg: e05f04a8e12418073ebbc97f40000000f03127920000000000000000000000000000000000a5000000000000000000000000000000000000000000000000000f
2020-07-07_18:54:57 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 18:54:57
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi txCounter: 0
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi batteryState: ok
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi temperature: 24
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi temperatureString: 24°C
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi humidity: 49
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi humidityString: 49%
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi airPressure: 1013
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi airPressureString: 1013hPa
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi T: 24 H: 49 A: 1013
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi lastMsg: e05f04a8e22418073ebbc97f40000000f03127920000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000b
2020-07-07_18:54:58 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 18:54:58
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi txCounter: 1
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi temperature: 23.9
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.9°C
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi humidity: 49
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi humidityString: 49%
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi airPressure: 1013
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi airPressureString: 1013hPa
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi T: 23.9 H: 49 A: 1013
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04aa4b2418073ebbc97fc0000100ef31279200f03127920000000000000000000000007d000000000000000000000000000000000000000000000000002d
2020-07-07_19:00:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:00:59
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi txCounter: 2
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi temperature: 23.8
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.8°C
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi humidity: 50
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi humidityString: 50%
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi airPressure: 1013.1
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi airPressureString: 1013.1hPa
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi T: 23.8 H: 50 A: 1013.1
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04abb32418073ebbc97fc0000200ee32279300ef3127920000000000000101010101017c000000000000000000000000000000000000000000000000001c
2020-07-07_19:06:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:06:59
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi txCounter: 3
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi temperature: 23.7
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.7°C
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi humidity: 50
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi humidityString: 50%
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi airPressure: 1013
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi airPressureString: 1013hPa
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi T: 23.7 H: 50 A: 1013
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04ad1b2418073ebbc97fc0000300ed32279200ee322793010101010101000000000000a0000000000000000000000000000000000000000000000000002a
2020-07-07_19:12:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:12:59
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi txCounter: 4
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi temperature: 23.7
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.7°C
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi humidity: 50
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi humidityString: 50%
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi airPressure: 1012.8
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi airPressureString: 1012.8hPa
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi T: 23.7 H: 50 A: 1012.8
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04ae832418073ebbc97fc0000400ed32279000ed32279203030303030300000000000033000000000000000000000000000000000000000000000000002f
2020-07-07_19:18:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:18:59
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi txCounter: 5
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi temperature: 23.6
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.6°C
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi humidity: 50
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi humidityString: 50%
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi airPressure: 1012.8
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi airPressureString: 1012.8hPa
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi T: 23.6 H: 50 A: 1012.8
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04afeb2418073ebbc97fc0000500ec32279000ed322790030303030303000000000000a00000000000000000000000000000000000000000000000000003
2020-07-07_19:24:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:24:59
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi txCounter: 6
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi temperature: 93.8
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi temperatureString: 93.8°C
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi humidity: 9999
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi humidityString: ---
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi airPressure: 1012.7
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi airPressureString: 1012.7hPa
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi T: 93.8 H: 9999 A: 1012.7
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04b1532418073ebbc97fc0000683aaff278f00ec322790040404040404000000000000a00000000000000000000000000000000000000000000000000000
2020-07-07_19:30:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:30:59
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi txCounter: 7
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi triggered: 1
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi batteryState: low
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi temperature: 23.5
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi temperatureString: 23.5°C
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi humidity: 51
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi humidityString: 51%
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi airPressure: 1012.8
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi airPressureString: 1012.8hPa
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi T: 23.5 H: 51 A: 1012.8
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi lastMsg: e05f04b2bb2418073ebbc97fc0000700eb33279083aaff278f030303030303010101010101a0000000000000000000000000000000000000000000000000006a
2020-07-07_19:36:59 MA_Luftdruck_Temp_WoZi lastRcv: 2020-07-07 19:36:59
Falls Du noch mehr brauchst, kann ich das gerne ausmessen.
Hallo,
war in letzter Zeit leider etwas unterwegs. Danke fürs probieren und perfekt die Anzeige "battery low" klappt damit auch mit den 3 Byte Countern genauso wie bei den 2 Byte Countern (habe bisher kein Gerät mit einem 3 Byte Counter und konnte es daher nicht selber probieren).
Viele Grüße
Markus
Hallo zusammen,
leider musste ich feststellen des die Sensoren MA10005 und WL2000 nicht mehr lieferbar sind laut Aussage von Mobile Alters auch aus dem Programm genommen wurden.
Hat jemand ne Ahnung, warum und ob es adäquaten Ersatz hierzu gibt.
Ich habe mit dem MA10005 eine komplette Büroumgebung aufgebaut und in FHEM/FTUI integriert, was auch gut funktioniert. Nur mit dem Erweitern bzw. Ersatz habe ich nun ein Problem.
Vielleicht hat jemand von euch hier eine gute Idee, was man anstatt dem MA10005 nehmen könnte.
Gruß
Isno
Hallo Markus,
zunächst vielen Dank für Deine Arbeit!
Vielleicht mache ich etwas falsch, vielleicht kannst Du mir helfen:
Ich benutze u.a. einen Regenmesser MA10650 um Werte zu sammeln, die ich dann als Wetterstationsdaten an Weather Underground hochlade (Modul WUup). Wenn FHEM neu startet ist mir aufgefallen, dass die Niederschlagsdaten astronomisch sind.
Grund ist offenbar die Initialisierung der Niederschlagswerte mmRainActHour und mmRainActDay, die zumindest bei mir auf mmRain gesetzt werden.Das gleiche passiert nach "clear readings". In dem Logausschnitt unten sieht man zunaechst die regulären Werte (14:23), dann "clear readings" um 14:48, 14:41 die Initialisierung von mmRainActHour und mmRainActDay auf mmRain, danach stimmen die Werte wieder (abgesehen von der Historie).
Mache ich da irgendetwas falsch?
Vielen Dank und viele Grüße!
Peter
2021-01-12_14:23:32 MA_0818f68edbfc rain
2021-01-12_14:23:30 MA_0818f68edbfc mmRainActHour: 0.258
2021-01-12_14:23:30 MA_0818f68edbfc mmRainActDay: 3.612
2021-01-12_14:23:30 MA_0818f68edbfc mmRain: 1133.394
2021-01-12_14:23:30 MA_0818f68edbfc txCounter: 11096
2021-01-12_14:23:30 MA_0818f68edbfc temperature: 2.9
2021-01-12_14:23:30 MA_0818f68edbfc temperatureString: 2.9°C
2021-01-12_14:23:30 MA_0818f68edbfc eventCounter: 4393
2021-01-12_14:23:30 MA_0818f68edbfc T: 2.9 C: 4393
2021-01-12_14:23:30 MA_0818f68edbfc lastRcv: 2021-01-12 14:23:30
2021-01-12_14:48:28 MA_0818f68edbfc clear readings
2021-01-12_14:41:53 MA_0818f68edbfc deviceType: MA10650
2021-01-12_14:49:22 MA_0818f68edbfc rain
2021-01-12_14:41:53 MA_0818f68edbfc mmRainActHour: 1133.652
2021-01-12_14:41:53 MA_0818f68edbfc mmRainActDay: 1133.652
2021-01-12_14:41:53 MA_0818f68edbfc mmRain: 1133.652
2021-01-12_14:41:53 MA_0818f68edbfc txCounter: 11097
2021-01-12_14:41:53 MA_0818f68edbfc triggered: 1
2021-01-12_14:41:53 MA_0818f68edbfc batteryState: ok
2021-01-12_14:41:53 MA_0818f68edbfc temperature: 2.6
2021-01-12_14:41:53 MA_0818f68edbfc temperatureString: 2.6°C
2021-01-12_14:41:53 MA_0818f68edbfc lastEvent: 0
2021-01-12_14:41:53 MA_0818f68edbfc lastEventString: 0 s
2021-01-12_14:41:53 MA_0818f68edbfc eventCounter: 4394
2021-01-12_14:41:53 MA_0818f68edbfc T: 2.6 C: 4394
2021-01-12_14:41:53 MA_0818f68edbfc lastRcv: 2021-01-12 14:41:53
2021-01-12_14:54:24 MA_0818f68edbfc actStatus: switchedOff
2021-01-12_14:41:53 MA_0818f68edbfc mmRainLastHour: 1133.652
2021-01-12_15:00:00 MA_0818f68edbfc mmRainActHour: 0
2021-01-12_15:00:00 MA_0818f68edbfc mmRainLastHour: 0
2021-01-12_16:41:51 MA_0818f68edbfc txCounter: 11098
2021-01-12_16:41:51 MA_0818f68edbfc triggered: 0
2021-01-12_16:41:51 MA_0818f68edbfc temperature: 3.2
2021-01-12_16:41:51 MA_0818f68edbfc temperatureString: 3.2°C
2021-01-12_16:41:51 MA_0818f68edbfc lastEvent: 7201
2021-01-12_16:41:51 MA_0818f68edbfc lastEventString: 7201 s
2021-01-12_16:41:51 MA_0818f68edbfc T: 3.2 C: 4394
2021-01-12_16:41:51 MA_0818f68edbfc lastRcv: 2021-01-12 16:41:51
2021-01-12_19:00:40 MA_0818f68edbfc rain
2021-01-12_19:00:38 MA_0818f68edbfc mmRainActHour: 0.516
2021-01-12_19:00:38 MA_0818f68edbfc mmRainActDay: 1134.168
2021-01-12_19:00:38 MA_0818f68edbfc mmRain: 1134.168
2021-01-12_19:00:38 MA_0818f68edbfc txCounter: 11100
2021-01-12_19:00:38 MA_0818f68edbfc triggered: 1
2021-01-12_19:00:38 MA_0818f68edbfc temperature: 3.9
2021-01-12_19:00:38 MA_0818f68edbfc temperatureString: 3.9°C
2021-01-12_19:00:38 MA_0818f68edbfc lastEvent: 0
2021-01-12_19:00:38 MA_0818f68edbfc lastEventString: 0 s
2021-01-12_19:00:38 MA_0818f68edbfc eventCounter: 4396
2021-01-12_19:00:38 MA_0818f68edbfc T: 3.9 C: 4396
2021-01-12_19:00:38 MA_0818f68edbfc lastRcv: 2021-01-12 19:00:38
Hallo Peter,
also es gibt dort wahrscheinlich zwei Probleme.
Problem Nummer eins konnte ich lösen und habe das Ergebnis soeben ins SVN eingecheckt. Es sollte morgen mit einem FHEM-Update abrufbar sein. Das Problem war, dass bei einem Neustart des Regensensors (was ja auch nach "clear readings" passiert) quasi der gesamte bisherige Regen als neue Regen registriert wird. Das habe ich soweit korrigiert. Nachteil ist jetzt allerdings, dass ggf. der Regen vom ersten Event nach einem "clear readings" ignoriert wird. Das lässt sich aber nicht anders lösen.
Problem Nummer zwei müsste bei dir in der Umgebung liegen. Im Prinzip das Verhalten, was du nach einem Restart hast, ist das gleiche wie bei Einfügen eines neuen Sensors. Mit der Behebung für Nummer eins, wird das Problem dann auch nicht mehr so stark auftauchen, aber ggf. wird Regen wenn es das erste Event nach dem Restart ist ignoriert. Ursache dafür ist, dass das Reading eventCounter nicht gespeichert wird. Das sollte normalerweise in die fhem.save im Log-Verzeichnis beim Stop von fhem erfolgen. Kannst du mal prüfen, ob die Schreibrechte dort korrekt sind und die Datei auch beim Stop geschrieben wird, das Reading eventCounter auch drin ist und beim Start von fhem auch richtig gelesen wird (oder irgendwelche Fehlermeldung im Log dazu stehen).
Viele Grüße
Markus
Hallo Markus,
vielen Dank!
1. habe ich verstanden, und wenn ich das richtig sehe sollten bei der Stückelung des Regenmessers max. 0,3 mm Regen verloren gehen, sollte das Clear Readings im Regen erfolgen
2. Da bin ich mir nicht sicher, ob ich das verstanden habe :) Der eventCounter in dem Log-Beispiel vom ersten Post wird doch korrekt fortgeschrieben?
Jedenfalls kann fhem.sav geschrieben werden und wird auch wie erwartet gespeichert. Auszug für den genannten Sensor:
fhem.sav:
setstate MA_0818f68edbfc T: 13.5 C: 4440
setstate MA_0818f68edbfc 2021-01-12 14:54:24 actStatus switchedOff
setstate MA_0818f68edbfc 2021-01-12 14:41:53 batteryState ok
setstate MA_0818f68edbfc 2021-01-12 14:41:53 deviceType MA10650
setstate MA_0818f68edbfc 2021-01-19 19:50:16 eventCounter 4440
setstate MA_0818f68edbfc 2021-01-21 11:50:18 lastEvent 144000
setstate MA_0818f68edbfc 2021-01-21 11:50:18 lastEventString 2400 m
setstate MA_0818f68edbfc 2021-01-21 11:50:18 lastRcv 2021-01-21 11:50:18
setstate MA_0818f68edbfc 2021-01-19 19:50:16 mmRain 1145.52
setstate MA_0818f68edbfc 2021-01-20 00:00:00 mmRainActDay 0
setstate MA_0818f68edbfc 2021-01-19 20:00:00 mmRainActHour 0
setstate MA_0818f68edbfc 2021-01-19 20:00:00 mmRainLastHour 0
setstate MA_0818f68edbfc 2021-01-20 00:00:00 mmRainYesterday 0
setstate MA_0818f68edbfc 2021-01-21 09:50:12 state T: 13.5 C: 4440
setstate MA_0818f68edbfc 2021-01-21 09:50:12 temperature 13.5
setstate MA_0818f68edbfc 2021-01-21 09:50:12 temperatureString 13.5°C
setstate MA_0818f68edbfc 2021-01-19 21:50:16 triggered 0
setstate MA_0818f68edbfc 2021-01-21 11:50:18 txCounter 11237
setstate MA_0818f68edbfc_INITIALIZED inactive
setstate MA_0818f68edbfc_INITIALIZED 2021-01-12 09:53:27 state inactive
Danke, viele Grüße
Peter
Hallo,
also den Fehler den du darstellst, kann an sich nur passieren, wenn er die erkannten "mmRain" nicht aus der Differenz vom letzten "eventCounter" ausrechnet bzw. ausrechnen kann.
Dies war der Fall, wenn das Reading nicht da war (wie nach einem Löschen der Readings) oder wenn der aktuelle Wert vom eventCounter kleiner ist wie der vom letzten (z.B. nach Batteriewechsel oder Überlauf des Counters (der Batteriewechsel dürfte früher sein)).
Den Fehler den ich behoben war der erste Fall. Im zweiten Fall ist es richtig.
Daher bin ich davon ausgegangen, dass der Wert bei dir nach einem Restart nicht da war (also nicht in der fhem.save gesichert war). Da dies aber der Fall ist, kann ich mir den Fehler nicht mehr erklären. Prüfe mal ob er weg ist und wie eventCounter direkt nach dem Restart im Gerät steht.
Sollte dort alles ok sein, dann dürfte dein anderes Problem auch weg sein.
Viele Grüße
Markus
Hallo zusammen,
da ich überlege, mir auch MobileAlerts zuzulegen, aber nur den Windsensor brauche, folgende Frage:
Werden sowohl der MA10660 als auch der MA10660PRO durch das Modul unterstützt?
Worin besteht überhaupt ein Unterschied zwischen den beiden?
MA10660PRO:
https://de.elv.com/elv-mobile-alerts-windmesser-ma10660pro-mit-solarpanel-121285
MA10660:
https://www.amazon.de/gp/product/B015WC8OUS/ref=ox_sc_act_title_1?smid=A3JWKAKR8XB7XF&psc=1
Danke!
Hallo,
ich kann leider nichts direkt dazu beitragen. Aber:
- Normalerweise haben die Pro Sensoren und normalen Sensoren andere Nummern z.B. MA10300 und MA10320(PRO). Die offizielle Webseite listet auch nur einen Windsensor https://mobile-alerts.eu/de/windmesser-ma-10660/ (https://mobile-alerts.eu/de/windmesser-ma-10660/)
- Die normalen und PRO Sensoren unterscheiden sich wie ich es bisher hatte, "nur" in der Genauigkeit (z.B. 0,5° statt 1°) und Sendegeschwindigkeit (alle 3,5 Minuten ein Messwert statt alle 7 Minuten). Z.B. der MA10300 und MA10320 haben genau den gleichen Code zur Decodierung aber der MA10320 ist genauer.
- Als Fallback: Bisher habe ich es immer geschafft in kurzer Frist in Zusammenarbeit mit den Besitzern neue Geräte zu integrieren. (Man sieht es gut an der Liste von Geräten, die nur "Von jemanden anderen getestet" sind.) Das Mobile Alerts Protokoll hat bisher nichts neues erfunden. Basierend auf der Vorarbeit von Markus Fritze ging es bisher immer problemlos.
Allerdings aufgrund meiner aktuellen Situation kann es statt wie bisher wenige Tage dann ggf. doch 1-2 Wochen dauern, bis ich eine Erweiterung drin habe.
Insgesamt würde ich mal Tippen es gibt keinen Unterschied und es ist das gleiche Gerät, wenn es einen Unterschied geben würde, wäre meine Vermutung, würde ELV auch beide anbieten. (Bisher hat ELV immer alle Sensoren auch gehabt, die auf dem Markt sind, wenn sie sich nicht nur in der Bauform also z.B. TFA und MobileAlerts unterschieden haben) Aber wie gesagt nur geraten.
Viele Grüße
Markus
PS: Noch ein kleiner Quirk, der (noch) nicht in der Dokumentation ist. Die Messwerte für die Windgeschwindigkeit, die mein Modul soweit ausgibt, sind in m/s, die auch der Sensor aufzeichnet. Die Anzeige in der MobileAlerts App ist in km/h.
Hallo MarkusF,
vielen Dank für die vielen Infos!
Ich hatte auch keine weiteren Unterschiede im Internet finden können, deshalb habe ich den Sensor auf Verdacht bei ELV bestellt, und ich kann Dir sagen, dass er mit Deinem Modul gut funktioniert!
Das Sendeintervall ist ebenfalls 7 Minuten. Was mich ein bisschen anfangs irritiert hat, ist die Tatsache, dass der Sender zwar - so vermute ich es - nach 7 Minuten sendet, aber das Gateway noch nicht an FHEM weiterleitet. Ich glaube, das hast Du ja auch schon insofern versucht auszugleichen, dass die tatsächliche Empfangszeit im Gateway als Messzeit in FHEM angezeigt wird.
Dadurch ist der Messwert tatsächlich noch älter als 7 Minuten, aber das ist technisch ja leider nicht anders möglich, man muss auf das Gateway warten.
Da ich den Sensor in den nächsten Tagen hoch auf dem Dach anbringen will, will ich ihn vorher noch ein bisschen ausprobieren. Am Windmesser ist noch ein Restartknopf angebracht, der nach dem Auspacken betätigt wird. Ich vermute, dass dies notwendig ist, wenn der Sensor mit seinem Solarmodul und Akku auf Standby gefahren ist, nachdem zuwenig Licht (Verpackung) auf das Solarmodul gefallen ist.
Danke auch für den Tipp mit den m/s, die rechne ich jetzt in der Anzeige um. Bei den Readings bekomme ich trotz Attribut "expert" auf 4 keine vorherigen Readings, aber das ist nicht weiter schlimm.
Also noch einmal vielen Dank für dieses Modul!!
Gruß,
Friedhelm
Zitat von: MarkusF am 22 Februar 2019, 06:14:27
Hallo,
also die Reaktionszeit ist durchaus sehr unterschiedlich je Gerät. Das Gateway sendet tatsächlich nur ca. alle sieben Minuten oder bis es eine gewisse Anzahl von Nachrichten hat, es sei denn, es bekommt eine Nachricht, dass es sofort senden soll. Dies ist wohl beim Regen, Wind, Wasser, Alarm und Pro Sensor so:Ich kann es nur für den Regenmesser bestätigen. Jedes Mal wenn die Wippe fählt, gibt es eine Meldung im Netz, sonst meldet sich der Sensor ca. alle zwei Stunden.
Hier gibt es eine gute Übersicht:
http://www.mobile-alerts.eu/index.php/pages/zusatzsensoren (http://www.mobile-alerts.eu/index.php/pages/zusatzsensoren)
...
Viele Grüße
Markus
Erst mal vielen Dank für das Modul.
Ich habe lange nach was Passendem gesucht und bin damit fündig geworden.
Leider werden die Daten für den Windmesser MA 10660 und Regensensor MA 10650 tatsächlich nur alle 7 Minuten übertragen (beim 10650 nur wenn Regen fällt).
Eine direkte Übertragung bei einer gefüllten, kippenden Wippe kann ich nicht nachvollziehen.
Das Zitat, vermutlich von MA würde das auch bestätigen.
ZitatThe exceptions are Window/Door/Water/Sound sensors and Pro-Sensors, which force a transmission.
Also Fenster, Tür, Wasser und Sound Sensor.
Wind und Regen ist da nicht dabei.
Blödsinnigerweise habe ich mir nicht die PRO Ausführungen gekauft, die das wohl könnten.
Gibt es dennoch eine Möglichkeit früher (realtime) an die Werte zu kommen?
Also beispielsweise den Button am Gateway per Script "drücken"?
Hallo,
also meine Erfahrung mit dem Regenmesser ist an sich, er sendet ca. alle zwei Stunden mal die Temperatur und wenn die Wippe auslöst kommt eine Nachricht mit Bit 14 im TX-Counter. Also quasi durch Alarm ausgelöst, da müsste an sich das Gateway durchsenden. Muss ich mal beobachten. Allerdings ist mein Sensor auch schon ziemlich alt, ggf. haben die dort was geändert um Batterie zu sparen.
Ansonsten habe ich bisher keine Möglichkeit gefunden es vorab auszulösen. Allerdings er reicht ein Teil, dass es auslöst. Die anderen Nachrichten im Speicher werden immer mitgesendet. (Das Gateway scheint dort primitiv zu sein: Sammle alle Nachrichten, wenn Buffer voll, sende, wenn Zeit abgelaufen, sende, wenn Meldung mit Alarm, sende und wenn Schalter gedrückt, sende.)
Ob man das Gateway dazu bringen kann, einfach sofort den Cache zu übertragen, weiß ich leider nicht, bzw. habe dort nichts bisher festgestellt. Wenn jemand fündig wird, baue ich es gerne als Befehl ein.
Sonst wäre es nur möglich direkt die Funknachrichten mit einem anderen Empfänger zu empfangen. Ich vermute mal das ist noch nicht einmal so komplex. Ich denke mal die Nachrichten, die ich vom Gateway bekomme sind wahrscheinlich ähnlich wie die per Funk. (Dort habe ich zwar vor was zu probieren, komme aber wahrscheinlich auf privaten Gründen zu so einem großen Projekt erst Ende des Jahres, da mir hier noch Know-How fehlt... Also wenn jemand ein gutes Tutorial für das Decodieren von Funknachrichten hat.)
Viele Grüße
Markus
Hallo Markus,
danke für Deine ausführliche Antwort.
Mal schauen, ob ich mich da reinwusle und vlt. was beitragen kann, um das GW per Befehl zum Quatschen zu bringen.
Gruß
Andi
Hallo Markus,
ich revidiere...
Irgendwas hatte wohl noch Startschwierigkeiten.
Der Regensensor sendet auch bei mir bei jedem Wippenschlag. :-)
Allerdings habe ich eine weitere erfreuliche Nachricht.
Ich habe seit längerer Zeit TFA KlimaLogg Pro Sensoren im Einsatz, die ich mit tfrec (https://github.com/baycom/tfrec) abfange und verarbeite.
tfrec kann "nebenbei" auch Mobile Alerts. Mit der Option -T 20 kommen die MA Sensoren an:
#004 1641721393 L=25 4b 2d d4 2b 12 02 75 63 ee ab 5b 03 ef 01 45 01 45 1a 32 b0 f3 e4 b0 e0 1a RSSI 82 WHB02 ID 27563eeab5b TEMP 32.5, PTEMP 32.5
#005 1641721393 L=25 4b 2d d4 2b 12 02 75 63 ee ab 5b 03 ef 01 45 01 45 1a 32 b0 f3 e4 b0 e0 1a RSSI 82 WHB02 ID 27563eeab5b TEMP 32.5, PTEMP 32.5
#000 1641721197 L=29 4b 2d d4 2b 16 03 44 98 ce de 34 03 ed 00 05 0a 4d 00 05 0a 4d 1a 46 72 ce 52 c0 ed 03 RSSI 80 WHB03 ID 34498cede34 TEMP 0.5 HUM 77, PTEMP 0.5 PHUM 77
#001 1641721198 L=29 4b 2d d4 2b 16 03 44 98 ce de 34 03 ed 00 05 0a 4d 00 05 0a 4d 1a 46 72 ce 52 c0 ed 03 RSSI 79 WHB03 ID 34498cede34 TEMP 0.5 HUM 77, PTEMP 0.5 PHUM 77
#000 1641734083 L=44 4b 2d d4 2b 25 08 58 30 76 28 ff 40 7c 80 f1 00 49 c0 00 86 69 c0 11 c0 0b c0 0c c0 1c c0 04 c0 02 c0 0a c0 01 01 77 2f 7f d0 ee 04 RSSI 84 WHB08 ID 858307628ff cnt 73
#001 1641734083 L=44 4b 2d d4 2b 25 08 58 30 76 28 ff 40 7c 80 f1 00 49 c0 00 86 69 c0 11 c0 0b c0 0c c0 1c c0 04 c0 02 c0 0a c0 01 01 77 2f 7f d0 ee 04 RSSI 84 WHB08 ID 858307628ff cnt 73
#002 1641721807 L=45 4b 2d d4 2b 26 0b 51 64 6e f9 e4 00 03 e4 b0 05 22 d2 b0 04 1b d2 e0 02 20 d2 e0 06 27 d2 80 04 25 d2 e0 05 1d d2 df be 63 a8 40 9c 12 RSSI 85 WHB0b ID b51646ef9e4 #0 DIR 247.500000 SPEED 0.500000 GUST 3.400000 time 420
WHB0b ID b51646ef9e4 #1 DIR 247.500000 SPEED 0.400000 GUST 2.700000 time 420
WHB0b ID b51646ef9e4 #2 DIR 315.000000 SPEED 0.200000 GUST 3.200000 time 420
WHB0b ID b51646ef9e4 #3 DIR 315.000000 SPEED 0.600000 GUST 3.900000 time 420
WHB0b ID b51646ef9e4 #4 DIR 180.000000 SPEED 0.400000 GUST 3.700000 time 420
WHB0b ID b51646ef9e4 #5 DIR 315.000000 SPEED 0.500000 GUST 2.900000 time 420
Sollte der Windsensor tatsächlich nur alle 7 min senden, dann werde ich wohl auf tfrec umsteigen.
Damit könnte man ihn auch als Markisenwächter verwenden.
Mal schauen....
Hi!
Erstmal: Saugute Arbeit!
Ich hätte eine Frage: Ich hab einen Sensor mit externer Temperatursonde.
Ich hab Readings für: In T: (Temperatur am Sensor) H: (Luftfeuchtigkeit am Sensor) Out T: (Temperatursensor an der Sonde)
Hab ich eine Möglichkeit für diesen einen Sensor "In T" in "Raumtemperatur" und "Out T" in "Warmwassertemperatur umzubenennen?
(Hintergrund: Im Heizungskeller wird ein neuer Warmwasserspeicher eingebaut, der neue hat kein Thermometer angebaut und die Sonde soll ins Tauchrohr - und die Frau soll nicht so viel grübeln müssen, wenn sie nachschaut ob sie sich jetzt ein Bad einlassen kann.
Danke und herzliche Grüße,
Stephan
Hallo,
entschuldige die späte Antwort (war etwas unterwegs). Also dazu habe ich soweit nichts realisiert, aber auch nur, weil FHEM dort in den Standardmitteln so ziemlich alles bietet, was man sich wünschen kann.
Was dort hilft ist einmal das Attribut stateFormat https://wiki.fhem.de/wiki/DeviceOverview_anpassen#stateFormat (https://wiki.fhem.de/wiki/DeviceOverview_anpassen#stateFormat) bei dir müsste klappen "Raumtemperatur temperatureInString Warmwassertemperatur temperatureOutString". Sonst was ich auch gerne mache einen ReadingProxy (https://wiki.fhem.de/wiki/ReadingsProxy (https://wiki.fhem.de/wiki/ReadingsProxy)) anlegen, um eine eigene Zeile zu bekommen, z.B.
define rp.flur.humidity readingsProxy MA_xxxxxx:humidityInString
attr rp.flur.humidity alias Luftfeuchte
attr rp.flur.humidity icon humidity
Viele Grüße
Markus
Hallo,
ich habe dieses Modul seit 2019 im Betrieb und es läuft sehr gut. Seit Freitag habe ich einen Regenmesser MA10650 eingebunden dieser sendet auch sehr zuverlässig! Aber zu meinen Verständnis welches Reading zeigt mir an ob es gerade Regenet?
hie ein List!
Internals:
.corrHumidity 0
.corrHumidity2 0
.corrHumidity3 0
.corrHumidityOut 0
.corrTemperature 0
.corrTemperature2 0
.corrTemperature3 0
.corrTemperatureOut 0
.expertMode 4
CFGFN
DEF xxx
DeviceID xxxxx
FUUID 62628e49-f33f-66a9-af0c-1777582dfad174af
LASTInputDev MobileAlertsGW
MSGCNT 73
MobileAlertsGW_MSGCNT 73
MobileAlertsGW_TIME 2022-04-25 07:10:56
NAME MA_Regenmesser
NR 131531
STATE T: 8.6 C: 57
TYPE MOBILEALERTS
.attraggr:
.attreocr:
.*
.attrminint:
.attrtocr:
.*
OLDREADINGS:
READINGS:
2022-04-22 19:08:41 actStatus switchedOff
2022-04-22 14:46:23 batteryState ok
2022-04-22 14:46:23 deviceType MA10650
2022-04-25 07:10:55 eventCounter 57
2022-04-25 00:34:37 lastEvent 0
2022-04-25 07:10:55 lastEvent1 1327
2022-04-25 07:10:55 lastEvent1String 1327 s
2022-04-25 07:10:55 lastEvent2 1133
2022-04-25 07:10:55 lastEvent2String 1133 s
2022-04-25 07:10:55 lastEvent3 2761
2022-04-25 07:10:55 lastEvent3String 2761 s
2022-04-25 07:10:55 lastEvent4 2791
2022-04-25 07:10:55 lastEvent4String 2791 s
2022-04-25 07:10:55 lastEvent5 960
2022-04-25 07:10:55 lastEvent5String 960 s
2022-04-25 07:10:55 lastEvent6 1423
2022-04-25 07:10:55 lastEvent6String 1423 s
2022-04-25 07:10:55 lastEvent7 646
2022-04-25 07:10:55 lastEvent7String 646 s
2022-04-25 07:10:55 lastEvent8 4682
2022-04-25 07:10:55 lastEvent8String 4682 s
2022-04-25 00:34:37 lastEventString 0 s
2022-04-25 07:10:55 lastRcv 2022-04-25 07:10:55
2022-04-25 07:10:55 mmRain 8.256
2022-04-25 07:10:55 mmRainActDay 3.096
2022-04-25 07:10:55 mmRainActHour 0.258
2022-04-25 06:48:51 mmRainLastHour 0.516
2022-04-24 21:23:26 mmRainYesterday 5.16
2022-04-25 07:10:55 state T: 8.6 C: 57
2022-04-25 07:10:55 temperature 8.6
2022-04-25 07:10:55 temperatureString 8.6°C
2022-04-25 00:34:37 triggered 1
2022-04-25 07:10:55 txCounter 80
Attributes:
event-on-change-reading .*
expert 4
icon temperature_humidity
room Garten,MOBILEALERTS
timestamp-on-change-reading .*
Ich dachte es wäre das Reading mmRain aber das ist nur der Summierte Wert! Vielleicht kann mir einer einen Tip geben.
mfg
Sig10680
Hallo,
da ist genau ein Problem, was heißt "gerade". Man hat dummerweise ja nur das Kippen der Wippe als Event (und keinen Zustand: es ist gerade nass, wie bei z.B. anderen Sensoren). Deswegen gibt es nur mmRain=Regen (Anzahl der Kippungen) seit Beginn der Zählung (gut für Graphen). Das gleiche für den aktuellen Tag, aktuelle Stunde, letzte Stunde und Vortag. Was es aber auch gibt ein Event "rain" das erzeugt wird, wenn der Wert sich ändert, also die Wippe gewippt hat. Sonst gibt es noch das Reading lastEvent, dass angibt wie lange das letzte Event in Sekunden her war, beim letzten Empfang. Mit dem beiden Werten kann man sich was bauen und dann selbst bestimmen, wann es noch regnet.
Viele Grüße
Markus
Zitat von: MarkusF am 28 April 2022, 19:08:08
Hallo,
da ist genau ein Problem, was heißt "gerade". Man hat dummerweise ja nur das Kippen der Wippe als Event (und keinen Zustand: es ist gerade nass, wie bei z.B. anderen Sensoren). Deswegen gibt es nur mmRain=Regen (Anzahl der Kippungen) seit Beginn der Zählung (gut für Graphen). Das gleiche für den aktuellen Tag, aktuelle Stunde, letzte Stunde und Vortag. Was es aber auch gibt ein Event "rain" das erzeugt wird, wenn der Wert sich ändert, also die Wippe gewippt hat. Sonst gibt es noch das Reading lastEvent, dass angibt wie lange das letzte Event in Sekunden her war, beim letzten Empfang. Mit dem beiden Werten kann man sich was bauen und dann selbst bestimmen, wann es noch regnet.
Viele Grüße
Markus
Hallo und Guten Morgen,
danke für die Hilfestelleung ich werde mal versuchen soetwas für mich umzusetzen. Ich möchte irgendwie meinen Rasenroboter wenn es anfängt zu Regnen einfach nur Parken.
mfg Sig10680
Hi,
erstmal danke für das Modul - Ersteinrichtung und Thermo und Windsensoren laufen einwandfrei
Ich habe allerdings Probleme mit dem MA10860. Der wird einfach nicht erkannt.
FHEM Update habe ich bereits gemacht. Die 51_MOBILEALERTS.pm hat auf meiner FHEM Instanz auch einen Zeitstempel vom 23.08. (letzter Versuch es zum Laufen zu bekommen)
Ich bin mir nun unsicher ob ich was falsch mache oder ob mein Sensor tatsächlich eine Unbekannte Kennung hat.
Hier die Daten die Fhem dazu ausspuckt. GGf. noch jemand eine Idee was ich versuchen könnte ?
Zitat
deviceType Unknown - 0a cb
lastMsg cb631b82310f0a16745e975800f600ea00f91a600000d2600000d2600000d2600000d2600000d200000000000000000000000000000000000000000000000059
gruß
Sorry war mein Fehler. Ich hatte den Code auf meinem GitHub schon um den MA 10860 erweitert, aber nicht das Modul im svn für FHEM angepasst. Ich habe gerade die neue Version hochgeladen. Sie sollte dann morgen über Update in FHEM abrufbar sein.
Viele Grüße
Markus
Kein Thema - Danke Schön :D
Nun wird der Sensor erkannt und liefert Daten !
Moin,,
ich habe mir ein Gateway, div, Thermometer und den Regenmesser MA10650 zugelegt, weil ich das Konzept faszinierend finde (ohne Cloud).
AEG: Auspacken, Einschalten,Geht! Wunderbar, auch die Einrichtung des GWs in FHEM.
Jetzt mein Problem:
Der Regenmesser zeigt in FHEM eine um ca. 4,4°C zu hohe Temperatur, i.e. 20,8
LastMsg.: e1633eedfa25xxxxxxxxxxxx003640d0001f8708c001c083c026c011c1cac005c156c021c4640000000000000000000000000000000000000000000000000064
lGibt es auch für das temperature-Reading eine Korrekturmöglichkeit?
Wenn ich die Definition des Gerätes um einen der in der Hilfe angegebenen Parameter versuche, nimmt Fhem den nicht an.
Die Wippe sendet bei jedem Wechsel übrigens bei mir eien wert ohne Verzögerung.
Danke für die Entwicklung. Das macht Lust auf mehr!
Reimer
Hallo,
danke. Der Lob gebührt aber mir nicht allein ohne die Vorarbeit von Markus Fritze würde es die Komponente ggf. nicht geben.
Dann zum Problem: Der Regenmesser sendet die Temperatur (außer wenn es regnet) nur alle paar Stunden. Er ist also für die Temperaturmessung äußerst schlecht. Also bevor man anpasst einmal prüfen, ob es zum Sendezeitpunkt nicht so kalt war.
Sonst gibt es eine Korrekturmöglichkeit, wie bei jedem Sensor. Dafür muss einfach nur die Definition des Sensors angepasst werden. Im Standard besteht diese aus der ID (die ID ist hier ein "Zufallswert", sie muss natürlich zum Sensor passen), z.B.:
08152bad9704
wenn man diese z.B. in der GUI auf:
08152bad9704 -4.4
ändern. Dann zieht er von der Temperatur 4,4 Grad ab. (Bei anderen Sensoren kann man entsprechend auch weitere Werte anpassen. Siehe auch https://fhem.de/commandref_DE.html#MOBILEALERTSdefine (https://fhem.de/commandref_DE.html#MOBILEALERTSdefine) .)
Das hast du aber soweit schon gefunden.
Ich kann aber keinen Fehler bei mir nachvollziehen. Ich rufe das Modul auf, klicke dort bei den "Internals" auf "DEF" und ergänze einfach die "-4.4" und klicke "modify ..."
Der direkte Befehl dafür wäre:
modify <Name des Gerätes> <ID des Gerätes> -4.4
also z.B.:
modify MA_08152bad9704 08152bad9704 -4.4
Wenn es weiter nicht klappt, was für ein Fehler steht im Log?
Viele Grüße
Markus
Läuft jetzt korrekt.
Ich hatte nicht daran gedacht die Korrektur nur in Ziffern einzutragen und zusätzlich hatte iches dummerweise mit einem Komma versucht.
Danke für die Hilfe!
Reimer
Zitat von: gandi1791 am 08 Januar 2022, 11:03:52
Allerdings habe ich eine weitere erfreuliche Nachricht.
Ich habe seit längerer Zeit TFA KlimaLogg Pro Sensoren im Einsatz, die ich mit tfrec (https://github.com/baycom/tfrec) abfange und verarbeite.
tfrec kann "nebenbei" auch Mobile Alerts. Mit der Option -T 20 kommen die MA Sensoren an:
Sollte der Windsensor tatsächlich nur alle 7 min senden, dann werde ich wohl auf tfrec umsteigen.
Damit könnte man ihn auch als Markisenwächter verwenden.
Mal schauen....
Also zunächst einmal Respekt an alle Mitwirkende und vor allem denen die sich Federführend einbringen.
Ich habe früher einen Raspberry mit einem JeeLink Empfänger mit zwei Technoline Sensoren (z.B. TX25) verbunden.
Damit habe ich dann zum Beispiel den Temperaturverlauf der Standklimatisierung meines Hybriden Actuv Tourer geloggt :)
Das sah dann so wie im folgenden Link aus:
https://www.active-tourer-forum.de/forum/thread/1482-ladeverluste/?postID=22064#post22064
Nun bin ich wegen Heizungsproblemen auf der Arbeit auf die "Mobile-Alerts" Sensoren gestoßen und war zunächst begeister nach dem super schnellen Einrichten.
Leider bin ich nun aber enttäuscht weil die Messzyklen je nach Sensor bei 3,5 oder 7 Sekunden liegen.
Für Raumptemperaturen usw. mag das ja ausreichend sein, aber wenn man einen höher aufösenden Verlauf aufzeichnen möchte (z.B. alle 60 Sekunden) wird es schwieriig und man kann ja nicht jedes Mal das Senden von Hand auslösen, wie bei dem MA 10320 via Button möglich.
Ich bin nun kurz davor alles wieder zurück zu schicken und habe die Frage, ob die Sensoren nicht doch öfters als die 3,5 oder 7 Sekunden senden??
Dann wäre gerade der MA 10320 für meine Ansprüche ein toller Sensor :)
Alternativ habe ich dann noch den folgenden Sensor gefunden und der ist auch nicht zu verachten:
http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LHT65N%20LoRaWAN%20Temperature%20%26%20Humidity%20Sensor%20Manual/#H2.ConnectLHT65NtoIoTServer
EDIT:
die amerikanische Variante von la crosse (Alerts mobile) scheint wohl kürzere Messintervalle zu ermöglichen!!!
http://support.lacrossealertsmobile.com/edit-sensor.html
Leider scheinen die US Varianten sich deutlich von den europäischen Varianten zu unterscheiden:
https://github.com/sarnau/MMMMobileAlerts/blob/master/MobileAlertsELVvsLaCrosse.markdown
Hallo,
habe mit dem Modul die EInbindung meiner Thermostate super hinbekommen; vielen Dank hierfür!
Überlege jetzt die Temperatur und Luftfeuchte der 8 Geräte noch über Tablet ui anzuzeigen.
Jemand eine Idee auf welche Weise ich das am besten/schicksten machen könnte.
EIne "einfache Anzeigenübersicht" würde mir ausreichen, würde nur ungern das Thermostat-Widget benutzen da ich dieses für die Heizkörpermodule benutze!
Gruß
Mutschler
Zitat von: mutschler am 02 April 2023, 10:56:09Hallo,
habe mit dem Modul die EInbindung meiner Thermostate super hinbekommen; vielen Dank hierfür!
Überlege jetzt die Temperatur und Luftfeuchte der 8 Geräte noch über Tablet ui anzuzeigen.
Jemand eine Idee auf welche Weise ich das am besten/schicksten machen könnte.
EIne "einfache Anzeigenübersicht" würde mir ausreichen, würde nur ungern das Thermostat-Widget benutzen da ich dieses für die Heizkörpermodule benutze!
Gruß
Mutschler
nun, was hast du vor?
Ich habe mir einen View mit allen Zimmern/Sensoren erzeugt und gebe die Temperatur/Feuchtigkeit per Label aus. Das kombiniert mit Fenster offen/zu und Rollladen offen/zu finde ich übersichtlich.