berland

Det ante meg at det alltid var en løsning, men heldigvis bestilte jeg før jeg sjekket. Dream Machine Pro var for fristende

Ny hardware i løpet av 2020. Gammel hus-server kjørte Ubuntu 16.04LTS, og trengte oppdatering til 20.04. Siden man ikke lar smarthuset være dysfunksjonelt, så må man ha overgangshardware, så en ny datamaskin ble bygget for formålet. CPU: i7-7700K (4-kjerne) (arvet fra en annen maskin i huset) 32 GB RAM 512Gb M2.SSD Satt inn i et Silverstone MILO03B kabinett: Hardware er skikkelig overkill for å kjøre smarthus, men gjør vedlikehold utrolig behagelig, og så er noen i huset fornøyd med at det er kraft nok til å kjøre Minecraft-servere og annet snacks. Jeg har noen Telldus-temperatursensorer (og en Nexa-bryter). Telldus-programvaren er grovt utdatert, og lar seg ikke kompilere på Ubuntu 20.04. Løsningen etter noe styr var å kjøre en Ubuntu 14.04 i et docker-bilde, der Telldus-programvaren kjører (med tilgang til den Telldus-USB-dings), og som sender info videre på MQTT (eget script) til OpenHAB.

Byttet fra OpenHAB DSL-språk for automatisering til OpenHAB Jythons (Python 2.7), dette ble gjort høst 2020 og tok noen måneder. Python for å kode automatiseringen passer meg svært mye bedre enn DSL-språket, og har fjernet mange (av mine) bugs og gjort flere ting mer robust. Jeg har 5000 linjer med slik kode fordelt på 250 regler, dette utgjør "kjernen" av automatiseringen i huset.

Måling av kompost- og hagejord-temperatur ble bygget sent 2018:

Har du sett på Z-way integrasjonen i OpenHAB? Den bindingen ser ut til å ha sine egne problemer, jeg tror det egentlig det var den som kansellerte min plan om å prøve UZB1. Noe diskusjon finnes på https://community.openhab.org/t/new-z-way-binding/14096/313

Bestilt meg en Unifi Dream Machine Pro. Erstatter en Unifi security gateway (legges ut på finn), pluss unify controller og unifi video controller som kjører på hus-ubuntu-server. Utløsende årsak er at OpenHAB 3 skal kjøres på Java 11, mens Unifi-programvaren henger igjen på Java 8, så noe måtte gjøres for å planlegge hopp fra OpenHAB 2.5 til 3.

Ja, jeg ser litt mer på tallene mine og det er noe fishy som skjer i utregningen av sparepotensialet. Likevel, maksimalt teoretisk sparepotensial er gjerne 50 kr hvis billigste time er 50 øre, og snittpris på dagtid er 1 kr, og man klarer dra nok effekt de billigste timer, og har et stort og velfungerende varmelager i huset (stor varmtvannstank og vannbåren varme). Dette gir en "virkningsgrad" på 2 for pengesparing, og det er egentlig lite i forhold til hva en varmepumpe klarer når den får kjøre optimalt, så med varmepumpe som primærkilde, så blir sparingen (mye) mindre (noe man gjerne har hvis man har stor vanntank og vannbåren varme) Konklusjonen om at man *ikke* skal gjøre investeringer i smarthus for å flytte oppvarming til billige timer står seg. Smarthus-styring av oppvarming gjør jeg for dagsenking, nattsenking, og feriesenking. Flytting av kWh fra dyre til billige timer er mest en artig akademisk øvelse (bortsett fra for elbil-lading, der Tibber gjør det så enkelt)

Det er mulig, og kanskje noen kroner i døgnet å spare på det for øyeblikket, avhengig av hvordan du varmer huset og hvor godt isolert det er, og hvor mye varmemasse det kan lagre. Se min tråd under. Denne koden ruller og går fortsatt, og påstår at jeg kommende døgn skal spare 9 kroner (endelig gav siste ukes kulde noen strømprisvariasjoner)

