Pool Controller

Begonnen von bugster_de, 01 Mai 2014, 22:34:49

Vorheriges Thema - Nächstes Thema

dadoc

Hi Bugster,
Zitat von: bugster_de am 03 Juli 2017, 10:08:49
Ich hatte den Martin vor geraumer Zeit mal gefragt, ob er nicht "virtuelle Eingänge" als neues Feature in den Pool-Controller aufnehmen kann, [...] Hast Du da mal was von Martin gehört?
Falls Du mich meinst, glaube ich, dass Du mich verwechselst. Ich habe weder dieses noch das andere Pool-Modul gemacht, sondern nur ein paar kleine Änderungen eingefügt. Vielleicht meinst Du Frank?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

charlie71

Hi Bugster,

ich hab mir schon eine Lösung für dein gewünschtes Feature überlegt, leider muss dafür eine komplett neue Schnittstelle implementiert werden.
Das wird ein wenig dauern ;-)

Mit dieser Lösung währe es möglich folgende Relaisemodi zu setzen:
* Manual Aus
* Manuel Ein
* Auto

lG
Charlie71

dadoc

Hi Charlie,
Zitat von: charlie71 am 24 Juni 2017, 11:15:59
ich werd mir bei Gelegenheit das Timeout verhalten prüfen.
Hast Du schon eine Idee dazu bekommen? Steigt bei mir wg. VPN Verbindung und Zwangstrennungen immer wieder gern aus.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

charlie71

Hallo,

ich hab einen Wunsch von dadoc umgesetzt, es gibt in der neuen Version ein timeout Attribute.
Antwortet der Poolcontroller nicht innerhalb des timeouts --> dann geht der Status auf Error.

lG
charlie71


dadoc

Vielen Dank Charlie, ich habe ihn jetzt mal auf 6.000 gesetzt, so dass die Erfassung auch bei läneren Verbindungsunterbrechungen erhalten bleibt.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

andre070

Hallo zusammen, seit einiger Zeit hab ich ein Problem mit dem Modul und kann es mir nicht ganz erklären.

Das PM Modul empfängt irgendwann keine Daten mehr bzzw. stellt den Betrieb einfach ein.
Als wenn das Modul "disabled" wird. Status nach wie vor auf "OK".

Das erkennt man daran, das zb. beim auslesen aller Werte, auch der Uhrzeit ein alter Wert drin ist.
Den Controller selber kann ich aber jederzeit erreichen.

Wenn ich bei Fhem ein shutdown restart eingebe funktioniert es wieder eine Zeit lang..mal Stunden, mal rund einen Tag in etwa.
Aktualisierungsintervall ist auf "300".

Was könnte das sein?

Die aktuellste Version habe ich eingespielt und auch diesen Tmeout mal probiert. Ergebnis bleibt aber gleich.
Fhem ist up to date..

Vielen Dank!

Andre

dadoc

Zitat von: charlie71 am 12 August 2017, 13:01:34
es gibt in der neuen Version ein timeout Attribute.
Antwortet der Poolcontroller nicht innerhalb des timeouts --> dann geht der Status auf Error.
Hmm... scheint auch bei kürzeren Trennungen auf error zu gehen:
21.08.17 22:30:16 VPN-Verbindung zu xxxx.myfritz.net wurde erfolgreich hergestellt.
21.08.17 21:56:17 VPN-Verbindung zu xxxx.myfritz.net wurde getrennt. Ursache: 9 Dead Peer Detection


Letzer Eintrag im Pool Log:
2017-08-21_21:52:16 Pool Wassersensor: -6.46
2017-08-21_21:52:16 Pool Time: 5428

Eintrag im fhem Log:
2017.08.21 21:57:14 1: Timeout for myPoolcontroller_bcReadData reached, terminated process 5417
Das würde ja heißen, dass das Modul trotz Timeout-Einstellung 6000 bereits nach knapp 60 sec. auf Error geht?
Oder sind die Timeout-Angaben vlt. in Milliskenunden?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

andre070

#82
Ok, ich hab auch mal in das Log geschaut und entdecke das auch, habe aber keine vPN, sondern eine direkte lokale Verbindung.

