Missing Ack seit Update Heute bei HH-CC-TC

Begonnen von Steffen, 10 April 2013, 21:11:18

Vorheriges Thema - Nächstes Thema

Steffen

Guten Abend!

Seit Update heute bekomme ich bei Befehle auf HH-CC-TC immer ein Missing Ack zurück,
ein state der Temp. bekomme ich aber übermittelt!
Activity:
alive
2013-04-10 20:48:25
CommandAccepted
yes
2013-04-10 20:09:01
R-pairCentral
set_0x123ABC
2013-04-10 19:58:10
actuator
0 %
2013-04-10 21:02:15
controlMode
auto
2013-04-03 22:22:20
desired-temp
21.0
2013-04-10 20:09:09
humidity
42
2013-04-10 21:01:55
measured-temp
24.6
2013-04-10 21:01:55
noReceiver
src:1D2612 (A001) 01040000000005
2013-04-10 20:06:36
powerOn
-
2013-04-10 20:05:55
state
T: 24.6 H: 42
2013-04-10 21:01:55
time-request
-
2013-04-10 20:05:54


jetzt mit set:

Activity:
alive
2013-04-10 20:48:25
CommandAccepted
yes
2013-04-10 20:09:01
R-pairCentral
set_0x123ABC
2013-04-10 19:58:10
actuator
0 %
2013-04-10 21:05:10
controlMode
auto
2013-04-03 22:22:20
desired-temp
21.0
2013-04-10 20:09:09
humidity
42
2013-04-10 21:07:31
measured-temp
24.6
2013-04-10 21:07:31
noReceiver
src:1D2612 (A001) 01040000000005
2013-04-10 20:06:36
powerOn
-
2013-04-10 20:05:55
state
MISSING ACK
2013-04-10 21:07:39
time-request
-
2013-04-10 20:05:54




habe schon alle HC&VD Reset und neu gepairt auch mit Fhem aber das selbe Ergebnis!

Wo könnte ich jetzt Ansetzen bei dem Problem??

Mfg Steffen


Carsten

Hallo!

Ich hatte gerade nach Update den selben Effekt.

Habe die vorherigen Versionen von 00_HMLAN.pm und 10_CUL_HM.pm wieder zurückgespielt und jetzt gehts erstmal wieder.

Gruß

Carsten

Steffen

Zitat von: Carsten schrieb am Mi, 10 April 2013 22:56Hallo!

Ich hatte gerade nach Update den selben Effekt.

Habe die vorherigen Versionen von 00_HMLAN.pm und 10_CUL_HM.pm wieder zurückgespielt und jetzt gehts erstmal wieder.

Gruß

Carsten

Ja habe das gleiche gemacht und der gleiche Effekt wie bei dir!

Also müsste es ein Fehler in einer von den beiden .pm sein!?

Mfg Steffen

martinp876

Hi,

werde ich mir ansehen...
Scenario ist demnach einfach:
TC eine temp-aenderung geben...
werde ich probieren

Gruss,
Martin

martinp876

Hi,

die Version von gestern Abend 3063 sollte mit dem TC wieder funktionieren. Ich will am Wochenende aber noch einmal Testen.
falls jemand schon feedback hat...
Gruss
Martin

Carsten

Danke Martin!

Ich kann frühestens morgen testen.

Kannst du vielleicht noch grob umreißen, was die Ursache war, um False-Positives beim Testen auszuschließen?

Gruß

Carsten

Steffen

Hatte gerade das update gezogen über Fhem(hoffe das war Richtig) nachdem ich ja vorher die alte pm zurück gespielt hatte aber leider genau das Gleiche wie beim Letzten mal beim set temp. oder andere befehle "Missing Ack":-(.
Das war mir aber noch aufgefallen ist ich habe mit der neuen version zwar "Missing Ack" aber keine "Disconnect" mehr die bei mir Regelmäßig auftraten!

Rohan

Hi,

gerade Update per Fhem-Webinterface gezogen, shutdown restart war erforderlich, gemacht, einen TC ausgesucht, desired-temp verstellt => Missing ACK, also nochmal, bei der Kontrolle am TC aus Versehen den Modus von Auto auf Cent geändert, kein Missing ACK, Temp.-umstellung ist übernommen worden.

TC zurück auf Auto-Modus und mehrfach die desired-temp verändert, wurde immer durchgeführt nachdem der TC seine Werte an die Zentrale übermittelt hat.

Also von meiner Seite Entwarnung, wobei mir aber auch vorher keine Probleme aufgefallen waren (ich mache so alle 3 - 5 Tage ein Fhem-update), ich aber auch nur ab und zu per Fhem in die per Auto-Modus gesteuerten Temperaturen an den TCs eingreife. Vor dem gerade durchgeführten Update habe ich auch nicht auf evtl. Probleme gecheckt. Insoweit muss meine Schilderung also nicht unbedingt auf andere zutreffen.

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

Ich habe noch ein Problem erkannt. Kommt noch einmal ein Update - sorry.

Werde ihn nacher einstellen, noch ein paar tests...

so aenderungen sind drin.
Grob umrissen: Im HMLAN hat sich einiges getan im Ablauf, sollte aber nicht sicherbar sein (war doch ein bisschen, schade).
Ich hatte eine Berechnung eingebaut um das Timing sicherzustellen, kommandos zu senden. Berechnung ist immer nur ein Behelf, den ich jetzt umgebaut habe. Es gab immer noch Probleme bei langen Abfragen, bursts oder wiederholern.
Das sollte jetzt besser sein, da ich auf eine Rückmeldung des HMLAN warte. Damit kann ich den HMLAN eigentlich nicht mehr überfahren (kam schon einmal vor, wenn man druck gemacht hat...)
Was ich übersehen habe ist, dass der TC (alle wakeup devices , denke ich) immer 100ms Pause nach dem Aufwachen brauchen (sind wohl morgenmuffel).
Die haben sie jetzt bekommen - beim ersten Fix war ein seltsames Problem in Perl, der meine Parameter nicht immer gelesen hat, daher der 2. fix.

Was sich noch geaendert hat ist das Model-abhaengige schalten des HMLAN, das ich der Windows SW abgeschrieben habe. Hier habe ich nicht alle devicetypen ... evtl muss man hier noch nachbessern. Kann man mit traces machen, wenn einer wireshark nutzt und die PC sw logged will.

Also keine aenderung an der Oberflaeche aber doch einiges am Kern des HMLAN.
Was jetzt fehlerfrei geht ist z.B. eine Abfrage eines

Gruss
Martin

LuckyDay

Was jetzt fehlerfrei geht ist z.B. eine Abfrage eines


???
jetzt machst du es spannend
:)

martinp876

ja, muss wohl sein :-)
sorry
eines RC12. HMLAN war nicht in der Lage alle 12channels abzuarbeiten. Da muss man HMLAN noch einmal streicheln....
Das habe ich fuer alle Typen übernommen, da es wohl besser ist.
Martin

Carsten

Hallo,

hab heute mal wieder ein Update durchgeführt und es scheint alles bestens zu funktionieren.

Danke Martin!

Gruß
Carsten