WARP Firmware 2.0.0 Beta 2 und WARP2 Firmware 2.0.0 Beta 3 mit Ladetracking

[E-t-h]

So, ich will jetzt hier nicht so viel zitieren deswegen mal so:

Ich hatte die Probleme mit 1. "Früher gab es in der NFG Config die Möglichkeit, das einzuschalten:"

So wie Du das beschreibst (Autostart, NFC) geht das nun. Aber wie bekomme ich einen Ladevorgang per MQTT zur Nachtzeit gestartet? Das geht nun nicht mehr auf Grund der fehlenden Authentifizieung?

und 2.: "Gerade noch eine neue Beobachtung: zumindest das Topic iec61851_state wird nicht geupdated, ..."

Das kommte jetzt alles. Sieht also gut aus.

Wenn mir noch was auffält melde ich mich selbstredent. Nur das Thema mit dem MQTT-Start wäre mir noch wichtig. Vielleicht am User oder NFC-Tag die Berechtigung zu starten verankern, sodass es auch ohne Authentifizierung geht? Es ist ja ohnehin nicht klar, welches Fahrzeig beim nächtlichen Start am Kabel gehangen hat. Ich kenne jetzt den IEC61851 nicht, aber an eine Fahrzeug-ID wird man wohl nicht kommen., oder?

Danke & Viele Grüße!

 

 

 

[rtrbt]

12 hours ago, E-t-h said:

So wie Du das beschreibst (Autostart, NFC) geht das nun. Aber wie bekomme ich einen Ladevorgang per MQTT zur Nachtzeit gestartet? Das geht nun nicht mehr auf Grund der fehlenden Authentifizieung?

12 hours ago, E-t-h said:

Vielleicht am User oder NFC-Tag die Berechtigung zu starten verankern, sodass es auch ohne Authentifizierung geht? Es ist ja ohnehin nicht klar, welches Fahrzeig beim nächtlichen Start am Kabel gehangen hat. Ich kenne jetzt den IEC61851 nicht, aber an eine Fahrzeug-ID wird man wohl nicht kommen., oder?

Das stimmt über den Ladestandard bekommen wir keine Fahrzeug-ID.

Du kannst https://www.warp-charger.com/api_beta.html#nfc_inject_tag benutzen um über MQTT eine Ladung auf einen bestimmten User zu starten. Schwierig ist dann in der Tat nur die Zuordnung dazu, welcher Benutzer das ist. Eine Idee dazu:

Deine MQTT-Steuerung hat bisher doch entschieden, ob Auto-Start an oder aus ist bzw. Auto-Start war immer aus und über MQTT kam früher oder später ein evse/start_charging-Aufruf. Das kannst du weiterhin so machen, also dass du Auto-Start ausschaltest und die ganze NFC-Tracking-Sache zusätzlich dazu benutzt. Du musst dann nur daran denken, wenn du das Auto ansteckst die entsprechende Karte dranzuhalten, wie bisher. Die Benutzerfreigabe bleibt dann erhalten bis das Auto abgezogen wird, deine MQTT-Steuerung kann also Stunden später erst start_charging aufrufen und das wird funktionieren.

 

[E-t-h]

vor 22 Stunden schrieb rtrbt:

Das stimmt über den Ladestandard bekommen wir keine Fahrzeug-ID.

Du kannst https://www.warp-charger.com/api_beta.html#nfc_inject_tag benutzen um über MQTT eine Ladung auf einen bestimmten User zu starten. Schwierig ist dann in der Tat nur die Zuordnung dazu, welcher Benutzer das ist. Eine Idee dazu:

Deine MQTT-Steuerung hat bisher doch entschieden, ob Auto-Start an oder aus ist bzw. Auto-Start war immer aus und über MQTT kam früher oder später ein evse/start_charging-Aufruf. Das kannst du weiterhin so machen, also dass du Auto-Start ausschaltest und die ganze NFC-Tracking-Sache zusätzlich dazu benutzt. Du musst dann nur daran denken, wenn du das Auto ansteckst die entsprechende Karte dranzuhalten, wie bisher. Die Benutzerfreigabe bleibt dann erhalten bis das Auto abgezogen wird, deine MQTT-Steuerung kann also Stunden später erst start_charging aufrufen und das wird funktionieren.

 

