Home Assistant - For Dummies (hass.io)

Ja tosiaan kuten tuossa sanoinkin, niin suurin este täysin toisenlaisen uppovalaisimien vaihdolle on rakennusvaiheessa sahattu 95mm asennusreikä, johon ei tunnu kirveelläkään löytyvän sopivaa Zigbee valaisinta. Aukon suurentaminenkaan ei luonnollisesti ole mikään ihan helppo temppu näin jälkikäteen.

Mieluiten vaihtaisin tilalle gu10 kantaisen uppovalon, mutta pitäisi varmaan 3d-tulostaa adapteri, että ne saisi sopimaan tuohon asennusreikään.
 
Jos valon peitelevy on tarpeeksi iso niin voi tosiaan pienentää reikää tulosteella. Mutta periaattessa jos liimaat jotkut "tikut" (puunpalat tms) reikään minkä taakse uuden valon pidikkeet menee niin pääsee varmaan vähimmällä.
 
Ja tosiaan kuten tuossa sanoinkin, niin suurin este täysin toisenlaisen uppovalaisimien vaihdolle on rakennusvaiheessa sahattu 95mm asennusreikä, johon ei tunnu kirveelläkään löytyvän sopivaa Zigbee valaisinta. Aukon suurentaminenkaan ei luonnollisesti ole mikään ihan helppo temppu näin jälkikäteen.

Mieluiten vaihtaisin tilalle gu10 kantaisen uppovalon, mutta pitäisi varmaan 3d-tulostaa adapteri, että ne saisi sopimaan tuohon asennusreikään.

Ainakin Bacholla on tuollaisia suurennusmuuntokappaleita jolla olemassaolevaa reikää saa suurennettua. Toimivuudesta ei ole kokemusta.

 
Ilman tuollaista muuntokappaletta. Sahaa puusta saman kokoisella reikäsahalla rinkula, kuin alkuperäinen reikä sulla siellä on ja laita se ohjuriksi siihen suurempaan reikäsahaan. Jos tietysti ylipäätään sitä reikää saa suurennettua.
 
Mutta takaisin alkuperäiseen kysmykseen: jos puhutaan tuosta WiFi valaisimesta, niin ilmeisesti valaisin otetaan käyttöön jossain näistä (korjatkaa jos olen väärässä):
-Google Home
-Amazon Alexa
-Tuya Smart

Oma HA pyörii dockerilla ja siellä ainakaan suoraa integraatiota ole Googlen tai Amazonin appeihin, tämä ei toki tarkoita etteikö niitä silti sinne saisi manuaalisesti konfiguroitua. Tuya integraatio näyttää löytyvän.

Onko Home Assistantissa jotain muuta tapaa konfiguroida WiFi laitteita osaksi omaa ekosysteemiä?

E: päivitin docker imagen uuteen tuosta 2021 versiosta ja integraatioiden määrä moninkertaistu (mm. Google ja Amazon).
 
Viimeksi muokattu:
Vaatiiko tuo kiosk ohjelma laitteelta juuri mitään? Ajatus tehdä huawei mediapad T3 tämmönen home assistant näyttö.
 
Vaatiiko tuo kiosk ohjelma laitteelta juuri mitään? Ajatus tehdä huawei mediapad T3 tämmönen home assistant näyttö.
Mulla pyörii kioski Lenovon M10 tabletissa. Toimii ihan ok tuossa käytössä, mitä nyt välillä on tabletti jumitellut ja joutuu buuttaamaan sen. Nopealla vilkaisulla tuossa T3 taitaa olla vähän parempi rauta, niin voisi kuvitella parempaa toimivuutta.
 
Mulla pyörii kioski Lenovon M10 tabletissa. Toimii ihan ok tuossa käytössä, mitä nyt välillä on tabletti jumitellut ja joutuu buuttaamaan sen. Nopealla vilkaisulla tuossa T3 taitaa olla vähän parempi rauta, niin voisi kuvitella parempaa toimivuutta.
Tuo kiosk oli ilmeisesti kk maksullinen?
 
