HM-CC-TC Temperatur einstellen

Begonnen von Guest, 20 August 2012, 13:36:06

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 6 7 8 9 10 ... 17
Benutzer-Aktionen

Guest

#105
09 Oktober 2012, 09:15:31
Originally posted by: <email address deleted>

>
> Nur zur Sicherheit - kannst du einmal das setzen eines Parameters loggen?
>>
>
> Kann ich gerne tun, wenn ich wüsste wie das genau geht!
>

Du musst attribut global loglevel auf 5 setzen

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

#106
09 Oktober 2012, 10:09:39
                                                         

Danke
In Anlage die LOG Dateien
Gruss
Billy

Am Dienstag, 9. Oktober 2012 09:15:31 UTC+2 schrieb Martin:
>
>
>  
>>
>> Nur zur Sicherheit - kannst du einmal das setzen eines Parameters loggen?
>>>
>>
>> Kann ich gerne tun, wenn ich wüsste wie das genau geht!
>>
>
> Du musst attribut global loglevel auf 5 setzen
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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*

Guest

#107
09 Oktober 2012, 16:47:55
Originally posted by: <email address deleted>

Hallo Billy,

Danke fuer die Logs.
Auch hier ist am Ablauf kein Unterschied zum neuen zu entdecken.
Es besteht die Vermutung das es etwas mit dem Timing zu tun hat - und dass
das TC einschlaeft bevor FHEM eine Nachricht schickt.
Andererseits ist dein Aufbau nicht wirklich schnell, so 200-300ms.
Aber das kann daran liegen, dass du Rudis neues Warten nach dem Senden
hast. Das sollten so 300ms sein.
Der verdacht ist, dass der TC nach ~ 200ms einschlaeft. Da die 300ms nach
dem Senden kommen kann es bei dir immer noch passen.
Ich werde testen wie ich das Wakeup schneller raus bekommen ... ist mal ein
Ansatz.

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#108
09 Oktober 2012, 20:50:12
Originally posted by: <email address deleted>

Ich denke die Wurzel des Problems gefunden zu haben - es ist wohl das
Timing.
Meinen TC bringe ich jetzt zum Laufen.

Die Loesung wird noch etwas dauern - Performancemessungen sind langwierig.

Wichtig ist den Dump auszuschalten. Also in hmlan

hmProtocolEvents

löschen.
Logs ausschalten sollte auch ein bisschen bringen
Das bringt bei mir 130ms
Lasst mich wissen ob es etwas bringt!

Gruss
Martin



--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

#109
09 Oktober 2012, 22:08:14
                                                         

Hallo Martin,

habe in hmlan --> hmProtocolEvents

"hmId hmProtocolEvents hmKey"; aus dieser Zeile gelöscht!
neue Zeile 46 sieht so aus.

"hmId hmKey";

 War das so gemeint?

Hat bei mir nichts gebracht!

Gruss
Billy

Am Dienstag, 9. Oktober 2012 20:50:12 UTC+2 schrieb Martin:
>
> Ich denke die Wurzel des Problems gefunden zu haben - es ist wohl das
> Timing.
> Meinen TC bringe ich jetzt zum Laufen.
>
> Die Loesung wird noch etwas dauern - Performancemessungen sind langwierig.
>
> Wichtig ist den Dump auszuschalten. Also in hmlan
>
> hmProtocolEvents
>
> löschen.
> Logs ausschalten sollte auch ein bisschen bringen
> Das bringt bei mir 130ms
> Lasst mich wissen ob es etwas bringt!
>
> Gruss
> Martin
>
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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*

LuckyDay

#110
09 Oktober 2012, 22:24:31
                                         

ne du bist falsch,

du gehst in die webansicht, raum unsortet
auf den hmlan oder cul, wie auch immer die heißen bei euch
und löscht nur das atribut --> hmProtocolEvents 1 fals gesetzt, save
nicht vergessen

Hary

