Hi,
das kann eigentlich nicht sein.
Alle drei Boxen sind bis auf die IP Adresse im IPS gleich konfiguriert.
Ich habe drei UDP Stockets, die bis auf die IP Adresse der Wallbox von deinem Box gleich konfiguriert wurden.
Portmapping kann ich nicht machen, da es ein VPN ist, ist es ja sogesehen das gleiche Netzwerk - also ohne NAT. Durch den VPN Tunnel kann jede IP Adresse auf beiden Seiten jede Adresse auf der anderen seite auf allen TCP und UDP Ports erreichen. Eigentlich schon fast wie ein normales Netzwerk, nur das ich 8ms Latenz habe.
Welche IP Adresse ist denn bei dir gleich? 10.12.12.37 ist mein IPS. und 10.12.50.1 , 2, 3, sind die Wallboxen.
da diese daten so gleich sind, vermute ich jetzt mal, das beides die Box 2 ist.
Dann kannst du bitte meinen letzten Post ignorieren.
Trotzdem ist das ja schon merkwürdig, neben der Systemmeldung, das die Socket nicht erreichbar ist ist ja nich die Situation, das ich in einem der älteren Logfiles Daten gesehen habe, die mE nur Broadcast sein können jnd demzufolge nur via Port 7092 kommen dürften. Kämen sie daher, würde das aber im Logfil erkennbar sei
Die Fehlerhafte Wallbox wurde auch korrigeirt.
Nun laufen alle Wallboxen super, die Daten sind sauber und korrekt. ich bin schon richtig Happy.
Hast du noch interesse das Modul zu erweitern? Ich habe habe das schon versucht, bin aber etwas überfordert.
Ich wollte wenn eine neue RFID erkannt wird einen Float für die RFID anlegen und egal an welcher Wallbox die RFID genutzt wird, bei Abschluss der Ladung wird der Wert „Stromverbrauch des aktuellen Ladevorgangs“ dem aktuell Stand der RFID Karte zugeordnet.
Schon hat man Zusammen mit dem Energierechner von KaiS eine saubere Abrechnung für die Ladekosten
mir ist aber noch nicht ganz klar, wie das zusammenspielen soll (was aber sicherlich auch daran liegt, das ich den Energierechner nicht selbst im Einsatz habe)
das soll doch bestimmt eine Variable sein, die die Summe des Energieverbrauchs der jew. RFID ist
Ist das dann eine Float-Variable mit der Aggregation Zähler?
wann wird denn der Wert wieder zurück gesetzt? Spätestens, wenn „abgerechnet“ wurde, muss ja die Variable auf 0 gesetzt werden?
Kommt man wirklich damit aus, das es nur den einen Zahlenwert gibt?
Ich hatte da ja eher auf die Historie gesetzt und deswegen diese Werte gesammelt.
Wenn man die Historie auswertet, hat man ja sowohl eine Dokumentation der einzelnen Ladevorgänge (bezogen auf die RFID) also auch (daraus zusammengezählt) die Gesamt-Egergiemenge.
Das einzige was dazu in der Historie nich fehlt ist die Markierung eines Eintrags als „abgerechnet“. Das hatte ich noch nicht implementiert, weil ich keine Vorstellung hatte, wie man da in diesem Kontext am besten vorgeht. Da kann man ja noch was machen.
demel
ps: rein interesse halber, weil das ja schon irgendwie merkwürdig war: was war kaputt?
der energie Rechner hat nicht so viel damit zu tun. Der macht nur einen Preis aus den kwh
Richtig.
Es wurden 50kwh geladen, also werden der Variable RFID: 89273469 50kwh angerechnet.
Waren schon z.B. 20 kwh darauf ist der Zähler der Karte bei 70kwh.
ist die RFID unbekannt (evlt. neu) wird diese als Variable anelegt.
Ich würde die nicht zurück 0 setzen. Da es eine Zähler Variable ist kann ich doch super damit rechnen.
Man kann doch für jeden Monat direkt sehen kwh dort verbraucht wurden.
Die History der Ladevorgänge sind dann doch im IPS-Archive drin.
Zeit wann du Ladung abgeschlossen wurde inkl. dem Wert.
Abrechnung wäre sicher ganz lustig, brauche ich aber nicht. Ich möchte ja nur wissen wieviel kwh welcher Kollege geladen hat.
Lasse ich Nachbarn laden sehe ich im IPS kwh und mit dem Energie Rechner die Preis.
(oder kwh * Strompreis).
hmm, das Problem ist
a) zu erkennen, das ein Ladevorgang abgeschlossen ist und
b) keinen Ladevorgang doppelt auszuwerten
wegen der fehlende Broadcast habe ich ja kein Event, den ich das Trigger nehmen könnte. Also muss ich das aus den Daten gewinnen.
Wobei es ja grundsätzlich ein potentielles Problem gibt, das eine irgendwie unterbrochene Kommunikation zu Fehlern führen würde, schlimmstenfalls würden Ladevorgänge der falsche RFID zugerechnet. Klingt vielleicht etwas hypothetisch, aber wenn dein VPN mal ein WE weg sein sollte …
Also bleiben vermutlich nur die Lade-Historie als verlässliche Basis, denn die wird ja in den Wallboxen lokal geführt und ist sicher mit den Ladevorgängen synchronisiert.
a)
das ist eigentlich relativ einfach, (siehe Bild).
Ich hatte versucht ein Skript zu bauen welches die RFID der Auslösenden Box + die Menge abfragt.
Dann kann man gucken womit man das Skript am besten löst.
Mein Favorit ist wenn „nicht bereit zum laden“
Im Bild:
08:19 kommt zur Arbeit.
10:45: Fahre weg.
15:03: bin wieder, lade auto.
17:10: auto hat Ladegrenze erreicht.
17:25: Ich habe die Ladegrenze erhöht
17:42: Feierabend.
Kurz um, jedes mal wenn ich den Stecker ziehe ist er auf „nicht bereit zum laden“.
die Variable „Stromverbrauch des aktuellen Ladevorgangs“ wird scheinbar erst zurück gesetzt wenn ich einen neuen Ladevorgang anfange.
b)
ich denke das ist dadurch ausgeschlossen, da man nur das Skript nur startet wenn das Skript ausgelöst wird.
Du hast aber recht, zu 100% richtig wäre es nur wenn man das Log von der Wallbox direkt ausliest und die dort die Werte addiert. Auf die Idee bin ich nicht unbedingt kommen, da ich das nicht umsetzen könnte.
Ich habe mal eingebaut, um aus der Historie die Daten zu gewinnen.
Da ich das nicht testen kann, kann ich auch nicht sagen, ob es wirklich funktioniert, ich bin mir nicht ganz sicher, es könnte sein, das die letzte Messung mehrfach ausgewertet wird (und zwar bei der nächsten Messung erneut angerechnet wird). Sollte das passieren, müsste ich an der Stelle nochmal ändern.
Ansonsten mit den entsprechenden Debug-Logs …
Es ist egal, warum der Ladezyklus beendet wurde, alles was die Wallbox als eigen Eintrag nimmt, wird gezählt, insofern kannst Du das auch gut testen, wenn du den Ladevorgang vorzeitig beendest.
Siehe Konfiguration: „Speichern des Stromverbrauchs pro RFID“
Wenn ein neuer Historien-Eintrag von der Wallbox übernommen wird, wir eine neue Variable ChargedEnergy_<RFID-Tag> angelegt mit Aggregation „Zähler“ und entsprechend gefüllt.
Was die angesprochene Lücke in der Übertragung angeht: die Wallbox speichert ja bis zu 30 Ladevorgänge in der eigenen Historie, da hat man also schon etwas Zeit, bis da was verloren ginge.
Es ist natürlich logischerweise pro Wallbox eine Variable…
HI,
ich habe das jetzt auf allen 3 Wallboxen aktiviert. Morgen ist Montag, das ist ein perfekter Tag zum testen. Da kommen alle mit leeren Akkus zur Arbeit
Aktuell speichert die RFID pro Box getrennt? Danach müsste man nur noch eine Zusammenfassung bauen. Da wir ja 3 Wallboxen haben und nicht jeder immer die gleiche Wallbox erwischt.
Ich schicke dann morgen ein paar Screenshoot wenns der Kampf um den Ladeplatz vorbei ist
Er hat scheinbar schon Ladewerte von vorher genommen und die auch addiert.
Bin echt begeistert!
Ich warte jetzt mal ein paar Tage, damit einige Leute die Ihr mehrfach aufladen, dann schicke ich noch mal einen Screenshoot.
Die IDs habe ich vorsichtshalber mal etwas anonymisiert.
Moin,
ich habe mir mal die Ladungen angschaut, das mit der Addidtion der Ladevorgänge klappt leider nicht so richtig.
Die ganzen Ladevorgänge auf der RFID sehen etwas wild aus. eine Gesamtsumme auf der karte kann ich da nicht erkennen.
Ich habe nochmal etwas korrigiert - ob es was bringt? Ist veröffentlicht.
Es ist auf jeden Fall wichtig, das du dem Debug in die Datei laufen lässt. Wobei bei den langen Test-Zyklen lässt sich ja kaum noch etwas herausfinden - die Datenmenge ist einfach zu groß.
Daher empfehle ich schon gezielt Tests zu machen mit kurzen Ladezyklen.
Die ChargedEnergy_<RFID-Tag>-Variablen sollte Du auf jeden Fall löschen bzw. auf 0 setzen, damit es einen sauberen Start gibt.
Zu Gegenkontrolle der zu erwartenden Werte kann ich dir nur empfehlen, die Historien-Einträge heranzuziehen, das ist ja die Basis der Berechnung (Feld E pres), damit muss es übereinstimmen.
ich bekomme jetzt Folgende meldungen, wenn ich daten abrufen drücke:
Notice: Undefined variable: e_pre in C:\ProgramData\Symcon\modules\IPSymconKebaConnect\KeConnectP30udp\module.php on line 859
Dann habe ich die RFID Dinger alle gelöscht und nochaml gedrückt:
Cannot find Variable with ident UnlockPlug in C:\ProgramData\Symcon\modules\IPSymconKebaConnect\KeConnectP30udp\module.php on line 1111
Notice: Undefined variable: e_pre in C:\ProgramData\Symcon\modules\IPSymconKebaConnect\KeConnectP30udp\module.php on line 859
und dann wieder die erste Fehlermeldung.
ich kann ja Montag mal direkt rein gucken wenn ein auto anschlossen was im Debug läuft und das dann online stellen.
da war ein Fehler im Debug (e_pre statt e_pres) - hattest du den vorher nicht an?
fix ist eingereicht.
das mit UnlockPlug bedeutet, das du wohl aus Versehen diese Variable gelöscht hast, die ist zuständig um zu kommunizieren, das du das Kabel (vorzeitig) von Fahrzeug entfernen willst.
Die wird aber wieder angelegt durch das o.g. Update oder wenn du ein ApplyChanges der Instanz ausführst / in der Konfiguration der Instanz speicherst ( kann man ja provozieren, indem men etwas änderst und wieder zurück änderst - ich nehme dann gerne den Schalter „Modul deaktivieren“)
Der Fehler kam als PopUP wenn ich direkt auf „Daten aktualsieren“ gedrückt habe.
Ich hatte das aber auf allen 3 Boxen, bevor ich die RFIDs alle gelöscht habe und Autos waren auch nicht dran. Ob das im debug direkt war glaube ich nicht, da ich keiner Fehler im IPS hatte.
Aber jetzt ist es weg. Dann werde ich mal warten bis ein paar RFIDs geladen haben.
Ich finde dies Modul ist echt Mega cool geworden!!!
Moin,
Debug war blöderweise aus
Der Server hat Windows Updates gemacht.
History vom Laden kann ich gerne per Email schicken. Ich weiß nicht ob man die RFIDs veröffentlichen sollte…
Das ist aber schon ein ziemlches auf und ab bei den berechnungen.