Verstehe, bin aber nicht so glücklich damit. Kurz zum Szenario: Einfamilienhaus, Parlplatz vor Haus, von aussen zugänglich. Hybridwagen (=kleiner Akku). Wenn man tagsüber kurz unterwegs war soll schnell mal geladen werden. Das wurde bisher über den NFC gemacht. Wenn ich nicht mehr los will, soll das Fahrzeug nachts laden. Das NFC ist hier also eher ein verschlüsselter Taster (der richtige ist abgeschaltet) und erspart einem das gefummle auf den Telefon. Wichtig ist also: die Entscheidung ich will jetzt gleich laden oder das soll über Nacht passieren wird beim Anschliessen getroffen. Soll auch unbedingt geladen werden wenn man den Tag vergisst. Wenn keiner da ist (Urlaub) wird die Box deaktiviert.

Die Zuordnung zur Person ist hier sogar eher nachrangig, weil 2. Auto = 2. Box (wegen Load Balancing und ggf. späterer Eigenverbrauchssteuerung). Eine Box für Papi (der rechnet ab), eine für Mami. Wenn Gäste kommen gibts dafür einen eigenen Tag.

Aus meiner Sicht gäbe es hier nur 2 Möglichkeiten: Autostart am Nutzer oder Tag anbinden oder Authentifizierung beim Start über MQTT. Oder übersehe ich das was?

Ich hatte auch mal geschaut ob folgendes geht (Autostart = Ein): Wagen abstellen, zur Box, Tag ranhalten, Kabel stecken. Lädt nicht sofort. Musste erst Tag nochmal dranhalten. Ist das so gewollt? Man könnte vielleicht auch folgendes ralisieren: Auto abstellen, Tag an Box und Reinstecken: läd wann das System das entscheidet, oder Tag an Box + Taster drücken und Reinstecken : läd sofort.

Danke und viele Grüße!

[rtrbt]

D.h. das NFC-Tag ist nur das Signal für "Ich möchte jetzt laden, nicht erst heute Nacht"? Da fallen mir zwei Varianten zur Umsetzung ein. Variante 1:

• Auto-Start an, NFC-Tag angelernt und Nutzer zugeordnet, Ladung nur mit Nutzerfreigabe bzw. Tag
• Wenn du das Auto ansteckst und dann das Tag dranhältst, wird sofort geladen
• Wenn du kein Tag dranhältst kann deine MQTT-Steuerung Nachts nachsehen, ob 1. evse/state["charger_state"] == 1 und 2. evse/slots[6]["max_current"] == 0 ist. Das bedeutet, dass du in dem Zustand bist, dass die Box nicht lädt weil kein NFC-Tag gesehen wurde. In diesem Fall machst du ein nfc/inject_tag dann sollte der Ladevorgang beginnen und auf das entsprechende Tag getrackt werden.

Da ist noch etwas unschön, dass du evse/slots benutzen musst. Ich füge mal (allein der Vollständigkeit halber) noch ein Topic für den Strom der Benutzerfreigabe hinzu, das gibt es für die anderen Stromslots auch.

Variante 2 ist dass du das ganze NFC- und User-System umgehst:

• Auto-Start aus, NFC-Tag kann angelernt sein, muss aber nicht, Ladung ohne Nutzerfreigabe bzw Tag erlaubt
• Deine MQTT-Steuerung sieht sich permanent evse/state["charger_state"] und nfc/seen_tags an. Wenn sich in seen_tags der oberste Eintrag ändert (also wenn die Tag-ID wechselt oder die last_seen-Zeit rückwärts springt) hat jemand ein Tag dran gehalten. Dann prüfst du ob die Tag-ID passt und falls ja schickst du evse/start_charging
• Wenn nachts ein Auto angeschlossen ist (charger_state == 1) schickst du auch evse/start_charging. Wenn du nachts charger_state == 2 siehst heißt das, dass du in dem oberen Fall warst, also per Tag gestartet wurde.

1 hour ago, E-t-h said:

