Schickst du mir mal deine Mailadresse, dann leite ich dir das excel-sheet weiter?
Welche Zeile 10 von was?
richimaint
die zeile in der exel-tabelle
Das ist Heizen ohne NanoeX?
richimaint
Sorry, verrutscht. Ich meinte Zeile 11
Das kommt raus:
20.10.2023, 07:02:56 | SetOperateMode | add nanoeStandAlone mode
20.10.2023, 07:02:56 | ControlDevice | SendDataToParent(Array
(
[DataID] => {34871A78-6B14-6BD4-3BE2-192BCB0B150D}
[CallerID] => 40390
[Function] => ControlDevice
[Guid] => CS-Z35ZKEW+E064803805
[Parameters] => {"operationMode":4,"nanoe":2}
)
)
richimaint
Ich habe die 1.14 in dem Modulstore/beta veröffentlicht. Hier gibt es nun einen zusätzlichen Schalter, der die Steuerung „Lüften“ unabhängig von „nanoe“ macht - also wird dann bei Modus „Lüften“ nanoe nicht automatisch aktiviert und man kann nanoe separat abschalten (der Ausgangspunkt dieser Diskussion)
bei den Suchen im Internet habe ich was dazu gefunden. nanoe-G ist wohl das ältere und vergleichbar mit einem HEPA-Filter, nanoe-X sorg dafür, das „im Wasser enthaltene Hydroxylradikale“ aktiviert und zerstäubt werden
1 „Gefällt mir“
Ich habe nun den neuen Stand ausprobiert und es sieht soweit gut aus.
Eine Frage hätte ich noch: das Umschalten zwischen den Betriebsarten dauert ausgesprochen lange.
Beispiel: in Symcon steht der Betriebsmodus auf „Heizen“. Ich schalte um auf „Kühlen“. Der Schalter springt aber sofort zurück auf „Heizen“ und bleibt da auch für 20-30 Sekunden. Erst dann zeigt Symcon den neuen Modus an.
In der App wird der neue Status jedoch bereits nach ca.3-5 Sekunden angezeigt.
Hast du da eine Idee, woran das liegt. Müsste ich das Aktivierungsintervall von jetzt 30 auf vielleicht 5 heruntersetzen?
Hmm.
Ich setze im RequestAction schon die Variable auf den neuen Wert, mache aber nach 1000 ms eine UpdateStatus-Abfrage von der Panasonic-Cloud (Zeile 669 in …/PanasonicCloudDevice/module.php). Das mache ich eigentlich um den aktuellen Status zu bekommen - das Setzen der Variable allein sorgt ja nicht für eine korrekte Abbildung des Stands im Klimagerät/in der Panasonic-Cloud. Bis zum normalen Intervall warte ich eigentlich nicht ganz so gerne, weil das ja ziemlich dauern kann (je nachdem wie der Benutzer es so eingestellt hat).
public function RequestAction($ident, $value)
{
if ($this->LocalRequestAction($ident, $value)) {
return;
}
if ($this->CommonRequestAction($ident, $value)) {
return;
}
if ($this->GetStatus() == IS_INACTIVE) {
$this->SendDebug(__FUNCTION__, $this->GetStatusText() . ' => skip', 0);
return;
}
$this->SendDebug(__FUNCTION__, 'ident=' . $ident . ', value=' . $value, 0);
$r = false;
switch ($ident) {
case 'Operate':
$r = $this->SetOperate((bool) $value);
break;
...
default:
$this->SendDebug(__FUNCTION__, 'invalid ident ' . $ident, 0);
break;
}
if ($r) {
$this->SetValue($ident, $value);
$this->MaintainTimer('UpdateStatus', 1000);
}
}
Und dann kommen die Update wieder im normalen Intervall.
Ich befürchte, das diese Abfrage das Problem ist, das die 1s zu kurz ist. Ich könnte den Wert erhöhen? Was meinst Du, auf welchen Wert? Zugang ist halt auch nicht so doll, weil längere Zeit Unklarheit herrscht, wie die Klima nun so drauf ist.
Dein Verfahren finde ich sehr gut.
Das sieht bei mir danach aus. Ich habe mal das Aktualisierungsintervall auf 0 gestellt und ein wenig mit den Zeiten gespielt.
Mein Ergebnis: zwei Sekunden waren für alle Operationen noch zu knapp. Bei drei Sekunden läuft es gut, bis auf das Ein-/Ausschalten. Hier sind vier Sekunden notwendig.
Bei mir also optimal:
$r = false;
$interval = 3000;
switch ($ident) {
case 'Operate':
$r = $this->SetOperate((bool) $value);
$interval = 4000; // needs e little more time
break;
case 'OperationMode':
$r = $this->SetOperateMode((int) $value);
break;
case 'EcoMode':
$r = $this->SetEcoMode((int) $value);
break;
case 'TargetTemperature':
$r = $this->SetTargetTemperature((float) $value);
break;
case 'FanSpeed':
$r = $this->SetFanSpeed((int) $value);
break;
case 'AirflowVertical':
$r = $this->SetAirflowVertical((int) $value);
break;
case 'AirflowHorizontal':
$r = $this->SetAirflowHorizontal((int) $value);
break;
case 'NanoeMode':
$r = $this->SetNanoeMode((int) $value);
break;
default:
$this->SendDebug(__FUNCTION__, 'invalid ident ' . $ident, 0);
break;
}
if ($r) {
$this->SetValue($ident, $value);
$this->MaintainTimer('UpdateStatus', $interval);
}
Vielleicht kannst du es bei dir einmal gegenprüfen und dann eventuell übernehmen.
Burkhard
Dann hätte ich noch einen Wunsch 
Für den Kühlmodus braucht man eigentlich eine andere Solltemperatur als für den Heizmodus. Da fände ich es toll, wenn man die Solltemperaturen getrennt definieren könnte.
Also z.B. 21°C als Solltemperatur Heizen und 25°C Solltemperatur Kühlen. In der App wird es wohl so praktiziert.
Wie siehst du das?
mache ich. Vermutlich werde ich da ein Property draus machen, ist ja keine Arbeit und man kann es dann immer noch anpassen.
Ja, verstehe ich. Ich hatte die Teile noch nie zum heizen benutzt, daher hatte sich mir diese Frage nicht gestellt, aber nachvollziehbar.
Melde mich wieder
1 „Gefällt mir“
es gibt bei mir 3 getrennte Temperaturen
a) auto
b) kühlen
c) heizen
bei „Entfeuchten“ scheint die Temperatur vom Kühlen zu greifen (?). Was ist bei Lüften (das habe ich ja wegen fehlender nanoe-Funktion nicht)
Nachtrag: „Trocknen“ ist auch eine eigene Temperatur, von daher erst recht die Frage, wie das bei „Lüften“ ist
Wenn ich es recht sehe, dann hat Lüften keine Temperatur. Macht ja auch eigentlich Sinn.
ok, dann setze ich das morgen oder montag um.
eine frage noch: wenn man Lüften aktiviert, was kommt dann als TargetTemperatur vom Panasonic zurück?
Ich nehme an, das man bei Lüften in der App auch keine Temperatur-Einstellrad vorhanden ist?
dort gibt es keine Auswahl an Temperatur:
richimaint
Wenn ich in der Panasonic App „Lüften“ aktiviere, dann kommt bei der nächsten Statusabfrage gar kein „temperatureSet“:
20.10.2023, 23:22:46 | UpdateStatus | jdata=Array<LF>(<LF> [energyConsumption] => 14.451<LF> [deviceRegisterTime] => 20231008<LF> [temperatureUnit] => 0<LF> [historyDataList] => Array<LF> (<LF> [0] => Array<LF> (<LF> [dataNumber] => 0<LF> [consumption] => 0.655<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 15.25<LF> [cost] => 0<LF> )<LF><LF> [1] => Array<LF> (<LF> [dataNumber] => 1<LF> [consumption] => 0.684<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 27.75<LF> [averageOutsideTemp] => 15.5<LF> [cost] => 0<LF> )<LF><LF> [2] => Array<LF> (<LF> [dataNumber] => 2<LF> [consumption] => 0.637<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 27.25<LF> [averageOutsideTemp] => 15.25<LF> [cost] => 0<LF> )<LF><LF> [3] => Array<LF> (<LF> [dataNumber] => 3<LF> [consumption] => 0.733<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28.25<LF> [averageOutsideTemp] => 15.25<LF> [cost] => 0<LF> )<LF><LF> [4] => Array<LF> (<LF> [dataNumber] => 4<LF> [consumption] => 0.665<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 27.75<LF> [averageOutsideTemp] => 14.75<LF> [cost] => 0<LF> )<LF><LF> [5] => Array<LF> (<LF> [dataNumber] => 5<LF> [consumption] => 0.643<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 27.25<LF> [averageOutsideTemp] => 14.5<LF> [cost] => 0<LF> )<LF><LF> [6] => Array<LF> (<LF> [dataNumber] => 6<LF> [consumption] => 0.383<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 14<LF> [cost] => 0<LF> )<LF><LF> [7] => Array<LF> (<LF> [dataNumber] => 7<LF> [consumption] => 0.704<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28<LF> [averageOutsideTemp] => 14.5<LF> [cost] => 0<LF> )<LF><LF> [8] => Array<LF> (<LF> [dataNumber] => 8<LF> [consumption] => 0.65<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28<LF> [averageOutsideTemp] => 14.5<LF> [cost] => 0<LF> )<LF><LF> [9] => Array<LF> (<LF> [dataNumber] => 9<LF> [consumption] => 0.676<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28<LF> [averageOutsideTemp] => 14.5<LF> [cost] => 0<LF> )<LF><LF> [10] => Array<LF> (<LF> [dataNumber] => 10<LF> [consumption] => 0.682<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 28.25<LF> [averageOutsideTemp] => 15.25<LF> [cost] => 0<LF> )<LF><LF> [11] => Array<LF> (<LF> [dataNumber] => 11<LF> [consumption] => 0.652<LF> [averageSettingTemp] => 22<LF> [averageInsideTemp] => 27<LF> [averageOutsideTemp] => 16<LF> [cost] => 0<LF> )<LF><LF> [12] => Array<LF> (<LF> [dataNumber] => 12<LF> [consumption] => 0.58<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 20<LF> [averageOutsideTemp] => 16.75<LF> [cost] => 0<LF> )<LF><LF> [13] => Array<LF> (<LF> [dataNumber] => 13<LF> [consumption] => 0.601<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 20<LF> [averageOutsideTemp] => 18<LF> [cost] => 0<LF> )<LF><LF> [14] => Array<LF> (<LF> [dataNumber] => 14<LF> [consumption] => 0.583<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 22.75<LF> [averageOutsideTemp] => 18<LF> [cost] => 0<LF> )<LF><LF> [15] => Array<LF> (<LF> [dataNumber] => 15<LF> [consumption] => 0.85<LF> [averageSettingTemp] => 28.5<LF> [averageInsideTemp] => 26.25<LF> [averageOutsideTemp] => 18.5<LF> [cost] => 0<LF> )<LF><LF> [16] => Array<LF> (<LF> [dataNumber] => 16<LF> [consumption] => 0.506<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 28.75<LF> [averageOutsideTemp] => 17.25<LF> [cost] => 0<LF> )<LF><LF> [17] => Array<LF> (<LF> [dataNumber] => 17<LF> [consumption] => 0.579<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 28.75<LF> [averageOutsideTemp] => 16.75<LF> [cost] => 0<LF> )<LF><LF> [18] => Array<LF> (<LF> [dataNumber] => 18<LF> [consumption] => 0.62<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 29.5<LF> [averageOutsideTemp] => 16.25<LF> [cost] => 0<LF> )<LF><LF> [19] => Array<LF> (<LF> [dataNumber] => 19<LF> [consumption] => 0.573<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 15.25<LF> [cost] => 0<LF> )<LF><LF> [20] => Array<LF> (<LF> [dataNumber] => 20<LF> [consumption] => 0.604<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 14.25<LF> [cost] => 0<LF> )<LF><LF> [21] => Array<LF> (<LF> [dataNumber] => 21<LF> [consumption] => 0.603<LF> [averageSettingTemp] => 27<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 14.25<LF> [cost] => 0<LF> )<LF><LF> [22] => Array<LF> (<LF> [dataNumber] => 22<LF> [consumption] => 0.588<LF> [averageSettingTemp] => 25.5<LF> [averageInsideTemp] => 28.5<LF> [averageOutsideTemp] => 14.25<LF> [cost] => 0<LF> )<LF><LF> [23] => Array<LF> (<LF> [dataNumber] => 23<LF> [consumption] => -255<LF> [averageSettingTemp] => -255<LF> [averageInsideTemp] => -255<LF> [averageOutsideTemp] => -255<LF> [cost] => 0<LF> )<LF><LF> )<LF><LF>)<LF>ok
in dem Log war nur der Abruf der historischen Daten zu sehen. Wäre aber folgerichtig
Zu den mehreren Zieltemperaturen hätte ich noch eine Frage um Einschätzung eurerseits. Es gibt folgende Implementierungmöglichkeiten
-
es gibt weiterhin nur eine Variable TargetTemperatur, intern jedoch für jeden OperationMode ein Attribute, in dem der aktuelle Wert gemerkt wird. Wir der Wert der Variable geändert, wird dieser Wert auch in das korrespondierende Attribut übernommen und (wie bisher) an die Panasonic-Cloud geschickt.
Beim Wechsel des OperationMode wird der jew. Zielwert aus dem korrespondierenden Attribute gelesen, die Variable gesetzt etc pp.
Das entspricht am ehesten dem Verhalten der App, auch da hat man nur eine aktuelle Zieltemperatur sichtbar/editerbar.
Kleiner Nachteil: man weis nicht, wie der Zielwert eines nicht aktiven OperationMode ist und kann ihn auch nicht ändern. -
statt der Attribute gibt es zusätzliche Read-only Variablen. Verhalten analog zu (1) mit dem „Vorteil“, das man auch sehen kann, wie die Zielwerte nicht aktiver OperationMode sind
-
wie (2), jedoch sind die Variablen editierter. Dann könnte man auch bei inaktiven Modi den Zielwert ändern, schafft aber sowohl etwas mentales Chaos (weil man ja nur mit Kenntnis des Kontextes weis, welche Änderung jetzt auch zu einer Änderung im Gerät führt. Ist auch m.M. nach bei der Implementierung ziemlich tricky, weil sich zwei editorbare Variablen (TargetTemperature und der jew. aktive Modus-spezifischen Zielwert.) ja gegenseitig beeinflussen können und das in Abhängigkeit von einer 3. Variablen (OperationMode)
-
es gibt nur die Modusabhängigen Zielwerte (also kein aktuelle TargetTemperatur). Auch ziemlich Tricky; zudem noch unklarer, weil man den Kontext kennen muss (welcher Modus denn gerade aktiv ist) um zu erkennen, welcher Zielwert denn gültig ist. Wäre zu unterstützen durch Invisible-machen von den jew. anderen Variablen, aber das darf eine Modul gar nicht machen, wäre also immer eine manuelle Erstellung von Logik, um das Invisble zu schalten.
Irgendwie unschön.
Insgesamt plädiere ich eigentlich für (1)
Dann habe ich gesehen in dem Screenshot von @richimaint: „Inside Clean“
a) ich nehme an, das ist de Luftqualität?
b) ich nehme an, da kann auch was anderes stehen? was zB?
c) sieht man das irgendwo in den Daten?
Und dann bleibt ja noch die Frage, wie sich das mit dem (gefakten) Betriebsmodus „nanoe-x“ (neben dem Modus "Entfeuchten) verhält. Indem Daten war ja nichts zu sehen, das es ein spezieller OperationMode ist, sondern die Kombination von OperationMode=Lüften+nanoe=ON
Schicke ich aber diese Wertekombination an das Gerät, wird der Button nicht blau. Mich würde mal interessieren, was eigentlich auf einem zweiten Endgerät steht, wenn man auf dem ersten den nanoe-x-Button drückt (also das oben rechts blau wird). Ist das auf dem 2. Handy dann auch blau? Dann müsste es ja doch irgendwas in den Daten sein.
Steht für das:
richimaint
ok, dann ist das ja eher uninteressant für IPS