PHP & MySQL gränssnitt, HomeAutomation v2.0.2 releasad!!

[starkjohan]

Jag lade in ett cronjob på parsern så nu har jag fina värden i databasen var 5:e minut.

Parsern borde nog kolla mot databasen så att värdet faktiskt är nytt innan den lägger till ett nytt värde. Tyvärr uppdaterar inte alla sensorer så tätt...

Nu är allt på plats utom det absolut sista, nämligen funktionen. Vanliga schedules (av/på static) fungerar fint men jag märker inte någon effekt av temperaturstyrt schema. Är det något mer som måste på plats innan det går igång? Vet inte riktigt vad jag missat.

Edit: Jag insåg att ett "static" event måste "dra igång" det dynamiska för att det ska fungera, jag var tidsmässigt mitt i den event jag trodde inte fungerade. Efter att ha flyttat fram starttiden temporärt gick det bättre.

[tom_rosenback]

Jag upptäcker några småproblem med parsing/db.

Överskriften "Protocol Model Id" kommer med som en sensor. Inget stort problem men lite irriterande. Jag löste det "problemet" i mitt skript med grep. Tex:

Code: Select all

$command .= $sudoCmd.$settings["tellduspath"]["value"]."/tdtool --list|grep -v PROTOCOL";

Nästa problem är tabellerna temps och tempsensors i databasen. Mina sensorer heter efter din modell tex. "mandolyn-temperaturehumidity-13" men fälten kapas efter 24 tecken. Enkelt fixat genom att öka fältlängden i databasen iofs. Något att tänka på i nästa version av HA.

En liten miss till har smugit sig in på rad 124.

Code: Select all

"date" => trim($rowData[4])

borde vara

Code: Select all

"date" => trim($rowData[5])

annars försöker man stoppa in luftfuktigheten i date-fältet.

Hejsan,

Tack för inputten! Grep finns tyvärr inte som standard i Windows miljöer och eftersom detta är kodat för att fungera på alla miljöer så kan jag inte använda grep, men löste protocol problemet mha kod istället. Sensor inläsningen från tdtool har blivit kodat "i blindo" då jag själv inte har några sensorer kopplat till min Duo (ännu iaf). Har nu ändrat datum inläsningen också. Kan du testa och återkoppla hur det fungerar?

Innan jag börjar leta, finns det någon funktion som automatiskt parsar eller måste jag lägga till ett cronjob manuellt för det?

WP tar telldusd's output och stoppar in det i tabellen temps, ingenting annat (förutsatt att inga andra saker är aktiverade såklart)? Förstår jag det rätt? Hade jag fattat det hade jag kunna använda min egen kod istället för att tjata på dig ...

Det är nog ett manuellt cronjob som gäller för tillfället. Hade koden färdig och paketerad så det var nog inget problem, ingen stressfaktor

Jag lade in ett cronjob på parsern så nu har jag fina värden i databasen var 5:e minut.

Parsern borde nog kolla mot databasen så att värdet faktiskt är nytt innan den lägger till ett nytt värde. Tyvärr uppdaterar inte alla sensorer så tätt...

Nu är allt på plats utom det absolut sista, nämligen funktionen. Vanliga schedules (av/på static) fungerar fint men jag märker inte någon effekt av temperaturstyrt schema. Är det något mer som måste på plats innan det går igång? Vet inte riktigt vad jag missat.

Edit: Jag insåg att ett "static" event måste "dra igång" det dynamiska för att det ska fungera, jag var tidsmässigt mitt i den event jag trodde inte fungerade. Efter att ha flyttat fram starttiden temporärt gick det bättre.

Du har nog rätt i att det borde kollas mot databasens senaste värde för man matar in ny rad, men det får bli till en senare version. Lite mera data skadar ju inte, så länge det inte blir för mycket

Om du har både statiska och dynamiska aktiveringar så måste de dynamiska vara emellan de statiska också tidsmässigt.

[starkjohan]

Helt rätt ang. grep, windows slog mig inte ens... Jag såg din blacklistløsning en stund efter mitt inlägg och det är givetvis en bättre løsning men den borde vara aktiv som standard så att nya användare slipper få massa onödiga inputs i databasen.

Hade lite problem med temperaturstyrningen i natt men det berodde nog på att jag ändrade i schedules efter att dom skulle aktiverats statiskt. Återkommer när jag testat lite mer men helt klart verkar detta mycket lovande. Jag ser redan fram emot 3.0! Jag checkade ut svn-koden men jag vill ha ett stabilt system i drift så jag valde att nöja mig med 2.0.2 tillsvidare.

