SensorAndSwitch Haus-Automation auf Webserver-Basis

[ws65]

die Pseudoscripte hab ich auch in Verdacht.
hab nämlich ca 15 Scripte die immer Status lesen und schreiben auf der SD-Karte.

hatte jetzt mal die Idee entweder die Statusdateien auf eine angeschlossene HD zu speichern,
oder SAS ganz von der Festplatte laufen zu lassen.
bringt das was?
hab allerdings bei der Festplatte Probleme mit den Rechten!
Beispiel:
mit Samba über wwwdata/usbhd komme ich nicht dran,
gehe ich aber über alldata/var/www/usbhd komme ich da dran.
Kann Daten lesen und ändern, aber SAS geht so nicht.

bin dabei mich schlau zu machen, hängt glaube ich mit der Art der Einbindung in der fstab ab.
hab da im Moment drin:
UUID=FCC8AE65C8AE1DC0 /media/usbntfs/ ntfs-3g defaults,auto,users,rw 0

da müsste aber noch sowas wie
uid=www-data,gid=www-data
dazu, weis aber noch nicht wie.
bin da ja auch bei der fstab vorsichtig geworden, schlechte Erfahrung.

Edit: in der php.ini war 30 eingestellt, hab mal auf 0 geändert.

 

[JL3]

Wenns die Himbeere ist, den tmp-Bereich von sas nutzen und so einrichten, wie in der Anleitung als RAM-Laufwerk beschrieben steht. Ich schreibe die Pseudoscripte, die status-Dateien produzieren dahingehend um, dass sie ihre Dateien dort kurz ablegen. Dann läuft das ohne die SD-Karte zu strapazieren. Das Edimax-Script habe ich bereits bei mir angepasst.

 

[JL3]

Die externe Festplatte kann nur ext3 oder ext4 - formatiert mit Linuxrechten versehen werden, wenn ich mich nicht irre. Ist die so formatiert?

 

[ws65]

die Platte ist ntfs, schon gelesen das das damit schwierig ist,
sollte aber mit uid=www-data,gid=www-data in der fstab gehen.

wenn nicht, muss ich sie umformatieren.

 

[JL3]

Habe ich noch nicht versucht, daher kann ich leider nichts dazu sagen. Da hilft wohl nur Ausprobieren.

 

[JL3]

ein Wort zu der neuen 1.50er Version.

das SAS Script ist ja noch unseren Wünschen und eigentlich sehr gut, aber es ist sehr langsam geworden.
wenn ich mehr als ca. 32 Scripte im Hauptverzeichnis habe stürzt das ganze mit einem weisen Bildschirm ab.
liegt das an meinem langsamen Computer?
hab extra mal server2go versucht, aber das selbe Ergebnis.

ich hätte zwar noch Wünsche zur Verbesserung, werde mich aber mal zurückhalten.
eventuell besser, man versucht erst mal die Laufzeit zu optimieren.

ich brauche auch keine 25 Scripte pro Reiter, wird einfach zuviel des Guten.

Ich habe mich jetzt eingehend mit dem Problem der langsamen PseudoScripte beschäftigt, doch es liegt dort schon in der Natur der Sache, dass jede externe Abfrage Zeit kostet. PHP ist ein Interpreter und damit ebenfalls nicht sehr schnell. Nachdem ich sogar schon etliche Alpha-Versionen mit Abspeichern aller Gerätedaten im Temp-Bereich, sodass die Scripte nur diese lesen müssten und verschiedener anderer Lösungsansätze ausprobiert und getestet habe, konnte ich bei keiner eine Verbesserung der Geschwindigkeit feststellen. Am schlimmsten sind Webabfragen von Internetseiten. Sie blockieren teils lange die Abarbeitung.

Fazit: Solange mir da keine zündende Idee kommt, müssen wir damit leben. Sorry. Ich hoffe, sas erfüllt trotzdem noch seinen Zweck, auch wenn es mit Pseudoscripten einfach langsamer geworden ist.

 

