Gauges

[guinnes]

Was für eine Heizung hast Du denn?

meine Heizung ist eine Vaillant Turbo Tec Classic. Es hat mehrere Jahre gedauert, die Therme an den eBus zu kriegen, immer wieder wurde mir erzählt " Das geht damit nicht ", bis der Regler angeblich kaputt war. Dann hieß es " den alten Regler gibts nicht mehr, Wir müßen einen neuen Regler einbauen und dafür ist noch ne Zusatzkarte nötig". Und Oh Wunder : Die Zusatzkarte stellt den eBus zur Verfügung. Informationen, welche Daten unter welchen Adressen zu holen sind, gibts aber immer noch nicht.

Ich habe hier auch eine Heizung am "Netz", allerdings M-Bus. Evtl. gibt es da ja Schnittmengen?

Könnte sein, aber dann muß ich die Therme MBus-fähig machen, und das wird bestimmt noch einmal Jahre dauern. Vaillant ist da "etwas" zögerlich, was Auslesen von Daten angeht

[violine21]

Meine Therme ist von Broetje.
Sorry, der Bus ist nicht M-Bus, sondern LPB/BSB.
Als ich mich nach einer Möglichkeit umgeschaut habe, bin ich auf ein LPB-Bus-LAN-Adapter gestossen, mit dem es tatsächlich auf
Anhieb funktioniert hat.
Ich erinnere mich, das die Thermensteuerung eigentlich von Siemens ist und nur umgelabelt wurde.
Evtl. ist das bei Dir auch der Fall?

Edit: Habe kurz gegoogelt:
z.B. e-Bus >>> LAN
https://www.esera.de/produkte/ebus/142/ ... r-ethernet
https://adapter.ebusd.eu/

[guinnes]

z.B. e-Bus >>> LAN
https://www.esera.de/produkte/ebus/142/ ... r-ethernet
https://adapter.ebusd.eu/

Meinen eBus-Adapter habe ich selber gebaut ( eBus-Adapter-2 ) und ich benutze einen Wemos zur Übertragung über den WLan. Soweit sogut, tut alles seit gut nem halben Jahr. EBusD hab ich probiert, der findet nur die Konfiguration für meinen Regler, nicht meinen Feuerungsautomaten. Die Software für den Wemos ist auch von dem John30, der auch EBusD geschrieben hat. Leider sind die Konfigurations-Files von EBusD noch undurchsichtiger als die JSON-Files vom eBus-Binding.
Wie gesagt, es tut, allerdings nur bis zur Version 2.5.8. Danach nicht mehr. Aber ich bin guter Hoffnung, das da noch was kommt, der letzte Snapshot ist 12 Tage alt, es tut sich also noch was

[udo1toni]

Was das ebus Binding betrifft, so handelt es sich ja um ein OH1 Binding.

Ich hab da folgendes Verzeichniss : org.openhab.binding.ebus-2.5.1-8, also gehe ich mal davon aus, daß das ein OH2-Binding ist.

Nein? Du kannst die beiden Sorten Bindings hinreichend darin unterscheiden, ob sie das Thing Modell verwenden. Musstest Du ein Thing anlegen? -> OH2 Binding. Musstest Du kein Thing anlegen? -> OH1 Binding. Gibt es eine *.cfg für das Binding unter services/? -> OH1 Binding.
Noch deutlicher wird es, wenn man in die Sourcen schaut, dort findet man unter https://github.com/openhab/openhab2-add ... .x/bundles keinen Eintrag für ebus, wohl aber in https://github.com/openhab/openhab1-add ... es/binding. Wie das Binding auf Dateiebene heißt, spielt hingegen nur eine untergeordnete Rolle.

Aufgrund deiner Antwort hab ich nochmal gesucht und das hier gefunden. Werd ich wohl demnächst mal probieren

Das sieht doch sehr gut aus! Es gibt also schon einen Entwickler, der das Binding portiert, auch wenn es noch nicht im offiziellen Repository angekommen ist.
Ich habe für Testzwecke immer eine Installation von openHAB zur Hand, die nicht produktiv genutzt wird. In so einer Testumgebung kannst Du das Binding manuell nachinstallieren (indem Du die *.jar in dem richtigen addons-Ordner ablegst). Da die Konfiguration zwischen OH1 und OH2 erheblich anders abläuft, bietet es sich an, das zunächst zu üben

Der Poll ergab nur einen Nutzer, was für die Entwickler leider wenig Dringlichkeit bedeutet.