Her er mine tre stikker, den til høyre merket "3" har en ekstra Aeotec-logo, og det er denne jeg påstår har fått endel hardware-bugfixer. https://www.dropbox.com/s/14c5xk9srt0av4s/2021-01-08 16.25.05.jpg?dl=0

Jeg er på min tredje aeotec-stikke. Jeg hadde først to som jeg synkroniserte med backupsoftwaren, og slik at jeg alltid hadde en i reserve jeg kunne putte rett inn når en hardware-feil slo inn og krevde at jeg la inn fra backup. Husker ikke hvorfor, men jeg kjøpte så en tredje for vel ett år siden. Denne er mattere i plasten og litt mer avrundet (i plastkassen sin), og har sannsynligvis fått noen oppgraderinger internt også, for denne har vært mye mer stabil enn de to første (jeg lurer på om den faktisk aldri har feilet) Har også en UZB1 som jeg en gang tenkte å bruke, men den er ikke mulig å få til (windows/lisensproblematikk?) (burde vel forsøkt å selge den)

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.

Utregningen her har noen antakelser som det er lett å snuble i. Det ikke-intuitive kommer av at fuktig varm luft har mye energi (entalpi) og tørr uteluft har lite av det. Og så antar vi at vi tar den tørre utelufta, fukter den opp til din måling av inne-fukt (21%), og også varmer opp "fukten". Du kan alternativt tenke på at du bare skal varme opp lufta utenifra, og ikke ta hensyn til fuktøkning, da blir det noen hundre watt mindre (og 80% RH ved -10 grader vil gi 7% RH innendørs). Men personene og huset avgir fukt som holder 25 grader, og denne fuktige energirike lufta forsvinner ut vifta di, så det er riktig å ta hensyn til det i beregningen. Fukteffekten her (via entalpi) er det samme som gjør at varmegjenvinner kan varme opp uteluft med f.eks. 10 grader gjennom varmeveksler selv om temperaturfallet i avkastlufta er mindre enn 10 grader.

Øyeblikksbilde fra optimalisering. Lyseblå strek er strømpris (skala i kr til høyre). Minimumstemperaturprofil i mørkeblå, og optimalisert temperatur i rødt. Koden forsøker å holde temperaturen på et minimum på slutten, dvs. når strømprisinformasjonen slutter (og så ligger det inne en legionellasikring hver natt til søndag som tilsier 70-80 grader som krav). Når rød kurve stiger, brukes det altså strøm, og variasjonen i hvor fort den faller kommer fra beregnet ukesprofil fra forbruk. Det ligger også inne en varmetapsmodell slik at temperaturen faller litt fortere i tanken hvis den holder 80 grader kontra 50 grader. Når huset settes i ferie-modus senkes den mørkeblå kurven ned til 40 grader.

Koden fikk seg en oppvask i høst (ikke pga. innsparingspotensiale!) og har nå følgende egenskaper: Gjør full optimalisering hvert 8. minutt, og kan skru av eller på hver gang Bruker Dijkstra's algoritme for korteste vei (shortest path) for selve optimaliseringen, etter at det gikk et lys opp for meg en dag i 2019 om hvordan problemet skulle formuleres som en graf. Tidligere ad-hoc/brute-force kode hadde neppe ikke klart å optimalisere av/på hvert 8. minutt 24 timer fram i tid. Hvert døgn reberegnes ukesprofilen for forbruk, og ved å ikke titte for langt tilbake i tid eller vekte siste måneder mer, så har den fått med seg bittelitt endret bruksmønster med hjemmekontor (maskinlæring). Bedre kode gjør det mulig å gjøre et bedre estimat av besparelsen, som er et ganske tricky regnestykke der man må simulere hva den innebygde termostaten i vvb hadde gjort i tilsvarende situasjon, men nå stoler jeg ihvetfall mer på det. De fire siste dagene har det vært fest, siden koden har spart meg over 1 kr strømutgifter i døgnet (ellers var 2020 på mange måter et magert år). Koden ligger på https://github.com/berland/pyrotun/blob/master/pyrotun/waterheater.py som åpen kildekode og er i prinsippet gjenbrukbar (gitt Python-kunnskaper) for alle med temperaturlogg for tanken i InfluxDB (for forbruksestimatet).