On 9 Okt., 22:08, littlebilly wrote:
> Hallo Martin,
>
> habe in hmlan --> hmProtocolEvents
>
> "hmId hmProtocolEvents hmKey"; aus dieser Zeile gelöscht!
> neue Zeile 46 sieht so aus.
>
> "hmId hmKey";
>
>  War das so gemeint?
>
> Hat bei mir nichts gebracht!
>
> Gruss
> Billy
>
> Am Dienstag, 9. Oktober 2012 20:50:12 UTC+2 schrieb Martin:
>
>
>
>
>
>
>
>
>
> > Ich denke die Wurzel des Problems gefunden zu haben - es ist wohl das
> > Timing.
> > Meinen TC bringe ich jetzt zum Laufen.
>
> > Die Loesung wird noch etwas dauern - Performancemessungen sind langwierig.
>
> > Wichtig ist den Dump auszuschalten. Also in hmlan
>
> > hmProtocolEvents
>
> > löschen.
> > Logs ausschalten sollte auch ein bisschen bringen
> > Das bringt bei mir 130ms
> > Lasst mich wissen ob es etwas bringt!
>
> > Gruss
> > Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

#111
09 Oktober 2012, 22:38:05
                                                         

Danke,
man lernt nie aus!
attribut --> hmProtocolEvents war bei mir nicht gesetzt!

Damit kanns auch nichts bringen! Bleibe im Moment bei meiner lösung mit der
alten 10_CUL_HMneu.pm!

Billy

Am Dienstag, 9. Oktober 2012 22:24:32 UTC+2 schrieb fhem-hm-knecht:
>
> ne du bist falsch,
>
> du gehst in die webansicht, raum unsortet
> auf den hmlan oder cul, wie auch immer die heißen bei euch
> und löscht nur das atribut --> hmProtocolEvents 1 fals gesetzt, save
> nicht vergessen
>
> Hary
>
> On 9 Okt., 22:08, littlebilly wrote:
> > Hallo Martin,
> >
> > habe in hmlan --> hmProtocolEvents
> >
> > "hmId hmProtocolEvents hmKey"; aus dieser Zeile gelöscht!
> > neue Zeile 46 sieht so aus.
> >
> > "hmId hmKey";
> >
> >  War das so gemeint?
> >
> > Hat bei mir nichts gebracht!
> >
> > Gruss
> > Billy
> >
> > Am Dienstag, 9. Oktober 2012 20:50:12 UTC+2 schrieb Martin:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Ich denke die Wurzel des Problems gefunden zu haben - es ist wohl das
> > > Timing.
> > > Meinen TC bringe ich jetzt zum Laufen.
> >
> > > Die Loesung wird noch etwas dauern - Performancemessungen sind
> langwierig.
> >
> > > Wichtig ist den Dump auszuschalten. Also in hmlan
> >
> > > hmProtocolEvents
> >
> > > löschen.
> > > Logs ausschalten sollte auch ein bisschen bringen
> > > Das bringt bei mir 130ms
> > > Lasst mich wissen ob es etwas bringt!
> >
> > > Gruss
> > > Martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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*

Guest

#112
10 Oktober 2012, 07:42:10
Originally posted by: <email address deleted>

Hallo Billy,

die aktuelle Abfrage ist leider etwas komplizierter. Um es sicher
auszuschalten musst du
1) im LAN interface "hmProtocolEvents" loeschen
2) im lan-interface attribut "loglevel" loeschen
3)  attribut global "verbose" auf "0"

Sicher aus ist es sobald keinen logs wie
07:56:46 HMLAN HMLAN1 RCV L:0E N:65 F:82 CMD:02 SRC:bd_Stellantrieb
DST:bd_Heizung 0101000032 (ACK_STATUS CHANNEL:01 STATUS:00 UP:0 DOWN:0
LOWBAT:0 RSSI:-50) (,WAKEMEUP,RPTEN)
mehr kommen.

Sag bescheid wenn es nach dem Abschalten immer noch nicht funktioniert.
Dann schalte ein:
global "msecLog" = "1"
inform on
inform timer

und logge.

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#113
10 Oktober 2012, 07:57:31
Originally posted by: <email address deleted>

Danke Martin, dass du Dich da so hinterklemmst.

