Beim kopieren der defekten Karte gab es einige Lesefehler, und zwar bei den .csv files. Aber Irgendwie gelingt es mir nicht eine neue Karte zu aktivieren, habe leider nur min. 16GB sd cards, habe mal eine 4GB Partition (equivalent zur original Karte) formatiert und Dateien kopiert. Der Controller bootet dann, das dauert aber sehr lange und das Gui wird dann nur unvollständig geladen, alle Sensorwerte auf NA und nur chts zum schalten. Habe dann mal die originale Karte mit chkdsk repariert, damit funktioniert der Controller zwar, und scheinbar funktioniert das schreiben der history auch wieder, aber ich würde dann doch gerne eine neue Karte einsetzen, wenn ich mir jetzt eine neue Karte besorge und ganz frisch formatiere, welche Dateien muss ich kopieren, bzw wo ist den die Konfiguration meines controllers abgelegt?

Danke für die schnelle Antwort.

Ich weiss den Wortlaut nicht mehr genau, und ich habe es nicht beachtet, es ist jedenfalls die selbe wie bei den raspberry images, also wenn man z.b. Windows unbekannte partitions hat. Und ich habe nicht auf reparieren geklickt.
Ich werde die Karte jedenfalls mal tauschen, ich hoffe nicht dass der Kontroller im Winter gelitten hat. Ich nehme an formatieren auf FAT?

Guten Morgen,

Da sich im Osten Österreichs der Winter schön langsam verabschiede, die Wassertemperatur zu steigen beginnt und ich jetzt mal ein paar Wochen im Urlaub bin habe ich dieses WE die Poolsteuerung reaktiviert. Beim Update hatte ich beim Einstecken der SD Karte in den PC beim ersten update (auf 1.6.6c) eine Fehlermeldung die ich eher dem Leser zugeordnet hatte, beim zweiten Update 1.6.7a trat dann keiner mehr auf. Upgrades haben funktoiniert, aber heute morgen habe ich bemerkt dass der Status des Controllers in meinem Tablet nicht angezeigt wird (/gif/test3.gif).
Beim Öffnen der poolcontroller Webseite habe ich dann auch keine Verlauf bekommen, sondern nur "loading". Mit dem SD explorer habe ich dann festgestellt dass z.b. die gif dateien 0 byte haben und dass auch keine Statistiken geschrieben werden.
Im Diagnostik Output sehe ich nur das timeout Nach einem Reset funktioniert es wieder, aber jetzt habe ich den Verdacht dass eventuell die SD Karte defekt ist und möchte sie mal sicherheitshalber tauschen.

Was gibt es dabei zu beachten? nehme ich einfach eine mit der selben Kapazität und kopiere das Image der alten drauf? oder eher normal formatieren und dann die files draufkopieren?

Gruß

Karl

Jein, nicht direkt selbst gebaut, nutze die fhem bridge https://forum.fhem.de/index.php/topic,48558.0.html

Intern, also im LAN bin ich sehr zufrieden, allerdings muss man sich mit den Gerätenamen spielen damit alles eindeutig erkannt wird. Extern, also über AppleTV und iCloud ist es allerdings nicht immer verfügbar.

Extremer show effekt für Bekannte, aber man kommt auch ohne aus, Frau nutzt es überhaupt nicht (noch).

Das Problem mit dem Durchfluß gelöst, das glaubt Ihr nie;

Bei der Meßzelle gab es einen Produktionsfehler, eine Bohrung war nicht ordentlich, nur das was vom Guß übrig blieb, ein Loch kleiner 1mm, Nach dem Aufbohren funktioniert alles perfekt

Also die Sonden kalibriert, Dosierpumpen montiert, Verrohrung fertiggestellt, und der Controller tut schon, der Sommer kann kommen.

@redbaron, ja ich habe die Löcher durch die montierte Schelle gebohrt.

@Alex, ich habe das Flowmeter montiert aber bin leider noch nicht dazugekommen dass ich es auch anschliesse. Das mache ich sobald es das Wetter wieder zulässt.

Macht es eventuell Sinn den druckseitigen Anschluss der Messzelle vor dem Filter zu platzieren? Ich befüchte nämlich dass eben an der jetzigen Stelle zuwenig Druck ist, und saugen ist nicht gerade die Stärke der Poolpumpe.

stimmt. man sieht das schlecht, der Anschluss links im Bild ist die Saugseite der Pumpe (also in Flussrichtug vor der Pumpe), vom Skimmer direkt zur Pumpe. Hinter der Messzelle ist der Anschluss auf der Druckseite, (nach dem Filter). OK jetzt glaube ich meinen Fehler zu erkennen, dort kann ja kaum noch Druck vorhanden sein da ja die Einlaufdüsen quasi offen sind. Dann müsste ich die Messzelle eigentlich VOR dem Filter anschliessen, oder?

