HMinfo - Fehlermeldung bei - set hm peerCheck

Begonnen von new_rasp, 20 März 2015, 21:24:26

Vorheriges Thema - Nächstes Thema

new_rasp

Wenn ich einen -  set hm peerCheck - mache dann wird folgendes angezeigt:
configCheck done:

trigger sent to unpeered device
    triggerUnpeered: OG_Bewe_Toi:354xxx

trigger sent to undefined device
    triggerUndefined: OG_Bewe_Toi:354xxx

MDIR funktioniert (bis auf die Helligkeit) ohne Probleme.

Bei den Internals vom OG_Bewe_Toi:
peerList OG_Treppenlicht
Hier sind dann auch PeerIDs von den zwei MDIR zu finden.

An einen Switch LC_SW2 sind somit zwei Bewegungsmelder gepeert.

Nachtrag:
Hab jetzt mal ein Update/Upgrade gemacht und alles neu gestartet. Jetzt bekomm ich noch folgendes:
Error messages while initializing FHEM:
statefile: Please define ActionDetector first
Please define ActionDetector first
Please define ActionDetector first
Please define ActionDetector first

Nachtrag2:
Nach erneuten Start ist der Fehler mit dem ActionDetector wieder weg.

Zu peerCheck:
Hab jetzt folgendes hier gefunden:
trigger sent to unpeered device
der Kanal triggert peers, die nicht in seiner peerListe auftauchen - prüfe die Konfiguration, ob dies ok geht.

trigger sent to undefined device
der Kanal triggert peers, die nicht in FHEM bekannt (definiert) sind.  prüfe die Konfiguration.

Erneutes pairen und peeren bringt irgendwie nix...

new_rasp

Fehlermeldung ist nun weg.
Hab jetzt x-mal neu gepaired - gepeered - get config ...
Scheint jetzt weg zu sein.

new_rasp

Also bei dem zweiten ist die Meldung jetzt weg. Dafür hab ich einen dritten hinzugefügt. Der zeigt wieder das gleiche Verhalten!

configCheck done:

trigger sent to unpeered device
    triggerUnpeered: OG_Bewe_Treppe:354xxx

trigger sent to undefined device
    triggerUndefined: OG_Bewe_Treppe:354xxx

Ist das normal das sich jeder MDIR so verhält?

martinp876

Du kannst im mdir nachsehen, welche trigger er ausloest. Diese sollten an peers gehen, die auch in den attributen auftauchen. Wenn es weitere trigger gibt kannst du pruefen warum, wann die kommen, wohin,.....

new_rasp

Also wenn ich den MDIR im Event Monitor bei Auslösung anschaue:

2015-03-22 14:38:07 CUL_HM OG_Bewe_Treppe motion
2015-03-22 14:38:07 CUL_HM OG_Bewe_Treppe motion: on (to Treppenlicht)
2015-03-22 14:38:07 CUL_HM OG_Bewe_Treppe motionCount: 102_next:14s
2015-03-22 14:38:07 CUL_HM OG_Bewe_Treppe brightness: 72
2015-03-22 14:38:07 CUL_HM OG_Treppenlicht trig_OG_Bewe_Treppe: 72
2015-03-22 14:38:07 CUL_HM OG_Treppenlicht trigLast: OG_Bewe_Treppe :72
2015-03-22 14:38:09 CUL_HM OG_Treppenlicht level: 100
2015-03-22 14:38:09 CUL_HM OG_Treppenlicht pct: 100
2015-03-22 14:38:09 CUL_HM OG_Treppenlicht deviceMsg: on (to broadcast)
2015-03-22 14:38:09 CUL_HM OG_Treppenlicht on
2015-03-22 14:38:09 CUL_HM OG_Treppenlicht timedOn: running
2015-03-22 14:38:10 CUL_HM EG_Treppenlicht level: 100
2015-03-22 14:38:10 CUL_HM EG_Treppenlicht pct: 100
2015-03-22 14:38:10 CUL_HM EG_Treppenlicht deviceMsg: on (to broadcast)
2015-03-22 14:38:10 CUL_HM EG_Treppenlicht on
2015-03-22 14:38:10 CUL_HM EG_Treppenlicht timedOn: running
2015-03-22 14:38:42 CUL_HM OG_Treppenlicht level: 0
2015-03-22 14:38:42 CUL_HM OG_Treppenlicht pct: 0
2015-03-22 14:38:42 CUL_HM OG_Treppenlicht deviceMsg: off (to broadcast)
2015-03-22 14:38:42 CUL_HM OG_Treppenlicht off
2015-03-22 14:38:42 CUL_HM OG_Treppenlicht timedOn: off
2015-03-22 14:38:42 CUL_HM EG_Treppenlicht level: 0
2015-03-22 14:38:42 CUL_HM EG_Treppenlicht pct: 0
2015-03-22 14:38:42 CUL_HM EG_Treppenlicht deviceMsg: off (to broadcast)
2015-03-22 14:38:42 CUL_HM EG_Treppenlicht off
2015-03-22 14:38:42 CUL_HM EG_Treppenlicht timedOn: off

Im MDIR selbst sind auch beide eingetragen:

peerList OG_Treppenlicht,EG_Treppenlicht

Gegencheck beim OG_Treppenlicht,EG_Treppenlicht. Hier steht der MDIR ebenfalls drin.

Hab gelesen das man VCCU anlegen soll. Das wäre in meinen Fall aber eigentlich nicht nötig weil ich mit dem USB-Stick hier überall hin komme wo ich will. Aber anscheinend soll die Fehlermeldung dann nicht mehr kommen!?
Sollte meiner Meinung aber auch ohne VCCU fehlerfrei funktionieren oder?

martinp876

Es ist kein entsprechender Trigger zu sehen. HMInfo liest aber die Readings für diese Auswertung. Dort sollte demnach einer stehen. Ist das so und ist der timestamp entsprechend neu? Also auch vom letzten trigger?

die ID, welche bemängelt wird ist die vom HMUSB?
eine VCCU kann man immer einrichten - hätte ich eigentlich immer und automatisch gemacht. Aber da gab es das Konzept schon.
Vorteile hat sie ein paar mehr also nur multi-IO.

Mit clear trigger kannst du aufräumen und alle trigger-readings löschen. danach sollte HMInfo glücklich sein - bis wieder ein trigger kommt.
wenn es dann immer noch passiert logge die rohmessages und schicke die peeringeinträge des MDIR (attr peerIds)

new_rasp

Hab jetzt einfach mal alle readings gelöscht. Jetzt ist der Fehler weg. Kommt auch nicht wieder beim Trigger! Somit scheint es so als würde ich jetzt keinen Fehler mehr bekommen.

Da sag ich doch gleich mal Dankeschön! :)

martinp876

noch einmal allgemein:
die Meldung ist an den trigger-readings festgemacht. solange die da ist kommt ggf die Meldung.
man muss nicht alle Readings löschen um es zu bereinigen (könnte einmal vorgekommen sein, dass ein solcher trigger kam). clear trigger löscht selektiv die relevanten Readings.