Neues Reading dutycycle in 00_MAXLAN gewünscht

[John]

Hallo Matthias,

zur Einbindung des CUBE in den MaxScanner benötige ich ein neues Reading "dutycycle" in 00_MAXLAN.

Der Zeitstempel der letzten Aktualisierung ist nötig, damit ich den tatsächlichen Wert
von dutycycle berechnen kann. (analog zu credit10ms beim CUL)
Der Wert in $hash->{dutycycle} ist ohne Zeitstempel nicht viel wert.
Nur über den Zeitstempel kann man den aktuell zur Verfügung stehenden Wert ermitteln.


Ich würde dich daher bitten dies in 00_MAXLAN einzubringen.

John

[Harald]

Da schließe ich mich an. Mir scheint, dass das jetzt zur Verfügung stehende dutycycle in MAXLAN nicht immer dem tatsächlichen Wert des Cubes folgt. Ich habe schon verschiedentlich festgestellt, dass die Erhöhung, wenn man z.B. die Temperatur eines MAX-Gerätes in der Web-Oberfläche ändert, auch in MAXLAN erfolgt. Geschieht aber einige Zeit nichts, verringert sich der Wert von dutycycle im Cube, aber in MAXLAN bleibt er auf dem alten Betrag. Erst wenn irgend etwas auf MAXLAN einwirkt, wie z.B. ein Neustart von FHEM oder Abspeichern der FHEM.cfg, wird dutycycle in MAXLAN auf den tatsächlich im Cube vorhandenen Wert aktualisiert.

Jürgen I. hat einige Änderungen in MAXLAN und MAX eingefügt, die bewirken, dass das Handling von dutycycle einwandfrei funtioniert. Außerdem gibt es in Cube auch ein Reading dutycycle mit Zeitstempel. Er hat mir die Dateien zu Testzwecken zur Verfügung gestellt und es klappt prima.

Allerdings ist die von John gewünschte Funktion noch nicht implementiert.

Viele Grüße

Harald

[John]

Hallo Matthias,
bis wann kann ich mit einer Antwort rechnen ?

John

[jisleib]

im heutigen Update von Matthias ist der Dutycycle mit drin, leider noch mit dem "%"- Zeichen.

Gruß Jürgen

[John]

Hallo Jürgen,

so ist es derzeit realisiert.

Code Auswählen Erweitern

    my $dutycycle = 0;
    if(@args > 5){
      $dutycycle = hex($args[5]);
      $hash->{dutycycle} = sprintf("%3.0f %%", $dutycycle);
    }
   
   
Dies wäre optimal für den Scanner.

Code Auswählen Erweitern

    my $dutycycle = 0;
    if(@args > 5){
      $dutycycle = hex($args[5]);                          
      readingsSingleUpdate( $hash, 'dutycycle', $dutycycle, 1 );
    }   

In der Max-Thermostat-Struktur ist mit IODev ein Verweis auf MAXLAN nicht jedoch auf den Cube abgebildet.
Daher würde mir das Reading in MAXLAN deutlich besser gefallen.

John

[jisleib]

Hi John,

hab darauf im Scannermodul von dir geantwortet.

Gruß Jürgen

[jisleib]

Hi John,

hier mal ein Versuch dein Modul auf den Dutycycle im Cube umzuswitchen. 

aus
     my $strType=$strIOHash->{TYPE};       # CUL_MAX,MAXLAN type des IO-Devices   
in Zeile 330 wird
    my $strType=$strIOHash->{type};       # CUL_MAX,MAXLAN type des IO-Devices   

und aus
    if ($strType eq "MAXLAN")  # fuer MAXLAN
in Zeile 335 wird
    if ($strType eq "Cube")  # fuer Cube
die Zeile 340
      $strDutyCycle     = InternalVal($strCulName,"dutycycle",0) if ($strDutyCycle eq "?");
ist nicht mehr notwenig, es gibt kein "Internal" für Dutycycle im Cube !

so sollte das dann mit dem Dutycycle klappen.

Ich kann´s leider nicht testen da ich dein Modul nicht verwende, ich benutze Wandthermostate für die Isttemperatur.

Gruß Jürgen

[jisleib]

Hi John,

ich hab deine Abfrage für den CUL ausser acht gelassen.

