berland

Jeg forsøkte i går (med offisiell kabel). Oppdatering av firmware gikk greit. Demonterte hele fronten og tok den med til en datamaskin (oppgraderingen "krever" Windows, og det er litt mangelvare i huset) En RPi (lysfjernkontrollen min for Gira-belysning) døde når jeg tok sikringen. Arg. Noen timer brent på å få denne opp og gå (reformatere SD-kort). Etter firmwareoppgradering får jeg ikke til å kommunisere med enheten, men kommunikasjonen er ikke helt død. Jeg våknet opp til 39 grader på baderomsgulvet, og i følge AMS-strømloggen så har det skrudd seg på i dag tidlig, så enheten har mottatt noen kommandoer via Z-wave (kombinasjon av mange grader etter at jeg har trykket desperat for å få noe til å skje, samt at enheten gikk over til luft-modus og ikke gulvsensor-modus etter oppgradering). Tenkte å prøve factory reset på heat-it-enheten, men venstre+center i 20 sekunder ser ikke lenger ut til å klare gjøre factory reset. Arg. Det virket ihvertfall på tidligere firmware. Så status nå er at dette var bare trøbbel. Vet ikke hvem eller hva jeg skal skylde på. ?

Gjør dette det samme som denne bindingen til OpenHAB? https://community.openhab.org/t/openhab-can-now-use-amazon-echo-devices-to-speak-any-text-tts-new-feature-in-the-amazonechocontrol-binding/44889 Jeg har kjørt den noen uker, men har ikke funnet mange bruksområder ennå. Vaskemaskinbeskjeder etterhvert.

Ikke sett det problemet. Jeg vil gjette på at det er test_rx som henger i de tilfellene.

Jeg har nesten en slik, for serie-interface via USB til ESP8266. Min har 6 pinner, lenken din har 5 pinner, og Heatit-kabelen har fire pinner. Kan jo hende de er like, men vi må finne ut hvilke som skal brukes. (i så fall så skal jeg få testet 1.92 på OpenHAB)

Klippet opp en ødelagt Fibaro wallplug før den går i spesialavfallet.

I dag har jeg bestilt meg en UZB1-stick, som jeg tenkte å kjøre i tillegg til Aeotec Z-stick gen 5. Er ikke fornøyd med stabiliteten til Z-wave nettverket, en gang døde nesten hele nettverket, og nå har jeg akkurat fått resatt tre-fire noder som hadde dødd. Det er mulig (men ikke sikkert) at det er noe fysisk galt med Aeotec'en, så da kjøper jeg en ny kontroller av ulik type. Med OpenHAB skal det gå an å kjøre med to kontrollere. Nye noder som dør, vil bli lagt til UZB1, så får jeg se om det er noe forskjell i stabilitet. Har vel 40-50 noder tilsammen i nettverket. Z-stick står i en betongbod mellom hus og garasje, så akkurat det er ikke helt ideelt.