[SF1975]

Hallo,

Fazit: ... müssen wir damit leben. Sorry. Ich hoffe, sas erfüllt trotzdem noch seinen Zweck...

Kein Problem. Erstens können wir keine Erwartungen/Forderungen an Dich stellen, da ja alles privat von Dir gemacht wird.
Zweitens kannst Du Dinge nicht beschleunigen, die Du nicht beschleunigen kannst

Alles bestens so

 

[fred_feuerstein]

Sehe ich genauso. Mach Dir mal keinen Kopf JL3.

Das SAS macht genau das was es soll. Und das vor allem sehr sehr gut .
Jeder kann selbst entscheiden ab wann vielleicht das ein oder andere Pseudoskript für die Performance, auch aufgrund der verwendeten Hardware, zu viel ist.

 

[HarryHase]

Als Gedankenspiel; machte es Sinn bei jedem Durchlauf 5 / 8 / 10 Dekunden oder was da auch immer eingestellt ist sinn die Web-Scripte durch zulaufen, oder kann man die nicht jedes 3'te mal durchlaufen oder einmal die stunde oder oder ... Wenn ich das richtig verstanden habe sollte es dann flotter gehen?

 

[JL3]

Die Aktualisierung regelt - wie der Name schon sagt - die Aktualität der Schalter und Sensoren. Gerade bei den Schalterstellungen möchte man möglichst aktuelle Werte. Schließlich will man sich ja die SAS-Anzeige nicht ausdrucken und für den Tag an die Wand hängen zum Draufschauen.

Aber Spaß beiseite. Sicher kann man mit dem Aktualisierungswert experimentieren. Je länger, desto weniger Scriptdurchläufe. Nur wozu? Da sehe ich auch nicht wirklich einen Vorteil. Pseudoscripte auch nur jeden xten Durchlauf zu berücksichtigen ist leider auch keine Lösung, da sich in den Pseudoscripten auch Schalter befinden und die wären dann nicht aktuell. Ich habe jetzt zumindest schon einmal für die 1.60 die Schalteraktualisierung direkt nach dem Abarbeiten des Schaltvorgangs umgesetzt und die Sensorwerte werden dann nach dem "Warterädchen" nachgeholt. So macht eine längere Aktualisierungszeit weniger aus.

Pseudoscripte, wie das des Pi mit vielen Daten, sind ebenfalls eine Bremse. Sie beinhalten bis zu 6 sashelper-Aufrufe und jeder davon braucht seine Zeit. Ich denke über einen sashelpermulti nach, der gleich mehrere Befehle auf einmal übergeben kann und die Ergebnisse auf einen Rutsch zurückliefert. Mal sehen.

Ich arbeite jedenfalls nach wie vor an dem Problem. Kann nur etwas dauern und Erfolg ist nicht garantiert.

 

[ws65]

so, bin jetzt mit meinem SAS mal auf externe HD am Raspi umgezogen.

ich meine etwas besser ist es schon, und stürzt jetzt auch nicht mehr ab.

hab ja auch schon einge Scripte gesammelt, aber wenn man die maßvoll einsetz geht das schon.
bin halt der Meinung mit 30-40 Scripten sind die meißten Anforderungen abgedeckt, mehr brauche ich wahrscheinlich nicht.
War halt nur ein Denkanstoß, das mit der Laufzeit.
SAS ist schon gut, und JL3 auch, er tut schon was er kann!

 

[koyaanisqatsi]

Aktualisierung

Gedankenexperiment...
"Das SaS Webinterface erhält seine Anzeigedaten nicht durch sich selbst,
sondern von der "Brain" der minütlichen crond Ausführung.
Genauso wie dann das Schalten nur vom crond Aufruf initiert wird."

...wenn "möglichst Aktuelle" davon ausgeschlossen werden können,
wär daß naürlich auch eine feine Sache, aber Wetterdaten und so?

 

[JL3]

