Problem OH3 http Binding

[dirkabel]

420 Channel sind schon mal angemeldet, Rest folgt.

[dirkabel]

Meine 17 Module sind als Channels abgelegt 720 Channel, sieht alles gut aus, fehlen nur noch die Heizungsdaten.

Vielen Dank nochmal!

Werde ich mal nach und nach die restlichen Bindings auf OH3 wieder anwerfen. Das war aber hoffentlich meine größte Baustelle.

[udo1toni]

Doch, tatsächlich ist genau das die Idee von OSS. Wenn mir was nicht passt, oder etwas nicht akzeptiert wird, forke ich und mache von da aus weiter.

Ja, soweit passt das

Das Resultat ist öffentlich verfügbar und wer möchte, kann es ja dann ja auch verwenden um es in das ursprüngliche Repo einzubringen.

Aber warum tust Du das nicht selbst?

Diverse Funktionen sind eben in openHAB nicht gewünscht (sowohl was ganze Add-ons als auch Funktionen innerhalb eines Add-ons betrifft), deswegen musste ich irgendwann entscheiden, ob ich darauf verzichte oder eine andere Lösung anbiete.

Für mich klingt das nach "Politik", die offensichtlich an mir vorübergeht, weil ich auch nicht zu den Entwicklern gehöre.
Ich hatte bisher immer den Eindruck, dass Code vor allem abgelehnt wurde, weil er den Qualitätsansprüchen nicht genügte (was ja dann nur bedeutet, dass man nachbessern muss), aber nicht, weil bestimmte Funktionen nicht zur Verfügung gestellt werden sollen. Das wäre auch widersinnig, schließlich geht es ja darum, möglichst viele Geräte möglichst allumfassend einzubinden.

Dass Änderungen am Core eher abgelehnt werden, kann ich noch nachvollziehen. Aber warum sollten Fixes zu Fehlern abgelehnt werden?

[J-N-K]

Aber warum tust Du das nicht selbst?

...

Für mich klingt das nach "Politik", die offensichtlich an mir vorübergeht, weil ich auch nicht zu den Entwicklern gehöre.
Ich hatte bisher immer den Eindruck, dass Code vor allem abgelehnt wurde, weil er den Qualitätsansprüchen nicht genügte (was ja dann nur bedeutet, dass man nachbessern muss), aber nicht, weil bestimmte Funktionen nicht zur Verfügung gestellt werden sollen. Das wäre auch widersinnig, schließlich geht es ja darum, möglichst viele Geräte möglichst allumfassend einzubinden.

Dass Änderungen am Core eher abgelehnt werden, kann ich noch nachvollziehen. Aber warum sollten Fixes zu Fehlern abgelehnt werden?

Es geht nicht um einzelne Fixes, die abgelehnt werden würden. Es ist aber aufwändig, zwei Versionen des gleichen Codes zu pflegen. Deswegen wäre ein Übertrag aus SmartHome/J nach openHAB nicht einfach ein PR sondern ein manuelles Einpflegen. Das ist auch die Antwort auf die obige Frage, meine Zeit ist nicht unbegrenzt.

Es gibt einige Entscheidungen, die ich für grundlegend falsch halte und die meiner Meinung nach die beste User-Experience verhindern.

Das ist z.B. die seit Jahren ungelöste Problematik, dass bei einem Update eines Things-Types (also z.B. neuer Channel dazu, alter Channel weg oder Channel-Type geändert) Things gelöscht, neu angelegt und komplett neu konfiguriert werden müssen. Da das in openHAB nicht geht und nicht gewünscht ist (weil Versionierung nicht elegant genug ist, die Problematik wurde ja schon zu Eclipse SmartHome Zeiten diskutiert), habe ich das extern implementiert. Neue Funktionen/Channels sind somit auch für UI-Things nachrüstbar. Das finde ICH wichtig, weil ich ausschliesslich UI Konfiguration verwende.

Ein anderer Punkt ist, dass Code nicht zwischen zwei Add-Ons geteilt sein darf, man muss also die gleiche Funktionalität mehrfach programmieren. Das betrifft zu Beispiel konkret das Problem hier: Ich verwende den gleichen Code für state/commandTransformations und Wert->Channel-Konvertierung sowohl für das TCP/UDP Binding als auch das HTTP Binding. Es macht aus meiner Sicht keinen Sinn, das nicht zusammen zu pflegen: mit einem Fix und Code für den es viel Test-Code sind gleich zwei Bindings versorgt (was übrigen das Rückportieren dann komplizierter macht, weil der Code eben nicht mehr da ist, wo er in openHAB ist).

Es gibt noch mehr Gründe (die zum Teil auch Politik sind). Ich halte das aber nicht für sinnvoll, das mit "Unbeteiligten" in aller Breite zu diskutieren. Das heisst aber nicht, dass ich openHAB grundsätzlich doof finde für technisch untauglich. Sonst würde ich sicherlich nicht meine Zeit auf Core-Development/Maintaining verwenden.

[dirkabel]

