Posts by rotala

OldSmarthomer

Das stand in den verlinkten FAQ Seiten. Ich hatte es auch erst später gesehen...

Die FAQ wurden wohl seitdem angepasst.

schaeferC

Die rule setzt die Soll Temperatur wieder wenn das Fenster wieder zu ist. Es könnte ja sein, das zwischenzeitlich ein Zeitprogramm in der SHC gelaufen ist.

Ein Szenario in der SHC zum geöffnenten Fenster habe ich nicht mehr.

Ich habe alles per file erstellt.

import org.openhab.core.model.script.ScriptServiceUtil

/* beispielhafte items
Number PARTYKELLERSoll "PARTYKELLER Soll [%.1f °C]" <temperature> (gKeller, gPARTYKELLER, gSoll) {channel="livisismarthome:RST:SHCJLE01:1111111111111111111111111:set_temperature"}
Number PARTYKELLERSollSetpoint "PARTYKELLER Setpoint [%.1f °C]" <temperature> (gKeller, gPARTYKELLER, gSollSetpoint)
Switch PARTYKELLERWindowReduction "PARTYKELLER Window Reduction" (gEG, gInnogyWindowReduction) 
Contact PartykellerFenstersensor  "Partykeller Fenster [MAP(de.map):%s]" (gKeller, gFenster,gSicherheitInnen, gSicherheitAussen) {channel="livisismarthome:WDS:SHCJLE01:2222222222222222222222222222222:contact"}

Vorraussetzungen
1. Zu jedem Item mit set_temperature gibt es ein passendes Number ItemSetpoint welches den Sollwert speichert falls das/die Fenster geöffnet werden und der Sollwert set_temperature auf 6 Grad geht
2. es gibt noch eine Valiable kWinter welche die Anlage zwischen Winter und Sommerbetrieb umschaltet. Im Sommer ist set_temperature immer 30 Grad um die Antriebe und die Ventilfeder zu Entlasten (andere Rule). Deswegen ist die Windowreduction nur im Winterbetrieb aktiv
3. all items, die eine set_temperature sind in der Gruppe gSoll

Funktion
1. wann immer Item mit set_temperature sich ändert wird ItemSetPoint geschrieben. Das passiert bei manueller Änderung am Ventil, Zeitplan von SHC oder Kommando von OH
2. alle 20 sec wird geprüft, ob ein Fenster offen ist. Falls ja, wird das set_temperature auf 6 kommandiert

Kommentar Ende
*/


val org.eclipse.xtext.xbase.lib.Functions$Function5<NumberItem, NumberItem, ContactItem, ContactItem, SwitchItem, Number> funcWindowReduction = [
    NumberItem SollSetpointItem,
    NumberItem SollItem,
    ContactItem Window1,
    ContactItem Window2,
    SwitchItem WindowReduction
 |
    var Number nSollSetpoint
    var Number nSoll


    //logInfo("funcWindowReduction", "Aufruf " + SollItem.name.toString +"  " + SollItem.state.toString +"  " + SollSetpointItem.name.toString +"  " + SollSetpointItem.state.toString +"  " + Window1.name.toString +"  " + Window1.state.toString +"  " + Window2.name.toString +"  " + Window2.state.toString )
    if ( SollSetpointItem.state == NULL || SollSetpointItem.state.toString == "6" ){
        sendCommand (SollSetpointItem, 15)
    }

    nSollSetpoint = SollSetpointItem.state as DecimalType
    nSoll = SollItem.state as DecimalType
    //logInfo("funcWindowReduction","nSoll " + nSoll + "  nSollSetpoint " + nSollSetpoint)
    if (kWinter.state.toString == "ON"){
        if(Window1.state.toString == "OPEN" || Window2.state.toString == "OPEN") {
            if (nSoll != 6 ){
                sendCommand(SollItem, 6)
                sendCommand(WindowReduction, ON)
                logInfo("funcWindowReduction", "Windowreduction EIN " + SollItem.name.toString)
            }
        }
        else {
            if (nSoll != nSollSetpoint){
                logInfo("funcWindowReduction", "Windowreduction AUS " +  SollItem.name.toString)
                sendCommand(SollItem, nSollSetpoint) 
                sendCommand(WindowReduction, OFF) 
            }
        }
    }
    
]



rule "WindowReductionRooms"
when
    Time cron "*/20 * * * * ?" 
