Autogenerator Fehler

[Dragonos2000]

Hallo,

ich habe heute kurzfristig wegen eines Datums-Problems auf SH 1.0 / SV 2.7 umgestellt. Nach ein paar Anpassungen, die mich bisher von der Umstellung SH 0.9 -> SH 1.0 abgehalten haben, habe ich mich gewundert, warum einige Seiten nicht mehr angezeigt werden bzw. nach einem Reload im Browser dann auf einen Fehler laufen.
Als Problem habe ich die Plots identifiziert und zwar, wenn ich mehrere Plots in einer Grafik darstellen will und die Farben vorgebe.

Folgendes Statement in der Items.conf

sv_widget = "{{ plot.period('item', ['item.L1', 'item.L2' , 'item.L3'], 'max', '1d', '', 0, '','', ['L1','L2','L3'],['#aa0', '#a00','#0aa'], ['stair', 'stair', 'stair']) }}"

führt zu folgendem HTML-Code

<div class="block">
    <div class="set-2" data-role="collapsible-set" data-theme="c" data-content-theme="a" data-mini="true">

        <div data-role="collapsible" data-collapsed="false">
            <h3>Strom taeglich</h3>
            "{{ plot.period('central.energy.meter_og.I', ['central.energy.meter_og.I.L1', 'central.energy.meter_og.I.L2' , 'central.energy.meter_og.I.L3'], 'max', '1d', '', 0, '','', ['L1','L2','L3'],['
        </div>

    </div>
</div>

Der Code wird also unvollständig erzeugt. Das taucht bei mehreren anderen Plots mit ähnlicher Konfig genauso auf. Sieht so aus, als ob er genau dann auf die Nase fällt, wenn das # für den Farbwert kommt.
Ich kann nun allerdings nicht sagen, ob der Grund in SH oder SV liegt, da ich das RPI Image einsetze und beides nun auf neuer Version ist
Kann das jemand bestätigen/nachvollziehen?

Gruss
Jochen.

[TCr82]

Ja hatte ich auch schon bei der Pre-Release gemeldet. Marcus wollte das aber leider nicht mehr korrigieren.

Gesendet von meinem GT-I9100 mit Tapatalk

[callidomus]

Und das war meine Antwort darauf (2 Tage vor Release) - mit Workaround
https://knx-user-forum.de/352848-post23.html

[Dragonos2000]

OK, danke für die Info, hab das per Forumssuche auf die Schnelle nicht gefunden.

Gruss
Jochen

[Dragonos2000]

Anderes Problem: Bei Restart

Hi,

bin noch auf ein anderes Problem gestoßen, auf das ich mir keinen Reim machen kann:

Bei einem Reboot des Systems oder Restart von SH mit Smartcontrol, werden leere Files für die Räume erzeugt. Melde ich mich mit admin an und stoppe / starte SH von hier aus mit "sudo /etc/init.d/smarthome.py start", oder auch im Debug taucht der Fehler nicht auf.
Vielleicht hat von Euch einer eine Idee, woran das liegen könnte, bevor ich das System nochmal von Scratch neu aufsetze

Im Log hab' ich folgende Fehlermeldung, wenn ich den Fehler provoziere:

Init SmartHome.py 1.0-21-g7f162e6
2014-01-01 13:11:45 INFO     Main         Start SmartHome.py 1.0-21-g7f162e6
2014-01-01 13:11:45 INFO     Main         Init Scheduler
2014-01-01 13:11:45 INFO     Main         Init Plugins
2014-01-01 13:11:48 INFO     Main         Init Items
2014-01-01 13:11:54 INFO     Main         Start Plugins
2014-01-01 13:11:54 INFO     Main         Start Logics
2014-01-01 13:11:55 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.living_room.html
2014-01-01 13:11:55 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.terace.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.hall.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.office.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.kitchen.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.bath_room.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/og.bed_room.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/roof.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/central.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/outdoor.html
2014-01-01 13:11:56 WARNING  visu         Could not write to /var/www/smartvisu/pages/smarthome/alerts.html

Die Berechtigungen sehen eigentlich okay aus und sind identisch, wenn Fehler / kein Fehler:

-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 alerts.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 central.html
-rw-r--r-- 1 admin admin  809 Jan  1 12:11 index.html
-rw-rw-r-- 1 admin admin 1833 Jan  1 12:11 navigation.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.bath_room.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.bed_room.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.hall.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.kitchen.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.living_room.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.office.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 og.terace.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 outdoor.html
-rw-rw-r-- 1 admin admin    0 Jan  1 12:11 roof.html
-rw-r--r-- 1 admin admin  443 Jan  1 12:11 rooms.html

