openhabforum.de

...so ist es. Hab mal Cache gelöscht. Danach musste ich dann mehrfach neu starten. Da kam erst mal "Salat" hoch. Da solltest du dich evtl. im internationalen Forum umschauen und evtl. den Entwickler kontaktieren.

In der Karaf-Konsole wurde das Binding aber angezeigt.:

..ich hab's bei mir schon wieder deinstalliert, aber ich habe hier noch was zur Einrichtung gefunden. Vielleicht hilft dir das weiter. Allerdings steht hier, dass man mit seinem "ewelink"-Account ein Thing erstellen muss.

Dieser Thread scheint auch noch interessant zu sein.

Ja in diesem thread war ich auch schon unterwegs aber ich komme da nicht mit wenn ich dieses Binding nicht zum Laufen bekomme.
Wenn du es in Karaf gesehen hast, dann war es doch schon da oder was bedeutet das?
Ich weiß nicht wirklich was Karaf ist und warum sieht man da was und anderswo nicht?

In die Karaf-Konsole kommt man mit "openhab-cli console". Das Standard-Passwort ist da "habopen". Mit dem Befehl "bundle:list" kannst du sehen, welche "bundles" installiert sind. Mit "bundle:list | grep -i sonoff" habe ich die Liste gefiltert (s. obigen Post).

So wie ich das verstehe, muss man aber erst ein Thing(Account) anlegen(manuell). Und das verbindet sich mit dem chinesischen Server. Darin wird auch festgelegt, wie der Zugriffsmodus ist (accessmode: your choice of mode for the binding (local,cloud,mixed)).

Ich hatte zwar mal einen Sonoff-Basic über die Cloud laufen, aber nur ganz kurz. Die App (ewelink) hab ich ganz schnell wieder verworfen. Meine ESP's sind alle mit Tasmota geflasht (ca. 25-30). Ich hatte auch schon ein paar mit ESPEasy am Laufen. Das geht auch ganz gut. Aber mit Tasmota läuft das ganz gut und ich möchte nicht so viele verschiedene Systeme laufen haben und dann natürlich auch aktuell halten müssen.

Wenn du aber mit ESP-Mikroprozessoren (ESP8266, ESP32) und Sensoren arbeiten willst, wirst du wohl um das Flashen nicht herum kommen. Und dann wird wieder MQTT die erste Wahl sein (Denke ich).

Ich habe alle sonoffs die mit Tasmota geflasht werden können auch geflasht und via mqtt eingebunden.
Wegen diesem ewelink Binding habe ich mir einige Sonoff dw2 WiFi Magnet Kontakte zugelegt.
So dachte ich kann ich auch solche nicht Tasmota ewelink devices einbinden.
Vielleicht gehe ich erst Mal auf oh3 dort scheint das mit diesem Binding besser supported zu sein, so verstehe ich das.
Jedoch scheue ich mich noch, da ich meine Rules anpassen muß, und das sind noch ein paar Fragezeichen für mich

Das mit den DSL-Rules ist m.E. nicht ganz so kritisch. Die kannst du nach wie vor als Text-Files benutzen. Das gilt übrigens auch für die anderen Konfigurations-Dateien. Es gibt halt einen wesentlichen Unterschied. -> Joda-Time wird Java-Time. Aber dazu findest du hier im Forum ziemlich viele Beispiele. Ich bin Step by Step (Binding/Konfiguration) umgezogen und habe dabei gleich die Funktionalität des jeweiligen SetUps testen können. Und bis auf Homematic(Fenster-Türkontakte/Wassersensor/Aussensensor) laufen bei mir alle Bindings parallel.

Ob das in OH3 besser wird mit dem Sonoff-Binding ?? Ich weiss nicht!!1 Ich nehme mal an, dass das der gleiche Installationsweg ist wie in OH2. Im Market-Place hab ich jedenfalls nichts gefunden.
Hast du schon mal probiert eine Sonoff-Bridge nach diesem Muster anzulegen ? Dann sollten eigentlich die Devices per Things-Scan gefunden werden. ich kann's leider nicht testen, da ich das Sonoff-Binding wieder deinstalliert habe und auch keine passenden Devices für den Scan habe..

Das Binding sollte halt schon unter den installierten Bindings gelistet werden, auch wenn es manuell hinzugefügt wurde. Mag aber sein, dass an dieser Stelle im Binding etwas nicht richtig funktioniert (immerhin taucht es ja in der Konsole auf).
Ich habe in meiner 5.2.12-Umgebung zwei manuell eingerichtete Bindings (http2 und vdr2), die tauchen ganz normal in der Liste auf, nur halt nicht unter den installierbaren Bindings, was aber auch nicht weiter verwunderlich ist, da sie nicht in der kar-Datei vorhanden sind.

