Søk i nettsamfunnet

Da jeg var innom et shoppingsenter i Berlin i fjor sommer fant så jeg disse klokkene: Jeg ble kjempefasinert, særlig fordi det slo meg at dette var noe jeg selv kunne klare å lage. Da jeg kom hjem fant jeg dem på nettet hos Nordiska Galleriet og de var ikke akkurat billige 😮 (Sjekk DEN prisen) Enda en grunn til å lage dem selv. Jeg har alltid være fasinert (og litt stolt) over måten vi normenn angir tiden med "avstanden til nærmeste halve time": - 5 over 2 - 5 på halv 3 - 5 over halv 3 -5 på 4 osv Utlendinger går i fella hele tiden og mange tror at "halv 7" er 07:30 🙂 I tillegg ville jeg selvfølgelig ha minutters nøyaktighet (og ikke 5 min nøyaktighet som de kjøpeklokkene hadde) og også tekst på "halv" og "kvart". Etter å ha sittet noen kvelder og stablet sammen ord på rutepapir (Trenger ikke egen TO når du kan tenne de 2 første bokstavene i TOLV etc) endte jeg opp med en matrise på 12x12 bokstaver. Jeg hadde da også plass til "KLOKKA ER NÅ" og litt Service ord som "WIFI" og "DOT" Jeg var litt usikker på angivelsen av minuttene mellom xx:15 og xx:20 (og xx:40 og xx:45). -Sier vi "tolv minutter over halv" eller "atten minutter på" ? (Antakeligvis ingen av delene 🙂 ) Jeg tok en sjefsavgjørelse og bestemte meg for 1..19 minutter på og over hel time, og 1..10 minutter på/over halv time Å frese ut så små bokstaver i aluminium er ikke bare-bare og det prosjektet arbeider jeg fortsatt med, -MEN jeg har jo en laser 😉 ! Og laserskårene Times New Roman (Med seriff og greier) ble skikkelig fint i svart kartong (Fra Ark bokhandel) Måtte jobbe litt i CAD for å få bokstavene til å bli "stencil-type" men det ble jo ferdig til slutt. De nye adresserbare LED stripene er jo helt perfekte til slikt og jeg valgte en 5V stripe med RGBW slik at jeg kunne kjøre dem på en USB kabel og kunne få litt varmt gult lys. Med 30 stk på meteren ble det 3.33cm på hver bokstav som var helt passe. Så da var det bare å klippe dem opp og lime dem på bakplata og lodde dem sammen med strøm og data slik at alle kom etterhverandre: "Avstands plata" ble det jo en del arbeid med. Den måtte freses nøyaktig og ha utsparinger til loddingene: Her er et glimt fra produsjonen IMG_0096.mp4 Med plata montert og ESP32'en på plass så det slik ut: Hadde ikke lyst til å sette av noe plass til en "reset knapp" så den ble bare 2 kabler på baksiden 🙂 : For at kartong-bokstavene skulle holde seg flate måtte jeg ha plastplate både over og under. Jula hadde noen fine i 2mm og 4mm. Jeg prøvde meg med hvit plast fra Biltema for å gjøre lyset diffust men det "lakk" for mye over til nabobokstaven så løsningen ble faktisk helt vanlig printerpapir (2 x A3) som ble lagt under bokstavene: En venn av meg foreslo svart silkepapir som difusjonspapir og det ble også ganske fint. -Da ser en ikke bokstavene så godt før de lyser opp og det gir en annen effekt (men jeg synes det er litt kult å se dem ellers også) 2 x 6mm MDF + 2mm plast + 4mm plast = 18mm Til slutt hadde jeg litt flaks og fant alu-profiler hos Maxbo som var perfekte. Disse var rett under 18 og kunne klemmes på som eneste festemåte etter at de var skåret i gjerdesaga. Siden jeg bruke 5m USB kabler til strømforskyning var det jo ingen grunn til ikke å la den USB'en også være plugget i ESP32'en slik at en kan reprogrammere om en vil. Men jeg turte ikke å ta strøm til LED'ene fra ESP32'en så kablene ble klippet opp og tappet for 5V. Så var det programvaren da. Minimums konfigurasjonen fikk WiFi Manager som setter opp en SSID = "BokstavKlokke" med samme passord for å sette opp husets WiFi. Den leser så klokka fra nettet med NTP og "tidssone" = CET-1CEST,M3.5.0,M10.5.0/3 Det skal gi riktig sommertid også så vidt jeg forstår. Når du trykker "reset" (kortslutter de to kablene på baksiden) går den i AP mode igjen og viser "WIFI" på displayet Når den starter tester den alle LEDene i alle farger og så "tekster" den ut IP adressen 🙂 Untitled Video - Made With Clipchamp (2).mp4 Mulighetene herfra er mange: - Flere konfigurerings-parametere i WiFi Manager: Justering av bokstav-farger og intensitet Modi med andre farger om natta Feiring av hel/halv time med farger - MQTT support fra Smarthuset Blinker klokka om noe skjer Styrer fargene avhengig av sol opp/ned MEN alt dette må jeg jo spille ball med dere på forumet om ! Jeg opretter en tråd på Mikroprosessor-forumet og tar imot ideer og kode der. (Min kode skal dere selvfølgelig få). Jeg har brukt så mange timer på dette prosjektet at det ville være dumt å ikke dele det med flere. Så jeg har laget noen få komplette som er lagt ut på finn. (Søk på bokstavklokke) Til dere som liker å gjøre ting selv men ikke har fres og/eller laser tenkte jeg å tilby et "byggesett" med de delene som er vanskelige å lage. Egentlig er det bare de to MDF platene og bokstavkartongen men jeg er redd kartongen ikke overlever postgang om jeg ikke legger den mellom plastplatene. Kontakt meg her eller på Finn om dere er interessert. Og hva er neste skritt? Vel, jeg har ikke gitt opp å frese ut bokstavene i aluminiumsplate. Da kan den øverste plastplaten skippes og difusjonspapiret bør byttes ut med plastfolie. Jeg HAR allerede forsøkt å bruke noe annet enn svart kartong i laseren. Jeg har prøvd meg på tapet, både med og uten mønster. Det ble veldig kult men min laser er egentlig bare en fres med påmontert laser og brenner derfor et lite hull hver gang den starter en skjæring. Jeg har kjøpt inn en ny controller som kan ta M11P1/M10P1 koder (skru på laseren først når aksen begynner å bevege seg) så når den er montert får vi se mere på tapeter.