das in Zeile 355
    else { # fuer CUL
      $strCulName    = $strIOHash->{IODev}{NAME};                   # name des io devices bestimmen
muss natürlich auch angepasst werden
    elseif ($strType eq "??") # fuer CUL, hier eintragen was im CUL bei "type" steht (nicht "TYPE")
      {
      $strCulName    = $strIOHash->{IODev}{NAME};                   # name des io devices bestimmen

so wird dann je nach dem ob ein CUL oder ein Cube verwendet wird dein $numCulCredits richtig berechnet.

Gruß Jürgen

[John]

Hallo Jürgen,
Harald hatte ja das ganze schon mit der zuvor beschriebenen Änderung am laufen (dutycylce als Reading in MAXLAN).

Dein Vorschlag wird nicht funktionieren, da IODev immer auf MAXLAN zeigt und "type" immer HeatingThermostat sein muss.
(wurde zuvor ja ausgefiltert).

Ich sehe keine Möglichkeit um vom der Thermostat-Struktur auf den CUBE schliessen zu können.
Was spricht den dagegen das Reading dutycylce bei MAXLAN zu belassen ? (2 Zeilen und alles funktioniert).
Dann lassen sich die Abhängikeiten sauber auflösen.

John

PS: warum antwortet Matthias unser Mainteiner und Moderator nicht ?

[Harald]

Hallo zusammen,

ihr diskutiert ja schon. Ich habe nämlich auch gerade ein Update gemacht und gesehen, dass Jürgens Lösung 1:1 übernommen wurde.
John hat ja schon ausgeführt, wo's klemmt. Wenn wenigsten MAXLAN Internal als Userreading auslesbar wäre, könnte man sich ein reading in MAXLAN basteln. Hab' ich gerade probiert - geht nicht.

Also werde ich erstmal John's MAXLAN weiter verwenden. Tut mir leid, Jürgen 

Viele Grüße

Harald

[jisleib]

Hallo John,

es spricht nichts gegen ein Reading in MAXLAN, das wäre bestimmt das einfachste für den Scanner und ist abhängig von einer Änderung in einem nicht von dir gepflegten Modules. Sowas versuche ich zu vermeiden wenn ich was anpasse. Manchmal geht es halt nicht anderst.

Wo du ansetzen könntest wäre vor der Ausfilterung, in der foreach-Schleife in Zeile 242, da siehst du den Cube und kannst aus ihm den Wert und die Zeit des Dutycycles lesen bevor du Thermostate ausfilterst(vor dem next if), mehr brauchst du ja nicht. Das in zwei globale Variablen und unten bei MAXLAN ab Zeile 335 die beiden Variablen an deine $strDutyCycle und $strCreditTime Variablen bei erkennen eines MAXLANs übergeben.

Warum Matthias nicht reagiert kann ich nicht sagen, er wird private Dinge haben die vor gehen. Das hier ist ja Hobby.

Gruss Jürgen

[John]

Hallo Jürgen,

das wäre ein Weg, aber immer noch ein ungenauer.
Welchen CUBE soll ich den nehmen wenn es mehr als einer ist ?

Durch die Referenz auf IODev wäre eigentlich alles klar und IODev zeigt eben auf das MAXLAN -Device.



John

[jisleib]

Hallo John,

sowas in die foreach vor dem next if für die Thermostate einfügen

      if ($defs{$shashName}{type} ~~ m/^Cube/) 
     {
            $DC = ReadingsVal($hash,"dutycycle","?");
            $DCTime = ReadingsTimestamp($hash,"dutycycle","");
           }
die beiden Variablen oben bei MaxScanRun deklariert werden. Die kannst du dann weier unten an deine anderen Variablen übergeben.

Gruß Jürgen 

[jisleib]

Es gibt nur einen Cube. Hättest du einen 2ten Cube dann hätte dieser eine eigene IP und wird vermutlich auch unter MAXLAN auftauchen. Jeder Cube hat seinen eigenen Dutycycle und seine eigenen devices, es kann nicht gemischt werden. Ein Cube versorgt theoretisch 140 Geräte in 50 Räumen. mit mehreren Cubes müssten vermutlich noch viel tiefer gehende Änderungen am Scanner gemacht werden, z.B. je ein eigener Scanner pro Cube.

Gruß Jürgen

[Harald]

Hallo Jürgen,

ich sehe gerade diese Zeile

Code Auswählen Erweitern

  if ($defs{$shashName}{type} ~~ m/^Cube/) 

Ich habe gelesen, das diese ~~ nicht mehr verwendet werden sollen. Die werden oder sind schon auf "experimentell" gesetzt und werden in zukünftigen Perl-Versionen nicht mehr unterstützt.

Viele Grüße

Harald

[jisleib]

ups, sorry

das natürlich so nicht verwenden, da gibt´s das mit grep(?) dafür. Wie das genau geht kann ich im moment nicht sagen.

Gruß Jürgen

[Matthias Gehre]

Hallo Jürgen,

so ist es derzeit realisiert.

Code Auswählen Erweitern

    my $dutycycle = 0;
    if(@args > 5){
      $dutycycle = hex($args[5]);
      $hash->{dutycycle} = sprintf("%3.0f %%", $dutycycle);
    }
   
   
Dies wäre optimal für den Scanner.

Code Auswählen Erweitern

    my $dutycycle = 0;
    if(@args > 5){
      $dutycycle = hex($args[5]);                          
      readingsSingleUpdate( $hash, 'dutycycle', $dutycycle, 1 );
    }   

In der Max-Thermostat-Struktur ist mit IODev ein Verweis auf MAXLAN nicht jedoch auf den Cube abgebildet.
Daher würde mir das Reading in MAXLAN deutlich besser gefallen.

John

Ich habs jetzt so eingecheckt, dass dutycycle sowohl in READINGS als auch in $hash->{dutycycle} steht.

[John]

Hallo Matthias,
besten Dank.

John