Hallo zusammen,
kennt jemand von euch ring-mqtt von tsightler (https://github.com/tsightler/ring-mqtt (https://github.com/tsightler/ring-mqtt))?
Super simpel zum laufen zu bekommen, allerdings habe ich ein Problem - und ich weiß nicht, woran es liegt (ring-mqtt / mqttjs / FHEM / MQTT2_SERVER / ...)
Start EDIT:
Gerade eben erst den Hinweis aufs Wiki gesehen:
- tagesaktuelles FHEM
- MQTT2_SERVER
- MQTT2_DEVICE (autocreate)
ZitatInternals:
FUUID 5c508649-f33f-3ff8-b3f3-8dbc7a320090f51f
FVERSION 98_autocreate.pm:0.216590/2020-04-13
NAME autocreate
NOTIFYDEV global
NR 14
NTFY_ORDER 50-autocreate
STATE active
TYPE autocreate
Attributes:
DbLogExclude .*
filelog ./log/%NAME-%Y.log
room CUL
End EDIT (hoffe, habe jetzt alles relevante mit aufgenommen)
Jedes Mal, wenn ich den rint-mqtt-Service stoppe+starte (oder natürlich einfach restarte), bekomme ich ein neues Topic. Als Beispiel (es ändert sich ausschließlich der rote Teil):
mqttjs_
082bc927:homeassistant/...
mqttjs_
082bc927:ring/...
mqttjs_
b0e8b7fc:homeassistant/...
mqttjs_
b0e8b7fc:ring/...
mqttjs_
d6da5183:homeassistant/...
mqttjs_
d6da5183:ring/...
tsightler hat mir super schnell auf mein Git-Issue geantwortet:
ZitatI'm afraid this question should be directed to the FHEM community and is not really related to anything here. The information you are highlighting is not something that is coming from the ring-mqtt script, the ring-mqtt script creates topics starting with homeassistant/ and ring/ while the mqttjs_<random_number> is some type of ID generated by FHEM. You will notice that ring-mqtt generates 100% consistent topics each time using location/device IDs.
Just taking a quick glance at the FHEM docs (I had never even heard of it) it appears that is has some ability to create regex rules to ignore topics or map the id to specific topic levels. Also, I double you need to care about the topics that start with homeassistant/ at all as those are just used to publish discovery messages to home assistant. Unless FHEM supports home assistant style MQTT discovery these would be totally useless. The actual devices are all published in the topic starting with ring/.
Regardless, the issue you are posting about is specific to FHEM and nothing to do with ring-mqtt and I'm not going to be able to help you with that.
Er geht dabei von einem "FHEM-Problem" aus - ich selber hatte bisher nur Shelly, Raspberry Pi, ESP8266 und ESP32 per MQTT angebunden und nie solche Probleme gehabt. Er war sogar so lieb und hat sich kurz die FHEM-Ref angesehen und mich auf die Möglichkeit hingewiesen, ggf. REGEX-Regeln definieren zu können, um Topics zu ignorieren oder die ID zu spezifischen Topic-Leveln zuzuordnen (falls ich das halbwegs korrekt übersetzt habe) - allerdings bin ich auf dem Gebiet leider auch (noch) komplett lost :(
Ich hoffe ihr versteht mein Problem - und natürlich auch, dass mir jemand helfen kann ;) --> Denn mit jedem Service-Start ein neues Device (und Filelog, welches ich dann löschen muss...) bekomme ich nix vernünftiges aufgebaut...
Vielen Dank im Voraus und viele Grüße
Sascha
Hallo Sascha,
kommt mir bekannt vor.
Schau Dir mal die Lösung sonos2mqtt im Wiki an. https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Sonos2Mqtt
Du brauchst sicher auch ein Bridge Device. Wenn Du das definiert hast entsteht Dein Ring Device und bleibt :)
Hier im Thread wird genau diese Problematik am Anfang besprochen https://forum.fhem.de/index.php/topic,111711.0.html
Gruß Otto
Hi Otto,
oha, Danke für Deine schnelle Antwort! (Da war ich gerade noch am editieren ;D)
Danke für den Hinweis - da schaue ich natürlich gern und sofort rein! :)
Viele Grüße
Sascha
Im meinem Wiki Artikel ist natürlich das Meiste schon im Template verhackstückt. Aber im Thread am Anfang wird eigentlich genau dieses Thema abgearbeitet. Ich hoffe damit kommst Du klar. Sonst lohnt es sich ja fast, dazu mal ein allgemeines HowTo aufzusetzen.
Aber am Anfang vom Wiki Artikel ist das Thema auch gut anhand von zigbee aufgearbeitet.
Das mit der random CID steht afaik bei den "typischen Problemen" in den Praxisbeispielen (das darf auch gerne woanders hin).
Ein Howto fände ich gut (wenn es jemand anderes macht), ich würde aber vorschlagen, eines für "Anfänger" zu machen (am Beispiel eines Shelly-pm erläutern, wie die Attribute (allgemeine Readingfn und spezielle für MQTT2_DEVICE) aufeinander aufbauen, und dann ggf. den Bereich für "Fortgeschrittene", wo sowas wie bridgeRegexp erläutert ist.
Da könnte man dann am Ende mal zusammentragen, was es an "speziellen Lösungen" gibt - also alles, wo dann etwas (Auswertung, Vorverarbeitung usw.) mit der payload geschieht... (Da steige ich dann gerne mit ein, vielleicht fällt dann auch noch jemand was nettes zu dem ein, was es schon so gibt ;) .)
Zum Hintergrund: mit MQTT2_SERVER verwendet FHEM das vom Client gesendete ID dazu, um unterschiedliche Topics einem Geraet zuzuordnen. Wenn man (wie vmtl. alle anderen Loesungen) keinen integriertern MQTT Server zur Verfuegung hat, dann hat man keinen Zugriff auf das clientId, und man muss die unterschiedlichen Topics entweder manuell, oder mit Hilfskonstrukten ala homematic-topic einem Geraet zuordnen.
Aus mir nicht ganz nachvollziehbaren Grund generieren einige MQTT-Client-Bibliotheken bei jeder Verbindung eine neue clientId, was zu den o.g. Problemen fuehrt. Ob das jetzt ein "FHEM-Problem" oder "client-Bibliothek-Problem" ist, ist Ansichtssache, meiner Ansicht nach gehoert das im Client gefixt, wenigstens optional.
Es gibt mehrere Moeglichkeiten in FHEM das Problem zu loesen, z.Bsp. bei readingsList das automatisch dazugenerierte clientId manuell entfernen, oder mit einem Attribut in MQTT2_SERVER die ID festsetzen.
Zitat von: Beta-User am 16 August 2020, 08:10:29
Das mit der random CID steht afaik bei den "typischen Problemen" in den Praxisbeispielen (das darf auch gerne woanders hin).
Du meinst den Abschnitt? https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#bridgeRegexp
Den könnte man zumindest zur Erklärung immer mal verlinken.
Was ich über die typische mqtt Broker Welt so lese, spielt da CID überhaupt keine Rolle. Alle sind froh wenn sie sie nicht wissen oder brauchen. Der Broker ist der zentrale Punkt - ringsherum wird geplappert und gelauscht. Die Topics sind die, die für die "draussen" relevant sind. Die CID ist nur für den Broker wichtig damit der nicht durcheinander kommt. Da gibt es auch kein autocreate für automatische Zuhörer. ;) Nein stimmt wahrscheinlich nicht ganz: Es wird von einigen ein spezieller Topic erzeugt (z.B. homeassistant) aus dem macht eine Applikation irgendein spezielles Gerät. Alles andere wird automatisch ignoriert.
Für MQTT2_SERVER gibt es aus meiner Sicht zwei Vorgehensweisen:
- Man legt das Gerät, dass man will, manuell an. Mit entsprechenden Topics in readingList und setList
- Man nimmt das per autocreate erzeugte Gerät und verändert es so, dass in Zukunft kein neues Gerät erzeugt wird. Hat Rudi schon gesagt ;)
MQTT2_SERVER macht nämlich nur so lange neue Geräte wie kein MQTT2_DEVICE zuhört. Für 2. gibt es noch die schöne Sache der Templates.
Für ring-mqtt gibt es da jetzt noch keins. Könnte man als Ergebnis von dem Thread erzeugen. Ring Produkte sind ja auch in FHEM oft im Einsatz.
Gruß Otto
Gemeint war eigentlich https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F
Das mit dem clientId-Attribut am SERVER war mir bisher auch entgangen, muß ich da aaO in den Praxisbeispielen mal noch einarbeiten; ich finde das aber eher eine nicht ganz so empfehlenswerte Variante, sowas macht eigentlich dann auch wieder nur Sinn iVm. einem General-bridgeRegexp-Gerät, das man dann bei Bedarf erweitert. Das erfordert aber genau dasselbe Verständnis der Gesamtzusammenhänge wie das Löschen der CID aus den readingList-Attributen...
@Beta-User Vielleicht sollte man den Abschnitt (Mein Link ff. also auch Deiner) in einen eigenen Artikel MQTT2_SERVER auslagern? Den gibt es noch nicht :) dazu die Ergebnisse aus den Beiträgen von Rudi. Damit man das mal zusammen hat :)
Noch zum Thema von Sascha:
am Ende entsteht wahrscheinlich hier auch eine Dreierkombination:
MQTT2_SERVER
MQTT2_DEVICE als Bridge
MQTT2_DEVICEs als Ring Geräte
Die Bridge muss man konfigurieren damit die Ring Geräte erzeugt werden. Am Anfang und bei nur einem Ring Gerät ist nicht unbedingt eine Bridge nötig. Besser ist es sicher sie von Anfang an zu haben.
Muß ich mal drüber nachdenken. bridgeRegexp und das Verhalten von autocreate sind mMn. aber eigentlich Themen, die zu M2_DEVICE gehören und nicht zu M2_SERVER (M2_CLIENT verhält "sich" bei eingeschaltetem autocreate eigentlich auch nicht substantiell anders als M2_SERVER, man muß da eben nur selbst dafür sorgen, dass man eine "gute CID" zur Orientierung hat=vernünftige bridgeRegex-Ausdrücke).
Einen Artikel zu M2_SERVER hatte ich bisher v.a. deswegen nicht angelegt, weil ich keinen besonderen Bedarf dafür gesehen hatte, aber zwischenzeitlich gibt es gibt es wohl schon ein paar Kleinigkeiten, die man da reinpacken könnte (und den ansonsten als Verweisungsartikel gestalten).
Es gibt übrigens auch einen Thread zur Artikelstruktur@MQTT, vielleicht würde es Sinn machen, den wieder zu reaktivieren und dann auch die Frage aufzugreifen, was wie in Praxisbeispiele bleiben soll und was nicht (Das Milight-Thema könnte man z.B. auch noch ausgliedern, und Tasmota wäre dem Gefühl nach einen "upgrade" wert).
EDIT: Was die Struktur bei dieser Ring-Geschichte angeht, dürfte übrigens das zutreffen, was Otto geschrieben hatte. Es wäre ggf. mal zielführend, das Ding eine Weile laufen zu lassen und dann mal eine komplette RAW-Definition hier zu zeigen, dann können wir besser unterstützen?
(In dem Sonos-Thread ist ziemlich viel "neben" den Hauptthemen erörtert; vielleicht besser mal den ems-esp-Thread suchen, das ist nach meiner Erinnerung hier etwas "prototyischer" und leichter nachzuvollziehen (allerdings auf englisch); sonst den zigbee2tasmota-Thread, wobei da die JSON-Struktur "speziell" ist).
Hallo zusammen,
zuerst möchte ich mich noch einmal bei euch allen bedanken! :)
Leider ist es aufgrund Arbeit und anderer Dinge im Haus bei mir bisher liegengeblieben (man muss sich ja auch Zeit dafür nehmen, damit es ordentlich werden kann...).
Sobald ich wieder etwas mehr Luft habe, werde ich mich wieder ins Vergnügen stürzen --> der nächste Urlaub ist jetzt nicht mehr sooo lange entfernt und die Reisepläne haben sich in nicht-Reisepläne geändert ;)
Danach gibt's natürlich ein Update!
Viele Grüße
Sascha
Hallo zusammen,
sorry, für die lange Zeit bis zur Rückmeldung - leider ist es bei mir untergegangen :-(
Zum Überbrücken hatte ich einen Weg über IFTTT eingerichtet und MQTT aus den Augen verloren --> naja, in der aktuellen Zeit klingelt es ja auch nicht so oft.....
Da ich meine gesamte Netzwerk-Infrastruktur aber gerade auf UniFi umgestellt habe, holt es mich wieder ein ;D UniFi-Protect ist über Homebridge angeschlossen und MQTT aktiviert. Dort wird mqttjs verwendet und Überraschung: 1x bis 2x am Tag wird ein neues MQTT2-DEVICE angelegt. Irgendwie Karma, glaube ich :-D
Viele Grüße
Sascha
Zitat von: Sascha_F am 30 April 2021, 08:50:51
Hallo zusammen,
sorry, für die lange Zeit bis zur Rückmeldung - leider ist es bei mir untergegangen :-(
Zum Überbrücken hatte ich einen Weg über IFTTT eingerichtet und MQTT aus den Augen verloren --> naja, in der aktuellen Zeit klingelt es ja auch nicht so oft.....
Da ich meine gesamte Netzwerk-Infrastruktur aber gerade auf UniFi umgestellt habe, holt es mich wieder ein ;D UniFi-Protect ist über Homebridge angeschlossen und MQTT aktiviert. Dort wird mqttjs verwendet und Überraschung: 1x bis 2x am Tag wird ein neues MQTT2-DEVICE angelegt. Irgendwie Karma, glaube ich :-D
Viele Grüße
Sascha
Falls da eine Frage versteckt sein soll: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F
(das Grundproblem scheint _auch_ zu sein, dass der PAHO-Dienst entsprechend oft neu gestartet wird. Warum das passiert, solltest du klären, klingt nach einem bug. Ist aber _kein_ FHEM-Thema...!)
Hi! Wenn jemand eine Antwort parat hat, würde ich mich darüber natürlich nicht ärgern --> es sollte aber nur die längst überfällige Rückmeldung von mir sein. Das Problem selbst liegt nicht in FHEM, das ist mir klar - in FHEM kann ja nur verarbeitet werden, was vorne reinkommt.
Ich versuche mich gerade etwas hinsichtlich ClientID, 2. Broker-Instanz, etc. zu beschäftigen, um das für mich "in den Griff zu bekommen". Das hatte ich damals wohl entweder übersehen oder nicht richtig verstanden. Danke Dir aber natürlich trotzdem für den Link ins Wiki! :)
Viele Grüße ++ schönes WE
Sascha
Einfach hier (https://github.com/tsightler/ring-mqtt/blob/main/ring-mqtt.js):
// Initiate the connection to MQTT broker
function initMqtt() {
const mqtt = mqttApi.connect({
host:CONFIG.host,
port:CONFIG.port,
username: CONFIG.mqtt_user,
password: CONFIG.mqtt_pass
});
return mqtt
}
die Clientid dazu packen?
https://www.eclipse.org/paho/files/jsdoc/Paho.MQTT.Client.html
Hallo,
das Thema ist zwar schon etwas älter, ich habe aber vor kurzem ring-mqtt ausprobiert und finde es eigentlich sehr gut, da ich hierbei die Möglichkeit habe die Location (arm-away, arm-home, disarm) bei Ring zu verändern, was z.B bei fhempy oder anderen Ring-Lösungen nicht geht.
Ich habe 2 Ring Türklingeln und 1 Ring Chime sowie die Location in FHEM als MQTT2 Devices eingebunden. Im MQTT2-Server ist für meine FHEM Instanz eine feste ClientID vergeben.
Soweit so gut, aber ich habe exreme Schwierigkeiten mit meinen beiden Klingel. Diese laufen einige Tage problemlos, und irgendwann fangen sie an mein Log (in Verbose 5) mit folgenden Meldungen zu befüllen:
2022.07.28 21:55:12.281 1: ERROR evaluating my $CID= $evalSpecials->{'%CID'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $EVTPART1= $evalSpecials->{'%EVTPART1'};my $EVTPART2= $evalSpecials->{'%EVTPART2'};my $EVTPART3= $evalSpecials->{'%EVTPART3'};my $EVTPART4= $evalSpecials->{'%EVTPART4'};my $EVTPART5= $evalSpecials->{'%EVTPART5'};my $EVTPART6= $evalSpecials->{'%EVTPART6'};my $EVTPART7= $evalSpecials->{'%EVTPART7'};my $EVTPART8= $evalSpecials->{'%EVTPART8'};my $EVTPART9= $evalSpecials->{'%EVTPART9'};my $JSONMAP= $evalSpecials->{'%JSONMAP'};my $NAME= $evalSpecials->{'%NAME'};my $TOPIC= $evalSpecials->{'%TOPIC'};{return undef; { $TOPIC =~ m,$DEVICETOPIC\/.*\/([a-zA-Z\-_]+),; $1 eq 'ips'? {"ip4"=> (split ',',$EVENT)[0]}:{"$1"=>$EVENT} }}: Global symbol "$DEVICETOPIC" requires explicit package name (did you forget to declare "my $DEVICETOPIC"?) at (eval 55982946) line 1.
2022.07.28 21:55:12.281 3: Global symbol "$DEVICETOPIC" requires explicit package name (did you forget to declare "my $DEVICETOPIC"?) at (eval 55982946) line 1.
Nach einem Neustart von FHEM werden die Readings der beiden Klngeln nicht mehr aktualisiert, das Chime Device sowie Location Device gehen immer noch problemlos. Im MQTT-Explorer kommen aber immer noch munter alle Aktualisierungen der jeweiligen Topics an...
Nach Löschen und Neuanlgen der beiden Devices funktionieren sie wieder für ein paar Tage, bis spätestens FHEM zu BackUp-Zwecken wöchentlich heruntergefahren und neugestartet wird.
Mir ist auch aufgefallen, dass das erstellen des Snaphotes jeweils 2 mal im Millisekundenbereich folgenden Log-Eintrag erstellt:
2022.07.28 00:00:03.517 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/image => snapshotImage
2022.07.28 00:00:03.565 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/attributes => { json2nameValue($EVENT,'',$JSONMAP) }
2022.07.28 00:00:03.608 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/image => snapshotImage
2022.07.28 00:00:03.651 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/attributes => { json2nameValue($EVENT,'',$JSONMAP) }
2022.07.28 00:00:32.807 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/image => snapshotImage
2022.07.28 00:00:32.849 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/attributes => { json2nameValue($EVENT,'',$JSONMAP) }
2022.07.28 00:00:32.874 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/image => snapshotImage
2022.07.28 00:00:32.921 4: MQTT2_DEVICE_Parse: MQTT2_RING_HAUSTUER ring/u0u4dz-vm-0/camera/083a882690cc/snapshot/attributes => { json2nameValue($EVENT,'',$JSONMAP) }
Ich habe jetzt mal das Intervall von 30 Sekunden auf 10 Minuten abgehoben... Das Reading des Images ist eine Rohdatei, die aussieht wie die Karte bei Valetudo, vielleicht macht das ja auch Probleme
Anbei noch die Lists der jeweiligen Devices:
Chime:
Internals:
CID FHEM-MARDELLE5
DEF FHEM-MARDELLE5
FUUID 62a86817-f33f-8cc0-87b8-182c3877bd411c96
FVERSION 10_MQTT2_DEVICE.pm:0.258890/2022-03-27
IODev MQTT2_SERVER
LASTInputDev MQTT2_SERVER
MQTT2_SERVER_CONN MQTT2_SERVER_172.17.0.11_48024
MQTT2_SERVER_MSGCNT 180
MQTT2_SERVER_TIME 2022-07-29 12:13:51
MSGCNT 180
NAME MQTT2_RING_CHIME
NR 1044
STATE volume
TYPE MQTT2_DEVICE
eventCount 180
READINGS:
2022-07-28 21:57:35 IODev MQTT2_SERVER
2022-07-29 12:13:51 firmwareStatus Up to Date
2022-07-29 12:13:51 lastUpdate 2022-07-29T07:30:02Z
2022-07-28 21:58:57 minutes_remaining 0
2022-07-28 21:58:58 play_ding_soundState OFF
2022-07-28 21:58:58 play_motion_soundState OFF
2022-07-28 21:58:57 snoozeState OFF
2022-07-28 21:58:57 snooze_minutesState 150
2022-07-28 18:35:28 state volume
2022-07-29 11:48:57 subscriptions # $SYS/#
2022-07-29 06:15:08 volumeState 8
2022-07-29 12:13:51 wirelessNetwork MelowMennedy
2022-07-29 12:13:51 wirelessSignal -39
Attributes:
DbLogExclude .*
IODev MQTT2_SERVER
alias Chime
autocreate 0
devicetopic ring/u0u4dz-vm-0/chime/54e0195dcc62
readingList $DEVICETOPIC/volume/state:.* volumeState
$DEVICETOPIC/snooze/state:.* snoozeState
$DEVICETOPIC/snooze/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/snooze_minutes/state:.* snooze_minutesState
$DEVICETOPIC/play_ding_sound/state:.* play_ding_soundState
$DEVICETOPIC/play_motion_sound/state:.* play_motion_soundState
$DEVICETOPIC/info/state:.* { json2nameValue($EVENT,'',$JSONMAP) }
room 56_MQTT,78_Ring
setList volume:slider,0,1,11 $DEVICETOPIC/volume/command $EVTPART1
snooze:ON $DEVICETOPIC/snooze/command $EVTPART1
snooze_minutes:slider,0,10,1440 $DEVICETOPIC/snooze_minutes/command $EVTPART1
play_ding_sound:ON $DEVICETOPIC/play_ding_sound/command $EVTPART1
play_motion_sound:ON $DEVICETOPIC/play_motion_sound/command $EVTPART1
attr MQTT2_RING_CHIME stateFormat infoState
webCmd volume
Klingel 1:
Internals:
CID FHEM-MARDELLE5
DEF FHEM-MARDELLE5
FUUID 62e0e755-f33f-8cc0-5fe2-c136d8c0e055470d
FVERSION 10_MQTT2_DEVICE.pm:0.258890/2022-03-27
IODev MQTT2_SERVER
LASTInputDev MQTT2_SERVER
MQTT2_SERVER_CONN MQTT2_SERVER_172.17.0.11_48024
MQTT2_SERVER_MSGCNT 9
MQTT2_SERVER_TIME 2022-07-28 21:58:58
MSGCNT 9
NAME MQTT2_RING_HAUSTUER
NR 1062
STATE inactive
TYPE MQTT2_DEVICE
eventCount 9
READINGS:
2022-07-28 21:57:35 IODev MQTT2_SERVER
2022-07-28 21:51:46 eventId 7125470616654510585
2022-07-28 21:53:51 firmwareStatus Up to Date
2022-07-28 21:58:57 lastMotion 1659027911
2022-07-28 21:58:57 lastMotionTime 2022-07-28T17:05:11Z
2022-07-28 21:53:51 lastUpdate 2022-07-28T19:18:13Z
2022-07-28 21:58:57 motionDetectionEnabled true
2022-07-28 19:08:12 motionState OFF
2022-07-28 21:58:57 personDetected true
2022-07-28 21:58:58 status inactive
2022-07-28 21:53:51 still_Image_URL https://localhost:8123{{ states.camera.haustuer_snapshot.attributes.entity_picture }}
2022-07-28 21:58:58 streamState OFF
2022-07-28 21:53:51 stream_Source rtsp://172.17.0.11:8554/083a882690cc_live
2022-07-29 11:48:57 subscriptions # $SYS/#
2022-07-28 21:58:40 timestamp 1659038316
2022-07-28 21:53:51 wiredNetwork online
Attributes:
DbLogExclude .*
IODev MQTT2_SERVER
alias Ring Haustür
autocreate 0
devicetopic ring/u0u4dz-vm-0/camera/083a882690cc
readingList $DEVICETOPIC/ding/state:.* dingState
$DEVICETOPIC/motion/state:.* motionState
$DEVICETOPIC/light/state:.* lightState
$DEVICETOPIC/siren/state:.* sirenState
$DEVICETOPIC/info/state:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/stream/state:.* streamState
$DEVICETOPIC/event_stream/state:.* event_streamState
$DEVICETOPIC/event_select/state:.* event_select
$DEVICETOPIC/ding/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/motion/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/snapshot/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/stream/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/event_stream/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/event_select/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/snapshot/image:.* snapshotImage
room 56_MQTT,78_Ring
setList light:ON,OFF $DEVICETOPIC/light/command $EVTPART1
siren:ON,OFF $DEVICETOPIC/siren/command $EVTPART1
stream:ON,OFF $DEVICETOPIC/stream/command $EVTPART1
snapshot_interval:slider,10,100,604800 $DEVICETOPIC/snapshot_interval/command $EVTPART1
motion_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command Motion $EVTPART1
On-demand_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command On-demand $EVTPART1
Ding_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command Ding $EVTPART1
stateFormat status
verbose 5
Klingel 2:
Internals:
CID FHEM-MARDELLE5
DEF FHEM-MARDELLE5
FUUID 62e0e81f-f33f-8cc0-25ea-4a0f20d4baaeac27
FVERSION 10_MQTT2_DEVICE.pm:0.258890/2022-03-27
IODev MQTT2_SERVER
LASTInputDev MQTT2_SERVER
MQTT2_SERVER_CONN MQTT2_SERVER_172.17.0.11_48024
MQTT2_SERVER_MSGCNT 3
MQTT2_SERVER_TIME 2022-07-28 21:58:51
MSGCNT 3
NAME MQTT2_RING_TERRASSE
NR 1063
STATE inactive
TYPE MQTT2_DEVICE
eventCount 3
READINGS:
2022-07-29 11:49:01 IODev MQTT2_SERVER
2022-07-28 21:53:51 batteryLevel 100
2022-07-28 21:53:51 firmwareStatus Up to Date
2022-07-28 21:58:51 lastMotion 1658222686
2022-07-28 21:58:51 lastMotionTime 2022-07-19T09:24:46Z
2022-07-28 21:53:51 lastUpdate 2022-07-28T18:48:03Z
2022-07-28 21:58:51 motionDetectionEnabled true
2022-07-28 21:58:51 personDetected false
2022-07-28 21:58:51 status inactive
2022-07-28 21:53:51 still_Image_URL https://localhost:8123{{ states.camera.terrasse_snapshot.attributes.entity_picture }}
2022-07-28 21:58:51 streamState OFF
2022-07-28 21:53:51 stream_Source rtsp://172.17.0.11:8554/343ea41120cb_live
2022-07-29 11:48:57 subscriptions # $SYS/#
2022-07-28 21:53:51 wirelessNetwork MelowMennedy
2022-07-28 21:53:51 wirelessSignal -57
Attributes:
DbLogExclude .*
IODev MQTT2_SERVER
alias Ring Terrasse
autocreate 0
devicetopic ring/u0u4dz-vm-0/camera/343ea41120cb
disable 0
readingList $DEVICETOPIC/ding/state:.* dingState
$DEVICETOPIC/motion/state:.* motionState
$DEVICETOPIC/light/state:.* lightState
$DEVICETOPIC/siren/state:.* sirenState
$DEVICETOPIC/info/state:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/stream/state:.* streamState
$DEVICETOPIC/event_stream/state:.* event_streamState
$DEVICETOPIC/event_select/state:.* event_select
$DEVICETOPIC/ding/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/motion/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/snapshot/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/stream/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/event_stream/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/event_select/attributes:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/snapshot/image:.* snapshotImage
room 56_MQTT,78_Ring
setList light:ON,OFF $DEVICETOPIC/light/command $EVTPART1
siren:ON,OFF $DEVICETOPIC/siren/command $EVTPART1
stream:ON,OFF $DEVICETOPIC/stream/command $EVTPART1
snapshot_interval:slider,10,100,604800 $DEVICETOPIC/snapshot_interval/command $EVTPART1
motion_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command Motion $EVTPART1
On-demand_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command On-demand $EVTPART1
Ding_event_select:select,1,2,3,4,5 $DEVICETOPIC/event_select/command Ding $EVTPART1
stateFormat status
verbose 5
Location:
Internals:
CID FHEM-MARDELLE5
DEF FHEM-MARDELLE5
FUUID 62d68af9-f33f-8cc0-c38a-29cf5fd341cb650c
FVERSION 10_MQTT2_DEVICE.pm:0.258890/2022-03-27
IODev MQTT2_SERVER
LASTInputDev MQTT2_SERVER
MQTT2_SERVER_CONN MQTT2_SERVER_172.17.0.11_48024
MQTT2_SERVER_MSGCNT 7
MQTT2_SERVER_TIME 2022-07-29 10:56:18
MSGCNT 7
NAME MQTT2_RING_MODE
NR 1061
STATE armed_home
TYPE MQTT2_DEVICE
eventCount 13
READINGS:
2022-07-28 21:57:35 IODev MQTT2_SERVER
2022-07-29 10:56:18 modeState armed_home
2022-07-29 10:56:18 state mode
2022-07-29 11:48:57 subscriptions # $SYS/#
Attributes:
DbLogExclude .*
IODev MQTT2_SERVER
alias Location Mode
autocreate 0
devicetopic ring/u0u4dz-vm-0/alarm/u0u4dz-vm-0_mode/mode
readingList $DEVICETOPIC/state:.* modeState
room 56_MQTT,78_Ring
setList mode:select,disarm,arm_home,arm_away $DEVICETOPIC/command $EVTPART1
stateFormat modeState
webCmd mode
Falls jemand eine Ahnung hat, was da passiert, wäre ich dankbar :-)
Gruss Jan
Die Fehlermeldung wird bei der Analyse des readingsList Attributes generiert, das gleiche Code findet sich auch im valetudo AttrTemplate (Setzen des ip4 Readings).
Die Ursache ist die fehlende DEVICETOPIC Variable. Diese ist eigentlich immer gesetzt, es sei denn das devicetopic Attribut enthaelt Leerzeichen, und weist DEVICETOPIC nicht explizit zu, siehe https://fhem.de/commandref_modular.html#MQTT2_DEVICE-attr-devicetopic
Ob die fehlende Aktulisierung ein Folgefehler ist, kann ich nicht mit Sicherheit sagen, dazu muesste ich den Fehlerfall nachstellen koennen _und_ Rohdaten haben.
Hallo Rudolf,
ich habe mal ein 2. Device parallel angelegt, in dem das DEVICETOPIC nicht als Attribut gesetzt ist. Wie könntest Du an Rohdaten kommen bzw. was könnte ich zur Verfügung stellen...
Ich betreibe auch das noch nicht offizielle fhempy Modul von Dominik auf einem Peer und mir ist aufgefallen, dass nach einem Neustart von FHEM die Verbindung zum Peer fehlschlägt, was zu etlichen log Einträgen führt. Nicht dass sich da etwas in die Quere kommt. Ist mir bisher nicht aufgefallen, da ich den Peer jede Nacht neustarte und somit morgens alles normal läuft...
Werde die beiden Varianten jetzt mal so laufen lassen und dann Rückmeldung geben, ob es ohne Vorgabe des DEVICETOPIC als Attribut besser geht...
Wünsche ein schönes Wochenende,
Gruss Jan