HM-WDS40-TH-I kein Batteriestatus

[martinp876]

Hi Doc,

jetzt habe ich noch einen für dich:

set KESZ_TempHumSensor raw ++A001E1F88A2067730000

aus deinen Logs kann ich nur sehen, dass der Sensor keine List1 hat.

Ich habe noch einmal nachgesehen - auch mein SW2 beschreibt einen bat-level. Der macht hier aber keinen Sinn. Der WDS sollte es schon können... einfach unklar an dieser Stelle

Gruss Martin

[docb]

Moin moin,
die hieroglyphen habe ich abgeschickt, kurz gewartet, zur Sicherheit kurz anlernen gedrückt und nochmal eine Minute gewartet.
Hier der Log:

[code
2013.07.22 09:45:15 1: HMLAN_Parse: LANInterface V:03C1 sNo:IEQ0061715 d:139895 O:E1F88A t:1C23DCF4 IDcnt:000C
2013.07.22 09:45:15 1: HMLAN_Send:  LANInterface I:K
2013.07.22 09:44:50 1: HMLAN_Parse: LANInterface V:03C1 sNo:IEQ0061715 d:139895 O:E1F88A t:1C237B42 IDcnt:000C
2013.07.22 09:44:50 1: HMLAN_Send:  LANInterface I:K
2013.07.22 09:44:25 1: HMLAN_Parse: LANInterface V:03C1 sNo:IEQ0061715 d:139895 O:E1F88A t:1C23198A IDcnt:000C
2013.07.22 09:44:25 1: HMLAN_Send:  LANInterface I:K
2013.07.22 09:44:18 1: HMLAN_Parse: LANInterface R:R055606FF stat:0001 t:1C22FFFF d:FF r:FFAE     m:1B 8002 206773 E1F88A 00
2013.07.22 09:44:18 1: HMLAN_Send:  LANInterface S:S055606FF stat:  00 t:00000000 d:01 r:055606FF m:1B A001 E1F88A 206773 0000
2013.07.22 09:44:18 1: HMLAN_Send:  LANInterface I:+206773,00,00,
2013.07.22 09:44:18 1: HMLAN_Parse: LANInterface R:E206773   stat:0000 t:1C22FF02 d:FF r:FFAE     m:F6 8400 206773 000000 12003F4B45513030343835323270030100
2013.07.22 09:44:10 1: HMLAN_Parse: LANInterface R:E2067A1   stat:0000 t:1C22E14B d:FF r:FFD1     m:24 8670 2067A1 000000 00FA33
2013.07.22 09:44:02 1: HMLAN_Parse: LANInterface R:R0555C89C stat:0002 t:00000000 d:FF r:7FFF     m:9A 8002 E1F88A 1C571F 01015F00
2013.07.22 09:44:02 1: HMLAN_Send:  LANInterface S:S0555C89C stat:  00 t:00000000 d:01 r:0555C89C m:9A 8002 E1F88A 1C571F 01015F00
2013.07.22 09:44:02 1: HMLAN_Parse: LANInterface R:E1C571F   stat:0000 t:1C22C0A4 d:FF r:FFBD     m:9A 8410 1C571F E1F88A 06015F00
2013.07.22 09:44:00 1: HMLAN_Parse: LANInterface V:03C1 sNo:IEQ0061715 d:139895 O:E1F88A t:1C22B7D7 IDcnt:000B
2013.07.22 09:44:00 1: HMLAN_Send:  LANInterface I:K
2013.07.22 09:43:56 3: ############################################################# Loglevelschleife teston

[/code]

Viele Grüße
doc

[martinp876]

nein, leider auch keine Reaktion...

[docb]

Moin moin,
jetzt habe ich ein Virtuelles Device erstellt (Vact_Hum_dev) und den KESZ_TempHumSensor per peerBulk hoffentlich gepeert. Was soll ich jetzt absetzen?
Viele Grüße
doc

[martinp876]

Hi Doc,

Ob gepeert ist kannst du mit getConfig prüfen (nur dass ist die ultimative Wahrheit)
 Die Frage ist, ob jetzt neue Messages kommen, also einfach einmal loggen.

Gruss Martin

[docb]

Moin moin,
also gepeert ist, beim KESZ_TempHumSensor steht "Vact_Hum_dev_Btn1," in der peerList.
Ich habe das Log mal über Nacht mitlaufen lassen. Nachdem fhem jetzt crasht wenn ich das Log aufrufen (viel zu groß geworden), hab ich es als Textdatei rauskopiert - denke da kannst du auch besser suchen/finden.
Merci schon mal und viele Grüße
doc

[martinp876]

Hallo Doc,

leider kann man immer noch nichts sehen. Somit sehe ich leider keinen Batteriestatus irgendwo.
Damit habe ich keine Ahnung, wo man noch suchen könnte.

oder: es gibt noch einen Versuch, wenn du willst. Ein Byte, das u.A. sabotagemessage enthält. Vielleicht steuert es etwas. Keine Ahnung, was es macht.

Also
set KESZ_TempHumSensor regBulk RegL_00:   0F:FF

danach noch einmal ein getConfig und eine Zeit warten, ob messages kommen

Sorry, Gruss Martin

[docb]

Moin moin,
gesagt getan und im Anhang das Logfile...
Und noch eine Frage: fhem loggt mir jetzt nur noch alles mit - wie im angehängten logfile. Obwohl ich den loglevel des HMLAN wieder auf 3 gesetzt habe. Auch ein shutdown restart hat nix geholfen. Was hab ich denn da für einen Wurm drin?
Viele Grüße
doc

[martinp876]

schau dir
attr global verbose einmal an. Das ist der 'ober-Filter'. Sollte auf 3 stehen, jetzt wahrschienlich 1

[docb]

Moin,
global verbose seht auf 3... und trotzdem logt fhem noch wie ein wahnsinniger ;-)
gibts noch irgeneine Einstellung, die ich da irgendwo übersehen habe?

