Neues Modul für Brilix/Alsavo Pool-Wärmepumpe

Begonnen von Init, 02 Juni 2023, 19:18:54

Vorheriges Thema - Nächstes Thema

Init

Hallo zusammen,

da ich gerne meine Wärmepumpe über FHEM steuern möchte und es nichts in der Richtung gibt, habe ich endlich Zeit gefunden ein eigenes Mini-Modul anzufangen.

Da ich gerne die Dinge komplett verstehen würde, die ich hier mache, habe ich folgende Verständnisfrage:

Warum leitet folgendes "set" über FHEMWEB bei einem "on" immer auf eine leere Seite weiter, auf der dann "on" steht:
sub Alsavo_Set($@) {
.....
    if($cmd eq "off" || $cmd eq "on"){
        $hash->{STATE} = "$cmd";
        }
.....
}


Und warum bleibt folgende Version nach dem Ausführen des gleichen "set" auf der Seite und aktualisiert die Daten dort?
sub Alsavo_Set($@) {
.....
    if($cmd eq "off" || $cmd eq "on"){
        $hash->{STATE} = "$cmd";
        Log3 $name, 3, "$self #3 State: after: ". $hash->{STATE};
        }
.....
}


Letzte Variante hätte ich gerne, aber ich möchte keine überflüssigen Logausgaben einbauen.

Viele Grüße
Marc

Beta-User

Bitte nicht direkt ins Internal schreiben, sondern das Reading "state" aktualisieren (allerdings m.E. in Senderichtung mit einem Übergangswert).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Init

Danke für den Hinweis auf die richtige Implementierung.

Es sieht nun wie folgt aus:

sub Alsavo_Set($@) {
.....
    if($cmd eq "off" || $cmd eq "on"){
        readingsSingleUpdate($hash,'state',$cmd,1);
        }
.....
}

Aber leider lande ich nach dem Schalten auf on oder off wieder auf einer leeren Seite, wo das letzte $cmd ausgegeben wird. Also on oder off.

Was mache ich hier falsch?

Möchte weiterhin keine unnötige Logausgabe implementieren.

Viele Grüße
Marc


Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Init

Das
Zitatreturn
fehlte.

Jetzt funktioniert es wie erwartet.

Vielen Dank!

Init

Hallo,

jetzt habe ich leider das nächste Problem  :(

Ich möchte die Daten aus der Wärmepumpe über qx abholen, aber dies soll FHEM nicht blockieren.

Daher rufe ich das Update wie folgt auf:
    BlockingCall("getUpdates", $hash, "", "", "", "");

In der Sub getUpdates rufe ich das Modul der Wärmepumpe auf um die Statuswerte als Reading zu speichern, aber die Readings im BlockingCall werden nicht an das Device übergeben. Hier mein sub:
sub getUpdates($){
    my ($hash) = @_;
    my $output=qx (./AlsavoCtrl -s xxx -l xxx -a 172.16.0.70 -p 1194 2>/dev/null);
my @lines = split /\n/, $output;
readingsSingleUpdate($hash,'marc','initB10r',1);
readingsBeginUpdate($hash);
foreach my $line( @lines ) {
    my $jsonraw = (split(/\=/,$line))[1];
    my $json = from_json($jsonraw);
    my $rowId = $json->{index};
    my $rowValue = $json->{value};
    my $rowReadingName = $Alsavo_params{$rowId};
readingsBulkUpdate($hash, $rowId, $rowValue );
    }
readingsEndUpdate($hash, 1);
    return;
    }

Auch das "readingsSingleUpdate" klappt nicht. Vor dem BlockingCall funktioniert ein "readingsSingleUpdate".

Ist das nicht möglich, was ich hier versuche?

Viele Grüße
Marc

Beta-User

Kann mir das leider grade nicht im Detail ansehen.

Vielleicht suchst du mal meine Version von TvHeadend. Die ist etwas anders strukturiert (gepackaged), aber sonst vermutlich ähnlich.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Init

Danke für deine Hilfe!

Habe mir die letzte Version von runtergeladen, aber leider verfährst du da anders als ich, da du alles über HTTP-Requests abfragen kannst.

Bei meiner Wärmepumpe muss ich ein qx auf ein python-Skript machen.

Hab aber nun auch das Problem entdeckt. Ich muss das Ergebnis im Hauptprozess verarbeiten. Im Wiki wird auch auf diese Einschränkung hingewiesen:
ZitatVeränderungen an internen Variablen von FHEM (Device Hashes, Timers, usw.) werden innerhalb eines BlockingCalls durchgeführt und sind dort auch sichtbar, haben aber keinerlei Einfluss auf den eigentlichen FHEM Hauptprozess und alle Definitionen. Solche Veränderungen müssen an die finishFn delegiert werden

Grüße
Marc