Har laget en mulighet for å integrere varmepumpen min direkte inn i home assistant via MQTT. https://github.com/toremick/shorai-esp32 Sikkert kjekt for de som har varmepumpe av denne typen.

Dette er programmet for de av dere som ønsker informasjon fra og mulighet til å styre Easee sin "laderobot" fra smarthussystemet ditt. For å nå ut til flest mulig så velger jeg MQTT som er en strålende standard for slik kommunikasjon. Koden er fritt tilgjengelig på GitHub. Der ligger det også instruksjoner for hvordan dette installeres. Slik det er nå publiseres følgende informasjon til din MQTT-Broker: Akkumulert strømforbruk Strømforbruk nåværende ladeøkt Strømforbruk forrige ladeøkt Spenning Effekt Kabel-lås (altså om ladekabelen er låst i roboten) Status (altså om den lader eller ikke) Status smartlading (altså om smartlading er skrudd på eller ikke) Maksimal strøm for lading Sist kontakt I tillegg kan du styre følgende ved å sende kommandoer til programmet: Endre maksimal strømstyrke Lås / Lås opp kabelen Aktiver / deaktiver laderen Aktiver / deaktiver smartlading "Ping" for å få oppdaterte data. Programmet gir oppdatert status hvert 5. minutt ellers. Hører gjerne fra dere hvis dere har tilbakemeldinger eller tanker For egen del må jeg innrømme at det er nok akkumulert strømforbruk som er det viktigste grunnen til at jeg laget dette.

Har endelig blitt kvitt alt av interface på min virtulle Home-Assistant server, tidligere med DeCONZ for Zigbee, og nå nulig ZWaveJS2MQTT for Z-Wave. Det gikk lekende lett faktisk, selv om det etter alt å dømme ikke var godt dokumentert. Vil derfor dele denne how-to-en jeg skrev: https://flemmingss.com/how-to-set-up-zwavejs2mqtt-on-a-raspberry-pi-and-integrate-it-with-home-assistant/

På varmepumpeanlegget mitt står der en Itron-UltraMaXX-V energimåler som har M-Bus tilkobling. Så langt har denne bare stått som en frittstående enhet med manuell avlesing men den skal ha m-bus innebygget. AMS målerene går jo også på m-bus og kan det være mulig å bruke f.eks. Tibber Pulse til å lese data herfra? Tibber Pulse kan jo settes opp til å sende data til min MQTT broker og det har jeg gjort med den som står på AMS måleren men har ikke lyst til å ta den ut av drift for eksperimentering. Der finnes en brukt Tibber Pulse til salgs ikke så veldig langt hjemmefra men det kunne være greit med noe kvalifisert synsing om dette kan la seg gjøre. Tibber Pulse sender jo bare rådata, de må jo dekrypteres i etterkant... Håper måleren min har trådbundet m.bus, den har i alle fall optisk... Andre m-bus2mqtt eller m-bus til ZWave/Zigbee som finnes i markedet og anbefales? Edit: Ser at HAN porten er master og da blir Tibber Pulse slave. Tviler på at Itron måleren er master siden den er batteridrevet (står ikke noe om det i manualen) og 2 slaver snakker neppe sammen...