Im PM Log letzter Eintrag:
2017-08-29_19:22:34 PM Time: 4886

Fhem:
2017.08.29 19:34:18 1: Timeout for myPoolcontroller_bcReadData reached, terminated process 8472


charlie71

Hallo,

Timeout heißt nur dass der TCP - Client (in unserem Fall ist das das FHEM Modul) auf eine Antwort vom Server (= poolcontroller) wartet.
Wenn nun die Antwort früher kommt macht weiteres warten keinen Sinn. Die Antwort kann aber auch negativ (wie in den vorliegenden Fällen sein). Gründe für negative Antworten:
* kann den host nicht erreichen
* Netzwertverbindung getrennt.

lg
Charlie71

dadoc

Moyn zusammen,
was wäre denn der beste Weg, um das Modul nach einem Ausstieg (Timeout for myPoolcontroller_bcReadData...) automatisch wieder zu starten - alle halbe Stunde ein at mit rereadcfg oder so etwas? Bzw. wie reaktiviert man das Modul am Besten nach dem Timeout?
Würde etwas dagegen sprechen, wenn man das Modul so ändert, dass es bei Verbindungsabbruch über den Timeout hinaus einfach weiterläuft und halt automatisch dann wieder Daten holt, wenn die Verbindung erneut steht?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

charlie71

Hallo dadoc,

ich hab mir meinen Code angesehen, auch bei einem Timeout sollte kein Neustart des Modules notwendig sein. Wenn die Verbindung wieder aufgebaut ist sollte die Abfragen normal funktionieren.

lG
charlie71

dadoc

Hi Charlie,
bin jetzt gerade etwas verwirrt, weil ich den Timeout zum Testen nicht provoziert bekomme (Abfrageintervall auf 180, timeout auf 60 sec). Habe den Poolcontroller stromlos gemacht, aber statt wie bisher:
Timeout for myPoolcontroller_bcReadData reached, terminated process 1768
steht im Log schlicht:
2018.05.22 17:00:48 3: Error: Can't get http://192.168.0.xxx:8056/GetState.csv -- 500 Can't connect to 192.168.0.xxx:8056
2018.05.22 17:03:49 3: Error: Can't get http://192.168.0.xxx:8056/GetState.csv -- 500 Can't connect to 192.168.0.xxx:8056
2018.05.22 17:06:49 3: Error: Can't get http://192.168.0.xxx:8056/GetState.csv -- 500 Can't connect to 192.168.0.xxx:8056

usw. alle 3 Minuten. Das meinst Du vermutlich damit, dass das nach einem Verbindungsausfall automatisch weitergeht?

Wie wird denn dann der bcReadData Timeout verursacht? Nach einem solchen läuft das Modul nämlich AFAIK nicht automatisch weiter, wenn die Verbindung zurückkommt - da wurde ja auch ein Prozess gekilled?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

charlie71

Hallo Martin,

die Abfrage desPoolcontroller läuft in einem separaten Prozess. Leider killt FHEM den Prozess beim überschreiten des FHEM Prozesstimeouts (ungleich http timeout).
Den FHEM Prozesstimeout habe ich übersehen, so dass es unter Umständen dazukommen kann, dass der FEHM Prozesstimeout den Abfrageprozess killt.

Ich habe in der angefügten Version das Problem behoben, so dass das FHEM Prozesstimeout = http timeout +30s gesetzt wird.
lG
Charlie71

dadoc

Vielen Dank Charlie. Da die 30 sec. bei einem längeren Ausfall möglicherweise nicht ausreichen: wie würde man  nach einem fhem Prozesstimeout das Modul neu starten (außer mit shutdown restart bzw. rereadcfg)? Dann könnte man ja einfach ein DOIF anlegen, das die Sache im Auge behält.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

charlie71

Hallo Martin,

wenn der Server nicht erreichbar ist, dann schlägt dass httpTimeout zu und dass Modul funktioniert normal weiter. Das FHEMProzesstimeout ist immer um 30s größer als das http timeout, somit ergeben sich 30s für die Datenverarbeitung, das ist mehr als ausreichend.

lG
Charlie71