BKK har endelig (etter et halvår) klart å aktivere min HAN-port, og Pi'en som har ligget klar har endelig fått noe å gjøre på. Jeg er egentlig fornøyd med output som kommer fra test_rx programmet (JSON), og lagde da heller en Python-wrapper som kjører test_rx som en subprosess, og som sender dataene videre over MQTT. Følgende Python-kode trengtes da: import subprocess import paho.mqtt.client as mqtt import json # If the binary is still active for some reason, kill it subprocess.call("killall test_rx >/dev/null", shell=True) proc = subprocess.Popen(['./test_rx'], stdout=subprocess.PIPE) def on_connect(client, userdata, flags, rc): pass def on_disconnect(client, userdata, rc=0): sys.exit(1) client = mqtt.Client() client.on_connect = on_connect client.on_disconnect = on_disconnect client.connect('mqttserver', 1883) cumulativejson = '' try: for line in iter(proc.stdout.readline, ''): line = line.rstrip() cumulativejson += line if line[-1:] == '}': print cumulativejson try: print json.loads(cumulativejson) client.publish('ams', cumulativejson) cumulativejson = '' except UnicodeDecodeError: # Sometimes we get something strange # on the serial line, just ignore it. cumulativejson = '' continue except Exception: proc.terminate() sys.exit(1) # Let systemd restart us For at PI'en skal restarte prosessen hvis noe feil skjer, og etter reboot har jeg følgende i /etc/systemd/system/ams2mqtt.service: [Unit] Description=start and stop the ams2mqtt service [Service] WorkingDirectory=/home/pi/han-port-1.14 User=pi Group=pi Restart=always RestartSec=2 ExecStart=/usr/bin/python /home/pi/han-port-1.14/test_rx2mqtt.py [Install] WantedBy=multi-user.target Alias=ams2mqtt.service Så må man kjøre 'sudo systemctl enable ams2mqtt' for å aktivere denne For å sende tallene videre fra MQTT inn i en OpenHAB item bruker jeg dette i en *items fil: Number AMSpower "Strømforbruk instantant [%.0f W]" (Offlinewarning, Watt) {mqtt="<[mqttserver:ams:state:JSONPATH($.Act_Pow_P_Q1_Q4)]", expire="10s"} Number AMS_volt_L1 {mqtt="<[mqttserver:ams:state:JSONPATH($.Volt_L1):.*Volt_L1.*]"} Number AMS_volt_L2 {mqtt="<[mqttserver:ams:state:JSONPATH($.Volt_L2):.*Volt_L2.*]"} Number AMS_volt_L3 {mqtt="<[mqttserver:ams:state:JSONPATH($.Volt_L3):.*Volt_L3.*]"} Number AMS_cumulative_Wh {mqtt="<[mqttserver:ams:state:JSONPATH($.Act_Energy_P):.*Act_Energy_P.*]"} Number AMS_Reactive_Q3Q4 {mqtt="<[mqttserver:ams:state:JSONPATH($.React_Pow_M_Q3_Q4):.*React_Pow.*]"} Number AMS_Reactive_Q1Q2 {mqtt="<[mqttserver:ams:state:JSONPATH($.React_Pow_P_Q1_Q2):.*React_Pow.*]"}

