Hallo, also ich hab nochmal einen Test gemacht bezüglich dem langsamen schalten der Ausgänge vom pcf8574.
Ich hab nochmal an einem Raspberry Pi Stretch neu installiert mit frischem IP-Symcon.
Jedoch konnte ich zu dem vorherigen System, was eigentlich gleich war keine Verbesserung erzielen. Normal Zustand alle Ausgänge schalten 12 Sekunden. Hoch getaktet 9 Sekunden.
In „TOP“ ist zu sehen das IP-Symcon von normal 3-5% cpu last hoch geht auf knapp 90%.
Jetzt hab ich das ganze mal mit einem PI3 ausprobiert. Wenn ich hier das gleich Skript nutze um die Kanäle nacheinander anzuschalten, brauch das Skript knapp 2 Sekunden für die 8 Kanäle. Also wesentlich schneller.
Verstehe aber dann nicht wie es auf einem PI der ersten Generation zu keiner Verzögerung kommen sollte wie von dir angesprochenen.
Werde wohl einen PI2 zuerst mal für mein Vorhaben nutzen und schauen wie da die CPU Lasten sind.
Da ich damit meine Heizung regeln möchte (Pumpensteuerung, PID Regler, Solaranlage, Heinzkurvenberechnung) bin ich dort nicht auf Sekunden angewiesen.
Eine eigene RTC gehört für mich eigentlich in jeden Smarthome-Server. In vielen Industrieanlagen ist es sogar Pflicht eine stabile und genaue Zeit bereit zu stellen (z.B. aus einer Kombination aus Quarzoszillatoren, Funk wie GPS oder DCF77 und auch über Internet/NTP).
Nur NTP über Internet reicht aber oft nicht aus. Z.B. bei einem Stromausfall sind die lokalen Sensorsysteme (bei IPS wohl oft ESP8266 oder PIs) oft schneller UP als die WAN Router (VDSL-Vectoring 17a bis zu 10 min) und solang sind die erfassten Werte zeitlich Schrott.
Ein anderer Fall ist ein autarkes System mit IPS, welches nur sehr selten (z.B. GSM) oder fast nie mit dem Internet verbunden ist (z.B. im Schrebergarten zur Erfassung der Bodentemperatur und Feuchte).
Ich selbst bevorzuge bei meinen Designs immer Systeme, die eine eigene RTC besitzen und bei Internetverbindungen über Internet zyklisch immer auf den neuesten Stand gebracht werden. Bei Windows-PCs ist das meist gegeben (wobei da manche RTCs bis zu 5 min am Tag weglaufen), bei den PIs schauts da sehr schlecht aus.
Der DS3231 ist übrigens mit seinem temperaturkompensierten Quarzoszillator genial, der läuft über Wochen nur wenige Sekunden davon. Wenn du den schon im GeCos-Modul implemtiert hast, wäre es super den auch im PIGPIO-Modul zu integrieren. Beim PCF8583 würde es zumindest nicht schaden.
In meinem Heimnetzwerk arbeitet übrigens mein IPS-Windows-Server mit seiner eigenen RTC, die alle 15 Minuten gegen NTP synchronisiere (Software NetTime NetTime - Network Time Synchronization Tool siehe Bild unten). Max. Jitter so -19ms bis 22ms, für daheim reichts, für Industrie 4.0 schon lange nicht mehr. Bei uns in der Firma muessen wir weltweite Fertigungsstrassen im 100 us Bereich in Sync halten.
…den DS3231 gibt es günstig als Breakout mit Batterie…[emoji6]
Wir würde das laufen?
Das Modul würde regelmäßig ein NTP im Internet Anfragen und den DS3231 mit der richtigen Zeit setzen bzw. synchronisieren…
Wie bekommt man denn per Modul die Zeit vom DS3231 auf den Pi?
wenn man darüber genauer nach denkt, wird es wirklich etwas komplexer. Ich hätte mir das ungefähr so vorgestellt.
PI startet
Prüfung ob NTP server und Internet verfügbar sind
wenn nein über I2C die Zeit vom DS3231/PCF8583 holen und zwischen speichern
Gespeicherte Werte mit hwclock --set --date=„2018-02-05 22:30:00“ als Systemzeit setzen
Im laufenden Betrieb Zeit über NTP lesen (wenn möglich) und Systemzeit setzen und über I2C die RTC auf den neuesten Stand bringen
Für den Erststart ohne Internet wäre wohl eine Zeitsetzfunktion nötig.
Ob man hwclock (braucht normal sudo) in einem Modul starten kann, weiss ich nicht. So tief hat paresy in Lübeck bei der Modulentwicklung nicht referiert
@Hollowman: mache mal Bitte ein Update und prüfe mal, ob der Delay beim PCF 8574 sich reduziert hat…
@Bernd: Das wäre doch aber doch nur an dem IPS-Raspberry Pi selbst sinnvoll, oder? Bei den anderen spielt es doch eigentlich keine Rolle welche Zeit die gerade haben, sind doch eigentlich nur „intelligente Messwertaufnehmer“?
Wie verhält sich den der Raspberry Pi, wenn er nach dem Start die Internetverbindung verliert? Verliert er dann auch die Uhrzeit?
Was war passiert? Hatte diverse Änderungen vorgenommen, im Webfront hin- und hergeschaltet - glücklich gewesen…stellte dann quasi gleichzeitig mit Dir fest: die ganze Zeit ein anderes Device benutzt…
Hi, danke für die schnelle Bearbeitung.
Also jetzt schalten die Ausgänge viel schneller. Bin jetzt auf 6 Sekunden Laufzeit gekommen von den ursprünglichen 9 Sekunden (da der PI noch übertaktet ist).
Jedoch was jetzt auffällig ist wenn ich alle Ausgänge nach und nach durchschalte in einem Skript, Leuchten pro Schaltbefehl alle anderen LED’s auf dem Relaisboard ganz kurz schwach auf. Der Ausgang selbst wird von den schwach
leuchtenden LED’s nicht geschaltet, erst dann wenn er auch im Programm dran kommt.
Das war vorher nicht gewesen. Stören tut mich das selbst jetzt nicht, da es nur Visuell bisher ein Manko ist.
falls Du die Kombination der Schaltzustände in Gänze kennst, dann kannst Du mit der Funktion „SetOutput($Value)“ ja auch alles in „einem Rutsch“ schalten. Vielleicht hilft das…
klar, am meisten Sinn macht eine genaue/abgesicherte Uhrzeit an einem zentralen PI mit installiertem IP Symcon. Damit werden die Zeitstempel lokaler Variablen oder auch welche die über JSON-RPC gesetzt werden immer richtig gesetzt.
Natürlich kann diese zentrale Zeit auch über lokal installierten NTP-Server für die anderen PIs über deren NTP-Client genutzt werden. Das ist aber vollkommen unabhängig von IP Symcon und kann jeder eigenständig handhaben.
Zum Verhalten von PIs nach erfolgreichem booten und setzen der lokalen Zeit über NTP und anschließendem Verlust der Internetverbindung kann ich nur vermuten. Ich nehme an, dass die Uhrzeit vom Systemtakt abgeleitet weiter läuft. Die Genauigkeit ist dann vermutlich deutlich reduziert.
die Integration des DS3231 selbst wird nicht das Problem sein - möglicherweise aber das „Drumherum“. Deswegen sollte man sich zumindest einigermaßen über das Prinzip im Klaren sein Der DS3231 ist ja auch auf der GeCoS-Servermodul von GeDaD drauf, Code zum Abfragen/Setzen und hier in ein Modul „kippen“ wäre also im Wesentlichen Copy&Paste…
Ich hänge noch etwas mit dem PCF8583, zählen funktioniert, mit den Interrupts habe ich da noch Herausforderungen. Habe inzwischen sogar an NXP selbst geschrieben, mal sehen ob die zur Lösung des Rätsels beitragen können…
Habe hier auch noch zwei verschiedene MCP23017 Module herumliegen, die gelötet und ausprobiert werden wollen…
Dem SSD1306-Display konnte ich bisher leider auch noch kein „Hallo Welt!“ entlocken…
wenn es dir ohne grossen Aufwand möglich wäre, den DS3231 in das PIGPIO-Modul zu integrieren, könnte ich mal die verschiedenen Möglichkeiten NTP/Server/Client auf dem PI ausloten (Windows-PCs haben ja meistens RTC bereits im Bauch). Ideen mit eventueller zusätzlicher GPS-Integration (nicht Koordinaten, genaue Zeit) habe ich da viele.
Allgemeiner Hinweis: Joan hat PIGPIO in der aktualisierten Version 65 zum Downloadzur Verfügung gestellt.
Diese soll einige der bekannten Fehler beheben, habe es selbst noch nicht getestet…
Aktualisiert und läuft prinzipiell, I2C mit BME680 auf dem PIzeroW führt jetzt innerhalb von Minuten zum Abschuss. So ist das bei mir überhaupt nicht mehr zu gebrauchen. Nur mit 1wire läuft der Daemon wie bisher ohne Absturz dauerhaft.
Hast du bei den Luftdrucktrends gearbeitet? Die werden nur bei der Initialisierung auf 0,0 gesetzt und dann nie mehr aktualisiert. Das war seit einiger Zeit auch mit der V64 schon so.
Nein, die Trenddaten liefert doch der BME, zumindest beim Wiffi macht Eugen das so.
Gerade aktiviert, dann wird auch etwas aktualisiert. Aber eigentlich dürfte das nicht relevant sein, da die Trenddaten nicht aus dem Logging kommen sollten.