Ja tosiaan kuten tuossa sanoinkin, niin suurin este täysin toisenlaisen uppovalaisimien vaihdolle on rakennusvaiheessa sahattu 95mm asennusreikä, johon ei tunnu kirveelläkään löytyvän sopivaa Zigbee valaisinta. Aukon suurentaminenkaan ei luonnollisesti ole mikään ihan helppo temppu näin jälkikäteen.

Mieluiten vaihtaisin tilalle gu10 kantaisen uppovalon, mutta pitäisi varmaan 3d-tulostaa adapteri, että ne saisi sopimaan tuohon asennusreikään.
Moesilta ainakin löytyy 90mm Zigbee-valaisimia (kauluksen kanssa 115mm), eli peittää kyllä reiän.
 
Itseasiassa hämäsin näköjään vähän, eihän se sitä looppia enää lopussa tarvitse.:D

YAML:
  - sensor:
      - name: cheapest_total_price
        state: >
          {% set ns = namespace(cheapestHourPrice=0) %}
          {% set tomorrow = now() + timedelta( days = 1 ) %}
          {% set data = state_attr("sensor.shf_electricity_price_now", "data") %}
          {% for item in data %}
            {% if item.Rank == 1 and as_datetime(item.DateTime).date() == now().date() %}
              {% set ns.cheapestHourPrice = item.PriceWithTax | float + 0.0419 %}
            {% endif %}
          {% endfor %}
          {% for item in data %}
            {% if item.Rank == 1 and as_datetime(item.DateTime).date() == tomorrow.date() %}
              {% set ns.cheapestHourPrice = item.PriceWithTax | float + 0.0419 %}
            {% endif %}
          {% endfor %}
          {{  ns.cheapestHourPrice }}
Innostuin jatkokehittelemään ja kokeilin ensikertaa käyttää tekoälyä apuna.
Sain aikaiseksi tällaisen koodin, joka nyt ainakin tuntuisi toimivan, ellei mene rikki iltapäivällä kun tulee huomisen hinnat.
Eli idea on se, että ei käytetä pelkästään Rank 1:stä, vaan niin monen Rank X:n keskiarvoa kun on valittu shf_rank_slider helpperillä.
Idea tästä tuli siitä, kun viime yönä oli erikoiset hinnat. Rank 1 oli todella halpa verrattuna esim. Rank 2->.

YAML:
  - sensors:
      shf_rank_slider_average_price:
        unit_of_measurement: '€/kWh'
        value_template: >
          {% set ns = namespace(totalPrice=0, count=0) %}
          {% set tomorrow = now() + timedelta( days = 1 ) %}
          {% set data = state_attr("sensor.shf_electricity_price_now", "data") %}
          {% set rank_slider_value = states('input_number.shf_rank_slider') | int %}
          {% for item in data %}
            {% if item.Rank <= rank_slider_value %}
              {% set ns.totalPrice = ns.totalPrice + item.PriceWithTax | float %}
              {% set ns.count = ns.count + 1 %}
            {% endif %}
          {% endfor %}
          {% if ns.count > 0 %}
            {{ (ns.totalPrice / ns.count + 0.0419) | round(4) }}
          {% else %}
            0
          {% endif %}

Tarkoitus vielä kehittää keskiarvolaskentaa painottaen kolmea ensimmäistä Rankkia.

EDIT: Eipä tämä toimi, kun seuraavan päivän hinnat ilmestyivät. Ihan päin tekoälyn persettä laskee.
 
Viimeksi muokattu:
Mikähän voisi olla syynä, että HA:n template sensori toimii develop toolssissa, mutta kun sen syöttää configuaatioon, niin HA sen hyväksyy ja antaa tallentaa, mutta kun HA käynnistetään, niin sensori on unavailable.
Ei pitäisi olla sisennyksissäkään vikaa, koska HA sen hyväksyy..
Tuo edellisen viestin sensorini toimii hyvin, mutta kun sinne lisäsin tekoälyn avulla niitä painotuksia, niin se ei sitten toimikkaan enää.