then
    //OG
    funcWindowReduction.apply(OG_ESSZIMMERSollSetpoint,OG_ESSZIMMERSoll,OG_ESSZIMMERFenstersensor,OG_WOHNZIMMERFenstersensor, OG_ESSZIMMERWindowReduction)
    funcWindowReduction.apply(OG_DuscheSollSetpoint,OG_DuscheSoll,OG_DUSCHEFenstersensor,OG_DUSCHEFenstersensor, OG_DuscheWindowReduction)
    funcWindowReduction.apply(OG_AUSSENBUEROSollSetpoint,OG_AUSSENBUEROSoll,OG_AUSSENBUEROFenstersensor,OG_AUSSENBUEROFenstersensor, OG_AUSSENBUEROWindowReduction)

    //EG
    funcWindowReduction.apply(BueroSollSetpoint,BueroSoll,BueroFenstersensor,BueroFenstersensor, BueroWindowReduction)
    funcWindowReduction.apply(WohnEssZimmerSollSetpoint,WohnEssZimmerSoll,WohnzimmerTuersensor,WohnzimmerFenstersensor, WohnEssWindowReduction)
    funcWindowReduction.apply(KUECHESollSetpoint,KUECHESoll,KUECHEFenstersensor,KUECHEFenstersensor, KuecheWindowReduction)
    funcWindowReduction.apply(BADSoll,BADSollSetpoint,BADFenstersensor,BADFenstersensor, BadWindowReduction)
    funcWindowReduction.apply(RAUM1SollSetpoint,RAUM1Soll,RAUM1Fenstersensor,RAUM1Fenstersensor, RAUM1WindowReduction)

    //KG
    funcWindowReduction.apply(PARTYKELLERSollSetpoint,PARTYKELLERSoll,PartykellerFenstersensor,PartykellerFenstersensor, PARTYKELLERWindowReduction)
end


rule "UpdateSollSetpoint"
when
    Member of gSoll changed
then
    var String sbuffer
    var Number Soll

    //logInfo("UpdateSollSetpoint", "The item " + triggeringItem.name + " changed state from " + previousState + " to " + triggeringItem.state)
    sbuffer = triggeringItem.name + "Setpoint"
    //logInfo("UpdateSollSetpoint", "sbuffer = " + sbuffer)
    Soll = triggeringItem.state as DecimalType
    if (Soll > 6){
        ScriptServiceUtil.getItemRegistry.getItem(sbuffer).postUpdate(Soll)
    }
end

Ich habe mir in Openhab 2 rules gebaut, welche die Window Reduction der SHC ersetzen. Wenn Interesse besteht, schreibe ich noch ein paar Kommentare und poste das dann hier.

.. gerade habe ich alles auf Window Reduction Rules in Openhab umgestellt..
Ich teste trotzdem mal in 2 Räumen mit..

ich habe auf einem nackten Debian aufgesetzt. Dann kamen auf dem raspberry immer mehr Applikationen dazu und updates wurden damit zunehmen riskant.

Zur Installation habe mich hier orientiert https://hub.docker.com/r/openhab/openhab/

Wenn man dann verstanden hat wozu Volumes gut sind und wie man noch an die Karaf Konsole kommt ist eigentlich alles geklärt. Wie bereits geschrieben: Updates oder zusätzliche Applikationen sind dann ein Klacks. Mittlerweile liegt mein Raspberry im Schrank und ein HP 800G1 I5-4570s USDT macht den Job. da kann man 3 SATA Platten reinbasteln. Wegen Docker war der Umzug von Raspberry zum PC ein Klacks obwohl hier auch der Prozessor gewechselt wurde (ARM zu AMD64).

Bei mir beginnt die Herrin des Hauses sich zu beschweren. Wir haben immer wieder den Fall, daß das Thermostat ausbleibt.

Hat das noch jemand?

Wenn Du den Sollwert der Räume auf 30 stellst sollten die Ventile öffnen. Damit werden sie stromlos und sollten kalt werden. Sobald die Ventile regeln muß das Wachs temperiert werden und damit fühlen sich die Ventile warm an.

Ich habe keine Bedienungsanleitung für die Livisi Regelung. Ich kann so nicht sagen, ob das unterstützt wird. Motorische gibt es wohl. Die Wachspatronen sind halt leise und robust.

Hallo,

das ist laut Datenblatt ein thermischer Stellantrieb:

"Der elektrothermische Stellantrieb ist mit einem Wachs gefüllten Dehnstoffelement ausgestattet. Dieses Element wird mittels eines elektrischen Kontakts erwärmt und wieder abgekühlt. Dadurch dehnt sich das Wachs bei Erhitzung aus und beim Erkalten zieht es sich wieder zusammen."

Das lässt vermuten, daß die Ventilstellung ZU angesteuert wird. Bei den stromlos offen Ventilen wird dabei die Wachspatrone dauerhaft beheizt. Das ist anders als bei einem Ventil mit Getriebe, welches nur die Position anfährt und danach keinen Strom mehr verbraucht.

Da jetzt viele mit OH anfangen hier noch ein Tip. Was in Livisi fehlt ist ein Kalendar basiertes Schedule. Das habe ich mit einem Calendar Dienst gelöst. So kann man prima das Homeoffice an Homeoffice Tagen heizen usw.

