Jump to content

rtrbt

Administrators
  • Content Count

    570
  • Joined

  • Last visited

  • Days Won

    22

Posts posted by rtrbt

  1. On 2/19/2021 at 7:21 PM, SimRa said:

    über welchen Zeitraum wird hier gesprochen?

    1 Woche, 1 Monat,.. ? 

    Mindestens einen Monat, eher etwas länger. Der aktuelle Schlachtplan ist für die Wallbox (neben 100 kleineren Dingen) eine Zeitschaltung und Lastmanagement über OCPP zu implementieren. Wenn das weg ist und danach nicht neue dringende Featurewünsche auflaufen, kann ich vermutlich Zeit einschieben, die angefallenen aber unfertigen Projekte zu beenden, heißt openHAB- und C/C++-für-Mikrocontroller-Bindings.

    Aktuell ist aber die Wallbox das was mit Abstand am höchsten priorisiert wird.

    On 2/19/2021 at 7:21 PM, SimRa said:

    Seit Openhab3 kann man die Installation auf Openhab2-Kompatibilität stellen. Soweit ich das richrig verstanden habe.

    Das klingt interessant, gibt es da Dokumentation zu? Ich habe beim spontanen suchen nichts gefunden.

    On 2/19/2021 at 7:21 PM, SimRa said:

    Würde das gerne wissen, um zu entscheiden, on ich mir die Mühe machen muss, unnötige zusätzliche Hardware zwischen openhab3 und die Wetterstation einzubinden.

    Bevor du da Hardware draufwirfst: Du kannst notfalls den Weg über die (Tinkerforge-)MQTT-Bindings und das (openHAB 3-)MQTT-Binding gehen. Ist nicht ganz so komfortabel wie ein natives Binding, aber immerhin.

  2. On 2/20/2021 at 1:41 PM, Jhonny said:

    ist das dann nach Implementierung auch bei der warp smart verfügbar, oder ist man in jedem Fall auf die pro angewiesen?

    Die Smart bekommt das auch: Das Lastmanagement wird in jedem Fall darüber laufen, wie viel Strom man dem angeschlossenen Auto erlaubt zu laden, nicht darüber wie viel es tatsächlich zieht. (Sonst müsste man sich ja darauf verlassen, dass die Ladeelektronik nicht spontan das dreifache zieht)

  3. Wenn du nochmal testest, dann am Besten mit der Firmware 1.1.0, macht ja keinen Sinn alte Bugs zu jagen. Ich hätte aber auch erwartet, dass es mit der 1.0.1 funktioniert. Falls es mit der 1.1.0 auch nicht tut, häng mal Debug-Report und Event-Log an, vom Debug-Report am besten einen bevor das Auto dransteckt und einen während das Auto dransteckt aber nicht von alleine anfängt zu laden.

  4. Moin,

    On 2/14/2021 at 10:54 AM, StefanOHAN said:

    Ja die Button und Slider sind mit Rule verknüpft und diese funktionieren auch. Neben den 3xTab sind auf dem „Startbildschirm“ des LCD128x64 2xButton konfiguriert. Der eine Button ruft eine Rule zum Neuaufbau des LCD-Screen auf. Dieser wird dadurch komplett gelöscht und anschließend 2xSlider konfiguriert (dies funktioniert). Die beiden Slider zeigen Ihre Rückgabewerte auf dem LCD128x64 an. Wenn die Slider von rechts nach links bewegt werden, werden die entsprechend geänderten Rückgabe-Werte am Display angezeigt. Einzig die Tabs reagieren nicht.

    Das ist sehr interessant, vorallem in Kombination mit dieser Aussage:

    On 2/11/2021 at 9:27 AM, StefanOHAN said:

    Egal welchen TAB ich berührte (es sind 3 Stück konfiguriert), es änderte sich nichts an der Darstellung auf dem Display.

    Da du das nichts so betonst: Meinst du mit nichts auch, dass das hier.

    Quote

    dass sich beim berühren eines Tab die Ihm umranden Linie nach oben „öffnet“ ?

    nicht ging?

    Dann wäre das ein reines Problem des LCD 128x64 und komplett unabhängig von openHAB. Das würde das Debuggen extrem vereinfachen.

    On 2/14/2021 at 10:54 AM, StefanOHAN said:

    Frage: Kann es sein, dass man das LCD-Thing nicht im Log sieht, da es am PI2 über ein HeadBrick angeschlossen ist (und nicht am "OpenHAB"-Pi3), und dieser PI2 über das Netzwerk mit dem zugehörigen BrickDämon auf dem "OpenhHab"-PI3 kommuniziert ?

    Nein, das sollte aus openHAB-Sicht keinen Unterschied machen. Eventuell sind aber die Threadnamen verquer und ich habe das deshalb nicht gesehen.

    On 2/14/2021 at 10:54 AM, StefanOHAN said:

    Frage: Nachdem das LCD nicht an dem PI3 mit der OpenHab-Installation angeschlossen ist, gibt es andere Log-Quellen des PI2 die Dir helfen könnten ?

    Das hängt stark von der Antwort auf meine erste Frage ab. Wenn die Tab-Leiste korrekt gezeichnet wurde, wäre /var/log/brickd.log des Pi 2 interessant.

    Übrigens ein cooler Aufbau, damit sollten sich alle absurden Verbindungs-Bugs finden lassen :D

  5. Moin,

    Wenn du den Master Brick per USB anschließt und dann den Brick Viewer auf localhost verbindest, kannst du im Master Brick-Tab auf Show Status klicken. Sieht der Client-Status da soweit okay aus? (Status: Got IP, eine sinnvolle Signalstärke usw.) Mach am besten mal Sceenshots von sowohl der Konfiguration, als auch dem Status.

    Was ist das für ein Netz, zu dem sich die Extension verbinden soll? Ein "normales" durch WPA2-PSK gesichertes oder eher Eduroam ö.Ä.?

    Funktioniert es, die Extension anzupingen?

  6. Moin Stefan,

    (Das Problem hatten wir ja schonmal, sorry falls ich gerade Dinge doppelt frage)

    On 2/11/2021 at 9:27 AM, StefanOHAN said:

    Die Buttons und die Slider funktionieren noch.

    Reagierst du auf die Buttons und Slider auch mit Rules und wenn ja funktionierten die auch? D.h. waren nur die Tab-Wechsel kaputt und alles andere funktionierte noch?

    In dem Log sind ein paar Dinge interessant:

    • Ich sehe keine ThingHandler, eventuell übersehen ich da aber gerade etwas. (Thing kommt nicht vor, das ist sehr suspekt) Welche openHAB-Version ist das?
    • Ich sehen drei Brickd-Receiver Threads (und auch Callback-Processor- und Disconnect-Prober-Threads). Hast du drei Brick Daemons konfiguriert oder ist das kaputt?
  7. 6 hours ago, Photon_1978 said:

    Aber so einen groben Stand der Dinge wäre schon echt cool zu erfahren.

    Der aktuelle Stand ist, dass wir alle daran arbeiten, die vorbestellten Boxen zu bauen und zu verschicken. Wenn da Zeitlücken sind arbeite ich an der Firmware. Voraussichtlich wird das erste größere Feature, dass ich einbaue eine Zeitschaltung, danach geht es an die Implementierung des Lastmanagements. Da gibt es aber noch viele Entscheidungen zu treffen, wie das genau funktionieren wird, z.B. ob man gleich auf OCPP geht, oder erst eine Implementierung schreibt, die nur zwischen unseren Boxen funktioniert. Auf jeden Fall wird das aber eine reine Softwareimplementierung und die Boxen werden über WLAN miteinander kommunizieren.

    • Thanks 2
  8. On 2/5/2021 at 7:26 PM, poohnet said:

    Oder bezog sich die Aussage auf den Einbau des SDM630 in die Box?

    Ja tat es.

    On 2/5/2021 at 7:26 PM, poohnet said:

    Mein Plan wäre, den in der Verteilung vorhandenen SDM630 für die Wallbox zu verwenden und parallel zum Strom- auch ein CAT-Kabel für das RS485-Bricklet zu verlegen.

    Das sollte funktionieren. Du musst dann nur das RS485-Bricklet und das CAT-Kabel in die Box bauen. Die Smart (also ohne eigenen Zähler) hat aber keine Befestigungslöcher für das Bricklet. Falls du eine Box bestellst könnte man da aber eventuell was machen ;)

  9. Moin,

    On 2/4/2021 at 12:38 PM, poohnet said:

    ist es möglich, den WARP Charger Pro mit einem SDM630 Modbus-Zähler (anstelle des SDM72D) zu bestellen

    Stand jetzt nicht. Ob das künftig kommen wird weiß ich nicht, aber dann würden wir noch mehr Varianten fahren als jetzt schon. Ich halte das deshalb zumindest kurzfristig für eher unwahrscheinlich.

    On 2/4/2021 at 12:38 PM, poohnet said:

    könnte der WARP Charger Smart auch mit einem (bereits vorhandenen) SDM630 kommunizieren?

    Das habe ich gerade getestet, das sollte funktionieren. Du brauchst dann aber noch ein RS485-Bricklet und musst die ganze Verkabelung in der Box ändern.

    Offiziell unterstützt wird das von uns nicht. Die Modbus-Register der Zähler (zumindest die, die die Wallbox ausliest) scheinen kompatibel zu sein.

  10. Moin,

    Am einfachsten wäre es, wenn du pro Wägezelle ein Load Cell Bricklet nimmst. Du kannst theoretisch auch mehrere Wägezellen parallel schalten (siehe z.b. diese Diskussion) das scheint aber nicht ganz so einfach zu sein, sowohl mechanisch, als auch von der Messgenauigkeit her.

  11. Moin,

    Der Master Brick hat zwei Knöpfe neben dem USB-Anschluss: Erase und Reset. Wenn du (während der Brick angeschlossen ist) Erase gedrückt hältst, Reset drückst und dann Erase wieder los lässt, sollte der Brick als serielles Device auftauchen. Du kannst dann mit dem Brick Viewer die aktuelle Firmware flashen.

    Das ganze wird hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing noch detaillierter erklärt.

  12. Moin,

    Das ist leider missverständlich formuliert, "openHAB 2.5.0 or newer" meint nur, dass weitere 2.5-Versionen (oder falls es 2.6 gegeben hätte das) problemlos funktioniert. Ich ändere den Text mal, damit das nicht so verwirrend ist.

    Die openHAB 3-Version dauert noch etwas, ich bin Stand jetzt noch gut mit der Wallbox beschäftigt.

  13. Um kurz die Zählerverwirrung zu klären: Ihr müsst zwischen der Versorgung des Zählers und der Messung unterscheiden. Der Zähler selbst muss dreiphasig versorgt werden, kann aber ungleiche Lasten auf den Phasen messen (damit auch den Extremfall "Auto lädt nur einphasig"). Das heißt eine Bastellösung, die zwei der drei Phasen hinter dem Zähler abschaltet würde meines Wissens funktionieren. Möglicherweise ist das aber nicht nötig, denn:

    20 hours ago, Docmac said:

    Wenn ich mit weniger als 4.2kW (PV) Leistung laden will, wechselt ein 3-phasiger Lader im Auto nicht von sich aus auf 1-phasig, sondern man muss dem Lader im Auto ein 1-phasigen Wechselstrom (230V) vorgaukeln.

    Das hier stimmt nicht unbedingt, bzw. hängt vom Fahrzeug ab: Bei den Zoes ist es z.B. so, dass (wie batti geschrieben hatte) der Lader im Auto ungefähr bei 8 Ampere auf einphasiges Laden wechselt. Wenn man das ausnutzt könnten also Ladungen < 4,2 kW darüber erreicht werden, dass dem Zoe nur 7 Ampere Ladestrom erlaubt werden. Das hat natürlich das Problem, dass es dann diesen Sprung bei ~ 1,8 kW (einphasig, also 8 Ampere) gibt wo der Zoe dann auf 3 Phasen wechselt und auf einmal ~ 5,5 kW zieht.

  14. Moin,

    Teste mal immer mit

    tinkerforge_mqtt --debug ... andere Flags

    Dann bekommst du mehr hilfreiche Ausgabe.

    Mich wundert folgendes:

    1 hour ago, Manuel Ziel said:

    Obwohl ich den Brocker schon länger, ohne SSL, auf dem Port 8883 laufen habe und nie den Port in tinkerforge_mqtt eingestellt habe hat es funktioniert

    Die Bindings verwenden als Default-Port immer die 1883, d.h. wenn du den Broker ohne Verschlüsselung auch auf der 8883 laufen hast, hätte das nie funktionieren dürfen, wenn du den Port nicht angibst. Teste bitte nochmal, wie das bei deaktiviertem TLS mit den Ports genau ist, also ob du, selbst wenn du in mosquitto.conf 8883 konfigurierst, du mit der Default-Einstellung der Bindings eine Verbindung bekommst. Dann wäre auch interessant, was passiert, wenn du explizit --broker-port 1883 oder --broker-port 8883 mitgibst.

    Die ganze SSL/TLS-Geschichte werde ich unabhängig davon in den nächsten Tagen hier nochmal durchtesten, bisher gab es da keine Beschwerden, aber auch kein positives Feedback, eventuell ist das also wirklich einfach kaputt und es hat bisher noch niemand gemerkt. Bis ich zum testen komme kann es aber noch etwas dauern, also durchaus erst nächste Woche oder so. Ich gebe Bescheid ;)

     

  15. Moin,

    Ich hatte dein Script falsch gelesen, eigentlich hätte ich schon sehen können, wo das Problem ist: Du hast im Script ja eine Endlosschleife und darin die for-Schleife, die die Spannungen durchgeht. Das Problem ist jetzt, dass nach einem Durchlauf der for-Schleife du auf eine Eingabe wartest und danach die Verbindung zum Brick Daemon schließt, dann aber wegen der Endlosschleife die nächste Runde Spannungssetzen machst, was aber nur klappt, wenn die Verbindung noch da ist.

    Du müsstest also die beiden letzten Zeilen aus der Schleife rausnehmen, wenn du die ganze Zeit die Spannungen durchlaufen willst, oder alternativ, wenn du immer auf einen Tastendruck warten willst vor der nächsten Runde lässt du das input("...") in der Schleife, dann würde ich aber den Text ändern, ist dann ja kein Exit mehr.

  16. Moin,

    Die MQTT-API steht soweit, ich bin gerade dabei sie zu dokumentieren. Ich bin optimistisch, dass das diese Woche fertig wird. Stand jetzt kannst du (neben nicht direkt ladebezogenen Dingen):

    • den aktuellen Zustand (ist ein Auto angeschlossen, wird geladen, usw.) auslesen
    • den Ladestrom in mA einstellen,
    • den Ladevorgang starten, stoppen und Autostart konfigurieren
    • Bei der Pro-Variante den Zähler auslesen

    Wenn du für deinen Anwendungsfall noch andere Features brauchst, wäre das sehr interessant zu wissen. Aktuell kann ich die API noch beliebig ändern, ohne dass ich funktionierende Software breche.

    OCPP wird mit der ersten Software-Version noch nicht kommen, Support dafür wird dann eins der Updates.

×
×
  • Create New...