Aus meiner Sicht wäre die Nutzung des API von pi-hole https://discourse.pi-hole.net/t/pi-hole-api/1863 besser.
Zum einen muss man dann nicht mit Benutzerrechten auf Rechnern kämpfen und zum anderen geht der Zugriff natürlich auch remote.
Im konkreten Fall wäre das dann ein
api.php?enable&auth=183c1b634da0078fcf5b0af84bdcbb3e817708c3f22b329be84165f4bad1ae58
node 8.11 ist böse
bitte mindestens auf 8.12, besser auf 8.15 updaten `
Danke für diesen Hinweis.
Aber ist dies ursächlich für mein Problem oder löst das nur ein Problem mit dem Speicherfresser?
Ein echtes Speicherproblem habe ich nämlich (noch) nicht.
Ich habe gestern wieder einmal ioBroker aktualisiert.
Dazu habe ich zum einen den Javascript-Adapter auf die neueste Version gebracht (4.0.12).
Dann habe ich auch den Admin versucht zu aktualisieren (von 3.5.10 auf 3.6.0). Beim Admin hat die Aktualisierung nicht geklappt.
Jetzt sehe ich im Admin keine Skripte mehr. Die Skripte sind aber noch vorhanden und laufen weiterhin ohne Probleme (laut deren Ausgaben im Logfile).
Folgendes habe ich bereits versucht:
Neustart von ioBroker
Reboot des Pi
Nochmalige Installation Admin (hat jetzt den Admin auf 3.6.0 gebracht)
Bis auf die jetzt erfolgreiche Aktualisierung des Admin gab es jedoch keine Änderung des eigentlichen Problems.
Wie kann ich den Admin dazu bringen, mir die Skripte wieder anzuzeigen?
Meine Konfiguration:
Pi 3B+
Node.js v8.11.4 (Es gibt eine neuere Version: v8.15.0)
NPM 6.4.1
system.adapter.admin : admin - v3.6.0
system.adapter.hm-rpc : hm-rpc - v1.9.6
system.adapter.hm-rega : hm-rega - v2.2.1
system.adapter.web : web - v2.4.1
system.adapter.vis : vis - v1.1.8
system.adapter.history : history - v1.8.5
system.adapter.flot : flot - v1.9.2
system.adapter.javascript : javascript - v4.0.12
system.adapter.rpi2 : rpi2 - v1.0.0
system.adapter.vis-hqwidgets : vis-hqwidgets - v1.1.2
system.adapter.parser : parser - v1.0.7
system.adapter.systeminfo : systeminfo - v0.2.2
system.adapter.info : info - v1.0.2
system.adapter.deconz : deconz - v0.1.1
system.adapter.luftdaten : luftdaten - v0.0.6
Was mir noch aufgefallen ist: Ich habe laut Ausgabe einen deconz-Adapter in einer sehr alten Version(aktuell scheint 0.3.0) am Laufen, den deconz-Adapter sehe ich im Admin aber nicht. Da ich den Adapter auch nicht benötige, wüsste ich auch nicht, dass ich ihn installiert habe.
Aus meiner Sicht wäre die Nutzung des API von pi-hole https://discourse.pi-hole.net/t/pi-hole-api/1863 besser.
Zum einen muss man dann nicht mit Benutzerrechten auf Rechnern kämpfen und zum anderen geht der Zugriff natürlich auch remote.
Im konkreten Fall wäre das dann ein
api.php?enable&auth=183c1b634da0078fcf5b0af84bdcbb3e817708c3f22b329be84165f4bad1ae58
Meint ihr das der rasberry und iobroker damit klar kommt? `
Das kommt darauf an.
Der RAM dürfte dann schon extrem knapp werden. Das führt dazu, dass geswappt wird. Und das ist zum einen extrem langsam und zum zweiten nicht der SD-Karte zuträglich.
Ich persönlich habe für die beiden Anwendungen je einen PI im Einsatz.
Damit habe ich keine zusätzliche mögliche Fehlerursachen durch Inkompatibilitäten der beiden Softwarepakete.
Bei dem Preis für einen PI kann man das auch kostentechnisch verkraften.
Zum Mitschreiben müsste ich allerdings entweder schon die Sonoff einbauen und anhand des Verbrauchs mitschreiben oder irgendwas an die Regler basteln (?). `
Es wird kaum eine andere vernünftige Lösung geben (außer du möchtest dich daneben setzen und selbst mitschreiben).
Es gibt zwei Lösungsansätze, die Schaltung direkt auszuwerten:
Spannungsmessung oder
Strommessung
Je nach nachdem, wie deine konkrete Verschaltung aussieht (feste Verdrahtung, Steckverbindung, Hilfsspannung mit 230V oder Kleinspannung, …) ist das mehr oder weniger einfach umzusetzen.
Sofern Arbeiten an 230V notwendig sind, die über das Ziehen und Stecken eines Schukosteckers hinausgehen, solltest du daran jedoch nur etwas machen, wenn du auch die Vorschriften der VDE0100 kennst umd umsetzen kannst.
Auffällig ist eben, dass ich vor IObrocker niemals derartige Probleme hatte. `
Die Kommunikation zwischen CCU und den Aktoren und Sensoren läuft über Funk. Und da ist dann alles möglich, was solche Fehler bringen könnte.
ioBroker selbst halte ich bei dieser Fehlermeldung für nicht ursächlich.
Was wurde denn alles geändert seit der Umstellung?
Kannst du eine Skizze/Beschreibung deiner gesamten Konfiguration und Änderungen durch/nach ioBroker posten?
Welche CCU-Programme wurden durch welche ioBroker-Skripte ersetzt?
Laufen diese auch wirklich noch genau in den gleichen Zeitslots wie früher auf der CCU?
Wurden Direktverknüpfungen durch ioBroker ersetzt?
Wobei die Regler an der Wand auch nur "dumme" Bimetalle sind `
Damit kann man doch schon einmal das heutige Regelverhalten aufnehmen: Einfach einmal die Schaltungen der Bimetalle "mitschreiben".
Denn diese Schaltungen müsste der SW-Regler dann nachbilden.
Zum Thema Überschwingen: Ich vermute, dass hier die Thermostate einen entsprechenden Offset haben, der dann vor Erreichen des Sollpunkts bereits abschaltet. Und ja, das wird natürlich nicht immer punktgenau klappen.
Daher könnte es auch noch von Interesse sein, die Zimmertemperatur mit zu protokollieren. Dann sieht man zum einen das momentane Regelverhalten und die Qualität des einfachen Bimetall-Thermostats. Und man kann später leicht vergleichen, ob der Softwareregler besser arbeitet (z.B. in den Übergangszeiten).
Die "Steuerung" der Fußbodenheizung ist natürlich möglich.
Hier muss zunächst die Regelstrecke aufgenommen werden.
Danach kann man die Parameter entsprechend berechnen und dann weiter optimieren.
Beim PID-Regler gibt es drei (An-)Teile:
P: Den Proportionalanteil. Hier wird der Regler linear entsprechend dem Abstand zwischen Soll und Ist "aufgedreht"
I: Der Integralanteil: Hier wird geprüft, ob sich bei "aufgedrehtem" Regler auch das Ist dem Soll annähert. Falls nein, wird der Regler "aufgedreht"
Differentialanteil: Hier wird der Regler zunächst übersteuert (also zu weit "aufgedreht") und dann wieder zurückgeregelt.
Lästig bei Fußbodenheizungen ist insbesondere die lange Verzögerung zwischen "Heizen" und der Erhöhung der Raumtemperatur. Dies heißt, dass der Regler sehr langsam (im Sinn des Regeltakts) läuft.
Die von Dir erwähnte "Taktung" ist eine mögliche Vorgehensweise zur Vermeidung des Überschwingens aufgrund der langsamen Antwort des Regelkreises.
Bei der Heizung selbst stellt sich zusätzlich die Frage, ob du proportional regeln kannst ("Teilheizen") oder ob die FB-Heizung nur an- und ausgestellt wird.
Anfänglich hatte ich den Adapter als Schedule implementiert.
Das hatte auch problemlos geklappt und vermeidet ein solches Problem.
Allerdings kann ich dann den Adapter nur schwer steuernd nutzen (Absetzen von Kommandos).
Dazu muss er einfach als Daemon laufen, um auf Ereignisse in vernünftiger Zeit reagieren zu können.
Ich vermute, dass dieses Anforderung sicher viele Adapter haben: Reaktion auf Kommandos und (mehr oder weniger) zyklisches Lesen von Daten.
Heute habe ich meinen Adapter einmal einem kleinen Stresstest unterworfen und den Speicherverbrauch beobachtet.
top sagt mir, dass in einer Stunde der unter VIRT gemeldete Speicher um ca. 1MByte gestiegen ist (von ca.130.000 auf 131.000).
Das ist natürlich unschön und ich würde gerne die Ursache finden und beheben.
Der Adapter läuft als Dämon und pollt zyklisch externe Werte.
Dazu nehme ich folgendes Konstrukt (habe ich aus dem Solarlog-Adapter entnommen)
adapter.on('ready', function() {
adapter.subscribeStates('disablePeriod');
adapter.log.debug('[INFO] Starting adapter');
let pollingTime = (adapter.config.pollCycle * 1000) || 300000;
adapter.log.debug('[INFO] Configured polling cycle: ' + pollingTime);
if (!polling) {
polling = setTimeout(function repeat() { // poll states every [30] seconds
main();
setTimeout(repeat, pollingTime);
}, pollingTime);
};
});
Meine js-Erfahrungen sind nicht so wahnsinnig toll ausgeprägt.
Wenn ich dieses Konstrukt am Ende betrachte, so ist das doch ein rekursiver Aufruf, der zunächst nach dem Timeout main() aufruft und danach wieder nach dem Timeout sich selbst und danach nach dem Timeout …
Ansonsten wäre das Programm ja auch nach kurzer Zeit am Ende angelangt.
Wenn das so wäre, dann kann ich mir den Effekt des wachsenden Speicherbedarfs natürlich erklären.
Liege ich da richtig?
Falls ja, wie macht man diese Poll-Schleife denn "richtig"?