Hast im Logfile noch was erkannt nachdem ich deine geheime Geheimmessage geschickt habe? ;-)
Viele Grüße
doc

[martinp876]

hast du auch die loglevel gelöscht? Hier speziell den in HMLAN?
loglevel setzt alle logs einer Entity auf ein Niveau (HMLAN will ich immer auf 1 zum Testen) - sofern korrekt programmiert.
wenn du es löschst werden die default werte genutzt

Gruss Martin

[docb]

Gelöscht nicht, sondern auf 3 gesetzt:

Attributes:
   icon       hm_lan
   loglevel   3
   room       Z_System
   wdTimer    25

Viele Grüße
doc

[martinp876]

der mechanismus ist "anders".

verbose legt fest bis zu welchem Level logs ausgegeben werden. 3 gibt alle Logs mit prio 0-3 aus.

Alle Logs haben im code eine default prio. Mit loglevel (nicht jeder programmierer zieht es komplett durch) kannst du die Prio überschreiben. Wenn du für eine Entity '3' setzt werden alle Logs dieser Entity mit prio3 gesendet.

wenn du also HMLAN auf 3 setzt (prio) und verbose auf 3(filter) kommt wieder alles von HMLAN plus alle anderen Logs mit Prio 3 default.

Also löschen von Loglevel ist also die Lösung.

Gruss Martin

[docb]

Ah... super. Hab gleich meine Routine umgeschrieben. Falls du die brauchen kannst, wenn du da öfters umstellst:

Code Auswählen Erweitern

sub Loglevel() {
   my $ziel = ReadingsVal("FullLog", "state", 99);
   Log 3,("############################################################# Loglevelschleife test".$ziel);
   if ($ziel eq "on") {
    fhem ("attr global verbose 1");
    fhem ("attr LANInterface loglevel 1");
   } else {
    fhem ("attr global verbose 3");
    fhem ("deleteattr LANInterface loglevel");
fhem ("rereadcfg");
   }
  }
Brauchst nur einen Dummy namens FullLog.
Hast du eigentlich aus dem zweiten Logfile nach deinem Spezialbefehl set KESZ_TempHumSensor regBulk RegL_00: 0F:FF noch was rauslesen können?
Viele Grüße
doc

[martinp876]

Hi Doc,

nein, da konnte ich nichts mehr rauslesen. Das Register wird i.A. zum blocken der lokalen Buttons genutzt.

Auch wenns nicht weiter hilft: es wird ein maintenance-channel beschrieben, nur nicht, wie man den aktiv abfragen kann. Da sollte der Bat-Status versteckt sein.

Leider kann man bei diesem Device den Status nicht abfragen...
Ziemlich blöd, aber aktuell habe ich keine Idee.

Gruss Martin