IV-ohjauslogiikan rakentaminen ESP32 alustalle

[Hegsa]

Iltapuhteina tuli omaan ilmanvaihtoon instrumentoitua hieman lisämittauksia. Tällä hetkellä poistokanavistossa on ylimääräisenä ESP32:n pyörittämässä ESPhomea johon kytkettynä BME280, PMS5003 ja MH-Z19. ESP32 lähettää Home Assistantiin seuraavat tiedot:

Näiden mittausten perusteellaa voisi IV:ä siirtyä ohjaamaan esim CO2-pitoisuuden ja muutaman muun parametrin perusteella. Nilanin IV-koneessa löytyy modbus-lähtö, joka tällä hetkellä on valjastettu RS485-to-Eth sovittimella keskustelemaan HA:n kanssa. HA:lla on helppoa tehdä vaikka mitä ohjauksia, mutta kyseessä ei ole mikään SCADA enkä haluaisi laittaa IV:n ohjausta sen taakse. Kierrättäminen HA:n kautta ei myöskään ole mitenkään välttämätöntä kun modbus-ohjauksen voisi tehdä suoraan ESP32:lla lokaalisti IV-koneen vieressä ESPhomella. Seurantaa varten haluaisin kuitenkin pitää myös HA yhteyden mukana, mutta ilmeisesti kahden modbus-ohjaimen liittäminen samaan väylään pitäisi olla ok.

Onko kenelläkään kokemusta vastaavan setupin tekemisestä tai ylipäätänsä sopivasta raudasta tähän tarkoitukseen? ESP32 ja ESPhome valikoitui ensihätään alustaksi helppouden vuoksi, mutta paremman raudan ja softan perässä voisi alustan vaihtaa.

 

[Espejot]

Onko kenelläkään kokemusta vastaavan setupin tekemisestä tai ylipäätänsä sopivasta raudasta tähän tarkoitukseen? ESP32 ja ESPhome valikoitui ensihätään alustaksi helppouden vuoksi, mutta paremman raudan ja softan perässä voisi alustan vaihtaa.

Ei ole kokemusta vastaavasta... mulla jäi hieman vastaava projekti kesken ja odottaa uudelleen käynnistystä. Haukkasin kunnon palan kakku (wago) ja tuli ähky. Eli mietin miten saada plaoteltua projekti pienempiin osiin joita rakentaa IV jäähdytyksen päälle.

Eli seuraan mielenkiinolla jos ei muuten niin antureiden osalta.

 

[Hegsa]

Antureiden osalta uudelleen tehdessä valitsisin toisin heti Tilankäytön ja piuhoituksen osalta olisi pitänyt mennä kaikissa antureissa I2C-protokollalla ja mieluiten yhdellä jännitteellä ESP:ltä. Helpottaisi merkittävästi kun riittäisi vain toisen puolen pinnit eikä tarvisi vielä kuin 4 karvaa mitä jakaa antureiden päässä tarvitseville.

Scopen osalta koetan pitää mahdollisimman yksinkertaisena. Nilanissa on tarjolla 4 tasoa (poissa/normaali/tehostus/takka&liesituuletin) ja fiksuinta varmaan on ohjata ESP:llä pelkästään 1 tason prosentteja jolloin aluksi normikäyttö sekä poikkeustilanteet hoituu Nilanin omalla logiikalla.

 

[HotZone]

Minulla on ollut nyt noin 5 vuotta käytössä Arduino Mega:lla tehtynä IV-koneen täysohjaus
- kennon pyörityksen ohjaus optimoimaan sisälämpötila eri sisä-ja ulkolämpötilatilanteissa
- EC-puhaltimien ohjaus perustuen paine-eromittaukseen höyrynsulun yli
- graafinen käyttöliittymä 3.5" näytöllä. (tämä pyörii omana yksikkönään myös Megalla)
pääyksikkö ja käyttöyksikkö juttelee sarjaväylällä omalla kehysprotokollalla.
Lisäksi on yksi NodeMCU tai vataava 32bit wifi-prossu (en muista ulkoa) prossu mikä tallentelee tietoa SQL palvelimelle. Tai oikestaan tällainen oli. Parikin tällaista possahti omia aikojaan. Ei kovin luotettava.

Mega on ollut pommin varma ja tehot riittää yllin kyllin.

 

[Hegsa]