Ich weiss ja nicht, was der Poll zählt, aber 1 ist sicher nicht richtig

Doch, das ist richtig. Der Poll ist natürlich schon alt, vom August 2019, vermutlich wäre es keine schlechte Idee, so einen Poll erneut durchzuführen (an prominenter Stelle), auf der anderen Seite werden ja durchaus auch solche Bindings portiert, die weit abgeschlagen in der Liste stehen, wie man am ebus Binding sieht.

[guinnes]

Du kannst die beiden Sorten Bindings hinreichend darin unterscheiden, ob sie das Thing Modell verwenden. Musstest Du ein Thing anlegen? -> OH2 Binding. Musstest Du kein Thing anlegen? -> OH1 Binding. Gibt es eine *.cfg für das Binding unter services/? -> OH1 Binding.

Es stehen 4 Things in der JSONDB : Eine Bridge und 3 weitere Things. ( Also doch 2.x )
Es gibt aber auch eine *.cfg-Datei (Also doch nicht 2.x ? ) ( Diese cfg-Datei ist für die Interpretation der eBus-Telegramme zuständig bzw werden in dieser cfg-Datei die JSON-Dateien angegeben, die die Interpretation vornehmen ).
Diese Datei war ein Quell der Freude, weil sie binding.ebus.cfg heissen muß, was aber nicht beschrieben war. Den Namen hab ich dann Tage später im Quelltext des Bindings gefunden ( soviel zu "Alles steht irgentwo, man muß es nur finden")

Noch deutlicher wird es, wenn man in die Sourcen schaut, dort findet man unter https://github.com/openhab/openhab2-add ... .x/bundles keinen Eintrag für ebus, wohl aber in https://github.com/openhab/openhab1-add ... es/binding. Wie das Binding auf Dateiebene heißt, spielt hingegen nur eine untergeordnete Rolle.

Da hab ich das Binding auch garantiert nicht her.

Das sieht doch sehr gut aus! Es gibt also schon einen Entwickler, der das Binding portiert, auch wenn es noch nicht im offiziellen Repository angekommen ist.

Der hat auch das von mir verwendete Binding geschrieben

Ich habe für Testzwecke immer eine Installation von openHAB zur Hand, die nicht produktiv genutzt wird. In so einer Testumgebung kannst Du das Binding manuell nachinstallieren (indem Du die *.jar in dem richtigen addons-Ordner ablegst). Da die Konfiguration zwischen OH1 und OH2 erheblich anders abläuft, bietet es sich an, das zunächst zu üben

So eine Testumgebung hab ich natürlich auch ( sowohl eine mit 2.5.8 als auch seit neustem eine mit 3.0.1 ). Aber das eBus-Binding kann ich da nicht testen, da ich die eBus-Telegramme über WLan übertrage, und scheinbar kann sich immer nur ein Teilnehmer einloggen und erhält die Daten. Da der eBus aber schon produktiv läuft, geht das so erst mal nicht. Ich habe überlegt, das Interface ( Hardware ) zu modifizieren, aber das muß warten, bis die Heizperiode vorbei ist

Doch, das ist richtig. Der Poll ist natürlich schon alt, vom August 2019, vermutlich wäre es keine schlechte Idee, so einen Poll erneut durchzuführen (an prominenter Stelle), auf der anderen Seite werden ja durchaus auch solche Bindings portiert, die weit abgeschlagen in der Liste stehen, wie man am ebus Binding sieht.

Wenn du mal in die Foren ( z.b community.openhab.org ) schaust, an Diskussionen über das Binding sind etliche Leute beteiligt und das auch schon länger, da ist es doch sehr unwahrscheinlich, das die Leute darüber diskutieren, aber das Binding noch nicht instelliert haben

Aber egal, vielen Dank für deine Anmerkungen, es ist immer lehrreich

[udo1toni]

Da hab ich das Binding auch garantiert nicht her.

Das hast Du irgendwie nicht erwähnt, oder habe ich das nur überlesen?

scheinbar kann sich immer nur ein Teilnehmer einloggen und erhält die Daten.

Na, aber die Konfiguration sollte ja dennoch erstellt werden können. Ich gehe nicht davon aus, dass Autodiscovery oder Autoconfiguration hier funktionieren.
Ein paar Minuten Umschalten auf das neue Binding sollten ebenfalls drin sein, um die grundsätzliche Kommunikation zu testen