Bei mir scheint das Abschalten des hmProtocolEvents tatsächlich einen
großen Unterschied zu machen. Scheinbar ein typischer Heisenbug.

Vielleicht ist das auch der Grund, warum es mit den CULs angeblich besser
funktioniert. Da fällt die LAN-Latenz weg.

Am Dienstag, 9. Oktober 2012 20:50:12 UTC+2 schrieb Martin:
>
> Ich denke die Wurzel des Problems gefunden zu haben - es ist wohl das
> Timing.
> Meinen TC bringe ich jetzt zum Laufen.
>
> Die Loesung wird noch etwas dauern - Performancemessungen sind langwierig.
>
> Wichtig ist den Dump auszuschalten. Also in hmlan
>
> hmProtocolEvents
>
> löschen.
> Logs ausschalten sollte auch ein bisschen bringen
> Das bringt bei mir 130ms
> Lasst mich wissen ob es etwas bringt!
>
> Gruss
> Martin
>
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

#114
10 Oktober 2012, 09:44:12
                                                         

Hallo Martin,

danke für deine Mühe!
1-3 habe ich gemacht, keine Verbesserung!
Ergebnis

2012-10-10_09:10:22 WZ_UG desired-temp 25.0
2012-10-10_09:10:24 WZ_UG resend nr 2
2012-10-10_09:10:25 WZ_UG resend nr 3
2012-10-10_09:10:26 WZ_UG MISSING ACK


Ergebnis mit altem 10_CUL_HM.pm

2012-10-10_09:12:19 WZ_UG desired-temp 25.0
2012-10-10_09:14:38 WZ_UG desired-temp-ack: 25.0
2012-10-10_09:14:38 WZ_UG desired-temp: 25.0


Hat etwas länger gedauert, da es
"attr global mseclog 1" sein muss
In Anlage Log habe aber attr global verbose 5 gesetzt!
Hoffe das passt?
Könnte es auch am "resend" liegen?

Billy


Am Mittwoch, 10. Oktober 2012 07:42:10 UTC+2 schrieb Martin:
>
> Hallo Billy,
>
> die aktuelle Abfrage ist leider etwas komplizierter. Um es sicher
> auszuschalten musst du
> 1) im LAN interface "hmProtocolEvents" loeschen
> 2) im lan-interface attribut "loglevel" loeschen
> 3)  attribut global "verbose" auf "0"
>
> Sicher aus ist es sobald keinen logs wie
> 07:56:46 HMLAN HMLAN1 RCV L:0E N:65 F:82 CMD:02 SRC:bd_Stellantrieb
> DST:bd_Heizung 0101000032 (ACK_STATUS CHANNEL:01 STATUS:00 UP:0 DOWN:0
> LOWBAT:0 RSSI:-50) (,WAKEMEUP,RPTEN)
> mehr kommen.
>
> Sag bescheid wenn es nach dem Abschalten immer noch nicht funktioniert.
> Dann schalte ein:
> global "msecLog" = "1"
> inform on
> inform timer
>
> und logge.
>
> Gruss
> Martin
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

2012.10.10 09:33:16.661 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?arg.WZ_UG=desired-temp&dev.WZ_UG=WZ_UG&room=1_WZ_UG&val.WZ_UG=22.0&cmd.WZ_UG=set
2012.10.10 09:33:16.664 5: Cmd: >set WZ_UG desired-temp 22.0<
2012.10.10 09:33:16.666 2: CUL_HM set WZ_UG desired-temp 22.0
2012.10.10 09:33:16.777 5: SW: S49978298,00,00000000,01,49978298,01A1124853CC19E3E7
2012.10.10 09:33:17.078 4: SND L:09 N:01 F:A1 CMD:12 SRC:4853CC DST:WZ_UG  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012.10.10 09:33:17.079 5: Triggering WZ_UG (1 changes)
2012.10.10 09:33:17.080 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:33:17.081 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:33:17.211 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:33:17.212 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:33:17.213 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:33:17.213 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:33:17.213 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:33:17.214 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:33:17.214 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:33:17.223 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=1_WZ_UG
2012.10.10 09:33:17.256 4: /fhem?room=1_WZ_UG / RL: 1392 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:33:17.380 5: HMLAN/RAW: /R49978298,0008,00000000,FF,7FFF,01A1124853CC19E3E7