Jeg gjorde et forsøk på å denne koden til å kjøre på en pi (raspbian), men det gikk ikke (dvs. etter noen timers prøving). Får ikke installert alle Python-pakkene på kompatibelt vis. Men ved å ta bort sqlite-logging, og å bruke et virtualenv med Python 3.5, så fikk jeg scriptet til å rulle. Fikk dog kun ut instantaneffekt. (koden ligger på https://github.com/Danielhiversen/AMSreader)

Jeg har smappee i sikringsskapet, og har hatt det i et drøyt år. Jeg kan se instantanforbruket på app på telefonen med et par sekunders forsinkelse. Jeg laster ned 5-minuttsdata til OpenHAB via skyløsningen til smappee. Smappee forsøker også å se individuelle laster gjennom signalanalyse. Til en viss grad fungerer det, men ikke alt blir gjenkjent i en enebolig. Du må også gjøre en del detektivarbeid for å finne ut hva Smappee faktisk har funnet. Kanskje enkelt i en leilighet, litt for mye jobb i en enebolig. Det er heller ikke presist eller pålitelig nok til å bruke enhetsgjenkjenningen i automasjonssammenheng, du kan ikke være sikker på at du ikke mister noen av hendelsene (enten en av eller en på f.eks.). Hvis to laster skrus på samtidig f.eks, så kan man ikke forvente at signalanalyse skal klare plukke de opp. Den estimerer effekten på hver av enhetene, men nøyaktigheten her er nok på +/- 5-10% tipper jeg. Avvik på totalforbruk er i størrelsesorden 1%. Jeg er forsåvidt fornøyd nok. Men det gjelder å ikke ha for høye forventninger.

Helt enig, men ser ikke ut til å være mulig å finne. Irriterende at jeg må ha denne trafoen liggende ved siden av driveren, da begge omtrent gjør samme jobben.. https://www.powerdin.com/en/?route=product/product&product_id=232

Det ser ut som samme LED-driver som jeg har. Jeg mangler bare et siste lite elektrikerbesøk, så har jeg dette opp å gå med qubino 0-10V på z-wave sammen med en passende trafo (se tråden) Jeg har fått testet at det virker med midlertidige koblinger.

Jeg har laget mitt eget hack med en cron-jobb, wget og Python både for meteogram og for værradar. For meteogram, så gjør jeg i praksis et screenshot av yr-nettsida for Bergen. For å få til et 'screenshot' kjørt headless hvert kvarter har jeg tatt i bruk 'xvfb-run wkhtmltoimage'. Selvsagt penere om man klarer embedde HTML og CSS, men jeg endte altså opp med å generere en statisk PNG-fil som vises i mitt HABPanel. For værradar så har jeg tilsvarende løsning, med statisk bilde, men også innzoomet. Ønsker ikke å se radar for hele vestlandet hele tida, bare rett rundt Bergen. Bash-kode som kjøres via Cron: #!/bin/bash bergenmeteogram=/var/www/html/bergenmeteogram.png bergenradar=/var/www/html/bergenradar xvfb-run wkhtmltoimage --quiet http://localhost/yrbergen.html $bergenmeteogram convert -crop $((846-19))x$((338-67))+19+67 -level 0%,100%,0.4 $bergenmeteogram $bergenmeteogram wget --quiet "https://www.yr.no/_/proxy/met_images.aspx?radarsite=western_norway;size=large;type=reflectivity;content=image" -O ${bergenradar}.png python /home/berland/bin/radarcrop.py ${bergenradar}.png ${bergenradar}cropped.png Python-koden som gjør crop/zoom: # Klipper ut et område rundt Bergen fra radarbildet # og legger på klokkeslettet innenfor samme område # # Bruk: # python radarcrop.py origimage.png newimage.png import sys import math import Image, ImageFilter, ImageEnhance poi_coords = (289, 472) # Point of interest location in pixels timestamp_ul = (552, 5) # upper left timestamp_lr = (627, 50) # lower right timestamp_width = timestamp_lr[0] - timestamp_ul[0] timestamp_height = timestamp_lr[1] - timestamp_ul[1] timestamp_aspect = float(timestamp_width) / float(timestamp_height) newtimestampwidth = 50 orig_width = 320 # width in pixels in original image new_width = 250 aspect = 1 orig_image = Image.open(sys.argv[1]).convert('RGBA') new_image = Image.new('RGBA', (new_width, new_width/aspect)) zoomedradar = orig_image.crop( (poi_coords[0] - orig_width/2, poi_coords[1] - orig_width/aspect/2, poi_coords[0] + orig_width/2, poi_coords[1] + orig_width/aspect/2))\ .resize((new_width, new_width/aspect), Image.ANTIALIAS)\ .filter(ImageFilter.SHARPEN) timestamp = orig_image.crop( (timestamp_ul + timestamp_lr))\ .resize((newtimestampwidth, int(newtimestampwidth/timestamp_aspect)))\ .filter(ImageFilter.SHARPEN) mask = Image.new('L', timestamp.size, color=150) timestamp.putalpha(mask) zoomedradar.paste(timestamp, (10,10), mask) contrast = ImageEnhance.Contrast(zoomedradar) zoomedradar = contrast.enhance(1.2) zoomedradar = zoomedradar.point(lambda x: math.pow(x/float(256), 1.8)*256) zoomedradar.convert('RGB').save(sys.argv[2]) Og så ser jeg at bash-koden refererer til ei lokal html-fil for å lage screenshot, den fila inneholder: <script src="http://www.yr.no/sted/Norge/Hordaland/Bergen/Bergen/ekstern_boks_time_for_time.js"></script><noscript><a href="http://www.yr.no/sted/Norge/Hordaland/Bergen/Bergen/">yr.no: Værvarsel for Bergen</a></noscript> Eksempel fra mitt HABpanel finnes her:

OpenHAB, HomeAssistant og Domoticz er alle ok lisensmessig, med en stjerne til OpenHAB pga. copyleft-mekanismen (når man skal vurdere framtida). Jeg kjenner meg ikke igjen at OpenHAB2 har hatt lite utvikling i det siste, og har heller ikke hørt det andre steder. Men om det går fortere/saktere enn HA har jeg ingen forutsetninger for å vite, har aldri gravd meg ned i HA.. Noen klarer kanskje telle kodelinjer/commits pr. dag for de to prosjektene. Jeg er veldig mye mer glad i Python enn Xtend (~Java) som OpenHAB bruker, så det er egentlig for meg en god grunn til å ha prøvd HA, foreløpig strekker ikke tiden til.

Jeg har sterke preferanser for åpen kildekode. Spesielt for infrastrukturprogramvare (skal interagere med mye annen programvare, og ikke utelukkende for sluttbruker) så er åpenheten viktig. Hjemmeautomasjon er et slikt domene, og jeg har ingen tro på at et proprietært produkt er fremtidsrettet. Dette har ingenting med penger å gjøre, jeg betaler gjerne for programvaren (kan f.eks. gjøres gjennom donasjoner). I tillegg til at kildekoden skal være åpen, bør den også ha copyleft-elementer i seg. For hjemmeautomasjon er det viktig fordi det er potensielt uendelig mange komponenter som skal snakke sammen, og de beste insentivene for samarbeid får man ved å tvinge sine "motspillere" til å bli medspillere. OpenHAB har Eclipse Public License, som er åpen og som har copyleft-elementer i seg, om enn ikke like sterke som GPL (og uheldigvis GPL-inkompatibilitet i versjon 1) HomeAssistant er Apache 2.0, som er en BSD-type lisens. Dette er absolutt åpen kildekode, men ingen copyleft. Som bruker eller bidragsyter av HomeAssistant har du da ikke like gode garantier for at produkter ikke blir spist eller forket til noe proprietært. Se på Linux. Den viktigste grunnen til at Linux har tatt over verden på 30 år er GPL, intet annet. En bestemt proprietær programvare kan godt være det beste alternativet pr. i dag for hjemmeautomasjon, men fremtidsrettet? Nope, det tør jeg sette penger på (i form av donasjoner)..

Jeg måler nedi 14 grader nederst på innsiden av mine garasjevegger som vender inn mot grunn/fjell. (Det er 10 cm isolasjon bak betong, men isolasjonen bak henger ikke sammen med isolasjon under gulv så her har jeg ei kuldebro). Når været en gang slår om, kanskje sannsynlig med godværs-øs-pøs-med-torden, så vil utedugg fort være over 14 grader. Duggpunkt i min garasje ligger rundt 14, så jeg skal være akkurat på grensa til å få kondens nederst på bakveggen, men kondens er ikke observert. Ingen dum idé å få plassert en temperatursensor nederst på en av disse veggene for å følge med.

Jeg bruker absolutt temperaturdifferanse mellom utedugg og innedugg til å avgjøre om det er lurt å lufte, og krever typisk at det er et par graders forskjell før jeg setter igang vifter. Avstandskravet har jeg også laget med en liten avhengighet på RH - dess lavere RH dess høyere avstandskrav (opp til 4-5 grader). Jeg har noen ganger forsøkt å se respons (/korrelasjon) (på plottene) på innedugg på at viftene er påskrudd, men det virker vanskelig å se en klar effekt. Hos meg mistenker jeg da at lufta der jeg suger inn er fuktigere enn der jeg henter uteduggmålingen i fra. Eventuelt har jeg altfor liten kapasitet på viftene. Avfukteren gir tydelig avtrykk på inneduggplottet.

Hvis det skal dimmes opp og ned og finjusteres hver dag, er det verdt å være klar over at vanlige skrudimmere er mye mer brukervennlige enn en dimmer som styres av impulsbryter (med fjær) (tidels sekunder versus flere sekunders fingerarbeid for å nå ønsket dimmenivå) Men her går det ikke an å få begge deler perfekt og jeg hadde utvilsomt gått for å installere z-wave dimmer bak impulsbryter i din situasjon.

Hva jeg ikke har gjort i dag, i går eller i forgårs osv..: - Bygget hele zwave nettverket om igjen etter at over halvparten av nodene forsvant fra kontrolleren. Heldigvis trengs det ikke gulvvarme for tida..

Jeg dykket litt inn i the-louie-kildekoden, og fant ut at jeg får en HTTP-feil 401 Unauthorized tilbake fra sectoralarm. Noe mystisk at det oppstod akkurat i dag. Jeg fikk testet perbrage-koden, og den virker for meg - jeg får ut status, så da gjetter jeg det er en eller annen liten autentiseringsdetalj som har skjedd, og som kanskje trigger en bug i the-louie-python-koden. Får se om det kan ordnes, eller så bygger jeg om til å bruke perbrage (men erfaringen på javascript er så liten..) Takk for tipset!

Ja. Kjører cron-jobb hvert minutt. Hadde kontakt med alarmsentralen på telefon i kveld - de gjettet på at det ikke hadde skjedd noe med webserverapi'en i dag, men jeg kunne ta kontakt på dagtid i morgen med teknisk support for bekreftelse.

Siden 09:55 i dag, så har ikke python-koden min som poller SectorAlarm for alarmstatus fungert. Jeg klarer ikke få noe fornuftig ut ved å debugge python-koden som gjør jobben, så jeg mistenker at noe har skjedd på serversiden - endret URL'er f.eks, som medfører at python-modulen må oppdateres. Appen på telefonen har ingen problemer. https://github.com/the-louie/sectoralarm Andre som bruker dette og som har fått problemer samtidig?

Knall! Beskjeden fra min squeezeboxserver var at den hadde lastet ned ny versjon selv, alt jeg måtte gjøre var å skrive dpkg-kommandoen som den forslo, og så restarte. Etterpå virker favoritter slik via Spotty, så dette var tydeligvis en kjent og løst bug. Puh, kan nå skyve Sonos-innkjøp lenger ut i tid.

Ja, Spotty ser spillelistene. Hvis jeg trykker på hjerteikonet når musa går over en spilleliste for å markere at det er en favoritt, så lagrer Spotty det i min Squeezeboxserver-favorittliste. Men når jeg fra Favourites-lista prøver å trykke på 'play'-knappen for en spilleliste (som favoritt), så virker det ikke (ingenting skjer, og det gjelder kun favoritter som skal gjennom Spotty). Bruker jeg en spesiell URL for "favoritt nummer 10", som er det jeg kan kalle fra OpenHAB, så får jeg melding fra SqueezeboxServer om URL'en som favoritten refererer til er ugyldig. Dette ser ut som en bug i Spotty eller SqueezeBoxServer. Funker favoritter i Spotty på denne måten for andre? (i så fall fortsetter jeg med å oppdatere SqueezeboxServer til siste versjon, men slikt er farlig med aldrende software..)

Det var ingen dum idé, men jeg vet ikke hvor lett det er. Enten må man inn på kretskortet med en esp8266 eller gjøre noe mekanisk med tanksensoren? Jeg har noe ubrukt og altså utestet kode for å kutte strømmen når effektuttaket fra avfukteren har vært under 50W en viss tid, men har funnet meg til rette med å ha avfukteren gående på høyeste RH i garasjen.

Ja, disse har jeg lyst på. Lurer bare på om varierende fargebelysning i hagen vil være det jeg på rogalandsdialekt ville kalt 'knalskt'