Wenn du mal in die Foren ( z.b community.openhab.org ) schaust, an Diskussionen über das Binding sind etliche Leute beteiligt und das auch schon länger, da ist es doch sehr unwahrscheinlich, das die Leute darüber diskutieren, aber das Binding noch nicht instelliert haben

Ich bezweifele ja gar nicht, dass das Binding eingesetzt wird. Im verlinkten Poll haben insgesamt vielleicht 200 Leute abgestimmt (das ist etwas schwer zu schätzen, ich habe auch keine Lust die ganzen Daten manuell auszuwerten...) Zu der Zeit gab es weltweit vermutlich schon mehr als 20.000 Installationen. Genaue Daten gibt es da halt nicht. Der Punkt ist aber, dass von denen, die abgestimmt haben, nur einer das ebus Binding verwendet hat. Deshalb ja auch der Hinweis, dass meiner Meinung nach ein neuer Poll sinnvoll wäre.

[guinnes]

Na, aber die Konfiguration sollte ja dennoch erstellt werden können. Ich gehe nicht davon aus, dass Autodiscovery oder Autoconfiguration hier funktionieren.

Natürlich gehen Autodiscovery und Autoconfiguration hier nicht. Aber um eine neue Konfiguration auszuprobieren, brauche ich die Verbindung und nicht nur ein paar Minuten, sondern schon länger. Aber das ist ja gar nicht das Problem, meine Konfiguration funktioniert ja, eben nur nicht ab der Version 2.5.10
Aber, wie gesagt, die Version 3 kommt für mich ( noch ) nicht in Frage, ich habe mich gestern den ganzen Tag damit beschäftigt und die Version 3.0.1 sieht doch noch sehr nach einem Alpha-Stadium aus.

[udo1toni]

die Version 3 kommt für mich ( noch ) nicht in Frage, ich habe mich gestern den ganzen Tag damit beschäftigt und die Version 3.0.1 sieht doch noch sehr nach einem Alpha-Stadium aus.

Ich bin auch noch nicht auf OH3 und will Dich gewiss nicht dazu überreden, aber wie Du zu der Einschätzung kommst, die OH3.0.1 sähe nach Alpha aus, kann ich nicht nachvollziehen. OH3 ist nicht nur offiziell stable, die läuft hier auf dem Testsystem schon seit Monaten (also noch vor offizieller Veröffentlichung) sehr stabil, ohne jegliche Abstürze, man kann alles so bedienen, wie beschrieben, es läuft sogar stabiler als OH2. Dass ich noch nicht umgestiegen bin, liegt vor allem an der fehlenden Zeit und vielen anderen Projekten, die einfach dringlicher sind.

[guinnes]

Ich bin auch noch nicht auf OH3 und will Dich gewiss nicht dazu überreden, aber wie Du zu der Einschätzung kommst, die OH3.0.1 sähe nach Alpha aus, kann ich nicht nachvollziehen

Stabil mag ja sein, aber fertig ist anders :

Bild1.jpg

1. In der 1. Anzeige ober hab ich einen Kopftext angegeben : Wird nicht angezeigt
2. Wo sind die Icons geblieben ?
3. Warum stehen die Wertformatierungen noch in der Anzeige, werden aber nicht verarbeitet ?
4. Mapping geht auch nicht
5. Was macht im unteren Abschnitt die einsame Anzeige unterhalb der Uhr ? Die ist mit den anderen zusammen eingefügt worden mittels "Add from Model"
6. Beim Aufruf von "Edit masonry layout" kommt nur ein leeres Fenster
7. Beim run eines Scriptes gibts keine Meldungen, obwohl das script nicht lauffähig ist
8. beim Erstellen eines scriptes kommt sofort eine Fehlermeldung : "ERROR:HANDLER"
9. Der "knop" zum einstellen eines Sollwertes ist völlig unbrauchbar
[/list]

Bild3.jpg

Ich habe mir nur einen sehr kleinen Teil des Gesammtpaketes angesehen, aber der Teil ist noch lange nicht benutzbar

[violine21]

4. Mapping geht auch nicht

Beim Mapping hatte ich am Anfang auch meine liebe Not. Bis ich durch Zufall mal den Cache gelöscht habe und dann festellen musste,
das es funktioniert.

Mapping_Scale.gif

Lass mal beim Mapping die eckigen Klammern weg. Die map-Datei liegt im transform-Ordner? Add-Ons sind auch installiert?
Nur der Vollständigkeit wegen
Ich habe mit Mapping, Scale, Javascript etc. absolut keine Probleme (siehe Windrichtung).