2012.10.10 09:33:17.380 5: HMLAN_Parse: HMLAN1 R49978298,0008,00000000,FF,7FFF,01A1124853CC19E3E7
2012.10.10 09:33:17.381 5: HMLAN1 dispatch A0901A1124853CC19E3E7NACK
2012.10.10 09:33:19.092 5: SW: S49978BA3,00,00000000,01,49978BA3,01A1124853CC19E3E7
2012.10.10 09:33:19.393 5: Triggering WZ_UG (1 changes)
2012.10.10 09:33:19.394 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:33:19.395 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:33:19.514 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:33:19.515 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:33:19.516 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:33:19.516 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:33:19.516 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:33:19.517 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:33:19.517 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:33:19.695 5: HMLAN/RAW: /R49978BA3,0008,00000000,FF,7FFF,01A1124853CC19E3E7

2012.10.10 09:33:19.696 5: HMLAN_Parse: HMLAN1 R49978BA3,0008,00000000,FF,7FFF,01A1124853CC19E3E7
2012.10.10 09:33:19.697 5: HMLAN1 dispatch A0901A1124853CC19E3E7NACK
2012.10.10 09:33:19.907 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=1_WZ_UG
2012.10.10 09:33:19.940 4: /fhem?room=1_WZ_UG / RL: 1392 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:33:20.029 5: SW: S49978F4D,00,00000000,01,49978F4D,01A1124853CC19E3E7
2012.10.10 09:33:20.330 5: Triggering WZ_UG (1 changes)
2012.10.10 09:33:20.331 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:33:20.332 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:33:20.450 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:33:20.451 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:33:20.452 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:33:20.452 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:33:20.453 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:33:20.453 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:33:20.454 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:33:20.633 5: HMLAN/RAW: /R49978F4D,0008,00000000,FF,7FFF,01A1124853CC19E3E7

2012.10.10 09:33:20.634 5: HMLAN_Parse: HMLAN1 R49978F4D,0008,00000000,FF,7FFF,01A1124853CC19E3E7
2012.10.10 09:33:20.635 5: HMLAN1 dispatch A0901A1124853CC19E3E7NACK
2012.10.10 09:33:21.066 5: SW: S4997935A,00,00000000,01,4997935A,02A0114853CC19E3E702022C
2012.10.10 09:33:21.368 4: SND L:0C N:02 F:A0 CMD:11 SRC:4853CC DST:WZ_UG 02022C (SET CHANNEL:02 VALUE:2C) (,BIDI,RPTEN)
2012.10.10 09:33:21.369 5: Triggering WZ_UG (1 changes)
2012.10.10 09:33:21.370 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:33:21.371 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:33:21.486 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:33:21.487 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:33:21.488 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:33:21.489 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:33:21.489 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:33:21.489 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:33:21.490 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:33:21.492 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=1_WZ_UG
2012.10.10 09:33:21.525 4: /fhem?room=1_WZ_UG / RL: 1399 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:33:21.670 5: HMLAN/RAW: /R4997935A,0008,00000000,FF,7FFF,02A0114853CC19E3E702022C