Hei Noe av det jeg har: Home Assistant i Proxmox på Intel NUC. Lys: Fibaro dimmer 2 Fibaro singel switch 2 Fibaro double switch 2 Fibaro wall plug Ikea Trådfri Adapter Ikea Trådfri pærer WLED Varme: Mill ovner Varmekabler - Elko Strømmåling: AMS-måler Shelly Div sensorer fra : Netatmo Fibaro Xiaomi mijia/Aqara/CGG1

Edit 23-04-2022: Dette ble egentlig skrevet som et svar i en annen tråd, men moderator la det inn som egen tråd i ettertid. * Jeg holder på med å bruke opp noen kort fra rundt 1990 nå som dukket opp blant mye annet rart. Lagret i kjeller. Funker fint, men krever litt mer belysning. Hvis lakken din er Positiv 20, er det gunstig å få litt hjelp av varme. 1 stk leselampe av gammel modell. 60 W er bra. Ei passe stor metallplate som varmespreder som ligger oppå lampa. Spray på lakk Legg et par lister som avstandsstykker og ei ny plate på toppen som lyshinder. Tenn lampa og vent 15-20 minutter. Da flyter lakken fint og jevt ut, og den tørker fort. Støv når du sprayer er det største problemet. Databladet for Positiv 20 sier ca. 15 min og 70 grader. http://www.crceurope.com/wwwcrc/tds/TKC3 POSITIV20/css/TKC3 POSITIV20.htm Dette er slik vi gjorde for 40 år siden før vi fikk råd til å kjøpe ferdiglakkerte kort. Bildet viser siste rester av en boks som gikk ut på dato 11.88. Ble litt frynsete i kantene, men det er ikke så merkelig når det er mer enn 30 år på overtid. Dette var for ett år siden.

