Ansteuerung SolvisMax/Solvis-Remote

alpine310 · 07 Februar 2020, 13:57:28

Hallo Stefan

ZitatMir fällt gerade ein, hast Du evtl. keinen mehrstufigen Brenner? Bei mir sieht dies wie im Anhang aus. Er hängt sich bei der Laufzeitanforderung 2 ja auf

Genau. Ich habe einen modulierenden Gasbrenner. Deshalb sieht bei mir das Bild anders aus (siehe Anhang)!

Martin

SCMP77 · 07 Februar 2020, 14:10:42

Hallo Martin,

das ist die Ursache, vielen Dank.

Ich werde jetzt noch ein Optional-Attribut einführen. Der Server wird zwar versuchen den Wert abzufragen, wenn aber das Optional-Flag gesetzt ist, wird er den Format-Fehler ignorieren und einfach 0h zurückgeben. Ist dann für diese Konstellation ein unnötiges Reading, aber als neue Konfiguration will ich es aktuell noch nicht ansehen, denn dann wird das control.xml immer komplizierter und entsprechend schwer zu pflegen. Die Koordinaten der übrigen Felder sind ja glücklicherweise identisch.

Viele Gruße
Stefan

SCMP77 · 07 Februar 2020, 14:57:01

Hallo,

habe das Optional-Flag eingeführt. Das mit der blockierenden Queue habe ich noch nicht reingebracht, wäre ja auch nur eine Symptombekämpfung.

Die Version 0.10.05 liegt wieder auf dem Google-Drive.

Da ich das control.xml-File ändern musste, ist leider ein neues Learning erforderlich.

Dazu muss vorher der Service mittels "sudo systemctl stop SolvisSmartHomeServer.service" gestoppt sein.

Ich empfehle dazu folgende Befehlssequenz:

Code Auswählen

sudo systemctl stop SolvisSmartHomeServer.service
sudo make install
sudo make learn
sudo systemctl start SolvisSmartHomeServer.service

Viel Erfolg
Stefan

alpine310 · 07 Februar 2020, 16:00:04

Hallo

jetzt funktionierts

werde mich jetzt mit beschäftigen und meine alte Lösung auf deine neue umbauen.
Ich werde mich mit meinen Erfahrung wieder melden...Bei Problemen früher...ansonsten später

Ach ja, das ausufernde Log müsste man irgendwann wieder abstellen, oder irgendwo eine
"Schalter" einbauen mit dem man es für die Fehlersuche bequem ein- bzw. wieder auschalten kann.

Auf jeden Fall mal vielen Dank für die Mühe. Solltest du jemanden für weitere Test brauchen, dann
kannst du dich gerne melden

Martin

SCMP77 · 07 Februar 2020, 16:17:20

Zitat von: alpine310 am 07 Februar 2020, 16:00:04
jetzt funktionierts

Super!

Zitat von: alpine310 am 07 Februar 2020, 16:00:04Ach ja, das ausufernde Log müsste man irgendwann wieder abstellen, oder irgendwo eine "Schalter" einbauen mit dem man es für die Fehlersuche bequem ein- bzw. wieder auschalten kann.

Ich werde das in der nächsten Version auf "Debug" setzen, nicht auf Info. Dann kann man es - wenn man will - wieder vor holen. Die Log-Steuerung erfolgt über die Datei log4j2.xml in dem Verzeichnis /opt/fhem/SolvisServerData. da kann man die Levels einstellen. Aktuell steht er für das Log-File auf Info, wenn man es auf Debug setzt, hat man dann die Meldungen und noch vieles andere im Log-File. Dort kann man auch einstellen, welche Meldungen auf der Console erfolgen. Bei einem Service macht das aber nicht viel Sinn, daher werden nur Log-Meldungen ausgegeben, welche beim Learn-Vorgang entstehen. Log4J ist ein Standard, was häufig für Java-Programme verwendet wird.