[riso]

En liten miss till har smugit sig in på rad 124.

Code: Select all

"date" => trim($rowData[4])

borde vara

Code: Select all

"date" => trim($rowData[5])

annars försöker man stoppa in luftfuktigheten i date-fältet.

Hej i vilken fil ändrar jag detta?

[tom_rosenback]

En liten miss till har smugit sig in på rad 124.

Code: Select all

"date" => trim($rowData[4])

borde vara

Code: Select all

"date" => trim($rowData[5])

annars försöker man stoppa in luftfuktigheten i date-fältet.

Hej i vilken fil ändrar jag detta?

Hej,

Om du laddar ner 0.6.2 så är detta fixat redan.

[starkjohan]

Om jag klickar på en temperaturgraf får jag inte fram någon bild i popupen. Vad är det som skall visas? Är det bara samma graf fast i större format eller något mer intressant? Har inte tittat närmare på det (sitter på jobbresa nu) men det är kanske ett känt fel. Imagetagen verkar ha ett extra "/temperature" i sig.

[Jbravo]

tog bort dubbelpost.

[Jbravo]

Angående installation på Raspberry Pi.

Notera att "at" kommandot inte verkar ingå i Rasbian. Således fungerar inte scheman i HomeAutomation.

installera at;

Code: Select all

sudo apt-get install at

ta bort www-data ur at.deny

Code: Select all

sudo nano /etc/deny.at

Välj "återskapa scheman" i HA.

Lista aktuella at jobb

Code: Select all

sudo atq

Sen ska scheman fungera!

Mvh
/jonas

[Jbravo]

Ny feature för scheman.

Har tidigare kört min tellstick med EventGhost och pluginet SunTracker (windows), men håller på att migrera till HomeAutomation på Raspberry Pi.

Jag saknar en liten feature i HA som finns implementerad i SunTracker. Tänk er följande scenario;

Jag vill att en lampa tänds på klockan 07:00, och stängs av vid soluppgång (+/- tid). Detta scenario är inga problem på vinterhalvåret, men på sommarhalvåret inträffar soluppgången innan 07:00 vilket medför följande;

lampa av 06:00 (soluppgång)
lampa på 07:00

Dvs lampan kommer att stå på hela dagen, vilket känns lite onödigt. Det som istället är önskvärt är att lampan inte tänds alls, det är ju ljust ute!

Samma scenario kan även inträffa på kvällen, dvs jag vill att lampan tänds vid solnedgång, och släcks klockan 19.00. Om solnedgången är efter klockan 19.00 så händer följande;

lampa av 19.00
lampa på 20.00 (solnedgång)

Dvs lampan står på hela natten.

För att lösa detta förslår jag samma logik som finns i Suntracker, om på infaller efter av så ignoreras båda aktiveringarna.

Detta skulle kunna lösas i HA genom att införa en ny typ av aktivering, tex statisk-sol (ni kan säkert komma på ett bättre namn)

Vid denna typ av aktivering skulle man ange följande;
- en statisk tid då en enhet ska aktiveras (tex 06:00)
- ett soltillstånd (tex soluppgång) och +/- tid
- en minsta tid enheten måste vara aktiverad (tex 00:20) (inte lönt att tända 06:00 och släcka 06:01)

Om soluppgången innfaller efter 06:00 + 00:20, så schemaläggs följande;
på 06:00
av 07:00 (soluppgång)

Annars schemaläggs inget, och lampan förblir släckt.


Det finns även lite andra bra funtioner i Suntracker man kan tex ange vilka dagar som är semesterdagar, SunTracker kör då på automatik på lördags schemat eller semeste schema om det finns angivet.

Mvh
/jonas

[starkjohan]

Ett liknande "problem" uppstår med temperaturkontroll. (statisk-dynamisk-dynamisk-statisk)

När det statiska eventet går igång tas inte hänsyn till den aktuella temperaturen. Dvs. elementen startar oavsett om det är för kallt, lagom eller för varmt. Det tycker jag vore en logisk funktion.

Tom, vad är det du har kvar att fixa med i 3.0? Om de funktionerna jag använder mig av (endast temperaturkontroll i stort sett) är "klara" kanske jag trots allt skulle köra svn. Om du gjort om systemet mycket är det kanske till mer hjälp med test av det nya snarare än det gamla? Kanske är flera av de förbättringsförslag som nämns redan implementerade i 3.0?

