smartVISU Widgets

[the ratman]

ja, der hat das auch gelöst mit einer anderen version - siehe http://forum.fhem.de/index.php/topic,47827.0.html

das dumme ist, ich weiß immer noch ned, wo ich diese version 3.2 her kriege, weil meine 2.0 is definitiv nicht brauchbar und die 3.99 scheint schon smartvisu 2.8 zu sein.

hat BITTE irgendwer einen direkten link zu dieser v 3.2?

[dev0]

hat BITTE irgendwer einen direkten link zu dieser v 3.2?

Findest Du im UZSU Repository

[the ratman]

vielen dank - genau das suchte ich *g*

hab die files zwar schon per mail gekriegt, die waren aber recht kaputt und unvollständig - jetzt testen ma mal das original von dir.


nachtrag:
JAU, DAS wars warscheinlich - der onkel ratti is grad glücklich
in der config wird jetzt z.b.

Code Auswählen Erweitern

DEF Buecherregal_RGB en MO,TU,WE,TH,FR,SA,SU|12:20|1
mal gucken, obs auch los rennt, aber schaut ja gut aus jetzt

danke nochmal

[dev0]

.... SU|12:20|1

Keine Ahnung was Du schalten möchtest, aber "on" statt "1" wäre typischer für FHEM devices...

[the ratman]

die 1 und 0 waren noch n überbleibsel von meiner testerei - mir war nur wichtig zu zeigen, dass dieses vermaleteite ">>>{ my $date=1453720545;{_abs("REAL",0,,)}}<<<" weg is.
es rennt und rennt und rennt. ein großer meilenstein für mich, weil mit der uzsu auch meine freundin locker mal was mit machen kann.

wenn man jetzt von einem uzsu aus gleich einen set-befehl erweitern oder gar mehrere abschicken könnte könnte, wär ich im 7. himmel.
bsp.: als text eingeben "blink 3 3" oder "lampe1 lampe2" oder "pct 50", ... das packt der gute wohl nicht, scheint mir ...

eine dumme (naje, bis jetzt mal) frage hab ich allerdings noch:
sobald ich was an einem timer in sv ändere, schreit fhem, dass die config gespeichert werden muß. is das normal? kann ichs ignorieren?

[dev0]

wenn man jetzt von einem uzsu aus gleich einen set-befehl erweitern oder gar mehrere abschicken könnte könnte, wär ich im 7. himmel.

Ohne jetzt nachzusehen ist das eine Einschränkung des WeekdayTimers. Dietmat63 in der Rubrik Unterstützende Dienste entwickelt ihn...
Mit zusätzlichen Notifies läßt sich das aber auch umsetzen.

sobald ich was an einem timer in sv ändere, schreit fhem, dass die config gespeichert werden muß. is das normal? kann ichs ignorieren?

Es ist einfach die Entscheidung, ob ein Modul oder Erweiterung eigenständig die Konfig speichern soll/darf oder nicht. FHEM kann nicht selektiv speichern, alles oder nichts. Worst case wäre, wenn nach einem FHEM Neustart irgendwelche Module nicht geladern werden können, warum auch immer... Das Nächste save (automatisch durch Änderung einer UZSU Schaltzeit) würde sie aus der Konfiguration löschen. Ohne zu speichern würden allerdings Deine nicht gespeicherten UZSU Weekdaytimer, durch einen Neustart, verloren gehen.

Wenn Du in Deine 99_fronthemUtils schaust, findest Du in der Fn UZSU_execute folgende Zeile. Du kannst sie einkommentieren oder auch nicht. Deine Entscheidung.

Code Auswählen Erweitern


#fhem('save');   # use only if you want to save WDT settings immediately.


Btw: Änderungen an dieser Datei werden durch ein Update nicht automatisch überschrieben. Es ist das Äquivalent zu deiner persönlichen myUtils.pm...

[the ratman]

thx für die informationen.
naja, schalt ich das "autosave" mal ein. wird wohl besser sein, bevor ich wieder 1000 mal das speichern vergess *g*.

[bgewehr]

Es ist  ja so:

Die UZSU-Einstellungen aus SmartVISU werden in einem Userreading UZSU am zu schaltenden Device gespeichert und sind somit persistent über die das fhem statefile auch nach dem Neustart wieder da.

Die diversen UZSU-Weekdaytimer sind nur Erfüllungsgehilfen, müssen aber als devices in fhem erzeugt werden und sind somit in der fhem.cfg zu sichern, damit diese nicht neu erzeugt werden müssen.

fhem.save in der UZSU_execute soll genau dies machen. Dabei werden natürlich auch alle anderen Änderungen an der Konfiguration gespeichert, was nicht immer erwünscht ist.

Wenn das nicht gefällt, kann man auch eine Funktion "Create_UZSU_WDT_from_all_UZSU_Readings()" schreiben, die alle UZSU-Readings sucht und die wdts dazu neu anlegt.

Wäre ein Dreizeiler, schätze ich. Ob man beim Start von fhem solche Funktionen automatisch aufrufen kann (on_start()), das habe ich noch nicht untersucht...

[dev0]

Das Einfachste wäre mMn:

Code Auswählen Erweitern


CommandSave(undef,undef) if AttrVal("global", "autosave", 1);


In der command reference ist global/autosave so definiert:

enable some modules to automatically trigger save after a configuration change, e.g. after a new device was created. Default is 1 (true), you can deactivate this feature by setting the value to 0.

Wenn Jörg das Attribut in fronthem einbauen würde, dann könnte man es selektiv für fronthem ein/ausschalten.
@Jörg: Soll ich Dir einen Patch schicken? 

[herrmannj]

Danke fürs Angebot.

Ich arbeite lokal schon sehr viel weiter aber wenn Du magst gib das ins git und ich drück auf merge ...

vg
joerg

[dev0]

Ich arbeite lokal schon sehr viel weiter

Was hältst Du von einem git developer branch mit Deinem aktuellen Stand?

[bgewehr]

@dev0: das weißt Du doch schon! )

[herrmannj]

Oh Sorry.


Lasst mich das reinstellen wenn es lauffähig wird. Sonst mach ich euch mehr fragen.

Ich arbeite den webserver inkl php und User Setup ins modul ein. Es wird keinen ip zwang mehr geben sondern auch generische device. Die config geht von File auf sqllite. Gilt auch für logs. Weder mit file noch db konnte ich mich anfreunden, da kommt was komplett eigenes. Ich bekomme unterstützung eines der besten pentester um die Sicherheit zu maximieren.


Florian entwickelt eine wp app. Android hätte ich ein wenig, jemand für Apple wird noch gesucht.

[dev0]

reinstellen wenn es lauffähig wird. Sonst mach ich euch mehr fragen

Hintergedanke war eher Dich vielleicht irgendwie zu unterstützen...
Mit Apple-Entwicklung kann ich leider nicht dienen.

[herrmannj]

Hintergedanke war eher Dich vielleicht irgendwie zu unterstützen...

Absolut verstanden, vielen Dank.

Ist auch genau der Punkt. Wenn sich aus dem code noch nicht erschließt wozu x||y||z da sind, oder warum das (X) so und nicht anders gemacht ist, dann ist es halt schwer.

Was aber gut wär: wenn jamnd sich mit dem letsencrypt Protocoll beschäftigen würde. Die notwendigen (Server) Zerifikate würde ich gern von dort beziehen - bitte ohne den python client sondern direkt im modul (perl). Ein "well known url" für die validation kaann ich fix im modul erzeugen. Ich habae aber noch keine Verständniß für das rund herum.

vg
joerg