Viele Grüße
Stefan

SCMP77 · 08 Februar 2020, 21:52:47

Hallo,

habe jetzt die Version 0.10.06 wie üblich auf das Google-Drive gelegt (mit Sourcecode) .

https://drive.google.com/open?id=16I0RwNuYhTuL0AOJ1cGEOmnwlBNMqaRz

Die gestern eingebauten Log-Messages sind nun nicht mehr auf Info sondern Debug gesetzt, so dass sie im Standard-Log nicht mehr auftauchen.

Außerdem werden nun fehlerhaft ausgeführte Befehle ab dem 3. Versuch an das Ende der Command-Queue gehängt, so dass andere Command nun dran kommen können. Beim 10ten Fehler wird er ganz aus der Queue entfernt, dabei werden entspechende Fehler-Messages in den Log geschrieben.

Außerdem habe ich noch den Fhem-Client um die Beschreibung der Zustände von dem Reading "state" ergänzt.

Viele Grüße
Stefan

Lahaspi · 09 Februar 2020, 21:01:17

Hallo Stefan,

bei mir funktioniert Deine Software nun auch.
Sollte mir etwas auffallen melde ich

Ganz herzlichen Dank nochmals und viele Grüße,

Martin

alpine310 · 10 Februar 2020, 13:34:07

Hallo Stefan
habe gerade eine kleine Sache gesehen:
S11.Zirkulationsdurchfluss ist eine Temperatur.

man könnt Sie als:
S11.Zirkulationstemperatur
oder
S11.ZirkulationRücklauftemperatur (ist zwar genauer aber die Bezeichung ist etwas sperrig)
bezeichnen.

Gruß Martin

SCMP77 · 10 Februar 2020, 20:03:02

Hallo Nartin,

Danke für den Hinweis (habe keinen Ringleitung). Ich denke, ich nehme schon den langen Namen. Man kann ja bei der Anwendung mit regulären Ausdrücken arbeiten, da ist dann die Länge kein Hindernis.

Viele Grüße
Stefan

SCMP77 · 26 Februar 2020, 15:42:16

Hallo,

auf dem Google-Drive liegt eine neue Version:

https://drive.google.com/open?id=16I0RwNuYhTuL0AOJ1cGEOmnwlBNMqaRz

Auf Vorschlag von JHS ist nun die GUI-Steuerung über den Client (per Attribut "GuiCommandsEnabled") deaktivierbar. Ein Setzen auf FALSE dürfte dann Überraschungen bei den Service-Mitarbeitern und beim Schornsteinfeger verhindern. Außerdem werden die Bildschirme "Schornsteinfeger", "Nutzerauswahl" und "Nutzerauswahl-Code-Eingabe" erkannt und führen dazu, dass nach diesen Seiten min. 60 Minuten vergehen, bis die GUI-Steuerung wieder aktiv wird. Set-Kommandos werden in dieser Zeit zwar gemerkt, aber nicht ausgeführt. Jede Bildschirmänderung in dieser Zeit triggert die 60 Minuten erneut. Als Servicefall wird auch das Einschalten der Anlage betrachtet. Das ist noch ein "Notanker", falls man vergessen hat, das Attribut szu setzen.

Wenn man den Ablauf der 60 Minuten dann nciht mehr abwarten will, kann man über den Client mittels " Set device-name ServerCommand SERVICE_RESET" den Server wieder in den normalen Zustand bringen.

Außerdem sind jetzt die aktiven Features des Servers über das base.xml wählbar. dazu dient dort das neue Element Features. Entsprechende Kommentare sind in base.xml eingetragen.

Das Paket wird immer mit einer base.xml ausgeliefert, ber der sämtliche Features deaktiviert sind!. Der Anwender muss so aktiv wählen, was er nutzen will.

Die weiteren Ergänzungen/Fehlerbehebungen sind dem im Paket enthaltenen CHANGES.txt-Datei zu entnehmen. Die Doku wurde entsprechend erweitert.

