HM-PB-2-WM55 wieder mal ACK !!!REOPEN!!!

[rufus999]

Hallo zusammen,

ich habe vor einigen Monaten schon einmal das selbe Problem gehabt und Martin konnte es lösen. Meine Wandtaster sind mit einem virtuellem dummy verknüpft damit Sie mir eine grüne LED liefern wenn der Schaltbefehl bei fhem angekommen ist. Seitdem ich aber eine Update gemacht habe sind die Dinger wieder rot und nicht grün, so als ob der Befehl bei fhem nicht ankommt. Tut er aber die Taster schalten alles wie gewünscht. Ist bei dem letzten Update wieder etwas schief gelaufen?

Ich hoffe es ist kein grosses Problem?

Hier meine Version:

# $Id: fhem.pl 5503 2014-04-10 07:50:19Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 5521 2014-04-14 09:10:28Z martinp876 $
# $Id: 01_FHEMWEB.pm 5475 2014-04-07 16:07:58Z rudolfkoenig $
# $Id: 92_FileLog.pm 5452 2014-04-06 06:24:47Z rudolfkoenig $
# $Id: 00_HMLAN.pm 5449 2014-04-05 14:36:30Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 99_Utils.pm 5488 2014-04-08 11:32:17Z rudolfkoenig $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 5268 2014-03-20 20:46:00Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_notify.pm 5470 2014-04-07 08:32:35Z rudolfkoenig $
# $Id: 98_structure.pm 5050 2014-02-26 08:29:44Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 91_watchdog.pm 5452 2014-04-06 06:24:47Z rudolfkoenig $

Gruss rufus999

[martinp876]

hm - da hat ein device ein ACK ohne Daten haben wollen - sonst wurde er rot.
Viellencht braucht deiner zwingend eines mit Daten

tausche da # der beiden Zeilen 1908 (10_CULHM)

#      push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
      push @ack,$shash,$mNo."8002$dst$src"."00";
nach

      push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
#      push @ack,$shash,$mNo."8002$dst$src"."00";

dann muss ich noch herausfinden wann was besser geeignet ist.

[rufus999]

Hallo martin,

danke für deine schnelle Hilfe (wieder mal  ). Ich werde heute Abend den Code austauschen und testen.

Melde mich dann wieder.

Gruss rufus999

[rufus999]

Hallo martin,

habe die beiden Zeilen wie beschrieben geändert (die andere auskommentiert). Leider ohne Erfolg die Taster gehen alle wieder auf "rot". Gab es sonst noch eine Änderung?

Gruss

rufus999

[martinp876]

nein, sonst fällt mir nichts ein. Kannst du einmal die rohmessages aufzeichnen? Vielleicht ist es ganz etwas anderes

[rufus999]

Hallo martin,

anbei das Log. Hoffentlich ist etwas so sehen.

Gruss

rufus999

[martinp876]

Hi Rufus999
dein 332211 antwortet nicht.
wie set der definiert? Ist es ein virtueller Aktor oder die Zentrale? Ist er mit 1D33BB gepeert?

[rufus999]

Hallo martin,

danke für deine Hilfe (auch am Feiertag!). Also du hast schon eine richtige Spur gehabt. Die ganzen peerings zwischen virtuellem Actor und dem Schalter waren nicht mehr vorhanden  Keine Ahnung warum
Nun ja ich habe sie nun wieder gepeert und noch mal mit geloggt (siehe Anhang). Aber leider kommt immer noch kein ACK, die Dinger gehen wieder auf rot.

Gruss

rufus999

[martinp876]

das ist seltsam. Der 332211 antwortet nicht, der 1D33BB wiederholt nicht. Beides inkorrekt.
8D319F und 217179 unterhalten sich prächtig

[rufus999]

Hallo Martin,

hier mal die Austellung. Ich kann leider nicht mit den "Codes" arbeiten 

332211 = Vact_dev
33221101 = Vact_Taster
33221102 = Vact_dev_Btn2
1D33BB = Schalter_Flur_EG
1D33BB01 = Schalter_Flur_EG_Btn_01
1D33BB02 = Schalter_Flur_EG_Btn_02
8D319F = HMLAN1
217179 = Lampe_1OG_Treppe

Du schreibst, das 332211 nicht antwortet. Aber dass ist doch das DEVICE, müsste die Antwort nicht vom CHANNEL kommen Oder hab ich da was falsch verstanden? Gepeert ist Schalter_Flur_EG_Btn_01 (1D33BB01) mit Vact_Taster (33221101).

Gruss

rufus9999

[martinp876]

Du schreibst, das 332211 nicht antwortet. Aber dass ist doch das DEVICE, müsste die Antwort nicht vom CHANNEL kommen

ja... nun ja....schon ... aber
der 1D33BB  ist mit mindestens einem Kanal des 332211 gepeert. Er sendet an den 332211, nicht an einen Kanal. Trigger gehen immer an das Device. Der verteilt es an die Channels intern.
Der 332211 würde Antworten, für jeden gepeerten Kanal.

Senden kann nur das Device - ein Channel beauftragt den Sendewunsch.

Aus dem 332211 kommt aber keine Antwort raus. Für keinen Kanal.
Gruss Martin

[rufus999]

Hallo martin,

was wäre jetzt noch möglich? Ich bin mit meinem Wissen am Ende.

gruss

rufus999

[martinp876]

Wie gesagt, die letzten Logs waren seltsam. Insbesondere, da der WM55 nicht wiederholt hat. Kann das mit dem Monitoren zu tun gehabt haben? Hat der auch etwas gesendet?

hatten wir schon kontrolliert, dass der 1D33BB01 in der peerlist des 33221101 steht?
Also einmal alle peerings der Devices ansehen

[rufus999]

Hallo martin,

so habe noch mal geforscht. Also ich habe noch mal ein update force gemacht. Leider hier keine Besserung. Dann habe ich geschaut ob der 1D33BB01 in der peerlist des 33221101 steht.
Komischerweise war das nicht der Fall 
Dann habe ich ihn eingetragen und es läuft!
Juhu, endlich wieder alles grün 
Aber wie gesagt ich kann nicht nach voll ziehen warum diese ganzen Einträge nicht mehr vorhanden waren.

Danke und Gruss

rufus999

[martinp876]

Es sind sehr viele einträge- und das mit dem Speichern der Attribute (save/autosave/...) ist sub-optimal.
Ich werde an einer Lösung basteln, die Einträge automatisch zu speichern (schaltbar natürlich). HMInfo autoArchive ist quasi die Basis - muss aber noch getunt werden. Da muss dann auch noch etwas mit autoReadReg passieren.
Dann sollte peerIDs aus den Attributen verschwinden... aber da muss ich noch eine handlebare Lösung finden.
Insbesondere bei virtuellen Devices.

Ein HMInfo checkConfig hätte das nicht ausbalancierte peering beanstanden müssen - hattest du dies probiert? Das ist das Kommando, so etwas zu finden. (und muss noch erweitert werden.... es sollte noch viel mehr finden - muss die pattern noch definieren)

Gruss Martin