Heizungssteuerung mit VCLIENT (Version 0.2.11f)

[andies]

Kannst du mal das hier testen? Der Fehler mit dem buffer dürfte nicht mehr vorkommen, weil das inzwischen als nicht mehr integer abgewiesen wird (früher wurde es in das reading geschrieben).

Beim Status ohne Nachkommastelle tue ich mich schwer, weil ich das hardkodieren müsste. Ich mag so was nicht, weil ich nicht absehen kann, was dann passiert. Kannst Du nicht mit einem userreading das abfangen?  Das liest aus dem Status aus und löscht dabei die letzte Nachkommastelle, also (ungetestet)

Code Auswählen Erweitern


attr Vitotronic userradings status {sprintf("%d", $wert_aus_vcontrold)}

oder so?

[phantom]

der Test mit den Werten über 110°C kam gerade vor , es läuft
und auch der  Unknown buffer format  klappt (ist leichter zu provozieren)

das mit den UserReadings probiere ich später mal in Ruhe,  lass alles erstmal so wie in der letztwn Version
ich gehe nun Essen 

aller Besten Dank für deine schnelle Umsetzung, ich hoffe das können noch andere gebrauchen

Gruß Phantom

[phantom]

Hallo andies,

ich möchte die Betriebs-Stati der Vitotronic setzen können, habe damit jedoch noch folgendes Problem:
in der Vclient.cfg steht:
...
# Betriebs-Parameter
getBetriebSparM1         Betriebsart_SparM1
getBetriebSparM2         Betriebsart_SparM2
setBetriebSparM1         Betriebsart_SparM1     0,1
setBetriebSparM2         Betriebsart_SparM2     0,1
...

Beim Setzen von  setBetriebSparM2  1   geht alles klar, aber das Rücksetzen mit  setBetriebSparM2  0  schlägt fehl:
im FHEM-Log mit verbose=5:
2018.12.09 16:28:37 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 0,1

Es wird  0,1  anstatt nur der  0  weitergereicht, was dann fehlschlägt !?
Es wird wohl die  0  nicht akzeptiert,  mit der  1  (=aktiv) klappt es.


Und dann habe ich folgende kleine Modifikation gemacht, damit die Status- und Betriebsartenwerte so angezeigt werden  (0 oder 1), wie sie auch wieder zu setzen sind.
Damit sind alle Integer-Stati und -betriebarten meiner Viessmann  Vitotronic abgedeckt, die sich auch setzen lassen.
(Die "Basisbetriebsart", die mit Strings wie "H+WW" ausgegeben wird, läßt sich bei mir mit vcontrold nicht setzen)

Code Auswählen Erweitern

326c326
< if ($last_cmd =~ /(S|s)tatus/)
---
> if ($last_cmd =~ /status/)
401,406c401
< if ( $last_cmd =~ /(S|s)tatus/ || $last_cmd =~ /BetriebSpar/ || $last_cmd =~ /BetriebParty/ )
< {
< $value = sprintf("%.0f", $results[0]); #rounding to integer, if status value
< } else {
< $value = sprintf("%.1f", $results[0]); #rounding to, for example, 16.6
< }
---
> $value = sprintf("%.1f", $results[0]); #rounding to, for example, 16.6

Gruß Phantom

[phantom]

Ein noch unklares Phänomen gibt es , wenn man im Modul verbose=5 einstellt. Dann kommt es in unregelmäßigen Abständen zu einem FHEM-Restart !?
in Log sieht das etwas so aus:
...
2018.12.09 17:32:11 3: Vitotronic: Received 0 for Status_Pumpe_Wellness
2018.12.09 17:32:11 5: Vitotronic: Requesting getBetriebPartyM2 now
2018.12.09 17:32:15 3: Vitotronic: Received 0 for Betriebsart_PartyM2
2018.12.09 17:32:15 5: Vitotronic: Requesting getTempWWist now
2018.12.09 17:32:16 0: Server shutdown
2018.12.09 17:32:16 1: Shutdown executed
2018.12.09 17:32:21 1: Including fhem.cfg
...