Ich gehe stark davon aus, dass das sonoff Binding, wenn, dann eher für OH3 weiterentwickelt wird.
Zum Hintergrund: es gibt einige Abhängigkeiten, die in OH3 anders sind als in OH2. Deshalb muss das Binding immer in zwei Versionen kompiliert werden, um auf beiden Plattformen laufen zu können.
Außerdem meine ich, muss man ein paar Dinge dennoch anpassen. Aber die grundsätzliche Funktionsweise ist in beiden Versionen gleich, so dass das Binding eben nicht komplett neu entwickelt werden muss (im Unterschied zu OH1 -> OH3) - deshalb braucht man zwar neue *.jar, die aber quasi sofort zur Verfügung stehen, weil die Anpassungen trivial sind (also für einen Entwickler...).

Worauf ich hinaus will: Es kann sich durchaus lohnen, mal einen Test unter OH3 zu versuchen. Mein Tipp: Setze ein Testsystem auf und teste nur das eine Binding. Wenn Du es zum Laufen bringst, weißt Du, dass Arbeit auf Dich wartet (Umstieg), wenn nicht, kannst Du Dich erst mal entspannt zurücklehnen und abwarten - den Umstieg kannst Du natürlich trotzdem vorantreiben.

Hört sich sinnvoll an. Ich prüfe Mal noch mit Karaf ob sich bei mir da was zeigt in 2.5.12.

Ich weiß halt noch nicht wie ich auf OH3 wechseln soll!
Momentan läuft das bei mir auf einer SSD die entsprechend partitioniert ist, wo ich auch eine große Samba Partition als shared Drive verwende.
Das möchte ich mir mit einer Neuinstallation nicht zerschießen! Auf der anderen Seite würde ich gerne OH3 neu installieren, also den alten Gelumps nicht migrieren.
Wie bekomme ich das OH3 dann am besten auf meine SSD?
Wenn ich das per openhabian-config mache, nimmt er die alte config ja mit...

Ja, vorhandene Partitionen zu erhalten ist nicht trivial, auch, weil es verschiedenste Möglichkeiten gibt, wie die Partitionen organisiert sind.
Erst mal: Ohne komplettes Backup wäre es besser, die Partitionierung keinesfalls anzufassen. Wenn Du von 0 beginnen willst, sicherst Du Dir die alte Konfiguration (openhab-cli backup) und schiebst die zip-Datei an einen sicheren Ort Deiner Wahl. Danach deinstallierst Du openHAB und installierst es erneut. Mit apt purge werden auch alle Konfigurationsdateien entfernt (im Gegensatz zu apt remove).
Es kommt natürlich auch ein bisschen drauf an, wie Du das System überhaupt aufgesetzt hast. Basiert es auf openHABian? dann musst Du halt aufpassen, denn openHABian richtet ja selbst diverse Hilfsprogramme ein. Andererseits sollte es dann kein Problem sein, direkt ein openHAB Upgrade auszuführen. Du kannst anschließend nochmal mit sudo apt purge openhab && sudo apt install openhab die gesamte openHAB-Konfiguration verneichten.

Wichtig zu wissen: Zwar kannst Du Deine Textdateien weiter verwenden, Es kann aber gut sein, dass Du dennoch Anpassungen vornehmen musst, selbst wenn Du schon vor der Umstellung ausschließlich native (OH2) Bindings verwendet hast, da doch der Name des einen oder anderen Parameters geändert wurde (z.B. host statt Host oder host statt hostname/ip usw.)

Aus dem zip kansnt Du recht bequem die einzelnen Dateien einzeln an ihren Platz kopieren.

Ja ich benutze Openhabian. Wenn ich nun ein openhab-cli backup mache und dann ein Openhabian Standard Upgrade mache, habe ich dann irgendwelche Nachteile? Ist dann irgendwas mit den Items/Things/bindings nicht so, als würde ich OH3 neu installieren (irgendwas grau ...?)
Nimmt das Update auch zusätzliche Samba Konfiguration mit (die zusätzlich Partition... )?
Könnte ich eigentlich bei Problemen mit Standard Bordmitteln wieder zurück auf OH2.5?

Was meinst du mit den Textdateien, die rules?

OhJe