Von den Prozessen her sieht es m.E. auch unauffällig aus (Auszug während Fehlersituation):

1 S admin     1698     1  0  80   0 -  1012 poll_s 12:11 ?        00:00:01 /usr/bin/eibd --daemon --Server --Tunnelling --Discovery --GroupCache --listen-tcp --pid-file=/var/run/eibd.pid --eibaddr=15.
5 S avahi     1718     1  0  80   0 -   835 poll_s 12:11 ?        00:00:00 avahi-daemon: running [smarthome.local]
1 S avahi     1719  1718  0  80   0 -   835 unix_s 12:11 ?        00:00:00 avahi-daemon: chroot helper
0 S root      1747     1  0  80   0 -  1975 poll_s 12:11 ?        00:00:00 python /usr/sbin/avahi-alias
5 S ntp       1760     1  0  80   0 -  1335 poll_s 12:11 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -x -c /var/lib/ntp/ntp.conf.dhcp -u 101:102
1 S admin     1811     1  0  80   0 -  2355 SyS_ep 12:11 ?        00:00:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
0 S admin     1814  1811  0  80   0 -  4829 wait   12:11 ?        00:00:00 /usr/bin/php5-cgi
0 S admin     1821  1811  0  80   0 -  4829 wait   12:11 ?        00:00:00 /usr/bin/php5-cgi
0 S admin     1828  1811  0  80   0 -  4829 wait   12:11 ?        00:00:00 /usr/bin/php5-cgi
0 S admin     1832  1811  0  80   0 -  4829 wait   12:11 ?        00:00:00 /usr/bin/php5-cgi
1 S admin     1833  1821  0  80   0 -  4829 skb_re 12:11 ?        00:00:00 /usr/bin/php5-cgi
1 S admin     1834  1832  1  80   0 -  4934 skb_re 12:11 ?        00:00:11 /usr/bin/php5-cgi
1 S admin     1835  1828  0  80   0 -  4829 skb_re 12:11 ?        00:00:00 /usr/bin/php5-cgi
1 S admin     1836  1814  0  80   0 -  4829 skb_re 12:11 ?        00:00:00 /usr/bin/php5-cgi
5 S root      1849     1  0  80   0 -  1543 poll_s 12:11 ?        00:00:00 /usr/sbin/sshd
1 S admin     1879     1  2  80   0 - 21577 SyS_ep 12:11 ?        00:00:12 python3 /usr/smarthome/bin/smarthome.py --start

Habt Ihr da noch einen Tip für mich?
Gruss
Jochen.

[Apollo]

Zugriffsrechteproblem auf den Ordner pages.

Gruss

[Dragonos2000]

So in die Richtung vermute ich auch. Allerdings schafft er es die Dateien zu erzeugen, nur nichts reinzuschreiben.
Und SH/SV wird doch auch als Admin ausgeführt, oder?

drwxr-xr-x 2 admin admin 4096 Jan 1 12:32 smarthome
und
drwxr-xr-x 14 admin admin 4096 Jun 15 2013 pages

sehen mir auch plausibel aus

Gruss
Jochen.

[callidomus]

Hi,

welches Image verwendest Du?

Bis bald

Marcus

[Dragonos2000]

Hi,

hab' das 2013-11-16_2.img aufgespielt

Gruss
Jochen.

[callidomus]

Hi Jochen,

mach bitte mal eine Update über smartcontrol. Dann solltest Du im Logfile mehr angezeigt bekommen, weshalb nichts geschrieben werden konnte.

Vllt. hängt es mit der Formatierung zusammen. Evtl. BOM oder ähnliches in den Dateien.

Bis bald

Marcus

[Dragonos2000]

Hi Marcus,

habe bemerkt, dass manchmal nach einem Restart noch die folgende Meldung auftaucht:

2014-01-01 21:26:56 ERROR    env_loc      Logic: env_loc, File: /usr/local/lib/python3.2/dist-packages/ephem/__init__.py, Line: 379, Method: visit_transit, Exception: 'Sun' transits below the horizon at 2014/1/2 11:30:53
Traceback (most recent call last):
  File "/usr/smarthome/lib/scheduler.py", line 327, in _task
    exec(obj.bytecode)
  File "/usr/smarthome/lib/env/location.py", line 13, in <module>
    day = sh.sun.rise(-6).day != sh.sun.set(-6).day
  File "/usr/smarthome/lib/orb.py", line 63, in rise
    next_rising = self._obs.next_rising(self._orb, use_center=center).datetime()
  File "/usr/local/lib/python3.2/dist-packages/ephem/__init__.py", line 457, in next_rising
    return self._riset_helper(body, start, use_center, True, False)
  File "/usr/local/lib/python3.2/dist-packages/ephem/__init__.py", line 435, in _riset_helper
    d1 = visit_transit()
  File "/usr/local/lib/python3.2/dist-packages/ephem/__init__.py", line 379, in visit_transit
    % (body.name, d))
ephem.NeverUpError: 'Sun' transits below the horizon at 2014/1/2 11:30:53

In der Smarthome.conf hab' ich nur das stehen, allerdings ist das oben auch nicht immer reproduzierbar:
lat = 49.10
lon = 8.28
elev = 150
tz = 'Europe/Berlin'

Der output vom Update ist unauffällig:

Updating system... 
Please wait......................... [[COLOR=green]OK[/COLOR]]
Updating SmartHome.py  
HEAD is now at 7f162e6 remove debug output 
Updating 7f162e6..9c5d8fd Fast-forward  plugins/visu/smartvisu.py |    2 +-  1 file changed, 1 insertion(+), 1 deletion(-) 
Restarting SmartHome.py smarthome.py  
Updating smartVISU  
Reverted 'temp/offline_berlenz.var' 
Reverted 'temp/offline_fleischer.var' 
Reverted 'temp/offline_alber.eibd.var' 
Reverted 'temp/offline_meister.var' 
Reverted 'temp/offline_gleiss.linknx.var' 
Reverted 'temp/offline_otterstaetter.var'
Reverted 'temp/offline_docu.var' 
Reverted 'temp/offline_alber.smarthome.py.var' 
Reverted 'temp/offline_gleiss.smarthome.py.var' 
Updating '.':  
Fetching external item into 'vendor/Twig': External at revision 2499.   
Fetching external item into 'vendor/jquery.cycle2': External at revision 97.   
Fetching external item into 'vendor/google.prettify/src': External at revision 304.   
Fetching external item into 'vendor/google.prettify/styles': External at revision 304.  
At revision 539.

Im Logfile kommen danach nicht mal mehr die Fehlermeldungen, Files werden aber trotzdem nicht geschrieben (diesmal wurde nur eine Datei mit 0 Byte angelegt)

2014-01-01 21:30:48 INFO     Main         Number of Threads: 7
2014-01-01 21:30:48 INFO     Main         Stop Plugins
2014-01-01 21:30:52 INFO     Main         SmartHome.py stopped
Init SmartHome.py 1.0-22-g9c5d8fd
2014-01-01 21:30:56 INFO     Main         Start SmartHome.py 1.0-22-g9c5d8fd
2014-01-01 21:30:56 INFO     Main         Init Scheduler
2014-01-01 21:30:56 INFO     Main         Init Plugins
2014-01-01 21:30:59 INFO     Main         Init Items
2014-01-01 21:31:04 INFO     Main         Start Plugins
2014-01-01 21:31:04 INFO     Main         Start Logics

Gruss
Jochen.

[Dragonos2000]

Ich hab' glaub' nen Ansatz:
Ich hab' bei der 0.9 das Backup um die /etc/init.d/smarthome.py erweitert, weil ich dort einen Datums-Check eingebaut hatte, der den Start solange verhindert, bis das Datum des RPI synchronisiert ist.

Auf dem 1.0 Image habe ich mir die Datei mit dem Einlesen der Konfig-Dateien überschrieben. Wenn es Unterschiede zwischen 0.9 und 1.0 gibt, könnte hier der Hund begraben sein...

Gruss
Jochen.

[callidomus]

Hi Jochen,

Ja es gab in der Datei Anpassungen, die zu dem Fehlerbild passen. Hatte was mit der Sprache in der Umgebung, Python 3 und UTF-8 zu tun.

Bin aber heute nicht mehr am Rechner.

Bis dann

Marcus


Gesendet von unterwegs

[Dragonos2000]

Heureka - am /etc/init.d/smarthome.py lag's

Danke für Eure Unterstützung!

Gruss
Jochen.

[Onkelandy]

Heho!
Ich hab mein Init-Skript adaptiert, aber doch wieder den Fehler mit dem "sun above horizon".. Schmarren, was dazu führt, dass beim Neustart Tag und Nacht falsch erkannt werden

Any ideas?