Har oppdatert dette da det første utgangspunktet med ESP-01 ikke er så mye brukt lenger samt det er mye enklere med de nyere ESP variantene som Nodemcu, Wemos, ESP32, osv. som har det som trengs innebygd på kortet. Jeg gikk selv raskt over til en Nodemcu like etter jeg brukte ESP-01 pga litt nettere innstallasjon, så på tide med en update da jeg ser flere ønsker å gjøre dette . Jeg bruker enda kode som er fra 2018 som virker helt fint for meg, men det er blitt oppdatert flere ganger på https://github.com/SwiCago/HeatPump ------------- Deler litt bilder og hva jeg gjorde for å få Mitsubishi varmepumpe online med ESP8266 WIFI modul. Utgangspunket var å få noe bedre en zxt-120 til å styre varmepumpa og noterte meg at det kan kjøpes diverse plugin moduler fra Mitsubishi for dette (blant annet MelCloud WIFI adapter). Så da tenkte jeg at det måtte være noen terminaler eller plug som en kunne koble seg til. Heldigvis så er det noen som har trakka løypa først så noen kloke hoder har reversert kommunikasjonen på CN105 porten på disse varmepumpene og laget hardware oppsett og software bibliotek for dette; https://github.com/SwiCago/HeatPump. I korte trekk så er det en kontakt, CN105, som har seriell kommunikasjon og 5V på ene pinnen så da sier det seg selv at en ESP modul er rette valget her. Denne porten finnes på de fleste Mitsubsihi varmepumper, hvis varmepumpen søtter MelCloud så har den denne kontakten slik jeg har forstått det. Jeg har en Mitsubishi FD-Heat Kirigamine (MSZ-35FD). Så da er det bare å trekke ut strømkontakten til varmepumpa og åpne opp. Finner hovedkortet og i mitt tilfelle så må en ta ut flere kontakter for å få ut hovedkortet. CN105 kontakten ser ut til å være brun i det fleste tilfeller. Den har 5 pinner. Type kontakt som passer er PAP-05V-S, jeg kjøpte min fra Elfa: 300-21-706 "PAP-05V-S Krympehus Poles 5, JST 300-21-733 "SPHD-001T-P0.5 - Klemkontakt Hunn 26...22 AWG, JST" Elfa har også ferdige ledninger med klemkontakt montert i svart og rød for å gjøre det litt enklere; 143-52-231 "Rød Forkrympet ledning DF11 Hunn 500mm 143-52-235 "Sort Forkrympet ledning DF11 Hunn 500mm" Jeg gikk for klemkontakter så jeg kunne være litt fargerik på ledningene, bruker kontakter 2 - 5 (TX,RX,5V,GND). Siden jeg har min pumpe opp under taket laget jeg en lang ledning slik at jeg kan ha ESP modul på toppen. Laget et lite hakk i kabinett for ledning ut. Har en liten nedfelt "hylle" på toppen hvor jeg har ESP liggende. Flere modeller har også plass innvendig for ESP modul så kan gjemmes vekk hvis ønskelig. Sjekket at det var 5V på plus leding etter mod (NB! pinne 1 har 12V) så en slipper uønsket grill party. Tilkobling fra CN105 kontakt direkte til Nodemcu blir da slik som under. Kjører 5V fra varmepumpe kontakt inn på 5V inn på nodemcu (VIN). Ser da noe sånt ut som dette: Jeg brukte Arduino IDE med Nodemcu og PubSubClient MQTT biblioteker. På HS3 brukte jeg mcsMQTT plugin da denne parser JSON direkte og lager egne devicer for hver parameter i JSON strengen. Tick av "a" for de lesingene du ønsker og den lager devicer i Homeseer. Trykk på "ref" for å legge til knapper for de ulike parameterene. For hver kommando en vil sende til varmpepumpen må en legge til en kommando. Brukte MQTTlens for Windows med testing. Trykker på f.eks ID "534", tick av Button for "knapper" på HS device siden. Deretter gå til "HS Device VSP list" og legg til kommandoer. Skriver bare i feltet: "0=SWING" og tar retur, deretter neste knapp "1=<<", så bygger en listen nedover som da blir "knapper" i device siden. Det vil da se slik ut: * Oppdatert: dette eksempelet er som sagt laget med 2018 kode så det kan avvike litt fra det siste på https://github.com/SwiCago/HeatPump. Er nye opsjoner som f.eks ignorerer vanlig IR fjernkontroll og overstyrer med satte parameter. Modifiserte MQTT eksempelet med fixed IP og laget egne MQTT subscriptions for de ulike kommandoene da mcsMQTT plugin for Homeseer ikke sender JSON for kommandoer. Noter de ulike topics f.eks heatpump/set/fan nedenfor i settings for mcsMQTT som en må sette for hver device som skal sende data. I utgangspunktet er eksempel kode på ESP'en satt opp med å motta alle parameter på same topic, må da sende MQTT payload som JSON streng f.eks {temperature: 24}. Så derfor tok jeg en "kjapp" update med egen topic for hver setting og tar da bare verdi rett fra device i homeseer som payload for raskt få det til å virke. Men her kan en lage det som en vil uansett. Jeg la til disse som nye topics i .h filen, måtte også oppdatere litt i "void mqttCallback(...) samt registere de nye MQTT topics. // new topics for Homeseer/mcsMQTT const char* heatpump_set_power_topic = "heatpump/set/power"; const char* heatpump_set_mode_topic = "heatpump/set/mode"; const char* heatpump_set_temperature_topic = "heatpump/set/temperature"; const char* heatpump_set_fan_topic = "heatpump/set/fan"; const char* heatpump_set_vane_topic = "heatpump/set/vane"; const char* heatpump_set_widevane_topic = "heatpump/set/widewane"; Får da hver gang det er en forandring på varmepumpe settings (enten via MQTT eller fjernkontroll) og da oppdateres MQTT topic "heatpump" som JSON streng: {"power":"ON","mode":"HEAT","temperature":25,"fan":"2","vane":"SWING","wideVane":"SWING"} Ellers leser den temperatur hver 60 sekunder (kan justeres i kode) på topic "heatpump/status: {"roomTemperature":25,"operating":true} ...og det var en kort update på hvordan jeg fikk min varmepumpe online .

