Fehler in 10_CUL_HM.pm betrifft HM Thermostate

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

ich habe gerade den fhem Server neu gestartet und dabei ist mir aufgefallen:

# Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line 533.
Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line 533.
Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line 533.

Die Fehler treten auf wenn ich am TC manuell das Wochenprogramm ändere.

Ein zweiter kleinerer Fehler ist, dass die Temperatur Werte in der falschen
Reihenfolge übertragen werden, wenn ich das über perl mache. Der Aufruf
lautet wie folgt:

set wz_Thermostat tempListMon 04:00 20.0 06:00 22.0 12:00 20.0 16:00 20.0
18:00 23.0 21:00 23.0 24:00 22.0

Hier sollte " 04:00 20.0 06:00" bedeuten, dasszwischen 4 und 6 uhr soll es
20 Grad haben. Leider ist das nicht so, sondern... "04:00 20.0 06:00 22.0"
--> zwischen 4 und 6 soll es 22 Grad haben. Also die Soll Temperatur ist um
eins verschoben.

Gruß,
Christian

PS
Ich schau mal ob ich das beheben kann...



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

[Guest]

Originally posted by: <email address deleted>

Also zumindest beim 2. Problem denke ich das Problem liegt hier in der For
Next Schleife in Zeile 2115 der 10_CUL_HM.pm:

for(my $idx = 2; $idx < @a; $idx += 2) {

Allerdings kann ich nicht testen weil die Daten bei mir ja nicht übertragen
werden nachdem ich meinen TC in den Lernmodus versetze... (CUNO Problem, da
auch getConfig nicht geht... Timeout).

Ich hoffe das hilft weiter!

Beim ersten Problem kann ich nicht helfen. Ich sehe nur dass
"0+$ptr->{HOUR} == 24" nicht geht (Zeile 533) weil $ptr->{HOUR}=="". Ich
weiß aber nicht warum.

Gruß
Christian

Am Sonntag, 18. November 2012 02:53:37 UTC+1 schrieb kohrti:
>
> Hallo Martin,
>
> ich habe gerade den fhem Server neu gestartet und dabei ist mir
> aufgefallen:
>
> # Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line
> 533.
> Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line 533.
> Argument "" isn't numeric in addition (+) at ./FHEM/10_CUL_HM.pm line 533.
>
> Die Fehler treten auf wenn ich am TC manuell das Wochenprogramm ändere.
>
> Ein zweiter kleinerer Fehler ist, dass die Temperatur Werte in der
> falschen Reihenfolge übertragen werden, wenn ich das über perl mache. Der
> Aufruf lautet wie folgt:
>
> set wz_Thermostat tempListMon 04:00 20.0 06:00 22.0 12:00 20.0 16:00 20.0
> 18:00 23.0 21:00 23.0 24:00 22.0
>
> Hier sollte " 04:00 20.0 06:00" bedeuten, dasszwischen 4 und 6 uhr soll es
> 20 Grad haben. Leider ist das nicht so, sondern... "04:00 20.0 06:00 22.0"
> --> zwischen 4 und 6 soll es 22 Grad haben. Also die Soll Temperatur ist um
> eins verschoben.
>
> Gruß,
> Christian
>
> PS
> Ich schau mal ob ich das beheben kann...
>
>
>
>

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

[Guest]

Originally posted by: <email address deleted>

>
> Beim ersten Problem kann ich nicht helfen. Ich sehe nur dass
> "0+$ptr->{HOUR} == 24" nicht geht (Zeile 533) weil $ptr->{HOUR}=="". Ich
> weiß aber nicht warum.
>
>
> Ok, vielleicht doch...

Ich habe nun folgendes geändert:

if(defined ($ptr->{HOUR}) && $ptr->{HOUR} ne "" && 0+$ptr->{HOUR} == 24) {
     $twentyfour = 1;  # next value uninteresting, only first counts.
}
 
Die Fehlermeldungen sind weg, aber so ganz blick ich nicht durch. Mein
Verständnis soweit:
Die beiden Schleifen gehen die Wochentage durch und holen sich mit "my $ptr
= $shash->{TEMPLIST}{$wd}{$idx};" die Temp Liste des Tages. Das verstehe
ich nicht: "if(defined ($ptr->{TEMP}) && $ptr->{TEMP} ne "") {"... sollte
doch eigentlich immer definiert sein. Was ist $ptr->{TEMP} eigentlich? Es
kommen in der Liste immer alternierend Uhrzeit/Temp. So, dann kommt die
Sache mit den "24" - klar. Was ich nicht verstehe: $ptr->{HOUR} muß doch
eigentlich immer eine Zahl sein?! Ich rätsel gerade wann es keine Zahl sein
kann und vermute mal es hängt mit $ptr->{TEMP} zusammen. Ist das evtl.
manchmal nicht definiert?

Jo, jetzt beißt es aus....

Anyways, gute Nacht.

Christian



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

[Guest]

Originally posted by: <email address deleted>

Ich vergaß...

Meine Dateiversion ist:
# $Id: 10_CUL_HM.pm 2110 2012-11-11 19:09:21Z martinp876 $

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

[Guest]

Originally posted by: <email address deleted>

Christian,

schaue ich mir einmal an. Danke fuer den Versionshinweis - hilft mir viel.
Du kannst die Daten mit
set tc getConfig
auslesen. Die herkoemmliche webdarstellung wird hier nicht upgedated (kommt
vielleicht noch...).Aber danach kannst du die Werte mit
get tc_climate reg all
oder
get tc reg all
ansehen.
Kannst du mir den Wert schicken?
Evtl probierst du es mit Version 2131- die hat auch wieder das alte 'param'
handling

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

 

ich habe kein update gemacht. Log Einstellungen sind ,,attr global verbose 3"
und ,,attr CUNO loglevel 0".

 

Ich erhalte folgende Infos (get tc_climate reg all):

 

az_Thermostat type:thermostat -

List:0 Peer:broadcast            intKeyVisib:          value:0bool

List:0 Peer:broadcast            pairCentral:            value:15798836dec

 

Für getConfig erhalte ich im fhem log:

2012.11.18 12:17:19.988 3: CUL_HM set az_Thermostat getConfig rxt:12

 

Und im Thermostat Log:

2012-11-18_12:17:30 az_Thermostat Activity:unknown

2012-11-18_12:17:32 az_Thermostat RESPONSE TIMEOUT

2012-11-18_12:17:34 az_Thermostat RESPONSE TIMEOUT

 

Ein Setzen von Tagestemperaturvorgaben geht nicht mehr. Früher, vor ca. 1-2
Wochen konnte ich noch Temperaturwerte setzen.

 

Leider kann ich jetzt kein Update machen, da ich gleich weg muss. Ich hoffe
ich komme heute noch dazu und dann werde ich die Logs nochmal machen. Wird
dann auch mal mit den Log Einstellungen spielen.

 

Gruß und Danke!

Christian

 

PS

Ich habe eine CUNO mit FB7390 ... nur für diejenigen die erst jetzt dazu
kommen...

 

Von: fhem-users@googlegroups.com [mailto:fhem-users@googlegroups.com (fhem-users@googlegroups.com)] Im
Auftrag von Martin
Gesendet: Sonntag, 18. November 2012 11:48
An: fhem-users@googlegroups.com
Betreff: [FHEM] Re: Fehler in 10_CUL_HM.pm betrifft HM Thermostate

 

Christian,

schaue ich mir einmal an. Danke fuer den Versionshinweis - hilft mir viel.
Du kannst die Daten mit
set tc getConfig
auslesen. Die herkoemmliche webdarstellung wird hier nicht upgedated (kommt
vielleicht noch...).Aber danach kannst du die Werte mit
get tc_climate reg all
oder
get tc reg all
ansehen.
Kannst du mir den Wert schicken?
Evtl probierst du es mit Version 2131- die hat auch wieder das alte 'param'
handling

Gruss
Martin

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

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

[Guest]

Originally posted by: <email address deleted>

Hier noch vom Climate channel:

az_Thermostat_Climate type:thermostat -
List:5 Peer:broadcast   DecalDay:   value:0d
List:5 Peer:broadcast   DecalHr:   value:11h
List:5 Peer:broadcast   DecalMin:   value:0min
List:5 Peer:broadcast   DispTempHum:   value:1bool
List:5 Peer:broadcast   DispTempInfo:   value:0bool
List:5 Peer:broadcast   DispTempUnit:   value:0bool
List:5 Peer:broadcast   MdTempReg:   value:1
List:5 Peer:broadcast   MdTempValve:   value:0
List:5 Peer:broadcast   TempComfort:   value:21C
List:5 Peer:broadcast   TempLower:   value:17C
List:5 Peer:broadcast   TempParty:   value:20C
reglist incomplete


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

[Guest]

Originally posted by: <email address deleted>

Hallo Christian,

- bei den Registern fehlten die interessanten.
- du betreibst also TC mit HMLAN und andere mit CUNO? Die mit CUNO haben
Probleme?
- bei CUL werde ich noch einmal nachbessern - die wertezeit ist nicht
selektiv genug. Muss es aber erst mit meiner CUL ausprobieren. Ich hoffe,
dass es das die Stabilitaet weiter erhoeht - ist aber  noch nicht fertig

zum 2. Problem
das ist ein rechtes gemache, die Register zu sortieren. Und evtl. sind die
Listen noch nicht 'gefuellt'...
Das ist noch alles 'orginal' - ich werde es an die "register" angleichen -
eine internen 'uebung' und danach sollte es funktionieren
Auch das dauert noch etwas.

Beim aufloesen der Climate Tempereturen hatte ich einen Bug - der ist in
der Naechsten Version draussen.

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

du bist ja wirklich überall aktiv...

s.u.

Am Sonntag, 18. November 2012 18:12:08 UTC+1 schrieb Martin:
>
>
> Hallo Christian,
>
> - bei den Registern fehlten die interessanten.
>
--> Hm, soll ich da noch was machen?
 

> - du betreibst also TC mit HMLAN und andere mit CUNO? Die mit CUNO haben
> Probleme?
>
--> Ich habe ausschlielich eine CUNO. HMLAN habe ich nicht.
 

> - bei CUL werde ich noch einmal nachbessern - die wertezeit ist nicht
> selektiv genug. Muss es aber erst mit meiner CUL ausprobieren. Ich hoffe,
> dass es das die Stabilitaet weiter erhoeht - ist aber  noch nicht fertig
>
> --> Cool, danke!!!!!
 

> zum 2. Problem
> das ist ein rechtes gemache, die Register zu sortieren. Und evtl. sind die
> Listen noch nicht 'gefuellt'...
>
--> Ja das glaube ich dir.....
 

> Das ist noch alles 'orginal' - ich werde es an die "register" angleichen -
> eine internen 'uebung' und danach sollte es funktionieren
> Auch das dauert noch etwas.
>
--> OK!
 

> Beim aufloesen der Climate Tempereturen hatte ich einen Bug - der ist in
> der Naechsten Version draussen.
>
--> Mehr als freuen kann ich mich nicht... ausser vielleicht über deie
ohren grinsen... DANKE!
 

> Gruss
> Martin
>

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

[Guest]

Originally posted by: <email address deleted>

Ähm, noch ein blöde Frage...

Am Sonntag, 18. November 2012 18:12:08 UTC+1 schrieb Martin:
>
>
> - du betreibst also TC mit HMLAN und andere mit CUNO? Die mit CUNO haben
> Probleme?
>
 
--> Die Datei 10_CUL_HM.pm ist doch auch für die CUNO oder nicht? Es gibt
da ja auch die 00_CUL.pm. Nicht dass ich jetzt in der falschen Datei
geschaut habe.
Bisher dachte ich je höher die Zahl "00_" je abstrakter. Wie ist denn da
die Namenskonvention?

Grüße,
Christian

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

[Guest]

Originally posted by: <email address deleted>

>
>> - du betreibst also TC mit HMLAN und andere mit CUNO? Die mit CUNO haben
>> Probleme?
>>
>  
> --> Die Datei 10_CUL_HM.pm ist doch auch für die CUNO oder nicht? Es gibt
> da ja auch die 00_CUL.pm. Nicht dass ich jetzt in der falschen Datei
> geschaut habe.
> Bisher dachte ich je höher die Zahl "00_" je abstrakter. Wie ist denn da
> die Namenskonvention?
>

Das ist korrekt.
00_CUL ist der IO-treiber fuer CUL und CUNO.
00_HMLAN ist der IO-treiber fuer HMLan

Diese Module starten und betreiben das Interface zur IO-HW. Beiden haben
ihre Eigenheiten.
HMLAN betreibt ein eigenleben: sendet acks, will je device getriggert
werden und braucht ein keep-alive
CUL kann mehrere devicefamilien und muss entsprechend konfuguriert werden

CUL_HM ist eine Ebene hoeher. Es bildet die HM-devices nach und benutzt das
jeweiligen IO also interface.

Wenn das IO configuriert ist (CUL oder HMLAN) bietet es CUL_HM ein
einheitliches Interface so dass CUL_HM nicht wissen muss, welches IO-device
benutzt wird.

In beiden, CUL und HMLAN habe ich ein paar Anpassungen vorgenommen - und
immer etwas dazugelernt. HMLAN hat im Augenblick die effektievere
implementierung, ich werden CUL aber nachziehen.
Dann erhoffe ich mir einen Stand, dass einzelne Devices korrekt behandelt
werden und fehlerfrei bearbeitet werden koennen.
Dies sollte in den meisten Faellen reichen.
Was nicht effektiv unterstuetzt wird ist, viele devices gleichzeitig UND
fehlerfrei zu unterstuetzen. Das liegt daran, das Latenzzeiten fuer Devices
eingehalten werden muessen die wiederum anderen Devices - bei
Gleichzeitigkeit - eine zu hohe reaktionszeit aufdruecken.
Wenn ich einmal lust habe, werde ich versuchen die queues zu sortieren.

Fuer dich heisst dies
- du musst 00_CUL UND 10_CUL_HM updaten. Sonst geht es nicht
- die beschriebenen Probleme sollten dich nicht beunruhigen. Muss man aber
im Auge behalten bei Versuchen, viele Devices gleichzeitg Abzufragen oder
bei grossen Installationen.
Gruss
Martin

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