YAML:
  - sensors:
      shf_rank_slider_average_weighted_price:
        unit_of_measurement: '€/kWh'
        value_template: >
          {% set ns = namespace(totalPrice=0, count=0, weightedTotal=0) %}
          {% set tomorrow = now() + timedelta( days = 1 ) %}
          {% set data = state_attr("sensor.shf_electricity_price_now", "data") %}
          {% set rank_slider_value = states('input_number.shf_rank_slider') | int %}
          {% set weight = [1, 1, 1, 0.5, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3] %}  # Painotusarvot tuntien mukaan

          {% for item in data %}
            {% if item.Rank <= rank_slider_value %}
              {% set ns.totalPrice = ns.totalPrice + item.PriceWithTax | float %}
              {% set ns.weightedTotal = ns.weightedTotal + (item.PriceWithTax * weight[item.Rank - 1]) | float %}
              {% set ns.count = ns.count + 1 %}
            {% endif %}
          {% endfor %}

          {% if ns.count > 0 %}
            {{ (ns.weightedTotal / ns.count + 0.0419) | round(4) }}
          {% else %}
            0
          {% endif %}

EDIT: Noniin, logeista löytyi vinkki. Eli tuo # kommentti tuolla keskellä koodia sotki sensorin, eli sen poistamalla rupesi pelittämään.

EDIT2: Eipä tämä toimi, kun seuraavan päivän hinnat ilmestyivät. Ihan päin tekoälyn persettä laskee.
 
Viimeksi muokattu:
Mikähän voisi olla syynä, että HA:n template sensori toimii develop toolssissa, mutta kun sen syöttää configuaatioon, niin HA sen hyväksyy ja antaa tallentaa, mutta kun HA käynnistetään, niin sensori on unavailable.
Ei pitäisi olla sisennyksissäkään vikaa, koska HA sen hyväksyy..
Tuo edellisen viestin sensorini toimii hyvin, mutta kun sinne lisäsin tekoälyn avulla niitä painotuksia, niin se ei sitten toimikkaan enää.

YAML:
  - sensors:
      shf_rank_slider_average_weighted_price:
        unit_of_measurement: '€/kWh'
        value_template: >
          {% set ns = namespace(totalPrice=0, count=0, weightedTotal=0) %}
          {% set tomorrow = now() + timedelta( days = 1 ) %}
          {% set data = state_attr("sensor.shf_electricity_price_now", "data") %}
          {% set rank_slider_value = states('input_number.shf_rank_slider') | int %}
          {% set weight = [1, 1, 1, 0.5, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3] %}  # Painotusarvot tuntien mukaan

          {% for item in data %}
            {% if item.Rank <= rank_slider_value %}
              {% set ns.totalPrice = ns.totalPrice + item.PriceWithTax | float %}
              {% set ns.weightedTotal = ns.weightedTotal + (item.PriceWithTax * weight[item.Rank - 1]) | float %}
              {% set ns.count = ns.count + 1 %}
            {% endif %}
          {% endfor %}

          {% if ns.count > 0 %}
            {{ (ns.weightedTotal / ns.count + 0.0419) | round(4) }}
          {% else %}
            0
          {% endif %}

EDIT: Noniin, logeista löytyi vinkki. Eli tuo # kommentti tuolla keskellä koodia sotki sensorin, eli sen poistamalla rupesi pelittämään.

EDIT2: Eipä tämä toimi, kun seuraavan päivän hinnat ilmestyivät. Ihan päin tekoälyn persettä laskee.
En tiiä meneekö nuo painotusarvot pieleen kun datasta löytyy 48 tuntia 24 sijaan.

Kerro selkokielellä mitä tuossa on tarkoitus tehdä niin kokeilen illalla onko oikea ei-koodariäly keinoälyä fiksumpi!
 
En tiiä meneekö nuo painotusarvot pieleen kun datasta löytyy 48 tuntia 24 sijaan.