Viele Erfolg und viele Grüße
Stefan

PS:
Bei dem Update muss erneut ein Learning erfolgen. Ich habe das Makefile nun so geändert, dass es reicht, den Update + Learning wie folgt anzustoßen, nachdem das base.xml entsprechnd angepasst wurde:

sudo make learn

Das hat zur Folge, dass der Server gestoppt wird, die Dateien entsprechend aktualisiert, der Lernvorgang gestartet wird und wenn dieser fehlerfrei beendet ist, der Service wieder gestartet wird.

SCMP77 · 07 März 2020, 15:51:20

Hallo,

es gib mal wieder eine neue Version, die V00.11.02.

Folgende wesentlichen Änderungen sind erfolgt:

Der Status "Service" wurde durch einen Bug nicht autiomatisch nach 1h zurück gesetzt. Der Zugriff auf die Schornsteinfeger- oder Nutzer-Seite bewirkte, dass keinen Befehle mehr über das GUI gingen
Das Clock-Fine-Tuning habe ich komplet ausgebaut, das normale Stellen der Uhr ist davon nicht betroffen. Wie ich schon schrieb, führt das häufige Stellen der Uhr, das bei dieser Methode notwendig ist, manchmal zum Absturz der SolvisControl. Die hatte sich bisher immer wieder "erholt". Vor vielleicht einer Woche war die SolvisControl nach einem solchen Absturz nicht mehr im Modus "Tag" sondern "Timer". Das bedeutet, es ist nicht gesichert, dass die Anlage nach einem solchen automatischen Reset dann wirklich im vorherigen Zustand ist. Dieses Feature musste daher entfernt werden, war in Wirklichkeit eher Spielerei
Ich habe jetzt noch einen "DoubleUpdate eingeführt. Bisher war es so, dass sämtliche Kanäle die Daten zu Beginn der Stunde zum Client geschickt hat. Damit war immer sicher gestellt, dass die FHEM-Diagramme auch in der maximalen Vergrößerung immer links begonnen hatten. Das galt aber nicht für den rechten. Der Server schickt daher nun symetrisch zum Stundenwechsel 2 Updates. Der Abstand dieser Updates kann im base.xml-File durch das Attribut "doubleUpdateInterval_ms" eingestellt werden. Standard ist 10s.
Das "enable"-Atribut in der base.xml für das Stellen der Uhr habe ich entfernt, Es gibt die identische Funktion auch in den Feature-Elementen. Das hatte zu Verwirrungen geführt.

Hier nochmal der Link zum GoogleStore:

https://drive.google.com/open?id=16I0RwNuYhTuL0AOJ1cGEOmnwlBNMqaRz

Und seit der Version V00.11.01 gilt immer:

Das Paket wird immer mit einer base.xml ausgeliefert, bei der sämtliche Features deaktiviert sind! Der Anwender muss so aktiv wählen, was er nutzen will.

Viele Grüße
Stefan

SCMP77 · 15 März 2020, 19:08:24

Hallo,

kleine Vorankündigung:

Die Kombination SolvisControl-2/SolvisRemote ermöglicht ab Hardware-Versionsstand MA205 auch einen Modbus-Zugriff.

Sicher ist aktuell, dass die SolvisBen-Reihe komplett mit dieser Version ausgestattet ist. Da die SolvisMax 7 schon 2015 erschien, sicherlich nur die neueren.

Mit dem Modbus-Interface ist natürlich die ganze Gui-Steuerung nicht mehr notwendig. Ich werde den Modbus in den SolvisSmartHomeServer integrieren.

Könnt Ihr mir mal eine PM schreiben und mir mitteilen, ob Ihr schon die Version MA205 eingebaut habt?

Die Versionsnummer findet Ihr unter "Sonstig./weiter/System Informationen" und zwar unten links. Bei mir steht da noch MA150...