Das ist alles verständlich, es gibt ja auch eine brauchbare Lösung. Doof ist halt nur, dass man nicht automatisch darüber stolpert. Das kann einen schon Zeit und Nerven kosten.
Habe heute ein zweites Thing angelegt für die go-e Walbox, weill mir das offizielle nicht alle gewünschten Parameter liefert. Da ich keine Ahnung habe, wie man das Binding ändert und als jar zur Verfügung stellt, habe ich es (wieder) über http gelöst.
Eine Frage noch dazu:
Man kann doch bei der Transformation nach Doku mit dem math. UND mehrere Transformationen verknüpfen.
Gibt es eine einfache Möglichkeit einen numerischen Wert einfach durch 10 oder 1000 zu teilen?
Dann könnte ich die Rules auch noch rauswerfen.

[J-N-K]

Auch in SmartHome/J gibt es das Math Transformation Add-on, in dem es eine DIVIDE Transformation gibt: https://docs.smarthomej.org/3.2.12/org. ... .math.html, damit sollte das gehen.

[udo1toni]

Danke für den Einblick, das hilft schon weiter.
Unterm Strich ist es also so, dass, obwohl sich http und j-http äußerlich nicht großartig unterscheiden, innen kein Stein auf dem anderen blieb

[dirkabel]

Das Math Plugin tut was es soll, kann aber nicht durch grose Zahlen teilen (360000 oder auch 36000) aber mit kleinen Zahlen multiplizieren (0.000277). Ausgetrickst
Eine Frage habe ich noch.
Die beiden Wechselrichter haben eine ziemlich irre url, weil man da alles anegben muss.

war:

Code: Alles auswählen

# configuration of the second cache item  
Nedap1.url=https://USER:PASSWORD@mypowerrouter.com/power_routers/19878/logs/1hour.json?utf8=%E2%9C%93&normalize_logs=true&include_last_log=true&include_last_state=true&include_attribute_info=true&solar_power=true&solar_power_input1=true&solar_voltage_input1=true&solar_current_input1=true&solar_temperature_input1=true&solar_power_input2=true&solar_voltage_input2=true&solar_current_input2=true&solar_temperature_input2=true&dcac_grid_power=true&dcac_grid_voltage=true&dcac_frequency=true&dcac_local_power=true&dcac_local_voltage=true&battery_state_of_charge=true&battery_bus_power=true&battery_voltage=true&battery_current=true&battery_pack_temperature=true&platform_grid_power=true&grid_sensor_power_l1=true&grid_sensor_voltage_l1=true&grid_sensor_current_l1=true&grid_sensor_power_l2=true&grid_sensor_voltage_l2=true&grid_sensor_current_l2=true&grid_sensor_power_l3=true&grid_sensor_voltage_l3=true&grid_sensor_current_l3=true&responseContentDataType=json{Authorization:Basic XXXXXX}
Nedap1.updateInterval=60000

ist:

Code: Alles auswählen

Thing http:url:nedap1 "Power Router 1" 
   [
        baseURL="mypowerrouter.com/power_routers/19878/logs/1hour.json?utf8=%E2%9C%93&normalize_logs=true&include_last_log=true&include_last_state=true&include_attribute_info=true&solar_power=true&solar_power_input1=true&solar_voltage_input1=true&solar_current_input1=true&solar_temperature_input1=true&solar_power_input2=true&solar_voltage_input2=true&solar_current_input2=true&solar_temperature_input2=true&dcac_grid_power=true&dcac_grid_voltage=true&dcac_frequency=true&dcac_local_power=true&dcac_local_voltage=true&battery_state_of_charge=true&battery_bus_power=true&battery_voltage=true&battery_current=true&battery_pack_temperature=true&platform_grid_power=true&grid_sensor_power_l1=true&grid_sensor_voltage_l1=true&grid_sensor_current_l1=true&grid_sensor_power_l2=true&grid_sensor_voltage_l2=true&grid_sensor_current_l2=true&grid_sensor_power_l3=true&grid_sensor_voltage_l3=true&grid_sensor_current_l3=true&responseContentDataType=json{Authorization:Basic XXXXXX",
        bufferSize=3000,
        timeout=500,
        delay=0,
        refresh=60,
        username="USERl",
        password="PASSWORD",
        authMode="BASIC"
   ]    
   {
       Channels:
        Type number : PR1SOLAROWER   [stateExtension="/status", stateTransformation="JSONPATH:$.last_log.solar_power",mode="READONLY" ]
   }

USER PASSWORT von mir entfernt.

Liefert im Thing aber einen Fehler "baseURL is invalid: protocol not defined."
Liegt das den drei schon "escapden" Zeichen?
Wie stelle ich das um?

Danke, Dirk

[J-N-K]

Wieso kann das nicht durch grosse Zahlen teilen? Was passiert denn dann?

Es fehlt das Protokoll, also `http://` oder `https://` am Anfang der URL.

[dirkabel]

Wieso kann das nicht durch grosse Zahlen teilen? Was passiert denn dann?

Der Wert springt zwischen (meistens) Original und (manchmal) geteilt hin und her und im Log erscheint eine Warnung, dass er nicht durch diesen Wert teilen kann.
Auf Änderung reagiert es auch nur auf Neustart.
Aber wenn man es weiß...