es passiert stets im Anschluß zur Abfrage von Daten durch VCLIENT.pm ??
Habe dazu keine Ursache finden können; jedoch ist alles OK, wenn verbose z.B. auf 2 steht.


P.S.:
Die Betriebsartenstati für Spar und Party sind zwar "hardcodiert" in meiner kleinen Modifikation, aber mir ging es darum diese genauso Setzen wie Abfragen zu können.
Weitere setzbare Stati habe ich in der vcontrold -> vito.xml nicht gefunden.
Es geht um die Betriebsarten, die man ggf. besser auch als setzbaren String (mit 0 oder 1 oder H+WW oder ABSCHALT o.ä.) bearbeiten könnte.

Gruß Phantom

[andies]

Beim Setzen von  setBetriebSparM2  1   geht alles klar, aber das Rücksetzen mit  setBetriebSparM2  0  schlägt fehl

Kannst Du mal nachschauen, wie die dropdown aussieht? So wie bei mir (sinngemäß)? Oder erscheint da 0,1? Und wenn Du die config mit verbose5 einliest, gibt es da Meldungen?

Und dann habe ich folgende kleine Modifikation gemacht, damit die Status- und Betriebsartenwerte so angezeigt werden  (0 oder 1), wie sie auch wieder zu setzen sind.

OK, damit klappt es ja. Ich würde dann hier alle Änderungen dokumentieren, damit Du Deine Hardkodierung drin lassen kannst - sie aber nicht in der Hauptdatei übernehmen. Da kann ich vielleicht einen Link setzen, so dass jemand das auch händisch machen kann.

Ein noch unklares Phänomen gibt es , wenn man im Modul verbose=5 einstellt. Dann kommt es in unregelmäßigen Abständen zu einem FHEM-Restart !?

Uups. Das ist ja ätzend. Und ich werde mich die Woche damit nicht beschäftigen können. Also ich setze nur Log3-Befehle, die schreiben in die Logdatei. Das hört sich aber recht bös an.

Also das ist die Stelle hier

Code Auswählen Erweitern

if ($last_cmd){
#send signal
Log3 $name, 5,  "$name: Requesting ".$last_cmd." now";
$last_cmd .= "\r\n";
#flag because we need to stop sending until next timeout / successful reading, do this BEFORE syswrite
$reading_in_progress = 1;
if ($hash->{CD}){
syswrite($hash->{CD}, $last_cmd);
    } else {
Log3 $name, 1,  "$name: (ERROR) cannot reach hash, aborting syswrite";
    }

    #and set timer for timeout
    RemoveInternalTimer($hash);
    my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
    InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);

Da wird in den Hash geschrieben (und last_cmd existiert ja, weil es in den Log geschrieben wird) und dann wird ein Timer entfernt und ein neuer gesetzt. Also ich würde jetzt Zeile für Zeile auskommentieren und suchen, wo das genau passiert. Nach dem neuen internal timer wird die sub verlassen.

Aaah. Da ist doch zweimal "gettimeofday" drin, ist das nicht falsch? Aber dann hätte es doch nie funktioniert? Ich bin nicht vor Ort...

[phantom]

- das Setzen von z.B. setBetriebSparM2  auf 0 gibt folgendes im Log aus:
2018.12.10 19:07:05 5: Vitotronic: Requesting setBetriebSparM1 0,1 now
2018.12.10 19:07:05 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM1 0,1

das "last_set_command"-Reading bleibt dann bei "command in progress" stehen ...
aber das Dropdown sieht gut aus (s. Anlage)

Da es bei Setzen auf 1 ja klappt, liegt es wohl an der 0 Null

- Die ungeplanten shutdown's verschwinden, wenn man die Timingwerte vergrößert, bei mir so:
evtl. liegt es an den recht vielen Werten, die ich abfrage (ca. 30)
Abfrageintervall von 180 auf 300
attr timout von 1 auf 2
attr internal_update_interval von 0.1 auf 0.2

In deinem Codeschnipsel sehe ich keine gravierende Fehlerursache: Es lag wohl am Timing, was wohl zu agressiv war.
dazu ein Mini.Bug im Logging:

Code Auswählen Erweitern

