rtrbt
-
Gesamte Inhalte
1.411 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
130
Posts erstellt von rtrbt
-
-
Da der Wunsch nach der NFC-Aufrüstung schon mehrfach kam: Ich will nichts versprechen, aber theoretisch sollte NFC mit Einschränkungen auch mit WARP 1 funktionieren. Was nicht gehen wird ist der Ladestop per Tag, weil der Knopf bei WARP 1 nicht deaktiviert werden kann.
-
Die Doku zu den Remote-openHAB-Binding sagt zumindest, dass es genau für solche Fälle da ist. Ich habe aber keine Ahnung wie viel Aufwand es ist das Binding einzurichten. Im RED-Brick-Image ist aber vermutlich auch eine ältere openHAB-Version, die müsstest du von Hand aktualisieren.
Eventuell wäre folgendes einfacher: Die Tinkerforge-Bindings selbst können sich zu einem Brick Daemon verbinden, der nicht lokal läuft, sondern über das Netzwerk. D.h. du könntest da, wo OH3 bei dir läuft, OH2 daneben installieren, dich mit dem Binding zum RED-Brick verbinden (auf dem dann nur der Brick Daemon läuft) und es sollte funktionieren. Ich würde auch erwarten, dass die Performance dann besser ist: Der RED-Brick ist immerhin nur so schnell wie ein Pi 1, openHAB läuft auf dem Brick eher gemächlich.
-
Moin Stefan,
13 hours ago, stif said:ich verwende einen Olimex ESP32-Poe: bei diesem Board sind die Standard ESP32 GPIOs für VSPI bzw HSPI nicht vollständig herausgeführt. Wie kann ich die SPI Pins remappen? muss dafür das HAL umgeschrieben werden?
Du meinst die Pins die nicht Chip-Select sind? Die musst du im HAL selbst umbiegen, ja. Du kannst dir in hal_arduino_esp32.cpp in folgendem Block:
if (uses_hspi) { hal->hspi = SPIClass(HSPI); hal->hspi.begin(); } if (uses_vspi) { hal->vspi = SPIClass(VSPI); hal->vspi.begin(); }die Pins in den Begin-Aufruf reinpatchen, z.B. so:
hal->hspi.begin(CLK_PIN, MISO_PIN, MOSI_PIN);wenn du nur HSPI oder VSPI umbiegst, musst du dann in deiner ports.h alle Ports auf das entsprechende SPI setzen.
13 hours ago, stif said:Wie finde ich die UID des HAT Zero heraus? muss ich dafür eine SD Karte aufsetzten und den BrickViewer auf einem RaspberryPiZero installieren oder geht das auch irgendwie anders?
Das HAT Zero (übrigens auch das große HAT) sind im Endeffekt eine Schaltung + ein Bricklet. Es gibt einen Select-Pin am HAT-Stecker mit dem du mit dem Microcontroller auf dem HAT reden kannst (B-CS4 im Schematic, das ist Pin 22 bzw. GPIO 25 am Pi). Wenn du diesen Pin als normalen Port in deine ports.h packst, funktioniert das alles automagisch, du kannst dann also über tf_hal_get_device_info u.A. die UID abfragen.
13 hours ago, stif said:Und hat sonst noch wer Tipps und Tricks wie ich meine Code Struktur verbessern kann?
Weniger zur Codestruktur und mehr ein allgemeiner Hinweis: Du kannst dir die esp32-lib mal ansehen, da sind noch ein paar hilfreiche Konstrukte enthalten, wenn du z.B. Devices nach der Device-(Typ)-ID suchen willst oder Firmwares flashen o.Ä.. Die Lib ist aber darauf ausgelegt in einer Firmware wie der für unsere Wallbox eingesetzt zu werden, da musst du eventuell Zeug rauspatchen für Konstrukte die du nicht hast.
Grüße,
Erik -
Bei WARP 1 reicht es das automatische Laden abzuschalten. Der Taster kann das Laden nur abbrechen, nicht starten.
-
Moin,
Das ist leider garnicht so einfach: Die Wallbox weiß Stand jetzt nicht, wie spät es ist. Für ein paar der geplanten Features müssen wir NTP zur Zeitsynchronisierung implementieren, aber das ist noch Zukunftsmusik.
Deshalb kann ich erstmal nicht versprechen, dass es den Rückstellzeitpunkt so geben wird, geschweige denn wann. Ich behalte die Idee aber mal im Hinterkopf und komme darauf zurück, falls es sich ergibt.
-
Hi,
This is indeed possible with the C/C++ bindings for microcontrollers. However those are not finished yet. You can find the latest beta here:
Documentation is available here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_uC.html and here for the Voltage/Current Bricklet 2.0: https://www.tinkerforge.com/en/doc/Software/Bricklets/VoltageCurrentV2_Bricklet_uC.html
Links to the Bricklet-specific documentation are not generated yet, however you can use the documentation for the "normal" C bindings and then add a u before the last C like this:
https://www.tinkerforge.com/en/doc/Software/Bricklets/AirQuality_Bricklet_C.html
becomes
https://www.tinkerforge.com/en/doc/Software/Bricklets/AirQuality_Bricklet_uC.html
-
1
-
-
Damit ich das richtig verstehe: Du benutzt bereits die Python-Bindings für unsere Hardware, willst jetzt aber die MQTT-Bindings benutzen?
Im Endeffekt funktioniert das wie folgt: Die MQTT-Bindings machen nichts anderes als auf MQTT-Nachrichten zu warten und dann selbst die Python-Bindings aufzurufen. Deshalb müssen die MQTT-Bindings permanent als Programm laufen. Wenn du dann z.B. mit paho-mqtt folgendes machst:
mqttc.publish("tinkerforge/request/lcd_128x64_bricklet/AbC/get_identity", "")
legen die MQTT-Bindings intern eine Instanz von BrickletLCD128x64 an und rufen darauf .get_identity() auf. Das Ergebnis bekommst du auf das Topic
tinkerforge/response/lcd_128x64_bricklet/AbC/get_identityzurückgegeben.
Die Topics entsprechen 1:1 den Python-Bindings-Funktionsaufrufen.
-
On 8/10/2021 at 9:26 PM, hovoi said:
tinkerforge/callback/hat_zero_brick/Qcf/set_usb_voltage_callback_configuration
Das muss ein /request/ sein statt /callback/. Prinzipiell sind die /register/ und /request/-Topics die, auf die du publisht und /response/ und /callback/ die, auf die die Bindings publishen, also du subscribst.
-
There was indeed a bug in the streaming logic used by write_frame.
Does the attached version work on your side? If yes, the bugfix will be released with the next version of the bindings.
Cheers,
Erik -
Hm thats strange. What is the Python version that you are running the MQTT bindings with?
Please test again with the attached version of the bindings (and run the bindings with --debug ). I've added some details to the error message.
Edit: Nevermind I've just managed to reproduce the error. Let me take a look.
-
Hi Jérémie,
I've got two ideas:
- Did you change the UID from XYZ to the UID of your Bricklet? The UID is shown in Brick Viewer.
-
Please check the quoting of your payload:
11 hours ago, hdb3 said:
"'{"frame": [255,128,0]}' "
If you quote with " at the outer-most layer, you have to escape the innner " around frame. However then the single quotes are unnecessary. I'm not sure how this works in MQTT explorer, but I would assume the correct way to quote would be either
'{"frame": [255,128,0]}'or
"{\"frame\": [255,128,0]}"depending on support for single quotes in MQTT explorer.
If this does not help, my next question would be what version of the MQTT bindings you are running. Also you could check whether other functions work correctly. For example get_identity (does not require any parameters, i.e. you can just send an empty message).
Cheers,
Erik -
Das freut zu hören, danke!
@Jhonny Dein Edit hatte ich ganz übersehen, sorry. Aber gut, dass es bei dir funktioniert! Die Prüfung des Managers, ob die Clients richtig konfiguriert sind muss ich noch implementieren, es wird dann einen "Testen"-Button o.Ä. geben der die Konfigurationen abklopft. Für die UI auf der Statusseite habe ich ein paar Ideen, aber noch nichts spruchreifes.
-
1
-
-
21 hours ago, int5749 said:
- Wie erhalte ich eine Info über eine neue Version, oder wo kann ich nachschauen?
- Gibt es ein Update Log, was geändert wird? (Bugs, Enhancement, Improvements, etc)
Stand jetzt musst du auf warp-charger.com nachsehen: https://www.warp-charger.com/#firmware Da findest du auch das Changelog.
21 hours ago, int5749 said:Empfehlung, wer das Update durchühren sollte?
Solange nicht Beta dransteht, gerne jeder. Bei der Lastmanagement-Beta sollten die Grundfunktionen auch alle weiter funktionieren, der möglicherweise instabile Teil ist nur der neue, eben das Lastmanagement. (Aus meiner egoistischen Sicht sollte natürlich auch jeder die Beta testen, das erhöht die Wahrscheinlichkeit Bugs schnell zu finden ;) )
-
1
-
Ah ja, da bist du in einen sehr unschönen Bug gelaufen. Das Webinterface erlaubt keine Updates während ein Auto angeschlossen ist, weil unter Umständen im Update eine neue Ladecontroller-Firmware enthalten ist. Der Ladecontroller kann aber nur sicher geflasht werden, wenn kein Auto angeschlossen ist ist. Das Problem ist dann, dass die Anzeige für den Fehler nur ganz kurz, wenn überhaupt zu sehen ist (< 1 Sek.). Der Bug ist im Code schon gefixt, der Fix wird mit der nächsten großen Firmware-Version (1.3 oder der zweiten Lastmanagement-Beta) veröffentlicht.
-
2
-
-
Moin Michael,
42 minutes ago, kmfrank said:aber die neue Software wird nicht angezeigt.
Was meinst du damit genau? Das Webinterface wird noch geladen, aber die angezeigte Firmware-Version ist noch 1.2.3?
45 minutes ago, kmfrank said:Mit dem Android Handy habe ich es auch versucht, hier kann ich das Update auswählen aber ein hochladen geht nicht. Die Kästchen Firmware Aktualisierung und Duchsuchen sind hellblau umrandet, weiter geht es nicht.
Mit welchem Browser? Auf meinem Handy mit Firefox klappt es.
Lade dir von der Box mal Ereignis-Log und Debug-Report herunter und hänge beides hier an.
Grüße,
Erik -
On 7/24/2021 at 4:49 PM, Dosepower said:
Meine Frage was passiert wenn das Auto voll geladen ist in welchen Status geht die Wallbox?
Wieder in B bzw. 1 (IEC und vehicle state)
-
22 hours ago, Dosepower said:
gibt es eine Beschränkung wievielte anfragen man pro gewisse seit an die box senden kann?
Nicht direkt. Der Webserver auf der Box hat aber einige Stabilitätsprobleme, deshalb hat die Entwicklung des Lastmanagements so lange gedauert. Ich habe dann die Implementierung komplett ausgetauscht gegen eine, die direkt die Espressif-APIs benutzt und deutlich stabiler läuft. Wenn du das Problem reproduzierbar erzeugen kannst, teste mal bitte, ob es mit der Lastmanagement-Beta verschwindet.
-
10 hours ago, Hoich said:
Bei mir lädt der i3 auch an AC nicht mehr mit der vollen Leistung ab 9x% - die letzten Prozente scheinen sich ewig zu ziehen (es geht schon bis 100%, nur eben nicht in gleichbleibender Geschwindigkeit - an DC ist das Phänpmen viel deutlicher). Das wäre ein vergebener Slot.
Das ist leider so, ja. Am besten bekäme man das mit z.B. EVCC in den Griff, da sind die meisten Fahrzeug-APIs implementiert. EVCC könnte dann einfach 90% als Ladeziel ansetzen und danach die Wallbox stoppen, oder den Strom runterregeln. Das hieße auch, dass ich alle anderen Stromgrenzen berücksichtigen sollte, also auch die vom User oder von EVCC gesetzte. Ich setze mir mal auf die TODO-Liste damit zu experimentieren.
Die Idee mit der Strom- bzw. Leistungsmessung zu arbeiten ist gut, würde aber nur funktionieren, wenn alle Wallboxen einen Stromzähler haben. Wäre natürlich ein gutes Verkaufsargument für die Pro, da muss ich auch mal drüber nachdenken.
Danke für den Input!
-
11 hours ago, Hoich said:
Beziehst Du auch den aktuellen Ladestrom mit ein (also beim Pro oder auf anderem Weg gemessen - nicht das gesetzte Maximum)? Wenn das Fahrzeug voll ist oder langsamer lädt dann ist mehr zum Verteilen da.
Stand jetzt verteilt das Lastmanagement auf alle Boxen (die ladebereit sind) den gleichen Strom. D.h. ich ignoriere auch gesetzte Maximalströme auf den Boxen. Das ist noch auf meiner TODO-Liste (ich editiere es mal in die Liste der bekannten Bugs). Den aktuellen Ladestrom kann ich nicht einbeziehen, da den Wallboxen Informationen fehlen:
- Lädt ein Fahrzeug gerade nicht, weil es voll ist, oder weil es nach einem Zeitplan lädt oder die Batterie gerade zu heiß ist o.Ä.?
- Zieht ein Fahrzeug gerade nur (noch) z.B. 8 Ampere obwohl 16 zugeteilt sind, weil es fast voll ist oder auch wegen der Batterie? (Das macht einen Unterschied, weil das Auto dann jederzeit mehr Strom akzeptieren könnte, wenn ich ihn zuteile, es gibt aber keinen Kanal auf dem das der Wallbox und damit dem Lastmanagement mitgeteilt werden kann)
Die Stromgrenzen an der Wallbox, zumindest die "fixen" also Maximalstrom der Zuleitung und des Ladekabels, werden künftig auf jeden Fall berücksichtigt.
11 hours ago, Hoich said:Wie spielt das mit EVCC zusammen? (Ich habe EVCC seit heute am Start weil es einfacher war als ein eigenes Lademanagement für PV aufzusetzen, aber weniger Komponenten ist meist die bessere Lösung - aber dafür ist das Lastmanagement ja nicht gedacht - wobei PV-Überschuss zentral zu sehen wäre und nicht mehr an jede Wallbox gehen sollte).
Stand jetzt kannst du EVCC und das Lastmanagement parallel benutzen. Das Laden beginnt nur, wenn sowohl EVCC, als auch das Lastmanagement die Ladung freigeben und der Ladestrom ist das Minimum aus beiden. Im folgenden Bild siehst du, wie das genau funktioniert: Die Freigaben sind stufenweise, wobei wenn eine Freigabe weggenommen wird, alle die "danach" kommen auch wieder abgefragt werden. Also wenn der Lastmanager eine Ladung freigibt und später blockiert, kann er noch später die Ladung wieder freigeben, ohne dass der User (oder EVCC) gefragt werden, das Auto muss aber neu Strom anfordern (was typischerweise automatisch passiert). Wenn die User-Freigabe weggenommen wird, muss aber danach der Lastmanager (und das Auto) freigeben.
12 hours ago, Hoich said:Stellen die oben angegebenen Einschränkungen wirklich welche dar (also durch Austausch des Webservers)? Ich sehe gerade nichts was praktisch relevant wäre.
Als "normaler User" ist nur die Einschränkung bezüglich des Einloggens relevant. Der Rest ist betrifft nur Nutzer der HTTP-API.
12 hours ago, Hoich said:Wird es eine Art ‚Abrechnung‘ geben? Ich kenne hier das Projekt einer Garagenzeile die sich einen Stromanschluss teilen wollen. Wenn das Laden zentral gesteuert würde müsste auch irgendwo dokumentiert werden, wer wann wieviel Leistung bezogen hat.
Irgendetwas in die Richtung wird es voraussichtlich geben, da haben wir aber noch keine Details ausgearbeitet. Die einfachste Variante, wenn jede Garage bzw. jede Nutzergruppe die separat abgerechnet werden soll eine eigene Wallbox bekommt, wäre den WARP Charger Pro zu verbauen und dann über den Stromzähler abzurechnen. Da gibt es aber keine Hilfsfunktionen in der Software, man müsste also "händisch" die Zählerstände pro Abrechnungszeitraum abfragen (oder sich ein eigenes Script etc. dafür bauen).
12 hours ago, Jhonny said:Funktioniert das downgrade auf die Vorversion, falls was schief geht bzw instabil läuft?
Ja Downgrades sind möglich. Falls es da Probleme geben sollte, gib auf jeden Fall Bescheid.
2 hours ago, Schobi said:Ich kann leider noch nicht testen - "Lieferung Mitte August"
Ich höre über mir die Wallbox-Bauer, kurz: wir arbeiten daran ;)
-
Sorry, I've got no ETA yet. Everyone here is still focused on programming and building the chargers. The project is not dead, but don't expect a new version in the next few months.
-
Nein gibt es leider nicht, sorry. Das Projekt ist nicht tot, aber Stand jetzt liegt in der ganzen Firma klar der Fokus auf den Wallboxen. Ich gebe aber bescheid, wenn sich wieder etwas tut.
-
Moin,
tl;dr: Nach langem Warten gibt es (im Anhang) endlich die Beta-Version der Firmware mit Lastmanagement zwischen WARP Chargern. Das Lastmanagement stellt sicher, dass mehrere Wallboxen an einem Anschluss einen konfigurierten Ladestrom nicht überschreiten.
Weitere Neuerungen
Neben dem Lastmanagement habe ich die komplette Web-Server-Implementierung ausgetauscht. Der neue Web-Server läuft deutlich robuster als der alte, vorallem wenn noch weiterer Netzwerk-Traffic (wie das Lastmanagement oder MQTT) läuft.
Durch ein Update der verwendeten Bibliotheken beinhaltet die Firmware jetzt einen Patch für die kürzlich bekanntgewordenen WLAN-Sicherheitslücken FragAttacks. Details finden sich hier.
Auf der Statusseite wird jetzt angezeigt, warum das Ladestrom-Limit den aktuellen Wert hat.
Setup
Ihr könnt das Lastmanagement wie folgt testen:
- Die angehangene Firmware auf alle Wallboxen, die gesteuert werden sollen (Clients) und auf die Wallbox, die steuern soll (Manager), flashen
- Bei allen Clients und normalerweise auch beim Manager auf der Ladecontroller-Unterseite Lastmanagement aktivieren.
-
Beim Manager auf der Lastmanager-Unterseite:
- Alle Clients mit einem Anzeigenamen und der entsprechenden IP hinzufügen. Hier ist noch kein Neustart notwendig. Der Manager selbst ist bereits als "lokale Wallbox" angelegt.
- Den verfügbaren Ladestrom einstellen.
- Den Lastmanager aktivieren
- Neu starten
Wenn alles klappt, sollten die Clients jetzt auf der Statusseite des Managers angezeigt werden und das Lastmanagement sollte funktionieren.
Falls Probleme beim Lastmanagement auftreten, finden sich die Informationen, die dem Lastmanagemer bekannt sind als Low-Level-Zustand auf der Lastmanager-Unterseite und Informationen zu erfolgten Stromverteilungen im Event-Log. Die Clients zeigen den vom Lastmanager festgelegten Strom auf der Ladecontroller-Unterseite an.
Edit: Ein Downgrade auf eine ältere Firmware ist jederzeit möglich; im Idealfall auf die 1.2.4, die ich unter anderem veröffentlicht habe, damit der aktuelle Stand abzüglich der Lastmanagement- und Webserver-Änderungen verfügbar ist.
Bekannte Bugs und ProblemeDa das Lastmanagement wie unten beschrieben Strom zuweist, gibt es eine implizite Priorisierung nach der Konfigurationsreihenfolge. Das führt dazu, dass wenn weniger Strom zur Verfügung steht, als von allen ladebereiten Wallboxen benötigt wird, damit sie laden können (also weniger als 6 Ampere pro Box), werden immer die in Konfigurationsreihenfolge ersten Boxen Strom zugeteilt bekommen.
Die Lastmanagement-Konfiguration hat bisher kaum User-freundliche Überprüfungen. Künftig wird bei der Konfiguration und periodisch geprüft, ob alle Wallboxen im Lastmanagement-Verbund die selbe Firmware haben und die Konfigurationen korrekt sind. Außerdem können Wallboxen bisher nur über ihre IP hinzugefügt werden. Später werden auch Hostnamen unterstützt. Jede Wallbox zeigt ihre IP auf der Status-Seite hinter WLAN-Verbindung an.
Der neue Web-Server unterstützt folgende Features nicht mehr:
- Server-Sent Events: Stattdessen werden jetzt WebSockets verwendet um Events in das Webinterface zu übertragen.
- Login per Digest Authentication: In der Beta ist das Zugangsdaten-Modul deaktiviert, da es noch zu Bugs mit dem Web-Server führt. Ich arbeite an einer Lösung. Falls die Beta auf eine Wallbox geflasht wird, bei der Zugangsdaten für das Webinterface gesetzt sind, werden diese ignoriert. Nach einem Downgrade auf Firmware 1.2.4 wird das Modul automatisch wieder aktiviert. Bei einem künftigen Update auf die finale Version 1.3 sollte das genauso passieren.
- Handler für mehrere HTTP-Methoden: Die API reagiert in der Beta nur noch auf HTTP GET und HTTP PUT. PATCH und POST werden ignoriert.
Fehleranzeigen auf dem Webinterface werden sehr schnell gelöscht.
Die Status-Seite wird langsam unübersichtlich. Ich habe ein paar Ideen, wie man das Layout übersichtlicher gestalten kann, dazu später mehr.
Edit:
Das Lastmanagement ignoriert die Stromgrenzen der Zuleitung und Ladekabel. Das heißt wenn zum Beispiel zwei Boxen gesteuert werden, es stehen 32 Ampere zur Verfügung, eine der Boxen ist auf 12 Ampere konfiguriert und eine auf 32 Ampere, dann wird, wenn beide laden wollen, das Lastmanagement beiden Boxen 16 Ampere zuteilen, obwohl sinnvoller wäre 12 bzw. 20 Ampere zuzuteilen. In die andere Richtung ist es aber nicht schlimm, wenn nur der 12-Ampere-Box 32 Ampere zugeteilt werden (falls nur sie laden will): Die Wallbox selbst lädt nur mit dem Minimum aller Stromgrenzen.
Funktionsweise des Lastmanagements
Das Lastmanagement besteht aus zwei Komponenten: Einer Erweiterung der Ladecontroller-Firmware, sowie dem Lastmanager, der Strom verteilt.
Die Ladecontroller-Firmware hat neben dem Maximalstrom der Zuleitung bzw. des Ladekabels und dem konfigurierten Ladestrom jetzt ein viertes Stromlimit: das des Lastmanagements. Dieses vierte Limit wird nur berücksichtigt, wenn in der Ladecontroller-Unterseite Lastmanagement aktiviert wird. Der Ladecontroller hat neue API (evse/managed_current bzw. evse/managed_current_update) über den das Stromlimit festgelegt werden kann. Wenn eine Ladung beendet wurde, und wenn über einen längeren Zeitraum (30 Sekunden) kein managed_current_update empfangen wurde wird das Limit automatisch auf 0 A gesetzt. Damit die sehr häufigen Übertragungen effizienter sind, kann diese API auch über UDP benutzt werden.
Der Lastmanager benutzt die UDP-Variante der API um eine konfigurierte Menge Strom zu verteilen. Dazu schickt er regelmäßig den jeweils erlaubten Strom (anfangs 0 A) an Clients. Die Wallboxen beginnen daraufhin, dem Lastmanager regelmäßig ihren aktuellen Zustand zu übertragen. Aus diesen Informationen kann der Lastmanager erkennen, an welchen Boxen Fahrzeuge laden wollen und entsprechend Strom verteilen. Das passiert folgendermaßen:
- Ermitteln wie viele Boxen laden wollen
- Ermitteln des Ladestroms der dann jeder Box zur Verfügung steht (verfügbarer Strom / Anzahl ladebereiter Boxen)
- Begrenzen aller Boxen, die bereits laden
- Zuteilen des Stroms an Boxen die bereit sind, mit einer Ladung zu beginnen
- Blockieren aller anderen Boxen
Falls der Lastmanager feststellt, dass ein Client nicht mehr antwortet oder reagiert, stoppt er alle laufenden Ladungen und blockiert alle Boxen, bis das Problem behoben ist. Das ist notwendig, da bei gestörter Kommunikation nicht klar ist, ob die nicht erreichbare Box gerade lädt.
Ich freue mich wie immer über Feedback!
Erik
-
3
-
Moin,
On 7/2/2021 at 8:06 PM, drehstrom said:Kann ich mit dem Webinterface die Ladeleistung während des Ladevorgangs verändern?
Die Ladeleistung kannst du ändern, ja. Teilweise dauert es ein paar Sekunden bis die Autos darauf reagieren.
On 7/2/2021 at 8:06 PM, drehstrom said:Kann das Webinterface auch die Ströme der 3 Phasen anzeigen?
Nein, der Zähler, den wir verbauen, gibt nur Leistung und Energie summiert über alle drei Phasen aus.
-
On 6/28/2021 at 9:55 AM, rtrbt said:
Der aktuelle Zeitplan ist, dass ich Ende der Woche eine Beta-Version davon veröffentliche
Der Zeitplan hatte kurz Kontakt mit der Realität. Ich muss die Beta noch ~ eine Woche weiter schieben, sorry.
-
1
-
Betaversion der openHAB-Bindings
in Allgemeine Diskussionen
Geschrieben
openHAB kann sich auch zu WiFi Extensions verbinden. D.h.
openHAB3 <--> openHAB2 <--> Stack mit Master + Wifi Extension funktioniert auch ohne RED Brick, wenn du die openHAB2-Instanz auf dem selben Rechner laufen lässt wie die openHAB3-Instanz.