openhab and how I learned to love the Jython

[Alpøy]

Tok jobben ifjor høst med å konvertere alle DSL rules til Jython og har ikke sett meg tilbake! OH (nå 2.5M2) har aldri vært så smidig, stabilt og funksjonelt! Er strålende fornøyd og kan bare anbefale alle og enhver å ta samme steg, hvert fall hvis du har en basis forståelse av programmeringsspråk!

 

ESP8266/NodeMCU med EasyESP har også vært en gudsgave når det har kommet til å rulle ut sensorer i diverse rom, med enkel setup og stabilitet (selv om firmware'n har vært litt buggy her og der så har det bare handlet om diverse reboots i ny og ned, men siden de booter på sekunder har det ikke vært merkbart). Har kjørt på en development firmware fra 2018 og tok nå runden med å oppgradere til nyeste "stable" og den virker mye mer snappy i GUI og uten tvil har de løst stabilitets problemet nevnt tidligere.  

 

Jeg har mer eller mindre fjernet alt av batteri drevne Z-wave enheter og løst det med ESP8266'ere istedet (riktignok kablet). Det fine er at man kan bygge ut på disse nodene sensor for sensor, f.eks. har jeg noen med reed switcher (magnetkontakter), BME280 (temp/fukti./bar.trykk) og lekkasjesensor. På ett rom har jeg kunne brukt 1 node og målt 2 forskjellige rom med noen enkle grep. Fleksibiliteten er utrolig fin, eneste utfordringen har vært å ha noen gode eller "fine" containere for dette. Har som regel benyttet vanlige elektrisk koblingsbokser siden det "forsvinner" litt i anlegget fra før siden jeg ikke har skjult anlegg.

 

 

Nå har jeg satt opp virtuelle termostater i ethvert rom som jeg justerer temperatur på ved å slå av/på varmelementet som er i rommet (uavhengig av type oppvarming) siden jeg har standardisert navnene på alt. Samtidig har jeg lagt inn meta tags på termostat item'ene slik at jeg kun har 1 hoved "rule" som styrer alle termostater (sjekkes hver 5.minutt), f.eks:

Number THERMOSTAT_Fe_BarneSoverom "Setpunkt Barnesoverom [%.1f °C]" <thermostat> (gFe_BarneSoverom_Thermostat,gRoomThermostats,gPersistMysqlChange) { ga="thermostatTemperatureSetpoint", thermostatControl="Meta" [conditional="1", requiredCLOSED="KB_Fe_BarneSoverom_Vindu"]}

Her leser jeg ut av meta tag'ene at for at denne termostaten skal "automatisk" styres så må "KB_Fe_BarneSoverom_Vindu" være CLOSED

Siden jeg har standardisert navn for itemene mine vet jeg at for å finne rom temperatur trenger jeg bare å erstatte THERMOSTAT_ delen av navnet med TM_ og VE_ for varmovn.

VE = Varmeelement

KB = Kontaktbryter

Fe = Første Etasje

osv.

30-Mar-2020 10:40:00.089 [DEBUG] [jsrTempControlRules] - romtemp_regulering: Prosesserer termostat: THERMOSTAT_Fe_BarneSoverom
30-Mar-2020 10:40:00.092 [DEBUG] [jsrTempControlRules] - romtemp_regulering: Evaluerer oppvarming av THERMOSTAT_Fe_BarneSoverom. Temperatur: 22.3  Ønsket: 22.0  Maks: 23.0 Min: 22.0
30-Mar-2020 10:40:00.095 [DEBUG] [jsrTempControlRules] - romtemp_regulering [THERMOSTAT_Fe_BarneSoverom]: Temperatur innenfor ønsket verdi, ingen aksjon nødvendig.
 

 

Å standardisere det slikt har forenklet reglene mine betydelig! Så det er bare å utnytte disse hjemmekontor dagene til å konvertere til jython ?

 

 

 

[berland]

Jeg henger litt etter, men er nå ihvertfall over halvveis, med 3000 linjer jython-kode, mot 2000 linjer resterende DSL-kode. Det er mye jobb, og jeg tør ikke lage for mange nye regler om gangen, før jeg ser sikker på at bugs er borte (i tillegg kommer noen tusen linjer gammel python kode som kjøres "eksternt" og bare sender inn til OpenHAB  når den er ferdig,  som jeg aldri forsøkte å  lage i DSL, denne koden må fortsatt være cpython3 for numpy/pandas).

 

Men, uendelig mye bedre å kode i, reglene blir nå lesbare og vedlikeholdbare i forhold til før. Jeg har laget min egen wrapper for `getItem` som  kanskje er interessant for andre; 

 

def is_undef(itemname):
    return (
        isinstance(ir.getItem(itemname), UnDefType)
        or str(ir.getItem(itemname).state) == "UNDEF"
    )


def get_item(
    itemname, backupitem=None, backupvalue=0, datatype=str, closed_is_true=False
):
    """Helper function for accessing itemRegistry

    Args:
        itemname (str): Name of Item
        backupitem (str): Name of another item to use if the primary item
            is UNDEF
        backupvalue: Value to use if primary and backup item is UNDEF
        datatype: Set to str, int, float or bool.
        closed_is_true (bool): If datatype is bool, this affects how
            ContactItems are returned, by default OPEN is returned as True,
            but setting this argument to True reverses that.
    """
    if is_undef(itemname):
        if backupitem is None:
            value = str(backupvalue)
        elif is_undef(backupitem):
            value = str(backupvalue)
        else:
            value = str(ir.getItem(backupitem).state)
    else:
        value = str(ir.getItem(itemname).state)

    if datatype is None:
        return value
    else:
        if datatype == int or datatype == "int":
            return int(float(value))
        elif datatype == float or datatype == "float":
            return float(value)
        elif datatype == bool or datatype == "bool":
            if value in {"ON", "OFF"}:
                return value == "ON"
            if value in {"OPEN", "CLOSED"}:
                if closed_is_true:
                    return value == "CLOSED"
                else:
                    return value == "OPEN"
            return False
        return value  # string is default

 

[NilsOF]

@berland ta en titt på HabApp, den er ekte cpython3 så man kan bruke hvilket som helst pythonbibliotek og tar seg av kommunikasjon over APIet.

https://community.openhab.org/t/habapp-easy-automation-with-openhab/59669
edit: dokumentasjon habapp: https://habapp.readthedocs.io/en/latest/

Installeres i ett venv, og kan kjørest på en annen maskin, noe som forenkler utvikling og debugging. 
Jeg bruker Pycharm som IDE, og det forenkler sakene ganske betraktelig.

Til nå har jeg brukt HabApp på de mere hårete greiene, og det "native" språket til de enklere sakene.

Jeg bør ta en titt på jythongreiene jeg og..

 

Endret 8. september 2020 av NilsOF

[berland]

Jeg kikket litt på Habapp for en stund siden, men slo det fra meg da det var et enmanns(?) sideprosjekt til OpenHAB. Jeg har for mange kodelinjer til å tørre porte de til noe jeg ikke er sikker på blir støttet i lang framtid, og tilbakemeldingene fra OpenHAB-kjerneutviklerene var ikke veldig positive. 

 

Jython har sine svake sider, både at det er Python 2.7, og at det ikke er cpython, men styrken er da at det kan henge bedre sammen med Java i OpenHAB. For ren Python må jeg over på HomeAssistant, men det blir  jo enda mere jobb (hvis mulig).

 

 

[NilsOF]

@berland Jeg sympatiserer med mange av betraktningene dine vedr. HabApp.

Den største utfordringen med HabApp som jeg ser det er de ekstra rundene som signalene må gå over APIet, med den forsinkelse som det medfører.

Jeg er ingen programmerer, men koden til HabApp synest for meg grei nok til at også jeg skjønner oppbygningen når jeg stirrer lenge nok 🙂

 

Alt i alt så lander HabApp positivt for meg.

Å ha all konfigurasjon for Things (Channels, Items) tilgjengelig (og editerbar om de ikke er låst med konfigfil) er også ett kjempestort pluss.

[berland]

Jeg kom i mål med konverteringen til Jython. Samtidig har jeg ryddet opp i ekstra-koden min som har rullet ved siden av, og innsett at den til en viss grad nesten er som en HabApp i den grad den lytter på hendelser eller kjøres ved faste tidspunkt. Det har forsåvidt kostet noen hjerneceller å få grepet på async-programmering i Python, som også er kjernen i HabApp. https://github.com/berland/pyrotun

 

Tror ikke HabApp forsvinner, det gir absolutt mening å ha et async-bibliotek for å programmere Python mot hendelser i OpenHAB via REST API'et, og så kan man finne ut hvordan man best mikser cPython 3.x kode via HabApp og Jython 2.7 kode direkte inni OpenHAB.  Begge vil ha noen fordeler og ulemper avhengig av hva man vil automatisere. 

[NilsOF]

Når jeg plukket opp HABApp i løpet av fjoråret, så hadde jeg ikke rørt Python på 15 år.

Og fortsatt feiler jeg på selvfølgeligheter i Python.🙂 Og den lærekurven hadde blitt usigelig mye brattere om jeg ikke hadde hatt PyCharm å lene meg på.

Holder på med værdata fra met.no nå, bruker https://github.com/Rory-Sullivan/metno-locationforecast.

Til nå er jeg forbauset over hvor lite kode jeg måtte skrive for å få det jeg trenger levert til OpenHAB som jeg vil ha det.

 

Observerer at Jython fortsatt henger på 2.7 og for meg er det uklart når og hvor mye endringer det blir til noe som ligner Python 3.x.

Siden jeg fortsatt har huller i kunnskapen om hvordan grunnelementene i OpenHAB er tenkt til å fungere så  vil jeg fortsette å lappe med det gamle scriptspråket til de enklere tingene.

 

Mye skjer med OpenHAB v3 nå, og jeg har bestemt meg for å fortsette med configurasjonsfiler for Items en stund til.

V3 har ennå noen sprekker og ustabiliteter, jeg tror jeg venter til det grøvste støvet har lagt seg.

[Alpøy]

Jeg har en separat "IO" enhet (raspberry pi) hvor jeg kjører alt av scripts fra python/nodejs eller enkle bash script for å løse diverse utfordringer med å få data fra API'er til basic GPIO. Sender alt via MQTT til OH dermed slipper jeg litt unna problemer med å få jython til å støtte ymse libs eller modules. Det eneste jeg bruker jython til da er de spesifikke reglene eller actions de skal gjøre. Tror jeg har 1 ekstern modul import i jython og det er squeezelib for å kjøre varsling.

 

Har kjørt på dette ganske lenge og det er veldig stabilt (OH2.5.11). Får se om jeg tar steget over på OH3 på sikt.

Jeg forsøkte meg på HabApp før jeg gikk over til jython men slo det fra meg da det ikke støttet persistence (på den tiden) eller actions så det ble for mye hacks for å løse disse problemene. Bekymringen med at HabApp er et enmanns prosjekt, som berland nevnt tidligere, var uten tvil et viktig argument for å hoppe direkte på Jython.

 

Får håpe OH kommer til å støtte Python3 fullt en vakker dag (tm) 🙂

 

Endret 8. januar 2021 av Alpøy

[Alpøy]

Ettersom Jython virket bare mer og mer "forlatt" I OH så har jeg tatt steget med å migrere helt over til HabApp. Det har sine fordeler og bakdeler utvilsomt, men jeg må si at fordelen med å ha direkte tilgang til Python3 modules/libraries har vært veldig behagelig.

Tror ca. 70% av Jython koden kunne mer eller mindre copy/pastes over i sin helhet (med kun bytte av hvordan du henter item value) , resterende handlet om å gjøre om på actions og persistence som ikke fungerer på samme måte (jeg skrev en egen persistence module for influxdb for å kunne gjenbruke samme funksjoner som maximumSince etc.).

HabApp har hvert fall fungert veldig fint i etterkant, nå er det bare å avvente til OH 4.1 kommer og jeg tør/orker ta steget med å konvertere/konfigurere alle disse item unitene osv. 🤪