naja, in der cloud zahlt man eigentich nicht für ingress traffic.
Aber auch unabhängig von der Menge der Daten - wie bei den mppt - halte ich das Datenformat als JSON key-value-pairs für zu aufgebläht und für die Kommunikation nicht gut genug optimiert.
hallo,
das json-datenformat ist nur dann ein problem, wenn man die daten z.B. an iobrocker schickt und dort in einer flux-db speichern laesst. da funktionieren die ganzen mechanismen der datenbank naemlich nicht. die sind naemlich auf zahlenwerte ausgelegt und nicht auf strings!
es mag zwar sein, dass man fuer ankommenden traffic nicht bezahlen muss. das ist aber auch nicht das wirkliche problem, das problem ist der bedarf an rechenzeit, um die daten zu sortieren und zu verarbeiten und die muss man leider bezahlen und wenn da pro user das 5-30 fache faellig wird, duerfte sich das schon erheblich bemerkbar machen!
tschuess
VRM verwendet die Mqtt Daten nur (selektiv) während man in der Realtime Ansicht des Dashboards ist.
Alle Langzeitdaten werden über eine andere Machanik ans Portal übertragen und zuvor bereits aggregiert.
Brauchst dir also um die Rechnung keine Sorgen machen 
hallo,
ob das portal die daten nur selektiv verarbeitet oder nicht, spielt hier keine rolle. die frage is, ob die ankommenden daten zuerst gefiltert werden oder zuerst gespeichert werden und dann nicht alle verarbeitet werden.
werden sie zuerst gefiltert, dann ist das kein problem, werden sie aber zuerst gespeichert und dabei sortiert, dann ist das ein problem!
abgesehen davon, ich muss die rechnung ja nicht bezahlen, also kann es mir eigentlich egal sein. ausserdem nutze ich das vrm auch nur als umweg um mit victronconnect oder veconfig auf die geraete zuzugreifen, ich bin also nicht darauf angewiesen!
ich habe meine daten auch alle in einer eigenen datenbank! und da sind nicht nur die daten fuer ein jahr, sondern fuer die ganze zeit, seitdem ich die daten erfassen kann und das sind fast 10 jahre!
tschuess
hallo,
wenn du darin immer noch kein problem siehst, betrachte es einmal von einer anderen seite: dem internetzugang!
meine dsl-leistung waere mit der aktuellen vrm-datenrate zu ca. 25% ausgelastet und jede minute 2 mal fuer ca. 5-10s verstopft. eine noch langsamere dsl-verbindung waere dementsprechend staerker ausgelastet, eventuell sogar bis zu dem punkt, dass nicht mehr alle daten uebertragen werden koennten!
bei mobilem internetzugang muss man ja auch noch fuer das datenvolumen bezahlen. das waere dann auch schnell aufgebraucht und bei einer drosselung auf ca. 400 kBit oder weniger, waere die leistung voellig ueberlastet.
mal abgesehen davon, dass man schon bei einer verzoegerung von 5-10s auch nicht mehr wirklich von einer echtzeit-kommunikation sprechen kann!
tschuess
Also du übertreibt hier schon maßlos
Dein Internet wäre mit 450 KB alle 30s zu 25% ausgelastet? Hast du noch ein 56k Modem?
Auch sind die von dir genannten Performance Probleme beim Datenempfang wohl eher ein bisschen hausgemacht - Wenn ein kleiner Single-Core Broker - der nebenher noch etliche andere Tasks verrichtet - und dabei auf 5-10% CPU Auslastung kommt deinen Client in die Knie zwingt - dann ist das Problem eher Client-Seitig zu suchen…
Naja, wie dem auch sei. Probiers mal mit dem supress-republish payload für das keep-alive, das sollte dein Problem lösen.
Drum läuft das ja von seitens Victrun nur incrementel, und nur während der Realtime-Ansicht.
Dass du jetzt lokal den Broker 24/7 am leben hältst und alle 30s einen full-publish triggerst ist ja deine Entscheidung, erfreue dich doch einfach, dass es die Möglichkeit hier tief in Systemvorgänge einzugreifen überhaupt gibt.
hallo,
es geht nicht um 450 kB, sondern um 4,5MB alle 30s und das ist nur eines meiner gx-geraete! alle zusammen duerften also wohl eher auf 15-20 MB/minute kommen und ich habe nur ca. 1,3 MBit upload, also maximal etwa 150 kB/s! das verstopft also sehr wohl die leitung!
allerdings wollte ich, heute morgen, nocheinmal die transferrate messen und rate mal, was passiert ist! victron setzt jetzt vom vrm aus den keepalive, was dann zur folge hat, dass ich beim verbinden nur noch aenderungen bekomme, aber nicht mehr alle datensaetze!
ich habe inzwischen mein programm fuer den update der mqtt-daten so geaendert, dass es den keepalive wieder loescht, so dass ich wenigstens wieder einmal alle daten bekomme!
die feine art ist das aber auch nicht, denn ich brauche alle daten mindestens einmal, sonst funktioniert das nicht richtig!
also scheint wohl doch jemand bei victron meine mail oder diesen beitrag im forum gelesen zu haben!
nur auf meinem venus-gx treibt das seltsame blueten, da bekomme ich auf einmal garkeine daten mehr, sondern nur noch sowas:
N/0c1c57003990/system/0/Connected {“value”: 1}
R/0c1c57003990/system/0/Connected (null)
N/0c1c57003990/system/0/Connected {“value”: 1}
R/0c1c57003990/keepalive { “keepalive-options” : [“suppress-republish”] }
R/0c1c57003990/system/0/Connected (null)
N/0c1c57003990/system/0/Connected {“value”: 1}
R/0c1c57003990/system/0/Connected (null)
N/0c1c57003990/system/0/Connected {“value”: 1}
R/0c1c57003990/system/0/Connected (null)
N/0c1c57003990/system/0/Connected {“value”: 1}
also wieder ein problem, das ich abfangen muss oder zumindest einen firmware-update einspielen.
nach dem firmware-update funktioniert das ganze auch wieder mit dem venus-gx.
allerdings weiss ich nicht, wie viele user den mqtt-server abfragen und wegen der aenderungen auch probleme bekommen!
tschuess
du schriebst oben 450xxx B/s - das sind 450 kB, nicht MB.
Das tut VRM schon seit Jahren…
… und das ist genau das Standard-Verhalten seit Jahren. Als ankommender Client, der sich in einen “laufenden” Mqtt einloggt kannst du daher einen Full-Publish requesten, indem du einen leeren Payload an das Seriennummern-Topic schickst.
Das “R” Topic brauchst du nicht zu abonnieren. Das ist für Republish-Anfragen gedacht, und genau das passiert hier:
R/0c1c57003990/system/0/Connected (null)
Irgendein Client (VRM?) fordert ein Refresh des Connected-Werts an.
N/0c1c57003990/system/0/Connected {“value”: 1}
Das System reagiert und publisht den Connected-Wert erneut.
Ebenso kannst du W/ ignorieren. Das ist für Schreib-Anfragen, nicht alles was da gepublisht wird, wird aber auch vom System übernommen. Das hängt davon ab, ob der Wert innerhalb des gültigen Bereichs lag, und ob der Pfad ansich überhaupt beschreibbar ist.
Wenn ein Schreibzugriff als “gültig” übernommen wird, folgt danach direkt ein Publish unter N/
Drum sollte dein Script:
- Verbindung aufbauen
- Publish:
R/0c1c57003990/keepalive { null } - Erhalte ALLE Daten.
- Publish
R/0c1c57003990/keepalive { “keepalive-options” : [“suppress-republish”] }alle X Sekunden. - Erhalte kontinuierlich inkrementelle Daten.
Natürlich kann es passieren, dass sich zwischendurch ein anderer Client verbindet und ebenfalls einen Full-Publish anfordert - damit muss dein Script dann eben umgehen können. Mqtt ist und bleibt ein zentraler Broker und keine “Request/Response”-API für einen einzelnen Client.
Wenn dich das stört, kannst du das nur in deinem Skript abfangen, z.b.:
R/0c1c57003990/keepaliveebenfalls abonnieren.- Sobald du dort eine
nullbekommst, gehst du in einen “Pause-Modus”. - Sobald du unter
N/xxxxxxxxxxx/full_publish_completedeinen Wert bekommst, wechselst du wieder in den “Nicht-Pause-Modus”.
1 Like
hallo,
ich habe nie etwas von 450 kB oder 450000 B/s geschrieben, das warst du selbst!
mein script habe ich auch schon entsprechend angepasst, so dass es inzwischen auch mit der grossen datenmenge zurecht kommt. ich lasse einfach alles weg, was ich nicht brauche und es ist auch sichergestellt, dass ich mindestens einmal alle daten bekomme!
und ich kann dir garantieren, dass der keepalive vom vrm nicht gesetzt wurde. das waere mir naemlich beim abruf aller daten mit dem mqtt-explorer aufgefallen. ausserdem waere es dann nicht alle 30s zu diesem datenburst gekommen! im gegensatz, miut haetten daten gefehlt!
und glaube mir, bei den vielen versuchen, dieses problem zu loesen, waere es mir auf jeden fall aufgefallen, wenn das vrm den keepalive bereits vorher gesetzt haette!
einen pause-modus gibt es bei mir nicht, die verbindung steht dauerhaft und den full_publish_completed werde ich noch in die auswertung mit einbinden. momentan setze ich den keepalive wert zuerst mehrmals auf “” und danach dann wieder auf den richtigen wert, um sicherzustellen, dass ich alle daten habe. aber ich werde da eine datenbank-abfrage einbauen, die das prueft und dann schon vorher auf den richtigen keepalive wechseln.
tschuess
1 Like
hallo,
neues problem wegen dem mqtt-server:
da ich bestimmte daten beim verbindungsaufbau nicht mehr automatisch bekomme, sich die daten aber garnicht oder nur selten aendern, brauche ich jetzt jedesmal 2 mqtt-nodes. eines um den wert zu empfangen und eines um ihn abzurufen.
oder ich muss das auf einem anderen weg steuern, allerdings ist dann ein 3. system mit eingebunden, was ich ja eigentlich vermeiden will!
als wieder zusaetzlicher programmieraufwand oder ich muss dafuer sorgen, dass regelmaessig wieder alle daten gesendet werden und damit waere dann das, was victron im vrm gemacht hat, auch wieder hinfaellig!
tschuess