Viele Grüße
Stefan

SCMP77 · 15 April 2020, 20:48:38

Hallo,

ich habe eine neue Version auf den Google-Drive gelegt, die V01.00.01.

Folgende wesentlichen Änderungen sind erfolgt:

Vorbereitungen für Modbus, aber noch nicht getestet
Fhem-Client: Umgestellt auf FHEM::MaxClient-Package, FHEM::Meta-Support und mit etwas besserem Perl (angeregt durch RichardCZ)
Synchronisations-Fehler gefixt: Bei (fast) gleichzeitigem Zugriff von mehr als einem Client auf den Server, kam es sporadisch vor, dass der Zugriff für einen der beiden Clients nicht mehr möglich war
Clock-Adjustment funktionierte bei einer Differenz von mehr als 19h nicht mehr
Die Gui-Steuerung funktionierte nach Power-Off nicht mehr, wenn das Feature PowerOffIsServiceAccess aktiviert war.
Nach einem User-Zugriff wurde weder die WW-Temperatur noch der Status der WW-Pumpe aktualisiert

Hier nochmal der Link zum GoogleStore:

https://drive.google.com/open?id=16I0RwNuYhTuL0AOJ1cGEOmnwlBNMqaRz

Und seit der Version V00.11.01 gilt immer:

Das Paket wird immer mit einer base.xml ausgeliefert, bei der sämtliche Features deaktiviert sind! Der Anwender muss so aktiv wählen, was er nutzen will.

Da wegen den Modbus-Vorbereitungen das Format der Control-Datei erweitert wurde, ist ein erneutes Learning notwendig.

Nach dem Auspacken des Paketes daher folgenden Befehl ausführen:

Code Auswählen

sudo make learn

Viele Grüße
Stefan

ahlermi · 28 April 2020, 16:34:40

Hallo zusammen,

seit dem letzten neustart des FHEM Servers streikt das SolvisMax Modul.

Es steigt mit der Meldung:

Code Auswählen

Error: Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.28.1/LWP/Authen/Digest.pm line 17.

aus, und FHEM schmiert ab

Ich habe das Problem jetzt erst mal gelöst in dem ich ein "Try / Catch" im SolvisMax_ReadData($) eingebaut habe:

Code Auswählen


        my $response = undef;
        eval {
                my $urlLong = sprintf("http://%s/sc2_val.xml", $socket);
                $response = $ua->get( $urlLong );

                if ( !$response->is_success ) {
                        return "0|".$response->status_line;
                }
                1;
        } or do {
                my $e = $@;
                return "0|$e";
        };

        my $content = $response->decoded_content();

Nur bekomme ich mit dem Modul keine Werte mehr. Das Modul SolvisClient hingegen läuft.

Ein Perlexperte eine Idee? Passwort und User werden richtig übergeben, das habe ich mir schon ausgeben lassen.

Gruß Michael

SCMP77 · 03 Mai 2020, 20:46:48

ZU BEACHTEN

Leider ist seit der Version 1.0.0 ein Bug reingerutscht, der sich bei Konfigurationen ohne Raumtermostat zeigt. Es gibt eine Nullpointer-Exception.

Bitte daher auf die nächste Version warten, sie wird dann auch den Betrieb mit zwei Heizkreisen beherrschen und kann auch im Störungsfall eine Mail mit der Harcopy der Störung vesenden.

Außerdem gibt es mit diesen neueren Versionen ein Problem mit dem alten XML-File. Das versucht der Server erstmal einzulesen und erleide dabei Schiffbruch.

Sollte daher jemand doch eine der obigen Versionen benutzen, ist daher aus dem Verzeichnis, das in der base.xml unter "writablePathLinux" angegeben ist, die Datei "SolvisServerData/control.xml" zu löschen.

Auch das Problem wird in der neueren Version behoben sein.

Viele Grüße
Stefan