Kerro selkokielellä mitä tuossa on tarkoitus tehdä niin kokeilen illalla onko oikea ei-koodariäly keinoälyä fiksumpi!
Ei tarvitse enää. Sain ilmeisesti vihdoin sen toopen takoälyn tajuamaan, mitä haluan ja jouduin opettamaan sille tuon sinun skriptin avulla miten huomista dataa käsitellään. :)

Tässä vielä lopputulos, joka vaikuttaisi siis toimivan ainakin developer toolissa. Sisennyksissä voi olla vielä jotain häikkää.

YAML:
  - platform: template
  sensors:
    shf_rank_1_average_price:
      unit_of_measurement: '€/kWh'
      value_template: >
        {% set ns = namespace(totalPrice=0, count=0) %}
        {% set data = state_attr("sensor.shf_electricity_price_now", "data") %}
        {% set tomorrow = now() + timedelta(days=1) %}
        {% set rank_slider_value = states('input_number.shf_rank_slider') | int %}
   
        {% set weights = [1, 1, 1, 0.5, 0.5, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3] %}
   
        {% for item in data %}
          {% if item.Rank <= rank_slider_value and as_datetime(item.DateTime).date() == tomorrow.date() %}
            {% set weight = weights[item.Rank - 1] %}
            {% set ns.totalPrice = ns.totalPrice + (item.PriceWithTax * weight) | float %}
            {% set ns.count = ns.count + 1 %}
          {% endif %}
        {% endfor %}
   
        {% if ns.count > 0 %}
          {{ (ns.totalPrice / ns.count + 0.0419) | round(4) }}
        {% else %}
          0
        {% endif %}

Slider helperillä valitaan arvo 1-24, joka on siis se monen rankin keskiarvoa halutaan laskea.
Painotetaan vain kolmea ensimmäistä rankkiä keskiarvon laskemisessa, tosin käytännössä slider on aina asennossa 1-5.
Enää en jaksa, mutta kai toi 0,0419 siirtomaksu pitää vielä omaan helpperiin siirtää, ettei tartte koodia korjailla jos siirtomaksu muuttuu. :)

Ps. Sinänsä opettavaa touhua ja tunteja kun päätä hakkaa seinään, niin alkaa pikkuhiljaa hahmottamaan miten nuo koodit vaikuttaa. Toki heti kun smartääs tekoäly löi jonkin megakoodin kokeiltavaksi, niin ei siitä ottaan selkoa sen hölkkäsen pöläystä. Mutta kun piti koodin pienenä, ja pikku muutoksia kerrallaan, niin jotain alkoi hahmottamaan. Sinänsä kai ihan kova juttu tälläselle melkein 50v ukolle, joka ei ole ikinä koodannut. No ehkä jollain C64:lla jotain basicin alkeita.
 
Viimeksi muokattu:
Heh, nyt kun vuorokausi vaihtui, niin taisi taas mennä perseelleen tuon tekotioopeälyn koodit. No minkäs teet. Taitaa ottaa nyt huomisen tunteja vaikka ovat tyhjää täynnä, eli 0. Tämä tekoäly ei ainakaan valloita maailmaa.

EDIT: Jep varmistettu, että nyt kun seuraavanpäivän hinnat saapuivat heräsi sensori taas henkiin. Eli ei osaa pelkkää kuluvan päivän dataa enää hakea.
 
Viimeksi muokattu:
Heh, nyt kun vuorokausi vaihtui, niin taisi taas mennä perseelleen tuon tekotioopeälyn koodit. No minkäs teet. Taitaa ottaa nyt huomisen tunteja vaikka ovat tyhjää täynnä, eli 0. Tämä tekoäly ei ainakaan valloita maailmaa.
Heh, itse olen huomannut saman asian monessa asiassa, tekoäly on kyllä ihan hyvä apuri monessa asiassa mutta sen perään pitää katsoa aika tarkkaan. Itsekin olen erilaisia koodinpätkiä ja automaatioita kysynyt AI:lta mutta käytännössä lähes aina niissä on ollut jotain käsin korjattavaa eli joka tapauksessa on joutunut käymään AI:n tuottaman ratkaisun läpi manuaalisesti. Jossain perus-koodintuottamisessa se kyllä loistaa, monesti kun tietää että johonkin pikku juttuun pitää kirjoittaa pirusti koodia niin sen turhan kirjoittamisen voi pyytää tekoälyltä ja sitten paikkaa loput itse toimivaksi.
 
