EEBUS Schnittstelle

[openWB]

Autos können übrigens kein eebus. Wenn ist die wallbox hier der Übersetzer.

Ich vermute das wegen der weitreichenden Unterstützung die openWB so erfolgreich ist

Im PV Sektor hat das mit SunSpec übrigens auch schon erfolgreich nicht geklappt.

[aiole]

Ich gebe dir schon Recht, aber nur via EEBUS bekommt man so viele unterschiedliche IoT Geräte auch namenhafter Hersteller unter einen Hut.

So der Nutzerwunsch. Die Praxis sieht anders aus.

Ob E/Hybrid-Autos, Wärmepumpen, WR, Batteriespeicher und alle anderen smarten Verbraucher. Sieh dir doch mal an wie unterschiedlich die Protokolle und vorgehnsweisen im OpenWB Code sind um diese ganzen Sockets abzudecken. Dies alles nur weil jeder sein eigenes Süpchen kocht und es keinen einheitlichen und verbindlichen Standart gibt

Es gab schon etliche Versuche allgemeingültige Standards zu platzieren. Das hat nie richtig funktioniert und ich glaube auch nicht, dass es mit EEBUS funktionieren wird. Kaum ein Hersteller hat Interesse an "übergreifender" Nutzung.

Ein DIN-Vertreter hat uns mal ähnliches geschrieben. Bei DIN-Normen geht es nicht um den max. Nutzen für die Gesellschaft, sondern um die der (zahlenden) Interessensverbände.
Ich kenne noch etwas DDR. Dort waren Standards extrem wichtig und genau anders herum definiert (zum Wohle des Volkes). Die wurden akkurat eingehalten und stetig verbessert. Das war wirklich erstklassig und sie standen kostenfrei zur Verfügung. Hat nur mit der DDR selbst nicht funktioniert .

OpenWB geht den Weg deutlich nutzerfreundlicher. SW-Module, die das beste aus den Herstellerwelten zusammenbringen. Das ist 10x nutzbringender für den Anwender als die Träume von Standards, die nie alle zu 100% befolgen. Bei oWB kannst Du heute schon kräftig mischen - Smartmeter von A, WB und Speicher von B, nur bei der WB sollte man fairerweise auf C = oWB gehen, weil diese das Ganze finanziert.

btw
Ist EEBUS eigentlich an Cloud gebunden oder geht das auch lokal?

[Maxify23]

Danke für den Hinweis.

EEBUS läuft auch Lokal. Es gibt von KEO und Bosch jeweils Stacks dafür. Einmal Client und einmal Server Stacks. Wäre interessant wenn man das als Hybriedclient in die OpenWB implementieren könnte. Würde zumindest dann den SunnyHome Manager als Client Stack mit PV/Batterie und Autoladedaten versorgen oder Wärmepumpen als Serverstack mit den Daten zur effezienten Nutzung.

Unabhängig von OpenWB:

Habt ihr den eine Idee wie man eure Daten (PV und Batterie) sinnvoll in EEBUS konvertieren kann, damit meine Wärmepumpe von Nibe oder Wolf damit arbeiten kann.

Quasi als Konverter für alle von OpenWB unterstützen Geräte ?? (ähnlich wie es der Sunny Home Manager oder Kostal WR machen )

[hominidae]

...wenn es einen übergreifenden, offenen IoT Standard zum Datenaustausch gibt, dann MQTT und das kann die openWB.
Kann der EEBus einen MQTT-Broker bereitstellen, oder zumindest einen MQTT-Client nutzen?
Evtl. auch mit einer Node-Red Instanz als Bridge?
Für Node-Red gibt es jetzt nicht so viel von EEBus, aber KNX ist zahlreich vertreten: https://flows.nodered.org/search?term=knx

[Der-Kieler]

OpenWB geht den Weg deutlich nutzerfreundlicher. SW-Module, die das beste aus den Herstellerwelten zusammenbringen. Das ist 10x

O.K., EEBUS seht Ihr keine Notwendigkeit.

Dann habe ich eine Frage: Welche Waschmaschine und welchen Geschirrspüler könnt Ihr nennen (oder vielleicht sogar empfehlen?), der "Smart" von der openWB gesteuert werden könnte (anschaten, wenn genügend Strom da ist - mehr möchte ich ja gar nicht)? Ich hatte mir Siemens angeguckt, da ich in den letzten 30 Jahren immer gute Erfahrungen gemacht habe, aber die unterstützen EEBUS.

Eine Lösung die Waschmaschine zu programmieren und dann den Strom zu unterbrechen, der dann durch Shelly o.ä. wieder angeschaltet wird ist nur etwas für Nerds. Ebenso ist das Programmieren einer Startzeit am Gerät nicht zielführend (wird einfach nicht gemacht von der Familie). Beides ist einfach nicht WAF kompatibel. Und so verkommt unser Solarstorm im Netz (zumindest tagsüber, wenn das Auto unterwegs ist).

Bin gespannt auf Vorschläge.

[FosCo]

NodeRed als Steuerung (oder FHEM, openhab, iobroker), Daten der openWB über MQTT abgreifen und los geht's.

Ich persönlich bin froh, wenn die OpenWB den Fahrzeugfokus behält und ausbaut, die smarthome Sachen sind imho (!) eine andere Domäne.

Natürlich mit den sauber dokumentierten Daten der openWB zusammen. Die Stromzähler Werte sind z.b. bei der openWB kritisch, der FHEM zeigt nur an, also hole ich mir die demnächst nicht mehr direkt von discovergy aus dem FHEM heraus, sondern von der openWB, aber das ist Optimierung.

[Der-Kieler]

Danke @FosCo!
Ich habe gerade im Forum den Thread "Smarthome 2.0 Anlauferkennung" gefunden. Wow, das ist ja mal ein klasse Lösung, den dazu muss ich nicht mal Maschinen austauschen (oder warten, bis sie kaputt sind).

viewtopic.php?f=11&t=3430&p=36349&hilit ... ome#p36349

[FosCo]

Der usecase ist auch meiner, zum Glück funktioniert das zeitgesteuert (aktuell 8:30 Spülmaschine, Waschmaschine eh tagsüber) einstellen mit der Familie und die Geräte sind "doof", daher habe ich vielleicht grade nicht den usecase.

[mattberlin]

Hallo,

wie ist das nun mit dem EEBus, wenn man bspw. einen SMA Home Manager hat?

Wie kann man die openWB in Abhängigkeit der Stromerzeugung der eigenen PV-Anlage steuern, wenn diese den EEBus hat?

Ganz konktet geht es um eine Home Manager von SMA.

[holgerwolf]

Das schließt sich doch nicht aus. Ich steuere die Spülmaschine auch über den EEBus vom SHM. Was an Strom übrig bleibt packt die OpenWB ins Auto.
Es geht halt nur eine umgekehrte Priorisierung nicht (also erst Auto und dann Spüler). Aber das macht wegen der langen Laufzeit der Spülmaschine auch keinen Sinn. Das Auto ist da viel flexibler.