Her er en reproduserbar oppskrift på regnestykket, med alle forbehold om feil.. Jeg kommer til at du må bruke 1.2 kW for å varme opp igjen den lufta du blåser ut, gitt at vifta di faktisk blåser 85 kubikk i timen (kanskje ikke riktig..). Men det er ikke langt fra ditt første tall på 1.04 kW. Jeg måtte dikte opp et tall for luftfuktigheten i utelufta. Tørrere luft ute har mindre entalpi og krever enda mer energi (her er det noen antakelser som kanskje skurrer litt, for vi tar ikke hensyn til hvorfra økning i absolutt fukt kommer) In [9]: from pyrotun.vent_calculations import enthalpy In [10]: h_inneluft = enthalpy(25, 0.21, 1000) In [11]: h_uteluft = enthalpy(-10, .8, 1000) In [12]: delta_h = h_inneluft - h_uteluft In [14]: delta_h # enhet kJ/kg Out[14]: 42.53937825269311 In [15]: m_luft = 85 * 1.269 # kg Out[16]: 107.865 In [17]: energitap_pr_time = m_luft * delta_h In [18]: energitap_pr_time # kJ Out[18]: 4588.510035226743 In [19]: # watt er Joule/sek In [20]: energitap_pr_time * 1000 / (60*60) Out[20]: 1274.5861208963174

Jeg har gjort slike utregninger for en stund siden for ventilasjonsaggregatet, men da brukt til å estimere luftmengde siden jeg hadde kontroll på temperatur, fukt, trykk og strømforbruk. Nøkkelen til beregningen ligger i entalpi, som måles i kJ/kg. Eksempelet mitt er nesten dokumentert på https://github.com/berland/pyrotun/blob/master/pyrotun/vent_calculations.py Det skal være mulig å gjøre beregningen omigjen med denne koden i ditt tilfelle.

Beklager sen respons, kabelen er marginalt skadet etter siste turné (ryddig ordnet opp via PM!) og jeg tror jeg vil ha restlevetiden i reserve til eget behov.

To dager etterpå klarer jeg endelig søke på riktig frase på Google og finner: https://tekkieramblings.blogspot.com/2020/06/discord-gateway-for-mqtt.html Jeg hadde vel heller gått for den om jeg hadde funnet den i tide. Bruker ikke discord.py, og unngår alt async-dillet som er litt overkill for min enkle anvendelse.