Ja, der Verteiler ist im Schacht, die Feuchtigkeit macht mir weniger Sorgen, der Verteiler ist IP44, und auch entsprechend verkabelt, die Steckdose mit Wochenzeitschaltuhr die ich dort seit fast 20 Jahren im Einsatz hatte ist von dieser Schutzklasse weit entfernt. Ich mache mir eher wegen der Temperatur Sorgen, es wird im Verteiler durchaus schon sehr warm, muss das mal messen.

Hallo aus Österreich,

jetzt zum Saisonende habe ich mich durchringen können beim Poolcontroller zuzuschlagen und habe das jetzt seit dem Wochenende im Probebetrieb und einige Fragen die trotz wochenlangen durchforsten der Foren noch offen sind.

1. ich habe mir diese Kombidurchflusszelle DOS CL2 DeLuxe gekauft, mit allen Anschlussteilen und dem passendem 6 mm Schlauch. Die Anschlüsse sind im Kreislauf "parallel" zum Filter, also direkt vor und nach der Pumpe, mit ca. 80cm Schlauchlänge. Allerdings scheint die Durchflussmenge sehr gering zu sein (der Flowmeter ist noch nicht angeschlossen), kann es sein das der Querschnitt dieser Konstruktion zu gering ist? nicht lachen, ist nur ein Provisorium. 2. Temperatur. Ich habe jetzt bei einer Aussentemperatur von ca. 6°C im Technikschacht 15 °C und eine CPU-Temperatur von 48°C. Im Sommer haben wir wahrscheinlich wieder einige Tage über 30°C, da mein Technikschacht mit einem Alu Deckel abgedeckt ist rechne ich dann mit Temperaturen > 60°C, also ähnlich wie bei einem Auto in der Sonne. Wo liegt denn die max. CPU Temperatur? Und gibt es schon jemand der eine aktive Kühlung eingebaut hat?

Gruß

Karl

Ja, natürlich,
habe ein paar temperatur/feuchtigkeitssensoren gebaut, mit ESP8266 und DHT22, die liefern die Werte an den MQTT server. Auch für Arduino gibts fertige MQTT library, ausserdem gibt es ein MQTT Gateway für mySensors, ich bin gerade dabei einige unterscheidliche Sensoren und Aktoren damit zu bauen, für das Gateway warte warte ich nur noch bis ich endlich den Arduino Uno bekomme, dann implemtiere ich das auch. Und für die Kommunikation zwischen den FHEM Instanzen nutze ich teilweise auch MQTT. Alles was ich selbst integriere mache ich über MQTT anstatt z.b. Web Apis zu verwende. Das was es für mich so interessant macht ist die Möglichkeit die Daten aus der Queue beliebig zu verwenden, also z.b. Um verschiedene Visualiserungen oder Bedienungskomponenten zu bauen. Und in weiterer Folge dann mit Node-Red auch die Ereignissteuerung zu realisieren. Was die Latenzen betrifft, ich habe schon mal testweise mehrere hundert events pro sekunde generiert, ohne wirklich merkbare Latenzen, also da werde ich mit meiner HA eher nicht an die Grenzen stossen. Wenn ich dann mit Perl oder shellscripte die Webschnittstellen z.b. von Openhab oder FHEM bediene ist bei 40-50 Events/s die Schemrzgrenze erreicht, wobei deutliche Latenzen schon viel eher auftreten. Speziell bei FHEM das single theraded ist und auf Perl aufsetzt kommt man da schnell an die Grenzen. Ich meine da ist je nach HW bei 10 events/s schluss.

Alex hat geschrieben:Jo, die Werte kommen immer an der gleichen Stelle raus. Darüber kannst zuordnen, was was ist.

Warum musst/willst Du jede Sekunde pollen?

Hallo Alex,

das war nur mal ein Lasttest, muss nicht sein, aber um Schaltvorgänge zeitnah mitzubekommen (mir geht es nur um die Relais, ein, aus, automatik, die Tasterfunktion bekomme ich so sowieso nicht mit) muss ich halt relativ oft pollen. Habe dann gestern noch das skript erweitert und damit den MQTT Server gefüttert und damit das entsprechende FHEM Device upgedated. Alles nur um mal die Last zu testen. Das führt jedoch deutlicher Last am Server, etwa 20% CPU also verdopplung der Grundlast. Das pollen alleine ist nicht messbar, der nächste Schritt ist eben nur die Änderungen an den MQTT Server zu pushen, die reinen Messwerte reichen alle paar Minuten wie bei den anderen Sensoren.

schka17 hat geschrieben: Also zusammengefasst, pollen ist O.K., Relais schalten funtkioniert auch, aber was mir jetzt noch massiv helfen würde, wenn man zu jeweiligen Wert in der GetState.cav noch eine Typ mitbekommen könnte, damit man je nach "Gerätetyp" unterschiedlich mit den Daten weiterarbeiten kann, also z.B R=Relais, T=Temperatur, A/D=analog/digitaleingang. Jetzt verwende ich halt den Namen, aber hier muss ich dann Abstriche in der Lesbarkeit machen.