Mites tehdää sensori true/false?

eli jos jokin arvo on pienenmpi kuin toinen arvo = True ja jos suurempi niin false? tai voihan sen toteuttaa 1 ja 0 arvoillakin, mutta en keksi miten saan sensoriin sen arvoksi laskun perusteella.
 
Mites tehdää sensori true/false?

eli jos jokin arvo on pienenmpi kuin toinen arvo = True ja jos suurempi niin false? tai voihan sen toteuttaa 1 ja 0 arvoillakin, mutta en keksi miten saan sensoriin sen arvoksi laskun perusteella.
HA:ssa ei ole true/false sensoria, mutta binary sensor, jonka arvot ovat on/off on täysin vastaava. Eli tee template binary sensor, jonka arvo lasketaan jonkin muiden arvojen (sensorien?) tilasta.

 
En saanut aikaisemmin otettua Influxia käyttöön. Tuota tutkiessa sinne tallentuu data kun arvo muuttuu? Onkohan tuota jotenkin mahdollista muokata että otetaan arvo vain 5 min välein talteen tai sitten vaihtoehtoisesti ajaa joku scripti mikä poistaa muut?
 
En saanut aikaisemmin otettua Influxia käyttöön. Tuota tutkiessa sinne tallentuu data kun arvo muuttuu? Onkohan tuota jotenkin mahdollista muokata että otetaan arvo vain 5 min välein talteen tai sitten vaihtoehtoisesti ajaa joku scripti mikä poistaa muut?
On toki molemmat mahdollista ihan kuten minkä tahansa tietokannan kanssa, mutta miksi haluaisit tehdä näin?
 
On toki molemmat mahdollista ihan kuten minkä tahansa tietokannan kanssa, mutta miksi haluaisit tehdä näin?
Kun Xiaomit antaa aika usein sitä uutta dataa noin 40s välein kun katsoo lukemia. Toki voisi katsoa voiko tuota jotenkin sensorin päästä pienentää. Hyvin riittäisi arvo 5min välein.
 
Kun Xiaomit antaa aika usein sitä uutta dataa noin 40s välein kun katsoo lukemia. Toki voisi katsoa voiko tuota jotenkin sensorin päästä pienentää. Hyvin riittäisi arvo 5min välein.
Niin varmaan riittäisi, mutta mitä hyötyä saat siitä harvemmasta arvosta? Tilaa nuo ei vie yhtään mitään ja Influx on kyllä tehty kestämään suuria datamääriä.
 
Niin varmaan riittäisi, mutta mitä hyötyä saat siitä harvemmasta arvosta? Tilaa nuo ei vie yhtään mitään ja Influx on kyllä tehty kestämään suuria datamääriä.
Tilaa tuolla enimmäkseen haen takaa. Että tietokanta ei kasvaisi liian suureksi.
 
Tilaa tuolla enimmäkseen haen takaa. Että tietokanta ei kasvaisi liian suureksi.
Törmäsinpä juuri tällaiseen postaukseen, jossa kerrottu miten Influxissa on helppo tehdä downsampling eli harventaa datan sampleratea kun se vanhenee:
 
Vinkkejä hyvistä 5m led nauhoista jotka toimisi HA:n kanssa? 4000k valkoinen valo pitäisi olla. Zigbee tai Wifi.
 
Mä oon ostanut nauhaa, muuntajan ja zigbee palikan. Toimii loistavasti. Ihan pelkkään kirkkaus säätöön tai värien kanssa.
 