Ich hatte auch mal geschaut ob folgendes geht (Autostart = Ein): Wagen abstellen, zur Box, Tag ranhalten, Kabel stecken. Lädt nicht sofort. Musste erst Tag nochmal dranhalten. Ist das so gewollt?

Das ist Absicht, ja. Die Benutzerfreigabe gilt immer nur für den "laufenden" Ladevorgang, der definiert ist als der Zeitraum zwischen dem Anstecken und dem Abziehen des Autos.

[Witto]

Am 22.2.2022 um 11:12 schrieb rtrbt:

 

• Der Ladetracker: Der WARP Charger kann jetzt bis zu 7680 Ladungen aufzeichnen. Bei jeder Ladung werden Startzeitpunkt, Nutzer, Zählerstart bei Start und Ende der Ladung, sowie Ladedauer gespeichert. Die gesammelten Daten können als CSV-Datei über das Webinterface heruntergeladen werden.

Hallo zusammen,

sorry für die blöde Frage: die WARP 2 Smart hat ja keinen Stromzähler. Damit kann ich dann entsprechend keine Ladevorgänge sehen inkl. Stromverbrauch? Oder doch, aber ist halt nur kein geeichter Wert? 

[rtrbt]

Die Ladevorgänge werden auch ohne Zähler getrackt, nur der Stromverbrauch fehlt dann. Z.B. so: (Das ist meine Entwicklungsbox deshalb waren das auch nur 6 Sekunden Ladezeit)

Die Smart hat leider keine Möglichkeit zu messen wie viel Strom gezogen wurde.

Je nachdem wie dringend du den Stromverbrauch messen möchtest kannst du den Zähler aber nachrüsten, Details dazu hier:

 

[Witto]

Danke dir. Gibt es schon was neues zu OCPP? Mein Netzbetreiber fordert dies leider zwingend 😔

Zitat

Hinweis: Die Ladeeinrichtung muss über eine Kommunikations-Schnittstelle verfügen. Dies wird über das Kommunikationsprotokoll OCPP ab Version 1.6 gewährleistet.

 

[rtrbt]

Noch nicht, nein. OCPP wird auf jeden Fall kommen, aber bisher hatten andere Features Vorrang.

Bei welchem Netzbetreiber bist du? Wäre für uns auf jeden Fall interessant deren genauen Anforderungen zu sehen.

[Witto]

Bei der MEGA in Monheim am Rhein. Hier findest du unten auf der Seite unter „E-Mobilität“ deren Dokumente. Mein Zitat stammt aus dem 

Anmeldung Ladeeinrichtungen (S28)

[alestrix]

Moin!

Was hat es denn mit den verschiedenen Freigaben unter Ladecontroller -> Ladestromgrenzen auf sich?

Autostart, Benutzer und Lastmanagement kann ich mir so weit vorstellen, aber was macht z.B. der "Freigeben" Knopf bei "Externe Steuerung" anders als der an/aus Knopf der Externen Steuerung weiter oben bei den Einstellungen? Und was bedeutet "Konfiguration" (und wozu dient der Freigeben Knopf dort)?

Grüße
 Alex

 

[alestrix]

vor 6 Stunden schrieb Witto:

Gibt es schon was neues zu OCPP? Mein Netzbetreiber fordert dies leider zwingend

Ich frage mich, wie sich die MEGA an die OCPP Schnittstelle anbinden will. Mit dem reinen Vorhandensein einer solchen Schnittstelle ist es ja nicht getan, es muss auch einen (gesicherten!) Kommunikationsweg dorthin geben.

bearbeitet March 17, 2022 at 17:34 von alestrix

[gintonicgamer]

Ich habe jetzt die Warp1 Beta2 drauf, aber noch immer das Problem das ich keine WLAN Verbindung zu meinem Router hinbekomme. 

Kann es an Sonderzeichen liegen? Im Schlüssel habe ich ein @.

Die Wallbox müsste sich mit einem Fritz Repeater Verbinden im Mesh. 

bearbeitet March 18, 2022 at 07:09 von gintonicgamer

[rtrbt]

14 hours ago, alestrix said:

Was hat es denn mit den verschiedenen Freigaben unter Ladecontroller -> Ladestromgrenzen auf sich?

Das ist noch nicht gut dokumentiert, funktioniert grundlegend aber wie folgt:

Es gibt pro Ladestromgrenze einen Strom und ein Flag das angibt, ob die Grenze aktiv ist. Der Ladecontroller berechnet dann das Minimum aus allen aktiven Grenzen und das ist der Strom mit dem geladen werden kann.

Intern ist es so, dass neben den üblichen Strömen von 6000mA bis 32000mA auch 0 gesetzt werden kann, das bedeutet, dass diese Grenze den Ladevorgang blockiert. Ein Beispiel dafür wäre, das wenn das Lastmangement aktiviert ist, immer 0 in der entsprechenden Grenze steht, bis der Lastmanager eine Ladung freigibt. Dann wird entsprechend die Grenze auf das gesetzt, was der Lastmanager vorgibt.

Da es einige Grenzen gibt, die nur binär auf entweder 0 mA oder 32000 mA gesetzt werden (auch bei 16 Ampere bzw. 11 kW Wallboxen, da limitieren die Ladestromgrenzen von Zuleitung und Typ-2-Kabel entsprechend), habe ich das so gebaut, dass statt 0 mA "blockiert" angezeigt wird und statt 32000 mA "freigegeben".

Die "freigeben"-Buttons rechts neben einigen Grenzen sind dafür da, die entsprechende Grenze komplett aufzuheben, also auf 32000 mA zu setzen.

Die Ladestromgrenze "Konfiguration" ist der Wert, den du auf der Statusseite einstellen kannst. Da ist es aber auf der Statusseite so, dass du maximal das Minimum aus Zuleitungs- und Typ-2-Kabel-Grenze setzen kannst (wir hatten schon Benutzer, die verwirrt hat, dass man seine seine 16 Ampere-Box auf z.B. 24 Ampere konfigurieren kann), ist der Knopf die einzige Möglichkeit die Grenze wieder komplett aufzuheben.

Bei der externen Steuerung kann es hilfreich sein, die Grenze aufzuheben, ohne die externe Steuerung ansich zu deaktivieren. Z.B. wenn du dir ein Script gehackt hast, dass zu bestimmten Tageszeiten das Laden verbietet, das Script aber gerade nicht läuft, aber die Grenze nicht freigegeben hatte. Dann kannst du, wenn du jetzt sofort laden willst, die Grenze aufheben (und damit ggfalls. eine Ladung freigeben die sonst blockiert wäre) und irgendwann später dein Script wieder starten und es funktioniert wieder alles.

14 hours ago, alestrix said:

Ich frage mich, wie sich die MEGA an die OCPP Schnittstelle anbinden will. Mit dem reinen Vorhandensein einer solchen Schnittstelle ist es ja nicht getan, es muss auch einen (gesicherten!) Kommunikationsweg dorthin geben.

Das ist in der Tat seltsam. Auch interessant ist, das eine 11kW-Wallbox bei denen schon Zustimmungspflichtig ist. Bei allen anderen Netzbetreibern die mir so untergekommen sind, liegt die Grenze immer bei > 11kW, nicht bei >= 11 kW.

1 hour ago, gintonicgamer said:

Ich habe jetzt die Warp1 Beta2 drauf, aber noch immer das Problem das ich keine WLAN Verbindung zu meinem Router hinbekomme. 

Das ist wirklich seltsam. Ich teste gleich mal ein Passwort mit allen Sonderzeichen die mir so einfallen durch. Weißt du zufällig noch welche Firmware du vor der Beta installiert hastest? Da hatte es ja funktioniert, oder?

[gintonicgamer]

vor 6 Minuten schrieb rtrbt:

 

Das ist wirklich seltsam. Ich teste gleich mal ein Passwort mit allen Sonderzeichen die mir so einfallen durch. Weißt du zufällig noch welche Firmware du vor der Beta installiert hastest? Da hatte es ja funktioniert, oder?

Leider nicht. Sorry

[rtrbt]

Also an Sonderzeichen liegt es vermutlich nicht: Ich habe hier einen Fritz Repeater 2400, habe bei dem versucht alle möglichen Sonderzeichen in das Passwort zu setzen und dabei gelernt, dass AVM nur bestimmte Zeichen erlaubt. Zitat aus der Online-Hilfe:

Quote

Zeichen für Kennwörter und Netzwerkschlüssel

Erlaubte Zeichen	Verbotene Zeichen
Buchstaben von a bis z in Groß- und Kleinschreibung Ziffern 0 bis 9 Leerzeichen Sonderzeichen _ - ! " # $ % & ' ( ) * + , . / : ; < = > ? @ [ \ ] ^ ` { | } ~	Buchstabe ß Umlaute ä, ö, ü (Kleinschreibung) und Ä, Ö, Ü (Großschreibung) Sonderzeichen € § ´

Ich habe dann alle aus der erlaubten Liste benutzt, das funktioniert mit WARP1 Beta 2 ohne Probleme.

Wenn du im Webinterface unter die Netzwerk->WLAN-Verbindung die Netzwerksuche ausführst, taucht den Netzwerk da auf?

 

[alestrix]

vor 1 Stunde schrieb rtrbt:

Es gibt pro Ladestromgrenze einen Strom und ein Flag das angibt, ob die Grenze aktiv ist. Der Ladecontroller berechnet dann das Minimum aus allen aktiven Grenzen und das ist der Strom mit dem geladen werden kann.

[...]

Die Ladestromgrenze "Konfiguration" ist der Wert, den du auf der Statusseite einstellen kannst. Da ist es aber auf der Statusseite so, dass du maximal das Minimum aus Zuleitungs- und Typ-2-Kabel-Grenze setzen kannst

Danke für die ausführliche Beschreibung!

Kurz zum Verständnis: Bisher konnte man in der GUI beim konfigurierten maximalen Ladestrom sehen, wie die externe Regelung den Ladestrom immer wieder nachregelt. Mit der nun kommenden Trennung von "externer Ladegrenze" und (intern) konfigurierter Ladegrenze kann mit der neuen Firmware eine externe Ladesteuerung nun also nicht mehr über den in der GUI im Status konfigurierten maximalen Ladestrom hinausregeln (sofern nicht explizit freigegeben), korrekt?

[rtrbt]

Korrekt, die externe Steuerung kann zwar z.B. 28 Ampere vorgeben, aber wenn du in der GUI 12 Ampere eingestellt hast, dann ist das das Maximum. Wenn die externe Steuerung jetzt aber 10 Ampere vorgibt, dann wird auch nur mit 10 geladen. Eben immer das Minimum aus allen aktiven Ladegrenzen.

[gintonicgamer]

vor 4 Stunden schrieb rtrbt:

Also an Sonderzeichen liegt es vermutlich nicht: Ich habe hier einen Fritz Repeater 2400, habe bei dem versucht alle möglichen Sonderzeichen in das Passwort zu setzen und dabei gelernt, dass AVM nur bestimmte Zeichen erlaubt. Zitat aus der Online-Hilfe:

Ich habe dann alle aus der erlaubten Liste benutzt, das funktioniert mit WARP1 Beta 2 ohne Probleme.

Wenn du im Webinterface unter die Netzwerk->WLAN-Verbindung die Netzwerksuche ausführst, taucht den Netzwerk da auf?

 

Ja, ich habe alle 3 probiert. 
der mit dem starken signal ist der fritz repeater im mesh.

 

 

[alestrix]

vor 1 Stunde schrieb gintonicgamer:

Ja, ich habe alle 3 probiert. 
der mit dem starken signal ist der fritz repeater im mesh.

Probier's mal ohne BSSID Sperre. Wenn man mit Repeatern oder mehreren APs arbeitet, ist das IMHO die bessere Variante.

 

EDIT: Und am besten das Passwort auch nochmal neu eingeben, obwohl es sich nicht geändert hat.

bearbeitet March 18, 2022 at 14:58 von alestrix

[alestrix]

Ich hoffe, ich spamme nicht zu viel ins Forum (einfach Bescheid geben), aber ich bin möglicherweise über einen Fehler gestolpert.

Ich habe in der WARP (WARP 1 Smart mit NFC Bricklet) drei Tags händisch über die Weboberfläche eingetragen und die "Benutzerautorisierung" aktiviert. Unter Laststromgrenzen stehen sowohl "Benutzer" als auch "externe Steuerung" auf blockiert. Soweit ok.