Minulla on ollut nyt noin 5 vuotta käytössä Arduino Mega:lla tehtynä IV-koneen täysohjaus
- kennon pyörityksen ohjaus optimoimaan sisälämpötila eri sisä-ja ulkolämpötilatilanteissa
- EC-puhaltimien ohjaus perustuen paine-eromittaukseen höyrynsulun yli
- graafinen käyttöliittymä 3.5" näytöllä. (tämä pyörii omana yksikkönään myös Megalla)
pääyksikkö ja käyttöyksikkö juttelee sarjaväylällä omalla kehysprotokollalla.
Lisäksi on yksi NodeMCU tai vataava 32bit wifi-prossu (en muista ulkoa) prossu mikä tallentelee tietoa SQL palvelimelle. Tai oikestaan tällainen oli. Parikin tällaista possahti omia aikojaan. Ei kovin luotettava.

Mega on ollut pommin varma ja tehot riittää yllin kyllin.

Onko sinulla lisätietoa tuosta paine-eromittauksesta? Periaatteessa kiinnoistaisi vastaava myös itselle, mutta oma IV-kone on fyyisesti eri IV-alueella kuin talo niin ei onnistuisi ihan suoraviivaisesti.

Osatko yhtään sanoa mihin NodeMCU:t possahti? Lämpötila, kuormitus, joku muu? Sen verran paljon noita näkee kaupallisessa käytössä etten ensimmäisinä sulkisi pois. Ei tuo Mega myöskään mahdoton olisi, mutta vaatisi enemmän työtä kun koodin puolelta valmiina on vähemmän. ESP:n kanssa ainoa oikeastti itse tehtävä osuus olisi Nilanin rekisterien tuonti ESPHomelle, mutta siihenkin mappaus on valmiina.

Oma projekti liikahti sen verran eteenpäin että RS485-TTL sovitin on tilauksessa niin pääsee raudan puolesta koettelemaan miltä vaikuttaa.

 

[HotZone]

Muistaakseni anturi oli tällainen SDP610-125PA. Mouserilta sen tilasin.
Paha sanoa NodeMCUn palamissyytä. Kuormaa sillä ei ollut. Se vain luki kahden Megan välistä sarjaliikennettä ja sen perusteella kirjoitti wifin kautta NAS:ssa pyörivään MariaDB kantaan silloin tällöin. Ei sillä mitenkään kova kuorma ollut.
Samassa kotelossa oli kuin edelleen siellä pyörivä ja ohjaava Mega. Onhan se kotelo lämmin mutta ei kuuma. Siellä on kuitenkin puolijohdereleita, tavallisia releitä ja pari kiskoon asennettavaa 12V hakkuripoweria (kahdennus).

Megalle kyllä löytyy pitkälti samat kirjastot kuin wifi-prossuille. Ite pyöritän Megalla tai oikeammin Nanolla (sama siru kuin Megassa) kahta erillistä RS485 väylää ja Modbusia niiden päällä ynnä 20x4 LCD näyttöä yhteen toiseen tarkoitukseen. Tuo kahden RS485 väylän saaminen samaan prossuun olikin temppu. Kirjastojen tekijät ei milloinkaan olleet ajatelleet tällaista. Kyseessä oli konversio kahden Modbuslaitteen välillä niin että toinen oli masteri ja toinen orja. Yksi väylä ei siis riittänyt.

 

[Hegsa]

Muistaakseni anturi oli tällainen SDP610-125PA. Mouserilta sen tilasin.

Eipä tullut ajateltua tämmöistä kun seinät oli auki ja höyrynsulkuu näkyvillä pari vuotta sitten. Pitää laittaa muistiin niin tietää mitä tekee seuraavan talon kanssa.

Paha sanoa NodeMCUn palamissyytä. Kuormaa sillä ei ollut. Se vain luki kahden Megan välistä sarjaliikennettä ja sen perusteella kirjoitti wifin kautta NAS:ssa pyörivään MariaDB kantaan silloin tällöin. Ei sillä mitenkään kova kuorma ollut.
Samassa kotelossa oli kuin edelleen siellä pyörivä ja ohjaava Mega. Onhan se kotelo lämmin mutta ei kuuma. Siellä on kuitenkin puolijohdereleita, tavallisia releitä ja pari kiskoon asennettavaa 12V hakkuripoweria (kahdennus).