Tuli ehkä oikosulku.
Mutta liiketunnistin if elsellä sytyttää valoja. Saiskos samaan automaatioon jotenkin vielä auringon/kellon mukaan edes jonkinlaisen kirkkauden säädön?
 
Vinkkejä hyvistä 5m led nauhoista jotka toimisi HA:n kanssa? 4000k valkoinen valo pitäisi olla. Zigbee tai Wifi.
Annetaas pikaiset esimerkitkin.

Screenshot_2023-09-21-23-19-42-152_com.alibaba.aliexpresshd.jpg
Screenshot_2023-09-21-23-20-30-551_com.alibaba.aliexpresshd.jpg
Screenshot_2023-09-21-23-21-22-588_com.alibaba.aliexpresshd.jpg
Screenshot_2023-09-21-23-22-55-042_com.alibaba.aliexpresshd.jpg
Eli äkkiseltään 30€. Ei sitten kestä vettä. Muuten noi on toimineet.
 
  • Tykkää
Reactions: njs
Oletteko tuolla nordpoolilla laskeneet siirtoa mukaan?
Tuollahan on tuo additional cost mutta se ei taida ymmärtää sitä, että kun ollaan liikaa miinuksella, niin siirto tulisi maksaa aina. Vai pitääkö tehdä toinen laskenta, että samat kwh mutta aina tietty hinta? Vai miten olette tehneet?
 
Oletteko tuolla nordpoolilla laskeneet siirtoa mukaan?
Tuollahan on tuo additional cost mutta se ei taida ymmärtää sitä, että kun ollaan liikaa miinuksella, niin siirto tulisi maksaa aina. Vai pitääkö tehdä toinen laskenta, että samat kwh mutta aina tietty hinta? Vai miten olette tehneet?
Olen käyttänyt Eddyn mainiota Nordpool-integraatiota laajentavaa laskentaa, jossa on mukana verot, siirtohinta ja sähköyhtiön marginaali. Tällä näen sähkön todellisen hinnan. Siinä lisätään joukko inputteja, joilla määritellään tarvittavat lisäkulut ja sen jälkeen saadaan uusi arvo "Käyttösähkön kokonaishinta tällä hetkellä" ja "Sähkön hinta alle kipurajan" -binäärisensori, jolla voi tehdä suoraan ehtoja automaatioihin.
 
Oletteko tuolla nordpoolilla laskeneet siirtoa mukaan?
Tuollahan on tuo additional cost mutta se ei taida ymmärtää sitä, että kun ollaan liikaa miinuksella, niin siirto tulisi maksaa aina. Vai pitääkö tehdä toinen laskenta, että samat kwh mutta aina tietty hinta? Vai miten olette tehneet?
Itse olen siirtynyt käyttämään ao. spot-hinta.fi -rajapintaa hyödyntävää skriptiä. Tuohon saa laitettua siirtohinnat ja marginaalit myös siten että huomioi yösiirron jos käytössä. Muutenkin tuntuu toimivan paljon varmemmin kuin nordpool-integraatio joka aina välillä jätti seuraavan päivän hinnat hakematta.


Tekijä aktiivinen lämpöpumppufoorumilla
 
Näyttäisi olevan monipuolisempi ja samalla ns. kevyempikin.
 
Pitäisi toteuttaa seuraavanlainen automatisointi paljulle HA:lla

  • pakkasvahti, eli pumppu lähtee päälle kun keli menee miinuksen puolelle ja pysyy päällä kunnes keli taas plussalla
  • pakkasvahti, jos veden lämpötila painuu 0 tai alle niin kytkee lämmittimen päälle (vaatii että pumppu on päällä) ja kun vesi on +5 niin lämmitin sammuu. Lähettää ilmoituksen että jäätymisvaara.
  • Suodatussykli joka päivä 4h tuntia päivän halvimmilla tunneilla
  • Valvoo pumppaamon lämpötilaa

