HM-LC-SW1-BA-PCB Statusabfrage

Begonnen von Thomas81, 12 März 2013, 18:39:59

Vorheriges Thema - Nächstes Thema

Thomas81

Hallo
erst mal herzlichen dank an alle die es möglich machen das es Fhem, dieses Forum FhemWiki... gibt.
Hatte zu Weihnachten nach einen Verwendungszweck für meinen Raspberry Pi gesucht, und auch gefunden. Habe mittlerweile 3 HM Temperatursensoren sowie einen Aktor im Einsatz.
Nun möchte ich bei meinem Aktor HM-LC-SW1-BA-PCB den Status nach einer Zustandsänderung  kontrollieren, antwortet dieser nicht soll ein Mail gesendet werden.  
Nun ist es ja so das nach z.B. dem Einschalten kurz ,,ACK Missing" als Status gesetzt wird, bis on kommt. D.h. daß kann ich nicht direkt abfragen.
Derzeit werte ich über 2 Dummys mit einer Zeitverzögerung den Status aus.  Und frage dann HMAktor1State ab. Dies ist keine sehr schöne Lösung,  funktioniert aber.
Habt Ihr bessere ideen?


define HMAktor1State dummy
attr HMAktor1State room CUL_HM
define HMAktor1Fehlermerker dummy

define HMAktor1Check notify HMAktor1 {if (Value("HMAktor1") eq "on" or Value("HMAktor1") eq "off") {fhem "set HMAktor1State ok"}else{fhem "define a5 at +00:00:03 set HMAktor1Fehlermerker on"}}

define HMAktor1Check2 notify HMAktor1Fehlermerker {if (Value("HMAktor1") eq "on" or Value("HMAktor1") eq "off") {fhem "set HMAktor1State ok";;fhem "set HMAktor1Fehlermerker off"}else{fhem "set HMAktor1State FEHLER";;fhem "set HMAktor1Fehlermerker off"}}




martinp876

Hallo Thomas,

der BA-PCB ist ein "burst" device - kann also nicht mit der CUL 'befragt werden, nur monitoring ist moeglich.
mit HMLAN sollte es funktionieren, du hast also ein HMLAN im Einsatz?

Das missing-ack verstehe ich nicht, muesstest du logs aufnehmen und schicken.

Eigentich willst du doch auf missingACK oder Protokollfehler abfragen. Ein missing-ack kommt nach einer Zeitverzögerung - wenn alle wiederholer schiefgegangen sind. Sollte also reichen?

Gruss
Martin

Rohan

Hallo Thomas,

Zitat von: Thomas81 schrieb am Di, 12 März 2013 18:39define HMAktor1Check notify HMAktor1 {if (Value("HMAktor1") eq "on" or Value("HMAktor1") eq "off") {fhem "set HMAktor1State ok"}else{fhem "define a5 at +00:00:03 set HMAktor1Fehlermerker on"}}

define HMAktor1Check2 notify HMAktor1Fehlermerker {if (Value("HMAktor1") eq "on" or Value("HMAktor1") eq "off") {fhem "set HMAktor1State ok";;fhem "set HMAktor1Fehlermerker off"}else{fhem "set HMAktor1State FEHLER";;fhem "set HMAktor1Fehlermerker off"}}

Kleine Randnotiz: die beiden "or" oben sollten evtl. besser gegen "||" getauscht werden. In Perl gibt es auch "or", aber für z.B.:

sub or3 {
    my ($a,$b) = @_;
    (return $a) or $b;
}


oder

@info = stat($file) or die;

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

martinp876

oder....

define HMAktor1Check notify HMAktor1 {if (Value("HMAktor1") =~ m/^(on|off)$/) {fhem "set HMAktor1State ok"}else{fhem "define a5 at +00:00:03 set HMAktor1Fehlermerker on"}}


Thomas81

Hallo

Danke für die Infos. Habe mir nachdem ich eure Beiträge gelesen habe gedach, möglicherweise lag es an der mieserablen Spannungversorgung welche ich beim Testen hatte (Spannungseinbruch beim einschalten des Relais)... daher warscheinlich das missing-ack, das ist nun weg.