[Pen]

Ny feature för scheman.

Har tidigare kört min tellstick med EventGhost och pluginet SunTracker (windows), men håller på att migrera till HomeAutomation på Raspberry Pi.

Jag saknar en liten feature i HA som finns implementerad i SunTracker. Tänk er följande scenario;

Jag vill att en lampa tänds på klockan 07:00, och stängs av vid soluppgång (+/- tid). Detta scenario är inga problem på vinterhalvåret, men på sommarhalvåret inträffar soluppgången innan 07:00 vilket medför följande;

lampa av 06:00 (soluppgång)
lampa på 07:00

Dvs lampan kommer att stå på hela dagen, vilket känns lite onödigt. Det som istället är önskvärt är att lampan inte tänds alls, det är ju ljust ute!

Samma scenario kan även inträffa på kvällen, dvs jag vill att lampan tänds vid solnedgång, och släcks klockan 19.00. Om solnedgången är efter klockan 19.00 så händer följande;

lampa av 19.00
lampa på 20.00 (solnedgång)

Dvs lampan står på hela natten.

För att lösa detta förslår jag samma logik som finns i Suntracker, om på infaller efter av så ignoreras båda aktiveringarna.

Detta skulle kunna lösas i HA genom att införa en ny typ av aktivering, tex statisk-sol (ni kan säkert komma på ett bättre namn)

Vid denna typ av aktivering skulle man ange följande;
- en statisk tid då en enhet ska aktiveras (tex 06:00)
- ett soltillstånd (tex soluppgång) och +/- tid
- en minsta tid enheten måste vara aktiverad (tex 00:20) (inte lönt att tända 06:00 och släcka 06:01)

Om soluppgången innfaller efter 06:00 + 00:20, så schemaläggs följande;
på 06:00
av 07:00 (soluppgång)

Annars schemaläggs inget, och lampan förblir släckt.


Det finns även lite andra bra funtioner i Suntracker man kan tex ange vilka dagar som är semesterdagar, SunTracker kör då på automatik på lördags schemat eller semeste schema om det finns angivet.

Mvh
/jonas

Intressant. Precis detta orsakade mig mycket huvudbry när jag byggde min egen schemaläggare (jag planerar att gå över till homeautomation från 3.x). Dessutom tyckte jag att det var svårt att definera begrepp såsom "före", "efter" mm när multipla händelser styr något och vad som händer när man passerar 23.59. Jag löste det i princip så här:

Definera entydigt vad som menas med att klockan t är i ett intervall mellan tiden a och b:

function isIn($t,$a,$b)
// Test om tiden t tillhör intervallet [a,b]
// Intervall upp till 23:59 timmar tillåts
// t tillhör [a,b] omm (t-a)mod24:00 <= (b-a)mod24:00
// strtotime(t): Koverterar tid till sekunder. Kan även ta in full tid med datum.
{
$a_to_t_length = strtotime($t) - strtotime($a);
if ($a_to_t_length < 0) {$a_to_t_length = $a_to_t_length+86400;};
$a_to_b_length = strtotime($b) - strtotime($a);
if ($a_to_b_length < 0) {$a_to_b_length = $a_to_b_length+86400;};
if ($a_to_t_length > $a_to_b_length) {return 0;} else {return 1;};
};

Uttryck t.ex. ytterbelysningens önskade villkor som att tiden är i två intervall samtidigt - dels ska den vara mellan två klockslag (6-22 nedan) och dels ska den vara mellan soluppgång och solnedgång.

if (isIn($Time,'06:00','22:00') && isIn($Time,$SunSet,$SunRise)) {$State['Ytterbelysning'] = "on";}

På samma sätt definierade jag vad som menas med att klockan t är c minuter före b vilket är användbart för t.ex. motorvärmare.

Man behöver naturligtvis inte alls implementera det som ovan men det är ett sätt att definiera vad man vill åstadkomma.

Pen

[starkjohan]

Ja, någon form av lösning på events som sträcker sig över 00:00 hade suttit fint. Jag har ett sådant för kontroll av temp i sovrummet.
Nu har jag fuskat lite och delat eventet på en del fram till 23:59 och ett nytt event som börjar 00:02 när uppdateringen skett. På dessa tre minuter hinner inte temperaturen i sovrummet påverkas speciellt mycket.