Hehe, hvis noen vil grave seg inn i hullet så kommer koden her! Laget fra hovedeksempelet på: https://github.com/sbtinstruments/asyncio-mqtt og så brukt slegge for å få inn Discord via: https://discordpy.readthedocs.io/en/latest/api.html Har ikke klart å forene async-event-loopene til disse to bibliotekene, så jeg har juksa litt. Men det ser ut til å funke på tross av noen warnings. Kjører denne som en service på Ubuntu-serveren. import asyncio from contextlib import AsyncExitStack, asynccontextmanager from random import randrange import threading import time import asyncio_mqtt import discord DISCORD_TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" DISCORD_GUILD = "OpenHab" DISCORD_CHANNEL = "openhab" MQTT_SERVER = "xxxxxx.xxx" DISCORD_CLIENT = discord.Client() async def mqtt2discord(): disc_login = DISCORD_CLIENT.login(DISCORD_TOKEN) await disc_login disc_starter = DISCORD_CLIENT.start(DISCORD_TOKEN) disc_task = asyncio.ensure_future(disc_starter) time.sleep(2) # Klarer ikke vente på futuren på annet vis.. :( mqtt_client = asyncio_mqtt.Client(MQTT_SERVER) await mqtt_client.connect() # (får en unclosed client session på første await, den # kommer vel fra den andre tråden som kjører start() ) await push_discord("OpenHAB-Discord integration ready!") async with AsyncExitStack() as stack: # Keep track of the asyncio tasks that we create, so that # we can cancel them on exit tasks = set() stack.push_async_callback(cancel_tasks, tasks) topic_filters = ("discordmessage/send",) for topic_filter in topic_filters: manager = mqtt_client.filtered_messages(topic_filter) messages = await stack.enter_async_context(manager) template = f'[topic_filter="{topic_filter}"] {{}}' task = asyncio.create_task(push_many_to_discord(messages)) tasks.add(task) # Subscribe to topic(s) await mqtt_client.subscribe("#") await asyncio.gather(*tasks) async def push_many_to_discord(mqtt_messages): async for mqtt_message in mqtt_messages: await push_discord(mqtt_message.payload.decode()) async def push_discord(msg): guild = discord.utils.get(DISCORD_CLIENT.guilds, name=DISCORD_GUILD) if guild is not None: channel = discord.utils.get(guild.channels, name=DISCORD_CHANNEL) if channel is not None: await channel.send(str(msg)) else: print("channel was None") else: print("guild was None") async def cancel_tasks(tasks): for task in tasks: if task.done(): continue task.cancel() try: await task except asyncio.CancelledError: pass async def main(): # Run the advanced_example indefinitely. Reconnect automatically # if the connection is lost. reconnect_interval = 3 # [seconds] while True: try: await mqtt2discord() except asyncio_mqtt.MqttError as error: print(f'Error "{error}". Reconnecting in {reconnect_interval} seconds.') finally: await asyncio.sleep(reconnect_interval) asyncio.run(main())

Det er ikke alltid like lett å få gitt beskjeder til ungdommer i huset som gamer med headsett.. Løsning: OpenHAB->MQTT->Discord ! Lagde en liten liten Python-kode (samtidig som man lærer async-koding med prøv-og-feil) som klarer plukke opp et gitt MQTT-topic og sender den videre til en Discord-kanal som poden abonnerer på. Så nå kommer beskjeder som "Noen ringte på døra", "Noen ringte på døra og ingen har åpnet!", "Garasjen ble åpnet", "Mye CO2 - åpne et vindu!" og selvsagt den viktigste, "Leggetid!", fram. Tiden får vise hvor mye det hjelper..

Ikke over på Jython? Akkurat den members.filter greia for noe så naturlig som en for-løkke over noen items var noe av det verre med Rules DSL-koden til OpenHAB synes jeg.. Jeg er lykkeligere nå som jeg heller kan skrive for lys in ir.getItem("gLights").allMembers: events.sendCommand(lys, "OFF")

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).

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

Dette vet jeg lite om, men er det likeverdig om man har API til bilen for å styre lading av/på som API til laderen? Begge deler vil vel fungere, så lenge man får en plugin til sitt hjemmeautomasjonssystem (eller lager det selv)?

Ikke til dette, så da må man gjøre de triks som må til for å også sende dette gjennom Docker. Bruker bare docker for å få den gamle Tellstick-hub'en til å virke på Ubuntu 20.04, tellstick-programvaren er bare kompilert for Ubuntu 14.04. Jeg har ikke prøvd ditt scenario, så jeg kan bare spekulere. Du har potensielt to veier til mål - enten kjører du socat inni Docker-kontaineren og setter opp den virtuelle usb-devicen inni konteineren - da trenger socat inni Docker bare nett-tilgang på lokalnettet - og det har den vel allerede. Alternativt kjører du socat utenfor Docker-kontaineren på serveren din, akkurat som hos meg, men så gir du Docker-kontaineren tilgang til den virtuelle usb-devicen som socat setter opp. I min tellstick-kontainer bruker jeg --device flagget til docker for å gi tilgang til fysisk usb-port, men det er muligens ikke helt det samme som tilgang til noe under /dev