Habe nun folgendes probiert (Spannungsversorgung nun ok):

define HMAktor1Check notify HMAktor1 {if (Value("HMAktor1") eq "on" || Value("HMAktor1") eq "off") {fhem "set HMAktor1State ok"}else{fhem "set HMAktor1State FEHLER"}}

Mit HMAktor1State FEHLER wird das Mail gesendet.

Warum wird HMAktor1State FEHLER gesetzt?

Fogendes steht im Log:

2013.03.13 18:12:53 1: HMLAN_Parse: HMLAN1 S:E1ED439   stat:0000 t:2E2B9FD0 d:FF r:FFB0 m:9286701ED439000000011464
2013.03.13 18:12:54 1: HMLAN_Send:  K
2013.03.13 18:12:54 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315535,1C6656,1132AB,2E2BA407,0001

2013.03.13 18:12:54 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315535 d:1C6656 O:1132AB m:2E2BA407 IDcnt:0001
2013.03.13 18:13:19 1: HMLAN_Send:  K
2013.03.13 18:13:20 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315535,1C6656,1132AB,2E2C074B,0001

2013.03.13 18:13:20 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315535 d:1C6656 O:1132AB m:2E2C074B IDcnt:0001
2013.03.13 18:13:44 1: HMLAN_Send:  K
2013.03.13 18:13:44 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315535,1C6656,1132AB,2E2C6817,0001

2013.03.13 18:13:44 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315535 d:1C6656 O:1132AB m:2E2C6817 IDcnt:0001
2013.03.13 18:13:57 1: dummy set HMAktor1State FEHLER
2013.03.13 18:13:57 1: sendEmail RCP:
2013.03.13 18:13:57 1: sendEmail Subject: Modulfehler in Comline1004 Anschaltmodul
2013.03.13 18:13:57 1: sendEmail Text:
2013.03.13 18:14:05 1: sendEmail returned: Mar 13 18:14:05 raspberrypi sendEmail[20190]: Email was sent successfully!
2013.03.13 18:14:05 1: CUL_HM set HMAktor1 on rxt:2
2013.03.13 18:14:05 1: HMLAN_Send:  S64BE9966,00,00000000,01,64BE9966,0CB0111132AB1D7E700201C80000
2013.03.13 18:14:05 1: HMLAN/RAW: /R64BE9966,0001,2E2CB9CA,FF,FFAF,0C80021D7E701132AB0101C80050

2013.03.13 18:14:05 1: HMLAN_Parse: HMLAN1 S:R64BE9966 stat:0001 t:2E2CB9CA d:FF r:FFAF m:0C80021D7E701132AB0101C80050
2013.03.13 18:14:05 1: dummy set HMAktor1State ok
2013.03.13 18:14:05 1: dummy set HMAktor1State ok
2013.03.13 18:14:05 1: dummy set HMAktor1State ok
2013.03.13 18:14:09 1: HMLAN_Send:  K
2013.03.13 18:14:09 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315535,1C6656,1132AB,2E2CC9C6,0001

2013.03.13 18:14:09 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315535 d:1C6656 O:1132AB m:2E2CC9C6 IDcnt:0001
2013.03.13 18:14:14 1: dummy set HMAktor1State FEHLER
2013.03.13 18:14:14 1: sendEmail RCP:
2013.03.13 18:14:14 1: sendEmail Subject: Modulfehler in Comline1004 Anschaltmodul
2013.03.13 18:14:14 1: sendEmail Text:
2013.03.13 18:14:19 1: sendEmail returned: Mar 13 18:14:19 raspberrypi sendEmail[20194]: Email was sent successfully!
2013.03.13 18:14:19 1: CUL_HM set HMAktor1 off rxt:2
2013.03.13 18:14:19 1: HMLAN_Send:  S64BED2E4,00,00000000,01,64BED2E4,0DB0111132AB1D7E700201000000
2013.03.13 18:14:20 1: HMLAN/RAW: /R64BED2E4,0001,2E2CF34A,FF,FFAE,0D80021D7E701132AB010100004D

