taloLogger v1.5a, taloLoggerGraph v1.1a ja taloLoggerPi v1.0a julkaistu

[jussip]

Lisätty --nodaemon -optio, jolla voidaan pakollapakolla estää, ettei vahingossa väärällä konfiguraatiotiedostolla esim. taloLoggerPi:ssä loggeri mene daemon-tilaan. Daemon-tila toki tuettu edelleen normaalisti.

Miten tämän asetuksen kuuluu olla kun talologgeria ajetaan daemon-toolsilla (svc)? Onko tämä: "DAEMON_MODE = false"  em. nodaemon -optio?

Lisätty tuki taloLoggerin GPIO-inputien lokitukselle sekä viritys, jolla vain taloLoggerin GPIO-moduulia ajetaan root-tasoisena (GPIO vaatii, että pystyy käsittelemään) ja muuta taloLoggeria edelleen talo-käyttäjätasolla.

Miten tuo viritys tehdään vanhaan asennukseen? Muuten näyttää olevan suunnilleen sama systeemi kun mulla on shell-modulin ja skriptin kautta.

Koodia: [Valitse]

#!/usr/bin/env python

import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BOARD)


GPIO.setup(11, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(12, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(13, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(15, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(16, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(18, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(7, GPIO.IN, pull_up_down=GPIO.PUD_UP)


input0 = 1 - GPIO.input(11) # Kompressori, NO, RUS/VAL
input1 = 1 - GPIO.input(12) # Sahkovastus 3kW, NO, ORA
input2 = 1 - GPIO.input(13) # Sahkovastus 6kW, NO, ORA/VAL
input3 = GPIO.input(15) # LP1, NC, SIN
input4 = GPIO.input(16) # LP2, NC, SIN/VAL
input5 = GPIO.input(18) # Halytysrele, NC, VIH
input6 = GPIO.input(22) # Maakylma, NC
input7 = GPIO.input(7) # Hella, NC


print input0, input1, input2, input3, input4, input5, input6, input6
raspberryPiGPIO.py lopussa on viittaus /home/talo/bin/raspberry_gpio_launcher hakemistoon? Mulla talo-käyttäjää ei ole, talologger ajetaan käyttäjällä pi

[olammi]

Miten tämän asetuksen kuuluu olla kun talologgeria ajetaan daemon-toolsilla (svc)? Onko tämä: "DAEMON_MODE = false"  em. nodaemon -optio?

Asia ei vaadi mitään muutosta edelliseen. DAEMON_MODE:n pitää daemontoolsilla ajettaessa olla false. Lisäsin tuon taloLoggerPi:ä varten siksi, että nyt jos vahingossa muuttaa taloLogger.conf:ista daemonmoden todeksi, niin daemontoolsilla ajettaessa laitos menee kohtuullisen ikävään perätilaan, koska se alkaa monistamaan tuota taloLogger-prosessia ja ssh-shellit menevät melkolailla jumiin -> laitosta ei saa lopettamaan. Boottikaan ei auta, kun ilmiö alkaa heti bootin jälkeen "automaattisesti".

Nyt taloLoggerPi:ssä (v1.1b) taloLoggerin daemontools-run-skriptissä on tuo optio. Eli daemonmodea ei saa päälle, vaikka konfiguraatiotiedostoon tuon true:ksi laittaisikin.

Jos omassa ympäristössä haluaa varmistua daemontoolsin kanssa asiasta, niin --nodaemon sinne run-skriptiin.

Miten tuo viritys tehdään vanhaan asennukseen? Muuten näyttää olevan suunnilleen sama systeemi kun mulla on shell-modulin ja skriptin kautta.

raspberryPiGPIO.py lopussa on viittaus /home/talo/bin/raspberry_gpio_launcher hakemistoon? Mulla talo-käyttäjää ei ole, talologger ajetaan käyttäjällä pi

Tämä toimii tällä hetkellä uuden taloLoggerPi-asennuksen kanssa (v1.1b), joka asentaa talo-käyttäjälle tuon root-tasolle nostavan systeemin. Tein siitä "tietoturvasyistä" sellaisen, että sille ei voi antaa mitä tahansa komentoa, jonka se ajaa rootin oikeuksilla vaan että sillä on tarkka polku, jonka se ajaa. /home/talo/bin/raspberry_gpio_launcher asennetaan root:in omistukseen ja suid-bitti pannaan päälle (C:llä tehty pieni softa, skriptit eivät suostu suidiin). taloLogger käynnistää tuon, joka sitten taas ajaa pythonilla /home/talo/bin/taloLogger/raspberryGpioThread.py-prosessin, joka päätyy rootiksi. taloLogger ja raspberryGpioThread keskustelevat toistensa kanssa pipejen välityksellä.

Hyviä ehdotuksia otetaan vastaan, että miten tuota toolia voisi parantaa siten, että taloLoggerin paikka olisi sille konfiguroitavissa, mutta se ei suostuisi ihan mitä tahansa skriptiä ajamaan roottina.

[jussip]

Mitä jos raspberryPiGPIO.py, raspberryPiGPIO.pyc ja raspberryPiGpioThread.py olisi samassa erillisessä hakemistossa ja sen voisi määritellä talologger.confissa?

[olammi]

Julkaistu 9.1.2015:

taloLoggerGraph v1.2b:

• Muutamia pikkukorjauksia ja suorituskykyviilauksia
• Uutena ominaisuutena vaihtoehtoinen tapa piirtää kuvat vasta selaimessa. Aiemmin kuvat piirrettiin pelkästään palvelinpäässä PNG-kuviksi, jotka sitten esitettiin pikselikuvina selaimessa (tehtiin JpGraphilla ja PHP:lla). Nyt vaihtoehtoisena tapana on tuottaa vastaavat kuvaajat ja kuvat selaimessa D3 Data-Driven Documents -javascript-kirjaston avulla. Graafin luominen on suorituskykyisempi, koska piirtäminen tapahtuu vasta selaimessa.
  Materiaalin cachetus toimii myös näiden html-kuvien kanssa. Kuvaajien toimivuus testattu perus uusilla selaimilla (Firefox, Chrome, IE, Lumia-IE, Android-Chrome). Ios-laitteisiin ei ole pääsyä, joten niistä ei tietoa, mutta uskoisin
  toimivan. Oletuksena piirtää edelleen PNG-kuvia, mutta taloLoggerGraph.conf:iin voidaan lisätä "JAVASCRIPT_CHARTS = true", jonka jälkeen piirtää oletuksena javascript/html kuvaajia. Sivun alalaidoissa
  linkki, josta voi saman sivun ottaa toisessa moodissa halutessa (URL-parametri).

[koowee]

Ios-laitteisiin ei ole pääsyä, joten niistä ei tietoa, mutta uskoisin toimivan.

Nopeasti testattuna näyttäisi toimivan IOS-laitteillakin ihan hyvin

[olammi]

Julkaistu 13.2.2015:

taloLogger v1.7a http://olammi.iki.fi/sw/taloLogger/:

• Muokattu taloLoggerin sisäistä moduulirakennetta hierarkisemmaksi. Aiemmin kaikki oli rumasti päähakemistossa. Nyt alimoduuleissa. Ouman-komentorivityökalut siirretty tools-hakemistoon.
  taloLoggerPi, GPIO-lokittajat huomio! Lukekaa http://olammi.iki.fi/sw/taloLoggerPi/changelog.php alussa oleva NOTE.
• Muokattu moduulikonfiguraatioiden alustusta. (ei vaikutusta lopputoiminnallisuuteen muuten kuin konfiguraatioiden virhetapauksissa virheilmoitukset toivottavasti selkeämpiä)
• Lisätty Modbus-moduuli. Tukee sarjamuotoista RTU ja ASCII -protokollaa sekä ModbusTCP:tä.
• Lisätty NibeModbus -moduuli. Lukee modbus-moduulin avulla Niben datapisteitä. Käytössä kaikki NibeBusRS485-moduulissakin olevat datapisteet.
• Lisätty Nibe Bus RS485 -moduuli. Toimii joko pumpun RS485-väylään kytkettynä sarjaliikenteellä (tällöin kuulee väylältä pumpulle esikonfiguroidut 20 datapistettä) ja osaa kysyä pumpulta muutkin halutut arvot tarvittaessa tai jos pumpussa on kiinni OpenHAB-projektin NibeGW, kuuntelee UDP-verkkoporttia ja vastaanottaa NibeGW:ltä väyläsanomia ja lokittaa niiden perusteella (NibeGW tukee 20 esikonfiguroitua datapistettä).
  
• Lisätty tuki Telldus Live (Telldus TellStick Net) langattomien antureiden arvojen lokittamiseen.
• Muutettu SHELL-moduulia siten, että regular expressioneita voidaan antaa moduulikohtaisesti useita. Komennon ulostuloa voidaan käsitellä siis usealla eri regexpillä tarvittaessa.
• (testiversio)Lisätty Enervent EDA -moduuli (sarjaliikenne ja ModbusTCP)

[olammi]

Julkaistu 16.2.2015:

taloLoggerPi v1.1c:

• RPi.GPIO-tukea muutettu siten, että konsepti olisi käytettävissä muutenkin kuin taloLoggerPi-paketilla. Ei edellytä talo-käyttäjää, jos vain polusta löytyy taloLoggerPi-paketissa /home/talo/bin-hakemistosta löytyvä raspberry_suid_python_launcher -ohjelma ja se on rootin omistuksessa ja setuid-bitti päällä. Ohjelma käynnistää sille parametrina annetun python-skriptin rootin oikeuksin olettaen että myös tuo python-skripti on suid-oikeuksin. GPIO-tuki vastaa nyt myös taloLoggerin uutta moduulirakennetta (v1.7b yhteensopiva)
• Lisätty python-oauth-moduuli asennettavien pakettien listalle (apt-get install, tarvitaan Telldus Live API:n kanssa)
• Asetettu taloLoggerGraphin esimerkkikonfiguraatioon javascript-kuvaajat oletukseksi.
• Lisätty d3.v3.js -kirjasto palveltavaksi lokaalisti (versio 3.5.5, /home/talo/public_html/js/d3.v3.js) taloLoggerPi-paketista.
• Muutettu apachen talo-hakemistoasetuksia siten, että suostuu palvelemaan hakemistosta myös js-päätteisiä tiedostoja.

taloLogger v1.7b:

• taloLoggerPi v1.1c:n vaatimat muutokset RPi.GPIO-moduuliin
• shell-moduulin korjaus tietyissä erityistilanteissa virhettä komennon ajossa aiheuttava ongelma

taloLoggerGraph v1.2c:

• d3js-kirjasto palvellaan nyt paikallisesti, jos se on saatavilla. Aiemmin esim. SSL:n käyttö palvelimella rikkoi toiminnan, koska SSL-tarjotulla sivulla ei voi olla materiaalia ei-SSL-suojatulta saitilta (ja d3js:n kirjastolinkki on vain http). Kirjastoa (d3.v3.js) etsitään paikallisesti hakemistoista /js /script taloLoggerGraphin tasalta ja sen alta js ja script hakemistoista.
• Hyvin pieniä muutoksia JavaScript-kuvaajissa käytettyihin fonttimäärityksiin ja tekstien paikkoihin kuvaajan akseleilla. Muutokset aiheutuivat siitä, että Linux-selaimissa (esim. Ubuntu+Firefox) tekstit eivät kohdistuneet oikein.

[olammi]

Julkaistu 21.2.2015:

taloLogger v1.7c:

• Nibe Bus RS485 -moduulin tiedonsiirtovirheiden havainnointia ja niistä toipumista parannettu.
• Mahdollistettu useammalla taloLogger-instanssilla lokittaminen samaan tietokantatauluun. MySQL:llä paikallisesti tai verkon yli ja SQLite3:lla paikallisesti.
• Korjattu MySQL-kantaan liittyvä kesäajasta talviaikaan siirryttäessä tapahtuva aikaleimaongelma.

[Maatilallinen]

Minulla kävi niin että kun päivitin tuon 1.7c version, alkoi se tallentamaan kaksi tuntia jäljessä mittauksia entisten mittausten päälle tietokantaan.

Korjaantuuko ongelma itsestään kun se on tarpeeksi kauan aikaa ollut toiminnassa, vai tarvitseeko talologgergraphin versiota 1.2c? Nyt on talologgergraph 1.2b, ja palautin takaisin 1.7b versioon myös talologgerin huomattuani ongelman.

[Roori]

Julkaistu 21.2.2015:

taloLogger v1.7c:

• Mahdollistettu useammalla taloLogger-instanssilla lokittaminen samaan tietokantatauluun. MySQL:llä paikallisesti tai verkon yli ja SQLite3:lla paikallisesti.

ookei, eli eri interwallit eri talologgereilla, ihan mukava kun johonkin riittää 1h toiseen 15min ja joku vaikka 10s...
onko tuo laitettavissa 'ehdonalaisella', eli esmes jos pumppu käy niin tahti on 10s ja kun huilaa niin 15min?

nyt ei ole ehtinyt testailemaan Modbus TCP:tä...joskus lomat painaa päälle

[olammi]

Minulla kävi niin että kun päivitin tuon 1.7c version, alkoi se tallentamaan kaksi tuntia jäljessä mittauksia entisten mittausten päälle tietokantaan.

Korjaantuuko ongelma itsestään kun se on tarpeeksi kauan aikaa ollut toiminnassa, vai tarvitseeko talologgergraphin versiota 1.2c? Nyt on talologgergraph 1.2b, ja palautin takaisin 1.7b versioon myös talologgerin huomattuani ongelman.

Luulisin, että ongelmat korjaantuvat, kun aikavyöhykeasetukset on laitettu kohdalleen. Mitä komento "date" sanoo ja mitä oli kello Suomessa, kun annoit komennon?

[olammi]

ookei, eli eri interwallit eri talologgereilla, ihan mukava kun johonkin riittää 1h toiseen 15min ja joku vaikka 10s...
onko tuo laitettavissa 'ehdonalaisella', eli esmes jos pumppu käy niin tahti on 10s ja kun huilaa niin 15min?

Kyllä, eri taloLogger-instansseilla voi olla eri intervallit. Intervallin muuttaminen lennossa jonkun ehdon mukaan ei ole tuettu.

TaloLoggerissahan on kaksi tapaa käsitellä tietokantaa, tai kaksi mahdollista kantaschemaa. Toinen on taloLoggerin oma, jonka se osaa luoda automaattisesti. Tähän on voinut ennenkin syöttää useammalla eri instanssilla. Toinen on käyttäjän oma taulu, jossa datapisteiden nimet ovat tietokantataulun sarakkeiden nimiä ja loggerille pitää kertoa taulun nimen lisäksi kenttä, johon aikaleiman voi tallettaa. Tähän ei ole aiemmin voinut tallettaa useammalla instanssilla, mutta nyt voi.

[Maatilallinen]

Luulisin, että ongelmat korjaantuvat, kun aikavyöhykeasetukset on laitettu kohdalleen. Mitä komento "date" sanoo ja mitä oli kello Suomessa, kun annoit komennon?

Talokoneesta datella tulee tuollainen vastaus ja kello oli tismalleen tuon verran.

Koodia: [Valitse]

la 21.2.2015 14.01.35 +0200
Palvelimissa samalla tavalla kello on tarkalleen suomen ajassa ja aikavyöhyke UTC+02:00.

[olammi]

Talokoneesta datella tulee tuollainen vastaus ja kello oli tismalleen tuon verran.

Koodia: [Valitse]

la 21.2.2015 14.01.35 +0200
Palvelimissa samalla tavalla kello on tarkalleen suomen ajassa ja aikavyöhyke UTC+02:00.

Ok. Takaisin piirrustuspöydän ääreen siis.

[olammi]

Julkaistu 21.2.2015:

taloLogger v1.7c:

Vedetty takaisin. v1.7b kurantti versio. v1.7c rikkoi kantatalletuksen aikaleimat.

[olammi]

Julkaistu 24.2.2015:

taloLogger v1.7d:

• Aiemmin mainostetut v1.7c-version ominaisuudet, mutta c:ssä ollut MySQL-DATETIME-tyyppiin liittynyt ongelma korjattu.

[TTH]

Miten voin auttaa paremman tuen saamisessa Ouman EH-203/GL mallille? Ohjekirjasta tuskin on apua, mutta tämmösen linkin löysin foorumilta http://aijaa.com/uBx2bv

Raakadataa jonnekin oumanGetData:lla haettuna kenttä kerrallaan? Kerro mitä haluat ja missä muodossa.

EH203GT toimii aika hyvin, mutta ihan kaikki tiedot ei pidä paikkaansa (eli tulee joihinkin kenttiin vääriä arvoja) ja osa kentistä jää vastaavasti tyhjiksi. Sitä en tietysti tiedä antaako Ouman edes ulos kaikkea mitä valikon kautta näkee.

[olammi]

Miten voin auttaa paremman tuen saamisessa Ouman EH-203/GL mallille?

Tällä voisi aloittaa:

taloLogger-paketin mukana tulee tools-hakemistossa oleva Ouman-työkalu oumanMonitorSettings.py. Toolin käyttö on kuvattu tiedostossa docs/README.ouman kohdassa "Monitoring the controller memory:".

Tuolla toolilla ajaen sitten joko odotellaan, että jokin vaihtuu (jos on mittausarvoja), koitetaan arvella, että mikä arvo olisi ollut ja listataan raportoitu id, positio ja mistä mihin arvo vaihtui skriptin mukaan ja mistä mihin mielestäsi käyttöliittymän mukaan. Samoin pumpun eri asetuksia vaihdellaan käyttöliittymästä yksi kerrallaan ja odotellaan tuo työkalun päivityssykli (30 sek). Työkalun pitäisi jälleen ilmoittaa, missä id:ssä ja positiossa muuttui mikäkin mistä mihin. Tässäkin koitetaan kirjata, että kun käyttöliittymästä tietyn nimistä säätää, niin miten ja missä arvot vaihtuvat muistissa.

Listataan sitten vaikka ihan tekstitiedostoon tai exceliin tms. ainakin seuraavat tiedot:
* asetuksen tai mittauksen nimi (miten se käyttöohjeessa tai pumpun käyttöliittymässä on)
* mittausarvo vai asetusarvo
* id
* positiot
* positioiden arvot ja niiden vastaavuus "luonnolliseen" käyttöliittymän näyttämään arvoon.

Tooli ei reagoi dataid:isiin: (SKIPIDS = [2, 3, 18, 20, 21, 26, 27, 24, 33, 23, 34, 25, 45, 36, 38]) Jotka yleensä tiedetään positioiksi, joissa on noita mittausarvoja - ei asetusarvoja. Jos niiden suhteen on näkemystä, että mikä arvo missäkin noista on, niin listaan voi lisätä sille tiedetyn nimen. Niitä pystyy erikseen kyselemään sitten esim. tools/oumanGetData.py-työkalulla (ohjeistettu myös README.ouman-dokumentissa) kohdassa "Querying raw data from the controller memory:"

Mitä seikkaperäisemmän ja enemmän vertaillun (käyttöliittymä vs. muistin arvot) selvityksen saat aikaan, sitä tarkemman tuen voi kokata. Tuki konfigurioidaan sitten modules/datasources/ouman/oumanSerial.py:n taulukkoon OUMAN_DEVICES. Sieltä voi katsella (niinkuin GT:n osalta olet kai katsellutkin) noita sinne konfiguroituja arvoja. Taulukossa kentät ovat: asetuksen/mittauksen nimi, id, datatyyppi (sisältää datan pituudenkin), asetus vai mittaus, positio id:n datassa. Yhden id:n sisältö voi olla useita tavuja dataa ja esim. nuo asetukset voivat olla erillisissä tavuissa saman id:n alla. Tähän asti kaikki mittausarvot ovat olleet yksinään yksi/id, mutta ei sekään välttämättä ole mikään sääntö.

[TTH]

Tällä voisi aloittaa...

Kiitos. Älä pidätä hengitystä vastausta odotellessa. Pitää lukea tuo ohjeesi vielä aika moneen kertaan että ymmärrän miten etenen. Rupean tuota tutkimaan pikku hiljaa

[TTH]

Noiden uusien hakemistojen oikeuksia voisi varmaan laajentaa jo päivitys- / asennusskriptissä? Vähintäänkin siis esimerkiksi tuon docs hakemiston osalta

[olammi]

Noiden uusien hakemistojen oikeuksia voisi varmaan laajentaa jo päivitys- / asennusskriptissä? Vähintäänkin siis esimerkiksi tuon docs hakemiston osalta

Asiallinen huomio.

[jarik]

Katselin tuossa Verkkokaupan valikoimaa Raspberryjä näytti olevan useita versioita...

PI 2 model B
PI model B+
PI model A+

Mikä noista olis paras = toimivin taloLogger-käyttöön...

Nimimerkillä: noviisi

PS: Yritin tietoa etsiäkkin vähän sieltä sun täältä, mutta ei ilmeisesti osuneet hakusanat kohdalleen, kun ei löytynyt...

[tk-]

Katselin tuossa Verkkokaupan valikoimaa Raspberryjä näytti olevan useita versioita...

PI 2 model B
PI model B+
PI model A+

Mikä noista olis paras = toimivin taloLogger-käyttöön...

Nimimerkillä: noviisi

PS: Yritin tietoa etsiäkkin vähän sieltä sun täältä, mutta ei ilmeisesti osuneet hakusanat kohdalleen, kun ei löytynyt...

Kaikki toiminee, Pi2 on uusin ja nopein.

[jarik]

Kiitos, pistetään tilaukseen ;-)

Mites toimiiko toi suoraan, vai pitääkö koodata että saa toimimaan?

Tuollainen mahdollistaisi mukavasti anturimäärän jakamisen osiin, ja helpottaisi hallintaa, jos joku anturi lakkaa toimimasta...

http://www.sheepwalkelectronics.co.uk/product_info.php?cPath=22&products_id=67

[olammi]

Tuossa A+-mallissa ei ole verkkoliittymää, mikä kannattaa ottaa huomioon.

[tk-]

Mites toimiiko toi suoraan, vai pitääkö koodata että saa toimimaan?

http://www.maalampofoorumi.fi/index.php?topic=5425.0 & http://www.maalampofoorumi.fi/index.php?topic=5512.0

Noissa ketjuissa olammin sivuston ohjeiden lisäksi oli aika hyvät ohjeet, minkä avulla sain itse ilman sen kummempaa koodausta tai edes taitoa systeemit pelaamaan.

[jarik]

Sori huonosti aseteltu kysymys...

Noi perusohjeet on tullut lueskeltua läpi ja ehkä (ainakin osittain) ymmärrettyäkin, mutta tuo kysymykseni

Saako tän toimimaan helposti, vai vaatiiko koodaamista.... koski tuota alempana olevasta linkistä löytyvää lisäosaa, joka mielestäni olisi näppärä... saa myös tyrmätä ajatuksen tuon lisäpalikan käyttökelpoisuudesta.

Tuollainen mahdollistaisi mukavasti anturimäärän jakamisen osiin, ja helpottaisi hallintaa, jos joku anturi lakkaa toimimasta...

http://www.sheepwalkelectronics.co.uk/product_info.php?cPath=22&products_id=67

Kiitos jo etukäteen!

[olammi]

Saako tän toimimaan helposti, vai vaatiiko koodaamista.... koski tuota alempana olevasta linkistä löytyvää lisäosaa, joka mielestäni olisi näppärä... saa myös tyrmätä ajatuksen tuon lisäpalikan käyttökelpoisuudesta.

Ei tuo koodaamista vaadi, mutta jonkun verran konfigurointia Raspissa varmaankin. Kollega taisi tuollaisen ostaa ja laittaa tulille. Jotain mutinaa kuulin, että tuon RTC:n toimimaan saaminen (= oikeiden asetusten löytäminen) vaati vissiin eniten r-sanoja.

[jolla]

Mikä on vialla kun en saa talologgeria lukemaan 1-wireä digitempillä? Windows XP käyttöjärjestelmä, Python ja Cygwin. Digitemp löytää kaikki anturit normaalisti ja tekee niistä itselleen konfigurointitiedoston kun sen suorittaa -i parametrillä.

Sitten kun laitan talologgerin lukemaan digitempiä, luku epäonnistuu ja samalla lukittuu myös Oumanin käyttämä sarjaportti ja luku sieläkin lakkaa onnistumasta. Kun sammuttaa talologgerin, poistaa lock-tiedoston temp-hakemistosta, ottaa conffista digitempit pois ja laittaa uudelleen päälle niin lukee Oumania normaalisti.

Kun otan tuon talologgerin käyttämän komennon eli: C:\talo\digitemp\digitemp.exe -q -c c:\talo\digitemp\.digitemprc -s /dev/com4 -t 2 -o "%.2C" -O "%C" -H "%h"

ja laitan sen cmd-ikkunaan niin vastuksena tulee kyseisen anturin lämpötila esim. 68.50

laitoin windows 7' aan taloLoggerin 'hitachi' in ohjeiden mukaan, ja kun siinä ei owfs toimi, niin kokeilin, kun en ole koskaan käyttänyt, digitemp' illä lukea 1-wire antureita
latasin win version dtreg17.zip ja mukana tulleen pika ohjeen mukaan lähti komentokehotteelta lukemaan anturit mutta taloLoggerin
digitempcmd = digitempcmd + ' -o "%.2C" -O "%C" -H "%h"' rimpsua herjasi, "-O "%C" -H "%h" ei kelvannut joten poistin sen ja
digitempcmd = self.DT_BINARY + ' -q -c ' + self.DT_RC + ' -s ' + self.DT_PORT + ' -t ' + cmdid rivistä piti poistaa "+ ' -s ' + self.DT_PORT "
tämän jälkeen toimi

Cygwin ohjelmaa en ajanut ja jos käyttää vain logitukseen niin taitaa python riittää kun jo toimii

edit
testasin windows10 kanssa ja hyvin toimii ilman adapteria suoraan sarjaportista lukien(DS18B20 antureilla)
asensin pythonin, pyserialin, digitemp(windows) ja taloLogger_v17d, ei tarvinnut mitään TMEX ajureita eikä 1-wire ajureita

[olammi]

Eli ymmärränkö oikein, että digitempin komentorivisyntaksi on muuttunut ja taloLoggeria pitäisi siitä kohden paikata?

[jolla]

Eli ymmärränkö oikein, että digitempin komentorivisyntaksi on muuttunut ja taloLoggeria pitäisi siitä kohden paikata?

en ole linuxissa digitemp'iä kokeilllut, siellä se kait toimii, en tiedä

mutta windowsissa minulla toimi w7 sekä w10'llä yllä mainitusti, käytössä seuraavat versiot ohjelmista
pyserial-2.7.win32.exe
python-2.7.9.msi
dtreg17.zip
ja taloLoggerin viimeisin

seiskalla kokeilin läppärillä (AMD) ja kympillä ihan uudehkolla nopealla pöytäkoneella (intel)

jos lisään sen -O.... alkavan, niin kuvan mukaista virhettä pukkaa

[olammi]

Julkaistu 17.11.2015:

taloLoggerPi v1.1d:

• Asentuu nyt myös Raspbian Jessien päälle (ja edelleen wheezyyn)

[jolla]

mitähän minä olen taas kämminyt kun tällaisen heittää

root@rock:~# /home/talo/bin/upgrade_taloLogger.py
*********  taloLoggerPi - upgrade_taloLogger.py - v1.0b  ********************

Determining installed versions...
Retrieving versions from the network...

                Current:   Released:
taloLoggerPi:    v1.1c       v1.1d   New release
taloLogger:      v1.7d       v1.7d
taloLoggerGraph: v1.2c       v1.2c

Newer release of taloLoggerPi is available from

  http://olammi.iki.fi/sw/taloLoggerPi/

This upgrade script can not upgrade full taloLoggerPi release.

[olammi]

Et mitään. Upgrade-skriptillä ei voi päivittää taloLoggerPi:n pohja-asennusta. Ainoastaan loggerin ja graphin, jotka sinulla ovat nyt jo tuoreinta mallia.

taloLoggerPi:n install-skriptillä voi toki asentaa koko roskan Raspbianiin uudelleen, mutta et nyt (1.1c -> 1.1d) saa siitä muuta iloa irti kuin että jos itselläsi oli Jessie-asennus, niin olit
ehkä joutunut korjaamaan sitä aiemmin hieman käsin, että apache2 toimii. 1.1d asentuu Jessieen siten, että toimii ilman korjailuja.

[Kokko74]

Olisin apua vailla kun ei toi ohjelmointi ole oikein hanskassa. Olen yrittänyt lukea sql tietokannasta ulkolämpötilaa toista projektia varten. Yhteys sql serveriin on olemassa ja erillisillä kyselyillä saan suraavan komennon toimimaan SELECT * FROM talo_data WHERE ORDER BY time DESC position_id = '3' LIMIT 1; mutta tällä ei. Tarvitseeko tämä jotenkin pilkkoa osiin. Scripti joka tätä kyselee on tehty Pythonilla. Lisäksi saatu tieto pitäisi saada esim. txt tiedostoon.

[olammi]

Olisin apua vailla kun ei toi ohjelmointi ole oikein hanskassa. Olen yrittänyt lukea sql tietokannasta ulkolämpötilaa toista projektia varten. Yhteys sql serveriin on olemassa ja erillisillä kyselyillä saan suraavan komennon toimimaan SELECT * FROM talo_data WHERE ORDER BY time DESC position_id = '3' LIMIT 1; mutta tällä ei. Tarvitseeko tämä jotenkin pilkkoa osiin. Scripti joka tätä kyselee on tehty Pythonilla. Lisäksi saatu tieto pitäisi saada esim. txt tiedostoon.

Ei kyllä pysty auttamaan ennenkuin näkee tuon Python-skriptin, jolla kyselyä yritetään.

[Kokko74]

#!/usr/bin/python
# -*- coding: utf-8 -*-

import MySQLdb
import sys

db = MySQLdb.connect(host="192.168.0.15", user="talo", passwd="xxpassxx", db="talo")
       
cursor = db.cursor()
sql = "SELECT * FROM talo_data WHERE position_id LIKE '3' LIMIT 1"

with db:
    cursor.execute(sql)
    row = cursor.fetchone()
    print row     

# close the cursor
cursor.close()

# close the connection
db.close ()

Tällä koodilla saan rivin kyllä ulos mutta se ottaa tietokannan vanhimman tietueen. Tuloksen viimeinen arvo on oikea.

[olammi]

Mitenkäs tämä?

SELECT value FROM talo_data WHERE position_id = 3 ORDER BY id DESC LIMIT 1

[Kokko74]

Kiitos, nyt näyttäisi toimivan. Mielestäni yritin tuotakin mutta taisi olla typo jossain.

[timmy]

Julkaistu 17.11.2015:

taloLoggerPi v1.1d:

• Asentuu nyt myös Raspbian Jessien päälle (ja edelleen wheezyyn)

Onko mahdollista asentaa Jessie Liten päällä? Se olisi vähän kevyempi kuin täysversio.
/t