167c167
< Log3 $name, 5, "$name: Internal_Update_Interval set to $attrVal";
---
> Log3 $name, 5, "$name: Internal_Update_Interval set to $internal_update_interval";



P.S.: wie bekommt man denn deine Doku, die im Modul schon da ist, in FHEM integriert?

[CoolTux]

P.S.: wie bekommt man denn deine Doku, die im Modul schon da ist, in FHEM integriert?

Ein FHEM Update machen dann kommt sie automatisch. Oder auf den FHEM Server

Code Auswählen Erweitern


cd /opt/fhem
/usr/bin/perl contrib/commandref_join

ausführen.

[phantom]

Danke.  mit  contrib/commandref_join.pl  klappts mit der Doku 

und es bringt auch noch ein paar "Optimierungshinweise"     ...
*** EN FHEM/10_IT.pm: negative tagcount for li, line 1532
*** EN FHEM/99_MyUtils.pm: No a-tag with name="MyUtils"
*** EN FHEM/50_TelegramBot.pm: negative tagcount for code, line 3529
*** EN FHEM/73_UpsPico.pm: negative tagcount for td, line 1189
*** EN FHEM/73_UpsPico.pm: negative tagcount for tr, line 1190
*** EN FHEM/89_VCLIENT.pm: Unbalanced ul (1, last line ok: 896)
*** EN FHEM/98_apptime.pm: negative tagcount for div, line 439
*** DE FHEM/10_IT.pm: negative tagcount for li, line 1819
*** DE FHEM/71_PHILIPS_AUDIO.pm: negative tagcount for li, line 2613
*** DE FHEM/21_SONOSPLAYER.pm: negative tagcount for li, line 2011
*** DE FHEM/21_SONOSPLAYER.pm: negative tagcount for ul, line 2050
*** DE FHEM/73_UpsPico.pm: negative tagcount for td, line 1369
*** DE FHEM/73_UpsPico.pm: negative tagcount for tr, line 1370
*** DE VCLIENT: nonempty line after =begin html ignored

[andies]

Das mit den timings war in der Tat ein Fehler, da wurde zweimal der Tag addiert. Dazu muss wirklich, wie oben befürchtet, hier was geändert werden

Code Auswählen Erweitern

my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
    InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);

das zweite "gettimeofday()+" muss heraus. Das sollte also das Problem lösen. Bei dem 0,1 stehe ich auf dem Schlauch. Lies doch nochmal den configfile ein und zeige mir bei verbose 5, was dann im Logfile steht.

[phantom]

ich glaube wir sind da an 2 verschiedenen Dingen dran ...

a) Das mit den Timings klappt doch mit meinen o.g. Parametern Im Gegenteil, nehme ich das 2. "gettimeofday()+" raus, wird gar nichts mehr eingelesen:

Code Auswählen Erweitern

2018.12.11 18:27:35 5: Vitotronic: vcontrold opened
2018.12.11 18:27:35 5: Vitotronic: Requesting getTempWWist now
2018.12.11 18:27:35 3: Vitotronic: Received 45.4 for TempIst_Warmwasser
2018.12.11 18:27:35 5: Vitotronic: Requesting getTempA now
2018.12.11 18:27:37 5: Timeout: Was not able to receive a signal from homeserver:3002. Deleting command queue.
2018.12.11 18:27:37 5: Vitotronic: Closing vcontrold connection
2018.12.11 18:31:01 5: Vitotronic: execute get command Vitotronic ?
Das habe ich zurückgeändert auf den Ursprung.


b) Das 0,1_problem ist hingegen noch offen.
    Im FHEM-Log steht bei Einlesen der Vclient.cfg folgendes:

Code Auswählen Erweitern