2013.03.13 18:14:20 1: HMLAN_Parse: HMLAN1 S:R64BED2E4 stat:0001 t:2E2CF34A d:FF r:FFAE m:0D80021D7E701132AB010100004D
2013.03.13 18:14:20 1: dummy set HMAktor1State ok
2013.03.13 18:14:20 1: dummy set HMAktor1State ok
2013.03.13 18:14:20 1: dummy set HMAktor1State ok
2013.03.13 18:14:34 1: HMLAN_Send:  K
2013.03.13 18:14:34 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315535,1C6656,1132AB,2E2D2B77,0001

2013.03.13 18:14:34 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315535 d:1C6656 O:1132AB m:2E2D2B77 IDcnt:0001

martinp876

hm - lass mich mal notifies ueben.

deiner loest aus immer wenn ein trigger fuer HMAktor1 kommt EGAL welcher. Dann wurd geprueft wie jetzt gerade der state vom HMAktor1 ist.

Erster trigger kommt beim set-kommando. Da wird der state auf "set_on" gesetzt
=> Fehler wird generiert
Danach meldet sich das device und acked das schalten
HMAktor1 state
HMAktor1 batterie
HMAktor1 deviceMsg
=> 3 trigger, 3mal passt die regexp deines notify.

==> mit jedem schalter bekommst du immer einen fail - und dann kommt es auf den Aktor an.

Jetzt muss ich erst einmal nachsehen, was du eigentlich wolltest:
- pruefen ob von der Zentrale gesendete Kommandos abgearbeitet werden?
- Kommandos/trigger von remotes sind egal?
- Kommandos ohne Statusaenderung muessen nicht ueberwacht werden? (regset, getConfig....)

Wenn dein Anliegen ist "negative Protokoll-events" abzufangen ist dies sicher sinnvoll, aber deine urspruengliche und die jetzige Loesung werden dem nicht wirklich gerecht.

wie waere es mit
define HMAktor1Check notify HMAktor1 {if (Value("HMAktor1") !~ m/MISSING/) {<send email>}}

oder - sollte sparsamer sein in der Performance
define HMAktor1Check notify HMAktor1:state.*MISSING.* {<send email>}

oder - oder alle devices in einem
define HMAktor1Check notify .*:state.*MISSING.* {<send email>}

send-email meusstest du selbst einbauen....

kommt das hin?
Gruss
Martin

Martin Thomas Schrott

Hi zusammen,

@Martin, aber das sendet dann die mail auch wenn nur ein missing ack für z.B. die erste von drei wiederholten messages zurückgekommen ist und der status bei der zweiten doch geändert wurde. Macht das Sinn?

Aber ich wüsste jetzt auch keine perfekte Lösung, daher einfach nur der obige Senf, kein Nutzen.

LG
Martin

martinp876

Hi Martin,
Zitat@Martin, aber das sendet dann die mail auch wenn nur ein missing ack für z.B. die erste von drei wiederholten messages zurückgekommen ist und der status bei der zweiten doch geändert wurde. Macht das Sinn?

wieso? "missing ack" kommt, wenn die 3. Wiederholung erfolglos war und FHEM abbricht.

resend zaehler kannst du in protoReSend sehen

Gruss
Martin

Thomas81

hmm...

Bin davon ausgegangen das state nur den tatsächlichen Schaltzustand wiedergibt...

Ziel ist es zu überprüfen ob die gesendeteten Kommandos vom Aktor umgesetzt werden, wenn nicht, umgehend benachrichtigt zu werden.

martinp876

state gibt an
wenn "on" gesendet wird kommt ein "set_on". wir wissen nicht, ob das Licht "on" ist, aber das Kommando  ist unterwegs... Der Zustand ist also "unsicher" oder changing

geht auf "on" wenn das device (warum auch immer) "on" meldet. Das kann auch durch einen anderen trigger kommen

"missing ack" an device wenn ein kommendo mit ack-request KEIN ack zurueckschickt.

Gruss
Martin