2012.10.10 09:33:21.671 5: HMLAN_Parse: HMLAN1 R4997935A,0008,00000000,FF,7FFF,02A0114853CC19E3E702022C
2012.10.10 09:33:21.671 5: HMLAN1 dispatch A0C02A0114853CC19E3E702022CNACK
2012.10.10 09:33:26.091 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=all
2012.10.10 09:33:26.156 4: /fhem?room=all / RL: 2187 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:33:26.201 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?cmd=showlog%20weblink_CUL_WS_1%20FileLog_CUL_WS_1%20temp4hum6%20CUL_WS_1-2012.log&pos=
2012.10.10 09:33:26.210 5: plotcommand: get FileLog_CUL_WS_1 CUL_WS_1-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:
2012.10.10 09:33:26.210 5: Cmd: >get FileLog_CUL_WS_1 CUL_WS_1-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:<
2012.10.10 09:33:26.351 4: /fhem?cmd=showlog%20weblink_CUL_WS_1%20FileLog_CUL_WS_1%20temp4hum6%20CUL_WS_1-2012.log&pos= / RL: 2460 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:33:26.353 4: Connection accepted from FHEMWEB:192.168.148.10:49863
2012.10.10 09:33:26.355 4: Connection accepted from FHEMWEB:192.168.148.10:49864
2012.10.10 09:33:26.356 4: HTTP FHEMWEB:192.168.148.10:49863 GET /fhem?cmd=showlog%20wl_0%20FileLog_WZ_UG%20temp4hum6%20WZ_UG-2012.log&pos=
2012.10.10 09:33:26.364 5: plotcommand: get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:
2012.10.10 09:33:26.365 5: Cmd: >get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:<
2012.10.10 09:33:26.847 4: /fhem?cmd=showlog%20wl_0%20FileLog_WZ_UG%20temp4hum6%20WZ_UG-2012.log&pos= / RL: 2954 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:33:26.849 4: HTTP FHEMWEB:192.168.148.10:49864 GET /fhem?cmd=showlog%20wl_1%20FileLog_WZ_UG%20CC_TC%20WZ_UG-2012.log&pos=
2012.10.10 09:33:26.857 5: plotcommand: get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:temperature:0: 4:desired:0: 4:humidity:0: 4:actuator:0:int
2012.10.10 09:33:26.858 5: Cmd: >get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:temperature:0: 4:desired:0: 4:humidity:0: 4:actuator:0:int<
2012.10.10 09:33:27.595 4: /fhem?cmd=showlog%20wl_1%20FileLog_WZ_UG%20CC_TC%20WZ_UG-2012.log&pos= / RL: 3677 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:33:31.014 5: SW: K
2012.10.10 09:33:31.017 5: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245408,173F17,752501,0A596219,0000

2012.10.10 09:33:31.018 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,03C1,IEQ0245408,173F17,752501,0A596219,0000
2012.10.10 09:33:31.018 1: HMLAN setting owner to 4853CC from 752501
2012.10.10 09:33:31.029 5: SW: A4853CC
2012.10.10 09:33:33.315 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log
2012.10.10 09:33:33.471 4: /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log / RL: 32035 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:33:56.048 5: SW: K
2012.10.10 09:33:56.051 5: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A59C3D8,0000

2012.10.10 09:33:56.052 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A59C3D8,0000
2012.10.10 09:34:21.084 5: SW: K
2012.10.10 09:34:21.088 5: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A5A25A8,0000

2012.10.10 09:34:21.088 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A5A25A8,0000
2012.10.10 09:34:21.429 5: HMLAN/RAW: /E19E3E7,0000,0A5A26F6,FF,FFBD,C1867019E3E700000000DC3A

2012.10.10 09:34:21.430 5: HMLAN_Parse: HMLAN1 E19E3E7,0000,0A5A26F6,FF,FFBD,C1867019E3E700000000DC3A
2012.10.10 09:34:21.430 5: HMLAN1 dispatch A0CC1867019E3E700000000DC3A
2012.10.10 09:34:21.439 4: RCV L:0C N:C1 F:86 CMD:70 SRC:WZ_UG DST:broadcast 00DC3A (WeatherEvent TEMP:22 HUM:58) (,WAKEMEUP,BCAST,RPTEN)
2012.10.10 09:34:21.441 5: Triggering WZ_UG (4 changes)
2012.10.10 09:34:21.442 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:34:21.443 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:34:21.933 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:34:21.934 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:34:21.935 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:34:21.935 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:34:21.936 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:34:21.936 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:34:21.937 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:34:22.510 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=1_WZ_UG
2012.10.10 09:34:22.543 4: /fhem?room=1_WZ_UG / RL: 1396 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:34:29.556 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?cmd=logwrapper%20FileLog_WZ_UG%20text%20WZ_UG-2012.log
2012.10.10 09:34:29.715 4: /fhem?cmd=logwrapper%20FileLog_WZ_UG%20text%20WZ_UG-2012.log / RL: 25178 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:34:41.429 5: HMLAN/RAW: /E19E3E7,0000,0A5A7519,FF,FFBC,C1A25819E3E719D70E00A3