Hei, Nykommer her på forumet og hadde lyst å dele mitt oppsett. Etter litt frustrasjon (fra øvrige medlemmer av husstanden) over styring av hus via flere appen tenkte jeg at jeg skulle lage en sentral hub, hvor alle enheter kunne styres fra. Noen websøk senere havnet jeg på Home Assistant. Oppsett og hardware: Windows server: Home Assistant, MQTT, Unify kontroller, Plex server. Ubiquity nettverks utstyr. Airpatrol wifi varmepumpestyring Div hue produkter Chromecast Pioneer AVR Logitech UE smartradio Android webcam Wemos (Arduino) temp sensor Tibber Noen timer over noen kvelder senere har jeg satt opp følgende styring i Home Assistant: Styring av lys (Phillips Hue) med wakeup light automasjon. Styring av varme (Airpatrol wifi (via IFTTT og webhooks) med automasjon for nattsenking. Styring av media (Chromecast, Pioneer AVR og Logitech UE smartradio). Oversikt over vær (yr), strøm (tibber), webcamera og varmesensorer (diy). Husstandens medlemmer har webapp satt opp på telefonene, i tillegg har jeg hengt opp en Galaxy Tab 2 7" på veggen for besøkende. Denne skal byttes når ny kommer i posten (Huawei Mediapad T3 7" siden samsungen er sliten og treig. Kommende oppdateringer: Ny tablet for styring er på tur i posten. Deler til 4 nye temperatur og luftfuktighets sensorer er på tur i posten. Framtidige oppdateringer: Flere Hue lyskilder. Z-wave med veggplugger til de 3 panelovnene jeg har og strømuttak ute til defa. Hue motion sensor. Google home mini. Harmony hub. Når AMS måler kommer i hus blir jeg å sette opp lesing av sanntidsdata via HAN. Samboer (til tross liten interesse for teknologi o.l.) bruker systemet hele tiden og er veldig fornøyd med oppsettet. Setter pris på tilbakemeldinger, forslag og kritikk

Hei Jeg har nå begynt å "koble" meg på eksterne MQTT-devicer, og først ut er min dashboard tablet hvor planen er å styre "Wallpanel" over MQTT. Planene er å gjøre kommandoene reload, relaunch, wake tilgjengelige i HS4. For å gjøre dette bruker jeg den (foretrukkede metoden) plug-in devices hvor jeg velger en topic og videre fra den genererer en HS4-device. Problemet mitt er å lage en fornuftig gruppering hvor jeg har én parent device og funksjonene reload, relaunch, wake som hvert sitt child device. Det klarer jeg ikke helt på en reperarbar måte. I hovedsak så genereres det automatisk en ny parent for hver topic jeg legger til (assosierer). Noen spesielle triks som jeg bør kunne her?

Hei Jeg sliter med mcsMQTT og tror det er en feil i plug-in´en for HS4. Utvikleren mener at jeg skal kunne sub og pub på samme topic name (selv om jeg mener å ha lest at han anbefaler sepatate topics for set and get). Jeg får ikke dette til å fungere. Dersom jeg benytter ulike topic names for set og get (finnes en option for dette i ioBroker) som mottar på /topic og sender ut/svarer på topic/set så fungerer det (nesten) i HS4. Problemet er bare at da får jeg feedback siden mscMQTT tar innkommende verdi(subscribed) og publisher den ut broker igjen. Broker gjør som jeg tror er riktig...den svarer og sender echo av mottatt verdi tilbake til mcsMQTT...og så har vi det gående... Dersom jeg bruker fullstendige forskjellige topics som ikke har noe med hverandre å gjøre så fungerer det, med da jobber jeg ikke på samme "variabel". Det jeg ønsker er: Overstående fungerer mellom feks MQTT Explorer-client og ioBroker-broker, og grunnen til at jeg ønsker det slik er for å slippe "glue logic" i form av Node-Red. Forøvrig ikke noe feil med Node-Red, men i dette tilfellet skal det ikke være nødvendig å bruke...

Nå har jeg lekt med meg mcsMQTT på HS4 noen kvelder på rad og begynner å nærme meg sammenbruddets rand. Det jeg i praksis skal gjøre er å publisere verdiene fra noen VS som er temperatursetpunkter til en broker. Dette går helt fint og jeg kan bruke disse verdiene i mitt dash board for å vise verdienen. MEN så skal jeg også endre på disse verdiene i dashboard. I terorien må man da benytte en annen topic for å unngå "feedback". Vanligvis gjøres dette ved å slenge på en /set bak klientens publish topic. Så puttes det legges subscribe-verdien inn i mcsMQTT assosieringsmenyen (etter at man først har satt opp publish) Dette har jeg altså klart etpar ganger med verdiene StueEP og StueCP, verdiene vises fint i dashboard og HS4, og jeg kunne endre begge veier. Når jeg så skal legge til flere verdier slutter det å virke for de nye verdiene selv om jeg har benyttet samme fremgangsmåte for å legge dem inn. Deretter har jeg fiklet med det og så har alt sluttet å virke. Det som er snodig er at jeg også har satt opp en anndre klienter( MQTTX og MQTT Explorer), og her kan jeg subscribe på topicene jeg ønsker endre på dem og puclisere akkurat som jeg vil. Broker plukker opp riktig verdier. Nå får jeg bare til å publisere fra mscMQTT på HS4...ikke noen subscription i det hele tatt. Nå er det forøvrig slik at "master" for verdiene mine er HS4....det er ikke en device som jeg skal hente verdier fra noe steds slik som muligens oftest et oppsett er. Er det noen her som behersker mcsMQTT og kan gi noen tips? Holder på å bli sprø🥳

Har noen jobbet med/kommet lenger med en 100% lokal integrasjon av Yale Doorman v2n? Hadde vært kjekt å gjøre seg helt uavhengig av verisure's api med de begrensningene det har. Alt er av interesse! z-wave-modulen (som kanskje eller kanskje ikke kan la seg bruke) eller et HW-hack med f.eks. Fibaro smart implant som kan spionere på status og kanskje låse/låse opp ved å simulere vrideren? Eller esp32/d1 mini og mqtt?

Når man har automatisert lys, varme, dørlåser, garasjeporter, sengetepper, og så videre, så er selvfølgelig spørsmålet: "Hvordan kan jeg nå gjøre livet enklere for meg selv?" Svaret er åpenbart: Den tiden det tar å helde drikke fra en beholder til et glass er jo helt bortkastet, så det må jo automatiseres! Og så er det jo selvfølgelig kulere. Dermed ble The Bartender™ født. En liten 5V slangepumpe styrt av en ESP8266, et par slangelengder, litt tålmodighet, og voila! Den kan selvfølgelig gjøre mer enn det: Deler En NodeMCU eller ESP32 (som denne: https://www.aliexpress.com/item/32665100123.html) En slangepumpe (som denne: https://www.aliexpress.com/item/4000974680479.html) Et 5V relé brett (som dette: https://www.aliexpress.com/item/4000125547605.html) En 5V strømforsyning (f.eks. fra Clas Ohlson) Et knippe prosjekt-ledninger (som dette: https://www.aliexpress.com/item/33060775595.html) Strømtilkoblinger (som disse: https://www.aliexpress.com/item/4000097450967.html) En passende plankebit, jeg hadde en foring liggende Slanger (jeg fant på Biltema) Hullbånd Kantbånd for stryking Oppkobling Koble 3V og GND på NodeMCUen til VCC og GND på reléet. Koble D1 på NodeMCUen til Vin på reléet. Utgangene på releet kobles i serie på strømforsyningen. Kode Jeg styrer den via MQTT. Det var enkleste måten å få inn og ut data fra den uten for mye styr. Den har følgende topics. /motor/get - sender status på motoren, verdi: 1 eller 0 /motor/set - setter motoren på eller av, verdi: 1 eller 0 /runtime - heltall på antall sekunder motoren skal kjøre /runtimestatus - rapporterter fortløpende hvor lenge i prosent motoren har kjørt av sekunder satt med /runtime (verdi: 0-100) Alt sendes til "bartender/1", det siste /1 i tilfelle jeg skulle finne på å lage noen til… Du trenger Arduio Studio og ha installert PubSubClient (https://pubsubclient.knolleary.net) Bartender.ino: I HomeSeer ser det slik ut: … som er satt opp i mscMQTT slik: Dette kan man selvsagt enkelt legge til andre systemer, som Home Assistant, Node-Red eller Homey hvis man ønsker. Kalibrering En typisk drink er visstnok 40 ml. Jeg hadde et målebeger og kjørte pumpa til det nådde opp til 0,4 dl. Det tok 19,5 sekunder som jeg runder opp til 20. Dermed får vi sammenhengen Kjøretid = Drink_størrelse * (20 sek /40 ml) = ca. drinkstørrelse * 0,5. Men det kan være annerledes for din pumpe og strømforsyning. Alexa Den øverste devicen (merket 4052) er egentlig bare på/av som er lagt inn i Alexa. Der har jeg også bare laget en rutine som skrur på device 4052 når Alexa hører "pour me a drink". Når devicen blir skrudd på har jeg et event som sender "20" til topic "/runtime", og skrur seg selv av (dvs. til "inactive" etter 20 sekunder). Så nå står den her på kjøkkenbenken. Tror jeg må få meg et barskap den kan passe inn i...

Hei. Jeg er såvidt igang med å ta i bruk MQTT som protokoll for logging av data, og ønsker i den forbindelse litt inspirasjon når det kommer til struktur i navngivingen. Jeg har en Wemos d1 mini som leser inn temperaturer fra noen DS18B20 temperatursensorer. Jeg ønsker at dette skal være et fleksibelt system, hvor jeg kan henge på flere sensorer på samme Wemos, men også programmere flere Wemos'er som "noder" i systemet. Et par utfordringer jeg har møtt på: Klientnavn på MQTT noden. For å slippe å endre koden for hver ny node har jeg sett for meg at jeg kan hente ut MAC-adressen til wemos'en og bruke denne som klientnavn. På denne måten vil hver klient være unik Fordeler: Autogenerert data som man slipper og forholde seg til Ulemper: Vanskelig å feilsøke/finne når noden kun har et autogenerert navn. Generering av topic. Her ser jeg for meg å hente ut den unike adressen fra hver sensor, og sende denne som topic. Jeg vil deretter ha en kryssreferanse eller lignende på "serverside" som linker hver sensor mot riktig objekt i database/HA/Whatever. Fordeler: med dette er at jeg kan flytte sensorer mellom forskjellige noder uten at det vil påvirke hvordan data sendes inn. En annen fordel er at jeg ikke risikerer at sensorer "bytter plass" når jeg kobler inn en ekstra sensor. Ulemper vil nok være at det er forholdsvis tungvindt å hente ut den unike adressen fra hver sensor. Det vil også være mer arbeid på serversiden, samt at det blir vanskeligere å feilsøke siden navnene er autogenerert. Tanken er å lage en robust og god løsning som fremtidig kan utvides til flere forskjellige typer sensorer og data. Målet er å ha et automatisk system hvor alle noder kan kjøre på samme arduino-prosjekt uten å måtte tilpasses individuellt. En annen måte å gjøre det på er å lese inn all data til en JSON-streng som deretter sendes på MQTT. Fordelen med dette er at det blir færre publiseringer til MQTT brokeren. En ulempe er at dette blir vanskeligere å lese/feilsøke, samt at det krever mer programmering på serverside. Så...hvordan strukturerer DU din MQTT kommunikasjon? Hvilke fordeler/ulemper har du erfart med måten du gjør det på? Hvilke fordeler/ulemper ser du med måten jeg ser for meg å sette ting opp på?

Har en RPi ZeroW som kjører Miflora MQTT Daemon for å hente ut data fra BTLE-sensorer i plantene våre. Dette har fungert utmerket, men i det siste har det blitt stille. Jeg vet ikke helt hva jeg skal gjøre for å få det til. Må sette opp Mosquitto (addon i Hass.io), og få klientfila på stell. Konfigen i Mosquitto er nå: { "logins": [], "anonymous": true, "customize": { "active": true, "folder": "mosquitto" }, "certfile": "fullchain.pem", "keyfile": "privkey.pem", "require_certificate": false } I tillegg til at jeg har lagt inn ACL som anbefalt: Porter er default Her er konfigen for MQTT-daemonen (klient) # Configuration file for Xiaomi Mi Flora Plant Sensor MQTT Client/Daemon # Source: https://github.com/ThomDietrich/miflora-mqtt-daemon # # Uncomment and adapt all settings as needed. [General] # The operation mode of the program. Determines wether retrieved sensor data is published via MQTT or stdout/file. # Currently supported: # # mqtt-json - Publish to an MQTT broker in a proprietary json format (Default) # mqtt-homie - Publish to an MQTT broker following the Homie MQTT convention # (https://github.com/marvinroger/homie) # mqtt-smarthome - Publish to an MQTT broker following the mqtt-smarthome proposal # (https://github.com/mqtt-smarthome/mqtt-smarthome) # homeassistant-mqtt - Publish to an MQTT broker following the HomeAssistant discovery format # (https://www.home-assistant.io/docs/mqtt/discovery/) # thingsboard-json - Publish to the ThingsBoard MQTT broker # (https://thingsboard.io) # wirenboard-mqtt - Publish to the Wiren Board MQTT broker # (https://wirenboard.com) # json - Print to stdout as json encoded strings # reporting_method = homeassistant-mqtt # The bluetooth adapter that should be used to connect to Mi Flora devices (Default: hci0) adapter = hci0 [Daemon] # Enable or Disable an endless execution loop (Default: true) enabled = true # The period between two measurements in seconds (Default: 300) period = 300 [MQTT] # The hostname or IP address of the MQTT broker to connect to (Default: localhost) hostname = <ip-til-hassio> # The TCP port the MQTT broker is listening on (Default: 1883) port = 1884 # Maximum period in seconds between ping messages to the broker. (Default: 60) keepalive = 60 # The MQTT base topic to publish all Mi Flora sensor data topics under. # Default depends on the configured reporting_method #base_topic = miflora # Default for: mqtt-json, mqtt-smarthome #base_topic = homie # Default for: mqtt-homie base_topic = homeassistant # Default for: homeassistant-mqtt #base_topic = v1/devices/me/telemetry # Default for: thingsboard-json #base_topic = # Default for: wirenboard-mqtt # Homie specific: The device ID for this daemon instance (Default: miflora-mqtt-daemon) #homie_device_id = miflora-mqtt-daemon # The MQTT broker authentification credentials (Default: no authentication) username = mqtt password = <MITTSUPERPASSORD> # Enable TLS/SSL on the connection tls = false # Path to CA Certificate file to verify host #tls_ca_cert = # Path to TLS client auth key file #tls_keyfile = # Path to TLS client auth certificate file #tls_certfile = [Sensors] *SNIP* MQTT er jo sagt at det er noe SÅÅÅÅÅ fantastisk og enkelt, men dette er elendig dokumentert, og klarer ikke finne gode guider på nett. Noen som kan fortelle meg hvordan jeg skal feilsøke? Hass.io kjører i docker på en RPi uten mye hokus pokus og annet som kjører på samme boks.

Jeg kjører HA på en Raspberry pi, hvor jeg også kjører node-red. Hvordan kan jeg vise en verdi i brukergrensesnittet til HA, som sendes i fra Node-red? Er løsning mqtt? Eller finnest det andre måter å vise data på?

Var innom en kamerat som hadde investert i noen ADAX WiFi panelovner. Han hadde litt trøbbel med å få de aktivert, og jeg ble litt interessert i å finne ut om de kanskje kunne autmatisers og kobles til MQTT. Fant bare ut at de dukker opp som Access punkter, og at de kommuniserer med en Azure backend. Har kontaktet ADAX for å høre om de evt. kan gi sin velsignelse... Noen som har erfaringer? Kanskje noen som har åpnet en ovn og kikket inni?

Hass har støtte for en del ting som ikke (enda) er i Homeseer, f.eks. Twinkly og Roborock og sikkert en del andre som jeg ikke har funnet ut av enda. Ser en del andre bruker Hass som et, skal vi si støttesystem, til Homeseer for nettopp å kunne styre ting som ikke kan styres fra Homeseer. Så da har jeg satt opp en Pi med Hass.IO, og det funker fint. Men så var det dette med koblingen mellom Homeseer og Hass. Ser noen anbefaler å bruke MQTT, som jeg ikke har brukt enda. Er usikker på om jeg skal legge inn broker (Mosquitto eller den som følger med Hass?) på Pi'en eller et annet sted? Så har jeg lastet ned mscMQTT-pluginen til Homeseer og installert den, uten at jeg har filla peiling på hvordan den skal brukes. At den i tillegg bruker 100% CPU er jo et artig tilleggsproblem, men det kan sikkert løses. Så, poenget: Er det noen som har en oppskrift for dummies som kan brukes til dette?

Hei, Vinteren nærmer seg og dører og vinduer lukkes, da er det vel på sin plass å følge med på at Radon nivået holder seg innenfor sunne grenser, jeg har derfor "tuklet" litt med Airthings og tilpasset deres RaspberryPI script slik at jeg kan bruke og logge verdiene i openHAB. Jeg har valgt (for meg enkleste løsning) å gå via mqtt/mosquitto slik at løsningen også kan tilpasses og brukes av andre systemer. Last ned filene og følg instruksene, vær obs på at jeg kan hverken bash eller python, men ved hjelp av Google og masse prøv å feil fikk jeg det da til å virke, og løsningen har nå gått stabilt på to forskjellige systemer i et par måneders tid. Kommentarer og ikke minst forbedringer mottas med takk. read_wave.py inneholder instruksene og informasjonen du trenger. read_wave.sh er scriptet som kjøres for å oppdatere verdiene (må tilpasses din Wave). Airthings.ITEMS er et eksempel på openHAB items for bruk med scriptene over. /Ole Airthings.items read_wave.py read_wave.sh

Project Rotini er et svært attraktivt dashboard for ditt hjemmeautomasjon-system som inntil nå kun har vært tilgjengelig for openHAB brukere. Etter siste pressemelding fra skaperen av Rotini (Igor Gladkov) vil neste versjon ha full støtte for openHAB og Home Assistant + andre systemer som støtter MQTT protokollen. Det er også planlagt versjoner for Android wear/TV og iOS i fremtiden. Hele pressemeldingen kan du lese under: Vis full oppføring

Prøvd å søke litt på homeseer forumet men finner bare snakk om mqtt inbound til homeseer men ikke utgående. Noen som vet om det er grei skuring å eksportere zwave enheter til en mqtt server.

Hei, Har begynt å se på diverse led-strips, og i min søken etter en måte å styre dette på, uten å måtte betale 500,- pr kontroller, så kom jeg over denne: http://tinkerman.cat/closer-look-h801-led-wifi-controller/ Det er en wifi-enablet kontroller som med flashet firmware lar deg styre led-strips via MQTT. Noen som har erfaring med den? Ja, jeg vet det ikke er zwave, men lurer litt på om det er verdt ett forsøk for å lage en enkel styring. TJ