NEWS
[Frage] Realisierung Adapter UDP Keba Wallbox
-
@Haki nein, curr regelt nur die Leistung, mit enable wird die Ladung aktiviert und beendet.
Wenn keine lastabhängigen Werte hinterlegt sind, dann sollte auch kein curr gesendet werden. Wenn Du "nur" maximale Leistung wählst, dann wird curr mit dem Wert max curr gesendet@Sneak-L8
Bin jetzt wieder zuhause und habe festgestellt, dass das Laderelais des Passat GTE wohl zum 2. Mal hinüber ist.
Ich glaube jetzt auch die Ursache gefunden zu haben.
Zum Hintergrund:
Ich habe bisher immer über einen Solarlog die Laderegelung durchgeführt. Keba und Solarlog arbeiten eng zusammen und in der Applikation vom Solarlog gibt es die Unterstützung der Keba Wallbox:- Immer Laden
- Überschuss / Minimalladung
- Überschuss
- Keine Steuerung
Jetzt ist im kecontact Adapter ebenfalls die Laderegelung verfügbar (was toll ist!). Um aber Konflikte mit anderen Reglern zu vermeiden, sollte der kecontact Adapter auch in einen reinen passiven Modus zu schalten sein. (nur die Reports abfragen, in die Objekte eintragen und keinen curr Sollwert setzen)
Durch die unterschiedlichen Ladestrom Vorgaben wurde der Ladevorgang immer wieder nach der einstellbaren Abschaltverzögerung unterbrochen und wieder neu gestartet. Dieses oszillieren der Ladestromvorgaben muss verhindert werden.Außerdem wird in der neuesten Version des Keba UDP Programmers Guide V 2.01 darauf hingewiesen, dass der Stromwert während der Ladung mit currtime geändert werden soll. Das haben sie jetzt erheblich besser beschrieben, als in der alten Doku.
Unter 3.3.2 UDP command: curr steht z.B. "The only option to remove a curr setting without a restart is to over-
write it with a currtime command. In general, it is not recommended to use the curr command, since the current
can be easily controlled via the non-permanent currtime."Es wäre toll, wenn du die currtime Anforderung von Keba noch mal checken könntest.
Außerdem wären Einstelloptionen für den Adapter super:- einstellbare Leistung (als veränderbares Objekt - deckt maximale Leistung mit ab)
- PV geregelt
- keine Steuerung (nur Reports auslesen)
Gruß Hans
-
Hallo Hans,
so hatte ich das bisher noch nicht gesehen. Aber Du hast recht, solange ein Fahrzeug angesteckt ist, wird alle 30 Sekunden nachgeregelt. Entweder PV-abhängig von 0 (aus) bis maiximum oder einfach immer auf Maximum.
Da könnte ich tatsächlich noch einen Schalter einbauen (ich tendiere dazu, ihn der Konfigursation zu setzen und nicht als State), der dafür sorgt, dass grundsätzlich nichts geregelt wird und die Box sich passiv erhält.
Mir ist allerdings nicht klar, warum man immer currtime anstelle curr benutzen soll. Beide Kommandos führen doch zum selben Ergebnis und regeln auf dieselbe Art die Ladeleistung des Fahrzeugs.
Doku:
P30 complies with IEC 61851-1. This international standard requires a minimum
waiting time between two consecutive current changes. To fulfill this requirement,
all P30 will delay the execution of UDP commands requesting a
current change during a charging session. The affected commands are currtime
and curr. The request to stop charging via currtime 0 1 will not be
delayed and executed as soon as possible.Damit sollten zu viele Umschaltvorgänge o.ä. eigentlich ausgeschlossen sein.
Aber ich kann in der nächsten Version einfach anstelle curr currtime benutzen. Sollte ja dasselbe bewirken.Edit: V0.2.4 ist zum Testen online: https://github.com/Sneak-L8/ioBroker.kecontact
Viele Grüße
Sneak-L8 -
So, ich habe leider mit V0.2.5 wieder auf curr zurückwechseln müssen. Bei currtime wurde das minimale Laden nicht nach der eingestellten Mindesladedauer pausiert, weil der Ladebginn immer wieder neu gesetzt wurde. Ich vermute, weil eine Rückmeldung von der Wallbox mit 1 Sekunde Verzögerung kommt und aktuell noch ein Laden erkannt wird.
Vielleicht schreibe ich auch mal Keba direkt an und frage nach, warum man currtime vorziehen sollte.
Das muss ich mir genauer ansehen. Macht die Programmierung aber komplizierter. Aber der passive Modus ist jetzt möglich. -
Hallo Sneak-L8
die einzige Erklärung die mir dafür einfällt ist, das bei curr anders als bei currtime der Wert gespeichert wird und das wahrscheinlich zu einem Schreibvorgang auf einem internen Speicher führt. Je nach dem was hier verwendet wird (SD,SSD), kann man diese nicht unbegrenzt beschreiben. Wenn man jetzt aber ständig curr verwendet, wird dieser Speicher frühzeitig ausfallen.
Ist aber nur eine Vermutung von mir.
Wenn meine Vermutung richtig ist müsste currtime ständig neu gesendet werden, auch wenn sich der Wert nicht ändert. -
Hallo ArnoD,
ich glaube nicht, dass das Schreiben in einen SSD/SD-Speicher das Problem ist. Die Menge ist so klein und die Schreibzyklus nicht so exorbitant hoch, dass durch die autoamtische Verteilung auf den gesamten Speicher oft derselbe Bereich überschrieben wird.
Es ging hier ja auch eher un konkrete Fehler beim Fahrzeug bzw. dessen Bordlader. Das soltle man erst nehmen.
Ich habe Keba bereits angeschrieben und bin gespannt auf die Antwort. -
@Sneak-L8
Danke für die Einführung des passiven Modus. Jetzt funkt der kecontact Laderegler nicht mehr dazwischen, wenn ich mit dem Solarlog die Laderegelung realisiere.
Bin gerade dabei die PV Regelung des kecontact Adapters ausprobieren. Habe es bisher noch nicht hinbekommen.
Wird hier ein bestimmtes Energy-Meter benötigt?
Welche Einheit wird beim Objekt "Name des States für Netzbezug/Netzeinspeisung" verwendet, mW oder W?Wird bei der Stromvorgabe mit curr bei einer Wertänderung der Ladevorgang neu gestartet (Relaisklappern)?
Gruß Hans -
Hallo Hans,
Du kannst die Daten eines beliebigen EnergyMeters (EM) nehmen. Die erwartete Einheit sind Watt. Liefert Dein EM poitive und negative Werte, dann musst Du es nur einmal eintragen. Hat Dein EM getrennte State für positive und negative Werte (Netzbezug/Einspeisung), dann musst du beide angeben.
Mit dem curr-Kommando solltest Du keine Relasie hören, es ändert nur die Modulation des Signals, das ans Auto übertragen wird und mit dem mitgeteilt wird, wieviel Ampere sich das Fahrzeug an der Wallbox genehmigen darf.
Viele Grüße
Sneak-L8 -
Heute ist bereits die Antwort vom Keba-Support eingetroffen:
da der Befehl „curr“ permanent an der Wallbox gilt, sollte zum dynamischen regeln der Wallbox der Befehl „currtime“ benutzt werden.
Zu Problemen an der Fahrzeugelektronik sollte es nicht kommen.
Jedoch reagieren verschiedene Fahrzeugtypen bei zu häufiger Leistungsanpassung unterschiedlich bzw. reagiert das Fahrzeug darauf nicht mehr.Dann werden noch Mindestwartezeiten für Kommandos angegeben:
- 100ms zwischen zwei UDP-Kommandos
- 5s für die Wiederholung desselben Kommandos
- 2s nach dem Abschalten der Wallbox (z.B. ena 0)
Da ich nur alle 30 Sekunden eine neue Berechnung starte und max. zwei verschiedene Kommandos auf einmal sende (der Adapter verschickte dies dann immer in Abständen von 300ms), kann diese Anforderugn als eingehalten betrachtet werden.
D.h. so eine zwingende Begründung für currime anstelle curr gibt es nicht.
Daher lasse ich es erst mal bei 0.2.4a (sorry, ist nicht 0.2.5) bei der wieder curr benutzt wird. currtime kann ich mir mal noch genauer ansehen, sehe da jetzt aber keine Dringlichkeit. -
Wenn ich die Version https://github.com/Sneak-L8/ioBroker.kecontact über github installiere, dann ist der admin Bereich über meine IP Adresse 192.x.x.x:8081 nicht mehr erreichbar. Über iobroker.pro kann ich in den admin Bereich noch einsteigen und im log steht folgendes:
host.ioBroker-Rock 2020-07-01 16:57:47.551 error instance system.adapter.admin.0 terminated with code 1 (JS_CONTROLLER_STOPPED) host.ioBroker-Rock 2020-07-01 16:57:47.550 error Caught by controller[0]: at /opt/iobroker/node_modules/standard-as-callback/built/index.js:19:49 host.ioBroker-Rock 2020-07-01 16:57:47.549 error Caught by controller[0]: at tryCatcher (/opt/iobroker/node_modules/standard-as-callback/built/utils.js:11:23) host.ioBroker-Rock 2020-07-01 16:57:47.549 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:616:17 host.ioBroker-Rock 2020-07-01 16:57:47.548 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.admin/main.js:265:30 host.ioBroker-Rock 2020-07-01 16:57:47.547 error Caught by controller[0]: at Array.forEach (<anonymous>) host.ioBroker-Rock 2020-07-01 16:57:47.547 error Caught by controller[0]: at /opt/iobroker/node_modules/iobroker.admin/main.js:268:22 host.ioBroker-Rock 2020-07-01 16:57:47.546 error Caught by controller[0]: at upToDate (/opt/iobroker/node_modules/iobroker.admin/main.js:223:16) host.ioBroker-Rock 2020-07-01 16:57:47.545 error Caught by controller[0]: at Function.gt (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:683:10) host.ioBroker-Rock 2020-07-01 16:57:47.544 error Caught by controller[0]: at compare (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:647:10) host.ioBroker-Rock 2020-07-01 16:57:47.543 error Caught by controller[0]: at new SemVer (/opt/iobroker/node_modules/iobroker.admin/node_modules/semver/semver.js:332:11) host.ioBroker-Rock 2020-07-01 16:57:47.541 error Caught by controller[0]: TypeError: Invalid Version: 0.2.4aAndere Version z.B 0.2.3 lassen sich nicht installieren. Ich muss den adapter löschen und die Version 0.1.0 installieren. Dann funktioniert wieder alles und ich kann den admin Bereich mit meiner IP Adresse erreichen.
Würde gerne aber meine PV Überschuß mit meiner wallbox verbinden.
Danke für Eure Hilfe. -
Also das sieht mir nach einem Fehler im Admin-Adapter aus. Er könnte aber vom Keb-Adapter ausgelöst worden sein, weil die Versions-Nr. 0.2.4a nicht ins Schema passt.
Ich habe daher die Version als 0.2.5 aktualisiert. Bitte mit dieser aktualisieren, um den Fehler im Admin-Adapter zu verhindern. -
Also das sieht mir nach einem Fehler im Admin-Adapter aus. Er könnte aber vom Keb-Adapter ausgelöst worden sein, weil die Versions-Nr. 0.2.4a nicht ins Schema passt.
Ich habe daher die Version als 0.2.5 aktualisiert. Bitte mit dieser aktualisieren, um den Fehler im Admin-Adapter zu verhindern. -
Ich habe gestern und heute an einer neuen Version 0.3.0 gearbeitet, die nun currtime unterstützen wird. Bisher war diese noch nicht stabil, ich bin noch am Testen. Daher bitte mit Neuinstallationen des Adapters mal noch etwas warten ...
P.S. Sieht aber schon ganz gut aus. -
So, gerade mit der neuen Version erfolgreich PV-abhängig geladen, V0.5.0 scheint nun korrekt zu funktionieren. Link unverändert.
@Haki: wie gewünscht und von Keba empfohlen wird nun ausschließlich mit currtime anstelle curr und ena bei der PV-abhängigen Ladung und der Leistungsbegrenzung gearbeitet
Bitte gerne testen und melden, falls etwas nicht (mehr) funktioniert... -
Ich habe nochmal eine V0.3.1 nachgeschoben, bei der die "Unsitte", auch bei zu geringer PV-Leisterung trotzdem für die minimale Ladedauer ein Laden anzufangen, nun hoffentlich ausgemerzt sein sollte.
Und noch ein Update auf v0.3.2: die Wallbox geht sperrt das Laden nun im PV-abhängigen Laden, solange kein Fahrzeug angeschlossen ist. Sonst beginnt das Fahrzeug unweigerlich mit dem Ladevorgang bis zum ersten Mal eine Berechnung der verfügbaren Leistung erfolgt.
Da macht es beim Überschussladen mehr Sinn, erstmal zu sperren und bei Bedarf das Laden freizugeben.
Falls mit der neuen Version etwas nicht stimmt, bitte kurze Info. -
Und noch ein Update auf v0.3.2: die Wallbox geht sperrt das Laden nun im PV-abhängigen Laden, solange kein Fahrzeug angeschlossen ist. Sonst beginnt das Fahrzeug unweigerlich mit dem Ladevorgang bis zum ersten Mal eine Berechnung der verfügbaren Leistung erfolgt.
Da macht es beim Überschussladen mehr Sinn, erstmal zu sperren und bei Bedarf das Laden freizugeben.
Falls mit der neuen Version etwas nicht stimmt, bitte kurze Info.@Sneak-L8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
Und noch ein Update auf v0.3.2
Hi Sneak-L8
Wie ich sehe, bist du mit der Entwicklung des Adapters voran gekommen. Macht es Sinn, dass wir das wieder auf mein Repo zurück mergen (PR)? Ich werde wohl bald den Adapter in die Community verschieben und so könnten dann alle auf dieser Basis weiterarbeiten und der Adapter kann dann auch wieder standardmässig in ioBroker installiert werden.
/UncleSam
(zurück aus der Versenkung) -
@Sneak-L8 sagte in [Frage] Realisierung Adapter UDP Keba Wallbox:
Und noch ein Update auf v0.3.2
Hi Sneak-L8
Wie ich sehe, bist du mit der Entwicklung des Adapters voran gekommen. Macht es Sinn, dass wir das wieder auf mein Repo zurück mergen (PR)? Ich werde wohl bald den Adapter in die Community verschieben und so könnten dann alle auf dieser Basis weiterarbeiten und der Adapter kann dann auch wieder standardmässig in ioBroker installiert werden.
/UncleSam
(zurück aus der Versenkung)@UncleSam Hallo UncleSam, freut mich, dass Du zurück bist "aus der Versenkung". Ich hatte vorhin noch gedacht: "Hm, was wohl aus meinem PR geworden ist bei UncleSam?". Daher meldest Du Dich gerade richtig.
Hatte auch überlegt, wie man ihn der Community nun allgemein zur Verfügung stellen könnte.
Prima, wenn Du das anschieben kannst!
Der PR ist schon älter, würde aber die neuen Commits mitnehmen, oder? -
Hallo UncleSam,
ok ich lege mal los:
soweit ich das bis jetzt beurteilen kann benötige ich nur folgende Anfragen:
<list type="decimal">2. report 1: eigentlich nur beim Starten des Moduls, da Seriennummer, Typ FW der Box hoffentlich recht statisch sind …)
<list type="2">* report 2: der regelmäßig (z.B. alle 30s oder 5min ODER wenn die Box über 255.255.255.255 ein Broadcast raushaut (s. weiter unten)
<list type="3">* report 3: analog zu report2
<list type="4">* curr X: X zwischen 6000 und 32000 (Wird mit DIP Schaltern an der Box eingestellt). X sollte über ein "schreibendes" Objekt möglich sein, da der Wert ja abhängig von der PV-Anlage über iObroker gesetzt werden sollZu den Reports:
Im log sehe ich nur die Werte von report 3 (soweit ich es sehen kann). D
Hier der Output des Adapter-Logs:
Drücke Strg+A und danach Strg+C, um den Inhalt in die Zwischenablage zu kopieren. Klicke irgendwo, um das Fenster zu schliessen. kecontact.0 2017-07-03 21:30:33.633 debug inMem message kecontact.0.* kecontact.0.uptime kecontact.0 2017-07-03 21:30:33.633 debug inMem message kecontact.0.* kecontact.0.serial kecontact.0 2017-07-03 21:30:33.633 debug inMem message kecontact.0.* kecontact.0.eTotal kecontact.0 2017-07-03 21:30:33.633 debug inMem message kecontact.0.* kecontact.0.ePres kecontact.0 2017-07-03 21:30:33.633 debug inMem message kecontact.0.* kecontact.0.pf kecontact.0 2017-07-03 21:30:33.632 debug inMem message kecontact.0.* kecontact.0.p kecontact.0 2017-07-03 21:30:33.632 debug inMem message kecontact.0.* kecontact.0.i3 kecontact.0 2017-07-03 21:30:33.567 debug inMem message kecontact.0.* kecontact.0.i2 kecontact.0 2017-07-03 21:30:33.556 debug inMem message kecontact.0.* kecontact.0.i1 kecontact.0 2017-07-03 21:30:33.555 debug inMem message kecontact.0.* kecontact.0.u3 kecontact.0 2017-07-03 21:30:33.555 debug inMem message kecontact.0.* kecontact.0.u2 kecontact.0 2017-07-03 21:30:33.533 debug inMem message kecontact.0.* kecontact.0.u1 kecontact.0 2017-07-03 21:30:33.523 debug Unknown value received: ID=3 kecontact.0 2017-07-03 21:30:33.522 debug UDP datagram from 192.168.0.11:7090: '{ 'ID': '3', 'U1': 0, 'U2': 0, 'U3': 0, 'I1': 0, 'I2': 0, 'I3': 0, 'P': 0, 'PF': 0, 'E pres': 0, 'E total': 0, 'Serial': '17501302', 'Sec': 2365446 } ' kecontact.0 2017-07-03 21:30:33.517 debug Sent 'report 3' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:30:33.517 debug Sent 'report 2' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.uptime kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.serial kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.eTotal kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.ePres kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.pf kecontact.0 2017-07-03 21:30:13.622 debug inMem message kecontact.0.* kecontact.0.p kecontact.0 2017-07-03 21:30:13.621 debug inMem message kecontact.0.* kecontact.0.i3 kecontact.0 2017-07-03 21:30:13.621 debug inMem message kecontact.0.* kecontact.0.i2 kecontact.0 2017-07-03 21:30:13.618 debug inMem message kecontact.0.* kecontact.0.i1 kecontact.0 2017-07-03 21:30:13.553 debug inMem message kecontact.0.* kecontact.0.u3 kecontact.0 2017-07-03 21:30:13.542 debug inMem message kecontact.0.* kecontact.0.u2 kecontact.0 2017-07-03 21:30:13.542 debug inMem message kecontact.0.* kecontact.0.u1 kecontact.0 2017-07-03 21:30:13.542 debug Unknown value received: ID=3 kecontact.0 2017-07-03 21:30:13.542 debug UDP datagram from 192.168.0.11:7090: '{ 'ID': '3', 'U1': 0, 'U2': 0, 'U3': 0, 'I1': 0, 'I2': 0, 'I3': 0, 'P': 0, 'PF': 0, 'E pres': 0, 'E total': 0, 'Serial': '17501302', 'Sec': 2365426 } ' kecontact.0 2017-07-03 21:30:13.542 debug Sent 'report 3' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:30:13.541 debug Sent 'report 2' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:53.610 debug inMem message kecontact.0.* kecontact.0.uptime kecontact.0 2017-07-03 21:29:53.610 debug inMem message kecontact.0.* kecontact.0.serial kecontact.0 2017-07-03 21:29:53.610 debug inMem message kecontact.0.* kecontact.0.eTotal kecontact.0 2017-07-03 21:29:53.610 debug inMem message kecontact.0.* kecontact.0.ePres kecontact.0 2017-07-03 21:29:53.610 debug inMem message kecontact.0.* kecontact.0.pf kecontact.0 2017-07-03 21:29:53.609 debug inMem message kecontact.0.* kecontact.0.p kecontact.0 2017-07-03 21:29:53.609 debug inMem message kecontact.0.* kecontact.0.i3 kecontact.0 2017-07-03 21:29:53.609 debug inMem message kecontact.0.* kecontact.0.i2 kecontact.0 2017-07-03 21:29:53.609 debug inMem message kecontact.0.* kecontact.0.i1 kecontact.0 2017-07-03 21:29:53.608 debug inMem message kecontact.0.* kecontact.0.u3 kecontact.0 2017-07-03 21:29:53.605 debug inMem message kecontact.0.* kecontact.0.u2 kecontact.0 2017-07-03 21:29:53.532 debug inMem message kecontact.0.* kecontact.0.u1 kecontact.0 2017-07-03 21:29:53.523 debug Unknown value received: ID=3 kecontact.0 2017-07-03 21:29:53.522 debug UDP datagram from 192.168.0.11:7090: '{ 'ID': '3', 'U1': 0, 'U2': 0, 'U3': 0, 'I1': 0, 'I2': 0, 'I3': 0, 'P': 0, 'PF': 0, 'E pres': 0, 'E total': 0, 'Serial': '17501302', 'Sec': 2365406 } ' kecontact.0 2017-07-03 21:29:53.509 debug Sent 'report 3' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:53.508 debug Sent 'report 2' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:33.593 debug inMem message kecontact.0.* kecontact.0.uptime val=2365386, ack=true, ts=1499110173536, q=0, from=system.adapter.kecontact.0, lc=1499110173536 kecontact.0 2017-07-03 21:29:33.592 debug inMem message kecontact.0.* kecontact.0.serial val=17501302, ack=true, ts=1499110173535, q=0, from=system.adapter.kecontact.0, lc=1498491663484 kecontact.0 2017-07-03 21:29:33.590 debug inMem message kecontact.0.* kecontact.0.eTotal val=0, ack=true, ts=1499110173534, q=0, from=system.adapter.kecontact.0, lc=1498491663482 kecontact.0 2017-07-03 21:29:33.589 debug inMem message kecontact.0.* kecontact.0.ePres val=0, ack=true, ts=1499110173533, q=0, from=system.adapter.kecontact.0, lc=1498491663481 kecontact.0 2017-07-03 21:29:33.588 debug inMem message kecontact.0.* kecontact.0.pf val=0, ack=true, ts=1499110173532, q=0, from=system.adapter.kecontact.0, lc=1498491663472 kecontact.0 2017-07-03 21:29:33.581 debug inMem message kecontact.0.* kecontact.0.p val=0, ack=true, ts=1499110173532, q=0, from=system.adapter.kecontact.0, lc=1498491663446 kecontact.0 2017-07-03 21:29:33.580 debug inMem message kecontact.0.* kecontact.0.i3 val=0, ack=true, ts=1499110173531, q=0, from=system.adapter.kecontact.0, lc=1498491663444 kecontact.0 2017-07-03 21:29:33.578 debug inMem message kecontact.0.* kecontact.0.i2 val=0, ack=true, ts=1499110173530, q=0, from=system.adapter.kecontact.0, lc=1498491663443 kecontact.0 2017-07-03 21:29:33.577 debug inMem message kecontact.0.* kecontact.0.i1 val=0, ack=true, ts=1499110173529, q=0, from=system.adapter.kecontact.0, lc=1498491663430 kecontact.0 2017-07-03 21:29:33.559 debug inMem message kecontact.0.* kecontact.0.u3 val=0, ack=true, ts=1499110173528, q=0, from=system.adapter.kecontact.0, lc=1498491663419 kecontact.0 2017-07-03 21:29:33.539 debug inMem message kecontact.0.* kecontact.0.u2 val=0, ack=true, ts=1499110173522, q=0, from=system.adapter.kecontact.0, lc=1498491663410 kecontact.0 2017-07-03 21:29:33.534 debug inMem message kecontact.0.* kecontact.0.u1 val=0, ack=true, ts=1499110173512, q=0, from=system.adapter.kecontact.0, lc=1498491663399 kecontact.0 2017-07-03 21:29:33.509 debug Unknown value received: ID=3 kecontact.0 2017-07-03 21:29:33.508 debug ' kecontact.0 2017-07-03 21:29:33.508 debug } kecontact.0 2017-07-03 21:29:33.508 debug 'Sec': 2365386 kecontact.0 2017-07-03 21:29:33.508 debug 'Serial': '17501302', kecontact.0 2017-07-03 21:29:33.508 debug 'E total': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'E pres': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'PF': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'P': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'I3': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'I2': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'I1': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'U3': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'U2': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'U1': 0, kecontact.0 2017-07-03 21:29:33.508 debug 'ID': '3', kecontact.0 2017-07-03 21:29:33.508 debug UDP datagram from 192.168.0.11:7090: '{ kecontact.0 2017-07-03 21:29:33.506 debug Sent 'report 3' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:33.506 debug Sent 'report 2' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:33.506 debug Sent 'report 1' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:33.505 debug Sent 'i' to 192.168.0.11:7090 kecontact.0 2017-07-03 21:29:33.347 debug UDP broadcast server listening on 0.0.0.0:7092 kecontact.0 2017-07-03 21:29:33.346 debug UDP server listening on 0.0.0.0:7090 kecontact.0 2017-07-03 21:29:33.321 info starting. Version 0.0.2 in /opt/iobroker/node_modules/iobroker.kecontact, node: v4.8.3 kecontact.0 2017-07-03 21:29:33.274 debug statesDB connected kecontact.0 2017-07-03 21:29:33.213 debug objectDB connected kecontact.0 2017-07-03 21:29:29.749 info terminatingSetzen des Wertes curr

Werden Werte < 6000 oder > 32000 eingegeben kommt keine Warnung, sondern auch TCH-OK: done
Broadcasts
Ändert sich an der Box ohne Steuerungen durch iObroker etwas (z.B. der Taster zum ein/ausschalten der Ladeerlaubnis wird getätigt)
schickt die Box ein Broadcast raus. Das sieht dann so aus:

hier müsste dann auf ein Broadcast von der Box reagiert werden (mit Abfrage der Reports 2 und 3). Ich habe das in meinem Skript nicht hinbekommen das ging irgendwie nur indem ich auf Port 7092 gelauscht habe:Leider kann ich nicht sagen was beim Laden so an Daten kommt - da sich der Liefertermin des Autos leider auf Anfang August verschoben hat ;(
Gruß
Olli
Kann man über die Hercules Setup Routine auch ein script starten?
-
Kann man über die Hercules Setup Routine auch ein script starten?
Hallo zusammen,
ich habe total vergessen hier zu erwähnen, dass der Adapter nun in der Tester-Rubrik zum Testen und Kommentieren gepostet wurde.
Das ist der erste Schritt auf dem Weg zu einem "offiziellen" Adapter, der dann direkt in ioBroker gefunden und installiert werden kann.
Weitere Diskussionen sollten wir dann dort weiterführen.