Laitteistona on Shelly pluis 2pm jossa add-on ja kolme DS18B20 lämpötila anturia. yksi mittaa vettä, yksi ulkolämpötilaa ja yksi pumppaamon lämpötilaa. lämmitin ja pumppu omien hagerin releiden takana joita shelly käskyttää.

Miten tätä lähtisit toteuttamaan? miten esim toteutetaan se että jos ilma on pakkasella ja pumppu käy niin tuo päivittäinen suodatus sykli ei lopettaessaan katkaise myös tuota ilmanlämpötilan mukaan tehtyä ohjausta? Sitten vielä se että kun paljua lämmitetään niin osaa pysäyttää ja jatkaa nuo pakkasvahti automaatiot vaikka veden lämpöjen mukaan.

Toisaalla tähän tarjottiin jo vaihtoehdoksi ESP32 pohjaista ratkaisua ja suoraan shellyyn scriptejä jne.... Esp menee jo mun ymmärryksen yli ja shellyn scriptit eli koodaaminen myös aika utopiaa.
 
Onko ideoita miksi Xiaomin valvontakamera ei oikein tahdo toimia tässä? Löytyi kyllä hienosti muiden Xiaomin laitteiden tapaan, mutta live-kuvaa olen saanut näkyviin kerran ja hälytystallenteetkaan ei toimi? Ilmanpuhdistin ja imuri sen sijaan toimivat täydellisesti.
 
Onko jollain ideaa miten saada tarkasti ja reaaliaikaisesti tieto että auto on saapunut kotiin / lähtenyt kotoa? Corollassa on kyllä GPS ja se integroitu HA:han mutta status päivittyy 5min myöhässä. Riittäisikö esim joku zigbee-lämpömittari tms jos vaan kantama riittää?
 
Onko jollain ideaa miten saada tarkasti ja reaaliaikaisesti tieto että auto on saapunut kotiin / lähtenyt kotoa? Corollassa on kyllä GPS ja se integroitu HA:han mutta status päivittyy 5min myöhässä. Riittäisikö esim joku zigbee-lämpömittari tms jos vaan kantama riittää?

Toimisiko tähän "sänkysensori", eli zigbee kontaktisensorista viritelty paineentunnistin, jonka päälle auton jokin rengas aina asettuu. Youtubesta löytyy zigbee bed sensor nimellä vaikka mitä. Kustannukset kiinasta alle kympin.

Toinen halpa olisi liikkeentunnistin, mutta se pitäisi saada just sopivaan kulmaan niin ettei sitä triggeröi mikään muu kuin auton liike.

Heitä autoon AirTägi tai Samsung SmartTag ja kotona joku EspHome laite seuraa sen bluetooth signaalin läsnäoloa. EspHomessa taikasanat ehkä esp32_ble_tracker: ja platform: ble_presence.
 
Toimisiko tähän "sänkysensori", eli zigbee kontaktisensorista viritelty paineentunnistin, jonka päälle auton jokin rengas aina asettuu. Youtubesta löytyy zigbee bed sensor nimellä vaikka mitä. Kustannukset kiinasta alle kympin.

Toinen halpa olisi liikkeentunnistin, mutta se pitäisi saada just sopivaan kulmaan niin ettei sitä triggeröi mikään muu kuin auton liike.

Heitä autoon AirTägi tai Samsung SmartTag ja kotona joku EspHome laite seuraa sen bluetooth signaalin läsnäoloa. EspHomessa taikasanat ehkä esp32_ble_tracker: ja platform: ble_presence.
Itselle tuli mieleen yhdeksi mahdolliseksi vaihtoehdoksi kamera ja siihen perään jotain videoanalytiikkaa, syystä että on tullut töissä leikittyä vähäsen videoanalytiikan kanssa ja sillä saa tehtyä kaikkea kivaa. Ei tietty ole ihan halvimmasta päästä oleva ratkaisu mutta tuollaisella saisi jo kohtalaisen luotettavan ja lähestulkoon reaaliaikaisen (viive sekuntiluokassa) tiedon onko auto ruudussa vai ei ja samalla tiedon jos paikalla onkin jotain muuta kuin auto, jota mitkään paineanturit tai liiketunnistimet eivät oikein voi tunnistaa. Sopivalla kameran sijoittelulla voisi jopa lukea rekisterinumeron.
 
