Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
|
x 2 ... du hast das Log vergessen. Ich würde aber mal in selbiges Log schauen. Falls die wiederholten Schreibvorgänge da nicht drinstehen, ist die Chance gut, dass das nicht zählt. Ich teste mal schnell per DIY-Modbus: Durchschnittszeit für die Umschaltschwellen von 24h auf 24h gestellt und dann in den Keller gegangen: Log-Eintrag zeigt diese und auch die vorherige Änderung beide mit Wert 24h. Zudem wurde wirklich geschrieben, weil die durchschnittliche AT AT [Außentemperatur] auf die aktuelle gesetzt wurde, was ja nur passiert, wenn man ändert (24->24 scheint eine Änderung zu sein). Von daher erzeugst du mindestens 336 Schreibvorgänge am Tag, also 122640 im Jahr. Nach 8 Jahren sind die 1Mio Zugriffe erreicht. Schau mal, ob die S das auch so macht. Wenn sie das loggt, dann sollte man das IMO dringend (!) lassen. Ob man UVR+CMI dazu bringen kann, diesen Unfug zu lassen, weiss ich natürlich nicht. Das bestärkt mich aber in meiner Sichtweise, sowas nur mit selbstgeschriebener Software zu machen... |
||
|
||
|
hab nachgesehen. im Änderungsprotokoll der Nibe stehen nun wirklich jede Stunde 7 Schreibvorgänge. Also wer mit UVR+CMI über Modbus TCP schreiben will, der sollte gewarnt sein! Ich werd das aber mal an TA melden. Die sind normalerweise eh bemüht. Ich denke schon dass die sich dazu bewegen lassen, dieses Dauersende-Intervall abstellbar zu gestalten. Interessanterweise kann man das bei Modbus RTU Ausgängen ausschalten. Hier gibts die Option: "im Intervall senden: ja/nein" Bei Modbus TCP-Ausgängen kann das hingegen nicht deaktiviert werden. |
||
|
||
|
Da bin ich voll deiner Meinung - Modbus TCP ist zum Glück ein recht einfacher Standard und gibt für eigentlich alle Sprachen passende libraries um damit zu arbeiten. Um schnell mal was auszuwerten würde sich pyModbus anbieten (https://pymodbus.readthedocs.io/en/latest/readme.html) Lesen der register sollte ja keine Probleme für die Lebenszeit der WP WP [Wärmepumpe] machen. Oder wird auch jeder lesende Zugriff irgendwie geloggt und in den Speicher geschrieben ... das wäre eher suboptimal |
||
|
||
|
Ich bin mir nicht sicher ob das ganze (zumindest für die S1255) wirklich so ein großes Problem ist. Das S1255 update file schaut so aus, als wäre das ganze Linux basiert mit einem UBIFS file system. Und das sollte eigentlich genau dafür optimiert sein schreibvorgänge auf FLASH speicher zu minimieren inkl. write cache und write counter pro block. Auch ein eigener Mechanismus, die Daten nicht gleich im Flash zu persistieren sondern z.b. nur beim runterfahren fände ich jetzt nicht so abwegig. Sind aber natürlich nur Mutmassungen meinerseits, kann mir aber fast nicht vorstellen, dass sowas heutzutage so low level implementiert ist, dass die Konfigurationsparameter wirklich ein 1:1 mapping in den flash speicher haben. Wollte mir das update image aber eh schon öfter mal etwas genauer anschauen... |
||
|
||
|
ich mag das auch nochmal genauer hinterfragen. die Aussage von Nibe war ja: NIBE schrieb: The EEPROM settings are stored has, according to the datasheet, a limit of 1 million writes per position. That may of course sound a lot but if you write every second that means only 11.5 days until the EEPROM position dies. So to answer the question, when calculating with 15 years of life the maximum would be 182 writes per day per setting Ich hab zwar wenig Ahnung von solchen Vorgängen, aber was mich hier stutzig macht, ist: - limit of 1 million writes per position - 182 writes per day per setting Verstehe ich das nur falsch, oder wären das eben 182 Änderungen pro Tag -> PRO PARAMETER ?? Also nicht 1 millionen Schreibvorgänge ingesamt, sondern 1.000.000 x für jeden verfügbaren Paramater?! Dann wäre das Ganze ja ohnehin wesentlich unkritischer?! |
||
|
||
|
Die Speicherzelle kann hierbei 1 million mal beschrieben werden, wobei mir diese Zahl extrem hoch vorkommt. Bei SSDs wird Wear Leveling eingesetzt, hierbei wird von der FW der SSD versucht die Schreibvorgänge auf alle Speicherzellen geichmäßig zu verteilen. Siehe dazu auch https://de.wikipedia.org/wiki/Flash-Speicher-Controller Es kommt halt darauf an wie intelligent der Schreibvorgang von Nibe implementiert wurde. |
||
|
||
|
ja, klar. jeder Parameter belegt eine Speicherposition und diese Position darfst du 1 Mio mal beschreiben. Aber was bringt das? Die UVR schreibt 7 mal die Stunde, also 168 mal am Tag. Somit hast du dein Flash nach 16,3 Jahren ruiniert, wenn auch nur an einer Stelle, aber hin ist hin. |
||
|
||
|
Naja das meinte ich ja. Ich versuche es ja nur zu verstehen... Pro Modbus-Ausgangs-Register wird bei mir aktuell 1x pro Stunde gesendet. Also 1x pro Stunde gibt es einen Schreibvorgang für den Parameter selbst und 1x pro Stunde einen Schreibvorgang fürs Änderungsprotokoll, richtig?! Aber das sind ja auch schon zwei verschiedene, separate Schreibpositionen, oder? Also bleibts bei 1x pro Position pro Stunde? Es sind zwar 7 Ausgänge, also 14 Schreibvorgänge pro Stunde, aber auch auf 14 verschiedenen Positionen?! Oder stellt sich das der Maschinenbauer wieder komplett falsch vor? |
||
|
||
|
Das ist eine HEIZUNG, kein Rechner Im Normalfall fährt die keiner runter, sondern sie geht beim Stromausfall oder so hart runter und muss danach weiter funktionieren. Wenn man ein Wear-Leveling UND einen hinreichend großen Flash hat, dann ja. Hier wird aber - zumindest bei der F - in einem extra EEPROM gespeichert. Der Flash scheint nur bei Updates angefasst zu werden, sprich, überschrieben. Das wiederum passiert vermutlich mit zwei Bänken im Wechsel, weil man ja per Tastenkombination in die jeweils vorherige Firmware booten kann. Vieles, was in "normalen" Rechnern keiner tun würde, macht man im Embedded-Bereich durchaus noch. Zudem landen sie nicht im Flash, sondern im EEPROM. Berichte mal über deine Erkenntnisse! Bei der "S" würde es mich nicht wundern, wenn man ein kleines Embedded Linux reingebastelt hat, das für Netz und GUI zuständig ist, während der eigentliche Embedded-Rechner wie bei der F irgendwas deutlich kleineres ist und davon separat ist. Dafür spricht auch, dass die Registeradressen der S bei Modbus TCP deutlich von denen der F via Modbus 40 abweichen. Ja, weil es kein Wear-Leveling zu geben scheint. Wenn da nicht das Log wäre. Meiner Meinung nach ist das als Ringpuffer realisiert, es dürfte also eine gewisse Anzahl (ich glaube, es waren 5 Seiten x ein paar Einträge) von Speicherplätzen belegen. Auf die wird ja auch jedes Mal geschrieben. Das sind dann ca. 40 oder so Plätze, aber das dürfte dann die Gesamtzahl der Schreibzugriffe auf 1 Mio x Anzahl der Logplätze begrenzen. Bei deinen 7 Parametern dürfte das nicht die Grenze sein, bei anderen Anwendungen vielleicht schon. Meist nennt man bei EEPROM etwa 100K Zyklen, was deutlich über den 1000-10000 Zyklen eines Flash liegt, aber eben unter einer Million. Müsste man mal recherchieren, ob man da Bausteine findet, die das aushalten. Wear Leveling würde ich nach der Aussage von Nibe nicht erwarten. Das stellst du dir richtig vor. Das Log dürfte dabei ein Ringpuffer sein, der quasi immer im Kreis beschrieben wird. Da du aber weniger Register schreibst als das Log groß ist, dürfte das Log nicht der begrenzende Faktor sein. Was genau passiert, hängt aber sehr stark von dem verwendeten EEPROM ab. Manche können nur blockweise schreiben, andere byteweise... andere wiederum haben unterschiedliche Granularitäten für Löschen (muss vor dem Schreiben passieren) und Schreiben. Fortsetzung folgt... |
||
|
||
|
Am besten wäre, wenn wir in das Datenblatt des verwendeten EEPROMs schauen könnten. Wenn ich mich recht an die entsprechende Diskussion erinnere, hatten wir vermutet, dass das EEPROM beim F-Modell im Display-Modul ist, oder? Von den Platinen weiter unten habe ich Fotos... aber noch nicht nach EEPROMs gesucht. Die sehen auch eher nach IO-Boards und weniger nach der gesuchten Rechnerplatine aus, aber das kann natürlich täuschen. Falls also jemand den Typ des verwendeten EEPROMs rausbekommt, wäre das vermutlich sehr hilfreich. |
||
|
||
|
Und dann extern auslesen, ein paar Stück nachkaufen und wenn es flöten geht, einfach tauschen 😁 |
||
|
||
| Hallo berhan, schau mal hier im Shop nach, da siehst du Preise und wirst sicher auch fündig. | ||
|
||
|
Wenn du mit Rechner einen PC mit Monitor und Tastatur meinst geb ich dir recht, das ist sie nicht ;) Allerdings haben aktuelle embedded systeme oft mehr von der Architektur eines solchen "Rechners" als die hier momentan diskutierte "klassische" Variante. Mit herunterfahren war nicht nur user interaktion gemeint, sondern allgemein das herunterfahren des systems. Das kann auch noch in gewissem maße gepuffert bei z.b. einem Stromausfall passieren. Aber mir ging es nur darum, dass es da schon durchaus noch ein paar layer dazwischen geben kann, auch im embedded bereich. Wie schon geschrieben, ich hab mich nur auf die S bezogen, da scheint sich die Architektur doch zu unterscheiden. In meinem Gedankenexperiment gibts keinen klassischen EEPROM (wenn du mit EEPROM byte-wise adressierbaren speicher meinst) sondern ein linux system auf FLASH-(EEPROM) (block-wise) Aber wie gesagt, das ganze war nur als Anregung gedacht, und es kann natürlich auch ganz anders gelöst sein. |
||
|
||
|
Ich hab jetzt mal über das update image von der S1255 geschaut: Verbaut dürfte ein TI AM3352 ARM cortex A8 (https://www.ti.com/product/AM3352) sein. Es läuft darauf ein Linux mit 4.9er Kernel (Wird wahrscheinlich auf dem TI SDK basieren). Darauf laufen diverse services, die 2 auffälligsten sind: noah-ui (GUI, in QT Qml geschrieben) noah-heatsystem (ob das wirklich der Regler ist, nur die kommunikation mit dem regler übernimmt oder ganz was anderes weiß ich nicht) dann noch diverse für modbus RTU, modbus TCP, logging... Interessanterweise auch für eine RestAPI, MQTT und Zigbee. Das einzige was ich herausgefunden habe wo anscheinend Daten abgelegt werden ist unter /var/noah/var auf einer ubifs partition. Dort landen zumindest logs und (was auch immer) in den sqlite datenbanken alarms.db3 und data.db3. Ausserdem wird es beim factory reset gelöscht. Einfacher wäre es wenn man live zuschauen könnte, aber der SSH zugang ist vernünftigerweise (leider ;) ) abgedreht. Also viel Kaffeesudlesen, aber gefühlt bleibe ich eher dabei, dass in der S Serie eher kein extra Prozessor für die Regelung verbaut ist sondern dass das auch auf diesem linux system läuft.
|
||
|
||
|
WP OS Hacking next 😈 und Overclocking 😈 |
||
|
||
|
@pedaaa gibt es da schon was neues? Da ja bei mir die WW WW [Warmwasser]-Automatikregelung nicht funktioniert und der Service-Mann erst am 20.11. vorbeikommt (ohne dass das was bringen würde) überlege ich, ob ich das erst mal in der UVR selbst schreibe und durch verändern der Pumpendrehzahl über Modbus die WW WW [Warmwasser]-Vorlauftemperatur so hinstelle, dass sie eben nicht über 50°C hinausgeht... |
||
|
||
|
jein, laut Telefon-Aussage sehen sie das Problem ein, und es SOLL irgendwann ein Update geben, wo dann das "Pollen" also das dauerhafte Senden im Intervall ein/ausschaltbar sein wird. Ist aber nicht grad mit hoher Priorität versehen. Ich bleib aber dran und bleibe nervig 😉 Wenn das hier mehrere Leute brauchen, bitte um Info, dann kann ich evtl. etwas mehr Druck machen. |
||
|
||
|
Update zu den Modbus-TCP Schreibzyklen bei der S1155. Mein Schriftverkehr mit Nibe NES Aftersales Service: I am using a NIBE S1155-6 PC EM 3X400V. serial No: ***** I am using your included Modbus TCP interface for monitoring and controlling some parameters. As I now already have approx. 190 write operations per day, in future maybe even more, I wonder if this could possibly lead to a problem?! Is there a danger of damaging the internal storage by too many write operations to configuration registers such as hot water mode or GP1 pump speed using Modbus TCP? If so, what are the limits? Hello Peter, We have not tested the max limit for Modbus commands during a day, but we can assure you that 190 commands per day is no problem. Best regards, Thanks for the quick answer. 190x per day would be 1.387.000 times in 20 years for example. but could you please clarify: Is this 190 per day limit meant “per write position”? Or meant “in total”? Is it like this: it’s no problem to change the GP1 heating pump speed (register 218) 190x per day. And also change hot water pump speed (register 217) 190x per day. or like this: if changing heating pump speed 100x per day. Its then only allowed to change hot water pump speed 90x per day, so not to exceed 190 writes in total? Hello Peter, Do you really have a need for changing information in the system so often?? Most of these things are take care of by the built-in control system and that system is making changes all the time so changes from the outside (via Modbus) should not damage the unit in any way. The only thing that can happen is if you send too many commands at the same time, then there will be a delay in the system. Best regards, Hello, I change it that often, because the Auto-Mode for Pump speed does not work that good for my house. So, I control pump-speed (during heating) externally by Modbus TCP based on outside temperature. This provides apprx. 20-100 changes on register 218 per day. And, I tried a PID-controller function for changing pump speed during hot water production (register 217). This works perfect, but produces additional apprx. up to 200 changes per day. So, this high number of changes let me worry, that it might cause the flash memory, EEPROM or similar to kill itself after exceeding the max. allowed number of write cycles. (e.g. Tesla had similar problems with such memories in their electric cars) So, if you confirm me, that it is no problem, I will surly continue with this many write cycles, because my S1155 heat pump now works perfect with this strategy. But if this high Modbus-write numbers could potentially kill my heat pump EEPROM, I need to think of other solutions. Many many thanks! Peter Hello Peter, This should not be a problem, we have not seen any problem with this so far. Best regards, So...... Was ist das jetzt?! Ein Freifahrtsschein für uns, um munter per Modbus-TCP unbegrenzt Befehle an die S1155 zu schicken?! Alles easy und keine Probleme? Oder will sich Nibe damit einfach nicht genauer beschäftigen, weils eh egal ist. Bis es zu einem Problem führt, ist die WP WP [Wärmepumpe] ohnehin sicher schon aus jeder Gewährleistung draussen?! Was meint ihr? |
||
|
||
|
Typische Entwicklerantwort. Du wirst der erste sein, der so häufig die Register ändert. Falls das EEPROM in x Jahren (x vermutlich über 5) ausfallen wird, bist Du der erste :) Ich schätze Garantie wirste darauf eher nicht haben, könnte ja auch aus einem anderen Grund defekt gegangen sein, das lässt sich sicher nicht herausfinden. |
||
|
||
|
Klar, bis bei den 2 Trotteln, die mit der Müllregelung nicht leben wollen und sich was eigenes über UVR und Modbus programmiert haben, die Steuerung die Hufe hochreißt, sind ja locker 10 Jahre ins Land gegangen und dann zahlst du deine neue Steuerung selber... Eine belastbare Aussage ist das ja eh nicht, geschweige den ein Garantieversprechen 😜 Und dass sie bisher da kein Problem sehen, wenn die WP WP [Wärmepumpe] erst 1 Jahr auf dem Markt ist, wenn wunderts...die haben bisher ja nicht mal bemerkt, dass die Regelung da ein grundsätzliches Problem hat...😣 |
||
|
||
|
Ich weis ist offtopic, aber wenn du da ja wirklich sehr schnell konstruktive Antworten bekommst hast du da denn auch versucht die Probleme genau zu schildern und sie darauf anzusprechen wieso sie das nicht selber so umsetzen können in ihrer Steuerung? Ich denke mir mit einer guten Erklärung wie das umzusetzen ist und genauen Daten warum das so gemacht werden muss kann man sicher auch dort etwas bewegen. |
||
|
||
|
hab ich natürlich schon gemacht, was glaubst du denn 😉 Bin ja ein nerviger Kunde. 😇 Aber halt auch sehr daran interessiert das Produkt zu verbessern. Leider wird man bei sowas aber oft ausschließlich nur als nervig angesehen, anstatt als Hilfe. Damals kam (von aftersalesservice@nibe.se) auch eine wirklich erstaunlich detaillierte Rückmeldung mit diesem letzten Satz: (da hatte ich das Problem geschildert, dass die Auto-Pumpendrehzahl bei WW WW [Warmwasser]-Zielladung keine einstellbaren min/max. Limits hat) "Over the years changes and improvements have been done to both the pump and the compressor controls to improve our functions and we are always looking at ways to optimize our controls. So we do thank you for you input which we will take into consideration" Ich find das wirklich gut, und sowas sieht man definitiv nicht bei allen Firmen. Nur leider fehlt mir trotzdem der Glaube, dass das vom Aftersales wirklich irgendwann zurück in die Entwicklung zu den Programmierern wandert... |
Dieser Thread wurde geschlossen, es sind keine weiteren Antworten möglich.