Wenn ich nun per

mosquitto_pub -t warp/nfc/inject_tag -m '{"tag_type": 0, "tag_id": "DE:AD:BE:EF"}'

eine Aktivierung per RFID simuliere, bleiben aber weiterhin beide Werte unverändert auf "blockiert" stehen. Der Tag findet sich nach Aufruf des mosquitto Befehls im seen_tags Topic und die Tag-ID habe ich per copy-and-paste aus dem NFC Menüpunkt der WARP kopiert, ein Tippfehler ist also ausgeschlossen.

Ich hätte erwartet, dass ein inject_tag die Begrenzung bei "Benutzer" beeinflusst.

bearbeitet March 18, 2022 at 23:12 von alestrix

[E-t-h]

Am 16.3.2022 um 09:06 schrieb rtrbt:

D.h. das NFC-Tag ist nur das Signal für "Ich möchte jetzt laden, nicht erst heute Nacht"? Da fallen mir zwei Varianten zur Umsetzung ein. Variante 1:

• Auto-Start an, NFC-Tag angelernt und Nutzer zugeordnet, Ladung nur mit Nutzerfreigabe bzw. Tag
• Wenn du das Auto ansteckst und dann das Tag dranhältst, wird sofort geladen
• Wenn du kein Tag dranhältst kann deine MQTT-Steuerung Nachts nachsehen, ob 1. evse/state["charger_state"] == 1 und 2. evse/slots[6]["max_current"] == 0 ist. Das bedeutet, dass du in dem Zustand bist, dass die Box nicht lädt weil kein NFC-Tag gesehen wurde. In diesem Fall machst du ein nfc/inject_tag dann sollte der Ladevorgang beginnen und auf das entsprechende Tag getrackt werden.

Da ist noch etwas unschön, dass du evse/slots benutzen musst. Ich füge mal (allein der Vollständigkeit halber) noch ein Topic für den Strom der Benutzerfreigabe hinzu, das gibt es für die anderen Stromslots auch.

 

Hi,

danke für dies Tips. Ich verstehe ledier das Konzept mit den Slots noch nicht, habe auch nichts finden können. Hast Du mal was zum nachlesen?

Danke..

[alestrix]

vor 5 Stunden schrieb E-t-h:

Hast Du mal was zum nachlesen?

Schau Dir mal die Erklärung oben zu den einzelnen Ladegrenzen an. Der Slot mit Index 6 ist die Benutzer-Grenze, also die durch RFID gesetzte und 0A= blockiert, weil kein Tag rangehalten wurde.

bearbeitet March 19, 2022 at 22:21 von alestrix

[E-t-h]

vor 18 Stunden schrieb alestrix:

Schau Dir mal die Erklärung oben zu den einzelnen Ladegrenzen an. Der Slot mit Index 6 ist die Benutzer-Grenze, also die durch RFID gesetzte und 0A= blockiert, weil kein Tag rangehalten wurde.

Alles klar, Danke alestrix! Slot=Ladegrenze. Gibts irgendwo noch eine Übersicht welcher Slot was ist?

Nachtrag:

Sorry für die Frage, ich hätte selber drauf kommen können, steht ja alles in der esp32-firmware/software/src/modules/evse_v2/evse_v2.h. Für diejenigen die es vielleicht auch wissen wollen:
#define CHARGING_SLOT_INCOMING_CABLE 0
#define CHARGING_SLOT_OUTGOING_CABLE 1
#define CHARGING_SLOT_SHUTDOWN_INPUT 2
#define CHARGING_SLOT_GP_INPUT 3
#define CHARGING_SLOT_AUTOSTART_BUTTON 4
#define CHARGING_SLOT_GLOBAL 5
#define CHARGING_SLOT_USER 6
#define CHARGING_SLOT_CHARGE_MANAGER 7
#define CHARGING_SLOT_EXTERNAL 8

@rtrbt

Ich habe die Lösung 1 zu dem Thema mit den NFC-Tags zum Sofort-Start und dem nfc/inject_tag ausprobiert: funktioniert. Nun bin ich zufrieden (mal sehen wie lange ;-) ), Danke auf jeden Fall für Deine Hilfe! Werde das jetzt in meinem FHEM reinbasteln. Wenn jemand Interesse daran hat bitte melden.