Ein zentraler Datenpool hatte ich auch schon im Versuch. Grundsätzlich verwendet die Fritzbox-FW ebenfalls einen solchen Datenpool für die Sensordaten der Dosen. Aktualisierung erfolgt hier alle 2 Minuten. Bei mir lief das irgendwie programmtechnisch nicht rund, weil sas auch der Datenerzeuger und -verwerter war und da biss sich irgendwie ständig was.

Die Idee mit crond ist dafür ein äußerst interessanter Denkansatz. Damit werkelt sascron zur Datenbeschaffung vor sich hin und sas greift nur auf den Datenpool zu und wäre sehr schnell. Schaltinfos schreibt sas beim schalten selbst rein.

Mir gefällt die Idee. Das klingt nach sas 2.0 :mrgreen:

 

[JL3]

Bei ersten Versuchen übernimmt sasap das Erstellen des Gerätepools. Es läuft dann zwar fast 20 Sekunden, aber das bekommt man ja nicht mit. Das automatische Schalten wird nicht verzögert, aber das Script arbeitet etwas länger, um die nicht schaltrelevanten Preudos noch abzuarbeiten, aber ich denke, eine halbe Minute länger das wäre da noch zu verschmerzen.

Das Ganze nimmt schon Form an...

 

[HarryHase]

cool, das freut mich richtig und zeigt wie eine community an konzepten weiter arbeitet ...

 

[JL3]

Jep. Danke an koyaanisqatsi für den Denkansatz mit crond. Das sieht schon sehr vielversprechend aus. sasap schreibt alle Geräteinfos nach seinen Schaltvorgängen (die sind dann auch mit berücksichtigt) in eine Array-Datei und dort sind sogar schon die P##-Anzeigen fix und fertig HTML-formatiert. sas muss dann nur noch diese Array-Datei einlesen, was sehr schnell geht und anzeigen. Der Aufbau geht dabei ruckzuck. Soweit so gut.

Jetzt darf sich Schreiben und Abfragen der Daten nicht in die Quere kommen. Und manuelle Schaltvorgänge müssen berücksichtigt werden (Aktualisierung der Array-Datei auch von sas). Das sind die nächsten Schritte...

Nachtrag: WebGUI-Ladezeit kleiner 1 Sekunde. Das macht was her...... superschnell zwischen den Seiten wechseln, superschnell in die Einstellungen und zurück.
Jetzt noch der Schaltupdate...

 

[JL3]

Sieht gut aus. Probleme machen noch die Pseudoscripte... muss ich noch nachsehen. Ansonsten funktioniert es schon im Alpha-Stadium.

 

[SF1975]

Hallo,
*Daumenhoch*

 

[JL3]

Leider noch immer große Probleme mit Pseudogeräten. "display"-Scripte machen hier in bestimmten Konstellationen undefinierbare Probleme. Ich arbeite noch daran... ist zum Glück die Alpha-Version...

 

[JL3]

Inzwischen funktionieren alle Schaltgeräte, solange es nicht PseudoGeräte mit versteckter DECT200 sind. Da muss ich noch basteln. Ansonsten ist die Ladezeit von sas unter 1 Sekunde, es sei denn, sasap schreibt gerade Gerätedaten. Dann wartet sas einige Augenblicke, aber das fällt nicht so ins Gewicht. Sämtliche Sensordaten aktualisieren nach 1 Minute, da sie von sasap abgefragt und bereit gestellt werden. Schaltsteckdosen wie DECT200 und auch Edimax reagieren sofort auf einen Mausklick auf den Schalter und dieser wechselt auch sofort den Schaltzustand. Zwischen den Modulen kann man nun ebenfalls in 1 Sekunde wechseln. Das alles geht jetzt richtig flott. Auch das Erfassen von Schaltlisten ist nun richtig schnell (sasapui).

Naja, so weit so gut. Zufrieden bin ich allerdings noch nicht. Jedenfalls wird dies später - wenn wirklich alles funktioniert - tatsächlich die Version 2.00