2018.12.11 18:33:37 5: Vitotronic: opening command file FHEM/Vclient.cfg
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempA Aussentemperatur
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempKist TempIst_Kessel
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempWWist TempIst_Warmwasser
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempVListM2 TempIst_VorlaufM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRListM2 TempIst_RuecklaufM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getBrennerStarts Brennerstarts
2018.12.11 18:33:37 5: Vitotronic: reading command line getBrennerStarts BrennerstartsBisGestern daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusM1 Status_Pumpe_Haus manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusM2 Status_Pumpe_Wellness manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusSp Status_Pumpe_Warmwasser manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusZirku Status_Pumpe_Zirku manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumNorSollM1 TempSoll_Haus daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumRedSollM1 TempSoll_Haus_Reduz daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumNorSollM2 TempSoll_Wellness daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumRedSollM2 TempSoll_Wellness_Reduz daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempWWsoll TempSoll_Warmwasser daily
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumNorSollM1 TempSoll_Haus 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumRedSollM1 TempSoll_Haus_Reduz 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumNorSollM2 TempSoll_Welllness 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumRedSollM2 TempSoll_Wellness_Reduz 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempWWsoll TempSoll_Warmwasser 50,60,15
2018.12.11 18:33:37 5: Vitotronic: reading command line getSystemTime Systemzeit_Heizung daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebArtM1 Betriebsart_Haus daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebArtM2 Betriebsart_Wellness daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebSparM1 Betriebsart_SparM1
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebSparM2 Betriebsart_SparM2
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebPartyM1 Betriebsart_PartyM1 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebPartyM2 Betriebsart_PartyM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebSparM1 Betriebsart_SparM1 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebSparM2 Betriebsart_SparM2 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebPartyM1 Betriebsart_PartyM1 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebPartyM2 Betriebsart_PartyM2 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWMo Warmwasser_1Montag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWDi Warmwasser_2Dienstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWMi Warmwasser_3Mittwoch manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWDo Warmwasser_4Donnerstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWFr Warmwasser_5Freitag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWSa Warmwasser_6Samstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWSo Warmwasser_7Sonntag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWMo WW_1Mo_spaet 07:40-10:10|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWDi WW_2Di_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWMi WW_3Mi_spaet 06:10-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWDo WW_4Do_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWFr WW_5Fr_spaet 08:10-10:00|12:00-12:30|15:30-16:00|19:00-20:40
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWSa WW_6Sa_spaet 08:00-11:00|14:00-15:00|17:00-20:30|
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWSo WW_7So_spaet 08:00-13:10|16:00-17:00|18:50-20:30|
2018.12.11 18:33:37 5: Vitotronic: command file 'FHEM/Vclient.cfg' closed (211 lines read)