Olisiko ollut vaan huonoa tuuria useampaan kertaan tai jotain erikoista virtalähteessä? Omassa setupissa ESP32 on nyt paikallaan mittaamassa ja ennen lämmitykautta ei suurempia intoja ole ohjauksen siirtoon eli saa vähän kokemusta. Pitää seurailla herkällä korvalla oireeleeko vai ei.

Megalle kyllä löytyy pitkälti samat kirjastot kuin wifi-prossuille. Ite pyöritän Megalla tai oikeammin Nanolla (sama siru kuin Megassa) kahta erillistä RS485 väylää ja Modbusia niiden päällä ynnä 20x4 LCD näyttöä yhteen toiseen tarkoitukseen. Tuo kahden RS485 väylän saaminen samaan prossuun olikin temppu. Kirjastojen tekijät ei milloinkaan olleet ajatelleet tällaista. Kyseessä oli konversio kahden Modbuslaitteen välillä niin että toinen oli masteri ja toinen orja. Yksi väylä ei siis riittänyt.

Pitääpä pohtia tarkemmin millaisella setupilla sitä haluaa jatkossa ajaa. Alkuperäisenä ajatuksena oli asentaa ESP32 nykyisen RS485-Eth sillan (https://www.waveshare.com/wiki/RS485_TO_ETH_(B)) rinnalle, mutta tässähän voisi vapauttaa samalla yhden PoE lähdön parempaan käyttöön ja laittaa kaikki yksiin kuoriin.

Jos lähtisin Megalla tekemään täytyisi anturitiedot saada eteenpäin vähintään MQTT:llä kun tänne on tulossa iso kasa kiinnostavia, mutta ohjauksen kannalta ei välttämättömiä (esim PM1, PM2.5 ja PM10) mikä menee hukkaan ilman logittamista. Vaihtoehdot olisi lähinnä samat kun sinullakin eli ESP rinnalle tai Megalle shield, joissa kummassakin alkaa potentiaalisesti hajoavien komponenttien määrä nousemaan.

 

[iro]

Osatko yhtään sanoa mihin NodeMCU:t possahti? Lämpötila, kuormitus, joku muu? Sen verran paljon noita näkee kaupallisessa käytössä etten ensimmäisinä sulkisi pois. Ei tuo Mega myöskään mahdoton olisi, mutta vaatisi enemmän työtä kun koodin puolelta valmiina on vähemmän. ESP:n kanssa ainoa oikeastti itse tehtävä osuus olisi Nilanin rekisterien tuonti ESPHomelle, mutta siihenkin mappaus on valmiina.

Oma projekti liikahti sen verran eteenpäin että RS485-TTL sovitin on tilauksessa niin pääsee raudan puolesta koettelemaan miltä vaikuttaa.

Muutama vuosi sitten tein järjestelmän jossa Arduino-Uno (5V logiikka) ja Wemos-D1-Mini vaihtavat tietoja TX/RX pinnien välityksellä. Wemosissa TX- ja RX-nastat on kytketty suoraan USB-piirin ja prossun välisiin vetoihin enkä saanut liikennettä toimimaan luotettavasti suoralla kytkennällä tai sarjavastuksilla. Lopulta tein logiikkatasojen sovituksen optoerottimilla ja näinollen Arduino ja Wemos ovat myös galvaanisti erotettuja. Kaksi tällaista järjestemää on nyt oiminut ongelmitta useita vuosia.

 

[HotZone]

Jos lähtisin Megalla tekemään täytyisi anturitiedot saada eteenpäin vähintään MQTT:llä kun tänne on tulossa iso kasa kiinnostavia, mutta ohjauksen kannalta ei välttämättömiä (esim PM1, PM2.5 ja PM10) mikä menee hukkaan ilman logittamista. Vaihtoehdot olisi lähinnä samat kun sinullakin eli ESP rinnalle tai Megalle shield, joissa kummassakin alkaa potentiaalisesti hajoavien komponenttien määrä nousemaan.

Kyllä nuo mqtt kirjastot saa myös megalle. Ite olen megoissa käyttänyt wifi-sovitinta ja nyt ethernet sovitinta.
ESp32 on hauska peli mutta IO avaruus on rajoittunut joissain tapauksissa. Sitä kuten noita NodeMCU versioita tullut käytettyä.
Olen vaan pikkuhiljaa siirtymässä ethernetin käyttöön wifistä. Johto on johto ja radio on radio. Jos johdon saa väliin niin se on luotettavampi. Tiedonkeruussa sillä ei niin paljon merkitystä mutta ohjaus kuten vaikka kuorman hallinta talossa tai IV-koneen ohjaus onkin eria asia. Niihin en radiota sotke enkä varsinaiseen ohjausosuuteen Linuxia. Linuxpurkki saa kyllä hakea netistä vaikkapa sähkön hintatietoa mutta ei ohjata realiajassa kuormia.

 

[Hegsa]

Aliexpressin pakettia odotellessa on hyvin aikaa tutustua mille seurantadata näyttää ilman kontrollia. Parin viikon käyrät näyttää tälle:

Muutama huomio tuloksista:

• BME680:n CO2-"anturi" ei ole oikea CO2 mittaus mikä näkyy selvästi erona MH-Z19 oikean CO2 mittauksen kannssa heti kun jotain poikkeavaa tapahtuu
• IV:n tehostukseen BME680:n IAQ vaikuttaa fiksuimmalle antamalla signaalin kosteudesta, partikkeleista ja CO2:sta. Helpottaa logiikkaa huomattavasti kun ohjaus olisi yhden parametrin takana eikä 3 erillisen.
• Talviaikaisesta IV:n kuristuskapasiteetista ei tässä vaiheessa vielä saa mitään irti

Ohjauspiirin osalta taidan kuitenkin pysyä alkuperäisessä ESP32 suunnitelmassa. Varsinainen mittaus-ohjauslogiikka toimii senkin kanssa kovilla kaapeleilla, IO:t ei lopu tässä käytössä kesken ja loggaaminen hoituu samalla piirillä niin Arduinolla menisi väkisinkin vaikeammaksi kun Wifi/ethernet pitäisi rakentaa toisella piiriillä saamatta vastineeksi oikein mitään. Tässä käytössä minulla on vielä backuppina IV:n modbus-yhteys HA:lle, jolla ESP:n mahdollisesti kaatuessa saataisiin palautettua IV:n oletusasetuksiin + olemassa oleva lokaali kontrollipaneeli.

 

[Hegsa]

Posti toi uusia osia, joten projetki etenee. Nilanin ja ESP32:n väliin tuli tämmöinen (https://www.aliexpress.com/item/100....order_list.order_list_main.51.18751802YD1pG1), mutta ongelmana on ettei Nilan halua vastata ESP:lle ja nyt kaivattaisiin ajatuksia. Nilan on valmiiksi HA:ssa kiinni Wavesharen RS485-to-Eth sovittimessa, joten todistetusti modbus toimii Wavesharen terminaalille asti. ESP:n logi näyttää vain kaikille rekistereille:

[D][modbus_controller:040]: Modbus command to device=30 register=0x00 countdown=0 no response received - removed from send queue

RS485-TTL sovitin vilkuttelee RXs lediä uskottavasti xx sekunnin välein, joten ainakin sinne asti voisi yhteyden kuvitella toimivan. Hyviä ajatuksia mitä kokeilla seuraavaksi kaivattaisiin. ESP-testien aikana RS485-to-Eth on kylmänä eli tämän pitäisi olla ainoa linjoilla oleva laite. Waveshare toimii myös maadoittamattomana, mutta maadoituksen lisäys ei auttanut tässä.

Koko ESPhome yaml alla. Käytössä nyt Jopand:n valmiit Nilan rekisteriterit, mutta ei tuo käsin kokeillen myöskään mitään löytänyt. Nilanin dokumentaatio sanoo osoitteeksi 30 ja UART asetukset vastaa Wavesharea eli siinäkään ei pitäisi olla vikaa.

Spoiler: Koodi

substitutions:
  name: esphome-web-288740
  friendly_name: Modbus

esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: false
  project:
    name: esphome.web
    version: '1.0'

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

packages:
  remote_package:
    url: https://github.com/Jopand/esphome_components
    ref: main
    files: [components/nilan/basic.yaml]
    refresh: 0s

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
  platform: esphome

# Allow provisioning Wi-Fi via serial
improv_serial:


wifi:
  ap: {}

captive_portal:

#dashboard_import:
#  package_import_url: github://esphome/firmware/esphome-web/esp32c3.yaml@main
#  import_full_config: true

esp32_improv:
  authorizer: none

# UART configuration for RS485
uart:
  rx_pin: 16
  tx_pin: 17
  parity: EVEN
  baud_rate: 19200
  id: uart_modbus
  stop_bits: 1
 
modbus:
  id: modbus_id
  uart_id: uart_modbus
 
modbus_controller:
  id: nilan_modbus_controller
  address: 30
  modbus_id: modbus_id
  update_interval: 30s

 

[HotZone]

Tuossa yllä kertomassani rs485/ModBus konvertterissa oli myös tuskaisaa saada yhteyttä pystyyn tavallisilla rs485 adaptereilla. Päädyin käyttämään galvaanisesti erottavia malleja ja kas kummaa, heti toimi kuin ajatus. Ei siitä erotuksesta kiinni varmaan ollut. Saattoi olla että käyttämäni kirjasto ei vaan toiminut yhteen modulin kanssa.

Voisit testailla tuota unohtamalla modbuskirjaston ja kokeilla serial-kirjastolla lähettää suoraan sopivan viestin ja dumpata sen ruudulle. rs485/modbus:ssa kulkee ihan normaali sarjaliikenne. rs485 on balansoitu linjasovitus ja modbus oma protokolla tuossa tapauksessa sarjaliikenteen päällä.

Voit myös koittaa pistää toiseen prosuun myös rs485 sovittimen ja sen tuohon samalle väylälle. Tuohon toiseen sitten vain silmukkaan pari käskyä millä dumppaat rs485 väylällä kulkevan datan ruudulle. Näin testailin josain vaiheessa. PC:hen saa kyllä samaan aikaan kiinni useammankin USB perässä olevan prossun. VOit käyttää vaikka putty:a näyttämään mitä prossu lähettä jos arduino ymärisön serial monitor näyttää logitustasi pääprossulta.
Välttämättä et tarvitse edes toista prossua jos sinulla TTL-serial USB sovitin. Sen perään vaan suoraan rs485 sovitin ja linjalle nuuskimaan.

 

[Hegsa]

Tuossa yllä kertomassani rs485/ModBus konvertterissa oli myös tuskaisaa saada yhteyttä pystyyn tavallisilla rs485 adaptereilla. Päädyin käyttämään galvaanisesti erottavia malleja ja kas kummaa, heti toimi kuin ajatus. Ei siitä erotuksesta kiinni varmaan ollut. Saattoi olla että käyttämäni kirjasto ei vaan toiminut yhteen modulin kanssa.

Voisit testailla tuota unohtamalla modbuskirjaston ja kokeilla serial-kirjastolla lähettää suoraan sopivan viestin ja dumpata sen ruudulle. rs485/modbus:ssa kulkee ihan normaali sarjaliikenne. rs485 on balansoitu linjasovitus ja modbus oma protokolla tuossa tapauksessa sarjaliikenteen päällä.

Voit myös koittaa pistää toiseen prosuun myös rs485 sovittimen ja sen tuohon samalle väylälle. Tuohon toiseen sitten vain silmukkaan pari käskyä millä dumppaat rs485 väylällä kulkevan datan ruudulle. Näin testailin josain vaiheessa. PC:hen saa kyllä samaan aikaan kiinni useammankin USB perässä olevan prossun. VOit käyttää vaikka putty:a näyttämään mitä prossu lähettä jos arduino ymärisön serial monitor näyttää logitustasi pääprossulta.
Välttämättä et tarvitse edes toista prossua jos sinulla TTL-serial USB sovitin. Sen perään vaan suoraan rs485 sovitin ja linjalle nuuskimaan.

Tässä oli hyvää pohdintaa, kiitos! Löysin miljoonalaatikosta yhden USB-TTL sovittimen millä sain luettua ESP32:lla serialina lähetetyn Hello Worldin. Tässä onnistui muuten sekä lähettävän ESP32:n että USB-TTL:n lukeminen Arduinon serial monitorilla kunhan vaan vaihtoi oikean portin ja lähetysnopeuden. Pinnit oli samat mitä koetin käyttää modbusia varten eli ESP:n rautavian voi sulkea pois.

Mulla pitäisi olla ylimääräinen TTL-to-RS485 sovitin kolvaamista vaille niin voisin seuraavaksi kokeilla oman modbus-väylän rakentamista tietokoneelta/ESP:ltä ja sen lukemista ESP:llä. Tuossa voi palikka kerrallaan lisätä ja katsoa missä vaiheessa alkaa tulla ongelmia. Softan kanssa varmaan pitää jumpata vähän kun tähän asti olen käyttänyt ESPhomea (OTA on huippu kun joutuu kokeilemaan kaikkea), mutta se ei taivu kuin masteriksi.

Muistatko vielä mikä tuo käyttämäsi galvaanisesti erottava malli oli? Mikäli näitä meinaa askarrella jossain vaiheessa voisi vaihtaa pois pennisarjan osista eurojen osiin ilman konkurssia.

 

[Hegsa]

Iltapuhteena tuli rakennettua testimielessä modbus verkko seuraavasti:

• CH340K USB-to-TTL muodostamassa sarjaportin COM8
• Modbus rtu serveri diagslavella (.\diagslave.exe -b 9600 -p none -a 5 -m rtu COM8 )
• Aiemmin aiemmin mainitulla Aliexpressin TTL-to-RS485 sovittimella käännetään modbusiksi
• Toisella samanlaisella käännetään takaisin TTL:ksi
• ESP32:ssa pyörii ESPhome joka lukee 5 sekunnin välein modbus serveriltä
• Spoiler: ESPhome yaml

  [*]

  # UART configuration for Modbus communication
  uart:
    rx_pin: 16
    tx_pin: 17
    baud_rate: 9600  # Match the baud rate of your Modbus server
    id: uart_modbus
    parity: NONE      # Match the parity setting
    stop_bits: 1      # Default stop bits
  
  # Modbus configuration
  modbus:
    id: modbus1
    uart_id: uart_modbus
  
  # Modbus Controller Configuration to read from the server
  modbus_controller:
    id: modbus_device
    address: 5           # The Modbus address of your server
    modbus_id: modbus1
    update_interval: 5s  # How often to poll the Modbus server
  
  # Reading a holding register (example: register 1)
  sensor:
    - platform: modbus_controller
      modbus_id: modbus_device
      name: "Holding Register 1"
      register_type: holding
      address: 1         # The Modbus register address you want to read
      value_type: U_WORD # Unsigned 16-bit value
      filters:
        - multiply: 1.0  # Apply any necessary scaling

  [*]

Näillä homma lähti toimimaan (liitteet molemmista päistä). Pientä päänvaivaa tuossakin oli kun ESP ei saanut aluksi yhteyttä käynnissä olevaan modbus-serveriin. diagslaven pysäytys ja uudelleen käynnistäminen tuntui auttavan ja lukeminen toimi heti sen jälkeen. Rauta siis toimii ja olen melko luottavainen että Nilanin kanssa boottaus tulee auttamaan.

Joku yritteliäs toimija voisi ruveta tarjomaan näitä laitetoimittajariippumattomina paketteina lämmityksen ohjaukseen kaikkeen mikä keskustelee modbusia. Lokaalin web-portaalin mahduttaa helposti ESP32:een ja pilvirajapinnat omaan käyttöön tai muuhun pilveen ei ole kovin kummoinen rakennettava. Wifi- ja ethernet mallit ainakin eikä SIM-kortillisetkaan ratkaisut lompakkoa riko.

 

[Hegsa]

Pikapäivityksenä nyt yhteys toimii myös Nilanin kanssa, epäselväksi vain jäi miksi se ei aiemmin toiminut. Johdotukset on identtiset aiemman kanssa, koodin osalta (alla) suurin muutos on useamman rekisterin sijaan luen vain yhtä ja yhteys nousi pystyyn ilman väylän uudelleenkäynnistämista.

Varsinaisen IV-seurannan osalta pistin tilaukseen toisenkin BME680:n, joka on tarkoitus laittaa tuloilmapuolelle. Muutaman kuukauden seurannan jälkeen BME680:n IAQ on vieläkin oma suosikkiparametri, mutta käytännössä tämä vaatii ainakin kesäaikaan seurannan myös sisääntuloon. IAQ arvot on kesäaikaan ollut yllättävän korkeat jopa talon ollessa tyhjillään, jolloin pelkällä arvolla tehostaminen ei auta tilannetta. Ajatuksena on laittaa toinen mittaus suodatettuun tuloilmaan ja katsoa miten IAQ:n nousu talossa kuvaa tarvetta tuulettaa.

Spoiler: Koodi

# UART configuration for Modbus communication
uart:
  rx_pin: 16
  tx_pin: 17
  baud_rate: 19200  # Match the baud rate of your Modbus server
  id: uart_modbus
  parity: EVEN      # Match the parity setting
  stop_bits: 1      # Default stop bits

# Modbus configuration
modbus:
  id: modbus1
  uart_id: uart_modbus

# Modbus Controller Configuration to read from the server
modbus_controller:
  id: modbus_device
  address: 30           # The Modbus address of your server
  modbus_id: modbus1
  update_interval: 5s  # How often to poll the Modbus server

sensor:
  - platform: modbus_controller
    modbus_controller_id: modbus_device
    name: "Holding Register 1"
    register_type: read
    address: 0         # The Modbus register address you want to read
    value_type: U_WORD # Unsigned 16-bit value

 

[HotZone]

Muistatko vielä mikä tuo käyttämäsi galvaanisesti erottava malli oli? Mikäli näitä meinaa askarrella jossain vaiheessa voisi vaihtaa pois pennisarjan osista eurojen osiin ilman konkurssia.

Päässyt hiukan foorumit jäämään vähemmälle.
En muista tuota modulian tyyppiä mutta koitan otta purkin auki ja katsoa millaiset modulit tuli hankittua. Kallita ne galvaanisesti erottavat modulit kuitenkin on, useita kymppejä mutta autonlatauslaitteeseen kytkettäessä ja kahden eri rakennuksen välillä ei kannata säätellä muutama kymppiä.

 

[HotZone]

No niin nyt sain laitteen auki ja tällaisia RS485 moduleja olen käyttänyt. En muista mistä noita ostin mutta malli on sama.
https://digilent.com/shop/pmod-rs485-high-speed-isolated-communication/
Ovat toimineet luotettavasti ja tuo 5kV eristyskyky on tärkeää kun laitteet on eri rakennuksissa ja eri ryhmäkeskusten takana.

Tuo on sikäli pätevä että se on full dublex. AB ja ZY

 

[Hegsa]

Pitääpä tutustua tarkemmin tuohon. Melko pitkälläkin tutkimisella kohtuuhintaisen valmiin modbus-paketin löytäminen on ollut vaikeaa eikä vieläkään ihan sopivaa ole tullut vastaan. Lähimmäksi pääsee tällä hetkellä STM32-pohjoinen lauta, jossa on mukana myös RS485 kilkkeet. Vieras arkkitehtuuri itselle, mutta kerrankos sitä uuden opettelee mielenkiinnosta.

Tuosta kun vielä saisi galvaanisella erotuksella olevan mallin niin saisi samalle alustalle, mutta taitaa mennä liioitteluksi toivoa.

Noin yleisesti pitäisi päättää haluanko replikoida koko Nilanin modbus-protokollan omalle kontrollerille vai en. Vähän yllätyksenä tuli ettei Modbus-RTU tue luon yhtä masteria (IP tukisi), joten vaihtoehdot on luopua nykyisestä RS485-to-Eth sovittimesta ja korvata HA-yhteys samalla palikalle kuin lokaali kontrolli tai olla tekemättä mitään.

 

[HotZone]

Huomaa että jotkin laitteet vaatii full dublexin. Sen kanssa ainakin on yksinkertaisempaa kirjoituksen ja lukemisen välillä, siis RS485 tasoaa ei Modbustasolla (jokainen modbusoperaatio se kirjoittaa että lukee RS485 tasolla).

Pistähän vinkkiä jos löydät jonkin halvemman galvaanisesti erotetun ja mieluusti full dublexin.

 

[HotZone]

Otsikon ESP32:sta sen verran että ESP32 S3 on kyllä aika paketti. Tykkään kovasti siitä että melkein kaiken I/O tominnallisuuden voi uudelleen allokoida melkein mihin tahansa I/O pinniin ja onhan siinä tietysti potkuakin kunnolla. Vielä ei ole tullut tehtyä softaa mikä käyttää aktiivisesti molempia ytimiä.
On se jännä että nykyään näissä pesukoneen ohjausprossuissa on niin paljon paukkua että voisi periaatteessa emuloida realiajassa Amigaa, 8-bittisistä puhumattakaan.

Toinen hieno asia on että toimivat jopa alle -30 asteen lämpötiloissa.

Kolmas on tietysti hinta.