- ich nutze einen Baikal Server lokal aus folgendem Docker image https://hub.docker.com/r/ckulka/baikal/tags

- in OH verwende ich das iCalendar Binding (wollte google meiden)

- Auf die termine im Kalender greife ich mit Thunderbird zu

Ich habe nur items file basiert definiert. Da wird der Name des Bindings und die ID der Bridge geändert.

Things lasse ich immer über die Inbox suchen/finden.

Shihan Woran merkt man daß man den Repeater Modus braucht? Gehen die Melder offline?

... und Du kannst Devices mischen. Ich nutze inzwischen Zigbee Bewegungsmelder und Femstersensoren in den rules bunt gemischt mit Livisi Geräte.

ich habe vor ca 1 Jahr die OH Installation auf meinem Raspberry auf Docker umgestellt.
Kann ich sehr empfehlen. Releasewechsel von OH sind damit super easy. Da ein moderner PI 4 weit mehr Leistung als für OH notwendig bietet kann man entsprechend mehr damit machen. Ich betreibe da noch 10 weitere docker Container (Zigbee/Deconz, VPN, PIhole, FTP, Plex, ..). Wird irgendwie immer mehr. Da sich die System nicht beeinflussen ist die Pflege wenig aufwendig.
Docker Images gib es hier https://hub.docker.com/r/openhab/openhab/

Es dreht sich um diesen Satz:

Die Plattform wird zum 1. März 2024 geschlossen. Um die Benutzer vor falschen Erwartungen und Spekulationen zu schützen, haben wir uns entschieden, die Registrierung von Zentralen und die Erstellung neuer Benutzerkonten zu unterbinden.

Ich hatte noch eine OVP SHC 2.0 im Schrank...

Ich habe völlig übersehen, daß Livisi am 28.2. mitgeteilt hat, daß ab 1.3. keine neuen User mehr angelegt und keine Zentralen mehr aktiviert werden können. Ich dachte die meinten den 1.3. 2024. Es war aber der 1.3.2022 gemeint. Das ist echt kurzfristig. Finde ich nicht wirklich gut und erzeugt jetzt etliches an Elektroschrott.

Bei mir ist auch keine Verbindung möglich. Das Problem existiert wohl seit 18:20 mit kürzeren Ausfällenvorher.

            <h1 id="unavailable">Error 403 - This web app is stopped.</h1>@@@WCF_PRE_LINEBREAK@@@            <p id="tryAgain">The web app you have attempted to reach is currently stopped and does not accept any requests. Please try to reload the page or visit it again soon.</p>@@@WCF_PRE_LINEBREAK@@@            <p id="toAdmin">If you are the web app administrator, please find the common 403 error scenarios and resolution <a href="https://go.microsoft.com/fwlink/?linkid=2095007" target="_blank">here</a>. For further troubleshooting tools and recommendations, please visit <a href="https://portal.azure.com/">Azure Portal</a>.</p>@@@WCF_PRE_LINEBREAK@@@

Und Innogy spricht auch wieder mit Openhab.

Man kann sich wieder mit der App anmelden. Und natürlich kommt gleich wieder die Meldung daß der Speicher voll ist. Bin gespannt wann die API für Openhab wieder geht.

Smarte Systeme sind nur smart wenn sie offen sind. Die aktuelle Performance von dem Team Innogy und Openhab ist ein Trauerspiel. Das hat schon mal über Monate gut funktioniert.

2020-07-16 22:01:08.788 [WARN ] [internal.handler.InnogyBridgeHandler] - Error starting websocket. java.util.concurrent.ExecutionException: java.io.EOFException: HttpConnectionOverHTTP@c51fe6::DecryptedEndPoint@fb970e{api.services-smarthome.de/51.124.73.211:443<->/192.168.123.12:48784,OPEN,fill=-,flush=-,to=103/600000} at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) ~[?:1.8.0_201] at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) ~[?:1.8.0_201] at org.openhab.binding.innogysmarthome.internal.InnogyWebSocket.start(InnogyWebSocket.java:84) ~[?:?] at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startWebsocket(InnogyBridgeHandler.java:272) ~[?:?] at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startClient(InnogyBridgeHandler.java:247) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_201] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_201] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_201] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_201] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]

java.util.concurrent.ExecutionException: org.eclipse.jetty.websocket.api.UpgradeException: Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 503 Service Unavailable at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) ~[?:1.8.0_201] at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) ~[?:1.8.0_201] at org.openhab.binding.innogysmarthome.internal.InnogyWebSocket.start(InnogyWebSocket.java:84) ~[?:?] at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startWebsocket(InnogyBridgeHandler.java:272) ~[?:?] at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startClient(InnogyBridgeHandler.java:247) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_201] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_201] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_201] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_201] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]