Dort werden die Zeilen mit z.B. Betriebsart_SparM2   0,1 korrekt eingelesen lt. Log.  (es sind TAB's zur Übersicht in der VClient.cfg, OK?).
Und die Dropdown-Auswahl sieht auch OK aus.

Beim Setzen von  0  wird lt. Log   statt  0   ein  0,1  abgesetzt:

Code Auswählen Erweitern

2018.12.11 18:41:47 5: Vitotronic: Requesting setBetriebSparM1 0,1 now
2018.12.11 18:41:47 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM1 0,1

2018.12.11 18:41:47 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command
2018.12.11 18:41:47 5: Vitotronic: Closing vcontrold connection

Beim Setzen von  1  klappt es ja:

Code Auswählen Erweitern

2018.12.11 18:43:07 5: Vitotronic: vcontrold opened
2018.12.11 18:43:07 5: Vitotronic: Requesting setBetriebSparM2 1 now
2018.12.11 18:43:09 3: Vitotronic: Received OK for last_set_command
2018.12.11 18:43:09 5: Vitotronic: Closing vcontrold connection


Es liegt an der  0  , denn wenn man zum testen mal  setBetriebSparM2         Betriebsart_SparM2     2,1   ins config schreibt,
wird die 2 auch korrekt genommen (nur 'halt nicht vom vcontrold akzeptiert):

Code Auswählen Erweitern

2018.12.11 18:45:13 5: Vitotronic: Requesting setBetriebSparM2 2 now
2018.12.11 18:45:13 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 2

2018.12.11 18:45:13 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command

Wenn man in der config 1,0 umgekerht schreibt (setBetriebSparM2         Betriebsart_SparM2     1,0)  springt das Dropdown sofort von 1 auf 0 um, obwohl 1 vorne steht.
Und leider klappt das Auswählen der 0 dann auch nicht:

Code Auswählen Erweitern

2018.12.11 18:49:35 5: Vitotronic: vcontrold opened
2018.12.11 18:49:35 5: Vitotronic: Requesting setBetriebSparM2 1,0 now
2018.12.11 18:49:35 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 1,0

2018.12.11 18:49:35 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command
2018.12.11 18:49:36 5: Vitotronic: Closing vcontrold connection

Ich hoffe diese Tests helfen, da ich das 0,1 Problem im Code auch nicht erkennen kann. Muß heute leider weg.
Gruß Phantom

[andies]

Ja, das sind zwei verschiedene Dinge.

Zum ersten, mit dem timeout. Bisher steht da

Code Auswählen Erweitern

my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);
und so, wie das steht, würde man einen Zeitpunkt $this_timeout definieren, der von diesem Moment an genau so lange weg ist wie der Wert (in Sekunden), der im Attribut timeout steht. Gibt es das nicht, nimmt er eine Sekunde.

In  der nächsten Zeile aber werden dann zu diesem Zeitpunkt nochmal so viel Sekunden hinzugezählt, wie seit 1.1.70 vergangen sind - das kann nicht sein und das würde in meinen Augen die Abstürze erklären. (Danach wird der Timer gesetzt und VCLIENT dann nach $this_timeout aufgerufen.)

Zum zweiten Problem, da denke ich laut: Intern läuft das so, dass die Befehle beim Einlesen der config-Datei in ein array (hash) geschrieben werden. Insgesamt sind das zwei hash:

Code Auswählen Erweitern


my %set_hash; #set commands with values that should appear in FHEM-dropdown
my %dropdown_hash; #contains the values for every set command

Wenn die falsch eingelesen werden, war's das - das wird dann falsch ausgeführt. Eingelesen wird in der sub VCLIENT_Read_Config($). Die set-Kommandos werden ab dieser Zeile erkannt

Code Auswählen Erweitern

} elsif (substr($vcontrold_command, 0, 3) eq "set") {

Die 0,1 stehen nun in

Code Auswählen Erweitern

my $options = $cfgarray[2];

Da das kein timer ist, bleibt my $msg in der nächsten Zeile leer. Und damit wird

Code Auswählen Erweitern

$set_hash{$FHEM_set_command} = [$vcontrold_command, $options] ;
abgearbeitet. Also die Optionen werden neben dem Kommando $vcontrold_command als Optionen in den Hash geschrieben. Ich kapier's nicht.

Ändert sich etwas, wenn Du statt 0,1 einfach mal 1,0 schreibst?

[andies]

hast du timeout verändert? das waren bei dir nämlich nur zwei sekunden.


Gesendet von iPad mit Tapatalk Pro

[andies]

Das sind jetzt alles so Gedanken vor dem Einschlafen. Vielleicht nimmt er 0,1 als boolsche Variable und nicht als String an. Das könnte man auffangen, indem man daraus eindeutig einen String macht. Vielleicht so

Code Auswählen Erweitern

my $options = $cfgarray[2]." ";

Wenn das keine Nebenwirkungen hat...

[phantom]

Hi andies,

zum 0,1 Problem steht in meinem letzen Posting, was passiert wenn man 1,0 in die Vclient.cfg schreibt und (testhalber) auch mal 2,1.
Es klappt bei allen Zahlen, außer bei der Null  0.  (siehe Fehler beim ausfuehren von setBetriebSparM2 1,0 in obigen Beispiel)
Nur der 0-Wert führt dazu, daß der ganze String  (1,0 oder 0,1)  verarbeitet wird und nicht nur der gewünschte Teil.
Logs dazu s.o.

die Timing-Unklarheit muß ich heute Abend noch mal in Ruhe testen und ja, ich habe folgende Timings eingestellt mit denen es läuft:
Abfrageintervall in der Modul DEF:   300
attr timeout :   2
attr internal_update_interval :   0.2

[andies]

OK, dann ändere mal in Zeile 547

Code Auswählen Erweitern

my $options = $cfgarray[2]." ";

und schaue mal, ob das dann geht. Wegen des Timers: Mach mal timout 5, nicht zwei. Ist das Problem dann noch da?