En annan förslag är bättre kontroll av output i run.php. Eftersom at-kommandot mailar stderr och stdout (går det att ändra till endast stderr?, jag lyckas inte) hade det varit smidigt om run.php hade fått lite bättre errorhantering. Just nu får jag mail på varenda jäkla event från at till www-data så jag gjorde det enklaste att helt enkelt kommentera ut de echon som egentligen bara är stdout. Inte det heller en speciellt snygg lösning

[starkjohan]

Jag löste "problemet" med dubbla poster i 'temps'-tabellen med en kombinerad nyckel:

Code: Select all

UNIQUE KEY `nyckelnamn` (`sensor_serial`,`date`)

och följande sql-syntax:

Code: Select all

INSERT INTO temps_test (sensor_serial,temp_c,date) VALUES (val1,val2,val3) ON DUPLICATE KEY UPDATE sensor_serial=sensor_serial"

Det innebär alltså att en sensor inte uppdateras i databasen om tdtool inte rapporterar något nytt värde.

[tom_rosenback]

Om jag klickar på en temperaturgraf får jag inte fram någon bild i popupen. Vad är det som skall visas? Är det bara samma graf fast i större format eller något mer intressant? Har inte tittat närmare på det (sitter på jobbresa nu) men det är kanske ett känt fel. Imagetagen verkar ha ett extra "/temperature" i sig.

Noterat och dubbelkollar. Tack!

Angående installation på Raspberry Pi.

Notera att "at" kommandot inte verkar ingå i Rasbian. Således fungerar inte scheman i HomeAutomation.

installera at;

Code: Select all

sudo apt-get install at

ta bort www-data ur at.deny

Code: Select all

sudo nano /etc/deny.at

Välj "återskapa scheman" i HA.

Lista aktuella at jobb

Code: Select all

sudo atq

Sen ska scheman fungera!

Mvh
/jonas

Tack för instruktionerna!

Ny feature för scheman.

Har tidigare kört min tellstick med EventGhost och pluginet SunTracker (windows), men håller på att migrera till HomeAutomation på Raspberry Pi.

Jag saknar en liten feature i HA som finns implementerad i SunTracker. Tänk er följande scenario;

Jag vill att en lampa tänds på klockan 07:00, och stängs av vid soluppgång (+/- tid). Detta scenario är inga problem på vinterhalvåret, men på sommarhalvåret inträffar soluppgången innan 07:00 vilket medför följande;

lampa av 06:00 (soluppgång)
lampa på 07:00

Dvs lampan kommer att stå på hela dagen, vilket känns lite onödigt. Det som istället är önskvärt är att lampan inte tänds alls, det är ju ljust ute!

Samma scenario kan även inträffa på kvällen, dvs jag vill att lampan tänds vid solnedgång, och släcks klockan 19.00. Om solnedgången är efter klockan 19.00 så händer följande;

lampa av 19.00
lampa på 20.00 (solnedgång)

Dvs lampan står på hela natten.

För att lösa detta förslår jag samma logik som finns i Suntracker, om på infaller efter av så ignoreras båda aktiveringarna.

Detta skulle kunna lösas i HA genom att införa en ny typ av aktivering, tex statisk-sol (ni kan säkert komma på ett bättre namn)

Vid denna typ av aktivering skulle man ange följande;
- en statisk tid då en enhet ska aktiveras (tex 06:00)
- ett soltillstånd (tex soluppgång) och +/- tid
- en minsta tid enheten måste vara aktiverad (tex 00:20) (inte lönt att tända 06:00 och släcka 06:01)

Om soluppgången innfaller efter 06:00 + 00:20, så schemaläggs följande;
på 06:00
av 07:00 (soluppgång)

Annars schemaläggs inget, och lampan förblir släckt.


Det finns även lite andra bra funtioner i Suntracker man kan tex ange vilka dagar som är semesterdagar, SunTracker kör då på automatik på lördags schemat eller semeste schema om det finns angivet.

Mvh
/jonas

Hejsan,

Är detta något du testat och konstaterat att det inte fungerar? Tanken är nämligen att det skall fungerar precis som du beskriver redan nu.

Ett liknande "problem" uppstår med temperaturkontroll. (statisk-dynamisk-dynamisk-statisk)

När det statiska eventet går igång tas inte hänsyn till den aktuella temperaturen. Dvs. elementen startar oavsett om det är för kallt, lagom eller för varmt. Det tycker jag vore en logisk funktion.