2012.10.10 09:34:41.430 5: HMLAN_Parse: HMLAN1 E19E3E7,0000,0A5A7519,FF,FFBC,C1A25819E3E719D70E00A3
2012.10.10 09:34:41.431 5: HMLAN1 dispatch A0BC1A25819E3E719D70E00A3
2012.10.10 09:34:41.439 4: RCV L:0B N:C1 F:A2 CMD:58 SRC:WZ_UG DST:19D70E 00A3 (ClimateEvent CMD:00 ValvePos:163) (,WAKEMEUP,BIDI,RPTEN)
2012.10.10 09:34:41.441 5: Triggering WZ_UG (1 changes)
2012.10.10 09:34:41.441 5: WZ_UG trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.10 09:34:41.442 5: WZ_UG trigger: Checking FileLog_WZ_UG for notify
2012.10.10 09:34:41.553 5: WZ_UG trigger: Checking FileLog_wk_LampeDecke for notify
2012.10.10 09:34:41.554 5: WZ_UG trigger: Checking Logfile for notify
2012.10.10 09:34:41.555 5: WZ_UG trigger: Checking WEB for notify
2012.10.10 09:34:41.556 5: WZ_UG trigger: Checking WEBphone for notify
2012.10.10 09:34:41.556 5: WZ_UG trigger: Checking WEBtablet for notify
2012.10.10 09:34:41.556 5: WZ_UG trigger: Checking autocreate for notify
2012.10.10 09:34:41.557 5: WZ_UG trigger: Checking initialUsbCheck for notify
2012.10.10 09:34:41.561 5: HMLAN/RAW: /E19D70E,0000,0A5A759D,FF,FFC1,C1820219D70E19E3E7010180003D

2012.10.10 09:34:41.562 5: HMLAN_Parse: HMLAN1 E19D70E,0000,0A5A759D,FF,FFC1,C1820219D70E19E3E7010180003D
2012.10.10 09:34:41.562 5: HMLAN1 dispatch A0EC1820219D70E19E3E7010180003D
2012.10.10 09:34:41.572 4: RCV L:0E N:C1 F:82 CMD:02 SRC:19D70E DST:WZ_UG 010180003D (ACK_STATUS CHANNEL:01 STATUS:80 UP:0 DOWN:0 LOWBAT:0 RSSI:-61) (,WAKEMEUP,RPTEN)
2012.10.10 09:34:44.251 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?room=all
2012.10.10 09:34:44.316 4: /fhem?room=all / RL: 2221 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.10.10 09:34:44.379 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?cmd=showlog%20weblink_CUL_WS_1%20FileLog_CUL_WS_1%20temp4hum6%20CUL_WS_1-2012.log&pos=
2012.10.10 09:34:44.388 5: plotcommand: get FileLog_CUL_WS_1 CUL_WS_1-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:
2012.10.10 09:34:44.388 5: Cmd: >get FileLog_CUL_WS_1 CUL_WS_1-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:<
2012.10.10 09:34:44.527 4: /fhem?cmd=showlog%20weblink_CUL_WS_1%20FileLog_CUL_WS_1%20temp4hum6%20CUL_WS_1-2012.log&pos= / RL: 2460 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:34:44.529 4: HTTP FHEMWEB:192.168.148.10:49864 GET /fhem?cmd=showlog%20wl_0%20FileLog_WZ_UG%20temp4hum6%20WZ_UG-2012.log&pos=
2012.10.10 09:34:44.537 5: plotcommand: get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:
2012.10.10 09:34:44.538 5: Cmd: >get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:T\x3a:0: 6:H\x3a:0:<
2012.10.10 09:34:45.019 4: /fhem?cmd=showlog%20wl_0%20FileLog_WZ_UG%20temp4hum6%20WZ_UG-2012.log&pos= / RL: 2957 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:34:45.020 4: HTTP FHEMWEB:192.168.148.10:49863 GET /fhem?cmd=showlog%20wl_1%20FileLog_WZ_UG%20CC_TC%20WZ_UG-2012.log&pos=
2012.10.10 09:34:45.029 5: plotcommand: get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:temperature:0: 4:desired:0: 4:humidity:0: 4:actuator:0:int
2012.10.10 09:34:45.030 5: Cmd: >get FileLog_WZ_UG WZ_UG-2012.log INT 2012-10-10 2012-10-11 4:temperature:0: 4:desired:0: 4:humidity:0: 4:actuator:0:int<
2012.10.10 09:34:45.774 4: /fhem?cmd=showlog%20wl_1%20FileLog_WZ_UG%20CC_TC%20WZ_UG-2012.log&pos= / RL: 3683 / image/svg+xml / Content-Encoding: gzip
 /
