ActionDetector

Begonnen von kossmann, 21 Januar 2013, 17:26:17

Vorheriges Thema - Nächstes Thema

kossmann

Zitat von: Billy schrieb am Di, 12 Februar 2013 11:16Nach einem shutdown restart [...] alle 22 Einträge gehen auf Unknown! Ist das so richtig?
Karneval ist vorbei, ich mach mal wieder mit :-)

Das ist zumindest bei mir auch so. Ich würde auch erwarten, dass der letzte Status in der fhem.save gespeichert und beim Neustart ausgewertet wird. Es hat aber vielleicht auch einen Grund, den müsste man uns wohl nur erklären ;-)

martinp876

nach restart geht der Zustand auf "unknown". Das ist beabsichtigt. Es koennten Daten fehlen,... zeitstempel usw. Je nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.

Wenn man haeufig neu startet koennte man Problem bekommen...
wenn man nur auf "dead" triggert sollte es trotzdem i.O. gehen. Es sei den man restarted mehrfach am Tag....

Das Befuellen der peerIDs des actionDetectors baue ich gerade um. Nach Restart wird die liste aus den attributen der Devices gefuellt. Muss ich noch einmal testen.
Eine aufraeum-procedur wird 5s nach dem letzten define ausgefuehrt - dann habe ich alle attribute zum pruefen. Danach sollte alles mit den Kommandos funktionieren


tobi73

Hi Martin,

Zitatnach restart geht der Zustand auf "unknown". Das ist beabsichtigt. Es koennten Daten fehlen,... zeitstempel usw. Je nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.

Ok, leuchtet ein. Allerdings habe ich beobachtet, dass auch nach einem rereadcfg die Werte auf unknown gehen. Ist das auch beabsichtigt / sinnvoll? Gruß Tobi

justme1968

hallo martin,

könnte man nicht zumindest nach einem neustart den status auf alive setzen wenn das letzte reading nicht länger her ist als actCycle ?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Billy

Zitat von: martinp876 schrieb am Di, 12 Februar 2013 14:08nach restart geht der Zustand auf "unknown". Das ist beabsichtigt.
Ok das ist so!
ZitatJe nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.
Das ging bei mir nicht! Habe um 10:57:43 einen restart gemacht, seitdem peerIDs komplett gelöscht und alle 22 Einträge gingen und bleiben auf Unknown! Auch bei den Devices bleibt seitdem der Staus auf "actStatus unknown"
ZitatDas Befuellen der peerIDs des actionDetectors baue ich gerade um. Nach Restart wird die liste aus den attributen der Devices gefuellt.
Löst das dann dieses Problem?
Gruss Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

@Billy
das Fehlzaehlen kommt daher, dass ein device nach dem ersten Zaehlem addiert wurde. Der state wird erst nach Ablauf des Timers neu gesetzt. Devices werden aber sofort addiert und mit dem Status unknown versehen

Kannst du einmal nachsehen, ob der ActionDetector laeuft? Der Zeitstempel des Status sollte sich mir jedem Ablauf erneuern...

@Andre
Nach dem restart sind die Zeitstempel rar. Fast alle sind weg, ausser die an den readings (es sei den, das Device sendet etwas).
Und an den readings muss man unterscheiden, ob es ein wirkliches reading oder ein set-kommando war.
Hast du einen Zeitstempel, der immer da ist?

Gruss
Martin

justme1968

hallo martin,

ich habe beim bewegungsmelder und den fenstergriffen jewels ein battery reading. da eine hauptanwendug die batterie betriebenen geräte sind könnte man zumindest da wo es ein battery ok reading im zeitfenster actCycle gibt den status nach neustart auf alive setzen. wer genau das mutwillig von hand setzt hätte dann wirklich pech gehabt.

ich gebe aber zu ich bin nicht ganz objektiv. ich starte mein system zur zeit mehrfach am tag weil es auch das system ist auf dem ich entwickle.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

kossmann

Zitat von: justme1968 schrieb am Di, 12 Februar 2013 21:42da wo es ein battery ok reading im zeitfenster actCycle gibt den status nach neustart auf alive setzen. wer genau das mutwillig von hand setzt hätte dann wirklich pech gehabt.
Da würde ich Andre voll zustimmen. Es gibt doch auch wesentlich relevantere Daten, die sich FHEM aus der fhem.save beim Starten holt. Fenster open/tilted/closed z.B. - dies ist in meinen Augen sicherheitsrelevanter als eine Batterie, wird aber aus der fhem.save genommen. Genau so könnte es man doch auch beim ActionDetector machen, oder?

martinp876

Ich denke, ihr habt nich ueberredet. Ich habe da sowieso noch ein paar umbauten vor, mit den Kommandos.

- ActionDetect wird ueber "attr actCycle" ein und ausgeschaltet
- das Kommando actiondetect abgeschafft
- beim start werden die readings nach den neusten Eintrag durchsucht und der Status gesetzt.

Gruss
Martin

Billy

@ Martin zur Info!
Mit der 10_CUL_HM.pm.2711 läuft der ActionDetector jetzt wieder an, die peerIDs sind nach restart vorhanden.

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

martinp876

hoffentlich läuft er immer noch
habe den actionDetector teilweise um-designed.
Das Kommando actiondetect ist geschichte, jetzt einfach das Attribut actCycle setzen.
Ausserdem werden bei einem Restart und beim Eintragen eines Device die Readings als referenz hergenommen - mit Filter natürlich.

Zu tun ist nichts, sollte (hoffentlich) einfach laufen.

Gruss
Martin

Billy

Ja er läuft immer noch, habe jetzt die 10_CUL_HM.pm.2719 geladen.

Werde morgen mal berichten.

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

Billy

Hallo Martin, zur Info

Nach dem Einspielen der 10_CUL_HM.pm.2719 hat es mir die
fhem.cfg
komplett verspult! Bin jetzt wieder auf die alte Version 10_CUL_HM.pm.2711 zurück.
Hatte Gottseidank ein backup der Konfig.

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

kossmann

Zitat von: martinp876 schrieb am Mi, 13 Februar 2013 19:47hoffentlich läuft er immer noch
habe den actionDetector teilweise um-designed.
Das Kommando actiondetect ist geschichte, jetzt einfach das Attribut actCycle setzen.
Ausserdem werden bei einem Restart und beim Eintragen eines Device die Readings als referenz hergenommen - mit Filter natürlich.

Zu tun ist nichts, sollte (hoffentlich) einfach laufen.
Hallo Martin,

kommt der ActionDetector jetzt über ein autocreate und dies dann im "room CUL_HM"? Mir flog meine Konfiguration eben um die Ohren. Was darf ich von folgender Konfiguration nun nicht mehr verwenden und was muss ich ggf. an anderer Stelle ergänzen?

define ActionDetector CUL_HM 000000
  attr ActionDetector actCycle 600
  attr ActionDetector peerIDs 1CC...,1C2...,1C2...,1C2...,1DC... # 3x Rauchmelder, 1x Fenstergriff, 1x KeyMatic
  attr ActionDetector room System

define ActionDetector_FileLog FileLog ./log/ActionDetector.log ActionDetector
  attr ActionDetector_FileLog logtype text
  attr ActionDetector_FileLog room Logfiles

Billy

ZitatMir flog meine Konfiguration eben um die Ohren.
Mir auch siehe oben, also ein Bug?

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