Kleines Feedback meinerseits: Ich finde die Box gelungen und mit dem NFC und dem Aufzeichnen der Verbräuche und dem Lastmanagement nun auch für Firmenparkplätze gut geeignet. Und der Support hier ist a class of its own..

bearbeitet March 20, 2022 at 13:06 von E-t-h

[rtrbt]

On 3/19/2022 at 12:07 AM, alestrix said:

Ich hoffe, ich spamme nicht zu viel ins Forum (einfach Bescheid geben), aber ich bin möglicherweise über einen Fehler gestolpert.

Alles gut, Feedback hilft gerade bei den Betas immer.

On 3/19/2022 at 12:07 AM, alestrix said:

Wenn ich nun per

mosquitto_pub -t warp/nfc/inject_tag -m '{"tag_type": 0, "tag_id": "DE:AD:BE:EF"}'

eine Aktivierung per RFID simuliere, bleiben aber weiterhin beide Werte unverändert auf "blockiert" stehen. Der Tag findet sich nach Aufruf des mosquitto Befehls im seen_tags Topic und die Tag-ID habe ich per copy-and-paste aus dem NFC Menüpunkt der WARP kopiert, ein Tippfehler ist also ausgeschlossen.

Ich hätte erwartet, dass ein inject_tag die Begrenzung bei "Benutzer" beeinflusst.

Du bekommst im Ereignislog vermutlich

MQTT: Ignoring message with payload length 40 for topic warp2/X8A/nfc/inject_tag. Maximum length allowed is 32.

(oder ähnlich)?

Das ist dieser Bug hier:

Ich gebe Bescheid, wenn das gefixt ist.

 

@E-t-h Eine genauere Dokumentation der Slots kommt noch, liegt unfertig auf meiner Platte.

On 3/20/2022 at 7:35 AM, E-t-h said:

Kleines Feedback meinerseits: Ich finde die Box gelungen und mit dem NFC und dem Aufzeichnen der Verbräuche und dem Lastmanagement nun auch für Firmenparkplätze gut geeignet. Und der Support hier ist a class of its own..

Danke! Gebe ich auch mal an den Rest weiter :)

 

On 3/18/2022 at 2:23 PM, gintonicgamer said:

Ja, ich habe alle 3 probiert. 
der mit dem starken signal ist der fritz repeater im mesh.

Weißt du was das genau für ein Fritz Repeater ist? Hat er ein aktuelles FritzOS installiert? Kannst du eine Verbindung mit dem Router/Repeater aufbauen, der am nächstbesten erreichbar ist? (Der mit der 44:... MAC-Adresse, da musst du die BSSID-Sperre wieder anmachen um zu erzwingen, das der genommen wird.)

[rtrbt]

tl;dr: WARP1 Beta 3 bzw. WARP2 Beta 4. Hoffentlich die letzte Beta ;) Viele Bugfixes.

Was gibt's neues?

Die Betas sind wieder zum Großteil nur ein Bugfix-Release. Die API wurde noch etwas besser auf die Bedürfnisse von EVCC angepasst. Außerdem gibt es jetzt Migrationslogik, sodass die Konfiguration der alten Firmwares (WARP 1.3.3 bzw. WARP2 1.1.2 oder älter) so umgebaut wird, dass sie mit der kommenden 2.0.0 kompatibel ist. ACHTUNG: Updates von älteren Betaversionen auf die hier gepostete werden nur NACH einem Reset auf Werkszustand unterstützt! Updates von Firmwares älter als 1.9.90 sollten aber ohne Probleme funktionieren.

Größere Bugfixes

• WebSocket-Verbindungen können jetzt sauber durch SSL-Proxies durchgeführt werden.
• Die MQTT-Payload-Längenberechnung funktioniert wieder
• Die Firmware kann wieder ohne angeschlossenen Ladecontroller gebootet werden
• Spontane Fehler beim Flashen von Firmwares behoben

warp2_firmware_1_9_93_6239e590_merged.bin warp_firmware_1_9_92_6239e52c_merged.bin