2012.10.10 09:34:46.096 5: SW: K
2012.10.10 09:34:46.099 5: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A5A875F,0000

2012.10.10 09:34:46.100 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,03C1,IEQ0245408,173F17,4853CC,0A5A875F,0000
2012.10.10 09:34:46.298 4: HTTP FHEMWEB:192.168.148.10:49859 GET /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log
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*

Guest

#115
10 Oktober 2012, 12:49:01
Originally posted by: <email address deleted>

@Carsten: der Unterschied ist erheblich und mir ist auch klar wieso. Das
dump benutzt eine elegange Methode zum umrechnen der Werte. Elegant im
coding - es benutzt 'eval'. Perl kann das nicht compilieren und muss es zur
Laufzeit interpretieren - das kostet erheblich Zeit - bei meiner 7390 sind
es 130ms.
=> ich werden mein system "benchmarken" (oder jedenfalls die wichtigen
Prozeduren ausmessen und pruefen). Dann sollte eine neu Version kommen. Ein
bisschen Zeit braucht dies aber - hoffentlich an Wochenende...

@Billy: leider nein. wenn in global msecLog gesetzt ist (der Wert ist egal)
sollten die Timerwerte in millisekunden ausgegeben werden - es fehlen die
Nachkommastellen - und die brauchen wir jetzt.

2012-10-09_20:12:58.280 RCV L:1A N:08 F:A0 CMD:10 SRC:Licht DST:1743BF
0301000000326400FF00FF014454642000 (INFO_PARAM_RESPONSE_SEQ OFFSET:01
DATA:000000326400FF00FF014454642000) (,BIDI,RPTEN)

dann mein Fehler:
um die Logs aus HHLAN zu sehen brauchen wir
attr global verbose 5
um dump zu stoppen muss hmLan loglevel > verbose sein also
attr hmLan loglevel 6

Jetzt sollten traces kommen mit  
2012-10-09_20:12:58.280 HMLAN/RAW
oder
2012-10-09_20:12:58.280 HMLAN_Parse

Evtl wartest du aber auf die naechste Version, da sollte es einfacher
gehen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

#116
10 Oktober 2012, 15:02:34
                                                         

Martin
ich werde auf die naechste Version warten.

Zu deiner Info FHEM läuft bei mir unter Debian auf einer ICONNECT NAS.
Falls das Timing Hardware abhaengig ist vielleicht wichtig?

Gruss Billy


> Evtl wartest du aber auf die naechste Version, da sollte es einfacher
> gehen.
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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*

Guest

#117
10 Oktober 2012, 15:26:40
Originally posted by: <email address deleted>

Billy,

es ist extrem HW und SW abhaengig. Eine schnelle HW hat weit weniger
Probleme. Es haengt aber auch von Betriebssystem, den anderen Prozessen auf
dem System und deren Prioritaet ab.
Nachdem ich nichts verzoegere (also keine festen delays) kann ich nur
versuchen so wenig Performance wie moeglich zu brauchen und kritische
Ablaeufe zu optimieren.
Es kann immer passieren, dass ein anderer Process sich reindraengelt und
schon ist FHEM nicht schnell genug. Wenn du es auf einem PC laufen laesst
und nebenbei dein Fotoablum umformatierst,... kann es zu Problemen kommen.