Nachtrag, habs einfach über eine Zähler gelöst, das ist auch eindeutig

Hallo,

mein erster Post und das dann gleich zu dieser interessanten Diskussion (für mich). Ich habe den Poolcontroller erst letzte Woche bekommen und bin gerade dabei zumindest mal softwareseitig alles vorzubereiten, wenn dann die restlichen Installationsteile da sind, gehts an die Pooltechnik und die HW-Installation.
Auch ich beschäftige mich schon seit vielen Jahren mit Hausautomatisierung, die Bezeichnung gab es halt damals noch nicht. Ich habe mit der Automatisierung (Beschattung/Fensteröffnung und Heizung) meines Wintergarten begonnen, damals noch mit der C-Controlunit von Conrad und mit wenigen Sensoren, also Innen/Aussen-temperatur, Helligkeit usw.
Heute habe ich ca. 300 Sensoren und Aktoren im Einsatz und die Poolsteuerung ist die letzte Komponente die mir noch fehlt (ich denke danach wird mir schon noch was einfallen). Ich habe hier in den letzten 15 Jahren ziemlich viel ausprobiert und für mich entschieden dass ich für bestimmte spezielle Aufgaben, also z.B. Heizung, Sicherheit, Alarmierung, Multimediasteuerung, Presence, GUI, Ereignissteuerung, und eben Poolsteuerung jeweils eigene, autark arbeitende Einheiten sind und jede für sich auch alleine funktioniert. Alles läuft natürlich an einer Stelle zusammen und auch hier habe ich einiges ausprobiert, am besten kam ich mit meinen Anforderungen mit Openhab und FHEM zurecht, letzteres ist jetzt auch seit zwei Jahren mit mehreren Instanzen in Produktion. Als nicht-Programmierer muss ich mich hier mit vielen Sprachen herumschlagen (Perl, Java, Shell, HTML.....) und das treibt mich teilweise zur Verzweiflung, dafür bin ich bisher nirgendwo an Grenzen der Integration gestossen, ausser bei meiner Daikin Klimaanlage, aber das ist nur eine Frage der Zeit. Ich bin dann auf MQTT und Node-Red gestossen und beginne jetzt, wenn möglich, alle neue Sensoren oder Aktoren über MQTT einzubinden. Und wenn ich mir etwas wünschen könnte für die Integration des Poolcontrollers, dann wäre das ein MQTT-Client (oder im einfachsten Fall einen telnetport den ich mit netcat auslesen kann). MQTT habe ich mittlerweile auch mit den Arduions (über das mySensors MQTT Gateway) und testweise mit dem ESP8266 im Einsatz -> das wäre vielleicht auch eine Idee um den Controller Wlan Fähig zu machen.
Und wenn man dann alle diese Aktoren und Sensoren am MQTT angebunden hat dann kann man damit auch als nicht-programmierer schon sehr viel machen, z.b. mit Node-red visuell eigene Regeln erstellen oder auch eigene GUI's.

Es gibt zwar zwei FHEM Module für den Poolcontroller, die erfüllen aber beide nicht meine Anforderungen, muss mir was eigenes schreiben, verwende zurzeit testweise das Perl script von Alex und werde es ein bischen modifizieren. Meine bisherigen Tests damit haben jedenfalls gezeigt dass das pollen im 1s Abstand scheinbar keine Auswirkungen auf den Controller hat und auch im Netzwerk und auf meinem zentralen Rechner keine messbare Last erzeugt, also kann ich damit mal sehr gut leben.
Ich teile die vorher abgebenen Meinungen dass ich nicht alle Messwerte bei jeder Änderung benötige, der Controller soll ja grundsätzlich autark arbeiten, aber Statusänderungen bei den Tastern oder Relais hätte ich schon gerne sehr zeitnah, darunter verstehe ich ca. 1-2s. Das reicht natürlich nicht für die Bedienung beispielsweise eines Lichtschalters, weil in einer früheren Phase hatte ich das mal ausprobiert und alles über Regeln gesteuert, und alle Reaktionszeiten > 300ms war eine Katastrophe (also Lichtschalter ein bis Licht angeht).
Also zusammengefasst, pollen ist O.K., Relais schalten funtkioniert auch, aber was mir jetzt noch massiv helfen würde, wenn man zu jeweiligen Wert in der GetState.cav noch eine Typ mitbekommen könnte, damit man je nach "Gerätetyp" unterschiedlich mit den Daten weiterarbeiten kann, also z.B R=Relais, T=Temperatur, A/D=analog/digitaleingang. Jetzt verwende ich halt den Namen, aber hier muss ich dann Abstriche in der Lesbarkeit machen.

Gruß
Karl