Tom, vad är det du har kvar att fixa med i 3.0? Om de funktionerna jag använder mig av (endast temperaturkontroll i stort sett) är "klara" kanske jag trots allt skulle köra svn. Om du gjort om systemet mycket är det kanske till mer hjälp med test av det nya snarare än det gamla? Kanske är flera av de förbättringsförslag som nämns redan implementerade i 3.0?

Det tas ingen hänsyn till vad som är konfigurerat i det dynamiska event när det statiska körs, nej. Jag har funderat lite på att kunna definiera regler i ett event som då skulle göra som du beskriver.

För tillfället är det mest små buggar som jag behöver lösa samt fixa installern så att den rockar. Du har så rätt med vilken version som borde testas men den SVN version som ligger ute nu är tyvärr rätt ostabil så ja skulle inte rekommendera den ännu. Som jag skrev ovan så skall de förslag du gett redan vara implementerade i 2.0.2 men om dom inte är det så är det en klar bug. Får kollar närmare på den saken.

[tom_rosenback]

Intressant. Precis detta orsakade mig mycket huvudbry när jag byggde min egen schemaläggare (jag planerar att gå över till homeautomation från 3.x). Dessutom tyckte jag att det var svårt att definera begrepp såsom "före", "efter" mm när multipla händelser styr något och vad som händer när man passerar 23.59. Jag löste det i princip så här:

Definera entydigt vad som menas med att klockan t är i ett intervall mellan tiden a och b:

function isIn($t,$a,$b)
// Test om tiden t tillhör intervallet [a,b]
// Intervall upp till 23:59 timmar tillåts
// t tillhör [a,b] omm (t-a)mod24:00 <= (b-a)mod24:00
// strtotime(t): Koverterar tid till sekunder. Kan även ta in full tid med datum.
{
$a_to_t_length = strtotime($t) - strtotime($a);
if ($a_to_t_length < 0) {$a_to_t_length = $a_to_t_length+86400;};
$a_to_b_length = strtotime($b) - strtotime($a);
if ($a_to_b_length < 0) {$a_to_b_length = $a_to_b_length+86400;};
if ($a_to_t_length > $a_to_b_length) {return 0;} else {return 1;};
};

Uttryck t.ex. ytterbelysningens önskade villkor som att tiden är i två intervall samtidigt - dels ska den vara mellan två klockslag (6-22 nedan) och dels ska den vara mellan soluppgång och solnedgång.

if (isIn($Time,'06:00','22:00') && isIn($Time,$SunSet,$SunRise)) {$State['Ytterbelysning'] = "on";}

På samma sätt definierade jag vad som menas med att klockan t är c minuter före b vilket är användbart för t.ex. motorvärmare.

Man behöver naturligtvis inte alls implementera det som ovan men det är ett sätt att definiera vad man vill åstadkomma.

Pen

Tack för heads-uppen!

Ja, någon form av lösning på events som sträcker sig över 00:00 hade suttit fint. Jag har ett sådant för kontroll av temp i sovrummet.
Nu har jag fuskat lite och delat eventet på en del fram till 23:59 och ett nytt event som börjar 00:02 när uppdateringen skett. På dessa tre minuter hinner inte temperaturen i sovrummet påverkas speciellt mycket.

En annan förslag är bättre kontroll av output i run.php. Eftersom at-kommandot mailar stderr och stdout (går det att ändra till endast stderr?, jag lyckas inte) hade det varit smidigt om run.php hade fått lite bättre errorhantering. Just nu får jag mail på varenda jäkla event från at till www-data så jag gjorde det enklaste att helt enkelt kommentera ut de echon som egentligen bara är stdout. Inte det heller en speciellt snygg lösning

Får nog ta och fundera på "overnight" featuren!

Outputten i run.php kan jag fixa så att den stängs av om inte debug läge är aktivt, så det är inget problem.

Jag löste "problemet" med dubbla poster i 'temps'-tabellen med en kombinerad nyckel:

Code: Select all

UNIQUE KEY `nyckelnamn` (`sensor_serial`,`date`)

och följande sql-syntax:

Code: Select all

INSERT INTO temps_test (sensor_serial,temp_c,date) VALUES (val1,val2,val3) ON DUPLICATE KEY UPDATE sensor_serial=sensor_serial"

Det innebär alltså att en sensor inte uppdateras i databasen om tdtool inte rapporterar något nytt värde.

Detta förutsätter att datumet och sensorn är identiska, vilket dom är i tdtool fallet, men det finns andra system som inte ens har något datum och där måste man nog kolla på ett annat sätt, detta är dock helt bra det också och är nog värt att slänga in i HA koden! Tack!