deinen ICONNECT NAS kenne ich nicht - aber ich bin zuversichtlich das alte
Timing wieder zu erreichen  - hoffenltich zu toppen, jetzt wo wir wissen,
wo das Problem liegt.

Ich wuerde hier gerne einen wakeup-retry einbauen. Wenn aus irgendwelchen
Gruenden das Zeitfenster verpasst wurde (meine FB war gerade am
Telefonieren und hat die 200ms gefressen) warten wir eben auf das naechste.
So 2-3 Versuche sollten ok sein. Kann dann bis zu 10 min dauern (3*3
min...).

Mal sehen, wie weit ich komme.

Gruss
Martin


>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#118
10 Oktober 2012, 18:46:41
Originally posted by: <email address deleted>

> Ich wuerde hier gerne einen wakeup-retry einbauen. Wenn aus irgendwelchen
> Gruenden das Zeitfenster verpasst wurde (meine FB war gerade am
> Telefonieren und hat die 200ms gefressen) warten wir eben auf das naechste.
> So 2-3 Versuche sollten ok sein. Kann dann bis zu 10 min dauern (3*3
> min...).
>
>
Das fände ich gut, weil dann ein "Fire and Forget" - Skripting möglich
wäre. Auch wenn es mal länger dauert, ist das immer noch besser, als wenn
Befehle untergehen. Im Moment muss ich für Desired-Temps regelmäßig prüfen,
ob die Desired-Temp des Geräts auch wirklich richtig angekommen ist. Bei
den Templists ist das aufgrund der Asynchronität derzeit gar nicht prüfbar,
weshalb ich die einfach regelmäßig neu schicke in der Hoffnung, dass es
mindestens einmal ankommt.

Ich persönlich fände es allerdings gut, wenn die Retry-Queue geleert würde,
wenn zwischen einem Fehlversuch und dem nächsten Retry neue cmds
dazukommen. Ist mir allerdings auch nicht übermäßig wichtig. Im schlimmsten
Fall werden halt 3 verschiedene Werte nacheinander gesetzt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Dirk

#119
10 Oktober 2012, 20:34:33
                                                   

> Ich wuerde hier gerne einen wakeup-retry einbauen. Wenn aus irgendwelchen
Gruenden das Zeitfenster verpasst wurde
> (meine FB war gerade am Telefonieren und hat die 200ms gefressen) warten
wir eben auf das naechste.
> So 2-3 Versuche sollten ok sein. Kann dann bis zu 10 min dauern (3*3
min...).

 

Das macht die CCU der Homematic übrigens auch so. Die sammelt alle Messages
die nicht angekommen sind und senden die das nächte mal wenn sich das gerät
wieder meldet.


> Ich persönlich fände es allerdings gut, wenn die Retry-Queue geleert
würde, wenn zwischen einem

> Fehlversuch und dem nächsten Retry neue cmds dazukommen. Ist mir
allerdings auch nicht übermäßig

> wichtig. Im schlimmsten Fall werden halt 3 verschiedene Werte nacheinander
gesetzt.

 

Die CCU "merged" die hängengebliebenen Nachrichten irgendwie. Wenn man z.B.
Verknüpfungsinformationen für verschiedene Aktoren nacheinander absetzt, und
keines ankommt, dann schein trotzdem nur eine Nachricht für den Empfänger
gespeichert zu werden. Trotzdem kommen alle Einstellungen an, nicht nur die
Letzte.

Wenn man es schön machen möchte müsste man mehrere nicht empfangene
Nachrichten für ein Device zusammenführen.

 

Kann man schön mit Fernbedienungen testen die Ihre Konfiguration nur auf
Tastendruck empfangen.

 

Gruß

Dirk

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Drucken
Nach oben Seiten 1 ... 6 7 8 9 10 ... 17
Benutzer-Aktionen