Onko jollain ideaa miten saada tarkasti ja reaaliaikaisesti tieto että auto on saapunut kotiin / lähtenyt kotoa? Corollassa on kyllä GPS ja se integroitu HA:han mutta status päivittyy 5min myöhässä. Riittäisikö esim joku zigbee-lämpömittari tms jos vaan kantama riittää?
Eikö juuri tuo zigbee -lämpömittari hoida homman? Siis jos se kytkeytyy zigbee verkkoon ns reaaliajassa?
Ihan mielenkiinnosta, mihin tarkoitukseen pitää tietää reaaliajassa auton lähtö/ saapuminen?
 
Eikö juuri tuo zigbee -lämpömittari hoida homman? Siis jos se kytkeytyy zigbee verkkoon ns reaaliajassa?
Ihan mielenkiinnosta, mihin tarkoitukseen pitää tietää reaaliajassa auton lähtö/ saapuminen?
Tuskin ainakaan hyvin riippuen anturista. Voi mennä pitkäkin aika ennen kuin "tippuu verkosta" ja kun on tarpeeksi pitkään irti voi vaatia vielä enemmän aikaa takaisin liittymiseen. Tee-se-itse -ratkaisuilla tilannetta voi parantaa, mutta tosiaan esim. se BT beacon paljon toimivampi suoraan.

Kyllähän nopeahkolle tiedolle on esim. ulkovaloille, lukitukselle jne. hyötyä.
 
Eikö juuri tuo zigbee -lämpömittari hoida homman? Siis jos se kytkeytyy zigbee verkkoon ns reaaliajassa?
Ihan mielenkiinnosta, mihin tarkoitukseen pitää tietää reaaliajassa auton lähtö/ saapuminen?

Niin no tuo tuli Zigbee-sensori tuli ekana mieleen, mutta ei oo oikein kokemusta miten tommonen toimis.

Reaaliaikainen oli ehkä vähän liioiteltu, sanotaan että jos 30sek sisään kotiin tulosta toimisi niin olisi hyvä. Nyt kun tuo Toyota päivittää 5min jälkeen sijaintinsa kotiin niin sillä ei paljoa mitään tee.
 
Niin no tuo tuli Zigbee-sensori tuli ekana mieleen, mutta ei oo oikein kokemusta miten tommonen toimis.

Reaaliaikainen oli ehkä vähän liioiteltu, sanotaan että jos 30sek sisään kotiin tulosta toimisi niin olisi hyvä. Nyt kun tuo Toyota päivittää 5min jälkeen sijaintinsa kotiin niin sillä ei paljoa mitään tee.
No en itsekään tiedä miten lämpötilasensori voisi toimia. Mutta ainakin zigbee lamput tupsahtaa saman tien aktiiviksi HA:han kun pistää virrat päälle...
 
No en itsekään tiedä miten lämpötilasensori voisi toimia. Mutta ainakin zigbee lamput tupsahtaa saman tien aktiiviksi HA:han kun pistää virrat päälle...
Tuo riippuu myös paljon siitä toimiiko zigbee-laite reitittiminenä vai ei, yleensä verkkojännitteiset laitteet kuten lamput toimivat mutta paristokäyttöisistä ei taida mikään toimia reitittiminenä ja silloin ne löytävät verkon huomattavasti hitaammin. Lisäksi paristokäyttöisissä on kaikenlaisia virransäästötoimintoja joten muutenkin kommunikoivat zigbee-verkossa paljon harvemmin, esim 5min tai 15min välein.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
262 475
Viestejä
4 558 111
Jäsenet
74 971
Uusin jäsen
Maikkol

Hinta.fi

Back
Ylös Bottom