Hallo zusammen,
ich hoffe Ihr habt alle Weihnachtsgeschenke beisammen und das Fest kann kommen.
Wie versprochen hier eine Preview (beta 1) auf den aktuellen Entwicklungsstand fronthem (smartVISU @ fhem).
Das Paket richtet sich in in erster Linie an die Anwender mit Erfahrung, die Dateien in der zip liegen in den entsprechenden Unterverzeichnissen. Es werden auf fhem Seite die beiden perl module Net::WebSocket::Server und JSON benötigt. Die Dateien im smartVISU Verzeichnis sind optional ( aber empfohlen). Sie stellen die Mandantenfähiglleit auf smartVISU Seite her.
SmartVISU selbst läßt sich auf smartVISU de oder aus deren GIT laden (man braucht nicht (!) das Paket mit smarthome.py, nur die knapp 30mb smartVISU ... )
Neue Installation sowie updates:
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
perl module:
curl -L https://cpanmin.us | perl - --sudo App::cpanminus (evtl. wenn noch nicht auf dem system..)
sudo cpanm Net::WebSocket::Server
sudo cpanm JSON
Im großen und ganzen sollte man sich darüber im klaren sein das man sich einarbeiten muss, das braucht Zeit (und Geduld). Die beta ist vom Umfang noch weit von vollständig entfernt - trotzdem lassen sich bereits erstaunlich vollständige und gut funktionale sv Oberflächen erstellen - und es wird weiter gehen !
Vielen Dank an die Tester der ersten Runde die sehr viel wertvolles Feedback gegeben und zusätzlich im Wiki erste Anlaufpunkte geschaffen haben.
im Vorwege, frohe Weihnachten an die fhem Gemeinde,
viele Grüße,
Jörg
issue:
perl < 5.14, raised error at #113, #173, #294 (unlessed array)
CFG loader wont work with some versions of JSON at first startup
rereadcfg führt zum Absturz, daher nicht von Hand in die cfg schreiben (Strafe muss sein ;) )
ws fehler nach aktivieren und deaktivieren von flugmoduls
NumDisplay verchluckt minus (bitte solange DumDirect verwenden, NumDisplay hat trotz allem seinen Sinn, bsp weil es formatieren kann)
UTF8 und Sonderzeichen konvertieren
Converter und ":" im event (Zeiten) arbeitet fehlerhaft
GAD in der Form "{{ HCSCalues.OliLevel }}" verhindern Editor
open todo:
converter für fs20 dimmer
converter (delayed actions)
converter disable/enable attrib
attribut für default access
copy existing access cfg at define
open implementation:
plots
native wvc support
certs and ca (client side certs aktuell keine option mehr da keine massentaugliche device unterstützung)
Vielen Dank für die beta.
Kann es sein, dass die fhconverter.pm im zip fehlt?
danke & sorry da isser:
vg
jörg
Danke. Dann mache ich mal weiter.
und btw - in smartVISU den domotiga treiber nehmen, port 2121. Ich glaub aber das steht auch so im wiki. Die sv (ws) treiber sind untereinander austauschbar.
vg
jörg
Ja, klappt schon. Ich habe die Temperatur von einem Kellerraum in SV. Coole Sache.
Du hast das prinzip also schnell inhaliert :D Freut mich das es läuft. Editor ist ok ? (dropdown etc)
Ja, ist geil, ich müsste eigentlich auch schlafen gehen - stattdessen bau ich mir das iphone interface für fernzugriff. .... herrjeh. (access geht saugeil über vpn 8)).
vg
jörg
Das ist so spannend, da bekomme ich kein Auge zu ;D ;D
Ein Punkt gibt mir aber zu denken: die GAD werden ja pro device=IP=Rechner definiert, das müsste man ja dann für drei Rechner drei mal machen.
Wäre es denkbar, anstatt einer IP ein Subnet zu definieren?
weiß nicht ob Du das schon machst und kennst: schalt den cache ab (config sv) während Du änderst, uu auch mal in smartVISU/temp/ alles löschen
Zitat von: HCS am 24 Dezember 2014, 01:36:16
Das ist so spannend, da bekomme ich kein Auge zu ;D ;D
Ein Punkt gibt mir aber zu denken: die GAD werden ja pro device=IP=Rechner definiert, das müsste man ja dann für drei Rechner drei mal machen.
Wäre es denkbar, anstatt einer IP ein Subnet zu definieren?
ne, die gads werden global definiert (wegen genau was Du sagst :))
unter fhem/www/fronthem/clients/ .... liegt die cfg die den zugriff regelt. Wenn Du einen fertig hast kannste die zum nächsten kopieren. Ich bau noch was das man das beim define schon angeben kann - kannst aber händisch kopieren
soweit so geil, morgen ist auch noch ein tag ...
OK, gerade verstanden. Die fhserver.fronthem.cfg definiert die GADs und für jeden Client wird in der jeweiligen fhclient.xxx.cfg die Berechtigung gesetzt.
Wenn ich mal geschaut hätte, was es in www\fronthem\ so gibt, dann hätte es mir ja auffallen können. Hatte den Editor falsch interpretiert.
Kannst aber trotzdem mal überlegen, ob bei der Definition vom fronthemDevice ein 192.168.xxx.0 denkbar wäre, so dass man mit jeder beliebigen IP von diesem Subnet drauf kommt.
Dieser Wunsch soll nun aber als solcher gesehen werden, das Ganze ist generell erst mal super und ich zwinge mich jetzt ins Bett ;)
Als Fan de ersten Stunde freut mich das total wie schnell es gegangen ist und ich muss mir wohl in den familienurlaub einen rpi und ein fhembackup mitnehmen ;)
Ich freue mich schon, mich gleich mal an der Beta zu probieren.
Für alle, die die Homematic HM-TC oder HM-CC oder HM-BL einsetzen: ich habe (ebenfalls Beta) ein Homematic Widget Katalog gebastelt. Wird mit
{% import "widget_homematic.html" as homematic %}
in den Raum eingebunden, in dem Ihr ein Gerät benutzen wollt. Die angehängte Datei muss dazu in Euer Verzeichnis in .../pages/ und muss Rechte für www-data erhalten. (Chmod 755 widget_homematic.html)
Bisher könnt Ihr folgende Geräte nutzen:
HM-TC Wandthermostat und HM-CC Heizkörperthermostat
Kopiert diesen Code in eine Smartvisu Seite:
{{ homematic.hmtc('HMTC_EG', 'mode', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_controlmode', 'WZ_rtr_daytemp', 'WZ_rtr_nighttemp', 'WZ.fenster', 'WZ_rtr_battery', 'WZ_rtr_state', 'WZ_rtr_text') }}
Und stellt auf der fhem Seite bei Eurem fronthemDevice folgendes ein:
GAD Editor
WZ_rtr_act
mode item
device Mein HM-TC fhem-Wandthermostat, Kanal Temperatur
reading measured-temp
converter NumDisplay
cmd set
WZ_rtr_battery
mode item
device Mein HM-TC fhem-Wandthermostat, Hauptgerät
reading batteryLevel
converter NumDisplay
cmd set
WZ_rtr_controlmode
mode item
device Mein HM-TC fhem-Wandthermostat, Kanal Temperatur
reading controlMode
converter Direct
cmd set controlMode
WZ_rtr_set
mode item
device Mein HM-TC fhem-Wandthermostat, Kanal Temperatur
reading desired-temp
converter NumDirect 5, 30
cmd set desired-temp
WZ_rtr_text
mode item
device Mein HM-TC fhem-Wandthermostat, Kanal Temperatur
reading boostTime
converter Direct
cmd set
WZ_rtr_state
mode item
device Der mit dem TC fhem-Wandthermostat Kanal Switch (07) gepeerte Switch
reading state
converter OnOff
cmd set state
(Hinweis: der Betrieb ist für eine Fußbodenheizung ausgeführt, daher kommt state vom Gerät, das mit dem Switch-Kanal gepeert ist. Bei der Steuerung von Heizkörperthermostaten ist das sicher anders...)
HM-BL Rolladenschalter für Markenschalter
{{ homematic.hmbl('Roll_Terrasse','', 'T_blind_mov','T_blind_stop','T_blind_pos','','',0,100,5) }}
GAD Editor:
T_blind_mov
mode item
device Mein HM-BL fhem-Rolladenschalter
reading state
converter direct
cmd set state
T_blind_pos
mode item
device Mein HM-BL fhem-Rolladenschalter
reading level
converter NumDirect
cmd set pct
T_blind_stop
mode item
device Mein HM-BL fhem-Rolladenschalter
reading state
converter Direct
cmd set state
Ich habe meine Seiten mal auf GitHub gestellt: https://github.com/bgewehr/smartVISU
Hallo,
wollte es auch gerade testen. Habe vorher nochmal FHEM auf den aktuellen Stand gebracht. Aber wenn ich das fronthem defninieren möchte, erhalte ich folgende Fehlermeldung im Log:
2014.12.24 12:26:51 1: reload: Error:Modul 01_fronthem deactivated:
Type of arg 1 to keys must be hash (not hash element) at /usr/share/fhem/FHEM/01_fronthem.pm line 256, near "})
"
Dadurch wird das Modul dann deaktiviert.
In der FHEM Config habe ich es wie folgt definiert:
define fronthem fronthem
Gruß
Gregor
Zitat von: bgewehr am 24 Dezember 2014, 12:28:33
Für alle, die die Homematic HM-TC oder HM-CC oder HM-BL einsetzen: ich habe (ebenfalls Beta) ein Homematic Widget Katalog gebastelt. Wird mit
Und ich habe gerade begonnen, ein Widget für die LaCrosse Sensoren (TX29... und Ähnliche) zu basteln.
Da aber auch noch eine Menge Kugeln am Tannenbaum instaziiert werden müssen, wird es noch etwas dauern. So rudimentär funktioniert es schon mal.
So das eine oder andere Problemchen habe ich aber noch: Die Werte in SV aktualisiern nur bei einem F5 und beim F5 bekomme ich immer kurz (für knapp eine Sekunde) das "Error-Dreieck" rechts oben. Nadem ich es endlich mal erwischt habe konnte ich kurz die Meldung sehen: "Clould not connect to DomotiGa server!"
Die Werte sind dann aber da und der Zugriff wurde auch auf der debian Konsole rausgeloggt.
Der Tip mit dem temp-Verzeichnis war übrigens gut. Nach einigen Umbauarbeiten bekam ich nach dem Einschalten des Pagecache erst nach dem Löschen der temp Files die aktuelle Version der Seite zu sehen.
Hi,
sollten wir übermorgen klären, wenn es sich nicht evtl. dann schon erledigt hat.
Tip ins Blaue: Probleme mit dem perl json modul.
schönes Fest
vg
jörg
Zitat von: HCS am 24 Dezember 2014, 13:29:12
Und ich habe gerade begonnen, ein Widget für die LaCrosse Sensoren (TX29... und Ähnliche) zu basteln.
Da aber auch noch eine Menge Kugeln am Tannenbaum instaziiert werden müssen, wird es noch etwas dauern. So rudimentär funktioniert es schon mal.
So das eine oder andere Problemchen habe ich aber noch: Die Werte in SV aktualisiern nur bei einem F5 und beim F5 bekomme ich immer kurz (für knapp eine Sekunde) das "Error-Dreieck" rechts oben. Nadem ich es endlich mal erwischt habe konnte ich kurz die Meldung sehen: "Clould not connect to DomotiGa server!"
Die Werte sind dann aber da und der Zugriff wurde auch auf der debian Konsole rausgeloggt.
Der Tip mit dem temp-Verzeichnis war übrigens gut. Nach einigen Umbauarbeiten bekam ich nach dem Einschalten des Pagecache erst nach dem Löschen der temp Files die aktuelle Version der Seite zu sehen.
geht bei mir ohne f5 und - allerdings garantiere ich hiermit auch das es in dem ersten Wurf garantiert bugs gibt :D Die nächste Zeit werde ich mit drögem debuggen verbringen .... :-\ also ab über/über morgen 8)
schönes fest
vg
jörg
Zitat von: herrmannj am 24 Dezember 2014, 13:33:02
... allerdings garantiere ich hiermit auch das es in dem ersten Wurf garantiert bugs gibt
Das erwartet man ja auch von einer BETA ;D
Ich spiele und bastle noch ein wenig dran rum, dann sehen wir weiter. Hat ja auch keine Eile.
Am Widget kann ich auch so weiter machen.
Die Werte in SV aktualisieren nun auch ohne F5.
Ich trau mich kaum zu schreiben, woran das lag. Ich hatte mit Readings getestet, die keine Events generieren. War mir ganz entfallen, dass ich die unterdrückt hatte :-[
Das Widget für die LaCrosse Sensoren funktioniert nun auch rudimentär. Auf der Hardcopy sitzt es vier mal in einem Block und zeigt Temperatur, Feuchte und Batterie-Status.
Frohes Fest
Hallo,
ich bin von diesem Projekt sehr begeistert und habe natürlich auch gleich versucht, smartVISU ans Laufen zu bekommen. Ich bin nach dieser Anleitung vorgegangen: http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117 (http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117)
Ich möchte SV auf meinem FHEM Raspberry (mit wheezy) neben dem Hauptsystem installieren.
Bei der Nachinstallation der diversen perl-Module kamen teilweise Meldungen wie
$ sudo cpanm strict
skipping R/RJ/RJBS/perl-5.20.0.tar.gz
Daher weiß ich als Nicht-Experte leider nicht, ob es funktioniert hat. Muss ich perl aktualisieren? sudo update usw. habe ich gemacht.
lighttpd habe ich installiert, ebenso smartVISU. Räume anlegen klappt und die config.ini habe ich denke ich auch richtig angepasst.
Die FHEM Dateien habe ich an die richtige Stelle kopiert und fronthem sowie ein device in FHEM definiert.
Was mir aufgefallen ist:
Im FHEM log finde ich folgenden Fehler:
22:36:46.562 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246
22:36:46.569 2: fronthem: ipc listener opened at port 16384
22:36:47.614 3: start forked ws: ws:9805
22:36:47.921 1: fronthem_PC: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/31_fronthemDevice.pm line 453
Wenn ich in FHEM auf das device gehe, kann ich keine Lampe o. ä. auswählen. Die Tabelle ist vorhanden, aber leer.
Hat jemand zufällig eine Idee, was ich ändern muss, damit die Verbindung zu FHEM funktioniert?
Vielen Dank!
schöne Grüße
Jo
Tritt der Fehler auch mit der original Config.ini auf? Wenn nicht, musst Du noch mal genau prüfen, ob Du die Syntax wirklich richtig eingehalten hast.
Meinst Du die originale aus dem thread hier? Da muss ich doch zumindest die IP Adressen ändern.
schöne Grüße
Jo
@Jojo11
Du kannst auch mal deine Posten, dann kann ich/wir sie ansehen auf Fehler.
Lg,
Tropaion
Hallo zusammen,
die Fehler, sowohl von Gregor als auch von Jo, "sollte" es eigentlich nicht geben - beide haben im erweiterten Sinn etwas mit dem laden der cfg zu tun. Da die beim ersten Start nicht vorhanden ist wird sie vom modul erzeugt. In der Theorie darf da also eigentlich kein Müll drinstehen.
Daher tippe ich mal auch Fehler bei der Nachinstallation der perl module oder vielleicht ein Berechtigunsgproblem in den Ordnern wo die cfg liegt, mit den Infos läßt sich aber kaum arbeiten.
Die Installation von "strict" etc wird eigentlich nicht benötigt. Auf einem normalen perl (und wo anders würde ich fronthem auch nicht installieren, sorry fritzbox, sorry nas ...) braucht man wirklich nur die beiden perl module (JSON und Websocket::Server..) aus dem ersten Post.
Die cfg wird unter fhem/www/frontend/fronthem ... gespeichert, postet doch bitte mal den Inhalt dieser Verzeichnisse und deren Berechtigungen.
vg
Jörg
Hallo, bin erst am Samstag wieder daheim und werde dann die cfg posten.
so,
zwischen Pute und Raclett (boah, kann ich echt noch mehr essen ???) hab ich mir gerade mal die screenshots von HCS angeschaut (ola :) )
Eine gute Inspiration sind da die Demohäuser, ein Tip dazu: wer da rein schaut sollte vorher den driver auf offline schalten weil sich sonst fronthem die cfg der Demohäuser merkt. Kann man zwar löschen, sind aber 2 clicks 50 ;)
Die machen das an solchen Stellen immer ganz pragmatisch mit <table><tr><td> .. so das kaum Aufwand entsteht. Für die Batterie Anzeige könnte man auch die Icons in diversen Spielarten einsetzen. Über basic.symbol (http://www.smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.symbol) könnte man ok und low jeweils mit einem eigenen Symbol verknüpfen (converter: Direct). Genauso könnt man auch nur die schlechten Batterien anzeigen. Für HM Device welche die voltage melden wäre es auch möglich (noch über Umweg) via "Dynamic Icons" eine echte Batteriestandanzeige darzustellen (http://www.smartvisu.de/docu/2.7/index.php?page=design/design_icons). Umweg deshalb weil die dynamischen Icons nur einen festen Wertebereich können (0..255). Ich gehe dazu für Windsack und Windrose derzeit über ein userReading (funktioniert). Da wird es in Kürze aber auch einen passenden converter geben der das komfortabel umrechnen kann.
btw: Batterie low (und andere) Meldungen: oben rechts, die "rote Ecke" wo jetzt nach stand-by die driver meldung auftaucht: das ist ein vollwertiger Dialog (mit info: grün, warn:gelb und error: rot) den ich in Zukunft auch über fhem zugänglich mache. Dann wird es möglich sein solche Meldungen auch persistent von sv anzeigen zu lassen.
btw2: driver Error nach stand-by: die ganzen sv driver können (warum auch immer) kein re-connect nach einem stand-by (vom Tablett, Handy, Rechner). Das nervt mich - da gehe ich in kürze bei. Ich habe mich auch lange gewundert warum die templates beim page reload einen kompletten reload machen anstatt über ajax-load zu gehen, ich vermute mal das ist der Grund.
Für eine wvc Integration ist das aber doof weil es tts oder Musikausgabe unterbricht, das wird sich mit driver dann erledigen. Die entsprechende Anpassung für das ajax load ist ganz leicht: in base (oder den eigenen Seiten), im room_menu findet sich vor den links ein data-ajax = false, der muss auf true geändert werden. Funktioniert perfekt
Was mich freut ist das sofort widgets erstellt werden (@Bernd: HM rtr: TOP!). Hier sollten wir vielleicht überlegen die in ein gemeinsames git zu legen. Bernd hat ja schon eins angelegt, vielleicht ist Rudi auch damit einverstanden das wir das im sf mit unterbringen.
Was meint ihr ?
vg
Jörg
Die Batterie funktioniert auch zwischen den gewünschten Werten 2.2 und 2.9, wenn man den Fehler im basic.shifter behebt, der leider vergisst min und Max an basic.icon weiterzugeben, habe ich unter Code.google.com/smartvisu schon als Issue gemeldet...
Zitat von: herrmannj am 25 Dezember 2014, 15:16:32
Hallo zusammen,
die Fehler, sowohl von Gregor als auch von Jo, "sollte" es eigentlich nicht geben - beide haben im erweiterten Sinn etwas mit dem laden der cfg zu tun. Da die beim ersten Start nicht vorhanden ist wird sie vom modul erzeugt. In der Theorie darf da also eigentlich kein Müll drinstehen.
Daher tippe ich mal auch Fehler bei der Nachinstallation der perl module oder vielleicht ein Berechtigunsgproblem in den Ordnern wo die cfg liegt, mit den Infos läßt sich aber kaum arbeiten.
Die Installation von "strict" etc wird eigentlich nicht benötigt. Auf einem normalen perl (und wo anders würde ich fronthem auch nicht installieren, sorry fritzbox, sorry nas ...) braucht man wirklich nur die beiden perl module (JSON und Websocket::Server..) aus dem ersten Post.
Die cfg wird unter fhem/www/frontend/fronthem ... gespeichert, postet doch bitte mal den Inhalt dieser Verzeichnisse und deren Berechtigungen.
vg
Jörg
Hallo Jörg,
vielen Dank für die Rückmeldung. Es scheint so, als würde im Ordner fhem/www/frontend beim ersten Start gar nichts angelegt werden (auch nicht unter fhem/www/). Der Ordner fronthem fehlt und somit auch die cfg.
Der Nutzer auf dem Raspberry ist "pi", der komplette fhem-Ordner gehört fhem:root (also alles eigentlich normal nach Anleitung) und hat die Berechtigungen drwxrwxrwx, was wahrscheinlich übertrieben ist.
01_fronthem.pm, 31_fronthemDevice.pm und fhconverter.pm liegen in fhem/FHEM mit den gleichen Berechtigungen.
Die SV config.ini habe ich zunächst so gelassen und später abgeändert, was aber nicht geholfen hat (nur ein client mit entsprechender IP sowie driver_address angepasst mit der IP des pi).
Irgendwie komme ich nicht weiter :-\
schöne Grüße
Jo
Zitat von: bgewehr am 25 Dezember 2014, 19:40:34
Die Batterie funktioniert auch zwischen den gewünschten Werten 2.2 und 2.9, wenn man den Fehler im basic.shifter behebt, der leider vergisst min und Max an basic.icon weiterzugeben, habe ich unter Code.google.com/smartvisu schon als Issue gemeldet...
Hallo Bernd,
stimmt, Du hattest das erwähnt. Ist eigentlich der bessere Weg das an der Wurzel zu packen. Den converter hatte ich so geplant das man min und max angibt und der das auf 0 .. 255 umsetzt. Hätte das dann irgendeinen Vorteil ? (Wenn ich Dich richtig verstehe: nö.)
Magst Du (hattest Du schon?) den geänderten code posten, würde ich gern übernehmen.
Danke und Grüße
Jörg
Zitat von: Jojo11 am 25 Dezember 2014, 19:42:47
vielen Dank für die Rückmeldung. Es scheint so, als würde im Ordner fhem/www/frontend beim ersten Start gar nichts angelegt werden (auch nicht unter fhem/www/). Der Ordner fronthem fehlt und somit auch die cfg.
Hi Jo,
ja - passt. Die cfg wird erst intern angelegt und beim speichern auf platte gebracht. Das isses also nich ...
Zitat
Die SV config.ini habe ich zunächst so gelassen und später abgeändert, was aber nicht geholfen hat (nur ein client mit entsprechender IP sowie driver_address angepasst mit der IP des pi).
passt, für das beschriebene Problem auch ohne Bedeutung.
Sach ma bitte, wie ist Deine Umgebung. Welcher Host (pi?), welches OS, welches perl. Sind die beiden perl module sicher (und als root) installiert ?
vg
jörg
Hallo Jo,
weisste was:
ZitatWenn ich in FHEM auf das device gehe, kann ich keine Lampe o. ä. auswählen. Die Tabelle ist vorhanden, aber leer.
Schick mal bitte einen screenshot von der leeren Tabelle. Ich hab gerade mal im quellcode geschaut, vmtl ist das alles biss dahin korrekt. Die cfg ist leer, ergo die msg bzgl JSON empty - das passt.
Du hast eher ein Problem bei der Verbindung von sv zu fhem. Wie ist fronthemDevice genau definiert, mach mal ein list bei stehender Verbindung (oder bei soll-stehender ... :) )
vg
jörg
Sehr gut, dann liegt es wohl doch an der fehlenden Verbindung. Komme leider erst übermorgen wieder an den Rechner. Werde dann mal weiter berichten. Habe ein aktuelles wheezy auf dem pi und ein aktuelles fhem. Perl muss ich überprüfen.
schöne Grüße
Jo
bekomme beim Einbinden diesen Fehler:
2014.12.26 09:45:12 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246
2014.12.26 09:45:12 2: fronthem: ipc listener opened at port 16384
2014.12.26 09:45:13 3: start forked ws: ws:27843
2014.12.26 09:45:14 3: ipc fronthem:127.0.0.1:49057 (ws): ws alive with pid 27843
2014.12.26 09:51:29 1: cubie: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/31_fronthemDevice.pm line 453
$VAR1 = {
'cmd' => 'gadList'
};
$VAR1 = {
'cmd' => 'gadList'
};
$VAR1 = {
'cmd' => 'gadList'
};
Hier mal das einbinden:
eingebunden habe ich so:
define fronthem fronthem
define cubie fronthemDevice 192.168.178.155
Hi,
das ist vmtl kein Fehler - sondern erster Start. (oder ?) :
... at character offset 0 ...
Da ist die cfg leer und JSON meckert. Da ist aber eine eval drum, die Meldung die rauskommt passt. Das da drunter ist noch debug - output.
Wenn Du jetzt von 192.168.178.155 aus zugreifst und in der sv oberfläche den driver auf <ip_von_fhem> 2121 konfigurierst wird es laufen.
vg
Jörg
Hallo,
erst mal ein großes Kompliment an die Entwickler und Unterstützer. Tolle Arbeit.
Vielleicht sollte man dabeischreiben, dass man mit
define <device> fronthemDevice <ip>
nicht den Server für Smartvisu definiert, sonder die Ip des Gerätes, welches auf den SV zugreift (also das Tablet, Rechner, Smartphone etc.).
Das hatte ich falsch verstanden.
@bgewehr: Die Homematik-Anpassung ist wirklich gut, ich habe für mein Verständnis allerdings aus dem Slider für die Homematik-Rolladenaktoren den Typ bottomup gemacht, das spiegelt die Rolladen besser wieder (meine Meinung):
{{ basic.slider(id~'pos', gad_pos, min, max, step, 'bottomup') }}
Schöne Rest-Weihnacht
Kai
Hallo @all,
ich würde gern noch wissen ob es Probleme im Zusammenspiel mit dem dashboard (in Bezig auf jquery) gibt. Hat jemand beides am laufen ?
vg
Jörg
manchmal dauerts ;D
Jetzt hab ich das mit den dyn icons geschnallt.
@Bernd: Du hast Dir den shifter vorgenommen - richtig (?).
Was total crazy ist, beim shifter sind min/max dokumentiert (funktionieren aber nicht). Bei den dynamischen svg sind min, max nicht dokumentiert (aber funktionieren 8) ).
Daher kann man sich echt bei den svg sowohl die userReadings als auch den converter sparen. Der screenshot im Anhang ist dieser code
<p>Wetter aktuell</p>
<table>
<tr>
<td> {{ icon.windrose('garden.icon.wind.actual', '', 'garden.wind.actual', 0, 360) }}</td><td> Wind aus {{ basic.value('garden.wind.actual', 'garden.wind.actual', '°') }} </td>
<td> {{ icon.windsock('garden.icon.wind.speed', '', 'garden.wind.speed', 0, 5) }}</td><td> speed {{ basic.formula('garden.wind.speed', 'garden.wind.speed', 'km/H', 'VAR * 10') }} </br> böen {{ basic.formula('garden.wind.max', 'garden.wind.max', 'km/H', 'VAR * 10') }} </td>
<td> {{ icon.graph('garden.icon.wind.max', '', 'garden.wind.max', 0, 3) }}</td>
</tr>
</table>
Dahinter hängt ein WGR800 mit NumDisplay. Sogar das x 10 (braucht man beim WGR800, anders als beim WGRT ...) geht mit basic.formula.
Rechts neben dem Wind ist ein graph der den Verlauf der böen anzeigt, alles ganz ohne userReadings :D. Nicht meckern, ich weiß, graphisch geht das noch schöner, ist ja nur Test.
@Bernd: ist in Deinem git der shifter schon aktualisiert ?
vg
Jörg
ok,
ich glaube das war von mir falsch verstanden.
Habe auf einem Cubie FHEM laufen(.155) und auf einem PI (.22) SV.
Wie kann ich diese jetzt kombinieren?
sobald ich auf FHEM
define fronthem fronthem
das mache bricht fhem zusammen und ist nicht mehr erreichbar.
im Log sehe ich nichts
nach einem reboot des Cubie, ist alles wieder da, jedoch kein fronthem modul
Hallo Zusammen,
Zitatok,
ich glaube das war von mir falsch verstanden.
Habe auf einem Cubie FHEM laufen(.155) und auf einem PI (.22) SV.
Wie kann ich diese jetzt kombinieren?
sobald ich auf FHEM
Code: [Auswählen]
define fronthem fronthem
das mache bricht fhem zusammen und ist nicht mehr erreichbar.
im Log sehe ich nichts
nach einem reboot des Cubie, ist alles wieder da, jedoch kein fronthem modul
genau den selben Fehler habe ich im Moment auch und habe noch keine Idee, an was es liegen kann.
viele Grüße
Alexander
Ich glaube, wir haben alle den gleichen Fehler bzw die gleiche Fehlbedienung. Die Beschreibungen kommen mir sehr bekannt vor.
schöne Grüße
Jo
ist der erste Wurf, da können schon Konstellation auftauchen die es in der alpha nicht gab, aber ihr müsst suchen.
Ohne Hinweise von Euch geht da nix, geht am besten so vor.
per ssh einloggen, fhem beenden und über die console als root starten. checkt vorher die beiden perl module aus dem ersten post. Wenn fhem über die console gestartet ist wird es fehlermeldungen geben, ihr müsst sie finden.
Wenn fhem nicht mehr reagiert, schaut mit "sudo ps aux | grep perl" wie viele Prozesse noch leben. Alterntiv fhem mit der demo cfg starten, fronthem server definieren, schauen was passiert (um andere module auszuschliessen).
@hyper: in Deinem log sehe ich den start von fronthem.
vg
jörg
Zitat von: Jojo11 am 26 Dezember 2014, 17:01:12
Ich glaube, wir haben alle den gleichen Fehler bzw die gleiche Fehlbedienung. Die Beschreibungen kommen mir sehr bekannt vor.
schöne Grüße
Jo
ich denke Du siehst den Editor aber ohne die sv Daten ?
vg
jörg
Hallo Zusammen,
ich habe mal ein bisschen ausprobiert. Wenn ich
Zitatdefine fronthem fronthem
in die Kommandozeile von FHEM eingebe, stürzt dieses ab, nichts neues. Wenn ich dann, wenn FHEM offline ist
Zitatdefine fronthem fronthem
manuell in die fhem.cfg eintrage, startet FHEM gar nicht mehr. Wenn ich das starten nun mal manuell über die Konsole teste, kommt nach ein paar Sekunden eine Fehlermeldung (siehe Anhang) und die Konsole schließt sich wieder.
Im Logfile von FHEM erscheint dann folgendes:
Zitat014.12.26 20:02:00 5: Loading ./FHEM/01_fronthem.pm
2014.12.26 20:02:00 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246.
Die zwei Perl Module JSON und Net::WebSocket::Server sind in dem entsprechenden Perlverzeichnis meines Servers vorhanden.
vielleicht hilft dies weiten und viele Grüße
Alexander
soso, windows.. irgendwann kommt alles ans Licht ;)
im Ernst, im context von fhem/perl hast Du einen Exoten. Das muss ich in Ruhe untersuchen zumal es sich um irgendeinen Sekundär Effekt handelt- Devio rufe ich nicht auf.
Es tut mir Leid, aber ich kann Dir hier keine kurzfristige Abhilfe anbieten. Ich hab auch keine konkrete Idee die Fehlermeldung betreffend. Sollte jemand anhand der Fehlermeldung die Lösung haben gerne her damit. Ein schnelles googeln sagt das es Windows spezifisch ist und mit Handles zu tun hat ...
vg
jörg
edith:
Devio.pm #261 hat was mit serial port zu tun, das passt zu http://www.perlmonks.org/?node_id=1084794
Dort wird vorgeschlagen strawberry perl in dieser Version " without USE_64_BIT_INT portable edition " zu testen. Was das (serial?) jetzt mit meinem modul zu tun haben soll erschließt sich mir nicht - but who knows ... Bitte teste das mit der vorgeschlagenen perl version.
edith2:
wie immer, viel Kompetenz hier im Forum: schau mal ob das Dir hilft
http://forum.fhem.de/index.php?topic=30692.0
Zitat von: herrmannj am 26 Dezember 2014, 17:05:50
ich denke Du siehst den Editor aber ohne die sv Daten ?
vg
jörg
Das ist richtig. Aber genau diese Fehlermeldungen sind auch im log. Sobald ich wieder am Rechner sitze gebe ich mal einen detaillierteren Bericht ab.
schöne Grüße
Jo
Zitat von: Jojo11 am 26 Dezember 2014, 22:14:35
Das ist richtig. Aber genau diese Fehlermeldungen sind auch im log. Sobald ich wieder am Rechner sitze gebe ich mal einen detaillierteren Bericht ab.
alles gut: das ist
keine Fehlermeldung, diese Meldung ist gaaanz normal beim ersten Start und da steht drin das eine nicht vorhandene config kein gültiger json Syntax ist ... was irgendwie Sinn macht ;)
Ich könnte mir vorstellen das Du entweder den driver in sv falsch eingestellt hast oder das fronthemDevice nicht mit der Adresse des Endgerätes konfiguriert. Lass uns morgen schauen - alles wird gut !
vg
jörg
Hallo,
ich habe gerade festgestellt, dass das Problem mit dem Win32-SerialPort doch nichts mit dem Modul zutun hat. Die Fehlermeldung kommt bei mir immer, es ist nur nie aufgefallen, weil ich FHEM in der Regel nicht über die Konsole starte. Somit kann dies schon einmal ausgeschlossen werden. Da ich momentan sowieso keine Devices über SerialPort mit FHEM verbunden habe, werde ich dies erst einmal hinten anstellen.
Ich vermute das mein Problem wahrscheinlich das gleiche ist, das hyper2910 auch hat. Eventuell hängt es auch wie bei Jojo11 an einem falsch eingestellten driver in sv.
Das werde ich dann morgen mal testen!
viele Grüße
Alexander
Hallo Alexander,
bei Jo ist (fast) alles gut, Editor läuft, fhem läuft - der Rest ist setup.
Du sagst das Dein fhem nicht mehr startet. Aufgrund Deines (nicht böse gemeint:) seltenen setups und der Komplexität im modul ist das möglich. Einige der verwendeten Techniken sind auf windows bestenfalls emuliert - getestet unter Windows wurde nichts, entwickelt ist auf linux. Wenn ich weiß woran ich drehen muss werde ich gern, wenn möglich, die notwendigen Sonderbehandlungen für windows einbauen. Ich kann da leider im Augenblick nicht viel für Dich tun.
Ehrliche Empfehlung von mir: solange Du da nicht selbst sehr sattelfest (Du musst selber Fehler-Meldungen suchen und sehr viel beim debuggen) bist, warte noch ab, so schade wie das ist.
sorry, vg
jörg
Zur Info, mein Fhem läuft nicht unter WIN, auch nicht Smartvisu.
Ich bediene die Oberfläche momentan aus Win, daran sollte es aber nicht liegen.
beim ersten mal hat er das Device geladen, dann habe ich ein noch ein normales Update gemacht und neugestartet und er hat das device auch geladen.
Ich habe noch kurz ein altes "Max!" Device manuell aus der fhem.cfg gelöscht und da ist mir aufgefallen, das ich dort nirgends das fronthem sehe.
Gespeichert und damit ist fhem abgestürzt.
Jetzt stürzt es nach jedem define fronthem ab.
Leider kann ich nicht viel testen, da meine komplette Heizung über das Ding läuft und wenn meine Frau kalt bekommt, ist die Stimmung auf dem Nullpunkt, der Frauenwohlfühlfaktor muss gegeben sein.
Hallo hyper,
Verstehe ich, wenn Du soweit bist sag Bescheid. Deinen letzten post kann ich nur entnehmen das Dein fronthem lief aber auch das Du das Device mit der IP .155 eingebunden hattest. Das ist Deinen post nach der fhem Host, da muss aber die IP des device rein was zugreift.
Abstürze gibt es aber deswegen nicht, die könnten jedoch durch manuelles Bearbeiten der fhem cfg entstehen wenn Du die Ladereihenfolge veränderst. Ein rename (das hat jetzt nichts mit Dir zu tun) bei laufendem Betrieb würde ebenfalls (böse) Auswirkungen haben.
Warum es bei Dir erst lief und jetzt nicht mehr kann ich Dir ohne weitere Fehlermeldungen allerdings nicht sagen.
vg
jörg
so,
habe alles nochmals gelöscht,
alles neugestartet, dann die Dateien wieder dahin wo sie hin sollen, allen Dateien alle Rechte gegeben und jetzt läuft es.
So jetzt muss ich mich nochmals mit SV befassen!
Ich bin weiter dran, neue Widgets zu bauen, die für fhem hilfreich sein können:
1. Textinput
2. Selectlist
3. FritzBox-bezogene Widgets
4. Homematic
Bitte gebt mir Eure Rückmeldung und weitere Vorschläge!
Moin,
habe heute versucht smartvisu zum laufen zu bekommen. Leider hänge ich aber schon bei den Perl Modulen
bei der Eingabe von
curl -L https://cpanmin.us | perl - --sudo App::cpanminus
bleibt der Raspberry bei
Building and testing ExtUtils-MakeMaker-7.04 ...
hängen.
bei den beiden anderen
sudo cpanm Net::WebSocket::Server
sudo cpanm JSON
kommt immer die Meldung
command not found
kann es sein das hier ein Schreibfehler ist
und das ganze
so aussehen müsste
sudo cpan Net::WebSocket::Server
sudo cpan JSON
Ich würde mich echt freuen wenn ihr mir helfen könnte.
Hallo zusammen,
erstmal vielen Dank für die super Arbeit.
Viele meiner Sachen laufen schon in SmartVisu ( Rollladen, Dachfenster, Licht, Garagentor, Temperatursensoren...)
Probleme/Fragen derzeit:
- Bei Betätigung eines Links in SV kommt kurz das Rote Error Dreieck. Meldung Keine Verbindung zum Domotiga Server.
Funktion ist aber sonst voll gegeben.
- Darstellung als Plot in SV. Es wird kein Gad das in einen Plot definiert ist in Fhem angezeigt. Ist dies generell schon möglich?
- Bei den Rollläden springt der Slider in SV. Hab gelesen es soll hierfür noch einen anderen Converter mal geben?
- Wie sieht die Anbindung (oder vielleicht geplante) mit dem Sonos-Widget aus?
vg
Florian
Zitat von: FlorianZ am 27 Dezember 2014, 19:53:29
- Bei Betätigung eines Links in SV kommt kurz das Rote Error Dreieck. Meldung Keine Verbindung zum Domotiga Server.
Funktion ist aber sonst voll gegeben.
Genau das habe ich auch, aber es funktioniert. Die Daten sind da. Seltsame Sache.
Zitat von: svenomatt am 27 Dezember 2014, 19:43:49
Moin,
habe heute versucht smartvisu zum laufen zu bekommen. Leider hänge ich aber schon bei den Perl Modulen
Hallo svenomatt,
da bin ich gestern auch hängen geblieben. Ich habe dann wie folgt installiert:
sudo apt-get install cpanminus
sudo apt-get install build-essential ==> sonst konnten die make's nicht ausgeführt werden
danach ging dann :
sudo cpanm Net::WebSocket::Server
sudo cpanm JSON
Ich bin Linuxmäßig eher wenig bewandert. Vielleicht hilfts.
Gruß Norbert
Erst einmal danke an alle beteiligten für die bisher geleistete Arbeit :)
Ich habe gerade alles installiert und Heizung eine sehr spartanische Sonos Steuerung klappen soweit ganz gut.
Bei meinen HUE Lampen klappt das Schalten und Dimmen hervorragend, nur beim setzen der Farbe über den RGBConverter komme ich gerade nicht weiter, ist der für das basic.rgb Widget gedacht ?
Hallo,
habe es auf gerade mit einem RaPi versucht, zum laufen zu bekommen. Leider stürzt FHEM ab, wenn ich ein
define fronthem fronthem
ausführe mit folgender Fehlermeldung:
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/01_fronthem.pm line 255.
Hi MartinMuc,
isser, Du musst für jedes GAD einen RGBCombined anlegen und hinter jeden die 3 RGB GAD in der Reihenfolge, RGB als param hängen.
Wenn es hängt, poste mal die GAD und die 3 converter Einstellungen.
Hi redlav,
saubere Lösung! Die module müssen natürlich nicht über cpanminus installiert werden, ist typischerweise aber einfacher. Ich würde es toll finden wenn Du Deine Erfahrung plus Lösung vielleicht mit im Wiki verewigen könntest. "Nachfolgende Generationen" habens dann leichter.
Hi Florian,
Rote Error : schreib ich gleich noch was zu.
Plot: kommen noch. Gibt sicher tausend Möglichkeiten wie man das "schnell" hinbekommt - ich will es, wie den Rest auch vor allem sauber. Wir in einem der kommenden release drin sein.
Rollläden: yepp, logisch, während Du den slider bewegst meldet der actor schon erste Bewegungen das ist unschön. Dafür ist ein Spezialconverter geplant, Geduld. Bernd hat das mit den HM widgets schon jetzt minimiert, vielleicht sagt er noch was dazu.
Sonos widget: haut in die Tasten Jungs: eines der Vorteile von sv ist ja das jeder (relativ einfach) widgets entwickeln kann. Ich freu mich schon auf einen regen Tauschhandel 8)
Erstes Fazit von mir: die Installation scheint ja überall zu funzen. Ausnahme Alexander auf dem windows-fhem (tut mir leid). Insgesamt ist der Schnitt scheinbar sehr gut, freut mich.
Eine Bitte nochmal: hat jemand das dashboard und fronthem installiert ? Da gab es Anfangs Stress mit dem jquery loader. Ich hoffe das gelöst zu haben, hätte aber gern eine Bestätigung.
Für mich persönlich sind die Tage nach der beta auch hochspannend gewesen, bis dahin war ich so mit dem backend beschäftigt das ich in sv kaum was gemacht habe. Jetzt, in den Weihnachtstagen habe ich auch begonnen einzurichten. Ich freue mich wie ein kleines Kind 8) - macht richtig Spaß.
Der NumDisplay converter hat einen kleinen bug, der verschluckt das minus. Da es außer mir keiner gemerkt hat gibts den erst beim nächsten update neu. (NumDirect funktioniert an der Stelle als Ersatz).
Die "rote Ecke": könnt die ganz entspannt sehen, alles richtig. Technisch (sind ja in der beta in der Erfahrenen-Runde): der dialog ist an das close-event vom ws gebunden. Wenn ihr jetzt einen reload oder einen page Wechsel macht wird die Verbindung sauber geschlossen (Seite zu ende), das führt über das close event - Dialog kurz da - neue Seite: Dialog wech ... alles richtig.
Die Implikation ist eher weitreichender: technisch ist es nämlich ... unklug ;) ... überhaupt beim laden einer neuen Seiten den Weg zu nehmen. Ich vermute das die sv Leute das gemacht haben weil die driver keinen automatischen re-connect können. Das bring ich dem domotiga driver bald bei (und dann ist es ein dedizierter fhem driver). Im Augenblick führt das noch dazu das nach einem sleep (vom nb, vom Tablett) die Verbindung nicht automatisch wieder hergestellt wird - erst nach einem reload steht die wieder.
Ich empfehle trotzdem jetzt schon folgendes zu machen: in den "room_menu" Seiten findet ihr vor den links zu den einzelnen Seiten einen Eintrag "data-ajax=false". Setzt den schon jetzt auf true. Dadurch wird beim Seitenwechsel die Seite per ajax-loader nachgeladen - und die scripte und der ws werden nicht mehr unterbrochen.
Ich möchte sv so schnell als möglich nativ wvc kompatibel machen, logisch Tabletts dürften die Hauptkonsumenten sein. Das würde zwar auch mit data-ajax=false gehen (flooplan und co können das auch nicht besser) - aber: mit dem ajax-loader läuft zu Beispiel Musik auf dem tab weiter auch wenn man die Seiten wechselt. TTS wird nicht unterbrochen .. etc. Also viel besser. :)
smartVisu nativ wvc kompatibel: hätte ich gern so das die wvc Funktionen (brigthness, play, tts, spracheingabe) als widget in sv nachgebaut werden (den code gibt es ja von Dirk als Vorlage). Sollte sich das jemand zutrauen und sich einbringen wollen: Hilfe gern gesehen :) (required skills: javascript, jquery)
So, die nächsten Tage wirds aber nichts neues geben, ich spiel mit sv. Als nächstes muss ich mir erst mal die ganzen neuen coolen widgets von Bernd anschauen 8)
vg
jörg
Zitat von: pole23 am 27 Dezember 2014, 23:00:13
Hallo,
habe es auf gerade mit einem RaPi versucht, zum laufen zu bekommen. Leider stürzt FHEM ab, wenn ich ein
define fronthem fronthem
ausführe mit folgender Fehlermeldung:
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/01_fronthem.pm line 255.
Während ich hier einen Roman poste sowas ... ;)
Lösch mal die fronthem ordner unterhalb von www.
Schau das die rechte auf www stimmen.
Checke das (100%!) json eingebunden und ok ist.
Danach erst mal nur fronthem (noch kein fronthem device) installieren.
Bis zu dem Punkt wo der Fehler bei Dir auftritt passiert im modul noch kaum was, die Fehler Meldung sagt das keine (oder eine defekte) fronthem cfg da ist, gleichzeitig konnte aber auch keine leere cfg (nur im Speicher) erzeugt werden. Einen Reim kann ich mir nicht drauf machen allerdings ist es recht sicher das es irgendeine spezielle Situation ist.
Bei hyper ging es acuh im zweiten Anlauf, check bitte nochmal die perl Module und die Rechte.
vg
jörg
Zitat von: herrmannj am 27 Dezember 2014, 23:11:14
Hi MartinMuc,
isser, Du musst für jedes GAD einen RGBCombined anlegen und hinter jeden die 3 RGB GAD in der Reihenfolge, RGB als param hängen.
Wenn es hängt, poste mal die GAD und die 3 converter Einstellungen.
Danke Jörg jetzt geht's, dann bau ich mir das ganze noch hübsch und schau das ich den RGB Wert noch In ein Userreading bekomme und dann hab ichs
Viele Grüße
Martin
ich hab keine hue - aber die haben doch ein rgb reading ? Normalerweise sollte das dann doch ohne userreading gehen - oder passt da was vom format nicht. Wenn ja kann ich vlt im converter was machen.
vg
jörg
Die haben ne RGB Methode die den Wert zurück gibt aber kein direktes Reading das ich auslesen kann, ich schau mir das aber Morgen mal an. Ich hab eh schon ein UserReading für On und Off für die Hues angelegt damit ich nicht an den Konvertern basteln musste ;)
verstehe. ich dachte das Andre mal irgendwo geschrieben hat er hätte sowohl "RGB" als auch "rgb". Das eine auf 100% luminaz, das andere der echte rgb.
btw CONVERTER: generell kann man eigene converter in die 99..er schreiben wenn man mag. die fhconverter.pm würde ich empfehlen dafür nicht anzupassen weil man sich updates verbaut.
Eigene converter in den 99er.pm müssen nur die gleiche Signatur haben und in dem gleichen namespace wie die im fhconverter.pm stehen dann werden die dynamisch geladen und stehen sofort in fronthem zur Verfügung.
Wenn ansonsten converter für Spezialaufgaben fehlen sagt gern Bescheid - ich bin da offen versuche die aber nach dem Prinzip "so wenig wie möglich, so viel wie nötig" zu bündeln.
vg
jörg
so,
habe mal ein vorgefertiges Layout von SV genommen.
Im FHEM sehe ich jetzt das Schlafzimmer und habe das soweit konfiguriert,
jedoch sehe ich die Temp nicht in Smartvisu
Ist ein MAX Heizventil!
kann ich nix zu sagen ohne das reading und das gad (bzw widget) genau zu kennen.
Ich würde aber ohnehin NumDirect oder NumDisplay als converter nehmen, da werden die Zahlen aus den reading rausgefiltert.
Ansonsten nochmal drauf achten das die entsprechenden events nicht unterdrückt sind (event-min und co), allerdings würdest Du dann bei f5 den neuen Wer sehen, nicht jedoch die Aktualisierung (push/pull).
edith:
read write haken musst Du auch setzen, und die IP vom fronthemDevice muss die IP von dem device sein was zugreift. (NB, tablett etc).
Am PC nur ein tab nehmen (sonst sieht fronthem mehrere device mit der gleichen IP zugreifen die sich gegenseitig ins Gehege kommen)
vg
jörg
Hallo Jörg,
Kombination Dashboard/fronthem
ich habe das Dashboard eingerichtet und nutze es auf dem Windows-Rechner, fronthem habe ich auf einem RasPi laufen (Vielen Dank für die erstklassige Arbeit!).
Mir ist an meinem Dashboard nichts außergewöhnliches aufgefallen, auf was soll ich achten bzw. wo hat es Probleme gegeben?
Grüße
Rainer
So, nachdem die Feiertage jetzt vorbei sind, komme ich mal wieder dazu, SV zu testen.
Folgendes habe ich gemacht, nachdem ich die fehlenden perl-Pakete installiert und die Dateien in die FHEM- bzw. SV-Verzeichnisse kopiert habe:
config.ini editiert:
[clients]
192.168.178.xx = 'Test'
(Das ist mein Rechner, von dem aus ich SV testen möchte.)
driver_address = '192.168.178.xx'
(Das ist der RPi, auf dem FHEM und SV laufen.)
Ganz unten in der config.ini habe ich die clients entsprechend entfernt/angepasst:
[client:Test]
title = 'Test'
cache = false
animation = true
driver_realtime = true
pages = 'docu'
Danach habe ich den lighttpd-Service gestartet.
SmartVISU ist daraufhin erreichbar und zeigt die ganze Palette an widgets auf der linken Seite.
Ober rechts ist die rote Ecke mit "Error" zu sehen.
Auf der Konfigurationsseite ist alles so eingetragen, wie ich es in der config.ini geändert habe.
Jetzt habe ich in fhem in der Kommandozeile fronthem definiert:
define fronthem fronthem
Und danach den Zugriffsrechner:
define fronthemTest fronthemDevice 192.168.178.xx
In SV ist daraufhin die rote Ecke oben rechts weg. In FHEM sehe ich eine leere Tabelle.
Dann in der SV Konfiguration/Interface "MeinHaus" ausgewählt, welches ich zuvor angelegt hatte. Klappt soweit. Die beiden Räume, die ich angelegt habe, werden angezeigt.
In FHEM zeigt fronthem immer noch den Status "???" an. Das Device ist connected.
Und siehe da, wenn ich auf das Device gehe, sehe ich die Leselampe in der Tabelle ;D
Keine Ahnung, warum das jetzt funktioniert, aber ich habe das Gefühl, dass die Reihenfolge bei der Einrichtung eine Rolle spielt.
Vielen Dank für Eure Geduld!
schöne Grüße
Jo
Hi,
ich versuche es auch gerade, aber ich bräuchte mal den genauen Pfad und die Berechtigung für den Ordner "fronthem".
Ich habe den in /opt/fhem/www erstellt und die Berechtigung auf fhem:root aber es wird nichts da drunter erstellt.
Die Berechtigungen der anderen Dateien wären auch mal gut, die habe ich gesetzt wie alles anderen in den jeweiligen Verzeichnisen.
MFG
P.S.: Ich nutze einen IntelNUC
Hallo,
diesen Ordner musst Du selber nicht anlegen. Er wird nach meinem Verständnis von dem Modul beim ersten Aufruf angelegt. Bei mir war er nicht vorhanden.
schöne Grüße
Jo
ich bekomme einfach keine Daten in SV rein.
habe das GAD definiert.
wie im Bild zu sehen
im Log von fhem sehe ich dieses:
2014.12.28 11:41:06 3: set Esszimmer ? : Unknown argument ?, choose one of wakeUp factoryReset groupid associate:Wohnzimmer,WZ_Terasse1,Schlafzimmer,WZ_Hofseite,MAX_04ee5b,Badezimmer,Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse,Fenster_FlurOben,Elch,SZ_Shutter1,Glicht,Kuechenfenster,Garage,Kueche,WZ_Shutter1,oelzaehler,Flur_Oben,fakeWallThermostat,fakeShutterContact deassociate:Wohnzimmer,WZ_Terasse1,Schlafzimmer,WZ_Hofseite,MAX_04ee5b,Badezimmer,Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse,Fenster_FlurOben,Elch,SZ_Shutter1,Glicht,Kuechenfenster,Garage,Kueche,WZ_Shutter1,oelzaehler,Flur_Oben,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 windowOpenDuration boostDuration:30,15,60,10,5,20,0,25 boostValveposition decalcification maxValveSetting valveOffset weekProfile
$VAR1 = {
'cmd' => 'gadItem',
'item' => 'EG.Esszimmer.temperature.stellgroesse'
};
$VAR1 = {
'cmd' => 'gadItemDeviceChanged',
'item' => 'EG.Esszimmer.temperature.stellgroesse',
'device' => 'Esszimmer'
};
device msgcnt
device TimeInformationHour
device mode
device valveposition
device measurementOffset
device state
device battery
device desiredTemperature
device groupid
device temperature
$VAR1 = {
'editor' => 'item',
'cmd' => 'gadItemSave',
'item' => 'EG.Esszimmer.temperature.stellgroesse',
'config' => {
'read' => '0',
'reading' => 'battery',
'type' => 'item',
'converter' => 'NumDisplay',
'device' => 'Esszimmer',
'write' => '0',
'set' => ''
}
};
aber irgendwie komme ich nicht weiter.
bei mir legt sich das Ver. anscheinend nicht an... :'(
und im SV bekomme ich immer ERROR obwohl der Port 2121 läuft und Treiber Domotiga ausgewählt ist.
Also bei mir funktioniert jetzt auch alles. Das Problem mit dem jquery loader scheint gelöst.
Gruß
Thorsten
Hallo zusammen,
wollte mich auch mal hier zu Wort melden. Erstmal danke an hermannj, fronthem ist echt ein tolles Projekt.
Ich konnte mit fronthem und smartVISU bereits eigene positive Erfahrungen machen. Ich kann via smartVISU bereits mein Heizungsthermostat und meine Funkschalter steuern.
Zwei Probleme habe ich noch:
Wenn ich von einem Gerät smartVISU aufrufe und dann meine Netzwerkverbindung trenne (z.B. WLAN abschalten) und wieder verbinde, kann smartVISU von keinem meiner Geräte mehr eine Verbindung zu fronthem aufbauen.
Nach einem Neustart des FHEM Servers funktioniert alles wie zuvor.
Das zweite Problem tritt nach Speichern der fhem.cfg über die FHEM Weboberfläche auf. Danach versucht FHEM die neue Config einzulesen und anzuwenden. Im Log erscheint dann die Fehlermeldung, dass der Telnet Port (Standard FHEM Port) bereits verwendet wird und der Start von FHEM wird abgebrochen. Startet man dann per Konsolen-Befehl neu, funktioniert der Start problemlos.
Grüße
Timo
Hallo,
da ich sehe, das es unter Windows doch immer schwerer mit FHEM wird, stelle ich jetzt, erst mal nur zu Testzwecken, auf Debian um. Dafür habe ich mir jetzt eine Virtuelle Maschine auf meinem Windows Server installiert und werde schauen, ob dann alles Problemfrei funktioniert. Sollte dies der Fall sein, werde ich FHEM dauerhaft dann auf Debian umstellen, da ich dann ja auch nicht mehr Hardware am laufen, als vorher, wo FHEM direkt auf Windows lief.
Werde meine Erfahrungen dann mit fronthem und sv mitteilen.
viele Grüße
Alexander
@hyper: Bist Du sicher dass du unter dem device auf save gedrückt hast? Den Fehler hatte ich auch schon mal.
schöne Grüße
Jo
@Jojo11, ja, bin ich mir, wenn ich das device anklicke, habe ich auch alle Infos dazu
Zitat von: ergerd am 28 Dezember 2014, 08:25:08
Hallo Jörg,
Kombination Dashboard/fronthem
ich habe das Dashboard eingerichtet und nutze es auf dem Windows-Rechner, fronthem habe ich auf einem RasPi laufen (Vielen Dank für die erstklassige Arbeit!).
Mir ist an meinem Dashboard nichts außergewöhnliches aufgefallen, auf was soll ich achten bzw. wo hat es Probleme gegeben?
Grüße
Rainer
Hallo Rainer,
super, dann ist alles roger. (Symptom war: fronthem Editor lief nicht wenn dashboard als modul in fhem eingebunden ist weil dashboard dann die jquery instanz überschrieben hat. Paaasst 8) DANKE! )
vg
Jörg
Zitat von: Jojo11 am 28 Dezember 2014, 10:13:16
Und danach den Zugriffsrechner:
define fronthemTest fronthemDevice 192.168.178.xx
...
In FHEM zeigt fronthem immer noch den Status "???" an. Das Device ist connected.
...
Keine Ahnung, warum das jetzt funktioniert, aber ich habe das Gefühl, dass die Reihenfolge bei der Einrichtung eine Rolle spielt.
...
Hi Jo,
perfekt. fronthem, Status ? ? ? ist richtig: das connected wird beim fronthemDevice angezeigt, bei der fronthem "Mutter" wird noch kein state gesetzt (da schreib ich vielleicht später irgendwas wie '3 clients connected, 1 rejected' oder so rein. Weiß noch nicht genau, muss ja auch Sinn machen)
Reihenfolge wird eine Rolle spielen. Erst sv, dann fronthem, dann fronthemDevice war meine Reiehenfolge. fronthem und tronthemDevice vertauscht wird nicht gehen.
In sv brauchen die clients übrigens nicht händisch ergänzt werden. Ich hab in die .ini oben so was wie autoadd = true|false eingebaut (bin mir nicht sicher wie der Schlüssel genau heist, sieht man aber). Wenn der auf true steht werden neue clients automatisch in sv angelegt und bekommen eine Kopie der default Einstellungen. Dann kann man über die cfg page die individuellen Settings über die sv Oberfläche speichern. Sind ja eigentlich nur page, design, evtl calender.
vg
jörg
Zitat von: thoweiss am 28 Dezember 2014, 11:59:27
Also bei mir funktioniert jetzt auch alles. Das Problem mit dem jquery loader scheint gelöst.
Gruß
Thorsten
Hi,
frohe (nach-) Weihnachten. Super.
vg
jörg
Hallo Timo,
willkommen im Forum ! :)
Zitat von: Tmelle am 28 Dezember 2014, 12:08:51
Wenn ich von einem Gerät smartVISU aufrufe und dann meine Netzwerkverbindung trenne (z.B. WLAN abschalten) und wieder verbinde, kann smartVISU von keinem meiner Geräte mehr eine Verbindung zu fronthem aufbauen.
Das musste mir bitte nochmal erklären. Du schaltest wlan komplett ab ? Am router ? fhem selber hat dann auch kein Netz mehr ? Oder nur client, (flugmodus). Generell kann sv noch keinen re-connect nach wlan weg - und man muss einen manuellen reload der Seite machen, das hab ich auf der Liste.
Zitat
Das zweite Problem tritt nach Speichern der fhem.cfg über die FHEM Weboberfläche auf. Danach versucht FHEM die neue Config einzulesen und anzuwenden. Im Log erscheint dann die Fehlermeldung, dass der Telnet Port (Standard FHEM Port) bereits verwendet wird und der Start von FHEM wird abgebrochen. Startet man dann per Konsolen-Befehl neu, funktioniert der Start problemlos.
Grüße
Timo
Das hat vmtl nix mit fronthem zu tun, macht fhem in diversen Situation. Ich weiß jetzt nicht wie sicher Du schon "fhem sprichst", wenn ja: fhem über die cmdline starten, "ps aux | grep perl" - alle fhem prozess id notieren (mit fronthem mindestens zwei) - dann in fhem "shutdown". Danach nochmal grep und schauen was da steht. Ansonsten wie gesagt macht fhem das in verschiedenen Konstellation.
vg
jörg
Zitat von: hyper2910 am 28 Dezember 2014, 11:47:08
ich bekomme einfach keine Daten in SV rein.
habe das GAD definiert.
wie im Bild zu sehen
im Log von fhem sehe ich dieses:
2014.12.28 11:41:06 3: set Esszimmer ? : Unknown argument ?, choose one of wakeUp factoryReset groupid associate:Wohnzimmer,WZ_Terasse1,Schlafzimmer,WZ_Hofseite,MAX_04ee5b,Badezimmer,Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse,Fenster_FlurOben,Elch,SZ_Shutter1,Glicht,Kuechenfenster,Garage,Kueche,WZ_Shutter1,oelzaehler,Flur_Oben,fakeWallThermostat,fakeShutterContact deassociate:Wohnzimmer,WZ_Terasse1,Schlafzimmer,WZ_Hofseite,MAX_04ee5b,Badezimmer,Flur_Unten,Esszimmer_WindowSensor,BZ_Fenster,WZ_Terasse,Fenster_FlurOben,Elch,SZ_Shutter1,Glicht,Kuechenfenster,Garage,Kueche,WZ_Shutter1,oelzaehler,Flur_Oben,fakeWallThermostat,fakeShutterContact desiredTemperature:eco,comfort,boost,auto,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on measurementOffset:-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5 windowOpenDuration boostDuration:30,15,60,10,5,20,0,25 boostValveposition decalcification maxValveSetting valveOffset weekProfile
$VAR1 = {
'cmd' => 'gadItem',
'item' => 'EG.Esszimmer.temperature.stellgroesse'
};
$VAR1 = {
'cmd' => 'gadItemDeviceChanged',
'item' => 'EG.Esszimmer.temperature.stellgroesse',
'device' => 'Esszimmer'
};
device msgcnt
device TimeInformationHour
device mode
device valveposition
device measurementOffset
device state
device battery
device desiredTemperature
device groupid
device temperature
$VAR1 = {
'editor' => 'item',
'cmd' => 'gadItemSave',
'item' => 'EG.Esszimmer.temperature.stellgroesse',
'config' => {
'read' => '0',
'reading' => 'battery',
'type' => 'item',
'converter' => 'NumDisplay',
'device' => 'Esszimmer',
'write' => '0',
'set' => ''
}
};
aber irgendwie komme ich nicht weiter.
Hallo hyper,
das log ist top, alles in Ordnung. Das sind alles debug - log von Editor, frronthem liest auch Deine sv Oberfläche. Der erste Eintrag im log lädt die 'set' von Esszimmer für das drop down im Editor - alles ganz perfekt.
Wenn ich helfen soll musst Du mehr Infos bringen, ich brauch den genauen Inhalt des Readings "temperature" mit allen Space, Sonderzeichen, ... und die Definition des widgets in sv wo die Temp hin soll. Mach Dir bitte eine leere Seite in sv wo nur dieses eine widget drin ist.
@allschöner (eigener) Fehler in SV ist es die ID des widgets (nicht das GAD, die ID!) doppelt zu vergeben, kannste ewig suchen warum sich nichts aktualisiert .... ( 8) fragt mal woher ich das weiß )
Außerdem bitte ein list mit (show hidden an, gern als text Anhang) auf sowohl von fronthem als auch dem fronthemDevice.
vg
jörg
Hallo,
habe jetzt nochmal alles runtergeworfen und nochmal neu gemacht. Jetzt kann ich meine ersten Lampen schalten:-)
cool 8)
Hast Du 'ne Idee warum es im ersten Wurf nicht lief die man an andere weitergeben kann ?
vg
Jörg
Hallo, davor war dort ein Fertiges Image vom Smarthome.py drauf, mit dem ich viel getestet hatte. Evtl lag es da dran. Er konnte immer die Config nicht lesen, obwohl die Rechte korrekt waren und er die Config auch anlegen konnte. Nachdem ich ein frisches Wheezy draufgemacht hatte, geht es jetzt.
Zitat von: herrmannj am 28 Dezember 2014, 13:47:29
Hallo Timo,
willkommen im Forum ! :)
Das musste mir bitte nochmal erklären. Du schaltest wlan komplett ab ? Am router ? fhem selber hat dann auch kein Netz mehr ? Oder nur client, (flugmodus). Generell kann sv noch keinen re-connect nach wlan weg - und man muss einen manuellen reload der Seite machen, das hab ich auf der Liste.
Das hat vmtl nix mit fronthem zu tun, macht fhem in diversen Situation. Ich weiß jetzt nicht wie sicher Du schon "fhem sprichst", wenn ja: fhem über die cmdline starten, "ps aux | grep perl" - alle fhem prozess id notieren (mit fronthem mindestens zwei) - dann in fhem "shutdown". Danach nochmal grep und schauen was da steht. Ansonsten wie gesagt macht fhem das in verschiedenen Konstellation.
vg
jörg
Hallo Jörg,
zu 1:
Ich deaktiviere das WLAN nur am Client:
- SV aufrufen
- WLan am Client abschalten (z.B. Flugmodus am iPhone), FHEM bleibt weiter im Netz
- Client wieder mit WLan verbinden
- Reload von SV
--> SV bekommt keine Verbindung mehr mit fronthem (Fehlermeldung in SV: Could not connect to DomotiGa server!)
Habe SV und FHEM auf einem Banana Pi laufen.
zu 2:
Ich habe mir die Geschichte gerade nochmal genauer angesehen:
- Die Prozesse werden wenn ich einen shutdown mache korrekt beendet. Danach sind keine fhem-Prozesse aktiv.
- Das Problem tritt also nicht bei einem normalen Shutdown auf.
- Das Problem tritt bisher nur beim speichern der fhem.cfg auf.
- Das Problem tritt bei nur auf wenn ich die Zeile "define fronthem fronthem" in meiner config habe.
Ich vermute es handelt sich hier um ein Timing-Problem. Evtl. ist der Shutdown noch nicht abgeschlossen wenn Fhem wieder versucht zu starten? Evtl dauert das beenden mit aktivem fronthem länger? Alles nur Mutmaßungen ;-).
Gruß
Timo
Hallo Jörg,
dickes Lob nochmal an Dich! Es funktioniert ziemlich vieles schon erstaunlich stabil und es macht richtig Laune, die Oberfläche anzupassen.
schöne Grüße
Jo
Zitat von: Jojo11 am 28 Dezember 2014, 16:32:26
Hallo Jörg,
dickes Lob nochmal an Dich! Es funktioniert ziemlich vieles schon erstaunlich stabil und es macht richtig Laune, die Oberfläche anzupassen.
schöne Grüße
Jo
Danke - war auch 'ne Menge Arbeit - hat sich jedoch gelohnt - macht mir auch sehr viel Spaß.
@Timo
Danke, (bitte nich per edit, hätte ich beinahe übersehen)
Zitat- Die Prozesse werden wenn ich einen shutdown mache korrekt beendet. Danach sind keine fhem-Prozesse aktiv.
- Das Problem tritt also nicht bei einem normalen Shutdown auf.
- Das Problem tritt bisher nur beim speichern der fhem.cfg auf.
- Das Problem tritt bei nur auf wenn ich die Zeile "define fronthem fronthem" in meiner config habe.
Ich beende den geforkten Prozess mit dem Papa, und hab auch eine Schutzschaltung drin falls Papa mal unverhofft ablebt. Kann aber wirklich, so wie Du vermutest, eine Frage des Timings sein.
Bei mir tritt das nicht auf aber ich schau mir das genauer an. Ich kann ja shutdown verzögern bis der fork Vollzug meldet.
vg
Jörg
@all
wenn Ihr screenshots oder codeschnipsel habt immer rein damit - das ist bestimmt eine schöne Inspiration und man kann best practice ja gut übernehmen.
vg
Jörg
Habe meinen ersten Fehler gerade noch einmal genauer angesehen.
Habe ein Logging eingebaut und festgestellt, dass in Zeile 437 von 01_fronthem.pl eine Exception auftritt:
Code: $hash->{helper}->{ipc}->{$connection}->{sock}->{TCPDev}->send(encode_json($msg)."\n", 0);
Exception: Cannot determine peer address at ./FHEM/01_fronthem.pm line 437
Nach dem ein Client "hart" getrennt wurde (z.B. durch Aktivierung des Flugmodus) geht anscheinend die Connection kaputt.
(Mein Gedanke: Socket auf fronthem Seite bleibt geöffnet und kriegt nicht mit das der Client nicht mehr lauscht und beim senden knallt es dann)
Hallo,
auch von mir nochmal großes Lob!!!Habe das Thema schon einige Woche beobachtet und mich zwischenzeitlich auch schonmal mit smartvisu auseinander gesetzt. Nach einigen Anlaufschwierigkeiten beim einbinden der Module funktioniert mittlerweile alles wunderbar. Einige Fragen hätte ich allerdings noch...
-Ist es jetzt schon möglich den FS20-Dimmer mit seinen tollen Dim-Steps :P vernünftig einzubinden oder ist das eventuell noch für zukünftige Versionen geplant?Zurzeit läuft er bei mir nur in 25%-Steps.
- Wenn ich ein nur ein reading von einem Device haben möchte, lasse ich im Gad-Editor das cmd-set Feld leer.Nach abspeichern taucht im log allerdings ein set XYZ(Device)....:Unknown argument ? auf.Diese Meldung kommt allerdings nur einmal und das reading wird auch ordnungsgemäß angezigt. Ist das normal?bzw mache ich was falsch?
-und meine letzte Frage:Wenn ich ein zusätliches fronthemDevice einrichte(z.B.) muss ich alle Gad's durchklicken, die Rechte neu setzen und speichern.Gibt es da vielleicht eine elegantere Lösung?
ansonsten bin ich top zufrieden.Endlich ein schönes Frontend :)Super Arbeit!!!
Gruß
Jakob
Hallo Jakob,
Zitat von: Gorbi am 28 Dezember 2014, 18:53:39
-Ist es jetzt schon möglich den FS20-Dimmer mit seinen tollen Dim-Steps :P vernünftig einzubinden oder ist das eventuell noch für zukünftige Versionen geplant?Zurzeit läuft er bei mir nur in 25%-Steps.
ne, dafür kommt noch ein extra converter. Die dimsteps sind doof, hatte das schon an den Rand der Wahrnehmung verdrängt :) kommt aber.
Zitat
- Wenn ich ein nur ein reading von einem Device haben möchte, lasse ich im Gad-Editor das cmd-set Feld leer.Nach abspeichern taucht im log allerdings ein set XYZ(Device)....:Unknown argument ? auf.Diese Meldung kommt allerdings nur einmal und das reading wird auch ordnungsgemäß angezigt. Ist das normal?bzw mache ich was falsch?
alles richtig. Der Editor fragt die sets für das dropdown beim device per "?" ab. Ich weiß gar nicht ob man das eleganter (also ohne Meldung im log) machen könnte ... ist aber kein Fehler oder so, fhem spuckt das auf die Frage nach den möglichen cmds so ins log.
Zitat
-und meine letzte Frage:Wenn ich ein zusätliches fronthemDevice einrichte(z.B.) muss ich alle Gad's durchklicken, die Rechte neu setzen und speichern.Gibt es da vielleicht eine elegantere Lösung?
Ja, musst Du. Da kommt aber noch was. Im Augenblick ist die Tabelle im Editor ja ein Überblick (mal f5 drücken zwischendurch dann sind oben die Pfeile für read und write drin). Zukünftig:
Variante #1: wäre das man bei der definition eines neuen device ein schon bestehendes angibt und die Berechtigungen von dem übernommen werden. (Das kannst Du jetzt auch schon händisch indem Du die *.cfg unter /www/fronthem/clients/... von device a auf b kopierst, den Namen anpasst und dann das device definierst)
Variante #2: wäre ein attrib "defaultAccess" welches man einfach auf "true" für ein device setzt. Dann würde das device gleich access auf alle items bekommen und die Rechte würden, für dieses device, erst gar nicht beachtet.
Vermutlich beides ..
Zitat
ansonsten bin ich top zufrieden.Endlich ein schönes Frontend :)Super Arbeit!!!
vielen Dank, das lob gehört aber auch den smartVISU Entwicklern - die Jungs haben da gute Ideen umgesetzt.
vg
jörg
Zitat von: Tmelle am 28 Dezember 2014, 17:58:00
Habe meinen ersten Fehler gerade noch einmal genauer angesehen.
Habe ein Logging eingebaut und festgestellt, dass in Zeile 437 von 01_fronthem.pl eine Exception auftritt:
Code: $hash->{helper}->{ipc}->{$connection}->{sock}->{TCPDev}->send(encode_json($msg)."\n", 0);
Exception: Cannot determine peer address at ./FHEM/01_fronthem.pm line 437
Nach dem ein Client "hart" getrennt wurde (z.B. durch Aktivierung des Flugmodus) geht anscheinend die Connection kaputt.
(Mein Gedanke: Socket auf fronthem Seite bleibt geöffnet und kriegt nicht mit das der Client nicht mehr lauscht und beim senden knallt es dann)
Hallo Timo,
das ist in der Tat ein interessantes Verhalten. Ich hab das explizit in den Tests drin - eben auch nochmal versucht. Bei mir kann ich das nicht nachstellen. Da Du ja (vielen Dank) sogar logging eingebaut hast kannst Du mir vmtl folgen.
Der Teil wo die Exception bei Dir auftritt ist der parent Teil, der hat keinen direkten Zugriff auf die Enddevice. Das was Du beschreibst deutet eigentlich an das der gesamte ws server (im fork) gestorben ist ..
Das gewünschte Verhalten ist:
Wenn der client sich verbindet geht der state (am fronthemClient) sofort auf "connected".
Am Iphone (IOS 6) eben nochmal getestet:
Seite geladen (browser oder homescreen), Seite in den Hintergrund (Homebutton): state geht sofort auf "disconnected".
Seite geladen, WLAN ausgeschaltet (slide von unten nach oben damit die Seite nicht "entladen" wird), state bleibt auf connected (das ist nach Plan, könnte ja auch eine kurze Unterbrechung sein). Der ws hat einen "heartbeat" (um router offen zu halten). Nach ca 15min schlägt der heartbeat zu und das device geht auf "disconnected".
Gibt es irgendwas ungewöhnliches an Deiner fhem-host Konfiguration ? (Ich versuche zu verstehen warum es bei Dir anders läuft)
Wenn Du ein list auf das fronthem mit "show hidden" on auff fronthem (die mutter nicht das device) machst sieht Du unter ipc folgende Einträge:
Ipc:
Ws:
name smartvisu:127.0.0.1:49789
pid 16109
Sock:
FD 12
NAME smartvisu:127.0.0.1:49789
TYPE fronthem
buffer
registered ws
Parent:
pid ist die pid des geforkten Prozesses (da kommen später noch wss und plots dazu).
Schau doch mal bitte ob der Prozess laut "ps aux" noch lebt wenn Du (nachdem Du) den Flugmodus aktivierst. Wahrscheinlich musst Du das einige Zeit beobachten, vmtl stirbt er erst wenn der heartbeat zuschlägt.
Ansonsten kann ich mir aktuell keinen Reim drauf machen und das auch nicht reproduzieren. Das würde ich aber (hier mit Deiner Hilfe) gerne jagen wollen, ein Absturz ist das nicht tolerierbar.
Ich habe im Vorwege ohnehin viele dieser Szenarien getestet, WLAN an / aus, bin mit dem Ipad aus dem WLAN gelaufen, und wieder zurück, VPN, on off - ich konnte da nix mehr entdecken. Aber wie immer, erstens anders: zweitens als man denkt.
Danke und vg
Jörg
Hallo,
eine kurze Rückmeldung: Es scheint so, als könnte NumDirect nicht ohne Weiteres negative Werte verarbeiten. Ich bastel gerade eine Temperaturanzeige mit LaCrosse-Sensoren und verwende das basic.value-Widget in Verbindung mit NumDirect. Bei Minusgraden wird das "-" nicht angezeigt, sondern nur der Betrag des Wertes (bei -2,5°C also 2,5°C). Mit dem Converter "Direct" funktioniert es.
schöne Grüße
Jo
mach ich heil - Danke :)
vg
jörg
Hallo Jörg !
Auch von mir erst mal ein ganz ganz großes Lob an Deine Entwicklerarbeit !
Ich habe FHEM, SV und den Rest soweit installiert ... nur habe ich eine Basis-Frage:
Muß ich in den SV Einstellungen unter I/O "Domotiga" oder "Json" auswählen ... ?
Bei mir schmiert FHEM übrigens auch immer ab, wenn ich das fronthem device in die fhem.cfg schreibe ... irgendeine Idee ?
Viele Grüße ak323
Zitat von: ak323 am 28 Dezember 2014, 20:47:40
[...]
Bei mir schmiert FHEM übrigens auch immer ab, wenn ich das fronthem device in die fhem.cfg schreibe ... irgendeine Idee ?
Viele Grüße ak323
Ja: Editiere nicht die fhem.cfg direkt, sondern gib mal
define <name> fronthem in die Kommandozeile in fhem ein (save nicht vergessen).
schöne Grüße
Jo
Hi,
zeig mal bitte die beiden define, welche Reihenfolge ? Schreibst Du (wörtlich) in die cfg oder gehst Du über die cmd line von fhem ?
In sv: I/O "Domotiga", ip vom fhem host und port 2121
vg
jörg
jo war schneller :)
Danke Euch !
Ich habe die fhem.cfg direkt editiert:
define fronthem fronthem
define Notebook fronthemDevice 192.168.2.106
Mit nur dem ersten Eintrag läuft fhem weiter, wenn ich den 2. eingefügt habe stürzt es ab ...
edit:
@jo: wenn ich es über die fhem Kommandozeile eingebe, dann stürzt fhem nicht ab .. !
@jörg: bzgl. SV IO hatte ich das auch so verstanden, dann bekomme ich aber die rote Ecke mit der Meldung, daß der Domotiga Server nicht erreichbar ist ... ?!? (läuft alles auf dem gleichen RPi).
ak323
ZitatIch habe die fhem.cfg direkt editiert:
mach nich..
probier mal ganz normal übers webif, so wie Jo sagt. Must aber erst in der cfg wieder heil machen.
Wenn das fronthem läuft geht die rote Ecke auch weg. Ich hab mal aus Versehen Komma statt Punkte in sv bei der IP eingegeben, das sieht man kaum. Hab 'ne Weile gesucht ... ;)
vg
jörg
Hallo,
hat zufällig schon jemand einen homematic Fensterkontakt erfolgreich eingebunden? Irgendwie will das nicht so ganz klappen ???
@ak323: Wenn Du die beiden define-Befehle über die kommandozeile eingibst, müsste es funktionieren.
schöne Grüße
Jo
Fensterkontakt läuft bei mir ohne Probleme mit dem Direct Converter. Man muss bei der Definition des Symbols die States des "Switches" mit angeben:
{{ basic.symbol('WZ.fensterauf', 'WZ.fenster', '', icon1~'fts_window_2w_open.png','open') }}
Dann geht's!
Sehr gut, danke!
schöne Grüße
Jo
Zitat von: Jojo11 am 28 Dezember 2014, 21:13:07
Hallo,
hat zufällig schon jemand einen homematic Fensterkontakt erfolgreich eingebunden? Irgendwie will das nicht so ganz klappen ???
@ak323: Wenn Du die beiden define-Befehle über die kommandozeile eingibst, müsste es funktionieren.
schöne Grüße
Jo
Jo/Jörg,
sorry muß revidieren: Geht auch nicht wenn ich die beiden Definifionen per Kommondozeile von fhem eingebe !
Bekomme auf dem RPi folgende Fehlermeldung:
pi@raspberrypi ~ $ $VAR1 = {
'cmd' => 'gadList'
};
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/31_fronthemDevice.pm line 112.Irgendeine weitere Idee ?
Hallo, wie sehen die Definitionen für WZ.fensterauf und WZ.fenster bei euch aus?
hallo,
benötigt man für das fronthemDevice zwingend eine feste ip für die clients, stichwort dhcp und leases <=24h ?
Zitat von: chris1284 am 28 Dezember 2014, 21:35:47
hallo,
benötigt man für das fronthemDevice zwingend eine feste ip für die clients, stichwort dhcp und leases <=24h ?
Hi,
yepp, brauch man. Im Normalfall leben die leases ja länger und im Zweifel kann man dem Router ja sagen "immer gleiche IP ...".
Die identy per ip ist nur eine Krücke bis die certs kommen (Stichwort wan) - und für device die das dann nicht können.
vg
jörg
Zitat von: ak323 am 28 Dezember 2014, 21:29:59
Jo/Jörg,
sorry muß revidieren: Geht auch nicht wenn ich die beiden Definifionen per Kommondozeile von fhem eingebe !
Bekomme auf dem RPi folgende Fehlermeldung:
pi@raspberrypi ~ $ $VAR1 = {
'cmd' => 'gadList'
};
Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/31_fronthemDevice.pm line 112.
Irgendeine weitere Idee ?
Hi,
ja, hatten wir ja hier schon einige Male, am Ende ging es dann eigentlich immer. Ich weiß nicht wo das herkommt (cfg von Hand oder so ?). Nimm mal den Kram aus der cfg, beende fhem, lösche die Verzeichnisse unter www/fronthem, checke die beiden perl module (JSON, websocket::server) mach einen reboot und gib das über die fhem cmd line ein. Wenn ich verstehe was schief läuft fang ich das ab.
Ich habe es nie getestet das von Hand in die cfg zu nehmen - macht ja auch keinen Sinn, nicht wahr ;)
vg
jörg
Zitat von: herrmannj am 28 Dezember 2014, 21:59:43
Hi,
yepp, brauch man. Im Normalfall leben die leases ja länger und im Zweifel kann man dem Router ja sagen "immer gleiche IP ...".
Die identy per ip ist nur eine Krücke bis die certs kommen (Stichwort wan) - und für device die das dann nicht können.
vg
jörg
Schade, dann sich das thema estmal erledigt. hostname oder eine art id die vom host gesendet wird (wie zb in wvc) wäre sinnvoller. Was steckt da für ein grund hinter ( einen sicherheitsaspekt lass ich nicht gelten ;) )
Dieses Problem habe ich leider auch: FHEM und SV laufen, Werte in SV sind da, alles OK. Ein simpler rereadcfg lässt FHEM dann abstürzen, speichern der fhem.cfg in Frontend ebenfalls. FHEM Neustart von der Konsole aus und alles läuft wieder.
System auf dem beides läuft ist ein Cubietruck mit Debian.
Zitat von: chris1284 am 28 Dezember 2014, 22:31:06
Schade, dann sich das thema estmal erledigt. hostname oder eine art id die vom host gesendet wird (wie zb in wvc) wäre sinnvoller. Was steckt da für ein grund hinter ( einen sicherheitsaspekt lass ich nicht gelten ;) )
Doch, geht in Richtung Sicherheit (Richtung certs). Wo ist denn der showstopper bei den IP für Dich ? Im Endausbau hat man die Möglichkeit sich nur für zertifikate zu entscheiden, (IP überhaupt nicht) oder IP zusätzlich (für LAN, nicht WAN).
Wie ist denn Dein use case ? Man kann es nicht allen recht machen aber vielleicht geht ja was
vg
jörg
Ich gehöre ja auch zu den Leuten, die den Wunsch hätten, dass man die komplette Security optional pauschal abschalten kann. Wenn man in seinem Intranet sitzt und nichts nach draußen offen hat und nur vertrauenswürdige Rechner im Netz sind, dann macht es wenig Spaß alle Tablet, Handies und Laptops zu konfigurieren, die hier rumschwirren.
Nachtrag: und jetzt zu Beginn wäre es noch schöner, weil es einfacher wird, mal mit diesem und jenem Tablet und Handy zu testen, wie das Frontend läuft und aussieht.
Zitat von: HCS am 28 Dezember 2014, 22:32:47
Dieses Problem habe ich leider auch: FHEM und SV laufen, Werte in SV sind da, alles OK. Ein simpler rereadcfg lässt FHEM dann abstürzen, speichern der fhem.cfg in Frontend ebenfalls. FHEM Neustart von der Konsole aus und alles läuft wieder.
System auf dem beides läuft ist ein Cubietruck mit Debian.
Ach schau, ein speichern der cfg läßt fhem abstürzen ? Re-read-cfg ?? Das würde erklären warum die von-Hand-rein-schreiber ;) Probleme hatten.
Ist in der alpha nie aufgetreten, habe meinerseits auch keine Probleme damit (speichere regelmäßig, aktuell sehr oft, re-read brauche ich nie).
Wo liegt denn die Schnittmenge ? config-db ? db-log ?
@HCS: irgendeinen Verdacht ? Wenn Du nicht config-db nimmst, kannst Du bitte mal fhem mit leerer cfg starten (über cmd line mit der initialen aus dem svn oder sowas, macht ja nichts kaputt) und
dort einmal fronthem und einmal fronthemDevice definieren + speichern ?
Du verstehst was ich meine (bevor was Du aus versehen was löschst) oder ?
Danke vorab und viele Grüße
Jörg
Zitat von: HCS am 28 Dezember 2014, 22:40:38
Ich gehöre ja auch zu den Leuten, die den Wunsch hätten, dass man die komplette Security optional pauschal abschalten kann. Wenn man in seinem Intranet sitzt und nichts nach draußen offen hat und nur vertrauenswürdige Rechner im Netz sind, dann macht es wenig Spaß alle Tablet, Handies und Laptops zu konfigurieren, die hier rumschwirren.
Nachtrag: und jetzt zu Beginn wäre es noch schöner, weil es einfacher wird, mal mit diesem und jenem Tablet und Handy zu testen, wie das Frontend läuft und aussieht.
JA-JA, ich hör ja zu ;)
Ich baue in (die, eine?) kommende Versionen ein das man die Berechtigungen per default (attribut) auf on setzt. Dann muss ein GAD ein mal definiert werden und alle device haben Zugriff ohne das man nur einmal in den Editor muss. Deal ? ;)
vg
jörg
Zitat von: herrmannj am 28 Dezember 2014, 22:04:53
Hi,
ja, hatten wir ja hier schon einige Male, am Ende ging es dann eigentlich immer. Ich weiß nicht wo das herkommt (cfg von Hand oder so ?). Nimm mal den Kram aus der cfg, beende fhem, lösche die Verzeichnisse unter www/fronthem, checke die beiden perl module (JSON, websocket::server) mach einen reboot und gib das über die fhem cmd line ein. Wenn ich verstehe was schief läuft fang ich das ab.
Ich habe es nie getestet das von Hand in die cfg zu nehmen - macht ja auch keinen Sinn, nicht wahr ;)
vg
jörg
Hallo Jörg,
alles schon ausprobiert. Perl module sind aktuell, reboot hilft nicht.
Ich hatte noch einen 1-wire OWFS laufen dessen http frontend auch auf port 2121 lauschte ... geändert auf 2122, hilft aber nix.
Ich weiß gerade auch nicht weiter ... :-\
Ich denke zusammen werden wir das Problem gelöst bekommen .. ich will doch auch endlich SV nutzen ! Bin ganz scharf drauf ... und meine bessere Hälfte als Designerin auch ...
Schönen abend ... ak323
Ich will eine visualiserung für alle pflegen ( also kein er darf das sehen , er das, er jenes) und habe 4 mobile +3 feste geräte.
Alles dhcp mit lease 12h da wechselnde gäste. Dhcp ist übrigens per default bei den meisten routern aktiv und ihr würdet mit hostname mehr configs abdegken als mit statischen ips. Zertifikate + evtl eine eigene ca für 7 clients zu verwalten / einrichten ist etwas overkill. Ich möchte ungern eine exceltapete mit ips, cert-ablaufdaten, passwörtern für die zertifikatsfiles usw pflegen (im jahr 2014) + quf 7 clients zertifikate importieren. Warum auch das eine frontend so sichern wenn fhem direkt offen ist ;D
Zertifikate habem den nachteil das man unter android die sicherheit mind. Auf pin für das entsperren setzen muss! Sehr doof bei nem wandtablet mit option zur mobilen nutzung oder bei seinem smartphone wo man nur wischen will um es zu entsperren oder das surftablet auf dem man auch nich jedesmal per pin entsperren will.
axo, Nachtrag: man muss aber trotzdem jeweils ein device pro Gerät (ip, cert) in fhem anlegen. Das muss sein weil die device nicht stateless sind. Die müssen ja individuell wissen welche GADs (pro device) ge-monitored werden sollen.
Unter Umständen kann ich, so wie in fhem web, device volatile anlegen, bis dahin vergeht aber noch Zeit. Ich würde jetzt wvc, plots, certs und den sicher anfallenden bugfixes erstmal den Vorrang geben.
vg
jörg
Zitat von: herrmannj am 28 Dezember 2014, 22:47:01
Wo liegt denn die Schnittmenge ? config-db ? db-log ?
Ich verwende keinerlei db.
Zitat von: herrmannj am 28 Dezember 2014, 22:47:01
@HCS: irgendeinen Verdacht ? Wenn Du nicht config-db nimmst, kannst Du bitte mal fhem mit leerer cfg starten (über cmd line mit der initialen aus dem svn oder sowas, macht ja nichts kaputt) und dort einmal fronthem und einmal fronthemDevice definieren + speichern ?
Werde ich mal austesten. Bin eh auf einem Testsystem, das ich nach wilden Orgien mir öfters mal aus dem Produktivsystem neu kopiere.
Noch ein Wunsch: lässt sich die tracerei auf der Konsole irgendwie unterbinden? Auf der möchte ich eigentlich gerne was tun, aber das ist schwierig so ... ;D
ich meine das und weiteres:
monitor Temperature_Mobile2.temperature
res
monitor Temperature_Mobile2.humidity
res
monitor Temperature_Mobile2.battery
Zitat von: herrmannj am 28 Dezember 2014, 22:51:07
Ich baue in (die, eine?) kommende Versionen ein das man die Berechtigungen per default (attribut) auf on setzt. Dann muss ein GAD ein mal definiert werden und alle device haben Zugriff ohne das man nur einmal in den Editor muss. Deal ? ;)
Ja. Super, damit hast Du mindestens mal mich glücklich gemacht.
(die,
eine?) ;D
Evtl geht ja ein proxy über den alle geräte gehen. Ident per ip und konfig pro client hab ich in smartvisu eh schon deaktiviert umd es hat nur die default
Zitat von: herrmannj am 28 Dezember 2014, 22:47:01
Wo liegt denn die Schnittmenge ? config-db ? db-log ?
@HCS: irgendeinen Verdacht ? Wenn Du nicht config-db nimmst, kannst Du bitte mal fhem mit leerer cfg starten (über cmd line mit der initialen aus dem svn oder sowas, macht ja nichts kaputt) und dort einmal fronthem und einmal fronthemDevice definieren + speichern ?
Du verstehst was ich meine (bevor was Du aus versehen was löschst) oder ?
Danke vorab und viele Grüße
Jörg
Hi Jörg,
hab ich gerade auch mal mit der demo.cfg aus fhem gemacht...
Stürzt nicht ab !
Gibt aber ne Reihe von Meldungen auf der konsole des RPI und SV hat immer noch das rote Dreieck !
2014.12.28 22:56:46 2: FHEM demo version
2014.12.28 22:56:46 0: Server started with 33 defined entities (version $Id: fhem.pl 7301 2014-12-22 07:12:41Z rudolfkoen ig $, os linux, user pi, pid 3967)
2014.12.28 22:57:08 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or a tom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246
2014.12.28 22:57:08 2: fronthem: ipc listener opened at port 16384
2014.12.28 22:57:09 3: start forked ws: ws:3968
2014.12.28 22:57:09 3: ipc fronthem:127.0.0.1:37821 (ws): ws alive with pid 3968
2014.12.28 22:57:32 1: Notebook: Error loading cfg file malformed JSON string, neither array, object, number, string or a tom, at character offset 0 (before "(end of string)") at ./FHEM/31_fronthemDevice.pm line 453
$VAR1 = {
'cmd' => 'gadList'
};
Zitat von: ak323 am 28 Dezember 2014, 22:52:17
Hallo Jörg,
alles schon ausprobiert. Perl module sind aktuell, reboot hilft nicht.
Ich hatte noch einen 1-wire OWFS laufen dessen http frontend auch auf port 2121 lauschte ... geändert auf 2122, hilft aber nix.
probier mal bitte mit jungfäulicher fhem cfg (siehe post an hcs). Vorsicht, nix löschen bei Dir, Sicherheitskopie machen ... etc.
Zitat
und meine bessere Hälfte als Designerin auch ...
Ach guck mal, die möchte jetzt sv noch schicker machen ? Schön den code posten, will ich auch was von haben 8) (viele Grüße unbekannter weise)
voll überschnitten. Den code von Deiner GöGa will ich trotzdem. :)
Die Meldungen sind alle ok, keine Fehler. Rotes Dreieck geht weg wenn ein fronthemDevice mit passender ID konfiguriert ist.
Dann lass mal überlegen wo der Unterschied zwischen Demo cfg und Deiner produktiven ist.
vg
jörg
Zitat von: chris1284 am 28 Dezember 2014, 23:01:36
Evtl geht ja ein proxy über den alle geräte gehen. Ident per ip und konfig pro client hab ich in smartvisu eh schon deaktiviert umd es hat nur die default
Ne, wenn die alle mit der gleichen ip ankommen geht das in die Hose. fronthem muss die einzelnen clients unterscheiden können weil die individuell beschickt werden. Aber wart mal kurz, ich muss den post oben erstmal lesen und verstehen :D
Testergebnisse:
Mit dieser cfg keinerlei Problem bei einem rereadcfg:
attr global userattr devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global backup_before_update 1
attr global logfile ./log/fhemDummy-%Y-%m.log
attr global modpath .
attr global motd none
attr global room System
attr global sendStatistics onUpdate
attr global statefile ./log/fhemDummy.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global updateInBackground 0
attr global verbose 3
define telnetPort telnet 7072 global
attr telnetPort room System
define eventTypes eventTypes ./log/eventTypesDummy.txt
define Logfile FileLog ./log/fhem-Dummy-%Y-%m.log fakelog
define WEB FHEMWEB 8083 global
#define fronthem fronthem
#attr fronthem room SmartVISU
Mit der hier crash:
Wenn ich den "define fronthem" reinnehme, dann funktioniert der erste rereadcfg und das device erscheint im frontend und läuft.
Ab dem nächsten rereadcfg crasht es dann grundsätzlich.
fhem.cfg im frontend speichern ebenso.
attr global userattr devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global backup_before_update 1
attr global logfile ./log/fhemDummy-%Y-%m.log
attr global modpath .
attr global motd none
attr global room System
attr global sendStatistics onUpdate
attr global statefile ./log/fhemDummy.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global updateInBackground 0
attr global verbose 3
define telnetPort telnet 7072 global
attr telnetPort room System
define eventTypes eventTypes ./log/eventTypesDummy.txt
define Logfile FileLog ./log/fhem-Dummy-%Y-%m.log fakelog
define WEB FHEMWEB 8083 global
define fronthem fronthem
attr fronthem room SmartVISU
Zitat von: chris1284 am 28 Dezember 2014, 22:54:24
Ich will eine visualiserung für alle pflegen ( also kein er darf das sehen , er das, er jenes) und habe 4 mobile +3 feste geräte.
Alles dhcp mit lease 12h da wechselnde gäste. Dhcp ist übrigens per default bei den meisten routern aktiv und ihr würdet mit hostname mehr configs abdegken als mit statischen ips. Zertifikate + evtl eine eigene ca für 7 clients zu verwalten / einrichten ist etwas overkill. Ich möchte ungern eine exceltapete mit ips, cert-ablaufdaten, passwörtern für die zertifikatsfiles usw pflegen (im jahr 2014) + quf 7 clients zertifikate importieren. Warum auch das eine frontemd so sichern wenn fhem direkt offen ist
Zertifikate habem den nachteil das man unter android die sicherheit mind. Auf pin für das entsperren setzen muss! Sehr doof bei nem wandtablet mit option zur mobilen nutzung oder bei seinem smartphone wo man nur wischen will um es zu entsperren oder das surftablet auf dem man aufh nich jedesmal per pin entsperren will.
ja ok, im prinzip ist das ja auch so gedacht. Für die "Faulen" (nicht böse gemeint) eben nur ip - sonst cert.
Btw, fronthem unabhängig von fhemweb sehr dicht macht sehr viel Sinn, Du kannst fhemweb zusätzlich ber basic-auth oder/und allewed-by sichern, oder eben ganz zumachen (aus wan). Die ca und Verwaltung der certs wird fronthem übernehmen, wenn sich alles umsetzen lässt wie geplant sollten auch "Normaluser" damit (später) streßfrei mit umgehen können.
Ich hab das Problem jetzt noch nicht genau verstanden. Der Punkt ist das Deine 7 Geräte alle 12h eine neue IP bekommen (müssen?)
Ansonsten passt doch alles auf den use case ?
vg
jörg
Zitat von: herrmannj am 28 Dezember 2014, 23:06:08
Die Meldungen sind alle ok, keine Fehler. Rotes Dreieck geht weg wenn ein fronthemDevice mit passender ID konfiguriert ist.
vg
jörg
Frage für Dummies: wie geht das ?
Ich habe in fhem eine Funksteckdose die Funksteckdose_D heißt: (define Funksteckdose_D GenShellSwitch /home/pi/rcswitch-pi/send 11011 4 1 0)
Wie definiere ich hierfür nen fronthemDevice mit passender ID ?
(sorry für die blöde Frage ...)
Meine "simple" fhem.cfg bringt fhem nicht mehr zum Absturz .. ! ;)
Hi,
schau mal ins wiki, Bernd und Fabian haben die ersten Schritte gut dokumentiert
vg
jörg
Zitat von: herrmannj am 28 Dezember 2014, 23:51:36
Hi,
schau mal ins wiki, Bernd und Fabian haben die ersten Schritte gut dokumentiert
vg
jörg
JUHUUUU !!!! Es klappt !!!
Mit meiner einfachen fhem.cfg .... !
Das WiKi finde ich wirklich nicht selbst erklärend ... wenn ich hier Erfahrungen gesammelt habe, dann schreibe ich dort mit ...
Danke für den Support jo und jörg !
Mal zur Designerin runter gehen ... ;)
Zitat von: HCS am 28 Dezember 2014, 23:13:29
Testergebnisse:
attr global userattr devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global backup_before_update 1
attr global logfile ./log/fhemDummy-%Y-%m.log
attr global modpath .
attr global motd none
attr global room System
attr global sendStatistics onUpdate
attr global statefile ./log/fhemDummy.save
attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global updateInBackground 0
attr global verbose 3
define telnetPort telnet 7072 global
attr telnetPort room System
define eventTypes eventTypes ./log/eventTypesDummy.txt
define Logfile FileLog ./log/fhem-Dummy-%Y-%m.log fakelog
define WEB FHEMWEB 8083 global
Hi,
Danke, ich hab das mit Deinen cfg nachgestellt, in der Konstellation schaffe ich es auch nach rereadcfg.
Aber: nimm mal bitte die cfg oben, starte und gib am Stück (also ohne reread oder so) über das webif
define test fronthem
define tab fronthemDevice 192.168.178.33
und speichere dann.
Das geht bei mir problemlos. Das mit rereadcfg (wozu braucht man das ??) ;) schau ich mir an.
vg
jörg
Zitat von: ak323 am 28 Dezember 2014, 23:58:10
JUHUUUU !!!! Es klappt !!!
Mit meiner einfachen fhem.cfg .... !
Das WiKi finde ich wirklich nicht selbst erklärend ... wenn ich hier Erfahrungen gesammelt habe, dann schreibe ich dort mit ...
Danke für den Support jo und jörg !
Cool, aber warum mir der und nicht mir Deiner normalen .... ::)
Zitat
Mal zur Designerin runter gehen ... ;)
oh ja, ich hab ne Frage: eigentlich wollte ich heute Abend meine Wohnzimmer Lampen alle in die visu bringen, mir fällt aber noch nicht ein wie ich das optisch ansprechend gestalte mache. Insgesamt 6 Stück, einige nur Schalter, andere Dimmer, andere RGB. Grüß schön .... ;D
vg
jörg
Danke Euch !
Meine Funksteckdose kann ich jetzt auch schalten .... :D
Schöne Nacht ...
-3 Grad außen übrigens ....
Zitat von: herrmannj am 28 Dezember 2014, 23:58:56
Das mit rereadcfg (wozu braucht man das ??) ;) schau ich mir an.
rereadcfg braucht man nun nicht ganz unbedingt, aber die fhem.cfg sollte man halt nach Änderungen schon ohne crash speichern können, und das geht ja auch nicht.
Und manchmal verwende ich einen "vernünftigen" Editor, um die fhem.cfg zu bearbeiten und dann braucht man auch den rereadcfg.
Du denkst noch an die Ausgaben auf der Konsole?
Und frag nun nicht "Konsole, wozu braucht man das ??" ;D ;D
Zitat von: herrmannj am 29 Dezember 2014, 00:03:32
Cool, aber warum mir der und nicht mir Deiner normalen .... ::)
vg
jörg
Jörg, ich habe jetzt noch mal meine "normale" fhem.cfg zurückkopiert und "define fronthem fronthem" und "define Notebook fronthemDevice 192.168.2.106" händisch ganz unten hinzugefügt. Fhem Neustart und siehe da ....: klappt alles ! ich kann immer noch auf die Aussentemperatur und die Funksteckdose_D aus SV zugreifen .. !
Verstehe das wer will --- ?! ...
Jetzt habe ich ne Menge Devices zu definieren ....
Ich finde aber auch wir sollten es möglich machen generische Devices (Clients) zu definieren, die einmal defineirt werden und auf alles zugreifen dürfen ... Ich habe aktuell 5 devices: 2 Notebooks, 1 Tab an der Wand im WZ und 2 iPhones ....
-> denkt doch bitte mal drüber nach .... !
VG ak323.
Zitat von: HCS am 29 Dezember 2014, 00:16:58
rereadcfg braucht man nun nicht ganz unbedingt, aber die fhem.cfg sollte man halt nach Änderungen schon ohne crash speichern können, und das geht ja auch nicht.
Und manchmal verwende ich einen "vernünftigen" Editor, um die fhem.cfg zu bearbeiten und dann braucht man auch den rereadcfg.
Du denkst noch an die Ausgaben auf der Konsole?
Und frag nun nicht "Konsole, wozu braucht man das ??" ;D ;D
Ja, aber warte mal, kurzer Schritt zurück:
Bei rereadcfg sehe ich einen Fehler, den werde ich beseitigen.
Das define über webif (fronthem, fronthemDevice) und anschließendes save funktioniert problemlos.
Haben wir da den gleichen Stand ?
vg
Jörg
Zitat von: ak323 am 29 Dezember 2014, 00:22:47
Jörg, ich habe jetzt noch mal meine "normale" fhem.cfg zurückkopiert und "define fronthem fronthem" und "define Notebook fronthemDevice 192.168.2.106" händisch ganz unten hinzugefügt. Fhem Neustart und siehe da ....: klappt alles ! ich kann immer noch auf die Aussentemperatur und die Funksteckdose_D aus SV zugreifen .. !
Verstehe das wer will --- ?! ...
Na, soweit dann ja gut. Schön.
Überlege bitte nochmal ob es nicht vielleicht doch einen Unterschied gab, ich weiß jetzt nicht ob (geschweige denn was) gefixt werden soll.
Zitat
Ich finde aber auch wir sollten es möglich machen generische Devices (Clients) zu definieren, die einmal defineirt werden und auf alles zugreifen dürfen ... Ich habe aktuell 5 devices: 2 Notebooks, 1 Tab an der Wand im WZ und 2 iPhones ....
Hatte ich doch geschrieben. Im Augenblick mach es Dir einfach, kopier die client cfg auf das nächste device. Später wird das komfortabel beim define gemacht.
Unter uns: fünf HomeMatic Funk-Stellantriebe (HM-CC-VD) zu installieren kostet Dich deutlich (!) mehr Aufwand ... oder ? ;)
vg
Jörg
Hallo,
eine kurze Rückmeldung noch. Ich habe jede Menge Temperatursensoren mit einem device angelegt. Die Rechte hatte ich für das zweite device noch nicht gesetzt. Dennoch ist es möglich, diese Werte mit dem zweiten device anzeigen zu lassen. Allerdings erscheinen dann diese Meldungen im log-file:
DeviceXY no read permission for SensorXY
Mein log-file wird dadurch ziemlich aufgeblasen. Selbst wenn sich das Anzeigen der Werte bei fehlender Berechtigung noch nicht unterdrücken lässt, sollte man evtl. die Meldungen im log unterdrücken können.
schöne Grüße
Jo
Zitat von: herrmannj am 28 Dezember 2014, 23:18:25
Für die "Faulen" (nicht böse gemeint) eben nur ip - sonst cert.
gerade wegen der Faulheit haben sich findige Entwickler dhcp und Namensauflösung einfallen lassen. weil keiner die festen ips in einem zb class a Netzwerk pflegen wollte 8)
ZitatDer Punkt ist das Deine 7 Geräte alle 12h eine neue IP bekommen (müssen?)
es ist mit einer lease Zeit von 12h durchaus möglich (wenn sie zb aus sind oder länger unterwegs so das keine Verlängerung erfolgt). und wenn das passiert muss ich in fhem die ip's der frontfhemdevices ändern. ich würde mich aber nicht an den 12h orientieren, das kann auch bei 24h, 48h usw. usw. passieren.
ist es schwer neben der ip noch den Host-Name auszulesen, der ist in der Regel eindeutiger als die ip? sollte, im Gegensatz zu einer sich selbstverwaltenden ca, doch schneller umsetzbar sein.
per ip was zu sichern ist für mich in etwa die gleiche pseudo Sicherheit wie Mac-Filter, Default Passwörter oder eine aktive Firewall mit Regel "allow any any" ;D
ip kann ich ohne erhöhte rechte oder großen Aufwand ändern => ich bin ein anderes device und darf dann zb alles. den Namen zu ändern geht bei den meisten Geräten nicht so problemlos
ich setzte bei fhem schon, für WAN, auf clientauth per cert über Apache als reverse Proxy. und gerade hier ist es extrem, ich muss es so sagen, kacke das sobald man ein Zertifikat auf einem Android gerät installiert man das entsperren des Displays auf mindestens pin oder Passwort setzen muss (nichts mehr mit wischen, Zeichen oder ohne Sperrung des Bildschirms arbeiten).
das ist der Grund warum alle Clients, die nicht über WAN gehen, bei mir keine Zertifikate mehr haben. es ist komfortabler.
wenn nun aber wieder die "feste ip" da zwischen funkt wird es wieder unkomfortabler.
des Weiteren kann man mit einem selbsterstellten Zertifikat die Seiten nicht direkt aufrufen sondern muss immer vorher bestätigen dass man sicher ist (gerade im Chrome optisch ganz schlecht gelöst). wenn frontfhem noch eine vertrauenswürdige ca mit bringt (glaub ich nicht da es Geld kosten würde) steht man trotzdem vor dem Problem "root" um auf vielen mobilen Geräten das cert zu installieren (egal ob man eine eigene ca oder eine offizielle hat).
Zitat von: Jojo11 am 29 Dezember 2014, 07:37:44
Hallo,
eine kurze Rückmeldung noch. Ich habe jede Menge Temperatursensoren mit einem device angelegt. Die Rechte hatte ich für das zweite device noch nicht gesetzt. Dennoch ist es möglich, diese Werte mit dem zweiten device anzeigen zu lassen. Allerdings erscheinen dann diese Meldungen im log-file:
DeviceXY no read permission for SensorXY
Mein log-file wird dadurch ziemlich aufgeblasen. Selbst wenn sich das Anzeigen der Werte bei fehlender Berechtigung noch nicht unterdrücken lässt, sollte man evtl. die Meldungen im log unterdrücken können.
schöne Grüße
Jo
Hi Jo,
ist richtig, hatte das zu test zwecken so eingebaut - und (eher aus versehen) :) drin gelassen. Hab es aber für mich behalten damit das mit den Rechten gleich richtig angewendet wird.
Nehm ich in der zweiten beta raus.
Danke und Grüße
Jörg
Ok, danke. Ist zum Testen ja auch durchaus hilfreich :)
schöne Grüße
Jo
Zitat von: chris1284 am 29 Dezember 2014, 09:56:03
ich setzte bei fhem schon, für WAN, auf clientauth per cert über Apache als reverse Proxy. und gerade hier ist es extrem, ich muss es so sagen, kacke das sobald man ein Zertifikat auf einem Android gerät installiert man das entsperren des Displays auf mindestens pin oder Passwort setzen muss (nichts mehr mit wischen, Zeichen oder ohne Sperrung des Bildschirms arbeiten).
das ist der Grund warum alle Clients, die nicht über WAN gehen, bei mir keine Zertifikate mehr haben. es ist komfortabler.
wenn nun aber wieder die "feste ip" da zwischen funkt wird es wieder unkomfortabler.
Hi chris,
ja passt doch, so ist es doch auch geplant. Den proxy sparst Du auf dem path sv host und ws. Möglichkeit Nummer 3, um per WAN rein zugehen ist der VPN. Glaub mir, ich hab mehr device :)
Hostname kommt erst mal nicht (wieso das besser sein soll als ip versteh ich nicht). Für den Rest der Anwender deutlich aufwendiger als einmal den Haken (diesem Gerät die gleiche IP zuweisen) im router zu setzen - was imho in 99% der auch quatsch ist weil die normalen Router sowieso versuchen dem device die gleiche ip wieder zu geben.
vg
Jörg
Zitat von: herrmannj am 29 Dezember 2014, 00:40:34
Bei rereadcfg sehe ich einen Fehler, den werde ich beseitigen.
Das define über webif (fronthem, fronthemDevice) und anschließendes save funktioniert problemlos.
Haben wir da den gleichen Stand ?
Ja. Das funktioniert. So habe ich es auch initial ans Laufen gebracht. Das mit dem Speichern der fhem.cfg ist mir erst viel später aufgefallen, als ich etwas ganz Anderes darin geändert habe.
Also bei mir funzt das leider nicht!
Bekomme noch immer folgendes im Log:
fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246.
Habe es schon mehrmals versucht auch mit Berechtigungen. Das fronthem-Verz. wird auch nicht erstellt.
Aus dem WIKI werde ich auch nicht wirklich schlau da meiner Meinung nach die Details fehlen.
Also Berechtigungen der Dateien und genaue Pfad.
Auch ist nicht zu lesen wie der Editor funktioniert oder wo man diesen findet.
Meinen Test-Client sehe ich in FHEM als "Connected" in SmartVISU bekomme ich komischerweise noch immer die ERROR-Ecke.
Hoffe man kann mir helfen.
@Grimm: Läuft fhem bei Dir als root?
Gesendet von meinem iPad mit Tapatalk
Das hatte ich auch erst gedacht aber dem ist nicht so.
fhem 5615 0.4 1.3 121732 45552 ? S 10:19 0:04 perl fhem.pl fhem.cfg
fhem 5617 0.0 0.5 73716 20400 ? Ss 10:19 0:00 perl fhem.pl fhem.cfg
Auszug aus m Wiki:
Der Websocket wird durch ein fhem-Modul 01_fronthem.pm realisiert, das im Ordner .../fhem/FHEM/ abgelegt wird.
Die Device-Connectoren werden durch das fhem-Modul 31_fronthemDevice.pm realisiert, welches im Ordner .../fhem/FHEM/ abgelegt wird.
die Readings Converter. Sie werden durch die Datei fhconverter.pm realisiert, die im Ordner .../fhem/FHEM/ abgelegt wird.
Der Javascript Editor ist eine fhem WebIF Erweiterung, um die Bindung der fremden Frontend-Objekte an FHEM Devices/Readings vorzunehmen und die dazu notwendigen Konvertierungen zu wählen. Er wird durch die Datei fronthemEditor.js repräsentiert, die in den Ordner .../fhem/www/frontend/pgm2/ kopiert wird.
Also, der genaue Pfad sollte damit wohl geklärt sein, oder? Wenn fhem als root läuft, sind die Berechtigungen egal, wenn nicht, musst Du chown <fhemuser> <datei> ausführen und evtl. noch chmod 755 <datei>, dann sollte es gehen.
Gesendet von meinem iPad mit Tapatalk
Der Editor wird über die fronthemDevices aufgerufen:
Auszug aus dem Wiki:
Sobald ein Device definiert ist, kann man über denn device connector die GADs definieren und die Rechte verteilen.
Gesendet von meinem iPad mit Tapatalk
Habe es mal alles so gemacht, doch leider noch immer der gleiche Fehler im LOG und kein Verzeichnis in /opt/fhem/www
Hallo Grimm,
na - das hatten wir doch jetzt schon einige male hier im thread.
Ist keine Fehlermeldung...
die Ordner Ordner werden beim speichern der fronthem cfg angelegt ...
vg
jörg
hat dein fhem user denn dort die Rechte auf das Verzeichnis? poste mal ein ls -l von ./fhem
Gesendet von meinem iPad mit Tapatalk
wäre evtl. die beschränkung auf ip ranges drin? sprich define <name> frontfhemdevice 192.168.2.*
Zitat von: Grimm80 am 29 Dezember 2014, 10:44:49
Habe es mal alles so gemacht, doch leider noch immer der gleiche Fehler im LOG und kein Verzeichnis in /opt/fhem/www
Der Vollständigkeit halber ;): Hast Du die fhem.cfg von Hand angepasst und gespeichert oder fronthem per FHEM-Kommandozeile definiert?
schöne Grüße
Jo
habe die zwei Zeilen per Hand wie Web-Interface eingetragen
Zitat von: chris1284 am 29 Dezember 2014, 10:52:13
wäre evtl. die beschränkung auf ip ranges drin? sprich define <name> frontfhemdevice 192.168.2.*
das hast Du vmtl so als "generisches" oder "pool" define gedacht - geht aber nicht weil es pro device ein define geben muss (wegen status und push).
Zitat von: HCS am 28 Dezember 2014, 23:13:29
fhem.cfg im frontend speichern ebenso.
Kann ich bestätigen. Habe jetzt wegen einer anderen Änderung die fhem.cfg editiert und gespeichert und musste danach FHEM neu starten :-\
schöne Grüße
Jo
ja, das haben wir doch nun identifiziert ... das nachfolgende (von fhem imitierte) rereadcfg funtkioneirt nicht.
Deswegen beta ... und wer die cfg von Hand ändert ... ;) Aber ich bin da kein Apostel. Entweder ihr verzichtet bis zur nächsten Version auf cfg von Hand ändern oder müsst halt einen Neustart hinnehmen :)
vg
jörg
wo genau muss die "fronthem.cfg" hin und hat jemand ein beispiel dafür?
die wird vom modul erzeugt. Hast Du denn den Editor schon gefunden ? vg
nein hab ich leider nicht....
Wo muß ich da denn suchen? *komm mir voll blöd vor*
also im fhemDevice "Test" ist oben was drin, aber editieren kann ich da nix.
Steht nur "gad device r w" drin
soso, und dann willste die cfg mal von Hand schreiben ... nenene kinners
Wenn da nix drin steht hat Dein sv keine Verbindung zu fronhem - da musste ran.
fronthemDevice mit der IP die zugreift definiert ?
in sv in der cfg page die Adresse von fhem und port 2121 eingetragen ?
steht "connected" im state des fronthemDevice ?
vg
jörg
Verbindung steht! Connect habe ich für den TEST.
Zitat von: Grimm80 am 29 Dezember 2014, 12:15:22
also im fhemDevice "Test" ist oben was drin, aber editieren kann ich da nix.
Steht nur "gad device r w" drin
Das ist der Editor. Jetzt musst Du in SV etwas anlegen, was dann dort erscheint.
@Jörg: Sorry, komme nicht nach mit Lesen ;)
schöne Grüße
Jo
Zitat von: Grimm80 am 29 Dezember 2014, 12:22:15
Verbindung steht! Connect habe ich für den TEST.
JUT !, dann drück mal ctrl f5 in sv (damit die gad geladen werden) und danach f5 im editor.
Wenn dann da wirklich immer noch nix steht (wärst der erste) schick mal nen screenshot vom editor und ein list vom fronthemDevice.
@jo
Zitat@Jörg: Sorry, komme nicht nach mit Lesen ;)
sch...e kenn ich :D
vg
jörg
Zitatas ist der Editor. Jetzt musst Du in SV etwas anlegen, was dann dort erscheint.
Axo, genau. oder ein demohaus nehmen. Ich hab das jetzt vorausgesetzt - but who knows.. Danke Jo!
Hallo,
ich wollte nur mal kurz mitteilen, wie bei mir aktuelle der Stand der Dinge ist.
Ich habe mir jetzt FHEM auf Debian in einer Virtuellen Maschine auf meinem Windows Server am laufen, habe alles so installiert, wie beschrieben.
Jetzt hatte ich in die Kommandozeile von FHEM
Zitatdefine test fronthem
eingegeben und es hat direkt funktioniert.
:) Ihr glaubt gar nicht, wie sehr ich mir jetzt freue, dass es endlich funktioniert hat.
So und als nächstes muss ich jetzt mal SmartVisu einrichten... :)
viele Grüße
Alexander
Zitat von: avg123-de am 29 Dezember 2014, 12:35:30
:) Ihr glaubt gar nicht, wie sehr ich mir jetzt freue, dass es endlich funktioniert hat.
So und als nächstes muss ich jetzt mal SmartVisu einrichten... :)
Hi Alexander,
super, cool. Beim sv einrichten fängt der Spaß erst richtig an. Bernd hat auch schon einige coole widgets gebaut.
btw: ich habe heute schon gelernt das Dirks wvc http://www.fhemwiki.de/wiki/WebViewControl leider keine websockets kann - aber auch das es ein plugin dafür gibt: https://github.com/mkuklis/phonegap-websocket/blob/b7cc3bf50e2aa83bb70ffaf40cfb017c219b7bdc/README.md
Nun weiß ich mal das es cordova gibt und wofür das gut ist :) Gemacht habe ich das aber noch nie - hat zufällig jemand eine funktionierende Entwicklungsumgebung und ein bischen Zeit dafür am start ? Plan wäre von Dirk die source für das wvc zu erbetteln (bin schon betteln gegangen :D ), das plugin einzubauen und dann sv über das wvc laufen zu lassen.
Danke und Grüße
Jörg
LOL...
hätte ich gleich mal eine andere Page probiert :o
Vielen Danke für die schnelle Hilfe jetzt klappt es und ich kann testen....
@Jörg: geiler Plan! Ich helfe, wo ich kann!
He Bernd, Danke.
ich hoffe ja mal das jemand "hier" schreit ;D
Ich häng das gleich nochmal ran - viel hilft viel :)
Zitatbtw: ich habe heute schon gelernt das Dirks wvc http://www.fhemwiki.de/wiki/WebViewControl leider keine websockets kann - aber auch das es ein plugin dafür gibt: https://github.com/mkuklis/phonegap-websocket/blob/b7cc3bf50e2aa83bb70ffaf40cfb017c219b7bdc/README.md
Nun weiß ich mal das es cordova gibt und wofür das gut ist :) Gemacht habe ich das aber noch nie - hat zufällig jemand eine funktionierende Entwicklungsumgebung und ein bischen Zeit dafür am start ? Plan wäre von Dirk die source für das wvc zu erbetteln (bin schon betteln gegangen :D ), das plugin einzubauen und dann sv über das wvc laufen zu lassen.
vg
jörg
Hallo,
die Informationen darüber, was alles gemacht werden muss, stehen mittlerweile ziemlich verteilt im Thread. Ich habe mir da auch ziemlich einen abgebrochen es überhaupt ans laufen zu bekommen. Vielleicht, schauen die Experten mal drüber, was ich hier zusammen gefasst habe.
Die Dateien aus der ersten Threadseite so kopiert, wie es im zip-File abgebildet ist und in der Beschreibung steht. Dabei an die Berechtigungen denken.
In der fhem-Gui:
define fronthem fronthem
define pc fronthemDevice 192.168.xxx.xxx <= das ist die IP des PC über dem ich mit dem Browser zugreife
Dann in der config.ini, die bei mir im Verzeichnis /var/www/smartVISU auf dem PI liegt, den Client eingetragen:
[clients]
192.168.xxx.xxx = 'pc' <== das ist die gleiche IP wie im fronthemDevice angegeben wurde
und seine Umgebung:
[client:pc]
title = 'xxx' <== Name der in der als Beschriftung für den Tab im Browser verwendet wird
cache = false
animation = false
driver_realtime = true
pages = 'fhem' <== Verzeichnisname unter /var/www/smartVISU/pages, da wo auch die Beispiele stehen. Muss angelegt werden
design = 'night'
driver_address = '192.168.xxx.xxx' <== IP des fhem-Servers
Für den Start habe ich dann die Dateien aus dem Verzeichnis /var/www/smartVISU/pages/_template in das von mir angelegte Verzeichnis /var/www/smartVISU/pages/fhem kopiert.
Nach dem Aufruf von http://sv-Server/smartVISU/index.php sehen ich die Umgebung, die durch die Templates dargestellt wird. Ein Raum "Sleeping", die Uhrzeit und das Wetter von Würzburg.
Wenn sv dann die Verbindung aufgebaut hat, steht das fronthemDevice auf Connected und man sieht die leere Liste der Device. Da kann man aber zu diesem Zeitpunkt nichts editieren
Von da an habe ich meine Änderungen erst einmal in den vorhandenen Dateien ausgeführt um zu sehen, was jeweils passiert. Ich habe dann in der Datei /var/www/smartVISU/pages/fhem/room_sleeping.html ein Homematicdevice (aus der ersten Threadseite) reinkopiert:
{{ homematic.hmtc('Devicename aus FEHM', 'mode', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_controlmode', 'WZ_rtr_daytemp', 'WZ_rtr_nighttemp', 'WZ.fenster', 'WZ_rtr_battery', 'WZ_rtr_state', 'WZ_rtr_text') }}
Nach dem Aktualisieren der sv-Seite tauchen dann die Parameter aus dieser Zeile im fronthemDevice auf und müssen mit Leben gefüllt werden.
Wie das geht steht auch auf der ersten Threadseite.
Das ganze hat aber auch erst im zweiten Anlauf so funktioniert. Ich habe als es nicht funktioniert hat, alles gelöscht und noch einmal Schritt für Schritt alles kopiert, die Berechtigungen gesetzt und dann ging es.
Ich hoffe, das ich keine großen Fehler hier reingeschrieben habe und das die Zusammenfassung denen hilft, die noch am Anfang stehen.
Gruß Norbert
Hi Norbert,
im schnellen überflug sieht das sehr gut aus.
cache kannst Du später, wenn die Seiten fertig sind, auf true setzen. Da kommst Du auch über die cfg page in sv ran.
vg
jörg
@Norbert:
und ganz herzlichen Dank für die gute Auflistung !
vg
Jörg
Hallo Zusammen,
von mir ebenfalls ein großes Lob!!! Klasse Modul/Erweiterung
Sitze hier in Österreich mit nem Meniskusriss (kann kein Skifahren... :'() und dachte mir nutz die Zeit um SmartVisu etwas kennen zu lernen...
Also "kurzerhand" über VPN auf meinem Mac-Server "alles" eingerichtet...
Nun läuft es soweit das ich 10 VPN-Clients als fronthemDevice eingerichtet habe, zwei "Test-switches" im Frontend verbunden mit Fhem über den Editor...
...schalten!!! ;D
Nun suche ich die schon oft beschriebene/gesuchte cfg in ./www/fronthem/... nicht vorhanden... :o
Kann mir das jemand erklären??
Hallo,
bei mir wurde die folgende Struktur automatisch angelegt:
xxx@xxx:/opt/fhem/www/fronthem# ls -ltR
.:
total 8
drwxr-xr-x 3 fhem dialout 4096 Dec 28 22:12 clients
drwxr-xr-x 3 fhem dialout 4096 Dec 28 18:43 server
./clients:
total 4
drwxr-xr-x 2 fhem dialout 4096 Dec 28 22:12 pc
./clients/pc:
total 4
-rw-r--r-- 1 fhem dialout 837 Dec 28 22:56 fhclient.pc.cfg
./server:
total 4
drwxr-xr-x 2 fhem dialout 4096 Dec 28 18:43 fronthem
./server/fronthem:
total 4
-rw-r--r-- 1 fhem dialout 2092 Dec 28 22:56 fhserver.fronthem.cfg
Ich habe dort nichts manuell angelegt oder editiert. Wenn diese Dateien nicht da sind, scheint etwas nicht
funktioniert zu haben. Eventuell alles noch mal löschen und neu beginnen. Vor allem auf die Rechte achten.
Gruß Norbert
P.S. Gute Besserung!
Hallo,
ich gehe doch richtig in der Annahme, dass wenn ich sv das erste mal starte und dann auf "Config" klicke, dass dann eigentlich die config.ini automatisch erstellt werden müsste, oder?
Bei mir wird nämlich automatisch keine erstellt. Und wenn ich unter den Einstellungen in sv etwas eintrage und anschließend auf Save drücke, wird auch nichts gespeichert.
viele Grüße
Alexander
Rechte geprüft? Chown ... www-Data, chmod 755 ...???
Zitat von: avg123-de am 29 Dezember 2014, 15:32:41
Hallo,
ich gehe doch richtig in der Annahme, dass wenn ich sv das erste mal starte und dann auf "Config" klicke, dass dann eigentlich die config.ini automatisch erstellt werden müsste, oder?
Bei mir wird nämlich automatisch keine erstellt. Und wenn ich unter den Einstellungen in sv etwas eintrage und anschließend auf Save drücke, wird auch nichts gespeichert.
viele Grüße
Alexander
Hallo Alexander,
ich habe die aus dem zip-File des ersten Post extrahiert, auf meinen PI übertragen und dann soweit konfiguriert. Ob das die richtige Vorgehensweise ist, kann ich nicht beurteilen. Es hat aber funktioniert.
Gruß Norbert
Hallo,
ich hatte die rechte via
Zitatchown -R www-data:www-data smartVISU
chmod -R 775 smartVISU
vergeben.
viele Grüße
Alexander
ZitatHallo Alexander,
ich habe die aus dem zip-File des ersten Post extrahiert, auf meinen PI übertragen und dann soweit konfiguriert. Ob das die richtige Vorgehensweise ist, kann ich nicht beurteilen. Es hat aber funktioniert.
Gruß Norbert
Das hatte ich auch probiert, aber anscheinend greift sv nicht darauf zu.
viele Grüße
Alexander
Vor oder nachdem Du die Dateien von Jörg verteilt hast?
Davor.
Dann mach das nochmal, sind ja neue Dateien drin...
Habe ich gemacht, danach reboot, jedoch keine Veränderung.
Der erstellt keine config.ini und wenn ich die aus der .zip-Datei nehme, funktioniert es auch nicht.
Ich hatte SmartVisu so installiert:
Zitatcd /var/www
rm index.html
wget http://smartvisu.de/download/smartVISU_2.7.zip
unzip smartVISU_2.7.zip
rm smartVISU_2.7.zip
und danach noch:
Zitatchown -R www-data:www-data smartVISU
chmod -R 775 smartVISU
Beschrieben war das hier: https://github.com/mknx/smarthome/wiki/Komplettanleitung-Installation-sh.py-,-smartVISU,-eibd-und-1-Wire
Hast du folgende Files ?
/var/www/smartVISU
-rwxrwxr-x 1 www-data www-data 1166 Dez 28 22:35 config.ini
-rwxrwxr-x 1 www-data www-data 5373 Dez 28 17:33 index.php
/var/www/smartVISU/pages/base
-rwxrwxr-x 1 www-data www-data 1209 Dez 28 17:33 configure.php
/var/www/smartVISU/lib
-rwxrwxr-x 1 www-data www-data 5238 Dez 26 23:16 functions_config.php
Ja, aber danach hast Du doch die Dateien von Jörg in die Verzeichnisse kopiert, oder?
ZitatHast du folgende Files ?
/var/www/smartVISU
-rwxrwxr-x 1 www-data www-data 1166 Dez 28 22:35 config.ini
-rwxrwxr-x 1 www-data www-data 5373 Dez 28 17:33 index.php
/var/www/smartVISU/pages/base
-rwxrwxr-x 1 www-data www-data 1209 Dez 28 17:33 configure.php
/var/www/smartVISU/lib
-rwxrwxr-x 1 www-data www-data 5238 Dez 26 23:16 functions_config.php
Die sind bei mir alle in dem Verzeichnis drin.
... Und stimmen da auch die Rechte!
ZitatJa, aber danach hast Du doch die Dateien von Jörg in die Verzeichnisse kopiert, oder?
Hatte ich so gemacht. Und die Rechte hatte ich eben auch noch mal angepasst.
Ich glaube ich lösche den sv Ordner noch mal komplett und installiere es nochmal ganz neu!
Zitat... Und stimmen da auch die Rechte!
Wie kann ich das prüfen, habe FHEM erst seit gestern auf Linux am laufen und kenne mich noch nicht so sehr aus.
Gibt es da einen Befehl, wie bei der Rechtevergabe, den ich ins Terminal eingeben muss?
... Und stimmen da auch die Rechte!
Zitat... Und stimmen da auch die Rechte!
Wie kann ich das überprüfen, gibt es da auch so einen Befehl, wie bei der Rechtevergabe, den ich ins Terminal eingeben muss?
Sorry, habe FHEM erst seit gestern auf Linux am laufen.
Wiederhole nochmal die Chown und chmod Befehle von oben!
ZitatWiederhole nochmal die Chown und chmod Befehle von oben!
Habe ich gemacht, ist es richtig, dass in der Konsole dann nicht viel erscheint?
Zitatroot@Debian:/var/www# chown -R www-data:www-data smartVISU
root@Debian:/var/www# chmod -R 775 smartVISU
root@Debian:/var/www#
Nun sei mal 'n großer und probier etwas selber...
Es scheint jetzt zu funktionieren, da jetzt die Client-Konfiguration aus der .ini greift.
Ich kann nur noch mit Geräten auf sv zugreifen, die dort drin sind. :)
wie bekommt man ein frontfhemdevice dazu die liste vorhandener gad's neu einzulesen?
selbst ein fhem neustart bringt nichts. ich habe in fhserver.fronthem.cfg ein neues eingefügt, in der fhclient....cfg das gad hinzugefügt. es taucht in fhem im device nicht auf
und bitte das im device eingebaute
desktop.svg
arrow-down.svg
arrow-up.svg
mit liefern, ist deafault nicht in
/opt/fhem/www/images/default
Diese cfg sollten nicht von Hand angepasst werden. Der Editor macht das zuverlässig, wenn alles andere stimmt. Lösch lieber und Fang von vorne an!
es tauchte irgendwann allein auf...
bitte noch die gerade oben editierten svg's anhängen ;)
nimm doch einfach die aus dem zip in post #1 - ich finde die passen ;)
Habe mal die Schritte wie "REDLAV" geschrieben hat durchgeführt, aber ich sehe keine Änderungen wenn ich die room_sleeping.html editiere.
Im Browser erscheint immer nur Sleeping.
Das ist der Inhalt für den Raum:
{% extends "rooms.html" %}
{% block content %}
HEIZUNG
{% import "widget_homematic.html" as homematic %}
{{ homematic.hmtc('WZ1_OG.Heizung', 'mode', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_controlmode', 'WZ_rtr_daytemp', 'WZ_rtr_nighttemp', 'WZ.fenster', 'WZ_rtr_battery', 'WZ_rtr_state', 'WZ_rtr_text') }}
{% endblock %}
Sehe wie gesagt keine Änderungen und im FHEM zeigt er auch nichts an außer das er verbunden ist.
Hast Du die widget_homematic.html überhaupt? Wenn ja, muss sie in Deinem Pages Folder liegen. Probier doch erst mal einfache standarditems wie switch oder so, dann sammelst Du einige Erfahrungen.
Ja die Datei liegt mit dabei.
Chown, chmod ok?
Ich kann in die Datei schreiben was ich will, Änderungen werden keine angezeigt das ist es was mich stutzig macht.
Wo hast Du die denn her? Hast Du mal reingeschaut?
Cache Off und temp Folder leer?
Zitat von: bgewehr am 29 Dezember 2014, 18:21:37
Diese cfg sollten nicht von Hand angepasst werden. Der Editor macht das zuverlässig, wenn alles andere stimmt. Lösch lieber und Fang von vorne an!
wie bekomme ich denn neu gads hinzugefügt die ich dann über fhem im device editieren kann ohne die cfg anzufassen?
Editiere Deine SmartVISU Seiten korrekt, dann erscheinen die Gads von selber... Dann setz die Gad-Eigenschaften im fhem Gad-Editor und die cfg werden automatisch gepflegt.
Ich muss auch mal ein großes Lob an herrmanj ausprechen! Klasse Modul!
Nachdem ich Gestern alle hier beschriebenen Fehler durchgemacht hatte:
- Fehlende Treiber / Programme beim Cubie
- Rechtevergabe Cubie
- Absturz FHEM
- kein Neustart von FHEM
- keine Verbindung SV zu FHEM
- Fehler mit Domitiga - Treiber
Habe ich mir Heute nochmal den gesammten Tread durchgelesen. Danach alles gelöscht, eine Datensicherung der fhem.cfg draufgespielt und dann nochmal alles in der richtigen Reihenvolge (mit den entsprechenden Tips aus dem Tread) neu gemacht.
Erfolg 8)
Dann die mitgelieferten Beispiele von SV angesehen und siehe da, das gesamte System ist recht einfach und nachvollziebar aufgebaut.
Ich hatte mich schon an das Layout von FHEM gewöhnt! Aber jetzt bin ich begeistert.
Danke herrmannj
Gruß Lutz
Hallo, Lutz! Zunächst freut es mich, dass alles geht. Kannst Du vielleicht ein kleines Protokoll über die richtige Reihenfolge verfassen, damit andere es leichter haben? Ich hatte das schon mal probiert, aber meine Version scheint nicht allen zu helfen...
Zitat von: bgewehr am 29 Dezember 2014, 23:23:13
Hallo, Lutz! Zunächst freut es mich, dass alles geht. Kannst Du vielleicht ein kleines Protokoll über die richtige Reihenfolge verfassen, damit andere es leichter haben? Ich hatte das schon mal probiert, aber meine Version scheint nicht allen zu helfen...
Hallo Bernd, dann mach ich das mal:
Installation fronthem Quick Guide: *** Ergänzungen in Farbe ***fhem installieren [http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/ (http://www.meintechblog.de/2013/05/fhem-server-auf-dem-raspberry-pi-in-einer-stunde-einrichten/)], konfigurieren, update, restart -> fhem.cfg sichern nicht vergessen ...
smartVISU installieren
[https://www.domotiga.nl/projects/domotiga/wiki/SmartVISU (https://www.domotiga.nl/projects/domotiga/wiki/SmartVISU)]
Testen ob sv auch läuft .. sv demo
perl Module WebSocket & JSON installieren/updaten
curl -L https://cpanmin.us | perl - --sudo App::cpanminus (evtl. wenn noch nicht auf dem system..)
>>Installation cpanmin:curl hat bei mir nicht funktioniert -> "wget -O - ..." ging dann.
sudo cpanm Net::WebSocket::Server
sudo cpanm JSON
fronthem.zip Inhalte aus dem 1. Post [http://forum.fhem.de/index.php/topic,30909.msg234616.html#msg234616 (http://forum.fhem.de/index.php/topic,30909.msg234616.html#msg234616)] in die entsprechenden Verzeichnisse kopieren
fhconverter.pm nicht vergessen ! [http://forum.fhem.de/index.php?action=dlattach;topic=30909.0;attach=23789 (http://forum.fhem.de/index.php?action=dlattach;topic=30909.0;attach=23789)]
In sv Domotiga Treiber in Configuration I/O Connection auswählen, IP des Rechners auf dem fhem läuft angeben, port 2121
Rotes Dreieck von sv in der rechten oberen Ecke ignorieren.
In fhem
per Web Kommandozeile:
define <name> fronthem
define <name> fronthemDevice <ip>"Save" nicht vergessen .. ;-)
ACHTUNG: diese <ip> ist die Adresse des Clients/Rechners mit welchem Ihr per fronthem auf sv zugreifen wollt !
Vorsicht bei DHCP mit neuer IP !
Jetzt sollte fhem nicht abstürzen - im Gegensatz dazu wenn Ihr die fhem.cfg händisch ändert ... ggf. mit einer simplen fhem.cfg testen...
>>Wenn FEHM abstürzt oder nicht startet immer daran denken den Ordner fronthem im Verzeichnis www löschen! Danach nächster Versuch! ;)
sv & fhem verbinden:
In sv unter www/pages/ ein Verzeichnis für Eure Hausprojekt anlegen ...z.B. "TestHaus".
Aus einem anderen Verzeichnis mindestens category.html, index.html, room_xxx.html, rooms.html, rooms_menu.html, visu.css und visu.js reinkopieren und nach Bedarf anpassen
Dann in sv unter Configuration/Interface dieses ("TestHaus") auswählen.
room_xxx.html mit einer
einfachen GAD Definition testen - bspw:
{% extends "rooms.html" %}
{% block content %}
<div class="preblock">
</div>
<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>Funksteckdosen</h3>
<table width="90%">
<tr><td align="left" width="100px">
{{ basic.switch('switch01', 'Funksteckdose_D') }}
<td>Funksteckdose D</td></tr>
</table>
</div>
</div>
</div>
{% endblock %}
"Funksteckdose_D" ist bei mir eine in fhem definierte Funksteckdose, switch01 ist eine frei vergebene sv ID die einmalig in sv sein muss.
Dann in fhem auf das fronthemDevice (bspw. euren Rechner) gehen und das neue GAD konfigurieren:
GAD Edit
Funksteckdose_D
mode item
device Funksteckdose_D
reading state
converter OnOff
cmd set in der Liste erscheint das dann so:
gad device r w
Funksteckdose_D Funksteckdose_D
Jetzt solltet Ihr in sv die "Funksteckdose_D" schalten können .. !
(rotes Dreieck in sv weiterhin ignorieren !)
Vielen Dank an Jörg für die super Entwicklerarbeit (weiter so !) und Jörg & jo dafür, daß sie beide mir neulich bei der erfolgreichen Konfiguration meines fronthem geholfen haben !
VG ak323
Freut mich. Die Zusammenfassung sieht sehr gut und komplett aus, danke!
schöne Grüße
Jo
Super, vielen Dank!
Für den Fall, dass fhem nicht als Root läuft sind noch die Rechte an den Verzeichnissen und Dateien anzupassen. Der fhem User sollte mit chown zum Eigentümer der fhem-Verzeichnis-Struktur und aller Dateien gemacht werden und mit chmod read, write und execute Rechte haben. Gleiches gilt für den www-data User des Webservers in der smartVISU Struktur. Dann sollte es immer gelingen!
Da ist mir ak323 zuvorgekommen. Sieht Klasse aus!
Noch ein paar Anmerkungen!
Installation cpanmin:
curl hat bei mir nicht funktioniert -> "wget -O - ..." ging dann.
Wenn FEHM abstürzt oder nicht startet immer daran denken den Ordner fronthem im Verzeichnis www löschen! Danach nächster Versuch! ;)
Unbedingt auf die Rechte beim Kopieren oder Bearbeiten der Dateien auf dem Cubie achten. War teilweise mein Fehler, da ich im Netzwerk beim kopieren mit anderem Benutzer angemeldet war.
In die Gruppe www-data auch FHEM (bei mir der Name under dem FHEM läuft) mit hinzufügen.
Gruß Lutz
Danke Lutz, hab's hinzugefügt ...
Also bei mir war der Cache noch aktiv! Danke!
Ein kleines Problem hab ich noch, smartVisu läßt sich nicht auf DE umstellen. Also wenn ich DE einstelle dann ist alles noch immer in EN.
Gibt es da noch einen Trick?
Hast Du in der Config im Register "text" auf german umgestellt?
Die Config-Seiten bleiben übrigens auf Englisch!
Ja da hab ich es umgestellt und es steht dann auch "Deutsch" drin, aber Temperatur bleibt auf °F stehen und nicht auf °C
Hast Du auch unten auf save gedrückt?
Ja na klar... ;D
Schau mal in die config.ini, ob dort bei [default] lang = 'de' steht und wie das bei Deinen diversen Clients eingestellt ist.
Ich empfehle Dir, das in default auf 'de' zu setzen und lang = 'XX' bei allen anderen zu löschen.
Hab ich verscuht aber leider alles in English
Hab es auch mal auf FR gestellt, aber da hat sich auch nix geändert.
Immer nur alles in EN
laut sv ist auch nur bei einige widgets (was auch immer das meint) Mehrsprachunterstützung drin. vg
Ohh, ich nutze das widget_heizung aus dem Thread 1
Zitat von: bgewehr am 25 Dezember 2014, 19:40:34
Die Batterie funktioniert auch zwischen den gewünschten Werten 2.2 und 2.9, wenn man den Fehler im basic.shifter behebt, der leider vergisst min und Max an basic.icon weiterzugeben, habe ich unter Code.google.com/smartvisu schon als Issue gemeldet...
Hut ab. Ich habe mir den korrigierten code bei Dir aus dem github kopiert ::) Seitdem klappt's auch mit der Batterieanzeige.
Da auch bei mir immer °F angezeigt wurde, habe ich Dein widget aus Beitrag http://forum.fhem.de/index.php/topic,30909.msg234786.html#msg234786 (http://forum.fhem.de/index.php/topic,30909.msg234786.html#msg234786) minimal geändert:
{{ basic.float(id~'actual', gad_actual, '°C' ) }} bzw.
{{ basic.float(id~'set', gad_set, '°C' ) }}Mag sein, dass das dann in anderen Sprachen nicht mehr klappt, aber °C ist international ;D
schöne Grüße
Jo
Vielen Danke manchmal sieht man den Wald vor lauter Bäumen nicht mehr ;)
Zitat von: Jojo11 am 30 Dezember 2014, 12:46:23
Hut ab. Ich habe mir den korrigierten code bei Dir aus dem github kopiert ::) Seitdem klappt's auch mit der Batterieanzeige.
Da auch bei mir immer °F angezeigt wurde, habe ich Dein widget aus Beitrag http://forum.fhem.de/index.php/topic,30909.msg234786.html#msg234786 (http://forum.fhem.de/index.php/topic,30909.msg234786.html#msg234786) minimal geändert:
{{ basic.float(id~'actual', gad_actual, '°C' ) }} bzw. {{ basic.float(id~'set', gad_set, '°C' ) }}
Mag sein, dass das dann in anderen Sprachen nicht mehr klappt, aber °C ist international ;D
schöne Grüße
Jo
Yepp. Da möchte ich auch an dieser Stelle noch mal explizit auf die Arbeit (und Anpassung) von Bernd hinweisen:
Erst mit dem von Bernd reparierten shifter (sollte eigentlich jeder übernehmen wollen) funktionieren zum Beispiel die Icon Anzeige für gedimmte Lampen (0..100). Das brauche ich auch an vielen weiteren Stellen.
@Bernd ! TOP!!!
vg
Jörg
Hallo,
da ich gestern Probleme mit sv hatte, das die config.ini nicht lesen wollte, hatte ich heute Debian nochmal komplett neu installiert.
Ich hatte es genau nach der Beschreibung von ak323 gemacht, jedoch bekomme ich in FHEM immer noch den Fehler:
Zitat2014.12.30 16:29:47 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/01_fronthem.pm line 246
2014.12.30 16:29:48 2: fronthem: ipc listener opened at port 23031
2014.12.30 16:29:49 3: start forked ws: ws:2220
2014.12.30 16:29:49 1: Alexanders_PC: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/31_fronthemDevice.pm line 453
und meine fronthemDevice ("Alexanders_PC") gibt mir nur
Zitat???
zurück.
Berechtigungen habe ich bereits angepasst, genau wie die config.ini.
Zumindest funktioniert sv inzwischen reibungslos (ich kann Seiten erstellen, Devices anlegen, nur das schalten klappt durch die fehlende Verbindung zu FHEM leider noch nicht). Und einen Ordner im Verzeichnis /fhem/WWW/ mit dem Namen fronthem gibt es auch leider nicht.
viele Grüße
Alexander
Hallo,
gibt es eigentlich schon Ideen, wie die SV-plots mit den Daten aus den FHEM-logfiles gefüttert werden können?
schöne Grüße
Jo
Zitat von: herrmannj am 30 Dezember 2014, 13:12:40
....funktionieren zum Beispiel die Icon Anzeige für gedimmte Lampen (0..100). Das brauche ich auch an vielen weiteren Stellen.
...
Hallo,
kannst du mir dazu bitte mal ein kurzes Beispiel geben?
Zitat von: avg123-de am 30 Dezember 2014, 16:38:19
Hallo,
da ich gestern Probleme mit sv hatte, das die config.ini nicht lesen wollte, hatte ich heute Debian nochmal komplett neu installiert.
Ich hatte es genau nach der Beschreibung von ak323 gemacht, jedoch bekomme ich in FHEM immer noch den Fehler:und meine fronthemDevice ("Alexanders_PC") gibt mir nur zurück.
Berechtigungen habe ich bereits angepasst, genau wie die config.ini.
Zumindest funktioniert sv inzwischen reibungslos (ich kann Seiten erstellen, Devices anlegen, nur das schalten klappt durch die fehlende Verbindung zu FHEM leider noch nicht). Und einen Ordner im Verzeichnis /fhem/WWW/ mit dem Namen fronthem gibt es auch leider nicht.
viele Grüße
Alexander
Hallo Alexander,
log ist ok:
... character offset 0 ... sagt einfach das es noch keine cfg gibt.
Ordner unter fhem/www werden erst beim arbeiten im Edtor angelegt - also auch roger.
Zitatund meine fronthemDevice ("Alexanders_PC") gibt mir nur
da stehen 3 dann Fragezeichen (vmtl.)
Bevor dort nicht connected steht brauchst Du nix weiter machen - im sv driver fhem ip überprüfen. Ich hatte da zb mal anstelle von punkten bei der ip ein komma eingetippt - das sind so dinger die sieht man kaum, sorgen aber für fehler.
Häng mal Deine config.ini aus sv ran und schreib mal bitte Deine ip's (local) in den post. (fhem, client, sv)
vg
Jörg
tante edith: schau noch vorab das Dein www ordner in fhem die richtigen Rechte hat (im Zweiles user und group wie fhem cfg)
Zitat von: pole23 am 30 Dezember 2014, 16:44:12
Hallo,
kannst du mir dazu bitte mal ein kurzes Beispiel geben?
ja gern, mach ich heute Abend. (Wenn Du das dann nimmst, anreicherst und ins wiki setzt wäre schön)
vg
jörg
Zitat von: Jojo11 am 30 Dezember 2014, 16:42:31
Hallo,
gibt es eigentlich schon Ideen, wie die SV-plots mit den Daten aus den FHEM-logfiles gefüttert werden können?
schöne Grüße
Jo
Yepp, tief in meinem Kopf :-)
Das wäre noch das i-Tüpfelchen. Mit dem Einrichten des Rests bin ich fast schon durch ::) Wobei das irgendwie doch kein Ende nimmt :o
schöne Grüße
Jo
Hallo Jörg,
meine config.ini sieht derzeit wie folgt aus:
[smartVISU]
version = '2.8'
multiuser = true
ident_by_ip = true
ip_allowed = ''
ident_by_cert = false
ca_cert = ''
auto_add = true
[clients]
172.16.0.30 = 'Alexanders_PC'
[default]
pages = 'TestPage'
design = 'night'
cache = false
animation = true
title = 'fronthem [smartVISU]'
lang = 'de'
driver = 'domotiga'
driver_address = '172.16.0.4'
driver_port = '2121'
driver_realtime = true
weather_service = 'offline'
weather_location = 'Germany/Bayern/Würzburg'
weather_key = ''
phone_service = 'offline'
phone_server = '172.16.x.x'
phone_user = ''
phone_pass = ''
calendar_service = 'offline'
calendar_url = 'http://www.google.com/calendar/feeds/...'
js = 'js'
[client:Alexanders_PC]
title = 'joerg'
cache = false
animation = true
driver_realtime = true
IP FHEM: 172.16.0.4
IP sv: 172.16.0.4
IP Client: 172.16.0.30
Die Rechte des Ordners www hatte ich gerade nochmal zugewiesen, hat jedoch keine Auswirkung gehabt.
viele Grüße
Alexander
das sieht soweit eigentlich ok aus.
Ich vermute mal Du hast in sv die rote Ecke, auch nach f5 (richtig?)
Sach ma, Du hattest doch, (war so?) ein debian in einer virtual box ?
Kommt man eigentlich von außen aktiv auf die virtual box (also den port 2121) ?
Mein spielchen mit virtual boxen sind schon eine Weile her, ich meine mich aber zu erinnern das man da ein recht spezielles ip setup brauchte um so was zu machen.
Ich hab grad keine Idee wie Du das "messen" könntest - aber mach doch mal in der vbox cmdline (shell) ein "ifconfig" mal schauen was die box für ne ip hat.
Was eine virtualisierung läuft da ? Vielleicht kennt sich hier jemand genauer damit aus.
vg
jörg
hmm, kann mit dem Verdacht auch danebenliegen. Musstest Du irgendwas spezielles machen um das fhem webif zu erreichen ? Ist das "von außen" (= anderer pc) zu erreichen ?
vg
jörg
Hallo Jörg,
hat sich erledigt, nachdem ich jetzt bei sv mal F5 gedrückt hatte und danach nochmal in fhem geschaut hatte, stand dort "connected".
Nur zur Info: Mein Debian (und auch alle meine anderen VMs) läuft unter der windowseigenen Virtualisierungsplattform Hyper-V, dort sind die IP-Einstellungen relativ easy.
viele Grüß
Alexander
P.S. Dann kann ich jetzt auch mal den GAD-Editor ausprobieren. :)
P.S.S Danke für die großartige Hilfe hier im Forum!!!
na perfekt , viel spaß beim einrichten
vg
jörg
Zitatna perfekt , viel spaß beim einrichten
Danke, den werde ich haben!
Ich würde mir gerne einen converter für ein Device mit 3 Status basteln. Mein Starknopf für die Alarmanlage wird zunächst auf setOn und dann automatisch durch ein at auf on geschaltet. Im Prinzip bräuchte ich also nur einen converter, der setOn/Off kann. Ich habe versucht den OnOff Konverter zu nehmen und in einer 99_myUtils umzubauen. Leider wird der converter im Feld nicht zur Auswahl angeboten und funktioniert auch nicht. Kann mir da eventuell jemand Starthilfe geben? Eventuell auch allgemein dazu, wie man einen converter in eine 99_myUtils einbaut?
theoretisch wäre es (glaub ich) möglich das problem zu umschiffen in dem man 2 Buttons nimmt, den einen auf "setOn" den anderen auf "off". Ich hab ein Beispiel für eine Lichtszene ins Wiki gelegt was Du unter Umständen dazu adaptieren könntest.
Das war aber nicht Deine Frage, die war 99my Utils:
Generell ist dieses vorgehen für Leute geeignet die perl fest sind (no offense) - den OnOff als Vorlage zu nehmen ist in Deinem Beispiel gut.
Importiert wird anhand des namespace, Du musst also den gleichen namespace wie in fhconverter nehmen. Ich muss auch gestehen das ich das noch nicht getestet habe. Ich lese beim Start alle subs in dem Namespace und die stehen dann als converter zur Verfügung. Wenn ich aber so darüber nachdenke kann es sehr wohl sein das ich das nochmal (vom Zeitpunkt) verschieben muss damit nicht fronthem den Namespace schon abfragt wenn die 99er von fhem noch garnicht geladen ist.
Du könntest Deinen code mal probeweise in den fhconverter schreiben und so schauen ob er generell läuft. Wenn Du ihn danach in die 99er (mit gleichem namespace) verschiebst und er wird nicht mehr geladen habe ich ein todo.
vg
jörg
Ein wenig PERL kann ich schon. Leider verstehe ich jedoch nicht, wie ich den gleichen Namespace verwende.
Ich habe wohl aber auch grundsätzlich die converter nicht verstanden, denn in der fhconverter läuft er ebenfalls nicht.
Ich schaue mir das weiter an und melde mich ggf.
Du, poste den gerne, ich schau mal drüber
vg
jörg
@Karl: Du brauchst keinen speziellen Converter, nimm einfach Direct!
Zitat von: bgewehr am 30 Dezember 2014, 18:39:31
@Karl: Du brauchst keinen speziellen Converter, nimm einfach Direct!
sorry für meinen temporären Gehirnfrost, ich war zu sehr auf "converter" fixiert: Bernd hat, logisch, Recht! ....
Ich meine so:
{{ basic.switch(id, gad, pic_on, pic_off, val_on, val_off) }}
also für Dich:
{{ basic.switch(id, gad, pic_on, pic_off, 'seton', 'off') }}
Mit dem converter direct auf state read/write sollte das klappen!
Auf Direct war ich auch gekommen. Aber ich verstehe nicht, wie ich dann den Button einbauen muss. Aber wie sagt man dann smartVisu, dass es setOn und off senden soll?
Ich sehe schon, mir fehlt noch zu viel Einblick in das Konzept.
@bgwehr: Ich habe sowas. So wird das Device aber auf 1 und 0 gesetzt:
{{ keypad.auth_switch('TestButton', 'TestButtonOnOff', icon1~'status_locked.png', icon0~'status_open.png',"setOn","off",1234) }}
Sorry. Mein Fehler. Es funktioniert. Ich habe den falschen Test-Button verwendet.
Danke!! Das fronthem ist klasse.
ja und ich schalt mein Gehirn wenn ich "converter" höre - ein Glück das es morgen Bier gibt und wir ein Taxi nehmen 8)
Sach ma: was ist denn "keypad.auth_switch" ?
vg
jörg
Das ist ein Widget, das ich im KNX Forum gefunden habe. Es erstellt einen Button, der nur geschaltet wird, wenn man in einem Popup Keypad den richtigen Code eingibt. Ich habe es etwas umgebaut, sodass es auch 2 verschiedene Codes akzeptiert.
Das ganze ist natürlich nicht sicher, da man den Code im Quelltext sehen kann aber mit solchen Sachen werde ich mich auch noch beschäftigen, wenn ich Zeit finde.
ja stimmt, cool. Hast Du den link noch ?
fronthem wird dazu auhc noch was bekommen damit im server eine pin ausgewertet wird, aber bis dahin ist das top. vielleicht kann man das später als grafische vorlage nehmen, dann braucht man auch in sv nicht viel zu ändern
danke und gütßr
jörg
Hier der Link:
http://knx-user-forum.de/smartvisu/37369-neues-widget-zum-testen-freigegeben.html (http://knx-user-forum.de/smartvisu/37369-neues-widget-zum-testen-freigegeben.html)
Lauffähige Version in Beitrag Nr. 6.
Ich habe das bisher in FHEM mit remoteConrol und sequence gelöst. Das ist dort sogar deutlich komplizierter als jetzt in SmartVisu ;)
Hallo,
smartVISU läuft. Vielen Dank an alle die ihre Probleme schon gepostet haben. Hat mir eine menge Arbeit erspart. Da ich immer mal wieder mit CPAN und Debian auf meinem RPi Probleme habe hier noch eine Möglichkeit JSON nicht über CPAN sondern über Debian zu installieren:
sudo apt-get install libjson-perl
Als Web-Sever nutze ich übrigens nginx. Leider ist mein RPi B nicht gerade der Schnellste für smartVISU. Die Web-Seiten werden nur mäßig schnell ausgeliefert (dauert bis zu 15 Sekunden). Von daher meine Frage: Auf welcher Hardware habt ihr smartVISU laufen und wie lange dauert das erste Ausliefern der Startseite.
Grüße Jörg
Hallo Jörg,
Habe am Anfang auch mit dem raspi gearbeitet, der reicht. Cache einschalten und data-ajax=true (dann bleibt die Seite im Speicher des tabs).
Für Produktiv bin ich aber auf einem odroid unterwegs - andere Klasse. Besser!
vg
jörg
Hi, also alles installiert, habe auch die gad im Fronthem device. Jedoch unter state immer nur ???, habe fhem auf cubie laufen und sv auf RPi.
beim device oder bei fronthem ?
Zitat von: JoWiemann am 30 Dezember 2014, 20:03:33
Leider ist mein RPi B nicht gerade der Schnellste für smartVISU. Die Web-Seiten werden nur mäßig schnell ausgeliefert (dauert bis zu 15 Sekunden). Von daher meine Frage: Auf welcher Hardware habt ihr smartVISU laufen und wie lange dauert das erste Ausliefern der Startseite.
Grüße Jörg
Hi Jörg.
fhem und sv auf nem RPi B mit ner ultralangsamen SD Karte (4): 10s
Bei beiden Fronthem und Fronthemdevice
@Jörg: das auth_switch Widget ist bei mir im GIT und funktioniert.
die gads kommen erst wenn ein connected da ist - war also bei Dir schon.
fronthem (die Mutter hat noch keinen state)
Drück mal f5 an sv. Ansonsten neustart fhem. Mehrere tabs am browser bringen das System noch durcheinander (weil fronthem dann mehrer connects von gleicher ip / mit gleicher identity sieht)
vg
Zitat von: bgewehr am 30 Dezember 2014, 20:35:08
@Jörg: das auth_switch Widget ist bei mir im GIT und funktioniert.
cool, zieh ich mir. Aber vorher tauch ich mal in ein Kellerlabor - hatte doch noch nen verrückten Plan ;D
Ein Teil davon ist in der visu.js, also muss die ebenfalls aktualisiert werden!
Gesendet von meinem iPad mit Tapatalk
Neustart hat nichts gebracht.
Im log beim Start sehe ich nur dieses!
2014.12.30 20:40:49 3: ipc SV:127.0.0.1:41107 (ws): ws alive with pid 3432
Zitat von: bgewehr am 30 Dezember 2014, 20:35:08
@Jörg: das auth_switch Widget ist bei mir im GIT und funktioniert.
#
Link zum Original ist auch im letzten Beitrag der vorherigen Seite.
der ws lebt 8)
Du hast die gads ja im editor, also lief es. in sv driver und ip/port überprüfen. Save. Dann f5.
vg
Zitat von: bgewehr am 30 Dezember 2014, 20:35:08
@Jörg: das auth_switch Widget ist bei mir im GIT und funktioniert.
Stimmt. Danke Dir.
Wie bekommst Du die FritzBox-Daten. Welchen Eintrag hast du bei der FritzOS 6.2 gemacht. Meine FritzBox wird jedenfalls nicht gültig angesprochen.
Grüße Jörg
Define myfritzbox FRITZBOX, das Modul ist recht neu, glaube ich.
Telnet muss aktiviert sein -> avm Handbuch!
Ein bisschen musst Du Dich mit dem Telnet User beschäftigen, eine password Datei erstellen usw.
Hat jemand eigentlich die beiden Systeme getrennt laufen oder nutzt ihr beides auf dem gleichen System?
Bei mir beides auf einem bananaPI! Ich bin damit sehr zufrieden!
Bei mir läuft beides auf einem raspi. Allerdings wird der demnächst gegen etwas leistungsfähigeres ausgetauscht.
schöne Grüße
Jo
Hallo bgewehr
ich wollte mal das widget_homematic.html testen bekommen aber nur folgenden Fehler!
smartVISU
21:32, 30.12, v2.8
--------------------------------------------------------------------------------
Error accoured in twig-template engine!
error: Unexpected character "&"
file: widget_homematic.html
line: 539
--------------------------------------------------------------------------------
Muss ich noch weitere Dateien im page - Verzeichnishaben oder was kann es sein.
Danke
Lutz
Zitat von: bgewehr am 30 Dezember 2014, 21:15:29
Define myfritzbox FRITZBOX, das Modul ist recht neu, glaube ich.
Danke für den Hinweis. Ich dachte Du nutzt die FritzBox-Anmeldung aus der Konfigurationsseite von smartVISU.
Grüße Jörg
hat schon jemand einen HM-Dimmer mal eingebaut?
Kann mir da mal jemand die Zeile dafür schicken?
So geht die leider nicht:
{{ homematic.dimmer('WZ.Dimmer', 'slider', 'wz_value', 'wz_min', 'wz_max', 'wz_step') }}
Nimm den hier:
{{ device.dimmer(id, txt, gad_switch, gad_value, min, max, step) }}
Also:
{{ device.dimmer('meinDimmer', 'Stehlampe', 'Mein_switch', 'Mein_value', 0, 100, 1) }}
Gad_Editor:
Mein_switch per OnOff an state und Mein_value Direct an pct!
Hallo allerseits,
Ich konnte bereits alles erfolgreich aufsetzen allerdings habe hier an mehreren stellen gelesen das man nicht von hand in die config.ini eingreifen soll anders hab ich es aber nicht hinbekommen wenn ich in der konfigurationsseite von sv änderungen vornehme und unten auf save drücke passiert nichts, momentan geht mir noch nicht so recht ein licht auf woran es liegt. Die von hand editierte config.ini funktioniert bei mir.
Nun zu meinem ersten wirklichen Problem, Ich habe eine Keymatic Türsteuerung integriert und mit 3 simplen basic.buttons jeweils 1 gad definiert, die im GAD edit per direct dann jeweils ein cmd set bekommen haben (lock, unlock, open) soweit so gut, "unlock" und "open" funktionieren aber der dritte button für "lock" funktioniert nicht, jemand ne idee?
Nächstes problem tauchte mit der RGB steuerung auf auch diese konnte ich erfolgreich konnektieren allerdings werden die ausgewählten farben nicht korrekt übertragen, hier bin ich etwas irritiert von der gad definierung und hinterher im gad edit kann mir da jemand eventuell auf die sprünge helfen?
In der Demo von sv war eine schöne runde farbkarte bzgl. RGB farben zu sehen irgendwie finde ich die nicht, bisher habe ich kleine farbquadrate?
Zitat von: herrmannj am 25 Dezember 2014, 19:02:19
Was mich freut ist das sofort widgets erstellt werden (@Bernd: HM rtr: TOP!). Hier sollten wir vielleicht überlegen die in ein gemeinsames git zu legen. Bernd hat ja schon eins angelegt, vielleicht ist Rudi auch damit einverstanden das wir das im sf mit unterbringen.
Was meint ihr ?
Um auf dieses Thema nochmal zurückzukommen:
Da ich tagelang damit beschäftigt war, dem LaCrosse Sketch beizubringen, dass er auch einen RFM69CW beherscht (das war ungefähr 3,75 mal so viel Arbeit wie gedacht) will ich nun endlich an dem Widget für die LaCrosse Temperatursensoren weiter machen.
Ist die repository-Frage schon irgendwie geklärt?
Ideal wäre ein "alles zusammen" repository in dem fronthem und die widgets enthalten sind.
Und: die Visualisierung läuft nun schon seit dem 24 Dezember 2014, 01:21 ohne Probleme oder Ausfälle (wenn man mal von so Kleinigkeiten wie rereadcfg absieht :) )
Ist mit fronthem und SmartViso eigentlich so etwas möglich wie, dass man auf einer Seite nur die Fenster anzeigt, die nicht closed sind? In FHEMWEB ist sowas aktuell sehr leicht mit der ReadingsGroup realisierbar (mit devspec). In SmartViso fällt mir aktuell nur die Möglichkeit ein, tatsächlich alle Fenster auf der Seite einzubinden und dann die geschlossenen auszublenden.
hi,
ich komme nicht weiter.
Cubietruck mit aktuellem FHEM und der genannten Dateien aus dem Thread.
DEF
192.168.178.22
NAME
SV1
NR
414
NTFY_ORDER
50-SV1
STATE
???
TYPE
fronthemDevice
Ich sehe die GADs. (hier eine einfache IT Steckdose)
gad: Tannenbaum
device: Tannenbaum
reading: state
Converter: OnOff
in SV
Domotiga
Adresse: IP des FHEM
Port2121
Realtime: ON
SV auf RPI:
Das Device in SV habe so angelegt
{% extends "rooms.html" %}
{% block content %}
<div class="preblock">
</div>
<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>Tannenbaum</h3>
<table width="90%">
<tr><td align="left" width="100px">
{{ basic.switch('switch01', 'Tannenbaum') }}
<td>Tannenbaum</td></tr>
</table>
</div>
</div>
</div>
{% endblock %}
aber die Verbindung kommt nicht mehr zustande.
Zitat von: hyper2910 am 31 Dezember 2014, 09:20:25
[...]
aber die Verbindung kommt nicht mehr zustande.
Hallo,
kann es sein, dass Dein FHEM abgestürzt ist? Hast Du read und write für den Rechner, von dem aus Du testest ausgewählt?
schöne Grüße
Jo
Hi,
read and write sind angehakt
FHEM läuft 1a.
von dort kann ich alles schalten!
Habe auch schonmal alles "reboot"et!
Gruss Dirk
Ich gehe mal davon aus, dass Du nach dem Anlegen des gad's nichts mehr an der IP-Konfiguration geändert hast, so dass generell die Verbindung funktionieren sollte. Hast Du testweise mal den converter "direct" ausgewählt?
Ansonsten wäre es wichtig zu verstehen, was Du nach dem Anlegen geändert hast, dass es jetzt nicht mehr geht.
schöne Grüße
Jo
Zitat von: hyper2910 link=topic=30909.msg237774#msg237774
gad: Tannenbaum
device: Tannenbaum
reading: state
Converter: OnOff
Zitat
Hier fehlt der Set cmd: ebenfalls state
in SV
Domotiga
Adresse: IP des FHEM
Port2121
Realtime: ON
OK!
Das Device in SV
{{ basic.switch('switch01', 'Tannenbaum') }}
OK!
ein kleiner schönheitsfehler: die 3 svg (desktop, arrow-up/down) sind auch im darkstyle schwarz, schwarz auf schwarz ist nicht so toll.
ansonsten bräucht ich mal nen css tip:
- wenn man das fenster des smartvisu zusammenschiebt verdrenkt der content das menu -> ich bekomms nicht hint das dann gescrolled wird und beides immer zu sehen ist
@cruiser: wie hast Du die Datei erstellt? Windows macht hier falsche Zeilenumbrüche, nimm einen Editor wie notepad++ dafür, der macht das richtig!
Zitat von: chris1284 am 31 Dezember 2014, 10:10:21
ansonsten bräucht ich mal nen css tip:
- wenn man das fenster des smartvisu zusammenschiebt verdrenkt der content das menu -> ich bekomms nicht hint das dann gescrolled wird und beides immer zu sehen ist
Du hast sicher einen Fehler mit einer nicht geschlossenen Klammer, einem fehlenden </..> tag oder einer nicht korrekten table. Schau noch mal genau durch!
Zitat von: bgewehr am 31 Dezember 2014, 10:11:26
@cruiser: wie hast Du die Datei erstellt? Windows macht hier falsche Zeilenumbrüche, nimm einen Editor wie notepad++ dafür, der macht das richtig!
Ich hatte mir dier Datei hier https://github.com/bgewehr/smartVISU (https://github.com/bgewehr/smartVISU) runter geladen. Werde es noch mal mit notepad++ und neu erstellen versuchen.
Zitat von: karl0123 am 31 Dezember 2014, 08:05:39
Ist mit fronthem und SmartViso eigentlich so etwas möglich wie, dass man auf einer Seite nur die Fenster anzeigt, die nicht closed sind? In FHEMWEB ist sowas aktuell sehr leicht mit der ReadingsGroup realisierbar (mit devspec). In SmartViso fällt mir aktuell nur die Möglichkeit ein, tatsächlich alle Fenster auf der Seite einzubinden und dann die geschlossenen auszublenden.
Kann ReadingsGroup spezialisiert vmtl besser - mir würde jetzt auch ad-hoc nur einfallen alle Fenster einzubinden und dann mit basic.sysmbol zu arbeiten.
Vielleicht gibt es aber auch andere Möglichkeiten, fhem hat da ja viel zu bieten. Evtl kannst Du ja readingsGroup (oder structur ?) nutzen um das Symbol darzustellen und ein Textfeld um die Fenster (Text) anzuzeigen ??
vg
jörg
Zitat von: cruser1800 am 31 Dezember 2014, 11:06:31
Ich hatte mir dier Datei hier https://github.com/bgewehr/smartVISU (https://github.com/bgewehr/smartVISU) runter geladen. Werde es noch mal mit notepad++ und neu erstellen versuchen.
Das widget ist in Ordnung, lief sofort. Muss also am kopieren liegen
vg
jörg
Zitat von: HCS am 31 Dezember 2014, 01:05:41
Ist die repository-Frage schon irgendwie geklärt?
Ideal wäre ein "alles zusammen" repository in dem fronthem und die widgets enthalten sind.
https://github.com/bgewehr/smartVISU
https://github.com/bgewehr/fronthem
Hi @all,
ich habe festgestellt das die Webviewcontrol auf android keine websockets unterstützt, scheint wohl erst ab kitkat zu gehen (ich bin bei den namings immer unsicher, hab hier zb ein 4.2.2, glaube das wäre jelly bean...).
Ich habe zwar erste work-arounds - ist aber komplexer als ich dachte (isses ja eigentlich immer).
Hat jemand von Euch sv auf einem Tab laufen ? Mich würden hier Erfahrung, verwendete Versionen etc interessieren.
vg
jörg
Zitat von: karl0123 am 31 Dezember 2014, 08:05:39
Ist mit fronthem und SmartViso eigentlich so etwas möglich wie, dass man auf einer Seite nur die Fenster anzeigt, die nicht closed sind? In FHEMWEB ist sowas aktuell sehr leicht mit der ReadingsGroup realisierbar (mit devspec). In SmartViso fällt mir aktuell nur die Möglichkeit ein, tatsächlich alle Fenster auf der Seite einzubinden und dann die geschlossenen auszublenden.
Schau mal im Demohaus von Alber:
{% block content %}
<h1><img class="icon" src='{{ icon0 }}fts_shutter.png'/>Status Rolllaeden</h1>
<div class="preblock">
</div>
<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>Erdgeschoss</h3>
{% import "widgets/widget_shutter_small.html" as smallshutter %}
{{ smallshutter.smallshut('sshut_wohnen_westen', 'Wohnen Westen', '0/2/21/1.001', '0/2/22/1.001', '0/2/25/5.001') }}
{{ smallshutter.smallshut('sshut_wohnen_sueden', 'Wohnen Süden', '0/2/11/1.001', '0/2/12/1.001', '0/2/15/5.001') }}
{{ smallshutter.smallshut('sshut_wohnen_giebel', 'Wohnen Giebel', '0/2/1/1.001', '0/2/2/1.001', '0/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_kueche_sueden', 'Küche Süden', '1/2/1/1.001', '1/2/2/1.001', '1/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_kueche_osten', 'Küche Osten', '1/2/11/1.001', '1/2/12/1.001', '1/2/15/5.001') }}
{{ smallshutter.smallshut('sshut_gaeste_osten', 'Gäste Osten', '2/2/1/1.001', '2/2/2/1.001', '2/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_gaeste_norden', 'Gäste Norden', '2/2/11/1.001', '2/2/12/1.001', '2/2/15/5.001') }}
{{ smallshutter.smallshut('sshut_gaestewc_norden', 'GästeWC Norden', '3/2/1/1.001', '3/2/2/1.001', '3/2/5/5.001') }}
</div>
</div>
</div>
<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>Dachgeschoss</h3>
{{ smallshutter.smallshut('sshut_schlafen_sueden', 'Schlafen Süden', '6/2/1/1.001', '6/2/2/1.001', '6/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_schlafen_westen', 'Schlafen Westen', '6/2/11/1.001', '6/2/12/1.001', '6/2/15/5.001') }}
{{ smallshutter.smallshut('sshut_kind_sueden', 'Kind Süden', '7/2/1/1.001', '7/2/2/1.001', '7/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_kind_osten', 'Kind Osten', '7/2/11/1.001', '7/2/12/1.001', '7/2/15/5.001') }}
{{ smallshutter.smallshut('sshut_arbeiten_osten', 'Arbeiten Osten', '8/2/1/1.001', '8/2/2/1.001', '8/2/5/5.001') }}
{{ smallshutter.smallshut('sshut_bad_westen', 'Bad Westen', '9/2/1/1.001', '9/2/2/1.001', '9/2/5/5.001') }}
</div>
</div>
</div>
{% endblock %}
Zitat von: herrmannj am 31 Dezember 2014, 11:23:12
Hi @all,
ich habe festgestellt das die Webviewcontrol auf android keine websockets unterstützt, scheint wohl erst ab kitkat zu gehen (ich bin bei den namings immer unsicher, hab hier zb ein 4.2.2, glaube das wäre jelly bean...).
Ich habe zwar erste work-arounds - ist aber komplexer als ich dachte (isses ja eigentlich immer).
Hat jemand von Euch sv auf einem Tab laufen ? Mich würden hier Erfahrung, verwendete Versionen etc interessieren.
vg
jörg
Habe ein "Volkstablett" mit Android 2.3.1 - da isses langsam, aber alles geht mit opera!
Zitat von: herrmannj am 31 Dezember 2014, 11:23:12
Hat jemand von Euch sv auf einem Tab laufen ? Mich würden hier Erfahrung, verwendete Versionen etc interessieren.
Ja. Google Nexus 5 mit Android 5.0.1 im Chrome und im Dolphin Browser, beides einwandfrei schnell und ohne Probleme.
Zitat von: bgewehr am 31 Dezember 2014, 11:23:44
Schau mal im Demohaus von Alber:
[...]
Das ist nicht ganz, was ich suche. Dort wird alles angezeigt. Auch nett. Aber ich würde gerne auf meiner Alarmanlagen-Schaltseite nur die Fenster anzeigen, die auch offen sind. Ich habe das aktuell über jquery gelöst, in dem ich schaue, welches Symbol gerade verwendet wird. Alle Devices mit "closed" im image werden ausgeblendet. Das ist allerdings nicht wirklich elegant.
@Karl: Das fertige Basic symbol erscheint nur wenn der entsprechende Wert übermittelt wird.
Stimmt. Es reicht ja ein Symbol. Manchmal sieht man den Wald vor lauter Bäumen nicht.
Geht ähnliches auch mit einem Switch?
Gibt es eigentlich eine Möglichkeits gads im FHEM fronthemDevice auf schnelle Art und Weise wieder los zu werden, wenn man mal einen Demoraum probiert hat?
Zitat von: karl0123 am 31 Dezember 2014, 11:38:38
Das ist nicht ganz, was ich suche. Dort wird alles angezeigt. Auch nett. Aber ich würde gerne auf meiner Alarmanlagen-Schaltseite nur die Fenster anzeigen, die auch offen sind. Ich habe das aktuell über jquery gelöst, in dem ich schaue, welches Symbol gerade verwendet wird. Alle Devices mit "closed" im image werden ausgeblendet. Das ist allerdings nicht wirklich elegant.
Du das brauchste gar nicht, http://www.smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.symbol kann das doch alleine. Da kannste sogar mehrere gads verknüpfen. (das demo unter sv.de scheint manchmal zu hängen, bei mir gings grad nicht...)
vg
jörg
Tante edith: sorry Bernd, warst schneller :)
Zitat von: herrmannj am 25 Dezember 2014, 19:02:19
Eine gute Inspiration sind da die Demohäuser, ein Tip dazu: wer da rein schaut sollte vorher den driver auf offline schalten weil sich sonst fronthem die cfg der Demohäuser merkt. Kann man zwar löschen, sind aber 2 clicks 50 ;)
8)
@Jo,
nach den beiden Defines habe ich nichts mehr geändert.
nur seit dem 2xNeugestartet, (beide Systeme)
Die Anzeige der GADs hat dort beim aller ersten mal ca. 2Min gedauert.
Hier fehlt der Set cmd: ebenfalls state
habe ich auch mal gesetzt, aber keine Änderung!
Morgen kann ich dann weiter testen
Zitat von: bgewehr am 31 Dezember 2014, 11:24:58
Habe ein "Volkstablett" mit Android 2.3.1 - da isses langsam, aber alles geht mit opera!
Jo, opera ging - wollte ja aber wvc - und das hat sich echt verteidigt. Sach ma, kannste :) Dir vorstellen da auch irgendein 4er upzugraden ?
Ich würde (WVC) ab 4 unterstützen sonst wird der aufwand noch deutlich höher. Also opera ist ja sowieso laufend, das bleibt natürlich
vg
jörg
Zitat von: herrmannj am 31 Dezember 2014, 11:52:22
(das demo unter sv.de scheint manchmal zu hängen, bei mir gings grad nicht...)
Die 2.7 hakt seit gestern. Ich nutze grad die 2.6 um zu lernen. Also bspw.
http://www.smartvisu.de/docu/2.6/index.php?page=basic/widget_basic.symbol (http://www.smartvisu.de/docu/2.6/index.php?page=basic/widget_basic.symbol)
Die funktioniert.
Morgen,
hat jemand zufällig MAX Thermostate mit sv laufen? Habe die Thermostate über das rtr Widget eingebunden.Wenn ich die Temperatur ändere(in 1° Schritten)überträgt sv jeden Schritt einzeln. Das führt dazu das nach einigen Änderungen die Credits aufgebraucht sind und fhem warten muss.Lässt sich der geänderte Wert irgendwie speichern und erst nach x Sekunden übertragen?Ein Schieberegler im rtr Widget würde mir auch weiterhelfen.Habe allerdings in der Doku nichts gefunden.Hat das jemand anders gelöst?
Gruß
Jakob
@Jörg: Bitte erst die Plots , dann UTF-8...?
@Gorbi: wir brauchen an mehreren Stellen noch verzögerndes Sendeverhalten, auch bei den Heizungsregelungen und den Rollladen! Wenn dir was einfällt, wie man das einfach lösen kann, ich helfe gerne mit!
@Jörg: ist der Browser, der in der Wvc App benutzt wird, frei wählbar?
Zitat von: herrmannj am 31 Dezember 2014, 11:23:12
Hat jemand von Euch sv auf einem Tab laufen ? Mich würden hier Erfahrung, verwendete Versionen etc interessieren.
Android 4.4.4 in opera und google-browser alles super.
in wvc "Bitte warten" und es erscheint nur das menue, daten bekommt er nicht geladen
Zitat von: bgewehr am 31 Dezember 2014, 12:20:14
@Gorbi: wir brauchen an mehreren Stellen noch verzögerndes Sendeverhalten, auch bei den Heizungsregelungen und den Rollladen! Wenn dir was einfällt, wie man das einfach lösen kann, ich helfe gerne mit!
Danke für die Info.Ich werde mal überlegen ::)
@Jörg @Gorbi wir müssten sowas wie eine command Queue bauen, die über einen Oarameter erst dann wirklich auf Io feuert, wenn seit xxx mS kein neuer Command eingegangen ist! Das klingt aber so, als wenn das am besten bei Jörg im Converter aufgehoben wäre. Allein mit sv-Mitteln wird das glaube ich schwierig!
ja, denke ich auch. in sv machen die das so (im slider) der feuert nach 400ms. Aber ein converter dafür hat einen mMn eine höhere Wiederverwendbarkeit.
@Gorbi: kannste nicht bis dahin das Textinputfeld von Bernd nehmen ?
vg
Zitat von: chris1284 am 31 Dezember 2014, 12:26:15
Android 4.4.4 in opera und google-browser alles super.
in wvc "Bitte warten" und es erscheint nur das menue, daten bekommt er nicht geladen
In 4.4 könnte (?) das theoretisch im wvc laufen, ansonsten genau das Thema, fehlender ws. Wobei wir da was hinbekommen, ein funktionierender prototyp liegt direkt neben mir -
geht nicht, gibts nicht !
Zitat von: bgewehr am 31 Dezember 2014, 12:22:36
@Jörg: ist der Browser, der in der Wvc App benutzt wird, frei wählbar?
ne leider nich, sonst hätten wir das Thema gar nicht.
Zitat von: bgewehr am 31 Dezember 2014, 12:14:16
@Jörg: Bitte erst die Plots , dann UTF-8...?
UTF-8 ist gesetzt. Ich würde gern so ping-pong im modul vorgehen - Fehler beseitigen -> neue Features -> Fehler beseitigen ....
Wenn ich anfange neue Sachen einzubauen kann man sich schnell verzetteln.
Plan wäre noch bis Mitte nächster Woche abzuwarten (dann gibts noch mehr Langzeiterfahrung), dann Liste machen und die bis dahin aufgelaufenen Fehler zu beseitigen. Im nächsten Wurf dann Features. Da sehe ich aktuell auch plots auf Platz 1. Damit die anständig umgesetzt werden sind aber einige Tage Arbeit notwendig.
Ansonsten (meine ich) sind ja keine großen Bugs aufgetreten: Die Stabilität scheint, dort wo die Installation gemeistert ist, gut zu sein
(bis auf rereadcfg, da sind noch mal einige Umbauten notwendig).
insofern kann man das wvc Ding ein wenig parallel fahren
vg
jörg
Zitat von: herrmannj am 31 Dezember 2014, 11:58:15
Sach ma, kannste :) Dir vorstellen da auch irgendein 4er upzugraden ?
Klar, die 100€ müssen eh bald investiert werden -> WAF des Volkstabletts=0! ;-)
na denn (und seh ich auch so)
bzgl der plots: weisste, mir ist Stabiltät da grundsätzlich wichtiger als features, weil sie Nachhaltigkeit erzeugt. In einigen Jahren erinnert sich doch niemand mehr dran ob die plots nun in kw3,5,7 / 15 liefen.
Da fragst Du Dich, läufts ?, ist es robust ? kann ich mich drauf verlassen ?. Daher... (ich versteh den "will haben Faktor" genau, bin ja auch nicht frei davon ;) )
vg
Der Erfolg gibt Dir Recht, Jörg! Alles ist bisher super stabil und wirklich sauber umgesetzt!
Ich zwinge mich zur Geduld...
@Jörg: Kann man dem WS irgendwie bei der Arbeit zusehen?
Nur bedingt, ein Teil landet in fhem log (die msg), ein Teil kannst Du im browser in der console sehen. Ansonsten ist so ein ws aber ein komplexeres Protokoll (halt http plus Erweiterung) - da müsste man sniffen.
Hast Du was spezielles im Sinn ? Vielleicht kann ich Dir dann einen einfachere Weg nennen.
vg
jörg
Zitat von: herrmannj am 31 Dezember 2014, 13:52:01
Hast Du was spezielles im Sinn ? Vielleicht kann ich Dir dann einen einfachere Weg nennen.
Reine Neugier! Sniffen werde ich mal ausprobieren - wireshark habe ich noch irgendwo...
Hallo,
wollte mal meine Erfahrungen mitteilen. FHEM läuft jetzt stabil auf Debian, die Windows-Version von FHEM habe ich jetzt auf Eis gelegt. SmartVisu läuft auch sehr stabil und das einbinden von Devices funktioniert nach ein bisschen Übung und Einarbeitung (und auch den ersten Fehlern ;))auch sehr einfach und schneller als ich dachte.
Und was ich noch sagen muss ist, dass die ganze Einrichtung und Programmierung selbst erklären ist, was ich im übrigen super finde.
viele Grüße
Alexander
Zu meinem Problem von gestern mit dem Ausblenden von gewissen Devices: Die Lösung mit basic.symbol ist ka leider nicht schaltbar. Ich habe jedoch hier ein Widget gefunden, mit dem das ganze auch mit einem Switch funktioniert:
http://knx-user-forum.de/smartvisu/31181-neues-widget-nur-aktive-lampen-anzeigen-ausschalten-ermoeglichen.htm (http://knx-user-forum.de/smartvisu/31181-neues-widget-nur-aktive-lampen-anzeigen-ausschalten-ermoeglichen.htm)l
Lernt ihr die "{% Sprache" auch wie ich mühevoll aus Beispielen oder habt ihr was gefunden, wo man mal nachlesen kann, was es da so gibt?
Hier mal der erste Anlauf vom "LaCrosse widget":
Im Verzeichnis der Page ein Verzeichnis widgets erstellen und die lacrosse.html reinwerfen
in rooms.html nach
{% extends "base.html" %}
hinzufügen:
{% import "widgets\\lacrosse.html" as LaCrosse %}
Testseite:
{% extends "rooms.html" %}
{% block content %}
<h1><img class="icon" src='{{ icon0 }}temp_inside.png'/>Übersicht</h1>
<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>Temperaturen</h3>
<table width="100%">
<tr><td>{{ LaCrosse.tx29dth("Outside", "Außen", "Temperature_Outside", "icons/sw/scene_day.png") }}</td></tr>
<tr><td>{{ LaCrosse.tx29dth("HobbyCellar", "Hobbykeller", "Temperature_Cellar_Hobby", "icons/sw/scene_office.png") }}</td></tr>
<tr><td>{{ LaCrosse.tx29dth("StorageCellar", "Lagerkeller", "Temperature_Cellar_Storage", "icons/sw/scene_storeroom.png") }}</td></tr>
<tr><td>{{ LaCrosse.tx29dth("Mobile1", "Test-Sensor 1", "Temperature_Mobile1") }}</td></tr>
<tr><td>{{ LaCrosse.tx29dth("Mobile2", "Test-Sensor 2", "Temperature_Mobile2", "icons/sw/scene_bath.png") }}</td></tr>
</table>
</div>
</div>
</div>
{% endblock %}
Die Parameter von LaCrosse.tx29dth:
Eindeutige ID
Beschriftung
gad-Prefix
icon (optional)
wenn kein icon übergeben wird, zeigt das widget ein Thermometer an.
Beispiel:
LaCrosse.tx29dth("Outside", "Außen", "Temperature_Outside", "icons/sw/scene_day.png")
erwartet folgende GADs in FHEM:
Temperature_Outside.battery
Temperature_Outside.humidity
Temperature_Outside.temperature
Die angehänge Hardcopy zeigt dieses Beispiel auf einem Google Nexus 5
Im Lagerkeller ist die Batterie schwach.
Zitat von: HCS am 31 Dezember 2014, 15:40:34
Lernt ihr die "{% Sprache" auch wie ich mühevoll aus Beispielen oder habt ihr was gefunden, wo man mal nachlesen kann, was es da so gibt?
Ich schau immer hier:
http://www.smartvisu.de/docu/2.7/index.php
Da schaue ich auch. Die widgets sind ja dokumentiert. Ich meinte eher so Dinge wie:
{% if ... %}
...
{% endif %}
usw.
Da habe ich auch noch keine Quelle entdeckt. Twig könnte ein Stichwort sein...
http://twig.sensiolabs.org/
@HCS: Das LaCrosse Widget passt auch auf sehr viele andere Temp/Hum Sensoren. Könnte man das nicht direkt "verallgemeinern"?
Hallo,
ich hätte mal eine Frage zu einem HomeMatic Unterputz-Schalteraktor (HM-LC-Sw1PBU-FM). Wenn ich bei diesem den Converter auf OnOff setze, kann ich über sv nur einschalten, ausschalten geht über sv nicht, außerdem wird mir der Status in sv nicht angezeigt (bleibt weiß und wird nicht orange, wenn angeschaltet).
Habe ich den falschen Converter genommen oder muss ich den Schaltaktor anders in sv definieren?
Aktuelle Definition in sv:{{ basic.switch('Deckenlampe_Flur_OG', 'Deckenlampe.Flur_OG.basic.switch', icon1~'light_light_dim_100.png', icon0~'light_light.png') }}
Viele Grüße und einen guten Rutsch ins neue Jahr!
Alexander
Zitat von: karl0123 am 31 Dezember 2014, 16:38:34
@HCS: Das LaCrosse Widget passt auch auf sehr viele andere Temp/Hum Sensoren. Könnte man das nicht direkt "verallgemeinern"?
Ja. Könnte Sinn machen.
Wäre eh noch zu klären, wie das werden soll. Ob jeder, der Widgets macht, ein File beisteuert, oder zusammenpassende Dinge in einem gemeinsamen widget file gesammelt werden. Da würde ein repository dann wieder hilfreich sein.
Ich denke, dass da eine gewisse Linie rein sollte.
Aber momentan sind wir sowieso eher in einer Experimentierphase.
Zitat von: avg123-de am 31 Dezember 2014, 16:40:28
Hallo,
ich hätte mal eine Frage zu einem HomeMatic Unterputz-Schalteraktor (HM-LC-Sw1PBU-FM). Wenn ich bei diesem den Converter auf OnOff setze, kann ich über sv nur einschalten, ausschalten geht über sv nicht, außerdem wird mir der Status in sv nicht angezeigt (bleibt weiß und wird nicht orange, wenn angeschaltet).
Habe ich den falschen Converter genommen oder muss ich den Schaltaktor anders in sv definieren?
Aktuelle Definition in sv:{{ basic.switch('Deckenlampe_Flur_OG', 'Deckenlampe.Flur_OG.basic.switch', icon1~'light_light_dim_100.png', icon0~'light_light.png') }}
Viele Grüße und einen guten Rutsch ins neue Jahr!
Alexander
Converter OnOff ist richtig, wenn reading und set cmd auf state stehen.
Zitat von: bgewehr am 31 Dezember 2014, 16:26:49
http://twig.sensiolabs.org/
Cool 8)
Danke. Das ist genau das was ich gesucht habe.
Zitat
Converter OnOff ist richtig, wenn reading und set cmd auf state stehen.
Die stehen bei mir beide auf state, jedoch klappt nur anschalten, ausschalten geht nicht, genauso, wie der Status, der immer als aus angezeigt wird.
Du musst die Haken bei read und write setzen.
schöne Grüße
Jo
jaaaa. aber, da muss auch noch was anderes falsch sein.
Wie sind den sie state auf dem hm in den jeweiligen Zuständen ? Das "set_" ist da vlt auch im weg ... ?
juten Rutsch !!!
vg
jörg
Zitat von: HCS am 31 Dezember 2014, 16:05:32
Hier mal der erste Anlauf vom "LaCrosse widget"...
Hallo,
danke für Deine Idee. Grundsätzlich funktioniert das mit allen Temperatursensoren. Von daher folgenden Vorschlag:
LaCroose widget wird TempSensor widget.
Ich habe außerdem die festen Pfade in variable umgewandelt, so dass auch die Icons der entsprechenden Designs gewählt werden.
Bei mir habe ich die widgets nicht in einem separatem Pfad, von daher auch eine andere Einbindung. Muss dann jeder für sich entscheiden.
In rooms.html nach
{% extends "base.html" %}hinzufügen:
{% import "widgets_temp_sensor.html" as TempSensor %}Hier Dein Beispiel entsprechend angepasst:
{% extends "rooms.html" %}
{% block content %}
<h1><img class="icon" src='{{ icon0 }}temp_inside.png'/> Übersicht</h1>
<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>Temperaturen</h3>
<table width="100%">
<tr><td>{{ TempSensor.Data("Outside", "Aussen", "Temperature_Outside", "scene_day.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Wintergarden", "Wintergarten", "Temperature_Wintergarden", "scene_livingroom.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Stairway", "Treppenhaus", "Temperature_Stairway", "scene_stairs.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Bath", "Badezimmer", "Temperature_Bath", "scene_bath.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Mobile2", "Test-Sensor 2", "Temperature_Mobile2") }}</td></tr>
</table>
</div>
</div>
</div>
{% endblock %}
Eindeutige ID
Beschriftung
gad-Prefix
icon (optional)
und ohne Pfadwenn kein icon übergeben wird, zeigt das widget ein Thermometer an.
Grüße Jörg
Hat jemand einen Tipp warum mein Keymatic sich nicht locken lässt?
Die Befehle "open" und "unlock" werden aktzeptiert und funktionieren einwandfrei.
Im GAD Edit sind sie per state, direct, <jeweiliger befehl (open,lock,unlock)> definiert, wie gesagt open und unlock funktionieren tadellos jedoch "lock" will nicht.
Ebenfalls läuft bei mir was mit dem RGB schief die ausgewählten Farben werden nicht korrekt übertragen es ist eher so zufall welche farbe mir dann gezeigt wird? Kann mir da jemand mit der GAD definierung und nem Twig Snippet für sv weiterhelfen?
Bei mir läuft unter Android 5.0.1 Lollipop alles sauber und super schnell, selbes wie für ios8 und iphone...
LG und vorab schonmal einen guten rutsch!
Zitat von: herrmannj am 31 Dezember 2014, 17:48:19
jaaaa. aber, da muss auch noch was anderes falsch sein.
Wie sind den sie state auf dem hm in den jeweiligen Zuständen ? Das "set_" ist da vlt auch im weg ... ?
juten Rutsch !!!
vg
jörg
Ich verwende die gleichen Aktoren und bei mir läuft es mit OnOff und state. Daher denke ich, dass es nur die beiden Haken sind, die noch fehlen zum Erfolg ;)
Von mir auch einen guten Rutsch!
schöne Grüße
Jo
Zitat von: speex am 31 Dezember 2014, 18:06:38
Hat jemand einen Tipp warum mein Keymatic sich nicht locken lässt?
Die Befehle "open" und "unlock" werden aktzeptiert und funktionieren einwandfrei.
Im GAD Edit sind sie per state, direct, <jeweiliger befehl (open,lock,unlock)> definiert, wie gesagt open und unlock funktionieren tadellos jedoch "lock" will nicht.
Ebenfalls läuft bei mir was mit dem RGB schief die ausgewählten Farben werden nicht korrekt übertragen es ist eher so zufall welche farbe mir dann gezeigt wird? Kann mir da jemand mit der GAD definierung und nem Twig Snippet für sv weiterhelfen?
Bei mir läuft unter Android 5.0.1 Lollipop alles sauber und super schnell, selbes wie für ios8 und iphone...
LG und vorab schonmal einen guten rutsch!
Hi
wg RGB, da haste die GADs vertauscht oder die hängen falsch am converter (hatte ich auch, is witzig) . Lass mal morgen (gegen Abend .. 8) ) drüberschaun.
vg und juten Rutsch und so
jörg
Zitat von: Jojo11 am 31 Dezember 2014, 18:08:47
Ich verwende die gleichen Aktoren und bei mir läuft es mit OnOff und state. Daher denke ich, dass es nur die beiden Haken sind, die noch fehlen zum Erfolg ;)
Von mir auch einen guten Rutsch!
schöne Grüße
Jo
unter uns: de Haken werden noch gar nicht ausgewertet, hatte das zum debuggen auf log msg umgestellt... und dann vergessen 8)
ids doppelt vergeben in sv macht auch witzigste Fehler, wenn die settings stimmen da vlt mal schauen ...
vg
jörg
Zitat von: herrmannj am 31 Dezember 2014, 18:28:17
unter uns: de Haken werden noch gar nicht ausgewertet, hatte das zum debuggen auf log msg umgestellt... und dann vergessen 8)
ids doppelt vergeben in sv macht auch witzigste Fehler, wenn die settings stimmen da vlt mal schauen ...
vg
jörg
AHA, diese Vermutung hatte ich auch schon ;D
Stimmt, mit doppelten ID's hatte ich auch schon Probleme. Aber generell funktionieren die Aktoren.
schöne Grüße
Jo
Zitat von: herrmannj am 31 Dezember 2014, 18:26:30
Hi
wg RGB, da haste die GADs vertauscht oder die hängen falsch am converter (hatte ich auch, is witzig) . Lass mal morgen (gegen Abend .. 8) ) drüberschaun.
vg und juten Rutsch und so
jörg
prima, gerne.
Ebenfalls, kommt alle gut rüber. :)
ich habe mir ein HM-CC-RT-DN widget erstellt welches
a) einzelne RT's darstellt
hmccrtdn(id, text , gad_desired, gad_measured, gad_ValvePosition , gad_battery, gad_controlmode, gad_btnlock ,step)beispiel
{{ homematic.hmccrtdn('az_hz_Clima', 'Heizung Arbeitszimmer' , 'az_hz_Clima_desired' , 'az_hz_Clima_measured' , 'az_hz_Clima_ValvePosition', 'az_hz_battery' , 'az_hz_Clima_controlmode' , 'az_hz_bntlock') }}b) gleich eine ganze liste RT's anzeigt
ich übergebe eine liste der devices (ohne Channel)
{% set values = ['az_hz', 'bz_hz', 'ku_hz', 'sz_hz', 'wz_hz'] %}dazu alle optionen die ich will (für alle RT's)
hmccrtdn_list(ids, gad_desired, gad_measured, gad_ValvePosition , gad_battery, gad_controlmode, gad_btnlock ,step)beispiel
{{ homematic.hmccrtdn_list( values, '_Clima_desired' , '_Clima_measured' , '_Clima_ValvePosition', '_battery' , '_Clima_controlmode' , '_bntlock') }}das holt mir alle meine rt's in einem raum mit 2 zeilen code.
anbei das widget
die gads noch:
Zitat"<nameRtClimachannel>_measured" : {
"reading" : "measured-temp",
"type" : "item",
"converter" : "NumDisplay",
"device" : "<nameRtClimachannel>",
"set" : null
},
"<nameRt>_battery" : {
"reading" : "battery",
"type" : "item",
"converter" : "Direct",
"device" : "<nameRt>",
"set" : null
},
"<nameRtClimachannel>_controlmode" : {
"reading" : "controlMode",
"type" : "item",
"converter" : "Direct",
"device" : "<nameRtClimachannel>",
"set" : "controlMode"
},
"<nameRt>_bntlock" : {
"reading" : "R-btnLock",
"type" : "item",
"converter" : "Direct",
"device" : "<nameRt>",
"set" : "regSet"
},
"<nameRtClimachannel>_ValvePosition" : {
"reading" : "ValvePosition",
"type" : "item",
"converter" : "NumDirect",
"device" : "<nameRtClimachannel>",
"set" : null
},
"<nameRtClimachannel>_desired" : {
"reading" : "desired-temp",
"type" : "item",
"converter" : "NumDirect 5, 30",
"device" : "<nameRtClimachannel>",
"set" : "desired-temp"
}
ein bild eines RT's in der liste ist abgehängt. geplant ist noch auf grund der werte (batterie, mode usw) ein iconentsprechend zu zeigen statt text
Frohes Neues smartVISU Jahr erst einmal !
Hi Chris, sieht super aus ...
Wenn wir alle unsere HomeMatic (und andere) Widgets zusammenschmeissen, haben wir in Kürze ein super Toolset zusammen !
Freue mich schon, mein Smart Home System edlich komplett auf fronthem/sv umzustellen ...
VG ak323.
Hallo,
erst einmal ein frohes neues Jahr!!!
ZitatDu musst die Haken bei read und write setzen.
schöne Grüße
Jo
Habe ich gemacht, hatte jedoch erst mal keine Auswirkung.
Zitatjaaaa. aber, da muss auch noch was anderes falsch sein.
Wie sind den sie state auf dem hm in den jeweiligen Zuständen ? Das "set_" ist da vlt auch im weg ... ?
juten Rutsch !!!
vg
jörg
Mir ist heute Morgen eingefallen, das ich eine eventMap angelegt hatte. Die habe ich dann gelöscht und siehe da, es klappt jetzt mit dem Schalten.
ZitatIch verwende die gleichen Aktoren und bei mir läuft es mit OnOff und state. Daher denke ich, dass es nur die beiden Haken sind, die noch fehlen zum Erfolg ;)
Von mir auch einen guten Rutsch!
schöne Grüße
Jo
Jetzt läuft es bei mir auch mit OnOff und state!
viele Grüße
Alexander
Frohes Neues Jahr für alle hier!
Zitat von: ak323 am 01 Januar 2015, 10:41:02
Frohes Neues smartVISU Jahr erst einmal !
Wenn wir alle unsere HomeMatic (und andere) Widgets zusammenschmeissen, haben wir in Kürze ein super Toolset zusammen !
achso, euch auch ein frohes nues :D
ja das sollte man tun. am besten für jeden typ ein macro mit erstmal ALLEN optionen aus denen man sich beim definieren die gewünschten aussuchen kann.
ich baue auch gerade an einem universellen schalter-widget. man gibt ihm typ, styleoptionen und gerätespez. optionen mit. es kann mittlerweile:
-switche (on/off) im 2-buttonstyle
-switche (on/off) im 1-buttonstyle (switch)
-dimmer (on/off/dim)
ein universelles sensorwidget ist bereits im kopf
am hmccrt will ich im _list mode noch eine alias-option einbauen so das alle rts auch mit einem alias versehen werden könne statt dem fhem-gerätenamen
Hi, Chris, soll ich Deine Arbeit mit ins Git aufnehmen? Am besten wäre es, wenn sich die Widget-Entwickler ein GitHub Konto anlegen und dann die gewünschten Änderungen online machen und ein pull request erstellen. Dann kann ich den Code mergen, so dass er wieder allen zur Verfügung steht.
Hallo,
ich hatte gerade begonnen, notifys einzubinden, jedoch klappt das nicht so wie ich das gerne möchte.
Ich habe hierfür in sv zwei basic.button eingerichtet (einen für On und einen für Off). Wenn ich jetzt aber im GAD-Editor den Converter OnOff, sowie bei cmd set on oder off eintrage, passiert nichts, außer dass sich in FHEM das Icon verändert (On oder Off), jedoch geschaltet wird nicht.
viele Grüße
Alexander
Cmd Set muss state sein!
Zitat von: bgewehr am 01 Januar 2015, 12:18:26
Cmd Set muss state sein!
Wenn ich aber state eintrage, kann ich das notify nur anschalten, ausschalten kalappt nicht, egal welchen der zwei Buttons ich nehme.
viele Grüße
Alexander
Zitat von: bgewehr am 01 Januar 2015, 12:12:10
Hi, Chris, soll ich Deine Arbeit mit ins Git aufnehmen? Am besten wäre es, wenn sich die Widget-Entwickler ein GitHub Konto anlegen und dann die gewünschten Änderungen online machen und ein pull request erstellen. Dann kann ich den Code mergen, so dass er wieder allen zur Verfügung steht.
wenn bedarf daan besteht gerne
Zitat von: avg123-de am 01 Januar 2015, 12:22:56
Wenn ich aber state eintrage, kann ich das notify nur anschalten, ausschalten kalappt nicht, egal welchen der zwei Buttons ich nehme.
Moment: einen notify ein oder auszuschalten geht doch mit disable =0 oder 1.
Da musst Du nur einen ganz normalen switch nehmen und mit Converter Direct auf disable setzen:
Item: dein notify
Reading disable
Converter Direct
Set cmd disable
Zitat von: avg123-de am 01 Januar 2015, 12:22:56
Wenn ich aber state eintrage, kann ich das notify nur anschalten, ausschalten kalappt nicht, egal welchen der zwei Buttons ich nehme.
Moment: einen notify ein oder auszuschalten geht doch mit disable =0 oder 1.
Da musst Du nur einen ganz normalen switch nehmen und mit Converter Direct auf disable setzen:
Item: dein notify
Reading disable
Converter Direct
Set cmd disable
@bgwehr: Ist es wirklich möglich darüber ein Attribut zu setzen? Das disablen funktioniert ja nicht über ein set Kommando.
Hab ich noch nicht getestet. Probier mal aus!
Hab ich noch nicht getestet. Probier mal aus!
Attr meinnotify disable 1 funktioniert in fhem, aber ich fürchte Attr ist noch nicht im fronthem Wortschatz, oder, Jörg?
Das meinte ich. Da es kein set-Kommando ist, wird es nicht gehen (über Fronthem/SmartVisu).
Stimmt. Notify hat kein Set cmd für enabled oder disabled. Da bleibt nur die Möglichkeit, ein dummy als switch zu benutzen und im notify abzufragen.
stimmt du müsstes ein attr setzen
also attr <name> disable 1
Ich habe für meine Alarmanlage in FHEMWeb einen großen Countdown für das scharf schalten der Anlage. Dieses realisiere ich über einen Dummy dessen Wert ich über ein at sekündlich verändere. Das ganze funktioniert mit longpoll in FHEMWEb einwandfrei. Ich habe einen echten Countdown.
SmartVisu jedoch bekommt die Änderungen nicht mit (basic.value / converter Direct). Der Wert wird nur aktualisiert, wenn ich die Seite aktualisiere (was zumindest zeigt, dass das gad richtig definiert ist. Woran kann das liegen? Kann der Websocket sowas nicht?
Zitat von: bgewehr am 01 Januar 2015, 13:43:47
Stimmt. Notify hat kein Set cmd für enabled oder disabled. Da bleibt nur die Möglichkeit, ein dummy als switch zu benutzen und im notify abzufragen.
Gesundes Neues @all,
, disable geht noch nicht - ist aber geplant. Braucht einen speziellen converter. Das "disable" kommt mit abweichender Logik über das device "global" rein, der converter bekommt dann das "end-device" als param (in diesem Fall wäre es der Name des notiffy).
vg
jörg
Zitat von: karl0123 am 01 Januar 2015, 14:22:30
Ich habe für meine Alarmanlage in FHEMWeb einen großen Countdown für das scharf schalten der Anlage. Dieses realisiere ich über einen Dummy dessen Wert ich über ein at sekündlich verändere. Das ganze funktioniert mit longpoll in FHEMWEb einwandfrei. Ich habe einen echten Countdown.
SmartVisu jedoch bekommt die Änderungen nicht mit (basic.value / converter Direct). Der Wert wird nur aktualisiert, wenn ich die Seite aktualisiere (was zumindest zeigt, dass das gad richtig definiert ist. Woran kann das liegen? Kann der Websocket sowas nicht?
Doch, doch, dem ws ist das ganz egal der macht das.
Der converter triggert (vereinfacht) beim aktualisieren auf Events in der form "device:reading.*", bzw bei "state" auf "device:.*". Wenn jetzt die Aktualisierung nicht klappt dann hat das irgendwas mit den, vom dummy, erzeugten events zu tun.
Welche events (genau) erzeugt der dummy denn und wie (genau) ist der converter definiert ?
vg
jörg
Events von dem dummy sieht bspw. so aus:
2015-01-01 15:01:43.914 dummy AlarmCountdown 04:49
2015-01-01 15:01:44.915 dummy AlarmCountdown 04:48
2015-01-01 15:01:45.915 dummy AlarmCountdown 04:47
converter habe ich ja oben geschrieben. Der ist als Direct definiert. Grundsätzlich bekommt SmartVisu die Daten ja offensichtlich, da bei einem PageReload der richtige gerade aktuelle Wert geholt werde. Bloß die automatische Aktualisierung funktioniert nicht.
Definition gad:
device: AlarmCountdown
reading: state
converter: Direct
cmd set:
Widget in SmartVisu:
{{ basic.value('AlarmCountdown', 'AlarmCountdown') }}
Hallo,
ein frohes Neues auch von mir in die Runde :)
Mir ist noch etwas aufgefallen: Ich habe jetzt seit einem Tag nicht mehr auf SV geschaut - der server lief aber. Jetzt wollte ich mal wieder loslegen und habe gesehen, dass die Verbindung nicht funktioniert, obwohl in fhem "connected" stand. Erst ein Neustart von fhem hat geholfen.
schöne Grüße
Jo
Zitat von: karl0123 am 01 Januar 2015, 15:05:15
Events von dem dummy sieht bspw. so aus:
2015-01-01 15:01:43.914 dummy AlarmCountdown 04:49
2015-01-01 15:01:44.915 dummy AlarmCountdown 04:48
2015-01-01 15:01:45.915 dummy AlarmCountdown 04:47
converter habe ich ja oben geschrieben. Der ist als Direct definiert. Grundsätzlich bekommt SmartVisu die Daten ja offensichtlich, da bei einem PageReload der richtige gerade aktuelle Wert geholt werde. Bloß die automatische Aktualisierung funktioniert nicht.
Definition gad:
device: AlarmCountdown
reading: state
converter: Direct
cmd set:
Widget in SmartVisu:
{{ basic.value('AlarmCountdown', 'AlarmCountdown') }}
hmm. Wäre denkbar das der ":" die regex durcheinander bringt. Muss ich untersuchen. Kannst Du Deinem at mit wenig Aufwand, testweise, beibringen dort anstelle des ":" was anderes rein zuschreiben ?
Gute Idee. Es funktioniert mit einem Unterstrich tatsächlich einwandfrei. Gut zu wissen, dass es nicht an mir liegt ;)
Jedoch könnt der Doppelpunkt hier häufiger gebraucht werden, wenn man Zeiten übermittelt.
Danke erstmal.
Zitat von: Jojo11 am 01 Januar 2015, 15:06:53
Hallo,
ein frohes Neues auch von mir in die Runde :)
Mir ist noch etwas aufgefallen: Ich habe jetzt seit einem Tag nicht mehr auf SV geschaut - der server lief aber. Jetzt wollte ich mal wieder loslegen und habe gesehen, dass die Verbindung nicht funktioniert, obwohl in fhem "connected" stand. Erst ein Neustart von fhem hat geholfen.
schöne Grüße
Jo
Hi Jo,
im Auge behalten. Wenn es nochmal auftritt zieh mal bitte ein list von fronthem und dem fronthemDevice vor dem Neustart. (mit show internals oder hidden oder wie dad heißt )
vg
jörg
Zitat von: karl0123 am 01 Januar 2015, 15:16:40
Gute Idee. Es funktioniert mit einem Unterstrich tatsächlich einwandfrei. Gut zu wissen, dass es nicht an mir liegt ;)
Jedoch könnt der Doppelpunkt hier häufiger gebraucht werden, wenn man Zeiten übermittelt.
Danke erstmal.
ja, logisch. Ich muss mir mal die regex anschauen. Doppelpunkte sind halt auch trenner. Sehe ich aber genauso das man das braucht. vg
btw, ich aktualisieren im ersten Post die issues die ich so sehe. In der Hauptsache damit ich weiß was ich erledigen muss. Wenn ich da was vergesse gern Bescheid sagen. vg
Zitat von: bgewehr am 24 Dezember 2014, 12:28:33
HM-BL Rolladenschalter für Markenschalter
{{ homematic.hmbl('Roll_Terrasse','', 'T_blind_mov','T_blind_stop','T_blind_pos','','',0,100,5) }}
GAD Editor:
T_blind_mov
mode item
device Mein HM-BL fhem-Rolladenschalter
reading state
converter direct
cmd set state
T_blind_pos
mode item
device Mein HM-BL fhem-Rolladenschalter
reading level
converter NumDirect
cmd set pct
T_blind_stop
mode item
device Mein HM-BL fhem-Rolladenschalter
reading state
converter Direct
cmd set state
Hallo,
hatte gerade meinen ersten Rollladen nach dieser Beschreibung eingerichtet, jedoch sind die Buttons irgendwie vertauscht, wenn ich auf den button für och klicken, geht der Rollladen runter und wenn ich den für runter klicke, geht der Rollladen hoch, das selbe mit dem Slider, hoch ist runter und runter ist hoch, nur der Stopp-Button funktioniert einwandfrei, woran kann das liegen?
viele Grüße
Alexander
Das Problem ist bei mir auch. Die HM-Aktoren definieren 100% als ganz auf und nicht als ganz zu (was zunächst eventuell nicht logisch erscheint). Das Widget bzw. SmartVisu sieht das aber genau andersrum.
bau die Rollladen halt andersrum ran - dann passt das doch ;D
Die Tasten kannste ja umdefinieren - das mit den 100% geht vmtl nicht so einfach - da müsste man im js von sv ändern - oder eine converter nehmen der das "gerade - rückt". oder sieht noch jemand einen einfacheren Weg?
@hermannj - Das RGB Problem hab ich nun in den Griff bekommen, ich hab die reihenfolge nochmal überprüft jetzt läuft es wie gewünscht.
Nun bleibt das Problem mit dem lock bei meinem Keymatic inzwischen glaube ich das Problem gefunden zu haben, wenn ich bei sv auf den button drücke und in der console schaue wird folgendes command abgeschickt:
[io.domotiga] sending data: {"cmd":"item","id":"homematiclock","val":"1"}
base.js:678 [basic.button] update 'room_flur-TürSchliessen': [1]
in der fhem log finde ich dann folgendes:
set FL.Tuerschloss lock 1 : lock requires no parameters
Bei den funktionierenden sieht das wie folgt aus:
[io.domotiga]: update item: homematiclock val: set_unlock
base.js:678 [basic.button] update 'room_flur-TürSchliessen': ["set_unlock"]
Fhem log:
CUL_HM set FL.Tuerschloss unlock 1
wie verhindere ich das die val bei lock hinten angehangen wird?
lg
ja, ich kenn jetzt Deine gad-cfg nicht aber ich vermute Du bist über converter OnOff gegangen ? Mach doch über direct und trage in sv beim on-val "lock" ein - dann geht das. Schau Dir mal im wiki das Beispiel mit der Lichtszene an - macht das gleiche auf einem dummy.
vg
jörg
edit: hier http://www.fhemwiki.de/wiki/Smartvisu/lichtSzene
Hallo avg123-de und karl0123,
ich habe die widgets bei mir auch leicht angepasst. Vielleicht passt das bei Euch ja auch besser so (sicherlich kein perfekter code ???):
{% macro hmbl(id, txt, gad_move, gad_stop, gad_pos, gad_shift, gad_angle, min, max, step) %}
{% import "basic.html" as basic %}
{% set uid = uid(page, id) %}
<div class="blind">
<table align="center" cellpadding="0" border="0">
<tr><td valign="top" colspan="2">{{ txt }}</td></tr>
<tr>
<td valign="top">
<div class="set">{{ basic.button(id~'up', gad_move, '', 'arrow-u', 'on') }}</div>
</td>
<td rowspan="3" align="left" class="pos">
{{ basic.slider(id~'pos', gad_pos, min, max, step, 'bottomup') }}</td>
</tr>
<tr>
<td>
{% if gad_stop %}
<div class="set">{{ basic.button(id~'stop', gad_stop, '', 'delete', 'stop') }}</div> {% endif %}</td>
</tr>
<tr>
<td valign="bottom">
<div class="set">{{ basic.button(id~'down', gad_move, '', 'arrow-d', 'off') }}</div>
</td>
<td valign="bottom">
{% if gad_shift %}
<div class="set">
<span style="float: left;">{{ basic.button(id~'minus', gad_shift, '', 'minus', 0) }}</span>
<span style="float: right;">{{ basic.button(id~'plus', gad_shift, '', 'plus', 1) }}</span>
</div>
{% endif %}
</td>
</tr>
</table>
</div>
{% endmacro %}
Außerdem habe ich noch ein kleineres für eine Übersichtsseite gemacht:
{% macro hmblsmall(id, txt, gad_move, gad_stop, gad_pos, gad_shift, gad_angle, min, max, step) %}
{% import "basic.html" as basic %}
{% set uid = uid(page, id) %}
<div class="blind">
<table align="center" cellpadding="0" border="0">
<tr>
<td width="170px" align="left">{{ txt }}</td>
<td><div class="set">{{ basic.button(id~'down', gad_move, '', 'arrow-d', 'off','micro') }}</div></td>
<td>{% if gad_stop %}<div class="set">{{ basic.button(id~'stop', gad_stop, '', 'delete', 'stop','micro') }}</div> {% endif %}</td>
<td><div class="set">{{ basic.button(id~'up', gad_move, '', 'arrow-u', 'on','micro') }}</div></td>
<td width=50px" align="right">{{ basic.value(id~'pos', gad_pos, '%', 'tag') }}</td>
</tr>
<tr>
<td valign="bottom">
{% if gad_shift %}
<div class="set">
<span style="float: left;">{{ basic.button(id~'minus', gad_shift, '', 'minus', 0) }}</span>
<span style="float: right;">{{ basic.button(id~'plus', gad_shift, '', 'plus', 1) }}</span>
</div>
{% endif %}
</td>
</tr>
</table>
</div>
{% endmacro %}
Alles natürlich nur eine Modifikation der codes auf S. 1 und sicherlich nicht perfekt - aber als Ideengeber evtl. ganz nützlich.
schöne Grüße
Jo
@herrmannj - Danke für den tipp jetzt läufts.
sehr gern, man muss erst reinkommen.
Zitat von: herrmannj am 23 Dezember 2014, 22:36:44
...
Im großen und ganzen sollte man sich darüber im klaren sein das man sich einarbeiten muss, das braucht Zeit (und Geduld).
...
erfolgreich ist man wenn man dran bleibt 8)
viele Spass, vg
jörg
Zitat von: herrmannj am 01 Januar 2015, 15:51:02
bau die Rollladen halt andersrum ran - dann passt das doch
Ich dreh einfach mein Tab um ... dann passt es doch auch !
;D
@jörg
Sry das ich mich erst jetzt wieder melde :-). Ich hoffe ihr seid alle Gut ins neue Jahr gekommen. Ich habe immer noch mit meinem Problem (http://forum.fhem.de/index.php/topic,30909.msg236388.html#msg236388) zu kämpfen.
Ich habe mir das heute noch einmal genauer angesehen. Der Absturz tritt wohl nicht bei Aktivierung des Flugmodus auf, sonder erst wieder wenn der Flugmodus wieder deaktiviert wird und versucht wird sich wieder zu Verbinden. Dann versucht fronthem vermutlich den WebSocket wiederzuverwenden, dies geht aber nicht da die Verbindung zum Socket abgebrochen ist. So kommt es zu einer Unhandled-Exception und somit zum Absturz.
So lange das Gerät sich im Flugmodus befindet, kann ich von anderen Clients noch auf SmartVISU zugreifen.
An meiner Umgebung ist eigentlich nicht aussergewöhnliches:
Banana PI (Bananian Image)
HMLan Adapter
SCC 833 MHz
2x HM-CC Thermostat
3x Intertechno Funksteckdose
2x FS20 Funksteckdose
Gruß
Timo
das wird nicht an Deiner Umgebung liegen - eher daran das wir hier beta #1 haben. Ich verstehe Dich richtig das Du das sauber reproduzieren kannst ?
vg
jörg
Zitat von: herrmannj am 01 Januar 2015, 21:58:50
Ich verstehe Dich richtig das Du das sauber reproduzieren kannst ?
Ja kann ich sauber reproduzieren.
übernehme ich - bis dahin darfst Du Dein iphone im Flieger anlassen. Beruf Dich auf mich :)
vg
jörg
Alles klar :-) würde mich Interessieren wo der Fehler genau lag. Habe leider noch nicht viel mit perl gemacht und im Moment nicht so viel Zeit um mich einarbeiten. Komme eher aus der Windows-Welt ::) :-[ :P.
Gruß
Timo
vmtl wird folgendes passieren:
der fronthemClient hält eine referenz auf die Verbindung, beim neu-connect nach dem Flugmodus macht das iphone aber eine neue auf und der fronthemClient versucht noch auf der alten (mittlerweile ungültigen) zu antworten.
So ganz genau kann ich mir das noch nicht zusammenreimen weil es dagegen eigentlich bereits Maßnahmen gibt die ja in allen anderen Fällen auch greifen. Weil ich aber sowieso diverse Umbauten machen werde kann es sein das ich am Ende nicht genau die Zeile nennen kann. Ist sowieso vmtl eher kein Fehler im Sinne von Syntax sondern im Sinn von falschen Ablauf.
vg
jörg
Hallo Jo,
vielen Dank für deine Änderung, jetzt funktionieren die Buttons bei mir richtig!
viele Grüße
Alexander
Zitat von: herrmannj am 29 Dezember 2014, 12:54:59
btw: ich habe heute schon gelernt das Dirks wvc http://www.fhemwiki.de/wiki/WebViewControl leider keine websockets kann - aber auch das es ein plugin dafür gibt: https://github.com/mkuklis/phonegap-websocket/blob/b7cc3bf50e2aa83bb70ffaf40cfb017c219b7bdc/README.md
Hi Jörg,
ich wollte heute auch mal die Grundlage legen um mit SV arbeiten zu können um die WVC unterstützung mit angehen zu können.
Leider gelingt mir nicht fronthem und fronthemDevice zu definieren.
Ich mache das Ganze schön wie angefordert über das WebUI von FHEM:
define fronthem fronthem
Zitat
Cannot load module fronthem
Fehler aus dem FHEM-Log:
2015.01.02 00:51:32 1: reload: Error:Modul 01_fronthem deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/01_fronthem.pm line 257, near "})
"
2015.01.02 00:51:32 0: Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/01_fronthem.pm line 257, near "})
"
define test fronthemDevice 192.168.178.233
Zitat
Cannot load module fronthemDevice
Fehler aus dem FHEM-Log:
2015.01.02 00:52:43 1: reload: Error:Modul 31_fronthemDevice deactivated:
Type of arg 1 to keys must be hash or array (not private variable) at /opt/fhem/FHEM/31_fronthemDevice.pm line 113, near "$config)
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 173, near "})
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 294, near "})
"
2015.01.02 00:52:43 0: Type of arg 1 to keys must be hash or array (not private variable) at /opt/fhem/FHEM/31_fronthemDevice.pm line 113, near "$config)
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 173, near "})
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 294, near "})
"
Gruß
Dirk
Hey :D Grüße !
schau Dir nochmal die Rechte unter www an. Die beiden module checken. Ich kann Dir noch nicht genau sagen wieso das auftritt (machts bei mir nicht), aber im zweiten (bis dritten Anlauf) hat es bisher dann immer geklappt. Ich bitte dieses Fehlerverhalten des moduls mit der version beta #1 zu entschuldigen :)
vg
jörg
Rechte sind aber 777. Das Sollte also passen.
Wenn ich mir die Zeilen 256ff in 01_fronthem.pm ansehe, wird da versucht die config aus "./www/fronthem/server/$hash->{NAME}/$cfgFile" zu lesen. Diese existiert hier natürlich noch nicht. Somit hat $data->{config} keine Keys. Daher knallt es im foreach in Zeile 256.
keinen Plan warum das bei "allen anderen" funktioniert.
Perl version?
Gruß
Dirk
Ich schau gleich mal rein, bisher bin ich davon ausgegangen das der Fehler durch "von Hand cfg" entsteht, bin aber bereit das zu revidieren.
ws unterstützung im aktuellen 3,5 cordova hab ich laufen. Aber lass uns das mal zusammen legen, ich würde da parallele Entwicklungen doof finden.
Ich hab im übrigen folgende verrückte Idee: einmal für tabs, als wvc style mit tts und so on.
Dazu drei Handy apps nach gleichem schema, aber ohne tts und co. Dafür mit background mode (läuft als prototyp auf android schon) mit notifiactions und mit geo location.
Das sind doch eigentlich (mMn) die beiden Themen die wir für mobilen zugriff brauchen. Ich hab gelesen das Du im Augenblick wenig Zeit hast, ich kann da reingehen (also bin schon, beides läuft ja). Müsste mir jetzt den cfg screen vornehmen. Für mobil fehlt noch auth...
Wie hast Du das eigentlich hinbekommen cordova.js generell (also auch die normalen browser versionen) zu laden ? Bei mir zickt der immer und bremst die dt Variante extrem aus. Für sv ist das nicht so schlimm weil man ja ganz fix ein extra dir dafür machen kann.
vg
jörg
produktiv
This is perl 5, version 18, subversion 2 (v5.18.2) built for arm-linux-gnueabihf-thread-multi-64int
da meckert der nicht. Aber das ich da trotzdem gefordert bin ist mir klar. Mein Plan ist (war eigentlich) noch ein bischen die (bis auf das) ja meist minor bugs zu sammeln und dann eine beta#2 mit allen fixes raus-zubringen.
Aber irgendwie wird der install schon lästig ... ich schau was sich da kurzfristig drechseln lässt ...
Zitat von: herrmannj am 02 Januar 2015, 01:16:22
Dazu drei Handy apps nach gleichem schema, aber ohne tts und co. Dafür mit background mode (läuft als prototyp auf android schon) mit notifiactions und mit geo location.
Ich habe ja noch viele Ideen für WVC.
ZitatIch hab gelesen das Du im Augenblick wenig Zeit hast, ich kann da reingehen (also bin schon, beides läuft ja).
Das ist in der Tat leider ein kleines Problem aktuell.
Ich hoffe und Denke das sich das in den nächsten Tagen etwas entspannt damit ich auch an den anderen projekten (HM-Wired und Universlsensor) weiter machen kann.
Als erstes will ich WVC auf die aktuelle Cordova-Version anheben. Das wird sicher etwas umfangreicher. Dann sollte das webview-controll aber auch performanter laufen. Und da sind dann noch die Tasks im Tracker.
ZitatWie hast Du das eigentlich hinbekommen cordova.js generell (also auch die normalen browser versionen) zu laden ? Bei mir zickt der immer und bremst die dt Variante extrem aus.
Eigentlich werden die WVC-Teile im JS nur initialisiert wenn die App als Container erkannt wird. Ohne App sollte der Code und auch cordova.js inaktiv bleiben.
Zitat von: herrmannj am 02 Januar 2015, 01:31:17
This is perl 5, version 18, subversion 2 (v5.18.2) built for arm-linux-gnueabihf-thread-multi-64int
Bei mir:
This is perl 5, version 12, subversion 1 (v5.12.1) built for i586-linux-thread-multikönnte also an der Perl-Version liegen.
Ich werde das noch mal auf meinem DEV-System am RPI testen.
Gruß
Dirk
ich teste gerade, kann mir nur vorstellen das im eval, wo ja für diesen Fall $data->{config} = {} gesetzt wird, was schief geht. Hast Du über der meldung (#257) die "json-ich-hab-nix" meldung ? Die wird ja im eval gemacht.
Nö. Ich bekomme nur das was ich vorhin gepostet habe als Fehler.
magst Du mal probeweise in 01_fronthem.pm #242 $data so initialisieren:
#my $data->{config} = {};
Ja, aber das führt nicht zum Erfolg.
Wenn ich das foreach von 261-268 auskomentiere klappt das definieren übrigens.
Dann bekomme ich auch den "malformed JSON" Error
2015.01.02 01:53:42 1: fronthem: Error loading cfg file malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /opt/fhem/FHEM/01_fronthem.pm line 247
2015.01.02 01:53:42 1: PERL WARNING: print() on closed filehandle SOCKET at /opt/fhem/FHEM/01_fronthem.pm line 254.
2015.01.02 01:53:42 1: PERL WARNING: print() on closed filehandle SOCKET at /opt/fhem/FHEM/01_fronthem.pm line 255.
2015.01.02 01:53:42 1: PERL WARNING: print() on closed filehandle SOCKET at /opt/fhem/FHEM/01_fronthem.pm line 256.
2015.01.02 01:53:42 2: fronthem: ipc listener opened at port 16384
kommentiere mal bitte gleichzeitig die #246 aus... sorry
#246:
$data = $json->decode($json_text);
das print kommt von Dir..debug. oder ?
Ja stimmt.
ich habe um das foreach mal ein
Zitatif (defined($data->{config}) {
...
}
gebaut.
Dann klappt das auch.
Dann müsste man das in 31_fronthemDevice.pm vermutlich ähnlich machen?
kannste (Biite :) ) trotzdem nochmal die beiden kleinen Änderungen von mir ausprobieren ? Ich denke ich verstehe jetzt WAS passiert.
Das gewünschte (und getestete) Verhalten ist das der json im eval bei nicht existierender cfg einen Fehelr wird und im or do block $data mit einem empty hash vorgeladen wird der vom nachfolgenden foreach ja genau null runden macht. Das foreach ist nur safety falls irgendjemand händisch Unsinn in die cfg schreibt.
Der Schlawiner ist dann nicht die perl Version sondern das JSON Modul was scheinbar auf einigen Systemen den Fehler nicht wirft. Das erklärt auch warum ich das nie nachstellen konnte
Danke schon mal
ZitatDann müsste man das in 31_fronthemDevice.pm vermutlich ähnlich machen?
ja genau. ne, wenn die Mutter ok ist reicht, siehr next post
Alternativ kannste den foreach aus 01_fronthem komplett rauswerfen und darunter den
$hash->{helper}->{config} = $filtered->{config}; auf
$hash->{helper}->{config} = $data->{config};setzen.
fronthemDevice ist nur ein Sekundäreffekt - wenn die Mutter eine korrekte cfg hat (im Zeifel auch den empty hash) läuft das ab werk.
Du meinst
Zitat von: herrmannj am 02 Januar 2015, 01:49:10
magst Du mal probeweise in 01_fronthem.pm #242 $data so initialisieren:
#my $data->{config} = {};
Und das?
Zitat von: herrmannj am 02 Januar 2015, 01:56:26
kommentiere mal bitte gleichzeitig die #246 aus... sorry
#246:
$data = $json->decode($json_text);
Ja, das klappt dann.
Ok, super. Danke - dann haben wir das mit Deiner Hilfe festgenagelt. Blödes JSON Modul. (und: wer hätte das gedacht).
Ich halte es für am besten dann vor das foreach eine Zeile mit
$data->{config} = {} unless (exists($data->{config});
zu schrieben. Der sollte imho dann alles catchen.
ZitatIch halte es für am besten dann vor das foreach eine Zeile mit
$data->{config} = {} unless (exists($data->{config});
zu schrieben. Der sollte imho dann alles catchen.
Kann man machen.
Das funktioniert auch.
define fronthemDevice tut aber noch nicht.
Deine Zeilen von vorhin kann ich da so auch nicht finden.
ja, ich hab da eben nochmal reingeschaut. Der Effekt ist der gleiche wenn der KEY in der Mutter nicht existiert läuft das device (greift auch darauf zu) in die gleiche Falle, andere Stelle.
Du hast aber recht, mach mal bitte noch aus #254 in 01_fronthem
my $filtered;
zu
my $filtered;
$filtered->{config} = {};
weil ja in diesem Fall (keine cfg) der an den helper gereicht wird.
Hab ich drinn.
Das reicht aber noch nicht:
2015.01.02 02:40:32 1: reload: Error:Modul 31_fronthemDevice deactivated:
Type of arg 1 to keys must be hash or array (not private variable) at /opt/fhem/FHEM/31_fronthemDevice.pm line 113, near "$config)
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 173, near "})
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 294, near "})
"
2015.01.02 02:40:32 0: Type of arg 1 to keys must be hash or array (not private variable) at /opt/fhem/FHEM/31_fronthemDevice.pm line 113, near "$config)
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 173, near "})
"
Type of arg 1 to keys must be hash or array (not hash element) at /opt/fhem/FHEM/31_fronthemDevice.pm line 294, near "})
"
die sehen jetzt äußerst mysteriös aus ...
#173 liest die Readings für den Editor aus einem device .... Ich sehe jetzt ad-hoc keinen Grund, bzw Zusammenhang mit den eben identifizierten. Ich hab gerade mal in den perldoc geschaut, in der 5.12 hat sich das Verhalten von keys tatsächlich geändert. Aber a in Bezug auf arrays und b hast Du die ja.
Generell ist es wichtig das die Mutter (01..) bereits lebt wenn das device definiert wird. Rename und co nimmt das modul auch (noch) übel.
Hast Du nach unseren Spielchen von eben nochmal einen kompletten Neustart gemacht ?
ich habs, da ist #2
Starting with Perl 5.14, keys can take a scalar EXPR, which must contain a reference to an unblessed hash or array.
5.12 < 5.14 .....
Ich erstelle morgen eine neue Version, so für die alten perl und so 8).
Für jetzt ist Feierabend.
Danke und vg
jörg
Zitat von: herrmannj am 02 Januar 2015, 03:15:35
Für jetzt ist Feierabend.
Gute Idee.
Hab hier auch grade was kaput gemacht. Ist wohl schon zu spät.
Dann bis morgen. Vermutlich aber erst wieder abends bei mir.
Gruß
Dirk
Hallo zusammen,
ich habe da nochmal etwas gesehen, was ziemlich sicher von SV kommt. In meinem log-file gibt es folgende Einträge:
res
monitor sensor1
res
monitor sensor4
res
monitor sensor5
res
res
res
res
res
res
res
res
res
res
res
res
res
res
res
res
Das "res" habe ich ungefähr 3000x seit gestern Abend. Wohlgemerkt habe ich seitdem nichts mit SV gemacht ::)
schöne Grüße
Jo
Hallo und Frohes Neues,
ich habe mal eine generelle Frage zu VISU! Als ich den Artikel gelesen habe und mir die ersten Hardcopy angeschaut habe, sagte ich mir "WOW, Will ich auch haben" Das alles ist ja noch eine Beta Version. Soll VISU später mal zum Standard zu FHEM gehören? Wann wird die Bet Phase abgeschlossen sein?
Die 10000 Res habe ich auch...
Zitat von: herrmannj am 31 Dezember 2014, 13:05:30
ja, denke ich auch. in sv machen die das so (im slider) der feuert nach 400ms. Aber ein converter dafür hat einen mMn eine höhere Wiederverwendbarkeit.
@Gorbi: kannste nicht bis dahin das Textinputfeld von Bernd nehmen ?
vg
Hallo,
und erstmal frohes neues Jahr!Wo finde ich denn dieses Widget?bzw wurde es überhaupt schon veröffentlicht?
Gruß
So, allen ein frohes neues!
Könnte wieder was testen, jedoch weiß ich nicht was ich noch probieren soll? , wie gehabt, ist die Verbindung von fhem zu sv nicht konstant da. Die gads sehe ich, aber keine Reaktion
Die 10000 Res habe ich auch...
Dito
Zitat von: Jojo11 am 02 Januar 2015, 09:21:33
Hallo zusammen,
ich habe da nochmal etwas gesehen, was ziemlich sicher von SV kommt. In meinem log-file gibt es folgende Einträge:
res
monitor sensor1
....
Das "res" habe ich ungefähr 3000x seit gestern Abend. Wohlgemerkt habe ich seitdem nichts mit SV gemacht ::)
schöne Grüße
Jo
Hi Jo,
yepp, Danke.
Sas sind noch Reste vom debuggen - ich mach kurzfristig eine Beta #2, hauptsächlich wegen dem Issue beim install. Da nehme ich das raus.
vg
jörg
Hallo bjoernbo,
frohes Neues!
Zitat von: bjoernbo am 02 Januar 2015, 10:00:21
Das alles ist ja noch eine Beta Version.
Yes, viel läuft bereits vernünftig. Was an Fehlern auftritt (siehe gestern Nacht) wird beseitigt werden.
Soll VISU später mal zum Standard zu FHEM gehören? Die visu ist ja erstmal völlig unabhängig, es gibt ein Team was die pflegt und weiterentwickelt. Das modul schafft die Verbindung von fhem mit sv und ja, wird ein Teil von fhem. Wir sprechen nicht über ein re-placement für fhemweb sondern einen Zusatz, ein "auch".
Ohne Frage ist fhemweb (und wird es bleiben) für viele user erste Wahl. zB ist (und wird immer bleiben)
der Konfigurationsmauswand für fronthem/sv viel größer.ZitatWann wird die Bet Phase abgeschlossen sein?
Schauen wir mal. Die Kinderkrankheiten sollen raus sein - Stabilität und Nachhaltigkeit sind wichtiger als irgendeine Zeitleiste.
vg
jörg
Zitat von: hyper2910 am 02 Januar 2015, 11:23:24
So, allen ein frohes neues!
Könnte wieder was testen, jedoch weiß ich nicht was ich noch probieren soll? , wie gehabt, ist die Verbindung von fhem zu sv nicht konstant da. Die gads sehe ich, aber keine Reaktion
Hi,
Die auch, ein frohes Neues!
Ich weiß nicht mehr wo "wir" stehen :-).
Mach mal die generellen Dinger, Neustart fhem und sv. Dann schau mal bitte im ersten Schritt
fronthemDevice (fhem) soll auf disconntected stehen. Jetzt mit dem browser sv aufrufen.. (nur ein tab im browser). Geht der state (fast) sofort auf connected ?
vg
jörg
Der state steht immer auf ???
von fronthem vermute ich. Und beim fronthemDevice ?
Von welchem client aus (OS, Typ: tablet, browser etc) greifst Du denn auf sv zu ?
Das Fronthemdevice steht auf ???. Auf sv greife ich via Chrome zu, win 8.1.
Hallo,
bin gerade dabei noch Schalter in sv einzubauen, jetzt aber mit dem basic.flip.
Das funktioniert soweit auch ganz gut, jedoch hätte ich gerne auf dem basic.flip "Umschalter Pufferspeicher" die Bezeichnung der Pufferspeicher (500 oder 1000) stehen.
Ich hatte das mal so definiert gehabt{{ basic.flip('Umschalter_Pufferspeicher', 'Umschalter_Pufferspeicher_basic.flip', '500', '1000') }}
jedoch funktioniert dann der Converter OnOff nicht. Habt ihr eine Idee, wie ich das Umsetzen kann?
Ansonsten muss ich es halt bei on und off belassen, ist ja nur der Optik halber.
Achso: Es handelt sich hierbei um einen HomeMatic Schaltaktor.
viele Grüße
Alexander
Zitat von: hyper2910 am 02 Januar 2015, 13:21:16
Das Fronthemdevice steht auf ???. Auf sv greife ich via Chrome zu, win 8.1.
ok, roger.
Auf welcher IP läuft fhem ?
Welche IP hat der Win 8.1 Rechner ?
Wie genau ist fronthemDevice definiert (am besten den gesamtem Block internals und readings aus der detailview von fhem)
Und bitte hänge mal die config.ini von sv an.
vg
jörg
Zitat von: avg123-de am 02 Januar 2015, 13:24:58
Hallo,
bin gerade dabei noch Schalter in sv einzubauen, jetzt aber mit dem basic.flip.
Das funktioniert soweit auch ganz gut, jedoch hätte ich gerne auf dem basic.flip "Umschalter Pufferspeicher" die Bezeichnung der Pufferspeicher (500 oder 1000) stehen.
Ich hatte das mal so definiert gehabt{{ basic.flip('Umschalter_Pufferspeicher', 'Umschalter_Pufferspeicher_basic.flip', '500', '1000') }}
jedoch funktioniert dann der Converter OnOff nicht. Habt ihr eine Idee, wie ich das Umsetzen kann?
Ansonsten muss ich es halt bei on und off belassen, ist ja nur der Optik halber.
Achso: Es handelt sich hierbei um einen HomeMatic Schaltaktor.
viele Grüße
Alexander
Hi,
ich hoffe mal das ich die Frage richtig verstehe. Das Problem ist das hier eigentlich (bei "on") die "500" die dann von sv kommen in ein "on" Richtung fhem gewandelt werden müssten ? Richtig ? Wenn ja, dafür bräuchte man wirklich einen speziellen converter. Evtl könntest Du einen dummy plus notify auf fhem Seite dazwischen schalten. Der dummy mit setstate 500,1000 und ein notify welches das vom dummy auf den HM bringt.
So einen "Schweizer Taschenmesser converter" hab ich auf der todo - bisher war der aber noch nie praktisch gefragt.
vg
jörg
Kleines Problemchen im GAD-Editor:
Habe mich in SV vertan und folgendes GAD ins fronthemDevice rein bekommen:
{{ HCSCalues.OliLevel }}
und noch einige in der Art.
Wenn man das in der Liste anwählt, erscheint der GAD Editor nicht.
Das Problem sind wohl die doppelten geschweiften.
Habe sie dann mal von Hand aus der fhserver.fronthem.cfg entfernt, nach einem restart wars dann weg.
btw, und wenn Du magst: ich hab hier einen code Schnipsel der dafür sorgt das, auf der linken Seite (raumauswahl) jeweils der Raum in dem Du Dich befindest markiert wird wird (icon), ist ein optisches Ding, finde es aber angenehm und kostet nix ;) :
http://www.fhemwiki.de/wiki/SmartVisu/IconHighlights_in_Menus
Btw#2: denkt bitte (bitte) auch daran das eine oder andere sinnvolle, schöne oder auch unsinnige 8) im Wiki zu verewigen. Ich werde für die nächste Beta einen neuen Post erstellen damit nicht diese unsäglichen 1000 Seiten threads entstehen die keiner mehr durchlesen kann.
Damit würden dann aber die wertvollen Erkenntnisse aus diesem thread ins digitale nirvana sinken - wäre schade.
vg
jörg
Zitat von: HCS am 02 Januar 2015, 13:54:39
Kleines Problemchen im GAD-Editor:
Habe mich in SV vertan und folgendes GAD ins fronthemDevice rein bekommen:
{{ HCSCalues.OliLevel }}
und noch einige in der Art.
Wenn man das in der Liste anwählt, erscheint der GAD Editor nicht.
Das Problem sind wohl die doppelten geschweiften.
Habe sie dann mal von Hand aus der fhserver.fronthem.cfg entfernt, nach einem restart wars dann weg.
perfekt, danke. Nehme ich als issue auf. vg jörg
Zitat von: herrmannj am 02 Januar 2015, 13:56:24
perfekt, danke. Nehme ich als issue auf. vg jörg
Ich habe auch sowas hier bei mir drin
EG.wz.SD.TVLampe.TV.light data-val=Auch das lässt sich nicht löschen oder ändern. Ist vermutlich wegen eines fehlenden Anführungszeichen da rein gekommen und ich verdächtige das Leerzeichen, das Problem mit der fehlenden Editiermöglichkeit zu verursachen.
Kann man in smartVisu auch die Werte im Code/Template/Widget abfragen um zum Beispiel die Farbe eines basic.values zu verändern?
Als Beispiel: Wenn der humidity Wert eines gads über 65% geht, färbe den Wert gelb.
klar, musst Du halt ein wenig js reinbringen. Am besten css class erstellen plus template. Das von mir oben verlinkte wiki Beispiel macht ja nichts anderes, nur eben icon vs room. vg
An JS hatte ich nicht gedacht. Aber wäre das dann auch dynamisch. Soll heißen: ich habe eine Status-Seite und der Wert ändern sich von 64 auf 65. Wird das dann gelb?
Zitat von: marvin78 am 02 Januar 2015, 14:02:07
Ich habe auch sowas hier bei mir drin
EG.wz.SD.TVLampe.TV.light data-val=
Auch das lässt sich nicht löschen oder ändern. Ist vermutlich wegen eines fehlenden Anführungszeichen da rein gekommen und ich verdächtige das Leerzeichen, das Problem mit der fehlenden Editiermöglichkeit zu verursachen.
Ja, vmtl. Generell kann man sich mit den größeren Möglichkeiten auch selber Fehler rein-bauen. Ich frage mich gerade ob ich das wirklich in fronthem abfange oder eben so
ZitatHabe sie dann mal von Hand aus der fhserver.fronthem.cfg entfernt, nach einem restart wars dann weg.
Die Möglichkeiten da "Unsinn" rein zu bekommen sind ja unendlich - muss ich mal drüber nachdenken.
Denk sicherheitshalber an eine Sicherung von der *cfg bevor Du von Hand löschst. Wenn fronthem beim Start eine ungültige (im Sinne eines json) findet erstellt fronthem eine komplett neue.
vg
jörg
Zitat von: karl0123 am 02 Januar 2015, 14:04:47
An CSS hatte ich nicht gedacht. Aber wäre das dann auch dynamisch. Soll heißen: ich habe eine Status-Seite und der Wert ändern sich von 64 auf 65. Wird das dann gelb?
Ne, ganz alleine noch nicht. Du must irgendwo noch eine (js) condition einbauen die dann zum Beispiel via $(..).css() umschaltet. Zweiter Weg dürfte (so wie das Wiki Beispiel) über twig (also template) führen. Ich könnte Dir jetzt nicht auf Anhieb den korrekten code sagen, das muss man suchen und schlussendlich den Besten Weg finden.
Was mglw auch für Dich funktioniert wären zwei basic.symbol mit zusätzlicher Unterstützung aus fhem. Ich benutze so eine Konstruktion für die Lieblingsorchidee meine GöGa. Da steckt ein Feuchtemesser drin und ich hab ein userreading:
userReadings dry {ReadingsVal("wz.clima.orchidee","humidity",0) == 99?'wet':'dry';;}Wenn jetzt die Feuchte unter 99% fällt geht das userReading auf "dry" - und ich nutze das zum Umschalten des symbols in sv und für eine Meldung auf dem display via
http://www.smartvisu.de/docu/2.7/index.php?page=status/widget_status.notify
In Kürze dann auch push aufs mobile ..... :D
vg
Jörg
Zitat von: avg123-de am 02 Januar 2015, 13:24:58
{{ basic.flip('Umschalter_Pufferspeicher', 'Umschalter_Pufferspeicher_basic.flip', '500', '1000') }}
jedoch funktioniert dann der Converter OnOff nicht. Habt ihr eine Idee, wie ich das Umsetzen kann?
Hast Du in fhem schon mal eventmap 500:On 1000:Off probiert? Natürlich mit NumDirect Converter!
Zitat von: karl0123 am 02 Januar 2015, 14:04:47
An JS hatte ich nicht gedacht. Aber wäre das dann auch dynamisch. Soll heißen: ich habe eine Status-Seite und der Wert ändern sich von 64 auf 65. Wird das dann gelb?
So sollte es gehen:
<script type="text/javascript">
$(document).ready(function() {
$(document).delegate('span[class="humidity"]', {
'update': function (event, response) {
if (response>60) $(this).css('color','red');
},
});
});
</script>
Zitatok, roger.
Auf welcher IP läuft fhem ?
Welche IP hat der Win 8.1 Rechner ?
Wie genau ist fronthemDevice definiert (am besten den gesamtem Block internals und readings aus der detailview von fhem)
Und bitte hänge mal die config.ini von sv an.
IP FHEM: 192.168.178.155
IP SV: 192.168.178.22
IP Win8.1 192.168.178.21
fronthemdevice:
define SV fronthem
attr SV room smartvisu
define SV1 fronthemDevice 192.168.178.22
attr SV1 room smartvisu
die config.ini haste mir verschwiegen ;), ein Fehler ist aber hier:
IP Win8.1 192.168.178.21
define SV1 fronthemDevice 192.168.178.22
Das fronthemDevice braucht in der def die IP des Client - nicht die von sv
vg
Jörg
ok, dann hatte ich das falsch verstanden.
Was trage ich ein, wenn ich über einen DYNDNS zugreife?
Gruss Dirk
Hi Dirk,
gehts denn jetzt ?
Dyndns geht noch nicht (kommt mit den certs wenn das alles so funktioniert wie ich hoffe). Ich nehme dafür aktuell vpn, -> löppt !
vg
jörg
hi,
ja scheint es zu tun, die Daten für Sonnenauf/untergang werden übertragen.
Das andere muss ich machen, wenn ich zu hause bin.
Gruss Dirk
... nach Sonnenuntergang :) . Schön das jetzt läuft, viel Spass.
Zitat von: hyper2910 am 02 Januar 2015, 15:06:49
ok, dann hatte ich das falsch verstanden.
Was trage ich ein, wenn ich über einen DYNDNS zugreife?
Bis dahin geht VPN ganz gut!
@Jörg: mir sind drei Fälle begegnet, in denen ich
1.) ein Reading setzen wollte, für das es kein Set gibt -> setreading()
2.) ein Attribut gefragt war und kein Reading -> AttrVal() setattr()
3.) ich wollte den Timestamp eines Readings haben, nicht den Wert -> ReadingsTimestamp()
Ist sowas über spezielle Converter möglich?
Zitat von: bgewehr am 02 Januar 2015, 14:19:20
Hast Du in fhem schon mal eventmap 500:On 1000:Off probiert? Natürlich mit NumDirect Converter!
Hallo bgewehr,
habe ich probiert, jedoch mit eventMap on:500 off:1000. ;)
Jedoch wird mir in sv immer 500 (also on) angezeigt, egal wie er in FHEM steht.
viele Grüße
Alexander
Zitat von: bgewehr am 02 Januar 2015, 16:19:32
@Jörg: mir sind drei Fälle begegnet, in denen ich
1.) ein Reading setzen wollte, für das es kein Set gibt -> setreading()
2.) ein Attribut gefragt war und kein Reading -> AttrVal() setattr()
3.) ich wollte den Timestamp eines Readings haben, nicht den Wert -> ReadingsTimestamp()
Ist sowas über spezielle Converter möglich?
Ein Glück das Du fragst. Nächtelang hab ich mir im Vorweg über das wie bei den convertern Gedanken gemacht - und jetzt sah es eine Woche so aus als ob wir das gar nicht brauchen :D
#3, no prob
#2, yes, aber etwas mit Einschränkung weil attrib keine Events erzeugen. Du bekommst also keine Echtzeitaktualisierung in sv. Für disable und co geht es weil Rudi dankenswerter Weise Events dafür eingebaut hat. Wenn Du das echt als Schalter verwenden möchtest macht es Sinn den modulautor zu überzeugen das er ein set und ein reading einbaut - das hat aber nichts mit den convertern zu tun sondern ist systemisch.
#1, yepp, wobei ich mich da unwohl fühle - ist eigentlich so gar kein fhem-style. Du hast Dir was gedacht, gibt es einen anderen Weg das zu erreichen ?
vg
Jörg
Ich habe mir grade den AttributeDisplay Converter selbst gemacht, das war einfach.
Ein Attribut zu setzen, geht aber gar nicht, weil der set Befehl nicht im Converter steckt, sondern fest codiert ist.
Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?
Zitat von: avg123-de am 02 Januar 2015, 17:06:32
habe ich probiert, jedoch mit eventMap on:500 off:1000. ;)
Jedoch wird mir in sv immer 500 (also on) angezeigt, egal wie er in FHEM steht.
Ist klar, weil der Trick nur in eine Richtung funktioniert.
Du hast mehrere Möglichkeiten:
1) Du nimmst das Reading im fronthemDevice Editor raus. Dann kannst Du den Wert zwar setzen, wirst aber in SV nicht am switch über den Status benachrichtigt. Pack noch ein basic.value() daneben, dann weißt Du, wie der Schalter stehen sollte. Er schaltet dann aber sicher richtig.
2) Anstelle neuer Converter können wir auch converting widgets erstellen. Stell Dir einen basic.switch() in SV vor, der SVValueON, SVValueOff, FHEMValueON, FHEMValueOFF als Parameter hat, dann brauchen wir gar keine neuen Converter für sowas und machen das einfach in Widgets... Ist recht einfach zu erstellen, versuche Dich mal dran!
Zitat von: bgewehr am 02 Januar 2015, 17:28:46
Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?
Dumm, dann müsste auch der Editor das berücksichtigen und anstelle der Readings und set commands die attributes anbieten, um es ganz perfekt zu machen... oder man lässt das einfach so und sagt: ist die Expertenvariante, also brauchen wir keine Werthilfe.
Zitat von: bgewehr am 02 Januar 2015, 17:28:46
Ich habe mir grade den AttributeDisplay Converter selbst gemacht, das war einfach.
Ein Attribut zu setzen, geht aber gar nicht, weil der set Befehl nicht im Converter steckt, sondern fest codiert ist.
Ich würde vorschlagen das Wort set im Converter festzulegen, dann kann man auch andere Möglichkeiten schaffen, ohne dass das gleich sehr schwierig wird. Man kann dann statt set auch setreading, setattribute und was auch immer nehmen! Ist das für Dich vorstellbar?
yepp, jenau. Bekommst halt keine Aktualisierung und das kann später (bei data-ajax=true) zum Problem werden weil es dann auch den initialen call nicht gibt. Aber, wie gesagt, dem converter isses egal.
Das mit dem "set" ist eingeplant. Wenn der converter den job selber erledigt einfach 'done' zurückgeben (bsp #243 in fhconverter). Dann weiß das framework das der converter das erledigt hat und legt sich wieder schlafen. Für Dich bedeutet das bereits im converter das attribut auf das device zu setzen (das device bekommt der converter über den hash) und dann 'done' als return.
vg
jörg
Hier mein AttributeDirect Converter:
###############################################################################
#
# Read and write fhem device Attributes (gadval == attribute == setval)
#
###############################################################################
sub Attribute(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $attribute = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = main::AttrVal($device, $attribute, '');
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$param->{result} = $gadval;
$param->{results} = [];
return undef;
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Direct';
}
return undef;
}
Zitat von: bgewehr am 02 Januar 2015, 17:37:54
Dumm, dann müsste auch der Editor das berücksichtigen und anstelle der Readings und set commands die attributes anbieten, um es ganz perfekt zu machen... oder man lässt das einfach so und sagt: ist die Expertenvariante, also brauchen wir keine Werthilfe.
ah ne, der plan ist anders. Da nur readings (und global) events erzeugen kann man (sofern irgendwie sinnvoll) ein anderes reading (oder event) als trigger nehmen. Ob und wie hängt natürlich dann von der ganz konkreten Situation ab.
Das attrib würde ich in diesem Fall dem converter als param geben, dann kann er getriggert werden (fhem->sv) und weiß was zu tun ist wenn sv sich meldet (param + val auf dem device xyz setzen)...
vg
jörg
... beim setzen des attrib im converter musst Du noch auf den namespace achten. Alles was fhem ist beginnt dann mit main:: ...
tante edith:
jetzt hat haben sich die posts überschnitten, gerade gesehen das den namespace schon kennst. perfekt. Setzen geht, wie geschrieben, direkt im converter
so:
elsif ($param->{cmd} eq 'rcv')
{
$param->{result} = $gadval;
$param->{results} = [];
$result = main::fhem('attr '.$device.' '.$attribute.' '.$gadval)
return done;
}
oder anders?
Zitat von: bgewehr am 02 Januar 2015, 17:54:54
so:
elsif ($param->{cmd} eq 'rcv')
{
$param->{result} = $gadval;
$param->{results} = [];
$result = main::fhem('attr '.$device.' '.$attribute.' '.$gadval)
return done;
}
oder anders?
fast:
return 'done';
Das ganze "rundherum" brauchst Du an der Stelle nicht mehr, main::fhem('attr' .... müsste eigentlich reichen.
addon:
und wie gesagt, ich würde den namen des attr in die params nehmen, und ein reading behalten was sich möglichst oft aktualisiert. Dann bekommt sv wenigstens verzögert mit das sich das attr verändert.
Zitat von: bgewehr am 02 Januar 2015, 17:35:20
Ist klar, weil der Trick nur in eine Richtung funktioniert.
Du hast mehrere Möglichkeiten:
1) Du nimmst das Reading im fronthemDevice Editor raus. Dann kannst Du den Wert zwar setzen, wirst aber in SV nicht am switch über den Status benachrichtigt. Pack noch ein basic.value() daneben, dann weißt Du, wie der Schalter stehen sollte. Er schaltet dann aber sicher richtig.
2) Anstelle neuer Converter können wir auch converting widgets erstellen. Stell Dir einen basic.switch() in SV vor, der SVValueON, SVValueOff, FHEMValueON, FHEMValueOFF als Parameter hat, dann brauchen wir gar keine neuen Converter für sowas und machen das einfach in Widgets... Ist recht einfach zu erstellen, versuche Dich mal dran!
Hier wäre doch der "ich-mappe-dir-alles-converter" über den wir gesprochen hatten eigentlich das mittel der Wahl - oder ?
params on:500, off:1000 und fertsch. Oder sehe ich da was nicht.
vg
jörg
@Jörg: genau!
na dann machen wir das einfach :-).
Ich versuche mal zeitnah zu prüfen ob das laden von convertern aus der 99 so hinhaut wie ich möchte. Wenn ja ein Beispiel ins wiki und dann hat man was schnelles zur Selbsthilfe an der Hand.
Wenn man hier die 500 und 1000 hart kodiert (also nicht param) nehmen würde könnte man den in 12 sekunden aus dem OnOff ableiten.
vg
jörg
ich behaupte nicht das der hier läuft - aber das er nahe dran ist 8)
sub special(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, 'on');
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = (lc($event) eq 'on')?'500':'1000';
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$param->{result} = ($gadval == 500)?'on':'off';
$param->{results} = [];
return undef;
}
elsif ($param->{cmd} eq '?')
{
return 'usage: OnOff';
}
return undef;
}
Ich behaupte, das hier läuft (ist aber was anderes):
###############################################################################
#
# Read fhem device Reading timestamps (gadval == timestamp)
#
###############################################################################
sub ReadingsTimestamp(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = main::ReadingsTimestamp($device, $reading, 0);
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Readingstimestamp';
}
return undef;
}
Zitat von: bgewehr am 02 Januar 2015, 18:52:18
Ich behaupte, das hier läuft auch:
###############################################################################
#
# Read and write fhem device Attributes (gadval == attribute == setval)
#
###############################################################################
sub Attribute(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $attribute = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
my $result = '';
if ($param->{cmd} eq 'get')
{
$event = main::AttrVal($device, $attribute, '');
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$result = main::Log(1, 'attr '.$device.' '.$attribute.' '.$gadval);
$result = main::fhem('attr '.$device.' '.$attribute.' '.$gadval);
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Direct';
}
return undef;
}
ZitatIch behaupte, das hier läuft
8)
Den ersten würde ich gern so übernehmen.
Beim zweiten würde ich gern ich gern die param / readings Geschichte noch einbauen damit so ein Hauch von Echtzeit-aktualisierung entstehen könnte ... (der würde mit data-ajax=true den Wert nur einmal von fhem holen, danach nie wieder. Wie gesagt, das ist systemisch fhem ... )
Dankeschön,
vg
jörg
Hallo,
ich habe mein System jetzt mal von dem Raspberry auf einen cubietruck verschoben. Hat inkl. smartVISU erstaunlich gut geklappt. Das Einzige, was nicht übernommen wurde waren die R/W-Berechtigungen der clients. Das ist etwas mühselig, die alle wieder zusammen zu klicken. cfg-Datei alleine kopieren hat irgendwie nicht gereicht.
Aber die Installation der ganzen Konstruktion auf dem CT hat auf Anhieb geklappt :)
schöne Grüße
Jo
he, super. Das teilweise aufgetretene Installations- Problem hat mittlerweile einen Namen, es ist das JSON Modul das auf einigen System zeitweise "zickt". Mit dem Wissen um die Ursache kann ich das glücklicherweise schnell aus der Welt schaffen.
Das kopieren cfg Dateien reicht, der Name muss mit dem device übereinstimmen und die Datei muss bei ausgeschaltetem fhem in das Verzeichniss gelegt werden. Beim nachfolgenden Start findet das device dann "seine" cfg und lädt die - so der Plan und auch getestet. Aber nach der Erfahrung mit dem "zickenden" JSON: so soll es klappen :)
Zitat von: herrmannj am 02 Januar 2015, 19:40:48
he, super. Das teilweise aufgetretene Installations- Problem hat mittlerweile einen Namen, es ist das JSON Modul das auf einigen System zeitweise "zickt".
Welches JSON ist es denn. CPAN oder Debian-Repository. Ich habe mit meinem JSON aus dem Debian bisher keine Probleme gehabt.
Grüße Jörg
Ok, fhem lief noch ;) Dann werde ich das beim nächsten device mal testen. Danke!
schöne Grüße
Jo
Zitat von: bgewehr am 02 Januar 2015, 16:15:38
Bis dahin geht VPN ganz gut!
Kannst du mir mal ein Tip geben? Mit VPN kommt zwar die Oberfläche aber ohne Werte! Habe VPN über die Fritzbox!
Danke
Zitat von: JoWiemann am 02 Januar 2015, 20:06:32
Welches JSON ist es denn. CPAN oder Debian-Repository. Ich habe mit meinem JSON aus dem Debian bisher keine Probleme gehabt.
Grüße Jörg
Du das weiß ich nicht, bei mir läufts ja auch (CPAN). Schlussendlich geht es nur um einen mini-effekt, der aber leider einigen usern einen holprogen install beschert hat.
Der Punkt ist das JSON auf einigen Systemen sichtlich nur manchmal einen Fehler meldet wenn der input ein leerer String ist (initialer Start). Eben auch nur manchmal, nach einigen Versuchen habens ja alle zum laufen gebracht (afaik).
Insofern gibt es da auch keinen Anlass jetzt akribisch das eigene JSON zu untersuchen, es geht um den Sonderfall leere cfg, das kann ich charmant anders lösen.
vg
jörg
Zitat von: cruser1800 am 02 Januar 2015, 20:48:38
Kannst du mir mal ein Tip geben? Mit VPN kommt zwar die Oberfläche aber ohne Werte! Habe VPN über die Fritzbox!
Danke
dito fb. Du bekommst über vpn eine andere IP als normal im WLAN, musst also ein eigenes device dafür anlegen. Finde ich persönlich ganz charant weil ich unterwegs auf einen andere sv zugreifen kann. Kannst natürlich genauso gut in sv die gleichen pages nehmen die Du auch sonst nimmst.
vg
jörg
Zitat von: cruser1800 am 02 Januar 2015, 20:48:38
Kannst du mir mal ein Tip geben? Mit VPN kommt zwar die Oberfläche aber ohne Werte! Habe VPN über die Fritzbox!
Danke
Du musst die VPN IP zusätzlich als fronthemDevice anlegen!
Zitat von: herrmannj am 02 Januar 2015, 19:27:56
8)
Den ersten würde ich gern so übernehmen.
Beim zweiten würde ich gern ich gern die param / readings Geschichte noch einbauen damit so ein Hauch von Echtzeit-aktualisierung entstehen könnte ... (der würde mit data-ajax=true den Wert nur einmal von fhem holen, danach nie wieder. Wie gesagt, das ist systemisch fhem ... )
Also für meinen Fall brauche ich das gar nicht, weil mach nur ich und mach ich nur über SV, also kein Update Problem....
Aber ich verstehe die Intention und finde das auch besser!
Du, ich schieb den auch noch auf - gibt ja "wichtigere" und Dein Ding ist ja damit gelöst - oder ?
Zitat von: bgewehr am 02 Januar 2015, 21:13:15
Du musst die VPN IP zusätzlich als fronthemDevice anlegen!
Danke
Zitat von: herrmannj am 02 Januar 2015, 21:23:43
Du, ich schieb den auch noch auf - gibt ja "wichtigere" und Dein Ding ist ja damit gelöst - oder ?
Yepp!
Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.
Jörg, kannst Du Dir das erklären?
'Fritzbox-Callmoncall_timestamp' ist der Name des basic.value aus dem Widget.
'FB_call_timestamp' ist der Name des gads im basic.value im Widget.
[io.domotiga]: update item: FB_call_timestamp val: 2015-01-02 21:27:27
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["2015-01-02 21:27:27"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","call"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: call
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["call"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","connect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: connect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["connect"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","disconnect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: disconnect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["disconnect"]
Zitat von: bgewehr am 02 Januar 2015, 18:51:10
Ich behaupte, das hier läuft (ist aber was anderes):
###############################################################################
#
# Read fhem device Reading timestamps (gadval == timestamp)
#
###############################################################################
sub ReadingsTimestamp(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = main::ReadingsTimestamp($device, $reading, 0);
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Readingstimestamp';
}
return undef;
}
Edit:
Ich vermute, dass es damit zu tun hat, dass das Reading von FBCallmonitor, das ich verwende "event" heißt und "event" womöglich fronthem in die Irre führt, kann das sein?
Widerlegt, weil bei anderen Readings das Gleiche passiert.
Zitat von: bgewehr am 02 Januar 2015, 22:21:32
Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.
Jörg, kannst Du Dir das erklären?
'Fritzbox-Callmoncall_timestamp' ist der Name des basic.value aus dem Widget.
'FB_call_timestamp' ist der Name des gads im basic.value im Widget.
[io.domotiga]: update item: FB_call_timestamp val: 2015-01-02 21:27:27
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["2015-01-02 21:27:27"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","call"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: call
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["call"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","connect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: connect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["connect"]
io_domotiga.js:115 [io.domotiga] receiving data: {"cmd":"item","items":["FB_call_timestamp","disconnect"]}
io_domotiga.js:121 [io.domotiga]: update item: FB_call_timestamp val: disconnect
base.js:678 [basic.value] update 'Fritzbox-Callmoncall_timestamp': ["disconnect"]
will have a look soon :)
Hi Jörg,
du hast doch auch die LED Bulbs, Modul WIFILight.
Bekommst du diese in SV angesteuert?
Im Log auf FHEM sehe ich nur!
PC: error TVLicht: converter syntax: missing paramter
Gruss Dirk
Hi Dirk,
selbstredend ! Gutes Modul :)
Du musst drei die GADs nehmen, allen dreien den converter RGBCombined geben und daran, als parameter, die 3 GAD in der Reihenfolge R,G,B anhängen. Der converter setzt die drei Einzelsignale von sv zusammen. Funktioniert perfekt.
Auf sv Seite bin ich fast zufrieden, ich nehme den shifter für das Lampensymbol (und Schalter) sowei einen slider. Ein wenig doof (finde ich) das ich nochmal einen RGB für die Farbe dahinter setzen muss, eigentlich hätte ich das gern als RGB-shifter.
Grundsätzlich hab ich das auch mal kurz getestet - die svg icons könnte man per fill mit der Lampenfarbe innen ausfüllen - ich hab es aber noch nicht verstanden wie der Syntax lautet um dem shifter mit svg icons zu betreiben. Dann könnte man schnell ein widget klöppeln. Allerdings habe ich das auch nur kurz getestet weil, bin ja mehr mit fronthem beschäftigt.
Wenn jemand weiß wie der syntax für svg icons im shifter lautet bitte gern posten.
vg
Jörg
Zitat von: bgewehr am 02 Januar 2015, 22:21:32
Tja, es läuft EINMAL, danach kommt statt des Timestamps der Value() des Readings.
Jörg, kannst Du Dir das erklären?
yes, I see:
der converter kennt 3 (main) modes (($param->{cmd} eq 'get'))
get: sv fragt aktiv das GAD an,
send: fhem schickt den Wert pro-aktiv an sv
rcv: sv sendet an fhem.
Du hast unter 'get"
$event = main::ReadingsTimestamp($device, $reading, 0);wenn sv den Wert aktiv anfragt (einmal: pageload) wird der timestamp genommen.
Der Zweig drunter wird aktiv wenn fronthem das event (aus fhem) sieht, da wird bei Dir jetzt das event (hier reading) durch-gereicht.
So gehts:
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = main::ReadingsTimestamp($device, $reading, 0);
$param->{gads} = [];
return undef;
}
Zweig 'get':
Unterscheidung zwischen 'fronthem holt den Wert" und 'fronthem bekommt den Wert' hier nicht möglich, timestamp muss immer geholt werden. Daher gleich mode auf 'send' ändern damit der nächste Zweig immer genommen wird.
Zweig 'send'
$param->{gadval} (der geht an sv raus) mit dem timestamp laden.
Bei 'rcv'
return 'done': perfekt, dann kommt fronthem nicht auf dumme Ideen falls jemand auf dem GAD was aus sv zurückschickt.
$param->{cmd} eq '?'
Da soll später mal eine online Hilfe zurückgegeben werden die dann im converter eingeblendet werden kann, so wie bei excel die hints zur Benutzung einer speziellen Funktion.
vg
Jörg
Zitat von: herrmannj am 03 Januar 2015, 14:20:26
yes, I see:
der converter kennt 3 (main) modes (($param->{cmd} eq 'get'))
get: sv fragt aktiv das GAD an,
send: fhem schickt den Wert pro-aktiv an sv
rcv: sv sendet an fhem.
Zweig 'get':
Unterscheidung zwischen 'fronthem holt den Wert" und 'fronthem bekommt den Wert' hier nicht möglich, timestamp muss immer geholt werden. Daher gleich mode auf 'send' ändern damit der nächste Zweig immer genommen wird.
Zweig 'send'
$param->{gadval} (der geht an sv raus) mit dem timestamp laden.
Warum dann nicht bei Direct genauso?
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, '');
$param->{gads} = [];
return undef;
}
Das hat bei mir einen Fehler behoben, den ich schon länger hatte: dass nämlich Texte mit Leerzeichen bei get anders erschienen sind als bei send. Bei get waren sie immer vollständig, bei send waren sie immer nur bis zum ersten Leerzeichen enthalten.
Nach der Änderung oben scheint das behoben zu sein.
Zitat von: herrmannj am 03 Januar 2015, 13:17:11
Hi Dirk,
selbstredend ! Gutes Modul :)
Jörg, kannst Du mal den SV-Code für dieses Layout posten? Dein Raum gefällt mir sehr gut!
Hi @all,
ich versuche jetzt seid gestern Abend ein encoding Problem zu lösen, langsam gehen mir die Ideen aus:
Problem: Umlaute werden in smartVISU falsch dargestellt.
Nachstellen:
fhem: dummy erstellen, dann set den dummy 'Ö'
sv: basic.value
dann über "Direct" mit dem dummy verbinden.
Darstellung in sv als "ÃÂ"
Das ist die korrekte (byte) Repräsentation in UTF-8.
Der Weg fronthem -> sv geht über perl -> JSON (UTF8) -> ws (UTF8) -> JSON (UTF8) -> jquery mobile in sv.
Ich habe jetzt testweise überall mal convert (UTF8 ...) reingesetzt, bringt natürlich alles nix.
Den browser hab ich "hart" auf UTF8 gestellt (nix), nginx "gezwungen" UTF8 coding zu für die page zu verwenden (nix), meta im head in allen Spielarten ... (guess what: nix) ... jetzt gehen mitr irgendwie die Ideen aus.
Hat jemand weitere Ideen oder gar die Lösung ?
vg
jörg
Zitat von: bgewehr am 03 Januar 2015, 15:30:46
Jörg, kannst Du mal den SV-Code für dieses Layout posten? Dein Raum gefällt mir sehr gut!
sehr gern. Für den slider hängt noch ein user css dran dami der blöde val weg ist. vg
Zitat von: bgewehr am 03 Januar 2015, 15:28:53
Warum dann nicht bei Direct genauso?
...
Das hat bei mir einen Fehler behoben, den ich schon länger hatte: dass nämlich Texte mit Leerzeichen bei get anders erschienen sind als bei send. Bei get waren sie immer vollständig, bei send waren sie immer nur bis zum ersten Leerzeichen enthalten.
Nach der Änderung oben scheint das behoben zu sein.
geht beides. Ist eher so ein logik Ding. Bei send werden die ja frei Haus geliefert und man kann sich das extra "holen" sparen. Von der performance ist es aber vmtl egal. Damian macht das bei DOIF sogar konsequent nur über readingsval und nimmt das event nur als Anlass im modul aktiv zu werden.
Der aktuelle Weg hat den Vorteil a: einen call (readingsval) zu sparen und b: auch 'flüchtige' events (ohne reading) zu bekommen. Ich muss wohl eher das abschneiden am space reparieren, aber bis dahin kannst Du das gern genauso fixen.
vg
Jörg
Zitat von: herrmannj am 03 Januar 2015, 15:39:03
Für den slider hängt noch ein user css dran dami der blöde val weg ist. vg
Du kannst auf ein separates css verzichten:
<td rowspan="3" align="left" class="pos">
{{ basic.slider(id~'pos', gad_pos, min, max, step, 'vertical') }}
</td>
Die class "pos" zeigt nur den slider, die class "ui-slider-input" zeigt nur den VAL und - logisch, class="pos:ui-slider-input" zeigt beides!
@Jörg,
kannst du mir mal einen kompletten Block zu einem RGB Device posten.
Irgendwie hakt es noch!
Hallo,
ich habe nochmal ein feedback zur Stabilität:
- FHEM läuft mit SV auf cubietruck.
- SV installiert und zwei devices eingerichtet (PC und handy).
- Beide laufen und sind mit SV verbunden (state "connected").
- Zwischendurch (während einer Kaffeepause) schmiert fhem ab und der cubie startet neu (watchdog installiert).
- Beide Systeme laufen wieder, aber weder vom handy (state " ? ? ? ") noch vom PC (state "disconnected") lässt sich eine Verbindung herstellen (rote Ecke oben rechts).
- Ein schließen/neu-öffnen der browser-tabs bringt nichts.
Was dabei ein wenig kritisch ist sind die spontanen FHEM-Abstürze. Leider findet sich im FHEM log nichts dazu. Kann ich dazu im Nachhinein noch irgendwo etwas finden?
Wie kann ich beides wieder miteinander verbinden? Ich hab erstmal nichts erneut neu gestartet, um evtl. noch Hinweise zum Absturz finden zu können.
schöne Grüße
Jo
Zitat von: hyper2910 am 03 Januar 2015, 17:20:49
@Jörg,
kannst du mir mal einen kompletten Block zu einem RGB Device posten.
Irgendwie hakt es noch!
Hi,
poste mal bitte wie Du das widget in sv erstellt hast und bitte alle drei GAD cfgs aus dem Editor.
Achte bitte darauf das Du die id auf der sv Seite nicht ausversehen doppelt vergeben hast (innerhalb der Seite)
vg
jörg
Zitat von: Jojo11 am 03 Januar 2015, 18:28:27
Hallo,
ich habe nochmal ein feedback zur Stabilität:
- FHEM läuft mit SV auf cubietruck.
- SV installiert und zwei devices eingerichtet (PC und handy).
- Beide laufen und sind mit SV verbunden (state "connected").
- Zwischendurch (während einer Kaffeepause) schmiert fhem ab und der cubie startet neu (watchdog installiert).
- Beide Systeme laufen wieder, aber weder vom handy (state " ? ? ? ") noch vom PC (state "disconnected") lässt sich eine Verbindung herstellen (rote Ecke oben rechts).
- Ein schließen/neu-öffnen der browser-tabs bringt nichts.
Was dabei ein wenig kritisch ist sind die spontanen FHEM-Abstürze. Leider findet sich im FHEM log nichts dazu. Kann ich dazu im Nachhinein noch irgendwo etwas finden?
Wie kann ich beides wieder miteinander verbinden? Ich hab erstmal nichts erneut neu gestartet, um evtl. noch Hinweise zum Absturz finden zu können.
schöne Grüße
Jo
Hi Jo,
das geht vmtl in Richtung der Geschichte mit dem Flugmodus, ich habe es auch geschafft ein ähnliche Situation zu reproduzieren.
Mal so als generelles update (in der Reihenfolge kritisch nach lästig):
- Wir hatten bei einigen usern Probleme während der Installation die vom JSON Modul kamen. -> das ist gefixt (aber noch nicht veröffentlicht).
- Auf einem perl unter 5.14 gab es Fehlermeldungen, also lief nicht. -> das ist gefixt (aber noch nicht veröffentlicht).
- An der Geschichte mit dem Flugmodus (vgl Jo) bin ich dran, keine Frage das darf nicht sein.
- Das Thema rereadcfg überschneidet sich mit rename und co, kommt danach, ist leider etwas aufwendiger.
- Dann gab es noch den Punkt das bei "vertippern" in sv GADs geladen wurden die den Editor ausknocken.
Da bin ich noch etwas unentschlossen, für den Input ist ja jeder selbst verantwortlich. ABER: fronthem (und damit ich) ist in der Verantwortung das nicht evil-boy über einen erbeuteten Zugang das System lahmlegen kann. Das sind möglicherweise konkruente Ziele - mal sehen.
- Laden von convertern aus den 99ern habe ich überprüft, das ist es wirklich so das ich beim Start suchen lasse, das verschiebe ich nach hinten.
- Wenn ein Reading/event Doppelpunkte beinhaltet oder space wird es falsch an sv übermittelt - kommt.
Mit dem Thema Zeichenkonvertierung habe ich eine ganze Weile verbracht ohne eine Lösung zu finden. Meiner Meinung nach (da will ich aber noch nicht zu laut schreien) muss das auch in SV gefixt werden. Meine conclusion aktuell ist die das aus dem driver auf sv Seite korrektes UTF8 rauskommt, sv selber Darstellungsprobleme hat. Mögliche fixe, Stand jetzt, wären ein converter (hack) der "ö" zu "oe" wandelt oder eine UTF8->Latin Wandlung am Ausgang des Treibers auf SV Seite. Wobei mich beides nicht zufrieden stellt - irgendwie muss das doch auch vernünftig gehen. Das lege ich jetzt aber erstmal nach hinten, wenn jemand eine Lösung kennt, auf anderen Browsern anderes Verhalten sieht - bitte her damit.
Ich wollte jetzt keine updates scheibchenweise erstellen, wenn akuter Bedarf (bspw wegen JSON vs. install) besteht gebt mir eine kurze Info, dann gebe ich den aktuellen Stand "unter der Hand" ;) raus.
vg
jörg
Ich hatte heute ebenfalls 2 Komplettabstürze von FHEM. Einen Hinweis darauf, woran es lag, kann ich in keinem Log finden. Verbunden sind aktuell der PC und 2 Tablets von denen keines in den Flugmmodus (ich habe jetzt nicht nachgelesen, was in diesem Kontext damit gemeint ist) geht und ein Handy (ebenfalls kein Flugmodus). Wichtig zu wissen ist, dass FHEM ohne fronthem absolut stabil ist und eine Uptime von 12 Tagen hatte (letztes Update). Einen Absturz hatte ich in 3 Jahren nicht einmal.
Das hier soll kein "meckern" sein. Lediglich eine weitere Meldung des Spontanabsturzes ohne Hinweis auf den Fehler.
Hallo,
ui, das ist mal eine roadmap :o
Keine Sorge, das ist nicht wirklich kritisch. Ich werde mal verfolgen, wie oft sich FHEM verabschiedet und was davor passiert - vielleicht ergeben sich ja Hinweise zur Fehlersuche.
Zur Zeichenkonvertierung kann ich leider auch nichts beitragen :-\
schöne Grüße
Jo
ZitatDas hier soll kein "meckern" sein. Lediglich eine weitere Meldung des Spontanabsturzes ohne Hinweis auf den Fehler.
ja genau, vielen Dank.
es scheint das eine Situation bei der eine unterbrochene (nicht ordentlich geschlossene) Verbindung vom client zu fronthem das auslösen kann. Ich konnte es noch nicht exakt lokalisieren sage jedoch "das lasse ich mir nicht bieten !!!" :D
Bei Jo (Kaffepause) vmtl stand-by , Flugmodus ja von Kontext vergleichbar (WLAN aus).
das fixen wir !
vg
jörg
edith: überschnitten :)
Ich habe ehrlich gesagt den Überblick verloren, was hier schon als Fehler gemeldet wurde. Ich hoffe, das hier noch nicht:
Reading einer Windrichtung (win_dir) als gad definiert mit dem converter Direct. Das ganze in SmartVisu als basic.value eingebunden. Die Windrichtung hat das Format , wie
360 NW
Beim ersten Aufrufen der entsprechende Seite steht das Value in SM auch genau so . Ändert sich das Reading jedoch steht nur noch die Zahl dort:
350
Das ganze lässt sich auch in der FireBug Console verfolgen. Es kommt bei Aktualisierung des Readings nur die Zahl in SmartVisu an.
[io.domotiga] receiving data: {"cmd":"item","items":["GS.xx.WM.Wind.dir","337 NNW"]}
[io.domotiga] receiving data: {"cmd":"item","items":["GS.xx.WM.Wind.dir","337"]}
Hi marvin,
haben wir schon, trotzdem vielen Dank. Das kommt durch das space im reading, wird gefixt.
Das ist das Elend bei diesen langen threads, da blickt man irgendwann nicht mehr durch - hat auch keiner Lust sich durch 1000 posts zu wühlen. Deswegen würde ich mit der nächsten beta gern hier zumachen und auf reset zu drücken. Daher die Bitte:
Wer mag, nehmt bitte das eine oder andere aus diesem thread ins wiki, da bleibt es wenigstens bis zum nächsten plattencrash :)
Danke und viele Grüße
Jörg
@Jörg, kannst Du Dir erklären, warum hier hinter prog1 ein Leerzeichen kommt? In fhem ist keines!
Der Converter ist "Direct" auf ein weekPrgSel-Reading eines HM-TC.
[io.domotiga] receiving data: {"cmd":"item","items":["WZ_rtr_prog","prog1 "]}
io_domotiga.js:121 [io.domotiga]: update item: WZ_rtr_prog val: prog1
base.js:678 [basic.selectmenu] update 'room_wohnzimmer-HMTC_EG_timerprog': ["prog1 "]
io_domotiga.js:164 [io.domotiga] sending data: {"cmd":"item","id":"WZ_rtr_prog","val":"prog1"}
base.js:678 [basic.selectmenu] update 'room_wohnzimmer-HMTC_EG_timerprog': ["prog1"]
Zitat von: bgewehr am 03 Januar 2015, 15:30:46
Jörg, kannst Du mal den SV-Code für dieses Layout posten? Dein Raum gefällt mir sehr gut!
Bitteschön (rtr ist noch nicht schick, energie noch nix drin, zum ab schauen trotzdem gerne). Das mit class pos habe ich nicht hinbekommen, entweder in es geht in der Konstellation mit den blocks nicht - oder ich habs falsch gemacht. Kannst ja mal schauen.
Vielleicht kennst oder findest Du bei der Gelegenheit ja auch den Syntax für shifter und svg icons.
@all: ihr braucht den von Bernd reparierten shifter dazu (wegen dim 0..100)
vg
jörg
/**
* -----------------------------------------------------------------------------
* @package smartVISU
* @author Martin Gleiß
* @copyright 2012
* @license GPL [http://www.gnu.de]
* -----------------------------------------------------------------------------
*/
{% import "widget_homematic.html" as homematic %}
{% import "widget_special.html" as special %}
{% import "plot.html" as plot %}
{% extends "rooms.html" %}
{% block content %}
<div class="cells">
<div class="cell4 ui-btn-up-a">Aktivität</div>
<div class="cell6 ui-btn-up-a">
<span data-role="controlgroup" data-type="horizontal">
{{ basic.dual('light.a', 'wz.light.szene.auto', icon1~'time_automatic.png', icon0~'time_automatic.png', 'auto', 'off', 'midi') }}
{{ basic.dual('light.b', 'wz.light.szene.tv', icon1~'it_television.png', icon0~'it_television.png', 'tv', 'off', 'midi') }}
{{ basic.dual('light.c', 'wz.light.szene.work', icon1~'light_ceiling_light.png', icon0~'light_ceiling_light.png', 'work', 'off', 'midi') }}
{{ basic.dual('light.d', 'wz.light.szene.eat', icon1~'light_dinner_table.png', icon0~'light_dinner_table.png', 'eat', 'off', 'midi') }}
{{ basic.dual('light.e', 'wz.light.szene.party', icon1~'light_party.png', icon0~'light_party.png', 'party', 'off', 'midi') }}
{{ basic.dual('light.f', 'wz.light.szene.full', icon1~'light_light_dim_100.png', icon0~'light_light_dim_100.png', 'full', 'off', 'midi') }}
{{ basic.dual('light.g', 'wz.light.szene.xmas', icon1~'scene_x-mas.png', icon0~'scene_x-mas.png', 'on', 'off', 'midi') }}
{{ basic.dual('light.h', 'wz.light.szene.off', icon1~'control_on_off.png', icon0~'control_on_off.png', 'off', 'off', 'midi') }}
</span>
</div>
</div>
<div class="block" style="width:100%; heigth:600px">
<div class="set-3" data-role="collapsible-set" data-theme="c" data-content-theme="a" data-mini="true">
<div data-role="collapsible" data-collapsed="false">
<h3>Heizung</h3>
<p>
<table>
<tr>
<td>{{ homematic.hmtc('wz.HMTC', 'mode', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_controlmode', 'WZ_rtr_daytemp', 'WZ_rtr_nighttemp', 'WZ.fenster', 'WZ_rtr_battery', 'WZ_rtr_state', 'WZ_rtr_text') }}</td>
<td>{{ plot.comfortchart('wz.plot.comfort', 'wz.measured.temperature', 'wz.measured.humidity') }}</td>
</tr>
</table>
</p>
</div>
<div data-role="collapsible">
<h3>Beleuchtung</h3>
<div class="cells">
<div class="cell2 ui-btn-up-a">Deckenlicht</div>
<div class="cell1 ui-btn-up-a">{{ basic.shifter('ld.sh.wz.light.decke', 'wz.light.decke.switch', 'wz.light.decke.dim' , '', '', 0, 100) }}</div>
<div class="cell4 ui-btn-up-a xdimmer">{{ basic.slider('ld.sh.wz.light.decke.dim', 'wz.light.decke.dim', 0, 100) }}</div>
<div class="cell3 ui-btn-up-a"></div>
</div>
<div class="cells">
<div class="cell2 ui-btn-up-a">Esstisch</div>
<div class="cell1 ui-btn-up-a">{{ basic.switch('ld.sw.wz.light.essen', 'wz.light.essen.switch', icon1~'light_light_dim_100.png', icon0~'light_light_dim_00.png') }}</div>
<div class="cell4 ui-btn-up-a"></div>
<div class="cell3 ui-btn-up-a"></div>
</div>
<div class="cells">
<div class="cell2 ui-btn-up-a">Bücherregal</div>
<div class="cell1 ui-btn-up-a">{{ basic.switch('ld.sw.wz.light.billy', 'wz.light.billy.switch', icon1~'light_light_dim_100.png', icon0~'light_light_dim_00.png') }}</div>
<div class="cell4 ui-btn-up-a"></div>
<div class="cell3 ui-btn-up-a"></div>
</div>
<div class="cells">
<div class="cell2 ui-btn-up-a">Leselampe</div>
<div class="cell1 ui-btn-up-a"> {{ basic.shifter('ld.sh.wz.light.lese', 'wz.light.lese.switch', 'wz.light.lese.dim' , '', '', 0, 100) }}</div>
<div class="cell4 pos ui-btn-up-a xdimmer">{{ basic.slider('ld.sh.wz.light.lese.dim', 'wz.light.lese.dim', 0, 100) }}</div>
<div class="cell1 ui-btn-up-a">{{ basic.colordisc('ld.sh.wz.light.lese.color', 'wz.light.lese.r', 'wz.light.lese.g', 'wz.light.lese.b', 0, 255, 16, 20) }}</div>
<div class="cell2 ui-btn-up-a"></div>
</div>
<div class="cells">
<div class="cell2 ui-btn-up-a">Sideboard</div>
<div class="cell1 ui-btn-up-a">{{ basic.shifter('ld.sh.wz.light.sideboard', 'wz.light.sideboard.switch', 'wz.light.sideboard.dim' , '', '', 0, 100) }}</div>
<div class="cell4 ui-btn-up-a xdimmer">{{ basic.slider('ld.sh.wz.light.sideboard.dim', 'wz.light.sideboard.dim', 0, 100) }}</div>
<div class="cell1 ui-btn-up-a">{{ basic.colordisc('ld.sh.wz.light.sideboard.color', 'wz.light.sideboard.r', 'wz.light.sideboard.g', 'wz.light.sideboard.b', 0, 255, 16, 20) }}</div>
<div class="cell2 ui-btn-up-a"></div>
</div>
<div class="cells">
<div class="cell2 ui-btn-up-a">Dekolicht</div>
<div class="cell1 ui-btn-up-a">{{ basic.switch('ld.sw.wz.light.deko', 'wz.light.deko.switch', icon1~'light_light_dim_100.png', icon0~'light_light_dim_00.png') }}</div>
<div class="cell4 ui-btn-up-a"></div>
<div class="cell3 ui-btn-up-a"></div>
</div>
</div>
<div data-role="collapsible">
<h3>Energie</h3>
<p>
</p>
</div>
</div>
</div>
{% endblock %}
Zitat von: bgewehr am 03 Januar 2015, 20:27:07
@Jörg, kannst Du Dir erklären, warum hier hinter prog1 ein Leerzeichen kommt? In fhem ist keines!
Der Converter ist "Direct" auf ein weekPrgSel-Reading eines HM-TC.
[io.domotiga] receiving data: {"cmd":"item","items":["WZ_rtr_prog","prog1 "]}
io_domotiga.js:121 [io.domotiga]: update item: WZ_rtr_prog val: prog1
base.js:678 [basic.selectmenu] update 'room_wohnzimmer-HMTC_EG_timerprog': ["prog1 "]
io_domotiga.js:164 [io.domotiga] sending data: {"cmd":"item","id":"WZ_rtr_prog","val":"prog1"}
base.js:678 [basic.selectmenu] update 'room_wohnzimmer-HMTC_EG_timerprog': ["prog1"]
Das wird in die gleiche Richtung wie ":" und space gehen. Der erste ist pageload, der nächste update ?
Ja! Aber das Reading ist nur "prog1"
Hallo zusammen,
ich habe eine kleines Problem. Eigentlich läuft alles perfekt bis auf das Speichern der GAD-Definitionen. Die cfg-Dateien werden nicht erzeugt, auch nicht die Verzeichnisse. So sind nach einem Neustart von FHEM alle GADs weg.
Allerdings habe ich auch eine etwas "außergewöhnliche" Konfiguration: Mein FHEM läuft auf einem Synology NAS. Da wird z.B. FHEM nicht unter /opt installiert sondern unter /volume1/@appstore/FHEM.
Könnte das der Grund dafür sein die GADs nicht gespeichert werden?
Grüße
Rainer
Hallo Rainer,
hmm, sorry - ich hoffe Du hast das rechtzeitig entdeckt.
Das pfad wird von motd abgeleitet, sollte also kein Problem sein. Das "@" schon eher, sollte aber eigentlich nicht. Hast Du mal nach den rechten unter/in www geschaut ?
Das speichern findet jedes mal wenn ein GAD geändert wird statt, Du könntest damit das speichern im Betrieb überprüfen.
vg
jörg
Hallo Jörg,
drwxr-xr-x 10 1000 1000 4096 Jan 3 21:48 www
sollte passen, oder?
Grüße
Rainer
vergleich mal bitte mit dem owner der fhem.cfg - muss der gleiche sein. Auch an Unterverzeichnisse denken!
"Nicht-grouper" dürfen bei Dir nicht ins www schreiben. Wäre also möglich ... vg
Hallo zusammen,
aus dem Urlaub zurück wollte ich mich nun auch mit fronthem auseinandersetzen. Habe zwar alles aus dem Thread im Urlaub mitverfolgt, aber der Thread ist nun leider sehr groß und alles ist sehr verteilt.
Ich scheitere leider schon bei der Installation von smartVISU.
Installiert habe ich folgendermaßen:
/# cd /var/www/
/var/www# wget http://smartvisu.de/download/smartVISU_2.7.zip
/var/www# unzip smartVISU_2.7.zip
/var/www# rm smartVISU_2.7.zip
/var/www# mv smartVISU smartvisu
/var/www# chown -R www-data:www-data /var/www/smartvisu
Beim Aufruf von http://serverip/smartvisu (http://serverip/smartvisu) kommt
Forbidden
You don't have permission to access /smartvisu/index.php on this server.
Wenn ich noch
/var/www# chmod -R 775 smartvisu
mache, funktioniert es genau so wenig.
Woran kann das liegen?
Vielen Dank.
Hallo Jörg,
Zitat von: herrmannj am 03 Januar 2015, 21:53:21
vergleich mal bitte mit dem owner der fhem.cfg - muss der gleiche sein. Auch an Unterverzeichnisse denken!
"Nicht-grouper" dürfen bei Dir nicht ins www schreiben. Wäre also möglich ... vg
Das Verzeichnis www hat wie auch die Datei fhem.cfg den gleichen User:Gruppe
drwxr-xr-x 11 1000 1000 4096 Jan 3 23:26 www
Auch das Anlegen der Verzeichnisse frontend/fronthem unterhalb www und chown -R 1000:1000 frontend hat nichts geändert. Im Verzeichnis fronthem wir nichts angelegt.
Grüße
Rainer
Hi Jörg,
Ich verstehe noch nicht was du damit meinst, du hast ein gad für Ein/Aus, eins zum dimmen und einen fuer die farbwahl, diesen soll dann immer der gleiche converter zugeordnet werden?
Zitat von: ergerd am 03 Januar 2015, 23:33:38
Hallo Jörg,
Das Verzeichnis www hat wie auch die Datei fhem.cfg den gleichen User:Gruppe
drwxr-xr-x 11 1000 1000 4096 Jan 3 23:26 www
Auch das Anlegen der Verzeichnisse frontend/fronthem unterhalb www und chown -R 1000:1000 frontend hat nichts geändert. Im Verzeichnis fronthem wir nichts angelegt.
Grüße
Rainer
Ein Nachteil der Jugend des Moduls ist es das nur an einigen Stellen logging gibt - da nicht ...
Im Augenblick habe ich leider keine Idee. Welches perl läuft auf der synology ?
Traust Du Dir zu (und möchtest Du) selber Logzeilen einzubauen wenn ich Dich anleite ? Das schreiben in die cfg ist eigentlich recht straight forward, ich sehe nicht wo es hängen kann aber es wird schon was geben ... :D
vg
Jörg
Zitat von: hyper2910 am 03 Januar 2015, 23:44:13
Hi Jörg,
Ich verstehe noch nicht was du damit meinst, du hast ein gad für Ein/Aus, eins zum dimmen und einen fuer die farbwahl, diesen soll dann immer der gleiche converter zugeordnet werden?
nee, die Farbwahl hat 3 GAD. Jetzt zier Dich nicht so - poste die widget def !
vg
jörg
Hallo Jörg,
Zitat von: herrmannj am 03 Januar 2015, 23:59:20
Ein Nachteil der Jugend des Moduls ist es das nur an einigen Stellen logging gibt - da nicht ...
Im Augenblick habe ich leider keine Idee. Welches perl läuft auf der synology ?
Traust Du Dir zu (und möchtest Du) selber Logzeilen einzubauen wenn ich Dich anleite ? Das schreiben in die cfg ist eigentlich recht straight forward, ich sehe nicht wo es hängen kann aber es wird schon was geben ... :D
ich habe Perl 5.16.0 auf der Synology laufen.
Ich denke, das mit den Logzeilen sollte ich hinbekommen, würde es gern versuchen.
Was muss ich wo einbauen?
Grüße
Rainer
Moin zusammen,
habe bei der Installation laut Anleitung aus dem Thread
http://forum.fhem.de/index.php/topic,30909.msg237143.html#msg237143 (http://forum.fhem.de/index.php/topic,30909.msg237143.html#msg237143)
weitergemacht. Leider bekomme ich immer noch meinen genannten Fehler aus dem Thread
http://forum.fhem.de/index.php/topic,30909.msg239770.html#msg239770 (http://forum.fhem.de/index.php/topic,30909.msg239770.html#msg239770)
Keiner eine Idee?
Andere hatten doch auch Probleme mit den Berechtigungen. Wie muss es denn korrekterweise sein?
Berechtigungen von smartVISU:
root@cubie:/var/www# ls -la
total 12
drwxr-xr-x 3 www-data www-data 4096 Jan 3 22:44 .
drwxr-xr-x 13 root root 4096 Oct 2 12:11 ..
drwxr-xr-x 14 www-data www-data 4096 Jan 3 22:44 smartvisu
Vielen Dank.
Hi Jörg,
hier mal der Teil aus SV
{{ basic.shifter('TV00', 'TV_AN_AUS' ) }}
{{ basic.slider('TV1slider0', 'TV_DIMM', 0, 300, 10 ) }}
{{ basic.rgb('TV2', 'TV_color_r', 'TV_color_g', 'TV_color_b', 0, 255, 16, 20) }}
so,
jetzt ist mir aber noch nicht klar, was in den GADs im FHEM rein soll.
momentan sieht es so aus! Siehe Bild
Mein Berechtigungsproblem hat sich erledigt.
Musste im Apache noch
<Directory "/var/www/smartvisu">
Options +Indexes FollowSymLinks +ExecCGI
AllowOverride AuthConfig FileInfo
Order allow,deny
Allow from all
</Directory>
hinzufügen.
Zitat von: hyper2910 am 04 Januar 2015, 09:58:53
Hi Jörg,
hier mal der Teil aus SV
{{ basic.shifter('TV00', 'TV_AN_AUS' ) }}
{{ basic.slider('TV1slider0', 'TV_DIMM', 0, 300, 10 ) }}
{{ basic.rgb('TV2', 'TV_color_r', 'TV_color_g', 'TV_color_b', 0, 255, 16, 20) }}
so,
jetzt ist mir aber noch nicht klar, was in den GADs im FHEM rein soll.
momentan sieht es so aus! Siehe Bild
Hi,
das sieht doch schon ganz gut aus.
Exakt die gleichen Einstellungen musst Du für alle drei GAD (r, g, b) machen - die Zeile converter kannst Du direkt mit ctrl-c - ctrl-v auf die anderen beiden nehmen. Was ich im screenshot nicht genau sehe: die Parameter hinter dem converter müssen mit "komma" getrennt werden - dürfte kein Punkt sein.
So wird es funktionieren.
vg
Jörg
Die sind mit ',' getrennt. On off und dim funktioniert, nur der rgb teil nicht
wenn Du das gleiche bei den anderen beiden GAD drinstehen hast sieht das gut aus. Wüsste jetzt nicht warum das hängen sollte.
Passiert nichts ? Du könntest jetzt nochmal die Unterstriche in den GAD gegen Punkte tauschen - das ist der einzige Unterschied zu meiner def.
vg
jörg
Wie hast du die gads eigentlich in SV hintereinander bekommen?
kannste per html (div mit css) machen - oder
einfacher mit Tabelle (GADs in die <TD>) - oder
schöner mit den Design-Blocks von sv (so in dem Beispiel von gestern, kannst Dir ja runterladen und anschauen)
geht rgb jetzt ?
vg
jörg
Zitat von: ergerd am 04 Januar 2015, 08:48:55
Hallo Jörg,
ich habe Perl 5.16.0 auf der Synology laufen.
Ich denke, das mit den Logzeilen sollte ich hinbekommen, würde es gern versuchen.
Was muss ich wo einbauen?
Grüße
Rainer
Hi Rainer,
damit wir nicht per trial and error im dunkeln stochern, ich mach Dir was fertig.
vg
jörg
Rgb kann ich gerade nicht testen, meine Frau stört das Licht an aus sie ganze zeit. Wo kann ich das eigentlich runterladen, finde zwar beispiele aber keinen code
büddeschön: (screenshot einige post davor)
http://forum.fhem.de/index.php/topic,30909.msg239692.html#msg239692
Zitatmeine Frau stört das Licht an aus sie ganze zeit
;D kenn ich !!! (schreib mal ein Modul für RGB Lampen ... oder anders: frag mal meine ;) )
vg
Danke, habe mir den Sourcecode aus der Doku anzeigen lassen, und es von dort nachgebaut, das klappte auch.
Rgb, funktioniert immer noch nicht.
Im fhem log sehe ich folgendes
2015.01.04 15:43:41 3: TVLicht RGBW2 slot 6 dim 20 0 res res in converter rcv start TV_color.r in converter rcv start TV_color.g in converter rcv start TV_color.b in converter rcv start TV_color.r in converter rcv start TV_color.g in converter rcv start TV_color.b
ja, da ist noch debug code von mir der da auftaucht - der war aber für was anderes. fronthem gibt einem halt sehr viel Freiheiten -das macht aber ferndiagnose schwer.
Was auch sein kann ist das durch die Tests die logik des converters jetzt "schief" steht (das geht, der muss ja die drei reinkommenden GAD zu einem RGB synchronisieren, dafür zählt der intern mit).
Mach mal einen kompletten fhem neustart zwischendurch, dann stehen die internen Zähler alle auf Null. Sonst kannst Du jetzt evtl lange suchen!
Hallo zusammen,
irgendwie funktioniert bei mir recht wenig.
State beim fronthem ist ???
State beim fronthemDevice ist Connected. Im fronthemDevice dirket konnte ich aber nichts mit GADs machen.
Unter SmartVISU habe ich im rechten oberen Eck den Error. Sollte der nicht irgendwann weg gehen?
Jetzt wollte ich mal fhem neustarten und fhem startet nicht mehr.
Wenn ich auf der Konsole fhem starte kommt
root@cubie:/opt/fhem/log# Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/01_fronthem.pm line 255.
Zitat von: dancatt am 04 Januar 2015, 16:19:14
Hallo zusammen,
irgendwie funktioniert bei mir recht wenig.
State beim fronthem ist ???
State beim fronthemDevice ist Connected. Im fronthemDevice dirket konnte ich aber nichts mit GADs machen.
Unter SmartVISU habe ich im rechten oberen Eck den Error. Sollte der nicht irgendwann weg gehen?
Jetzt wollte ich mal fhem neustarten und fhem startet nicht mehr.
Wenn ich auf der Konsole fhem starte kommt
root@cubie:/opt/fhem/log# Type of argument to keys on reference must be unblessed hashref or arrayref at ./FHEM/01_fronthem.pm line 255.
was für eine perl version hast Du ? vg jörg
Zitat von: herrmannj am 04 Januar 2015, 16:36:19
was für eine perl version hast Du ? vg jörg
v5.14.2 auf einem Cubietruck mit Igor Image.
Fhem lässt sich zumindest mal starten wenn der Apache unten ist. Den Apache darf ich erst nach fhem starten.
Im Anhang noch ein Sreenshot von fronthemDevice.
list fronthem:
Internals:
CFGFN
FD 15
NAME fronthem
NR 111
STATE ???
TYPE fronthem
Helper:
COMMANDSET save
Client:
fronthem_dc_notebook registered
Config:
Ipc:
Ws:
name fronthem:127.0.0.1:56571
pid 31363
Sock:
FD 18
NAME fronthem:127.0.0.1:56571
TYPE fronthem
buffer
registered ws
Parent:
Listen:
Receiver:
Ws:conn-a4bgooot:
device fronthem_dc_notebook
identity unknown
sender 192.168.178.200
state connected
Sender:
Fronthem_dc_notebook:
connection ws
ressource conn-a4BgOoot
state connected
Attributes:
group Terminal
room 9.09_Einstellungen
list fronthem_dc_notebook:
Internals:
CFGFN
DEF 192.168.178.200
NAME fronthem_dc_notebook
NR 112
NTFY_ORDER 50-fronthem_dc_notebook
STATE connected
TYPE fronthemDevice
CHANGETIME:
Helper:
Dblog:
Protokoll:
Dblog:
TIME 1420386127.37654
VALUE 0.1
State:
Dblog:
TIME 1420386126.89064
VALUE connected
Readings:
2015-01-04 16:25:20 identity 192.168.178.200
2015-01-04 16:42:07 protokoll 0.1
2015-01-04 16:42:06 state connected
Helper:
gateway fronthem
init done
converter:
NumDisplay
Direct
RGBCombined
NumDirect
OnOff
monitor:
Attributes:
group Terminal
room 9.09_Einstellungen
der Start von Apache kann nichts mit fhem zu tun haben. Wenn doch ist irgendwas ganz schräg konfiguriert ... (keine Idee, ist auf OS Level).
Die Fehlermeldung die Du geschickt hast passt zu einem bekannten Issue mit perl < 5.14, ich schick Dir eine pm dann wissen wir es.
Die rote Ecke geht weg wenn fronthem richtig läuft - und du dann ctrl-f5 in sv drückst.
Der thread ist leider schon lang, findest trotzdem viel wertvolles drin.
vg
jörg
Danke Jörg, ich musste Neustarten. Jetzt läuft es.
Wie hast du das Value wegbekommen? Bin gerade erst dabei mich in css einzuarbeiten, bisher alles mit wysiwyg Editoren gemacht
Habe die Dateien ersetzt. Nach einem Neustart von fhem bekomme ich nun:
root@cubie:/opt/fhem# Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.
Fhem startet also immer noch nicht. Apache gestoppt...fhem gestartet und Apache wieder gestartet => fhem läuft. Den Apache brauche ich ja wegen smartVISU. Irgendwie hängt es da.
Der Fehler 01_fronthem Modul scheint aber weg zu sein.
Wenn ich aber in die Detail-Ansicht vom fronthemDevice gehe sieht das immer noch so aus wie im Screenshot in meinem vorherigen Post.
Noch ein paar Fragen:
- Muss ich eigentlich was in der config.ini unterhalb des Verzeichnisses smartVISU ändern? Hierzu steht nichts in der Anleitung. In der config.ini stehen nur Clients welche bei mir nicht existieren.
- Wo liegt die Datei fronthemEditor.js? Im Wiki steht ".../fhem/www/frontend/pgm2/" und hier im Thread in der zip liegt sie unter "fhem\www\pgm2"
- Muss Domotiga vorhanden sein? Soweit ich weiß nicht.
Zitat von: dancatt am 04 Januar 2015, 17:41:07
Habe die Dateien ersetzt. Nach einem Neustart von fhem bekomme ich nun:
root@cubie:/opt/fhem# Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.
Fhem startet also immer noch nicht. Apache gestoppt...fhem gestartet und Apache wieder gestartet => fhem läuft. Den Apache brauche ich ja wegen smartVISU. Irgendwie hängt es da.
dazu bitte separaten Fehlermeldung an den maintainer (lt. maintainer.txt, vmtl rudi). Hat nichts mit fronthem zu tun - fronthem benutzt blocking.pm nicht. Allerdings denke ich das es bereits viele Systeme gibt die apache und blocking.pm auf einem system haben. Vielleicht findest Du was im forum.
Zitat
Der Fehler 01_fronthem Modul scheint aber weg zu sein.
super! qed
Zitat
Wenn ich aber in die Detail-Ansicht vom fronthemDevice gehe sieht das immer noch so aus wie im Screenshot in meinem vorherigen Post.
sv driver richtig konfigurieren, ctrl-f5 in sv, dann im detailscreen fronthem ctrl-f5.
Zitat
Noch ein paar Fragen:
- Muss ich eigentlich was in der config.ini unterhalb des Verzeichnisses smartVISU ändern? Hierzu steht nichts in der Anleitung. In der config.ini stehen nur Clients welche bei mir nicht existieren.
Kannste, musste aber nicht.
Zitat
- Wo liegt die Datei fronthemEditor.js? Im Wiki steht ".../fhem/www/frontend/pgm2/" und hier im Thread in der zip liegt sie unter "fhem\www\pgm2"
gleiches Verzeichniß wie fhemweb.js
Zitat
- Muss Domotiga vorhanden sein? Soweit ich weiß nicht.
Nö - ich habe mir nur den driver von sv "geliehen" ;)
vg
jörg
Hallo,
es gibt eigentlich, außer wenn config.db genutzt wird, nur dann eine Verbindung zwischen Apache und Fhem, wenn beide den selben Port benutzen. Hast Du mal geprüft auf welchem Port der Apache hört (sowohl http als auch Telnet). Ansonsten schmeiß doch mal den Apache runter und installiere nginx. Bei mir laufen php-Sachen mit nginx einfach schneller.
Grüße Jörg
Zitat von: hyper2910 am 04 Januar 2015, 17:26:30
Danke Jörg, ich musste Neustarten. Jetzt läuft es.
Wie hast du das Value wegbekommen? Bin gerade erst dabei mich in css einzuarbeiten, bisher alles mit wysiwyg Editoren gemacht
ah, super. Der RGBCombined ist da anspruchsvoller als die anderen converter. Im laufenden Betrieb klaglos - verzeiht aber eben Fehelr auch mal nicht :)
Value: ich musste user css nehmen, Bernd sagt geht auch ohne. In den Demohäusern ist da aber auch ein Beispiel drin (ist mir wieder eingefallen). Schalte vorher den sv treiber ab sonst bekommst Du die GADs aus den Demohäusern alle in den Editor.
vg
joerg
Zitat von: JoWiemann am 04 Januar 2015, 17:53:33
Ansonsten schmeiß doch mal den Apache runter und installiere nginx. Bei mir laufen php-Sachen mit nginx einfach schneller.
Habe ich gemacht. Mit nginx kenne ich mich leider nicht aus. Was muss ich da noch konfigurieren? Beim Aufruf von "http://serverip/smartvisu" kommt "Welcome to nginx!"
Vielen Dank.
Hallo, was hast du als Document Root eingestellt? Wo liegt der smartvisu Ordner?
Dann muss man den Server konfigurieren:
sudo nano /etc/nginx/sites-enabled/default
Folgende Konfiguration sollte eigentlich direkt funktionieren und kann direkt überkopiert werden. Eine toller Einstieg in die Konfiguration von nginx gibt übrigens die Wiki-Seite bei ubuntuusers.de.
server {
listen 80;
root /var/www;
index index.html index.php;
server_name localhost;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Grüße Jörg
Zitat von: JoWiemann am 04 Januar 2015, 20:15:19
Dann muss man den Server konfigurieren:
Danke. Bin schon die ganze Zeit am lesen und probieren. Habs auch schon hinbekommen. Danke
Hi Jörg,
In den Demohäusern finde ich nichts, teilweise benutzen die device.Dimmer, aber dann hat man ein Lampen Symbol daneben. Vielleicht kann Bernd seine Idee mal kundtun. Der Teil sieht uja wie bei dir aus:
<div class="cells">
<div class="cell2 ui-btn-up-a">Leselampe</div>
<div class="cell1 ui-btn-up-a"> {{ basic.shifter('ld.sh.wz.light.lese', 'wz.light.lese.switch', 'wz.light.lese.dim' , '', '', 0, 100) }}</div>
<div class="cell4 pos ui-btn-up-a xdimmer">{{ basic.slider('ld.sh.wz.light.lese.dim', 'wz.light.lese.dim', 0, 100) }}</div>
<div class="cell1 ui-btn-up-a">{{ basic.colordisc('ld.sh.wz.light.lese.color', 'wz.light.lese.r', 'wz.light.lese.g', 'wz.light.lese.b', 0, 255, 16, 20) }}</div>
<div class="cell2 ui-btn-up-a"></div>
hat er schon, ist ein/zwei Tage zurück.
Mein user.css für xdimmer sieht so aus
.xdimmer .ui-slider .ui-input-text {
display: none !important;
}
.xdimmer .ui-slider {
margin: 0px 0 0 10px;
position:relative; top:-5px; left:-48px; width:100%;
}
vg
jörg
Teste ich morgen, wie lädst du die User.css?
simple: im pages liegt visu.css als add-on zu den themes. Da reinschrieben
Hallo Jörg,
nach der Umstellung von Apache auf nginx kann ich nun fhem ohne Probleme restarten wenn nginx läuft.
Das rote Error-Dreieck in SmartVISU ist anscheinend auch weg.
Was noch nicht passt ist folgendes:
- In der Detailview von fronthem habe ich unter state immer noch ? ? ?. Trotz ctrl-F5
- In der Detailview vom fronthemDevice kann ich mit GAD immer noch nichts machen. Keine Möglichkeit ein GAD zu definieren. Siehe Screenshot.
Beim Laden der Detailview des fronthemDevices kommen auch 2 JavaScript Fehler:
cordova-2.3.0.js:1 Uncaught SyntaxError: Unexpected token <
webviewcontrol.js:1 Uncaught SyntaxError: Unexpected token <
Also am Rotwein kann es nicht liegen?! Im Screenshot steht doch connected oder ?!
Zitat von: JoWiemann am 04 Januar 2015, 21:36:01
Also am Rotwein kann es nicht liegen?! Im Screenshot steht doch connected oder ?!
Ich glaube das ist das was mir grad fehlt....
Die ? ? ? stehen im state im fronthem.
Der Screenshot ist vom fronthemDevice. Dort sollte es doch möglich sein GADs zu definieren, oder?
.200 ist die ip des rechners auf dem der browser läuft ?
wenn ja: mach mal das browser fenster zu. state geht auf "disconnected" ?
Ja, aber nur wenn entsprechende GADs definiert sind. Wenn Du 72_FRITZBOX einsetzt kannst Du Dir das GAD von Bernd https://github.com/bgewehr/smartVISU installieren und nutzen.
Grüße Jörg
Zitat von: herrmannj am 04 Januar 2015, 21:42:55
.200 ist die ip des rechners auf dem der browser läuft ?
Ja
Zitat von: herrmannj am 04 Januar 2015, 21:42:55
wenn ja: mach mal das browser fenster zu. state geht auf "disconnected" ?
Ja
Zitat von: JoWiemann am 04 Januar 2015, 21:43:28
Ja, aber nur wenn entsprechende GADs definiert sind. Wenn Du 72_FRITZBOX einsetzt kannst Du Dir das GAD von Bernd https://github.com/bgewehr/smartVISU installieren und nutzen.
Zitat aus dem Wiki: "Sobald ein fronthemDevice definiert ist, kann man über die device details in fhem die GADs definieren und die Rechte verteilen."
Vorausgesetzt es sind GADs in smartVISU definiert...
Crtl+f5 in smartVISU und fhem Seite mit f5 aktualisieren, dann sollten sie da sein.
Ansonsten vielleicht noch ein Rechte Problem?
Zitat von: fidel am 04 Januar 2015, 22:05:15
Vorausgesetzt es sind GADs in smartVISU definiert...
Crtl+f5 in smartVISU und fhem Seite mit f5 aktualisieren, dann sollten sie da sein.
Ansonsten vielleicht noch ein Rechte Problem?
Danke. Das erklärt so einiges. Zuviel hier schon gelesen. Mehr verwirrt als recht ist.
Hallo!
Erstmal danke für das Modul. Was man damit jetzt schon alles machen kann :D
2 Probleme wollte ich noch melden:
- Nach einen shutdown restart wird mein FHEM nicht richtig neugestartet. In der console sehe ich zwar das FHEM neu startet (fehlermeldung die immer beim start kommt) aber im browser wird auch nach einer minute nichts geladen. Auch mit telnet tut sich nichts. FHEM und smartvisu liegt auf einem macmini
- nach einem rename desstürzt FHEM ab
Grüße
Zitat von: fhainz am 04 Januar 2015, 22:54:18
Hallo!
Erstmal danke für das Modul. Was man damit jetzt schon alles machen kann :D
2 Probleme wollte ich noch melden:
- Nach einen shutdown restart wird mein FHEM nicht richtig neugestartet. In der console sehe ich zwar das FHEM neu startet (fehlermeldung die immer beim start kommt) aber im browser wird auch nach einer minute nichts geladen. Auch mit telnet tut sich nichts. FHEM und smartvisu liegt auf einem macmini
- nach einem rename desstürzt FHEM ab
Grüße
Hi,
Danke.
Rename ist ok (sprich todo)
shutdown restart scheint ein mac-feature zu sein ;). Welche Fehlermeldung (console), wie weit kommt er laut log ?
Danke und grüße
In der console kommt nur der fehler der immer kommt. Im FHEM-Log steht das:
Zitat2015.01.04 23:14:02.938 0: Server shutdown
2015.01.04 23:14:05 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2015.01.04 23:14:05.105 1: Including fhem.cfg
2015.01.04 23:14:05.113 3: Opening jeelink device /dev/tty.usbserial-AE01DUEH
2015.01.04 23:14:05.123 3: Setting jeelink baudrate to 57600
2015.01.04 23:14:05.124 3: jeelink device opened
2015.01.04 23:14:06.133 3: Opening CUL1 device /dev/tty.usbmodem1d1321
2015.01.04 23:14:06.133 3: Setting CUL1 baudrate to 9600
2015.01.04 23:14:06.133 3: CUL1 device opened
2015.01.04 23:14:06.255 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.01.04 23:14:06.284 1: HMLAN_Parse: HMLan new condition disconnected
2015.01.04 23:14:06.284 3: Opening HMLan device 10.0.0.55:1000
2015.01.04 23:14:06.286 3: Can't connect to 10.0.0.55:1000: Connection refused
2015.01.04 23:14:06.316 1: WEB: Can't open server port at 63191: Address already in use. Exiting.
Grüße
Zitat von: herrmannj am 04 Januar 2015, 23:09:26
shutdown restart scheint ein ...
shutdown restart in der Fhem Commandozeile führt zu einem Neustart von Fhem.
Grüße Jörg
ZitatIn der console kommt nur der fehler der immer kommt
ist nix allgemeines (Fehler) sondern speziell (bei mir kommt keiner). Auch wenn er "immer" kommt, sach ma büdde (hilft mir evtl "um die Ecke zu denken")
laut log: exit weil web noch offen (port hast Du angepasst ?). Da bin ich evtl durch einen fehler beim shutdown involviert obwohl mir nix ins Gedankenfeld springt - ich mach gerade house keeping - Mal schauen ob das in nächster beta bestand hat.
Kann das Verhalten (shutdown restart funktioniert nicht) ein zweiter mac benutzer bestätigen oder dementieren ?
Danke und Grüße
Jörg
Zitat von: JoWiemann am 04 Januar 2015, 23:23:41
shutdown restart in der Fhem Commandozeile führt zu einem Neustart von Fhem.
Grüße Jörg
... oder auch eben nicht ;)
jedenfalls bei Linux. Bei mir RPi und Debian. Funktioniert jedenfalls mit smartVISU. Somit kann ich meine cfg weiterhin manuell editieren und bekomme nicht der Shutdown durch rereadcfg. :D
;) Ja, bei mir ja auch. Nur eben auf'm mac bei fhainz nich ..
Tante edith:
Zitatrereadcfg. :D
bin ich (auch) grad mit bei. Obwohl ich immer noch nicht erstehe wozu man das braucht. Aber mei, wenns Euch glücklich macht .... ;D
Zitat von: herrmannj am 04 Januar 2015, 23:23:57Auch wenn er "immer" kommt, sach ma büdde (hilft mir evtl "um die Ecke zu denken")
Zitat"my" variable $gg masks earlier declaration in same scope at ./FHEM/99_myUtilsEM.pm line 848.
Constant subroutine main::SHIFT redefined at /Volumes/HDD/Users/Fabian/perl5/perlbrew/perls/perl-5.16.0/lib/5.16.0/constant.pm line 151, <$fh> line 2508.
Der erste Fehler kommt klar aus dem Utils Modul, den 2. Fehler hab ich seit einiger Zeit, keine Ahnung wo der herkommt plötzlich war er da.
Zitat von: herrmannj am 04 Januar 2015, 23:23:57
laut log: exit weil web noch offen (port hast Du angepasst ?).
Wo Port anpassen?
Grüße
Zitat von: hyper2910 am 04 Januar 2015, 21:03:08
Hi Jörg,
In den Demohäusern finde ich nichts, teilweise benutzen die device.Dimmer, aber dann hat man ein Lampen Symbol daneben. Vielleicht kann Bernd mal...
Mir ist aufgefallen, dass im device.shutter() ein slider ohne Input ist. Schaut Euch den Code an, da habe ich die Idee mit class="pos" her...
da
2015.01.04 23:14:06.316 1: WEB: Can't open server port at 63191: Address already in use. Exiting.
der 63191 ist noch offen, daher exit. Der kommt aber nicht von mir (iss ja WEB). Da ist er ja aber nicht standard, deswegen die Frage.
Wenn Du nur einen shutdown machst wird der nicht clean durchlaufen. Kannst Du sehen wo (console?) der aussteigt ?
vg
jörg
Zitat von: bgewehr am 04 Januar 2015, 23:43:40
Mir ist aufgefallen, dass im device.shutter() ein slider ohne Input ist. Schaut Euch den Code an, da habe ich die Idee mit class="pos" her...
ah, Danke. Bei mir hat es nicht funktioniert (was auch gut an mir liegen kann). Ich komme erst später dazu - wenn jemand schneller ist gern info in den thread - oder noch besser auch ins WIKI .
vg
jörg
63191 ist meiner normaler FHEMWEB port. Ein shutdown restart funktioniert ohne die beiden fronthem devices ganz normal.
In der console hab ich nur die 2 meldungen. Wie kann ich herausfinden wo FHEM aussteigt?
Grüße
console oder log oder gar nicht.
Ist halt irgendwas spezifisches in Deiner Umgebung, normal funktioniert das. Aber macht Dir nicht zu viel Stress mit der Suche, wenn Du was siehst hab ich einen Ansatz. Sonst warten wir mal auf die nächste beta (also Du warten - ich coden :-X ) und schauen mal ob es dann immer noch auftritt. Wenn ja müssen wir tiefer suchen - dann vlt mit log verbose 5.
vg
jörg
Mir ist noch etwas aufgefallen:
Sobald mein Laptop die Verbinung zu Fronthem verliert (Laptop zugeklappt somit wlan aus) geht der state auf disconnected und verbindet nicht mehr. Nur ein FHEM Neustart, der zu diesem Zeitpunkt wieder problemlos funktioniert, löst das Problem und der state geht nach dem Neustart auf connected.
Also sobald fronthem mit smartvisu connected ist funktioniert der Neustart bei mir nicht.
Grüße
Edit:
Anscheinend passiert das nicht immer. Vorher hatte ich das 2x nachstellen können, jetzt schalte ich das WLAN aus und wieder an und die verbindung ist wieder da.
Zitat von: fhainz am 05 Januar 2015, 00:01:45
63191 ist meiner normaler FHEMWEB port. Ein shutdown restart funktioniert ohne die beiden fronthem devices ganz normal.
In der console hab ich nur die 2 meldungen. Wie kann ich herausfinden wo FHEM aussteigt?
Grüße
Mach mal fhem shutdown. Lösche 01_fronthem,31_frothemdevice,fhconverter und unter pgm2 den fronthem editor. Den fronthem ordner der durch die Verbindung zum device angelegt wird auch löschen, unter fhem/www/ Dann alles neu rein kopieren, Berechtigungen (chmod, chown) setzen und fhem starten.
Ich hatte dieses Problem auch...
Leider hat das nichts gebracht.
Rechte hab ich mit
sudo chmod -R a+w fhem gesetzt, chown hab ich noch nie verwendet.
Hattest du das Problem unter OS X?
Grüße
Nein, aber ich hatte die selbe Fehlermeldung cant open server port Adress already in use...
Zitat von: fidel am 05 Januar 2015, 10:40:25
Mach mal fhem shutdown. Lösche 01_fronthem,31_frothemdevice,fhconverter und unter pgm2 den fronthem editor. Den fronthem ordner der durch die Verbindung zum device angelegt wird auch löschen, unter fhem/www/ Dann alles neu rein kopieren, Berechtigungen (chmod, chown) setzen und fhem starten.
Ich hatte dieses Problem auch...
Hi,
Nee, macht nicht !
Wenn Du in das modul schaust dann stehen da noch 2,5 Millionen mal # TODO ... ;) Die stehen da nicht für neue features sondern um irgendwelche Sondersituationen abzufangen. Macht Euch keinen Stress - da bin (leider) erst mal ich gefragt.
vg
Jörg
Zitat von: fhainz am 05 Januar 2015, 10:01:51
Mir ist noch etwas aufgefallen:
Sobald mein Laptop die Verbinung zu Fronthem verliert (Laptop zugeklappt somit wlan aus) geht der state auf disconnected und verbindet nicht mehr. Nur ein FHEM Neustart, der zu diesem Zeitpunkt wieder problemlos funktioniert, löst das Problem und der state geht nach dem Neustart auf connected.
Also sobald fronthem mit smartvisu connected ist funktioniert der Neustart bei mir nicht.
Grüße
Edit:
Anscheinend passiert das nicht immer. Vorher hatte ich das 2x nachstellen können, jetzt schalte ich das WLAN aus und wieder an und die verbindung ist wieder da.
Hi & Danke,
ich habe das auch gesehen, wird abgeschafft!
Die ganz genaue Konstellation mit der man das nachstellen kann habe ich auch noch nicht gefunden (in 9 von 10 Fällen klappt es bei mir). Im Prinzip ist es aber für mich nachzuvollziehen - und damit auch zu beseitigen.
vg
Jörg
Ich habe mal den nw_tiles Stil ausprobiert und muss sagen, dass ich das noch schöner finde. Kombiniert mit ein bisschen Quad design kommt das einem Gira HomeServer schon recht nahe!
Hallo Jörg,
vielleicht wurde es auch schon gemeldet. Mir ist aufgefallen das Werte, in diesem Fall die Temperatur, welche nach der Kommastelle eine 0 liefern nicht mit Komma angezeigt werden.
Als Converter habe ich NumDisplay eingstellt.
@Bernd, wo ändert man den Style zu nw_tiles?
Gruß
Tino
Zitat von: oniT am 05 Januar 2015, 13:50:54
...
vielleicht wurde es auch schon gemeldet. Mir ist aufgefallen das Werte, in diesem Fall die Temperatur, welche nach der Kommastelle eine 0 liefern nicht mit Komma angezeigt werden.
Als Converter habe ich NumDisplay eingstellt.
...
Hallo Tino,
hast Du mal geschaut ob auf sv Seite basic.float und basic.value sich unterscheiden ? Das ist vmtl ein Ausgabethema, fronthem schickt das als float dahin.
NumConverter habe ich schon (rudimentär) eine anpassbare Formatierung spendiert. Die ist aber eher dafür da um die Nachkommastellen zu begrenzen.
vg
jörg
Zitat von: herrmannj am 05 Januar 2015, 14:08:25
hast Du mal geschaut ob auf sv Seite basic.float und basic.value sich unterscheiden ?
Ich hab das gerade getestet. basic.value zeigt einen Integer Wert an wenn einer geliefert wird. basic.float setzt an einen integer .0 dran.
Grüße
Zitat von: bgewehr am 05 Januar 2015, 12:38:00
Ich habe mal den nw_tiles Stil ausprobiert und muss sagen, dass ich das noch schöner finde. Kombiniert mit ein bisschen Quad design kommt das einem Gira HomeServer schon recht nahe!
Ah, schick !
generell denke ich das wir, in Bezug auf die Möglichkeiten in sv, ohnehin noch recht am Anfang stehen. Irgendwo auf den sv Seiten habe ich auch ein tutorial gesehen wie man sich (basierend auf den themeroller themes) komplett eigene designs erstellen kann.
Ich bin überzeugt davon das mit der wachsenden Stabilität von fronthem und dem breiteren Einsatz von sv für fhem auch immer mehr von den css, js, und webdesign geeks (die wir ja hier im forum haben) hier vorbeischauen und die Möglichkeiten für sich erkennen. Und sicher dann auch hier einsteigen und viele Add-ons rein bringen.
Daher sind auch die screenshots von Dir, Bernd, immer super - das macht ja alles Lust auf mehr 8) Gerne mehr davon
vg
jörg
Zitat von: fhainz am 05 Januar 2015, 14:14:23
Ich hab das gerade getestet. basic.value zeigt einen Integer Wert an wenn einer geliefert wird. basic.float setzt an einen integer .0 dran.
Grüße
Ah super, danke - müsste also mit basic.float so gehen wie gewünscht.
vg jörg
Bei mir wird weder mit dem
{{ basic.value('dim_aussen.temperatur', 'dim_aussen.temperatur', ' °C') }}
noch mit dem
{{ basic.float('dim_aussen.temperatur', 'dim_aussen.temperatur', ' °C') }}
die Kommastelle bei einem Wert mit .0 angezeigt.
Der Wert steht im state eines Dummys und wird dort mit 3.0 angezeigt. Was mach ich hier dann falsch?
Danke
Gruß
Tino
Welcher Converter?
[gelöst]
{{ basic.float('dim_outdoor.temperature', 'dim_outdoor.temperatur', 'temp') }}
{{ basic.float('dim_outdoor.temperature', 'dim_outdoor.temperatur', '°') }}
Entscheidend ist die unit "temp" oder auch "°". Die unit kommt aus der lang_xx.txt. Zumindest steht es so in der Doku:
Zitatunit
a unit, tries to get the format for that unit from the language-file (optional)
und das Ergebnis wird richtig angezeigt.
Danke
Gruß
Tino
Schon mal Direct probiert?
Zitat von: oniT am 05 Januar 2015, 13:50:54
@Bernd, wo ändert man den Style zu nw_tiles?
Macht man in der Seite!
Schau mal in meinem Git unter Pages/gewehr in den Raum roms_menu.html
http://www.github.com/bgewehr/SmartVISU
kann mir jemand folgendes ICOn schicken?
sani_heating_boot.svg und png
die fehlen mir leider...
Zitat von: Grimm80 am 05 Januar 2015, 18:15:30
kann mir jemand folgendes ICOn schicken?
sani_heating_boot.svg und png
die fehlen mir leider...
Schau mal im github von bgewehr nach, da habe ich es auch gefunden ::) Danke bgewehr!
schöne Grüße
Jo
Hat schon jemand max Komponenten Integriert?
Ich hab MAX Komponenten integriert aber derzeit nur die reine Temperatur-Regelung mit minimal veränderten standard-widgets (noch ohne auto, eco, boost, etc, bau ich aber bestimmt "mal").
Hallo, Leute, gestern habe ich mir weitere Design Möglichkeiten angesehn, konkret das Layout von 2ndsky aus dem knx Userforum. Es baut sehr kompakte Tabellen und die Widgets sind alle in Popups:
Hallo,
noch eine Feststellung. NumDisplay ist ja laut Wiki angedacht:
Zitat
NumDisplay
NumDisplay arbeitet nur in eine Richting, FHEM zu Frontend. Die Werte werden ohne Umwandlung weitergegeben. Es ist dazu gedacht Zahlenwerte zu übergeben, ohne etwas zu verändern.
z.B. für Temperaturwerte
um Temperaturwerte 1:1 zu übergeben. Bei Minustemperaturen wird das Vorzeichen jedoch weggelassen. Stellt man den Converter auf Direct oder NumDirect wird das Vorzeichen mit übergeben.
Gruß
Tino
Zitat von: bgewehr am 06 Januar 2015, 09:27:48
Hallo, Leute, gestern habe ich mir weitere Design Möglichkeiten angesehn, konkret das Layout von 2ndsky aus dem knx Userforum. Es baut sehr kompakte Tabellen und die Widgets sind alle in Popups:
...Sieht echt klasse aus. Hab mir das auch mal angesehen. Die Buttons für die Rolladen müssten noch vom Button-Rahmen befreit werden - mal sehen, wie das geht. Ansonsten finde ich die von Dir ergänzten Daten (Temp, Energieverbrauch etc.) in der Raumübersicht super. Bei der Version von 2ndsky finde ich es toll, dass er den Raumnamen und das Raumicon oben im Titelmenü anzeigt. Das spart nochmals Platz...
Gruß
Thomas
Raumname im Titelmenü bedeutet aber Anpassung der base.html - also wieder ein Stück weniger updatefest!
...stimmt. Aber das letzte Update ist sowieso sehr alt. Einmal im Jahr bin ich dazu bereit :-)
Gruß
Thomas
Für die Buttons hat 2ndsky schon ein eigenes lbutton widget in seiner widget_visu.html angelegt. Ich hab diese bisher noch nicht übernommen!
OK. Werd ich mir mal ansehen. Danke.
Gruß
Thomas
Zitat von: bgewehr am 06 Januar 2015, 11:38:20
Raumname im Titelmenü bedeutet aber Anpassung der base.html - also wieder ein Stück weniger updatefest!
Hi zusammen,
das muss man den sv Leuten lassen, sie haben dafür mit gedacht. Die Anpassung in base.html (ich mache das bei einer speziellen root.html) kann man update fest machen wenn man die modifizierte base.html im eigenen /page Verzeichnis liegen hat.
Die template engine schaut zuerst dort nach und danach in /base, deswegen sind Anpassungen an (root, base) etc für spezielle Geräte möglich - und werden später auch nötig sein.
Mittlerweile sind wir mNn auch an einem Punkt an dem wir uns aber über das Thema sv updates tatsächlich noch mal Gedanken machen sollten. Während der Entwicklung habe ich die Jungs von sv sporadisch informiert und habe auch die Mandantenfähigkeit angesprochen.
Das fanden die auch cool und wollten das übernehmen. Die entsprechenden Anpassungen habe ich denen geschickt - seid dem dann aber auch kein feedback mehr bekommen. Insofern stellt sich jetzt wirklich die Frage ob wir das forken wollen. Wenn ja sollten wir das mMn mit Bedacht machten: folgendes Szenario: wir verändert die core files (widget.js und co) - dann kommt ein update von sv mit vielleicht neuen coolen widgets. Dann würde sich das nur noch händisch mergen lassen.
Habt ihr Ideen , Vorschläge ?
BETA ZWEI:
geht planmäßig voran. In BETA EINS waren noch viele fliegende Verdrahtungen drin, ich leg die alle schön in Dosen und unter Putz. Fertigstellungsgrad etwa 60-70%. Damit haben sich auch bereits fast alle Probleme aus BETA EINS erledigt. Die Aussteiger wegen unterbrochener Verbindungen schaffe ich überhaupt nicht mehr zu provozieren, da kommen trotzdem noch einige Sicherheitsschaltungen zu. Dann fehlen noch die "minor" Bugs, hauptsächlich in Bezug auf die converter.
vg
Jörg
Zitat von: reichi am 05 Januar 2015, 22:55:08
Ich hab MAX Komponenten integriert aber derzeit nur die reine Temperatur-Regelung mit minimal veränderten standard-widgets (noch ohne auto, eco, boost, etc, bau ich aber bestimmt "mal").
Hi,
wie hast du die Temperatur Regelung gebaut?`
{{ device.rtr('HZ01', 'Wohnzimmer', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_state', 'WZ_rtr_comfort', 'WZ_rtr_night','WZ_rtr_frost', 'WZ_rtr_state', 'WZ_rtr_text' ) }}
<td></td></tr>habe dies so gemacht.
aber die Steps bekomme ich nicht hin, welches GAD hast du wie belegt?
Hallo zusammen,
Mir ist noch was komfortables zum Thema Attribute via smartvisu verändern eingefallen:
Problem:
Attribute lassen sich zwar schalten, weil das keine events produziert bekommen die anderen smartVisu Displays nichts davon mit.
Lösung
ein dummy und ein notify in fhem:
sv schaltet die den dummy (der die anderen sv aktualisiert) und das notify setzt das attrib (pari zum dummy) auf dem device.
In den seltenen Fällen wo das schalten von Attributen überhaupt Notwendig ist lässt sich so die fhem limitation smart umschippern.
Für "disable" wird es unabhängig eine komfortable build-in Lösung geben.
vg
Jörg
Zitat von: herrmannj am 06 Januar 2015, 13:13:19
Habt ihr Ideen , Vorschläge ?
Das SV-Projekt war bis Ende 2013 sehr aktiv. Die aktuelle Version ist jedoch über 1 Jahr alt. Hier im Forum besteht aktuell reges Interesse an dem Projekt und offensichtlich auch die Bereitschaft, das Projekt voranzutreiben. Da die SV-Jungs z. Zt. wenig motiviert scheinen bzw. vielleicht auch zeitlich enge Grenzen haben, gibt es meiner Meinung nach 3 Möglichkeiten:
1. Die SV-Jungs geben Dir Zugriff auf die Sourcen und Du übernimmst (temporär) das Projekt.
2. Wir machen getrennt weiter, bleiben aber möglichst kompatibel zu allen anderen SV-Schnittstellen. Dann können auch die Leute aus dem KNX-Forum von unseren Erweiterungen profitieren und wenn der harte Kern wieder da ist kann die Weiterentwicklung auf dem erweiterten Code aufsetzen.
3. Wir machen getrennt weiter und lassen alles, was man für fronthem nicht benötigt einfach links liegen. Dann müssen wir natürlich die >>neuen coolen Widgets<< von Hand mergen. Die Frage ist: Wie wahrscheinlich ist es, dass sooo viele neue coole Widgets kommen, dass sich diese Arbeit nicht bewerkstelligen ließe - zumal die letzten neuen Widgets auch nicht im Release gelandet sind, sondern aus dem Forum manuell eingepflegt werden müssen.
Ich glaube, dass Nr. 3 aktuell den geringsten Aufwand (Abstimmung, Test mit anderen Systemen etc.) bedeuten würde und somit in der aktuell sehr dynamischen Phase von fronthem die zielführendste Möglichkeit ist.
Gruß
Thomas
Hallo,
ich habe auch nochmal eine Frage zu cmd set. Mal angenommen ich möchte ein On oder Off in einen Dummy schreiben. Allerdings nicht mit
set dummy on
in den State, sondern in ein eigenes Reading "test" mit
setreading dummy test on
ist das möglich? Das Auswahlfeld im cmd set zeigt mir, trotz dass das Reading "test" vorhanden ist, dies nicht an. Es wird immer nur "state" zur Auswahl vorgeschlagen. Ist das Überhaupt möglich?
Hintergrund ist, ich müsste wenn ich ein Notify zum Schalten auslösen möchte nicht immer einen extra Dummy anlegen, sondern könnte diesen mit mehrere Readings füllen.
Danke
Gruß
Tino
Zitat von: bgewehr am 06 Januar 2015, 09:27:48
Hallo, Leute, gestern habe ich mir weitere Design Möglichkeiten angesehn, konkret das Layout von 2ndsky aus dem knx Userforum. Es baut sehr kompakte Tabellen und die Widgets sind alle in Popups:
Für die die verzweifelt suchen: https://github.com/2ndsky/quad
Grüße Jörg
Und für uns homematic User gibt's die angepasste Fassung unter http://www.github.de/bgewehr/SmartVISU Ihr müsst vor neben den ganzen widget_xy.html auch die visu.css und die visu.js mitnehmen und - ich habe schon wieder in die basic.html und die widgets.js hineingeändert... Dafür mit ein bisschen mehr responsive Design:
Zitat von: oniT am 06 Januar 2015, 18:57:08
Hallo,
ich habe auch nochmal eine Frage zu cmd set. Mal angenommen ich möchte ein On oder Off in einen Dummy schreiben. Allerdings nicht mit
set dummy on
in den State, sondern in ein eigenes Reading "test" mit
setreading dummy test on
ist das möglich? Das Auswahlfeld im cmd set zeigt mir, trotz dass das Reading "test" vorhanden ist, dies nicht an. Es wird immer nur "state" zur Auswahl vorgeschlagen. Ist das Überhaupt möglich?
Hintergrund ist, ich müsste wenn ich ein Notify zum Schalten auslösen möchte nicht immer einen extra Dummy anlegen, sondern könnte diesen mit mehrere Readings füllen.
Danke
Gruß
Tino
Hi Tino,
der Editor koppelt das immer an einen "set" aber das converter design sieht so etwas vor. Bernd hatte auch diesen converter angefragt und ich habe das auf der todo - aber nicht ganz oben (setreading ist ja schon speziell).
In der nächsten Version werden selbst geschriebene converter auch tatsächlich aus den 99er Dateien geladen. Damit hat man dann auch ein Mittel zur pragmatischen Umsetzung von individuellen Konzepten an der Hand - aber der wird auch als Teil der fhconverter kommen.
vg
Jörg
Mit dem Attribute Converter aus meinem fronthem git kannst Du das notify direkt ein- und ausschalten.
ich hatte das so verstanden das tino das notify triggern möchte. vg
OK, ich glaube ich verstehe den Ansatz nicht...
ich lege mich da auch nicht fest ;)
das setreading generiert ein event, das löst das notify aus.... Könnte man eigentlich einen converter bauen der das event gleich selber auslöst... Mal schauen was tino sagt :)
Ich habe gesehen dass man in der GAD-Liste im fronthemDevice keine Einträge löschen kann. Ich habe da jede Menge Einträge stehen die ich nicht mehr habe (z.B. durch Umbenennungen). Wenn ich den Ordner "/opt/fhem/www/fronthem" lösche, dann ist zwar alles korrekt nach einem Neustart, aber meine Einstellungen von den richtigen GADs sind dann logischerweise auch weg.
Wie ist hier das korrekte vorgehen?
Ich glaube, wir sollten den nativen Befehlssatz von FHEM im Editor auswählbar machen. {Set, get, Attr, trigger, setreading, readingsval, AttrVal, ?}
Zitat von: herrmannj am 06 Januar 2015, 19:44:27
ich hatte das so verstanden das tino das notify triggern möchte. vg
ja korrekt ... ;)
Zitat von: bgewehr am 06 Januar 2015, 19:52:23
Ich glaube, wir sollten den nativen Befehlssatz von FHEM im Editor auswählbar machen. {Set, get, Attr, trigger, setreading, readingsval, AttrVal, ?}
das wäre doch dann schon fast das Optimum oder :-\
Zitat von: herrmannj am 06 Januar 2015, 19:49:16
ich lege mich da auch nicht fest ;)
das setreading generiert ein event, das löst das notify aus.... Könnte man eigentlich einen converter bauen der das event gleich selber auslöst... Mal schauen was tino sagt :)
Wenn ich es richtig verstehe, müsste man dann nicht den Umweg über einen Dummy gehen der wiederum ein Notify triggert, richtig? Das hätte natürlich auch etwas. Allerdings überblicke ich da nicht die Folgen und bin mir nicht sicher ob dies dann wiederum bei allem richtig ist. Nicht, dass dann mehrere Converter programmiert werden müssen. Macht ja auch keinen Sinn.
Zitat von: dancatt am 06 Januar 2015, 19:52:16
Ich habe gesehen dass man in der GAD-Liste im fronthemDevice keine Einträge löschen kann. Ich habe da jede Menge Einträge stehen die ich nicht mehr habe (z.B. durch Umbenennungen). Wenn ich den Ordner "/opt/fhem/www/fronthem" lösche, dann ist zwar alles korrekt nach einem Neustart, aber meine Einstellungen von den richtigen GADs sind dann logischerweise auch weg.
Wie ist hier das korrekte vorgehen?
Unter dem Fronthem Device das GAD edit Fenster öffnen. Unten gibt es neben dem save Button auch cancel und delete...
@Jörg: kennst Du das hier?
http://www.theopentransporter.de/downloads/TheOpenTransporter_Dokumentation.pdf
Zitat von: bgewehr am 06 Januar 2015, 19:52:23
Ich glaube, wir sollten den nativen Befehlssatz von FHEM im Editor auswählbar machen. {Set, get, Attr, trigger, setreading, readingsval, AttrVal, ?}
ick wees nich ... da müsste der editor dann zwölf trilliarden Sonderfälle behandeln - mit reading und set macht der editor doch 95% der Anwender happy. Wenn wir den Rest mit converter (und param) machen bleibt das doch clean und wir wir schaffen kein multi-config Monster.
Zitat von: bgewehr am 06 Januar 2015, 20:07:30
@Jörg: kennst Du das hier?
http://www.theopentransporter.de/downloads/TheOpenTransporter_Dokumentation.pdf
ja hab schon mal wargenommen. Da hängt irgendein java frameork dahinter und iirgendwie ist dann alles eingeschlafen - vmtl auch aufgrund praktischer Anwendungen. Aber he - wir haben doch alles was wir brauchen, auch praktisch.
Ich kann mir vorstellen, dass es neben Reading die combo für get-Methode gibt: readingsval, get, AttrVal und für Set eben Set, setreading Attr, Direct, wobei Direct für alle möglichen Befehle genutzt werden kann und auch für "trigger ..."
Zitat von: oniT am 06 Januar 2015, 20:01:29
Wenn ich es richtig verstehe, müsste man dann nicht den Umweg über einen Dummy gehen der wiederum ein Notify triggert, richtig? Das hätte natürlich auch etwas. Allerdings überblicke ich da nicht die Folgen und bin mir nicht sicher ob dies dann wiederum bei allem richtig ist. Nicht, dass dann mehrere Converter programmiert werden müssen. Macht ja auch keinen Sinn.
yepp genau - die converter haben ja den Vorteil das sie kein Brot fressen - die lassen sich extremst fix programmieren.
Wenn ich die nur langsam liefere dann hängt das nicht damit zusammen das da was aufwendig ist. Ich kann die Stunde halt nur einmal vergeben und kümmere mich um erstmal um die groben Dinger. Die converter kann man sich als poweruser ganz schnell selber schnitzen, da ist nix dran aber viel drum-rum :)
vg
Zitat von: bgewehr am 06 Januar 2015, 20:16:41
Ich kann mir vorstellen, dass es neben Reading die combo für get-Methode gibt: readingsval, get, AttrVal und für Set eben Set, setreading Attr, Direct, wobei Direct für alle möglichen Befehle genutzt werden kann und auch für "trigger ..."
na, net so gern :)
Das reading ist in erster linie ein shortcut für die events um die Aktionen des converters zu triggern. Ich hatte früher tatsächlich mal geplant dem editor einen Experten Modus zu geben, ich glaub sogar in den ersten Versionen der alpha war zumindest der dropdown noch drin. Mittlerweile bin ich aber recht ab davon - das läßt sich doch alles mit convertern viel einfacher regeln. Selbst ein "get" passt doch perfekt ins system.
Der converter darf doch per se alles machen was er möchte, siehe Deinen mit den attributen. Setreading läßt sich genauso einfach umsetzen (oben das reading, converter machts und gibt 'done' zurück. 30 Sekunden coden ... Nagut - mit zum Kühlschank gehen 45 ;) ) vg
@jörg: Du hast Recht, alles das geht auch locker über Converter. Ich bastel mal einen für trigger, dann haben wir ja schon fast alle...
oh das ist cool, danke.
Da kommen bestimmt noch welche nach, aber ist ja auch kein limit. Für die uszu zb ... ;) Kannst mir mal so einen json schicken der aus der uszu rauskommt ? Das wäre ein guter Test für ein fhem modul mit eingebauten converter.
Zitat von: fidel am 06 Januar 2015, 20:05:56
Unter dem Fronthem Device das GAD edit Fenster öffnen. Unten gibt es neben dem save Button auch cancel und delete...
AARRGGHHH. Danke. Irgendwie nicht gesehen.
Zitat von: hyper2910 am 06 Januar 2015, 13:18:10
Hi,
wie hast du die Temperatur Regelung gebaut?`
Meine Widgets
/**
* Small RTR (Room Temperatur Regulator)
*
* @param unique id for this widget
* @param name of the rtr
* @param a gad/item for the actual temperature
* @param a gad/item for the set temperature
* @param a gad/item for the current state of the actor
* @param step for plus/minus buttons (optional, default 0.5°)
*/
{% macro smallrtr(id, txt, gad_actual, gad_set, gad_state, step) %}
{% import "basic.html" as basic %}
{% set uid = uid(page, id) %}
/** Design */
<div id="{{ uid }}" class="rtr">
<table style="width:100%; text-align: left;">
<tr>
<th width="25%">{% if txt %} {{ txt }} {% endif %}</th>
<td width="15%"><div class="temp">{{ basic.float(id~'actual', gad_actual, '°C' ) }}</div></td>
<td width="15%">
{% if gad_set %}
{{ basic.button(id~'minus', '', '', 'minus', '', 'micro') }}
{% endif %}
</td>
<td width="15%"><div class="temp">{{ basic.float(id~'set', gad_set, '°C' ) }}</div></td>
<td width="15%">
{% if gad_set %}
{{ basic.button(id~'plus', '', '', 'plus', '', 'micro') }}
{% endif %}
</td>
<td width="15%">
{{ basic.symbol(id~'stateon', gad_state, '', icon1~'sani_floor_heating.png', 1) }}
{{ basic.symbol(id~'stateoff', gad_state, '', icon0~'sani_floor_heating.png', 0) }}
</td>
</tr>
</table>
{% if gad_set %}
/** Events */
<script type="text/javascript">
// plus / minus
$("#{{ uid~'minus' }}").unbind('click').bind('click', function(){
var temp = (Math.round((parseFloat($("#{{ uid~'set' }}").html().replace(',','.')) - {{ step|default(0.5) }}) * 10) / 10).toFixed(1);
$("#{{ uid~'set' }}").html(temp + ' °C');
io.write("{{ gad_set }}", temp);
});
$("#{{ uid~'plus' }}").unbind('click').bind('click', function(){
var temp = (Math.round((parseFloat($("#{{ uid~'set' }}").html().replace(',','.')) + {{ step|default(0.5) }}) * 10) / 10).toFixed(1);
$("#{{ uid~'set' }}").html(temp + ' °C');
io.write("{{ gad_set }}", temp);
});
</script>
{% endif %}
</div>
/**
* Max RTR (Room Temperatur Regulator)
*
* @param unique id for this widget
* @param name of the rtr
* @param a gad/item for the actual temperature
* @param a gad/item for the set temperature
* @param a gad/item for the current state of the actor
* @param step for plus/minus buttons (optional, default 0.5)
*/
{% macro rtr(id, txt, gad_actual, gad_set, gad_state, step) %}
{% import "basic.html" as basic %}
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(0.5) }}"
class="rtr">
<div class="actual">
<div class="temp">{{ basic.float(id~'actual', gad_actual, '°C' ) }}</div>
<div class="text">{{ txt }} {% if gad_state != 0 %} ({{ gad_state }}) {% endif %}</div>
</div>
{% if gad_set %}
<div class="set">
<a data-role="button" data-icon="minus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
<div class="temp">{{ basic.float(id~'set', gad_set, '°C' ) }}</div>
<a data-role="button" data-icon="plus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
</div>
{% endif %}
</div>
{% endmacro %}
{% endmacro %}
hier eins im Einsatz:
{{ max.rtr('arbeitszimmer_heizen', 'Arbeitszimmer', 'arbeitszimmer.heizung.ist_temperatur', 'arbeitszimmer.heizung.soll_temperatur', 'arbeitszimmer.heizung.status') }}im gad die soll temp über "desiredTemperature" mit NumDirect als 'Converter
UZSU:
UZSU aktiv, leerer Eintrag:
{"active":true,"list":[]}
UZSU aktiv, ein leerer inaktiver Eintrag:
{"active":true,"list":[{"active":false,"rrule":"","time":"00:00","value":0}]}
UZSU aktiv, ein aktiver Eintrag, Mo-Fr 08:00 up:
{"active":true,"list":[{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"08:00","value":1}]}
... Und dann auch noch Mo-Fr 21:00 down:
{"active":true,"list":[{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"08:00","value":1},{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"21:00","value":0}]}
Lässt sich mit einem Direct Converter erfolgreich an einen dummy state geben, aber so richtig cool wäre natürlich ein UZSU Converter...
Zitat von: bgewehr am 06 Januar 2015, 22:43:10
UZSU:
UZSU aktiv, leerer Eintrag:
{"active":true,"list":[]}
UZSU aktiv, ein leerer inaktiver Eintrag:
{"active":true,"list":[{"active":false,"rrule":"","time":"00:00","value":0}]}
UZSU aktiv, ein aktiver Eintrag, Mo-Fr 08:00 up:
{"active":true,"list":[{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"08:00","value":1}]}
... Und dann auch noch Mo-Fr 21:00 down:
{"active":true,"list":[{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"08:00","value":1},{"active":true,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR","time":"21:00","value":0}]}
Lässt sich mit einem Direct Converter erfolgreich an einen dummy state geben, aber so richtig cool wäre natürlich ein UZSU Converter...
Hi,
wo ist der Unterschied zwischen
UZSU
aktiv, leerer Eintrag:
UZSU aktiv, ein leerer
inaktiver Eintrag:
Oder anders: gibt es UZSU
inaktiv ?
danke und Grüße
Jörg
Jeder einzelne Regel für sich kann aktiv oder inaktiv sein. Man kann aber auch die gesamte Zeit Schalt Uhr aktiv oder inaktiv setzen.
Hier ein Beispiel:
verstehe, Danke.
Zitat von: bgewehr am 05 Januar 2015, 12:38:00
Ich habe mal den nw_tiles Stil ausprobiert und muss sagen, dass ich das noch schöner finde. Kombiniert mit ein bisschen Quad design kommt das einem Gira HomeServer schon recht nahe!
Hallo,
mal ne blöde Frage: Wie bekommst Du die zwei Spalten in der Übersicht hin? Class="nw_tiles" reicht doch dafür nicht aus, oder? Ist das quad?
Gibt es zu den designs irgendwo eine Kurzdoku?
schöne Grüße
Jo
Lad dir die visu.css aus meinem Git im Pages/Gewehr Folder, da sind die Styles drin!
Cool, danke. Ich wusste doch da fehlt was.
schöne Grüße
Jo
Zitat von: Jojo11 am 07 Januar 2015, 19:11:52
Gibt es zu den designs irgendwo eine Kurzdoku?
ich glaub bei den homebrew dingern heißt es trial and error - learning by doing. Hier hab iich ein tut zum erstellen von eigenen gefunden:
https://code.google.com/p/smartvisu/wiki/themeroller
Ich glaube aber vorher nehme ich mir mal die Uhr vor - anstelle von dem htc style hätte ich gern irgendwie was dezenteres, gerne gleich mit fhem Wecker Anbindung. eigentlich auch fürs Wetter. Ist da evtl schon jemand über was gestolpert ?
vg
jörg
Gibt es eigentlich zum dem plötzlichen connect Verlust eine Lösung? Habe seit heute das Problem und bekomme keinen connect mehr!
Ja gibts es. Ich habe das nie gezielt reproduzieren können, hatte das aber auch.
In der Ecke musste ich aber sowieso noch einiges machen - und seither passt das zu 100% bei mir. Ich wollte mir das jetzt sparen irgendwelche "Zwischenversionen" vor der beta 2 zu raus zubringen weil ich dann Meldungen hier aus dem Forum nicht mehr zuordnen kann. Vielleicht ist das aber auch keine so gute Strategie, scheint ja doch (gegen Empfehlung ;) ) auch schon produktiv genutzt.
Für die beta 2 liege ich so bei knapp über 70% fgr - vielleicht macht es ja doch Sinn das in ein git zu packen, dann könnte man auch direkt aus dem git den Tagesstand nach fhem updaten. Bernd hatte sein git angeboten (vielen Dank) - nur da müsste er das immer commiten. Für tägliche updates wäre das dann nicht mehr geeignet, setze ich lieber eins auf (hoffe das passt @Bernd) - und wenn dann der aktuelle Featurestand fehlerfrei läuft, und Rudi sein ok gibt, dann über das reguläre svn.
Hyper: magst Du bitte nochmal kurz ein list (mit show internals) ziehen und auf der console mit "ps aux | grep perl" schauen ob der ws noch lebt ? Danach Neustart und alles ist wieder gut.
Danke und Grüße
Jörg
Macht doch generelle smartVISU / fronthem gits auf github. Man kann auch auch anderen Leuten push-rechte geben :).
ich gestehe das ich mich da überhaupt nicht auskenne :) aber ich befürchte ... irgendwann muss ichs lernen ;)
Wir hatten das (generelle) ja gestern kurz als Thema und ich wollte mal warten ob es noch Meinungen zu der von Thomas gibt. Gibts nich - ist also vmtl für die meisten auch keine Thema. Thomas:
Zitat1. Die SV-Jungs geben Dir Zugriff auf die Sourcen und Du übernimmst (temporär) das Projekt.
ne, könnte ich garnicht wuppen und würde ich nicht wollen. Die sourcen sind sowieso gpl, da ist alles transparent.
Zitat2. Wir machen getrennt weiter, bleiben aber möglichst kompatibel zu allen anderen SV-Schnittstellen. Dann können auch die Leute aus dem KNX-Forum von unseren Erweiterungen profitieren und wenn der harte Kern wieder da ist kann die Weiterentwicklung auf dem erweiterten Code aufsetzen.
3. Wir machen getrennt weiter und lassen alles, was man für fronthem nicht benötigt einfach links liegen. Dann müssen wir natürlich die >>neuen coolen Widgets<< von Hand mergen. Die Frage ist: Wie wahrscheinlich ist es, dass sooo viele neue coole Widgets kommen, dass sich diese Arbeit nicht bewerkstelligen ließe - zumal die letzten neuen Widgets auch nicht im Release gelandet sind, sondern aus dem Forum manuell eingepflegt werden müssen.
2 und 3 sind ja nahe beieinander. Ich finde es wichtig das die credits für sv bei den Jungs bleiben die smartVisu auch geschrieben, viele Arbeit und grips rein gesteckt haben.
Vorschlag, ich kann ja eine jungfräuliche (aber eben um die fhem parts erweiterte) Version in das git stellen, dann hat man einen Anlaufpunkt für die Installation. Daneben gibts ja dann das git von Bernd, wo ja schon seine widgets liegen und da kommen bestimmt weitere dazu. Schlussendlich wird das UZSU oder nw_tiles usw ja ach so verteilt.
Wir müssen halt nur ein wenig aufpassen weil ja im knx Forum auch viel support plus tips und tricks für sv gibt. Wenn jetzt die fhem sv zu weit davon weg ist haben es die Neu-User natürlich entsprechend schwerer weil sie nicht mehr wissen welche Info passt und wo es anders ist.
Das zieht dann natürlich hier die Fragen (und Aufwand) hoch... Andere Vorschläge, IDeen, Einwände ... ?
vg
jörg
Zitat von: herrmannj am 07 Januar 2015, 21:33:19
ich gestehe das ich mich da überhaupt nicht auskenne :) aber ich befürchte ... irgendwann muss ichs lernen ;)
Verwendest du eine Entwicklungsumgebung wie zB eclipse? Für eclipse (ich denke auch für andere) gibt es GIT/SVN Plugins, da ist ein commit nur mehr 2 Klicks entfernt ;) Ich mach das sogar für meine 99_my*Utils Dateien, einfach um den überblick über Änderungen zu behalten.
Grüße
Zitat von: herrmannj am 07 Januar 2015, 21:08:30
... setze ich lieber eins auf (hoffe das passt @Bernd)
Ja logo!
@Jörg: wie ist Dein GitHub-Name?
Einfach registrieren, dann gebe ich die contributor Rechte auf das fronthem-Git!
Sicher, dass es nicht der hier ist?
https://github.com/herrmannj
Hallo zusammen,
dieses:
update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
habe ich eben todesmutig am Produktivsystem getestet - funktioniert.
Es handelt sich um die aktuelle Arbeitskopie, allerdings sind bereits viele Punkte adressier, gegenüber der beta noch stabiler, a lot of fixes schon drin. Für Sicherheitskopien steht jeder selber gerade (!), denkt auch an die cfg unter fronthem.
Offen sind
refactoring im device
bitte kein rename
beim speichern der fronthem cfg gibt es scheinbar auf einigen wenigen Systemen Probleme, Ursache noch offen.
vg
jörg
Zitat von: herrmannj am 08 Januar 2015, 02:15:23
update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
habe ich eben todesmutig am Produktivsystem getestet - funktioniert.
Hallo, Jörg, super!
Der Editor ist nicht im ...txt enthalten, ist das Absicht?
Bei mir kommt übrigens nur nothing to do...
Hi,
ja, am editor und fhconverter hat sich noch nichts geändert.
ZitatBei mir kommt übrigens nur nothing to do...
Das ist nicht ok, fronthem und fronthemDevice hat er bei mir damit erneuert. Das wäre korrekt.
so sieht es bei mir aus:
Got remote controlfile with 3 entries.
https://raw.githubusercontent.com/herrmannj/fronthem/master/CHANGED: empty file received
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
update finished, "shutdown restart" is needed to activate the changes.
Please consider using the global attribute sendStatistics vg
jörg
Hallo,
habe es gerade bei mir getestet und folgende Ausgabe bekommen:
https://raw.githubusercontent.com/herrmannj/fronthem/master/CHANGED: empty file received
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
update finished, "shutdown restart" is needed to activate the changes.
@pole23: Dann hat ja alles geklappt.
Konnte so auf die schnelle nach einem Neustart auch noch keine Fehler erkennen. Funktion einwandfrei!
Hallo,
hab alles installiert, bekomme aber keine devicelist angezeigt.
Screenshot im Anhang
Gruß
Hallo,
hast du nebenbei auch die SmartVISU Seite offen?
Hast du schon Devices im smartVISU eingerichtet?
Da bei dir state auf "disconnected" steht.
Hallo,
habe smartVisu auf einem anderen Host installiert. Das läuft auch soweit und ist über domotiga verbunden.
Ob Disconnect oder Connect hatte keine Auswirkung, das ist ja auch nur ein Client, da sollte es egal sein ob online oder offline oder ?
In Smartvisu habe ich noch keine Devices angelegt, dachte ich muss die erst in fhem definieren...
Gruß
Hallo Sebastian,
sv anderer host ist ok.
Adresse im fhem fronthemDevice (ip) muss die IP des clienst sein der zu-greift
sv, driver domotiga, ip von fhem, port 2121.
device (schalter etc): erst in sv anlegen (oder demohäuser testen).
Der client aktualisiert die liste in fronthem.
Danach im GAD editor die GAD (über die converter) mit fhem "verbinden"
vg
jörg
edith: überschnitten
du musst erst ein Device in smartVISU anlegen. Dann taucht es erst im FHEM auf.
Edit: Da war ich wohl zu langsam :)
@pole:
perfekt das es läuft (update). Ich schreib mal den Rets noch rein (icons usw), dann ist update ja entspannt möglich.
Bin (wegen css darkstyle) gerade nochmal drüber gestolpert das man bei darkstyle die icons kaum sieht - muss ich mir noch was einfallen lassen. Nach Möglichkeit wollte ich ohne fhem css Anpassung auskommen.
btw, wenn noch jemand eine Lösung oder einen hint für das Thema "Sonderzeichen in smartvisu" kennt, gerne her damit. Ich war da schon eine Runde bei (leider noch offen, erst einmal zurückgestellt), ist ein UTF-8 Ding.
Hauptsächlich bin ich mir nicht sicher ob fronthem falsch liefert oder smartVisu falsch versteht.
vg
jörg
Ok jetzt tauchen devices auf :) konnte ich der "Doku" nicht entnehmen ....
Habe es mir übrigens auch über den Updatebefehl geholt und die restlichen Dateien so eingespielt.
Danke & Gruß
Zitat von: Sebastian am 08 Januar 2015, 11:46:53
konnte ich der "Doku" nicht entnehmen ....
Da geht noch was. ( schreibrechte im wiki bekommt man übrigens bei soulman ;) )
ZitatHabe es mir übrigens auch über den Updatebefehl geholt und die restlichen Dateien so eingespielt.
Ah super!. Dann war das bei Bernd kein generelles Ding, bin beruhigt.
vg + viel Spass
jörg
Hallo zusammen,
anbei ein paar Anregungen/Fragen (bitte nicht steinigen falls ich hier was falsches schreiben sollte, das Ganze dient nur der Anregung):
- Update Fronthem: Finde ich super dass man das nun updaten kann. Würde es Sinn machen das ganze zip aus dem 1. Thread auf GitHub darzustellen? Also auch das Verzeichnis "smartVISU" auf der selben Ebene wie "fhem"? Die config.ini sollte man dann in config.default.ini umbenennen. Diese muss dann halt jeder in config.ini ändern. Irgendwann sollte aber alles über den fhem-Update Mechanismus gezogen werden, oder?
- Update smartVISU:
- Man macht einen Fork vom smartVISU-Projekt. Man macht keine Änderungen an den Basisdateien, so dass man Änderungen immer wieder ohne Konflikte reinziehen kann (vorausgesetzt das Projekt lebt noch).
- Man macht einen Fork vom smartVISU-Projekt. Schmeißt alles raus was nicht für fhem relevant ist und versucht das ganze in fhem reinzubringen so dass es kompletter Bestandteil von fhem wird (?).
In beiden Fällen könnte man eigene Widgets direkt darin ablegen (im Pfad smartVISU\widgets ?). Man könnte verschiedene Interfaces bereitstellen (im Pfad smartVISU\pages) welche in der smartVISU-Konfiguration/Interface änderbar wären. Man erhält so mit der Zeit ein großes Sammelsurium und jeder könnte für sich entscheiden welches ihm am Besten gefällt.
Man muss auf jeden Fall schauen dass man eine vernünftige Lösung findet. Ich finde dass fronthem/smartVISU ein sehr großes Potential hat. Da sollte man schon möglichst früh darauf achten dass man sich nichts verbaut.
- Forum: Für mich ist hier der Thread schon recht lang. Wärs vielleicht sinnvoll je einen eigenen Thread für Fehler Beta1, Fehler Beta2, Installation, Widgets zu machen? Eventuell macht es ja irgendwann Sinn im Forum unter Frontends nochmal ein eigenes fronthem Board zu erstellen.
- Ist jemand beim "2. FHEM User-Treffen Karlsruhe" dabei? Vielleicht wäre das ja mal ein Thema für dort.
Desweiteren habe ich mir die Schreibberechtigung fürs Wiki besorgt. Ich möchte demnächst dort mal die Installationsanleitung schreiben.
Gruß Daniel
Falls es noch keiner gesehen hat: Floorplan in Smartvisu inkl. Verwendung der Widgets:
http://knx-user-forum.de/smartvisu/37293-designidee-grundriss.html
fett ! Hab mich mal dort angemeldet - jetzt kann ich auch die Bilder sehen :D
ZitatEventuell macht es ja irgendwann Sinn im Forum unter Frontends nochmal ein eigenes fronthem Board zu erstellen.
Das erledigt sich von alleine. Erstmal müssen wir zeigen das wir hier nicht sprinten sondern marathon laufen. Dann kommt eines schönen tages jemand vorbei der die Macht dazu hat und der keinen Bock mehr hat immer das gleiche Thema zu sehen - und dann zack .. 8)
Da ein Thermostatwidget mit einem basic.shifter für die absoluten Batteriewerte eines Homematic Thermostats nicht wirklich funktioniert (der Min-Wert wird gar nicht wirklich verwendet), habe ich mir ein User Reading in jeden Thermostat gepackt, dass den relativen Wert berechnet. Damit klappt die Batterieanzeige dann auch sehr gut:
batteryRel {batteryRel(ReadingsVal($name,'R-lowBatLimitRT','2.1'),3,ReadingsVal($name,'batteryLevel',3))}
Dazu zwei subs in einer myUtils:
### Float auf x Nachkommastellen runden
sub round
{
my $zahl=shift;
my $stelle=shift;
my $zz=$zahl+0;
if($zz=~/^.+?\.\d{$stelle}/)
{
$zz=~s/^.+?\.\d{$stelle}/'0.'.('0'x$stelle)/e;
$zahl+=$zz;
$zahl=~s/^(.+?\.\d{$stelle}).*$/$1/;
}
$zahl=sprintf("%.$stelle"."f",$zahl);
return $zahl;
}
## Relaiven Batterie-Wert zurück geben
sub batteryRel($$$) {
my ($min,$max,$val) = @_;
my $newVal=$val-$min;
if ($newVal>0) {
my $ret=$newVal/($max-$min)*100;
return round($ret,0)
}
return 0;
}
Dann noch im Widget min auf 0 und max auf 100 setzen und die Batterieanzeige liefert ein gutes Bild.
Hallo,
welche Homematic Thermostat hast den im Einsatz?
Das funktioniert sowohl beim RT, als auch beim TC.
Frage: Ist es geplant, dass man auch setLists (eigene und vom Modul vorgegebene/im Modul vorhandene) aus FHEM-Devices an smartVisu übergeben kann (Auswählbar über ein Select-Feld - ein entsprechendes Widget, das mit einem Array umgehen kann, hätte ich schon)?
Damit könnte man dann beispielsweise Enigma2 Receiver oder andere Media-Geräte steuern (Sendrauswahl, Favoritenauswahl etc.).
Zitat von: karl0123 am 08 Januar 2015, 17:40:15
Das funktioniert sowohl beim RT, als auch beim TC.
Bist du dir sicher, das es beim TC auch geht?
Habe einen HM-CC-TC und dort gibt es nur Reading "battery" mit den Werten "low|ok".
Zitat von: karl0123 am 08 Januar 2015, 17:50:26
Frage: Ist es geplant, dass man auch setLists (eigene und vom Modul vorgegebene/im Modul vorhandene) aus FHEM-Devices an smartVisu übergeben kann (Auswählbar über ein Select-Feld - ein entsprechendes Widget, das mit einem Array umgehen kann, hätte ich schon)?
Damit könnte man dann beispielsweise Enigma2 Receiver oder andere Media-Geräte steuern (Sendrauswahl, Favoritenauswahl etc.).
Array an sv - sv (dropdown|selectlist) einer geht zurück ?
Geht!
Welches widget ist das ?
Wie komme ich sinnvol an die fhem-list ? Ändert die sich oder macht es Sinn die statisch an den converter zu hängen ?
vg
jörg
Das ist das Problem. Die Liste liegt nicht in Readings. Das FHEM Modul holt sich diese Liste vom Receiver, Radio oder anderem Mediamodul und sie ist natürlich dementsprechend dynamisch. Wenn man im Receiver bspw. andere Sender einstellt, sieht die Liste anders aus, wenn man in der Squeezebox andere Favoriten einstellt, sieht sie anders aus und so weiter. Die Module stellen die Liste nur bereit, sie kommen aus den entsprechenden Devices.
Wie kommt man da ran? Ich weiß es nicht. Dafür geht mein Wissen nicht weit genug, was FHEM Internas angeht.
Das Widget für das SELECT sieht so aus:
{% macro select_uni(id, gad, items, choose_text) %}
<div align="center">
<label>
<select id="{{ uid(page, id) }}" data-widget="basicext.select_uni" data-item="{{ gad }}" />
{% if choose_text != '' %}
<option selected>{{ choose_text }}</option>
{% endif %}
{% for item in items %}
<option>{{ item }}</option>
{% endfor %}
</select>
</label>
</div>
{% endmacro %}
Das habe ich selbst gebaut.
Das JS dazu ist von bgwehr übernommen
$(document).delegate('select[data-widget="basicext.select_uni"]', {
'update': function (event, response) {
$(this).val(response).selectmenu('refresh');;
},
'change': function (event) {
// DEBUG:
console.log("[basicext.select_single] change '" + this.id + "':", $(this).prop("value"));
io.write($(this).attr('data-item'), $(this).val() );
}
});
Das umschalten in FHEM geht bei solchen Modulen dann so wie
set Dreambox channel <select>
oder
set Squeezebox favorites <select>
oder
set XYZ modus <select>
Zitat von: pole23 am 08 Januar 2015, 17:55:42
Bist du dir sicher, das es beim TC auch geht?
Habe einen HM-CC-TC und dort gibt es nur Reading "battery" mit den Werten "low|ok".
Ich meine den neuen TC (HM-TC-IT-WM-W-EU), sorry. An den alten hatte ich bei deiner Frage nicht gedacht.
Ok, alles klar.
Wenn ich mit update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt ein Update mache kommt
https://raw.githubusercontent.com/herrmannj/fronthem/master/CHANGED: empty file received
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
update finished, "shutdown restart" is needed to activate the changes.
fheminfo server response: ==> ok
was erstmal ja ok ist. Nach einem Neustart kommt das aber nochmal wenn ich wieder update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
mache. Sollte da beim 2. mal nicht sowas stehen? nothing to do...
Zitat von: karl0123 am 08 Januar 2015, 18:06:36
Wie kommt man da ran? Ich weiß es nicht. Dafür geht mein Wissen nicht weit genug, was FHEM Internas angeht.
Ja, verstehe. Grundsätzlich können converter direkt im modul sein. An so einer Stelle macht das vmtl auch Sinn. Weitere Kandidaten wären Kalender, Wetter und auch UZSU. Glaube aber das ist erstmal für Autoren interessant die vielleicht selber in sv unterwegs sind. Schau mal ob es erst mal einen anderen Weg gibt
vg
jörg
Zitat von: dancatt am 08 Januar 2015, 18:53:06
Wenn ich mit update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt ein Update mache kommt
https://raw.githubusercontent.com/herrmannj/fronthem/master/CHANGED: empty file received
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
update finished, "shutdown restart" is needed to activate the changes.
fheminfo server response: ==> ok
was erstmal ja ok ist. Nach einem Neustart kommt das aber nochmal wenn ich wieder update fronthem https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
mache. Sollte da beim 2. mal nicht sowas stehen? nothing to do...
ja, normalerweise ... ist bei mir aber auch so wie bei Dir..
Da es funktioniert habe ich das ignoriert. Hat evtl was mit den Dateigrößen zu tun oder so ....
vg
jörg
Hi, ich werde verrückt.
Ich habe meine Max FensterKontakte, in SV integriert, was auch auf anhieb funktioniert hat, nur wird das zugehörige Bild nicht angezeigt, hat jemand eine Ahnung warum!
{{ basic.symbol('AU_G1_T0', 'AU.GT.GaragenTor', 'GaragenTor ist offen', icon1~' fts_garage_door_10.svg ', 'closed') }}
{{ basic.symbol('AU_G1_T1', 'AU.GT.GaragenTor', 'GaragenTor ist zu', icon0~'fts_garage_door_90.svg ', 'opened') }}
Bist Du sicher, dass es opened ist? Ich glaube, es ist nur open!
@Jörg: Muss nicht in der .pm Datei das Datum fortgeschrieben werden, damit der updater das neue file erkennen kann?
nö, der schaut nach timestamp und filesize. Geht immer noch nicht ?
Wenn ich eine von den Dateien in neuer habe (hab ja Converter gebaut), bricht dann alles ab?
sollte nicht, mach mal touch mit einem alten timestamp
Ist opened,
NR
344
RSSI
-56.5
STATE
opened
TYPE
MAX
Die Auswertung erfolgt ja richtig, der Text wird richtig angezeigt nur das Bild wird angezeigt als ob es nicht da wäre.
Jedoch nur bei Status Opened!
Das bild ist da!
Zitat von: herrmannj am 07 Januar 2015, 20:10:26
ich glaub bei den homebrew dingern heißt es trial and error - learning by doing. Hier hab iich ein tut zum erstellen von eigenen gefunden:
https://code.google.com/p/smartvisu/wiki/themeroller
Ich glaube aber vorher nehme ich mir mal die Uhr vor - anstelle von dem htc style hätte ich gern irgendwie was dezenteres, gerne gleich mit fhem Wecker Anbindung. eigentlich auch fürs Wetter. Ist da evtl schon jemand über was gestolpert ?
vg
jörg
Irgendwie will es nicht klappen. Wenn ich die .css und Deine rooms_menu.html nehme, erhalte ich 3 Spalten mit Schaltflächen (nw_tiles style). Die anderen Dateien habe ich nicht verändert. Egal ob Minimalbeispiel oder komplette Seite, auf smartphone und PC erscheinen 3 Spalten ??? Ist da irgendwo ein Fehler oder ist das so gewollt?
schöne Grüße
Jo
Ich nehme an, Du meinst mich, JoJo!
Hol noch mal ganz frisch meinen Ordner Gewehr aus dem GitHub in das pages Verzeichnis (vollständig), dann kannst Du den Domotiga Treiber auf den falschen Port legen und meine Seiten ausprobieren. Wenn das dann geht - dann heißt es suchen!
Ok :-\
Das mit dem falschen Port ist ne gute Idee - ich habe jetzt ungefähr alle Deine devices bei mir in der Liste ;D
schöne Grüße
Jo
Ich habe jetzt gleich den neuen fhconverter "Trigger" im Git - läuft schon!
Zitat von: Jojo11 am 08 Januar 2015, 20:10:42
Das mit dem falschen Port ist ne gute Idee - ich habe jetzt ungefähr alle Deine devices bei mir in der Liste ;D
jaja...
@Jörg: mit der neuen Version aus deinem GIT habe ich häufige Abbrüche mit domotiga nicht erreichbar Fehler. Zurück auf die alte Version - alles wieder gut! Was kann ich machen, um den Fehler einzukreisen?
Hallo,
das mit den Abbrüchen habe ich auch heute schon drei mal gehabt.
Er hat bei mir zwar "Error" angezeigt jedoch ohne wirklich Error zu habe, dass soll heißen, bei mir wurde angezeigt, dass keine Verbindung war, jedoch hat die Verbindung bestanden, da ich die aktuellen Temperaturwerte angezeigt bekommen hatte und auch alles schalten konnte.
viele Grüße
Alexander
hmmm, das müssten wir evtl sortieren.
Der aktuelle (von domotiga "geliehene") sv driver hat die Einschränkung das er jedes mal beim Seitenwechsel den Fehlerdialog auslöst.
Ich beobachte das nicht weil ich im lokalen menu.html dies geändert habe (empfehle das generell):
Zitat
...
<a id="menu-rooms" data-ajax="true" href="index.php">
<img class="icon" src="{{ page == 'index' ? icon1 : icon0 }}control_on_off.png"/></a>
<a id="menu-weather" data-ajax="false" href="index.php?page=weather_current">
<img class="icon" src="{{ page == 'weather' ? icon1 : icon0 }}weather_cloudy.png"/></a>
...
Generell nehme ich mir den js driver noch vor - der hat eh einige Macken (auch reconnect nach Fehler, stand-by behandlung etc)
Unter welchen genauen Umständen lässt sich das bei Euch beobachten ? Irgendwelche Randparameter ?
vg
jörg
Bei mir war es so: Umgestellt auf neue Version - Fehler häufig und schon beim ersten Laden einer Seite nach irgendeiner Anzahl erfolgreich geladener gads (wechselnd, nicht ein spezielles).
Zurückgestellt auf alte Version läuft wieder einwandfrei!
Genau so ist das bei mir auch.
Gleiche hier, immer mal wieder Verbindungsunterbrechungen. Halbe Seite geladen, alle readings drin, der Rest nicht.
Zitat von: hyper2910 am 08 Januar 2015, 19:17:38
Hi, ich werde verrückt.
Ich habe meine Max FensterKontakte, in SV integriert, was auch auf anhieb funktioniert hat, nur wird das zugehörige Bild nicht angezeigt, hat jemand eine Ahnung warum!
{{ basic.symbol('AU_G1_T0', 'AU.GT.GaragenTor', 'GaragenTor ist offen', icon1~' fts_garage_door_10.svg ', 'closed') }}
{{ basic.symbol('AU_G1_T1', 'AU.GT.GaragenTor', 'GaragenTor ist zu', icon0~'fts_garage_door_90.svg ', 'opened') }}
Hat hier niemand eine Idee, warum das Bild bei Opened nicht angezeigt wird? Bei Closed funktioniert es einwandfrei. Auch die Textausgabe stimmt.
Weil die es im Verzeichnis kein SVG mit dem Namen gibt. Du musst, so wie ich es verstanden habe, die PNGs nehmen um verschiedene Farben zu benutzen.
Und noch was: ich habe auch schon alle Seiten auf Ajaxload umgestellt, weil sonst die Darstellung von der Web-App in den Browser wechselt. Trotzdem der Fehler...
Dauert es bei euch auch so lange, bis alle gads geladen sind (etwa 6-7 Sekunden im Gigabit-LAN)? Erst dann kann man die Seite scrollen und interagieren. Auch mit Pagecache gibt es diesen "Block", in dem man nicht mit der VISU interagieren kann. Ich gebe zu, ich habe viele gads im Menü aber ich verstehe nicht woher dieser "Block" kommt!?
Zitat von: bgewehr am 09 Januar 2015, 08:08:26
Und noch was: ich habe auch schon alle Seiten auf Ajaxload umgestellt, weil sonst die Darstellung von der Web-App in den Browser wechselt. Trotzdem der Fehler...
Ich habe am ws geändert, kann also durchaus sein. Wundert mich weil ich da echt auch Stresstests gemacht hab, mit 4 Geräten gleichzeitig, 256Zeichen lange GAD VALS mit schneller Freuqenz, WLAN weg, an, weg .. argh!
Nur doof isses weil ich das nicht reproduzieren kann.
Triitt das genauso im laufenden Betrieb oder (nur?) beim Seitenwechsel auf ?
Tritt das bei allen Seiten auf oder nur bei langen/vollen (?), kleinen/leeren (?), bestimmte inhalte ? <- hierzu hätte ich einen Verdacht, das wäre aber schräg ...
Welcher client ? (typ, browser, os, version)
Wenn die Abbrüche statt finden, geht der client auf disconnect ?
Stellt mal bitte log von fronthem auf verbose 5 und provoziert das mal. (log sichern !)
Bevor jemand fragt: ignorieren und einfach wieder alles zurück ändern ist der falsche Weg, da wurden bugs beseitig, bspw konnte, durch einen vololen puffer, ein Gerät das andere lahmlegen ..
vg
jörg
Zitat von: marvin78 am 09 Januar 2015, 07:46:33
Weil die es im Verzeichnis kein SVG mit dem Namen gibt. Du musst, so wie ich es verstanden habe, die PNGs nehmen um verschiedene Farben zu benutzen.
Danke Marvin, das war es!
Ich war eben dann auch etwas unpräzise:
Ihr müsstet im log (bei Fehler) finden (wenn mein Verdacht stimmt)
(bla) force disconnect for (blub)
und die Schnittmenge wäre: ihr habt alle drei eine sehr umfangreiche fronthem cfg (viele GAD definiert).
Gegencheck: fhem beenden, die fronthem (Mutter) cfg temporär wo anders hin schieben, fhem starten (fronthem erstellt eine leere cfg). Testweise nur einige GAD definieren (10? 20? plus minus) -> Fehler tritt nicht auf.
Mögt ihr das mal checken ? (wenn mgl, wäre cool, damit ich in der richtigen Ecke unterwegs bin)
Danke und Grüße
jörg
Zitat von: karl0123 am 09 Januar 2015, 08:13:04
Dauert es bei euch auch so lange, bis alle gads geladen sind (etwa 6-7 Sekunden im Gigabit-LAN)? Erst dann kann man die Seite scrollen und interagieren. Auch mit Pagecache gibt es diesen "Block", in dem man nicht mit der VISU interagieren kann. Ich gebe zu, ich habe viele gads im Menü aber ich verstehe nicht woher dieser "Block" kommt!?
Bei mir nicht - ich befürchte aber das ich auch nur einen Bruchteil Deiner GAD im Einsatz habe. Tablet oder NB ?
vg
Jörg
Rechner, Tablet, Notebook und Handy. Wobei es im LAN schon etwas schneller geht.
Auffällig ist eben, wenn man sich die Konsole ansieht, dass die Seite zuerst geladen wird (auch wenn sie aus dem Cache kommt - dabnn sieht sie fertig aus), dann dauert es einen Augenblick und dann werden die Gads aktualisiert (Sichtbar in der Konsole). Erst danach kann man schalten, scrollen etc. Browser sind Firefox, Chrome und Dolphin.
Und ja, ich habe sehr viele gads. Aber ich denke nicht, dass es überdurchschnittlich viele für eine Hausautomation sind (etwa 230). Zudem kann ich dieses Verhalten bei anderen Anwendungen, die mit websockets arbeiten nicht wirklich beobachten.
Ich denke eben, dass gerade die Verwendung der Websockets dazu führen sollte, dass diese nicht blockierend wirken und die Aktualisierung im Hintergrund stattfinden sollte. Deshalb wundert mich das.
Zitat von: karl0123 am 09 Januar 2015, 11:21:50
Rechner, Tablet, Notebook und Handy. Wobei es im LAN schon etwas schneller geht.
Auffällig ist eben, wenn man sich die Konsole ansieht, dass die Seite zuerst geladen wird (auch wenn sie aus dem Cache kommt - dabnn sieht sie fertig aus), dann dauert es einen Augenblick und dann werden die Gads aktualisiert (Sichtbar in der Konsole). Erst danach kann man schalten, scrollen etc. Browser sind Firefox, Chrome und Dolphin.
Und ja, ich habe sehr viele gads. Aber ich denke nicht, dass es überdurchschnittlich viele für eine Hausautomation sind (etwa 230). Zudem kann ich dieses Verhalten bei anderen Anwendungen, die mit websockets arbeiten nicht wirklich beobachten.
Ich denke eben, dass gerade die Verwendung der Websockets dazu führen sollte, dass diese nicht blockierend wirken und die Aktualisierung im Hintergrund stattfinden sollte. Deshalb wundert mich das.
Ja, das stimmt schon. Da spielt aber die Programmierung von sv eine Rolle, das ist halt so programmiert das es sich genau so so verhält. Das wäre meine nächste Frage gewesen mal in der console zu schauen. fronthem bringt die Daten schnell genug rüber aber sv aktualisiert teils gemächlich.
Ich weiß nicht ob man da optimieren kann, müsste man in sv machen. Sag mal, wenn Du so viele GAD hast, hast Du das update von gestern installiert oder bist Du mit der allerersten Version unterwegs ?
vg
Jörg
Update von gestern ist drauf, ja. Diese Abbrüche, von denen hier die Rede war habe ich nur auf dem recht langsamen Handy und in Firefox Mobile auf dem Tablet. In Chrome läuft auf allen Geräten alles einwandfrei.
btw, bei mir siehts so aus (Anhang). 500ms dom, 600ms Rest.
Im firbug kannste doch sehr gut sehen wo die Zeiten bleiben.
vg
jörg
Zitat von: karl0123 am 09 Januar 2015, 11:34:47
Update von gestern ist drauf, ja. Diese Abbrüche, von denen hier die Rede war habe ich nur auf dem recht langsamen Handy und in Firefox Mobile auf dem Tablet. In Chrome läuft auf allen Geräten alles einwandfrei.
ok, Danke. Würde meinen Verdacht bestätigen, aber mal schauen was die Jungs liefern. Kann man heil machen. Muss ich sogar ;)
vg
jörg
Naja. Wie ich das analysieren weiß ich schon. Ich habe ja oben geschrieben, was blockt. Ich sehe, wie die gads geladen werden und in der Konsole scrollen und wenn das fertig ist, kann ich wieder interagieren.Die Liste ist natürlich ziemlich lang. Nur verstehe ich nicht warum das laden der gads im Hintergrund blockierend wirkt. Dass es lange dauert kann ich nachvollziehen.
Ich habe angefangen meine Uhr schöner (für mich) zumachen (dachte ich hätte langsam Zeit dazu - Pustekuchen :P)
Da kommt noch (fhem) Wetter mit den meteo icons und ein Wecker dazu, dann leg ichs ins git.
vg
jörg
Zitat von: karl0123 am 09 Januar 2015, 11:42:39
Naja. Wie ich das analysieren weiß ich schon. Ich habe ja oben geschrieben, was blockt. Ich sehe, wie die gads geladen werden und in der Konsole scrollen und wenn das fertig ist, kann ich wieder interagieren.Die Liste ist natürlich ziemlich lang. Nur verstehe ich nicht warum das laden der gads im Hintergrund blockierend wirkt. Dass es lange dauert kann ich nachvollziehen.
tschuldigung, sollte keine Bevormundung sein (sorry)
Das laden (sprich transport) der GAD geht schnell. SV nimmt sich aber eine interne loop, packt jeden einzeln an, aktualisiert und scheint da eher gemütlich vorzugehen. Solange steht die GUI. Wobei ich jetzt Deine 6-7 Sekunden auch echt lange dafür finde. Wenn ich mir den domotiga treiber vornehme finde ich evtl stellen wo man optimieren kann, dazu kann ich aber jetzt noch keine Aussagen machen.
Wenn da nichts geht könnte ich die GADs aus fronthem langsamer liefern. Das mag unlogisch klingen, aber: der sv treiber liest alle GADs die er bekommen kann (aus dem ws) auf einen Rutsch und dreht seine loop. Wenn ich langsamer liefere sind am Anfang schon Pausen (in sv) in denen die GUI aktiv werden kann. Diese tuning sollten wir aber später machen, es gibt aber Schrauben an denen ich drehen kann.
vg
jörg
Das sollte hier keine Kritik an dir und deiner Arbeit sein. Ich dachte nur, ich erwähne es mal und frage, ob andere das auch beobachten und stelle fest, ob es an meiner Konfiguration liegt. Deine Beschreibung jedoch passt sehr gut auf das Verhalten. Die 6-7 Sekunden stimmen im Schnitt. Am langsamen Handy sind es sogar noch mehr. Am PC mit LAN etwas weniger (3-4).
Ich möchte auch auf keinen Fall Druck machen. Jedoch dachte ich, dass auch solche Dinge früh in der Entwicklung bekannt sein sollten.
Danke!!
BTW: In welchen JS Dateien macht SmartVisu diese Dinge?
Es werden doch immer nur die sichtbaren gads aktualisiert oder?
Zitat von: karl0123 am 09 Januar 2015, 11:59:38
Ich möchte auch auf keinen Fall Druck machen. Jedoch dachte ich, dass auch solche Dinge früh in der Entwicklung bekannt sein sollten.
BTW: In welchen JS Dateien macht SmartVisu diese Dinge?
Es werden doch immer nur die sichtbaren gads aktualisiert oder?
Alles gut, das passt perfekt. Vielen Dank :)
zu 1: geht vom sv driver aus, danach macht aber das gesamte framework mit
zu 2: na..., it-depends-on ... da werden auch unsichtbare GADs angepackt (was auch gut ist). Die Zeit geht nur in geringem Maß fürs Neu-Zeichnen drauf. Das suchen der Elemente im DOM (von jquery via selector) braucht typischerweise viel Zeit.
vg
jörg
Das unsichtbare Gads aktualisiert werden ist eventuell hilfreich (wobei mir ein Grund gerade nicht einfällt). Vielleicht wäre es sinnvoll, dass das später passiert (nach und nach!?).
Meine Frage zielte darauf ab, ob ich für langsamere Verbindungen das Menu "verschlanke" und gads daraus entferne.
ZitatDas unsichtbare Gads aktualisiert werden ist eventuell hilfreich (wobei mir ein Grund gerade nicht einfällt).
status.notify, status.log, pop-up Kamera, pop-up Telefonanruf - später dann die app (notifications, tts, screen brightness, Musik Wiedergabe ...)
ZitatMeine Frage zielte darauf ab, ob ich für langsamere Verbindungen das Menu "verschlanke" und gads daraus entferne.
Ne mach nicht. Da muss ich ran - das muss so funktionieren. Wo soll die Grenze sein (mobile, gprs Verbindung) ?
vg
jörg
Hallo,
ich arbeite auch mit der aktuellen Version und habe gerade folgendes beobachtet. Wenn ich auf ein Device im FHEM anklicke, um die GAD zu sehen, werden diese zwar angezeigt aber im Log steht dann folgendes:
set HomeStatus ? : Unknown argument ?, choose one of 1 2 3 4
Das kommt jetzt bei jedem Device.
yepp, alles richtig. Der Editor fragt das device "HomeStatus" mit "set HomeStatus ?" welche set Befehle es kann - die bietet Dir der Editor im dropdown an.
Das ist das übliche vorgehen, kannst das im webif ausprobieren. Mir ist keine Art bekannt die irreführende Logmeldung zu unterdrücken.
vg
Jörg
ja da geht was. Hab gerade mal geschaut wie Rudi das in fhemweb macht. Da ist das schöner gelöst. Ich "leih" mir das mal von ihm aus (credits an rudi :) )
@karl:
ich bin da kurz rein getaucht und habe einen theoretischen Lösungsansatz innerhalb smartVisu.
Muss ich umsetzen, testen und dann muss das auch noch hinhauen :), etwas Geduld.
Kurze Überschlagsrechnung am Rande: 6000ms / 250 GAD = 24ms pro ... das geht. Bin trotzdem (gerade weil) bei Dir, lass das mal 500 GADs ++ werden, schon blöd. Ich frag mich wie die Jungs im KNX das machen, die haben das auch. Weniger GAD vlt ? Zum Glück tritt es ja nur einmal beim starten auf und ich denke ich kann es lösen.
Der Punkt mit dem disconnect kommt aber vorher und ich befürchte das ist ein bug in net::websoocket::server ...
vg
jörg
Hört sich gut an. Wenn ich was testen kann/soll weil du nicht genug gads hast, um es zu simulieren, dann stehe ich zur Verfügung. Ich bin mittlerweile bei 310 ;)
ja danke. :) Ich hätte schon noch einiges - komm halt nicht zum einrichten. 310 ist natürlich 'ne Hausnummer. Ganz schön Arbeit. ...
vg
jörg
Und es werden noch mehr. Und ja. Das ist viel Arbeit. Da kommt der gad Editor doch arg an seine Grenzen. Zumal ich das ganze auch noch für 6-8 Devices machen muss ;)
der Editor oder der éditeur ? ;)
Naja beide. Um die 310 gads für 6 Devices einzurichten muss 6 mal jedes Device angefasst sowie read und write gesetzt werden.
Eigentlich wäre es logischer einen zentralen Gad-Editor zu haben und dort den einzelnen Devices die Rechte zuzuordnen (wobei ich das auch erst jetzt gemerkt habe ;)).
Zitat von: herrmannj am 09 Januar 2015, 10:30:17
Triitt das genauso im laufenden Betrieb oder (nur?) beim Seitenwechsel auf ?
Tritt das bei allen Seiten auf oder nur bei langen/vollen (?), kleinen/leeren (?), bestimmte inhalte ? <- hierzu hätte ich einen Verdacht, das wäre aber schräg ...
Welcher client ? (typ, browser, os, version)
Wenn die Abbrüche statt finden, geht der client auf disconnect ?
Stellt mal bitte log von fronthem auf verbose 5 und provoziert das mal. (log sichern !)
Bevor jemand fragt: ignorieren und einfach wieder alles zurück ändern ist der falsche Weg, da wurden bugs beseitig, bspw konnte, durch einen vololen puffer, ein Gerät das andere lahmlegen ..
Beim laden der Seite
Ich habe gerade eine recht langsame VPN-Verbindung rein, da passiert es bei jedem reload, nach ca. 10 GADs, plus minus zwei drei (eben waren es auch mal gerade 18)
Das fronthemDevice geht auf disconnected
Eintrag im Log:
3: ipc fronthem:127.0.0.1:36153 (ws): ws force disconnect for VPN1Eine Seite mit nur zwei GAD funktioniert jedes mal, das fronthemDevice bleibt connected
passt auf meinen Verdacht, ist ein fehler im net::websocketserver .... doof. OK, mach ich heil ist nur shit-viel-arbeit.
vg
jörg
Hab eben im Log folgendes gefunden:
2015.01.09 17:33:44.755 1: PERL WARNING: Use of uninitialized value $e[0] in concatenation (.) or string at ./FHEM/31_fronthemDevice.pm line 311.
2015.01.09 17:33:44.756 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/31_fronthemDevice.pm line 312.
2015.01.09 17:33:44.756 1: PERL WARNING: Use of uninitialized value $e[0] in string eq at ./FHEM/31_fronthemDevice.pm line 316.
Zitat von: bgewehr am 08 Januar 2015, 20:07:11
Ich nehme an, Du meinst mich, JoJo!
Hol noch mal ganz frisch meinen Ordner Gewehr aus dem GitHub in das pages Verzeichnis (vollständig), dann kannst Du den Domotiga Treiber auf den falschen Port legen und meine Seiten ausprobieren. Wenn das dann geht - dann heißt es suchen!
Hallo Bernd,
ich habe den kompletten Ordner kopiert, Port verdreht und getestet: 3 Spalten auf dem PC und auf dem smartphone ???
Scheint so, als würde der code nicht zu Deinem screenshot passen. Hast Du später noch was geändert?
Es muss doch möglich sein, dieses Zweispalten-Design zu aktivieren :-\
schöne Grüße
Jo
Die zwei Spalten sind dynamisch über @media css Befehle in der Visu.css recht weit unten realisiert. Mach mal auf dem PC den Browser immer schmaler, dann müsstest Du die Veränderungen sehen können!
Hab nochmal ins Git gepusht. Nimm nochmal die visu.css.
Ist für iphone6 ausgelegt!
Wenn deine Bildschirm Auflösung anders ist als bei mir, dann stimmen die Regeln nicht, die ich erstellt habe. Du musst dann die Einstellungen anpassen. Das geht ziemlich einfach, wenn du in Chrome die Taste F12 drückst und auf das kleine Handy Symbol klickst. Dann kannst Du die Breite ablesen und die min und Max Width Regeln anpassen!
Ok, alles klar. Hatte nur die 50% im nw_tiles style gesehen und gedacht, das müsste passen. Bei mir sieht es derzeit so aus :D
Iphone? Gibt's die noch? ;D
schöne Grüße
Jo
Nachtrag:
Übeltäter identifiziert:
/* Portrait phones to Landscape */
@media (min-width: 376px) and (max-width: 568px) {
.nw_tiles li {
width: 33.33%;
}
}
Mein Telefon hat eine Auflösung von 1280 × 768 Pixeln, wird aber mit diesem code erkannt :o
Hallo bgewehr,
ich habe mir von GitHub mir deinen kompletten Ordner runter geladen.
Leider bekomme ich jetzt folgende Fehlermeldung:
Content-Encoding-Fehler
Die Webseite, die Sie öffnen möchten, kann nicht angezeigt werden, da sie eine ungültige oder unbekannte Form der Kompression verwendet.
Wo liegt der Fehler? Bitte kurzen Tip
Danke Lutz
Edit: Hat sich erledigt! Musste die config.ini erst umbenennen!
Moin,
ich habe jetzt ein paar fronthemDevices definiert, bekomme sie aber nicht in den Status connected ...
Das einzige Device was auf connected steht ist mein Mac Book, bei den Tablets und meinem Handy bekomme ich keinen Connect.
Gruß
Das hatte ich auch, update der fronthem und wenn du auf den Tablett alles eingibt hat sich hinter die letzte stelle der IP eine ' ' gemogelt.
Zu der update Funktion, ich kann immer updaten der holt sich immer wieder die Files neu!
Zitat von: hyper2910 am 09 Januar 2015, 21:31:55
Zu der update Funktion, ich kann immer updaten der holt sich immer wieder die Files neu!
Ja, macht er er bei mir auch, mglw irgendwas mit den filesize. Ist ja aber unkritisch.
vg
jörg
Auch nach dem neuen Update steht da nix hinter der IP wie ' ' . Connect klappt weiterhin nicht...
Gruß
bei android brauchst Du kitkat oder chrome. vg
@bernd,
hast Du das "force disconnect" im log ?
Ich habe mal ein Frage zu den Plotts!
Was muss ich einrichten? Habe bei bgewehr gesehen, dass es funktioniert! Aber kriege es selber nicht hin. Die Gad's werden nicht eingelesen. Muss ich noch irgendein Verweis auf eine ander html machen.
Danke Lutz
@cruser bisher geht nur der rtr comfortplot. Die anderen kommen erst später...
@jörg: ich habe dblog aktiv, wo kann ich das nachsehen? stehe grade echt auf dem Schlauch!
hab kein db log. Normale logmeldung. fhem log. wie viele gads ca hast Dun in der cfg ?
Hallo!
Ich habe gestern die neue Version aus dem git eingespielt. Nur zur Info, mein shutdown restart Problem gibt es noch immer. Wenn du willst kann ich mich mal dahinter klemmen, oder wir warten die Beta 2 und sehen dann weiter.
Weiters ist mein FHEM gerade mit dieser Meldung in der Console komplett abgestürzt.
Zitatsend: Cannot determine peer address at ./FHEM/01_fronthem.pm line 530.
Liegt vermutlich an diesem TODO, wollte das aber trotzdem melden ;)
Zitat
# TODO
# only write if ipc instance is available
# (if not: lg warning, disconnect device)
# write at ipc write
Grüße
Zitat von: bgewehr am 02 Januar 2015, 18:51:10
Ich behaupte, das hier läuft (ist aber was anderes):
###############################################################################
#
# Read fhem device Reading timestamps (gadval == timestamp)
#
###############################################################################
sub ReadingsTimestamp(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = main::ReadingsTimestamp($device, $reading, 0);
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Readingstimestamp';
}
return undef;
}
Hab das in die fhconverter.pm eingefügt und ein neues gad erstellt. Der Timestamp des readings wird bis zum ersten aktualisieren angezeigt, dann wird aber der Wert des Readings angezeigt.
Muss ich noch irgendwo was machen?
Grüße
Zitat von: fhainz am 10 Januar 2015, 10:59:51
Hallo!
Ich habe gestern die neue Version aus dem git eingespielt. Nur zur Info, mein shutdown restart Problem gibt es noch immer. Wenn du willst kann ich mich mal dahinter klemmen, oder wir warten die Beta 2 und sehen dann weiter.
Weiters ist mein FHEM gerade mit dieser Meldung in der Console komplett abgestürzt.
Liegt vermutlich an diesem TODO, wollte das aber trotzdem melden ;)
Grüße
Hi,
&danke.
Teil eins (shutdown restart) sollte erledigt sein, schau bitte mal im log nicht das es an was anderem liegt (blocking, presence und co).
ZitatWenn du willst kann ich mich mal dahinter klemmen
JA Bitte ! Sehr gern.
Teil zwei: jenau ! ;) wobei der ipc ohnehin nicht einfach so seinen Leiden erliegen soll. Da gibt es aber eine Verbindung zu dem disconnect Thema, bin da gerade dran, man sieht schon Licht am Ende des tunnels. Da noch abwarten bitte.
vg
Jörg
Zitat von: herrmannj am 10 Januar 2015, 12:29:28
Teil eins (shutdown restart) sollte erledigt sein, schau bitte mal im log nicht das es an was anderem liegt (blocking, presence und co). JA Bitte ! Sehr gern.
Im Log (global verbose 3) findet sich nichts auffälliges.
Zitat2015.01.10 12:38:00.093 1: in SHUTDOWN
2015.01.10 12:38:00.093 1: in SHUTDOWN
2015.01.10 12:38:00.096 0: Server shutdown
2015.01.10 12:38:02 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2015.01.10 12:38:02.280 1: Including fhem.cfg
2015.01.10 12:38:02.288 3: Opening jeelink device /dev/tty.usbserial-AE01DUEH
2015.01.10 12:38:02.298 3: Setting jeelink baudrate to 57600
2015.01.10 12:38:02.299 3: jeelink device opened
2015.01.10 12:38:03.310 3: Opening CUL1 device /dev/tty.usbmodem1d1321
2015.01.10 12:38:03.310 3: Setting CUL1 baudrate to 9600
2015.01.10 12:38:03.311 3: CUL1 device opened
2015.01.10 12:38:03.433 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.01.10 12:38:03.466 1: HMLAN_Parse: HMLan new condition disconnected
2015.01.10 12:38:03.466 3: Opening HMLan device 10.0.0.55:1000
2015.01.10 12:38:03.468 3: Can't connect to 10.0.0.55:1000: Connection refused
2015.01.10 12:38:03.501 1: WEB: Can't open server port at 63191: Address already in use. Exiting.
Ein ps aux | grep perl liefert zu diesem Zeitpunkt:
ZitatFabian 13639 0,0 0,0 2506928 6556 ?? Ss 12:39pm 0:00.01 perl fhem.pl fhem.cfg
Fabian 13637 0,0 0,4 2544612 70792 s000 S+ 12:38pm 0:17.07 perl fhem.pl fhem.cfg
root 223 0,0 0,0 2498660 4336 ?? Ss 3:35pm 0:00.06 /usr/bin/perl -T /usr/libexec/emlog.pl -l
Fabian 13737 0,0 0,0 2441988 688 s001 S+ 12:43pm 0:00.00 grep perl
Anschließend hab ich das Problem mit global verbose 5 nachgestellt. Ich finde nichts auffälliges im Log.
2015.01.10 12:57:27.849 5: Cmd: >shutdown restart<
2015.01.10 12:57:27.849 5: Triggering global (1 changes)
2015.01.10 12:57:27.849 5: Notify loop for global SHUTDOWN
2015.01.10 12:57:27.854 1: in SHUTDOWN
2015.01.10 12:57:27.854 1: in SHUTDOWN
2015.01.10 12:57:27.856 0: Server shutdown
2015.01.10 12:57:27.857 5: SW: X00
2015.01.10 12:57:27.897 4: fronthem: shutdown called
2015.01.10 12:57:27.897 4: fronthemDevice: shutdown called
2015.01.10 12:57:27.897 4: fronthem_iPhone6: shutdown called
2015.01.10 12:57:30 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2015.01.10 12:57:30.029 1: Including fhem.cfg
2015.01.10 12:57:30.037 3: Opening jeelink device /dev/tty.usbserial-AE01DUEH
2015.01.10 12:57:30.048 3: Setting jeelink baudrate to 57600
2015.01.10 12:57:30.048 3: jeelink device opened
2015.01.10 12:57:31.069 3: Opening CUL1 device /dev/tty.usbmodem1d1321
2015.01.10 12:57:31.070 3: Setting CUL1 baudrate to 9600
2015.01.10 12:57:31.070 3: CUL1 device opened
2015.01.10 12:57:31.200 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.01.10 12:57:31.235 1: HMLAN_Parse: HMLan new condition disconnected
2015.01.10 12:57:31.235 3: Opening HMLan device 10.0.0.55:1000
2015.01.10 12:57:31.236 3: Can't connect to 10.0.0.55:1000: Connection refused
2015.01.10 12:57:31.268 1: WEB: Can't open server port at 63191: Address already in use. Exiting.
2015.01.10 12:57:46.622 4: fronthem_iPhone6: undef called
2015.01.10 12:57:46.622 4: fronthemDevice: undef called
2015.01.10 12:57:46.622 4: fronthem: undef called
2015.01.10 12:57:46.624 2: harmony: disconnect
2015.01.10 12:57:46.626 3: HourCounter hc_plexSerien Undef.272 Done
2015.01.10 12:57:46.627 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 7001.
2015.01.10 12:57:46.629 5: ENIGMA2 wzReceiver: called function ENIGMA2_Undefine()
2015.01.10 12:57:46.630 3: HourCounter testhc Undef.272 Done
2015.01.10 12:57:46.632 5: [homeTwilight] removing Timer: homeTwilight_ss_civil
2015.01.10 12:57:46.632 5: [homeTwilight] removing Timer: homeTwilight_sr_civil
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sr_weather
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sr_naut
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_ss_indoor
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_ss
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sr_astro
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_ss_astro
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sr_indoor
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_ss_naut
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_ss_weather
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sr
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_Midnight
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_perlTime
2015.01.10 12:57:46.633 5: [homeTwilight] removing Timer: homeTwilight_sunpos
2015.01.10 12:57:46.633 3: HourCounter hc_wzTV Undef.272 Done
2015.01.10 12:57:46.633 3: HourCounter hc_wzReceiver Undef.272 Done
2015.01.10 12:57:46.633 3: HourCounter hc_wzPS3 Undef.272 Done
2015.01.10 12:57:46.633 3: HourCounter hc_wzDeckenfluter Undef.272 Done
2015.01.10 12:57:46.633 3: HourCounter hc_Waschmaschine Undef.272 Done
2015.01.10 12:57:46.633 3: HourCounter hc_kuKaffeemaschine Undef.272 Done
2015.01.10 12:57:46.634 3: HourCounter hc_allgRegensensor Undef.272 Done
2015.01.10 12:57:46.634 3: Unregistering GEOFANCY geofancy for URL /geo...
2015.01.10 12:57:46.637 5: SW: X00
2015.01.10 12:57:46.666 1: Including fhem.cfg
2015.01.10 12:57:46.668 3: Opening jeelink device /dev/tty.usbserial-AE01DUEH
2015.01.10 12:57:46.673 3: Setting jeelink baudrate to 57600
2015.01.10 12:57:46.674 3: jeelink device opened
2015.01.10 12:57:47.679 3: Opening CUL1 device /dev/tty.usbmodem1d1321
2015.01.10 12:57:47.680 3: Setting CUL1 baudrate to 9600
2015.01.10 12:57:47.680 3: CUL1 device opened
2015.01.10 12:57:47.810 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.01.10 12:57:47.841 1: HMLAN_Parse: HMLan new condition disconnected
2015.01.10 12:57:47.842 3: Opening HMLan device 10.0.0.55:1000
2015.01.10 12:57:47.846 3: HMLan device opened
2015.01.10 12:57:47.847 1: HMLAN_Parse: HMLan new condition init
2015.01.10 12:57:47.848 3: WEB: port 63191 opened
2015.01.10 12:57:47.850 3: WEBphone: port 63193 opened
2015.01.10 12:57:47.851 3: webReadOnly: port 62789 opened
2015.01.10 12:57:47.852 3: WEBtablet: port 63192 opened
2015.01.10 12:57:47.856 3: Waschmaschine: I/O device is jeelink
2015.01.10 12:57:47.857 0: HourCounter hourCounterAllgemein Define.228 parameters: hourCounterAllgemein HourCounter sys_s0EingangAllgemein:pin:.on sys_s0EingangAllgemein:pin:.off
2015.01.10 12:57:47.858 0: HourCounter hourCounterBoiler Define.228 parameters: hourCounterBoiler HourCounter sys_s0EingangBoiler:pin:.on sys_s0EingangBoiler:pin:.off
2015.01.10 12:57:47.867 3: Durchlauferhitzer: I/O device is jeelink
2015.01.10 12:57:47.931 2: eventTypes: loaded 13964 events from ./log/eventTypes.txt
2015.01.10 12:57:47.955 3: Registering GEOFANCY geofancy for URL /geo...
2015.01.10 12:57:47.955 0: HourCounter hc_allgRegensensor Define.228 parameters: hc_allgRegensensor HourCounter d_allgRegensensor:regen:.1 d_allgRegensensor:regen:.0
2015.01.10 12:57:47.955 0: HourCounter hc_kuKaffeemaschine Define.228 parameters: hc_kuKaffeemaschine HourCounter kuKaffeemaschine:doKaffee:.1 kuKaffeemaschine:doKaffee:.0
2015.01.10 12:57:47.956 0: HourCounter hc_Waschmaschine Define.228 parameters: hc_Waschmaschine HourCounter d_aktuelleBetriebszeit:Waschmaschine_state:.on d_aktuelleBetriebszeit:Waschmaschine_state:.off
2015.01.10 12:57:47.956 0: HourCounter hc_wzDeckenfluter Define.228 parameters: hc_wzDeckenfluter HourCounter d_aktuelleBetriebszeit:wzDeckenfluter_state:.on d_aktuelleBetriebszeit:wzDeckenfluter_state:.off
2015.01.10 12:57:47.956 0: HourCounter hc_wzPS3 Define.228 parameters: hc_wzPS3 HourCounter d_aktuelleBetriebszeit:wzPS3_state:.on d_aktuelleBetriebszeit:wzPS3_state:.off
2015.01.10 12:57:47.957 0: HourCounter hc_wzReceiver Define.228 parameters: hc_wzReceiver HourCounter d_aktuelleBetriebszeit:wzReceiver_state:.on d_aktuelleBetriebszeit:wzReceiver_state:.off
2015.01.10 12:57:47.957 0: HourCounter hc_wzTV Define.228 parameters: hc_wzTV HourCounter d_aktuelleBetriebszeit:wzTV_state:.on d_aktuelleBetriebszeit:wzTV_state:.off
2015.01.10 12:57:48.294 3: kuGeschirrspuehler: I/O device is jeelink
2015.01.10 12:57:48.295 3: kuKaffeemaschine: I/O device is jeelink
2015.01.10 12:57:48.754 3: FHEM2FHEM opening sysFhemVerteiler at 10.0.0.43:7072
2015.01.10 12:57:48.755 3: FHEM2FHEM device opened (sysFhemVerteiler)
2015.01.10 12:57:48.761 3: telnetPort: port 7072 opened
2015.01.10 12:57:48.761 0: HourCounter testhc Define.228 parameters: testhc HourCounter szHeizung:.actuation szHeizung:.actuation.0
2015.01.10 12:57:48.765 3: macbookairLadedose: I/O device is jeelink
2015.01.10 12:57:49.095 3: wzMacMini: I/O device is jeelink
2015.01.10 12:57:51.151 0: HourCounter hc_plexSerien Define.228 parameters: hc_plexSerien HourCounter plex.type:.episode plex.playStatus:.(stopped|paused)
2015.01.10 12:57:51.224 2: fronthem: ipc listener opened at port 16385
2015.01.10 12:57:51.227 1: PERL WARNING: Filehandle STDIN reopened as STDOUT only for output at ./FHEM/01_fronthem.pm line 562.
2015.01.10 12:57:51.232 3: IN CHILD start forked ws: ws:13995
2015.01.10 12:57:51.236 1: Including ./log/fhem.save
2015.01.10 12:57:51.392 1: in REREADCFG
2015.01.10 12:57:51.393 1: in REREADCFG
2015.01.10 12:57:51.398 3: harmony: connected
2015.01.10 12:57:51.412 1: withings: no I/O device
2015.01.10 12:57:52 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2015.01.10 12:57:52.925 1: Including fhem.cfg
2015.01.10 12:57:52.933 3: Opening jeelink device /dev/tty.usbserial-AE01DUEH
2015.01.10 12:57:52.950 3: Setting jeelink baudrate to 57600
2015.01.10 12:57:52.951 3: jeelink device opened
2015.01.10 12:57:53.968 3: Opening CUL1 device /dev/tty.usbmodem1d1321
2015.01.10 12:57:53.968 3: Setting CUL1 baudrate to 9600
2015.01.10 12:57:53.969 3: CUL1 device opened
2015.01.10 12:57:54.098 3: CUL1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.01.10 12:57:54.134 1: HMLAN_Parse: HMLan new condition disconnected
2015.01.10 12:57:54.134 3: Opening HMLan device 10.0.0.55:1000
2015.01.10 12:57:54.138 3: HMLan device opened
2015.01.10 12:57:54.138 1: HMLAN_Parse: HMLan new condition init
2015.01.10 12:57:54.173 3: WEB: port 63191 opened
2015.01.10 12:57:54.177 3: WEBphone: port 63193 opened
2015.01.10 12:57:54.178 3: webReadOnly: port 62789 opened
2015.01.10 12:57:54.179 3: WEBtablet: port 63192 opened
2015.01.10 12:57:54.193 3: Waschmaschine: I/O device is jeelink
2015.01.10 12:57:54.198 3: HourCounter HourCounter Initialize.220 Init Done with Version 1.0.1.2 - 24.12.2014
2015.01.10 12:57:54.198 0: HourCounter hourCounterAllgemein Define.228 parameters: hourCounterAllgemein HourCounter sys_s0EingangAllgemein:pin:.on sys_s0EingangAllgemein:pin:.off
2015.01.10 12:57:54.199 0: HourCounter hourCounterBoiler Define.228 parameters: hourCounterBoiler HourCounter sys_s0EingangBoiler:pin:.on sys_s0EingangBoiler:pin:.off
2015.01.10 12:57:54.306 3: Durchlauferhitzer: I/O device is jeelink
2015.01.10 12:57:54.362 2: eventTypes: loaded 13964 events from ./log/eventTypes.txt
2015.01.10 12:57:54.401 3: Registering GEOFANCY geofancy for URL /geo...
2015.01.10 12:57:54.402 0: HourCounter hc_allgRegensensor Define.228 parameters: hc_allgRegensensor HourCounter d_allgRegensensor:regen:.1 d_allgRegensensor:regen:.0
2015.01.10 12:57:54.402 0: HourCounter hc_kuKaffeemaschine Define.228 parameters: hc_kuKaffeemaschine HourCounter kuKaffeemaschine:doKaffee:.1 kuKaffeemaschine:doKaffee:.0
2015.01.10 12:57:54.402 0: HourCounter hc_Waschmaschine Define.228 parameters: hc_Waschmaschine HourCounter d_aktuelleBetriebszeit:Waschmaschine_state:.on d_aktuelleBetriebszeit:Waschmaschine_state:.off
2015.01.10 12:57:54.403 0: HourCounter hc_wzDeckenfluter Define.228 parameters: hc_wzDeckenfluter HourCounter d_aktuelleBetriebszeit:wzDeckenfluter_state:.on d_aktuelleBetriebszeit:wzDeckenfluter_state:.off
2015.01.10 12:57:54.403 0: HourCounter hc_wzPS3 Define.228 parameters: hc_wzPS3 HourCounter d_aktuelleBetriebszeit:wzPS3_state:.on d_aktuelleBetriebszeit:wzPS3_state:.off
2015.01.10 12:57:54.403 0: HourCounter hc_wzReceiver Define.228 parameters: hc_wzReceiver HourCounter d_aktuelleBetriebszeit:wzReceiver_state:.on d_aktuelleBetriebszeit:wzReceiver_state:.off
2015.01.10 12:57:54.403 0: HourCounter hc_wzTV Define.228 parameters: hc_wzTV HourCounter d_aktuelleBetriebszeit:wzTV_state:.on d_aktuelleBetriebszeit:wzTV_state:.off
2015.01.10 12:57:54.740 3: kuGeschirrspuehler: I/O device is jeelink
2015.01.10 12:57:54.741 3: kuKaffeemaschine: I/O device is jeelink
2015.01.10 12:57:55.289 3: FHEM2FHEM opening sysFhemVerteiler at 10.0.0.43:7072
2015.01.10 12:57:55.290 3: FHEM2FHEM device opened (sysFhemVerteiler)
2015.01.10 12:57:55.300 3: telnetPort: port 7072 opened
2015.01.10 12:57:55.300 0: HourCounter testhc Define.228 parameters: testhc HourCounter szHeizung:.actuation szHeizung:.actuation.0
2015.01.10 12:57:55.304 3: macbookairLadedose: I/O device is jeelink
2015.01.10 12:57:55.633 3: wzMacMini: I/O device is jeelink
2015.01.10 12:57:57.743 0: HourCounter hc_plexSerien Define.228 parameters: hc_plexSerien HourCounter plex.type:.episode plex.playStatus:.(stopped|paused)
2015.01.10 12:57:57.856 2: fronthem: ipc listener opened at port 16384
2015.01.10 12:57:57.863 3: IN CHILD start forked ws: ws:13997
2015.01.10 12:57:57.878 1: Including ./log/fhem.save
2015.01.10 12:57:58.017 1: in INITIALIZED
2015.01.10 12:57:58.017 1: in INITIALIZED
2015.01.10 12:57:58.023 3: harmony: connected
2015.01.10 12:57:58.033 3: No I/O device found for withings
2015.01.10 12:57:58.033 1: withings: no I/O device
2015.01.10 12:57:58.381 2: SecurityCheck: WEBphone,WEBtablet,webReadOnly has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.01.10 12:57:58.381 0: Server started with 451 defined entities (version $Id: fhem.pl 7358 2014-12-29 16:03:31Z rudolfkoenig $, os darwin, user Fabian, pid 13996)
2015.01.10 12:57:58.454 1: HMLAN_Parse: HMLan new condition ok
2015.01.10 12:57:58.534 3: ipc fronthem:127.0.0.1:50403 (ws): ws alive with pid 13997
2015.01.10 12:57:58.557 2: Waschmaschine läuft
2015.01.10 12:57:58.577 3: PCA301 Unknown device FDED1D, please define it
2015.01.10 12:57:58.581 1: in UNDEFINED
2015.01.10 12:57:58.581 1: in UNDEFINED
2015.01.10 12:57:58.584 3: PCA301 Unknown device 0D8CC5, please define it
2015.01.10 12:57:58.587 1: in UNDEFINED
2015.01.10 12:57:58.587 1: in UNDEFINED
2015.01.10 12:57:58.617 3: PCA301 Unknown device 3F5397, please define it
2015.01.10 12:57:58.620 1: in UNDEFINED
2015.01.10 12:57:58.620 1: in UNDEFINED
2015.01.10 12:57:59.113 3: harmony: new config
2015.01.10 12:57:59.147 3: harmony: IODev for device 22738462 is harmony
2015.01.10 12:57:59.247 3: harmony: IODev for device 22734976 is harmony
2015.01.10 12:57:59.293 3: harmony: IODev for device 22735131 is harmony
2015.01.10 12:57:59.295 3: harmony: IODev for device 22738983 is harmonyHast du einen Tipp was ich noch versuchen könnte?
Zitat von: herrmannj am 10 Januar 2015, 12:29:28Teil zwei: jenau ! ;) wobei der ipc ohnehin nicht einfach so seinen Leiden erliegen soll. Da gibt es aber eine Verbindung zu dem disconnect Thema, bin da gerade dran, man sieht schon Licht am Ende des tunnels. Da noch abwarten bitte.
Kein stress!
Grüße
Edit:Zitat von: herrmannj am 10 Januar 2015, 12:29:28
nicht das es an was anderem liegt (blocking, presence und co).
Wenn das fronthem device gelöscht ist, funktioniert der restart ganz normal.
Hi Danke,
hab gerade Deinen edith gelesen (wollte das gerade vorschlagen :)) Du hattest das irgendwie auf einem mac -richtig ? Ich schau da nochmal rein. Das wundert mich eigentlich weil der fork in der mutter gemacht wird, but who knows ...
Der Teil2 hat wegen dem disconnect und der damit einhergehenden Behinderung im Normalbetrieb kurzfristig höhere prio.
vg
jörg
Hallo,
ich weiß nicht ob es ein Fehler ist oder ob ich es überlesen habe!
Wenn das Gad im Namen ein "ß" enthält, kann man zwar im FHEM ein Device zuordnen, aber in smartVISU wird dieses nicht angezeigt!
Hat mich gerade ein paar Nerven gekostet! :-)
Gruß Lutz
Hi,
ne, kannte ich noch nicht. Danke. Wird was mit dem utf8 zu tun haben - das ist auch aktuell das einzige issue wo ich im dunkeln tappe.
vg
jörg
Zitat von: herrmannj am 10 Januar 2015, 13:15:12
Du hattest das irgendwie auf einem mac -richtig ?
Ja.
Das ist ein MacMini mit OSX 10.10.1 und OS X Server 4.0.3
Die Server Erweiterung bringt u.a. den Webserver mit auf dem smartVisu läuft. FHEM läuft in meinem Benutzerverzeichnis.
Grüße
Zitat von: fhainz am 10 Januar 2015, 10:59:51
Hallo!
Ich habe gestern die neue Version aus dem git eingespielt. Nur zur Info, mein shutdown restart Problem gibt es noch immer. Wenn du willst kann ich mich mal dahinter klemmen, oder wir warten die Beta 2 und sehen dann weiter.
Weiters ist mein FHEM gerade mit dieser Meldung in der Console komplett abgestürzt.
Liegt vermutlich an diesem TODO, wollte das aber trotzdem melden ;)
Grüße
Hallo,
ich muss mich da leider anschließen. Auch nach update führt ein shutdown restart noch zum crash.
Allerdings schmiert FHEM bei einem rereadcfg nicht mehr ab :)
Was mir auch aufgefallen ist: Ich habe gerade wieder so einen seltsamen Verbindungsabbruch. Erst ging gar nichts. Nach mehrmaligem fhem Neustart zeigt er jetzt "connected" an, aber der Editor ist vollkommen leer und es werden auch keine Werte angezeigt. Das rote Dreieck ist nicht zu sehen.
Hilft da nur noch ein Neustart des servers?
schöne Grüße
Jo
Hi,
eine regression :) Danke
Wer viele GADs hat sollte mit dem update noch kurz warten (bzw temporär wieder zurück), kommt bald eine neue version dazu.
vg
jörg
Zitat von: Jojo11 am 10 Januar 2015, 14:31:48
Was mir auch aufgefallen ist: Ich habe gerade wieder so einen seltsamen Verbindungsabbruch. Erst ging gar nichts. Nach mehrmaligem fhem Neustart zeigt er jetzt "connected" an, aber der Editor ist vollkommen leer und es werden auch keine Werte angezeigt. Das rote Dreieck ist nicht zu sehen.
unbedingt zuerst, sofort die fronthem.cfg (im server dir) sichern !!! Deine GADs verschwinden soonst. vg jörg
Zitat von: herrmannj am 10 Januar 2015, 14:40:21
unbedingt zuerst, sofort die fronthem.cfg (im server dir) sichern !!! Deine GADs verschwinden soonst. vg jörg
Zu spät ;D
Ich habe den server neu gestartet und jetzt läuft es wieder. Alle GADs sind noch da 8)
schöne Grüße
Jo
Zitat von: Jojo11 am 10 Januar 2015, 14:53:28
Zu spät ;D
Ich habe den server neu gestartet und jetzt läuft es wieder. Alle GADs sind noch da 8)
schöne Grüße
Jo
Ein Glück, denk(t) daran das regelmäßig zu sichern. Wir haben hier beta 1 -
Für die cfg: die ist JSON und fronthem schaut beim laden ob formal richtig ist. Wenn nein wird eine neue, leere angelegt, die überschreibt die alte dann. Was wir in dieser Phase machen ist ja durchaus auf irgendwelche Sondersituationen, Außnahmefälle etc zu achten (siehe "ß"). Von daher - sichern!
Das (Ursprungs) Thema sollte sich mit dem nächsten update erledigt haben, ich muss leider Teile vom net::websocket::server umschreiben. Ist aber ok, spätestens bei ssl hätte ich das sowieso machen müssen weil der keinen out-of-band handshake vertragen hätte.
vg
jörg
Zitat von: fhainz am 10 Januar 2015, 11:59:37
Hab das in die fhconverter.pm eingefügt und ein neues gad erstellt. Der Timestamp des readings wird bis zum ersten aktualisieren angezeigt, dann wird aber der Wert des Readings angezeigt.
Muss ich noch irgendwo was machen?
Grüße
Nimm die neueste Version aus meinem GIT, da war noch ein Fehler drin!
Zitat von: herrmannj am 09 Januar 2015, 23:26:10
hab kein db log. Normale logmeldung. fhem log. wie viele gads ca hast Dun in der cfg ?
Den gesuchten Fehler habe ich nicht (force...) finden können!
Zitat von: herrmannj am 09 Januar 2015, 23:26:10
hab kein db log. Normale logmeldung. fhem log. wie viele gads ca hast Dun in der cfg ?
Ich schätze so um die 100!
Zitat von: bgewehr am 10 Januar 2015, 16:35:48
Nimm die neueste Version aus meinem GIT, da war noch ein Fehler drin!
Funktioniert, danke!
Hallo.
Ich lese hier schon eine Weile mit und finde die Möglichkeiten mit smartVISU toll. Ich habe es nun einmal nach den Tipps hier im Forum installiert und es läuft. Einen ersten Raum habe ich auch eingerichtet und Steckdosen habe ich auch schon eingerichtet. Einen Raumregler habe ich auch schon mal angetestet. Das vorhandene RTR passt zu meinem FHT leider nicht ganz. Ich wollte mich jetzt einmal an die notwendigen Anpassungen wagen. Programmierung ist etwas Neuland für mich. Aber aufbauend auf dem vorhandenen RTR und dem von bgewehr wird das schon gehen. Ich sollte aber einmal bevor ich anfange fragen, wo ich überall ran muss. Die device.html habe ich schon mal gefunden. Muss ich noch irgendwo Änderungen vornehmen? Oder hat jemand bereits einen FHT mit smartVISU gescheit am laufen?
Dirk
Hallo Dirk,
bevor Du jetzt in die Details gehst, poste doch bitte mal einen Screenshot, damit man mal sehen kann was man ad-hoc mit smartVISU erreichen kann.
Gruß!
Hallo DerFrickler,
schau Dir am besten http://www.smartvisu.de/demo/index.php an.
Design und co hast Du freie Hand. Wenn Dir controls fehlen kannst Du jederzeit eigene umsetzen, je mehr jquery und css Du kannst um so besser dafür, keine Voraussetzung.
vg
jörg
Moin zusammen,
habe eben ein update (fronthem + fhem) gemacht und nach einem fhem Neustart lässt sich das Modul fronthem nicht mehr laden. Hier mal das Log.
2015.01.11 10:10:22.993 1: reload: Error:Modul 01_fronthem deactivated:
Can't locate fhwebsocket.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.01.11 10:10:22.993 0: Can't locate fhwebsocket.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Ist der Fehler schon bekannt?
Vielen Dank.
Hallo Dancat,
ist mir auch passiert, das update von fronthem liefert die fhwebsocket.pm nicht mit aus. Einfach die Datei direkt aus dem Git holen und ins FHEM-Vezeichnis legen. Dann funktioniert es.
Grüße
Zitat von: ftobi am 11 Januar 2015, 10:39:04
ist mir auch passiert, das update von fronthem liefert die fhwebsocket.pm nicht mit aus. Einfach die Datei direkt aus dem Git holen und ins FHEM-Vezeichnis legen. Dann funktioniert es.
Vielen Dank. Dieser Fehler ist schonmal weg.
Nach einem restart kommet der nächste:
2015.01.11 10:45:01.386 1: reload: Error:Modul 01_fronthem deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 46 at FHEM/fhwebsocket.pm line 13.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.01.11 10:45:01.386 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 46 at FHEM/fhwebsocket.pm line 13.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Hallo dancatt,
da werd ich dir nicht weiterhelfen können, bei mir tut es soweit. Hab also nur die schrittweisen Standardtipps:
- fhem neu starten (hast Du schon) -> testen
- evtl. ganze Maschine, auf der fhem läuft, neu starten -> testen
- noch mal alle dateien aus dem git neu kopieren -> testen
- unbedingt immer ne Sicherung des Verzeichnises fhem/FHEM/www/fronthem haben (da sind z.B. die r/w device-Berechtigungen) !!
Grüße
Hallo Jungs,
ihr seid ja schon fleißig. Hat bei mir auch nicht funktioniert (update) woraufhin ich erst mal die update.pm studiert habe. Jetzt verstehe ich auch warum er immer alles (und in Eurem Fall zu wenig) up-dated.
War aber zu spät um das neu zu packen. Der richtige Syntax lautet temporär:
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
später dann
update all https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt.
@Daniel: mach das mal mit dem force, (danach shutdown restart). Damit wären Probleme beim kopieren ausgeschlossen.
Das update begegnet dem disconnect den einige nach der letzten Version hatten.
Außerdem habe ich die converter von Bernd übernommen (vielen Dank) und einen beispielhafte 99_fronthemUtils.pm mit einem converter erstellt.
Die 99er nehme ich nicht mit in das update Paket. Das entspricht Konventionen: 99er sollen bei updates eben nicht überschrieben werden. Die soll in erster Linie ein Anschauungsbeispiel sein damit man die fhconverter nicht mehr anfassen muss und damit riskiert das updates die eigenen converter überschrieben.
vg
jörg
Zitat@Daniel: mach das mal mit dem force, (danach shutdown restart). Damit wären Probleme beim kopieren ausgeschlossen.
Vielen Dank. Das hat funktioniert.
Seit dem gestrigen Fhem-Update gibt es mehrere Probleme. Hab heute schon einiges gelesen. Mal sehen was passiert.
Z.B. werden in Fhem keine Dropdownlisten mehr angezeigt oder
in einer Devicedefinition beim Klick auf den Attributnamen wird der Wert nicht mehr ins Edit-Feld übernommen und und und.
Das hat sicher mit dem JS-Umbau nach jquery zu tun, schaut mal im fhem-Git!
Hallo,
das ist (leider) korrekt. Der fhemweb eigene jquery loader ist seid langer Zeit sehr buggy, die jquery docs sind eindeutig wie es richtig aussehen muss.
Das hat mir auch viele Probleme beim schreiben des fronthem editors gemacht weil immer wieder andere Module da zwischen ge-grätscht haben. Das hatte ich mehrfach gemeldet - ohne Ergebniss geschweige denn Resultat. Jquery hat einen Betriebsmode "noconflict" - der ist dazu da eine eigene jquery (neben anderen) zu betreiben ohne das die sich ins Gehege kommen: noconflict.
Auf den musste ich dann zähneknirschend ausweichen. Das hat zum Ergebnis das der fronthem editor vom (durchaus tiefgreifenden) fhemweb.js Umbau völlig unbeeindruckt ist - und läuft. Das es anders herum nicht so ist liegt daran das fhemweb.js leider immer noch nicht korrekt die jquery lädt, von einer im "noconflict" Modus laufenden Instanz gebremst zu werden (nochmal, das ist der Modus ich gehe Dir aus dem Weg) ist kein gutes Zeichen :)
Ich hoffe mal das Rudi hier jetzt überhaupt mal in den Dialog geht, man (er ;) ) könnte das vergleichsweise einfach fixen. Alles andere wird Murks.
vg
jörg
Hallo Frickler.
Ich hänge hier mal zwei Bilder dran. Das habe ich mit einfachen Anpassungen schon einmal hin bekommen. Ich arbeite mich erst in das Thema ein.
Aber was ist mit meiner Frage. Wo muss ich alles Änderungen vornehmen, wenn ich den RTR an meinen FHT anpassen möchte. Die device.html habe ich schon entdeckt. Gibt es noch Dateien, die geändert werden müssen? Oder hat jemand schon einen FHT Raumregler eingebunden?
Ohne die Anpassung an den FHT werde ich diese Fehlermeldungen sonst wohl nicht los.
2015.01.11 12:56:49 3: set FHT_Schlafen ? : Unknown argument ?, choose one of day day-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 desired-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 fri-from1:time fri-from2:time fri-to1:time fri-to2:time holiday1 holiday2 hour lowtemp-offset manu-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 minute mode mon-from1:time mon-from2:time mon-to1:time mon-to2:time month night-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 report1 report2 sat-from1:time sat-from2:time sat-to1:time sat-to2:time sun-from1:time sun-from2:time sun-to1:time sun-to2:time thu-from1:time thu-from2:time thu-to1:time thu-to2:time tue-from1:time tue-from2:time tue-to1:time tue-to2:time wed-from1:time wed-from2:time wed-to1:time wed-to2:time windowopen-temp:on,off,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 year
Zitat von: dancatt am 11 Januar 2015, 10:47:20
Vielen Dank. Dieser Fehler ist schonmal weg.
Nach einem restart kommet der nächste:
2015.01.11 10:45:01.386 1: reload: Error:Modul 01_fronthem deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 46 at FHEM/fhwebsocket.pm line 13.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.01.11 10:45:01.386 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 46 at FHEM/fhwebsocket.pm line 13.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Das sieht mir nach einer falsch geholten fhwebsocket aus! Am besten in ein frisches Verzeichnis ein
git clone https://github.com/herrmannj/fronthem.git
Dann hast Du die Dateien korrekt auf Deinem Server. Kopier sie in die richtigen Verzeichnisse und chmod 755, dann sollte es gehen. Alternativ nimm die force-update Regel von Jörg, siehe oben...
Hallo dlehmann69,
das issccht gar keine Fehlermeldung. :)
Die Meldung kommt ins log weil der Editor die set beim FHT mit "?" abfragt. Rudi verwendet in fhemweb eine schönere Variante (weil ohne Meldung im log) - die baue ich auch ein.
Wenn Du Änderungen in sv machst würde ich Dir vorschlagen die device.html so zu lassen wie sie ist und eine Kopie davon anzulegen (vielleicht mydevice.html oder so), dort zu ändern und dann anstelle der device.html diese zu importieren. (Mit den richtigen namings, versteht sich).
Mal anders, woran hängt es denn im Augenblick ?
vg
jörg
update force ... geht.
Nachdem ich das System jetzt verstehe ändere ich auch in Kürze das git so das nur noch die frischen Dateien geholt werden.
vg
jörg
Zitat von: herrmannj am 11 Januar 2015, 11:50:05
Außerdem habe ich die converter von Bernd übernommen (vielen Dank) und einen beispielhafte 99_fronthemUtils.pm mit einem converter erstellt.
Ich hab noch einen für Euch: der Setreading-Converter, der ein bisschen fragwürdig ist, weil er nicht von fhem aus getriggert werden kann, um seine Werte in SV aufzufrischen.
Er setzt einen SV-Wert an ein benutzerdefiniertes Reading an jedes beliebige fhem-device. Wenn das Reading vorher noch nicht existiert, dann wird es erzeugt. (Hinweis: Überflüssige Readings kann man mit deletereading <device> <reading> in der fhem Kommandozeile wieder entfernen.)
Dennoch sehe ich eine sinnvolle Nutzung dafür, um einige Dummies zu ersparen. So kann man mit diesem Converter irgendetwas an ein fhem-device "speichern", um es später wieder in SV nutzen zu können, so als Zwischenspeicher.
Ich starte grade meine Versuche, damit ein Reading uzsu an die zeitaktivierten fhem-devices zu speichern, dass dann mit einem uzsu-modul in fhem ausgewertet werden kann. Mal sehen....
Zitat von: bgewehr am 11 Januar 2015, 13:25:53
Das sieht mir nach einer falsch geholten fhwebsocket aus! Am besten in ein frisches Verzeichnis ein
git clone https://github.com/herrmannj/fronthem.git
Dann hast Du die Dateien korrekt auf Deinem Server. Kopier sie in die richtigen Verzeichnisse und chmod 755, dann sollte es gehen. Alternativ nimm die force-update Regel von Jörg, siehe oben...
Danke, aber es läuft ja schon. Der Tip von Jörg mit dem "update force..." hatte anscheinend gereicht.
Hallo herrmann.
Danke für die schnelle Antwort. Ihr seit echt schnell hier.
Also keine Fehlermeldung, ok. Dann ignoriere ich die Meldung, bis sie nicht mehr kommt.
Also es hängt nicht wirklich, nur ist programmieren neu für mich und eher auch nur Hobby. Und ich möchte das Device RTR an meinen FHT anpassen. Ich benötige nicht die Icons im Standard RTR und möchte dafür den Fensterstatus mit angezeit bekommen. Dafür wollte ich aus dem Standard RTR und dem Homematic RTR von bgewehr die notwendigen Dinge holen und für den FHT zusammen schreiben.
Und mit einer z.B. mydevice.html geht es gleich weiter. Das muss ich mal schauen, wo die dann importiert wird. Für diese eine Seite habe ich eine Weile gebraucht. Vorallem mit den ganzen div Tags. Bis die alle stimmten, hat es eine Weile gedauert. Aber mit ein wenig Struktur in der Datei behält man den Überblick.
Dirk
Hi Dirk,
schau Dir am besten mal die homemmatic.html von Bernd an. Bernd macht exakt das für hm device. Die files liegen hier im thread (irgendwo ;D ) - oder in seinem git https://github.com/bgewehr.
Generell hab ich auch schon mal gedacht ob man nicht ein widget ohne icons erstellt, die icons kann man ja fix via basic.symbol darunter setzen. Bin in einer ähnlichen Situation weil meine HM-TC keine batterie readings liefern - hängt wohl von der firmware ab.
vg
jörg
Zitat von: herrmannj am 11 Januar 2015, 13:46:24
... weil meine HM-TC keine batterie readings liefern - hängt wohl von der firmware ab.
vg
jörg
Sowohl mein HM-TC als auch mein HM-CC haben im Haupt-device (der Mutter) das battery-level-reading mit der Voltzahl der Batterie.
Meine auch. Und ich denke, ich habe von allen vorhandenen Firmwareversionen mindestens ein Gerät ;)
Hallo,
ich bin nun seit 2 Tagen auch vom fronthem-Virus infiziert.
Hatte zwar anfangs auch meine Probleme aber mit den nun 52 Seiten Thread soweit alles hin bekommen.
Die bessere Hälfte ist auch begeistert und so hab ich die eine oder andere Stunde Zeit genehmigt bekommen.
Es ist leicht OT aber für den WAF muss ich den Google Kalender noch ans fliegen bekommen, da sonst Geburtstage und Müll fehlen.
Leider bleibt es leer wenn ich es wie in den Demohäusern einrichten will. Im Demohaus direkt geht es auch nicht
Läuft das bei jemandem?
@Jörg: Ich habe aktuell geschafft, das UZSU-Widget mit einem Reading uzsu eines fhem device zu verbinden, so dass die Speicherung der JSON-Information zum Widget erledigt wäre. Ich nutze dazu einen setreading-converter, der eine regex-replace macht ';' -> ';;' weil sonst fhem den String nach dem ersten ';' abschneidet.
Den Code im visu.js habe ich so angepasst, dass stringify und eval genutzt werden, um die Daten von JSON object in String und zurück zu wandeln.
Nun könnte man sich mit der Interpretation in fhem beschäftigen. Welchen Grundansatz hältst Du für sinnvoll?
Im uzsu-Converter einen notify triggern, der in fhem die nötigen at Befehle erstellt? Wäre einfach, oder?
Was meinst Du?
Alle Änderungen sind im git (fhem und SV).
Edit 15:09: RegExp korrigiert, hat nur das erste ';' ersetzt. Nun alle.
Zitat von: Daku123 am 11 Januar 2015, 14:12:19
Hallo,
ich bin nun seit 2 Tagen auch vom fronthem-Virus infiziert.
Hatte zwar anfangs auch meine Probleme aber mit den nun 52 Seiten Thread soweit alles hin bekommen.
Die bessere Hälfte ist auch begeistert und so hab ich die eine oder andere Stunde Zeit genehmigt bekommen.
Es ist leicht OT aber für den WAF muss ich den Google Kalender noch ans fliegen bekommen, da sonst Geburtstage und Müll fehlen.
Leider bleibt es leer wenn ich es wie in den Demohäusern einrichten will. Im Demohaus direkt geht es auch nicht
Läuft das bei jemandem?
Hi,
ich glaub das im knx forum gesehen zu haben, da gab es wohl eine Ädnerung in der google api und (bei den knx lern) auch einen fix. @Bernd: warst Du da nicht auch dran ?
vg
jörg
Sucht mal nach "Yoshi-ical". Damit funktioniert die iCal Variante.
Zitat von: herrmannj am 11 Januar 2015, 14:57:37
Hi,
ich glaub das im knx forum gesehen zu haben, da gab es wohl eine Ädnerung in der google api und (bei den knx lern) auch einen fix. @Bernd: warst Du da nicht auch dran ?
vg
jörg
Ja, ich habe den Abfallkalender als lokale Datei mit hübschen Tonnensymbolen hinbekommen, wie im KNX Userforum-Thread beschrieben s.o. Im anderen Beitrag. Stichwort iCal-sabredav.
Der Google Kalender geht auch, war aber tricky mit der Prozedur aus dem KNX-Thread.
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 11 Januar 2015, 14:53:23
@Jörg: Ich habe aktuell geschafft, das UZSU-Widget mit einem Reading uzsu eines fhem device zu verbinden, so dass die Speicherung der JSON-Information zum Widget erledigt wäre. Ich nutze dazu einen setreading-converter, der eine regex-replace macht ';' -> ';;' weil sonst fhem den String nach dem ersten ';' abschneidet.
Den Code im visu.js habe ich so angepasst, dass stringify und eval genutzt werden, um die Daten von JSON object in String und zurück zu wandeln.
Nun könnte man sich mit der Interpretation in fhem beschäftigen. Welchen Grundansatz hältst Du für sinnvoll?
Im uzsu-Converter einen notify triggern, der in fhem die nötigen at Befehle erstellt? Wäre einfach, oder?
Was meinst Du?
Alle Änderungen sind im git (fhem und SV).
Hi,
ja, bin leider noch nicht dazu gekommen da tiefer einzusteigen - ich schaff ja nicht mal mein sv weiter einzurichten :-X
Grundsätzlich würde ich vorschlagen die Übernahmen in fhem nochmal ohne Anpassung vom widget zu versuchen (also ich, musst Du nix machen).
Danach kommt aber, so wie Du sagst, der Punkt wo es spannend wird:
wenn wir da mit notify und at rangehen wird das mMn recht schnell komplex. Die Daten müssen ja von JSON in eine (variable) Struktur gebracht werden. Logisch kann man das auch mit notify (plus viel perl wegen Zeiten extrahieren) und at lösen.
Für die uzsu halte ich es für sinnvoll ein fhem device zu erstellen. Das magst Du jetzt nicht gerne hören weil Du das möglichst schnell willst - gelle ? :D Ich glaube auch das fhem sowieso noch kein solches device kennt - der weekday timer den ich mir mal dafür angeschaut hatte arbeitet scheinbar direkt mit einem Heizungsmodul zusammen, insofern besteht da vmtl sowieso ein need. Mit Andre hatte ich schon mal gesprochen, der würde generell das widget für fhemweb bauen wollen (ich finde Sonderlocken nicht so doll).
Soweit ich das sehe müssten wir, mit dem update von gestern, eigentlich wieder stabil genug unterwegs sein. Ich will mir sowieso einen fhem-sv-Wecker device bauen (weil ich sv auch auf einem Radiowecker betreibe). Da könnte ich das in einem Rutsch mit machen. Wenn nichts dazwischen kommt 1,2 tage.
Wäre ok ?
vg
jörg
Zitat von: karl0123 am 11 Januar 2015, 14:05:12
Meine auch. Und ich denke, ich habe von allen vorhandenen Firmwareversionen mindestens ein Gerät ;)
Ich denk ja auch das es an mir liegt ... nur:
model HM-CC-VD
D-firmware 2.0das einzige battery reading das ich finde ist "ok"
battery ok
model HM-CC-TC
firmware 2.1
...
battery okgepaird sind die, fhem von kurz vor Weihnachten. ... Wie sieht das reading denn bei Euch aus ?
danke und Grüße
jörg
edith, einige vd sind 1.9 - da siehts aber genauso aus.
@all:
beseitigt das aktuelle update das "disconnect" zufriedenstellend ?
vg
jörg
Hallo zusammen,
ich habe unter http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem) einen ersten Wurf der Installationsanleitung.
Habe diesen auch in http://www.fhemwiki.de/wiki/Fronthem (http://www.fhemwiki.de/wiki/Fronthem) verlinkt.
Bei Gelegenheit könnt ihr ja mal drüberschauen, ändern oder euch hier melden.
Vielen Dank.
Zitat von: herrmannj am 11 Januar 2015, 15:47:21
...
battery ok
...
Jedes HM-TC und HM-CC besteht doch aus mehreren fhem-devices. Z. B. das XXX.clima. Darin findet man den Link zum XXX-device (der "Mutter").
Darin ist bei mir in beiden Fällen
battery ok 2014-12-24 00:05:25
batteryLevel 3.1 2015-01-11 16:49:01
Ich habe Firmware 1.3!
Zitat von: herrmannj am 11 Januar 2015, 15:13:52
Grundsätzlich würde ich vorschlagen die Übernahmen in fhem nochmal ohne Anpassung vom widget zu versuchen (also ich, musst Du nix machen).
Danach kommt aber, so wie Du sagst, der Punkt wo es spannend wird:
wenn wir da mit notify und at rangehen wird das mMn recht schnell komplex. Die Daten müssen ja von JSON in eine (variable) Struktur gebracht werden. Logisch kann man das auch mit notify (plus viel perl wegen Zeiten extrahieren) und at lösen.
Für die uzsu halte ich es für sinnvoll ein fhem device zu erstellen. Das magst Du jetzt nicht gerne hören weil Du das möglichst schnell willst - gelle ? :D Ich glaube auch das fhem sowieso noch kein solches device kennt - der weekday timer den ich mir mal dafür angeschaut hatte arbeitet scheinbar direkt mit einem Heizungsmodul zusammen, insofern besteht da vmtl sowieso ein need. Mit Andre hatte ich schon mal gesprochen, der würde generell das widget für fhemweb bauen wollen (ich finde Sonderlocken nicht so doll).
Soweit ich das sehe müssten wir, mit dem update von gestern, eigentlich wieder stabil genug unterwegs sein. Ich will mir sowieso einen fhem-sv-Wecker device bauen (weil ich sv auch auf einem Radiowecker betreibe). Da könnte ich das in einem Rutsch mit machen. Wenn nichts dazwischen kommt 1,2 tage.
Hier ist der Python-Code, mit dem das JSON in smarthome.py ausgewertet und interpretiert wird:
https://github.com/mknx/smarthome/blob/develop/plugins/uzsu/__init__.py
Vielleicht hilft's ja!
Zitat von: bgewehr am 11 Januar 2015, 17:00:24
Jedes HM-TC und HM-CC besteht doch aus mehreren fhem-devices. Z. B. das XXX.clima. Darin findet man den Link zum XXX-device (der "Mutter").
Darin ist bei mir in beiden Fällen
battery ok 2014-12-24 00:05:25
batteryLevel 3.1 2015-01-11 16:49:01
Ich habe Firmware 1.3!
danke. Bin beim TC auf der Mutter - ( vd haben bei mir keine) - da ist nur battery ok. Dann ich aber insofern schlauer das mir ein reading fehlt, entweder weil die fw anders ist oder weil ich was falsch mach, irgendein register nicht gelesen habe oder so was in der Art. Ist zum Glück nicht Kriegsentscheidend - ich schieb das mal auf ;) Danke, jörg
Zitat von: bgewehr am 11 Januar 2015, 17:04:31
Hier ist der Python-Code, mit dem das JSON in smarthome.py ausgewertet und interpretiert wird:
https://github.com/mknx/smarthome/blob/develop/plugins/uzsu/__init__.py
Vielleicht hilft's ja!
Ja super, Danke. Das interpretieren ist mMn recht entspannt. Für mich ist eher die Frage wie man das vernünftig in fhem integriert, und zwar in zwei Punkten:
zum ersten kannst Du bei der uzsu doch beliebig viele Schaltgruppen erstellen, zumindest habe ich das so verstanden. Das läßt sich in fhem schlecht in readings abbilden (weil variable Anzahl). Da könnte ich mir vorstellen das man die einzelnen Gruppen per "get" abfragen kann und nur ein reading für das jeweils folgende event erstellt.
punkt 2 betrifft die konkrete Aktionen die ausgelöst werden sollen. Also nehmen wir mal an Du erstellst 3 Gruppen, jeweils für eine andere Jalousie. Die fhem Seite muss ja jetzt (wenn eingestellte Zeit erreicht ist) eine konkrete Aktion auslösen (Jalousie morgens hoch, Abends runter)
Variante a: an dem fhem uzsu part wird konkret eingestellt was passieren soll (set x on)
Variante b: das fhem device sendet ein event, und man erstellt ein notify was darauf reagiert.
a ist wieder doof umzusetzen (wegen variabler Anzahl von möglichen Gruppen).
Daher würde ich zu b (event von der uzsu, notify macht) tendieren. So ein Event könnte dann so aussehen: "uzsu <group1> on"
Meinungen, Ideen, Anregungen ?
vg
jörg
Zitat von: herrmannj am 11 Januar 2015, 17:12:25
danke. Bin beim TC auf der Mutter - ( vd haben bei mir keine) - da ist nur battery ok. Dann ich aber insofern schlauer das mir ein reading fehlt, entweder weil die fw anders ist oder weil ich was falsch mach, irgendein register nicht gelesen habe oder so was in der Art. Ist zum Glück nicht Kriegsentscheidend - ich schieb das mal auf ;) Danke, jörg
Hallo,
kann es sein, das es sich hierbei um zwei verschiedene Geräte handelt? Lauf Commandref gibt es bei einem HM-CC-VD das Reading "battery:[critical|low|ok]" und HM-CC-TC nur das Reading "battery:[low|ok]".
Das Reading "batteryLevel $bat V" tauch nur bei den neueren HM-CC-RT-DN auf.
Daher habe ich mir für die Batterieanzeige folgendes UserReading erstellt".
battRel {battRel(ReadingsVal('bz_Stellantrieb','battery',''))}Und folgendes für die 99_MyUtils.pm
sub battRel($) {
my ($state) = @_;
if ($state eq "ok") {
my $ret=100;
return $ret
}
if ($state eq "low") {
my $ret=20;
return $ret
}
if ($state eq "critical") {
my $ret=0;
return $ret
}
return 0;
}
hallo zusammen,
jörg hatte mich gefragt ob ich interesse habe für die zeitschaltuhr auch eine darstellung/widget beizusteuern mit der das device im normalem fhemweb frontend darstellbar und bedienbar ist.
ich habe die posts zur uzsu gerade erst kurz überflogen. dabei sind natürlich direkt ein paar fragen und bemerkungen aufgetaucht:
- der WeekdayTimer ist nicht (mehr) heizungs spezifisch. das urpsüngliche modul war zwar HeatingControl aber das konzept ist eigentlich allgemeiner und deshalb sollte das device umbenannt werden. da das aber probleme bei bestehenden anwendern verursacht hätte wurde WeekdayTimer zusätzlich zu HeatingControl eingecheckt und beide verwenden intern zum grossen teil den gleichen code.
- vermutlich ist es normalerweise sinnvoll mehr als solches device für dedizierte aufgaben zu haben und nicht nur eine einzige schaltuhr für alles mögliche. seht ihr das auch so?
- die uzsu 'nur' für die schaltzeiten zu haben und das eigentliche schalten über notifys zu machen hat den vorteil das man z.b. das gruppieren von devices auch durch bestehende fhem konstrukten wie structure oder LightScene machen kann.
- mir ist noch nicht ganz klar welchen funktionsumfang die uzsu genau haben soll. bzw. aus welcher richtung das desgin genau kommen soll. d.h. ob es primär um das gui geht das (nur) bestimmte dinge ermöglichen soll und das backend device dem folgt, oder ob es um funktionalität im backend geht (so universell wie möglich) die dann (so gut es geht) mit einem passenden frontend versehen werden sollen.
- diese frage stellt sich z.b. besonders wenn es darum geht wie die existierenden sunset/sunrise funktionen eingebunden werden sollen. mit perl aufrufen ist es unschlagbar flexibel aber im frontend nicht vernünftig darstellbar.
- es wäre schön wenn es eine vorausicht der nächsten schaltzeiten über mindestens eine woche gibt und hier auch die sich ändernden sonnenauf- und -untergangszeiten widerspiegeln.
ich hoffe als seiteneinsteiger ist es ok erst mal zu fragen...
gruss
andre
Zitat von: herrmannj am 11 Januar 2015, 16:51:11
@all:
beseitigt das aktuelle update das "disconnect" zufriedenstellend ?
vg
jörg
Hallo,
wenn ich jetzt smartVISU aufrufe, ist mein device connected, das rote Dreieck ist weg, aber keine Werte werden angezeigt. Der Editor ist leer. Vermutlich geht es wieder, wenn ich FHEM neustarte. Habe heute aktualisiert.
schöne Grüße
Jo
Zitat von: justme1968 am 11 Januar 2015, 18:48:43
jörg hatte mich gefragt ob ich interesse habe für die zeitschaltuhr auch eine darstellung/widget beizusteuern mit der das device im normalem fhemweb frontend darstellbar und bedienbar ist.
Danke fürs rein schauen, trotz dem fhemweb.js Umbau Streß.
Zitat
- der WeekdayTimer ist nicht (mehr) heizungs spezifisch. das urpsüngliche modul war zwar HeatingControl aber das konzept ist eigentlich allgemeiner und deshalb sollte das device umbenannt werden. da das aber probleme bei bestehenden anwendern verursacht hätte wurde WeekdayTimer zusätzlich zu HeatingControl eingecheckt und beide verwenden intern zum grossen teil den gleichen code.
verstehe, ich hab die includes gesehen und das falsch interpretiert. Da schau ich nochmal um Doppelentwicklung zu vermeiden.
Zitat
- vermutlich ist es normalerweise sinnvoll mehr als solches device für dedizierte aufgaben zu haben und nicht nur eine einzige schaltuhr für alles mögliche. seht ihr das auch so?
yes!
Zitat
- die uzsu 'nur' für die schaltzeiten zu haben und das eigentliche schalten über notifys zu machen hat den vorteil das man z.b. das gruppieren von devices auch durch bestehende fhem konstrukten wie structure oder LightScene machen kann.
sehe ich auch so.
Zitat
- mir ist noch nicht ganz klar welchen funktionsumfang die uzsu genau haben soll. bzw. aus welcher richtung das desgin genau kommen soll. d.h. ob es primär um das gui geht das (nur) bestimmte dinge ermöglichen soll und das backend device dem folgt, oder ob es um funktionalität im backend geht (so universell wie möglich) die dann (so gut es geht) mit einem passenden frontend versehen werden sollen.
Das widgets gibt es für sv, die Funktionalität (schalten) soll das fhem device erbringen. Wenn am design (sv) was geändert werden muss das geht das. Ich bin gerade beim installieren, lernen, verstehen - ich stelle nachher mal einen screenshot rein wenn Bernd nicht sogar schneller ist. In fhem muss die Bedienung (GUI) "erfunden" werden.
Zitat
- diese frage stellt sich z.b. besonders wenn es darum geht wie die existierenden sunset/sunrise funktionen eingebunden werden sollen. mit perl aufrufen ist es unschlagbar flexibel aber im frontend nicht vernünftig darstellbar.
Da sehe ich kein problem (und ja, geiles feature). Die zeiten können ja in fhem angepasst werden, muss man sich jetzt fragen wie das in der GUI und vom workflow laufen soll. Ich nehme so eine Zeitschaltuhr ja unter Umständen auch für Aufgaben die völlig unabhängig von ss/sr sind. Ladenöffnungszeiten zb.
Zitat
- es wäre schön wenn es eine vorausicht der nächsten schaltzeiten über mindestens eine woche gibt und hier auch die sich ändernden sonnenauf- und -untergangszeiten widerspiegeln.
screenshot kommt, dann siehst Du das.
Zitat
ich hoffe als seiteneinsteiger ist es ok erst mal zu fragen...
logitsch! :D je mehr desto besser.
danke und Grüße
Jörg
Zitat von: Jojo11 am 11 Januar 2015, 19:02:18
Hallo,
wenn ich jetzt smartVISU aufrufe, ist mein device connected, das rote Dreieck ist weg, aber keine Werte werden angezeigt. Der Editor ist leer. Vermutlich geht es wieder, wenn ich FHEM neustarte. Habe heute aktualisiert.
schöne Grüße
Jo
das mit gad weg hattest Du schon mal, richtig ? Nach dem update Neustart gemacht ? Die GADs dürfen im Betrieb nicht weg sein. Was bei mir noch offen ist: wenn man von der gleichen ip aus gleichzeitig, mehrfach zugreift (browser, mehrere tabs) das wird (noch) nicht abgefangen, Probleme sind da zu erwarten. Rename (noch) don't do. Erst Mutter dann device definieren. Sonst: Hast Du einen Verdacht ?
vg
jörg
pffff, ich habe keinen Plan. Kommt mir so vor, als würde die Verbindung einschlafen. Das mit den tabs kann sein, das mache ich regelmäßig.
Gerade sudo restart ohne Absturz überlebt -> läuft wieder.
Wenn ich ein Muster erkenne, gebe ich Bescheid ;)
schöne Grüße
Jo
ja cool. Aber ich hab auch Baustellen offen (siehe tabs). Pass nur bitte auf, wenn Du bei leerer GAD list speicherst -- isse wech :)
Zitat von: Jojo11 am 11 Januar 2015, 19:19:10
Kommt mir so vor, als würde die Verbindung einschlafen.
spricht für mehrer Tabs vs eine ip.
ZitatGerade sudo restart ohne Absturz überlebt -> läuft wieder.
"sudo ..." oder "shutdown ..."? shutdown sollte ok sein. Bei sudo bin ich raus 8)
vg
jörg
Sorry, habe gerade mehrere Baustellen. Meinte natürlich "shutdown restart" ;D ;D
schöne Grüße
Jo
Hallo bgewehr,
ich habe mich mal mit deinem Tabellen -Layout beschäftigt. Ist sehr gut und gefällt mir. Da ich nicht so viel Ahnung davon habe, kann ich leider nicht die Stelle finden, wo ich die Werte mit etwas mehr Abstand zur Bezeichnung des Buttons einrichten kann.
Habe schon an den verschiedenen Stellen mit "padding" versucht, hat aber leider nicht geklappt.
Kannst du mir bitte kurz helfen?
Danke Lutz
@Lutz: Wenn Du meine Dateien hast, dann hast Du mein Layout. Wenn Du das Layout anders haben möchtest, müsste ich schon sehr viel genauer wissen, welches meiner inzwischen diversen Layouts Du meinst und was daran genau anders sein soll. Ich hab halt schon viel rumgespielt... Mach mal Screenshots und sag mir , wo genau was anders sein soll! Du kannst auch Deinen Pages Folder tippen und mir senden, dann schau ich mir das mal an!
Gesendet von iPhone mit Tapatalk
Ich habe mich jetzt entschieden, was ich nehme: das modifizierte 2ndsky Layout gefällt mir am besten!
Für die Fenster habe ich noch ein Reading gebastelt, das über einen Notify hochgezählt wird, wenn das Fenster offen ist. Finde ich ganz witzig, festzustellen, wie lange (im Winter vor allem) welches Fenster geöffnet ist...
Gesendet von iPhone mit Tapatalk
@bgewehr
In der Anlage mal ein Bild. Ich meine den Abstand zwischen "Außen" und der darunter liegenden Tabelle mit den Temperaturen.
Danke
Lutz
Hier nochmal ein UZSU Beispiel. Ich mach das jetzt mal mit notifys, das ist eine schöne fhem-Übung...
Gesendet von iPhone mit Tapatalk
Hi Jörg,
zuerst auch von mir ein fettes Dankeschön für das tolle Frontend. Bin gerade dabei, all meine Devices einzurichten. Dabei bin ich beim OnOff-Konverter auf eine Komplikation gestossen: wenn ich für die Hues das Triplett aus flip, slider und rgb bastle und dann mit dem slider die Helligkeit auf < 255 ziehe, ist der state nicht mehr 'on' und der flip geht auf aus - nicht gerade schön. Ich konnte dies aber ganz einfach dadurch flicken, dass ich in fhconverter.pm in sub OnOff(@) nicht auf 'on', sondern auf 'off' teste:
$param->{gadval} = (lc($event) eq 'off')?'0':'1';
Könnte dies etwas für upstream sein, oder habe ich etwas übersehen?
danke und viele Grüße,
-Christian
Zitat von: daduke am 12 Januar 2015, 19:18:16
Hi Jörg,
zuerst auch von mir ein fettes Dankeschön für das tolle Frontend. Bin gerade dabei, all meine Devices einzurichten. Dabei bin ich beim OnOff-Konverter auf eine Komplikation gestossen: wenn ich für die Hues das Triplett aus flip, slider und rgb bastle und dann mit dem slider die Helligkeit auf < 255 ziehe, ist der state nicht mehr 'on' und der flip geht auf aus - nicht gerade schön. Ich konnte dies aber ganz einfach dadurch flicken, dass ich in fhconverter.pm in sub OnOff(@) nicht auf 'on', sondern auf 'off' teste:
$param->{gadval} = (lc($event) eq 'off')?'0':'1';
Könnte dies etwas für upstream sein, oder habe ich etwas übersehen?
danke und viele Grüße,
-Christian
Hi Christian,
Danke (aber ds Lob fürs sv gehört den sv Jungs).
wegen dem converter: im Prinzip ja, ob das jetzt bei irgend jemand Nebeneffekte in die andere Richtung hat weiß ich nicht - der Fall hier war mir auch nicht bewusst. Ansonsten stell ich das gern um - beides ist technisch gleichwertig.
Generell fehlen bei den converter noch einige - ich schau halt erstmal das der Keller stabil ist. Habe vorhin auch nochmal was im ws geändert, da gab es noch Aussetzer. Liegt im git.
Wer eigene converter braucht und das diy machen kann/will kann sich aus dem git die 99_fronthemUtils.pm als Beispiel laden und die anpassen. Die ist update-sicher (im Gegensatz zu dem fhconverter.pm)
vg
jörg
Was neues an der Converter-Front:
Ich habe mir immer einen Converter gewünscht, der irgenwas in fhem in irgendwas in SV übersetzen kann, indem reguläre Ausdrücke verwendet werden.
ICH HAB IHN FERTIG!!
Damit kann man nun tolle Sachen machen:
genRegExp on, 1, off, 0 macht das Gleiche wie der OnOff Converter
genRegExp ;;,; macht die Verdoppelung der Semikolons, die fhem braucht, um einen String mit ; von SV korrekt anzunehmen
genRegExp auf, 1, ab, 0 usw.....
Es müssen null, zwei, oder maximal vier Parameter angegeben werden, ungerade Zahlen gehen nicht. Erst immer der Wert für die fhem-Seite, dann der SV-Wert dazu.
Im Moment ist es so: Wenn die Suchregeln nicht zutreffen, wird der Inhalt zwischen SV und fhem ohne Veränderung ausgetauscht. Wird sicher nicht immer passen, kann man aber auch leicht noch ändern.
Jetzt seid Ihr dran: Bitte postet Eure Ideen, wie Ihr das für Euch verwendet habt!
###############################################################################
#
# generic regex converter (gadval =~ s/arg1/arg2/ig reading =~ setval s/arg3/arg4/ig)
# @param search1 replace1 search2 replace2
# example: genRegExp on, 1, off, 0
#
###############################################################################
sub genRegExp(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
my $result = main::Debug('geRegExp Converter params: ' . $args[0] . ', ' . $args[1] . ', ' . $args[2] . ', ' . $args[3]);
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$event = main::ReadingsVal($device, $reading, '');
if ($event =~ /$args[0]/)
{
$event =~ s/$args[0]/$args[1]/ig;
}
elsif ($event =~ /$args[2]/)
{
$event =~ s/$args[2]/$args[3]/ig;
}
$param->{gad} = $gad;
$param->{gadval} = $event;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
if ($gadval =~ /$args[1]/)
{
$gadval =~ s/$args[1]/$args[0]/ig;
}
elsif ($gadval =~ /$args[3]/)
{
$gadval =~ s/$args[3]/$args[2]/ig;
}
$param->{result} = $gadval;
$param->{results} = [];
return undef;
}
elsif ($param->{cmd} eq '?')
{
return 'usage: Direct';
}
return undef;
}
Hallo,
hab grad geschafft, den fhem-prozess zu "erschiessen". Hier die letzten Zeilen aus dem fhem-log, damit das auch zu Jörg findet und nicht nur bei mir im Log rumgammelt:
2015.01.12 21:31:50 1: PERL WARNING: Use of uninitialized value $connection in hash element at /opt/fhem/FHEM/01_fronthem.pm line 530.
2015.01.12 21:31:50 2: ipc gui:127.0.0.1:57658 (ws): error Can't call method "send" on an undefined value at /opt/fhem/FHEM/01_fronthem.pm line 530.
decoding ipc msg {"connection":"conn-ro1ZAgyI","sender":"192.168.178.46","identity":"unknown", "message":{"cmd":"monitor","items":["eg.wohnen.temperatur.luft","eg.wohnen.humidity","eg.wohnen.rm.alarm","eg.kueche.temperatur.luft","eg.kueche.humidity","eg.treppe.temperatur.luft","eg.treppe.humidity","eg.toilette.temperatur.luft","eg.toilette.humidity","eg.eingang.temperatur.luft","eg.eingang.humidity","dg.buero.temperatur.luft","dg.buero.humidity","dg.buero.rm.alarm","dg.bad.temperatur.luft","dg.bad.humidity","dg.schlafen.temperatur.luft","dg.schlafen.humidity","dg.schlafen.rm.alarm","dg.gast.temperatur.luft","dg.gast.humidity","dg.gast.rm.alarm","ug.kellertreppe.rm.alarm","ug.speisekeller.temperatur.luft","ug.speisekeller.humidity","ug.speisekeller.rm.alarm","ug.grosser_keller.temperatur.luft","ug.grosser_keller.humidity","ug.grosser_keller.rm.alarm","aussen.temperatur","aussen.humidity"]}}
Im Apache- und im sys-log war nichts aussergewöhnliches zu sehen.
What I did before, bzw. evtl. zweckdienliche Hinweise:
Auf dem Macbook mit OS-X und Firefox die Seite heute früh aufgerufen, nur den Deckel geschlossen (standby), heute abend wieder aufgemacht. Habe die Seite mit F5 neu laden müssen um Daten zu bekommen. Dann Firefox geschlossen und die Seite mit Safari geöffnet. Als da keine Daten kamen, habe ich kontrolliert, ob der fhem-Prozess noch da ist ==> nein.
BTW: wenn ich mit dem Android-Tablet morgens auf die Seite gehe und dann abends wieder, dann bekomme ich die Daten direkt, muss also keinen reconnect machen. Scheint also Browser oder Betriebssystemabhängig zu sein.
Bitte nur als "Fehlersymptom bekannt geben" sehen, nicht als "muss gefixt werden". Muchas Gracias an Jörg, für was superg..... und der Folge eines deutlich höheren WAF von fhem hier :)
Grüße
Hallo,
nach heutigem Fhem-Update funktioniert das Syntax Highlighting in Fhem nicht mehr. Mit Deaktivieren der smartVisu-Einträge in der fhem.cfg funktioniert es wieder. Der Fehler ist reproduzierbar.
fronthemEditor.js 08.01.2015 (Eine Versions-ID in den js-Dateien wäre schön)
# $Id: 01_fronthem.pm 0 2014-10-01 08:00:00Z herrmannj $
# $Id: 31_fronthemDevice.pm 0 2014-10-01 08:00:00Z herrmannj $
Grüße Jörg
Zitat von: ftobi am 12 Januar 2015, 22:01:39
Hallo,
hab grad geschafft, den fhem-prozess zu "erschiessen". Hier die letzten Zeilen aus dem fhem-log, damit das auch zu Jörg findet und nicht nur bei mir im Log rumgammelt:
...
BTW: wenn ich mit dem Android-Tablet morgens auf die Seite gehe und dann abends wieder, dann bekomme ich die Daten direkt, muss also keinen reconnect machen. Scheint also Browser oder Betriebssystemabhängig zu sein.
Bitte nur als "Fehlersymptom bekannt geben" sehen, nicht als "muss gefixt werden". Muchas Gracias an Jörg, für was superg..... und der Folge eines deutlich höheren WAF von fhem hier :)
Grüße
Sehr gern & danke für report.
Doch, das muss (!) gefixt werden. :) Ich habe im ersten post den install neu beschrieben (per update force damit einfacher). Ich bin auch im Augenblick da dran, das update ist aktuell, genau das Thema. Bitte installiere das mal und versuch den Fehler gern zu provozieren (ist ja besser wenn man daneben sitzt). Mit der aktuellen Version soll das beseitigt sein - bin ebenfalls gerade am testen. (was leider die uzsu verzögert)
vg
jörg
Zitat von: JoWiemann am 12 Januar 2015, 22:09:18
Hallo,
nach heutigem Fhem-Update funktioniert das Syntax Highlighting in Fhem nicht mehr. Mit Deaktivieren der smartVisu-Einträge in der fhem.cfg funktioniert es wieder. Der Fehler ist reproduzierbar.
fronthemEditor.js 08.01.2015 (Eine Versions-ID in den js-Dateien wäre schön)
# $Id: 01_fronthem.pm 0 2014-10-01 08:00:00Z herrmannj $
# $Id: 31_fronthemDevice.pm 0 2014-10-01 08:00:00Z herrmannj $
Grüße Jörg
ja stimmt, die im Modul ist auch nicht aktuell. Das hängt mit dem fhem js update zusammen. Rudi hat den loader aber scheinbar so gefixt das ich den den jquery loader im editor anpassen kann - dann sollte das weg sein.
können wir beide das kurz testen ?
vg
jörg
Zitat von: herrmannj am 12 Januar 2015, 22:18:17
Bitte installiere das mal und versuch den Fehler gern zu provozieren (ist ja besser wenn man daneben sitzt). Mit der aktuellen Version soll das beseitigt sein - ...
Hallo Jörg,
sieht erst mal sehr gut aus: habe jetzt zweimal von Safari auf Firefox und wieder zurück gewechselt, fhem läuft weiter und die Daten kommen auch sauber an. Top :)
Grüße
Hallo zusammen,
endlich habe ich fronthem auch bei mir am laufen. An dieser Stelle eine große Dankeschön an "herrmannj & Co" für die brillante Arbeit. Wirklich toll.
Bei mir lief vor der Installation von Fronthem noch der OwServer httpd daemon. Der benutzt lustiger weise ebenfalls port 2121.
Das fiel bei einen telnet auf den Port allerdings nicht sofort auf. Erst als ich ein wget auf den port gemacht habe.
Lustigerweise klappt wenn der OwServer http deamin läuft das "update force ..." auf der Konsole ebenfalls nicht. Den Zusammenhang habe ich aber nicht hergestellt.
Wer also Onewire und Owfs einsetzt sollte vor der Installation prüfen ob port 2121 schon belegt ist. Eine Fehlermeldung das der Port nicht aufgemacht werden kann ist mir weder im Logfile noch in der Konsole aufgefallen.
Viele Grüße,
TomTom
Zitat von: tomtom am 12 Januar 2015, 22:39:14
Hallo zusammen,
endlich habe ich fronthem auch bei mir am laufen. An dieser Stelle eine große Dankeschön an "herrmannj & Co" für die brillante Arbeit. Wirklich toll.
Bei mir lief vor der Installation von Fronthem noch der OwServer httpd daemon. Der benutzt lustiger weise ebenfalls port 2121.
Das fiel bei einen telnet auf den Port allerdings nicht sofort auf. Erst als ich ein wget auf den port gemacht habe.
Lustigerweise klappt wenn der OwServer http deamin läuft das "update force ..." auf der Konsole ebenfalls nicht. Den Zusammenhang habe ich aber nicht hergestellt.
Wer also Onewire und Owfs einsetzt sollte vor der Installation prüfen ob port 2121 schon belegt ist. Eine Fehlermeldung das der Port nicht aufgemacht werden kann ist mir weder im Logfile noch in der Konsole aufgefallen.
Viele Grüße,
TomTom
Hallo TomTom,
danke - den Fehlermeldung dazu habe noch auf todo.
2121 scheint der Standard Port beim ows zu sein, sollte fronthem evtl umziehen ... ?
vg
jörg
ps, eine option damit man den port anpassen kann kommt ebenfalls noch.
Zitat von: ftobi am 12 Januar 2015, 22:36:13
Hallo Jörg,
sieht erst mal sehr gut aus: habe jetzt zweimal von Safari auf Firefox und wieder zurück gewechselt, fhem läuft weiter und die Daten kommen auch sauber an. Top :)
Grüße
Hi perfekt,
schau mal bitte das Du nicht mit der gleichen ip (gleichzeitig) zwei mal rauf gehst, das wird noch nicht abgefangen (hat aber auch keine ernsten Auswirkungen)
Der Absturz den Du heute morgen hattest entstand in etwas anderer Konstellation:
smartVisu lief und Du hast den Deckel vom NB zu gemacht (danach ca 15-20 min warten). Das wurde in den ersten Versionen von mir nicht richtig ausgewertet und gab den Fehler - soll jetzt beseitigt sein. ( Insgesamt waren die Umstände noch spezieller, daher ist es in der alpha nicht aufgefallen , deswegen teste ich auch gerade noch )
Wer mag - gerne Streßtest (in Bezug auf Verbindung) machen:
NB Deckel zu, mal mit dem Ipad aus dem WLAN raus laufen, wieder ein - flugmodus - das volle Programm. Das hat einfach den Hintergrund das es Umstände gibt an die man (hier ich ...) beim Schreiben nicht denkt - und das Ding soll ja bullet proof laufen.
Danke vg
jörg
Hallo Jörg,
Zitat von: herrmannj am 12 Januar 2015, 23:22:04
Wer mag - gerne Streßtest (in Bezug auf Verbindung) machen:
NB Deckel zu, mal mit dem Ipad aus dem WLAN raus laufen, wieder ein - flugmodus - das volle Programm. Das hat einfach den Hintergrund das es Umstände gibt an die man (hier ich ...) beim Schreiben nicht denkt - und das Ding soll ja bullet proof laufen.
Danke vg
jörg
hab gestern abend die Seite geöffnet gelassen und klassisch den Notebookdeckel zu gemacht.
Heute früh geöffnet, auch auf ein paar andere Zimmer geklickt, es kamen keine Daten mehr (Domotica Error in der oberen rechten Ecke). Nach nem Seitenrefresh (F5) war alles wieder gut.
Grüße
Tobi
Ergänzung: heute abend den Browser geöffnet, da wurden noch die alten Werte angezeigt. Nach Wechsel in einen anderen Raum wurde der Domotica-Fehler angezeigt, kurze Warte-Pause (schätze ca. 2-4 Sekunden), dann waren die Werte aktualisiert und es ging wieder alles einwandfrei.
Auf dem Android-Tablet, das von heute früh bis jetzt nicht angefasst wurde, wurden direkt nach dem Öffnen die richtigen Werte und ohne Domotica-Fehler angezeigt.
Zitat von: herrmannj am 12 Januar 2015, 22:21:02
ja stimmt, die im Modul ist auch nicht aktuell. Das hängt mit dem fhem js update zusammen. Rudi hat den loader aber scheinbar so gefixt das ich den den jquery loader im editor anpassen kann - dann sollte das weg sein.
können wir beide das kurz testen ?
vg
jörg
KÖnen wir gerne machen.
Grüße Jörg
kurz zu den hue: um den on/off zustand zuverlässig zu ermitteln sollte man das onoff oder das pct reading verwenden und nicht state.
in onoff steht 0 oder 1 drin.
in pct 0-100 wobei 0 tatsächlich aus ist.
gruss
andre
@Jörg: Meinst Du ich sollte den genRegExp Converter auf beliebig viele Wertepaare erweitern? Das müssen ja nicht immer 2:2 sein...
Andere Frage: was hältst Du von einem JSONList Converter, dem ich beliebig viele Readings mitgeben kann, damit er die Werte dieser Readings als JSON Liste an SV übergibt? Wäre sicher ganz praktisch für so Dropdown select UI Elemente...
Gesendet von iPhone mit Tapatalk
Zitat von: justme1968 am 13 Januar 2015, 11:53:32
kurz zu den hue: um den on/off zustand zuverlässig zu ermitteln sollte man das onoff oder das pct reading verwenden und nicht state.
in onoff steht 0 oder 1 drin.
in pct 0-100 wobei 0 tatsächlich aus ist.
gruss
andre
Danke Andre, leider hat das in meinen Tests nicht funktioniert, da ich keine Kombination mit onoff hinbekomme, in der ich die Lampe dann auch schalten könnte (anstatt nur den Status anzuzeigen). Vermutlich liegt es daran, dass ja onoff 0 oder 1 will, also connector Direct, aber dann klappt das 'set hue 1' nicht, was ja erst durch connector OnOff zu 'set hue on' wird. Oder verstehe ich etwas grundsätzlich falsch?
danke,
-Christian
Ich hab mir damit geholfen
attr Lampe userReadings status {if(ReadingsVal($name,"onoff",0)==0) {"off"} else {"on"}}
Zitat von: daduke am 13 Januar 2015, 20:34:54
Danke Andre, leider hat das in meinen Tests nicht funktioniert, da ich keine Kombination mit onoff hinbekomme, in der ich die Lampe dann auch schalten könnte (anstatt nur den Status anzuzeigen). Vermutlich liegt es daran, dass ja onoff 0 oder 1 will, also connector Direct, aber dann klappt das 'set hue 1' nicht, was ja erst durch connector OnOff zu 'set hue on' wird. Oder verstehe ich etwas grundsätzlich falsch?
danke,
-Christian
Hi Christian,
bin jetzt nicht Andre aber Andre kann vmtl auch wenig zum converter sagen. Verstehe ich richtig ? : es würde gehen wenn der (ein) converter am "Eingang" (reading/event 'onoff') die 0/1 durch reichen würde, am Ausgang aber die 0/1 von sv in 'off' und 'on' wandeln würde ?
Wenn ja, kein Problem: du könntest Dir dazu die 99_fronthemUtils.pm aus laden und das schnell so reinklöppeln (ungetestet).
Reading ist dann "onoff" / Set ist "hue". Einfügen in die 99... sutdown restart und dann ist der converter als "PhillipsHueOnOff" sichtbar.
vg
jörg
sub PhillipsHueOnOff(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$event = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, '0');
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = $even;
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$param->{result} = ($gadval)?'on':'off';
$param->{results} = [];
return undef;
}
elsif ($param->{cmd} eq '?')
{
return 'usage: AnAus';
}
return undef;
}edith:
sorry martin, überschnitten: Deins ist natürlich kürzer :)
Ihr habt natürlich recht, ABER: am einfachsten ist es, OnOff so umzudrehen, wie ich gestern vorgeschlagen habe, dann muss man nämlich weder einen speziellen Konverter schreiben noch FHEM-intern states umdefinieren. Ich bleibe wohl einfach dabei. Wenn Andres Lösung einfach gegangen wäre, ok, aber so... ???
Gruß,
-Christian
Zitat von: bgewehr am 13 Januar 2015, 12:03:18
@Jörg: Meinst Du ich sollte den genRegExp Converter auf beliebig viele Wertepaare erweitern? Das müssen ja nicht immer 2:2 sein...
Andere Frage: was hältst Du von einem JSONList Converter, dem ich beliebig viele Readings mitgeben kann, damit er die Werte dieser Readings als JSON Liste an SV übergibt? Wäre sicher ganz praktisch für so Dropdown select UI Elemente...
Gesendet von iPhone mit Tapatalk
Hi Bernd,
sorry, bin erst gestern Abend zur uzsu gekommen, mit folgendem Stand:
den JSON weg halte (generell) für falsch weil: JSON ist ja nur der Transportweg - normal (hatte mich auch bei der uzsu schon gewundert) sollten wir mit dem Transport gar nicht dealen.
Wenn wir listen (select, wobei: kennst Du ein widget dazu?) brauchen sollten wir uns direkt Listen vornehmen, was für die Lichtszene via dummy ja auch gut funktioniert. Ansonsten schreib mal bitte den use case, ich schau mal.
USZU (sollgten wir einem extra thread weitermachen):
Da gilt das auch. Man braucht dort keinen Umweg über JSON. Ich habe im Anhang einen leicht modifizierten dummy, der hat den UZSU converter gleich eingebaut. Die Daten kommen auch bei direct im richtigen Format auf einem dummy an (perl hash) - nur der dummy weiß eben nichts damit anzufangen.
In den POC im Anhang wird ein reading Test erzeugt wo einfach der befehl (0,1 / 'on'/'off') und die Zeit verkettet wird - wie gesagt, nur demo.
Die gesamte Logik um tatsächlich zu schalten (im Prinzip ein eingebautes at), die Logik zum speichern auf Platte sowie der Zugang über fhemweb / floorplan etc müssen logischerweise noch. Ich weiß jetzt nicht ob Andre mit liest. Die Daten (hash Dumper) sehen so aus:
$VAR1 = {
'active' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'list' => [
{
'value' => 1,
'time' => '10:00',
'rrule' => 'FREQ=WEEKLY;BYDAY=MO,TU,FR',
'active' => $VAR1->{'active'}
}
]
};
wobei "list" eben beliebig viele, unterschiedliche, Einträge enthalten kann.
Value ist der Schaltbefehl, der ist konfigurierbar und kann auch "on" "off" | "laut" "leise" - whatever sein. Hier würde jetzt Mo, Do, Fr um 10:00 einen "1" anstehen.
Vorschlag:
ich lasse die Daten intern in einem $hash (keine Readings, die können später dazu).
@andre: schau mal bitte ob Du damit, später für das widget, arbeiten kannst. Sonst gern Info.
Speicher: Die Zeiten in die fhem.cfg zu speichern wird mMn schwer weil schnell lange Strukturen zusammenkommen die ich dann in ein reading qeutschen müsste. Ich würde über eine sep Zeitdatei (pro uszu) gehen. Frage: in welches Verzeichnis ?
Zum konkreten Schalten: entweder man gibt der uzsu in der def ein device mit, dann schaltet die direkt mit dem konfigurierten Befehl
- und -
der state der uszu entspricht dem konfigurierten Befehl. Am Beispiel oben würde also am Montag, um 10:00, die fhem uszu auf state 1 gehen - dann kann ich mit notify arbeiten.
Wenn das für alle passt würde ich gegen Ende der Woche damit weitermachen und die Zeitlogik implementieren - dann wäre sie über sv einsatzbereit. Für fhemweb/floorplan bäuchte es das widget oder ein anderes geeignetes Bedienkonzept.
ideen, Anregungen, Vorschläge, Einwände ?
vg
jörg
Zitat von: daduke am 13 Januar 2015, 21:26:11
Ihr habt natürlich recht, ABER: am einfachsten ist es, OnOff so umzudrehen, wie ich gestern vorgeschlagen habe, dann muss man nämlich weder einen speziellen Konverter schreiben noch FHEM-intern states umdefinieren. Ich bleibe wohl einfach dabei. Wenn Andres Lösung einfach gegangen wäre, ok, aber so... ???
Gruß,
-Christian
na klar, gerne. Wir jammern ja auch auf hohem Niveau - die Frage ist immerhin nicht
ob es geht, sondern welche der zahlreichen Möglichkeiten schön ist. Bin sicher es könnte schlimmer kommen 8)
vg
jörg
ein hash mit den schaltzeiten ist kein problem. ein reading (oder auch ein event ohne reading) das es eine änderung gab wäre aber schön
wenn die schaltzeiten nicht in readings stehen (wegen des namens problems) dann muss ich sie auf einem anderen weg holen. das kann ein get sein (muss ich aber dann wieder parsen und aufbereiten bevor ich es weiter verarbeite) oder gleich ein hash in einem dokumentierten format.
ich weiss noch nicht genau ob ich das ganze erst mal auf fhem seite vorbereite und dann ans frontend schicke oder ob ich gleich alles per json ans frontend schicke und dort direkt verwende. ersteres ist einfacher zu debuggen :) bei letzterem lässt sich eventuell mehr von sv wiederverwenden.
ich als 'anwender' fände es schön wenn bei time nicht nur eine feste zeit sondern auch symbolisch etwas relativ zum sonnenauf- und -untergang stehen kann. wenn hier nur die 'fertige' zeit steht kann ich im frontend nicht mehr darstellen das es eigentlich relativ zur sonnenauf- oder -untergang steht.
es gibt in fhem jeweils eine FileRead und FileWrite funktion mit der aus dem modul beliebige daten auf platte (oder in die configDb) geschrieben werden können. das modul kann direkt bei einer änderung speichern oder sich an global:SAVE hängen. als format für dieses file ist frei. man könnte z.b. den obigen hash zum speichern per Data::Dumper serialisieren und beim einlesen per eval wieder deserialisieren. ein beispiel dafür gibt es im LightScene modul (noch ohne FileRead/FileWrite sondern noch direkt mit perl file io).
wie wäre es sich für die möglichkeiten bei der wiederholung mal ical anzuschauen?
gruss
andre
ps: LightScene ist für licht (und andere) szenen besser als dummy :)
apps: ein eigener thread für die uzsu wäre gut.
Zitat von: justme1968 am 13 Januar 2015, 22:11:17
ein hash mit den schaltzeiten ist kein problem. ein reading (oder auch ein event ohne reading) das es eine änderung gab wäre aber schön
check!
Zitat
wenn die schaltzeiten nicht in readings stehen (wegen des namens problems) dann muss ich sie auf einem anderen weg holen. das kann ein get sein (muss ich aber dann wieder parsen und aufbereiten bevor ich es weiter verarbeite) oder gleich ein hash in einem dokumentierten format.
da richte ich mich nach Dir. Ich habe einfach keine gute idee wie ich das in readings abbilde. get und dokumentierter hash geht beides ohne prob - letzteres vmtl charmanter.
Zitat
ich weiss noch nicht genau ob ich das ganze erst mal auf fhem seite vorbereite und dann ans frontend schicke oder ob ich gleich alles per json ans frontend schicke und dort direkt verwende. ersteres ist einfacher zu debuggen :) bei letzterem lässt sich eventuell mehr von sv wiederverwenden.
your choice, auf sv brauchst Du keine Rücksicht zu nehmen, da existiert widget und transport ja ohnehin.
Zitat
ich als 'anwender' fände es schön wenn bei time nicht nur eine feste zeit sondern auch symbolisch etwas relativ zum sonnenauf- und -untergang stehen kann. wenn hier nur die 'fertige' zeit steht kann ich im frontend nicht mehr darstellen das es eigentlich relativ zur sonnenauf- oder -untergang steht.
lass mal im ersten Wurf ohne machen - die Einfachheit ist ja ein charmanter Faktor und die Lösung muss ja nicht jeden erdenklichen Fall erschlagen, sr un ss rüsten wir einfach bei Bedarf nach - oder machen dafür auch was einfaches.
Zitat
es gibt in fhem jeweils eine FileRead und FileWrite funktion mit der aus dem modul beliebige daten auf platte (oder in die configDb) geschrieben werden können. das modul kann direkt bei einer änderung speichern oder sich an global:SAVE hängen. als format für dieses file ist frei. man könnte z.b. den obigen hash zum speichern per Data::Dumper serialisieren und beim einlesen per eval wieder deserialisieren. ein beispiel dafür gibt es im LightScene modul (noch ohne FileRead/FileWrite sondern noch direkt mit perl file io).
wie wäre es sich für die möglichkeiten bei der wiederholung mal ical anzuschauen?
cool, kannte ich nicht. Schau ich mir an, hab nämlich auch schon darüber nachgedacht wie cfg-db user das mit der fronthem cfg machen - da passt das zusätzlich.
vg
jörg
Zitat
ps: LightScene ist für licht (und andere) szenen besser als dummy :)
I know - für mich (individuell) fahre ich mich dem dummy gut weil der (bei mir) mit automatiken, presence und co verknüpft ist.
Zitat
apps: ein eigener thread für die uzsu wäre gut.
yupp, bleiben wir in frontends damit ?
mit Sicherheit wurde die Frage in dem 55 Seiten langen Thread schon gestellt, aber an welcher Stelle kann ich denn aktiv etwas editieren? Wo finde ich diese GAD`s :-[
Ich habe auf meine mac mini
- einen Apache installiert, dort wie im wiki beschrieben Smartvisu installiert, welches auch mit der korrekten Startseite erscheint.
- Die notwendigen Perl Module installiert
- fronthem per update force installiert
- fronthem definiert STATE ???
- fronthemDevice für ein iPad und ein MBP definiert
Gehe ich mit den Clients auf http://server/smartvisu/index.php wird in FHEM auch brav connected bei den Clients angezeigt
Aber an welcher Stelle kann ich jetzt Dinge mit einem Editor bearbeiten?
Eine config.ini habe ich z.B. nach meiner Installation nicht im Hauptverzeichnis von sv gefunden, dass manuelle anlegen und füllen mit Angaben, welche ich am Anfang des Threads gefunden habe:
[clients]
10.0.81.254 = 'iPad'
10.0.81.248 = 'mbp'
[client:iPad]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
[client:mbp]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
hat keinen Effekt auf den Eingangsbildschirm den meine Clients beim verbinden mit sv haben. (dort wird weiterhin ein Demo Haus angezeigt)
Greetz
Eldrik
Zum Thema UZSU: ich habe Deinen Vorschlag umgesetzt, Jörg, aber SV kann damit zwar erfolgreich die Daten an fhem schreiben, aber nicht wieder lesen, beim zweiten Aufruf ist die UZSU wieder leer! Ist das bei Dir auch so?
Gesendet von iPhone mit Tapatalk
Hallo Bernd,
ja, nur demo wegen converter - das ist in der demo one way.
vg
jörg
Zitat von: eldrik am 13 Januar 2015, 23:15:35
mit Sicherheit wurde die Frage in dem 55 Seiten langen Thread schon gestellt, aber an welcher Stelle kann ich denn aktiv etwas editieren? Wo finde ich diese GAD`s :-[
Ich habe auf meine mac mini
- einen Apache installiert, dort wie im wiki beschrieben Smartvisu installiert, welches auch mit der korrekten Startseite erscheint.
- Die notwendigen Perl Module installiert
- fronthem per update force installiert
- fronthem definiert STATE ???
- fronthemDevice für ein iPad und ein MBP definiert
Gehe ich mit den Clients auf http://server/smartvisu/index.php wird in FHEM auch brav connected bei den Clients angezeigt
Aber an welcher Stelle kann ich jetzt Dinge mit einem Editor bearbeiten?
Eine config.ini habe ich z.B. nach meiner Installation nicht im Hauptverzeichnis von sv gefunden, dass manuelle anlegen und füllen mit Angaben, welche ich am Anfang des Threads gefunden habe:
[clients]
10.0.81.254 = 'iPad'
10.0.81.248 = 'mbp'
[client:iPad]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
[client:mbp]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
hat keinen Effekt auf den Eingangsbildschirm den meine Clients beim verbinden mit sv haben. (dort wird weiterhin ein Demo Haus angezeigt)
Greetz
Eldrik
Hallo,
einfach auf das jeweilige fronthemDevice in FHEM klicken, dann werden oben, sofern in SmartVisu definiert die GADs angezeigt.
viele Grüße
Alexander
Hallo Alexander,
danke für die Rückmeldung!
Ich habe heute noch ein paar Tests durchgeführt, was aufgefallen ist, als ich gestern um 23:30 die Augen geschlossen habe hat sich Fhem um ca. 01:14 ohne Meldung im Log weggehangen, so dass ich es heute früh erst einmal wieder starten musste und alle Definitionen fronthem betreffend sicherheitshalber entfernt habe.
Als ich wieder aktiv vor einem Rechner saß habe ich wieder die Definitionen vorgenommen und weiter mit fronthem experimentiert, Fhem hat sich dann noch einmal ohne Meldung im Log beendet!
Daraufhin habe ich Fhem via update aktualisiert (hatte ich die Tage bewusst nicht gemacht wegen der vielen gemeldeten Fehler, im Zusammenhang, mit dem JS Umbau).
Nach dem Update waren in den fronthemDevice Einträgen auch erstmalig oben die Tabelle mit:
gad device r w
zu sehen.
Ferner habe ich mir nun die smartvisu pages von bgewehr aus dem github geladen und erfolgreich gads aufgelistet bekommen, mit denen ich jetzt auch erfolgreich testen konnte :)
Ich hoffe, dass Fhem nach dem letzten Update auch stabil läuft und nicht im Zusammenhang mit fronthem abschmiert.
Greetz
Eldrik
Ich hatte leider mir der aktuellen fronthem Version (update force) gestern wieder einen kommentarlosen Absturz von FHEM. Szenario war Aktualisierung der SmartVisu Seite im Chrome. Etwa die Hälfte der gads wurden geladen, der Rest nicht. Also ist FHEM während des Ladens der Seite abeschmiert. Kein anderes Device außer dem Laptop im LAN war zu der zeit mit Fronthem verbunden, es war also kein Standby oder Flugmodus Problem.
Hallo,
ich habe auch grade den Steuerungsrechner ohne fhem-Prozess gefunden.
Letzte bekannte Aktion zu der Uhrzeit war, dass meine Frau mit Ihrem Handy (Android mit Chrome, als device mit connect) ungefähr zu der Uhrzeit das Haus verlassen hat.
Letzter relevanter Eintrag im fhem.log:
2015.01.14 08:30:45 1: gui: thread ws closed for unknown reason
Im access.log von apache2 hab ich den letzten Zugriff allerdings schon um 08:08:53 Uhr. error.log ist nichts drin
Grüße
Tja, und ich dachte ich könnte mich wieder hinlegen ...
Zur Sicherheit: bei allen aktuelle Version (fhwebsocket)? (Gleiche Größe wie im git? Wichtig, weil ich hatte diesbezüglich was gefixt). Bitte schaut mal im fhem Verzeichnisse ob in der Frontem.err was drinsteht.
Vg
Jörg
Hallo Jörg,
fronthem.err:
send: Cannot determine peer address at /opt/fhem/FHEM/01_fronthem.pm line 674.
Die hat aber ein File-Datum Jan 12 21:31, also anderer Zeitpunkt.
Hatte aber die letzten Änderungen in fhmwebsocket.pm nicht drin (die Klammer in Zeile 159 aus dem letzten change). Hab geupdatet und neu gestartet.
Grüße
Hallo zusammen,
habe heute mal wieder das Update von fronthem über
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
durchgeführt, jedoch werden mir meine GADs in FHEM nicht mehr angezeigt, in den Dateien sind sie jedoch noch vorhanden und das Schalten über sv von Aktoren und das Anzeigen von Werten aus FHEM klappt soweit noch einwandfrei.
Nur kann ich so leider auf den GAD-Editor zugreifen um neue Devices anzulegen, bzw. zu bearbeiten.
viele Grüße
Alexander
EDIT: Sorry, hat sich erledigt, hatte vergessen ein FHEM-Update durchzuführen :-X
Zitat von: herrmannj am 14 Januar 2015, 18:57:21
Tja, und ich dachte ich könnte mich wieder hinlegen ...
Zur Sicherheit: bei allen aktuelle Version (fhwebsocket)? (Gleiche Größe wie im git? Wichtig, weil ich hatte diesbezüglich was gefixt). Bitte schaut mal im fhem Verzeichnisse ob in der Frontem.err was drinsteht.
Vg
Jörg
Selbe größe, selbe Version. Die err Datei ist leer, deshalb "Kommentarlos" ;) Sorry, mehr Anhaltspunkte kann ich nicht geben, werde das aber weiter beobachten.
Hallo Jörg,
folgendes kann ich jetzt reproduzieren:
- smartVisu Oberfläche reagiert normal und aktualisiert die Werte.
- Bei geöffnetem Firefox Notebookdeckel zu, 30 Minuten warten. Dann wieder öffnen.
- Ab hier "Could not connect to DomotiGa server!". Keine Daten mehr. Reload der Seite per F5 geht auch nicht.
Meldung im fhem-log:
2015.01.14 22:07:07 1: gui: thread ws closed for unknown reason
Sonst keine fehler, auch nicht im fronthem.err. fhem isoliert läuft und reagiert, aber es gibt einen fhem-thread weniger.
voher: linaro@cubietruck:~$ ps -ax | grep fhem
3412 pts/0 S 0:32 perl fhem.pl fhem.cfg
3423 ? Ss 0:01 perl fhem.pl fhem.cfg
3823 pts/0 S+ 0:00 grep --color=auto fhem
nachher:linaro@cubietruck:~$ ps -ax | grep fhem
3412 pts/0 S 0:49 perl fhem.pl fhem.cfg
4394 pts/0 S+ 0:00 grep --color=auto fhem
Mehr hab ich nicht finden können, hoffe es hilft.
Grüße
Tobi
Hallo
und vielen Dank für die guten Berichte. Bin unterwegs gewesen und komme erst jetzt zur ausführlicheren Antwort.
Der Komplettausstieg von fhem ist bedauerlich (sorry!) - aber kein Mysterium. Der Websocket läuft in einem thread und an der Stelle im Haupt modul wo, nach einem Fehler, erst aufgeräumt werden soll und der ws danach neu gestartet steht aktuell nur "#TODO". In der alpha gab es keine Probleme mit dem ws und daher auch keine Prio das sofort einzubauen. Diesen Block baue ich morgen ein. Damit braucht auch keine Angst zu bestehen das der ws das komplette System mit nimmt.
Teil zwei kann ich anhand der Beschreibung recht sicher im writepuffer verorten. Dafür war das letzte update. Den Test mit Deckel zu, 30min warten, wieder auf habe ich in dem Zusammenhang mehrfach fehlerfrei durchgeführt. Das bedeutet nun das es Sondersituationen (System oder Timing) gibt wo das nicht vollständig greift.
Da mir klar ist WAS passiert werde ich das WARUM auch zeitnah finden. Nochmal Danke für die reports - damit kann ich gut arbeiten. Viel mehr könnt ihr von nicht machen, höchsten ein Auge auf fronthem.err haben, falls noch weitere Meldungen auflaufen.
vg
jörg
Hi,
heute ist fhem wieder stehen geblieben, letzte Meldungen im Log:
2015.01.15 14:18:22.080 5: ipc fronthem:127.0.0.1:49275 (ws): receive {"log":{"cmd":"log","level":4,"text":"ws send to client{\"items\":[\"VZ.strom.aktuell\",\"677.5\"],\"cmd\":\"item\"}"}}
2015.01.15 14:18:22.081 4: ipc fronthem:127.0.0.1:49275 (ws): ws send to client{"items":["VZ.strom.aktuell","677.5"],"cmd":"item"}
Es wurde auch nichts in fronthem.err und .out
Ich war zu dem Zeitpunkt nicht aktiv an dem System, der Browser mit sv war auf einem Client im Hintergrund geöffnet.
Greetz
Eldrik
super - Danke.
Ich habe den Fehler mittlerweile auch eindeutig identifizieren können - keine Magie, keine Esoterik - ich habe einen Fehler in der Umsetzung der Puffer Logik. Das update folgt asap.
Danke und viele Grüße
Jörg
Das klingt sehr gut! Dann mache ich auch noch mal den Stabilitätstest :D
schöne Grüße
Jo
ja gern - ich hab noch noch nichts commited. vg jörg
Hallo,
ich habe einen eigenen Kalenderserver installiert (DaviCal), den ich für meine Termine nutze. Damit ich diese auch
in sv darstellen kann habe ich basiernd auf der google.php eine Lösung gebaut, mit der man das ical-Format parsen
und darstellen kann.
Für die Ermittlung der zukünftigen Termine habe ich eine fertige Lösung gefunden, die sehr gut funktioniert und einiges
an Umfang bietet. Vielleicht, kann man damit später auch noch einen Kalendereditor bauen....
Diese kann hier http://kigkonsult.se/iCalcreator/index.php (http://kigkonsult.se/iCalcreator/index.php) herunterladen. Die im Paket befindliche
Datei iCalcreator.class.php kann unter einem beliebigen Pfad abgelegt werden, der aber in der ical.php
eingetragen werden muss.
Die ical.php muss in das Verzeichnis /smartVISU/lib/calendar/service und die Datei widget_ical.html in das
Homeverzeichnis der eigenen Seite abgespeichert werden z.b. /smartVISU/pages/fhem
Eingebunden wird das ganze dann so:
{% import "widget_ical.html" as calendar %}
{{ calendar.list('calendarlist', 'Abfalltermine', 6, 21) }}
Die erste Zahl (6) ist die Anzahl der Termine die aufgelistet werden. Die zweite Zahl (21) ist die Anzahl der Tage, die
im Kalender in die Zukunft geprüft wird, ob sich ein Termin wiederholt.
Das ganze funktioniert auch mit einem freigegebenen Googlekalender. Man nimmt dann den Pfad zur ics-Datei. Da gibt es einen
Button für auf der Freigabeseite des Kalenders.
Die Farben habe ich in der Beschreibung des jeweiligen Termins abgelegt. Wenn dort nichts, oder etwas anderes eingetragen
enthalten ist, wird die Standardfarbe verwendet.
Falls jemand ein php-Experte ist und ein syntaktisches Nogo findet, wäre ich für einen Hinweis dankbar. Ist mein erstes
php-Script 8)
Gruß Norbert
danke redlav funktioniert auf Anhieb mit meinem Caldav Yosemite OS X Server.
Greetz
Eldrik
Hallo eldrik,
kannst Du mir beschreiben wie Du Deinen CalDav vom OSX-Server eingebunden hast.
stehe anscheinend auf dem Schlauch...
Greetings
RockSteadyBeat
Hallo,
ich habe ein Problem mit dem Design von bgewehr. In der Tabelle ist die Ausrichtung der Zeilen so verschoben, daß die Hälfte der Zeilen nicht zu lesen sind (siehe Anhang). Browser Firefox 34.0
Liebe Grüße,
Thomas
RockSteadyBeat beschreib mal was du bisher gemacht hast und wie deine URL für den Zugriff aussieht!
Greetz
Eldrik
Hallo Ihr Lieben,
ich habe ein kleines Problem. Habe alles eingerichtet, damit fronthem laufen kann. Fronthem in FHEM eingebunden (state ??? - stimmt das so?) und ein Device (Mac) definiert.
Nun steht auch, wie im Anhang gesehen, der Mac auf connected - nur wie füge ich jetzt befehle (Leselampe ist in smartvisu schon "definiert") hinzu?
Ich kann über dem "Mac" Device nichts auswählen, das Feld ist einfach leer.
Danke!
Olli
Hallo Eldrik
genau da liegt mein Problem ich versteh nicht welchen Pfad für die .ics eines Accounts nehmen soll.
Sorry Newbie@OS-X-Server...
Hab schon gesucht unter /Library/Server/Calender and Contacts/ finde aber keine .ics etc.
Greetz
RockSteadyBeat
Schau mal hier
http://forum.fhem.de/index.php/topic,18797.msg242958.html#msg242958 (http://forum.fhem.de/index.php/topic,18797.msg242958.html#msg242958)
und hier ist u.a erklärt wie man die Url auf einem Mac findet
https://finallysolved.wordpress.com/2012/04/30/so-bekommt-man-den-icloud-kalendar-in-thunderbird-lightning-unter-windows-integriert/ (https://finallysolved.wordpress.com/2012/04/30/so-bekommt-man-den-icloud-kalendar-in-thunderbird-lightning-unter-windows-integriert/)
die Url kann man alternativ auch über den Browser herausfinden.
Greetz
Eldrik
Danke Eldrik,
war echt mühsam die Kalender-ID heraus zu bekommen... :'(
Hat aber gefunzt nach dem ich die User-ID hatte...
Terminal: dscl /LDAPv3/127.0.0.1 -list /Users GeneratedUID für die User-ID
dann
https://server.example:8443/calendars/__uids__/57C3D125-39CF-48B4-8A22-A7E198D2764A/
danach Kalender-ID "aussuchen" und in "Properties" den gesuchten {DAV:}displayname finden... ::)
Voila dann hat man die Kalender-ID... :o
Nochmal vielen Dank an Dich Eldrik!!! :)
Greetz
RockSteadyBeat
Zitat von: olli84 am 16 Januar 2015, 18:46:41
Hallo Ihr Lieben,
ich habe ein kleines Problem. Habe alles eingerichtet, damit fronthem laufen kann. Fronthem in FHEM eingebunden (state ??? - stimmt das so?) und ein Device (Mac) definiert.
Nun steht auch, wie im Anhang gesehen, der Mac auf connected - nur wie füge ich jetzt befehle (Leselampe ist in smartvisu schon "definiert") hinzu?
Ich kann über dem "Mac" Device nichts auswählen, das Feld ist einfach leer.
Danke!
Olli
Hi
Das ist ein jquery Problem. Fhem aktuell ? Rudi hat den js lader umgebaut
Vg
Jörg
Zitat von: T.ihmann am 16 Januar 2015, 16:56:30
ich habe ein Problem mit dem Design von bgewehr. In der Tabelle ist die Ausrichtung der Zeilen so verschoben, daß die Hälfte der Zeilen nicht zu lesen sind (siehe Anhang). Browser Firefox 34.0
Thomas
Ich teste nicht mit Firefox. Wie sieht es bei Dir in Chrome aus?
Gesendet von iPhone mit Tapatalk
Hallo.
Ich habe mal weiter gemacht in smartVISU. Die ersten Steckdosen funktionieren und ein FHT zeigt schon mal mit dem Standard RTR eine Temperatur an. Jetzt wollte ich einen FS20 Dimmer einrichten. Als Schalter funktioniert er auch schon mal. Aber als Dimmer bekomme ich ihn nicht hin. Als Reading gib es ja bei diesem Dimmer nur state. Aber was nehme ich für den converter und das cmd set? Aber ich schon alles mögliche probiert nur dimmen will er nicht. Nur schalten über einen Schalter funktioniert. Habt ihr einen Tipp für mich?
Dirk
Zitat von: bgewehr am 16 Januar 2015, 22:09:53
Ich teste nicht mit Firefox. Wie sieht es bei Dir in Chrome aus?
Gesendet von iPhone mit Tapatalk
Chrome funktioniert. Da sieht das Design richtig aus. Woran kann das liegen?
Zitat von: herrmannj am 16 Januar 2015, 21:20:15
Hi
Das ist ein jquery Problem. Fhem aktuell ? Rudi hat den js lader umgebaut
Vg
Jörg
Jörg,
danke. Und entschuldige, dass ich das nicht mal selbst probiert hab. :-[
Zitat von: T.ihmann am 16 Januar 2015, 23:20:14
Chrome funktioniert. Da sieht das Design richtig aus. Woran kann das liegen?
Jeder Browser rendert anders!
Für alle Browser zu optimieren ist immer sehr viel Arbeit!
Die Styles in der visu.css scheinen also wohl nicht für Firefox zu stimmen, aber da kann ich Dir auch nicht helfen, ich teste mit Safari, Chrome und IE, das muss reichen! Wenn Du was rausbekommst, lass es mich bitte wissen!
Gesendet von iPhone mit Tapatalk
Zitat von: dlehmann69 am 16 Januar 2015, 22:50:41
Hallo.
Ich habe mal weiter gemacht in smartVISU. Die ersten Steckdosen funktionieren und ein FHT zeigt schon mal mit dem Standard RTR eine Temperatur an. Jetzt wollte ich einen FS20 Dimmer einrichten. Als Schalter funktioniert er auch schon mal. Aber als Dimmer bekomme ich ihn nicht hin. Als Reading gib es ja bei diesem Dimmer nur state. Aber was nehme ich für den converter und das cmd set? Aber ich schon alles mögliche probiert nur dimmen will er nicht. Nur schalten über einen Schalter funktioniert. Habt ihr einen Tipp für mich?
Dirk
Hallo Dirk,
fs20 dimmer braucht ein eigenen converter - kommt noch.
vg
jörg
Zitat von: bgewehr am 16 Januar 2015, 23:59:33
Die Styles in der visu.css scheinen also wohl nicht für Firefox zu stimmen, aber da kann ich Dir auch nicht helfen, ich teste mit Safari, Chrome und IE, das muss reichen! Wenn Du was rausbekommst, lass es mich bitte wissen!
OK versuche es. Bin allerdings kein css Experte. Hast Du einen Tipp wo ich in der visu.css schauen muss? Wo ist das Layout für die Tabellen codiert?
Hallo zusammen,
als ich heute nach noch etwas wach lag, kam mir auf einmal eine Idee, die mir in meinem sv im Moment fehlt.
Ich habe bei mir im Erdgeschoss einen Touchscreen hängen, mit dem wir FHEM (inzwischen viel mit SmartVisu ;)) steuern können. Da dieser Touchscreen samt zugehörigen mini PC sowieso immer läuft, wäre es schön, dass wenn jemand vor der Haustür klingelt, dass dann dort ein Popup aufgeht mit dem Bild der vor der Haustür installierten IP-Cam. Hardwaretechnisch stelle ich es mir so vor, dass ich an dem Klingelknopf eine HomeMatic Tasterschnittstelle installiere, diese Sendet dann an FHEM (entweder short oder Long, wobei man ja long oder short ignorieren kann, indem man das ohne in FHEM definiert). Jedoch müsste ich sv dazu bekommen, wenn in FHEM dies empfangen wird, dass es dann dieses Popup öffnet (Popup ist im Demohaus Otterstaetter enthalten).
Hat jemand von euch eine Idee, ob es zum jetzigen Zeitpunkt so schon in sv mit Fronthem umgesetzt werden kann und wie ich sv dazu bekomme dieses Popup zu öffnen?
viele Grüße
Alexander
Zitat von: T.ihmann am 17 Januar 2015, 12:30:21
OK versuche es. Bin allerdings kein css Experte. Hast Du einen Tipp wo ich in der visu.css schauen muss? Wo ist das Layout für die Tabellen codiert?
Such nach nw_tiles!
... Und li_aside...
Gesendet von iPhone mit Tapatalk
Zitat von: avg123-de am 17 Januar 2015, 14:07:04
Hallo zusammen,
als ich heute nach noch etwas wach lag, kam mir auf einmal eine Idee, die mir in meinem sv im Moment fehlt.
Ich habe bei mir im Erdgeschoss einen Touchscreen hängen, mit dem wir FHEM (inzwischen viel mit SmartVisu;)) steuern können. Da dieser Touchscreen samt zugehörigen mini PC sowieso immer läuft, wäre es schön, dass wenn jemand vor der Haustür klingelt, dass dann dort ein Popup aufgeht mit dem Bild der vor der Haustür installierten IP-Cam. Hardwaretechnisch stelle ich es mir so vor, dass ich an dem Klingelknopf eine HomeMatic Tasterschnittstelle installiere, diese Sendet dann an FHEM (entweder short oder Long, wobei man ja long oder short ignorieren kann, indem man das ohne in FHEM definiert). Jedoch müsste ich sv dazu bekommen, wenn in FHEM dies empfangen wird, dass es dann dieses Popup öffnet (Popup ist im Demohaus Otterstaetter enthalten).
Hat jemand von euch eine Idee, ob es zum jetzigen Zeitpunkt so schon in sv mit Fronthem umgesetzt werden kann und wie ich sv dazu bekomme dieses Popup zu öffnen?
viele Grüße
Alexander
Hi,
hab ich ähnlich vor (Kamera im Garten, nachts, bei Bewegung).
popups sind generell im design enthalten. Darunter liegt ja jquery mobile. Vmtl kann man also mit open und close direkt auf dem popup arbeiten. Du musst sicher ein widget drum herum bauen.
Bzgl Kamerabild auf Screen, da hängt es davon ab ob h264 oder mjpeg (oder nur jpg). Die Format muss vom browser unterstützt werden, jgp (1 pro sekunde) geht immer.
vg
jörg
Hallo
Das mit dem Popup hab ich mir auch schon überlegt.
Meine Idee war bei einem Telefonanruf ein Popup mit dem Anrufer und Nummer.
vg
Florian
Hi,
ich habe mal über ein basic.textrepl() widget einige der falschen Umlaute zurückgeholt, die großen gingen nicht, also nur äöü. Bei mir reicht das, was ja aber Zufall ist.
Findet ihr in basic.html und widget.js bei mir im GIT.
Gesendet von iPhone mit Tapatalk
Hallo,
habe nun auch alles zum laufen bekommen. Lichter usw. kann man schon wunderbar schalten.
Nachdem ich Bernds GIT mit dem homematic widget entdeckt hatte musste ich das, aufgrund meiner zahllosen hm cc rt dn, einbauen.
Leider scheint das ganze etwas "verschoben" zu sein (siehe Anhang)
Meine config für den Raum:
{% extends "rooms.html" %}
{% import "widget_homematic.html" as homematic %}
{% block content %}
<h1><img class="icon" src='{{ icon0 }}scene_office.png'/>Arbeitszimmer</h1>
<div class="preblock">
</div>
<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>Heizung</h3>
<table width="90%">
<tr>
<td align="left" width="100px"> {{ homematic.hmtc('HMRT_DG', 'mode', 'DG_rtr_act', 'DG_rtr_set', 'DG_rtr_controlmode', 'DG_rtr_daytemp', 'DG_rtr_nighttemp', 'DG.fenster', 'DG_rtr_battery', 'DG_rtr_state', 'DG_rtr_text') }}
</td>
</tr>
</table>
</div>
</div>
</div>
{% endblock %}
Die Batterieanzeige funktioniert nicht, obwohl korrekt definiert.
Danke für eure Hilfe!
Olli
P.S.: Das gar nichts angezeigt wird ist soweit okay, der PC hier ist noch nicht "freigeschalten" :)
Ohje, vielleicht hätte ich auch mal die width ordentlich einstellen sollen. :D
Jetzt passts!
- bis auf die Batterieanzeige.
Hab den HM-CC-RT-DN, die "Mutter" des Devices und dort batteryLevel genommen - da steht in FHEM 2.9
Danke!
Hi Olli,
wegen der batterie: ich denke mal das Bernd den shifter verwendet. Der ist im original sv buggy. Schau mal in seiner widget.js, da ist ein fix drin.
vg
jörg
Hallo @all:
hier ist das update zum writebuffer und zum Verbindungsmanagement.
update all https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
- oder -
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
Wer mag, bitte Härtetests, ich habe alle mir zugänglichen Sondersituationen getestet und kann auch mit Macht keine Fehlfunktion provozieren.
vg
jörg
Batterie funktioniert auch mit Bernds Hack nicht wirklich zufriedenstellend. Irgendwo hier im Thread steht, wie man mit einem Userreading relative Batteriewerte erhält. Das funktioniert einwandfrei.
Vielen Dank dafür! Mein fhem ist die Nacht einfach so abgeschmiert, was ziemlich wahrscheinlich mit SV zu tun hat. Werde jetzt die aktualisierte Version mal Härte-testen :D
[Nachtrag]
Folgendes hatte ich im log-file:
2015.01.18 04:45:01.414 1: fronthem: thread ws closed for unknown reason
2015.01.18 04:56:27 1: called
2015.01.18 04:56:28.013 1: Including fhem.cfg
Habe einen watchdog laufen, der nach 700 s den Rechner neu startet, sollte fhem keinen Mucks mehr von sich geben. Der ist hier wohl angesprungen, nachdem diese fronthem-Meldung kam. Wohlgemerkt nicht mit dem letzten update.
schöne Grüße
Jo
Hmm ich hatte meine fronthem Definition vor 2 Tagen, wegen der häufigen Fhem Abstürze, löschen müssen und nach dem heutigen update force wieder definiert, leider werden mir nun keine gads mehr angezeigt und die vormals vorhandenen Werte in der smartvisu bleiben leer :'(
Greetz
Eldrik
Zitat von: eldrik am 18 Januar 2015, 10:07:22
Hmm ich hatte meine fronthem Definition vor 2 Tagen, wegen der häufigen Fhem Abstürze, löschen müssen und nach dem heutigen update force wieder definiert, leider werden mir nun keine gads mehr angezeigt und die vormals vorhandenen Werte in der smartvisu bleiben leer :'(
Greetz
Eldrik
Hallo,
hast du von FHEM auch ein Update gemacht, das hatte ich auch mal vergessen und hatte dann das selbe Problem. Nach dem Update hatte jedoch alles wieder geklappt.
viele Grüße
Alexander
Zitat von: olli84 am 18 Januar 2015, 00:53:25
Leider scheint das ganze etwas "verschoben" zu sein
<td align="left"
Die Batterieanzeige funktioniert nicht
Olli
Align left bedeutet linksbündig! Du musst das rausnehmen.
Bei Deinem HM Gerät ist evtl. die Batteriespannung nicht direkt als Reading verfügbar. Dann geht die Batterieanzeige auch so nicht. Ein Workaround ist hier im Forum mit einem Userreading veröffentlicht worden.
Außerdem muss der SV basic.switcher gepatcht werden, er übernimmt min und max nicht richtig. Schau Dir die basic.html in meinem Git unter widgets an.
Viel Spaß!
Gesendet von iPhone mit Tapatalk
die gads sind nach einem Update und weiteren shutdown restart wieder da, nur die vorher hinterlegten, Devices, Converter etc. sind weg!
Gibt es keine Möglichkeit diese zu speichern, oder gehen die immer beim löschen der fronthem Definition verloren?
Greetz
Eldrik
@Jörg: Ich habe heute nochmal das Update mit dem Update Force Befehl versucht, bei mir bleibt es bei "...nothing to do!"
Also habe ich das Git geklont und die Dateien manuell ausgetauscht - das lief sofort und bis jetzt ohne Probleme!
Vielen Dank dafür!
Gesendet von iPhone mit Tapatalk
Zitat von: eldrik am 18 Januar 2015, 11:06:28
Gibt es keine Möglichkeit diese zu speichern, oder gehen die immer beim löschen der fronthem Definition verloren?
Hi,
die bleiben bestehen.
Die config für gad/device/converter liegt unter www/fronthem/server... dort kann (soll) man die auch sichern. Wenn Du ein fronthem device löschst bleibt die config auf platte und wird wieder verwendet wenn Du das device neu anlegst. Wichtig: der Name muss stimmen.
vg
jörg
Zitat von: bgewehr am 18 Januar 2015, 11:25:04
@Jörg: Ich habe heute nochmal das Update mit dem Update Force Befehl versucht, bei mir bleibt es bei "...nothing to do!"
Also habe ich das Git geklont und die Dateien manuell ausgetauscht - das lief sofort und bis jetzt ohne Probleme!
Vielen Dank dafür!
Gesendet von iPhone mit Tapatalk
Komisch. Schau mal unter fhem/FHEM/.. da muss eine Datei controls_fronthem.txt liegen. Die ist die basis für das update (diese Datei wird mit der neuen abgeglichen)
vg
Jörg
Da ich bisher immer manuell installiert hatte, war die Datei nicht da. Ich habe sie jetzt dorthin kopiert und die fhconverter Zeile mit # auskommentiert, passt das? Ich möchte meine neuen Converter nicht verlieren...
Gesendet von iPhone mit Tapatalk
Logisch. Wenn Du willst kannst Du die eigenen converter ja in die 99_... verschieben, die ist update-sicher. Dann brauchst Du nicht jedes mal zu patchen.
Ich nehme mir als nächstes mal den Bereich rename/modify und co sowie die converter vor.
Bei rename geht es darum das die fronthem (Mutter/Device) gegenseitig mitbekommen wenn sie "renamed" werden und darum das fronthem die GAD Cfg gleich anpasst wenn ein fhem device umbenannt wird.
Bei den convertern nehme ich mir die fehlenden vor (FS20, die aus Deinem GIT, plus x?). Außerdem baue ich den Ausgang (Richtung fhem) so um das man Befehle wie "set device kommando $result option" verwenden kann.
vg
jörg
Edit
Zitatund die fhconverter Zeile mit # auskommentiert, passt das?
axo. Vmtl niicht - der update Mechanismus ist der fhem eigene - ich denke der überschreibt das dann.
Hallo Jörg,
FHEM ist mir gerade mit dieser Meldung abgeschmiert:
Not an ARRAY reference at ./FHEM/01_fronthem.pm line 314.
Hab heute früh ein Update gemacht, sollte also die aktuelle Version betreffen.
Grüße
Hi,
wie war die Ausgangssituation, sprich: wie ist das entstanden ?
Danke
jörg
Hi Jörg, ich bin etwas erschrocken über die Darstellung der Devices und Readings im fronthem Editor. In Chrome erscheinen die bei mir als UL Listenpunkte in blau ohne Hintergrund teilweise unlesbar ... Liegt das an mir?
Gesendet von iPhone mit Tapatalk
ich lass das auf ff laufen. Im Modul wird nur der kein css definiert, wird alles aus dem standard genommen. Wenn sich da was geändert hat liegt das an aktuellen fhem updates. Ging das denn früher ?
vg
jörg
Ja, vorher sah das hübsch aus wie ein Dropdown!
Gesendet von iPhone mit Tapatalk
na super. Mach mal bitte ctrl-f5 (cache). Wenn das dann immer noch ist - schau mal bitte wie das mit anderem style aussieht. (wird gehen). Welchen style nimmst Du denn ?
vg
Jörg
Auch auf dem iPhone kein schönes Ergebnis...
Gesendet von iPhone mit Tapatalk
Zitat von: herrmannj am 18 Januar 2015, 12:51:17
Hi,
wie war die Ausgangssituation, sprich: wie ist das entstanden ?
Danke
jörg
Kann ich nicht genau sagen aber habe das MacBook gerade nicht genutzt (Bildschirm dunkel) und anschließend bemerkt das nichts mehr geht. Ich erweitere aber gerade das visu vielleicht liegts irgendwo daran.
Style ist wohl egal...
Gesendet von iPhone mit Tapatalk
@fhainz
schau mal bitte im log nach (und wenn da nichts ist) sowie fhem/fronthem.err.
Fehler fixe ist gleich, sehe ich. Ganz besonders interessiert mich bei Dir (wegen mac) aber WARUM der Teil aufgerufen wird
vg
jörg
Zitat von: bgewehr am 18 Januar 2015, 13:08:48
Style ist wohl egal...
Am device und am editor habe ich nichts geändert (bis auf das laden von jquery). Dein fhem ist tagesaktuell ?
Von gestern...
Gesendet von iPhone mit Tapatalk
Zitat von: herrmannj am 18 Januar 2015, 13:12:44
schau mal bitte im log nach (und wenn da nichts ist) sowie fhem/fronthem.err.
die datei ist leer und im log nichts zu finden. ich hatte fronthem auf verbose 0 (warum auch immer) hab das jetzt gelöscht, sry.
edit: @bernd
sicher Dir mal Deine converter und mach mal das update force <git>...
Wenn du suchen möchtest schau vorher mal in der browser console. Da wirst Du was finden.
Zitat von: fhainz am 18 Januar 2015, 13:17:20
die datei ist leer und im log nichts zu finden. ich hatte fronthem auf verbose 0 (warum auch immer) hab das jetzt gelöscht, sry.
na denne, ich fix das geich und sag bescheid, ist nichts wildes.
danke. mach ich!
Zitat von: fhainz am 18 Januar 2015, 13:20:48
danke. mach ich!
(Du? das mit der console war für für bernd ... :) )
Danke @fhainz, fix ist eingecheckt.
ich habe den fix von eben gerade mit "update all git..." auf mein prooduktives gezogen, das hat einwandfrei funktioniert. Er hat sich nur die geänderte 01_fronthem gezogen. Allerdings sagt fhem dann nicht "bitte shutdown restart" - das muss man einfach wissen (und machen).
Ne, Kommando zurück, das funktioniert nur mit force vernünftig.
vg
jörg
2015.01.18 13:55:44 1: UPD FHEM/01_fronthem.pm
Hallo Jörg,
das letzte Update läuft schon richtig gut, vielen vielen Dank :)
Feedback:
direkt im ersten Clientstandby nach dem update heute früh hat sich fhem einmal komplett verabschiedet (vorher war ein Reboot des Cubie). Logmeldung war nur die altbekannte mit dem thread closed, sonst nichts an brauchbaren Hinweisen zu finden.
Seitdem habe ich den fhem-server und auch den frontHEM-Thread aber nicht mehr in die Knie bekommen, trotz bösartiger Versuche meinerseits. War da evtl. noch irgendwo was in nem Cache (den in smartVisu hab ich natürlich auf off)?
Aufgefallen:
Wenn ein Rechner bei geöffneter Seite in Standby war, dann erscheint oben rechts das rote Dreieck mit dem Domotiga-Fehler. Ist ja so weit korrekt. Ab hier ist das Verhalten unterschiedlichst. Mal reicht der Wechsel auf eine andere Seite, mal sind zwei/drei Wechsel nötig, ein anderes mal muss mit F5 die komplette Seite neu geladen werden. Ich kann hier aber kein System erkennen.
Grüße
Tobi
Hi,
Zitat von: ftobi am 18 Januar 2015, 20:54:30
Hallo Jörg,
das letzte Update läuft schon richtig gut, vielen vielen Dank :)
Feedback:
direkt im ersten Clientstandby nach dem update heute früh hat sich fhem einmal komplett verabschiedet (vorher war ein Reboot des Cubie). Logmeldung war nur die altbekannte mit dem thread closed, sonst nichts an brauchbaren Hinweisen zu finden.
Seitdem habe ich den fhem-server und auch den frontHEM-Thread aber nicht mehr in die Knie bekommen, trotz bösartiger Versuche meinerseits. War da evtl. noch irgendwo was in nem Cache (den in smartVisu hab ich natürlich auf off)?
Super. Mag im so gewesen sein (cache). Bösartige Versuche sind sehr gut ;D kann nur dazu ermuntern. Wenn die dann dazu führen das noch was auftaucht dann ist es eben so und ich muss noch ran. Besser bewusst provoziert als im Urlaub davon überrascht.
Ich hab ihn 24h lang mit zwei clients und 50kByte pro Sekunde gequält (was mal eben 100kByte = 0,8mbit sind. Der Server hatte den Lüfter durchgehend an :) ). Ich habe ihn auch nicht in die Knie bekommen - aber da kann es ja trotzdem Systeme geben woo irgendwas spezifisches ist, bzw wo ich noch etwas nicht beachtet habe.
Zitat
Aufgefallen:
Wenn ein Rechner bei geöffneter Seite in Standby war, dann erscheint oben rechts das rote Dreieck mit dem Domotiga-Fehler. Ist ja so weit korrekt. Ab hier ist das Verhalten unterschiedlichst. Mal reicht der Wechsel auf eine andere Seite, mal sind zwei/drei Wechsel nötig, ein anderes mal muss mit F5 die komplette Seite neu geladen werden. Ich kann hier aber kein System erkennen.
Grüße
Tobi
Ja, das ist auf sv Seite. Das nehmen wir uns noch vor :)
Vielen Dank für Test und für Feedback.
vg
jörg
Hallo bgewehr,
ich habe mal dein aktuelles SV genommen. Leider bekomme ich bei "basic.textrpl" keine Ausgabe. Was muss ich noch einbinden?
Wenn ich es in "basic.value" ändere ist wieder alles OK.
Danke
Lutz
@Lutz: Hast Du auch die widgets.js mitgenommenen?
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 18 Januar 2015, 22:04:16
@Lutz: Hast Du auch die widgets.js mitgenommenen?
Gesendet von iPhone mit Tapatalk
Ja sie liegt unter smartVisu\widgets. Hab auch rein geschaut, es ist deine Änderung drin.
Bei mir wird nur "---" angezeigt! Fehlt mir vielleicht ein spezieller Converter? Ich lege den Converter auf Direkt.
Gruß Lutz
Schau mal bei mir im widget_fritzbox nach, da habe ich es verwendet... Hast Du die letzte Version?
Gesendet von iPhone mit Tapatalk
Ich habe deine kopiert. Du verwendest die "widget_fritzbox_list.html" und verweist auf die "basic.html". Alle Dateien habe ich von dir kopiert und in die entsprechenden Verzeichnisse gepackt.
Ich habe auch dein komplettes Verzeichnis unter pages abgelegt und dann eine Verbindung zur FHEM aufgebaut. Auch hier wird nur "---" angezeigt.
Kann also nur an dem Converter oder einer generellen Änderung liegen.
Danke Lutz
Hast Du auch dem GAD, das basic.textrpl verwendet, einen FHEM Text zugewiesen? Was sagt die Browser-Konsole (F12-Konsole)?
Gesendet von iPhone mit Tapatalk
Ich nehme auch Direct dafür. Kann ich mir grade nicht erklären. Die --- stammen ja aus der basic.html, es scheint nur kein Ersatz mit dem fhem-Text stattzufinden. Dies wird durch den Code in der Widgets.js gemacht. Der wird getriggert, wenn ein Wert von fronthem kommt. Sicher, dass Du die neuesten Versionen hast und die Datei-Rechte alle stimmen?
Leg doch mal alle meine Dateien in einen neuen Ordner z. B. in /var/www/berndVISU und rufe sie so als Ganzes auf. Was bei mir geht, müsste doch dann auch bei Dir gehen!
Gesendet von iPhone mit Tapatalk
Ich weiß nicht ob das noch in Arbeit ist.
Mir ist aufgefallen, egal was ich im fronthem Editor beim Device bei r / w einstelle, ich kann es immer bedienen und immer alles sehen.
Wenn falsche Berechtigungen gesetzt sind wird dies zur Zeit "nur geloggt".
@Jörg: Bevor Du die Berechtigungen aktivierst, bitte ich um eine Vereinfachung für den Gall, dass man alles erlauben möchte. Das wird sonst eine ganztägige Klickerei...
Gesendet von iPhone mit Tapatalk
Hallo zusammen,
ich wollte meinen Google-Kalender einbinden und frage mich, wo ich - wie in der Docu beschrieben - user/pw eingebe...
Habe nur System und URL in der Configuration -> Calendar
Docu:
ZitatConfiguration
Enter user and password the configuration page.
Danke vorab !
Gruß Kai
Hallo zusammen,
ich habe heute meinen erstes HM-CC-RT-DN eingerichtet und wollte es auch gleich in sv anlegen mit:
{{ homematic.hmtc('HMTC_EG', 'mode', 'EZ_rtr_act', 'EZ_rtr_set', 'EZ_rtr_controlmode', 'EZ_rtr_daytemp', 'EZ_rtr_nighttemp', 'EZ.fenster', 'EZ_rtr_battery', 'EZ_rtr_state', 'EZ_rtr_text') }}
Das hat soweit auch funktioniert, jedoch wäre ich sehr dankbar, wenn mir jemand, der diesen Aktor schon in sv hat mal seine GADs hier hineinschreiben könnte, da bei mir noch ein paar nicht stimmen (siehe Bild). Das würde mir Sucherei ersparen und wir hätten es für die Zukunft schon hier drin stehen.
viele Grüße
Alexander
P.S.: Das mit der Batterien weiß ich, dass ich das über den kleinen Converter in der 99 anlegen muss, um es besser darstellen zu können.
@avg123: Act geht Direct an messuredtemp, Set an desiredtemp, Battery an batterylevel, Text an Boosttime und state mit OnOff an desiredtemp (dauerboost in diesem Fall) alle anderen heißen so wie in fhem! Fenster ist ein separater Sensor, davon der state!
Ich habe mal noch Ventilstellung (für HM-CC) und Luftfeuchte für HM-TC eingebaut!
Durch das Listenlayout werden die widgets bei mir immer komplexer, das ist ein gewisser Nachteil...
Ich kopiere mir inzwischen immer die {% Macro ... Zeile in die Seiten, mache dann die {{ Macro..macro() }} Definition, dann behält man besser die Übersicht über die Gads.
Seit gestern entwickle ich sv mit eclipse Luna for php, das ist mal 100 mal eleganter als bisher! Kann ich nur empfehlen. Es gibt sogar ein Twig Plugin, ich habe es nur noch nicht begriffen...
Gesendet von iPhone mit Tapatalk
Hallo zusammen erst mal super Arbeit mit dem smartVisu find ich richtig gut.
Aber hab da mal zu Einrichtung eine Frage oder zwei.
Wenn ich smartVisu installiere muss ich dann ein Interface auswählen?
Weil wenn ich alber.eibd auswähle bekomme ich räume und Schalter die ich nicht habe. Ich kann sie zwar über GAD anderst belegen aber ich kann die nicht benötigten nicht Löschen oder umbenennen.
Jetzt hab ich ein jungfräulich smartVisu und frag mal hier nach wo ich die Konfiguration am besten beginne.
Und im GAD kann ich zurzeit nichts auswählen
Gruß Christian
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 19 Januar 2015, 19:37:03
Seit gestern entwickle ich sv mit eclipse Luna for php, das ist mal 100 mal eleganter als bisher! Kann ich nur empfehlen. Es gibt sogar ein Twig Plugin, ich habe es nur noch nicht begriffen...
Mit welchem PHP Plugin ? Oder nutzt du PHP Ellipse.
Ja, ich glaube php eclipse, das habe ich fertig konfiguriert runterlasen können. Man muss ein bisschen auf die Bits achten- entweder alles 32 oder alles 64 - inklusive Java!
Gesendet von iPhone mit Tapatalk
Ja, ich glaube php eclipse, das habe ich fertig konfiguriert runterlasen können. Man muss ein bisschen auf die Bits achten- entweder alles 32 oder alles 64 - inklusive Java!
Gesendet von iPhone mit Tapatalk
@Bernd
Ich habe jetzt alles probiert! Rechte sind alle da, dein komplettes SmartVisu in neuen Ordner kopiert! Gleiches Ergebnis!
Bei F12 wird folgendes angezeigt:
<span id="Fritzbox-FBoxname" data-widget="basic.textrpl" data-item="FB_name">---</span>
Wo kann mein Problem liegen? Die Lösung für üäö wäre schon interessant!
Gruß Lutz
Basic.value funktionieren?
Gesendet von iPhone mit Tapatalk
Hallo Bernd,
danke, hat jetzt soweit geklappt. Nur noch eine Frage, wie bekomme ich das Kästchen zu einem °C (muss ich hierfür das ° im Widget zu °C abändern?
viele Grüße
Alexander
Nee, in den Settings bei Texts auf Deutsch umstellen:
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 19 Januar 2015, 14:34:57
@Jörg: Bevor Du die Berechtigungen aktivierst, bitte ich um eine Vereinfachung für den Gall, dass man alles erlauben möchte. Das wird sonst eine ganztägige Klickerei...
Gesendet von iPhone mit Tapatalk
Ja. Ist so geplant. Vg Jörg
Zitat von: bgewehr am 19 Januar 2015, 20:37:54
Basic.value funktionieren?
Gesendet von iPhone mit Tapatalk
Jepp!
Zitat von: bgewehr am 19 Januar 2015, 20:59:19
Nee, in den Settings bei Texts auf Deutsch umstellen:
Gesendet von iPhone mit Tapatalk
Das steht bei mir auf Deutsch.
@avg und Cruiser: Welcher Browser?
Gesendet von iPhone mit Tapatalk
@avg und Cruiser: Welcher Browser?
Gesendet von iPhone mit Tapatalk
IE, in Chrome funktioniert es aber auch nicht, da steht ein ?
Zitat von: bgewehr am 19 Januar 2015, 20:59:19
Nee, in den Settings bei Texts auf Deutsch umstellen:
Gesendet von iPhone mit Tapatalk
Hilft bei mir nicht! Habe in den Widgets hinter dem "°" ein C geschrieben dann war das F weg!
Zitat von: bgewehr am 19 Januar 2015, 21:18:40
@avg und Cruiser: Welcher Browser?
Gesendet von iPhone mit Tapatalk
Chrome und Firefox!
Also das ist insgesamt schon merkwürdig, dass Ihr alle andere Ergebnisse habt, auch mit den gleichen Browsern. Ich glaube, so werden wir das auf Dauer nicht supporten können. Ich habe Lighttpd als Webserver auf Raspian und teste unter Windows 7 und IPhone/IPad iOS8 mit Safari und Chrome. Alles was da mit derselben Konfig bei Euch nicht geht, können wir gern drüber sprechen, alles andere ist Glaskugelraten, da weiß ich auch nicht weiter. Bei mir hat es völlig gereicht, auf Deutsch umzustellen, damit aus F ein C wurde... Wenn das schon nicht geht, wie soll ich da bei allem anderen durchblicken? Sorry - da müsst Ihr basteln, bis es klappt! Jörg, was meinst Du dazu?
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 19 Januar 2015, 21:26:04
Also das ist insgesamt schon merkwürdig, dass Ihr alle andere Ergebnisse habt, auch mit den gleichen Browsern. Ich glaube, so werden wir das auf Dauer nicht supporten können. Ich habe Lighttpd als Webserver auf Raspian und teste unter Windows 7 und IPhone/IPad iOS8 mit Safari und Chrome. Alles was da mit derselben Konfig bei Euch nicht geht, können wir gern drüber sprechen, alles andere ist Glaskugelraten, da weiß ich auch nicht weiter. Bei mir hat es völlig gereicht, auf Deutsch umzustellen, damit aus F ein C wurde... Wenn das schon nicht geht, wie soll ich da bei allem anderen durchblicken? Sorry - da müsst Ihr basteln, bis es klappt! Jörg, was meinst Du dazu?
Gesendet von iPhone mit Tapatalk
Die Sonderzeichen Kiste (auch noch offen) haut evtl in die gleiche Kiste. Man kann die Server zwingen UTF auszuliefern. Dazu gibt es Anleitungen im Netz. Dieses Thema kann man evtl dadurch lösen.
Vg
Jörg
@Bernd
Ich arbeite mit einem Cubietruck und habe auch Lighttpd installiert! Mit Debian habe ich nicht so viel Ahnung! Bin Windows versaut!
Mal sehen was Jörg noch so raus kriegt!
Erstmal Danke
Hey, tut mir leid, aber da weiß ich einfach auch nicht weiter!
Gesendet von iPhone mit Tapatalk
Zitat von: cruser1800 am 19 Januar 2015, 21:37:18
@Bernd
Ich arbeite mit einem Cubietruck und habe auch Lighttpd installiert! Mit Debian habe ich nicht so viel Ahnung! Bin Windows versaut!
Mal sehen was Jörg noch so raus kriegt!
Erstmal Danke
Der ist noch im Auto unterwegs - irgendwo Rhön ... :) bei mir funktioniert das aber. Wichtig: das Symbol nicht von fhem liefern lassen sondern in den sv Text schreiben. Wenn das trotzdem nicht geht hat es was mit den zeichensätzen zu tun. Vermutung: du editierst unter Windows ? Vg jörg
So, wenn ich in dem Widget das {% if gad_set %}
<div class="set">
<a data-role="button" data-icon="minus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
<div class="temp">{{ basic.float(id~'set', gad_set, '°' ) }}</div>
<a data-role="button" data-icon="plus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
</div>
{% endif %}
zu {% if gad_set %}
<div class="set">
<a data-role="button" data-icon="minus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
<div class="temp">{{ basic.float(id~'set', gad_set, '°C' ) }}</div>
<a data-role="button" data-icon="plus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
</div>
{% endif %} ändere, bekomme ich in sv °C angezeigt, bei den Temperaturwerten unserer Solarthermie habe ich das übrigens genau so hinten dran gehangen.
viele Grüße
Alexander
@avg damit hast Du erfolgreich ein Problem umschifft, dass wir bisher nicht lösen konnten. Hoffentlich bleibt das stabil...
Gesendet von iPhone mit Tapatalk
@ Jörg
Ja ich editiere unter Windows aber mit Notepad++. Das mit den Schriftzeichen werde ich noch mal suchen!
Danke Lutz
Zitat von: bgewehr am 19 Januar 2015, 21:57:36
@avg damit hast Du erfolgreich ein Problem umschifft, dass wir bisher nicht lösen konnten. Hoffentlich bleibt das stabil...
Gesendet von iPhone mit Tapatalk
Bisher läuft alles noch, die Betonung liegt auf noch ;) (wollen wir hoffen, das es so bleibt).
Zitat von: avg123-de am 19 Januar 2015, 21:59:23
Bisher läuft alles noch, die Betonung liegt auf noch ;) (wollen wir hoffen, das es so bleibt).
Logisch, was soll da nicht stabil sein, das ist doch nur ein Zeichen. ;) wenn Text mit Sonderzeichen von fhem kommt werden die Sonderzeichen trotzdem falsch in sc. Dargestellt. Hier vermute ich aber das euer texteditor kein UTF8 speichert. Schaut dich mal ob man das einstellen kann - ggf einen anderen Editor nehmen der das kann
Vg
Jörg
Habe 2 Neue schwierigkeiten seitens sv:
1.Ich nutze Intertechno Dimmer und die Dimm funktion an sich funktioniert auch aber der Slider-Anfasser setzt sich immer auf 0 zurück ich weiss nicht wieso das passiert, hat vielleicht jemand eine Idee?
Bei manuellem reload von sv wird der aktuelle Dimmwert richtig angezeigt, dimme ich dann wieder setzt er sich wieder auf null.
2.Ich nutze meine Keymatic mit 3 einfachen Buttons und würde dort gerne die fts_door icons einbinden, als svg hat sich nichts getan dann hab ich von den betreffenden icons png`s gemacht, selber effekt, wenn ich probiere ein anderes Icon einzubinden erscheint ein "+" Icon, das scheinbar aus dem "icons/or" Ordner kommt?
Die Icons in or zu verschieben hat auch nicht funktioniert.
Hi,
#1 ist ein Thema converter betreffend. Entweder irgendein Effekt auf dem Reading oder converter falsch eingestellt.
Poste mal bitte ganz genau das reading mit Inhalt von dem dim-wert und die kompletten Einstellungen auf dem converter.
#2 icons verschieben macht keinen Sinn. Entweder falscher Syntax in sv oder eben auch converter (ich vermute Du eingestellt icon sichtbar wenn Gad == Wert x, dazu muss das GAD liefern sonst soll das icon ja unsichtbar sein. Würde man mit firebug sehen, der hat dann display:hidden)
Poste doch bitte mal die Definition vom icon in sv, dann schauen wir
vg
jörg
Bei mir funktionieren das "Update force https://.." sowie "update all https://.." nicht. Ich erhalte nur ein "..nothing new".
Die Installation erfolgte damals händisch aus dem GIT.
Rechte sind 2fach geprüft und ok.
Was kann ich tuen?
@tomtom: geht mir genauso! Ich mache auch die Updates manuell... Wenn Du was rausfindest, lass es uns bitte wissen!
Gesendet von iPhone mit Tapatalk
Hi,
ich sehe das update per git nur als temporäre Lösung während der alpha damit man die "Dateischubserei" nicht machen muss. Für das update per git kommt der normale, fhem eigene update Mechanismus zum tragen. Soweit ich weiß bin ich der einzige der den thirdparty mode verwendet - daher kann es in der update.pm von fhem durchaus Nebeneffekte geben die einfach noch niemanden aufgefallen sind.
Schaut doch mal bitte ob in Eurem fhem/FHEM Verzeichnis eine Datei controls_fronthem.txt liegt, wenn ja bitte kurz anhängen.
vg
jörg
Hallo Ihr Lieben,
da im Smartvisu Forum nicht soooo viel los ist und ich hier echt Experten zu Rate ziehen kann 8) - wie kann ich den RSS Feed der TV Apps (Spielfilm oder Movie) sortieren? Da sind grausige voreingestellte Programme, die kein Mensch braucht.
Sagt mir bitte nicht dass das nicht funktioniert, wär ja ewig schade. :(
Vielen Dank!
Olli
Hallo,
nochmal eine Rückmeldung bzgl. der Stabilität der Verbindung: Ich nutze immer den selben Firefox, aber ich verliere regelmäßig (nach shutdown des Rechners z.B.) die Verbindung - Werte werden nicht mehr angezeigt. Seltsam ist daran, dass das rote Dreieck fehlt und in fhem der Rechnr als connected angezeigt wird. FHEM-Neustart bringt auch nix. Gibt es dafür irgendeinen anderen Trick?
schöne Grüße
Jo
Schon interessant, wie unterschiedlich das ist. Ich habe alle mir bekannten Browser auf Windows und Android Mobilgeräten getestet und ich verliere zwar bei Standby und ähnlichen Events die Verbindung (rotes Dreieck), kann sie aber durch Aktualisierung der Seite oder Aufruf einer SV Seite ohne Ajax-Load wieder holen. Einen FHEM-Neustart habe ich noch nie gebraucht. Das klappt reproduzierbar in Firefox, Chrome, Dolphin...sogar Safari... Nur den IE habe ich nicht getestet. Wüsste nicht, warum man für ein modernes System den IE verwenden sollte ;)
Allerdings habe ich den Effekt, dass hin und wieder Gads nicht aktualisiert werden. Es bleibt dann konsequent ein "---" an der Stelle stehen, während alle anderen gads geholt und auch aktualisiert werden. Erst nach einem Reload der Seite wird der Gad dann geholt.
Auch kann man häufig erkennen, dass wenn das Schalten in FHEM zu schnell geht (bspw. ein schnelles schalten von aus nach standby und nach on (standby nur als Zwischenschritt), dass SmartViSU nur den Zwischenschritt anzeigt und die zweite, kurz darauf folgende Schaltung nicht mitbekommt. Das kann man konsequent reproduzieren und man sieht es auch in der Konsole. Das scheint dann für SV zu schnell zu gehen.
@jo
kannst Du mir das genauer beschreiben ? Was bedeutet "nach shutdown des Rechners z.B" ?
vg
jörg
Hi Karl,
Zitat von: karl0123 am 20 Januar 2015, 19:57:28
Schon interessant, wie unterschiedlich das ist.
ja, das erstaunt mich auch immer wieder. Teilweise kommen Berichte rein die bei mir nicht im Ansatz zu reproduzieren sind. In einer ganzen Anzahl waren die aber berechtigt weil ich zumindest anhand der Theorie und der Beschreibung das nachvollziehen kann. Das sich die Systeme teilweise im Verhalten so unterscheiden ist schon witzig - ist halt das richtige Leben. Schlussendlich ist aber genau das der Weg um das Ding rund zu machen. Im aktuellen Stand sollten mMn fhem restarts in keiner Situation (Ausnahme rename) mehr notwendig sein.
Zitat
Allerdings habe ich den Effekt, dass hin und wieder Gads nicht aktualisiert werden. Es bleibt dann konsequent ein "---" an der Stelle stehen, während alle anderen gads geholt und auch aktualisiert werden. Erst nach einem Reload der Seite wird der Gad dann geholt.
Auch kann man häufig erkennen, dass wenn das Schalten in FHEM zu schnell geht (bspw. ein schnelles schalten von aus nach standby und nach on (standby nur als Zwischenschritt), dass SmartViSU nur den Zwischenschritt anzeigt und die zweite, kurz darauf folgende Schaltung nicht mitbekommt. Das kann man konsequent reproduzieren und man sieht es auch in der Konsole. Das scheint dann für SV zu schnell zu gehen.
Ja, der domotiga driver in sv ist da nicht ganz optimal, das ist so einer der nächsten Punkte auf der Liste. Standby (reconnect), ladegeschwindigkeit (bzw Blocking bei ganz vielen GAD), Fehlermeldungen. Da würde ich jetzt den kompletten unteren Teil reinpacken mit Ausnahme der "---". Kannst Du für die was in der console sehen? Betrifft das evtl einen speziellen converter ?
vg
jörg
Kannst Du
In der Console sehe ich eigentlich nur, dass der Wert gar nicht geholt wird bzw. ankommt. Es handelt sich um den NumDirect Converter (bin mir fast sicher, dass es immer der war). Als Hinweis vielleicht noch hilfreich: das passierte bisher nur bei langsamen Verbindungen
hmmm, dann schauen wir uns das nochmal an wenn der neue js driver fertig ist. Unter Umständen reicht es schon da die Qualität zu verbessern.
vg jörg
da es den uzsu thread noch nicht gibt (oder ich ihn nicht gefunden habe) habe ich hier: http://forum.fhem.de/index.php/topic,32385.msg248989.html#msg248989 (http://forum.fhem.de/index.php/topic,32385.msg248989.html#msg248989) einen screenshot gepostet wie ich mir das ui für das normale fhemweb vorstelle.
gruss
andre
Hallo,
habe mir heute mal smartVISU zum testen installiert und ein paar Räume angelegt.
Was mir noch nicht ganz klar ist, wie genau kommt die Verbindung zu den fhem Devices zustande?
Was muss ich in den smartVISU html files angeben, damit das richtige Device geschalten wird?
Und dann noch ein "kleine" andere Frage, läuft bei jemand der Googlekalender und wenn ja, wie eingerichtet?
Ich habe alle möglichen Links versucht und bekomme immer Error.
Zitat von: herrmannj am 20 Januar 2015, 19:58:29
@jo
kannst Du mir das genauer beschreiben ? Was bedeutet "nach shutdown des Rechners z.B" ?
vg
jörg
Schwer zu sagen. Ich teste, schalte den Rechner aus, am folgenden Tag wieder an (mit neuer IP) und nichts geht mehr. Reload der Seite und fhem restart helfen nicht. Das gleiche am tablet.
schöne Grüße
Jo
Zitat von: Jojo11 am 20 Januar 2015, 21:17:27
Schwer zu sagen. Ich teste, schalte den Rechner aus, am folgenden Tag wieder an (mit neuer IP) und nichts geht mehr. Reload der Seite und fhem restart helfen nicht. Das gleiche am tablet.
schöne Grüße
Jo
neue IP ? Wie soll'n das gehen. Das fronthemDevice hängt doch an der ip ...
Zitat von: Mitch am 20 Januar 2015, 21:15:36
Hallo,
habe mir heute mal smartVISU zum testen installiert und ein paar Räume angelegt.
Was mir noch nicht ganz klar ist, wie genau kommt die Verbindung zu den fhem Devices zustande?
Was muss ich in den smartVISU html files angeben, damit das richtige Device geschalten wird?
Und dann noch ein "kleine" andere Frage, läuft bei jemand der Googlekalender und wenn ja, wie eingerichtet?
Ich habe alle möglichen Links versucht und bekomme immer Error.
Du hast aber schon ein wenig gelesen oder ?
fronthem installieren
fronthemDevice mit ip von sv Device
sv: - domotiga driver mit ip vom fhem host: port 2121
smartVisu.de studieren (!)
im fronthemDevice detailscreen aufrufen: GAD auswählen, converter einstellen, Spass haben :-)
( die konkreten Dinger schauen wir uns dann später an .. )
vg
jörg
Zitat von: herrmannj am 20 Januar 2015, 21:23:04
neue IP ? Wie soll'n das gehen. Das fronthemDevice hängt doch an der ip ...
Nee, neue IP vom provider. Sollte damit nichts zu tun haben, aber das ist eigentlich das einzige, was sich überhaupt ändert. Auf dem Handy habe ich übrigens das gleiche Verhalten. Update habe ich heute noch per force... gemacht.
Wenn ich in SV den Port ändere, kommt das rote Dreieck. Ändere ich ihn zurück, ist es weg aber Werte zeigt SV trotzdem nicht an.
schöne Grüße
Jo
Hi,
Ich habe weiterhin das Problem, dass Fhem abstürzt wenn ich fronthem definiert habe und dies auch wenn lediglich ein Client (Mac mit Safari) sv geöffnet hat und idelt, derzeit sind auch keine gads mit Geräten gefüllt gewesen.
Auffälligkeiten im Log traten nicht auf und auch nichts in der .err Datei.
Wegen Mangel eines Testsystems muss ich derzeit auf fronthem verzichten. :'(
Greetz
Eldrik
Zitat von: Jojo11 am 20 Januar 2015, 21:59:12
Nee, neue IP vom provider. Sollte damit nichts zu tun haben, aber das ist eigentlich das einzige, was sich überhaupt ändert. Auf dem Handy habe ich übrigens das gleiche Verhalten. Update habe ich heute noch per force... gemacht.
Wenn ich in SV den Port ändere, kommt das rote Dreieck. Ändere ich ihn zurück, ist es weg aber Werte zeigt SV trotzdem nicht an.
schöne Grüße
Jo
ok, aber die provider wan ip hat doch normalerweise nichts mit fhem zu tun ?
Dann musst Du mir das jetzt mal sortieren:
ich gehe davon aus das Dein fhem auf einem 24/7 server läuft. Richtig ?
Wenn Du von einem end device aus auf sv / fronthem zugreifst wechselt in fhem der state sofort auf connected. Richtig ?
Wenn Du das zugehörige browser fenster (nur einen Tab mit sv öffnen!) schließt ändert sich der state sofort auf "disconnected". Richtig ?
Wenn Du über "ausschalten" sprichst, was genau machst Du (standby, richtig runterfahren..) ?
vg
jörg
@jörg: genau so habe ich es gemacht, aber das Device meldet immer disconnected und ich kann keine GAD auswählen?
kein connect - keine GADs :)
Welcher browser ? Rote Ecke in sv (Fehlermeldung oben rechts) ?
vg
jörg
Ich muss mich korrigieren die Dimmer schwierigkeiten hab ich insofern das die slider jetzt ordnungsgemäß funktionieren in den Griff bekommen, jetzt ist mir dennoch ein neues Problem aufgefallen.
Der Dimm status wird nun korrekt angezeigt der converter war auf Direct eingestellt eine änderung zu numDirect brachte den erfolg, slider werte werden richtig dargestellt.
Nun zum neuen Problem, Ich nutze einen "device.dimmer" in sv und wenn Ich nun dimme werden automatisch alle Items aktualisiert soweit so gut nur wird dem switch in meinem fall dann auch gleich der wert 0 mitgegeben womit es dann in sv als aus angezeigt wird und auch entsprechend bei erneutem druck des lämpchens sv eine 1 sendet. Das Verhalten wird aufjedenfall von folgender funktion in base.js erzeugt auf zeile 678. Da bin ich dann doch gerade noch überfragt wie man das löst. :)
vg
@speex: es ist immer wichtig, sich über die Logik des eigenen Schalters wirklich im Klaren zu sein und sein fhem- Verhalten zu kennen. Wenn der Dimmer auf 0% ist, ist dann die Lampe nicht aus? Wenn der Schalter auf 1 schaltet, ist dann die Lampe nicht 100% an? Also muss man überlegen, ob man beim Dimmer das Schalter_gad nicht auch auf pct oder Level mit Converter Direct setzt, dann könnte das passen, oder?
Wenn der Dimmer einen separaten Switch hat, dann hat der SV Switch eben ein anderes device als der SV slider, das ist doch auch möglich. (Gad_switch, gad_value).
Gesendet von iPhone mit Tapatalk
@jörg: kann es sein, dass ein einfacher Button von FrontHEM nicht erkannt wird? Die gads von Buttons tauchen bei mir nicht im Editor auf...
Gesendet von iPhone mit Tapatalk
Kein Problem hier. Wie hast du den Button denn eingefügt?
Habe es jetzt nochmal getestet, aber es scheitert nun schon bei der Verbindung:
Could not connect to DomotiGa server!
Egal. ob ich domotiga.local oder die IP eingebe (fhem und smartVIU sind auf dem gleichen Server)
Im fhem Log steht:
2015.01.21 08:42:31 3: ipc fronthem:127.0.0.1:33713 (ws): ws alive with pid 13397
2015.01.21 08:42:31 2: fronthem: ipc listener opened at port 16385
Ich dachte der Port ist 2121?
Zitat von: bgewehr am 21 Januar 2015, 08:38:39
@jörg: kann es sein, dass ein einfacher Button von FrontHEM nicht erkannt wird? Die gads von Buttons tauchen bei mir nicht im Editor auf...
Gesendet von iPhone mit Tapatalk
dito - läuft. evtl id doppelt vergeben ? Besonderes naming ?
vg
jörg
Zitat von: Mitch am 21 Januar 2015, 08:49:18
Habe es jetzt nochmal getestet, aber es scheitert nun schon bei der Verbindung:
Could not connect to DomotiGa server!
Egal. ob ich domotiga.local oder die IP eingebe (fhem und smartVIU sind auf dem gleichen Server)
Im fhem Log steht:
2015.01.21 08:42:31 3: ipc fronthem:127.0.0.1:33713 (ws): ws alive with pid 13397
2015.01.21 08:42:31 2: fronthem: ipc listener opened at port 16385
Ich dachte der Port ist 2121?
völlig richtig. 16385 ist der ipc.
domotiga.local ist sowieso schon mal falsch - es sei denn Dein fhem host heißt zufällig so. ;)
Da muss die IP von fhem rein - und port 2121. Hast Du ows laufen, der hängt wohl auch manchmal auf 2121 ?
Nochmal und zur Sicherheit: welcher browser - kann der websocket ?
vg
jörg
@Mitch
Ich glaube du kommst bei der grundsätzlichen Konfiguration durcheinander.
1. Fhem installieren
2. Webserver,frontthem inkl Abhängikkeiten installieren (Perl Module etc),Smartvisu installieren.
3. Deine Clients im DHCP Server reservieren (Ich denke mal in deinem Router, je nach Netzwerkdesign)
4.config.ini innerhalb des Smartvisu Struktur bearbeiten und Clients anlegen:
ala
[clients]
192.168.20.51 = 'client_192.168.20.51'
##MEIN IPHONE
[client:client_192.168.20.51]
title = 'HomeControl'
pages = 'homecontrol'
cache = false
animation = true
driver_realtime = true
design = 'bluenight'
weather_service = 'yr.no'
weather_location = 'Tyskland/Schleswig-Holstein/Timbuktu'
5. In der fhem.cfg fronthem definieren
ala
define fronthem fronthem
attr fronthem group SmartVisu Bridge
attr fronthem room SmartVisu
6. In der fhem.cfg deine Clients die du auch in der config.ini angelegt hast definieren.
ala
define MEINIPHONE fronthemDevice 192.168.20.51
attr MEINIPHONE group SmartVisu User Devices
attr MEINIPHONE room SmartVisu
7. In der Smartvisu Weboberfläche in dem Abschnitt Konfiguration die IP Adresse deines FHEM Servers und den Port 2121 angeben
So im groben.
Deine öffentliche IP hat nichts mit fhem oder Smartvisu zu tun.
Grüße
Hi gravidi,
Perfekt - vielen Dank!
Ich würde folgende Ergänzung/Vereinfachung hinzufügen wollen: auf das Bearbeiten der config.ini in smartvisu kann läßt sich im Normalfall (default) verzichten.
Die Zeile
auto_add = true
sorgt dafür das neue clients in sv automatisch angelegt werden und individuelle Einstellungen (via sv Config Page) bekommen.
Natürlich brauchen die trotzdem ein eigenes fronthemDevice in fhem.
Mir ist eben noch klar geworden das die sv Anpassungen im Augenblick nirgendwo zum download bereitstehen: die lege ich gleich noch in das git.
Für alle die jetzt nur Bahnhof verstanden haben: smartVisu ist "ab Werk" nicht mandanten-fähig sondern verwaltet nur einen Satz Einstellungen für alle Device. Um use-case zu ermöglichen wie:
eine angepasste Oberfläche für Smartphones, sowie eine andere für (7") Tabletts und noch eine für (10") Tabletts oder NB, bzw
unterschiedliche (individuelle) Oberflächen für Tabletts in verschiedenen Räumen
personalisierte Oberflächen für unterschiedliche Benutzer ...
habe ich eine smartVisu Anpassung geschrieben die das nachrüstet. Die Installation dieses Paketes ist optional und muss nicht stattfinden, das Standard Paket von smartVisu.de funktioniert ebenfalls, nur ohne Mandanten.
vg
jörg
@jörg: danke, aber durch Eingabe der IP von fhem, war es ja schonmal richtig.
OWS habe nich nicht
Browserseitig habe ich Firefox und Safari
@gravidi: danke, den Teil mit der config.ini kannte ich nicht.
Vieleicht mal zur Infos, was und wie ich es genau gemacht habe:
1. Perl Module nachinstalliert (hatten nur zwei gefehlt)
2. smartVISU vom "Hersteller" geladen und ins Apache Verzeichnis gelegt
3. Eigenes Verzeichnis (MeinHaus) und darin Testräume angelegt
4. in fhem: define fronthem fronthem
5. in fhem: define iPhone fronthemdevice IP & define MacBook fronthemdevice IP
Bin gerade im Büro, weswegen ich nur eigeschränkt testen kann.
Wenn ich jetzt in SV die IP Adresse (intern natürlich) meines fhem eingebe, mit Port 2121 bekomme ich einen Fehler.
Eigentlich müsste SV sich mit fhem verbinden. Aber da ist schon das erste Problem.
Zitat von: Mitch am 21 Januar 2015, 13:29:19
@jörg: danke, aber durch Eingabe der IP von fhem, war es ja schonmal richtig.
OWS habe nich nicht
Browserseitig habe ich Firefox und Safari
@gravidi: danke, den Teil mit der config.ini kannte ich nicht.
Vieleicht mal zur Infos, was und wie ich es genau gemacht habe:
1. Perl Module nachinstalliert (hatten nur zwei gefehlt)
2. smartVISU vom "Hersteller" geladen und ins Apache Verzeichnis gelegt
3. Eigenes Verzeichnis (MeinHaus) und darin Testräume angelegt
4. in fhem: define fronthem fronthem
5. in fhem: define iPhone fronthemdevice IP & define MacBook fronthemdevice IP
Bin gerade im Büro, weswegen ich nur eigeschränkt testen kann.
Wenn ich jetzt in SV die IP Adresse (intern natürlich) meines fhem eingebe, mit Port 2121 bekomme ich einen Fehler.
Eigentlich müsste SV sich mit fhem verbinden. Aber da ist schon das erste Problem.
ja, scheint soweit zu passen.
Wir können ja heute Abend wenn Du fhem in Reichweite hast in die Fehlersuche gehen.
Erster Schitt: poste mal bitte
die IP von FHEM (dann die gleiche wie SV)
die IP vom Macbook
---
die Definition von fronthem
die Definition vom Macbook
Das Reading "ws" von fronthem.
Die sv Erweiterungen sind, Deiner Beschreibung nach, nicht installiert, richtig ?
In dem Fall bitte die config.php aus sv.
Zitat@gravidi: danke, den Teil mit der config.ini kannte ich nicht.
Fürs erste, ignoriere die config.ini bitte. Die ist nur vorhanden wenn dei erweiterung installiert ist und braucht im Normalfall keine Anpassung.
vg
jörg
Nachtrag: und bitte denke daran das nach der Installation des fronthem paketes ein shutdown restart notwendig ist.
Wo ist denn diese ini?
Ich habe nur folgende Dateien/Ordner:
apps designs favicon.ico icons lang license.txt pages readme.txt temp vendor
config.php driver favicon.png index.php lib make.php pics sounds Thumbs.db widgets
Das Reading "ws" von fronthem sagt: open
Bin gerade aber einen Schritt weiter gekommen.
Habe nochmal ein device (mein iPhone über VPN) angelegt und siehe da, es wird als connected angezeigt.
Nachdem ich einmal auf die SV Seite bin und dann in fhem einen reload gemacht habe, ist auch die GAD Liste da!!
Werde dann heute Abend mal weiter "spielen" - Danke euch schonmal
Zitat von: Mitch am 21 Januar 2015, 14:00:24
Wo ist denn diese ini?
Fürs erste, ignoriere die config.ini bitte. Die ist nur vorhanden wenn dei erweiterung installiert ist und braucht im Normalfall keine Anpassung.
Was war es denn jetzt?, das wird sicher auch andere user interessieren
vg
jörg
Hallo Ihr Lieben,
hatte eben ein kleines Problem und musste fhem neustarten um smartvisu wieder zum laufen zu bekommen:
2015.01.21 16:33:41 1: fronthem: thread ws closed for unknown reason
2015.01.21 16:33:41 3: fronthem: client Olli: forced disconnect
2015.01.21 16:34:10 1: fronthem Olli want send but isnt a sender
2015.01.21 16:34:10 1: PERL WARNING: Use of uninitialized value $conn in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.01.21 16:34:10 1: PERL WARNING: Use of uninitialized value $ressource in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.01.21 16:34:10 3: fronthem: client Olli: forced disconnect
2015.01.21 16:34:26 1: fronthem Olli want send but isnt a sender
vor dem obersten fronthem Eintrag war eigentlich nichts relevantes (10 Minuten davor nur eine Thermostatänderung der Temperatur).
Zum Zeitpunkt des "Absturzes" hatte ich nichtmal an dem Clienten gearbeitet.
Gibts irgendwo ein Error.log?
Grüße,
Olli
ja, im fhem Verzeichnis steht evtl in fronthem.err was drin.
vg
jörg
edit
Bitte unbedingt in die datei schauen (fronthem.err)
Die unteren Meldungen verstehe ich - alles logisch. Ich frage mich warum der ws geschlossen wurde, das sieht man nicht am log wenn das durch einen Fehler verursacht wird. Ich vermute das es nicht reproduzierbar ist - kannst Du evtl etwas über das "drum herum" sagen ?
Hallo Jörg,
zum Drumherum. Mein PC hier "Client Olli" läuft eigentlich den ganzen Tag. Browser war auch offen, FHEM und Smartvisu waren jeweils geöffnet. Gearbeitet wurde daran nichts. Aufgefallen ist es mir nur als ich am Tablet im Wohnzimmer meine Lichter anmachen wollte. Rotes Dreieck, auch per manuellem Refresh des Browserfensters nicht zum funktionieren zu bewegen. Dann per FHEM log die "Probleme" gesehen.
das steht in der error.log - ob das aber aktuell ist oder bereits seit ein paar Tagen drinsteht - kein Plan. :)
tried to send data before finishing handshake at FHEM/fhwebsocket.pm line 94
Edit: Die error log wurde zuletzt am 17.01. um ca. 17:16 geändert - scheint also eine ältere Meldung zu sein.
Grüße,
Olli
jut. Dann nehme ich mal die Existenz einer extremst selten auftretenden Absonderlichkeit auf.
Die logmeldungen (uninitialized, und forced diconnect vmlt danach mehrfach wiederholt) beseitige ich. Schön wäre wenn ich eine Idee zum nachstellen hätte ... aber "wünsch Dir was" läuft nicht mehr im Ersten ....
Hast Du eine Idee wann Du das am pc (im Browser, vmtl sv) das letzte mal was gemacht hattest ?
vg
jörg
Olli:
welche version von fhwebsocket.pm hast Du ?
vg
jörg
Zitat von: herrmannj am 20 Januar 2015, 22:16:48
ok, aber die provider wan ip hat doch normalerweise nichts mit fhem zu tun ?
Dann musst Du mir das jetzt mal sortieren:
ich gehe davon aus das Dein fhem auf einem 24/7 server läuft. Richtig ?
Wenn Du von einem end device aus auf sv / fronthem zugreifst wechselt in fhem der state sofort auf connected. Richtig ?
Wenn Du das zugehörige browser fenster (nur einen Tab mit sv öffnen!) schließt ändert sich der state sofort auf "disconnected". Richtig ?
Wenn Du über "ausschalten" sprichst, was genau machst Du (standby, richtig runterfahren..) ?
vg
jörg
Hallo Jörg,
sorry für die späte Rückmeldung.
Richtig, fhem läuft 24/7 auf einem CT. Der Rechner von dem ich aus zugreife wird meistens komplett runtergefahren. Zugriff per Firefox-Tabs. Temp-Dateien werden beim Schließen automatisch gelöscht.
>Wenn Du von einem end device aus auf sv / fronthem zugreifst wechselt in fhem der state sofort auf connected. Richtig ?
Richtig, gerade probiert mit PC und handy.
>Wenn Du das zugehörige browser fenster (nur einen Tab mit sv öffnen!) schließt ändert sich der state sofort auf "disconnected". Richtig ?
Richtig.
Ich habe den CT jetzt seit ein paar Tagen nicht mehr neu gestartet und auf keinem meiner devices läuft SV noch :( Obwohl alle "connected" sind.
schöne Grüße
Jo
Hi Jo,
ok - dann gehen wor mal vom pc aus.
Denke bitte nochmal dran nur mit einem TAB zu-zugreifen.
Bitte mach mal folgendes. Ausgehend von einem ausgeschalteten PC (Client) (state fronthem "disconnected").
Du schaltest den PC an, öffnest den browser und und gehst - mit geöffneter console, optimal firebug "skript" - auf sv.
So sieht mein log dann aus, poste bitte mal Deins.
vg
jörg
[animation.prepare]
animation.js (Zeile 39)
[animation.redraw]
animation.js (Zeile 46)
[io.domotiga] sending data: {"cmd":"proto","ver":"0.1"}
io_domotiga.js (Zeile 174)
[io.domotiga] sending data: {"cmd":"monitor","items":["wz.measured.temperature","garden.measured.temperature"]}
io_domotiga.js (Zeile 174)
[io.domotiga] receiving data: {"cmd":"item","items":["wz.measured.temperature","20.5"]}
io_domotiga.js (Zeile 115)
[io.domotiga]: update item: wz.measured.temperature val: 20.5
io_domotiga.js (Zeile 121)
[basic.float] update 'index-rooms_wz_measured_temperature': [20.5]
base.js (Zeile 678)
[io.domotiga] receiving data: {"items":["garden.measured.temperature","-1.1"],"cmd":"item"}
io_domotiga.js (Zeile 115)
[io.domotiga]: update item: garden.measured.temperature val: -1.1
io_domotiga.js (Zeile 121)
[basic.float] update 'index-rooms_garden_measured_temperature': [-1.1]
base.js (Zeile 678)
[io.domotiga] receiving data: {"items":["garden.measured.temperature","-1.1"],"cmd":"item"}
io_domotiga.js (Zeile 115)
[io.domotiga]: update item: garden.measured.temperature val: -1.1
io_domotiga.js (Zeile 121)
[basic.float] update 'index-rooms_garden_measured_temperature': [-1.1]
base.js (Zeile 678)
[io.domotiga] receiving data: {"items":["wz.measured.temperature","20.4"],"cmd":"item"}
io_domotiga.js (Zeile 115)
[io.domotiga]: update item: wz.measured.temperature val: 20.4
io_domotiga.js (Zeile 121)
[basic.float] update 'index-rooms_wz_measured_temperature': [20.4]
base.js (Zeile 678)
Hmm, schlechtes timing. Jetzt musste ich gerade aus anderen Gründen den CT neu starten und plötzlich geht es wieder auf allen Geräten. Interessant, fhem Neustart bringt nichts, CT Neustart aber schon. Firebug hab ich jetzt aktiviert und werde Dir den Auszug posten, sobald ich das Problem wieder habe...
schöne Grüße
Jo
Hallo Jörg,
ja, das hier
2015.01.21 16:34:10 3: fronthem: client Olli: forced disconnect
2015.01.21 16:34:26 1: fronthem Olli want send but isnt a sender
steht danach sehr häufig im log. Am Rechner hatte ich vielleicht 20 bis max. 30 Minuten vorher gearbeitet.
fhwebsocket.pm -> ##############################################
# $Id: fhwebsocket.pm 18 2015-01-18 12:34:48Z. herrmannj $
Zitat von: Jojo11 am 21 Januar 2015, 19:37:58
Hmm, schlechtes timing. Jetzt musste ich gerade aus anderen Gründen den CT neu starten und plötzlich geht es wieder auf allen Geräten. Interessant, fhem Neustart bringt nichts, CT Neustart aber schon. Firebug hab ich jetzt aktiviert und werde Dir den Auszug posten, sobald ich das Problem wieder habe...
schöne Grüße
Jo
perfekt. Danke
Zitat von: olli84 am 21 Januar 2015, 19:41:34
Hallo Jörg,
ja, das hier
2015.01.21 16:34:10 3: fronthem: client Olli: forced disconnect
2015.01.21 16:34:26 1: fronthem Olli want send but isnt a sender
steht danach sehr häufig im log. Am Rechner hatte ich vielleicht 20 bis max. 30 Minuten vorher gearbeitet.
fhwebsocket.pm -> ##############################################
# $Id: fhwebsocket.pm 18 2015-01-18 12:34:48Z. herrmannj $
geht der in den stand-by ?
Der "Olli"-Client? Nein. WLAN schaltet sich auch nicht ab, da ich nur LAN nutze. Nur der Bildschirm geht nach ein paar Minuten aus.
Aber selbst wenn - der Server verabschiedet sich ja?! Aufgrund der vielen fronthem Meldungen?
Zitat von: olli84 am 21 Januar 2015, 19:58:38
Der "Olli"-Client? Nein. WLAN schaltet sich auch nicht ab, da ich nur LAN nutze. Nur der Bildschirm geht nach ein paar Minuten aus.
Aber selbst wenn - der Server verabschiedet sich ja?! Aufgrund der vielen fronthem Meldungen?
ne, eben andersrum. Die Meldung ist die Folge. Das es viele sind liegt an einem Logikfehler - das ist aber kosmetisch.
Ursache der Meldungen ist das der ws gestorben ist. Fhem überlebt das Problemlos und ich werde später an dieser Stelle code einbauen der den ws einfach neu startet. Das ist, hier, jetzt, aber nur ein Pflaster. Grundsätzlich muss der ws so gehärtet sein das der nur bei äußeren Einflüssen (kill, speicher, os ...) aussteigt und erst dann kommt das Fangnetz restart zum Einsatz.
Im Augenblick versuche ich also zu erraten warum der ws bei Dir ausgestiegen ist. Ohne Meldung, ohne Reproduzierbarkeit und weil ja jetzt seltenst, ist das doof - und ich muss mich an dem "drum herum" entlang hangeln.
Theoretisch kann ich hier auch "äußere Einflüsse" nicht ausschließen.
Kabel ist übrigens sehr cool (!) - zieh doch bitte mal im Betrieb das Kabel einfach raus - und warte dann ab. Nach ca 20min (plus/minus) wird sich der State in fhem auf disconnect ändern - danach weiter abwarten (gern 60min ++ ) - da wird es spannend.
schon mal Danke - vg
Jörg
Guten Morgen,
die Nacht hat sich das Phänomen wiederholt. Ich hatte meinen Server restart, rund 20 Minuten später hat er sich abgeschossen. Da lag ich aber schon im Bett.
2015.01.21 22:35:41 1: in SHUTDOWN
2015.01.21 22:35:41 1: in SHUTDOWN
2015.01.21 22:35:41 1: in SHUTDOWN
2015.01.21 22:35:41 0: Server shutdown
2015.01.21 22:36:21 2: Perfmon: ready to watch out for delays greater than one second
2015.01.21 22:36:21 1: Including fhem.cfg
2015.01.21 22:36:22 3: WEB: port 8083 opened
2015.01.21 22:36:22 3: WEBphone: port 8084 opened
2015.01.21 22:36:22 3: WEBtablet: port 8085 opened
2015.01.21 22:36:23 2: eventTypes: loaded 4482 events from ./log/eventTypes.txt
2015.01.21 22:36:23 1: HMLAN_Parse: HMLAN2 new condition disconnected
2015.01.21 22:36:23 3: Opening HMLAN2 device 192.168.178.201:1000
2015.01.21 22:36:23 3: HMLAN2 device opened
2015.01.21 22:36:23 1: HMLAN_Parse: HMLAN2 new condition init
2015.01.21 22:36:23 3: Opening TRX_0 device /dev/ttyUSB0
2015.01.21 22:36:23 3: Setting TRX_0 baudrate to 38400
2015.01.21 22:36:23 3: TRX_0 device opened
2015.01.21 22:36:24 1: TRX: Init OK
2015.01.21 22:36:24 1: TRX: Init status: '433.92MHz transceiver, firmware=79, protocols enabled: Lighting4 LaCrosse Hideki OREGON AC X10 '
2015.01.21 22:36:25 3: tPort: port 7072 opened
2015.01.21 22:36:25 2: fronthem: ipc listener opened at port 16384
2015.01.21 22:36:25 1: Including ./log/fhem.save
2015.01.21 22:36:25 1: in INITIALIZED
2015.01.21 22:36:25 1: in INITIALIZED
2015.01.21 22:36:25 1: in INITIALIZED
2015.01.21 22:36:25 1: usb create starting
2015.01.21 22:36:26 1: usb create end
2015.01.21 22:36:26 0: Server started with 139 defined entities (version $Id: fhem.pl 7609 2015-01-17 21:37:05Z rudolfkoenig $, os linux, user fhem, pid 938)
2015.01.21 22:36:26 1: Perfmon: possible freeze starting at 22:36:22, delay is 4.104
2015.01.21 22:36:26 1: HMLAN_Parse: HMLAN2 new condition ok
2015.01.21 22:36:26 3: ipc fronthem:127.0.0.1:55764 (ws): ws alive with pid 1059
2015.01.21 22:36:30 3: Device Fenster.DG added to ActionDetector with 028:00 time
2015.01.21 22:36:30 3: Device Heizung.Bad added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.DG added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.Lena added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.Paul added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.SZ added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.WZ.A added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.WZ.B added to ActionDetector with 000:10 time
2015.01.21 22:36:30 3: Device Heizung.WZ.C added to ActionDetector with 000:10 time
2015.01.21 22:36:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 22:41:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 22:46:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 22:51:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 22:56:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 22:58:28 1: fronthem: thread ws closed for unknown reason
2015.01.21 22:58:28 3: fronthem: client Olli: forced disconnect
2015.01.21 22:59:54 1: fronthem Olli want send but isnt a sender
2015.01.21 22:59:54 1: PERL WARNING: Use of uninitialized value $conn in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.01.21 22:59:54 1: PERL WARNING: Use of uninitialized value $ressource in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.01.21 22:59:54 3: fronthem: client Olli: forced disconnect
2015.01.21 23:00:18 1: fronthem Olli want send but isnt a sender
2015.01.21 23:00:18 3: fronthem: client Olli: forced disconnect
2015.01.21 23:00:41 1: fronthem Olli want send but isnt a sender
2015.01.21 23:00:41 3: fronthem: client Olli: forced disconnect
2015.01.21 23:00:43 1: fronthem Olli want send but isnt a sender
2015.01.21 23:00:43 3: fronthem: client Olli: forced disconnect
2015.01.21 23:01:31 2: FRITZBOX Fritzbox: Open_Connection.2088 Could not open telnet connection to fritz.box
2015.01.21 23:02:41 1: fronthem Olli want send but isnt a sender
2015.01.21 23:02:41 3: fronthem: client Olli: forced disconnect
2015.01.21 23:02:43 1: fronthem Olli want send but isnt a sender
2015.01.21 23:02:43 3: fronthem: client Olli: forced disconnect
2015.01.21 23:02:50 1: fronthem Olli want send but isnt a sender
2015.01.21 23:02:50 3: fronthem: client Olli: forced disconnect
2015.01.21 23:03:09 1: fronthem Olli want send but isnt a sender
2015.01.21 23:03:09 3: fronthem: client Olli: forced disconnect
Die Meldungen mit der Fritzbox existierten beim letzten Absturz nicht.
Hi,
die Fritzbox kommt auch niicht von sv - irgendwas mit dem Netz ?
Geht nicht alleine reicht nicht - ich brauche mehr Informationen.
vg
jörg
Hallo nochmal,
ich weiss nicht was ich tun soll. Um diese Zeit war niemand mehr am Server oder an irgendeinem Clienten. Der Olli-Client war noch an (ich weiß, Stromverschwendung ;)).
Das komplette Haus ist verkabelt. Probleme mit dem Switch oder der Fritzbox kann ich eigentlich ausschließen, ich kam heute morgen ja auch ins Internet.
Wenn du mir sagst wie ich helfen kann mach ich alles!
Grüßle,
Olli
So, habe gestern Abend nochmal gespielt und jetzt geht es, ich konnte die erste Devices schalten.
Woran es nun gelegen hat, kann ich gar nicht sagen, aber ich glaube es hackt ein bischen mit Safari auf dem Mac.
Zitat von: olli84 am 22 Januar 2015, 08:52:39
Hallo nochmal,
ich weiss nicht was ich tun soll. Um diese Zeit war niemand mehr am Server oder an irgendeinem Clienten. Der Olli-Client war noch an (ich weiß, Stromverschwendung ;)).
Das komplette Haus ist verkabelt. Probleme mit dem Switch oder der Fritzbox kann ich eigentlich ausschließen, ich kam heute morgen ja auch ins Internet.
Wenn du mir sagst wie ich helfen kann mach ich alles!
Grüßle,
Olli
ja an Netz dachte ich wegen der Fritzbox Meldung. Ansonsten: probier halt mal bitte das mit dem Kabel raus ziehen. Es scheint speziell bei Dir aufzutreten, oder Du machst unbeabsichtigt etwas was das auslöst. Oder auf Deinem System ist was speziell.
Bei mir tritt es nicht auf und ich schaffe es nicht das zu provozieren. Ohne die Ursache zu kennen kann ich keine Gegenmaßnahmen ergreifen.
Ich kann sicher etwas dagegen einbauen. Wenn wir näher kommen kann ich auch zusätzliches logging einbauen - da brauchen wir aber erst einmal eine Richtung.
vg
jörg
Hallo Jörg,
sobald ich zuhause bin zieh ich mal das Kabel vom Olli-Client. Soll ich zu der Zeit verbose 5 anmachen?
Grüße,
Olli
Um meine Fritzbox zu nutzen müßte ich wissen was ich im Gadedit alles eintragen muß für Readings etc...
Habe die Vorlage von bgewehr.
Wenn mir da jemand mal die Daten schicken könnte?
Zitat von: olli84 am 22 Januar 2015, 12:30:35
Hallo Jörg,
sobald ich zuhause bin zieh ich mal das Kabel vom Olli-Client. Soll ich zu der Zeit verbose 5 anmachen?
Grüße,
Olli
Ja, schaden wirds nicht. Wir müssen hier aber den Dr. House geben.
Was ich bisher verstehe: der Fehler tritt bei Dir xx Minuten nachdem Du den Rechner verlassen hast auf.
Ich teste in diesem Zusammenhang drei Szenarien:
- Browser schließen (disconnect)
- Notebookdeckel zuklappen, NB geht irgendwann in den standy-by (disconnect nach ca 20..40min)
- WLAN unterbrechen (disconnect nach ca 20min, plus x)
Das "verzögerte" bei Dir deutet auf #2/3 hin - allerdings sagst Du das Du den Rechner laufen läßt. Vmtl ist das aber nur die halbe Wahrheit, irgendwann werden da Energiemanagement Einstellungen irgendwas machen. (Bitte aber die vorerst nicht verändert, wir wollen das ja suchen)
Insofern frage ich mich ob die gleiche Situation nicht auch tagsüber auftreten sollte, da gehst Du ja auch mal vom Rechner weg ?
Außerdem deute ich Dein log so das Du zwei clients installiert hast - es scheint nur beim Macbook aufzutreten ?
Mit dem Kabel fangen wir mal an und so tasten wir uns ran - und dann werden wirs irgendwann genau verstehen und dann ist es gut. :)
vg
jörg
Hallo,
beim Kabelziehen zeigt mir FHEM bereits nach Sekunden den Disconnect an!
Sobald ich dieses wieder reinstecke und die smartvisu seite aktualisiere (dann ist auch das rote dreieck da!) steht in FHEM wieder connected. Nach dem Aktualisieren ist das rote Dreieck weg, Temperaturen, Lichter o.ä. kann ich aber nicht schalten und nicht abrufen! Siehe Anhang!
Grüße,
Olli
tja, wäre auch zu schön ... :) Ich unterstelle mal das der ws thread einfach weiterläuft.
Magst Du fhem bitte mal auf dem server beenden und via cmd line starten (sudo perl fhem.pl fhem.cfg) - console bitte offen lassen.
Dann mach mal das das Safari Ding :) und lass uns mal schauen ob auf der console was auftaucht und wie lange es dauert von " ich lass den mac alleine - bis - der ws scheidet dahin.
vg
jörg
ganz kurz noch die log's:
Das ist im übrigen mein PC mitm Firefox, nicht der Mac. 8)
Wenn ich aktualisiere kommt dieses
Zitat2015.01.22 16:25:34 5: Triggering Olli (1 changes)
2015.01.22 16:25:34 5: Notify loop for Olli disconnected
2015.01.22 16:25:34 5: statistics Statistik: Notify.260 Notification of 'Olli' received. Device not monitored.
2015.01.22 16:25:34 4: eventTypes: fronthemDevice Olli disconnected -> disconnected
2015.01.22 16:25:34 4: eventTypes: fronthemDevice Olli state: disconnected -> state: disconnected
2015.01.22 16:25:35 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown","message":{"cmd":"connect"}}
2015.01.22 16:25:35 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown","message":{"cmd":"handshake"}}
2015.01.22 16:25:35 5: Triggering Olli (1 changes)
2015.01.22 16:25:35 5: Notify loop for Olli connected
2015.01.22 16:25:35 5: statistics Statistik: Notify.260 Notification of 'Olli' received. Device not monitored.
2015.01.22 16:25:35 4: eventTypes: fronthemDevice Olli connected -> connected
2015.01.22 16:25:35 4: eventTypes: fronthemDevice Olli state: connected -> state: connected
2015.01.22 16:25:35 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"proto","ver":"0.1"}}
2015.01.22 16:25:35 5: Triggering Olli (1 changes)
2015.01.22 16:25:35 5: Notify loop for Olli protokoll: 0.1
2015.01.22 16:25:35 5: statistics Statistik: Notify.260 Notification of 'Olli' received. Device not monitored.
2015.01.22 16:25:35 4: eventTypes: fronthemDevice Olli protokoll: 0.1 -> protokoll: .*
2015.01.22 16:25:35 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"monitor","items":["DG_rtr_act","DG.fenster","Paul_rtr_act","SZ_rtr_act","Lena_rtr_act","Bad_rtr_act","WZ_A_rtr_act","EG.Aussen.temperature"]}}
2015.01.22 16:25:39 4: Connection closed for FHEMWEB:192.168.178.20:58689: EOF
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2015-01.log
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58692 GET /fhem/pgm2/style.css
2015.01.22 16:25:39 4: Connection accepted from FHEMWEB:192.168.178.20:58704
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58691 GET /fhem/pgm2/jquery-ui.min.css
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58694 GET /fhem/pgm2/jquery.min.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58693 GET /fhem/pgm2/jquery-ui.min.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58704 GET /fhem/pgm2/fhemweb.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58692 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/pgm2/fhemweb_knob.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58691 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58694 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58693 GET /fhem/pgm2/cordova-2.3.0.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58704 GET /fhem/js/webviewcontrol.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58692 GET /fhem/pgm2/fronthemEditor.js
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/pgm2/defaultCommon.css
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/pgm2/dashboard_style.css
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/images/default/icoEverything.png
2015.01.22 16:25:39 4: HTTP FHEMWEB:192.168.178.20:58690 GET /fhem/images/default/fhemicon.png
danach erstmal nichtsmehr was nach fronthem aussieht.
Sobald ich z.B. versuche die Temperatur zu verstellen:
2015.01.22 16:27:18 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_set","val":"NaN"}}
2015.01.22 16:27:18 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_set","val":"NaN"}}
2015.01.22 16:27:19 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_set","val":"NaN"}}
2015.01.22 16:27:20 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_controlmode","val":"auto"}}
2015.01.22 16:27:22 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_controlmode","val":"manual"}}
2015.01.22 16:27:23 5: ipc fronthem:127.0.0.1:48055 (ws): receive {"connection":"conn-u7ulUqZj","sender":"192.168.178.20","identity":"unknown", "message":{"cmd":"item","id":"DG_rtr_controlmode","val":"auto"}}Mir ist es jetzt nichmehr möglich ohne einen restart von FHEM smartvisu zu bedienen. Ich kann das Browserfenster schliessen, ein neues öffnen - genau das gleiche.
verstehe ich nicht, erkläre mal bitte:
ZitatMir ist es jetzt nichmehr möglich ohne einen restart von FHEM smartvisu zu bedienen. Ich kann das Browserfenster schliessen, ein neues öffnen - genau das gleiche.
Hallo Jörg,
damit meine ich - es steht zwar in FHEM connected - aber auf dem Olli-Client (PC) kann ich smartvisu nichtmehr bedienen. Es sieht trotz Browser neustart u.ä. exakt so aus wie auf dem Screenshot vorhin. Erst nach einem FHEM restart geht es wieder, inklusive der FHEM Readings!
Nochmal kurz und knapp: Kabel gezogen (Verbindung weg - Fronthem sagt disconnect), halbe stunde später wieder dran (Fronthem sagt connected), smartvisu zeigt mir keine FHEM relevanten readings mehr an. Egal ob Browser Neustart, F5 oder sonstiges. Smartvisu zeigt in dem Fall dann auch kein rotes Kreuz mehr (Fronthem sagt ja auch connected).
Nächster "Test": 8)
Terminal am Mac geöffnet, ssh auf den Server, mit
sudo service fhem stop
den Server gestoppt und mit
sudo perl fhem.pl fhem.cfg
wieder gestartet. Ich spiel mit dem PC (Olli-Client) ein bisschen am FHEM und smartvisu rum und werde dann alles so stehen lassen. Werde mich später wieder melden, ob im Mac Terminal was auftaucht.
Grüßle,
Olli
ah ja, das wäre besser.
Aber mal zum Mac Terminal - damit meinst Du die ssh session zum fhem, oder ? fhem läuft auf linux (war cubi) ? Olli-client ist ein mac book der via LAN zugreift ?
Bitte mach noch folgendes:
einmal im ssh "ps aux | grep perl", da taucht fhem zweimal auf. Der erste ist fhem der zweite ist der ws thread. Bitte merk Dir beide pid.
Bitte merk Dir wann Du das Macbook alleine lässt. Wenn der ws sich verabschiedet (sichtbar anhand log, reading disconnected und ps aux zeigt dann nur noch eine pid an) müssen wir (Du :) ) ermitteln welche Zeit zwischen "alleine lassen" und "es weg" liegt.
Dann bitte console (ssh) auf Fehlermeldung prüfen und fronthem.err auf Eintrag prüfen.
Danke und vg
jörg
Hallo,
gibt es eigentliche schon Fortschritte bei den "Plot-Widgets" bis auf Comfort funktioniert leider noch nichts?
Ansonsten läuft Fronthem sehr stabil, egal ob ich über vpn zugreife und mein Handy in Standby geht oder ober den Laptop zugreife und auch hier mal den Deckel schließen muss (um die Aufgaben von meiner Frau zu erledigen ;) ).
Also für mich fühlt es sich nicht mehr nach Beta an.
Gruß Lutz
Hi Lutz,
Danke. Ich bekomme meins auch nicht mehr in die Knie, egal was ich anstelle.
Plots werden sicher von vielen sehnsüchtig erwartet - das wird noch mal ein recht umfangreicher Programmierblock, der nächste große.
Ursprünglich hatte ich die Hoffnung die Definitionen aus fhemweb übernehmen zu können, das wird aber nichts werden weil die sich sehr spezifisch an den gnuplot syntax anlehnen. Ich überlege im Augenblick noch wie ich da einen Editor, nach Möglichkeit so komfortabel wie möglich, auf die Beine stelle.
Die von sv verwendete Bibliothek (hihghcharts) ist gut dokumentiert, da gibt es im Prinzip nichts was nicht geht. Sv verwendet nur einen Teil der Möglichkeiten (die wesentlichen, laut Pareto also alles :) ). Trotzdem sollte der Editor auch neue widgets lernen können und ich möchte auch irgendwelche komplizierten Meta Befehle verzichten. Zusätzlich muss ich auch das Thema DB Log mit ab-frühstücken - da habe ich erst mal keinen Plan von ...
Kurz gesagt: ich denke darüber nach wie ich die fronthem GUI dazu gestalte ..... und hab noch nichts zündendes
vg
jörg
Hallo Jörg,
keine guten Nachrichten. Mir scheint sobald ein Client bei mir (in dem Fall Olli) die Verbindung verliert (vielleicht tatsächlich irgend unbeabsichtigter Stromsparmodus) funktioniert nichts mehr. Stehe jetzt im Moment wieder vor dem Problem das ich FHEM restarten muss. Egal ob ich per Tablet und/oder Rechner versuche mit Smartvisu in Kontakt zu treten - es werden keinerlei Readings angezeigt.
Verbose 5 hat auch nicht geholfen. Zu Fronthem stehen da keine weiteren Infos drin.
Den zweiten Prozess habe ich trotzdem immernoch drin. Selbst wenn der ,z.b. durch einen Save, neu zugeteilt wird (WS Alive with PID xxx) - ohne Neustart geht es nicht. Fronthem sagt auch weiterhin "connected". Nur in Smartvisu sehe ich keine Readings.
In der Shell gab es übrigens keine Reaktion.
Nach einem FHEM Neustart ist alles wieder gut, alles funktioniert.
ok - wir müssen aber bitte strukturiert und methodisch vorgehen (!), die Informationen sind für mich sehr widersprüchlich.
In den logs von gestern habe ich sowohl des disconnect gesehen als auch das schließen des websocket.
Hat denn jetzt der client "Olli" als du ihn alleine gelassen hast den Status in fronthem auf disonnected geändert ?
Wenn ja, wie lang ist die Zeitspanne zwischen "alleine lassen" und "disconnect"?
Wenn Du in dem Zustand bist wo weder das Tab noch Dein PC Daten bekommen, bitte mach mal einen list auf das fronthem (nicht das device) mit show internals. Bitte öffne im brwoser auch firebug (skipt) und poste mal das dort bei einem ctrl-f5 passiert und das gleiche Fenster im fhem log. (im Fehlerfall, versteht sich)
vg
jörg
Liebe FHEM Freunde,
ich suche als für ein Tablet als zentrale Steuereinheit noch eine "ansprechende" Oberfläche. Daher bin ich auch auf fronthem mit smartVISU gestossen.
Ich habe smartVISU auf meinem Raspberry installiert und kann die Oberfläche auch erreichen.
Die Dateien von Fronthem habe ich dann wie in diesem Thread beschrieben in die entsprechenden Verzeichnisse kopiert. So wie es mir scheint, ist dies auch ok.
2015.01.23 09:47:29 2: test_fronthem: ipc listener opened at port 16386
2015.01.23 09:47:30 1: Including ./log/fhem.save
2015.01.23 09:47:31 1: in REREADCFG
2015.01.23 09:47:32 1: in REREADCFG
2015.01.23 09:47:33 3: ipc test_fronthem:127.0.0.1:49427 (ws): ws alive with pid 8432
2015.01.23 09:47:34 1: in ATTR
2015.01.23 09:47:34 1: in ATTR
In der fhem.cfg habe ich dann (zunächst einmal) meinen PC als Device freigeschaltet.
Leider komme ich hier nicht weiter. wie es scheint, ist der PC nicht verbunden. (disconnected).
Hat jemand eine Idee?
oder muss ich noch etwas in der Konfiguration von smartVISU eintragen?
Danke im Voraus
Hallo Gerd,
ist in smartVISU domotiga mit fhem ip eingestellt??? Hast du in smartVISU ein demohaus ausgewählt bzw. ein eigenes mit GADs? Ist die fronthemDevice ip die des Gerätes welches auf sv zugreift?
Grüße
Hallo Fidel,
ich habe jetzt einmal ein anderes demohaus ausgewählt und siehe da, das device ist connected.
Kannst Du mir noch kurz erklären wie ich jetzt devices anlegen kann?
Danke schon mal
Gerd
Hallo Gerd,
das beste ist sich erst mal durch die verschiedenen Demos klicken, auch ohne Verbindung (sonst werden die Device alle angelegt) um zu sehen wie es aussehen kann. Dann die Hilfe von smartVisu mal durchblättern und die Funktion der einzelnen Elemente verstehen.
Danach einfach mal ein Demo auf Dateiebene (html) nachvollziehen wie es aufgebaut ist. Angefangen bei rooms.html dann rooms_menu.html, wie man widget einbindet und wie sie aufgebaut sind.
Erst wenn du da durch bist, würde ich mit der richtigen Planung der Oberfläche anfangen. Sonst macht man ständig alles neu ;)
Ich habe das Desingn von bgewehr genommen! Gefällt mir mit den Tabellen und Popups's am besten.
Gruß Lutz
Hallo Lutz,
vielen Dank für den Tip.
Ich habe die SW auf meinem "Ersatz" rpi installiert, von daher kann ich schon "real" ein wenig rumprobieren.
das Layout von bgewehr habe ich leider nicht gefunden (zumindest nicht in der Grund Installation). Gibt es einen Link in dem verschiedene Beispiele (ausser denen der Grundinstallation) zu sehen sind?
Danke & Gruß
Gerd
Hallo Gerd,
http://www.github.de/bgewehr/SmartVISU (http://www.github.de/bgewehr/SmartVISU)
Einfach den ganzen Ordner runterladen und spielen! Oder nur unter pages den Ordner Gewehr ;D
Gruß
Hallo Jörg,
vielen Dank für deine Hilfe und deine Geduld.
Falls meine Posts etwas missverständlich waren - hier nochmal eine Auflistung meiner Hardware.
1x Ubuntu 14.04 Server - hier läuft SV und FHEM
1x Win7-Rechner (Olli - auch ein Notebook)
1x Tablet (Acer A500)
1x Macbook 5,1
Ich glaube ich habe was interessantes gefunden. Mein Logfile ist nun schon 25MB groß und hab mich da mal durchgeackert.
Es war gestern von 17 Uhr bis 19 Uhr niemand zuhause. Server Server (SV und FHEM) lief einwandfrei als wir das Haus verlassen haben. Das Tablet war im Standby im Wohnzimmer an der Wand, der "Olli-Client" lief im Arbeitszimmer ohne Standby, aber mit ausgeschaltetem Bildschirm. Der Mac war per ssh mit dem Server verbunden (wie gestern besprochen) und war quasi im "idle".
Soviel zur Ausgangssituation. Gegen 19:15 Uhr sind wir nach Hause gekommen - ich hab das Tablet im Wohnzimmer angemacht (aus dem Standby erwacht) und verschiedene Lichter und Temperaturen geschalten.
Um 19:20:10 Uhr schaltet sich das Tablet (A500) in den Standby - und der ws von dir closed sofort und setzt meinen Olli-Client auf forced disconnect.
A500 connect:
2015.01.22 19:17:58 5: ipc fronthem:127.0.0.1:56781 (ws): receive {"connection":"conn-imWT1QFt","sender":"192.168.178.23","identity":"unknown","message":{"cmd":"connect"}}
2015.01.22 19:17:59 5: ipc fronthem:127.0.0.1:56781 (ws): receive {"connection":"conn-imWT1QFt","sender":"192.168.178.23","identity":"unknown","message":{"cmd":"handshake"}}
2015.01.22 19:17:59 5: Triggering A500 (1 changes)
2015.01.22 19:17:59 5: Notify loop for A500 connected
2015.01.22 19:17:59 5: statistics Statistik: Notify.260 Notification of 'A500' received. Device not monitored.
2015.01.22 19:17:59 4: eventTypes: fronthemDevice A500 connected -> connected
2015.01.22 19:17:59 4: eventTypes: fronthemDevice A500 state: connected -> state: connected
2015.01.22 19:17:59 5: ipc fronthem:127.0.0.1:56781 (ws): receive {"connection":"conn-imWT1QFt","sender":"192.168.178.23","identity":"unknown", "message":{"cmd":"proto","ver":"0.1"}}
2015.01.22 19:17:59 5: Triggering A500 (1 changes)
2015.01.22 19:17:59 5: Notify loop for A500 protokoll: 0.1
2015.01.22 19:17:59 5: statistics Statistik: Notify.260 Notification of 'A500' received. Device not monitored.
2015.01.22 19:17:59 4: eventTypes: fronthemDevice A500 protokoll: 0.1 -> protokoll: .*
2015.01.22 19:18:00 5: HMLAN_Send: HMLAN2 I:K
2015.01.22 19:18:00 5: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707684,1E9C46,123ABC,1B8A7475,000A
A500 standby und disconnect vom A500 und Olli-Client
2015.01.22 19:20:10 5: ipc fronthem:127.0.0.1:56781 (ws): receive {"connection":"conn-imWT1QFt","sender":"0.0.0.0","identity":"unknown","message":{"cmd":"disconnect"}}
2015.01.22 19:20:10 5: Triggering A500 (1 changes)
2015.01.22 19:20:10 5: Notify loop for A500 disconnected
2015.01.22 19:20:10 5: statistics Statistik: Notify.260 Notification of 'A500' received. Device not monitored.
2015.01.22 19:20:10 4: eventTypes: fronthemDevice A500 disconnected -> disconnected
2015.01.22 19:20:10 4: eventTypes: fronthemDevice A500 state: disconnected -> state: disconnected
2015.01.22 19:20:10 1: fronthem: thread ws closed for unknown reason
2015.01.22 19:20:10 3: fronthem: client Olli: forced disconnect
2015.01.22 19:20:10 5: Triggering fronthem (1 changes)
2015.01.22 19:20:10 5: Notify loop for fronthem ws: error (closed)
2015.01.22 19:20:10 5: statistics Statistik: Notify.260 Notification of 'fronthem' received. Device not monitored.
2015.01.22 19:20:10 4: eventTypes: fronthem fronthem ws: error (closed) -> ws: error (closed)
2015.01.22 19:20:15 5: HMLAN_Send: HMLAN2 I:K
2015.01.22 19:20:15 5: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0707684,1E9C46,123ABC,1B8C83E4,000A
Hallo Olli,
perfekt - so langsam kommen wir näher. Mit Fleiß und Disziplin beseitigen wir das.
Eine Frage dazu: hängt der Iconia am WLAN oder auch am Kabel ?
vg
jörg
WLAN. :)
die Antwort Kabel wäre mir lieber gewesen. ;)
Was mich wundert ist das der iconia sofort nach stand-by den disconnect meldet. Das ist zwar nett - aber sehr ungewöhnlich. Normalerweise antworten die clients einfach nicht mehr und nach ca 20min entscheidet fronthem das die doof sind und löst das disconnect aus. Das war bei Dir anders.
Welchen browser hast Du denn auf dem iconia genommen ? Hast Du die Lichter geschaltet und die Kiste dann ihrem Schicksal überlassen oder hast Du den Browser beendet oder irgendwie so was ? Oder das Tab aktiv ausgeschaltet ?
Ich fange an zu verstehen warum Dir das passiert - ich würde mich aber noch besser fühlen wenn ich das auch nachstellen kann.
vg
jörg
ich habe hier: http://forum.fhem.de/index.php/topic,32660.0.html (http://forum.fhem.de/index.php/topic,32660.0.html) einen thread für das fhemweb frontend zur uzsu (bzw. dem Baukasten dazu) auf gemacht. es gibt auch ein paar screenshots :).
gruss
andre
Hallo Jörg,
ich schalte das Tablet von selbst in den standby. Also aktiv am Knopf an der Aussenseite. Der Browser läuft zu der Zeit, damit ich nach einem Standby-ende (wieder Knopf Aussenseite) sofort wieder im Browser bin. Browser ist der ganz normale Android-Browser. Das Gerät ist jedoch gerootet!
Falls ich irgendwelche anderen Einstellungen ausprobieren soll - nur her damit! :)
Zitat von: herrmannj am 23 Januar 2015, 14:02:41
die Antwort Kabel wäre mir lieber gewesen. ;)
Was mich wundert ist das der iconia sofort nach stand-by den disconnect meldet. Das ist zwar nett - aber sehr ungewöhnlich. Normalerweise antworten die clients einfach nicht mehr und nach ca 20min entscheidet fronthem das die doof sind und löst das disconnect aus. Das war bei Dir anders.
Welchen browser hast Du denn auf dem iconia genommen ? Hast Du die Lichter geschaltet und die Kiste dann ihrem Schicksal überlassen oder hast Du den Browser beendet oder irgendwie so was ? Oder das Tab aktiv ausgeschaltet ?
Ich fange an zu verstehen warum Dir das passiert - ich würde mich aber noch besser fühlen wenn ich das auch nachstellen kann.
vg
jörg
Ich habe festgestellt, dass der Android-Browser im Zusammenhang mit Fronthem und SmartVisu an vielen Stellen Probleme macht. Auch und unter anderem Verbindungsprobleme werden mit diesem Behelfsbrowser deutlich. Mein Tipp: Schmeiß den Weg und verwende Chrome.
Zitat von: olli84 am 23 Januar 2015, 15:15:33
Hallo Jörg,
ich schalte das Tablet von selbst in den standby. Also aktiv am Knopf an der Aussenseite. Der Browser läuft zu der Zeit, damit ich nach einem Standby-ende (wieder Knopf Aussenseite) sofort wieder im Browser bin. Browser ist der ganz normale Android-Browser. Das Gerät ist jedoch gerootet!
Falls ich irgendwelche anderen Einstellungen ausprobieren soll - nur her damit! :)
ja, Du könntest bitte schauen ob Du den Fehler auf diese Art wiederholt reproduzieren kannst. Bzw hänge gerne mal das log von mehreren solchen Versuchen an - auch wenn sv weiterläuft.
vg
jörg
Zitat von: marvin78 am 23 Januar 2015, 15:18:04
Ich habe festgestellt, dass der Android-Browser im Zusammenhang mit Fronthem und SmartVisu an vielen Stellen Probleme macht. Auch und unter anderem Verbindungsprobleme werden mit diesem Behelfsbrowser deutlich. Mein Tipp: Schmeiß den Weg und verwende Chrome.
ja das stimmt, wobei jetzt unabhängig vom browser fronthem das wegstecken muss. Ich würde das gern beseitigen, danach kann man ja immer noch den browser tauschen.
vg
jörg
Und der nächste Test:
Timline:
15:53 Uhr Olli-Client in SV rumgespielt, Bildschirm aus, Browserfenster normal geöffnet gelassen (in aktueller SV Instanz)
15:56 Uhr Am Tablet rumgespielt, Lichter an / aus, Temperaturen usw. - danach per Knopf Aussenseite aus gemacht.
16:06 Uhr gleiches Prozedere, funktioniert immer noch, aber beim anmachen rotes Dreieck (keine Verbindung Domotiga Server). Wieder ausgemacht.
16:16 Uhr wieder angemacht. Ohne aktualisierung versucht durch Räume zu schalten -> SV-Meldung "Error loading Page". Aktualisierung per Browser -> Funktioniert wieder. Diesmal von alleine in den Standby gehen lassen, war ca. 16:19 Uhr.
16:20 Uhr Maus an Olli-PC bewegt, Browserfenster aktuell!. Die Zustände der Lampen, die ich vom Tablet geschalten habe wurden korrekt übertragen, ohne das ich am Olli-PC aktualisieren musste. Dann habe ich versucht einen anderen Raum anzuklicken. Ging auf - jedoch ohne Readings. Einmal Browser aktualisiert - alles wieder da.
ab jetzt wirds interessant.
16:27 Uhr Aktuelles Tab mit SV geschlossen. Per FHEM status von Olli-PC gecheckt - sofort auf disconnected gegangen.
16:27 Uhr Gemerkt das im Firefox noch ein weiteres, altes SV Tab offen ist (seit wann? Ich vermute gestern abend). Dieses geöffnet, keine Readingsanzeige. Aktualisiert, immernoch keine Readings. Zugemacht, neues Tab auf, wieder SV öffnen wollen - keine Readings. Das Logfile (siehe unten) zeigt Olli-PC jedoch als connected und bemerkt das surfen auf der SV Seite (andere Räume usw.) Jedoch immernoch keine Readings! Selbst ein komplettes Schliessen des Browsers und der Versuch einen anderen (Chrome) zu benutzen funktioniert nicht!
Das Logfile beginnt erst um 16:25 Uhr - das alte war bereits 25MB groß und ich hatte vergessen verbose=5 einzuschalten.
Edit: Gerade (16:48 Uhr) probiert per Macbook (bisher völlig unbeteiligt) SV aufzumachen. Mac geht auch per LAN-Kabel. SV öffnet sich, jedoch auch keinerlei Readings! Egal welches Gerät ich nehme!Mac wird von Fronthem als connected angezeigt.
Edit2: 17:19 Uhr: Status unverändert. Keine Readings in allen Geräten die ich habe. Der Status des FronthemDevice ändert sich trotzdem auf connected, ich kann aber auch keinerlei GAD's auf der FronthemDevice-Detailseite auswählen, da überhaupt keine angezeigt werden. Ich starte jetzt auch FHEM nicht neu, bis du mir es sagst.
Hi Danke,
bitte aufpassen, das sind zwei unterschiedliche Effekte. Der driver in/von sv kann mit stand-by nicht umgehen.
Du könntest aber bitte an dieser Stelle einmal auf einem client der nicht aktualisiert den browser komplett schließen, kurz warten bis fronthem den als "disconnect" zeigt. Den browser wieder öffnen und sv aufrufen. Wenn jetzt keine Werte kommen dann bitte einmal list (mit show hidden on) auf fronthem und das gleiche auf das entsprechende device.
Das sich der ws beendet läßt, wenn ich Dich richtig verstehe, so aber nicht sicher provozieren ?
vg
jörg
Ich weiss nicht mehr welche Abfolge ich das letzte Mal hatte. Ich probiere aber gerne noch weiter.
Soll ich das FHEM jetzt so lassen wie es ist? Und dann z.b. mit meinem Mac die Seite aufrufen, diese dann wieder schliessen, dann wieder öffnen und dann auf mein FHEM und dort die list auf mein Mac-fronthemDevice und auf das fronthem selbst?
Wo mach ich das mit dem Show hidden on?
FronthemDevice (Mac):
Internals:
DEF 192.168.178.32
NAME Mac
NR 271
NTFY_ORDER 50-Mac
STATE connected
TYPE fronthemDevice
Readings:
2015-01-23 16:25:24 gateway
2015-01-23 16:25:24 identity 192.168.178.32
2015-01-23 18:49:51 protokoll 0.1
2015-01-23 18:49:51 state connected
Helper:
Cache:
Bad_rtr_act:
count 0
Dg.fenster:
count 0
Dg_rtr_act:
count 0
Dg_rtr_battery:
count 0
Dg_rtr_controlmode:
count 0
Dg_rtr_set:
count 0
Dg_rtr_state:
count 0
Dg_rtr_text:
count 0
Eg.aussen.temperature:
count 0
Lena_rtr_act:
count 0
Paul.fenster:
count 0
Paul_rtr_act:
count 0
Paul_rtr_battery:
count 0
Paul_rtr_controlmode:
count 0
Paul_rtr_set:
count 0
Paul_rtr_state:
count 0
Paul_rtr_text:
count 0
Sz_rtr_act:
count 0
Wz_a_rtr_act:
count 0
Config:
Bad.fenster:
read 0
write 0
Bad_rtr_act:
read 1
write 0
Bad_rtr_battery:
read 1
write 0
Bad_rtr_controlmode:
read 1
write 1
Bad_rtr_set:
read 1
write 1
Bad_rtr_state:
read 1
write 1
Bad_rtr_text:
read 1
write 0
Dg.fenster:
read 1
write 0
Dg_rtr_act:
read 1
write 0
Dg_rtr_battery:
read 1
write 0
Dg_rtr_controlmode:
read 1
write 1
Dg_rtr_set:
read 1
write 1
Dg_rtr_state:
read 0
write 0
Dg_rtr_text:
read 1
write 0
Eg.aussen.temperature:
read 1
write 1
Kueche.radio:
read 1
write 1
Lena.fenster:
read 0
write 0
Lena_rtr_act:
read 1
write 0
Lena_rtr_battery:
read 1
write 0
Lena_rtr_controlmode:
read 1
write 1
Lena_rtr_set:
read 1
write 1
Lena_rtr_state:
read 1
write 1
Lena_rtr_text:
read 1
write 0
Leselampe.sw:
read 0
write 0
Licht fenster:
read 0
write 0
Licht sofa:
read 0
write 0
Licht tv:
read 0
write 0
Licht.fenster:
read 1
write 1
Licht.lichtkugel:
read 1
write 1
Licht.sofa:
read 1
write 1
Licht.tv:
read 1
write 1
Licht.vitrine:
read 1
write 1
Paul.fenster:
read 0
write 0
Paul_rtr_act:
read 1
write 0
Paul_rtr_battery:
read 1
write 0
Paul_rtr_controlmode:
read 1
write 1
Paul_rtr_set:
read 1
write 1
Paul_rtr_state:
read 1
write 1
Paul_rtr_text:
read 1
write 0
Sz.fenster:
read 0
write 0
Sz_rtr_act:
read 1
write 0
Sz_rtr_battery:
read 1
write 0
Sz_rtr_controlmode:
read 1
write 1
Sz_rtr_set:
read 1
write 1
Sz_rtr_state:
read 1
write 1
Sz_rtr_text:
read 1
write 0
Wz_a.fenster:
read 0
write 0
Wz_a_rtr_act:
read 1
write 0
Wz_a_rtr_battery:
read 1
write 0
Wz_a_rtr_controlmode:
read 1
write 1
Wz_a_rtr_set:
read 1
write 1
Wz_a_rtr_state:
read 1
write 1
Wz_a_rtr_text:
read 1
write 0
Wz_b.fenster:
read 0
write 0
Wz_b_rtr_act:
read 1
write 0
Wz_b_rtr_battery:
read 1
write 0
Wz_b_rtr_controlmode:
read 1
write 1
Wz_b_rtr_set:
read 1
write 1
Wz_b_rtr_state:
read 1
write 1
Wz_b_rtr_text:
read 1
write 0
Wz_c.fenster:
read 0
write 0
Wz_c_rtr_act:
read 1
write 0
Wz_c_rtr_battery:
read 1
write 0
Wz_c_rtr_controlmode:
read 1
write 1
Wz_c_rtr_set:
read 1
write 1
Wz_c_rtr_state:
read 1
write 1
Wz_c_rtr_text:
read 1
write 0
Bath_light_switch:
read 0
write 0
monitor:
DG_rtr_act
DG.fenster
Paul_rtr_act
SZ_rtr_act
Lena_rtr_act
Bad_rtr_act
WZ_A_rtr_act
EG.Aussen.temperature
Attributes:
Fronthem:
im Anhang, sonst zu groß!
jo danke, passt aber:
den aktuellen Effekt sehe ich hier:
2015-01-23 16:25:24 gateway
Da fehlt der gateway das ist "ok" soweit. (vmtl cfg editiert, save, rereadcfg irgendwie sowas, passt) .
Mach mal einen Neustart von fhem, dann ist wieder alles roger und konzentrier Dich bitte noch darauf ob und am Tablett, so wie gestern, den Effekt hinbekommst das der ws sich verabschiedet. Da gibt es auch keine Querverbindungen zu den anderen Clients, nichts komplexes. Wenn Du das sicher reproduzieren kannst (ws thread stirbt), das wäre schön weil wir dann den Patch direkt testen könnten.
vg
jörg
Zitat von: herrmannj am 21 Januar 2015, 19:49:19
perfekt. Danke
Hallo,
heute einfach mal wieder den PC hochgefahren, SV geöffnet: Rotes Dreieck (das war bisher nicht da) und das ist die Ausgabe (Auszüge):
[notify.error] Driver: DomotiGa - Websocket error: [object Event]
base.js (Zeile 309)
[notify.error] Driver: DomotiGa - Could not connect to DomotiGa server!
Firefox kann keine Verbindung zu dem Server unter ws://192.xxx.xxx.xxx:2121/ aufbauen.
io_domotiga.js (Zeile 107)
[animation.prepare]
animation.js (Zeile 39)
[animation.redraw]
animation.js (Zeile 46)
[notify.error] Driver: DomotiGa - Websocket error: [object Event]
base.js (Zeile 309)
[notify.error] Driver: DomotiGa - Could not connect to DomotiGa server!
base.js (Zeile 309)
Firefox kann keine Verbindung zu dem Server unter ws://192.xxx.xxx.xxx:2121/ aufbauen.
Gleiches auf dem handy. Der Status wechselt auch nicht auf connected. Seltsam... :-\
schöne Grüße
Jo
nö :) geh mal bitte per ssh auf den fhem server und mach mal "ps aux | grep perl". Und dann natürlich hier posten :)
Zitat von: herrmannj am 23 Januar 2015, 19:12:48
nö :) geh mal bitte per ssh auf den fhem server und mach mal "ps aux | grep perl". Und dann natürlich hier posten :)
fhem 2398 3.1 1.9 43528 40548 ? S Jan22 45:10 perl fhem.pl fhem.cfg
fhem 14700 0.1 1.8 43324 38024 ? Ss 19:15 0:00 perl fhem.pl fhem.cfg
root 14713 0.0 0.0 3100 664 pts/0 S+ 19:16 0:00 grep perl
schöne Grüße
Jo
Zitat von: Jojo11 am 23 Januar 2015, 19:16:24
fhem 2398 3.1 1.9 43528 40548 ? S Jan22 45:10 perl fhem.pl fhem.cfg
fhem 14700 0.1 1.8 43324 38024 ? Ss 19:15 0:00 perl fhem.pl fhem.cfg
root 14713 0.0 0.0 3100 664 pts/0 S+ 19:16 0:00 grep perl
schöne Grüße
Jo
wie hast Du das denn geschafft ?? Danach läuft fhem seid gestern der ws seid eben ? cfg editiert, reload etc ? Kann das sein ?
Mach mal bitte trotzdem kurz ein list auf fronthem (mutter) und schau mal was unter ipc -> ws -> pid drinsteht. Bei mir so (wegen format)
Ipc:
Ws:
name smartvisu:127.0.0.1:60058
pid 1981
Sock:
FD 103
NAME smartvisu:127.0.0.1:60058
TYPE fronthem
buffer
registered ws
Parent: Und schau mal auf dem device nach dem reading gateway, ob da was drin ist
vg
jörg
Ja, habe eben nebenbei mal die cfg im fhem-Editor bearbeitet. Hat aber nix geändert, außer dass jetzt wieder "connected" beim Device steht. Angezeigt wird aber nichts.
Ipc:
Ws:
name fronthem:127.0.0.1:42762
pid 14700
Sock:
FD 106
NAME fronthem:127.0.0.1:42762
TYPE fronthem
buffer
registered ws
Parent:
Im Device wird im Editor nichts angezeigt. Alle gads standen noch drin, als das rote Dreieck noch da war ???
gateway 2015-01-23 19:15:14
Die zweite Spalte ist leer.
schöne Grüße
Jo
ja, genau. Das ist auch noch eine "Unsauberkeit" in fronthem - da müssen einige Dinger noch anders gekapselt werden.
Ursache hier ist das rereadcfg nachdem Du manuell in der cfg warst. Das geht noch nicht - danach musst Du einen shutdown restart machen dann ist alles ok. So kann jetzt fronthem mit dem fronthemDevice sprechen aber das fronthemDevice nicht mit der Mutter. Das wird noch geändert, tritt aber auch nur in dieser Konstellation auf.
workaround: dont-do-it bzw mach einen shutdown restart danach.
vg
jörg
Ok, danke. Gerade getestet und funktioneirt wieder (nach fhem shutdown restart).
Dann beachte ich das solange mal :D
schöne Grüße
Jo
yepp - und ich schau mal das ich das weg bekomme. vg
Hallo Jörg,
ich werde die nächsten Tage nochmals versuchen das zu provozieren - aber erstmal auf verbose 3, sonst ist das Log nach ein paar Stunden kaum mehr händelbar. ;)
Falls du nochwas brauchst - nur her damit!
hi,
ja, kannst log gerne abschalten. Aber bitte bleib nochmal dran einen Weg zu finden, den Fehler der am Tablett den ws zum Absturz gebracht hat, zu provozieren. Das geht nur an Deinem Tab, bei mir no-way :) .
Sonst können wir nicht sicher überprüfen das der patch wirkt.
vg
jörg
Hallo.
Und wieder habe ich ein wenig weiter gebastelt. Das mit der FHT Einbindung läuft noch nicht über ein eigenes Widget. Ich habe das vorhandene RTR ein wenig gekürzt und die Darstellung des Fensterstatus im Block als zusätzliches Bildchen gelöst. Geht erst einmal, könnte aber sicherlich eleganter gelöst werden. Jetzt schaue ich noch, wie ich die Ventilstellung noch in den Block bekomme.
Jetzt wollte ich aber auch einen Plot darstellen. Aber er zeigt keinen Plot an. Ich habe es auf zwei Wegen probiert. Aber weder bei der Nutzung vorhandener gad's von einem bereits dargestellten FHT noch mit eigenen gad's funktioniert es. Die neuen gad's werden in FHEM auch nicht angezeigt. Mache ich etwas falsch, oder läuft die Plotfunktion in der Beta noch nicht?
Der Code sieht wie folgt aus (mit dem zugehörigen FHT):
<div class="block">
<div class="ui-bar-c ui-li-divider ui-corner-top">Heizung</div>
<div class="ui-fixed ui-body-a ui-corner-bottom">
<table width="100%">
<tbody>
<tr>
<td align="midle">
{{ device.rtr('heiz_schlafen', 'FHT_Schlafen', 'IST-temp', 'Soll-temp','mode', 'fenster')}}
<br>
{{ basic.symbol('fenster-schlafen-o', 'fenster-sz-o', 'Fenster ist offen', icon1~'fts_window_1w_open.png','Open') }}
{{ basic.symbol('fesnster-schlafen-c','fenster-sz-c', 'Fenster ist zu', icon0~'fts_window_1w.png','Closed') }}
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="block">
<div class="ui-bar-c ui-li-divider ui-corner-top">Heizungskurve</div>
<div class="ui-fixed ui-body-a ui-corner-bottom">
{{ plot.rtr('HZK-schlafen', 'IST-temp', 'Soll-temp', 50) }}
</div>
</div>
<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="true" >
<h3>Verlauf</h3>
{{ plot.rtr('p1', 'IST-temp-k', 'Soll-temp-k', 50) }}
</div>
</div>
</div>
Beste Grüße
Dirk
Hallo!
Ich hab hier ein seltsames Problem.
In einem Raum hab ich mir ein ein Popup gebastet das aufspringt wenn man einen Link anklickt. Darin finden sich Detail zum Receiver. Mit basic.dual hab ich mir einen Button zum mute/unmute schalten eingefügt. Nachdem ich diesen geklickt habe schaltet der Receiver in mute. Auf der sv page wird mir aber nun angezeigt das der Receiver aus ist. Nach einem neuladen der Seite passt wieder alles.
{{ basic.text('wz.receiver', 'wz.receiver', 'Eingeschaltet', 'Ausgeschaltet') }} seit {{ basic.value('wz.receiver.time', 'wz.receiver.time') }}
{{ basic.dual('wz.receiver.mute', 'wz.receiver.mute', icon1~'audio_volume_mid.png', icon1~'audio_volume_mute.png', 'on', 'off') }}
In der JS-Konsole sieht das so aus:
[io.domotiga] sending data: {"cmd":"item","id":"wz.receiver.mute","val":"on"}
base.js:678[basic.dual] update 'room_wohnzimmer-wz_receiver_mute': ["on"]
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver.time","2015-01-24 09:41:44"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver.time val: 2015-01-24 09:41:44
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver","0"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver val: 0
base.js:678[basic.switch] update 'room_wohnzimmer-s2_2': [0]
base.js:678[basic.text] update 'room_wohnzimmer-wz_receiver': [0]
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver.mute","on"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver.mute val: on
Mach ich was falsch?
Grüße
@dlehmann69
Plots funktionieren soweit ich weiß noch nicht.
Zitat von: fhainz am 24 Januar 2015, 09:43:24
Hallo!
Ich hab hier ein seltsames Problem.
In einem Raum hab ich mir ein ein Popup gebastet das aufspringt wenn man einen Link anklickt. Darin finden sich Detail zum Receiver. Mit basic.dual hab ich mir einen Button zum mute/unmute schalten eingefügt. Nachdem ich diesen geklickt habe schaltet der Receiver in mute. Auf der sv page wird mir aber nun angezeigt das der Receiver aus ist. Nach einem neuladen der Seite passt wieder alles.
{{ basic.text('wz.receiver', 'wz.receiver', 'Eingeschaltet', 'Ausgeschaltet') }} seit {{ basic.value('wz.receiver.time', 'wz.receiver.time') }}
{{ basic.dual('wz.receiver.mute', 'wz.receiver.mute', icon1~'audio_volume_mid.png', icon1~'audio_volume_mute.png', 'on', 'off') }}
In der JS-Konsole sieht das so aus:
[io.domotiga] sending data: {"cmd":"item","id":"wz.receiver.mute","val":"on"}
base.js:678[basic.dual] update 'room_wohnzimmer-wz_receiver_mute': ["on"]
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver.time","2015-01-24 09:41:44"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver.time val: 2015-01-24 09:41:44
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver","0"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver val: 0
base.js:678[basic.switch] update 'room_wohnzimmer-s2_2': [0]
base.js:678[basic.text] update 'room_wohnzimmer-wz_receiver': [0]
io_domotiga.js:115[io.domotiga] receiving data: {"cmd":"item","items":["wz.receiver.mute","on"]}
io_domotiga.js:121[io.domotiga]: update item: wz.receiver.mute val: on
Mach ich was falsch?
Grüße
Hi
schwer zu sagen. 99% sind doch aus versehen doppelt vergebene IDs. Bei Dir fällt mir jetzt aber auf das fhem auf "mute" auch mit
update item: wz.receiver val: 0 antwortet - da müsstest Du Dir vielleicht tatsächlich nochmal die converter Einstellungen anschauen. Richtiges reading ? Evtl anderer converter ? (direct). Aber das kann man von hier aus nicht nachvollziehen.
vg
jörg
Hallo,
kurze Frage an die Experten: Kann ich das homematic-rtr widget dahingehend abändern, dass ich einen dummy im Bereich von x bis y über "+" und "-" Tasten und slider verändere? Also Dummy-Wert zwischen z.B. 50 und 60 in 2er Schritten ändern? Mit dem slider des widgets funktioniert das schon, aber die plus/minus-Tasten wollen weder den slider bewegen, noch den dummy-Wert ändern. Der slider zeigt auch skaliert schon den Wert an. Habe immer state und direct bzw. numdirect als converter genommen.
Danke!
schöne Grüße
Jo
pauschal würde ich denken das geht. Du musst Dir vmtl ein eigenes widget vom rtr ableiten, also eine page zb widget_joja.html erstellen (formate und rules kannst Du ja sehen).
Da kopierst Du erstmal das rtr widget rein und löschst alles raus was Du nicht brauchst. So wie ich das verstehe bleibt bei Dir nur die äußere div und die div class=set stehen, den float wirst Du aber behalten müssen.
Dann kannst Du das importieren import widget_jojo as ... und dann sollte das laufen. (nicht getestet, aber ich sehe nichts was dagegen spricht)
vg
jörg
Zitat von: herrmannj am 24 Januar 2015, 12:49:48
99% sind doch aus versehen doppelt vergebene IDs.
hab ich erst auch vermutet und kontrolliert, da passt alles.
Es ändert sich nicht nur die meldung aus basic.text, die auf den wz.receiver state reagiert, sondern auch bei dem
{{ basic.switch('s2.2', 'wz.receiver') }} schalter/icon das auch auf den state reagiert.
Mit einem Slider der die Lautstärke des Receiver steuert und Play/Pause Buttons hab ich das gleiche Verhalten. Nach einem klick sieht es so aus als ob der Receiver aus wäre. Nach einem page Reload passt der on/off Status wieder. Die Buttons/Slider funktionieren, sprich es wird Leiser/Lauter etc.
Zitat von: herrmannj am 24 Januar 2015, 12:49:48
Bei Dir fällt mir jetzt aber auf das fhem auf "mute" auch mit update item: wz.receiver val: 0 antwortet - da müsstest Du Dir vielleicht tatsächlich nochmal die converter Einstellungen anschauen. Richtiges reading ? Evtl anderer converter ? (direct).
Die Buttons/Slider haben in FHEM den Direct Coverter, teils nur mit set teils reading + set. Leider gibt es nicht für jeden set befehl das passende Reading das den status wiedergibt. Der mute Button ist zB mit direct reading+set und der Pause Button nur mit direct set eingebunden. Die Probleme habe ich aber mit beiden Varianten.
wz.receiver hat den OnOff Converter
Hast du noch einen Tipp?
Grüße
Naja, genau das hatte ich gemacht, aber die Tasten wollten nicht.
Egal, von vorne angefangen und jetzt geht es :)
Danke!
schöne Grüße
Jo
ne leider nicht. Ohne den ganzen code, die converter Einstellung und die readings, sprich das konkrete Gesamtgebilde kann ich das auch nicht nachvollziehen. Das der "{{ basic.switch('s2.2', 'wz.receiver') }} " reagiert ist logisch, der hängt ja auch am "wz.reveiver" GAD und das geht auf "0" -> aus.
Du kannst ja mal die kompletten converter Einstellungen sowie das komplette reading für "wz.receiver" posten - vielleicht seh ich dann was.
vg
jörg
Zitat von: Jojo11 am 24 Januar 2015, 15:30:11
Naja, genau das hatte ich gemacht, aber die Tasten wollten nicht.
Egal, von vorne angefangen und jetzt geht es :)
Danke!
schöne Grüße
Jo
dann kann ich Dir sicher sagen das vorher was falsch war * duck-und-wech ;D
Zitat von: herrmannj am 24 Januar 2015, 15:34:18
Das der "{{ basic.switch('s2.2', 'wz.receiver') }} " reagiert ist logisch, der hängt ja auch am "wz.reveiver" GAD und das geht auf "0" -> aus.
Bei einem Klick/Slide wird nur die set funktion von wzReceiver aufgerufen und die schaltet auf mute. Am state ändert sich nichts, somit sollte {{ basic.switch('s2.2', 'wz.receiver') }} auch nicht reagieren, oder?
Das hier sind die relevanten auszüge aus der .cfg
"wz.receiver.start" : {
"reading" : null,
"type" : "item",
"converter" : null,
"device" : null,
"set" : null
},
"wz.receiver.record" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "wzReceiver",
"set" : "record"
},
"wz.receiver.pause" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "wzReceiver",
"set" : "pause"
},
"wz.receiver" : {
"reading" : "state",
"type" : "item",
"converter" : "OnOff",
"device" : "wzReceiver",
"set" : "state"
},
"wz.receiver.volume" : {
"reading" : "volume",
"type" : "item",
"converter" : "Direct",
"device" : "wzReceiver",
"set" : "volume"
},
"wz.receiver.mute" : {
"reading" : "mute",
"type" : "item",
"converter" : "Direct",
"device" : "wzReceiver",
"set" : "mute"
},
"wz.receiver.sender.next" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "harmony",
"set" : "command"
},
"wz.receiver.sender.last" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "harmony",
"set" : "command"
},
"wz.receiver.stop" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "harmony",
"set" : "command"
},
In der html
<h4>Receiver</h4>
<table>
<tr>
<td>{{ basic.text('wz.receiver', 'wz.receiver', 'Eingeschaltet', 'Ausgeschaltet') }} seit {{ basic.value('wz.receiver.time', 'wz.receiver.time') }}</td>
</tr>
<tr>
<td>
<div data-role="controlgroup" data-type="horizontal" style="text-align: center;">
{{ basic.dual('wz.receiver.mute', 'wz.receiver.mute', icon1~'audio_volume_mid.png', icon1~'audio_volume_mute.png', 'on', 'off') }}
{{ basic.button('wz.receiver.sender.last', 'wz.receiver.sender.last', '', icon1~'control_arrow_left.png', 'DirectionLeft' ) }}
{{ basic.button('wz.receiver.play', 'wz.receiver.play', '', icon1~'audio_play.png', 'play' ) }}
{{ basic.button('wz.receiver.pause', 'wz.receiver.pause', '', icon1~'audio_pause.png', 'pause' ) }}
{{ basic.button('wz.receiver.stop', 'wz.receiver.stop', '', icon1~'audio_stop.png', 'stop' ) }}
{{ basic.button('wz.receiver.sender.next', 'wz.receiver.sender.next', '', icon1~'control_arrow_right.png', 'DirectionRight' ) }}
{{ basic.button('wz.receiver.record', 'wz.receiver.record', '', 'icons/or/audio_rec.png', 'record' ) }}
</div>
</td>
</tr>
<tr>
<td>
{{ basic.slider('wz.receiver.volume', 'wz.receiver.volume', 0, 100, 5) }}
</td>
</tr>
</table>und noch ein list auf wzReceiver
Internals:
CHANGED
DEF 10.0.0.11 82 30
INTERVAL 30
NAME wzReceiver
NR 320
STATE on
TYPE ENIGMA2
model solo2
offtime 1422108193
ontime 1422109396
Readings:
2015-01-24 15:46:17 acg 86
2015-01-24 14:21:35 apid 1921
2015-01-24 15:46:17 ber 0
2015-01-24 14:21:35 channel ORF1_HD
2015-01-24 14:21:35 currentMedia 1:0:19:132F:3EF:1:C00000:0:0:0:
2015-01-24 15:00:25 currentTitle Biathlon Weltcup Antholz
2015-01-24 15:45:58 dauerHeute 19 Std. 21 Min.
2015-01-24 15:45:58 dauerJahr 11 T. 6 Std. 8 Min.
2015-01-24 10:40:38 dauerSec 0
2014-12-12 14:48:08 enigmaversion 2014-11-21-(no branch)
2015-01-24 15:46:17 eventcurrenttime 1422110776
2015-01-24 15:46:17 eventcurrenttime_hr 15:46:16
2015-01-24 15:46:17 eventcurrenttime_next 1422110776
2015-01-24 15:46:17 eventcurrenttime_next_hr 15:46:16
2015-01-24 15:00:25 eventdescription Herren Verfolgung
2015-01-24 15:23:16 eventdescription_next Vorsicht Dachs!
2015-01-24 15:23:16 eventduration 2700
2015-01-24 15:23:16 eventduration_hr 00:45:00
2015-01-24 15:23:16 eventduration_next 1336
2015-01-24 15:23:16 eventduration_next_hr 00:22:16
2015-01-24 15:46:17 eventend_hr 15:58:00
2015-01-24 15:46:17 eventend_next_hr 16:20:16
2015-01-24 15:00:25 eventname Biathlon Weltcup Antholz
2015-01-24 15:23:16 eventname_next New Girl
2015-01-24 15:46:17 eventremaining 704
2015-01-24 15:46:17 eventremaining_hr 00:11:44
2015-01-24 15:46:17 eventremaining_next 2040
2015-01-24 15:46:17 eventremaining_next_hr 00:34:00
2015-01-24 15:23:16 eventstart 1422108780
2015-01-24 15:23:16 eventstart_hr 15:13:00
2015-01-24 15:23:16 eventstart_next 1422111480
2015-01-24 15:23:16 eventstart_next_hr 15:58:00
2015-01-24 15:00:25 eventtitle Biathlon Weltcup Antholz
2015-01-24 15:23:16 eventtitle_next New Girl
2014-12-01 18:06:03 fpversion 0
2014-12-01 18:06:03 hdd1_capacity 931
2015-01-24 15:39:47 hdd1_free 145.996
2014-12-01 18:06:03 hdd1_model ATA(ST1000LM024 HN-M)
2014-12-01 18:06:03 imageversion VTi-Team Image Release v. 8.0.0
2015-01-24 09:04:55 input tv
2015-01-24 10:40:49 iswidescreen 1
2014-12-01 18:06:03 lanmac 00:1d:ec:06:0d:22
2014-12-01 18:06:03 model solo2
2015-01-24 15:43:27 mute off
2015-01-24 15:23:16 nextTitle New Girl
2015-01-24 14:21:35 onid 1
2015-01-24 14:21:35 pcrpid 1920
2015-01-24 15:03:16 pmtpid 107
2015-01-24 10:40:43 power on
2015-01-24 11:38:34 presence present
2015-01-24 14:21:35 providername ORF
2015-01-24 11:45:03 recordings 0
2014-12-01 18:07:00 recordings10_name -
2014-12-01 18:07:00 recordings10_servicename -
2014-12-01 18:07:00 recordings11_name -
2014-12-01 18:07:00 recordings11_servicename -
2014-12-01 18:07:00 recordings12_name -
2014-12-01 18:07:00 recordings12_servicename -
2014-12-01 18:07:00 recordings13_name -
2014-12-01 18:07:00 recordings13_servicename -
2014-12-01 18:07:00 recordings14_name -
2014-12-01 18:07:00 recordings14_servicename -
2014-12-01 18:07:00 recordings15_name -
2014-12-01 18:07:00 recordings15_servicename -
2014-12-01 18:07:00 recordings16_name -
2014-12-01 18:07:00 recordings16_servicename -
2014-12-01 18:07:00 recordings17_name -
2014-12-01 18:07:00 recordings17_servicename -
2014-12-01 18:07:00 recordings18_name -
2014-12-01 18:07:00 recordings18_servicename -
2014-12-01 18:07:00 recordings19_name -
2014-12-01 18:07:00 recordings19_servicename -
2015-01-24 11:45:03 recordings1_name -
2015-01-24 11:45:03 recordings1_servicename -
2014-12-01 18:07:00 recordings20_name -
2014-12-01 18:07:00 recordings20_servicename -
2015-01-24 00:32:11 recordings2_name -
2015-01-24 00:32:11 recordings2_servicename -
2015-01-24 00:05:11 recordings3_name -
2015-01-24 00:05:11 recordings3_servicename -
2014-12-12 22:50:01 recordings4_name -
2014-12-12 22:50:01 recordings4_servicename -
2014-12-01 18:07:00 recordings5_name -
2014-12-01 18:07:00 recordings5_servicename -
2014-12-01 18:07:00 recordings6_name -
2014-12-01 18:07:00 recordings6_servicename -
2014-12-01 18:07:00 recordings7_name -
2014-12-01 18:07:00 recordings7_servicename -
2014-12-01 18:07:00 recordings8_name -
2014-12-01 18:07:00 recordings8_servicename -
2014-12-01 18:07:00 recordings9_name -
2014-12-01 18:07:00 recordings9_servicename -
2015-01-24 11:08:29 recordings_error 0
2015-01-22 06:29:29 recordings_finished 0
2015-01-24 11:07:59 recordings_next 1422132760
2015-01-24 15:46:17 recordings_next_counter 21982.6002910137
2015-01-24 15:46:17 recordings_next_counter_hr 06:06:22
2015-01-24 10:28:26 recordings_next_counter_hr: :
2015-01-24 11:22:54 recordings_next_hr 21:52:40
2015-01-24 10:22:26 recordings_next_hr: :
2015-01-24 11:07:59 recordings_next_name Mayday - Alarm im Cockpit
2015-01-24 11:07:59 recordings_next_servicename NatGeo HD
2015-01-24 14:21:35 servicename ORF1 HD
2015-01-24 14:21:35 servicereference 1:0:19:132F:3EF:1:C00000:0:0:0:
2015-01-24 14:21:35 servicevideosize 1280x720
2015-01-24 14:21:35 sid 4911
2015-01-24 15:46:17 snr 64
2015-01-24 15:46:17 snrdb 64
2015-01-24 10:40:43 state on
2015-01-24 14:21:35 tsid 1007
2014-12-01 18:06:03 tuner_a BCM7356 DVB-S2 NIM (internal) (DVB-S2)
2014-12-01 18:06:03 tuner_b BCM7356 DVB-S2 NIM (internal) (DVB-S2)
2015-01-24 14:21:35 txtpid 1925
2015-01-24 14:21:35 videoheight 720
2015-01-24 14:21:35 videowidth 1280
2015-01-24 15:30:31 volume 50
2015-01-24 14:21:35 vpid 1920
2014-12-01 18:06:03 webifversion OWIF 0.4.3
Helper:
ADDRESS 10.0.0.11
AVAILABLE 1
PORT 82
lastFullUpdate 1422110387.07394
lastInput tv
Bouquet:
Radio:
Hitradio_oe3:
sRef 1:0:1:32D5:45D:1:C00000:0:0:0:
Tv:
13th_street_hd:
sRef 1:0:19:7F:D:85:C00000:0:0:0:
3sat_hd:
sRef 1:0:19:2B8E:3F2:1:C00000:0:0:0:
A&e:
sRef 1:0:1:39:F:85:C00000:0:0:0:
Ard-alpha:
sRef 1:0:1:6F47:445:1:C00000:0:0:0:
Atv2:
sRef 1:0:1:33A7:3EB:1:C00000:0:0:0:
Atv_hd:
sRef 1:0:19:33AC:3EB:1:C00000:0:0:0:
Axn_hd:
sRef 1:0:19:7D:A:85:C00000:0:0:0:
Br_nord_hd:
sRef 1:0:19:2856:401:1:C00000:0:0:0:
Bloomberg_europe_tv:
sRef 1:0:1:2753:402:1:C00000:0:0:0:
Cartoon_network_(s):
sRef 1:0:1:27:F:85:C00000:0:0:0:
Comedy_central/viva:
sRef 1:0:1:7004:436:1:C00000:0:0:0:
Comedy_central_/_viva_at:
sRef 1:0:1:3C:7:85:C00000:0:0:0:
Dmax:
sRef 1:0:1:3F:21:85:C00000:0:0:0:
Das_erste_hd:
sRef 1:0:19:283D:3FB:1:C00000:0:0:0:
Discovery_hd:
sRef 1:0:19:82:6:85:C00000:0:0:0:
Disney_channel:
sRef 1:0:1:701:5:85:C00000:0:0:0:
Disney_cinemagic_hd:
sRef 1:0:19:6F:D:85:C00000:0:0:0:
Disney_junior:
sRef 1:0:1:1A:11:85:C00000:0:0:0:
Eurosport_hd:
sRef 1:0:19:84:B:85:C00000:0:0:0:
Hitradio_oe3:
sRef 1:0:1:32D5:45D:1:C00000:0:0:0:
History_hd:
sRef 1:0:19:71:B:85:C00000:0:0:0:
Kabel_1_austria:
sRef 1:0:1:4E24:43A:1:C00000:0:0:0:
Kika_hd:
sRef 1:0:19:2B98:3F2:1:C00000:0:0:0:
Mdr_sachsen:
sRef 1:0:1:6E44:431:1:C00000:0:0:0:
Mgm_hd:
sRef 1:0:19:73:C:85:C00000:0:0:0:
Motorvision_tv:
sRef 1:0:1:A8:1:85:C00000:0:0:0:
N24:
sRef 1:0:1:445F:453:1:C00000:0:0:0:
Ndr_fs_nds_hd:
sRef 1:0:19:2857:401:1:C00000:0:0:0:
Natgeo_hd:
sRef 1:0:19:70:D:85:C00000:0:0:0:
Nat_geo_wild_hd:
sRef 1:0:19:76:6:85:C00000:0:0:0:
Nickelodeon:
sRef 1:0:1:7008:436:1:C00000:0:0:0:
Nicktoons_(s):
sRef 1:0:1:700A:436:1:C00000:0:0:0:
Orf1_hd:
sRef 1:0:19:132F:3EF:1:C00000:0:0:0:
Orf2k_hd:
sRef 1:0:19:33F6:3ED:1:C00000:0:0:0:
Orf_iii:
sRef 1:0:1:332D:45B:1:C00000:0:0:0:
Orf_sport+_hd:
sRef 1:0:19:33FD:3ED:1:C00000:0:0:0:
Phoenix_hd:
sRef 1:0:19:285B:401:1:C00000:0:0:0:
Puls_4_austria:
sRef 1:0:1:4E27:43A:1:C00000:0:0:0:
Prosieben_austria:
sRef 1:0:1:4E22:43A:1:C00000:0:0:0:
Prosieben_maxx:
sRef 1:0:1:4461:453:1:C00000:0:0:0:
Rtl2_austria:
sRef 1:0:1:708A:443:1:C00000:0:0:0:
Rtlnitro:
sRef 1:0:1:2F1D:441:1:C00000:0:0:0:
Rtl_austria:
sRef 1:0:1:7080:443:1:C00000:0:0:0:
Rtl_crime:
sRef 1:0:1:1B:1:85:C00000:0:0:0:
Rtl_nitro_a:
sRef 1:0:1:332E:45B:1:C00000:0:0:0:
Sat.1_a:
sRef 1:0:1:4E25:43A:1:C00000:0:0:0:
Sport1:
sRef 1:0:1:384:21:85:C00000:0:0:0:
Super_rtl_a:
sRef 1:0:1:708F:443:1:C00000:0:0:0:
Swr_bw_hd:
sRef 1:0:19:283F:3FB:1:C00000:0:0:0:
Servustv_hd_oesterreich:
sRef 1:0:19:1331:3EF:1:C00000:0:0:0:
Sky_3d:
sRef 1:0:19:75:A:85:C00000:0:0:0:
Sky_action_hd:
sRef 1:0:19:74:B:85:C00000:0:0:0:
Sky_atlantic_hd:
sRef 1:0:19:6E:D:85:C00000:0:0:0:
Sky_cinema+1_hd:
sRef 1:0:19:86:8:85:C00000:0:0:0:
Sky_cinema+24_hd:
sRef 1:0:19:87:8:85:C00000:0:0:0:
Sky_cinema_hd:
sRef 1:0:19:83:6:85:C00000:0:0:0:
Sky_comedy:
sRef 1:0:1:8:2:85:C00000:0:0:0:
Sky_emotion:
sRef 1:0:1:14:2:85:C00000:0:0:0:
Sky_hits_hd:
sRef 1:0:19:6B:C:85:C00000:0:0:0:
Sky_krimi:
sRef 1:0:1:17:1:85:C00000:0:0:0:
Sky_nostalgie:
sRef 1:0:1:204:3:85:C00000:0:0:0:
Sky_select_hd:
sRef 1:0:19:78:E:85:C00000:0:0:0:
Sky_sport_hd_1:
sRef 1:0:19:81:6:85:C00000:0:0:0:
Sky_sport_news_hd:
sRef 1:0:19:6C:C:85:C00000:0:0:0:
Spiegel_geschichte_hd:
sRef 1:0:19:89:8:85:C00000:0:0:0:
Syfy_hd:
sRef 1:0:19:7E:C:85:C00000:0:0:0:
Tele_5:
sRef 1:0:1:33:21:85:C00000:0:0:0:
Tnt_film_(tcm):
sRef 1:0:1:23:F:85:C00000:0:0:0:
Tnt_glitz_hd:
sRef 1:0:19:88:8:85:C00000:0:0:0:
Tnt_serie_hd:
sRef 1:0:19:7B:B:85:C00000:0:0:0:
Tectime_tv:
sRef 1:0:16:1523:455:1:C00000:0:0:0:
Universal_hd:
sRef 1:0:19:65:E:85:C00000:0:0:0:
Vox_austria:
sRef 1:0:1:7085:443:1:C00000:0:0:0:
Wdr_hd_k��ln:
sRef 1:0:19:6EA5:4B1:1:C00000:0:0:0:
Zdf_hd:
sRef 1:0:19:2B66:3F3:1:C00000:0:0:0:
Zdfinfo_hd:
sRef 1:0:19:2BA2:3F2:1:C00000:0:0:0:
Arte_hd:
sRef 1:0:19:283E:3FB:1:C00000:0:0:0:
Hr-fernsehen:
sRef 1:0:1:6DCC:44D:1:C00000:0:0:0:
Kabel_eins_classics:
sRef 1:0:1:4462:453:1:C00000:0:0:0:
N-tv:
sRef 1:0:1:2F3A:441:1:C00000:0:0:0:
Rbb_berlin:
sRef 1:0:1:6E2E:431:1:C00000:0:0:0:
Tagesschau24:
sRef 1:0:1:7031:41B:1:C00000:0:0:0:
Zdf.kultur_hd:
sRef 1:0:19:2B84:3F3:1:C00000:0:0:0:
Zdf_neo_hd:
sRef 1:0:19:2B7A:3F3:1:C00000:0:0:0:
Channels:
radio:
HITRADIO_OE3
tv:
ORF1_HD
NatGeo_HD
Discovery_HD
History_HD
ZDFinfo_HD
DMAX
Spiegel_Geschichte_HD
arte_HD
PHOENIX_HD
zdf_neo_HD
ServusTV_HD_Oesterreich
13th_Street_HD
Sky_3D
Sky_Cinema_HD
Sky_Cinema+1_HD
Sky_Cinema+24_HD
Sky_Atlantic_HD
Sky_Action_HD
Sky_Hits_HD
Sky_Comedy
Nat_Geo_Wild_HD
Universal_HD
Syfy_HD
TNT_Serie_HD
TNT_Film_(TCM)
TNT_Glitz_HD
AXN_HD
A&E
Eurosport_HD
ORF_SPORT+_HD
SPORT1
ORF2K_HD
ATV_HD
ATV2
PULS_4_Austria
ProSieben_Austria
VOX_Austria
RTL_Austria
RTL2_Austria
SAT.1_A
Kabel_1_Austria
ZDF_HD
Das_Erste_HD
3sat_HD
zdf.kultur_HD
RTL_Crime
Sky_Krimi
MGM_HD
RTLNITRO
Disney_Cinemagic_HD
KiKA_HD
Disney_Channel
Nickelodeon
Disney_Junior
Nicktoons_(S)
Cartoon_Network_(S)
n-tv
N24
Bloomberg_Europe_TV
TecTime_TV
Comedy_Central/VIVA
HITRADIO_OE3
RTL_NITRO_A
Sky_Select_HD
Sky_Emotion
Sky_Nostalgie
Sky_Sport_HD_1
Sky_Sport_News_HD
ProSieben_MAXX
kabel_eins_classics
ORF_III
Motorvision_TV
HITRADIO_OE3
Comedy_Central_/_VIVA_AT
SUPER_RTL_A
tagesschau24
ARD-alpha
TELE_5
hr-fernsehen
NDR_FS_NDS_HD
BR_Nord_HD
WDR_HD_Köln
SWR_BW_HD
MDR_Sachsen
rbb_Berlin
Attributes:
alias VU+ Solo2
bouquet-radio 1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.radio" ORDER BY bouquet
bouquet-tv 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.tv" ORDER BY bouquet
devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
event-on-change-reading .*
group Fernseher
http-method GET
icon dreambox
power-off 0.0
power-on 17.5
room 1. Wohnzimmer
steckdosen struct_steckdosen
userReadings eventend_hr { receiverEndZeiten("current") },eventend_next_hr { receiverEndZeiten("next") }
userattr steckdosen steckdosen_map structexclude
verbose 2
webCmd channel:input Grüße
Hi,
wir hatten vor einiger das Problem mit dem Jaluosieschaltern HM-LC-Bl1PBU-FM. Bei mir war 100% auf und im smartvisu ist 100% zu.
Habe dazu im Wiki folgendes gefunden:
ZitatAttribute
Dem Device können neben den Allgemeinen auch spezielle Attribute gesetzt werden.
param levelInverse: HM Blind Aktoren stehen auf 100% wenn sie offen sind und auf 0% wenn sie geschlossen sind. Das ist oftmals nicht intuitiv. In FHEM kann man dies "drehen" durch dieses Attribut. Damit dreht sich auch die Bedeutung von On und Off.
Brauchte noch nicht mal die Schalter drehen! ;D
Jetzt kann ich die Schalter von smartvisu ganz normal nutzen!
Lutz
Zitat von: fhainz am 24 Januar 2015, 15:53:46
Bei einem Klick/Slide wird nur die set funktion von wzReceiver aufgerufen und die schaltet auf mute. Am state ändert sich nichts, somit sollte {{ basic.switch('s2.2', 'wz.receiver') }} auch nicht reagieren, oder?
Du meinst bei mute wird set aufgerufen, richtig ?
Schau und poste mal bitte was im eventmonitor passiert wenn Du mute in sv drückst
vg
jörg
Tantte Edith ergänzt:
vmtl ist es hilfreich zu verstehen wie der converter arbeitet. Beim reload wird das eingestellte reading aktiv gelesen. Danach werden (als push) die events gelesen und fronthem schaut ob, nach normalen fhem Konventionen, hier das reading gemeint ist. Die Technik hat Grenzbereiche, Beispiel: dev a: 23 b: 45. Ist das nun der state "a: 23 b: 45" oder das Reading "a" mit "23 b: 45" ?? Deswegen gingen am Anfang keine Zeiten (wegen dem ":"). Vmtl erzeugt das device events die einen "falschen Alarm" triggern.
Zitat von: herrmannj am 24 Januar 2015, 16:22:15
Du meinst bei mute wird set aufgerufen, richtig ?
Nach dem klick/slide wird in smartvisu der off text und das off icon angezeigt. In FHEM passt alles, da wird auch nur zB mute geändert.
Ich hänge ein Video an.
Zitat von: herrmannj am 24 Januar 2015, 16:22:15
Schau und poste mal bitte was im eventmonitor passiert wenn Du mute in sv drückst
Nichts besonderes ausser das das Modul den Befehl 2x ausführt.
015-01-24 17:25:46.647 ENIGMA2 wzReceiver mute on
2015-01-24 17:25:46.661 ENIGMA2 wzReceiver mute off
2015-01-24 17:25:46.671 ENIGMA2 wzReceiver mute: onGrüße
Zitat von: fhainz am 24 Januar 2015, 17:47:11
Nach dem klick/slide wird in smartvisu der off text und das off icon angezeigt. In FHEM passt alles, da wird auch nur zB mute geändert.
Ich hänge ein Video an.
Nichts besonderes ausser das das Modul den Befehl 2x ausführt.
015-01-24 17:25:46.647 ENIGMA2 wzReceiver mute on
2015-01-24 17:25:46.661 ENIGMA2 wzReceiver mute off
2015-01-24 17:25:46.671 ENIGMA2 wzReceiver mute: on
Grüße
bei den ersten beiden fehlt der doppeltpunkt, den sieht der converter daher als state ?
Wahrscheinlich ist das auch der state und dann kannst Du OnOff nicht nehmen.
Daher:
steht im state tatsächlich nur "on" oder "off" ? Oder manchmal auch "Mute on" ?
Du musst Dir entweder für An/Aus ein anderes Reading suchen oder den direct converter nehmen und in sv auf "on" und "off" prüfen.
vg
Jörg
Zitat von: herrmannj am 24 Januar 2015, 18:39:41
bei den ersten beiden fehlt der doppeltpunkt, den sieht der converter daher als state ?
Wahrscheinlich ist das auch der state und dann kannst Du OnOff nicht nehmen.
Daher:
steht im state tatsächlich nur "on" oder "off" ? Oder manchmal auch "Mute on" ?
Du musst Dir entweder für An/Aus ein anderes Reading suchen oder den direct converter nehmen und in sv auf "on" und "off" prüfen.
Warum bei den ersten beiden Events der : fehlt weiß ich nicht. Das state Reading des receiver devices wird wirklich nur beim Ein-/Ausschalten des Receiver schrieben, sonst nicht.
Der mute Button ist ja nur ein Beispiel. Der off text/icon wird auch angezeigt wenn ich den den volume regler ändere oder den pause knopf drücke. Kann es sein das die Verbindung zu dem device verloren geht wenn eine set funktion auferufen wird?
Ich hab jetzt testweise dem mute button mit dem OnOff Converter verknüpft, jetzt wird das mute reading nur mehr auf on gesetzt auf off nicht mehr :o Das icon ändert sich auch nicht wenn ich auf der Fernbedienung mute schalte und warte bis das Modul das mute reading aktualisiert. Der off text/icon wird auch hier angezeigt.
Mit dem Direct Converter passt das Icon immer und das mute reading wird auch richtig gesetzt.
Grüße
Edit:Volume ändern sieht im event monitor so aus:
2015-01-24 19:36:32.546 ENIGMA2 wzReceiver volume 60
2015-01-24 19:36:32.576 ENIGMA2 wzReceiver volume: 60
2015-01-24 19:36:33.183 ENIGMA2 wzReceiver volume 40
2015-01-24 19:36:33.207 ENIGMA2 wzReceiver volume: 40
2015-01-24 19:36:34.101 ENIGMA2 wzReceiver volume 20
2015-01-24 19:36:34.127 ENIGMA2 wzReceiver volume: 20
2015-01-24 19:36:34.773 ENIGMA2 wzReceiver volume 45
2015-01-24 19:36:34.800 ENIGMA2 wzReceiver volume: 45Edit2:Ich hab auch noch 2 Buttons die das harmony modul trigger. Da ändert sich weder der Eingeschaltet Text noch das Icon. In FHEM sind die Buttons mit direct und einer set funktion verknüpft, kein reading.
Zitat von: fhainz am 24 Januar 2015, 19:25:16
Warum bei den ersten beiden Events der : fehlt weiß ich nicht. Das state Reading des receiver devices wird wirklich nur beim Ein-/Ausschalten des Receiver schrieben, sonst nicht.
Der mute Button ist ja nur ein Beispiel. Der off text/icon wird auch angezeigt wenn ich den den volume regler ändere oder den pause knopf drücke. Kann es sein das die Verbindung zu dem device verloren geht wenn eine set funktion auferufen wird?
Ich hab jetzt testweise dem mute button mit dem OnOff Converter verknüpft, jetzt wird das mute reading nur mehr auf on gesetzt auf off nicht mehr :o Das icon ändert sich auch nicht wenn ich auf der Fernbedienung mute schalte und warte bis das Modul das mute reading aktualisiert. Der off text/icon wird auch hier angezeigt.
Mit dem Direct Converter passt das Icon immer und das mute reading wird auch richtig gesetzt.
Grüße
da geht nix verloren.
Das device sendet "mute on" als state und Du hast den state mit OnOff verbunden -> funktioniert nicht. Da musst Du Dir was anderes überlegen.
vg
jörg
2015-01-24 20:06:55.749 ENIGMA2 wzReceiver mute off
2015-01-24 20:06:55.776 ENIGMA2 wzReceiver mute: off
Könnte das erste event nicht das event sein das modul auslösen lässt und das zweite das event durchs readings schreiben? Ich hab im ENIGMA Modul alles kommentiert was zum mute befehl gehört, bis auf die set funktion (für das set-dropdown) selbst. Es wird kein Reading generiert und auch am receiver nicht mehr gemutet. Das Event ist trotzdem da.
2015-01-24 20:13:52.822 ENIGMA2 wzReceiver mute on
Das harmony modul generiert auch so ein event wenn ich zB den Kanal mit set harmony command DirectionRight umschalte.
2015-01-24 20:15:19.250 harmony harmony command DirectionRight
Grüße
Zitat von: fhainz am 24 Januar 2015, 20:22:48
2015-01-24 20:06:55.749 ENIGMA2 wzReceiver mute off
2015-01-24 20:06:55.776 ENIGMA2 wzReceiver mute: off
Könnte das erste event nicht das event sein das modul auslösen lässt und das zweite das event durchs readings schreiben? Ich hab im ENIGMA Modul alles kommentiert was zum mute befehl gehört, bis auf die set funktion (für das set-dropdown) selbst. Es wird kein Reading generiert und auch am receiver nicht mehr gemutet. Das Event ist trotzdem da.
2015-01-24 20:13:52.822 ENIGMA2 wzReceiver mute on
Das harmony modul generiert auch so ein event wenn ich zB den Kanal mit set harmony command DirectionRight umschalte.
2015-01-24 20:15:19.250 harmony harmony command DirectionRight
Grüße
Hör off :), brauchst nicht im modul zu ändern. Das geht doch viel einfacher. Trotzdem, beides kommt vom modul und der autor hat sich sicher auch was dabei gedacht.
Die Logik zwischen reading und namen ist einfach, wenn am Anfang ein Name gefolgt von einem Doppelpunkt steht meldet das modul ein reading, fehlt der meldet das modul den state.
In Deinem Fall kannst Du:
bei state bleiben, als converter "direct" nehmen und in sv explizit die beiden Zustände Deines Button angeben: "on" und "off".
Das wäre mir aber zu doof - Variante 2:
mach Dir ein userreading "power" mit {Value(<devicename>)}. Dann kannst Du "on" und "off" wie gewollt über das reading "power" abgreifen und alles flutscht.
vg
jörg
Ihr Lieben, dieser Thread mit 71 Seiten und 1050 Posts wird etwas unübersichtlich. Wäre es nicht an der Zeit für ein Smartvisu Unterforum unter Frontends?
... ich muss die jeden Abend auswendig lernen ;)
hast recht. Fürs erste wäre es vmtl schon ganz hilfreich für neue Themen wie zum Beispiel "wie mache ich" etc einen neuen thread aufzumachen. Ich mag hier noch offen lassen um Themen die sich speziell mit fronthem beschäftigen aufzunehmen. Mittlerweile kommen ja kaum noch bugs rein, aber möglich wäre das schon noch...
In diesem Sinne, alles was sich mit "wie mache ich" in Smartvisu beschäftigt einen neuen thread ? Und hier nur noch bugs etc zu fronthem ?
Btw, die Beta hatte gestern Geburtstag und wurde einen Monat alt. Die 1000 Posts haben wir in weniger als 4 Wochen geschafft 8)
vg
jörg
Zitat von: herrmannj am 24 Januar 2015, 21:12:39
mach Dir ein userreading "power" mit {Value(<devicename>)}. Dann kannst Du "on" und "off" wie gewollt über das reading "power" abgreifen und alles flutscht.
Das Modul hat schon zusätzlich ein power reading. Nur kombiniert mit cmd set state funktioniert das ein/ausschalten nicht mehr. Das Modul hat aber noch eine toggle set funktion, mit dieser klappt es nun, danke!
Ich hab vorher mal die converter durchgesehen.
$event = ($reading eq 'state')?main::Value($device):main::ReadingsVal($device, $reading, 'off');Value() ließt ja STATE ein, dieser kann mit stateFormat geändert werden. Wäre hier nicht ReadingsVal("<name>", "state", "") geschickter da das Reading state immer den state abbildet?
Grüße
naja, STATE ist ja das was der user sieht. Mancher nimmt stateFormat ja auch ganz bewusst. vg jörg
Alles klar. Danke für deine Geduld :D
Glückwunsch zum ersten Monat! Ich habe mich weiter mit Oberflächengestaltung und Widget-Optimierung beschäftigt und folgenden Stand erreicht:
- Rooms_menu mit aktiven Icons für Presence und Heizung (leider css-Fummelei)
- FRITZBOX User: das sind ja unterschiedlich viele mit unterschiedlichen Nummern, also habe ich einfach 50 Zeilen in SV angelegt, mit 50 x 4 Readings des FritzBox FHEM Devices gekoppelt User1 bis User50, auch wenn einige davon ja gar nicht existieren. Die leeren Zeilen habe ich durch ein Basic.hide() Widget wieder ausgeblendet, wenn die gelieferten Namen leer waren. Performance mäßig grauenhaft, läuft aber stabil.
- die Timer-Popups für hm-cc und hm-tc nutzen jetzt die temperaturlisten - Funktion des HMInfo Moduls in fhem, was aber aufgrund der teilweise minutenlangen Verzögerungen beim einlesen und setzen der timestrings noch nicht schön funktioniert
- das falsche ü (interessanterweise der einzige Umlaut in meinem SV, der aus FHEM kommt) konnte ich durch ein regexp Ersetzungs-widget ersetzen, hat aber bisher nur bei mir funktioniert
Wie siehts bei Euch aus? Lasst doch auch mal ein paar Screenshots sehen, zum Geburtstag sozusagen!
Fettes Lob an Jörg für den Fleiß und die unermüdliche Freundlichkeit, mit der er sich hier um alles kümmert!
Gesendet von iPhone mit Tapatalk
Das ist doch eine gute Idee, da mache ich gleich mal mit.
Bin in sv noch nicht so weit wie Bernd, kann das aber mit der Arbeit an fronthem erklären :). Einige Fotos vom Wohnzimmer Tab (schlechte Quali, sorry).
Die mitgelieferte Uhr war mir zu hektisch, die habe ich ersetzt. Noch aktualisiert sie das Datum nicht, Wecker und Wetter fehlen mir noch (beim Wetter möchte ich ebenfalls un-aufgeregtere Symbole).
Den RTR habe ich ebenfalls zusammengestrichen, die ganzen Geschichten mit day/night etc benötige ich nicht - und auf dem 7" Tablett ist auch nicht so viel Platz. Die Batterie Anzeige nimmt drei GAD, einen vom TC und zwei von den VC. Die sind "and" verknüpft. Wenn einer der drei auf "low" geht (meine TC, VD sagen mir nicht die Volt, nur ok, low, critical) dann steht eine zweite "OR" verknüpfte an dieser Stelle die dann ein farbiges Batterie Low Symbol anzeigt. Dann muss ich an den Geräten schauen welcher das ist, reicht mir als Info. Evtl setze ich noch mal einen Dialog dazu, der könnte dann direkt sagen welcher es ist. Die Funktion lässt sich auch gut mit einem trigger testen.
Auf der Beleuchtungsseite gibt es nichts neues. Der Platz rechts neben den slider ist für buttons vorgesehen um in die Automatiken einzugreifen. Der RGB muss leider extra sein, ich habe mittlerweile raus gefunden das der shifter keine svg icons kann, da werde ich evtl nochmal ein widget schreiben um die Farbwahl besser auf das Symbol zu legen.
So long, vg
jörg
Zitat von: bgewehr am 24 Januar 2015, 22:14:49
Wie siehts bei Euch aus? Lasst doch auch mal ein paar Screenshots sehen, zum Geburtstag sozusagen!
Herzlichen Glückwunsch zum Geburtstag :D
Ich habe neben FHEM noch eine Steuerung für die Heizung, die Daten und Logs als JSON liefert. Mein Ziel war es, das Frontend, das ich für die mal geschrieben hatte, mit in SV zu integrieren.
Als Fan von Übersichtsseiten habe ich erst mal eine solche erstellt.
Auf der Hardcopy zu sehen:
Die Temperaturen links kommen von FHEM und stammen von TX29DTH, TX35DTH, usw. Das ist neun mal das widget_temp_sensor.
Die Werte für die Heizung kommen ebenfalls von FHEM. "Befehl" und "Status" werden von einem "LED-Widget" dargestellt (das ich bei Bedarf gerne noch zur Verfügung stelle)
"Füllstand Scheune" ist ein Regenwassertank, der in FHEM einen Levelsender hat (36_Level.pm)
In "System" (noch nicht ganz fertig) hole ich Werte, die ich mir in FHEM mit einem 98_CustomReadings.pm zusammenstelle.
Der Plot für die Heizung holt die Daten direkt von der Heizungssteuerung (also ohne dass FHEM da beiteiligt ist). Dazu verwende ich angularjs und nvd3, was ich etwas angepasst aus meinem alten "Heizungsfrontend" übernommen habe.
Das Wetter kommt von daswetter.at
Das (natürlich nur auf dem Tablet) seitenfüllende Layout ist im Wesentlichen css
Ich habe keinerlei Anpassungen in SV selbst gemacht, es läuft also ein völlig unverändertes SV. Alle Anpassungen und Erweiterungen, die ich gebraucht habe, waren in visu.css, visu.js usw. in meinem page-Verzeichnis machbar.
Aktuell beginne ich die einzelnen Räume zu implementieren.
Verwendete Komponenten:
- Ein Cubietruck mit "Igor Debian", lighttpd, FHEM, JeeLink, CUL, der per Kabel im LAN hängt
- Ein 10" Android Tablet als "Family-Frontend-Device" von dem der Screenshot stammt
- Diverse Android-Telefone
- FireFox und Chrome auf dem PC zum Entwickeln
Vielen Dank für Anbindung von SV an FHEM. Das ist genau das was ich brauche. Ein Frontend für FHEM, das aber für meine eigenen Erweiterungen offen ist und sich so erweitern lässt, dass ich meine Usecases abdecken kann.
Um die success story jetzt nicht zu ruinieren, lasse ich mich über die aktuellen Problemchen und Wünsche (bei denen aber nichts Dramatisches dabei ist) in einem anderen Beitrag aus ;D
Aber eins hat die SV-Anbindung in den vier Wochen bei mir
nie geschafft: FEHM abstürzen lassen
Nachtrag: Die Stromaufnahme des Cubietriuck ist natürlich nicht 0,371 mA sondern 0,371 A :-[
Zitat von: bgewehr am 24 Januar 2015, 22:14:49
[...]
- die Timer-Popups für hm-cc und hm-tc nutzen jetzt die temperaturlisten - Funktion des HMInfo Moduls in fhem, was aber aufgrund der teilweise minutenlangen Verzögerungen beim einlesen und setzen der timestrings noch nicht schön funktioniert
[...]
Fettes Lob an Jörg für den Fleiß und die unermüdliche Freundlichkeit, mit der er sich hier um alles kümmert!
Gesendet von iPhone mit Tapatalk
Hallo,
ich nutze zur Zeit nw_tiles in Verbindung mit den Standard-Boxen. Zu viel mehr bin ich noch nicht gekommen.
Wie hast Du denn die Temperaturlisten umgesetzt? Findet sich da etwas zu in Deinem github?
Das finale Design werde ich wohl erst anlegen, wenn plots funktionieren.
Was jetzt noch schön wäre, ist ein Fernzugang. Leider lässt sich mit Fritzbox und Android aus irgendwelchen Gründen das VPN nicht einrichten. Die Fritzbox-Startseite ist erreichbar und Internet auch, aber Heimnetz nicht... Wird das irgendwann auch ohne VPN gehen?
Ansonsten schließe ich mich mal an: Glückwunsch und riesiges Lob für das bisherige Ergebnis! Und danke für den support :)
schöne Grüße
Jo
Zitat von: Jojo11 am 25 Januar 2015, 09:59:46
Wie hast Du denn die Temperaturlisten umgesetzt? Findet sich da etwas zu in Deinem github?
Was jetzt noch schön wäre, ist ein Fernzugang. Leider lässt sich mit Fritzbox und Android aus irgendwelchen Gründen das VPN nicht einrichten.
Ja, ist alles im GitHub. Ich nutze mein HM-TC-Timer widget aus der widget_homematic, das als popup in der widget_popup hinterlegt ist und von dem list.rtr widget in der widget_list aufgerufen wird.
Die Textzeilen im Popup lesen und schreiben direkt die Readings. Mit den Buttons möchte ich nun die Fähigkeiten von HMInfo hinzufügen, aber das ist irgendwie noch bockig und verlangt hier und da irgendwelche Verifizierungen, die ich aber aktuell noch nicht verstanden habe.
Hier die fronthem-Config dazu:
"WZ_rtr_init" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "hminfo",
"set" : "tempList -f Raumthermostat_WZ restore tmpList.cfg "
},
"WZ_rtr_save" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "hminfo",
"set" : "tempList -f Raumthermostat_WZ save Raumthermostat_WZ.cfg "
},
"WZ_rtr_restore" : {
"reading" : null,
"type" : "item",
"converter" : "Direct",
"device" : "hminfo",
"set" : "tempList -f Raumthermostat_WZ restore Raumthermostat_WZ.cfg "
},
"WZ_rtr_prog" : {
"reading" : "R-weekPrgSel",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "regSet weekPrgSel"
},
"WZ_rtr_p1_fri" : {
"reading" : "R_P1_6_tempListFri",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListFri"
},
"WZ_rtr_p1_sat" : {
"reading" : "R_P1_0_tempListSat",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListSat"
},
"WZ_rtr_p1_sun" : {
"reading" : "R_P1_1_tempListSun",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListSun"
},
"WZ_rtr_p1_mon" : {
"reading" : "R_P1_2_tempListMon",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListMon"
},
"WZ_rtr_p1_tue" : {
"reading" : "R_P1_3_tempListTue",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListTue"
},
"WZ_rtr_p1_wed" : {
"reading" : "R_P1_4_tempListWed",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListWed"
},
"WZ_rtr_p1_thu" : {
"reading" : "R_P1_5_tempListThu",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : "tempListThu"
},
Wie gesagt, klappt bisher nur mäßig mit den Tasten. Manuell geht aber ganz gut!
Fritzbox-VPN ist gar nicht so schwer, trau Dich nochmal ran! Du kannst einfach einen neuen User an der Fritze anlegen, den als VPN User erklären und die Angaben für Dein Smartphone direkt als Popup an der Fritze angezeigt bekommen. Wirst Du sicher schaffen!
Liebe FHEM´ler,
seit 2 Tagen "spiele" ich nun schon ein wenig mit fronhem und smartVISU und ich muss sagen, das dies eigentlich genau das ist, was fhem (und ich) braucht.
Ich würde es auch sehr begrüssen, wenn das Thema in einem separaten Threat behandelt werden würde, da man langsam wirklich die übersicht verliert. Natürlich auch dem großen Interesse und der tollen Umsetzung geschuldet.
Ich hätte noch ein paar Anfängerfragen:
1. Ich berechne Strom- und Gasleistung in FHEM. Wie schaffe ich die Darstellung in smartVISU au 2 Nachkommastellen zu reduzieren?
2. Leider schaffe ich es (noch) nicht, den plot sauber hinzukriegen. Das Beispiel von HCS sieht ja super aus. Kannst Du dies einmal zur Verfügung stellen?
3. Wunderground wetter zeigt mir die Temperaturen nur in Grad Fahrenheit an. Wo wird das umgestellt?
Danke im Voraus
Gerd
Zitat von: herrmannj am 24 Januar 2015, 23:56:53
ich habe mittlerweile raus gefunden das der shifter keine svg icons kann, da werde ich evtl nochmal ein widget schreiben um die Farbwahl besser auf das
Ich glaube da einen Fehler entdeckt zu haben:
Der Shifter nutzt icon.html für SVG, diese läd aber nicht ohne {% import "icon.html" as icon %} (bei mir jedenfalls).
Füge das doch mal in basic.shifter hinzu und versuch es nochmal...
Edit:
steht schon drin, aber die Syntax habe ich noch nie woanders in SV gesehen:
{{ attribute(icon, pic_on|slice(5), [id, gad_switch, gad_value, '', min, max]) }}
Wer weiß, was das bedeutet {{ atribute() }}?
Das ,'' , scheint mir falsch zu sein, die Definition ist doch:
{{ basic.shifter('svg2', '', 'gad_val', 'icon.battery', '', 2.1, 3) }}
aber
{% macro graph(id, gad_switch, gad_value, min, max) %}
Also müsste doch der basic shifter ein icon.xy mit [id, gad_switch, gad_value, min, max] erstellen und nicht mit [id, gad_switch, gad_value, '', min, max], oder?
Zitat von: bgewehr am 25 Januar 2015, 11:38:09
[...]
Wie gesagt, klappt bisher nur mäßig mit den Tasten. Manuell geht aber ganz gut!
Fritzbox-VPN ist gar nicht so schwer, trau Dich nochmal ran! Du kannst einfach einen neuen User an der Fritze anlegen, den als VPN User erklären und die Angaben für Dein Smartphone direkt als Popup an der Fritze angezeigt bekommen. Wirst Du sicher schaffen!
Danke, dann schaue ich mir das mal an.
Die Fritte und VPN wollen nicht. Neuen Benutzer angelegt, VPN eingerichtet, VPN am handy (Android 4.4.4) eingerichtet, verbunden. Verbunden ist es und surfen kann ich auch, aber alle Adressen im LAN sind nicht verfügbar, außer die Startseite der Fritzbox ??? ??? ???
Leider finde ich zu diesem Verhalten auch wenig hilfreiches.
schöne Grüße
Jo
Häng mal ein .fritz.box an Deine Rechnernamen dran... IP probiert?
Gesendet von iPhone mit Tapatalk
Häng mal ein .fritz.box an Deine Rechnernamen dran... IP probiert?
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 25 Januar 2015, 13:12:01
Häng mal ein .fritz.box an Deine Rechnernamen dran... IP probiert?
Gesendet von iPhone mit Tapatalk
Naja, ich habe sie über IPs versucht aufzurufen.
Standard wäre ja z.B. 192.168.178.1 Fritte und dann 192.168.178.2:8084 z.B. fhem usw.
.1 geht, aber der Rest nicht.
Meinst Du
192.168.178.2.fritz.box:8084?
fritz.box geht. Der leitet ja nur auf die IP der Startseite um (also .1 im obigen Bsp).
Eigentlich gibt es ja aber gar keine Einstellmöglichkeiten mehr. subnetz usw. kann ich ja nirgends angeben.
schöne Grüße
Jo
Ich meinte FQDN also fhem.fritz.box oder so... Denk daran, dass du über VPN eine andere IP Adresse hast und dies in FrontHEM anlegen musst.
Gesendet von iPhone mit Tapatalk
Naja, bei smartVISU bin ich ja noch gar nicht. Ich dachte, ich müsste überhaupt erstmal meine normale fhem-Oberfläche erreichen, um zu sehen, dass es generell funktioniert. Ich kann auch nicht per Android SSH client auf die Rechner zugreifen. Das sagt mir, dass das generell was nicht stimmt ;D
schöne Grüße
Jo
@HCS: dein "Style" gefällt mir sehr gut. du nanntes "widget_temp_sensor". kannst du es anhängen? ggf deine gesamte page?
EDIT: widget ist aus Antwort #339 denke ich...
Hallo Jo,
hast du den vpn mit der Software von Avm eingerichtet?
Geht es dir nur um die android Verbindung? Funktioniert es mit nem Rechner? Ich kann mich daran erinnern das vpn mit Android zur Fritzbox, damals nicht mit der Standard vpn Software in android funktionierte.
Mit einer anderen vpn app hingegen schon.
Ansonsten gab es auch Anleitungen zur Einrichtung eines vpn für die Fritzbox.
Grüße
Zitat von: fidel am 25 Januar 2015, 14:11:09
Hallo Jo,
hast du den vpn mit der Software von Avm eingerichtet?
Geht es dir nur um die android Verbindung? Funktioniert es mit nem Rechner? Ich kann mich daran erinnern das vpn mit Android zur Fritzbox, damals nicht mit der Standard vpn Software in android funktionierte.
Mit einer anderen vpn app hingegen schon.
Ansonsten gab es auch Anleitungen zur Einrichtung eines vpn für die Fritzbox.
Grüße
Nein, im aktuellen Fritz.OS geht es anscheinend ohne AVM-Software. Habe es bisher nur auf dem handy probiert. Hatte auch mal was gelesen, dass eine extra app evtl gehen würde. Das werde ich als nächstes testen.
Danke!
schöne Grüße
Jo
Ich hatte damals dafür vpncilla...
Zitat von: fidel am 25 Januar 2015, 14:24:58
Ich hatte damals dafür vpncilla...
Gerade getestet, damit geht noch weniger.
Ich glaub ich lass das mal wieder :-\
schöne Grüße
Jo
Zitat von: chris1284 am 25 Januar 2015, 14:09:27
@HCS: dein "Style" gefällt mir sehr gut. du nanntes "widget_temp_sensor". kannst du es anhängen? ggf deine gesamte page?
EDIT: widget ist aus Antwort #339 denke ich...
Ja, das ist es. Habe es aber noch etwas erweitert, um zu steuern, ob Feuchte und Batterie vorhanden sind.
Doku siehe header. Ich hänge es hier an.
Und das LED-widget hänge ich noch mit dazu.
Die erforderlichen Styles (müssen in die visu.css) und das script (muss in die visu.js) sind als Kommentar im header enthalten.
Zitat von: Gerd.Ternes am 25 Januar 2015, 12:21:30
2. Leider schaffe ich es (noch) nicht, den plot sauber hinzukriegen. Das Beispiel von HCS sieht ja super aus. Kannst Du dies einmal zur Verfügung stellen?
Die Daten im Plot kommen nicht aus FHEM. Das ist angularjs und nvd3 und hillft Dir nichts für FHEM.
Die Routine ist genau für meine Heizungssteuerung geschrieben.
Da musst Du warten, bis herrmannj die Plots eingebaut hat.
Zitat von: chris1284 am 25 Januar 2015, 14:09:27
@HCS: ... ggf deine gesamte page?
Die komplette page geht leider nicht.
Aber ich beschreibe gerne mal, wie es geht:
Das angehängte css enthält die erforderlichen Styles.
Basis ist {% extends "full.html" %}
Es gibt Blöcke, die 25% breit sind und welche, die 50% breit sind.
Beispiel 25% Block (class: hcs-block25): Die Temperaturen links in meiner Hardcopy:
<div class="hcs-block25">
<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>Temperaturen</h3>
<table width="100%">
<tr><td>{{ TempSensor.Data("Outside", "Außen Süd", "Temperature_Outside", "scene_day.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("OutsideNorth", "Außen Nord", "Temperature_OutsideNorth", "", "NH,FB") }}</td></tr>
<tr><td>{{ TempSensor.Data("Temperature_LivingRoom", "Wohnzimmer", "Temperature_LivingRoom", "scene_livingroom.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Temperature_GroundFloor", "EG", "Temperature_GroundFloor", "control_building_eg.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Penthouse", "DG", "Temperature_Penthouse", "control_building_2_s_dg.png", "NH,FB") }}</td></tr>
<tr><td>{{ TempSensor.Data("HobbyCellar", "Hobbykeller", "Temperature_Cellar_Hobby", "scene_workshop.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("StorageCellar", "Lagerkeller", "Temperature_Cellar_Storage", "scene_storeroom.png") }}</td></tr>
<tr><td>{{ TempSensor.Data("Mobile1", "Mobil 1", "Temperature_Mobile1") }}</td></tr>
<tr><td>{{ TempSensor.Data("Mobile2", "Mobil 2", "Temperature_Mobile2", "scene_bath.png") }}</td></tr>
</table>
</div>
</div>
</div>Beispiel 50% Block (class: hcs-block): Der plot in meiner Hardcopy:
<div class="hcs-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>Heizung</h3>
{{ HCS_Plot.Plot("HCS-Plot") }}
</div>
</div>
</div> Um die Blöcke (wo erforderlich) auf eine einheitliche Höhe zu bekommen, wird die Klasse hcs-min verwendet.
Beispiel: die System-werte aus meiner Hardcopy
<div class="hcs-block25">
<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>System</h3>
<div class="hcs-min">
{{ System.Values("System", "System") }}
</div>
</div>
</div>
</div>
Ich hänge das css und die overview page hier an. Die geht so bei Dir nicht, weil Dir widgets dazu fehlen, aber zum "abschauen" kann man sie nehmen.
@HCS, danke.
hatte in der zwischenzeit temp_sensor schon umgebaut gehabt um alle meine klima-sensoren (die von t über th mit und ohne bat und dewpoint) quer feld ein mit einem widget einbinden zu können. man kann nun anwählen was man haben will (temp, hum, dewpoint, battery, usw) und der tabellenstyle ist nun auf % statt px.
Hallo!
Hier mal meine bisherigen Ergebnisse. Basieren auf das full.html mit einigen Popups.
Sieht auch sehr schick aus.
Könntest du den Code für das Receiver Popup posten?
Klar.
html
<div id="pop_receiver" class="popup popupMittel" data-role="popup">
<a href="#" data-rel="back" data-role="button" data-icon="delete" data-iconpos="notext" class="ui-btn-right">Close</a>
<h4>Receiver</h4>
<table>
<tr>
<td>{{ basic.text('wz.receiver', 'wz.receiver', 'Eingeschaltet', 'Ausgeschaltet') }} seit {{ basic.value('wz.receiver.time', 'wz.receiver.time') }}</td>
</tr>
<tr>
<td>
<div data-role="controlgroup" data-type="horizontal" style="text-align: center;">
{{ basic.dual('wz.harmony.activity.receiver', 'wz.harmony.activity', icon1~'it_television.png', icon0~'it_television.png', 'Watch.TV') }}
{{ basic.dual('wz.harmony.activity.plex', 'wz.harmony.activity', icon1~'scene_scene.png', icon0~'scene_scene.png', 'Plex') }}
{{ basic.dual('wz.harmony.activity.tv', 'wz.harmony.activity', icon1~'it_pc.png', icon0~'it_pc.png', 'Watch.PC') }}
{{ basic.button('wz.harmony.activity.powerOff', 'wz.harmony.activity', '', 'icons/or/control_standby.png', 'powerOff' ) }}
</div>
<div data-role="controlgroup" data-type="horizontal" style="text-align: center;">
{{ basic.dual('wz.receiver.mute', 'wz.receiver.mute', icon1~'audio_volume_mid.png', icon1~'audio_volume_mute.png', 'on', 'off') }}
{{ basic.button('wz.receiver.sender.last', 'wz.receiver.sender.last', '', icon1~'control_arrow_left.png', 'DirectionLeft' ) }}
{{ basic.button('wz.receiver.play', 'wz.receiver.play', '', icon1~'audio_play.png', 'play' ) }}
{{ basic.button('wz.receiver.pause', 'wz.receiver.pause', '', icon1~'audio_pause.png', 'pause' ) }}
{{ basic.button('wz.receiver.stop', 'wz.receiver.stop', '', icon1~'audio_stop.png', 'stop' ) }}
{{ basic.button('wz.receiver.sender.next', 'wz.receiver.sender.next', '', icon1~'control_arrow_right.png', 'DirectionRight' ) }}
{{ basic.button('wz.receiver.record', 'wz.receiver.record', '', 'icons/or/audio_rec.png', 'record' ) }}
</div>
</td>
</tr>
<tr>
<td>
{{ basic.slider('wz.receiver.volume', 'wz.receiver.volume', 0, 100, 5) }}
</td>
</tr>
</table>
<div data-role="collapsible-set" data-theme="c" data-content-theme="a" data-mini="true">
<div data-role="collapsible" data-collapsed="true" >
<h3>Harmony Tasten</h3>
<div style="float: left;">
{{ basic.button('wz.harmony.command.dvr', 'wz.harmony.command', 'DVR', '', 'List' ) }}
{{ basic.button('wz.harmony.command.guide', 'wz.harmony.command', 'Guide', '', 'Guide' ) }}
</div>
<div data-type="horizontal" style="text-align: center; left: -50px; ">
{{ basic.button('wz.harmony.command.up', 'wz.harmony.command', '', 'arrow-u', 'DirectionUp' ) }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.left', 'wz.harmony.command', '', 'arrow-l', 'DirectionLeft' ) }}
{{ basic.button('wz.harmony.command.ok', 'wz.harmony.command', 'OK', '', 'Select' ) }}
{{ basic.button('wz.harmony.command.ok', 'wz.harmony.command', 'Exit', '', 'Exit' ) }}
{{ basic.button('wz.harmony.command.right', 'wz.harmony.command', '', 'arrow-r', 'DirectionRight' ) }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.down', 'wz.harmony.command', '', 'arrow-d', 'DirectionDown' ) }}
</div>
<br>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.rewind', 'wz.harmony.command', '', 'icons/ws/audio_rew.png', 'Rewind' ) }}
{{ basic.button('wz.harmony.command.play', 'wz.harmony.command', '', 'icons/ws/audio_play.png', 'Play' ) }}
{{ basic.button('wz.harmony.command.fastForward', 'wz.harmony.command', '', 'icons/ws/audio_ff.png', 'FastForward' ) }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.rec', 'wz.harmony.command', '', 'icons/or/audio_rec.png', 'Record' ) }}
{{ basic.button('wz.harmony.command.pause', 'wz.harmony.command', '', 'icons/ws/audio_pause.png', 'Pause' ) }}
{{ basic.button('wz.harmony.command.stop', 'wz.harmony.command', '', 'icons/ws/audio_stop.png', 'Stop' ) }}
</div>
<br>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.1', 'wz.harmony.command', '1', '', 'Number1' ) }}
{{ basic.button('wz.harmony.command.2', 'wz.harmony.command', '2', '', 'Number2' ) }}
{{ basic.button('wz.harmony.command.3', 'wz.harmony.command', '3', '', 'Number3') }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.4', 'wz.harmony.command', '4', '', 'Number4') }}
{{ basic.button('wz.harmony.command.5', 'wz.harmony.command', '5', '', 'Number5') }}
{{ basic.button('wz.harmony.command.6', 'wz.harmony.command', '6', '', 'Number6') }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.7', 'wz.harmony.command', '7', '', 'Number7') }}
{{ basic.button('wz.harmony.command.8', 'wz.harmony.command', '8', '', 'Number8') }}
{{ basic.button('wz.harmony.command.9', 'wz.harmony.command', '8', '', 'Number9') }}
</div>
<div data-type="horizontal" style="text-align: center;">
{{ basic.button('wz.harmony.command.teletext', 'wz.harmony.command', 'Text', '', 'Teletext') }}
{{ basic.button('wz.harmony.command.0', 'wz.harmony.command', '0', '', 'Number0') }}
{{ basic.button('wz.harmony.command.E', 'wz.harmony.command', 'E', '', '') }}
</div>
</div>
</div>
<!-- <br>
<h5>Betriebszeiten</h5>
<table>
<tr>
<td>Heute:</td>
<td>{{ basic.value('wz.receiver.heute', 'wz.receiver.heute') }}</td>
</tr>
<tr>
<td>Jahr:</td>
<td>{{ basic.value('wz.receiver.jahr', 'wz.receiver.jahr') }}</td>
</tr>
</table>-->
<br>
<h5>Aktuelle Sendung {{ basic.value('wz.receiver.sendung.von', 'wz.receiver.sendung.von', '', 'div') }} - {{ basic.value('wz.receiver.sendung.bis', 'wz.receiver.sendung.bis') }}</h5>
<table>
<tr>
<td>{{ basic.value('wz.receiver.sender', 'wz.receiver.sender') }}</td>
<td>{{ basic.value('wz.receiver.sendung', 'wz.receiver.sendung') }}</td>
</tr>
<tr>
<td colspan="2">{{ basic.value('wz.receiver.sendung.desc', 'wz.receiver.sendung.desc') }}</td>
</tr>
</table>
<br>
<h5>Nächste Sendung {{ basic.value('wz.receiver.next.sendung.von', 'wz.receiver.next.sendung.von', '', 'div') }} - {{ basic.value('wz.receiver.next.sendung.bis', 'wz.receiver.next.sendung.bis') }}</h5>
<table>
<tr>
<td>{{ basic.value('wz.receiver.next.sendung', 'wz.receiver.next.sendung') }}</td>
</tr>
<tr>
<td>{{ basic.value('wz.receiver.next.sendung.desc', 'wz.receiver.next.sendung.desc') }}</td>
</tr>
</table>
<br>
<h5>Aktuelle Aufnahmen</h5>
<table>
<tr>
<td>{{ basic.value('wz.receiver.aufname.sender', 'wz.receiver.aufname.sender') }}</td>
<td>{{ basic.value('wz.receiver.aufname.sendung', 'wz.receiver.aufname.sendung') }}</td>
</tr>
</table>
<br>
<h5>Geplante Aufnahmen um {{ basic.value('wz.receiver.aufname1.zeit', 'wz.receiver.aufname1.zeit') }}</h5>
<table>
<tr>
<td>{{ basic.value('wz.receiver.aufname1.sender', 'wz.receiver.aufname1.sender') }}</td>
<td>{{ basic.value('wz.receiver.aufname1.sendung', 'wz.receiver.aufname1.sendung') }}</td>
</tr>
<tr>
<td colspan="2">{{ basic.value('wz.receiver.sendung.desc', 'wz.receiver.sendung.desc') }}</td>
</tr>
</table>
<br>
<h5>HDD</h5>
<table>
<tr>
<td>{{ basic.value('wz.receiver.hdd.frei', 'wz.receiver.hdd.frei', 'GB') }} von {{ basic.value('wz.receiver.hdd.kapazitaet', 'wz.receiver.hdd.kapazitaet', 'GB') }} frei</td>
</tr>
</table>
</div>
css
.popupMittel {
margin-top: 20px;
width:420px;
height: auto;
font-size: 14px;
}
#pop_receiver table.klein { margin-left: 0; margin-right: auto; }
#pop_receiver table td:first-child { width: 25%; text-align: left; }
#pop_receiver table td:nth-child(2) { width: 75%; text-align: left; }
#pop_receiver div[data-role="collapsible-set"] { margin: 10px; }
#pop_receiver #room_wohnzimmer-wz_harmony_command_up { margin-left: -96px; }
Danke dir, dann werde ich mal anfangen das ohne das Harmony-Modul zu nutzen.
Morgen!
Könntet Ihr vielleicht sämtliche htmls und css der diversen Geräte in das Wiki packen? Dann wäre es vielleicht auch etwas aufgeräumter und wenn man was sucht findet man es schneller?!
Welche Gads-Einträge benötige ich alles für die Fritzbox (BGEWEHR), damit mir auch was angezeigt wird?
Gruß
Zitat von: Grimm80 am 26 Januar 2015, 09:18:57
Könntet Ihr vielleicht sämtliche htmls und css der diversen Geräte in das Wiki packen? Dann wäre es vielleicht auch etwas aufgeräumter und wenn man was sucht findet man es schneller?!
Steht dir frei das zu machen :)
Grüße
Hi,
habe noch einen Tipp!
Sollte jemand Änderungen an den *.js Dateien bearbeiten muss man daran denken, dass in der config.ini ganz unten vereinbart wird welche Version der Datei benutzt wird.
Zitatjs = 'min.js'
Hat mich wieder mal ein paar Nerven gekostet.
Gruß Lutz
... ich habe in der ini diesen Eintrag auf .js geändert und benutze jetzt die lesbare Fassung der Javascript Dateien. Ist eine Performance-Optimierung, also funktional nicht nötig, die kleinere zu verwenden. Wer meine Widgets ausprobieren möchte, sollte darauf achten, dass auch bei ihm .js in dem Parameter steht. Lutz hat's herausgefunden, vielen Dank!
Gesendet von meinem iPad mit Tapatalk
Hallo Jörg,
es ist wieder passiert. Aus heiterem Himmel - und ich hatte natürlich kein verbose 5 an, damit ich dir mehr schicken kann.
2015.01.27 00:01:31 1: fronthem: thread ws closed for unknown reason
meine Konsole, die die ganze Nacht mitgelaufen ist, zeigt gar nix an. Das letzt Mal am Tablet war jemand um 23:56 Uhr.
Die fronthem.err hat jetzt 6139 Zeilen mit diesem Inhalt
tried to send data before finishing handshake at FHEM/fhwebsocket.pm line 99.
Ob die alle von gestern sind oder schon ein paar Tage alt - kann ich leider nicht sagen.
Ich habe jedoch eine Spur - mein Tablet!
Readings
gateway fronthem 2015-01-26 23:48:13
identity 192.168.178.23 2015-01-26 23:48:12
protokoll 0.1 2015-01-26 23:51:52
state disconnected 2015-01-27 00:01:31
Fällt dir was auf? Richtig - die Zeit des disconnected state vom Tablet ist exakt die Zeit in der sich der ws abgeschalten hat.
Grüßle,
Olli
Hi Olli,
das ist absolut logisch - das schließen des ws löst das disconnect auf dem device aus.
Zitat
Die fronthem.err hat jetzt 6139 Zeilen mit diesem Inhalt
tried to send data before finishing handshake at FHEM/fhwebsocket.pm line 99.
Das ist hilfreich - Danke.
Hast Du einen Weg gefunden das schliessen des ws zu provozieren - zB durch wiederholtes Ausschalten des iconia ?
vg
jörg
genau das werde ich jetzt probieren.
Ich hab mein Iconia so eingestellt, dass es eigentlich die wlan verbindung im standby halten sollte - irgendwann (bisher spätesten nach einer Stunde) kommt der disconnect. Laufen lasse ich das gerade alles über webviewcontrol.
Sobald ich rausfinde wie ich das provozieren kann werde ich auch wieder verbose 5 einschalten.
Grüßle,
Olli
unterstützt wvc bei Dir websockets ?
Ich vorschlagen den gleichen browser wie immer zu nehmen und die Einstellungen wieder zurückzunehmen wie die waren und dann wiederholt sv bedienen, auschalten und so weiter..
vg
jörg
wvc funktioniert ganz normal. Also wie der normale Android Browser. MIT dem wvc ist es auch gestern abgestürzt...
Also mit oder ohne?
bei mir funktioniert wvc nicht mit ws, ab 4.4 soll das aber gehen. Dann passt das schon. Mach mal, Du kennst das ja am besten.
Ich drück die Daumen das es Abstürzt (verkehrte Welt :) ) ...
vg
jörg
mein iconia A200 (android 4.4.4) läuft mit smartvisu in wvc ganz stabil bisher. bin zu frieden. fehlt nur noch tts und sprachsteuerung über smartvisu in wvc :D
Zitat von: chris1284 am 27 Januar 2015, 17:43:52
mein iconia A200 (android 4.4.4) läuft mit smartvisu in wvc ganz stabil bisher. bin zu frieden. fehlt nur noch tts und sprachsteuerung über smartvisu in wvc :D
kommt!. bin dran, ist leider komplex.
Das bei Olli ist irgendwie was besonderes, aber muss ja trotzdem weg
vg
jörg
wenns wirklich nur am android 4.4 liegt , so hab ichs verstanden, ist die frage ob man hier den aufwand betreibt oder einfach das tab auf 4.4 zieht.
ne, ist deutlich komplexer. Außerdem hab ich Tabs und Wecker die ich nicht upgraden kann :)
im Augenblick versuche ich seid gefühlten 500Millionen Jahren diesen nullpointer zu lösen
at org.apache.cordova.CordovaWebViewClient.onPageStarted(CordovaWebViewClient.java:144)
Das schöne ist das es auch ein ticket dazu offen ist
https://issues.apache.org/jira/browse/CB-7468
Zitat...and didn't get more attention.
KOTZ! Ärger!
Zitat von: herrmannj am 27 Januar 2015, 18:58:03
im Augenblick versuche ich seid gefühlten 500Millionen Jahren diesen nullpointer zu lösen
at org.apache.cordova.CordovaWebViewClient.onPageStarted(CordovaWebViewClient.java:144)
Das schöne ist das es auch ein ticket dazu offen ist
https://issues.apache.org/jira/browse/CB-7468
KOTZ! Ärger!
Hallo Jörg,
kurzer Zwischenstand. Ich werd hier noch zum Hirsch. Den ganzen Abend lässt sich mein kleines Tab nicht zum Verlieren der Verbindung bewegen. ;D
Ich hab mitlerweile mal meine Fritzbox 7270 mit in die Sache gezogen. Beim letzten Mal - als der ws abstürzte - hatte meine FB dazu folgenden Kommentar:
WLAN-Gerät wird abgemeldet: WLAN-Gerät antwortet nicht. MAC-Adresse: E0:B9:A5:0B:01:8B. (#0302).Aber, wie gesagt, hat mein Iconia seine aktuelle Rekordzeit schon gebrochen
state connected 2015-01-27 17:55:28@Chris: 4.4.2 ist schon immer auf dem Iconia drauf - wvc funktioniert einwandfrei. 8)
du hattest irgendwas drauf was direkt beim ausschalten das wlan abgeschaltet hat. Und nicht nur silent, aktiv an der box abgemeldet.
Guten Morgen!
Und das hat dann deinen ws nicht zum normalen "auslaufen" gebracht, sondern zum Absturz?
Seit gestern 18:00 disconnected mein Tab nicht mehr... :'( ;D
Im Endeffekt ein Fehler meines Tablets, der deinen prozess mit in den Abgrund zieht... ;D
ja, so war das. Unabhängig davon will ich das aber fixen damit auch böse Software das nicht vorsätzlich machen kann.
Ich hab auch eine gutes Bild wie Dein Tab das konnte und hoffe immer noch drauf das wir die Wirksamkeit des patch mit Deinem Tab testen können. Ich bekomme die Situation auch auf Gewalt nicht hin.
Na denn, warten wir mal noch einige Tage, vielleicht macht Dein Tab ja doch noch mal Stress. Einen fix hab ich eingebaut aber noch nicht commited. Wenn ich das hätte dann würdest Du jetzt denken das Dein Tab wegen dem patch nicht mehr abstürzt und ich würde mich in falscher Sicherheit wiegen.
vg
jörg
Hallo,
nachdem ich mein Smartvisu relativ problemlos zum Laufen gebracht habe, habe ich allerdings eine Fehlermeldung im meinem Fhem-Log:
2015.01.29 10:41:53 1: in MODIFIED
2015.01.29 10:41:53 1: in MODIFIED
2015.01.29 10:41:50 1: in MODIFIED
2015.01.29 10:41:50 1: in MODIFIED
diese Meldungen erscheinen jede Minute, da wird das Log ganz schön zugemüllt.
Es muß an dieses Zeilen in der Fhem.cfg liegen:
define Touchpanel fronthem
attr Touchpanel room Smartvisu
define meinipad fronthemDevice 192.168.1.201
attr meinipad room Smartvisu
define meinrechner fronthemDevice 192.168.1.100
attr meinrechner room Smartvisu
Denn wenn ich die lösche kommen keine neuen Meldungen im Log. Was kann das sein?
alles gut, da ist debug code von mir drin, Fehler: NULL.
Ich vermute Du hast ein at welches Du dynamisch anpasst ?
vg
jörg
ok, dann kam das durch mein at für meinen Kalender den ich zum Testen auf eine Minute gesetzt habe. Habe das jetzt geändert somit kommt die Meldung nicht mehr so häufig.
ja, und ich nehme die Log Meldung auch in einer der kommenden Version raus.
Das sind bereits vorarbeiten damit zukünftige Version von fronthem die eigene config (converter / GAD) automatisch aktualisieren wenn sich an den zugrunde liegenden fhem device definition etwas ändert.
vg
jörg
ich hätte da aber nochn eine Kleinigkeit. Ich habe einen Jalousie-Aktor wie folgt eingerichtet:
Mode: Item
Device: Jalousie_Kueche
Reading: state
Converter: Direct
cmd set: state
Grundsätzlich kann ich die Jalousie auch bedienen, allerdings fährt sie wenn ich auf den jeweiligen Pfeil klicke nur ganz kurz und dann geht nur wieder die Gegenrichtung.
So ist der Aktor definiert:
define Jalousie_Kueche CUL_HM 2204E2
attr Jalousie_Kueche .devInfo 010100
attr Jalousie_Kueche .stc 30
attr Jalousie_Kueche IODev HMLAN1
attr Jalousie_Kueche alias Küche
attr Jalousie_Kueche autoReadReg 4_reqStatus
attr Jalousie_Kueche devStateIcon runter:fts_shutter_up hoch:fts_shutter_down
attr Jalousie_Kueche eventMap on:hoch off:runter
attr Jalousie_Kueche expert 2_full
attr Jalousie_Kueche firmware 1.7
attr Jalousie_Kueche group Jalousien
attr Jalousie_Kueche icon fts_shutter_updown
attr Jalousie_Kueche model HM-LC-BL1-FM
attr Jalousie_Kueche peerIDs 00000000,
attr Jalousie_Kueche room Erdgeschoss
attr Jalousie_Kueche serialNr KEQ0542120
attr Jalousie_Kueche subType blindActuator
attr Jalousie_Kueche webCmd up:down:stop
Lässt sich folgendes Sonos Widget auch in Kombination mit fronthem nutzen?
https://github.com/pfischi/shSonos/tree/develop/widget.smartvisu
Ich habe es mal testweise eingebaut, sehe die Schaltflächen aber die gads werden in fronthem nicht geladen.
Grüße,
Matthias
Hallo zusammen,
ich wollte mich auch mal wieder zurückmelden.
Ich habe mein fhem zwischenzeitlich komplett neu aufgesetzt auf Ubuntu 14.04 Basis, seit heute läuft auch wieder smartvisu mit fronthem bei mir.
Meine Probleme mit dem dauerhaften speichern der GAD-Zuordnung haben sich jetzt auch erledigt. Die entsprechenden Dateien werden jetzt auch bei mir erstellt. Mein altes fhem war scheinbar reichlich verbastelt.
Erstmal vielen Dank an die Entwickler!
Jetzt muss ich erstmal wieder meine smartvisu seiten bauen.
Gruß,
Thorsten
Hallo Jörg,
es gibt Neuigkeiten. Heute morgen hatte ich mal FHEM per Kommandozeile beendet und gestartet (Grund war meine Viessmann Heizung, bzw. das USB-Kabel dorthin).
2015.01.29 10:34:37 1: HMLAN_Parse: HMLAN2 new condition ok
2015.01.29 10:34:37 3: ipc fronthem:127.0.0.1:58189 (ws): ws alive with pid 19544
2015.01.29 10:34:42 3: Device Fenster.DG added to ActionDetector with 028:00 time
und dann am späten Nachmittag (bis dahin funktionierte das schalten einwandfrei, das letzte Mal um ca. 15 Uhr:
2015.01.29 17:40:52 1: fronthem: thread ws closed for unknown reason
Keine Besonderheiten, nur mein Tablet war connected.
Tablet:
Readings
gateway fronthem 2015-01-29 10:34:37
identity 192.168.178.23 2015-01-29 10:34:37
protokoll 0.1 2015-01-29 16:03:35
state disconnected 2015-01-29 17:40:52
Hab jetzt mal alles kontrolliert.
kern.log ohne Befund
dmesg demzufolge auch nicht
fronthem.err keine neue Zeile
Fritzbox:
29.01.15 19:23:03 WLAN-Gerät angemeldet, WLAN wird mit voller Leistung reaktiviert.
29.01.15 17:53:18 Kein WLAN-Gerät mehr angemeldet, Stromverbrauch wird reduziert.
29.01.15 17:50:45 WLAN-Gerät wird abgemeldet: WLAN-Gerät antwortet nicht. MAC-Adresse: E0:B9:A5:0B:01:8B. (#0103).
29.01.15 17:40:45 WLAN-Gerät angemeldet. Geschwindigkeit 54 Mbit/s. MAC-Adresse: E0:B9:A5:0B:01:8B.
29.01.15 17:40:45 WLAN-Gerät angemeldet, WLAN wird mit voller Leistung reaktiviert.
29.01.15 16:21:48 Kein WLAN-Gerät mehr angemeldet, Stromverbrauch wird reduziert.
Mehr an Info hab ich leider nicht.
Provozieren kann ich das tatsächlich nicht. Nur das es - irgendwann - immer wieder passiert.
Ich werde es jetzt mal mit https://play.google.com/store/apps/details?id=com.googlecode.networklog probieren, vielleicht hab ich ja Glück und die App logged etwas entscheidendes. Sonst noch jemand einen Tipp für ne Log-App fürs Tablet?
Grüßle,
Olli
Ich kann den FHEM-Absturz mit Chrome vom Handy aus provozieren.
Flugmodus an -> Flugmodus aus -> FHEM abgestürzt.
Log:
2015.01.29 22:14:13 5: Triggering Handy (1 changes)
2015.01.29 22:14:13 5: Notify loop for Handy disconnected
2015.01.29 22:14:13 4: eventTypes: fronthemDevice Handy disconnected -> disconnected
2015.01.29 22:14:13 4: eventTypes: fronthemDevice Handy state: disconnected -> state: disconnected
2015.01.29 22:14:13 1: fronthem: thread ws closed for unknown reason
Auf der debian konsole:
Not an ARRAY reference at ./FHEM/01_fronthem.pm line 314.
So, hab catlog entdeckt!
Mein Log vom Tablet (Zur Info, Absturz ws war um 17:40:52 Uhr!)
01-29 17:23:12.836 W/ProcessCpuTracker(591): Skipping unknown process pid 10526
01-29 17:23:16.216 I/ActivityManager(591): Waited long enough for: ServiceRecord{42472310 u0 com.andrew.apollo/.MusicPlaybackService}
01-29 17:25:24.004 W/ProcessCpuTracker(591): Skipping unknown process pid 10536
01-29 17:26:19.985 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:30:50.917 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:31:26.222 W/ProcessCpuTracker(591): Skipping unknown process pid 10566
01-29 17:33:49.075 D/ConnectivityService(591): Sampling interval elapsed, updating statistics ..
01-29 17:33:49.095 D/ConnectivityService(591): Done.
01-29 17:33:49.095 D/ConnectivityService(591): Setting timer for 720seconds
01-29 17:36:01.995 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:36:24.500 W/ProcessCpuTracker(591): Skipping unknown process pid 10588
01-29 17:40:47.032 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:40:52.262 D/ConnectivityService(591): ConnectivityChange for WIFI: DISCONNECTED/DISCONNECTED
01-29 17:40:52.262 D/ConnectivityService(591): tryFailover: set mActiveDefaultNetwork=-1, prevNetType=1
01-29 17:40:52.262 D/ConnectivityService(591): Attempting to switch to mobile
01-29 17:40:52.262 D/ConnectivityService(591): Attempting to switch to BLUETOOTH_TETHER
01-29 17:40:52.262 D/ConnectivityService(591): Attempting to switch to ETHERNET
01-29 17:40:52.272 D/MobileDataStateTracker(591): dun: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=dun
01-29 17:40:52.272 D/MobileDataStateTracker(591): dun: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.272 D/ConnectivityService(591): resetConnections(wlan0, 3)
01-29 17:40:52.272 D/MobileDataStateTracker(591): supl: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=supl
01-29 17:40:52.282 D/MobileDataStateTracker(591): supl: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.302 D/MobileDataStateTracker(591): hipri: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=hipri
01-29 17:40:52.302 D/MobileDataStateTracker(591): hipri: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.302 D/MobileDataStateTracker(591): default: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=default
01-29 17:40:52.312 D/MobileDataStateTracker(591): default: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.312 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=false
01-29 17:40:52.322 D/MobileDataStateTracker(591): mms: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=mms
01-29 17:40:52.322 D/MobileDataStateTracker(591): mms: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.322 D/ConnectivityService(591): ConnectivityChange for WIFI: DISCONNECTED/DISCONNECTED
01-29 17:40:52.332 D/ConnectivityService(591): Attempting to switch to mobile
01-29 17:40:52.332 D/ConnectivityService(591): Attempting to switch to BLUETOOTH_TETHER
01-29 17:40:52.332 D/ConnectivityService(591): Attempting to switch to ETHERNET
01-29 17:40:52.332 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=false
01-29 17:40:52.332 D/ConnectivityService(591): handleInetConditionChange: no active default network - ignore
01-29 17:40:52.342 D/MobileDataStateTracker(591): dun: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=dun
01-29 17:40:52.342 D/MobileDataStateTracker(591): dun: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.352 D/MobileDataStateTracker(591): supl: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=supl
01-29 17:40:52.352 D/MobileDataStateTracker(591): supl: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.352 D/MobileDataStateTracker(591): hipri: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=hipri
01-29 17:40:52.352 D/MobileDataStateTracker(591): hipri: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.352 D/MobileDataStateTracker(591): default: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=default
01-29 17:40:52.352 D/MobileDataStateTracker(591): default: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:52.362 D/MobileDataStateTracker(591): mms: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=mms
01-29 17:40:52.362 D/MobileDataStateTracker(591): mms: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:40:55.342 D/ConnectivityService(591): setProvNotificationVisible: E visible=false networkType=1 extraInfo=null url=null
01-29 17:40:55.412 I/ActivityManager(591): Start proc com.android.mms for broadcast com.android.mms/.transaction.MmsSystemEventReceiver: pid=10643 uid=10009 gids={50009, 3003, 1028, 1015, 1023}
01-29 17:40:55.442 D/ConnectivityService(591): Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:40:55.442 D/ConnectivityService(591): handleCaptivePortalTrackerCheck: call captivePortalCheckComplete ni=NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:40:55.442 D/ConnectivityService(591): Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:40:55.442 D/ConnectivityService(591): handleCaptivePortalTrackerCheck: call captivePortalCheckComplete ni=NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:40:55.452 D/ConnectivityService(591): ConnectivityChange for WIFI: CONNECTED/CONNECTED
01-29 17:40:55.462 E/ConnectivityService(591): Unexpected mtu value: android.net.wifi.WifiStateTracker@41bc5288
01-29 17:40:55.482 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:40:55.482 D/ConnectivityService(591): ConnectivityChange for WIFI: CONNECTED/CONNECTED
01-29 17:40:55.492 E/ConnectivityService(591): Unexpected mtu value: android.net.wifi.WifiStateTracker@41bc5288
01-29 17:40:55.512 D/ConnectivityService(591): handleConnectivityChange: address are the same reset per doReset linkProperty[1]: resetMask=0
01-29 17:40:55.512 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:40:55.632 D/CountryDetector(591): The first listener is added
01-29 17:40:55.692 I/ActivityManager(591): Start proc com.android.chrome for broadcast com.android.chrome/com.google.android.apps.chrome.precache.PrecacheServiceLauncher: pid=10673 uid=10079 gids={50079, 3003, 1028, 1015, 1023}
01-29 17:40:55.712 I/ActivityManager(591): Killing 9542:com.android.providers.calendar/u0a1 (adj 15): empty for 3622s
01-29 17:40:56.252 I/ActivityManager(591): Killing 9560:com.android.calendar/u0a29 (adj 15): empty for 3620s
01-29 17:40:56.452 D/ConnectivityService(591): NetTransition Wakelock for ConnectedState released by timeout
01-29 17:40:56.502 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=0
01-29 17:40:57.032 D/ConnectivityService(591): handleConnectivityChange: addresses changed linkProperty[1]: resetMask=0
01-29 17:40:57.032 D/ConnectivityService(591): car=removed=[] added=[fe80::e2b9:a5ff:fe0b:18b/64,]
01-29 17:40:57.032 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:40:57.052 D/ConnectivityService(591): handleConnectivityChange: address are the same reset per doReset linkProperty[1]: resetMask=0
01-29 17:40:57.052 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:40:57.502 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:41:02.530 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:41:03.060 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:41:03.560 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:42:04.635 D/ConnectivityService(591): setProvNotificationVisible: E visible=false networkType=1 extraInfo=null url=null
01-29 17:42:04.755 W/ContextImpl(591): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1145 android.net.CaptivePortalTracker.sendNetworkConditionsBroadcast:507 android.net.CaptivePortalTracker.isCaptivePortal:399 android.net.CaptivePortalTracker.access$2600:60 android.net.CaptivePortalTracker$DelayedCaptiveCheckState.processMessage:283
01-29 17:42:04.775 D/ConnectivityService(591): captivePortalCheckCompleted: ni=NetworkInfo: type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false captive=false
01-29 17:45:56.515 D/ConnectivityService(591): Sampling interval elapsed, updating statistics ..
01-29 17:45:56.555 D/ConnectivityService(591): Done.
01-29 17:45:56.555 D/ConnectivityService(591): Setting timer for 720seconds
01-29 17:45:56.985 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:46:02.655 D/ConnectivityService(591): ConnectivityChange for WIFI: DISCONNECTED/DISCONNECTED
01-29 17:46:02.655 D/ConnectivityService(591): tryFailover: set mActiveDefaultNetwork=-1, prevNetType=1
01-29 17:46:02.655 D/ConnectivityService(591): Attempting to switch to mobile
01-29 17:46:02.655 D/ConnectivityService(591): Attempting to switch to BLUETOOTH_TETHER
01-29 17:46:02.655 D/ConnectivityService(591): Attempting to switch to ETHERNET
01-29 17:46:02.665 D/MobileDataStateTracker(591): dun: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=dun
01-29 17:46:02.675 D/ConnectivityService(591): resetConnections(wlan0, 3)
01-29 17:46:02.695 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=false
01-29 17:46:02.715 D/ConnectivityService(591): ConnectivityChange for WIFI: DISCONNECTED/DISCONNECTED
01-29 17:46:02.725 D/ConnectivityService(591): Attempting to switch to mobile
01-29 17:46:02.725 D/ConnectivityService(591): Attempting to switch to BLUETOOTH_TETHER
01-29 17:46:02.725 D/ConnectivityService(591): Attempting to switch to ETHERNET
01-29 17:46:02.725 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=false
01-29 17:46:02.745 D/ConnectivityService(591): handleInetConditionChange: no active default network - ignore
01-29 17:46:02.745 D/MobileDataStateTracker(591): dun: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.745 D/MobileDataStateTracker(591): supl: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=supl
01-29 17:46:02.755 D/MobileDataStateTracker(591): supl: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.755 D/MobileDataStateTracker(591): hipri: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=hipri
01-29 17:46:02.755 D/MobileDataStateTracker(591): hipri: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.755 D/MobileDataStateTracker(591): default: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=default
01-29 17:46:02.755 D/MobileDataStateTracker(591): default: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.755 D/MobileDataStateTracker(591): mms: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=mms
01-29 17:46:02.755 D/MobileDataStateTracker(591): mms: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.765 D/MobileDataStateTracker(591): dun: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=dun
01-29 17:46:02.765 D/MobileDataStateTracker(591): dun: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.765 D/MobileDataStateTracker(591): supl: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=supl
01-29 17:46:02.765 D/MobileDataStateTracker(591): supl: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.765 D/MobileDataStateTracker(591): hipri: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=hipri
01-29 17:46:02.775 D/MobileDataStateTracker(591): hipri: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.775 D/MobileDataStateTracker(591): default: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=default
01-29 17:46:02.775 D/MobileDataStateTracker(591): default: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:02.775 D/MobileDataStateTracker(591): mms: Broadcast received: android.intent.action.ANY_DATA_STATE apnType=mms
01-29 17:46:02.775 D/MobileDataStateTracker(591): mms: Received state=DISCONNECTED, old=DISCONNECTED, reason=dataEnabled
01-29 17:46:05.735 D/ConnectivityService(591): setProvNotificationVisible: E visible=false networkType=1 extraInfo=null url=null
01-29 17:46:07.985 D/ConnectivityService(591): handleInetConditionChange: no active default network - ignore
01-29 17:46:10.265 D/ConnectivityService(591): Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:46:10.265 D/ConnectivityService(591): handleCaptivePortalTrackerCheck: call captivePortalCheckComplete ni=NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:46:10.265 D/ConnectivityService(591): Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:46:10.265 D/ConnectivityService(591): handleCaptivePortalTrackerCheck: call captivePortalCheckComplete ni=NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false
01-29 17:46:10.285 D/ConnectivityService(591): ConnectivityChange for WIFI: CONNECTED/CONNECTED
01-29 17:46:10.285 E/ConnectivityService(591): Unexpected mtu value: android.net.wifi.WifiStateTracker@41bc5288
01-29 17:46:10.305 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:46:10.305 D/ConnectivityService(591): ConnectivityChange for WIFI: CONNECTED/CONNECTED
01-29 17:46:10.315 E/ConnectivityService(591): Unexpected mtu value: android.net.wifi.WifiStateTracker@41bc5288
01-29 17:46:10.325 D/ConnectivityService(591): handleConnectivityChange: address are the same reset per doReset linkProperty[1]: resetMask=0
01-29 17:46:10.325 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:46:11.285 D/ConnectivityService(591): NetTransition Wakelock for ConnectedState released by timeout
01-29 17:46:11.335 D/ConnectivityService(591): handleConnectivityChange: addresses changed linkProperty[1]: resetMask=0
01-29 17:46:11.335 D/ConnectivityService(591): car=removed=[] added=[fe80::e2b9:a5ff:fe0b:18b/64,]
01-29 17:46:11.335 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:46:11.345 D/ConnectivityService(591): handleConnectivityChange: address are the same reset per doReset linkProperty[1]: resetMask=0
01-29 17:46:11.345 D/Nat464Xlat(591): requiresClat: netType=1, hasIPv4Address=true
01-29 17:46:17.583 I/ActivityManager(591): Start proc com.android.providers.calendar for content provider com.android.providers.calendar/.CalendarProvider2: pid=10752 uid=10001 gids={50001, 3003, 1028, 1015, 1023}
01-29 17:46:18.703 I/ActivityManager(591): Start proc com.android.calendar for broadcast com.android.calendar/.alerts.AlertReceiver: pid=10776 uid=10029 gids={50029, 3003}
01-29 17:46:18.713 I/ActivityManager(591): Killing 9240:eu.chainfire.supersu/u0a58 (adj 15): empty for 2473s
01-29 17:46:18.913 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=0, published condition=0
01-29 17:46:23.493 V/WiredAccessoryManager(591): notifyWiredAccessoryChanged: when=223153878512000 bits=SW_MICROPHONE_INSERT mask=10
01-29 17:46:23.493 V/WiredAccessoryManager(591): newName=h2w newState=1 headsetState=1 prev headsetState=0
01-29 17:46:23.503 V/WiredAccessoryManager(591): device h2w connected
01-29 17:46:23.573 V/WiredAccessoryManager(591): notifyWiredAccessoryChanged: when=223153957661000 bits= mask=10
01-29 17:46:23.573 V/WiredAccessoryManager(591): newName=h2w newState=0 headsetState=0 prev headsetState=1
01-29 17:46:23.573 V/WiredAccessoryManager(591): device h2w disconnected
01-29 17:46:23.583 W/Vold (126): Returning OperationFailed - no handler for errno 30
01-29 17:46:27.483 D/ConnectivityService(591): setProvNotificationVisible: E visible=false networkType=1 extraInfo=null url=null
01-29 17:46:27.583 W/ContextImpl(591): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1145 android.net.CaptivePortalTracker.sendNetworkConditionsBroadcast:507 android.net.CaptivePortalTracker.isCaptivePortal:399 android.net.CaptivePortalTracker.access$2600:60 android.net.CaptivePortalTracker$DelayedCaptiveCheckState.processMessage:283
01-29 17:46:27.583 D/ConnectivityService(591): captivePortalCheckCompleted: ni=NetworkInfo: type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "fb7270", roaming: false, failover: false, isAvailable: true, isConnectedToProvisioningNetwork: false captive=false
01-29 17:46:29.873 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=0
01-29 17:47:05.285 I/ActivityManager(591): Waited long enough for: ServiceRecord{42094708 u0 com.andrew.apollo/.MusicPlaybackService}
01-29 17:51:07.785 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
01-29 17:55:52.945 D/ConnectivityService(591): handleInetConditionHoldEnd: net=1, condition=100, published condition=100
Grüßle,
Olli
Zitat von: HCS am 29 Januar 2015, 22:35:37
Ich kann den FHEM-Absturz mit Chrome vom Handy aus provozieren.
Flugmodus an -> Flugmodus aus -> FHEM abgestürzt.
Log:
2015.01.29 22:14:13 5: Triggering Handy (1 changes)
2015.01.29 22:14:13 5: Notify loop for Handy disconnected
2015.01.29 22:14:13 4: eventTypes: fronthemDevice Handy disconnected -> disconnected
2015.01.29 22:14:13 4: eventTypes: fronthemDevice Handy state: disconnected -> state: disconnected
2015.01.29 22:14:13 1: fronthem: thread ws closed for unknown reason
Auf der debian konsole:
Not an ARRAY reference at ./FHEM/01_fronthem.pm line 314.
Hi,
vielen Dank. Gehe ich recht in der Annahme das Deine Version älter ist als:
# $Id: 01_fronthem.pm 18 2015-01-18 12:34:48Z. herrmannj $
?
In der ist das gefixt
vg
jörg
Zitat von: olli84 am 29 Januar 2015, 22:55:16
So, hab catlog entdeckt!
Mein Log vom Tablet (Zur Info, Absturz ws war um 17:40:52 Uhr!)
Grüßle,
Olli
Hi Olli,
mach Dir bitte nicht zu viel Streß mit den logs, im Prinzip bin ich mit recht sicher die Ursache zu kennen und habe auch einen patch dafür.
Dein iconia verabschiedet sich manchmal ganz komisch aus dem Netzwerk. Das abschalten von einer tcp Verbindung ist ein komplexer und mehrstufiger Prozess.
Einfach gesagt macht Dein Iconia die Verbindung zu ohne tschüss zu sagen und knallt auch noch die Tür zu. Fronthem möchte aber, als guter Gastgeber, noch Auf Wiedersehen sagen und das sorgt für den vereinzelten crash. Das ist irgendwas ganz spezielles bei Dir. Wenn ich jetzt den patch commite und fronthem stürzt später doch noch mal wegen irgendwas anderem ab lässt sich nicht mehr genau feststellen ob alt oder neu.
Ich würde vorschlagen: probiere nochmal ein wenig ob Du doch noch einen Weg findest das zu provozieren damit wir testen können ob der patch genau dafür vollständig ist. in log etc brauchst Du zum jetzigen Zeitpunkt keine Arbeit zu investieren
vg
jörg
Zitat von: herrmannj am 30 Januar 2015, 03:01:03
vielen Dank. Gehe ich recht in der Annahme das Deine Version älter ist als:
# $Id: 01_fronthem.pm 18 2015-01-18 12:34:48Z. herrmannj $
Ja stimmt. War knapp davor: # $Id: 01_fronthem.pm 17 2015-01-17 00:54:45Z. herrmannj $
Werde ein Update machen und dann nochmal testen.
Hi,
erstmal vielen Dank an alle die das hier entwickelt haben, ist echt klasse geworden :)
Habe 2 Fragen:
1. Gibt es schon die möglichkeit Plots einzubinden ? Wenn ja, gibts da irgendwo Beispiele für ?
2. Hat schonmal jemand in smartVisu eine Webcam eingebunden, die sich auch alle X Minuten von "alleine" aktualisiert ?
Habe es bisher mit basic.image und multimedia.image probiert, allerdings scheint das nicht mit dem URL Aufruf zu funktionieren.
Die URL sieht so aus: 'http://192.168.2.201:88/cgi-bin/CGIProxy.fcgi?usr=fhem&pwd=fhem&cmd=snapPicture2
Im smartVisu Forum gibts leider auch nicht soviel Input.
Gruß & Dank
zu 1. nein
zu 2.
{{ multimedia.image('WebCamFlur', "http://192.168.XXX.XXX:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=USR&pwd=PWD", '', '10s') }}
funktioniert bei mir wunderbar.
Was genau geht denn nicht?
Moin,
es wird einfach kein Bild angezeigt, die URL funktioniert aber ..
Hier mal der Code:
<a href="#popup3" data-rel="popup">
<img class="icon" src="{{ icon1~'it_camera.png' }}">
</a>
<div id="popup3" data-role="popup" style="width:650px; height:490px;">
<a href="#" data-rel="back" data-role="button" data-icon="delete" data-iconpos="notext" class="ui-btn-right">Close</a>
{{ multimedia.image('WebCamgarten', "http://192.168.X.X:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=fhem&pwd=fhem", '', '10s') }}
</div>
Hast du es ohne Popup probiert? Hast du mal die ersten 10 Sekunden gewartet? Funktioniert der exakte Link in einem Browser mit neuer Session?
P.S.: Bitte Code-Tags verwenden, damit man auch was lesen kann.
Hallo,
sry wegen dem Code Tag :)
Hier mal der "gesamte" Code, der Aufruf im Browser funktioniert ohne Probleme, auch warten bringt kein Ergebnis.
<div class="block" style="width: 50%">
<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>Garageneinfahrt</h3>
<div class="image">
{{ multimedia.image('WebCamgarten', "http://192.168.2.201:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=fhem&pwd=fhem123!", '', '10s') }}
</div>
<a href="#popup3" data-rel="popup">
<img class="icon" src="{{ icon1~'it_camera.png' }}">
</a>
<div id="popup3" data-role="popup" style="width:650px; height:490px;">
<a href="#" data-rel="back" data-role="button" data-icon="delete" data-iconpos="notext" class="ui-btn-right">Close</a>
{{ multimedia.image('WebCamgarten', "http://192.168.2.201:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=fhem&pwd=fhem123!", '', '10s') }}
</div>
</div>
</div>
</div>
Ich könnte mir vorstellen, dass das Ausufezeichen im Passwort schuld ist. Versuche mal ein anderes Passwort.
Hallo,
funktioniert leider auch nicht :/ gnarf
Welchen Code benutzt du denn ?
Habe ich oben gepostet ;) Der Rest bringt dir nichts.
Was ist denn zum Beispiel die CSS-Klasse image bei dir? Wie genau sieht deine Ansicht nach dem Laden der Seite denn aus? Wird nichts angezeigt oder ein Bildplatzhalter? Welchen Browser benutzt du?
Hi,
das original multimedia.image von sv hat einen bug bei der Übertragung der query, ich vermute mal user/pwd kommen da bei der cam nicht an.
Im sv Forum gibt es einen patch dazu und es kann sein das im git von bgewehr die Korrektur drin ist, genau weiß ich das aber nicht.
@sebastian: google mal bzw schau im sv(knx) forum, da findest Du was dazu.
Hab auch cams und würde mittelfristig gern die cam bilder direkt über die bestehenden fhem plugins via websocket an sv schicken damit man von außen schauen kann ohne ein Loch in den router bohren zu müssen, das ist aber eher mittelfristig geplant. Nach dem mod funktioniert multimedia.image im local lan auf cams mit usr/pwd - das hatte ich mal getestet aber nicht im Einsatz (finde auch den mod nicht mehr).
vg
jörg
Oh man. Ich habe völlig vergessen, dass ich das auch gefixt habe (mit Hilfe des KNX-Forums). Das Widget muss so aussehen:
{% macro image(id, src, mode, time) %}
<img id="{{ uid(page, id) }}" data-widget="multimedia.image"
{% if mode == 'corner' %}
class="ui-corner-all"
{% elseif mode == 'corner-bottom' %}
class="ui-corner-bottom"
{% endif %}
src="pages/base/pics/trans.png" />
<script type="text/javascript">
var ind = '{{ src }}'.indexOf('?');
if(ind >0 ){
$('#{{ uid(page, id) }}').attr('src', '{{ src }}&_=' + new Date().getTime());
setInterval(function () {
$('#{{ uid(page, id) }}').attr('src', '{{ src }}&_=' + new Date().getTime());
}, new Date().duration('{{time|default("10i")}}'));
} else {
$('#{{ uid(page, id) }}').attr('src', '{{ src }}?_=' + new Date().getTime());
setInterval(function () {
$('#{{ uid(page, id) }}').attr('src', '{{ src }}?_=' + new Date().getTime());
}, new Date().duration('{{time|default("10i")}}'));
}
</script>
{% endmacro %}
Das Problem im original Widget war, dass es es die Uhrzeit und die Zeit (zur Verhinderung des Browsercaches) immer mit einem ? an die URL gehängt hat. Der Fix schaut nach, ob schon ein ? da ist und hängt es mit & an, falls ja. Es hängt also nicht am Passwort oder User, sondern generell an URLs mit Parametern.
Hallo,
jetzt hab ich es auch gerade gefunden :)
Aber wo genau muss ich das einfügen ?
Gruß & Danke
Hole die dir multimedia.html aus deinem Widgets Verzeichnis und packe es in das Verzeichnis deiner Page. Und ändere darin das entsprechende Widget.
... und beschäftige dich ein wenig mit dem Grundlagen von SmartVisu. Ich bin ja der Meinung, dass der Support dafür hier etwas zu weit geht, auch wenn ich es lobenswert finde, dass es gemacht wird ;) Dafür sollte es zumindest ein/mehrere eigene/s Thema/en geben.
Hi,
hab ich gemacht, bringt aber auch nicht den gewünschten Erfolg, trotzdem danke für die Hilfe.
Beschäftige mich gerne mit den Grundlagen, allerdings finde ich die Doku mehr als schlecht und das "offizielle" Forum ist auch nicht gerade sonderlich hilfreich.
Daher Versuch macht Klug :)
Grüße
lösch mal unter (auf) smartVisu/temp/ alles IN (!) dem tmep Dir.
und marvin hat recht, mach halt sonst schnell einen neuen thread auf, dann findet man das später auch wieder.
vg
jörg
Wenn du es wirklich so gemacht hast, dann lösche mal deinen Browser Cache, starte den Browser neu und probiere nochmal. Und schalte vorher mal den SmartVisu Cache aus und lösche den Inhalt des temp Verzeichnisses.
Als Workaround fixe sonst mal das entsprechende Widget (image) mal in der original Widget Datei.
Ok Jungs,
bitte nicht schlagen aber ich denke mal es lag zum schluss daran, das folgendes gefehlt hat .... {% import "multimedia.html" as multimedia %}
Jetzt funzt es :)
Werd mir dann wohl mal die Doku kaufen, hatte ich bis jetzt noch nicht, da ich aktuell nicht genug Zeit habe alles zu studieren.
Danke für die Hilfe
Oh. Dafür hast du aber schläge verdient ;)
Hallo zusammen,
nachdem ich diesen Thread gesehen habe, musste ich natürlich auch sofort losbasteln ;).
Soweit funktioniert das Ganze schon mal, nur zwei Fragen sind noch aufgekommen.
Ich habe in der Küche als Sockelbeleuchtung einen RGBW-Stripe mittels Milight am laufen.
Wenn ich diesen wie folgt einbinde:
<td align="center">Sockelbeleuchtung</td><td align="center" width="100px"> {{ basic.switch('Sockelbeleuchtung', 'KU_Sockelbeleuchtung', icon1~'light_floor_lamp.png', icon0~'light_floor_lamp.png') }}
Als Device wähle ich die Beleuchtung, als Reading state, als converter OnOff und als cmd set state.
Wenn ich nun auf das Icon in Smartvisu klicke geht die Sockelbeleuchtung auch an, jedoch bleibt das Icon weiss. Beim erneuten Klicken wird das Icon Gelb (so wie es vorher eigentlich sein sollte), die Sockelbeleuchtung bleibt auch an. Wenn ich dann noch einmal drücke, geht alles aus und das Icon wird wieder weiss.
Muss ich irgendwas besonderes beachten, um den zweiten Schritt zu übergehen?
Eine Eigenart der Milights ist vielleicht noch, dass folgende Stati vorhanden sind:
- on "Prozentzahl", also z.B. "on 100"
- off
Und dann habe ich noch eine zweite Frage...in der Homematic Thermostatdefinition von bgewehr gibt es ja die Definition "WZ_rtr_state". Ich habe meine Wandthermostate mit den Heizkörperthermostaten gepeert, wie muss ich den state dann definieren, bzw. besser gefragt, was soll dieser bewirken?
Vielen Dank schonmal für die viele Mühe, die in dieses Projekt geflossen ist, ich hoffe, dass auch ein wenig beisteuern kann :).
Wenn state niocht on und off ist/sind, dann kannst du auch nicht den converter OnOff verwenden. Verwende Direct und gebe die Status entsprechend in den Widgets an.
So weit ich weiß, ist bgewehrs Widget für Fußbodenheizung (an/aus Schalter). Für RTR musst du selbst ein wenig anpassen.
Hi Dennis,
sei so nett und mach bitte nochmal schnell einen neuen thread auf, hier überrennen wir uns sonst.
vg
jörg
Hallo
Nachdem ich mit Fronthem gerade ein Update gemacht habe bekomme ich folgende Meldung:
2015.01.30 16:40:46 1: reload: Error:Modul 01_fronthem deactivated:
Can't locate fhwebsocket.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./FHEM/01_fronthem.pm line 30, <$fh> line 257.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30, <$fh> line 257.
2015.01.30 16:40:46 0: Can't locate fhwebsocket.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./FHEM/01_fronthem.pm line 30, <$fh> line 257.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30, <$fh> line 257.
2015.01.30 16:40:52 1: configfile: Cannot load module fronthem
2015.01.30 16:40:52 1: in INITIALIZED
2015.01.30 16:40:52 1: in INITIALIZED
2015.01.30 16:40:52 1: in INITIALIZED
2015.01.30 16:41:00 2: Error messages while initializing FHEM: configfile: Cannot load module fronthem
2015.01.30 16:41:00 1: in ATTR
2015.01.30 16:41:00 1: in ATTR
2015.01.30 16:41:00 1: in ATTR
2015.01.30 16:41:14 1: in ATTR
2015.01.30 16:41:14 1: in ATTR
2015.01.30 16:41:14 1: in ATTR
Smartvisu bekommt jetzt auch keine Verbindung mehr.
Spiel jetzt erstmal eine Sicherung zurück.
vg
Florian
Automatischer Reconnect
Nach einem Neustart von FHEM hat SV auf meinem "immer an Info Tablet" keine Verbindung mehr zu FHEM. Ist auch logisch und kein Fehler.
Es ist aber lästig, daran denken zu müssen und zum Tablet zu laufen, um einen Reload zu machen, dass die Verbindung neu aufgebaut wird.
Darum habe ich Folgendes gemacht:
1. aus dem Domotiga-Treiber einen FHEM-Treiber gemacht
2. dem neuen FHEM-Treiber beigebracht, dass er ein mal pro Minute prüft, ob die WebSocket-Verbindung noch da ist, und falls nicht, sie neu aufbaut.
Installation: Die angehängte io_fhem.min.js (momentan noch nicht minifiziert) in das "smartvisu\driver\" Verzeichnis kopieren und in der Konfiguration der Page den Driver von Domotiga auf FHEM umstellen.
Falls dieser Driver Probleme verursacht, einfach wieder auf Domotiga zurückstellen.
Sobald FHEM nach einem Neustart wieder da ist, steht spätestens nach einer Minute die Verbindung wieder und die GADs werden wieder aktualisiert.
Das regelt bei mir auch alle Verindungsabbrüche nach "Laptop Deckel zu-auf", "Handy Flugmodus", usw. bei denen ein Pagereload erforderlich wäre, dass es weiter geht.
Aus dem error (Dreieck rechts oben) bei Verbindungsverlust habe ich eine warning gemacht, die beim Verbindungsverlust gelb ist, nach dem ersten erfolglosen reconnect rot wird und nach einem erfolgreichen reconnect von selbst wieder verschwindet.
Dieser driver ist eine Alternative, aber falls herrmannj das als sinnvoll betrachtet, kann er ihn ja als Startpunkt für einen "offiziellen" FHEM-driver nehmen.
Page reload senden
Wenn man die page in SV geändert hat, muss man zu den aktuell verbundenen Devices laufen, um dort einen page reload zu machen, um die Änderungen zu bekommen. In meinem Fall mal wieder das "immer an Info Tablet". Um das zu regeln habe ich in dem neuen FEHM-driver schon mal vorbereitet, dass er ein 'reloadPage' command versteht und die Seite (nicht aus dem cache sondern vom Server gezwungen) neu lädt.
Super wäre, wenn Du dem fronthemDevice ein "set fronthemDevice reloadPage" spendieren würdest, das ein "reloadPage" command an das device absetzt.
Das könnte man dann bei Bedarf absetzten oder mit einem AT periodisch oder wie immer man will, um das SV-Tablet aktuell zu halten.
Alternativ auch in 01_fronthem, das es an alle aktuell verbundenen fronthemDevice sendet.
Ist aber ein Prio. 2 Wunsch.
Sonstiges
- SV als Frontend läuft bei mir inzwischen im "Produktiv-Test-Stadium" und ersetzt bereits alles bisherigen Frontends, die ich so hatte. Das funktioniert schon sehr zuverlässig.
- Den Vorschlag von weiter oben, das Ganze hier in Threads für "Bugs", "SV-wie mache ich es", usw. aufzuteilen halte ich für sehr sinnvoll. Dieser Thread hier ist nicht mehr zu überblicken.
Nachtrag - Wichtig
Der Treiber ist, wie oben schon erwähnt, noch nicht minifiziert, was eigentlich egal ist.
Wenn jemand in der Konfiguration von SV "config_js" auf "js" stehen hat, dann muss er den Treiber zusätzlich auch mit dem Dateinamen "io_fhem.js" in das "driver"-Verzeichnis kopieren.
@HCS: Driver einem Stresstest unterzogen. Scheint gut zu laufen. Ich werde das weiter beobachten. Guter Ansatz. Danke. Jetzt fehlt im Driver noch das handeln bei vielen Gads. Es blockiert beim Seitenwechsel leider sehr lange, wie hier schon angesprochen wurde. Dann wäre der Driver schon fast perfekt.
Das mit dem Page-reload halte ich auch für einen sehr guten Ansatz. Ich habe mir auch schon mal kurz Gedanken darüber gemachte, wie man das Anlegen von gads nach bestimmten Regeln (die Regeln kämen dabei ins Device) weitgehend automatisieren könnte. Ich bin dabei aber leider auf keinen grünen Zweig gekommen. Leider komme ich auch vor August nicht dazu, mich mit sowas intensiver zu beschäftigen.
Zitat von: marvin78 am 31 Januar 2015, 09:00:39
@HCS: Driver einem Stresstest unterzogen. Scheint gut zu laufen.
Besser der Driver hat Stress als ich ;D
Zitat von: marvin78 am 31 Januar 2015, 09:00:39
Jetzt fehlt im Driver noch das handeln bei vielen Gads. Es blockiert beim Seitenwechsel leider sehr lange, wie hier schon angesprochen wurde. Dann wäre der Driver schon fast perfekt.
Ist mir auch schon aufgefallen. Mit dem Thema habe ich mich aber noch nicht beschäftigt. Wenn wir diesen Driver weiter verfolgen, schaue ich es mir mal an.
Zitat von: marvin78 am 31 Januar 2015, 09:00:39
Ich habe mir auch schon mal kurz Gedanken darüber gemachte, wie man das Anlegen von gads nach bestimmten Regeln (die Regeln kämen dabei ins Device) weitgehend automatisieren könnte. Ich bin dabei aber leider auf keinen grünen Zweig gekommen.
Das ist auch ein interessantes Thema. Die GAD-Anlegerei ist Stress.
Igrgendwie würde es Sinn machen, eine Bug-/Wunsch-Liste zu haben, in der man das alles findet und evtl. sehen kann, wer an was dran ist. Das minimiert das Risiko von doppelt geleisteter Arbeit.
Hallo!
Ich bekommen mit dem Treiber leider keine Verbindung zu stande. Port hab ich auf 2121. Auch nach einem FHEM Neustart bleibt das fronthemdevice auf disconnected. Nach dem zurückstellen auf domotiga passt wieder alles.
Hast du eine Idee?
Grüße
Schon interessant. Ich musste nicht einmal den Browser aktualisieren. Die Verbindung wurde sofort und ohne Unterbrechung aufgenommen (Chrome, FF).
Zitat von: fhainz am 31 Januar 2015, 10:02:58
Hallo!
Ich bekommen mit dem Treiber leider keine Verbindung zu stande. Port hab ich auf 2121. Auch nach einem FHEM Neustart bleibt das fronthemdevice auf disconnected. Nach dem zurückstellen auf domotiga passt wieder alles.
Hast du eine Idee?
Grüße
Hast Du nach dem Umstellen auf den FHEM-Treiber auch die IP-Adresse wieder eingetragen?
Die IP Adresse bleibt bei mir in dem Feld stehen, hab sie aber zur Sicherheit nochmals eingegeben. Kein Erfolg.
Mach mal im browser mit F12 die Konsole auf, mach danach einen page reload mit F5 und schau, ob Einträge, die mit [io.fhem] beginnen, geloggt werden.
[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (io_fhem.js, line 0)
Kommt bei mir in der JS-Konsole.
Nachdem ich die Datei umbenannt hab, klappt es.
nur wenn der config.ini Parameter auf .min.js steht, wird der neue fhem Treiber gefunden. Wenn er auf .js steht, muss auch der Treiber als .js vorhanden sein. Also datei kopieren, einmal als min.js, einmal als .js, dann mûsste es bei jedem gehen..
Gesendet von meinem iPad mit Tapatalk
genau so funktionierte es auch erst bei mit. treiber dublizieren so das es ihn einmal mit und einmla ohne min gibt. nur umbennen half nicht da er dann nicht in der liste der treiber auftaucht
Der Treiber ist ohnehin keine "min" ;) Das täuscht hier etwas.
Zitat von: marvin78 am 31 Januar 2015, 11:26:58
Der Treiber ist ohnehin keine "min" ;) Das täuscht hier etwas.
Ja klar. Wollte ich mir sparen, bis er irgendwie amtlich wird.
Und sorry Leute, dass jemand nicht min konfiguriert hat, war mir völlig aus dem focus gefallen.
Ich ändere gleich mal meinen originalen post dass nicht noch mehr drauf reinfallen.
Hi HCS,
sehr coole Idee !
Ich habe zwar schon prototyp Varianten von erweitertem js hier rumliegen, wenn Du die Vaterschaft über den driver übernehmen möchtest finde ich das sehr gut.
Wenn ich mir Vorschläge erlauben darf: ich würde den Timer primär an die "onclose" und "onerror" events des websockets binden und den dialog erst nach 2-3 Fehlversuchen anzeigen. *edit
Bzgl der vielen GADs und dem folgenden blocking bin ich mal testweise jquery Queue gegangen, das scheint gut zu funktionieren weil asynchron. Dazu müsste man den "onmessage" Zweige (mMn für items und series) darüber routen. Kann ich sehr gern unterstützen.
Ein dritter block: ich habe vereinzelt beobachtet (hauptsächlich android, IOS meldet sich bei mir sehr zuverlässig ab) das ein Tab in den standby geht ohne den ws abzuschalten, sondern den einfach einfriert. Hier müsste man ggf nochmal genau untersuchen um zu verhindern das während der ws "eingefroren" ist einzelne Nachrichten verloren gehen. Das ist aber nur Rand-Prio, normal puffert fronthem. Vielleicht einfach im Hinterkopf behalten.
Und last but not least: die vorhandene Webviecontrol von Dirk läßt sich nicht (nur sehr umständlich und sehr benutzer-unfreundlich) für fronthem/sv benutzen, zumindest in Bezug auf tts, brightness, play etc. Da bin ich dabei eine Variante zu erstellen die das voll unterstützt. Der Plan ist das die device Funktionen von der App automatisch als GAD zur Verfügung gestellt werden und das fronthem device einen Erweiterungssatz dazu genauso selbstständig nach-lädt. Da kann es sein das der Treiber zumindest minimal irgendwas dazu beitragen muss, bspw das dialoge (als Benachrichtigungen von fronthem) als Nachricht in android auch dann angezeigt werden, sollte die app im Hintergrund laufen. Kann ich aber noch nicht genau sagen wie - sehen wir dann.
vg
jörg
Zitat von: herrmannj am 31 Januar 2015, 12:02:54
Wenn ich mir Vorschläge erlauben darf
Natürlich.
Zitat von: herrmannj am 31 Januar 2015, 12:02:54
ich würde den Timer primär an die "onclose" und "onerror" events des websockets binden
Ja, das ist sinnvoller als ihn ständig kreisen zu lassen. Werde ich in die Richtung lenken.
Ich wollte erst mal schnell und ohne viel Aufwand sehen, ob das generell so hilft.
Zitat von: herrmannj am 31 Januar 2015, 12:02:54
wenn Du die Vaterschaft über den driver übernehmen möchtest finde ich das sehr gut.
So schnell kommt man zu Nachwuchs ;D
Soweit es mir möglich ist, mache ich das mal.
Zitat von: herrmannj am 31 Januar 2015, 12:02:54
... und den dialog erst nach 2-3 Fehlversuchen anzeigen
Warum hast Du die Idee wieder verworfen? Fand ich spontan sinnvoll.
Zitat von: herrmannj am 31 Januar 2015, 12:02:54
Und last but not least: die vorhandene Webviecontrol von Dirk läßt sich nicht (nur sehr umständlich und sehr benutzer-unfreundlich) für fronthem/sv benutzen, zumindest in Bezug auf tts, brightness, play etc. Da bin ich dabei eine Variante zu erstellen die das voll unterstützt. Der Plan ist das die device Funktionen von der App automatisch als GAD zur Verfügung gestellt werden und das fronthem device einen Erweiterungssatz dazu genauso selbstständig nach-lädt. Da kann es sein das der Treiber zumindest minimal irgendwas dazu beitragen muss, bspw das dialoge (als Benachrichtigungen von fronthem) als Nachricht in android auch dann angezeigt werden, sollte die app im Hintergrund laufen. Kann ich aber noch nicht genau sagen wie - sehen wir dann.
OK, das würde dann den pageReload vom fronthemDevice unnötig machen.
Der würde aber trotzdem nicht schaden, für jemanden, der das (alte oder neue) WVC nicht einsetzten kann oder will.
Wenn Du noch Treiber-Experimente rumliegen hast, kannst Du sie mir ja mal schicken.
bgewehr:
Zum Thema UZSU: ich habe Deinen Vorschlag umgesetzt, Jörg, aber SV kann damit zwar erfolgreich die Daten an fhem schreiben, aber nicht wieder lesen, beim zweiten Aufruf ist die UZSU wieder leer! Ist das bei Dir auch so?
Zitat von: herrmannj am 14 Januar 2015, 07:16:57
Hallo Bernd,
ja, nur demo wegen converter - das ist in der demo one way.
Kann ich hier mglw. am Converter helfen? Was würde denn gebraucht?
EDIT:
Aktueller flow:
[io.fhem] sending data: {"cmd":"item","id":"EG_blind_uzsu","val":{"active":true,"list":[{"active":false,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","time":"00:00","value":0}]}}
io_fhem.min.js:1 [io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu","HASH(0x364c740)"]}
io_fhem.min.js:1 [io.fhem]: update item: EG_blind_uzsu val: HASH(0x364c740)
ZitatSo schnell kommt man zu Nachwuchs ;D
;)
ZitatWarum hast Du die Idee wieder verworfen? Fand ich spontan sinnvoll.
Mach nach Lust und Laune, ich hab erst mit Verzögerung geschnallt das Du mit "gelb" - "rot" schon Stufen drin hast.
ZitatOK, das würde dann den pageReload vom fronthemDevice unnötig machen.
Lass gern drin, frist ja kein Brot.
ZitatWenn Du noch Treiber-Experimente rumliegen hast, kannst Du sie mir ja mal schicken.
Das muss neu aufgebaut werden. In so einem Experiment sind xx Irrwege drin und 1 einer der dann klappt. Ohne Wissen welche (warum) macht das keinen Sinn. Daher lieber theoretisch, hier die api zu jquery queue http://api.jquery.com/queue/
Ich hab den Post hier nicht mehr parat aber ich hatte das mal so überschlagen: wir sprachen, glaub ich, über >300Gad mit ca 6-7sek. Da landet man bei ~25ms pro Gad. An sich wenig spektakulär, die Summe macht es aber. Wenn da später noch series (plots) dazukommen dann wird das schon ein echtes Thema. Wie kommt die Zeit zustande ? Vmtl braucht jquery die einfach weil es über die Selektoren für jedes GAD erstmal den ganzen DOM scannen muss um das widget zu finden.
Die Idee ist also eine jquery queue im Treiber einzurichten. Das schreiben (aus "onmessage") in die Queue müsste also zeit optimiert ablaufen. Am Ausgang der queue für dann das jeweilige "widget.update(item, val);" aufgerufen - jquery selber trägt Sorge für den asynchronen Aufruf und auch dafür das sv die gesamte Zeit trotzdem responsive bleibt. Ich vermute das sich bei +300Gads auch die overhead Zeiten bemerkbar machen, um initial alle GADs zu laden dauert es dann also vmtl länger als 7 Sekunden - mit dem Unterschied das sv schon bedienbar ist.
Das aber bitte nur als Vorschlag, wenn Du andere Ideen hast gerne rin damit :D
vg
jörg
Zitat von: bgewehr am 31 Januar 2015, 13:16:28
bgewehr:
Zum Thema UZSU: ich habe Deinen Vorschlag umgesetzt, Jörg, aber SV kann damit zwar erfolgreich die Daten an fhem schreiben, aber nicht wieder lesen, beim zweiten Aufruf ist die UZSU wieder leer! Ist das bei Dir auch so?
Kann ich hier mglw. am Converter helfen? Was würde denn gebraucht?
EDIT:
Aktueller flow:
[io.fhem] sending data: {"cmd":"item","id":"EG_blind_uzsu","val":{"active":true,"list":[{"active":false,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","time":"00:00","value":0}]}}
io_fhem.min.js:1 [io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu","HASH(0x364c740)"]}
io_fhem.min.js:1 [io.fhem]: update item: EG_blind_uzsu val: HASH(0x364c740)
Hi Bernd,
völlig richtig, das war so zu sagen nur der Machbarkeitstest. Ich befürchte aber da kannst Du nur wenig tun. Bei der uzsu ist der converter nicht ein add-on sondern integraler Bestandteil im Modul. Andre wartet da auch bestimmt schon, er hat entsprechende widgets für fhem schon gebaut. Ich schau mal das ich da so schnell als möglich beigehen kann - aber das "richtige Leben" gibt es halt auch noch. Will (muss) halt auch Geld mit bezahlter Arbeit verdienen ...
vg
jörg
Kannst Du die Architektur aus Deinem Kopf hier mal kurz rauslassen?
Gesendet von iPhone mit Tapatalk
btw, ich mach nochmal ein update im GIT mit den fix für das Prob von Olli - dann mach ich (morgen?) hier zu und mach einen neuen thread mit bugs und wünschen zu fronthem auf. Wir hatten das ja schon einige Male, HCS vorhin auch - völlig richtig: hier verlieren wir Infos.
vg
jörg
Zum Forum und der Nutzung langer Threads:
Ich rufe mir häufiger mal die Druckansicht auf und suche dann mit [Strg]+[F], das geht über alle Seiten...
Zitat von: HCS am 31 Januar 2015, 08:01:34
Darum habe ich Folgendes gemacht:
1. aus dem Domotiga-Treiber einen FHEM-Treiber gemacht
Super, läuft bei mir ohne Probleme!
Kannst Du das im fhemwiki verewigen?
Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?
Vielen Dank!
Zitat von: bgewehr am 31 Januar 2015, 13:27:26
Kannst Du die Architektur aus Deinem Kopf hier mal kurz rauslassen?
Gesendet von iPhone mit Tapatalk
yepp. Im coverter Teil (namespave fronthem) kommt de Struktur als hash an (sv -> fhem).
Im main:: muss dann ein Hash liegen wo die Zeiten schon geordnet sind. Jedes mal wenn über das frontend ein update kommt muss die Struktur neu aufgebaut werden und die uszu muss die Liste von unten nach oben durchgehen um den nächsten "Schaltzeitpunkt" zu finden. Wenn der feststeht muss ein Timer gesetzt werden (evtl bestehende Löschen). Wenn der timer feuert wird dann im Modul die Aktion ausgelöst (Event und / oder direktes Schalten eines konfigurierten device). Danach reload des Timers (also Struktur / hash durchlaufen, finden, Timer setzen)
Dazu kommt die Verwaltung von disable/enable (per attrib) sowie das formatieren und anziegen der Liste in fhem (per get?).
Hier dann auch der Rückweg von fhem -> sv via converter.
Außerdem muss die Struktur serialisiert werden und auf (fhem) Platte gespeichert damit die Termine, Zeiten nach einem fhem shutdown wieder geladen werden können. mMn wird das nicht über die fhem.cfg gehen können (weil sehr umfangreiche Datensätze im Vergleich zu den üblichen Attributen), daher braucht es eine eigene cfg pro uzsu.
vg
jörg
Zitat von: bgewehr am 31 Januar 2015, 13:36:42
Super, läuft bei mir ohne Probleme!
Kannst Du das im fhemwiki verewigen?
Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?
Vielen Dank!
Schau Dir mal in sv die make.php an - da steckt das minify drin. Man muss nur die Dateien händisch ergänzen und dann make.php aufrufen.
Zitat von: herrmannj am 31 Januar 2015, 13:38:21
yepp. Im coverter Teil (namespave fronthem) kommt de Struktur als hash an (sv -> fhem).
Im main:: muss dann ein Hash liegen wo die Zeiten schon geordnet sind. Jedes mal wenn über das frontend ein update kommt muss die Struktur neu aufgebaut werden und die uszu muss die Liste von unten nach oben durchgehen um den nächsten "Schaltzeitpunkt" zu finden. Wenn der feststeht muss ein Timer gesetzt werden (evtl bestehende Löschen). Wenn der timer feuert wird dann im Modul die Aktion ausgelöst (Event und / oder direktes Schalten eines konfigurierten device). Danach reload des Timers (also Struktur / hash durchlaufen, finden, Timer setzen)
Dazu kommt die Verwaltung von disable/enable (per attrib) sowie das formatieren und anziegen der Liste in fhem (per get?).
Hier dann auch der Rückweg von fhem -> sv via converter.
Außerdem muss die Struktur serialisiert werden und auf (fhem) Platte gespeichert damit die Termine, Zeiten nach einem fhem shutdown wieder geladen werden können. mMn wird das nicht über die fhem.cfg gehen können (weil sehr umfangreiche Datensätze im Vergleich zu den üblichen Attributen), daher braucht es eine eigene cfg pro uzsu.
Du gehst von EINEM zentralen UZSU device in FHEM aus, richtig?
Ich hatte bisher immer gedacht, EIN UZSU READING an das fhem device zu setzen, das ich schalten möchte und EIN ZENTRALES UZSU notify, das auf die uzsu-Readings aller devices reagiert und die entspr. at-Befehle erzeugt oder modifiziert.
Was meinst Du dazu? Zu simpel gedacht?
Alle Zeiten wären im normalen statefile gesichert, keine komplexe Sache, oder?
Zitat von: herrmannj am 31 Januar 2015, 13:21:22
Das aber bitte nur als Vorschlag, wenn Du andere Ideen hast gerne rin damit :D
Noch habe ich keinerlei Idee. Habe mich mit dem Thema noch gar nicht befasst.
Ich werde das mal auf mich wirken lassen und generell überlegen, wie das mit dem Treiber Stück für Stück vorwärts gehen kann.
Zitat von: bgewehr am 31 Januar 2015, 13:36:42
Kannst Du das im fhemwiki verewigen?
Leider nicht. Habe keine wiki-Rechte.
Zitat von: bgewehr am 31 Januar 2015, 13:36:42
Ich habe mal das debian Paket yui-compressor benutzt und die .min.js Variante erstellt, ist auch wirklich nicht schwierig und auch für die von mir permanent veränderte widgets.js wichtig gewesen. Kannst Du beide Files im Wiki anbieten?
Sinnvollerweise werde ich in Zukunft beide Varianten bereitstellen.
Wiki siehe oben.
Könnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?
Zitat von: HCS am 31 Januar 2015, 13:54:57
Könnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?
Finde ich super. Dann wäre alles an einem Platz. Dokumentieren könnte man das dann im Wiki.
Zitat von: HCS am 31 Januar 2015, 13:54:57
Leider nicht. Habe keine wiki-Rechte.
Du kannst eine Email an einem Admin schicken, der legt dann einen Account für dich an. Siehe hier: http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren
Grüße
ZitatKönnten wir nicht im "herrmannj/fronthem" repository auch den Treiber und evtl. allgemeingültige widgets in der jeweils aktuellen Version bereitstellen?
Gerne, im Augenblick liegt die angepasste sv Version ja auch nirgendwo jungfräulich. Bernd ist eine gute Quelle, aber da sind eben auch die individuellen Anpassungen drin.
Vlt macht es auch Sinn in dem sv git eine fhem-widget.js zu pflegen. Die kann man ja ohne Überscheidung zusätzlich in die root oder base einbinden und man hätte eine zentrale Anlaufstelle für Erweiterungen. Von Bernd gibt es ja Textinput und select und da kommen bestimmt noch viele dazu.
Dann wäre die widget.js getrennt und damit auch etwas update-sicherer. Dort würde ich vorschlagen nur Fehler zu fixen und zu dokumentieren (wie shifter etc).
vg
jörg
Zitat von: herrmannj am 31 Januar 2015, 14:05:41
Vlt macht es auch Sinn in dem sv git eine fhem-widget.js zu pflegen. Die kann man ja ohne Überscheidung zusätzlich in die root oder base einbinden und man hätte eine zentrale Anlaufstelle für Erweiterungen. Von Bernd gibt es ja Textinput und select und da kommen bestimmt noch viele dazu.
Das macht Sinn. Ich habe bei mir bis jetzt strikt drauf geachtet, nichts an SV selbst ändern zu müssen. Ist ja nicht so schön, wenn man bei einem SV-Update im Eifer des Gefechts sich seine Änderungen wegbügelt.
Die Idee wäre in Deinem git ein ordner "smartvisu", der, sofern zutrffend, die passende Unterstruktur enthält.
smatvisu
-- driver/
---- io_fhem.js
---- io_fhem.min.js
-- lib/
---- functions_config.php
usw.
Den könnte man sich zu einer SV-Installation einfach draufkopieren.
Kannst Du aber ganz nach Deinen Vorstellungen gestalten, ist nur eine Anregung.
jo passt. Und dann nehmen wir die Änderungen an widget.js und css mit rein und ergänzen das um die fhem-widget.js (css) plus evtl widgets wie rtr etc.
vg
jörg
Das klingt nach einem Plan 8)
Zitat von: bgewehr am 31 Januar 2015, 13:42:57
Du gehst von EINEM zentralen UZSU device in FHEM aus, richtig?
Ich hatte bisher immer gedacht, EIN UZSU READING an das fhem device zu setzen, das ich schalten möchte und EIN ZENTRALES UZSU notify, das auf die uzsu-Readings aller devices reagiert und die entspr. at-Befehle erzeugt oder modifiziert.
Was meinst Du dazu? Zu simpel gedacht?
Alle Zeiten wären im normalen statefile gesichert, keine komplexe Sache, oder?
ja schon, zumindest ein fhem uzsu pro sv uzsu.
Die Schaltzeiten in readings am device zu packen ist nur auf den ersten Blick verlockend:
In so einer uzsu gibt es ja eine variable Anzahl von Zeilen die jeweils wieder verschiedene Schaltzeitpunkte haben (die Wochentage). Das uzsu device müsste erstmal schon das format von sv (hier hash) serialisieren um ein Reading in Textform zu bekommen. Das notify müsste jetzt nicht nur das eine Reading (am device) einzelne Zeiten zerlegen (pro Wochentag), sondern das mit allen uzsu readings am device machen, die ordnen, und könnte dann erst den nächsten Schaltzeitpunkt für das at bestimmen. Ein notify kann das mit Bordmitteln nicht, das muss mit ganz viel perl aufgepimpt werden. Das geht im fhem-uzsu device viel effizienter weil ich mir den Umweg über das Menschen - lesbare reading spare und gleich Maschinen - lesbar bleiben kann, das ist also der deutlich geringere Aufwand.
vg
jörg
Zitat von: herrmannj am 31 Januar 2015, 15:11:09
Die Schaltzeiten in readings am device zu packen ist nur auf den ersten Blick verlockend:
In so einer uzsu gibt es ja eine variable Anzahl von Zeilen die jeweils wieder verschiedene Schaltzeitpunkte haben (die Wochentage). Das uzsu device müsste erstmal schon das format von sv (hier hash) serialisieren um ein Reading in Textform zu bekommen. Das notify müsste jetzt nicht nur das eine Reading (am device) einzelne Zeiten zerlegen (pro Wochentag), sondern das mit allen uzsu readings am device machen, die ordnen, und könnte dann erst den nächsten Schaltzeitpunkt für das at bestimmen. Ein notify kann das mit Bordmitteln nicht, das muss mit ganz viel perl aufgepimpt werden. Das geht im fhem-uzsu device viel effizienter weil ich mir den Umweg über das Menschen - lesbare reading spare und gleich Maschinen - lesbar bleiben kann, das ist also der deutlich geringere Aufwand.
Also: dieser UZSU-Converter funktioniert für speichern und lesen der UZSU-Settings an einem Reading eines fhem-device ohne Anpassung des USZU-Codes in SV:
###############################################################################
#
# Setreading a device reading using JSON conversion (gadval => reading=decode_json() => setval => encode_json(reading) )
#
###############################################################################
sub UZSU(@)
{
use JSON;
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = decode_json(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$gadval = encode_json($gadval);
$gadval =~ s/;/;;/ig;
$param->{result} = main::fhem("setreading $device $reading $gadval");
$param->{results} = [];
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: UZSU';
}
return undef;
}
Das Reading wirft brav seine events in fhem:
2015-01-31 15:52:36 CUL_HM Roll_EG uzsu: {"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU","time":"","value":1,"active":true},{"value":0,"time":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","active":true},{"value":0,"time":"00:00","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","active":true}]}
und SV kann das alles sauber wieder anzeigen:
[io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu",{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SU","time":"","value":1,"active":true},{"value":0,"time":"","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","active":true},{"value":0,"time":"00:00","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH","active":true}]}]}
Was jetzt fehlt, ist ein notify, das darauf reagiert und eine custom function in der 99_uzsu.pm, um das perl-Objekt zu verarbeiten.
Erscheint mir nicht so schlimm schwierig, oder?
Bremst mich, sonst mach ich das jetzt...
Lass Dich bremsen - oder besser umlenken :-)
Im Prinzip passt ja alles, aber lass uns doch das notify und das at direkt mit in das device nehmen - wo soll der Vorteil sein die alle zu trennen und von Hand zu konfigurieren :-)
Schreib mal noch 3 weitere Zeilen in sv (uzsu) dazu, dann wird das Reading fix breit (das wäre nur optisch).
Für die Maschine würde jetzt die nächste Aufgabe darin bestehen das reading von links nach rechts (oben nach unten) durchzuparsen und daruas den nächsten Schaltzeitpunkt zu ermitteln.
Also: Eintrag #1 lautet 8:00 Di,Mi,Do: ein. Eintrag #2 9:00 Di,Mi,Do: aus. Eintrag #3 7:00 Mo,Sa,So: ein. ... usw
Wir haben jetzt (fiktiv) Montag 5:00 - jetzt muss geparst werden. Geh mal gedanklich davon weg wo (notify, modul etc) der code steht weil unabhängig davon wo ist er ja funktionell gleich.
Du kannst jetzt (ohne wieder über json zu gehen) das direkt auf dem hash im fhem uszu modul machen - das ist einfacher. Btw, ich würde das use JSON unbedingt (!) aus dem converter ruasnehmen - schau mal in den editor, die ganzen json routinen werden jetzt als converter angezeigt.
Geht so (modul):
package main;
use JSON;
sub makeJSON(@)
{
return magische_convertierung($);
}
package fronthem;
my $brauche_JSON = main::makeJSON(..);
vg
jörg
Hallo
Mein Updateproblem ( Antwort #1134 ) ist nun auch gelöst. :)
Hatte die falsche Updatereihenfolge gewählt.
Hab jetzt zuerst Fhem und dann Fronthem update mit Erfolg ausgeführt.
VG
Florian
Hallo,
bei mir werden im SV die Wetterinfos (yr.no) und Kalendereinträge im engl. Format angezeigt.. :(
In der config.ini steht bei [default] lang = 'de' , bei den Client-Optionen habe ich keine Language-Eintrag, was ja auch ok ist.
Hat jemand ne Idee woran es legen könnte ?
Gruß Kai
Jörg ist dran... http://forum.fhem.de/index.php/topic,33087.0.html
Übrigens auch eine Variante um deine Fritzbox einzubinden... ;)
Vorübergehend könntest du die default.php ändern, dann geht es...
Gruß Steven
Hallo Jörg,
hatte heute wieder einen ws absturz. Ich denke ich kann das provozieren indem ich einfach nur warte. ;D
Falls du das heute (oder wann auch immer) noch eincheckst werde ich mich gleich zum testen bereit machen. Nach 3-5 Tagen sollte dann ein Ergebnis sichtbar sein (eben hoffentlich keinen Absturz mehr).
Grüßle,
Olli
ja, so werden wir das wohl machen :) - Du hast ja schon genug Geduld geopfert. Danke. Ich habe (oben) noch 'nen Sack Arbeit dazubekommen, mal schauen ob ich das heute noch schaffe, sonst evtl morgen. Und dann machen wir 'nen neuen fred . vg jörg
Hi Fidel,
habe die defaults.php geändert, jetzt in deutsch :) Danke.
Deinen neuen Thread habe ich gefunden, kurz nachdem ich meine Anfrage gepostet habe.. wie es halt so is...
Gru0 Kai
@Jörg und auch alle anderen:
Ich habe ein neues Phänomen, kann aber nicht genau sagen, seit wann.
Wenn ich SV auf dem iPhone als Web-App benutze (full screen nach "zum home-Bildschirm hinzufügen"), dann kann ich die rooms_menu sauber aufrufen, alle gads aktualisieren sich. Dann rufe ich einen Raum auf (egal, welchen) und alles ist gut. Dann auf das Haus oben links, rooms_menu öffnet sich - aber außer zwei gads (Garagentor-Shutter und Energieverbrauch-SVG aktualisiert sich nichts.
Im Desktop-Browser nicht nachstellbar und - der Hammer: im nicht-Web-App modus im mobile Safari auch nicht.
Nun fällt mir überhaupt nichts ein, wie ich diesen Fehler eingrenzen könnte - habt Ihr eine Idee?
Hi Bernd,
doofes Ding - Setz mal bitte fronthem auf verbose 4 und schau mal im log ob fronthem die GAD vals sendet und wie die Monitor Anforderung von sv aussieht.
vg
jörg
@Jörg: schau ich gleich nach.
Auch wenn ich nerve: was hältst Du hiervon?
http://forum.fhem.de/index.php/topic,32660.msg255149.html#msg255149
Habe das Verhalten was bgewehr beschreibt auch seit gestern beobachtet.
Chrome, Android 4.4 und 5 egal ob web app oder Browser.
Ich bin der Meinung man kann es durch sehr schnelles hin her schalten provozieren....
Zitat von: bgewehr am 01 Februar 2015, 14:05:49
@Jörg: schau ich gleich nach.
Auch wenn ich nerve: was hältst Du hiervon?
http://forum.fhem.de/index.php/topic,32660.msg255149.html#msg255149
He, kein prob :)
ich hab ja schon meinen Senf dazugegeben, ich halte es für die besser (auch einfacher in Umsetzung und Anwednung) die Funktionalität in dem uszu device zu kapseln. Das uszu device lässt sich dann so konfigurieren des es direkt selber schaltet (set rollo hoch .. ) oder/und ein event feuert.
Das ist im übrigen fast das was du machst - der code liegt halt nicht mehr in x Dateien sondern nur einer (uszu).
Aber ich muss es sowieso noch wegen der bug reports die rein gekommen sind schieben. Also mach doch, ist ja auch ein Prozess.
vg
jörg
Zitat von: fidel am 01 Februar 2015, 14:15:26
Habe das Verhalten was bgewehr beschreibt auch seit gestern beobachtet.
Chrome, Android 4.4 und 5 egal ob web app oder Browser.
Ich bin der Meinung man kann es durch sehr schnelles hin her schalten provozieren....
Jetzt plötzlich, ja nee ne - iss schon klar. Ihr habt Euch doch abgesprochen weil ihr mir den Sonntag nicht gönnt. Gesteht !*!# :)
Im Ernst: same procedure: fronthem verbose 4 und erstmal schauen was sv über die monitor list anfordert. Wir müssen trennen ob das in sv oder in fronthem passiert.
vg
Zitat von: herrmannj am 01 Februar 2015, 14:23:13
Also mach doch, ist ja auch ein Prozess.
Ich schließe mich hier der Meinung von RudolfKönig an und setze UZSU auf WeekdayTimer in fhem um, das scheint super zu passen!
Gesendet von iPhone mit Tapatalk
Zitat von: bgewehr am 01 Februar 2015, 11:49:45
@Jörg und auch alle anderen:
Ich habe ein neues Phänomen, kann aber nicht genau sagen, seit wann.
Wenn ich SV auf dem iPhone als Web-App benutze (full screen nach "zum home-Bildschirm hinzufügen"), dann kann ich die rooms_menu sauber aufrufen, alle gads aktualisieren sich. Dann rufe ich einen Raum auf (egal, welchen) und alles ist gut. Dann auf das Haus oben links, rooms_menu öffnet sich - aber außer zwei gads (Garagentor-Shutter und Energieverbrauch-SVG aktualisiert sich nichts.
Im Desktop-Browser nicht nachstellbar und - der Hammer: im nicht-Web-App modus im mobile Safari auch nicht.
Nun fällt mir überhaupt nichts ein, wie ich diesen Fehler eingrenzen könnte - habt Ihr eine Idee?
Konnte diesen Fehler nun auch am Desktop PC erzwingen.
Smartvisu neu aufrufen. Dann auf einen Raum klicken und sowie dieser angezeigt wird, sofort auf das Haus oben links klicken.
Am Desktop muss man echt schnell sein, auf Smartphone etc. muss man nicht so schnell sein...
Eigentlich werde ich kaum in Verlegenheit kommen im normalen Gebrauch smartVISU so wenig Zeit zum laden zu geben.
Testen, loggen, etc kann ich frühstens heute Abend.
@jörg ist der Aufwand groß den Fehler mit der config.ini und service.php zu patchen?
Zitat@jörg ist der Aufwand groß den Fehler mit der config.ini und service.php zu patchen?
geschenkt wird einem nix ;) Ist umfangreicher. vg jörg
Zitat von: fidel am 01 Februar 2015, 15:54:17
Konnte diesen Fehler nun auch am Desktop PC erzwingen.
Smartvisu neu aufrufen. Dann auf einen Raum klicken und sowie dieser angezeigt wird, sofort auf das Haus oben links klicken.
Am Desktop muss man echt schnell sein, auf Smartphone etc. muss man nicht so schnell sein...
Eigentlich werde ich kaum in Verlegenheit kommen im normalen Gebrauch smartVISU so wenig Zeit zum laden zu geben.
Falls ihr den fhem-Treiber verwendet, dann geht mal auf den Domotiga zurück, ob es dann weg ist.
Gerade eingefallen: voe einiger Zeit (ein zwei Wochen) hatte ich dieses Verhalten bei einer langsamen VPN-Verbindung beobachtet. Da hat die Aktualisierung einfach nach einigen GAD aufgehört. Bei einer schnellen Anbindung war es immer OK.
Falls gegen dieses Problem noch nichts getan wurde, könnte es auch das sein.
der Fehler ist beseitigt. Unter anderem dafür musste ich den fhwebsocket schreiben.
Na dann schaut mal, ob es mit dem Domotiga auch ist.
Zitat von: HCS am 01 Februar 2015, 16:08:08
Falls ihr den fhem-Treiber verwendet, dann geht mal auf den Domotiga zurück, ob es dann weg ist.
Fehler tritt mit beiden Treibern auf...
Wie wäre es mit einem neuen Fred hierfür?
Hallo!
Hatte gerade einen Hänger in sv. Die ersten paar GAD's auf der Seite wurden angezeigt der rest nicht. Da stand dann ---
Im Log hab ich das stehen:
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.336 1: PERL WARNING: Use of uninitialized value $conn in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.02.01 16:39:55.336 1: PERL WARNING: Use of uninitialized value $ressource in concatenation (.) or string at ./FHEM/01_fronthem.pm line 331.
2015.02.01 16:39:55.336 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.336 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.336 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.336 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.336 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.336 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.337 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.337 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.338 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.338 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.339 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.339 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.339 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.339 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.339 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.340 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.340 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.341 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.341 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.342 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.342 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.343 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.343 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.344 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.344 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.345 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.345 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.346 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.346 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.347 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.347 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.348 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.348 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.348 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:55.348 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:55.348 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.416 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.416 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.438 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.438 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.439 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.439 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.439 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.439 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.439 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.439 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.450 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.450 3: fronthem: client fronthemdevice: forced disconnect
2015.02.01 16:39:59.459 1: fronthem fronthemdevice want send but isnt a sender
2015.02.01 16:39:59.460 3: fronthem: client fronthemdevice: forced disconnect
Die Seite hat sehr viele GAD's. Ich schätze mal 90-100 (mit menü)
Grüße
welche version nimmst Du ?
Die Aktuelle.
update all https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
2015-02-01 16:49:43.635 Global global nothing to do...
schau mal zur Sicherheit das die id im git mit Deiner übereinstimmt. Bernd sagte mal das das update bei ihm manchmal spinnt.
moin,
ich kämpfe gerade mit meinem heizungswidget.
sobald die elemente zum setzen der desired temp
Zitat<div class="set">
nicht mehr
direkt unter
Zitat<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
liegen sind sie ohne funktion.
woran liegt das?
ich wollte folgendes umsetzen:
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
<table><tr><td>
<div class="set">
</div>
</td></tr></table>
</div>
es geht aber nur
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
<div class="set">
</div>
</div>
Zitat von: herrmannj am 01 Februar 2015, 14:23:13
ich hab ja schon meinen Senf dazugegeben, ich halte es für die besser (auch einfacher in Umsetzung und Anwednung) die Funktionalität in dem uszu device zu kapseln. Das uszu device lässt sich dann so konfigurieren des es direkt selber schaltet (set rollo hoch .. ) oder/und ein event feuert.
Das ist im übrigen fast das was du machst - der code liegt halt nicht mehr in x Dateien sondern nur einer (uszu).
Jörg, ich habe es soweit fertig, es läuft ganz gut! Viel schlanker und einfacher könnte es doch nicht sein, oder?
Ansatz:
gad_UZSU wird über Converter UZSU an das Reading uzsu am zu schaltenden device get und set gebunden.
Das Reading uzsu muss einmalig mit setreading <device> uzsu '' erstellt werden, sonst lässt sich das UZSU-popup nicht öffnen.
UZSU-Converter:
###############################################################################
#
# Setreading a device reading using JSON conversion (gadval => reading=decode_json() => setval => encode_json(reading) )
#
###############################################################################
sub UZSU(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = decode_json(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$gadval = encode_json($gadval);
$gadval =~ s/;/;;/ig;
$param->{result} = main::fhem("setreading $device $reading $gadval");
$param->{results} = [];
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: UZSU';
}
return undef;
}
Dann wird mit einem einzigen notify auf die Änderungen der UZSU-Settings der SV-gads reagiert:
define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) }
Die Function UZSU_execute liegt oben in der 99_fronthemUtils.pm:
###############################################################################
# $Id: 99_fronthemUtils.pm 0 2015-11-10 08:00:00Z herrmannj $
###############################################################################
package main;
use strict;
use warnings;
use JSON;
sub
fronthemUtils_Initialize($$)
{
my ($hash) = @_;
}
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
$uzsu = decode_json($uzsu);
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
my $weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
fhem('delete wdt_'.$device.'_uzsu'.$i);
fhem('define wdt_'.$device.'_uzsu'.$i.' WeekdayTimer '.$device.' en '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value});
if (($uzsu->{active}) && ($uzsu->{list}[$i]->{active})) {
fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 0');
} else {
fhem('attr wdt_'.$device.'_uzsu'.$i.' disable 1');
}
}
}
package fronthem;
... usw.
Das macht dann aus
{"active":true,"list":[{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"20:00","value":1,"active":true},{"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA","time":"21:00","value":0,"active":true}]}
sehr brav folgendes:
define wdt_Leselampe_uzsu0 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|20:00|1
attr wdt_Leselampe_uzsu0 disable 0
define wdt_Leselampe_uzsu1 WeekdayTimer Leselampe en MO,TU,WE,TH,FR,SA|21:00|0
attr wdt_Leselampe_uzsu1 disable 0
Jörg, bitte sag mir noch was dazu!
Hi Leute,
ich habe eben neue Geräte zu Smartvius hinzugefügt.
Leider werden die in Fhem nicht in der GAD List angezeigt.
Kann ich das manuel aktualiseren?
Was mir auch aufgefallen ist,
wenn ich einen Gad lösche, auch einen der keinem Fhem Device zugeordnet ist, ist der nach einem
"shutdown restart" von Fhem wieder in der GAD Liste.
Fhem und Fronthem sind auf dem neuesten Stand.
Den Fhem Service habe ich auch schon neugestartet.
Danke und Grüße
Gravidi
Zitat von: herrmannj am 01 Februar 2015, 16:51:54
schau mal zur Sicherheit das die id im git mit Deiner übereinstimmt. Bernd sagte mal das das update bei ihm manchmal spinnt.
$Id: 01_fronthem.pm 18 2015-01-18 12:34:48Z. herrmannj $
$Id: 31_fronthemDevice.pm 0 2014-10-01 08:00:00Z herrmannj $
$Id: fhconverter.pm 0 2015-11-10 08:00:00Z herrmannj $
$Id: fhwebsocket.pm 18 2015-01-18 12:34:48Z. herrmannj $
Sollte passen.
Grüße
Ich war wohl zu voreilig, jetzt ist die GAD Liste aktuell.
Trotzdem Danke!
Zitat von: bgewehr am 01 Februar 2015, 18:06:47
Jörg, ich habe es soweit fertig, es läuft ganz gut! Viel schlanker und einfacher könnte es doch nicht sein, oder?
...
Jörg, bitte sag mir noch was dazu!
perfekt ... Gratulation!
Known issues für UZSU:
- on/off wird als 0/1 übermittelt, was für die meisten Schalter nicht funktioniert, ändere ich noch!
Gesendet von iPhone mit Tapatalk
Known issues für UZSU:
- on/off wird als 0/1 übermittelt, was für die meisten Schalter nicht funktioniert, ändere ich noch!
Alle Änderungen sind in meinen GITs.
Gesendet von iPhone mit Tapatalk
Wer reichlich GADs bekommen wird: bei der Vorbereitung vom "Daten-Stress" für die Treiberentwicklung habe ich gerade in FHEM dem GAD-Editor ca. 1100 GADs reingepackt.
Die steckt der locker weg. An der Stelle also kein Problem mit großen Datenmengen.
Zitat von: bgewehr am 01 Februar 2015, 22:16:45
Known issues für UZSU:
- on/off wird als 0/1 übermittelt, was für die meisten Schalter nicht funktioniert, ändere ich noch!
Alle Änderungen sind in meinen GITs.
Gesendet von iPhone mit Tapatalk
Hallo Bernd,
ich benutze dein Homematic Widget für meine Thermostate - wo muss ich ansetzen damit das ganze bei mir (visu.css alles standard) auch komplett mittig ausgerichtet wird? Irgendwie hakts da noch ein bisschen und ich find den Fehler nicht...
Hi, Olli!
Das Widget basiert auf dem device.rtr und dort hat man ein design mit festen Abständen umgesetzt, welches dann bei 5 Tastern unten genau mittig war. Nun sind es 6 Taster und richtet sich etwas falsch aus.
Ich verwende dafür immer den Entwicklermodus (drück mal F12) in Chrome, analysiere die Class und Style Eigenschaften der Dom-Objekte und übernehme dann erfolgreiche Änderungen in die Visu.css.
Da musst Du ansetzen.
Hallo, ich verfolge schon eine ganze Weile diesen thread und finde es sehr spannend und interessant was hier an Ergebnissen abgeliefert wird. Es ist aber richtig, dass es sich hierbei weiterhin um einen "Beta" Status handelt, oder ?
Eine weitere Frage die mich interessiert ist, habt ihr euch alle das Handbuch für 40€ gekauft, oder wie seit ihr sonst in dieses Thema reingekommen.
die komplette doku gibts online (offiziell und kostenlos)... mit beschreibung zum frontend und den scripten/funktionen, dazu das smartvisu forum
evtl jemand infos zu Antwort #1194 ?
Danke Chtis1284 aber ich finde das nicht auf der smartVisu Seite. Mir wird nur eine "Lektion" angezeigt. :-\ Kannst Du mir einen Link geben? Danke.
erst heuite nachmittag da der proxy smartvisu für pöse hält ??? ich habe das mal auf der siete gefunden als ich nach array-händling im smartvisu gesucht habe.
Zitat von: chris1284 am 01 Februar 2015, 17:13:35
moin,
ich kämpfe gerade mit meinem heizungswidget.
sobald die elemente zum setzen der desired temp
nicht mehr direkt unterliegen sind sie ohne funktion.
woran liegt das?
ich wollte folgendes umsetzen:
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
<table><tr><td>
<div class="set">
</div>
</td></tr></table>
</div>
es geht aber nur
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
<div class="set">
</div>
</div>
Hi,
das wird in der src (den selectoren) so programmiert sein. Die table hast Du um das Ding mittig zu setzen - oder ? Mach doch über die visu.css ohne table, table sind sowieso doof um layout zu steuern ... ;D
vg
jörg
.rtr .set .temp {
width: 80px;
height: 48px;
padding-top: 10px;
float: left;
font-size: 1.2em;
font-weight: bold;
}
.rtr .control .state {
font-size: 1.4em;
font-weight: bold;
}
.rtr .control .batt .icon {
width: 30px;
height: 30px;
margin-top: -8px;
}
es sollte eigentlich ein 3 spaltiges layout werden
1. links 100% hoch, 50% breit ,2. links 100% hoch, 50% breit -> in dieser dann 2 tr''s mit je 50% höhe
ich meine aber es verhält sich auch so wenn man den set div in einen anderen schachtelt, so das er nicht direkt im
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr"> liegt
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(1.0) }}" class="rtr">
<div>
<div class="set">
</div>
</div>
</div>
Hi Chris,
das habe ich jetzt nicht genau verstanden, daher nehme ich nochmal die Ursprungsfrage "warum geht es nicht" : Weil es so programmiert ist.
Das dahinter liegende js-widget sucht sein "set" vmtl genau eine Ebene unterhalb des gui-widget (html). Wenn da ein span/div/table dazwischenliegt findet er sein set nicht mehr.
Btw: lasst uns solche Dinger in jeweils eigenen threads machen und hier die fronthem bezogen Fragen
vg
jörg
ok, aber ich werde mir die js mal anschauen.
Anebi noch deie links zu den dokus die ichgefunden habe:
Doku zu basic widgets , device widgets , usw usw http://www.smartvisu.de/docu/2.7/index.php
der rest ist eigentlich das twig-template http://twig.sensiolabs.org/documentation zb variablen, funktionen usw
EDIT: um es abzuschließen
Ich habe die widget.js editiert undmit eine neue device"klasse" hmccrtdn angelegt. rtr wird nun für hm-thermostate bei mir nicht mehr verwendet. die set funktion schaut nun direkt in ihrem div nach den device-parametern(id, step usw)
Heute hatte ich einen interessanten Fall. Nach einigen page-reloads über eine recht langsame VPN-Verbindung war plötzlich FHEM weg.
Nach dem FHEM Neustart (und auch einigen weiteren) bekam der SV-Treiber keine Verbindung mehr zum WebSocket-Server.
Das FHEM-Log meint, dass der Port 2121 nicht mehr auf geht.
Konnte mich leider nicht weiter mit beschäftigen, also den Server neu gebootet. Danach war es wieder OK.
Aus dem FHEM-Log (bei jedem Neustart von FHEM vor dem Server-Neustart vertreten):
2015.02.02 17:05:54 3: ipc fronthem:127.0.0.1:57231 (ws): ws alive with pid 20523
2015.02.02 17:05:54 1: ipc fronthem:127.0.0.1:57231 (ws): ws could not open port 2121
2015.02.02 17:05:54 1: fronthem: thread ws closed for unknown reason
ok...die online Doku habe ich verstanden. Jetzt habe ich Bock auf mehr! Gibt es irgendwo in auf den 81 Seiten dieses Threads eine Anleitung zur Einrichtung von smartVISU, ausgenommen der #1Beitrag. :-\
Beitrag 212... !?
immer wieder, einzelne Post, ins Wiki hat es aber glaub ich nichts geschafft. Im Ernst, lasst uns dafür jeweils ein neues Themen aufmachen.
vg
jörg
Eine Installationsanleitung habe ich mal hier angefangen
http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem)
Zitat von: Jojo11 am 25 Dezember 2014, 06:58:56
Hallo,
ich bin von diesem Projekt sehr begeistert und habe natürlich auch gleich versucht, smartVISU ans Laufen zu bekommen. Ich bin nach dieser Anleitung vorgegangen: http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117 (http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117)
Gesendet von iPhone mit Tapatalk
Hi,
bzgl der Einheiten: hier https://github.com/herrmannj/smartvisu-cleaninstall/ ein jungfräuliches sv hinterlegt wo sowohl die extensions (multiuser) schon drin sind als auch die Geschichte mit den Lokalisierungen repariert ist. (der shifter ist im sv Ursprungszustand, muss also noch gepatcht werden). Einzig bei "Berlenz" zickt der bei mir (config wird geschrieben aber mit Fehlermeldung), hab ich noch nicht durchschaut. *
Leider suboptimal: um von da aus ein bestehendes sv zu aktualisieren muss man sich die Dateien einzeln rauspicken, ich habe noch keine einfache Lösung.
Diese Dateien müssen ersetzt werden:
index.php
lib/functions_config.php
lib/includes.php
pages/base/configure.php
Denkt bitte daran und erstellt Sicherheitskopien !
vg
jörg
* leider wiedermal vergessen den treiber rechtzeitig auf offline zu stellen ....
Zitat von: herrmannj am 02 Februar 2015, 23:08:49
Hi,
bzgl der Einheiten: hier https://github.com/herrmannj/smartvisu-cleaninstall/ ein jungfräuliches sv hinterlegt wo sowohl die extensions (multiuser) schon drin sind als auch die Geschichte mit den Lokalisierungen repariert ist. (der shifter ist im sv Ursprungszustand, muss also noch gepatcht werden). Einzig bei "Berlenz" zickt der bei mir (config wird geschrieben aber mit Fehlermeldung), hab ich noch nicht durchschaut. *
Leider suboptimal: um von da aus ein bestehendes sv zu aktualisieren muss man sich die Dateien einzeln rauspicken, ich habe noch keine einfache Lösung.
Diese Dateien müssen ersetzt werden:
index.php
lib/functions_config.php
lib/includes.php
pages/base/configure.php
Denkt bitte daran und erstellt Sicherheitskopien !
vg
jörg
* leider wiedermal vergessen den treiber rechtzeitig auf offline zu stellen ....
Hallo Jörg
habs getestet, jetzt werden die Daten eingestellten Daten aus der config verwendet.
Vielen Dank
Gruß
Steven
super danke. funktioniert bei Dir das speichern unter berlenz ? (schalte vorher den driver auf offline... )
vg
jörg
Nicht ohne Fehlermeldung ( rotes Dreieck).
Wobei die confg scheinbar trotzdem übernommen wird.
nur bei berlenz, oder .. ? verstanden hab ichs nich ...
Scheint so, bin jetzt nicht alle durchgegangen.
Was mir auffällt ist, dass beim umstellen auf Berlenz auf der config Seite die box für die Telefon Konfiguaration verschwindet.
Beim speichern von Berlenz fragt Chrome ob diese Einstellungen Telefonbenutzer und Passwort in Chrome gespeichert werden sollen.
Auch der Animation on/off Button verschwindet.
pling!
Das isses! der hat die page überschrieben. ... Ich hab das auch nicht so tief untersucht aber immerhin tief genug um den Fehler bei mir zu suchen ... argh
Danke und vg
jörg
Schön dir geholfen zu haben, ohne etwas zu verstehen... :D
in dem berlenz directory verwendet Herr/Frau Berlenz nicht die normale config Seite sondern er hat eine eigene erstellt. Die hat einen bug. Deswegen auch nur bei Berlenz ....
vg
jörg
Danke für die Erklärung.
Habe die config.html unter berlenz rausgeschmissen und dann funktioniert das auch ohne Fehler. ;)
Zitat von: herrmannj am 02 Februar 2015, 23:08:49
bzgl der Einheiten: hier https://github.com/herrmannj/smartvisu-cleaninstall/ ein jungfräuliches sv hinterlegt wo sowohl die extensions (multiuser) schon drin sind als auch die Geschichte mit den Lokalisierungen repariert ist. (der shifter ist im sv Ursprungszustand, muss also noch gepatcht werden)
Ich habe den FHEM-Treiber hinzugefügt.
Neue Versionen vom Treiber werde ich dann nicht mehr im Thread sondern grundsätzlich in diesem repository bereitstellen.
Zitat von: herrmannj am 02 Februar 2015, 23:08:49
* leider wiedermal vergessen den treiber rechtzeitig auf offline zu stellen ....
Eventuell wäre ein optionaler Modus im fronthem device sinnvoll, der neue GADs erst mal sammelt und erst auf Wunsch übernimmt.
Beim Entwickeln der Page in SV passiert es auch manchmal, dass einem das eine oder andere GAD "rausrutscht", das man so nicht wollte.
Hallo,
mal eine ganz dumme Frage. Ich habe Probleme mit Filezilla meine Smartvisu-Dateien zu überspielen. Ich bekomme immer diese Fehler: /var/www/smartvisu/index.php: open for write: permission denied
Ich weiß daß es an den Rechten liegt. Diese sind rw-r-r. Damit sollte es doch eigentlich funktionieren. Oder wo habe ich meinen Denkfehler?
Gruß, Sascha
Welcher Benutzer ist den am Filezilla angegeben?
Gesendet von iPhone mit Tapatalk
Du meinst bei den Servereinstellungen, oder. Da habe ich "PI" weil den Benutzer brauche ich ja für den Raspberry. Und Besitzer/Gruppe der Datei ist jeweils "www-data". Das muß ja wohl auch so.
Zitat von: Cybers am 03 Februar 2015, 11:01:28
Hallo,
mal eine ganz dumme Frage. Ich habe Probleme mit Filezilla meine Smartvisu-Dateien zu überspielen. Ich bekomme immer diese Fehler: /var/www/smartvisu/index.php: open for write: permission denied
Ich weiß daß es an den Rechten liegt. Diese sind rw-r-r. Damit sollte es doch eigentlich funktionieren. Oder wo habe ich meinen Denkfehler?
Gruß, Sascha
rw-r--r--
rw- bedeutet Besitzer darf lesen und schreiben. Besitzer der Datei auf dem Raspberry ist vermutlich www-data.
r-- bedeutet Gruppe darf lesen. Gruppe der Datei auf dem Raspberry ist vermutlich www-data
r-- bedeutet restliche Benutzer dürfen nur lesen.
Mit FileZilla meldest du dich als Benutzer PI mit der Gruppe www-data an.
Demnach ist es schon richtig, dass du nicht schreiben darfst...
Hi Leute,
ich stehe irgentwie auf dem Schlauch.
Ich habe diverse presence devices.
Fhem:
define pre_htpc_wohnzimmer PRESENCE lan-ping 192.168.0.20
Smartvisu:
{{ basic.text('pre_htpc_wohnzimmer', 'pre_htpc_wohnzimmer.sw') }}
Converter Fronthem:
reading: state
converter: direct
cmd set: state
Leider wird nichts an SmartVisu übergeben. Diverse Spielereien habe ich schon hintermir. In Fhem funktioniert PRESENCE tadellos.
Was habe ich übersehen?
Danke und Grüße
Grav
Versuche es mal mit basic.value.
Und der converter heißt Direct.
@marvin
Macht Sinn,
danke.
Lag am basic.value .
Hallo,
auf die Gefahr hin, dass diese Frage hier schon gestellt wurde: Funktioniert webviewcontrol schon mit Audioausgabe? Würde gerne auf einem tablet durch fhem gesteuert eine Audio-Datei abspielen können.
Nachdem ich mein tab auf Android 4.4.4 aktualisiert habe, funktioniert WVC :)
schöne Grüße
Jo
Hallo Leute,
ich wollte hier auch mal ein Bild meiner Haussteuerung hinterlassen, auch wenn der GB schon vorbei ist :)
Auf dem Bild zu sehen:
Default SmartVisu, mit ein paar Geräten und dem Livestream (transkodierter RTSP) des Hauseingangs.
Das ganze auf einem IPad, das im Flur an der Wand hängt. Auf der Rückseite habe ich eine USB Steckdose einsetzen lassen.
Zusätzlich nutze ich mediabrowser, was eine responsive gui mitbringt um im ganzen Haus (und auf dem IPad im Flur) meine Medienbiblo streamt.
Als nächstes geplant:
Rauchmelder, Rollos, Deckenlampen, Fussbodenheizung umbauen ^^
Vielen Dank für die Entwicklung der Extension!
Grüße
Grav
cooler Rahmen, hast du den selbst gebaut oder gibt es denn irgendwo zu kaufen?
grüße
sebinger
Einen passenden Rahmen zu finden war eine echte Qual.
Der jetzige Rahmen kommt aus der Bucht. Er lässt sich wirklich gut montieren und das IPad ist da drin sicher.
http://www.ebay.de/itm/Wandhalterung-passt-fur-iPad-2-3-4-Generation-Tablet-Halter-Halterung-weiss-/131222993066?pt=DE_iPad_Tablets_PCs_Zubeh%C3%B6r&hash=item1e8d7ff8aa
Was den Einbaurahmen angeht schau mal hier: http://homematic-forum.de/forum/viewtopic.php?f=18&t=13972&hilit=Flurprojekt+mit+Android+Tablet+Wandeinbau&sid=f1c61b291ddfbb2072ea7630c8735043 (http://homematic-forum.de/forum/viewtopic.php?f=18&t=13972&hilit=Flurprojekt+mit+Android+Tablet+Wandeinbau&sid=f1c61b291ddfbb2072ea7630c8735043)
Einfach Superuser002 kontaktieren, der produziert für verschiedene Tablets diese Einbaurahmen.
Hier ein Auszug aus einer PN vom August letzten Jahres:
"Rahmen habe ich für das IPad 2-4, Samsung Galaxy Tab 3 10.1 und Samsung Tab N 10.1 .
Die Kosten belaufen sich auf 70 Euro plus Versand. Da ist dann alles für den Rahmen dabei."
Gruß, Sascha
@Cybers
Der Rahmen ist wirklich sehr schick! Danke für den Link!
Zitat von: herrmannj am 02 Februar 2015, 23:08:49
Hi,
bzgl der Einheiten: hier https://github.com/herrmannj/smartvisu-cleaninstall/ ein jungfräuliches sv hinterlegt wo sowohl die extensions (multiuser) schon drin sind als auch die Geschichte mit den Lokalisierungen repariert ist. (der shifter ist im sv Ursprungszustand, muss also noch gepatcht werden). Einzig bei "Berlenz" zickt der bei mir (config wird geschrieben aber mit Fehlermeldung), hab ich noch nicht durchschaut. *
Leider suboptimal: um von da aus ein bestehendes sv zu aktualisieren muss man sich die Dateien einzeln rauspicken, ich habe noch keine einfache Lösung.
Diese Dateien müssen ersetzt werden:
index.php
lib/functions_config.php
lib/includes.php
pages/base/configure.php
Denkt bitte daran und erstellt Sicherheitskopien !
vg
jörg
* leider wiedermal vergessen den treiber rechtzeitig auf offline zu stellen ....
Wenn ich Smartvisu mit den Dateien aus dem Link installiere wird die Konfigurationsseite nicht richtig angezeigt. Es muß an der configure.php liegen.
Gruß, Sascha
Zitat von: herrmannj am 03 Februar 2015, 17:19:10
das mit dem "OnOff" hatten wir schon mal bei den hue, die machen das wohl ähnlich.
Generell erwartet der OnOff natürlich ein "on" und kein "on 100" ... zum Glück gehts trotzdem. Hab gerade ein fix dazu eingespielt, damit gehts ...
vg
jörg
Hallo Jörg,
seit dem update gestern, stehen meine HUE Bulbs im ausgeschaltenen Zustand in smartvisu (stromlos über normalen Lichtschalter) ständig auf on.
In Fhem führen die Hue´s im ausgeschaltenen Zustand den Status unreachable.
Wenn ich die geänderte Zeile im fhconverter sehe, erschließt sich das auch.
Da die Milights bei on einen anderen Zustand haben, stellt sich hier die Frage ob du ne Idee hast das anders abzufangen?
Ist nicht ein Vergleich nach dem Motto "on.*" mögich!? :)
Gruß Steven
Zitat von: Cybers am 04 Februar 2015, 13:22:17
Wenn ich Smartvisu mit den Dateien aus dem Link installiere wird die Konfigurationsseite nicht richtig angezeigt. Es muß an der configure.php liegen.
Gruß, Sascha
Hi
also ich habe damit keine Probleme.
Passen Rechte und Dateibesitzer?
Hast du auf berlenz aufgebaut?
Grüße
anbei ein Bild wie die Seite dann ausschaut...
Ich hatte es auch schon am Laufen. habe denn die vier von hermannj genannten Dateien aufgespielt und danach sah die Seite dann so aus. Darauf habe ich nochmal alle Dateien aus dem genannten Link frisch aufgespielt aber auch hier läuft es wieder nicht. Gerade bin ich nocheinmal wie folgt vorgegangen und habe die Dateien von Smartvisu statt der von hermannj genommen. Aber auch hier wieder das gleiche Bild (siehe letzter Beitrag):
$ mkdir ~/install
$ cd ~/install
$ wget http://smartvisu.de/download/smartVISU_2.7.zip
$ unzip smartVISU_2.7.zip
2. Install files
$ sudo cp -rp smartVISU /var/www/smartvisu
$ cd /var/www/smartvisu
$ sudo chown -R www-data:www-data /var/www/smartvisu
die erste Seite nach dem erstmaligen Aufrufen von Smartvisu bevor man auf Config klickt wird richtig angezeigt (siehe Bild unten)
Zitat von: Cybers am 04 Februar 2015, 14:05:26
anbei ein Bild wie die Seite dann ausschaut...
Hi,
Das sieht irgendwie aus als würde CSS fehlen.
Cache in vs löschen (temp), und sonst mal in der Console schauen.
Vg
Jörg
das Löschen von temp hat auch nichts gebracht. Jetzt habe ich wieder das komplette Smartvisu-Verzeichnis gelöscht und wieder alles neu aufgespielt. Jetzt läuft es auch mit den Dateien von hermannj. Keine Ahnung was los war...
2 Themen
Da die Performance von Smartvisu auf dem Rpi doch ein wenig zu wünschen übrig lässt, habe ich mir gestern fhem und Smartvisu auf einem Cubietruck installiert.
Alles scheint verbunden, aber ich sehe leider die gad´s nicht in meiner fhem installation (Bild Cubietruck). Hat jemand eine Idee, woran es liegen könnte bzw. was ich dagegen machen könnte? Habe Berechtigungen schon neu gesetzt und es mit verschiedenen Beispieldateien versucht.
Das 2. Thema wäre eher allgemeiner Art.
Da ich FHEM zur Zeit komplett neu auf dem Cubietruck aufsetzen möchte mache ich mir Gedanken, wie ich dies zukünftig bewerkstelligen soll. Hintergrund ist, dass fhem und Smartvisu doch eher Bastellösungen sind, die keinen Support liefern. Daher möchte ich die wichtigen Elemente (Heizungssteuerung) durch die bestehende Hardware erledigen lassen. (i.d.R Homematic). "Kritische" Themen (z.B. Zeit- und Temperatur abhängiges Schalten der Elemente) laufen bei mir derzeit nur über das heating control Modul von fhem. Im Fehlerfall (bzw. wenn ich mein Haus einmal Verkaufen möchte), wird die Heizung bei fehlerhaftem fhem natürlich crashen. Daher möchte ich für mich ein Konzept erarbeiten, in dem fhem und Smartvisu "nur" noch zur komfortablen steuerung bzw. für eine ansprechende Visualisierung genutzt werden.
Macht das Eurer Meinung nach Sinn? Hat jemand von Euch sich darüber schon Gedanken gemacht?
In einem ersten Schritt habe ich versucht die Elemente einmal auf einem Schaubild zusammen zu stellen. Über Anregungen/Tipps würde ich mich freuen.
Gruß
Gerd
Zitat von: Cybers am 05 Februar 2015, 12:08:48
das Löschen von temp hat auch nichts gebracht. Jetzt habe ich wieder das komplette Smartvisu-Verzeichnis gelöscht und wieder alles neu aufgespielt. Jetzt läuft es auch mit den Dateien von hermannj. Keine Ahnung was los war...
komisch, ich hab einen "kalten Install" mit dem GIT getestet da lief es. Naja, jetzt klappt es, viel Spaß :)
Hi Gerd,
zu #1, mach mal einen Neustart von fhem, danach in sv aktualisieren (ctrl-f5). Denk auch daran den chache in sv auszuschalten und nach Änderungen in sv den Inhalt den /temp/ Dirs unterhalb von sv zu löschen.
zu #2 das mit "Bastel" und "Support" verstehe ich jetzt nicht ganz genau, ich vermute Du beziehst das auf das was Du selbser in fhem und sv programmierst. Generell ja, und im speziellen sv: richtig: sv ist gut wenn man selber deutlich am Frontend anpassen (sag programmieren) will. Viel Macht, viel Verantwortung ;)
Der Rest ist so generisch ("was passiert mit meinem Haus wenn fhem abstürst ?") da würde ich Dich bitten einen neuen thread für auf zumachen. Nicht böse gemeint, aber hier soll es um features, Wünsche, evtl bugs in ftronthem gehen.
vg
jörg
Ich zietiere aus dem anderen (SmartVisu) Thread, weil es eigentlich hier hin gehört:
ZitatHi, ja witzig, das sollten wir eigentlich im fronthem thread weitermachen, da wo gerade "allgemeine Fragen" auftauchen :)
Antwort: im Prinzip ja - logisch gern.
Wenn Du Dir im Wiki die lichtszene anschaust - da mach ich das mit buttons und einem dummy. Ist von Prinzip her ähnlich. Ich wüsste jett ad hoc nicht wie man dynamische Listen komfortabel abbildet... Das setzt ja voraus dass das selecet widget überhaupt mal seine Inhalte dynamisch aktualisieren kann und es müsste eine, möglichst universelle, Art geben die Listen dann auszulesen. Alles andere wäre modulspezifisch. Das geht auch, setzt aber voraus das die entsprechenden Modul erweitert werden.
Man kann converter für solche Fragestellungen direkt ins modul einbauen. Das macht immer dann Sinn wenn die Logik des Moduls "mitarbeiten" muss (wie hier, im Prinzip kennt das yamaha modul die notwendigen Bedien-Dinger wie Channel etc).
Das wird aber nur funktionieren wenn der entsprechende Autor des Moduls "Bock drauf hat", evtl weil er smartVisu selbst einsetzt.
Ich bin für Vorschläge offen, kanns aber nicht leisten module dafür anzupassen. Ansonsten statisch: zB für channel gibt es ja einige Beispiele die Buttons auf der GUI zu ordnen, Icons (Das Erste...) dahinter zulegen usw. Das klappt ja Problems los. Um bei dem Beispiel Channel zu bleiben, das willst Du ja auch eine bestimmte Reihenfolge haben (Das Erste, ZDF, ...) da müsste man ja sowieso "händisch" ordnen.
Lass mal mit dem Ding im fronthem thread weitermachen.
vg
jörg
Das mit dem Sortieren ist schon richtig. Aber das war auch nur ein Beispiel. Es gibt ja viele Module, die solche set-Listen enthalten. Und bei den meisten reicht eine Sortierung nach Alphabet. Die Channel waren da eventuell ein falsches Beispiel.
Statisch ist natürlich kein Problem. Ich habe ja das Select-Widget aus dem anderen Thread statisch in Verwendung (also die entsprechenden List-Einträge in SmartVisu redundant und fest eingebaut). Da wäre als Beispiel ein Squeezebox-Player Widget. Das habe ich aus dem Multimedia-Widget gebastelt. Ich kann dort in dem Select die Favoriten wählen (das ist auch der Grund, aus dem mir die 10 Einträge von bewehrs Widget nicht reichten und ich es auf dynamisch umgebaut habe). Diese muss ich aber ggf. im Logitech Media Server definieren (FHEM bekommt sie dann automatisch) und noch in SmartVisu. Ein Luxusproblem aber doch unkomfortabel. Ich habe mir auch schon selbst Gedanken darüber gemacht, wie man das lösen könnte (und mir dazu die readingsGroup angeschaut, die genau das kann), komme aber zum verrecken nicht drauf, wie man diese Sachen per WebSocket aus FHEM heraus bekommt. Ich bin aber auch wirklich kein PERL-Kenner. Allerdings habe ich auch erst sehr wenig Zeit darauf verwendet. Bis August/September ist eigentlich jede wache Stunde meiner Zeit verplant.
also wenn man ein konkretes reading und ein dazu gehöriges set hat könnte das schon funktionieren. Dazu muss aber auch die selectlist mitspielen (sprich passend programmiert werden).
Ich würde das jetzt allerdings auf der prio liste eher nach hinten setzen.
Vielleicht macht es Sinn im neuen fronthem thread (der hier ist eigentlich durch ... ) eine Wunschliste einzubauen und bestimmte features zur Abstimmung zu stellen um Prioritäten "demokratisch" zu orden. Gibt ja einige, speziell converter, uzsu (weiß nicht genau ob ich da noch gefordert bin oder ob die Lösung so steht), Android App mit tts und so, Plots, ssl ... usw
vg
jörg
Die Prio sehe ich nicht besonders hoch. Mir geht es eher um deine Einschätzung der Machbarkeit.
Ich sehe die Prioritäten eher bei Stabilität (schon sehr gut), Plots und WebApp. USZU ist in meiner persönlichen Prio-Liste sehr weit unten aber das sehen hier viele anders ;)
Hallo,
ich bin nach folgender Anleitung http://www.fhemwiki.de/wiki/Installation_Fronthem#Installation_smartVISU (http://www.fhemwiki.de/wiki/Installation_Fronthem#Installation_smartVISU)
vorgegangen. Bekomme aber bei der Installation folgende Meldung:
Zitatpi@raspberrypi ~ $ sudo cp -rp smartVISU /var/www/smartvisu
cp: cannot stat `smartVISU': No such file or directory
im Verzeichnis 'var' gibt es keinen weiteren Unterordner 'www'.
Daher meine Frage: Muss es nicht lauten: sudo cp -rp smartVISU /opt/fhem/www/smartvisu ?
ja genau, dann kann man das ein wenig ordnen.
Stabilität und Zuverlässigkeit sind auf Platz 1 gesetzt. Dann ist das ja auch keine Auftragsarbeit sondern ich mach das ja weil ich es benutzte, die App steht für mich sehr hoch (Das sind dann die Grenzen der demokratie ;D ). Viele andere Sachen ordnen wir dann. Wir können ja schon mal sammeln ich mach mal einen thread auf.
vg
jörg
Zitat von: bjoernbo am 05 Februar 2015, 14:15:19
Hallo,
ich bin nach folgender Anleitung http://www.fhemwiki.de/wiki/Installation_Fronthem#Installation_smartVISU (http://www.fhemwiki.de/wiki/Installation_Fronthem#Installation_smartVISU)
vorgegangen. Bekomme aber bei der Installation folgende Meldung:
im Verzeichnis 'var' gibt es keinen weiteren Unterordner 'www'.
Daher meine Frage: Muss es nicht lauten: sudo cp -rp smartVISU /opt/fhem/www/smartvisu ?
Hi,
wegen schnellem Wachstum des Projektes: ich würde Dir empfehlen für smartVISU direkt die angepasste Version aus dem git zu installieren https://github.com/herrmannj/smartvisu-cleaninstall/archive/master.zip
Da hat sich das wiki schon ein klein wenig überholt. Bei der Installation bist Du frei, die Dateien von sv müssen in Dein Webserver Verzeichnis.
vg
jörg
Danke für die Info. Habe die Master installiert. Frage zum Webserver.... ich habe zuvor nginx installiert .. ich finde das Verzeichnis nicht :-\
Ich habe heute auch mal versucht smartVisu zu installieren.
Leider bekomme ich beim define eine Fehlermeldung!
2015.02.05 14:32:18.159 1: reload: Error:Modul 01_fronthem deactivated:
Can't locate Net/WebSocket/Server/Connection.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at FHEM/fhwebsocket.pm line 27.
BEGIN failed--compilation aborted at FHEM/fhwebsocket.pm line 27.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.02.05 14:32:18.160 0: Can't locate Net/WebSocket/Server/Connection.pm in @INC (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at FHEM/fhwebsocket.pm line 27.
BEGIN failed--compilation aborted at FHEM/fhwebsocket.pm line 27.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.02.05 14:33:11.809 1: reload: Error:Modul 01_fronthem deactivated:
Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
2015.02.05 14:33:11.810 0: Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Den Webserver habe ich eigentlich erfolgreich mit cspan installiert. Fehlt noch etwas?
das vielleicht Net::WebSocket::Server ?? vg jörg
Zitat von: herrmannj am 05 Februar 2015, 14:54:31
das vielleicht Net::WebSocket::Server ?? vg jörg
Nein ich glaube nicht!
root@cubie:(0)/root//cpanm Net::WebSocket::Server
Net::WebSocket::Server is up to date. (0.003001)
Muss ich einen Pfad anpassen?
Zitat von: bjoernbo am 05 Februar 2015, 14:33:54
Danke für die Info. Habe die Master installiert. Frage zum Webserver.... ich habe zuvor nginx installiert .. ich finde das Verzeichnis nicht :-\
sorry, da bin ich raus (der install von nginx ist durchaus systemabhängig).
Google sollte da aber sehr gut weiterhelfen können. Nginx ist weit verbreitet, gibt tutorials wie Sand am Meer dazu, wirst keine Probleme haben de Infos zu finden.
vg
jörg
Zitat von: P.A.Trick am 05 Februar 2015, 14:56:16
Nein ich glaube nicht!
root@cubie:(0)/root//cpanm Net::WebSocket::Server
Net::WebSocket::Server is up to date. (0.003001)
Muss ich einen Pfad anpassen?
normal nicht, Web::Socket::Server hat die Abhängigkeiten für connection etc drin und cpan installiert die, da stimmt also auf Deinen sys was nicht. Evtl per Hand ? Net::WebSocket::Server::Connection ...
Can't locate Net/WebSocket/Server/Connection.pm in @INC
habe mir nun das www Verzeichnis in var angelegt. Testweise eine info.php Datei angelegt.Beim Aufruf erhalte ich die Meldung 502 Bad Gateway.
Ich bin zwar jetzt schon ein Stück weiter, aber nicht nicht am Ziel :-[
Du musst dich mit nginx beschäftigen. Dazu sollte hier nicht auch noch Support geleistert werden. Schau dir mal an, wie man nginx konfiguriert, dann findest du auch heraus, wie das mit dem Pfaden auf deinem speziellen System ist.
Zitat von: herrmannj am 05 Februar 2015, 15:03:18
normal nicht, Web::Socket::Server hat die Abhängigkeiten für connection etc drin und cpan installiert die, da stimmt also auf Deinen sys was nicht. Evtl per Hand ? Net::WebSocket::Server::Connection ...
Can't locate Net/WebSocket/Server/Connection.pm in @INC
Hm...im apt finde ich auch kein passendes Paket. Naja, dann warte ich erst einmal ab!
Hallo hermannj,
zu #1, mach mal einen Neustart von fhem, danach in sv aktualisieren (ctrl-f5). Denk auch daran den chache in sv auszuschalten und nach Änderungen in sv den Inhalt den /temp/ Dirs unterhalb von sv zu löschen.
danke für die Tips. Haben leider nicht geholfen.
Kann es damit zusammenhängen, dass ich meinen produktiv raspi vom gleichen PC bediene?
Werde das heute abend einmal ausprobieren.
Gerd
Zitat von: P.A.Trick am 05 Februar 2015, 16:14:06
Hm...im apt finde ich auch kein passendes Paket. Naja, dann warte ich erst einmal ab!
fragt sich worauf ? ???
http://search.cpan.org/~topaz/Net-WebSocket-Server-0.001/lib/Net/WebSocket/Server/Connection.pm
Zitat von: herrmannj am 05 Februar 2015, 17:06:14
fragt sich worauf ? ???
http://search.cpan.org/~topaz/Net-WebSocket-Server-0.001/lib/Net/WebSocket/Server/Connection.pm
Ist schon klar, aber was soll ich tun? Laut cspan ist es ordnungsgemäß installiert!?
Hi P.A.Trick
Ich verwende lighttpd, das läuft problemlos.
Ich hatte mal irgendwann auf einem Test-Cubie nginx und apache auprobiert, wollte sehen, wer der Schnellste ist.
Apache war nicht merklich schneller oder langsamer als lighttpd.
Auf nginx habe ich es nicht zum Laufen gebracht, aber mich dann auch nicht intensiver damit beschäftigt, weil es mir irgendwann egal war.
Wenn Du also nicht unbedingt auf nginx stehst, könntest Du Dein Glück mal mit lighttpd versuchen.
Zitat von: P.A.Trick am 05 Februar 2015, 17:59:08
Ist schon klar, aber was soll ich tun? Laut cspan ist es ordnungsgemäß installiert!?
Hi,
no, isses nicht :) ! Das steht da auch ganz klar, die Abhnängigkeit Net::WebSocket::Server::Connection ist bei Dir nicht installiert.
Can't locate Net/WebSocket/Server/Connection.pm in @INC Das musst Du irgendwie mit Deinem perl ausmachen, fronthem wird daran auch in der Version 1000 nichts ändern ;)
vg
jörg
Naja. Es ist eigentlich nichts einfacher als ngingx. Ich denke auch nicht, dass P.A.Tricks Probleme an dem Webserver liegen, sondern, wie hermannj schon sagt am fehlenden PERL Modul.
Aber warten hilft hier natürlich nicht, denn magisch installieren wird sich das Paket nicht. ;)
Na das Modul ist da, leider scheinbar mit den falschen Rechten.
Ich hab's mal auf 775 gesetzt, allerdings bekomme ich dann:
Attempt to reload Net/WebSocket/Server/Connection.pm aborted.
Compilation failed in require at ./FHEM/fhwebsocket.pm line 27.
BEGIN failed--compilation aborted at ./FHEM/fhwebsocket.pm line 27.
root@cubie:(0)/usr/local/share/perl/5.14.2/Net/WebSocket/Server//ll
total 16K
-rwxrwxr-x 1 root staff 14K Sep 7 08:16 Connection.pm
root@cubie:(0)/usr/local/share/perl/5.14.2/Net/WebSocket/Server//
nachdem ich nginx Dienstalter habe und alles nochmal von vorne installiert habe erhalte ich weiterhin => 502 Bad Gateway.
Nachdem ich in das Log-File geschaut habe, muss ich feststellen, dass hier noch einiges für mich zu tun ist, aber ich ich weiß jetzt echt nicht mehr weiter, bzw. wo und wie ich ansetzten muss:
Zitatpi@raspberrypi /var/log/nginx $ cat error.log
2015/02/05 14:03:53 [warn] 3044#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 14:03:53 [warn] 3045#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 14:04:07 [warn] 3058#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 14:04:08 [warn] 3059#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 14:55:01 [warn] 3298#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 14:55:01 [warn] 3299#0: conflicting server name "localhost" on 0.0.0.0:80, ignored
2015/02/05 15:01:43 [crit] 3301#0: *5 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 15:02:13 [crit] 3301#0: *5 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 15:03:57 [crit] 3301#0: *9 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:03:03 [crit] 3301#0: *11 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /smartvisu/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:03:09 [crit] 3301#0: *11 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /smartvisu/index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:06:09 [crit] 3301#0: *14 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /smartvisu/index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:06:10 [crit] 3301#0: *14 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /smartvisu/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:06:11 [crit] 3301#0: *17 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: localhost, request: "GET /smartvisu/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:11:33 [notice] 3742#0: signal process started
2015/02/05 19:11:42 [crit] 3743#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: 192.168.178.51, request: "GET /smartvisu/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 19:11:46 [crit] 3743#0: *21 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.21, server: 192.168.178.51, request: "GET /smartvisu/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.178.51"
2015/02/05 21:35:08 [error] 5332#0: *1 directory index of "/var/www/" is forbidden, client: 192.168.178.21, server: 192.168.178.51, request: "GET / HTTP/1.1", host: "192.168.178.51"
Ich bin für jeden hilfreichen Tipp sehr dankbar.
DANKE
Ich bin weiterhin der Meinung, dass dir google bezüglich nginx besser und schneller helfen kann, als dieses Forum, was mit nginx eigentlich nichts am Hut hat. Den Werbserver musst du konfigurieren. Und dazu gibt es unndlich viele hilfreiche google-Einträge.
Treiber (io_fhem.js)
Ich habe den Treiber folgendermaßen geändert / erweitert
Reconnect
Der Timer für den reconnect nach einem Verbindungsabbruch zu FHEM wird erst dann angeworfen, wenn die Verbindung tatsächlich abgebrochen ist.
Das Hinweisdreieck oben rechts erscheint erst, wenn der erste reconnect nach einer Minute auch fehlgeschlagen ist. Als Text wird "connection" angezeigt.
Addon-Treiber
Ich habe den use case (und vielleicht ja noch jemand), dass ich noch von einer weiteren Steuerung Daten in SV visualisieren will.
Dazu habe ich eine optionale Erweiterungsmöglichkeit für den Treiber geschaffen.
Der Treiber hat ganz oben einen Konfigurationsabschnitt.
// --- Driver configuration ----------------------------------------------------
logLevel: 1,
gadFilter: "^hcs.data.", // regex, to hide these GADs to FHEM
addonDriverFile: "io_hcs.js", // filename of an optional addon driver
// -----------------------------------------------------------------------------
In gadFilter kann eine regex definiert werden, die dafür sorgt, dass GADs, die matchen, nicht an FHEM ausgeliefert werden.
Das alleine kann auch dazu verwendet werden, um GADs, die man nur SV-Intern verwendet, von FHEM fernzuhalten, dass sie dort nicht im GAD-Editor auftauchen.
In addonDriverFile kann man den "Erweiterungstreiber" angeben. Dieser muss dann auch im smartvisu/driver Verzeichnis liegen, in diesem Beispiel also als io_hcs.js
Genereller Ablauf:
Wenn addonDriverFile gesetzt ist, dann lädt der eigentliche Treiber (io_fhem) den addon Treiber nach und startet ihn, indem er eine Instanz von ihm macht und seine run Methode aufruft. Die run Methode bekommt die Instanz vom io_fhem übergeben, um auf seine props zugreifen zu können (z.B. die konfigurierte IP) und die Liste der GADs, um die er sich kümmern soll. Das sind genau die GADs, die der gadFilter aussortiert hat und nicht an FHEM durchgelassen hat.
Der addon Treiber kann sich dann wie auch immer Daten beschaffen und die Werte für die GADs setzen. Beispiel siehe unten.
Beispiel:
Irgendwo auf einer page sitzen die beiden:
{{ basic.value('hcs.data.now', 'hcs.data.now') }}
{{ basic.value('hcs.data.counter', 'hcs.data.counter') }}
Konfiguration im Treiber
gadFilter: "^hcs.data.",
addonDriverFile: "io_hcs.js",
io_hcs.js:
function addonDriver () {
this.driver = null;
this.timer = null;
// This driver does not make much sense but demonstrates how
// an addon driver can be implemented
this.run = function(driver, gads) {
// you get a reference to the main driver
// and the list of gads you should handle
this.driver = driver;
var self = this;
if(this.timer) {
clearInterval(this.timer);
this.timer = null;
}
console.log("addonDriver started (GADs: " + gads + ")");
console.log("main driver works on: " + this.driver.address);
this.update();
this.timer = setInterval(function () {
self.update();
}, 5000);
}
this.stop = function() {
console.log("argh! - they kill me");
if(this.timer) {
clearInterval(this.timer);
this.timer = null;
}
}
this.counter = 0;
this.update = function() {
// you can call this.driver.updateWidget at any time to set the data for a widget
// simply pass the GAD name and a string with the value
this.driver.updateWidget("hcs.data.now", new Date().toTimeString());
this.driver.updateWidget("hcs.data.counter", (this.counter++).toString());
}
}
Der Treiber ist hier zu finden:
https://github.com/herrmannj/smartvisu-cleaninstall/blob/master/driver/io_fhem.js
https://github.com/herrmannj/smartvisu-cleaninstall/blob/master/driver/io_fhem.min.js
Als nächstes werde ich mich dann mal mit der stockenden und bockenden Laderei bei großen Anzahlen von GADs beschäftigen.
hey cool. Mal interessehalber, was ist denn die zweite quelle ?
vg
jörg
Zitat von: herrmannj am 06 Februar 2015, 01:03:02
Mal interessehalber, was ist denn die zweite quelle ?
Auch wenn es etwas OffTopic wird, evtl. ist es ja eine Anregung was man so machen könnte...
Das ist meine selbstgeschriebene Steuerug für die Heizung. Die ersetzt seit Jahren die antike Steuerung (mit mechanischer Zeitschaltuhr mit so Reitern drauf) und fährt Heizung und Wasser mit Heizkurve, Außentemperatur, Bedarfsprofilen usw.
Dabei fallen aktuelle Werte und Logs usw. an (Temperaturverläufe, Brennerlaufzeiten, monatliche Ölverbräuche usw.)
Und das Frontend für die verheirate ich nun in SV mit dem, was von FHEM kommt.
Die zweite Datenquelle deshalb, weil es keinen Sinn macht, all diese Daten und Logs nach FHEM zu schaufeln, nur um sie in SV zu visualisieren.
In FHEM hole ich mir nur einige wenige Informationen von der Heizungssteuerung, die ich dort für nachgelagerte Aufgaben brauche (z.B. macht es keinen Sinn, ein MAX-Thermostat bis zum Anschlag aufzufahren, wenn die Vorlaufpumpe im Keller nicht mehr pumpt)
@HCS: Das mit dem Addon-Driver klingt interessant. Kann der Addon-Driver theoretisch auch eine 2. FHEM/Fronthem Instanz handeln?
Södele....nginx etc. ERFOLGREICH installiert! Unter IP-Adresse/smartvisu wird mir nun auch SV angezeigt. ;D ;D ;D
Ich habe aber jetzt den Überblick verloren. Wie und Wo fange ich an meine Geräte zu hinterlegen.
In der SV Config habe ich die IP Adresse von FHEM hinterlegt, allerdings erhalte ich im SV die Warnung
ZitatConnection to the fhem server lost!
Zitat von: bjoernbo am 06 Februar 2015, 10:58:49
Södele....nginx etc. ERFOLGREICH installiert! Unter IP-Adresse/smartvisu wird mir nun auch SV angezeigt. ;D ;D ;D
Ich habe aber jetzt den Überblick verloren. Wie und Wo fange ich an meine Geräte zu hinterlegen.
In der SV Config habe ich die IP Adresse von FHEM hinterlegt, allerdings erhalte ich im SV die Warnung
Hi,
was hast du denn anders gemacht bzw. wo lag der Fehler? Das wäre vielleicht für andere hilfreich.
Ansonsten muss erstmal in fhem ein fronthemDevice mit der ip vom Gerät mit dem du zugreifst definiert werden und in sv Treiber domotiga sowie die ip von fhem eingetragen werden. Wenn es funktioniert hast du in sv keine Warnung mehr sowie im fronthemDevice ein connected stehen...
Gruß
Zitat von: marvin78 am 06 Februar 2015, 09:05:27
@HCS: Das mit dem Addon-Driver klingt interessant. Kann der Addon-Driver theoretisch auch eine 2. FHEM/Fronthem Instanz handeln?
Das sollte machbar sein (ohne es getestet zu haben)
- Mit dem GAD-Filter die Weiche festlegen, was wo her kommt
- Irgendwo basic.sonstwas mit GADs definieren, die für die Weiche matchen
- Sie in irgendwas wie im folgenden Beispiel (nicht lauffähig) abhandeln
Also so ungefähr, nur halt in den addon treiber passend eingebaut
Wobei man damit dann den Treiber irgendwie ein zweites mal schreibt, nur halt als addon treiber
var socket = new WebSocket('ws://1.2.3.4:2121/');
socket.onopen = function () {
socket.send(unescape(encodeURIComponent(JSON.stringify({'cmd': 'proto', 'ver': '0.1'}))));
var monitor = [];
monitor.push("gad-name-1");
monitor.push("gad-name-2");
socket.send(unescape(encodeURIComponent(JSON.stringify({'cmd': 'monitor', 'items': monitor}))));
console.log("open");
};
socket.onmessage = function (event) {
var data = JSON.parse(event.data);
console.log("receiving data: " + event.data);
////hier dann die empfangenen Daten in SV schieben
};
socket.onerror = function (error) {
console.log("ERROR");
};
socket.onclose = function () {
console.log("CLOSE");
};
Ich habe bei google gesucht und gefunden!
Ich bin nach folgender Anleitung vorgegangen:
http://www.sysadminslife.com/linux/debian-wheezy-nginx-installation-mit-php5-5-und-mysql-5-6-lemp/ (http://www.sysadminslife.com/linux/debian-wheezy-nginx-installation-mit-php5-5-und-mysql-5-6-lemp/)
Das eigentliche Problem war u.a. das ich kein PHP installiert hatte. Dies ist allerdings auch nicht aus dem WIKI hervorgegangen.
Sowas muss auch nicht Teil dieses Wikis sein. Zu nginx gibt es ja genug Anleitungen und dass man für eine php-Anwendung php benötigt ist logisch. Etwas handarbeit ist immer nötig.
@marvin78: Da gebe ich dir recht. Jedoch habe ich meine vorherigen arbeiten mit PHP über xampp realisiert und da ist bekanntlich alles dabei ;-)
ich habe nun alle IP-Adressen angepasst. Im SV erhalte ich nun keine Fehlermeldungen.
(//)
Jedoch sind ist in fronthem der Status unbekannt und ich weiß nicht woher die angezeigt IP Adresse stammt, bzw. wo ich diese noch anpassen muss. in der config.ini ist diese jedenfalls nicht enthalten. Auch ein shutdown restart brachte keine Abhilfe.
Zitat von: herrmannj am 28 Dezember 2014, 13:35:06
Hi Jo,
perfekt. fronthem, Status ? ? ? ist richtig: das connected wird beim fronthemDevice angezeigt, bei der fronthem "Mutter" wird noch kein state gesetzt (da schreib ich vielleicht später irgendwas wie '3 clients connected, 1 rejected' oder so rein. Weiß noch nicht genau, muss ja auch Sinn machen)
Reihenfolge wird eine Rolle spielen. Erst sv, dann fronthem, dann fronthemDevice war meine Reiehenfolge. fronthem und tronthemDevice vertauscht wird nicht gehen.
In sv brauchen die clients übrigens nicht händisch ergänzt werden. Ich hab in die .ini oben so was wie autoadd = true|false eingebaut (bin mir nicht sicher wie der Schlüssel genau heist, sieht man aber). Wenn der auf true steht werden neue clients automatisch in sv angelegt und bekommen eine Kopie der default Einstellungen. Dann kann man über die cfg page die individuellen Settings über die sv Oberfläche speichern. Sind ja eigentlich nur page, design, evtl calender.
vg
jörg
Die IP Adresse mit der .21 ist Gerät mit dem du smartvisu aufgerufen hast.
Vermutlich ein Rechner der die IP per DHCP bezieht.
@HSC: Aktuell hat der Treiber noch Probleme, sich ein Status in FHEM sehr schnell ändert. Das bekommt DmartVisu dann nicht mit sondern bleibt auf dem alten Status hängen. Vorkommen kann das bei divers IO-Devs und auch bei HM-Aktoren. Es wäre schön, wenn du das auch auf deine Liste für den Treiber setzen könntest. Danke!
edith (überschnitten) @bjoern:
yepp, so siehts aus.
das frontendDevice ist mit ...51 definiert ...21 hat aber angefragt. Die def vom fronthemDevice (das ist der Rechner der sv anzeigt, nicht die ip des webservers) muss auf ...21 geändert werden, fhem Neustart dann sv: ctrl-f5.
Denk an dom-cache abschalten und den Inhalt des /temp/ Verzeichnis in sv regelmäßig löschen während Du Deine sv-Räume eintichtest.
vg
jörg
Jawollo :-D :-D Vielen Dank @herrmannj => connected !
Zitat von: karl0123 am 06 Februar 2015, 14:21:06
@HSC: Aktuell hat der Treiber noch Probleme, sich ein Status in FHEM sehr schnell ändert. Das bekommt DmartVisu dann nicht mit sondern bleibt auf dem alten Status hängen. Vorkommen kann das bei divers IO-Devs und auch bei HM-Aktoren. Es wäre schön, wenn du das auch auf deine Liste für den Treiber setzen könntest. Danke!
Meinst Du mit dem aktuellem Treiber den Domotiga oder meinen oder beide?
Du meinst damit, dass ein Reading in FHEM erst x, und dann sehr kurz darauf y wird?
Es ist in beiden (allen drei) Treibern so. Wechselt ein reading sehr schnell von x über y auf z oder von off über set_on nach on, kommt der letzte Status in SmartVisu oft nicht an und es bleibt der Zwischenstatus stehen. Bei Homematic weniger ein Problem, da der Status ja später nochmal aktiv von dem Device gesendet wird aber für alles andere, wie die genannten IO-Devices schon. Auch ein HMLAN geht bspw. oft sehr schnell von DISCONNECT über init nach open.
Kann mir jemand sagen, warum SV auf dem iPad 1 nichts anzeigt? egal, in welchem Browser?
Gesendet von meinem iPad mit Tapatalk
Nimm ein vernünftiges Device ;)
Spaß beiseite: Was heißt denn "nichts"? Ich würde sagen, dass es keine Websockets kann aber wenn gar nichts angezeigt wird, kann es am alten Browser liegen (ich habe leider keine Ahnung, was es für das iPad 1 so gibt, es ist aber durchaus möglich, dass aktuelle Technologien nicht funktionieren - APPs werden ja nicht für alle Geräte in gleiche Version ausgeliefert), der von jquery-mobile nicht unterstützt wird oder aber an falscher Konfiguration.
Das gesamt UI kommt, das device in fhem steht auf connected und kein GAD wird aktualisiert... Nach ein paar Minuten kommt das rote Dreieck und sagt websocket error [object event]. Sagt mir aber nichts. Sollte nicht ein Chrome auf ios auch websockets können? Ist immerhin iOS 5.1.1! ;-)
Gesendet von meinem iPad mit Tapatalk
Ab Chrome Version 31 (PC) und 40 (Android). Ob und wann das für deine iOS Version dann auch eingeführt wurde, weiß ich nicht, kann man aber sicher recherchieren.
Websockets haben ja auch eine Entwicklung genommen. Manche Browser unterstützen es auch nur teilweise. Und auch jQuery unterstützt nicht mehr alle alten Browser.
laut http://websocketstest.com/ full support!
Gesendet von meinem iPad mit Tapatalk
Zitat von: bgewehr am 06 Februar 2015, 17:46:06
laut http://websocketstest.com/ full support!
Gesendet von meinem iPad mit Tapatalk
da gibt es einige unterschiedliche drafts. Android 4.2 .. mit stockbrowser verhält sich genauso. Geht auf connected (weil http upgrade) kann aber keine Daten austauschen. can I use behauptet (mit safari) ab 7.1
http://caniuse.com/#feat=websockets
Was wirft er unter WebSocket protocol version aus ?
vg
jörg
Zitat von: karl0123 am 06 Februar 2015, 17:02:31
Es ist in beiden (allen drei) Treibern so. Wechselt ein reading sehr schnell von x über y auf z oder von off über set_on nach on, kommt der letzte Status in SmartVisu oft nicht an und es bleibt der Zwischenstatus stehen. Bei Homematic weniger ein Problem, da der Status ja später nochmal aktiv von dem Device gesendet wird aber für alles andere, wie die genannten IO-Devices schon. Auch ein HMLAN geht bspw. oft sehr schnell von DISCONNECT über init nach open.
Magst das mal bitte so untersuchen:
fronthem (+fronthemDevice) verbose 4, dann sehe ich im log was fronthem raus-schicken (möchte).
Gleichzeitig im Browser in der (js) console, da siehst Du was der Treiber bekommt.
Damit können wir anfangen einzugrenzen ob
a:) fronthem das nicht rausbringt,
b:) der js driver das nicht schnell genug abholt /verteilt
c:) die widgets nicht nachkommen
Meine Vermutung ist c, aber mit dem Unterschied zwischen Glauben und Wissen verdienen sich Religionen ganze Vermögen ...
vg
jörg
Hallo zusammen,
ich versuche nun auch schon seit Tagen auf meiner Synology DS 111 Fronthem zum laufen zu bringen doch leider immer ohne Erfolg.
Hier ist der Auszug aus meiner Log
2015.02.06 20:00:17 1: reload: Error:Modul 01_fronthem deactivated:
Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at /usr/local/FHEM/share/fhem/FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at /usr/local/FHEM/share/fhem/FHEM/01_fronthem.pm line 30.
Habe Perl Cpan JSON Net::WebSocket::Server installiert und es läuft. Habe DSM 5.1 u2 drauf. ale Dateien auch so angepasst, dass mein CUL und Jeelink erkannt werden und funktionieren.
Wäre für ein paar Ratschläg sehr dankbar.
könnte sein das fhwebsocket nicht gefunden wird ?
vg
jörg
Zitat von: herrmannj am 06 Februar 2015, 17:59:15
da gibt es einige unterschiedliche drafts. Android 4.2 .. mit stockbrowser verhält sich genauso. Geht auf connected (weil http upgrade) kann aber keine Daten austauschen. can I use behauptet (mit safari) ab 7.1
http://caniuse.com/#feat=websockets
Was wirft er unter WebSocket protocol version aus ?
vg
jörg
Hallo Jörg,
ich habe das gleiche Problem. Meinst du mit Version das hier :{"cmd":"proto","ver":"0.1"}} ?
Wenn ja, kommt das beim Aufruf vom Ipad aus nicht. Siehe Screenshots (.17 ist der PC, .25 ist das Ipad)
Gruß Norbert
Zitat von: redlav am 06 Februar 2015, 21:17:22
Hallo Jörg,
ich habe das gleiche Problem. Meinst du mit Version das hier :{"cmd":"proto","ver":"0.1"}} ?
Wenn ja, kommt das beim Aufruf vom Ipad aus nicht. Siehe Screenshots (.17 ist der PC, .25 ist das Ipad)
Gruß Norbert
Hi Norbert,
vmtl liegt es am Ipad - ich will da keine Hoffnungen wecken die ich hinterher nicht erfüllen kann. Mit Version ist das hier gemeint http://websocketstest.com/
Die Ausgabe hinter "WebSocket protocol version"
vg
jörg
Hallo Jörg,
dank für die Info. Bei mir steht draft-76. Was sollte da den stehen, damit es funktioniert.
Auf dem PC kommt rfc-6455 dabei raus.
Gruß Norbert
Zitat von: herrmannj am 03 Januar 2015, 15:37:14
Hi @all,
ich versuche jetzt seid gestern Abend ein encoding Problem zu lösen, langsam gehen mir die Ideen aus:
Problem: Umlaute werden in smartVISU falsch dargestellt.
Nachstellen:
fhem: dummy erstellen, dann set den dummy 'Ö'
sv: basic.value
dann über "Direct" mit dem dummy verbinden.
Darstellung in sv als "ÃÂ"
Das ist die korrekte (byte) Repräsentation in UTF-8.
Der Weg fronthem -> sv geht über perl -> JSON (UTF8) -> ws (UTF8) -> JSON (UTF8) -> jquery mobile in sv.
Ich habe jetzt testweise überall mal convert (UTF8 ...) reingesetzt, bringt natürlich alles nix.
Den browser hab ich "hart" auf UTF8 gestellt (nix), nginx "gezwungen" UTF8 coding zu für die page zu verwenden (nix), meta im head in allen Spielarten ... (guess what: nix) ... jetzt gehen mitr irgendwie die Ideen aus.
Hat jemand weitere Ideen oder gar die Lösung ?
vg
jörg
Hallo,
gibt es dafür eine Lösung / Workaround ?
Ein Reading aus 55_GDS, welches ich über Converter Direct einlese, wird so dargestellt -> STURMBÃÂEN
Gruß Kai
Zitat von: kumue am 06 Februar 2015, 22:09:55
Hallo,
gibt es dafür eine Lösung / Workaround ?
Ein Reading aus 55_GDS, welches ich über Converter Direct einlese, wird so dargestellt -> STURMBÃÂEN
Gruß Kai
Fragt mal bei bgewehr nach ich habe seine page übernommen! Hier werden die Umlaute korrekt dargestellt!
VG Lutz
Zitat von: cruser1800 am 06 Februar 2015, 22:16:10
Fragt mal bei bgewehr nach ich habe seine page übernommen! Hier werden die Umlaute korrekt dargestellt!
VG Lutz
ja aber nicht alle (afaik). Ds ist noch offen, ich hatte mal den driver im Verdacht, da ist HCS ja gerade bei.
vg
jörg
Zitat von: herrmannj am 06 Februar 2015, 22:55:39
ja aber nicht alle (afaik). Ds ist noch offen, ich hatte mal den driver im Verdacht, da ist HCS ja gerade bei.
Ich habe es mal in die driver-todo-Liste aufgenommen und schaue, ob ich es mit einem dummy in fhem nachvollziehen kann.
ja das geht easy - einfach dummy mit "ÄÖÜäöü" und dann value , converter direct. Ich hab schon mal einen Abend damit verbracht, man sieht aber ganz schwer wo genau das passiert weil nicht klar ist ob die debug Wege (console, Dumper etc) dann jeweils UTF-8 sehen und ausgeben ... Ich dachte jetzt evtl an decode_JSON (wobei das eigentlich nach norm UTF-8 ist, bzw das uri-escape ... ).
Musst aber nicht machen, bin ja eigentlich ich gefordert. Wenn Du Lust hast trotzdem sehr gern .
vg
jörg
Kann es gerade nachvollziehen.
In SV steht nicht "Ölkännchen" sondern eine üble Abwandlung.
Ich schaue es mir mal an. Wenn ich belegen kann, dass der driver nix für kann, bist Du dann dran ;)
Zitat von: redlav am 06 Februar 2015, 21:57:49
Hallo Jörg,
dank für die Info. Bei mir steht draft-76. Was sollte da den stehen, damit es funktioniert.
Auf dem PC kommt rfc-6455 dabei raus.
Gruß Norbert
Da https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 stehen die drafts, per definition eben ein Entwurf, kein Standard....
Die werden unterstützt:
draft-ietf-hybi-17 (latest)
draft-ietf-hybi-10
draft-ietf-hybi-00 (with HAProxy support)
draft-hixie-75
Mit dem Ipad1 bleibt also nur verschiedene Browser durchzuprobieren, ab Ipad2 läuft es out-of-the-box ...
Für Android entschärfe ich das mit der app entschärfen. Für Apple auch eine zu schreiben wäre theoretisch möglich, ich befürchte mir fehlt da die Zeit ...
vg
jörg
Hallo Jörg,
vielen Dank für deinen unermüdlichen Einsatz! Jetzt weiß ich wenigstens, das es nicht an mir liegt 8)
Gruß Norbert
Zitat von: HCS am 06 Februar 2015, 23:26:23
Kann es gerade nachvollziehen.
In SV steht nicht "Ölkännchen" sondern eine üble Abwandlung.
Ich schaue es mir mal an. Wenn ich belegen kann, dass der driver nix für kann, bist Du dann dran ;)
ja gern, so oder so. Ich ändere das gern sobald ich verstehe wo ..
vg
jörg
Ich habe den Verdacht, dass Du in FHEM einmal zuviel UTF-8 encodest.
Wenn ich mein ÃÂlkännchen und die STURMBÃÂEN, die von FHEM kommen, zweimal UTF-8 decode, dann wird da wieder ein Ölkännchen und STURMBÖEN draus.
Das würde bedeuten, dass Du einmal weniger encoden solltest und ich einmal decoden muss.
Man sieht es auch schon optisch, das sind zu viele bytes für ein "Ö"
Mit testweise zweimal UTF-8 decoden im driver kommen die Umlaute dann auch korrekt im widget an.
base64 kodiert in einem eval - das merkt keiner und die Lösung wäre OK 8)
Ich mach mich mal auf die Suche. Normal müsste doch auch dem JSON UTF-8 rauspurzeln. Wenn Du zwei mal decodierst hat fronthem ja sogar zwei codierungen zu viel, oder ?
Danke
Jörg
Ja, da hast Du wohl recht. Mach mal zwei weniger und schau, ob es mit dem ungeänderten driver funktioniert.
Sicher ist aber: es liegt nicht an fehlenden encodings sondern an einer "übercodierung" :D
Nachtrag: da war ich wohl schon halb im Bett. Da der DOM UTF-8 braucht, muss der "bereits UTF-8-String" fälschlicherweise noch zwei mal zusätzlich encoded sein.
ich habs befürchtet ... noch schlimmer ist das ich eigentlich (wissentlich) nix encode ... :) Na, Danke für die Richtung, dann beginne ich mal die Suche ... :D
vg
Vielleicht habe ich es nicht mitbekommen, aber warum wird bein Numdisplay kein negativer Wert angezeigt?
yepp, ich dachte das hätte ich schon geändert ... kommt asap. Für das UTF8 Ding hab ich dank HCS eine heiße Spur - kommt gleich mit .
Ich weiß, das ist nicht wichtig, aber könntest du bitte im git aus Schnittstele Schnittstelle machen (README.md)? Da bleibt mein Auge jedes Mal hängen ;)
Hallo zusammen,
ich wollte mich jetzt auch mal ans testen machen.
An sich läuft soweit auch schon alles, aber leider habe ich das Problem das die GAD Änderungen nicht gespeichert werden.
Hat hier noch jemand das ganze auf einer Synology laufen?
Ich weiß leider nicht wieso keine config erstellt wird. Auch die Verzeichnisse fronthem und clients werden nicht erstellt.
FHEM läuft noch als root, Berechtigungen für www sind aber auch auf 777 gesetzt.
Das sind die einzigen Warnungen die ich sehe:
015.02.07 14:51:31 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at /usr/local/FHEM/share/fhem/FHEM/31_fronthemDevice.pm line 178.
2015.02.07 14:51:31 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at /usr/local/FHEM/share/fhem/FHEM/31_fronthemDevice.pm line 179.
2015.02.07 14:51:36 3: set Rollade_Links_Aussen ? : Unknown argument ?, choose one of clear:readings,trigger,register,rssi,msgEvents,all down fwUpdate getConfig getRegRaw getSerial getVersion inhibit:on,off off on pair pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset sign:on,off statusRequest stop toggle unpair up
2015.02.07 14:51:47 1: PERL WARNING: print() on closed filehandle $cfgHandle at /usr/local/FHEM/share/fhem/FHEM/31_fronthemDevice.pm line 569.
2015.02.07 14:51:47 1: PERL WARNING: print() on closed filehandle $cfgHandle at /usr/local/FHEM/share/fhem/FHEM/01_fronthem.pm line 426.
Für eine Idee wäre ich sehr dankbar.
VG,
Marcel
Hi,
Du hast ja schon selber schon geschaut, die Ecke in der Du suchst ist richtig.
(btw, die ersten 3 Einträge kannst Du ignorieren, die letzten beiden sind entscheidend)
Kannst Du mal die DIRs von Hand anlegen und schauen was dann passiert (nach Neustart) ? Darüber hinaus, starte mal fhem von der cmd line und schaue mal ob in der console was ausgeworfen wird.
vg
jörg
Hallo zusammen,
Ich wollte mir gerade neue Elemente in die Visualisierung einfügen. Leider werden die neu erstellten Gads im fronthem Editor nicht angezeigt. Ich habe die unterschiedlichen Treiber aus dem Thread versucht, ohne Veränderung. Schaltvorgänge und Anzeigen funktionieren alle, es werden nur keine neuen Gads erkannt. Kann mich jemand in die richtige Richtung schupsen damit ich den Fehler finden kann?
Grüße,
Matthias
@matzemoerk: Hast du eventuell versehentlich doppelte IDs in den Widgets vergeben? Diese müssten pro Page eindeutig sein.
Bei mir sind leider alle Fronthem Devices immer auf disconnected, obwohl ich zur selben Zeit darüber auf smartVISU zugreife. Dadurch kann ich auch nichts im Editor auswählen. Hab es mit mehreren Vorlagen aus dem Pages Ordner probiert. Ich verwende die angepasste smartVISU Installation von Github und die Domotiga Treiber.
Warum bekomme ich bei der Github Version bei aktiviertem Pagecache die Fehlermeldung "Error accoured in twig-template engine!". Bei der offiziellen smartVISU Version von der Webseite kann ich auch mit aktiviertem Pagecache arbeiten.
ZitatBei mir sind leider alle Fronthem Devices immer auf disconnected, obwohl ich zur selben Zeit darüber auf smartVISU zugreife.
Da vermischst Du was. Zugreifen auf sv ist nicht das gleiche wie mit fhem verbunden.
ZitatWarum bekomme ich bei der Github Version bei aktiviertem Pagecache die Fehlermeldung "Error accoured in twig-template engine!". Bei der offiziellen smartVISU Version von der Webseite kann ich auch mit aktiviertem Pagecache arbeiten.
Ohne weitere infos lässt sich das nicht klären, stimmt wohl die Installation nicht.
vg
jörg
Ich hatte ein ähnliches Problem. Nach Update von fhem war die Verbindung da
Zitat von: herrmannj am 07 Februar 2015, 18:39:31
Da vermischst Du was. Zugreifen auf sv ist nicht das gleiche wie mit fhem verbunden.
Wie kann ich dann die Verbindung zwischen Fhem und SV aufbauen und die Converter usw. einstellen? Muss ich da in SV was Fhem-spezifisches in den Block Content schreiben? Bin nach dieser Anleitung gegangen: http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117 (http://forum.fhem.de/index.php/topic,27291.msg231117.html#msg231117).
Nur als Webserver verwende ich statt lighttpd nginx, der wie im Wiki beschrieben konfiguriert ist, aber das sollte in diesem Fall wohl keinen Unterschied machen.
Ein Update von Fhem hat auch nicht geholfen. Im Log hab ich mit Verbose 5 keine auffälligen Meldung von Fronthem bemerkt.
Hi,
hast Du den sv driver korrekt eingestellt ? Wenn ja meldet das frontheDevice "connected". Vorher geht sowieso nichts ...
vg
jörg
Der Treiber steht auf Domotiga, Adress ist domotiga.local, Port 2121, Realtime auf on. Hab auch auch schon mit dem Fhem Treiber versucht, aber da auch das selbe Problem.
Zitat von: kennymc.c am 07 Februar 2015, 19:40:36
Der Treiber steht auf Domotiga, Adress ist domotiga.local, Port 2121, Realtime auf on. Hab auch auch schon mit dem Fhem Treiber versucht, aber da auch das selbe Problem.
Hier ist der Fehler domotiga.local!!!! Hier muss deine IP Adressee von FHEM stehen!
Ok, jetzt steht es auf connected. Dachte, dass wenn beides auf dem selben System läuft, .local die selbe Funktion hat. Ist ja auch die Standardeinstellung, wenn man den Treiber ausgewählt.
Trotzdem kann ich in den Fhem Device Details immer noch nichts auswählen.
Habe auch eine Frage zur richtigen Einstellung der IP Adresse in smartvisu. Mein fhem erreiche ich über https://192.168.1.249:883, das ganze läuft über nginx als reverseproxy. Was muss ich jetzt als IP Adresse einstellen? 192.168.1.249 wird bestimmt nicht reichen.
sv greift mit dem websocket auf port 2121 von fhem (nicht proxy) zu.
vg
jörg
Also sollte 192.168.1.249 genügen, nur bekomme ich kein Device auf connect.
Zitat von: devil77 am 07 Februar 2015, 20:26:13
Also sollte 192.168.1.249 genügen, nur bekomme ich kein Device auf connect.
Hast du in den fronthemdevices die ip Adresse des Gerätes, welches auf smartVISU zugreift angegeben?
Wenn (!) Dein fhem echt auf dem Server 192.168.1.249 läuft und erreichbar ist musst Du die driver Einstellungen in sv überprüfen und Dir dann status und log von fronthem und ..Device anschauen. Zu einem allgemeinem "geht nicht" lässt sich keine Diagnose erstellen ;)
vg
jörg
Websocket über Reverse Proxy? Geht das?
Zitat von: karl0123 am 06 Februar 2015, 17:02:31
Es ist in beiden (allen drei) Treibern so. Wechselt ein reading sehr schnell von x über y auf z oder von off über set_on nach on, kommt der letzte Status in SmartVisu oft nicht an und es bleibt der Zwischenstatus stehen. Bei Homematic weniger ein Problem, da der Status ja später nochmal aktiv von dem Device gesendet wird aber für alles andere, wie die genannten IO-Devices schon. Auch ein HMLAN geht bspw. oft sehr schnell von DISCONNECT über init nach open.
Ich kann das nicht nachvollziehen.
Ich habe einen at, der alle 10 Sekunden das hier aufruft:
fhem("setreading quick_dummy state 000");
select(undef, undef, undef, 0.5);
fhem("setreading quick_dummy state 111");
fhem("setreading quick_dummy state 222");
fhem("setreading quick_dummy state 333");
den dummy bei dem sich das state ändert
in fronthem ein GAD mit
devce = quick_dummy
reading = state
converter = Direct
einen basic.value
{{ basic.value("quick_dummy", "quick_dummy") }}Die Werte kommen alle im SV-driver rein
2015-02-08 00:44:40.861 io_fhem.min.js:99 [io.fhem]: onmessage() data= {"cmd":"item","items":["quick_dummy","000"]}
2015-02-08 00:44:40.868 io_fhem.min.js:99 [io.fhem]: item updated: quick_dummy val: 000
2015-02-08 00:44:41.400 io_fhem.min.js:99 [io.fhem]: onmessage() data= {"cmd":"item","items":["quick_dummy","111"]}
2015-02-08 00:44:41.408 io_fhem.min.js:99 [io.fhem]: item updated: quick_dummy val: 111
2015-02-08 00:44:41.415 io_fhem.min.js:99 [io.fhem]: onmessage() data= {"cmd":"item","items":["quick_dummy","222"]}
2015-02-08 00:44:41.420 io_fhem.min.js:99 [io.fhem]: item updated: quick_dummy val: 222
2015-02-08 00:44:41.421 io_fhem.min.js:99 [io.fhem]: onmessage() data= {"cmd":"item","items":["quick_dummy","333"]}
2015-02-08 00:44:41.429 io_fhem.min.js:99 [io.fhem]: item updated: quick_dummy val: 333Und in SV steht kurz 0 und dann rauschen die Werte durch, bis zuletzt immer "333" dasteht.
Getestet auf einem irre schnellen Laptop und auf einem grausig langsamen Android 4 Tablet in Chrome
Wenn Du mir ein Szenario bauen kannst, mit dem ich es ohne Deine IO-devices und ohne HM nachvollziehen kann, dann forsche ich weiter.
Hier mal meine Liste der Treiber-Topics.
Wenn noch jemand was kennt, das ich vergessen habe, dann einfach melden.
Die Reihenfolge ist auch grob die Prio. Zumindest momentan.
Ist aber egal, bei Softwareprojekten gibt es nie eine konstante Priorität ;D
Umlautproblem
Liegt wohl auf der fromthem Seite.
Abwarten, was bei herrmannj passiert.
Das "zwei mal UTF-8 decodieren" wieder ausbauen, wenn es herrmannj auf der fronthem Seite geregelt hat
Verschluckte Werte, wenn sich das reading mehrmals kurz nacheinander ändert
-> aktuell nicht nachvollziehbar, auf hold
Blockierendes Aktualisieren der GADs
Plots implementieren
@herrmannj: bevor Du an das Thema ran gehst, müssen wir die Strategie festlegen.
Machen wir aber erst, wenn Du bereit bist dafür.
Ich habe das in den Treiber mal grob eingebaut und mit meinem addon-Treiber getestet.
Einen plot.period bekomme ich gefüllt.
Da sind aber noch einige Punkte zu klären, die plots in SV sind, hmmm, sagen wir mal so, optimierbar
Trigger implementieren für basic.trigger widget
Log implementieren für status.log
Zitat von: HCS am 08 Februar 2015, 00:57:16
Getestet auf einem irre schnellen Laptop und auf einem grausig langsamen Android 4 Tablet in Chrome
Gerade noch auf einem weiteren Tablet und einem Adroid 5 Telefon getestet. Funktioniert.
Ich lasse den at (der macht so schön Rabatz auf den Systemen) mal durchlaufen und schaue, ob morgen früh immer noch 333 dransteht.
Zitat von: HCS am 08 Februar 2015, 01:10:24
Umlautproblem
Liegt wohl auf der fromthem Seite.
Ist im nächsten update enthalten. Teste gerade "Heizölrückstoßabdämpfung" :D. Dein Hinweis mit "zwei mal" hat mich auf die richtige Fährte geführt. Danke! Der Unterschied liegt in UTF-8 bytestreams und UTF-8 characterstreams ... frag nicht ...
Zitat
Verschluckte Werte, wenn sich das reading mehrmals kurz nacheinander ändert
-> aktuell nicht nachvollziehbar, auf hold
das kann schon in fhem passieren, eventmonitor und log bräuchten wir bitte.
Zitat
Plots implementieren
@herrmannj: bevor Du an das Thema ran gehst, müssen wir die Strategie festlegen.
Machen wir aber erst, wenn Du bereit bist dafür.
Da sind aber noch einige Punkte zu klären, die plots in SV sind, hmmm, sagen wir mal so, optimierbar
ja gern, ich mächte den aktuellen Featurestand fehlerfrei haben, dann nächster Step. Warum findest Du die doof - ich habe mit highcharts (darauf baut das) gespielt und war hellauf begeistert ?
Zitat
Trigger implementieren für basic.trigger widget
ich würde trigger komplett weg lassen. Für fhem brauchen die die mMn nicht (button kann direkt auf converter gehen um notify oder trigger auszulösen). Ich denke das ist eher für die anderen Systeme in sv drin. Der Punkt ist das man dafür den editor anpassen müsste, sprich er würde komplexer ohne Nutzen.
vg
jörg
Leider bekomme ich über die beim manuellen Starten auch keine anderen Fehlerhinweise.
Manuelles anlegen der Verzeichnisse bringt leider auch keinen Erfolg.
Er erstellt einfach keine Config Files.
Noch eine Idee wo ich noch schauen könnte, bzw. lässt sich die Config von Hand erstellen?
Dann könnte ich zumindest mal testen ob Sie eingelesen wird.
Zitat von: herrmannj am 08 Februar 2015, 02:08:07
Ist im nächsten update enthalten. Teste gerade "Heizölrückstoßabdämpfung"
OK. "Südliche Ägäis" sollten wir dann noch testen, ob das auch geht. ;D ;D
Zitat von: herrmannj am 08 Februar 2015, 02:08:07
Warum findest Du die doof - ich habe mit highcharts (darauf baut das) gespielt und war hellauf begeistert ?
highcharts sind super, die hatte ich nicht gemeint. Ich meinte das Drumherum incl. der Ansteuerung von driver aus.
Nichts, was wir nicht hinbekommen würden. Können wir dann diskutieren.
Um nicht nebulös zu bleiben: das sind Dinge wie: "der plot wird nur gezeichnet, wenn für alle Serien Daten geliefert wurden", eine Aktualisierung des Plot führt zu seltsamen Ergebnissen, usw.
Alles kein highchart-Problem sondern ein Problem vom "drumherum" in SV.
Zitat von: herrmannj am 08 Februar 2015, 02:08:07
ich würde trigger komplett weg lassen. Für fhem brauchen die die mMn nicht (button kann direkt auf converter gehen um notify oder trigger auszulösen). Ich denke das ist eher für die anderen Systeme in sv drin. Der Punkt ist das man dafür den editor anpassen müsste, sprich er würde komplexer ohne Nutzen.
Ja, das ist OK. Hatte einfach mal alles aufgeschrieben, was der driver können könnte.
Dann streiche ich den Punkt mal vorerst.
Zitat von: HCS am 08 Februar 2015, 01:31:38
Ich lasse den at (der macht so schön Rabatz auf den Systemen) mal durchlaufen und schaue, ob morgen früh immer noch 333 dransteht.
Steht noch dran und läuft unverändert.
@HCS: Ich hatte die Beobachtung, dass SmartVisu schnelle Wechsel nicht immer mitbekommt auch gemacht, kann das aber aktuell beim besten Willen nicht reproduzieren oder provozieren (dein aktuellster FHEM-Treiber). Ich habe mir den Treiber noch nicht angeschaut, aber eventuell hast du das Problem schon "versehentlich" gelöst!? ;)
Zitat von: marvin78 am 08 Februar 2015, 09:25:08
@HCS: Ich hatte die Beobachtung, dass SmartVisu schnelle Wechsel nicht immer mitbekommt auch gemacht, kann das aber aktuell beim besten Willen nicht reproduzieren oder provozieren (dein aktuellster FHEM-Treiber). Ich habe mir den Treiber noch nicht angeschaut, aber eventuell hast du das Problem schon "versehentlich" gelöst!? ;)
Ich will es nicht völlig ausschließen, aber ich glaube zu 99,9% dass ich nichts geändert habe, das das verbessern würde.
Könnte es sein, dass es durch die aktuelle FHEM- oder fronthem-Version nicht mehr auftritt?
Gerade die Gegenprobe gemacht. Mit dem Domotiga funktioniert mein Test auch. Und an dem habe ich nichts geändert.
Entweder existiert das Problem nicht mehr oder mein Test ist nicht geeignet, es zu erzeugen.
Nachtrag: Du kannst ja mal meinen oben beschriebenen Test bei Dir nachbauen und schauen, was bei Dir passiert.
Das könnte auch so was wie ein langsamer Server oder sonst eine Systembedingung sein, bei der das auftritt.
Ich habe FHEM und SV auf einem Cubietruck, lighttpd und teste mit Chrome, Firefox und verschiedenen Android 4 ... 5 devices mit Chrome
Moin,
ich habe die Installationsanleitung im Wiki nochmal etwas angepasst:
- Installation smartVISU aus Jörgs git-Repo
- Fehlende Pakete
- Konfiguration smartVISU
Es fehlt aber immer noch einiges.
Wenn was gravierendes fehlt bitte melden oder selber ändern. Ich fände es super wenn ihr eure Probleme etc. im Wiki selber einträgt.
Über diesen Thread kann man ja nichts mehr finden :-)
Vielen Dank.
Gruß Daniel
Super! @jÄÃIÁrg nimm doch den Wiki-Link in das erste Post auf, vielleicht hilft das!
Zwei mal UTF-8 wäre dann aber so: jörg ;D ;D
Vorschlag zum wiki: ich würde aus "Driver: Fhem oder Domotiga" das Domotiga wegnehmen.
Sonst suchen wir Probleme, die einer hat oder nicht, je nachdem, welchen Driver er nimmt.
Und wenn plots implementiert sind, geht eh nur noch der FHEM driver
- Wandern die Widgets (z.B. die von Bernd) auch irgendwie in das Repo von "smartvisu-cleaninstall"?
- Wie lässt sich denn "smartvisu-cleaninstall" zukünftig updaten ohne dass die eigenen Projekte kaputt gehen? Über "git pull"?
Zitat von: HCS am 08 Februar 2015, 10:35:48
Vorschlag zum wiki: ich würde aus "Driver: Fhem oder Domotiga" das Domotiga wegnehmen.
Done
Zitat von: bgewehr am 08 Februar 2015, 10:24:26
Super! @jÄÃIÁrg nimm doch den Wiki-Link in das erste Post auf, vielleicht hilft das!
das kô¶nnte ich machen :)
Zitat von: Blaky am 08 Februar 2015, 08:50:46
Leider bekomme ich über die beim manuellen Starten auch keine anderen Fehlerhinweise.
Manuelles anlegen der Verzeichnisse bringt leider auch keinen Erfolg.
Er erstellt einfach keine Config Files.
Noch eine Idee wo ich noch schauen könnte, bzw. lässt sich die Config von Hand erstellen?
Dann könnte ich zumindest mal testen ob Sie eingelesen wird.
Das macht keinen Sinn - aber zum Abgleich: funktioniert der Rest ? also das connect und siehst Du im Editor die Einträge aus sv ?
vg
jörg
Zitat von: dancatt am 08 Februar 2015, 10:43:25
- Wandern die Widgets (z.B. die von Bernd) auch irgendwie in das Repo von "smartvisu-cleaninstall"?
- Wie lässt sich denn "smartvisu-cleaninstall" zukünftig updaten ohne dass die eigenen Projekte kaputt gehen? Über "git pull"?
Ich hab keine Idee, eigentlich wollte ich auch vermeiden da ein "eigenes" sv zu pflegen - aber mit den Anpassungen und zukünftig auch noch fhem widgets läuft das schon darauf hinaus ...
vg
jörg
Zitat von: herrmannj am 08 Februar 2015, 11:38:06
Das macht keinen Sinn - aber zum Abgleich: funktioniert der Rest ? also das connect und siehst Du im Editor die Einträge aus sv ?
vg
jörg
So ganz verstehe ich das auch gerade noch nicht.
Jup alles andere geht. Ich sehe das connect, ich sehe die Devices im Gad, ich kann diese zuweisen und Sie funktionieren auch. Getestet mit einer Lampe.
Sobald ich dann FHEM neu starte, ist der Editor leer und alle Zuweisungen sind weg.
Der Pfad war doch FHEM/www/frontend/fronthem/clients/... oder?
Gruß,
Marcel
Man kann doch einmal GIT pull machen, dann seinen eigenen Ordner anlegen. Danach kann man immer wieder gut pull machen, der eigene Ordner bleibt ja bestehen, oder etwa nicht?
@Blaky: Mach mal ein
set fronthem save
vor deinem Neutstart und schaue, ob die gads dann vorhanden bleiben. (fronthem natürlich durch deinen fronthem-Namen ersetzen)
Hat jemand schon das Multimedia.image benutzt? Ich bekomme einen schäbigen Umbruch unterhalb des Bildes in mein Layout und frage mich, wo das herkommen kann. Ich kann nichts finden... Ich habe es nur in ein Div gelegt... Padding und so weiter - alles 0!
Zitat von: Blaky am 08 Februar 2015, 12:33:00
So ganz verstehe ich das auch gerade noch nicht.
Jup alles andere geht. Ich sehe das connect, ich sehe die Devices im Gad, ich kann diese zuweisen und Sie funktionieren auch. Getestet mit einer Lampe.
Sobald ich dann FHEM neu starte, ist der Editor leer und alle Zuweisungen sind weg.
Der Pfad war doch FHEM/www/frontend/fronthem/clients/... oder?
Gruß,
Marcel
da werden die GAD <-> convert gespeichert:
$cfgFile = "./www/fronthem/server/$hash->{NAME}/$cfgFile";
Ich habe keine Idee warum das bei Dir nicht funktioniert (außer Rechte, Platz auf der HD ..). Ich möchte aber da sowieso noch umstellen damit auch die cfgDB Benutzer die cfg in der DB hinterlegen können. Ich kann das nach vorne ziehen, wenn dann immer noch was klemmt könnten wir noch debuggen .. Wär das OK ?
vg
jörg
edith: das betrifft auch die Art wie ohne db geschrieben wird ...
Zitat von: herrmannj am 08 Februar 2015, 13:20:06
da werden die GAD <-> convert gespeichert:
$cfgFile = "./www/fronthem/server/$hash->{NAME}/$cfgFile";
Ich habe keine Idee warum das bei Dir nicht funktioniert (außer Rechte, Platz auf der HD ..). Ich möchte aber da sowieso noch umstellen damit auch die cfgDB Benutzer die cfg in der DB hinterlegen können. Ich kann das nach vorne ziehen, wenn dann immer noch was klemmt könnten wir noch debuggen .. Wär das OK ?
vg
jörg
edith: das betrifft auch die Art wie ohne db geschrieben wird ...
Du musst das nicht unbedingt nach vorne ziehen.
Ich komme eh immer nur am Wochenende dazu. Mach wie es passt.
Ist für mich vollkommen ok.
das set "fronthem" save hat leider auch nichts gebracht.
Ist das eigentlich korrekt das das fronthem device "state = ???" anzeigt?
Gruß,
Marcel
Zitat von: Blaky am 08 Februar 2015, 14:08:06
Ist das eigentlich korrekt das das fronthem device "state = ???" anzeigt?
Gruß,
Marcel
Meinst du jetzt fronthem oder fronthemDevice?
fronthem state ??? und
fronthemDevice state (dis)connected sind normal...
Passen denn die Rechte der fronthem dateien unter fhem?
Zitat von: fidel am 08 Februar 2015, 14:25:18
Meinst du jetzt fronthem oder fronthemDevice?
fronthem state ??? und
fronthemDevice state (dis)connected sind normal...
Passen denn die Rechte der fronthem dateien unter fhem?
Ich meinte fronthem aber dann passt das ja.
Die Rechte sind in Ordnung, sind wie die der anderen auch.
Ich kann mir aber eh nicht vorstellen das das ein Rechteproblem ist, da FHEM bei mir zur Zeit noch als root läuft.
@herrmannj: Du würdest mir eine riesigen Gefallen tun, wenn Du die GADs alphabetisch sortiert in die fhserver.fronthem.cfg schreiben würdest.
mir auch!!!
Gesendet von meinem iPad mit Tapatalk
Zitat von: bgewehr am 08 Februar 2015, 17:10:44
mir auch!!!
Gesendet von meinem iPad mit Tapatalk
das lässt sich machen. Mittelfristig würde ich aber lieber dem editor das spendieren was ihr händisch machen wollt. Was würdet ihr Euch denn da wünschen ?
vg
jörg
ZitatWas würdet ihr Euch denn da wünschen ?
Von mir ein vote für: Die Rechte der gerade bearbeiteten GAD-Einstellung direkt für alle Geräte übernehmen können.
Grüße
Tobi
Der Editor sollte alle fronthemDevices zusammen fassen und man setzt dann innerhalb einer Tabelle Haken bei den Devices für Read und write. Das ist eigentlich die einzige Variante, bei der man auch den Überblick behält. Für alle Devices übernehmen bietet ja nur dann eine Zeitersparnis, wenn man wirklich auch alles übernehmen möchte. Das wird wohl häufig aber doch im Schnitt nichtmal bei 50% der gads der Fall sein, denke ich. Also plädiere ich, falls möglich für einen Editor für alle Devices.
ich denke Bernd und HCS haben nicht die Berechtigungen zum Ziel. Zum Thema Berechtigung: ich werde ein attribut einführen (access), wenn das gesetzt ist hat das device vollen access und man braucht sich nicht mehr darum zu kümmern.
vg
jörg
Zitat von: herrmannj am 08 Februar 2015, 19:36:04
ich denke Bernd und HCS haben nicht die Berechtigungen zum Ziel. Zum Thema Berechtigung: ich werde ein attribut einführen (access), wenn das gesetzt ist hat das device vollen access und man braucht sich nicht mehr darum zu kümmern.
vg
jörg
Könnte man bis das Thema Berechtigung richtig eingeführt ist, vielleicht die Einträge in dem Log abschalten? Zur Zeit "müllt" dadurch leider das Log mächtig voll!
VG Lutz
ähhhmmm, ja. Ist dran... :)
Na wenn Wunschzeit für den Editor ist: gads löschen wäre prima. Einfacheres Setzen der Berechtigungen in einer Tabelle jedoch weiterhin auch. ;)
Zitat von: marvin78 am 08 Februar 2015, 19:53:02
Na wenn Wunschzeit für den Editor ist: gads löschen wäre prima. Einfacheres Setzen der Berechtigungen in einer Tabelle jedoch weiterhin auch. ;)
GADs löschen geht doch...
Ja das stimmt, aber auch das ist zu umständlich. In einer pefekten Welt geht das alles über eine Tabelle. Aber ich will nicht meckern.
Zitat von: herrmannj am 08 Februar 2015, 18:32:02
das lässt sich machen. Mittelfristig würde ich aber lieber dem editor das spendieren was ihr händisch machen wollt. Was würdet ihr Euch denn da wünschen ?
Hat bei mir einen ganz anderen Hintergrund.
Ich habe für die performance Tests 999 GADs hinzugefügt, natürlich nicht manuell sondern mit einem Tool generiert und dann in die fhserver.fronthem.cfg reinkopiert.
Nun wollte ich davon die letzten 500 rausnehmen. Geht nicht, da sie kunterbunt gemischt sind. Wenn sie alphabetisch sortiert wären, wäre das kein Problem.
Mal was lustiges am Rande:
Ich habe auf dem alten Android 4.1 Sony Xperia U von meiner Tochter mal tasker und ip-Webcam installiert, das ganze mit Dauerstromversorgung an das Garagentor gehängt und erhalte nun folgendes:
Tasker Regeln:
- Display zeigt nach oben -> fhem per http set Garagentor offen
- Display aufrecht -> fhem per http set Garagentor zu
Das klappte schon mal auf Anhieb.
Dann natürlich in die Garage reinschauen, ob das Auto meiner Frau drinsteht, oder nicht (heißt für mich: parke ich auf dem Stellplatz davor oder woanders...)
Also
- ip-webcam aktiviert und läuft im Hintergrund auf 320x240 (weil Details unnötig)
- Widget multimedia.image ein bisschen gepimpt (width=100%, sonst Bild zu breit)
- Widget popup.image gebaut und ein widget httpcmd, um die Funktionen von ip-webcam zu bedienen (LED an/aus, nightview an/aus)
- mit einem basic.shifter schalte ich das Tor auf und zu. Das habe ich mit einer 220V Hörman-Fernbedienung und einem Homematic switch in einem alten Steckergehäuse realisiert. Der Wert vom Tor wird von dem dummy genommen, den der tasker auf 0 oder 100 schaltet.
et voila: Garage fertig.
Cole Idee :D Danke für den Hinweis zum multimedia.image! Das suche ich gerade. Ist der code in deinem github zu finden?
schöne Grüße
Jo
Bernd,
ich hab Dich im Git eingetragen bei smartvisu-cleaninstall und (neu eingerichtet) bei smartvisu-widgets.
Ich schlage vor die umfangreichen widgets wie uzsu und co in smartvisu-widgets, dort jeweils in einem eigenen Ordner zu speichern.
In smartvisu-cleaninstall würde ich dann eine fhem-widget.js pflegen. Dort würde ich die "basic - type" widgets rein nehmen, also zb ein iconize nach cruser1800 (Lutz).
Wer mag den trage ich gern bei github ein.
vg
jörg
@jörg: Danke, ich mach mal was rein...
Allerdings spielt sich UZSU im Git vom mWorion ab und nur der fhem Teil ist von mir neu, wie hast Du Dir das gedacht? Mein Code kommt ja nur in die 99_fronthemUtils.pm rein.
Die anderen Widgets sind einfach...
hab nicht bis ins Detail gedacht :) Mir ging es auch um die Struktur, hoffe das macht so Sinn, auch in Hinblick auf weitere widgets
vg
jörg
hi all,
ich nutze die config.ini in smartvisu mit festen Einträgen, also nicht über auto_add = true.
Nun wollte ich für jeden Client "Type" (Iphone, Ipad etc) die jeweils von mir erstellte page zuweisen.
Leider greift die Einstellung nicht und es wird mir immer die gleiche also default Seite angezeigt.
Ist die "Funktion" bei einem der letzten Updates rausgeflogen?
Danke und Grüße
Grav
nicht wissentlich - teste ich.
Danke
jörg
Ich habe mich nun mal mit der blockierenden Laderei beschäftigt.
Vorbemerkungen:
Man darf auf keinen Fall die (reichliche) Zeit, die SV benötigt, bis die Seite erscheint, speziell wenn der page cache aus ist, mit der Zeit verwechseln, die die GADs für das initiale Anzeigen brauchen.
Das "blocking GAD init" Problem beginnt ab dem Moment, ab dem die Seite sichtbar wird und noch keine Werte anzeigt werden.
Es ist nicht die Gesamt-Anzahl der GADs entscheidend, sondern wie viele auf der page sitzen, die gerade geladen wird.
Der Treiber frägt nur die GADs der aktuellen page bei fronthem an. Man kann also 500 GADs haben, wenn eine page nur 10 davon drauf hat, hat die kein Problem.
Das Problem ist eigentlich nur beim initialen Laden einer page gegeben, da in diesem Fall, wenn die page z.B. 100 GADs hat, alle 100 GADs sofort benötigt werden, um initial alles anzuzeigen.
Danach ist es sehr unwahrscheinlich, dass sich alle 100 readings in FHEM gleichzeitig ändern, es werden also immer mal nur einige wenige übertragen.
Stand:
Ich habe jquery queue mal testweise eingebaut. Das verbessert das blockieren leider nicht.
Es entsteht aber auch keine queue mit einem Füllgrad, da die GADs einzeln kommen.
Wenn also 100 GADs angefragt werden, dann werden die 100 GADs einzeln mit cmd="item" rübergeschickt.
Somit 100 mal Übertagung, einqueuen usw.
@herrmannj: Es wäre sehr hilfreich, wenn fronthem nach dem "monitor" für die initiale Befüllung alle angefragten GADs in einem cmd="item" gesammelt rüberschicken würde.
Dann könnte ich diese Liste responsiv abarbeiten. Ich habe das mal von meinem addon driver aus simuliert, das hat geklappt.
Es wird ja eh schon ein array rübergeschickt, nur ist da halt immer nur ein GAD mit seinem Wert drin.
Wenn das so klappt, dann haben wir das Thema bereits durch, da es, wie oben beschrieben, meiner Ansicht nach nur ein "Initial-load-Problem" ist.
Für plots regeln wir das ganze unabhängig, die müssen eh mit einem cmd='series' rüberkommen und können somit separat abgearbeitet werden.
Zitat von: HCS am 09 Februar 2015, 16:45:43
Vorbemerkungen:
Man darf auf keinen Fall die (reichliche) Zeit, die SV benötigt, bis die Seite erscheint, speziell wenn der page cache aus ist, mit der Zeit verwechseln, die die GADs für das initiale Anzeigen brauchen.
Das "blocking GAD init" Problem beginnt ab dem Moment, ab dem die Seite sichtbar wird und noch keine Werte anzeigt werden.
Das ist schon klar und weiter oben auch von mir beschrieben worden. Der genannte Pagecache ist aber ohnehin ein eher schlechtes Instrument, um Performance zu erhalten. Das müllt nur das DOM zu und hilft bei vielen DOM-Elementen eher nicht und ist Kontraproduktiv (das kann man leicht testen, in dem man mal viele Seiten in den Cache holt). Für genau unseren Anwendungsfall hier ist das eher nicht zu empfehlen, meine ich. Denn dann ist es entscheidend, wie viele gads man insgesamt hat. Zumindest der Domotiga Treiber hat alle Elemente im DOM bei init aktualisiert (so sah es zumindest in der Console aus) und nicht nur die auf der Seite. Das können dann schnell mal 500 werden.
Und was die vielen Gads auf einer Seite angeht: Die hat man sehr schnell, wenn man auch gads im Menü hat. Bei 10 Gads auf einer Seite ist das Blockieren auch schon deutlich spür- und sichtbar (in der Konsole). Bei 40-50 dann fast unerträglich. Und dass diese Zeit erst beginnt, wenn die komplette Seite geladen ist, ist klar. Jedoch ist die Ladezeit der Seite bei mir zu vernachlässigen und das auch ohne Pagecache. Die ist fast sofort da. Das Blockieren macht auch den Unterschied zu z.B. FHEM-Web aus: Der erste Status der Devices wird mit der Seite geladen und man kann sofort interagieren.
benötigt es für multimedia.image noch weiere vorbereitungen oder reicht {% import "multimedia.html" as multimedia %} ?
meine def:
{% import "multimedia.html" as multimedia %}
{{ multimedia.image("WC2", "http://schierke-am-brocken.de/webcam/schierke01.jpg") }} bringt immer
ZitatFatal error: Call to undefined method __TwigTemplate_bba03a48920a7b9f8724ba2ce9e116e3ccdb15c9f8e14f97f1be7bef41f0ec9a::getimage() in /var/www/smartVISU/vendor/Twig/Environment.php(331) : eval()'d code on line 39
EDIT: wenn man sollte seine pages nicht wie evtl. vorhandene widgets benennen...
Das einzige, was mich irritiert, ist das Fragezeichen...
habs bei mir ausprobiert, bild wird ohne probleme geladen... ? vorher entfernt...
bzgl der Verzögerung beim initialen Laden:
Ich schlage vor das wir das einfach aufschieben, tritt ja nur auf wenn man echt viele GADs hat und auch dann nur einmal initial. Mittelfristig sollten wir dann mal genaue Messungen machen, wenn die queue dafür nicht funktioniert (wobei sie sollte, die Transitions laufen ja auch non-blocking) brauchen wir halt eine andere Technik, wird sich finden. Die GADs in fronthem initial zu sammeln ist aufgrund der event getriebenen Struktur nicht trivial, mMn wäre der AUfwand höher als der Nutzen.
vg
jörg
Hm. Ich halte das Performance Problem (und ja, es ist ein Problem) für einen großen Spaßverderber und deshalb für extrem wichtig (manche würden sagen, dass es auch einen extrem schlechten WAF verursacht). Und das es erst bei "echt vielen" Gads ein Problem ist, stimmt ja auch nicht. Es ist aktuell alles noch beta, aber um überhaupt produktiv eingesetzt werden zu können, muss genau das Problem auf jeden Fall gelöst werden, da es sonst produktiv nicht nutzbar ist. Das sind meine 10 Cent zu dem Thema. Ich habe einen extrem schnelle Server und warte 10 Sekunden auf einen Seitenwechsel. Und so viele Gads braucht es dafür nicht einmal. Ich habe ja oben geschrieben, dass es schon bei recht wenigen gads spürbar wird. Und wenn das DOM voll ist, wird es noch schlimmer (Cache ist also kontraproduktiv).
Ich nutze noch kein Tablet, sondern im Moment nur das iPhone. Jeder Aufruf ist dabei ein initial load und schön langsam. Da ich beim Zurückblättern auf die Home Seite keine Gads mehr aktualisiert bekomme, ist sogar innerhalb einer Session mehrfach ein Full reload erforderlich. Mich nervts schon ein wenig, dass ich so lange warten muss, bis ich die Garage aufmachen kann...
Kann ich bestätigen. Man kommt recht schnell an die Grenze, ab der es zu lange dauert.
schöne Grüße
Jo
verstehe ich, aber passt das alles ? Ich habe einen odroid und die Wartezeiten sind sehr überschaubar, wohlgemerkt auf einem nicht über-performanten Tablett. Ich setze es mittlerweile Produktiv ein.
Im übrigen ist das keine Frage von "beta" - das würde nur fronthem betreffen (läuft doch recht stabil - oder ;) ). SmartVISU (da würde das hingehören) ist ja ein unabhängiges Paket, das was Du ansprichst betrifft (würde betreffen) alle Installationen quer über alle Systeme (KNX, smarthome.py ++).
Schau doch mal bitte ob diese Geschwindigkeitsbremsen die ja bei Dir sehr drastisch zu sein scheinen vielleicht irgendwo anders verortet werden können. Da scheint was nicht in Ordnung zu sein, zumindest wenn ich Deine Beschreibung in Relation zu der performance setze die ich sehe.
vg
jörg
2 neue post während ich geschrieben habe :)
Aber bleibt ja, schaut Euch doch in der console mal an wo die Zeiten verbraten werden - generell ist das ein sv Thema. Wenn da was ist müssen wir zusammen schauen ob wir da für die sv Jungs (und dür uns ;D ) was tun können.
vg
jörg
Zitat von: karl0123 am 09 Februar 2015, 19:22:16
Zumindest der Domotiga Treiber hat alle Elemente im DOM bei init aktualisiert (so sah es zumindest in der Console aus) und nicht nur die auf der Seite. Das können dann schnell mal 500 werden.
Das macht weder der Domotiga noch der FHEM-Treiber so.
Beispiel Domotiga page 1 geladen:
[io.domotiga] sending data: {"cmd":"monitor","items":["quick_dummy","XXumlGad","hcs.data.counter","MAX_LivingRoom_actual","MAX_LivingRoom_wanted","MAX_LivingRoom_comfort","MAX_LivingRoom_night","MAX_LivingRoom_frost","MAX_LivingRoom_state","Temperature_Outside.temperature","Temperature_Outside.humidity","Temperature_LivingRoom.temperature"]}
11 GADs bei fronthem angefragt und genau die 11 liefert fronthem.
Beispiel Domotiga page 2 geladen:
[io.domotiga] sending data: {"cmd":"monitor","items":["Temperature_Outside.temperature","Temperature_Outside.humidity","Temperature_Outside.battery","Temperature_OutsideNorth.temperature","Temperature_LivingRoom.temperature","Temperature_LivingRoom.humidity","Temperature_LivingRoom.battery","Temperature_GroundFloor.temperature","Temperature_GroundFloor.humidity","Temperature_GroundFloor.battery","Temperature_Penthouse.temperature","Temperature_Cellar_Hobby.temperature","Temperature_Cellar_Hobby.humidity","Temperature_Cellar_Hobby.battery","Temperature_Cellar_Storage.temperature","Temperature_Cellar_Storage.humidity","Temperature_Cellar_Storage.battery","Temperature_Mobile1.temperature","Temperature_Mobile1.humidity","Temperature_Mobile1.battery","Temperature_Mobile2.temperature","Temperature_Mobile2.humidity","Temperature_Mobile2.battery","HCSValues.BurnerTemperatureWanted","HCSValues.BurnerTemperature","HCSValues.BurnerOffCommand","HCSValues.BurnerIsOn","HCSValues.WaterTemperatureWanted","HCSValues.WaterTemperature","HCSValues.WaterOffCommand","HCSValues.WaterIsOn","HCSValues.HeatTemperatureWanted","HCSValues.HeatTemperature","HCSValues.HeatOffCommand","HCSValues.HeatIsOn","HCSValues.PenthouseTemperatureWanted","HCSValues.PenthouseTemperature","HCSValues.PenthouseOffCommand","HCSValues.PenthouseIsOn","HCSValues.HeatBackwardTemperature1Temperature","HCSValues.HeatBackwardTemperature2Temperature","LevelBarnEast.liters","LevelBarnEast.temperature","LevelBarnEast.voltage","hcs.data.oilconsumption.level","hcs.data.oilconsumption.3","hcs.data.oilconsumption.2","hcs.data.oilconsumption.1","System.cpu_freq","System.cpu_temp","System.ac_voltage","System.ac_current","System.battery_voltage","System.battery_capacity","System.time"]}
51 GADs bei fronthem angefragt und genau die 51 liefert fronthem.
Beispiel fhem-driver page 1 geladen:
2015-02-09 20:49:24.846 io_fhem.min.js:101 [io.fhem]: FHEM GADs:11, Own GADs:1, FHEM Series:0, Own Series:0
2015-02-09 20:49:24.875 io_fhem.min.js:101 [io.fhem]: item updated: quick_dummy val: 333
2015-02-09 20:49:24.880 io_fhem.min.js:101 [io.fhem]: item updated: XXumlGad val: Ölkännchen
2015-02-09 20:49:24.893 io_fhem.min.js:101 [io.fhem]: item updated: MAX_LivingRoom_actual val: 20.0
2015-02-09 20:49:24.902 io_fhem.min.js:101 [io.fhem]: item updated: MAX_LivingRoom_wanted val: 20.0
2015-02-09 20:49:24.907 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:49:24.912 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9
2015-02-09 20:49:24.921 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_LivingRoom.temperature val: 19.2
2015-02-09 20:49:26.984 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:49:27.007 io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9
Beispiel fhem-driver page 2 geladen:
2015-02-09 20:55:22.128io_fhem.min.js:101 [io.fhem]: FHEM GADs:51, Own GADs:4, FHEM Series:0, Own Series:0
2015-02-09 20:55:22.295io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.temperature val: 1.6
2015-02-09 20:55:22.309io_fhem.min.js:101 [io.fhem]: item updated: Temperature_Outside.humidity val: 85.9
usw. usw. 51 GADs Zitat von: karl0123 am 09 Februar 2015, 19:22:16
Und was die vielen Gads auf einer Seite angeht: Die hat man sehr schnell, wenn man auch gads im Menü hat. Bei 10 Gads auf einer Seite ist das Blockieren auch schon deutlich spür- und sichtbar (in der Konsole). Bei 40-50 dann fast unerträglich.
Dann muss bei Dir ein anderes Problem vorliegen.
Die Seite mit den 11 GADs lädt bei mir auf dem Tablet und dem Telefon (auf dem Laptop sowiso) verzugsfrei
Die Seite mit den 51 GADs lädt fast verzugsfrei und kaum merklichem blockierend.
Eine Test-Seite mit 300 GADS:
Hat auf dem Laptop knapp 2 Sekunden benötigt, auf dem Tablet und dem Handy zw. 5 und 6 Sekunden, vom Menü-Klick bis zum vollständigen Ergebnis.
2015-02-09 21:00:41.302io_fhem.min.js:101 [io.fhem]: FHEM GADs:299, Own GADs:1, FHEM Series:0, Own Series:0
2015-02-09 21:00:41.378io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy001 val: 2015-02-09T21:04:49
2015-02-09 21:00:41.403io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy002 val: 2015-02-09T21:04:49
.
.
.
2015-02-09 21:00:43.060io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy298 val: 2015-02-09T21:04:49
2015-02-09 21:00:43.067io_fhem.min.js:101 [io.fhem]: item updated: XtraDummy299 val: 2015-02-09T21:04:49
Zitat von: karl0123 am 09 Februar 2015, 19:22:16
Jedoch ist die Ladezeit der Seite bei mir zu vernachlässigen und das auch ohne Pagecache. Die ist fast sofort da.
Könnte es sein, dass Dein FHEM, warum auch immer, extrem langsam liefert?
Oder Dein Browser extrem lansam auf dem DOM ist.
Schwer zu sagen, aber was Du beschreibst, klingt für mich um Kategorien langsamer als meine Ergebnisse.
Bisher finde ich es echt noch ok. Könnte aber schneller laufen :)
schöne Grüße
Jo
Ich nutze noch kein Tablet, sondern im Moment nur das iPhone. Jeder Aufruf ist dabei ein initial load und schön langsam. Da ich beim Zurückblättern auf die Home Seite keine Gads mehr aktualisiert bekomme, ist sogar innerhalb einer Session mehrfach ein Full reload erforderlich. Mich nervts schon ein wenig, dass ich so lange warten muss, bis ich die Garage aufmachen kann...
Das Problem ist da. Das lässt sich nicht weg diskutieren. Ich weiß sehr genau was ich tue und kenne meinen Server und mein System sehr gut. Da gibt es kein anderes Problem, als das langsame init und das Blockieren der gads. Und selbst wenn ich das für das Handy (Nexus 5 mit sehr schnellem W-Lan) auf das nötigste reduziere (Seiten ohne unsichtbares Menü), ist die Wartezeit schon deutlich spürbar. "Hangelt" man sich parallel durch das "normal" FHEMWEB, macht das deutlich mehr Spaß und da geht mir aktuell tatsächlich die Performance vor Aussehen.
Es macht für mich auch gerade wenig Sinn, das ganze am PC zu analysieren (habe ich hier ja auch alles schon einmal gepostet), wenn es doch die Probleme an Tablets und Handys (mit Quad-CPUs und schnellem Wlan) gibt. Am PC merkt man es auch es ist aber ok. Da würde ich SmartVisu aber gar nicht einsetzen wollen.
P.S.: 10 Sekunden sind vielleicht etwas übertrieben aber selbst 4-5 sind für so ein Frontend zu viel. FHEMWEB lädt in deutlich unter 1 Sekunde ;)
Zitat von: karl0123 am 09 Februar 2015, 21:20:07
Das Problem ist da. Das lässt sich nicht weg diskutieren.
Ich diskutiere es auch nicht weg, ich arbeite daran.
Zitat von: karl0123 am 09 Februar 2015, 21:20:07
Und selbst wenn ich das für das Handy (Nexus 5 mit sehr schnellem W-Lan) auf das nötigste reduziere (Seiten ohne unsichtbares Menü), ist die Wartezeit schon deutlich spürbar.
Das Telefon, von dem ich oben schrieb, ist mein Nexus 5.
Die Ladezeiten generell sind ein weiteres Thema. Aktuell versuche ich das non blocking hinzubekommen, dass es zumindest bedienbar ist, wärend es lädt.
ZitatDas Problem ist da. Das lässt sich nicht weg diskutieren.
Relativ, bei mir ist ist es ok. Das hilft Dir jetzt nichts, ist aber so.
ZitatEs macht für mich auch gerade wenig Sinn, das ganze am PC zu analysieren
Das sehe ich anders. Dir Frage ist doch: kann man das ändern ? Um das zu klären braucht man objektive Daten. Die skalieren doch vom PC zum Tablett.
Entweder Du nimmst das als gottgegeben und arrangierst Dich, oder wir schauen zusammen was man ändern kann (wohlgemerkt in sv). Dafür braucht es zu aller erst eine genaue Analyse was, wann, wo, wielange dauert.
vg
jörg
Zitat von: karl0123 am 09 Februar 2015, 21:20:07
Das Problem ist da. FHEMWEB lädt in deutlich unter 1 Sekunde
Also ich stürze mich eben deshalb auf SmartVISU, weil fhemweb mich schon oft wegen blocking im Stich gelassen hat, es bei weitem nicht so gut aussieht und die Entwicklung in Richtung eines zeitgemäßen Frontends für Ästhetiker nicht mehr in Sichtweite war. Daher ist doch jetzt der ganze Schwung hier entstanden.
Sicher ist es so, dass man - wie in jeder Umgebung - mit den Ressourcen so umgehen muss, dass das Ergebnis passt. Ich habe auch schon HANA kriechen sehen...;-))
Zitat von: bgewehr am 09 Februar 2015, 21:32:23
Ich habe auch schon HANA kriechen
Och, da könnte ich was gegen liefern ;D
Zitat von: herrmannj am 09 Februar 2015, 20:40:05
Die GADs in fronthem initial zu sammeln ist aufgrund der event getriebenen Struktur nicht trivial, mMn wäre der AUfwand höher als der Nutzen.
Da ich nur den Nutzen kenne aber den Aufwand nicht, kann ich es schwer beurteilen.
Wenn das aber nicht möglich ist, dann wird es schwieriger.
Mal schauen, ob ich noch eine Idee dazu finde.
Zitat von: bgewehr am 09 Februar 2015, 21:32:23
Also ich stürze mich eben deshalb auf SmartVISU, weil fhemweb mich schon oft wegen blocking im Stich gelassen hat, es bei weitem nicht so gut aussieht und die Entwicklung in Richtung eines zeitgemäßen Frontends für Ästhetiker nicht mehr in Sichtweite war. Daher ist doch jetzt der ganze Schwung hier entstanden.
Naja. Performance geht immer vor Aussehen. Und in FHEMWEB blockt nichts so, wie das Nachladen der gads in SmartVisu. Ich will mich da nicht beschweren (ich beeindruckt von der Geschwindigkeit, wie sich das hier entwickelt), aber dass es aktuell noch ein klarer Showstopper ist, stimmt schon.
@hcs: ja smooth. Lass mal bitte strukturieren, ich seh schon, der Plan mit nach hinten schieben geht so nicht auf :)
Wir brauchen aber echt erst mal valide Daten.
Ich verstehe ad-hoc zB nicht warum eine initiale Sammellieferung von GADs schneller sein soll als der aktuelle event getriebene. Da sehe ich ein Zeichen das wir (ich) was nicht richtig einschätzen.
So wie ich das sehe wird die Zeit (20ms .. 40ms pro GAD) im DOM verbraten wenn jquery mit Hilfe der Selectoren (attr-val) das dazugehörige widget sucht. Da sollte es doch eigentlich keinen Unterschied geben.
Da es Deiner Beobachtung nach nicht so ist (gesammelt schneller) müssen wir mal alternative Theorien aufstellen.
Jquery lässt Interaktionen je erst zu wenn der das ready event durch ist. Wäre es vielleicht möglich das der initiale socket call das verzögert ? Dann könnte man den socket mit einem delay öffnen.
(Doof ist das ich kein setup habe um das nachzustellen - wie machst Du das eigentlich ?).
vg
jörg
Dass wir kein Missverständnis haben. Das gesammelte Senden meinte ich nur initial, wenn Du auf monitor antwortest.
Da bin ich von ausgegangen, dass Du die readings gem. der in monitor gelieferten Liste einsammelst, kannst ja nicht warten, bis die mal per event irgendwann kommen.
Darum dachte ich, dass das kein großes Problem sein sollte. Aber ich kenne Deine Architektur nicht, drum lag ich wohl falsch.
Es ist auch nicht schneller, nur eben ohne Blockieren machbar. Die Zeit, die die Updates der widgets auf dem DOM brauchen ist ja eher unabänderlich (solange man nicht in SV weiter unten eingreift).
Ich muss mich mal da runter debuggen, um zu sehen, was da genau vor sich geht.
@all: das Ganze ist ein mühseliges Geschäft, das braucht wohl noch etwas Zeit.
Ich kenne ja die guten Server von karl0123 nicht, aber dass wir auf dem gleichen Endgerät so drastisch unterschiedleiche Ergebnisse haben, muss einen Grund haben, der es wert wäre, gefunden zu werden.
Zitat von: herrmannj am 09 Februar 2015, 21:46:26
(Doof ist das ich kein setup habe um das nachzustellen - wie machst Du das eigentlich ?).
Ich versuche mal Dir meinen addon driver so zu bauen, dass Du es damit versuchen kannst.
Kann aber etwas dauern, muss erst mal die Zeit für finden.
Generell so:
eine page mit 299 basic.value
{{ basic.value("XtraDummy001", "XtraDummy001", "X") }}
.
.
.
{{ basic.value("XtraDummy299", "XtraDummy299", "X") }}
Ich aktualisiere vom addon driver aus in einer schnöden Schleife 299 GADs mit "widget.update(item, val);"
Dabei ist das Telefon unbedienbar, bis die GADs durch sind.
Diese Variante hier schafft die Aktualisierung ohne dass die Seite blockiert.
Während bei den 300 basic.value aus "---" die Werte werden, kann ich die Seite bedienen, scrollen usw.
var d = new Date();
var val = "I-" + d.getSeconds();
var i = 0, limit = 300, busy = false;
var updater = setInterval(function() {
if(!busy) {
busy = true;
var item = "XtraDummy" + ("000" + i).slice(-3);
widget.update(item, val);
if(++i == limit) {
clearInterval(updater);
}
busy = false;
}
}, 2);
}
Die paar hundert GADs mit ihren Werten sind schnell über die Leitung, schneller als jedes einzeln mit protokoll-overhead.
Und ab dann wären wir responsiv, während die 300 Werte innerhalb von 2-3 Sekunden nach und nach erscheinen.
verstehe, kann (muss) ich mir auch klöppeln.
Die untere Variante macht das ja eigentlich so wie ich das von der queue erwarten würde. Den overhead und auch die gesamte Datenmenge kann man bei 300 GAD (a 50byte ?) doch ignorieren. Das wären 15kb, normale jpegs haben das 10fache. ( plus x ... ). 3000ms für 300 GAD finde ich auch ok - das sind 10ms pro.
Hilft nichts, wir müssen das messen und untersuchen, alles andere ist wie blind mit der Schrotflinte in den Wald schießen und hoffen das der Hirsch umfällt.
vg
jörg
Der mit dem Hirsch ist gut ;D
Das ist die queue-Variante, die nichts geholfen hat. Aber möglicherweise habe ich das nicht so gemacht, dass es funktioniert?
Mit der jquery queue habe ich null Erfahrung.
Da es ja keinen Sinn macht, jedes GAD im DOM zu suchen und ihm eine queue für eine Aktion anzuhängen habe ich ein DOM Element erzeugt, an das ich die queue hänge.
Mal so grob rausgezogen aus meinem Test:
irgendwo im run:
var self = this;
this.q = $({});
und dann die Aktualisierung:
var d = new Date();
var val = "Q-" + d.getSeconds();
var ctr = 0;
for (var i = 1; i < 300; i++) {
this.q.queue("qt", function (next) {
var item = "XtraDummy" + ("000" + ctr++).slice(-3);
widget.update(item, val);
if(self.q.queue("qt").length > 0) {
next();
}
});
}
this.q.dequeue("qt");
Wie auch immer, morgen ist auch noch ein Tag ...
Ich hab ein Probleme mit einem einfachen Switch. Der ist ganz normal mit reading:state, converter:OnOff und cmd set: state definiert. Allerdings wird dieser im SV immer wieder auf On gesetzt, sobald man ihn ausschaltet. In Fhem bleibt er auf off. Im Log sieht man, dass Fronthem direkt nachdem Ausschalten wieder eine State-Änderung an SV schickt, die er irgendwoher bekommen hat.
ipc Fronthem:127.0.0.1:33186 (ws): receive {"log":{"level":4,"cmd":"log","text":"ws send to client{\"cmd\":\"item\",\"items\":[\"IT_Deckenfluter_sw\",\"1\"]}"}}
ipc Fronthem:127.0.0.1:33186 (ws): ws send to client{"cmd":"item","items":["IT_Deckenfluter_sw","1"]}
Mit toggle als cmd set kann man ihn zumindest über SV normal schalten aber der state wird trotzdem wieder zurück gesetzt. Woran kann das liegen?
Hab auch schon versucht beim Schalter den gesendeten Wert direkt auf On/Off zu ändern und dann in Fhem auf Direct zu stellen, aber dann ist der Effekt genau das Gegenteil wie vorher und der Schalter wird immer wieder auf off zurückgesetzt.
Leider hab ich auch noch sehr oft das Problem, dass die GAD-Listen nicht in den Device-Details zu sehen sind. Erst nach einem Fhem-Neustart tauchen sie wieder auf.
Das was zurückkommt ist normal und gewollt.
Der Effekt ist: sv setzt den (fhem) Schalter - der setzt ein event ab und das Event triggert den sv Schalter.
Hast Du ein mapping am Schalter gesetzt oder etwas in der Art ? Welche Version von fronthem ?
vg
jörg
@kenny poste mal den Switch code {{ ... }}
@herrmannj: auch wenn es nun einen GAD-Filter auf Treiberseite gibt, wäre es praktisch, wenn man das auch der fronthem-Seite hätte. Also einfach ein Attribut, in dem man eine regex definieren kann, die die mit "monitor" geschickten GADs filtert.
Wäre das kurzfristig machbar?
Ich könnte das gut für die Treiber-Experimente brauchen, da einige Test-Treiber-Varianten nicht filtern und ich so die unerwünschten GADs von fronthem fernhalten könnte.
Ich baue gerade einen Test-Treiber, der den Zeitverlauf der einzelnen Schritte beim Laden einer page anzeigt (auch auf Telefonen und Tablets)
Damit können wir dann mal schauen, wo auf verschieden Systemen der Hirsch im Wald seine Zeit vertödelt und gezielt das Feuer eröffnen. ;D
ja ich wollte da auch nachher noch bei, muss mich aber vorher um andere Sachen kümmern.
Mein Idee wäre das ich zum testen was einbaue wo 300 (1000?) GAD künstlich in fronthem erzeugt werden. Die wollte ich mit dem timestamp ihrer Geburts füttern.
In sv könntte man den timestamp wann sie abgeholt werden ergänzen und beides in basic value darstellen. Wenn wir Dein System nehmen (mit den vom script erzeugten GAD) könnte man die rauskopieren und mit eine calc auswerten.
Ansonsten sollten wir noch die lifecycle events des DOM und von query in die console geben - dann hätten wir doch schon mal eine Anfang ?
vg
jörg
OK, mit meinem "Mess-Treiber" und dem was Du beschreibst haben wir dann zwei Tests, die verschiedene interessante Daten liefern sollten.
Was mir aus Deiner Antwort nun nicht klar wurde: bekomme ich den regex Filter auf fronthem-Seite oder nicht?
Ich dachte Du brauchst das zum testen und das wäre damit erledigt ?
Was genau meinst Du mit fernhalten ? Der Aufbau der cfg und das beantworten sind unterschiedliche Dinge und passieren an unterschiedlichen Stellen
vg
jörg
Zitat von: bgewehr am 10 Februar 2015, 06:51:41
@kenny poste mal den Switch code {{ ... }}
{{ basic.switch('IT_Deckenfluter', 'IT_Deckenfluter_sw', icon1~'light_light_dim_100.png', icon0~'light_light_dim_00.png') }}Zitat von: herrmannj am 10 Februar 2015, 01:57:21
Hast Du ein mapping am Schalter gesetzt oder etwas in der Art ? Welche Version von fronthem ?
Ich hab per EventMap on auf Ein und off auf Aus gemappt. Hab es jetzt Testweise rausgenommen un nun funktioniert es wie es soll.
Zitat von: herrmannj am 10 Februar 2015, 15:34:45
Ich dachte Du brauchst das zum testen und das wäre damit erledigt ?
Was genau meinst Du mit fernhalten ? Der Aufbau der cfg und das beantworten sind unterschiedliche Dinge und passieren an unterschiedlichen Stellen
Kann ich immer noch gebrauchen, genau wie die sortierten GADs in der fhserver.fronthem.cfg
Ich habe reichlich GADs in SV, die ich in FHEM auf keinen Fall haben will. Das sind die Test-GADs und alle GADs, die mein addon driver erledigt.
Die filtert üblicherweise mein driver aus.
Wenn ich aber zum Testen mal den Domotiga oder einen meiner Test-driver verwende, dann sind die GADs drüben in FHEM und da wird man sie nur sehr mühsam wieder los.
Mit fernhalten meine ich folgendes: der driver schickt zu Begin mit "monitor" die Liste der GADs, die fronthem liefern soll. Die kommen bei Dir irgendwo rein, vermutlich hier wohl: fronthemDevice_fromDriver
if ($msg->{message}->{cmd} eq 'monitor')
Wenn man nun ein attribut definieren könnte, das eine regex enthält, die die GADs, die du in $msg->{message}->{items} hast, direkt mal filtert, bevor irgend etwas weiter damit gemacht wird, könnte man festlegen, welche GADs in fronthem völlig ignoriert werden sollen.
Betrachte es als ein Art spam-filter für fronthem :)
Speed-Test:
Ich habe den test-driver mal erste Messungen machen lassen. Siehe angehängte screenshots. Einmal auf dem Laptop und einmal auf dem Telefon (Nexus 5)
Die Zahlen (Nexus) sind so zu lesen:
driver init: SV hat den driver initialisiert
driver run: SV hat den driver gestartet, der früheste Zeitpunkt etwas zu tun.
monitor sent: es wurde das "monitor" command an fronthem gesendet und in diesem Fall 300 GADs angefordert.
first GAD received: das erste der 300 GADs wude von fronthem geliefert aber noch nicht in SV verarbeitet
first GAD handled: das GAD wurde verarbeitet, bedeutet, der Wert wird in SV angezeigt
50 GADs handled: es wurden 50 GADs von fronthem gesendet und in SV verarbeitet und angezeigt
Erkenntnisse (bezogen auf das Nexus 5):
die ersten 330ms gehen drauf, bis die GAD-Liste mit monitor bei fronthem abgeliefert ist
19 ms um das erste GAD zu verarbeiten. Das ist die Zeit, die der driver braucht, um es, nachdem er es von fronthem erhalten hat, in SV den Wert anziegen zu lassen
800ms für die 50 GADs von fronthem aus zu übertragen und in SV zu verarbeiten, dass sie angezeigt werden.
Das sind rund 16ms pro GAD.
Ab dem Moment, ab dem der driver überhaupt ins Spiel kommt, sind das 1,3 Sekunden, um 50 GADs anzuzeigen.
Das Laptop ist natürlich um Welten schneller.
Ich werde den test-driver noch etwas überarbeiten und dann in den nächsten Tagen zur Verfügung stellen, dann können auch ander Anwender mal Zeiten ermitteln, dass wir sehen, wo die langsamen Systeme die Zeit lassen.
@karl0123: hast Du in deiner menu.html in den links
<a class="ui-btn ui-corner-all" id="menu-overview" data-ajax="false" href="index.php?page=page_overview">
data-ajax="true" oder data-ajax="false" ?
Ich habe gerade einige Messungen zum Thema timing gemacht.
Ergebnis auf einem schon etwas betagteren Notebook:
Das erzeugen der GAD in fronthem benötigt etwa 4ms, die Übertragung benötigt recht konstant 25ms das aktualisieren des widgets von smartVisu knapp 100ms.
Die Folge ist das bei sehr hoher GAD Anzahl der nächste Wert vorliegt wenn ein Widget aktualisiert wurde und sofort in den event handler gesprungen wird ohne das die Jquery UI Zeit hat auf user Input zu reagieren.
Das liegt im Design von smartVisu (in Teilen Jquery). Mit einer queue lässt sich das tatsächlich nicht abfedern. Ich teste in Kürze einige Alternativen (fifo mit Timeout), denke das wird funktionieren.
Zum cache ist mir noch aufgefallen: karl spricht vom DOM Cache, das mag den einen oder anderen vielleicht verleiten den Button Cache in der sv config Seite abzuschalten. Der steuert jedoch den twig cache und sollte im produktiven Betrieb tunlichst angeschaltet bleiben :) (bringt deutlich speed). Der DOM Cache, auf der anderen Hand, ist ein spezielles jquery feature das im source von smartVisu gesteuert wird, ob das dort per default enabled kann ich nicht sagen, habs nicht untersucht. Wenn ja macht es sicher Sinn das abzuschalten, da müsste Karl noch mal sagen wo er das abgeschaltet hat.
vg
jörg
ich habe ein komisches problem wenn ich den Pagecache aktiviere... ich hatte ihn vor einiger zeit mal kurz an, dann wieder aus.
aktiviere ich den Pagecache nun erneut wird in uraltes design angezeigt. egal was ich mache (windos temp leeren, firefox cache leeren, refreshen ...) es änder sich nicht auf das aktuelle. wo kannich noch ansetzen?
EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" :D
winscp um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...
Mir ist noch folgendes aufgefallen: wenn ich auf iOS SV als Web-App benutze, dann wird beim Aufruf der App immer die Index Seite neu geladen. Das dauert so etwa 3-5s, ebenso wie alle weiteren Seiten, wenn sie das erste Mal geladen werden. Danach kann ich fast ohne Verzögerung zwischen den Seiten wechseln, kein Kringel, keine Ladezeit. Warum kann man eigentlich zu einer Web-App nicht hinwechseln, ohne dass sie neu geladen wird?
Zitat von: chris1284 am 12 Februar 2015, 06:38:15
ich habe ein komisches problem wenn ich den Pagecache aktiviere... ich hatte ihn vor einiger zeit mal kurz an, dann wieder aus.
aktiviere ich den Pagecache nun erneut wird in uraltes design angezeigt. egal was ich mache (windos temp leeren, firefox cache leeren, refreshen ...) es änder sich nicht auf das aktuelle. wo kannich noch ansetzen?
EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" :D
winscp um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...
Der Cache muss nur gelehrt werden wenn man die Seiten-Programmierung verändert.
vg
jörg
Zitat von: bgewehr am 12 Februar 2015, 06:59:20
Mir ist noch folgendes aufgefallen: wenn ich auf iOS SV als Web-App benutze, dann wird beim Aufruf der App immer die Index Seite neu geladen. Das dauert so etwa 3-5s, ebenso wie alle weiteren Seiten, wenn sie das erste Mal geladen werden. Danach kann ich fast ohne Verzögerung zwischen den Seiten wechseln, kein Kringel, keine Ladezeit. Warum kann man eigentlich zu einer Web-App nicht hinwechseln, ohne dass sie neu geladen wird?
So funktionieren Webapps, die Seite wird wie im browser geladen. Für alles andere brächte man eine app in der Seiten lokal vorgehalten werden - plus: - jquery mobile ist langsam und muss die Seite initialisieren.
vg
jörg
Wvc für IOS ist nicht in Sicht, oder?
Zitat von: herrmannj am 12 Februar 2015, 02:39:57
Ich teste in Kürze einige Alternativen (fifo mit Timeout), denke das wird funktionieren.
An einem fifo im triber zu responsive Aktualisierung der widgets bin ich auch gerade dran.
Da sollten wir achtgeben, dass wir keine Arbeit doppelt machen.
Kannst Du mal kurz beschreiben, was du wo machst?
Zitat von: chris1284 am 12 Februar 2015, 06:38:15
EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" :D
winscp um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...
Die Idee hatte ich kürzlich auch schon, aber in der Form, dass es sinnvoll wäre, wenn man in SV den page cache abschaltet, dass dann auch automatisch das temp Verzeichnis geleert wird.
Das wäre aber aus meiner Sicht eher ein natives SV Feature. Du kannst es ja mal im SV-Forum vorschlagen, ob die das machen würden.
Wenn nicht, können wir dann immer noch unsere eigene Lösung dafür bauen.
Je mehr wir an SV ändern, umso schwieriger und aufwändiger wird es, wenn man das nächste SV Update aufspielen will.
Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.
Zitat von: bgewehr am 12 Februar 2015, 07:53:46
Wvc für IOS ist nicht in Sicht, oder?
Ja, hab schon überlegt zumal ich selber zufriedener apple mobile Nutzer bin. Nur: die machen es einem echt schwer ohne Mac zu entwickeln, dann muss man da noch ca 100,- Jahresbeitrag abdrücken und ob das Ding dann in den store darf ist, wegen deren teilweise fast willkürlichen Bedingungen, auch nicht sicher.
Von daher versuche ich erst mal die Zeit für Android aufzubringen, bzgl apple: maybe later ...
vg
jörg
Zitat von: marvin78 am 12 Februar 2015, 09:15:12
Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.
Also in fronhtem (und darum gehts ja hier ;)) seh ich das nicht. Bau Dir doch ein php script was den cache löscht und ruf das vom fhem server auf.
Wofür soll das denn eigentlich gut sein ? Wenn ich an / in sv entwickle schalte ich den twig cache in den settings ab und lösche den cache einmal. Da sitz ich doch eh am nb und bin auf dem sv server eingeloggt ... ?
vg
jörg
Zitat von: HCS am 12 Februar 2015, 08:37:26
An einem fifo im triber zu responsive Aktualisierung der widgets bin ich auch gerade dran.
Da sollten wir achtgeben, dass wir keine Arbeit doppelt machen.
Kannst Du mal kurz beschreiben, was du wo machst?
bisher nur Plan und Untersuchung. Zu erst war mir wichtig zu schauen ob fronthem die performance bringt. Das tut es - im Prinzip wäre es sogar gut wenn fronthem langsamer liefern würde aber das ist natürlich nicht Sinn der Sache.
Das sv Thema sehe ich schon eher sekundär weil es hier ja um fronthem. Das von Karl beschriebene Setup mit 300GADs pro page sehe ich auch für mich nicht - genauso wenig sehe ich das auch in den Demohäusern die ja auch aus produktiv Umgebungen stammen. Ich habe gestern nochmal durchgeschaut. Dort sehe ich so an 30Gads (plus / minus) pro Seite, das kommt bei mir auch hin und funktioniert prächtig.
Trotzdem: ich habe noch untersucht was man machen kann. Am liebsten wäre mir ein event von jquery was signalisiert "alle widget gezeichnet" um danach das nächste GAD aus dem ws zu holen. Ich habe aber nichts gefunden was da geht. Von daher würde ich vorschlagen die GAD bei "onmessage" aus dem ws zu holen un in ein array (als fifo) zu schreiben. Die eigentlich aktualisieren würde ich dann so machen das jeweils ein widget aktualisiert wird und danach ein settimeout mit 5-10ms aufgerufen wird. In diesen 5-10ms kann die ui aktiv werden (sv ist responsive) und danach kommt das nächste item aus dem ws dran.
Wie sieht Dein Plan aus ?
vg
jörg
Zitat von: herrmannj am 12 Februar 2015, 10:12:18
Von daher würde ich vorschlagen die GAD bei "onmessage" aus dem ws zu holen un in ein array (als fifo) zu schreiben. Die eigentlich aktualisieren würde ich dann so machen das jeweils ein widget aktualisiert wird und danach ein settimeout mit 5-10ms aufgerufen wird. In diesen 5-10ms kann die ui aktiv werden (sv ist responsive) und danach kommt das nächste item aus dem ws dran.
Wie sieht Dein Plan aus ?
Der sieht ungefähr so aus, wie das, was Du beschrieben hast. Ich hatte das mal als wackeliges Experimet so probiert.
Hatte es aber erst mal nicht weiter verfolgt, da ich die Hoffnung hatte, dass Du initial nach monitor die GADs am Stück liefern kannst.
Dann hätte ich es nicht queuen müssen, da es ja schon als array vorliegt.
Der aktuelle Plan ist also momentan:
Alles, was in onmessage reinkommt in den fifo schieben und den so rausspulen, dass die Oberfläche responsiv bleibt.
Dann dauert es minimal länger, bis der letzte Wert auf dem Bildschirm steht, dafür bleibt das Ganze bedienbar.
Zitat von: marvin78 am 12 Februar 2015, 09:15:12
Die SmartVisu Jungs haben das löschen wohl in ihrer smarthome.py mit drin (Neustart löscht Cache). Die Hoffnung, dass sowas also nativ eingebaut wird, ist eher gering. Ich kann mich jedoch dunkel erinnern, dass im KNX-SmartVisu-Forum jemand eine Lösung gepostet hat.
Dann machen wir doch einfach ein Sys-Admin widget, das man sich auf eine seiner pages drauf setzt und da kann man das und weiter Dinge reinpacken.
Ich habe mir z.B. auch im menü einen refresh button, der einen page-reload macht, reingepackt, da es in einer WebApp ja keinen gibt und ein reload doch mal irgendwann erforderlich ist.
So:
<div class="ui-btn ui-corner-all" id="reload" onclick="location.reload(true);">
<img class="icon" src="{{icon0}}control_clear.svg"/>
</div>
Zitat von: herrmannj am 12 Februar 2015, 09:59:31
Also in fronhtem (und darum gehts ja hier ;)) seh ich das nicht. Bau Dir doch ein php script was den cache löscht und ruf das vom fhem server auf.
Wofür soll das denn eigentlich gut sein ? Wenn ich an / in sv entwickle schalte ich den twig cache in den settings ab und lösche den cache einmal. Da sitz ich doch eh am nb und bin auf dem sv server eingeloggt ... ?
vg
jörg
Ich brauche das nicht ;) Ich habe nur beschrieben, was ich in diversen Quellen gelesen habe ...
Zitat von: HCS am 12 Februar 2015, 12:42:13
Hatte es aber erst mal nicht weiter verfolgt, da ich die Hoffnung hatte, dass Du initial nach monitor die GADs am Stück liefern kannst.
Dann hätte ich es nicht queuen müssen, da es ja schon als array vorliegt.
Du, das würde nix bringen. Was passiert denn wenn kurz (0 - x Sekunden) nach dem "monitor" ein fhem device ein event produziert - sv aber noch mit abarbeiten der initialen GAD beschäftigt ist ? Fifo ... ;)
Dann zieh ich mich da raus - ok ?
vg
jörg
Zitat von: herrmannj am 12 Februar 2015, 13:14:06
Dann zieh ich mich da raus - ok ?
Ja, ist OK. Komme aber wohl erst am WE dazu.
Wenn ich nicht weiter komme rufe ich um Hilfe.
Muss aber wohl parallel noch einen weiteren Punkt erforschen. Bei der Experimentiererei ist mir in letzter Zeit sehr häufig FHEM gestorben. Ich will mal dahinter kommen, wie ich das gezielt reproduzieren kann. Da melde ich mich dann dazu, wenn ich was konkretes weiß.
Also, iPad1 unterstützt nur draft-76 websockets. Jörg, kann fronthem da etwas flexibler werden?
Gesendet von meinem iPad mit Tapatalk
Leider nein - für diesen Teil wird net::websocket::protocol verwendet. Da wird unterstützt
draft-ietf-hybi-17 (latest)
draft-ietf-hybi-10
draft-ietf-hybi-00 (with HAProxy support)
draft-hixie-75
die einzelnen Versionen unterscheiden sich auch nicht nur mal eben marginal, da sind teils große Unterschiede. Nicht despektierlich gemeint: dort den support für -76 nachzurüsten ist umfangreich und steht in keinem Verhältnis zu eine gebrauchten ipad-2.
Evtl kannst Du einen anderen browser einsetzen ?
vg
jörg
Ich bin auch der Meinung, dass hier mit der modernen Oberfläche nicht um jeden Preis jedes alt Schätzchen unterstützt werden sollte. Man sollte nicht den Fehler machen und die Abwärtskombatibität zu weit treiben. Auch die Unterstützung von zu vielen exotischen Systemen ist IMHO nicht sinnvoll.
Zum Thema IPad,
ich nutze das IPad2 als Wandtablet.
Ich habe im Zusammenhang mit Smartvisu und anderen Webapps die ich dort nutze sehr gute Erfahrungen mit dem Mercury Browser gemacht.
Den gibt es im App Store als Free und Pro Edition. Die Free reicht in den meisten Fällen. (Keine Adware!)
Beim Mercury Browser kann man den Browser Agent festlegen. Bei mir habe ich Chrome eingestellt und Smartvisu funktioniert 1A.
Grüße
Grav
No mercury for iOS 5...
ja, ist doof wenn man einem ipad1 ein Gnadenbrot geben möchte. Aber leider echt zu alt.
vg
Jörg
Und: da findet eine heftige Menge Client-seitige Verarbeitung statt, ein gewisses Maß an Rechenleistung muss einfach da sein.
Hat jemand schon mal Erfahrungen gesammelt, wie gut oder schlecht das auf einem Win 8 Tablet (irgend ein Atom wie Z3735F) läuft?
hi, nein.
Für Wandtabletts würde ich aber empfehlen auf android zu setzen. Grund: da hab ich die Grundzutaten für tts, brightness voice und co alle zusammen und die Dinger sind cheap und einfach zu ersetzen. Ich denke nicht das ich genug ressourcen habe dauerhaft auch andere OS damit zu versorgen. Bitte nur als Hinweis sehen,
vg
jörg
Ich hab hier noch ein Lenovo Thinkpad Tablet2 mit Windows8.1, zudem liegt im Wohnzimmer ein Samsung Galaxy Tablet 3 Lite für die Haussteuerung und Multimediasteuerung. Auf beiden Geräten funktioniert Smartvisu super.
Hi,
ich hab ein update ins git gestellt. Unter anderem Stabilität weiter verbessert.
Neu auch die Rechteverwaltung: read und write werden jetzt beachtet. Wenn man das nicht möchte kann man das attr "whitelist" auf "false" setzen. (Dann verschwinden auch im Editor die Optionen für "read" und "write"). Muss jeder selber entscheiden, man sollte aber bedenken das so ein system wächst. Wenn man das nicht von Anfang an richtig macht baut man sich Angriffspunkte.
Außerdem ändert sich das Verhalten vom "cmd set": bisher wurde (fälschlich) state angenommen wenn das Feld leer war. Richtig: wenn das Feld leer ist wird kein "set" ausgeführt.
Das kann diejenigen treffen die das Feld nicht ausgefüllt haben. Zur Erinnerung, da muss was drinstehen wenn ein "set" ausgeführt werden soll. Bei "set lampe on" muss "state" angegeben werden.
vg
jörg
Zitat von: T.ihmann am 16 Januar 2015, 16:56:30
ich habe ein Problem mit dem Design von bgewehr. In der Tabelle ist die Ausrichtung der Zeilen so verschoben, daß die Hälfte der Zeilen nicht zu lesen sind (siehe Anhang). Browser Firefox 34.0
Ich teste nicht auf Firefox. Ich nutze chrome und Safari.
Muss am css liegen, prüf nochmal, ob Du die visu.css sauber mitgenommen hast.
Bitte nicht die Stände mischen, heutige Seiten mit heutigem css, sonst passt gar nichts...
Zitat von: herrmannj am 13 Februar 2015, 21:45:23
ich hab ein update ins git gestellt. Unter anderem Stabilität weiter verbessert.
JÖRG, das ist super! Insbesondere der Gad-Editor sieht wieder richtig klasse aus und hilft über die set-Details richtig gut mit, alles richtig zu machen!
Toll, gemacht!
Zitat von: bgewehr am 13 Februar 2015, 22:04:22
Insbesondere der Gad-Editor sieht wieder richtig klasse aus...
Sieht bei mir optisch immer noch so aus wie vorher :(
Musste jetzt zumindest aber mal überall read setzen. Ansonsten würde ich nichts mehr sehen.
Wird sich der Editor noch in Zukunft ändern? Das ist viel Arbeit das für mehrere Fronthem-Devices zu pflegen.
Was eventuell auch noch interessant ist, innerhalb des GAD-Editors noch nach den "pages"-Ordnern zu trennen. Wenn man mehrere Designs hat und wechselt hin und her dann werden ja alle in die GAD-Liste mit aufgenommen.
Aber immer noch Wahnsinn was hier geleistet wird. Lob an Alle.
Danke Bernd :)
@dancatt
ohne Not ändere ich da nichts weiter, das mit dem set ist auch nicht neu das war schon immer so dokumentiert - fronthem hat das nur inkorrekt gehandelt.
Für die set kommt noch was dazu (was bisher keiner vermisst hat) - nämlich die Möglichkeit einzelne Werte (aus den GAD) in die set zu nehmen.
So:
set lampe off 900 ... -> set lampe off $gad. Gad liefert [300||600||900] - je nach button kann man dann also langsam ausschalten.
gleiches Spiel anderes setup:
set lampe off 900 ... -> set lampe $gad 900. Gad liefert [on||off] - also je nach button langsam an oder aus.
vg
jörg
axo & edith: pages, wäre cool aber weiß nicht wie das gehen soll. A: ein GAD kann ja auf verschiedenen Seiten sein, B: noch wichtiger: fronthem weiß garnicht welche page angezeigt wird, sprich von welcher page oder Ordner das GAD kommt ...
Prinzipiell finde ich den Editor gut, so wie er ist. Vor allem die Autovervollständigung ist eine große Hilfe.
Ich habe allerdings bereits jetzt 8 Geräte, mit denen ich das gerne testen möchte.
Im Moment ist mein Plan die Rechte für Gerät X01 anzupassen und dann die fhclient.X01.cfg über die fhclient.X02-X0n.cfgs drüberzubügeln.
Müsste doch gehen, oder geht das auch eleganter?
Hi Carsten,
genau, so gehts. Auf diese Weise gibst Du die individuellen Rechte von a -> b.
Wenn Du ohne arbeitest kannst Du "whitelist" auf false setzen.
vg
jörg
Alles klar. Danke!
Zitat von: herrmannj am 13 Februar 2015, 23:54:43
Wenn Du ohne arbeitest kannst Du "whitelist" auf false setzen.
Und mir nachher ein "Ich hab's Dir ja gesagt!" abholen? Nein Danke! :)
In der "Designphase" werd ich das wohl für die Geräte 2 bis n machen, aber beim Referenz-PC werd ich die immer schön setzen. Man muss ja sowieso einmal rein.
Ich hab heute die Widgets ( wohl größtenteils/alle? von bgewehr ) im github "entdeckt" ( sprich: jemand hat einen Link gepostet ).
Tolle Dinger dabei. Vielen Dank dafür. Gibts irgendwo zufällig ne Referenz dazu?
Ich habe mir das hmtc-Widget eingebaut. Gefällt mir gut, aber ich hab ein paar Schwierigkeiten.
Die Kommentare passen ja nicht (mehr?) ganz zur Parameterliste.
Laut Beschreibung ist das für die HM-TCs. Die haben aber doch gar keinen Boost, oder?
Den Batteriestatus liefern meine TCs auch nur als ok oder dead, aber keine Prozente.
Der Step-Parameter landed als GAD im Fronthem. Ich hatte 0.5 eingetragen und bekam dann ein neues GAD namens "0.5" in FHEM angezeigt. Hab das jetzt erstmal hardcodet im Widget selbst korrigiert, aber ist das ein Fehler im Widget oder im Verständnis?
Davon abgesehen aber ein hübsches Widget, durch das ich nebenbei auch viel über Widgets an sich lerne.
Was Ihr ( und die smartvisu-Jungs ) hier baut, ist das Frontend, dass ich immer vermisst habe. Flexibel, hübsch und so simpel, dass ich es gerade noch fast verstehe. Vielen Dank!
ZitatWas Ihr ( und die smartvisu-Jungs ) hier baut, ist das Frontend, dass ich immer vermisst habe. Flexibel, hübsch und so simpel, dass ich es gerade noch fast verstehe. Vielen Dank!
... da kann ich mich nur anschließen... Danke auch von mir !
Hallo,
Auch von mir: Danke.
Kleiner Wermutstropfen sind arrow-up.svg und arrow-down.svg. Die sind in einem Darkstyle nur in jeder zweiten Zeile zu erahnen. Ich habe sie mir rot eingefärbt. Das übersteht aber kein Update.
Ist sicherlich völlig sekundär aber doch störend.
Gruß
Hans
Ab sofort widget Referenz unter https://github.com/herrmannj/smartvisu-widgets
Hallo!
Hat noch jemand das Problem das fronthem alle 1-2 tage aus unerklärlichen Gründen abstürzt?
2015.02.14 15:09:48.651 1: fronthem: thread ws closed for unknown reason
Wollen wir den Issue Service von github für Problem Meldungen nutzen?
Grüße
zu 1) Bei mir ist fronthem selbst noch nie abgestürzt. Seit der vorletzten Version ist auch FHEM nicht mehr durch fronthem abgestürzt.
zu 2) ich bin nicht sicher, ob dann wirklich alle Probleme erfasst werden
@bgewehr: Dein Select-Widget ist nicht universell genug. Schau mal hier in den Widget Thread. Dort habe ich eine Alternative gepostet. Das lässt sich auch noch verwenden, wenn irgendwann einmal Listen aus FHEM geholt werden können.
Zum gad-Editor: Ich bin ehrlich, ich hätte mir das anders gewünscht. Von der Usability her, ist das teilweise schon grausam (Gründe habe ich weiter oben schon beschrieben). Ich bin niemand, der Dinge lobt, die ihm nicht gefallen und so ehrlich sollte man auch sein. Ich will aber nicht meckern. Insgesamt ist das ganze hier ein mächtiges und sehr gutes Projekt und es kann nicht immer alles sein, wie man es sich wünscht, wenn man selbst keine Zeit und/oder die Kenntnisse hat, sich an der Entwicklung zu beteiligen.
Zitat von: bgewehr am 14 Februar 2015, 15:16:52
Ab sofort widget Referenz unter https://github.com/herrmannj/smartvisu-widgets
Super, danke!
In Zeile 113 von widget_homematic ist ein Tippfehler. Dort steht "ednif" statt "endif".
Wo gibt es denn das Boost-Icon? Ist kein Standard, oder?
Versucht das Widget bei euch nicht, den Wert step von FHEM zu bekommen?
Wo bekommt ihr beim TC den Batterywert her?
Hallo Carsten,
das boot icon gibt es "nur" bei dem HM-TC-IT-WM-W-EU und nicht bei dem HM-CC-TC. Ich habe bei mir beide im Einsatz und der Boost Taster funktioniert bei dem ersten einwandfrei (wenn auch bei Fussbodenheizung nicht unbedingt nötig).
HM-TC hat Boost und HM-CC-RT auch!
Bernd: In welchem reading steht denn der Boost beim HM-CC-TC?
Ah, jetzt wird mir einiges klar... Ich dachte, es geht um den HM-CC-TC.
Dass der neue Thermostat auch ein TC drinhat, hatte ich nicht auf dem Schirm. Ich dachte, das wär was mit DN, aber das ist wohl der neue Stellantrieb.
Sorry für meine Verwirrung.
Zitat von: Gerd.Ternes am 14 Februar 2015, 16:34:42
Bernd: In welchem reading steht denn der Boost beim HM-CC-TC?
"WZ_rtr_text" : {
"reading" : "boostTime",
"type" : "item",
"converter" : "Direct",
"device" : "Raumthermostat_WZ_Temperatur",
"set" : null
},
FHEM-Treiber V1.02
Ich habe dem Treiber und SmartVISU das Blockieren ausgetrieben.
Die Routine, die die GADs nach einem monitor aktualisiert, bekommt das nun hin, ohne die Oberfläche zu blockieren.
Und dann war da noch die refresh-Routine in der widget-Klasse von SmartVISU. Die hat blockierend bei jedem Wechsel einer page reichlich Zeit verbracht.
Für die habe ich einen Ersatz im Treiber geschaffen, so dass SV nicht geändert werden muss.
Damit kann ich auf meinem Nexus 5 die pages (auch die Testpage mit 300 GADs) ohne nennenswerte Verzögerung direkt nach der Anwahl bedienen, während die Werte noch eintrudeln.
Der Treiber ist commited und hier zu finden:
https://github.com/herrmannj/smartvisu-cleaninstall/blob/master/driver/io_fhem.js
https://github.com/herrmannj/smartvisu-cleaninstall/blob/master/driver/io_fhem.min.js
Getestet und: Sehr geil!
Zitat von: marvin78 am 14 Februar 2015, 17:38:27
Getestet und: Sehr geil!
Hast Du den Change im repository gesehen, während ich hier getippt habe oder wie konntest Du so schnell sein? ;D
@HCS funktioniert bei mir einwandfrei, gute Arbeit, danke!!
Zufällig ja ;) Ach und: ich bin schnell :D
Zitat von: marvin78 am 14 Februar 2015, 15:24:24
... und es kann nicht immer alles sein, wie man es sich wünscht, ...
Ja, leider, ich hatte mir sooooo sehr die sortierten GADs in den cfg gewünscht.
ja, kommt noch. Bin etwas zeit-knapp.
Dafür gibt es mit dem update viele Sachen zum Thema Stabilität, das ist ja auch wichtig. Da ist fronthem mit dem neuen update so das kaum noch Punkte drin sind wo was passieren sollte. Umso wichtiger wird jetzt, sollte wirklich was unvorhergesehenes passieren, das genau zu dokumentieren und in ein Szenario zu finden in dem ich das nachstellen kann.
Zum Editor: (@marvin), ich hab das nicht mehr ganz im Kopf wo Du Verbesserungen willst. Sag noch mal bitte oder waren das die GADs nach Dir/page ? Das geht halt einfach nicht.
Was ich noch in der pipeline habe ist eine Sortier- und Filterfunktion bei den GADs. Gedacht so das man die Liste filtern kann (nur GADs die aktuell in sv angezeigt werden sind in der Liste). Und eine Funktion um die GADs nach Zeit (letzter Zugriff) zu sortieren. Das hat aber bei mir keine hohe Prio weil ich der Meinung bin das man da ja "nur" konfiguriert - im Normalfall, im normalen Betrieb wenn alles eingerichtet ist, geht man da ja nicht bei.
Ansonsten nehme ich Vorschläge gern auf. Ehrlicherweise: ich muss halt auch immer abwägen wie der Zeiteinsatz ist um das dann zu machen und da fallen auch Sachen runter.
vg
jörg
Zitat von: herrmannj am 10 Januar 2015, 13:15:12
hab gerade Deinen edith gelesen (wollte das gerade vorschlagen :)) Du hattest das irgendwie auf einem mac -richtig ? Ich schau da nochmal rein. Das wundert mich eigentlich weil der fork in der mutter gemacht wird, but who knows ...
Hast du dafür schon mal Zeit gefunden?
Grüße
@hsc,
driver: sehr cool, bin ihn eben überflogen. Ich hätte noch eine Idee, weiß aber nicht genau was die bringt. Thema ist die Zeit im update.
Normaleiweiße sind "each" und die Selektorsuche (line #171) echte Zeitfresser.
Idee wäre das widget-object selbst zu cachen, (array im driver), dann spart man sich für alle weiteren updates auf dem GAD die #171, ich vermute da >80% Zeit pro update damit gespart werden können (schätze, glaube .. )
vg
jörg
Zitat von: fhainz am 14 Februar 2015, 18:34:49
Hast du dafür schon mal Zeit gefunden?
Grüße
danke für den reminder - ich weiß nicht mehr genau worum das da ging. Sorry, sag noch mal bitte.
danke und vg
jörg
Es ging um das Problem das bei mir ein shutdown restart nicht funktioniert bzw in einen
2015.01.10 12:57:31.268 1: WEB: Can't open server port at 63191: Address already in use. Exiting. endet.
Siehe hier: http://forum.fhem.de/index.php/topic,30909.msg243206.html#msg243206
Ja, alles klar. Das soll, soweit es fronthem betrifft, vom Tisch sein, hab da einiges optimiert. Tritt immer noch auf ? Vorsicht, das kann auch völlig fronthem unabhängig sein.
Was ich oben vergessen habe zu erwähnen, in dem update sind auch die Sonderzeichen-fix drin.
vg
jörg
@herrmannj: Ich bin eben der Meinung, dass der gad Editor eigentlich "übergeordnet" sein müsste und nicht innerhalb der fronthemDevices. Das ist aktuell inkonsequent. Der gad wird automatisiert in allen Devices angelegt und das konfigurieren (Device, converter, set etc) muss man es in EINEM Device. Um dann aber die Rechte für die anderen Devices anzupassen, muss man in jedes Device und in jeden Gad rein klicken, abspeichern etc. Das ist schon sehr unkomfortabel und Benutzer unfreundlich. Meinen Vorschlag hatte ich eigentlich schon mehrfach gepostet: Sinvoll wäre IMHO, den gad-Editor im fronthem und nicht im fronthemDevice zu haben. Dann dort eine breite Tabelle in der man für die Rechte Haken setzen und dann für alle Devices auf einmal abspeichern kann. Ich denke, du kannst dir vorstellen, was ich meine. Auch das wird unter Umständen auf kleinen Bildschirmen nicht gerade übersichtlich aber da könnten gute Filter etc. helfen.
ABER: Das ist wirklich Jammern auf hohem Niveau. In einer perfekten Welt... ;)
Ja, das tritt immer noch auf.
Sobald das fronthem Device gelöscht oder aus unbekannten gründen plötzlich abgeschmiert (siehe hier (http://forum.fhem.de/index.php/topic,30909.msg261465.html#msg261465)) ist, funktioniert der neustart problemlos, deswegen denk ich schon das es mit fronthem zusammenhängt.
Grüße
Zitat von: herrmannj am 14 Februar 2015, 18:24:28
Was ich noch in der pipeline habe ist eine Sortier- und Filterfunktion bei den GADs.
Also so für die ganz ferne Zukunft wäre in den Spaltenköpfen ein "Excel-like" filter genial, um z.B. GADs zu filtern, die z.B. nicht R, W oder in der Bezeichnung etwas bestimmtes enhalten usw. Dazu noch Mehrfachselektion für das Löschen.
Und ohne es nun ganz gründlich zu überdenken, glaube ich, dass ich mich der "marvin78-Ansicht" anschließen kann.
Auch dafür bräuchte man dann leistungsfähige Filter und multiselect, sonst ist man immer noch am "durchklicken"
Und es klingt nach reichlich Arbeit.
Vielleicht findet sich ja jemand, der den ultimativen Editor schreiben möchte.
Fertigstellungstermin = Starttermin + Personenstunden /
Anzahl Personen ;) ;) (vereinfachte Formel)
Ist aber Prio 3
Zuerst sollten wir dann die Plots in Schwung bringen. Denk bitte dran, ich habe schon was vorbereitet.
Ach ja, ich habe das Interface für einen addon-driver geändert. Ich werde noch ein aktuelles Beispiel ins repository einchecken.
Wer schon einen geschrieben hat, sorry muss nun angepasst werden.
@marvin
sollte vielleicht - ja nach workflow auch beides gehen. Also "mutter" macht alle, "device" seins. Hatte ich nicht so dediziert verstanden.
Das Design ist aber auch aus einem Sachzwang heraus genau so. Theoretisch ist es möglich mehrere fornthem Instanzen zu betreiben. Ich hab zwar keine genaue Anwendung dafür aber sich so etwas offen zu halten ist eigentlich immer eine gute Idee (Stichwort: mehr als 16 Adressleitungen brauchen wir nieeeee). Dann würde die Mutter nicht mehr wissen welche device sie in der Liste darstellen soll (es sein denn sie sind gerade aktiv).
Muss ich nochmal nachdenken. Aber ich denke es ist ok das nicht ganz oben auf der Liste zu haben, da seh ich eher Stabilität, Plots, app. OK ?
vg
jörg
@HCS
Zitat
Ach ja, ich habe das Interface für einen addon-driver geändert.
btw, Du wolltest einen Filter in fronthem haben. Der ist rudimentär im fronthemDevice in line #635 angelegt. Der wird erweitert werden, ich brauch den später für die APPs (tts, brightness, play, voice und co) per plugin. Allerdings kommt da noch viel zu, wenn Du was änderst wird das von updates überschrieben werden.
Da sind die "mutter" und das "device" involviert. Die "mutter" soll die app spezifischen Funktionen ja nicht in die cfg übernehmen, das device muss aber seine set-list anpassen. Fürs erste aber hardcoded dort ein Einstiegspunkt.
Im Augenblick filtere ich GADs die mit "internal.".. beginnen - die funktionieren also nicht mehr als reguläres GAD.
vg
jörg
@HCS: Das hast du gesehen?
Zitat von: herrmannj am 14 Februar 2015, 18:35:19
@hsc,
driver: sehr cool, bin ihn eben überflogen. Ich hätte noch eine Idee, weiß aber nicht genau was die bringt. Thema ist die Zeit im update.
Normaleiweiße sind "each" und die Selektorsuche (line #171) echte Zeitfresser.
Idee wäre das widget-object selbst zu cachen, (array im driver), dann spart man sich für alle weiteren updates auf dem GAD die #171, ich vermute da >80% Zeit pro update damit gespart werden können (schätze, glaube .. )
vg
jörg
Zitat von: fhainz am 14 Februar 2015, 18:48:38
Ja, das tritt immer noch auf.
Sobald das fronthem Device gelöscht oder aus unbekannten gründen plötzlich abgeschmiert (siehe hier (http://forum.fhem.de/index.php/topic,30909.msg261465.html#msg261465)) ist, funktioniert der neustart problemlos, deswegen denk ich schon das es mit fronthem zusammenhängt.
Grüße
hmmm. Auch mit dem update von gestern ?
Ja. Hab gestern ein update gemacht.
Zitat von: herrmannj am 14 Februar 2015, 19:01:19
... da seh ich eher Stabilität, Plots, app. OK ?
Sehe ich auch so.
Stabilität scheint gut.
Plots wären nun dran.
Zur Stabilität: mit den Tests für den Treiber habe ich fronthem in letzter Zeit übel tracktiert und es öfter mal gekillt, wohlgemerkt, immer von SV aus, aber seit gestern ist nun definitv nichts mehr passiert. Ist zwar noch kein Langzeittest aber es sieht gut aus.
Zitat von: herrmannj am 14 Februar 2015, 19:10:32
Im Augenblick filtere ich GADs die mit "internal.".. beginnen - die funktionieren also nicht mehr als reguläres GAD.
Genau so hatte ich es mir vorgestellt, nur halt ein Attribut, in dem man den Filter definieren kann. Global, nicht pro Device.
Zitat von: herrmannj am 14 Februar 2015, 18:35:19
Normaleiweiße sind "each" und die Selektorsuche (line #171) echte Zeitfresser.
Idee wäre das widget-object selbst zu cachen, (array im driver), dann spart man sich für alle weiteren updates auf dem GAD die #171, ich vermute da >80% Zeit pro update damit gespart werden können (schätze, glaube .. )
Das habe ich noch als Forschungsprojekt auf der Liste. Die SV-Variante, die ich übernommen habe, hat mir auch nicht ideal gefallen.
Nachdem es so prima funktioniert hat und getestet war, wollte ich es erst mal veröffentlichen, dass Feld-Erfahrung mit dieser Treiber-Version entsteht.
Und
@All: Hat eigentlich jemand mal noch das Problem mit den verschluckten Werten gehabt, wenn sich die readings in FHEM sehr schnell ändern?
Mein Test dazu läuft immer noch so vor sich hin und es tritt bei mir nie auf.
jo, so sehe ich das auch. sv selber hat ja riesig gewonnen. Ist eine Idee für die Forschung :) und ja auch nicht ganz trivial umzusetzen.
vg
jörg
Zitat von: HCS am 14 Februar 2015, 19:26:13
Und @All: Hat eigentlich jemand mal noch das Problem mit den verschluckten Werten gehabt, wenn sich die readings in FHEM sehr schnell ändern?
Nein, nicht vorher und auch nicht nachher!
Dann hake ich das Topic jetzt ab. Habe eh nicht daran geglaubt, dass der Treiber das verursachen kann.
hier ebenfalls, nie aufgetreten. vg
Ich hab noch mal versucht meinem config Problem näher zu kommen.
Kann es sein das auf der Synology keine Configs gespeichert werden können, weil dort die Verzeichnisstruktur anders ist?:
Ich habe unter usr/local/FHEM/ folgende Verzeichnisse:
Unter bin liegt die fhem.pl:
usr/local/FHEM/bin/fhem.pl
Unter share/fhem/ liegt das eigentliche FHEM Verzeichnis:
usr/local/FHEM/share/fhem/FHEM
usr/local/FHEM/share/fhem/www
usw.
Leider bin ich in Perl nicht so bewandert um rauszubekommen ob das das Problem ist.
Ich hab schon mal versucht den Pfad fest einzutragen, hat aber leider nicht zum Erfolg geführt.
vg
Hallo,
ich ahbe nach längerer Zeit nochmal ein update eingespielt über update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
Auch wenn es nicht das hübscheste war, das Wetter auf der Startseite ist verschwunden (die Uhr ist noch da). Ist das so gewollt?
schöne Grüße
Jo
Klar ist das so gewollt. Man will genau dich ärgern!
Eigentlich hat das weather-Widget nichts mit Fronthem zu tun (wenn du das Standard-Widget verwendest). Um allerdings zu sagen, woran es liegen könnte, lieferst du hier viel zu wenig Informationen.
Zitat von: Jojo11 am 15 Februar 2015, 10:04:10
Auch wenn es nicht das hübscheste war, das Wetter auf der Startseite ist verschwunden (die Uhr ist noch da).
Hast du das read-Recht in der GAD-Liste gesetzt?
Hallo,
ich weiß, dass die Rechtevergabe bis vor Kurzem nicht berücksichtigt wurde. Von daher könnte ich mir vorstellen, dass da der Hund begraben liegt. Allerdings finde ich in der GAD Liste nichts, was der Wettervorhersage zuzuordnen wäre. Ich verwende das Standard-Widget und habe auch an der Einbindung nichts geändert.
schöne Grüße
Jo
Aber so lange du nicht mehr Infos lieferst, kann dir wohl keiner wirklich helfen. Wie hast du es eingebunden? Welchen Dienst verwendest so (kann es vielleicht einfach daran liegen, dass dieser aktuell nicht erreichbar ist)? ...
Zitat von: Blaky am 15 Februar 2015, 08:24:20
Ich hab noch mal versucht meinem config Problem näher zu kommen.
Kann es sein das auf der Synology keine Configs gespeichert werden können, weil dort die Verzeichnisstruktur anders ist?:
Hi,
Eigentlich nein, die pfade werden relativ berechnet.
vg
jörg
Zitat von: Jojo11 am 15 Februar 2015, 10:25:40
Hallo,
ich weiß, dass die Rechtevergabe bis vor Kurzem nicht berücksichtigt wurde. Von daher könnte ich mir vorstellen, dass da der Hund begraben liegt. Allerdings finde ich in der GAD Liste nichts, was der Wettervorhersage zuzuordnen wäre. Ich verwende das Standard-Widget und habe auch an der Einbindung nichts geändert.
schöne Grüße
Jo
Hi Jo,
wenn Du das Wetter widget von sv nimmst hat das nichts mit den Rechten zu tun, nichts mit fronthem allgemein. Muss also woanders liegen.
vg
jörg
Beim Converter NumDirect werden plötzlich negative Werte zu positiven Werten. Das war vor der neuen Version nur bei NumDisplay der Fall. Ist an der Stelle etwas geändert worden?
Edit: Kann das eventuell auch mit dem Treiber zusammenhängen?
ja, scheinbar nicht richtig. Ich meine im test hat das funktioniert ??? Steht in Deinem reading zwischen dem "-" und der Zahl ein space ?
vg
jörg
Nein. Das Reading ist ein korrekter negativer Float, wie
-3.6
Ich habe in fhem einen dummy der per slider auf einen negativen Zahlwert eingestellt wird bzw. in smartVISU. In sv steht das gad immer auf -50 (höchster wert) setze ich diesen jetzt auf - 57 wird der Wert in fhem richtig übernommen aber der sv slider springt sofort wieder auf -50. Mir scheint es so als ob smartVISU nicht richtig liest...
Zitat von: marvin78 am 15 Februar 2015, 11:55:57
Nein. Das Reading ist ein korrekter negativer Float, wie
-3.6
Dann muss ich suchen (keine spontane Idee). Die regex aktuell ist in fhconverter #199 : /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;
vg
jörg
Zitat von: fidel am 15 Februar 2015, 12:17:35
Ich habe in fhem einen dummy der per slider auf einen negativen Zahlwert eingestellt wird bzw. in smartVISU. In sv steht das gad immer auf -50 (höchster wert) setze ich diesen jetzt auf - 57 wird der Wert in fhem richtig übernommen aber der sv slider springt sofort wieder auf -50. Mir scheint es so als ob smartVISU nicht richtig liest...
versteh (die Frage) nicht komplett.
Wenn Du in sv was einstellst wird der Wert an fhem gegeben - dort verarbeitet und an sv zurückgegeben.
Das braucht man um andere GADs zu aktualisieren und um Begrenzungen einzurichten (zb rtr - 4° ... 30°). Wenn eine Werte-Begrenzung (wie auch immer) in fhem existiert passiert das von Dir beschriebene:
Du gehst in sv über|unter die Grenze (wird angezeigt) - fhem verarbeitet, passt an und setzt in sv auf den Grenzwert. Hat das was mit Deinem setup zu tun ?
vg
jörg
Nein es lief vorher.
Aber es würde passen, wenn der Wert als positiv Wert zu smartvisu zurück kommt, dass Smartvisu mir immer den Maimalwert (-50 angibt), oder!?
Sollte keine Frage sein, sonder ich wollte nur bestätigen, dass ich seit dem Update von gestern/vorgestern auch Probleme mit NumDirect habe.
axo, ja sorry. Ekläre mir das bitte nochmal genauer, ich machs ja gern heile - ich muss es nur verstehen. :)
vg
jörg
Zitat von: herrmannj am 15 Februar 2015, 10:37:11
Hi Jo,
wenn Du das Wetter widget von sv nimmst hat das nichts mit den Rechten zu tun, nichts mit fronthem allgemein. Muss also woanders liegen.
vg
jörg
Alles klar, danke. Ist alles Standard und nichts modifiziert. Ich such mal woanders oder werfe es gleich raus ::)
schöne Grüße
Jo
Nachtrag: Ok, der Service war wohl nicht erreichbar.
Zitat von: marvin78 am 15 Februar 2015, 11:48:33
Edit: Kann das eventuell auch mit dem Treiber zusammenhängen?
Nö.
Gerade getestet. Mit Direct kommt es beim Treiber korrekt an.
Bei NumDirect und NumDiplay kommt es beim Treiber falsch an.
Zitat von: herrmannj am 15 Februar 2015, 10:32:12
Hi,
Eigentlich nein, die pfade werden relativ berechnet.
vg
jörg
So ich habs hinbekommen.
Es scheint doch mit den rel. Pfaden ein Problem zu geben.
Allerdings habe ich noch keine Ahnung welchen Pfad er versucht zu benutzen.
Wenn ich den Pfad fest eintrage funktioniert es:
mkdir('/usr/local/FHEM/share/fhem/www/fronthem',0777) unless (-d '/usr/local/FHEM/share/fhem/www/fronthem');
mkdir('/usr/local/FHEM/share/fhem/www/fronthem/server',0777) unless (-d '/usr/local/FHEM/share/fhem/www/fronthem/server');
mkdir("./usr/local/FHEM/share/fhem/www/fronthem/server/$hash->{NAME}",0777) unless (-d "/usr/local/FHEM/share/fhem/www/fronthem/server/$hash->{NAME}");
$cfgFile = "/usr/local/FHEM/share/fhem/www/fronthem/server/$hash->{NAME}/$cfgFile";
Ist zwar mühsam das immer per Hand nach einem Update zu ändern, aber zumindest kann ich jetzt schon was basteln ohne immer neu anfangen zu müssen. ;D
Gruß,
Marcel
aha, ok danke. Verstehe ich nicht (sofort) - schau ich mir an.
d&g
jörg
Hallo,
ich habe ein kleines Problem mit dem Fhem-Treiber. Wenn ich den benutze bekomme ich in Fhem kein Connect. Wenn ich den Domotiga-Treiber nehme ist der Connect sofort da.
Woran kann das liegen?
Gruß, Sascha
Zitat von: Cybers am 15 Februar 2015, 14:22:44
ich habe ein kleines Problem mit dem Fhem-Treiber. Wenn ich den benutze bekomme ich in Fhem kein Connect. Wenn ich den Domotiga-Treiber nehme ist der Connect sofort da.
Woran kann das liegen?
IP und Port eingetragen, nachdem Du den FHEM Treiber gewählt hast?
ip und port stimmen...
Mach mal im Brower mit F12 die Konsole auf und dann einen page reload, was da so geloggt wird.
Zitat von: herrmannj am 15 Februar 2015, 12:40:08
axo, ja sorry. Ekläre mir das bitte nochmal genauer, ich machs ja gern heile - ich muss es nur verstehen. :)
vg
jörg
Ich habe in fhem nen dummy mit setlist slider von -80 bis -45. (Er dient um die Lautstärke meines AVR bei einem Anruf zu setzen. Den Maximalwert habe ich eben noch geändert.)
In sv habe ich ebenfalls einen slider mit selbem min max Wert.
Im gad editor den entsprechenden dummy ausgewählt reading und cmd set auf state und als converter numdirect.
Das Fehlverhalten ist folgendes.
In fhem hat der dummy den state -60.
Bei Aufruf von sv wird jedoch -45 angezeigt. Ändere ich in sv auf z. B. auf -58 wird der Wert in fhem im dummy korrekt übernommen und in sv springt der Wert direkt nach einstellen des Wertes wieder auf -45. In fhem bleibt der Wert -58 erhalten.
Grüße Steven
Das Verhalten würde ja passen, zu dem was marvin auch schon schilderte.
Wenn fhem bzw. fronthem den Wert +58 zurück liefert, springt der slider in sv auf -45.
gut (oder nicht). Das macht Sinn - ich geh auf die Suche woran das liegen könnte. vg jörg
Bei mir ist es aber (nur) ein ganz normaler Temperaturwert (jedoch aus unterschiedlichen Devices, aber immer gleich formatiert). Über NumDirect hat das schonmal funktioniert. Nur über NumDisplay noch nie.
Hallo Bernd,
ich habe deine Timecounter etwas angepasst. Jetzt zeigt es auch Stunden an. Weiß zwar nicht ob es elegant ist, aber es funktioniert.
Vielleicht willst du es einbauen!
{% macro timecounter(id, gad, mode) %}
<script type="text/javascript">
function ZeitAnzeigen (objectID, mode, value) {
var absSekunden = value
if (absSekunden == 'NaN') {absSekunden = 1};
var relSekunden = absSekunden % 60;
var absMinuten = Math.abs(Math.round((absSekunden - 30) / 60));
var relMinuten = absMinuten % 60;
var absStunden = Math.abs(Math.round((absMinuten - 30) / 60));
var anzSekunden = "" + ((relSekunden > 9) ? relSekunden : "0" + relSekunden);
var anzMinuten = "" + ((relMinuten > 9) ? relMinuten : "0" + relMinuten);
var anzStunden = "" + ((absStunden > 9) ? absStunden : "0" + absStunden);
return(anzStunden + ":" + anzMinuten + ":" + anzSekunden);
};
</script>
<span id="{{ uid(page, id) }}" data-widget="basic.timecounter" data-item="{{ gad }}" data="{{ mode }}">-:-:-</span>
{% endmacro %}
Gruß Lutz
Zitat von: herrmannj am 31 Januar 2015, 20:19:57
ja, so werden wir das wohl machen :) - Du hast ja schon genug Geduld geopfert. Danke. Ich habe (oben) noch 'nen Sack Arbeit dazubekommen, mal schauen ob ich das heute noch schaffe, sonst evtl morgen. Und dann machen wir 'nen neuen fred . vg jörg
Hallo Jörg,
war jetzt, wie du weisst, einige Tage im Urlaub.
Hab nun heute mal ein Update von Fronthem, FHEM und dem driver (v.1.02) gemacht.
Hatte heute mal wieder das zweifelhafte Vergnügen
2015.02.15 18:43:10 1: fronthem: thread ws closed for unknown reason
2015.02.15 18:43:10 3: fronthem: client Olli: forced disconnectzu begegnen. Hattest du den vermeintlichen Fix für mein Problem schon eingebaut?
Gemacht hatte ich kaum was, ein paar Seiten umgestaltet, Server restartet (Updates von FHEM, Fronthem, usw.) und ein bisschen am PC rumgespielt. Das Tablet war heute aussen vor!
Ich werde das die nächsten Tage mal beobachten und dir eventuelle Wiederholungen melden.
Grüßle,
Olli
Ich hätte eine Frage.
Ich habe bei mir zuhause ein sicheres Netz und greife gut und gerne auch mal über VPN auf mein Heimnetzwerk zu.
Dabei bin ich aber schon oft dem Problem begegnet das ich nicht mehr auf smartVISU zugreifen kann. Jetzt wäre die Frage ob ich nicht einfach alle Geräte für smartVISU erlauben kann. Auch ohne IP Erkennung. Ich brauche das nämlich für Zuhause nicht wirklich.
Danke im voraus.
Hi oli,
Wenn du das Update hast (kannst ja zur Sicherheit nochmal) dann müssen wir das beobachten. So mit Log, Frontem.err und so.
Hi trickser
Ne geht nicht, weil: geht ja nicht nur um den Access. Die device müssen auch einzeln von Frontem betreut werden. Wer braucht wann welche gad und so. Bzgl Access kannst du ja whitelist auf false setzen, dann musst du nichts weiter machen als das device mit Ip einmal zu definieren.
Vg
Jörg
Okay danke. Du meinst, wenn ich Whitelist auf false setzte können zumindest die angemeldeten Geräte auf alle Geräte zugreifen ohne das ich vorher die Rechte setzten muss? Oder wie ist das gemeint?
Ja genau. Natürlich musst du die jeweiligen gad einmal definiert haben. Das kannst du auf einem x beliebigen Client machen, das wird geshared.
Dann jeweil am device whitelist false, Client darf alle gad lesen und schreiben.
Vg
Jörg
Zitat von: fidel am 15 Februar 2015, 16:03:08
Ich habe in fhem nen dummy mit setlist slider von -80 bis -45. (Er dient um die Lautstärke meines AVR bei einem Anruf zu setzen. Den Maximalwert habe ich eben noch geändert.)
In sv habe ich ebenfalls einen slider mit selbem min max Wert.
Im gad editor den entsprechenden dummy ausgewählt reading und cmd set auf state und als converter numdirect.
Das Fehlverhalten ist folgendes.
In fhem hat der dummy den state -60.
Bei Aufruf von sv wird jedoch -45 angezeigt. Ändere ich in sv auf z. B. auf -58 wird der Wert in fhem im dummy korrekt übernommen und in sv springt der Wert direkt nach einstellen des Wertes wieder auf -45. In fhem bleibt der Wert -58 erhalten.
Grüße Steven
Hallo Jörg,
ich habe mich vertan. Der Wert kommt auch beim setzen aus smartVISU als positiv Wert in fhem an.
Gruß
Steven
Funktioniert der Attribute Converter schon ?
Will über SV ein AT je nach Bedarf auf disable 0 bzw. 1 setzten....
Habe im GAD-Editor verschiedenes probiert, aber es hatte keine Auswirkung auf das AT.
Gruß Kai
##################################################
Edit:
Habs hinbekommen.. auch bei reading disable eingetragen und dann gings...
Ich habe mich mal mit den Charts beschäftigt.
Hier die Grobfassung meiner Gedanken dazu. Details müssen noch ausgearbeitet werden.
Da gibt es einige SV Dinge, die meiner Meinung nach Änderungsbedürftig sind. Da wären (vermutlich noch nicht vollständig die Liste):
- Das GAD wird mit Konfigurationswerten erweitert. Das ist ganz unglücklich.
Beispiel: wenn man diesen plot definiert:
{{ plot.period("OilLevelPlot",
["hcs.data.OilLevelPlot"],
"avg",
"5y 6m",
"",
"10",
"400",
"4400",
"500",
"Füllstand",
["#44f"],
["line"],
["","Liter"]) }}
ist das GAD, das am Schluss dabei rauskommt und bei fronthem ankommen würde und auch wieder geliefert werden muss das hier: "hcs.data.OilLevelPlot.avg.5y 6m.0"
Im trunk von SV gibt es eine neuere Version, die einen weiteren Parameter hat, der auch an das GAD angehängt wird.
Nach einem SV-Update würde dann in fronthem kein definiertes GAD mehr passen.
Ich halte es generell auch nicht für sinnvoll, Konfigurationswerte mit Punkten getrennt, an ein Idetifikationsmerkmal anzuhängen.
-> Dafür habe ich bereits eine Lösung
- Man sollte in SV festlegen können, in welchem Interval der Plot aktualisiert wird
-> Lösung vorhanden
Ein plot mit mehreren Serien erscheint nur, wenn alle Serien Daten geliefert haben
-> Vermutlich im Treiber machbar
- Solange ein Plot keine Serie bekommen hat, ist er komplett unsichtbar
-> Vermutlich im Treiber machbar
Es ist nicht vorgesehen, den kompletten Plot zu aktualiseren, sondern nur einzelne Punkte hinten anzufügen
-> Lösung vorhanden, einzelne Punkte anhängen auch machbar
- Die plotoptions der Highcharts können nicht gesetzt werden. Genau da stecken aber viele nette Konfigurationsmöglichkeiten für das chart.
-> Im Widget realisierbar
Man sollte bei der GAD-Definition optional die Klasse für den "Plot-div" setzen können, um z.B. unterschiedlich große charts konfigurieren zu können
-> Im Widget realisierbar
Das läuft aber darauf raus, dass wir das ganze direkt vom Start weg selbst abhandeln. Der Treiber muss das eh, sonst bauen wir "nonblocking" hinterher wieder ein.
Ich habe das mal im Treiber testweise implementiert und versorge ihn von meinem addon-Treiber aus mit Daten.
Von fronthem aus sollte das eigentlich genauso machbar sein.
Der einzig Nachteil: Es geht nicht mit den original SV-Widgets, sondern nur mit angepassten. Für den plot.period habe ich das gemacht.
Ist nicht so dramatisch und es gibt eh nur vier plot Widgets in SV.
Und da wir die Widgets bestimmt erweitern werden, können wir auch direkt mit eigenen starten.
Die wären einfach analog zu den plot.* von SV, nämlich chart.comfortchart, chart.period, chart.rtr, chart.temprose
Die Kommunikation zwischen dem Treiber und fronthem könnte so ablaufen:
fronthem bekommt (analog zu monitor) die Serien mitgeteilt, die es liefern soll
Beispiel:
{
"cmd": "series",
"items": [
{
"gad": "plot.LivingRoom",
"mode": "avg",
"start": "2d",
"end": "1d",
"interval": "300"
},
{
"gad": "plot.Cellar",
"mode": "avg",
"start": "3d",
"end": "now"
"interval": "600"
}
]
}
Das teilt fronthem mit: bitte zwei Serien liefern
das GAD ist "plot.LivingRoom", mode ist "avg", die Serie soll vor zwei Tagen beginnen und vor einem Tag enden und alle 300 Sekunden aktualisiert werden.
Zweite Serie sinngemäß. Ob wir den mode brauchen muss man noch sehen.
fronthem würde die Serien dann in dieser form an den Treiber schicken:
{
"cmd": "series",
"items": {
"gad": "plot.LivingRoom",
"plotdata": [
[
"x-Value1",
"y-value1"
],
[
"x-Value2",
"y-value2"
],
[
"x-Value3",
"y-value3"
]
]
}
}
Ob da noch Anpassungen für comfortchart, rtr und temprose erforderlich sin, muss ich mir anschauen. Habe bisher nur den period betrachtet.
Das Ganze habe ich testweise mal imlementiert. Beispiel siehe Anhänge.
Comfortchart funktioniert auch jetzt und ohne irgendeine Anpassung schon. Der benötigt ja nur 2 AKTUELLE Werte für Temperatur und Humidity. Das muss nichts angepasst werden.
Comfortchart kannst Du weglassen, der funktioniert ja schon im Original. Super Sache, ich freue mich drauf!
Zitat von: marvin78 am 16 Februar 2015, 10:35:22
Comfortchart funktioniert auch jetzt und ohne irgendeine Anpassung schon. Der benötigt ja nur 2 AKTUELLE Werte für Temperatur und Humidity. Das muss nichts angepasst werden.
Praktisch. Arbeit gespart. :)
Temprose müsste doch auch schon funktionieren, oder?
Will ja auch nur Ist und Soll in Arrayform
Probiere es aus ;) Aber ich denke, du hast recht. Temprose sollte gehen.
Zitat von: marvin78 am 16 Februar 2015, 11:01:19
Probiere es aus ;) Aber ich denk, du hast recht. Temprose sollte gehen.
Ich habe aktuell nur zwei Thermostate im Einsatz. Da ist das Ergebnis ein wenig seltsam. ;D
Habe versucht, die Thermostaten jeweils doppelt einzubinden, aber dann stimmt für die zweiten der Wert nicht. Glaube aber nicht, dass das an FHEM bzw. Fronthem liegt. Prinzipiell zeigt er es aber an.
Zitat von: Carsten am 16 Februar 2015, 11:03:52
Ich habe aktuell nur zwei Thermostate im Einsatz. Da ist das Ergebnis ein wenig seltsam. ;D
Habe versucht, die Thermostaten jeweils doppelt einzubinden, aber dann stimmt für die zweiten der Wert nicht. Glaube aber nicht, dass das an FHEM bzw. Fronthem liegt. Prinzipiell zeigt er es aber an.
Praktisch. Noch mehr Arbeit gespart. :)
Dann sind es nur noch zwei Widgets, bei denen wir auf eigene zurückgreifen müssten. Wobei der plot.rtr auch nichts dramatisch Anderes als der period ist.
Und wenn der period ausreichend konfigureirbar wird und optional zoom vernünftig kann, dann braucht man vermutlich auch nicht viel mehr.
@hermannj: Wenn ich in Zeile 200 der fhconverter.pm
$event = $1;
durch
$event =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;
und in Zeile 212
$gadval = $1
durch
$gadval =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;
ersetze, funktionieren die Vorzeichen für NumDirect wieder. Hier scheint das RegEx also nicht korrekt in $1 zu stehen.
Hallo,
hab ein Homematic Schalter, der nicht immer zuverlässig antwortet. Der geht dann auf state MISSING ACK.
Der OnOff-Converter macht da wohl auch fälschlicherweise ein On draus.
Grüße
Tobi
@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).
Zitat von: marvin78 am 16 Februar 2015, 12:58:01
@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).
Da wäre dann ein nullable bool cool ;D ;D
Eigentlich bräuchte man noch einen Tri-State Converter + Widget
Im Grunde lässt sich das mit dem Direct-Converter doch machen. Ein Widget, dass bei mir die Alarmanlage schaltet (on,set_on,set_off,off - Kombination aus dem Keypad und einem basic.switch), war darauf sehr einfach und schnell realisiert.
Zitat von: marvin78 am 16 Februar 2015, 12:58:01
@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).
sry, hab ich nicht hingeschrieben. Das ist schon klar, dass für Produktivbetrieb die Unzuverlässigkeit weg muss.
Aber für frontHEM dacht ich, ich geb das Verhalten mal hier rein. Ein altes FS20-Relikt hatte auch An/Aus als State und da hatte der OnOff Converter nicht drauf reagiert, bis ich das Device auf On / Off umgestellt habe. Deshalb dachte ich, der Sinn des OnOff Converters ist, dass er eben nur On oder Off und sonst nichts weitergibt.
Aber wenn das Verhalten as desired ist, dann passt ja alles :)
Grüße
Tobi
Hi ftobi,
& Danke. Aber ja: ist bei Design - in der Hauptsache ist das so für die milight und hue weil die "off" und "on 100" und so etwas machen. Ich habe aber auch schon überlegt den rein auf "on" "Off" umzustellen und gleichzeitig einen regex-converter anzubieten. Den hatte Bernd mal vorgeschlagen da war mir das zu kompliziert (für den Benutzer, nicht vom programmieren). Mittlerweile denke schon das es Anwendungen dafür gibt.
Für den Schalter: ein tri-state widget an sich gibt es ja nicht aber Du könntest Dir ein basic.icon mit einem Ausrufezeichen daneben setzen und das auf "missing_ack" triggern. Dann wäre der Schalter mit "on" "off" normal belegt und im Falle des Fehler würde das Ausrufezeichen zusätzlich erscheinen. Nur so als Idee, könnte man auch mit notify.warn als dialog machen.
@marvin:
ich bin unterwegs und kann bis zum we nur umständlich testen. Mit der Regex wollte ich erreichen das auch "T: 20" als "20" erkannt wird. Wenn das so funktioniert würde ich das gern übernehmen, sonst muss ich nochmal schauen.
vg
jörg
Zitat von: herrmannj am 16 Februar 2015, 18:37:03
@marvin:
ich bin unterwegs und kann bis zum we nur umständlich testen. Mit der Regex wollte ich erreichen das auch "T: 20" als "20" erkannt wird. Wenn das so funktioniert würde ich das gern übernehmen, sonst muss ich nochmal schauen.
Dein Regex ist ja nicht falsch. Ich habe ihn ja so übernommen nur steht er offenbar nicht in $1. An der Stelle ist mir Perl aber auch (noch) zu fremd.
Zitat von: herrmannj am 16 Februar 2015, 18:37:03
ich bin unterwegs und kann bis zum we nur umständlich testen.
So geht es mir auch gerade. Aber wir haben ja auch keinen Stress ;)
Am WE schauen wir dann mal weiter ...
Wenn man als reading im gad etwas anderes als state verwendet (bspw. bState), als cmd set jedoch state, dann wird "state" auch mit dem Befehl beim Schalten übergeben. Fhem registriert in dem Fall also sowas wie
set DEVICE state on
und sagt im Log dann sowas wie
set DEVICE state on : Unknown argument state, choose one of ...
Ist das so gewollt? Ich meine, das hätte auch schon anders (besser) funktioniert. Zudem wäre es eigentlich ungemein praktisch, wenn man reading und cmd set unabhängig voneinander auch bei state verwenden könnte.
Weitere Dinge, die mir aufgefallen sind:
Treiber: Sind mit der Zeit viele Seiten im Dom, wird, bei angeschaltetem Cache und Laden der Seiten per AJAX, das aktualisieren der Gads immer träger. Das liegt vermutlich daran, dass vom Treiber zwar nur die gads aktualsiert werden, die sichtbar sind, aber per each das ganze DOM durchsucht wird. Das wird nach spätestens ab 5 Seiten unerträglich und führt sogar irgendwann dazu, dass gads gar nicht mehr aktualsiert werden, weil der Browser sie "verschluckt".
Am performantesten ist SmartVisu eigentlich ohne jeden Cache und vor allem mit data-ajax="false".
Ist es möglich, dass der Treiber bei Wiederverbindung mit FHEM auch direkt einen refresh der Widgets durchführt? SmartVisu bekommt sonst zwischenzeitliche Änderungen (von Devices die nur selten ihren Status ändern) nicht mit. Ich habe mir als Workaround die refresh Funktion folgendermaßen in die root.html geschrieben:
var myVar = setInterval(function(){ io.refreshWidgets();io.monitor();console.log("refresh")}, 100000);
Das bringt aber leider noch nichts, falls man den Cache an hat und zu einer Seite zurück wechselt, die schon im Cache ist. SmartVisu bekommt dann zwar neue Änderungen mit aber nicht alle, die zwischen Dis- und ReConnect stattgefunden haben. Auch hier muss man ohne Cache und am besten auch wieder ohne data-ajax=true arbeiten, um ein vernünftiges Ergebnis zu erzielen.
Hi,
passiert das mit set cmd = 'state' mit allen convertern ? Kann mir grad keinen Reim drauf machen und ja, das war mal besser :)
Beim cache Vorsicht bitte: der cache in den sv Einstellungen hat nichts mit dem dom zu tun. Da wird einfach das (compilierte) Ergebnis von den twig templates in sv (im dir sv/temp/) zwischengespeichert. Sprich: hat keinen Effekt auf den Inhalt von dom.
Data-ajax=false wiederum hat einen Effekt auf den Inhalt vom Dom (wird größer). Der driver geht zwar nur über $.mobile.activepage, wird aber vmtl langsamer aktualisieren weil der dom insgesamt umfangreicher ist.
Das mit dem reconnect ist natürlcih nur ein hack, lass uns das schnell wieder wegmachen, das war schon beim wvc so ein Graus :)
Trotzdem ist da was nicht koscher: soweit ich das sehe geht der driver in line 215 auch bei reconnect über "monitor". Monitor sorgt automatisch dafür das fronthem alle GAD an sv sendet (um genau die Lücke zwischen dis und reconnect zu schliessen).
Teil 2 der nicht koscher ist: das mit dem cache (im Zusammenhang mit reconnect bei Dir). Der cache (wenn wir hier über den selben sprechen) ist nur Serverseitig (!) nicht im client. Ergo kann der keinen Einfluss auf die Inhalte (in den widgets) haben - ich denk mal da klemmt was anderes.
Über welche menge GAD sprechen wir (Summe über alle Seiten ?). Magst Du mal bitte testen ob sich der domotiga driver da gleich verhält (logisch ohne den re-connect Teil).
Danke und Grüße
Jörg
Ich konnte es bei Direct und OnOff feststellen. Die anderen habe ich nicht getestet und dazu komme ich auch nicht so schnell. Es ist aber definitiv so reproduzierbar.
Der Twig-Cache hat ohnehin kaum Auswirkungen, von dem spreche ich nicht. Ich rede vom jQuery-Mobile DOM-Cache (den ich mir mitlerweile auskommentiert habe). Es ist logisch, dass die Aktualisierung der gads langsamer wird, wenn die Elemente im DOM in ihrer Zahl wachsen. Da ist es (fast) egal, ob der Driver nur über mobile.activepage geht. Der Treiber hat immer mehr "Mühe", die Elemente zu finden und dann ist es auf einmal nicht mehr egal, wie wieviele Elemente man insgesamt auf seinen Pages hat (ich spreche hier nicht von gads).
Was die nicht Aktualisierung von Widgets nach einem reconnect angeht kann ich nur Beobachtungen schildern. Hier habe ich mir den Driver nicht näher ansehen können. Ich verweile mit dem Tablet auf einer Statusseite. Dieses wird etwa 3 Stunden nicht durch Bewegung aktiviert und wenn man dann wieder davor steht, wird tatsächlich die aktuelle Seite mit allen gads aktualisiert (langsam aber sicher). Geht man mit dem Zurückbutton oder aber auch mit einem Link auf eine data-ajax=true Seite und hat den DOM-Cache an, passiert es, dass auf der aufgerufenen Seite (die man vor den 3 Stunden Pause schon einmal aufgerufen hatte) nicht alle gads aktuell sind (und auch nicht aktualisiert werden, wenn sie nicht tatsächlich einen neuen Wert erhalten - sie haben den Wert vor der Pause und nicht den, der aktuell anliegt). Besser kann ich das kaum beschreiben. Hat man data-ajax auf false und den DOM Cache aus, passiert das logischerweise nicht. Dann sieht man zwar, wie sich langsam die gads aufbauen aber das geht dann recht schnell, sodass flüssiges Arbeiten möglich ist (dank des Treibers der nicht mehr blockt).
Hallo,
mit dem aktuellen Treiber hab ich das Verhalten aus dem angehängten Video. Also alle Änderungen, seit das Tablet zugeklappt wurde, werden im Zeitraffer "nachgereicht". Könnte man jetzt als Feature bezeichnen, ist aber glaube ich nicht so gedacht ;)
Tritt bei mir nur mit Chrome auf Android 4.4 auf. Das Tablet bleibt als fronthemDevice in FHEM auch auf connected stehen.
Mit dem Domotiga-Treiber ist alles gut.
Bitte auch wieder nicht als zu lösendes Problem meinerseits behandeln, eher als Report an die Devs, die hier großartiges leisten.
Grüße
Tobi
Edith: die Originalwerte kommen mit einer Frequenz von ca. 15-20 Sekunden
Hi ftobi,
im Prinzip richtig, allerdings sollte das Verhalten bei dem domotiga und dem fhem treiber gleich sein. Wenn das Tablett sich nicht bei fronthem abmeldet (weil zugeklappt) ist für fronthem nicht zu unterscheiden ob das willentlich geschieht (Deckel) oder ob bspw WLAN unterbrochen ist (weil Störung, zu weit weg und so etwas). Daher sammelt es brav die Events für das device und wenn das device sich auf der gleichen (das macht Deins, das ist der Unterschied) Verbindung wieder meldet bekommt es alles das was es verpasst hat.
Da scheint der fhem driver noch Macken zu haben, Danke für den Report. Das Verhalten in bezug auf disconnect soll identisch zum domotiga sein.
@marvin
ich kann den Effekt nicht nachvollziehen. Es wäre schön wenn Du das strukturiert untersuchst. Am PC kannst Du bei aktivierter console (im browser) genau sehen was der driver macht, dann sehen wir auch wo die events verloren gehen (sich überholen)
vielen Dank, vg
jörg
@Jörg: hast Du meinen PR im Fronthem Git mitbekommen bzgl. Schnellsuche im GAD-Editor? Ich nutze das nun schon einige Tage und finde es eine große Hilfe...
Zitat von: herrmannj am 18 Februar 2015, 16:37:57
@marvin
ich kann den Effekt nicht nachvollziehen. Es wäre schön wenn Du das strukturiert untersuchst. Am PC kannst Du bei aktivierter console (im browser) genau sehen was der driver macht, dann sehen wir auch wo die events verloren gehen (sich überholen)
Ja das sehe ich. es hat bloß nicht immer mit dem zu tun, was auf dem Bildschirm tatsächlich stattfindet. Zudem habe ich den Effekt nicht am PC. Die Console gibt es aber am Tablet nicht. Ich habe mir beispielsweise eine Javascript-Funktion gebaut, die mir bestimmte Werte einfärbt. Es kommt nun vor, dass das einfärben tatsächlich funktioniert der Wert aber als --- dargestellt wird.
Das ist aber auch nicht das wirklich wichtige an meinem Beitrag. Wichtiger ist die Sache mit dem state.
Zitat von: bgewehr am 18 Februar 2015, 18:21:56
@Jörg: hast Du meinen PR im Fronthem Git mitbekommen bzgl. Schnellsuche im GAD-Editor? Ich nutze das nun schon einige Tage und finde es eine große Hilfe...
Ja hab ich, sorry wollt Dich da auch schon callen. Bin im Augenblick unterwegs und wollt mir das anschauen bevor ich das übernehme weil es doch recht zentral ist - ich komm erst am we dazu.
btw: den fronthemUtils habe ich übernommen, würde aber vorschlagen das "use json" aus dem namespace fhconverter raus zunehmen. Ohne das getestet zu haben: die ganzen Routinen aus dem JSON package müssten jetzt bei Dir als converter erscheinen (im autocomplete) weil die damit in dem namespace liegen. (richtig ?)
Wenn ja: besser oben im main importieren und aus dem converter einen call nach main::was_auch_immer. In "was_auch_immer" müsste dann das JSON decode stattfinden und als return durchgereicht werden.
vg
jörg
Zitat von: marvin78 am 18 Februar 2015, 19:56:17
Das ist aber auch nicht das wirklich wichtige an meinem Beitrag. Wichtiger ist die Sache mit dem state.
Yepp, ich hab mir das gestern am code angeschaut aber keine naheliegende Erklärung gefunden. Muss ich mir leider auch am we am lebenden objekt anschauen, mach ich heil.
Zu dem driver, wenn das einfärben klappt der Wert aber nicht gesetzt wird, dann kommt er ja in sv an, liegt vielleicht außerhalb des drivers ? Müsstest Du selber einmal jagen, bitte.
vg
jörg
Zitat von: herrmannj am 18 Februar 2015, 20:19:31
1) Ja hab ich, sorry wollt Dich da auch schon callen. Bin im Augenblick unterwegs und wollt mir das anschauen bevor ich das übernehme weil es doch recht zentral ist - ich komm erst am we dazu.
2) Ohne das getestet zu haben: die ganzen Routinen aus dem JSON package müssten jetzt bei Dir als converter erscheinen (im autocomplete) weil die damit in dem namespace liegen. (richtig ?)
3) Wenn ja: besser oben im main importieren und aus dem converter einen call nach main::was_auch_immer. In "was_auch_immer" müsste dann das JSON decode stattfinden und als return durchgereicht werden.
1) ok, bin gespannt, was Du dazu sagst
2) stimmt, das stört!
3) schaue ich mir an!
gute Reise!
Gesendet von meinem iPad mit Tapatalk
Ich lese so nebenbei mit,bin aber erst am WE wieder in der Lage, mir das genauer anzuschauen. Bis da hin bitte etwas Geduld und am Besten experimentierten und Infos sammeln.
@Jörg: meinst Du sowas:
package main;
use JSON;
sub decodejson($) {
return decode_json(@_);
}
was dann hier verwendet wird:
package fronthem;
{
$param->{gad} = $gad;
$param->{gadval} = main::decodejson(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
return undef;
}
Klappt irgendwie noch nicht so richtig...
das sieht soweit gut aus. Versuch mal aus
sub decodejson($) {
return decode_json(@_);
}
das:
sub decodejson($) {
return decode_json($_[0]);
}
Und vielleicht einen längeren sub Namen (zB myfhutils_decodejson) um Konflikte mit anderen Modulen zu vermeiden. (Das ist der gleiche namespace in dem all fhem, alle module und alle helper sind).
Btw, teste auch mal Umlaute. Das issue mit den UTF8 Umlauten lag in der Verwendung von to_JSON vs. encode_JSON. Abhängig davon wie der input ist (shit komplex - da gehts um utf8 Charakterstream vs UTF8 bytestream, ich geh nicht weiter ins detail) konvertiert jeweils einer von beiden falsch, bzw fhem stürzt komplett ab. Insgesamt hab e ich festgestellt ist es daher eine gute Idee das xxxJSON in ein eval zu packen.
vg
jörg
Zitat von: herrmannj am 18 Februar 2015, 23:28:06
sub decodejson($) {
return decode_json($_[0]);
}
Btw, teste auch mal Umlaute.
So, das funktioniert nun korrekt!
https://github.com/bgewehr/fronthem-1/commit/dbc3f54ddee3ff0416076d97546e14728d5c74c6#diff-46b6826e5550b920b097b5caf2de66e9R42
Umlaute:
Scheint bei mir zu gehen, ich muss noch einen Härtefall generieren... ü ist schon mal richtig...
Wäre es möglich eine Funktion im FronthemDevice zu implementieren, die alle nicht gesetzten GADs in FHEM zu diesem Zeitpunkt löscht oder gibt es die eventuell schon?
Quasi für den Fall, dass man eine andere Page in SV aufgerufen hat, aber den Treiber in FHEM nicht deaktiviert hat.
Oder gibt es einen einfachen Weg die GADs zu löschen?
Beste Grüße
Fabian
Zitat von: bgewehr am 19 Februar 2015, 08:44:06
So, das funktioniert nun korrekt!
https://github.com/bgewehr/fronthem-1/commit/dbc3f54ddee3ff0416076d97546e14728d5c74c6#diff-46b6826e5550b920b097b5caf2de66e9R42
Umlaute:
Scheint bei mir zu gehen, ich muss noch einen Härtefall generieren... ü ist schon mal richtig...
oh schön. (Aus dem Kopf) müsste "decode" an der Stelle auch richtig sein.
vg
jörg
Zitat von: Pythonf am 19 Februar 2015, 18:32:30
Wäre es möglich eine Funktion im FronthemDevice zu implementieren, die alle nicht gesetzten GADs in FHEM zu diesem Zeitpunkt löscht oder gibt es die eventuell schon?
Quasi für den Fall, dass man eine andere Page in SV aufgerufen hat, aber den Treiber in FHEM nicht deaktiviert hat.
Oder gibt es einen einfachen Weg die GADs zu löschen?
Beste Grüße
Fabian
Da existiert noch nichts. Ich bin mir auch nicht sicher ob das der richtige Weg wäre - weil: fronthem kennt nur die GAD der aktuellen Seite. Du möchtest aber vmtl eher die GAD des aktuellen Page-Dir. Mittelfristig möchte ich den editor dahin erweitern das er einen Filter so wie in Excel bekommt wo man bspw auf alle GAD filtern kann wo kein device hinterlegt ist. Dort soll man dann entweder per Ankreuzfeld (oder einem icon) direct aus der Liste löschen.
Das würde wahrscheinlich besser zum angestrebten Ergebnis passen - oder ?
vg
jörg
Das klingt nach einer guten und deutlich praktikableren Idee, als mein Vorschlag
Hallo zusammmen,
es läuft und läuft bin sehr happy mit smartvisu in verbindung mit fronthem. :)
Allerdings habe ich ein neues Problem zu dem ich momentan keine Lösung finde, un zwar hatte ich in der vergangenheit schon probleme meine Dimmbaren Lampen einzubinden aufgrund meines setups da ich intertechno dimmer mittels eines rfxtrx steuere und da sind die befehle leider ganz anders denn es gibt lediglich 15 dimmstufen die über den befehl "level x" gesteuert werden, Ein- und Ausschalten wird per on/off umgesetzt (An geht auch mit "level x"). Es sei angemerkt das bei mir auch level 0 nicht aus sondern eben die dimmstufe 0, schwächstes licht ist, und doppelt on kurz hinternander startet bei der lampe einen manuellen dimmodus.
Also habe ich bisher folgende lösung funktionierend im einsatz gehabt ich habe 2 basic.buttons für An/Aus definiert wobei der anschalter einfach nur zB. "6" als value übergeben hat an das value-gad das habe ich dann mit "state - numdirect - level" definiert und darunter einen einfachen slider (mit 15 stufen) der auch am value-gad hängt. Wenn ich nun eingeschaltet habe wurden die lampen stets im dimm modus "level 6" Eingeschaltet (slider wurde auch auf 6 gesetzt), und Ausgeschaltet habe ich das ganze über den 2 basic button der als value "off" übergeben hat ans switch-gad das in fronthem wie folgt definiert ist "state - direct - state" funktionierte in meinem fall wunderbar (bei off befehl - slider wurde auch auf 0 gesetzt) bis vor ein paar tagen wo ich ein update von fronthem gemacht habe ohne sicherheitskopien zu machen (ja ich weiss doof) denn seitdem habe ich das verhalten das bei "off" mein slider nicht mehr auf null gesetzt wird sondern in seinem letzten state verweilt, funktionieren an sich tut es also die lampen werden auch geschaltet nur der slider in smartvisu bleibt eben auf seinem letzem state stehen weil der numdirect converter seitdem update auch ganz richtig nichts mehr mit dem off befehl anfangen kann. Im log kann ich dann auch richtig lesen das der numdirect converter nichts mit dem off befehl anfangen kann weil es kein numerischer wert ist, vor dem update erschien der eintrag im log auch nicht daher vermute ich das es mit dem update zusammenhängt.
Jetzt weiss ich nur nicht mehr wie ich das in smartvisu bzw. fronthem definieren soll, da ja grundsätzlich alles richtig funktioniert nur eben der slider bei off nicht mehr reagiert. Hat da jemand einen Tipp wie ich das hinkriege?
vg
Ich verstehe nicht ganz, was du tust.
Das Read-Property für den Level-GAD ist state und das Write-Property ist level? Kannst du nicht einfach level auch für Read nehmen?
Alternativ könntest du dir ein Userdefined-Reading hinzufügen, in das du über Notifys etc. immer nur den aktuellen Level reinschreibst.
Als Beispiel kannst du dir mal die Timecounterlösung von Bernd anschauen: https://github.com/herrmannj/smartvisu-widgets/tree/master/timecounter
Hallo,
ich bin gerade dabei mein Fhem und fronthem updzudaten. Den Fhem hat er ohne Probleme geupdate aber wenn ich den Fronthem mit update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt updaten möchte bekomme ich immer nur
RMDIR: ./restoreDir/2014-10-15
RMDIR: ./restoreDir/2014-10-17
RMDIR: ./restoreDir/2014-11-01
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
UPD FHEM/fhwebsocket.pm
UPD FHEM/fhconverter.pm
UPD www/pgm2/fronthemEditor.js
UPD www/images/default/arrow-down.svg
UPD www/images/default/arrow-up.svg
UPD www/images/default/desktop.svg
New entries in the CHANGED file:
2015-01-18
- minor typo: thx fhainz
update finished, "shutdown restart" is needed to activate the changes.
fheminfo server response: ==> ok
wenn ich dann shutdown restart durchführe und danach wieder auf Updates prüfe kommt die selbe Meldung. Im Logfile taucht diese Meldung ebenfalls auf aber mehr nicht. Das System läuft auf einem Raps. mit Whezzy.
Was mache ich falsch? Rechte habe ich überprüft die stehen auf root und fhem 755.
Vielen Dank.
grüße
sebinger
Ist der Force-Parameter nicht genau dafür da, unabhängig von der Version immer ALLES upzudaten?
Genau das passiert ja scheinbar auch, oder?
Lösung: Hör auf updzudaten bis es wieder Updates gibt ;D
Hast du denn mal geschaut, ob du die aktuellste Version hast?
ja genau das ist ja mein Problem :-) es ist eben nicht die aktuelle Version er möchte die Versionen von 18.01. einspielen mittlerweile gibt es aber schon Versionen vom 13.02. somit bin ich nicht aktuell :-).
Zitat von: sebinger18 am 20 Februar 2015, 14:51:52
ja genau das ist ja mein Problem :-) es ist eben nicht die aktuelle Version er möchte die Versionen von 18.01. einspielen mittlerweile gibt es aber schon Versionen vom 13.02. somit bin ich nicht aktuell :-).
Nach meinem Verständnis bedeutet das nur, dass es nicht mehr Releasenotes (hab allerdings keine Ahnung, wo die herkommen) als die vom 18.01. gibt.
Hast du mal geschaut, ob die Dateien (z.B. 01_fronthem.pm ) aktuell sind?
Oder mal ein
update check https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt machen
also des update check hate ich vorher schon durch geführt, da kam nothing to do und die 01_fronthem.pm ist vom 13.02. ok die scheint aktuelle zu sein. mich hat halt verwirrt das er jedes mal sagt das diese Dateien aktualisiert wurden, aber da hast du natürlich vollkommen recht, wenn der update force Befehl immer alles updatet. Gut aber dann ist ja alles i.o. Vielen Dank.
Alles ok, ich hab nur uns changelog nichts eingetragen
Vg
Jörg
ich bin gerade dran das bei meinem HM Thermostat auch der Ladestand von der Batterie angezeigt wird. Nun habe ich im Forum gelesen das Bernd den fehlhaften Basic.Shifter angepasst hat, nur konnte ich bis jetzt nicht finden in welcher Datei das ist. Könnt ihr mir das sagen?
Vielen Dank.
Grüße
sebinger
basic.html im widgets Ordner!
super danke, hat sofort funktioniert.
Hallo Bernd,
mal eine Frage zum Basic Shifter.
Funktioniert bei dir der angegebene Minimalwert?
Bei mir nicht.
Als Minimalwert im hm widget habe ich 2,1 angegeben, als Maxwert 3.
Das Batterieicon nimmt hier die 2,1 nicht als Minimalwert sondern 0. Setze ich mit einem zusätzlichen Slider oder Shifter den Wert des GADs auf 2,1 wird das Batterieicon als fast voll angezeigt, gehe ich gegen null wird das Icon leer.
Gruß
Steven
Nimm 2.1 !
Entschuldige, dort steht natürlich 2.1
Habe es hier nur falsch gepostet.
Haben ihr diesen Fehler auch?
Also im widget steht ja
{{ basic.shifter(id~'battery', '', gad_battery, 'icon.battery', '2.2', '3') }}
Und so läuft das auch bei mir.
Ich habe es so angebunden:
Habe mich doch entschlossen, eine Reihe Quickbuttons über dem Grid zu platzieren, das spart Nerven beim Öffnen der Garage...
Ich rede nicht von der Anbindung.
Ohne Anbindung einen zusätzlichen Shifter oder Slider erstellen, der das Batterie_gad auf dem hm widget ändert.
Dabei fällt auf das 2.1 oder 2.2 nicht als Minimalwert für die Anzeige des dynamischen Icons dargestellt wird.
Mein Frage ist ob du das schon festgestellt hast oder das mal testen kannst.
Auf eine leere Batteriewert den fhem liefert wollte ich nicht warten...
Wie fällt Dir das denn auf?
Indem ich mit einem slider den Wert für das Batterieicon ändere.
{{ basic.slider('slider2', 'bath_light_value', 0, 3, 0.1) }}
'bath_light_value' muss in dem Fall mit dem Battery_Gad übereinstimmen...
Ich setze immer alle Parameter in Anführungszeichen...
0 ist der min Wert des Sliders
3 der max Wert
0.1 der Wert des steps
und wird laut Doku nicht in Anführungszeichen gesetzt.
Ich habe es damit nachvollzogen... Aber lassen wir das einfach...
OK!
Ich habe gesagt, dass etwas mit dem basic shifter fix bzw. mit der Anzeige des Batterie Icons nicht stimmt. Ich habe auch aufgezeigt wie man es nachstellen kann bzw. wie es mir aufgefallen ist.
Die Frage war, ob es bei euch auch so ist?
Das hat nichts mit Fronthem Anbindung bzw. oder fehlerhaftes anlegen von Widgets in smartVISU zu tun, sondern betrifft m.E. den Basic. Shifter fix bzw. nur smartVISU...
Ja. Auch mit "fix" kann der shifter als Minimalwert nur 0. Wenn man sich das JS ansieht, sieht man auch warum. Entweder macht man also einen weiteren Fix oder man nimmt den Workaround userReading (macht das ganze ohnehin schöner - ich würde es persönlich gar nicht als Workaround sondern als bessere Lösung sehen). Das hat schonmal jemand hier im Thread vorgestellt. Damit wird der absolute Batteriewert in einen relativen Wert umgesetzt. Ich habe aber gerade wenig Lust hier in dem ewig langen Thread rumzusuchen.
BTW: Anführungszeichen sind bei Zahlenwerten völlig überflüssig.
Zitat von: karl0123 am 08 Januar 2015, 17:00:20
Da ein Thermostatwidget mit einem basic.shifter für die absoluten Batteriewerte eines Homematic Thermostats nicht wirklich funktioniert (der Min-Wert wird gar nicht wirklich verwendet), habe ich mir ein User Reading in jeden Thermostat gepackt, dass den relativen Wert berechnet. Damit klappt die Batterieanzeige dann auch sehr gut:
batteryRel {batteryRel(ReadingsVal($name,'R-lowBatLimitRT','2.1'),3,ReadingsVal($name,'batteryLevel',3))}
Dazu zwei subs in einer myUtils:
### Float auf x Nachkommastellen runden
sub round
{
my $zahl=shift;
my $stelle=shift;
my $zz=$zahl+0;
if($zz=~/^.+?\.\d{$stelle}/)
{
$zz=~s/^.+?\.\d{$stelle}/'0.'.('0'x$stelle)/e;
$zahl+=$zz;
$zahl=~s/^(.+?\.\d{$stelle}).*$/$1/;
}
$zahl=sprintf("%.$stelle"."f",$zahl);
return $zahl;
}
## Relaiven Batterie-Wert zurück geben
sub batteryRel($$$) {
my ($min,$max,$val) = @_;
my $newVal=$val-$min;
if ($newVal>0) {
my $ret=$newVal/($max-$min)*100;
return round($ret,0)
}
return 0;
}
Dann noch im Widget min auf 0 und max auf 100 setzen und die Batterieanzeige liefert ein gutes Bild.
Ich gucke es mir bei Gelegenheit mal an. Scheint ja noch relativ am Anfang des Thread s gewesen zu sein. Habe ich wohl überlesen.
Danke Marvin
Kannst du das mit dem JS mal genauer erklären... Wo muss ich da gucken.?
Zitat von: fidel am 20 Februar 2015, 21:51:25
Ich gucke es mir bei Gelegenheit mal an. Scheint ja noch relativ am Anfang des Thread s gewesen zu sein. Habe ich wohl überlesen.
Brauchste ja nicht, hab's ja noch schnell gefunden und zitiert ;)
Zitat von: fidel am 20 Februar 2015, 21:51:25
Kannst du das mit dem JS mal genauer erklären... Wo muss ich da gucken.?
In der widget.js.
@Marvin: hast Du da den Fehler gefunden? Dann lass hören...
Nun. Siehst du irgendwo in der shifter Funktion, dass der "data-min" Wert ausgelesen wird? Wird er nicht, weil er zur Berechnung gar nicht verwendet wird (warum auch immer!?). Min-Wert ist immer 0. Ich habe jedoch keinen Fix dafür geschrieben, da ich die Lösung mit relativen Werten viel eleganter finde.
Zitat von: marvin78 am 20 Februar 2015, 22:11:12
Nun. Siehst du irgendwo in der shifter Funktion, dass der "data-min" Wert ausgelesen wird? Wird er nicht, weil er zur Berechnung gar nicht verwendet wird (warum auch immer!?). Min-Wert ist immer 0. Ich habe jedoch keinen Fix dafür geschrieben, da ich die Lösung mit relativen Werten viel eleganter finde.
Finde ich nicht unbedingt, da der min wert bei einigen widgets laut doku angegeben werden kann (dort steht ja for future use). Warum den umweg über fhem gehen, wenn smartVISU es selbst könnte...
Na. SmartVISU kann es aber nicht. ;)
Zitat von: marvin78 am 20 Februar 2015, 23:19:21
Na. SmartVISU kann es aber nicht. ;)
Max Wert schon, warum min nicht?
Das hab ich oben geschrieben. Der wird von der Funktion ignoriert.
Eigentlich ist das hier auch das falsche Thema für diese Diskussion.
Also, dieses icon.battery Script für die widget.js macht das dann schon mal richtig. Der Shifter mag aber noch nicht so recht...
// ----- icon.battery ---------------------------------------------------------
$(document).delegate('svg[data-widget="icon.battery"]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}
var val = Math.round((response[0] - $(this).attr('data-min')) / ($(this).attr('data-max') - $(this).attr('data-min')) * 40);
fx.grid(this, val, [39, 68], [61, 28]);
}
});
Zitat von: marvin78 am 20 Februar 2015, 23:42:25
Das hab ich oben geschrieben. Der wird von der Funktion ignoriert.
Eigentlich ist das hier auch das falsche Thema für diese Diskussion.
Wollen wir ein eigenen Thread dafür aufmachen?
Vielleicht würde es sich anbieten zum Thema Fronthem und Smartvisu einen eigenen Bereich im Forum einzurichten. Da könnte man dann leichter finden was man sucht und es entstehen wahrscheinlich mehrer Threads für einzelne Probleme und nicht ein oder zwei sehr lange.
Beste Grüße
Fabian
Jetzt muss ich mich leider auch nochmal melden.
Ich habe - ab und an - das Problem wenn ich von den einzelnen Räumen wieder auf die Hauptseite schalte (oben links, den Home Button) werden mir dort keine GAD's angezeigt (siehe Anhang!). Manchmal wird dann auch kein Wetter angezeigt.
Wenn ich dann dort den Browser per F5 aktualisiere läuft wieder alles - nur leider würde ich gerne einen Fullscreen browser auf dem Tablet nutzen - ergo keine Möglichkeit die Seite so zu aktualisieren.
Lässt sich irgendwas einbauen damit, falls man den Home Button drückt, automatisch die Seite reloaded wird?
Vielen Dank,
Olli
Moin,
ja die gibt es. Hatte glaube ich HCS vor nicht allzu langer Zeit hier gepostet. Bei mir sieht s dann so aus...
edit:
http://forum.fhem.de/index.php?topic=30909.msg260676.msg#260676
Gruß
Steven
Welches icon ist das denn?
Ein angepasstes icon aus fhem namens refresh.svg
Ich kann es ja hier mal bereit stellen.
Ah, schade, gefällt mir nämlich besser als das, das ich genommen habe.
Edit:
Zitat von: fidel am 21 Februar 2015, 08:10:51
Ich kann es ja hier mal bereit stellen.
Ja, wäre nett.
Zitat von: HCS am 21 Februar 2015, 08:12:29
Ah, schade, gefällt mir nämlich besser als das, das ich genommen habe.
Mir auch ;)
Ich habe gleich noch zusätzlich die pngs in alle Farben gepackt.
gleichzeitig sollten wir da die Ursache finden, am besten systematisch.
Wenn das auch beim Wetter passiert (was ja nix mit dem driver zu tun hat) - dann stimmt was IN sv nicht - oder wie seht Ihr das ?
vg
jörg
Ich habe ein Problem mit den Umlauten in SV...
widget_txtreplace.html befindet sich in meinem pages-Verzeichnis und auch die visu.js im selben Verzeichnis habe ich ergänzt...
Leider findet keine Umwandlung statt.
Habe ich noch was vergessen ?
Schönes WE!
Kai
Zitat von: fidel am 21 Februar 2015, 00:11:13
Wollen wir ein eigenen Thread dafür aufmachen?
Ich packe das optimierte Widget ins GIT, dann können wir dort weiter diskutieren!
Zitat von: kumue am 21 Februar 2015, 10:57:59
Ich habe ein Problem mit den Umlauten in SV...
widget_txtreplace.html befindet sich in meinem pages-Verzeichnis und auch die visu.js im selben Verzeichnis habe ich ergänzt...
Leider findet keine Umwandlung statt.
Habe ich noch was vergessen ?
Schmeiß das widget weg, die aktuelle fronthem Version macht das von selber richtig!
Zum basic.shifter: nehmt für die Batterieanzeige einfach den icon.battery aus dem widgets-Git, der macht das dann richtig. Der shifter geht mit dynamischen svg Icons nicht, weil die Twig Attribute Funktion buggy ist. Egal, die icon.* machen das Gleiche!
@kumue: nur Dateien irgendwo hinzulegen, reicht nicht, Du musst die macros darin in Deinen SV-Seiten benutzen. (Nur falls Du da noch rätselst..) also müsste das textreplace widget auch irgendwo in Deinen Seiten benutzt werden, damit was passiert. Dennoch: für Umlaute braucht es keine widgets mehr, fronthem aktuell hat bei mir alles richtig gemacht.
Zitat von: olli84 am 21 Februar 2015, 07:34:11
Ich habe - ab und an - das Problem wenn ich von den einzelnen Räumen wieder auf die Hauptseite schalte (oben links, den Home Button) werden mir dort keine GAD's angezeigt (siehe Anhang!). Manchmal wird dann auch kein Wetter angezeigt.
Wenn ich dann dort den Browser per F5 aktualisiere läuft wieder alles - nur leider würde ich gerne einen Fullscreen browser auf dem Tablet nutzen - ergo keine Möglichkeit die Seite so zu aktualisieren.
Lässt sich irgendwas einbauen damit, falls man den Home Button drückt, automatisch die Seite reloaded wird?
Meine Beobachtung dazu: solange mein gespeicherter Link nur http://IP/smartVISU war, habe ich auch diesen Effekt gehabt.
Nachdem ich den gespeicherten Link NACH dem ersten Aufruf der Index.php gespeichert hatte, lief das perfekt!
ZitatSchmeiß das widget weg, die aktuelle fronthem Version macht das von selber richtig!
@bgewehr:
Hat geholfen.
Danke auch für den Hinweis zu Macros...
Gruß Kai
Zitat von: bgewehr am 21 Februar 2015, 12:46:33
Meine Beobachtung dazu: solange mein gespeicherter Link nur http://IP/smartVISU war, habe ich auch diesen Effekt gehabt.
Nachdem ich den gespeicherten Link NACH dem ersten Aufruf der Index.php gespeichert hatte, lief das perfekt!
Hi,
ich verstehe nicht ganz, wie du das meinst. Heißt das, statt auf http://server/smartVISU steigst du jetzt immer direkt auf http://server/smartVISU/index.php ein?
Ja, genau!
Zitat von: bgewehr am 20 Februar 2015, 19:43:36
Habe mich doch entschlossen, eine Reihe Quickbuttons über dem Grid zu platzieren, das spart Nerven beim Öffnen der Garage...
Das gefällt mir, sieht gut aus!
schöne Grüße
Jo
Zitat von: bgewehr am 20 Februar 2015, 19:43:36
Habe mich doch entschlossen, eine Reihe Quickbuttons über dem Grid zu platzieren, das spart Nerven beim Öffnen der Garage...
Das gefällt mir, sieht gut aus!
schöne Grüße
Jo
Zitat von: bgewehr am 20 Februar 2015, 19:43:36
Habe mich doch entschlossen, eine Reihe Quickbuttons über dem Grid zu platzieren, das spart Nerven beim Öffnen der Garage...
Das gefällt mir, sieht gut aus!
schöne Grüße
Jo
Edith: tapatalk ist auch nicht mehr das, was es mal war >:(
Zitat von: bgewehr am 22 Februar 2015, 14:08:01
Ja, genau!
mach ich auch. Hat sich so ergeben ... witzig das es einen Unterschied macht ?
vg
jörg
Der Filter in der GAD-Liste ist praktisch, aber leider habe ich beim dark style schwarze Schrift auf schwarzem Grund = unsichtbar.
css - Thema, kannst Du eine Verbesserung erstellen?
Gesendet von meinem iPad mit Tapatalk
Der
style="color: rgb(0, 0, 0);"
würde nicht da nicht hin gehören
Edit: ich meinte "würde nicht da hin gehören"
Doppelt negiert war es dann doch falsch :D
Zitat von: marvin78 am 17 Februar 2015, 22:05:04
Ist es möglich, dass der Treiber bei Wiederverbindung mit FHEM auch direkt einen refresh der Widgets durchführt?
Das funktioniert bei mir wie gewünscht. Nach einem restart von FHEM werden die Werte nach Ablauf des Timers bei einem erfolgreichen reconnect sofort aktualisiert.
Zitat von: marvin78 am 17 Februar 2015, 22:05:04
Treiber: Sind mit der Zeit viele Seiten im Dom, wird, bei angeschaltetem Cache und Laden der Seiten per AJAX, das aktualisieren der Gads immer träger. Das liegt vermutlich daran, dass vom Treiber zwar nur die gads aktualsiert werden, die sichtbar sind, aber per each das ganze DOM durchsucht wird. Das wird nach spätestens ab 5 Seiten unerträglich und führt sogar irgendwann dazu, dass gads gar nicht mehr aktualsiert werden, weil der Browser sie "verschluckt".
Am performantesten ist SmartVisu eigentlich ohne jeden Cache und vor allem mit data-ajax="false".
Kann ich leider nicht nachvollziehen.
Ich teste auf einem betagten Android 4.2.1 Tablet (Tegra 3 mit 1,3GHz) mit einer Chrome Web-App
Pagecache in SV ist an, jquery DOM-cache auch und data-ajax ist true
Ich navigiere durch alle meine pages hin und her (incl. der 300 GADs Test-page), ohne dass sich die Geschwindigkeit ändert. Bei Rückkehr auf eine page werden die GADs sofort mit den aktuellen Werten aus FHEM aktualisiert.
SV ist eine originale unveränderte Installation (nicht die Mandantenfähige)
Server ist ein CubieTruck, WebServer lighttpd
Auf dem Nexus 5 mit Android 5.0.1 in einer Chrom Web-App ist das auch so, nur schneller und auf dem Laptop sowieso.
Jetzt müssen wir irgendwie herausfinden, wo die Unterschiede sind.
Ich wollte eh noch den Test-Treiber zum Messen fertig machen. Evtl. kann ich dem noch einbauen, dass er die Zeiten der jquery selectors misst, dass wir mal sehen, ob es überhaupt von da kommt.
Ich teste es mit Nexus 5, Samsung Galaxy Note 2014 10.1 (also sehr schnell) und Laptop. Server ist ein Intel NUC i5. Webserver ist nginx. Apache wurde auch probiert. Der Unterschied ist maximal marginal. Netzwerk ist Gigabit LAN, Wlan n und ac. SmartVisu ist die mandantenfähige Version (ich glaube nicht, dass hier der Unterschied liegt).
Mache ich alles an (data-ajax,DOM-Cache, Twig-Cache (wobei der, wie gesagt, zu vernachlässigen ist)), kann ich das beschriebene Verhalten auf allen Devices reproduzieren. Das Maß ist natürlich immer ein anderes. Ich rede hier übrigens jeweils über den ersten Aufruf der Seiten(n).
Dabei ist zu sagen, dass ich sehr viele gads (etwa 60-70!?) und dementsprechend auch Elemente im Menü habe. Ist der DOM-Cache an, liegen unter umständen bei 10 Seiten 10 Menüs im DOM. Vielleicht macht das den Unterschied!? Fakt ist, dass jQuery each nicht sehr schnell ist. Ich habe das mal Testweise im Treiber durch for ersetzt und dachte zunächst, es würde sich bessern. Wirklich viel brachte das aber nicht. Ich habe dann auch festgestellt, dass das Durchsuchen des DOM gar nicht so lange dauert aber das Aktualisieren dann ewig. Das sieht man auch in der Konsole.
Das mit dem Menü ist übrigens, meiner Ansicht nach, ein klares Defizit von SmartVisu. Besser wäre es, wenn nur der primary Block per AJAX aktualisiert würde. Ich habe schon Versuche gemacht, das anders umzusetzen aber Twig macht mir da einen Strich durch die Rechnung.
Auch das reine Aktualisieren der gads (auf der ersten aller Seiten) geht insgesamt bei mir recht langsam von statten ( für mein Empfinden in Zeitlupe). Ich kann ein Performance-Problem bei mir anhand keines anderes Tools nachvollziehen. Ich habe auf dem selben Server eine umfangreiche Webapplikation auf Grundlage von Yii laufen die eine sehr gute Performance zeigt. Auch dort werden teilweise Websockets verwendet. Das zeigt mir, dass es nicht an meiner Umgebung liegt. Auch bei FHEM, welches auch auf dem selben Server liegt, gibt es auch nach Analyse mit apptime keinerlei Probleme. Alles "fluppt" wie geschmiert.
Ich würde doch gerne mal ein Video sehen, wie das normalerweise aussehen müsste oder ob ich einfach verwöhnt bin...
Ich lasse mal ein Kamerateam kommen. 8)
Messwerte beziehen sich auf das oben beschriebene Tablet.
Habe gerade einige Messungen gemacht. Die bestätigen Deine Beobachtung. Die selects auf dem dom und die Schleife über das Ergebnis brauchen kaum Zeit (ca. 3ms).
Die Zeit bis der
$(this).trigger('update', [values]);
wieder zurück kommt ist erheblich, das sind pro GAD zwischen 60 und 100 ms
Und genau da wird es blöd. Da laufen all die individuellen update routinen, die in der widget.js für die widgets implementiert sind. Und natürlich die der selbst gebastelten widgets. Gegen die hat man (außer sie zu optimieren) nichts in der Hand, außer es responsive im Hintergrund zu machen.
Ich muss mal noch messen, ob der trigger Aufruf selbst schon so langsam ist oder ob das wirklich die widget update routinen sind.
Aber beim Überfliegen habe ich schon einige gesehen, die unötig oft den DOM immer wieder das Gleiche fragen.
Das sieht ganz nach den eventhandlern mit selectoren aus, die alle an document gehängt sind.
Das ist wohl nicht unbedingt schnell.
Wenn ich testweise im update delegate des basic.float einfach nichts mache, sind die Zeiten kaum besser.
Eigentlich auch logisch, die widgets sind schon recht weit unten, das event muss den ganzen Pfad im DOM hoch bubbeln und ein selector um die events zu filtern ist da auch noch drauf.
Ja, die jquery-Doku sagt es auch:
ZitatAttaching many delegated event handlers near the top of the document tree can degrade performance. Each time the event occurs, jQuery must compare all selectors of all attached events of that type to every element in the path from the event target up to the top of the document. For best performance, attach delegated events at a document location as close as possible to the target elements. Avoid excessive use of document or document.body for delegated events on large documents.
Da habe ich mir einen schönen Mist angelacht. Das liegt weit außerhalb des Treibers. Das ist ein generelles SV-Konzept-Topic.
Und dann hängt es wohl nun auch mit davon ab, ob man viele verscheidene widgets hat oder nicht. Und wie tief unten man mit den widgets ist, und, und, und.
Das erklärt auch ein Stück weit die unterschiedlichen Antwortzeiten.
Wenn das dann mit zunehmender Datenmenge evtl. noch logarithmisch abbaut, ...
Falls jemand die geniale Idee hat, was nun angesagt wäre, dann her damit.
Falls jemand das hier widerlegen kann dann auch her damit.
Gute Nacht ...
Meine Idee hatte ich oben kurz angerissen. Das steht aber dem zugrundleliegenden jQuery-Mobile Konzept entgegen und wäre, selbst, wenn man es umgegssetzt bekäme, nicht updatesicher. Es wäre hilfreich, wenn das Menü nicht jede Mal neu geladen werden müsste, ein Klickt auf einen Menüpunkt aber nur der Inhalt des primary-Blocks aktualisiert. Erste Versuche dazu mit ajaxload und get hatte ich gestern gemacht (ziemlich erfolglos). Hier müsste man wohl die index.php komplett umschreiben bzw. anders gestalten. Leider komme ich mit dem Twig-Konzept in der Tiefe bisher noch überhaupt nicht zurecht und ich habe auch viel zu wenig Zeit, um mich zeitnah noch intensiver damit zu beschäftigen.
Das würde aber auch nur die Symptome lindern (wie das Nonblocking auch) aber nicht das eigentliche Problem beseitigen.
die 100ms decken sich mit meinen Messungen recht gut. Und ja, das liegt in sv. Deswegen wundern mich auch marvins Points ein wenig. Sv funktioniert ja ja soweit (mit dieser Struktur) auch weit über fhem hinaus.
@hcs: ich schau mal ob ich mit dem caching thema was erreichen kann. Idee ist es sich die selector und each Läufe zu sparen in dem das widget selbst gecachet wird, also "update" für den driver erreichbar ist ohne über selectoren und each zu gehen.
@marvin: ich finde jetzt Deine 60-70 GADs nicht soviel. Entweder Deine Erwartungshaltung unterscheidet sich oder da ist noch was anderes. Bitte sei doch so nett und mach echt mal Messungen, an die widget Farbe etc bist Du ja auch rangegangen. Oder anders: schau doch mal ob sich ein jungräuliches sv dir gleich verhält. Dazu könntest Du in einen jungfräulichen Verzeichnis (wichtig ohne eigene visu.js und so) widgets (GAD) mit den Namen internal.0, internal.1 usw anlegen - fronthem bedient die automatisch ohne das Du was im Editor einstellen musst.
@Bernd: Danke für die Korrektur in fronthem_controls :)
vg
jörg
Also, klar könnte immer alles noch schneller sein, aber ich finde es mit caching schon recht gut! Ist sicher auch ne Frage der subjektiven Erwartung!
Zitat von: herrmannj am 23 Februar 2015, 18:52:51
@hcs: ich schau mal ob ich mit dem caching thema was erreichen kann. Idee ist es sich die selector und each Läufe zu sparen in dem das widget selbst gecachet wird, also "update" für den driver erreichbar ist ohne über selectoren und each zu gehen.
Das ist nicht das Problem, siehe meinen post oben. Die Messungen sagen deutlich, dass das Problem die Events sind.
Zitat von: herrmannj am 23 Februar 2015, 18:52:51
die 100ms decken sich mit meinen Messungen recht gut. Und ja, das liegt in sv. Deswegen wundern mich auch marvins Points ein wenig. Sv funktioniert ja ja soweit (mit dieser Struktur) auch weit über fhem hinaus.
Ja, aber halt langsam. Ich habe gerade mal ein Experiment gemacht, bei dem ich von Treiber aus alle basic.float und basic.value direkt aktualisiere, ohne die trigger.
Das ist beängstigend schnell (auf dem langsamen Tablet) ...
Und ich verwende immer noch die slectoren und each. Nur halt keine events mehr.
@marvin: Kannst Du mal bitte mit dem angehängten Treiber testen?
Der aktualisiert aber nur die basic.float und basic.value.
Mich würde interessieren, ob das bei Dir auch eine dramatische Geschwindigkeitserhöhung bringt.
So ist das zwar keine machbare Lösung, aber ich möchte erst mal sicherstellen, dass das der springende Punkt ist (auch bei Dir)
@All: der angehängte Treiber ist nicht für den normalen Betrieb geeignet. Nicht verwenden.
Bereit für die Oscarverleihung
In der Hauptrolle ein Nexus 5
Die Aktualisierung von 300 GADs, die von FHEM geliefert werden.
Den Seitenwechsel erkennt man am Aufleuchten des Menüpunktes.
Wenn die Scrollerei beginnt, ist das page Update komplett durch.
Nachtrag, bevor sich jetzt jemand über sein System wundert. Das ist mit dem Test-Treiber und die Geschwindigkeit, die ich mir wünche.
Nur der Weg, wie sie SV-Konzept-Verträglich machbar ist, ist noch unklar.
Findest Du das jetzt schnell oder langsam?
Zitat von: bgewehr am 23 Februar 2015, 21:36:39
Findest Du das jetzt schnell oder langsam?
Ich finde es schnell. So macht es Spaß. Das war mit dem Test-Treiber von zwei Posts weiter oben.
Die Geschwindigkeit würde ich mir wünschen.
Die Original-SV-Geschwindigkeit ist um Kategorieren langsamer, so, dass man es benutzen kann aber der Spaß-Faktor fehlt.
Ah, OK! Wollte schon sagen, damit kann man doch leben! Kann man denn die delegates tiefer im DOM aufhängen und würde das schon was bringen?
Zitat von: herrmann
@marvin: ich finde jetzt Deine 60-70 GADs nicht soviel. Entweder Deine Erwartungshaltung unterscheidet sich oder da ist noch was anderes. Bitte sei doch so nett und mach echt mal Messungen, an die widget Farbe etc bist Du ja auch rangegangen. Oder anders: schau doch mal ob sich ein jungräuliches sv dir gleich verhält. Dazu könntest Du in einen jungfräulichen Verzeichnis (wichtig ohne eigene visu.js und so) widgets (GAD) mit den Namen internal.0, internal.1 usw anlegen - fronthem bedient die automatisch ohne das Du was im Editor einstellen musst.
Meine Erwartungshaltung ist sicher nicht zu hoch. 10-15 Sekunden für eine normale Seite ist einfach zu viel. 60-70 Gads sind auch nur im Menü. Davon hat man schnell mal 10 im DOM, wenn der Cache an ist. Den Rest habe ich tatsächlich probiert. Klar bringt es was, nur wenige unterschiedliche Widgets zu haben. Das kann nicht die Lösung des Problems sein. Ein Workaround auf dem Handy ist tatsächlich auf die full.html zu setzen und das Menü weg zu lassen. Dann fluppt es ganz ordentlich. Das zeigt mit, das es tatsächlich die vielen Elemente im DOM sind, die das Problem machen. Ich denke einfach, dass ich schon ein sehr umfangreiches System habe. Insgesamt bin ich bei fast 600 gads (Widgets der untschiedlichen Art).
@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.
Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.
jetzt beiss Dich doch nicht so am DOM fest - mach mal bitte eine Messung - alles andere bringt doch nix.
vg
jörg
Das Problem ist, dass, was immer man tun möchte, man alle Widgets ändern müsste.
Hier steckt das Problem:
$(document).delegate('[data-widget="basic.float"]', {
Beispiel basic.float:
// ----- basic.float ----------------------------------------------------------
$(document).delegate('[data-widget="basic.float"]', {
'update': function (event, response) {
if ($(this).attr('data-unit') != '') {
$('#' + this.id).html(parseFloat(response).transUnit($(this).attr('data-unit')));
}
else {
$('#' + this.id).html(parseFloat(response).transFloat());
}
}
});
Na und? Sind ja keine 100?!
ich schau auch grad drauf - vielleicht gibt es Alternativen. Wenn wir das machen dann geht der updatepfad flöten, dann können wir echt gleich alles forken ...
wollen wir das wirklich ? Eigentlich spricht nichts dagegen, aber dann haben wir auch die ganze Arbeit an der Backe. .... (unsicher)
@hermannj: Ich weiß ehrlich gesagt nicht wie?! Am Ende ist entscheidend, was am Bildschirm geschieht und da aktualisieren sich die gads sehr langsam und vor allem auch stockend (mit teilweise sekundenlangen Pausen) - Vielleicht sollte ich mal ein Video zeigen.
@HCS: Ich habe nichts dagegen, die Widgets zu ändern. ;) Ich habe schon überlegt, eine Art Superwidget zu bauen und die Art über ein weiteres Attribut zu steuern, um nur noch wenige Arten Widgets zu haben. Einen Versuch wäre es Wert.
Ich komme nochmal zu den Fragen zurück:
Zitat von: marvin78 am 23 Februar 2015, 21:43:10
@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.
Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.
Halb so wild, ist doch nur die widget.js, oder?
Zitat von: herrmannj am 23 Februar 2015, 21:50:16
jetzt beiss Dich doch nicht so am DOM fest - mach mal bitte eine Messung - alles andere bringt doch nix.
Ich habe gemessen, reichlich und was ich weiter oben beschrieben habe, ist das Ergebnis der Messungen.
Aufgrund von diesem Ergebnis habe ich den Treiber experimentell so geändert, dass er die beiden Sorten widgets ohne events aktualisiert, mit dem Ergebnis, das im Video zu sehen ist.
Die Zeit, bis SV wieder aus dem trigger-Aufruf rauskommt, liegt auf dem Test-Tablet zw. 60 und 100ms. Meine Aktualisierung ohne events braucht 2 bis 3ms.
Zitat von: marvin78 am 23 Februar 2015, 21:43:10
@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.
Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.
Ja, das war mit dem experimentellen Treiber. Original ist deutlich langsamer.
@HCS
ZitatIch habe gemessen, reichlich und was ich weiter oben beschrieben habe, ist das Ergebnis der Messungen.
sorry, das war für marvin. :) nicht für Dich - wir haben ja gemessen :D - Du ganz viel
Zitat von: bgewehr am 23 Februar 2015, 22:00:41
Halb so wild, ist doch nur die widget.js, oder?
ja, hast schon Recht. Muss man aber aufpassen. Charmant ist ja das sv einfach "da ist". Auf der anderen Seite: mandanten: ergänzt. driver mit reconnect: ergänzt. Einige widgets: ergänzt. Und pass mal auf, bei den plots kommt auch das eine oder andere.... soweit isses also echt nich ... Man muss nur echt aufpassen das man nicht im Eifer anfängt irgendwas zu verschlimmbessern. Was denkt Ihr ? (Bernds Antwort kenn ich ;D )
vg
jörg
Anfangen!
Für ein bisschen Geschwindigkeit würde ich gern das eine oder andere Ändern! ;)
Die Idee, die wirklich hilft, selbst wenn man die Widgets ändern wollte, fehlt mir aber auch noch.
Ich schreibe da gerade im Treiber Stück für Stück ein SV. Oh, gerade den post gesehen, wärend ich schreibe, unsere Gedanken ähneln sich.
Ich muss mal in Ruhe nachdenken, was die Optionen sind.
Könnte vielleich noch jemand mal den experimentellen Treiber probieren, was er an der Geschwindigkeit ändert, verglichen mit dem Domotiga.
Charts: das habe ich im Treiber bereits weitgehend implementiert, fast komplett an SV vorbei, weil ich es nicht später Stück für Stück dann doch rausziehen wollte.
Nur so waren die Anforderungen, die ich tausend posts weiter oben beschrieben habe, machbar.
Mann, das Forum braucht länger zum Absenden eines Beitrags als SV für 50 GADs >:( ;D
Was auch immer wir nun machen, dass sollte gut und in Ruhe überlegt sein, weil es weitreichende Konsequenzen haben kann.
yepp. seh ich auch so. Mehr speed wäre schön - am besten mit Plan
<klugscheiss>
Plan, der: gedankliche Vorwegnahme zukünftigen Handelns
</klugscheiss>
Und das Highlight: ich wollte ja nur mal schnell einen reconnect in den Treiber einbauen, weil ich zu faul war, nach einem FHEM-Neustart zum Tablet zu laufen.
Erkenntnis: Faulheit wird mit Arbeit bestraft. :D
Ich werde mal anfangen, einiges gedanklich vorwegzunehmen ...
so isses. Immer wenn jemand sagt "Freiwillige vor" - einen Schritt zurück treten. Das muss ein Reflex werden! Spass beiseite: bist ja nicht alleine ;)
Würde gern mithelfen! Bewundere aber eure Programmierfähigkeiten, kann hier bestenfalls beim testen helfen!
http://jsperf.com/jquery-event-delegation
Eindrucksvoll - würde aber auch bedeuten die widgets umzuschreiben. Und ich bin mir nicht sicher on das geht. So vielleicht ? : $('a').on('update'... ?
Ich raffs noch nicht ganz, wir nutzen doch Delegation in SV und nicht find()...
ich auch nicht ganz. Denke der Unterschied liegt darin das in sv das delegate (was intern dann auch ein 'on' macht) an 'document' gebunden ist. Find interpretiere ich als Ersatz für die den selector - der Hauptunterschied ist, glaub ich, wo das delegate (on) dann hängt. Nur Hyptothese, und so hab ich HCS verstanden ...
Alle eventhandler hängen oben am document (parallel) und haben selectors. Jedes event muss hoch bubbeln und oben beim document alle selectors evaluieren, die es gibt. Das braucht Zeit. Genau das beschreibt auch die von mir zitierte jquery Doku.
Es wäre mal interessant, aus der widget.js alle widgets rauszuwerfen, die man nicht braucht, was ja die Anzahl der selectors, die im Spiel sind deutlich reduziert.
Da werden immerhin 50 delegates drangehängt, deren selector jedes mal ausgewertet werden muss, wenn ein GAD aktualisiert wird.
Oder mache ich jetzt einen Fehler bei der gedankliche Vorwegnahme?
Zitat von: HCS am 23 Februar 2015, 22:14:41
Könnte vielleich noch jemand mal den experimentellen Treiber probieren, was er an der Geschwindigkeit ändert, verglichen mit dem Domotiga.
Habe den Treiber mal getestet.
Auf nem Rechner macht es kaum einen Unterschied. Auf nem Smartphone bzw. Tablet ist der Treiber wesentlich schneller. Ich habe jedoch nur wenige Gads.
@HCS
ick wees et nich jenau,
Mit jquery kann ich schon, aber nicht umsonst findet man die 5 Millionen jqeury performance how to im Netz. Da ist halt Raum für Spezielisten. Ich befürchte nur wenn da einer in der loop wär dann hätte der oder die schon mal die Finger gehoben. Wird an uns hängen bleiben ...
Mal abstrkt gedacht: wenn man das event direkt zustellen könnte wäre der Job ja erledigt ? Meinst mit rigger könnte was gehen ? Also zB $('a').trigger( ... oder vielleicht sogar object.trigger ???
http://api.jquery.com/trigger/
den gibts auch noch. Da steht das der nicht bubbled und nur das erst element trifft (das könnte man ja handlen ... und dadurch isser ja noch mal schneller)
http://api.jquery.com/triggerHandler/
Naja, morgen ist auch noch ein Tag.
vg
jörg
n8
Moin! Es gibt ja diese Variante
// ----- basic.button ---------------------------------------------------------
$(document).delegate('a[data-widget="basic.button"]', {
Wo schon ein a ausgewählt ist und diese
// ----- basic.float ----------------------------------------------------------
$(document).delegate('[data-widget="basic.float"]', {
die ohne Objektfilter läuft. Würde es evtl schon helfen, wenn alle sauber mit dem Objekt formuliert werden, das am Ende auch im widget-html verwendet wird?
Das müsste ja die Menge der selectoren schon mal einschränken, oder?
Der basic value ist ohne Objekt:
// ----- basic.value ----------------------------------------------------------
$(document).delegate('[data-widget="basic.value"]', {
Kann einer von Euch mal messen, ob es einen Unterschied macht, wenn man statt dessen
// ----- basic.value ----------------------------------------------------------
$(document).delegate('span[data-widget="basic.value"]', {
Verwendet?
Kleine Beobachtungen, die ich zwischen dem Aufstehen und dem Aufbruch zu einer Geschäftsreise machen konnte:
Der Testtreiber bringt auf einer Testseite mit etwa 100 gads (vornehmlich basic.value) eine deutliche (fast unglaubliche) Verbesserung gegenüber Standard-FHEM und auch Domotiga-Treiber.
Das Kürzen der nicht benötigten Widgets aus der widget.js und das "Zusammenlegen" einiger selbst entwickelten Widgets bringt tatsächlich auch eine sichtbare Verbesserung.
Delegate ist schneller als live. Bei on war ich nicht direkt sicher, wie ich das implementieren kann und dann ging mir auch die Zeit aus. Auch den direkten Selector auf das Element hätte ich noch gerne getestet, kam aber nicht mehr dazu. Das sind hier alles immernoch keine empirischen Messungen aber ich hatte leider keine Zeit, dazu etwas zu bauen.
Zitat von: marvin78 am 24 Februar 2015, 09:16:44
Der Testtreiber bringt auf einer Testseite mit etwa 100 gads (vornehmlich basic.value) eine deutliche (fast unglaubliche) Verbesserung gegenüber Standard-FHEM und auch Domotiga-Treiber.
OK, damit ist das erwartete Ergebnis eingetreten. Ist das von der Geschwindigkeit das, was Du Dir vorstellen würdest?
Schade, dass das so nicht machbar ist.
Zitat von: marvin78 am 24 Februar 2015, 09:16:44
Das Kürzen der nicht benötigten Widgets aus der widget.js und das "Zusammenlegen" einiger selbst entwickelten Widgets bringt tatsächlich auch eine sichtbare Verbesserung.
Damit bestätigt sich meine Theorie.
Da sie leider wohl stimmt, bedeutet das aber, dass die Widgets auf keinen Fall so bleiben können, wie sie sind.
Zitat von: marvin78 am 24 Februar 2015, 09:16:44
Das sind hier alles immernoch keine empirischen Messungen aber ich hatte leider keine Zeit, dazu etwas zu bauen.
Wenn man die "Spaßbremse" raus hat, muss man eigentlich gar nicht mehr messen, die Veränderung sieht man so deutlich, dass man weiß, dass es OK ist :)
An alle, die dazu was ausprobieren: Auf einem ordentlichen PC, Laptop, ... merkt man da nicht so viel, auf Telefonen und Tablets ist es dagegen gravierend.
Sagt mal, man kann ja den JS code auch in einem Script Tag im widget html unterbringen und auf die widget.js ganz verzichten. Das würde einerseits bedeuten, dass die Skripte nur für die verwendeten Widgets geladen werden, andererseits aber, dass sie für jede Verwendung des Widgets angelegt werden, oder greift da irgendeine Optimierung?
Mein Vorschlag wäre erst ein mal zu versuchen das ohne impact auf widget.js hinzubekommen. Weil, wenn wir da jetzt garvierend umbauen dann kannste eben auch nicht mal einfach ein (zB) uzsu widget irgendwo aus einem git holen und das mal eben reinkopieren.
Ich könnte mir vorstellen das http://api.jquery.com/triggerHandler/ uns da schon weiterbringen könnte.
Jetzt:
driver bekommt ein update von fronthem und kippt das als event in den DOM. Im DOM bubbled das event dann durch, speziell an den delegates (die zum Teil ja von jquery auch als emulation abgebildet werden) muss also pro delegate der gesamte Hirarchie durchlaufen werden, mal anzahl der deleagtes. (@HCS, Du bist da ja mittlerweile mit expertise unterwegs, richtig beschrieben?)
Idee:
der driver kippt das event nicht mehr einfach "anonym" rein. Im "monitor" werden die widgets gesammelt (als object) und wenn ein update kommt prüft der driver wo es hingehört und reicht es via "triggerHandler" direkt an das entsprechende widget. Laut api (interpretiere ich so) geht das am DOM vorbei (es werden keine DOM Events ausgelöst, es wird nicht gebubbled). Das sollte imho die Punkte komplett beseitigen ohne (!) die Kompatibilität zu brechen.
@HCS: was denkst Du ? Könnte das funktionieren ? Wenn ja kann ich gern heut Abend mal testen ...
vg
jörg
Zitat von: herrmannj am 24 Februar 2015, 11:21:53
Mein Vorschlag wäre erst ein mal zu versuchen das ohne impact auf widget.js hinzubekommen. Weil, wenn wir da jetzt garvierend umbauen dann kannste eben auch nicht mal einfach ein (zB) uzsu widget irgendwo aus einem git holen und das mal eben reinkopieren.
Jörg, hilf mir kurz: warum nicht? Das eine hat doch mit dem anderen gar nichts zu tun, oder?
HCS kannst Du mal die aktuelle Architektur Deiner Plots kurz erläutern?
dann hab ich das falsch verstanden. Ich dachte du meinst dass in Hinblick auf die Aktualisierung Zeit. Generell hat sich die Ternnung doch bewährt und ja (Optiminierung), der twig cahce greift dann aber das kennen wir ja.
vg
jörg
Das hier klingt interessant, es erspart wieder und wieder im selben DOM zu suchen:
http://stackoverflow.com/a/1883643/2177484
Zitat von: bgewehr am 24 Februar 2015, 11:39:02
HCS kannst Du mal die aktuelle Architektur Deiner Plots kurz erläutern?
Können wir das verschieben? Drei Dinge gleichzeitig sind zu viel für mich.
Zitat von: bgewehr am 24 Februar 2015, 12:30:39
Das hier klingt interessant, es erspart wieder und wieder im selben DOM zu suchen:
http://stackoverflow.com/a/1883643/2177484
ja genau, das each. Aber HCS hat ja die eventhandler als Achse des Bösen erkannt. vg jörg
Zitat von: HCS am 24 Februar 2015, 12:47:06
Können wir das verschieben? Drei Dinge gleichzeitig sind zu viel für mich.
Klar!
Zitat von: herrmannj am 24 Februar 2015, 11:21:53
Idee:
der driver kippt das event nicht mehr einfach "anonym" rein. Im "monitor" werden die widgets gesammelt (als object) und wenn ein update kommt prüft der driver wo es hingehört und reicht es via "triggerHandler" direkt an das entsprechende widget. Laut api (interpretiere ich so) geht das am DOM vorbei (es werden keine DOM Events ausgelöst, es wird nicht gebubbled). Das sollte imho die Punkte komplett beseitigen ohne (!) die Kompatibilität zu brechen.
@HCS: was denkst Du ? Könnte das funktionieren ? Wenn ja kann ich gern heut Abend mal testen ...
Mir ist spontan nicht klar, wie das gehen soll. Die delegates der widgets hängen momentan (mit der aktuellen widget.js unabänderlich) am document.
Es ist doch momentan schon so, dass das event an das konkrete widget geht, nur dass da halt der handler nicht ist.
Und wenn man den handler dort hin bekommen will, muss man die widget.js ändern.
Zitat von: herrmannj am 24 Februar 2015, 12:56:29
ja genau, das each. Aber HCS hat ja die eventhandler als Achse des Bösen erkannt. vg jörg
Genau. In dem rasanten Test-Treiber ist das each drin, aber keine Events mehr.
Ich bin mir recht sicher, dass die Zeit an der Stelle drauf geht, an der das event am document die delegates abarbeiten muss, um rauszufinden, bei welchem der selektor passt.
Und solange die delegates in der Art am document hängen, führt da dran nichts vorbei.
Der Test von marvin78 (mit der ausgedünnten widget.js) hat das gezeigt. Wenn am document weniger widgets einen delegate angehängt haben, ist das Richtige schneller gefunden.
Um es nicht als unnötig erscheinen zu lassen, die Optimierung der Abfragen auf dem DOM um die instanz des widgets für einen GAD-Name zu finden kann man dann natürlich auch noch optimieren. Aber so lange das Event pro gad zw. 50 und 100ms kostet, ist das mit seinen 1-2ms eher zu vernachlässigen.
HCS machst Du mal die Messung mit Deinen 100 Gads wenn der value mit span ist?
Zitat von: bgewehr am 24 Februar 2015, 13:28:29
HCS machst Du mal die Messung mit Deinen 100 Gads wenn der value mit span ist?
Ja, muss nur schauen wann, bin mal wieder weit von meiner Entwicklungsumgebung entfernt. :(
Und: es sind 300 GADs 8) 8)
So, habe mir jetzt mal mit
{% for i in 1..10000 %}
{{ basic.value(i, 'FB_user1_todaysec') }}
{% endfor %}
10.000 gads angelegt. ;-))
das Ergebnis ist
5s loading
44s scripting
7s rendering
Ändere ich nun den Code des Widgets von
// ----- basic.value ----------------------------------------------------------
$(document).delegate('[data-widget="basic.value"]', {
'update': function (event, response) {
$('#' + this.id).html(response + ' ' + $(this).attr('data-unit'));
}
});
auf
// ----- basic.value ----------------------------------------------------------
$(document).delegate('span[data-widget="basic.value"]', {
'update': function (event, response) {
var item = $(this);
item.html(response + ' ' + item.attr('data-unit'));
}
});
erhalte ich
5s loading
43s scripting
6.5s rendering
also das Gleiche.
Ergo: kleinere Optimierungen am Widget-Code können wir uns sparen, wir brauchen einen anderen Grundansatz!
Mit
$(document).ready(function(){
$('div[data-role="basic.value"]').delegate('span', {
'update': function (event, response) {
$('#' + this.id).html(response + ' ' + $(this).attr('data-unit'));
}
});
});
sind es aber nur noch 20s scripting! Das bringt also schon eher was!
dazu musste ich aber das widget mit einem spezifischen div umgeben, was wiederum auf das Rendering wirkt, aber wir sind ja nur im Test!
{% macro value(id, gad, unit, tag) %}
<div data-role="basic.value">
<{{ tag|default('span') }} id="{{ uid(page, id) }}" data-widget="basic.value" data-item="{{ gad }}"
data-unit="{{ unit }}">--- {{ unit }}</{{ tag|default('span') }}>
</div>
{% endmacro %}
magst Du mal testweiße in der lib//base/widget.js , line #679
das
$(this).trigger('update', [values]);
in das
$(this).triggerHandler('update', [values]);
ändern ob das geht und was bringt ?
So, bin jetzt bei 10.000 values bei 15s, nur durch delegieren an die unterste Ebene (klingt irgendwie dekadent...)
Bitte mal ausprobieren: neue widget.js
Diese Version erfordert für jede Seite einen page reload, ist nur devstate.
EDIT:
Änderungen an den widget-html sind NICHT nötig!
Welchen Treiber verwendest Du aktuell dafür?
Zitat von: herrmannj am 24 Februar 2015, 16:23:57
lib//base/widget.js , line #679
$(this).trigger('update', [values]); -> $(this).triggerHandler('update', [values]);
TRIGGER bei 10.000 basic.value: 16s
TRIHGGERHANDLER bei 10.000 basic.value: 13s
Beide male gemessen mit meiner modifizierten widget.js.
Zitat von: HCS am 24 Februar 2015, 16:52:26
Welchen Treiber verwendest Du aktuell dafür?
io_fhem
Zitat von: bgewehr am 24 Februar 2015, 16:53:16
TRIGGER bei 10.000 basic.value: 16s
TRIHGGERHANDLER bei 10.000 basic.value: 13s
Beide male gemessen mit meiner modifizierten widget.js.
ah cool. minus 20%, hast Du die chance das nochmal mit einer unmodifizierten widget js durchlaufen zu lassen ? Ich könnte mir vorstellen das weitere Prozente in der #651 (base.js) liegen, da geht um das
$('[data-item*="' + item + '"]').each(function (idx) {.
Beides könnte man in den driver ziehen ohne sv anpacken zu müssen.
Wenn ich das so wie gestern auf dem Tablet messe, dann sieht das von den Zeiten her schon mal sehr gut aus.
Mit triggerHandler und "bgewehr widget.js" komme ich auf Zeiten, die nahe an der Direktaktualisierung dran sind.
Original SV: 30-50ms -> nicht toll
"bgewehr widget.js" mit triggerHandler: 2-3ms -> aktuell die machbarste Lösung
Direktaktualisierung ohne events: ca. 1-2ms -> ohne Konzeptänderung nicht machbar
triggerHandler geht nur mit der widget.js von bgewehr weil die die handler am widget hat.
Da die originale widget.js die handler an document hängt und bei triggerHandler die events nicht hoch bubblen, geht das nicht.
Ist aber auch interessant, das event findet keinen Handler, bubbelt nicht hoch und kommt unverrichteter Dinge zurück, und das in 0-1ms
Das Feuern der Events mit triggerHandler kann ich in den Treiber holen, dazu müssten wir nicht unbedingt an SV ändern.
So weit so cool, nun müsstest Du noch das AJAX-Thema lösen.
Der $('[data-item*="' + item + '"]'); braucht 0-1ms, eher 0 und der each spielt keine Rolle, es kommt eh nur ein Elemet zurück, wenn man nicht das gleich GAD mehrmals auf der page hat.
Das Ajax-Thema müsste mit
$(document).on("pagecreate", function() {
zu lösen sein. Oder?
$(document).on("pagecreate", function() {
funktioniert mit AJAX.
Dazu in der widget.js von bgewehr
$(document).ready(function() {
durch
$(document).on("pagecreate", function() {
eretzen.
So ist das Ergebnis selbst mir meinen vielen eigenen Widgets beinahe perfekt!
Ich hab da noch was:
Mit der originalen widget.js und einer kleinen Änderung in der base.js erhalte ich hiermit super Ergebnisse in usability und Performance:
https://github.com/bgewehr/smartVISU-multipage/tree/master
Probiert Ihr das mal aus? Ist Beta, aber zeigt auf, dass es überhaupt nicht langsam sein muss (mit Cache!) wenn man einfach alle Seiten am Anfang lädt und dann mit JQM Methoden die Seite wechselt!
Probiert auch mal die left und Right swipes!
Die Änderung in der base sind nötig, weil die Seitennamen in die Widgetnamen einfließen, daher habe ich alle Codes die den Seitennamen berücksichtigen entfernt und habe nur noch [data-item] dringelassen. Läuft super . Ladezeit 1-2 Sekunden, danach gar keine Verzögerungen mehr!
Ist eher ein Layout für Smartphones... Also bitte auf dem Handy testen!
Ich habs getestet! Ist wirklich schön schnell! Nur geht es immer gleich 2 Seiten weiter!
Würde es vielleicht auch klappen, dass zu der Seite "gewischt" wird welche gerade markiert ist? Sonst wird es bei vielen Seiten umständlich!
Die Geschwindigkeit ist natürlich fantastisch! ;D
Hallo,
mal eine ganz blöde frage von einem Neuling.
Wenn ich Smartvisu installiert habe und komme auch auf die config Seite IP/smartvisu.
Wie komme ich auf die oberfläche von Smartvisu bzw. was muss ich im Browser eingeben?
Danke
welches sv hast Du denn installiert ?
clean-install ?
vg
jörg
Ja
ich unterstell mal das Du php und so am laufen hast. Hast Du die config.ini.default (oder so) in config.ini umbenannt ?
vg
jörg
Danke. Das war es
bin auch schon drauf reingefallen ;) Bernd hat das umbenannt damit man sich mit einem update nicht die config zerschiesst - hatte das vergessen und einen fehler im neu aufgesetzten Server gesucht . Zum Glück schnell gemerkt .... vg
Umbenennen ist nicht gut, das meckert dann beim nächsten GIT pull! Bitte mit cp kopieren in config.ini! (Wie beschrieben im Readme!)
Zitat(Wie beschrieben im Readme!)
die ich mal hätte lesen sollen... ;)
Wenn ich Zeit habe dann bau ich was in die index.php ein damit beim ersten Start (oder wenn keine da ist) die von sv angelegt wird.
Abend zusammen,
ich wollte nochmal auf meine frage von vor ein paar tagen aufmerksam machen. (http://forum.fhem.de/index.php/topic,30909.msg264285.html#msg264285 (http://forum.fhem.de/index.php/topic,30909.msg264285.html#msg264285))
Wie Carsten schon gefragt hat das Reading auch auf "level" zu stellen geht leider nicht da es dieses Reading im Device nicht gibt.
Hinter den anderen Vorschlag bin ich noch nicht ganz gestiegen.
Gibt es den evtl. die Möglichkeit einen Custom-Converter zu basteln der das in meinem fall richtig hinbekommt, level x und off zu interpretieren?
Zitat von: speex am 25 Februar 2015, 22:20:07
Gibt es den evtl. die Möglichkeit einen Custom-Converter zu basteln der das in meinem fall richtig hinbekommt, level x und off zu interpretieren?
Du könntest einfach den Numdirekt Converter aus dem dritten posting dieses Threads nehmen, er ist in der Datei fhconverter enthalten. Dann achte darauf, dass nicht das nächste Update ihn wieder überschreibt. du kannst ihn Dir auch als ITDimmer Converter in die 99_fronthemUtils.pm ablegen, dann ist er "Safe"!
Hi super danke bgewehr, es läuft wieder wie es soll!
P.S. Ich habe Variante 2 umgesetzt mit in die 99_fronthemUtils.pm schreiben.
So. Ich habe die widget.js mit der Modifikation von Marvin (pagecreate) funktionsfähig ins cleaninstall-git als widget.js.alternativ gelegt. Kann ja jeder selber auswählen, wie er arbeiten möchte.
Ich habe inzwischen recht erfolgreich eine jQuery multipage app für meine Seiten entwickelt, die mit der cleaninstall läuft (siehe mein git). Die Navigation ist einfach, schnell und intuitiv.
Klick auf Seite in rooms_menu -> Seite öffnet
swipe right -> rooms_menu
swipe left aus rooms_menu -> Uhr/Wetter/Tel/Calender
Klick auf das smartVISU icon -> config
Sieht für mich sehr aufgeräumt aus, was meint Ihr?
Ich muss mich noch ein bisschen an die Empfindlichkeit gewöhnen, mit der jQuery die swipes detektiert. Manchmal schiebe ich einen slider zu schnell, dann ist es ein swipe und zack - die Seite wechselt... Kann man das eigentlich ein bisschen regeln, wie empfindlich das sein soll?
Schaut's Euch mal an, wenn Ihr Lust habt!
mach Dir nicht zu viel Stress, ich hab einen turbo driver im poc der mit de original sv files arbeitet. ...
Turbo-Driver: auch mit Custom widgets?
ja!. sieht gut aus. Arbeitet auch komplett unabhängig von der dom-size erste Messungen, schneller als sau schnell ...
Was war der Trick?
Wobei das hier so aktuell auch schon verdammt schnell ist....im Vergleich. Ich bin gespannt...
lass mich mal noch poc(en) - bin ja noch nicht durch. Wollte Dir nur erstmal Streß ersparen
Ach, Stress - ich sitze mit frisch operiertem Bein Zuhause... Da hab ich keinen Stress... aber viel Zeit!
gute Besserung nochmal
Zitat von: bgewehr am 24 Februar 2015, 11:39:02
HCS kannst Du mal die aktuelle Architektur Deiner Plots kurz erläutern?
Erst mal gute Besserung.
Also dann:
Momentan liefert mein addon driver die Daten für die Serien, fronthem könnte das aber genauso erledigen, darum beschreibe ich es mal, als ob es fronthem wäre.
Der Treiber holt sich für die aktuelle Page die Charts, die drauf sind.
Die Serien (ein Chart kann ja mehrere haben) werden bei fronthem angefragt und zwar in dieser Form:
{
"cmd": "series",
"items": [
{
"gad": "hcs.data.OilLevelChart",
"mode": "avg",
"start": "7y",
"end": "now",
"interval": "60"
},
{
"gad": "hcs.data.OilConsumptionChart",
"mode": "avg",
"start": "5y 6m",
"end": "now",
"interval": "120"
}
]
}Beispiel für das erste item: bitte eine Serie für das GAD hcs.data.OilLevelChart die vor 7 Jahren beginnt und jetzt endet und die bitte alle 60 Sekunden mit aktuellen Daten liefern.
fronthem liefert darauf hin alle 60 Sekunden die Daten die so aussehen:
{
"cmd": "series",
"items": {
"gad": "hcs.data.OilLevelChart",
"plotdata": [
[
"x-Value1",
"y-value1"
],
[
"x-Value2",
"y-value2"
],
[
"x-Value3",
"y-value3"
]
]
}
}
Der Treiber aktualisiert darauf hin das Chart.
Die Definition für ein Chart sieht so aus:
{% extends "rooms.html" %}
{% import "widget_chart.html" as chart %}
{% block content %}
Heizölstand: {{ basic.float("OilLevelPlot.Level", "hcs.data.oilconsumption.level", "l") }}
{% set options = '
{
"title": {
"text": "Ölstand",
"x": -20,
"style": {
"color": "#8888FF",
"fontWeight": "bold",
"fontSize": "22px"
}
},
"subtitle": {
"text": "noch was drin?",
"x": -20
},
"chart": {
"zoomType": "x"
},
"tooltip": {
"enabled": false
},
"exporting": {
"enabled": true
}
}
'%}
{{ chart.period("OilLevelPlot",
["hcs.data.OilLevelChart"],
"avg",
"7y",
"now",
"60",
"0",
"5000",
["Füllstand"],
["#44f"],
["line"],
["Jahre","Liter"],
"",
options) }}Im letzten Parameter kann man options reingeben, mit denen man so ziemlich alle Optionen, die die highcharts bieten, steuern kann.
Das ergibt den oberen Teil vom angehängten Beispiel OilChart.png
Die wesentlichen Unterschiede zu der original SV-Variante:
Die options, um das Chart zu steuern, optinal, übergibt man keine gibt es ein schnödes standard Chart
Der Name des GAD wird nicht mit den Parametern wie von, bis, ... erweitert.
Es kann ein Intervall festgelegt werden, in dem das Chart aktualisiert werden soll
SV kann an ein initialisiertes Chart nur Plotpunkte hinten anhängen, das hier kann das Chart mit geänderten Serien aktualisieren
Hier hatte ich auch schon mal meine Gedanken dazu gepostet: http://forum.fhem.de/index.php/topic,30909.msg262386/topicseen.html#msg262386
Hier noch ein Beispiel für die Definition eines Charts mit mehreren Serien (siehe MultiChartExample.png)
{% set options =' { "legend": {
"layout": "horizontal",
"align": "center",
"verticalAlign": "top",
"borderWidth": 1,
"floating": true
},
"chart": {
"showAxes": true,
"zoomType": "x",
"panning": true,
"panKey": "shift",
"animation":
{
"duration": 250,
"enabled": true
}
},
"plotOptions": {
"series":
{
"enableMouseTracking": false
}
},
"exporting": {
"enabled": true
}
} '%}
<div class="hcs-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>Heizung</h3>
{{ Chart.period("HeatingTemperaturesPlot",
["hcs.data.Heating.BurnerTemperatureChart",
"hcs.data.Heating.WaterTemperatureChart",
"hcs.data.Heating.OutsideTemperatureChart",
"hcs.data.Heating.PenthouseTemperatureChart",
"hcs.data.Heating.BurnerRunChart"],
"avg",
"2d",
"now",
"10",
"-20",
"80",
["Kessel","Wasser", "Außen", "DG", "Brenner"],
["#ff0000", "#7777ff", "#DEC11B", "#D04FE8", "#999999"],
["line", "line", "line", "line", "line"],
"",
"",
options) }}
</div>
</div>
</div>Dieser Plot kann z.B. zoom und pan und bietet einen Export des Plot als PDF, JPG, ... und zeigt keine Tooltips, wenn man mit der Maus über die Serien fährt.
Das Ganze läuft seit ca. 2 Wochen recht erfolgreich im Testbetrieb. Einige Detail müssen noch abgerundet werden.
Sieht super aus und wirkt schon sehr reif! Top! Wo kommen die Daten her? Filelog, dblog?
Ich habe mal Bernds widget.js ausprobiert!
Geschwindigkeit ist so wie man es sich vorstellt mit den normalen SV.
@Bernd
Irgendwo in deinen Files musst du deine IP einegetragen haben! Daher läuft leider deine SV nicht bei mir, da es immer ZUgrif auf dienicht vorhandene IP haben möchte.
Welche denn?
Zitat von: bgewehr am 26 Februar 2015, 22:36:57
Wo kommen die Daten her? Filelog, dblog?
Von meiner "nicht FHEM"-Heizungssteuerung. Die holt mein addon driver dort an einem Web Service ab, der die Daten für die Serien als JSON liefert.
Aber wie gesagt, wenn fornthem diese Kommunikation irgend wann implementiert, sollte es direkt auch mit FHEM-Daten laufen.
@herrmanj: was Dich jetzt nicht unter Druck setzen soll.
Das addon driver Konzept hatte ich viel weiter oben schon mal vorgestellt. Der io-fhem holt die Daten von FHEM und der addon driver die Daten von meiner Heizungssteuerung.
Kann's kaum erwarten! Plots, Plots, wir brauchen Plots! Was geht 'n.... War das Jan Delay?...
@Bernd
192.168.178.26
26 ist die Kamera in der Garage, schau mal auf room_garage.html. Da ist ein Multimedia.image()
Zitat von: bgewehr am 26 Februar 2015, 21:29:57
Was war der Trick?
für heute erst mal FA, im POC funktioniert es, muss aber noch umbauen.
Ich geh komplett an den delegates vorbei und benutze einen lookup auf das widget.
io.action[type].handler.call(this, 'update', '321');Der schreibt aktuell in alle widget die er hat eine '321'. Dadurch entfällt für jquery das komplette DOM gecrawle, gebubble etc. Ich brauche noch die Zuordnung der GAD zu den widgets (also hab ich, muss aber noch einen lookup erstellen) und irgendwie wird io new zweimal aufgerufen udn überholt sich. Das ist noch Fleißarbeit.
Zur performance, mit Deiner Anpassung komm ich auf ca 25ms pro GAD, mit dem lookup liege ich bei 0..5, Häufung bei 1. Betagtes NB.
Im Kern dürfte das bedeuten das, wenn alles gut bis zu Ende klappt, auch das asynch timeout wegfallen kann weil fronthem die Daten dann langsamer liefert als der driver die wegschreibt - ergo sv zumindest auf halbwegs brauchbarer HW auch vielen initialen GADS repsonsive bleibt.
Geht aber erst WE oder MO weiter,
vg
jrög
Ach übrigens: Da es eine komplette Parallelwelt zu den SV Plots ist habe ich es Charts genannt. Um nicht durcheinander zu kommen ...
Mann, Ihr kriegt hier was richtig großes zusammen! Ganz großes Kompliment!
Zitat@herrmanj: was Dich jetzt nicht unter Druck setzen soll.
Nö, dafür bin ich zu abgebrüht :P
Grass wächst, und das dauert. Kannste dran rupfen und zupfen - bringt alles nix ;)
Ich will das die Plots auch in einem fork generiert werden, das live updates gehen und einen vernünftigen Editor 8) mehr nich
Zitat von: herrmannj am 26 Februar 2015, 23:02:24
Grass wächst, und das dauert. Kannste dran rupfen und zupfen - bringt alles nix ;)
Düngen und gießen ...
Zitat von: herrmannj am 26 Februar 2015, 22:53:51
Der schreibt aktuell in alle widget die er hat eine '321'. Dadurch entfällt für jquery das komplette DOM gecrawle, gebubble etc. Ich brauche noch die Zuordnung der GAD zu den widgets (also hab ich, muss aber noch einen lookup erstellen) und irgendwie wird io new zweimal aufgerufen udn überholt sich.
Bahnhof.
Wie auch immer, wir müssen das im Treiber dann wieder zusammengepackt bekommen, da ich mit den Charts da schon weiter gemacht habe.
Zitat von: herrmannj am 26 Februar 2015, 22:53:51
Im Kern dürfte das bedeuten das, wenn alles gut bis zu Ende klappt, auch das asynch timeout wegfallen kann weil fronthem die Daten dann langsamer liefert als der driver die wegschreibt - ergo sv zumindest auf halbwegs brauchbarer HW auch vielen initialen GADS repsonsive bleibt.
Ja, mal schauen, wobei immer wieder mal kurz Blocken evtl. auch blockt, so in Summe.
Zitat von: herrmannj am 26 Februar 2015, 23:02:24
Ich will das die Plots auch in einem fork generiert werden, das live updates gehen und einen vernünftigen Editor 8) mehr nich
Sehe ich auch so.
Was sind live updates?
Hi zusammen,
mal ne kleine Frage ;) Ich hab Fronthem am laufen, smartvisu scheint auch zu funktionieren, ich bekomme in Fhem eine Verbindung angezeigt. Dann habe ich eine Testseite mit devices erstellt die in fhem ebenfalls vorhanden sind. Trotzdem bekomme ich kein einziges mal den ominösen Gad Editor angezeigt :(
Vielleicht hat ja jemand eine spontane Ahnung, was ich falsch mache?
Der GAD Editor erscheint, wenn
- die Datei fronthemEditor.js im Ordner fhem/www/pgm2 liegt und die Dateirechte stimmen ( unter welchem User läuft fhem?)
- dein Endgerät mit define meinhandy fronthemDevice MeineIP korrekt definiert wurde
- Du die Details zum Endgerät in fhem aufrufst
Schau mal ob dein Device connected ist!
Zitat von: bgewehr am 26 Februar 2015, 22:50:58
Plots, Plots, wir brauchen Plots! Was geht 'n.... War das Jan Delay?...
Das Boo ;-)
Zitat von: bgewehr am 01 März 2015, 09:43:03
- die Datei fronthemEditor.js im Ordner fhem/www/pgm2 liegt und die Dateirechte stimmen ( unter welchem User läuft fhem?)
läuft unter fhem und rechte hab ich mal auf 777 gesetzt. Daran wirds also nicht liegen
Zitat von: bgewehr am 01 März 2015, 09:43:03
- dein Endgerät mit define meinhandy fronthemDevice MeineIP korrekt definiert wurde
Auszug aus der fhem.cfg:
define meiniphone fronthemDevice 192.168.0.1
Zitat von: bgewehr am 01 März 2015, 09:43:03
- Du die Details zum Endgerät in fhem aufrufst
hier gehe ich auf "unsorted" und klicke auf "meiniphone" - richtig?
Zu sehen bekomme ich dann das direkteingabefeld ganz oben, darunter eine leere box. danach kommt dann "internals" und darunter "Readings" sowie die attr-felder.
Aber ein Gad Editor ist leider nicht zu sehen :(
angehangen mal ein bild des Endgerätes
Kein Gateway. Define ****** fronthem hast du aber?
define meinfronthem fronthem steht in der fhem.cfg
hab ich also, allerdings wird bei dem device als State "???" angezeigt.
Das fronthemDevice muss die IP des Endgerätes (Handy etc) bekommen, nicht die des Servers!
hat es: der server hat 192.168.0.30
192.168.0.1 ist das endgerät (in diesem falle mein rechner)
Komisch, meisten hat der Router die End Ip 1 wenn man es nicht ändert.
Das ist sehr ungewöhnlich! Wie ist denn die IP Deines Routers?
Jetzt schieb ich auch mal eine frage hinterher.
Wie greift man auf Smartvisu von aussen zu?
Auf fhem komme ich. Dort hab ich auf der FritzBox den Port 8083 freigegeben.
Danke schon mal.
@badflex: mach das bloß nicht, das kann dann JEDER und zwar völlig ungeschützt! Sofort den Port schließen und über VPN googeln!
Danke. Dann muss ich mich mal mit von beschäftigen.
Das stimmt schon so ;) mein Router hat 254
Dann schaue beim Laden der Seite mal in die Javascript-Console. Da werden sicher Fehler auflaufen.
hast Du ein fhem update gemacht ? Welche version ist fhem.pl ?
vg
jörg
Hallo,
wie ist derzeit der "offizille" Weg um fronthem aktuell zu halten?
Ich habe derzeit noch eine manuelle Installation von Smartvisu und fronthem im Einsatz.
Ich Frage deshalb, weil hier auch viel über Cleaninstall vom Git gesprochen wird.
Danke!
Hi Gravidi,
fronthem so:
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
Die cfg und 99_myfronthemUtils.pm sind updatesicher.
Daher solltest Du eigene converter in der 99_myfronthemUtils.pm hinterlegen.
Für das git /cleaninstall: da liegt die erweiterte smartVISU, mit Mandanten und reparierten widgets (wo nötig) - ansonsten aber unverfälscht und nicht mit widgets erweitert.
Wenn Du also beim erstellen eigener widgets sowie Deiner Seiten darauf achtest dort nicht einzugreifen sondern in den eigenen Pages darauf aufzusetzen kannst Du dir das aus dem GIT ziehen (per git tool oder zip download) und damit Dein sv bei Bedarf aktualisieren.
In sv eingreiefen vs. Aufsätze verwenden:
sv unterstützt das durch die Vererbungen sehr gut.
Bsp: anstelle root oder base direkt zu verändern kannst Du jeweils angepasste Kopien in dein Seiten Verzeichnis legen - die haben dann Vorrang vor den System Dateien und überlebben so auch updates.
vg
jörg
erstmal danke an alle :)
der ausschlaggebende Punkt war wohl ein fehlendes Update von FHEM. danach hab ich auch meinen GAD Editor bekommen :)
Hi,
im Anhang die Version highspeed Drivers. Bisher sind nur items (keine plots) implementiert, außerdem habe ich den re-connect noch nicht übernommen.
Feedback gern gesehen, im Fall von Fehlfunktionen bitte mit console (denkt an ein evtl. min.js, -> einfach umbenennen). :)
vg
Jörg
Der Treiber legt alles lahm (Javascript wird nicht zu Ende geladen, Navigation nicht möglich):
Uncaught TypeError: Cannot read property 'delegateCount' of undefined io_fronthem.min.js:186
io.monitor io_fronthem.min.js:81
io.run index.php?page=config:57
(anonymous function) jquery-2.0.3.min.js:5
x.event.dispatch jquery-2.0.3.min.js:5
x.event.add.y.handle jquery-2.0.3.min.js:5
x.event.trigger jquery-2.0.3.min.js:5
(anonymous function) jquery-2.0.3.min.js:4
x.extend.each jquery-2.0.3.min.js:4
x.fn.x.each jquery-2.0.3.min.js:5
x.fn.extend.trigger jquery.mobile-1.3.2.min.js:2
a.Widget._trigger jquery.mobile-1.3.2.min.js:3
(anonymous function) jquery-2.0.3.min.js:4
x.Callbacks.l jquery-2.0.3.min.js:4
x.Callbacks.c.add jquery.mobile-1.3.2.min.js:3
g jquery.mobile-1.3.2.min.js:3
a.mobile.changePage jquery.mobile-1.3.2.min.js:6
a.mobile.gradeA.a.extend.initializePage jquery.mobile-1.3.2.min.js:6
(anonymous function) jquery-2.0.3.min.js:4
x.Callbacks.l jquery-2.0.3.min.js:4
x.Callbacks.c.fireWith jquery-2.0.3.min.js:4
x.extend.ready jquery-2.0.3.min.js:4
S jquery-2.0.3.min.js:4
Hi
Danke - dann muss ich nochmal rausbekommen warum das bei Dir nicht geht.
Ich habe gesteren noch gesehen das es bei mit eine Situation gibt wo eine Temp im menu und gleichzeitig auf der Seite ist - die (und nur die) wird dann nicht aktualisiert. Mal schauen wie es insgesamt aussieht - die Einzelfälle schau ich mir dann an.
vg
jörg
Das ganze passiert übrigens ohne irgend einen gad aus FHEM auf dem Schirm schon im Einstellungsmenü von smartVisu. Wenn ich weitere Infos liefern kann, sag Bescheid.
ja, komme ich gern drauf zurück. Wenn Du magst kannst Du ja mal mit einem jungfräulichen Satz pages testen.
An der Fehlermeldung sehe ich das zu dem Zeitpunkt wo ich die widgets abfrage bei Dir keine delegates im Dom liegen. Soweit ich mich erinnere hast Du ja einige Modifikationen gemacht. Wir müssten uns halt einfach anschauen welche das sind und ich muss dann schauen warum sich das auswirkt - und wo ich das abfangen kann.
Lass uns vorher mal schauen wie sich das ingesamt, speziell dort wo es vorher Geschwindigkeitsprobleme gab, positiv auswirkt.
Ich habe gestern noch einen Test mit 1000 Icons gemacht und bin auf ca 0.35ms pro Icon (vs > 50ms vorher) gekommen - das ist schon ein Schluck aus der Pulle. Generell ist der driver noch ein proof of conecept und einzelne Situationen beseitige ich wenn sich das Konzept als gut erweist.
Danke und vg
jörg
Welche Page ich nehme ist egal. Es lieg evtl. an den Modifikationen (delegate auf tiefster Ebene und nicht jeweils gebunden an $(document)). Ich versuche, bis heute Abend alte widjet.js und visu.js auszugraben und damit zu testen. Vielleicht schafft das aber auch jemand eher.
ah - ich lokalisiere die delegates in $(document), wenn Du die verschiebst sind da keine mehr und der Fehler erklärt sich von selbst.
Damit musst Du nichts mehr suchen. Interessant sind jetzt Geschwindigkeitstest.
vg
jörg
Alte widget und visu.js rausgekramt. Leider kann ich jedoch über die Geschwindigkeit nichts sagen, da bei einem ajax Seitenwechsel nur ein Bruchteil der vorhandenen gads aktualisiert wird. In der console werde alle auf der Seite vorhanden gads angezeigt
[io.fronthem] receiving data: {"cmd":"item","items":["EG.fl.TF.Flur.temperature","20"]}
io_fronthem.min.js:121 [io.fronthem]: update item: EG.fl.TF.Flur.temperature val: 20
Die Aktualisierung auf der jeweiligen Seite passiert aber nur bei einer Hand voll gads. Bei einigen Seiten erscheint ein alert mit dem Inhalt (75.0).
das werden vmtl auch GADs sein die öfter auf der page sind:
ZitatIch habe gesteren noch gesehen das es bei mit eine Situation gibt wo eine Temp im menu und gleichzeitig auf der Seite ist - die (und nur die) wird dann nicht aktualisiert. Mal schauen wie es insgesamt aussieht - die Einzelfälle schau ich mir dann an.
Ajax und dom cache habbe ich auch beide an - das soll auch keine Auswirkungen haben. Nach dem duplicate such ich heute Abend - wird ein Logikfehler von mir sein.
Das alert kommt mir komisch vor, ich hab nichts dergleichen drin udn kenne das auch bei den normalen widgets nirgends
vg
jörg
Ahh. Der Alert könnte aus meiner alten visu.js kommen. Das war sicher irgendeine Speed-Messung oder sonstige Debug-Meldung. Da muss ich mich später mit beschäftigen...
Hallo zusammen,
ich habe mich auch heute mal dran gemacht fronthem + smartvisu einzurichten.
SmartVisu läuft (zumindest noch mit den defaults) und das fronthem Gateway + Devices ist eingerichtet.
Sieht erstmal alles ganz gut aus, allerdings scheiter ich an dem Editor.
Irgendwie scheint sich dieser nicht richtig zu laden (siehe Screenshot anbei).
FHEM ist aktuell, die Berechtigungen auf fronthemEditor.js habe ich testweise ohne Erfolg auf 0777 gesetzt.
Hat jemand eine Idee?
Danke & Gruß
----------
edit:
Ich war eventuell etwas zu ungeduldig jetzt sieht man zumindest schon ein paar Devices im Editor-Bereich.
Ich versuche mal weiterzukommen.
Passt doch.
Du musst nur noch in sv gads anlegen dann tauen die im editor auf.
Hi,
in sv ctrl-f5, danach Seitenreload in fhem.
Die GADs werden beim Aufruf einer Seite (in sv) an fhem übertragen.
vg
jörg
Überschnitten :)
Danke euch beiden mir war nicht klar dass die gads übers SV kommen ;-)
Das ist ja mal ein schneller Support hier
und das für knapp unter 1000euro ;)
viel Spass damit, vg jörg
;D
Leider komme ich noch immer nicht viel weiter.
Ich kann zwar jetzt schön im Editor die gads definieren aber er übergibt nichts.
Habe mal das Homematic Widget von Seite 1 eingebunden und genauso konfiguriert.
Alernativ habe ich schon sämtliche basic.value, basic.* ausprobiert aber nirgends krieg ich nen Wert aus FHEM gezogen.
Was mache ich falsch oder habe ich noch etwas vergessen?!
(basic.value hat im SV immer nur den Wert '---' egal was und wie ich es übergebe).
Gruß
Sieht so aus, als hättest du read und/oder write nicht gesetzt.
Edit: Der Thread wird auch zum Posten langsam zu lang. Es dauert mittlerweile ewig, bist der Beitrag abgeschickt ist.
Ich habe bei keinem von beidem die Checkbox aktiviert (ich dachte das mit den PINs käme erst noch?!)
Oder sind die Checkboxen unabhängig von den Felder daneben?
Ja
Die sind unabhängig und müssen bei jedem Client gesetzt werden.
Danke, so simpel aber jetzt gehts :)
Bin begeistert
Hat bei mir auch lange gedauert bis ich das gerafft hab.
Dabei steht's an einigen Stellen.
anbei ein update des poc drivers.
Der bug mit mehrfach verwendeten GAD ist beseitigt. Der driver zickt noch bei dynamischen icons und plots - aber es geht ja um speedtest.
feedback (Messungen) hoch willkommen
vg
jörg
WOW, das ding ist ja richtig schnell ;D
Manche GADs werden leider nicht geladen. In der Console steht dann.
[Error] SyntaxError: Unexpected number '.0'. Parse error.
eval (widget.js, line 295)
update (widget.js, line 295)
onmessage (io_fronthem.js, line 129)
Siehe screenshot.
Grüße
Edit:
Einige js scripts funktionieren mit dem Treiber komischerweise nicht mehr. :o
$('.desired-new').hide();
$('.desired').show();
$(document).delegate('.desired-new', {
'update': function (event, response) {
if (response>0) $('.desired').hide();
if (response>0) $(this).show();
if (response==0) $('.desired').show();
if (response==0) $(this).hide();
}
});
Jemand einen Tipp für mich?
ZitatJemand einen Tipp für mich?
vmtl mein Part.
Ist das script jenes welches den Fehler auslöst ?
Wo wird das geladen (genauer: ist der code schon auf der Seite wenn der driver eingebunden wird).
vg
jörg
Zitat von: herrmannj am 05 März 2015, 22:10:44
Ist das script jenes welches den Fehler auslöst ?
Nein. Ich hab mir jetzt nur mal das Linke Menü mit einer leeren visu.js anzeigen lassen. Eine stelle an dem der gad-wert fehlt, ein fehler in der js konsole.
[Error] SyntaxError: Unexpected number '.0'. Parse error.
eval (widget.js, line 295)
update (widget.js, line 295)
onmessage (io_fronthem.js, line 129)Zitat von: herrmannj am 05 März 2015, 22:10:44
Wo wird das geladen (genauer: ist der code schon auf der Seite wenn der driver eingebunden wird).
Ich verstehe nicht ganz was du meinst.
Meine js codes sind in der visu.js in meinem pages verzeichnis. Auf der Seite die ich als Screenshot angehängt hatte wird der js code nicht verwendet. Dieser ist für das RTR Widget und blendet beim klick auf +/- das SollTemp-Gad aus und das Gad in dem die neue Temp hochgezählt wird ein. Sind 2 verschiedene Readings in einem FHEM-Device. Gleich wie bei dem ReadingsGroup Heizungs Widget (http://www.fhemwiki.de/wiki/ReadingsGroup#Heizungswerte.2C_Status_und_Regelm.C3.B6glichkeit).
poste mal bitte die routine aus Deiner widget.js line#295
bei mir steht da das basic.rgb, das macht aber irgendwie keinen Sinn mit dem Fehler, Du hast da was angepasstes.
Danke und Grüße
Jörg
Anscheinend hab ich da wirklich was angepasst. Die Frage ist nur was :o
Ich hab mir jetzt mal die aktuelle widget.js aus dem cleaninstall im git geladen.
Jetzt ist es Zeile 284:
Zeile
calc = eval($(this).attr('data-formula').replace(/VAR/g, calc).replace(/AVG/g, '').replace(/SUM/g, '').replace(/SUB/g, ''));
alles klar, da zickt er bei mir auch, deswegen geht comfortchart nicht.
Das untersuche ich noch.
Kannst Du noch genauer abschätzen wie das system bei Dir auf den speed auswirkt und evtl blockierend (oder eben nicht :) ?
vg
jörg
Alles klar.
Meinst du den gad-aufbau-speed? Die vollständig geladene seite ist gefühlt 2-3x so schnell geladen als mit dem FHEM driver. FHEM und Smartvisu laufen auf einer ssd in einem QuadCore MacMini mit 16GB Ram. Aufgerufen wird die Seite mit einem MacBook Air 1.7 Ghz DualCore.
Hast du das gemeint?
Mir ist derweil noch etwas aufgefallen. Die dynamischen svg icons (zB batterie icon, meter icon) tun nichts mehr, sprich bleiben "in ausgangs lage".
Grüße
Hi Jörg,
schneller ist es auf jeden Fall.
Vereint ihr die beiden Treiber später noch? Oder ist der ganz und gar schon auf dem Treiber von HCS aufgebaut?
Zitat von: fidel am 05 März 2015, 22:56:06
Vereint ihr die beiden Treiber später noch? Oder ist der ganz und gar schon auf dem Treiber von HCS aufgebaut?
klar.
Wir haben ja in den vergangenen Tagen hier verschiedene Strategien im Umgang mit vielen GAD diskutiert und der driver ist ein poc. Jetzt muss sich zeigen ob die Technik geeignet ist das zu lösen und ob sie in der Breite funktioniert. Wenn ja schauen wir die jeweils besten Teile zu vereinen und dann gehts weiter :)
vg
jörg
Vereinen ist muss, meine addon- und chart-Implementierung will ich nicht verlieren. Ich spiele am Sonntag wieder mit. Gruß vom Kitzsteinhorn ...
Hallo hermannj,
ich habe heute mit dem neuen Treiber ein wenig rumgespielt. Gefühlt mindestens doppelt so schnell wie der alte. Du hattest ja schon bemerkt, dass der refresh nicht sauber funktioniert. Bei mir sind noch folgende Problemchen aufgetaucht:
1. basic tank wird nicht angezeigt
2. bei homematic (ist dies eine individuelle Anpassung?) ist es mir nicht möglich desired Temp zu verändern
3. im confortchart (hat beim fhem treiber einwandfrei funktioniert) wird der Bezugspunkt nicht angezeigt.
ansonsten wirklich klasse. Seite mit rd. 30 gad´s Aufbauzeit > 1 s
Für meine Anwendungen durchaus akzeptabel. ich denke bei den plots wird es wohl nicht so schnell gehen.
Zum Schluß noch ein großes Lob an Euch. Ich verfolge den Thread schon eine Weile und muss sagen, dass diese Oberfläche genau das wiederspiegelt was ich mir wünsche. Macht bitte weiter so!
Leider habe ich nur sehr begrenzte Programmierfähigkeiten, wenn ich Euch anderweitig helfen kann: Gerne
Zitat von: Gerd.Ternes am 06 März 2015, 09:13:09
ansonsten wirklich klasse. Seite mit rd. 30 gad´s Aufbauzeit > 1 s
Wenn das stimmt, ist der "alte" Treiber von HCS in Verbindung mit den direkten delegates aber deutlich schneller, als der poc Treiber. ;)
sorry, sollte < 1 s heissen!
jenau. btw: in jeder zweiten mail schreib ic "messen" ... ;)
Hier ist die Frage wie: vom f5 bis alles da, nur das laden der GAD .. ??
Wenn der threat eins zeigt dann dochdas viele individuelle Situationen bestehen. Ich vermute das Bernd und HCS bei Gelegenheit messen werden, meine Messungen zeigen das die reine aktualisierung eines GAD zwischen 500ns bis 4ms braucht. Das ist schneller als fhem liefert und das sorgt für freie Rechenleistung auf Seiten sv für um responsiver zu sein.
In der widget.js #285 habe ich einen Fehler lokalisiert: das steht:
calc = eval($(this).attr('data-formula').replace(/VAR/g, calc).replace(/AVG/g, '').replace(/SUM/g, '').replace(/SUB/g, ''));
richtig wäre es aber alles im eval in Hachkommas zu setzen, dann funktioniert auch basic.formula:
calc = eval("$(this).attr('data-formula').replace(/VAR/g, calc).replace(/AVG/g, '').replace(/SUM/g, '').replace(/SUB/g, '')");
vg
jörg
Hallo,
mal eine blöde frage. Was mach ich mit der fronthem.js ?
Hab dir in den drivers Ordner gepackt, auch schon mal in fhem umbenannt,
Ändert ich Merk kein unterschied.
Meinste den driver ?
Den müsstest Du in sv ins driver Verzeichniss packen, dort einmal eine Kopie als .min.js ertstellen und dann könntest Du den alternativ zu dem Domotiga driver oder dem von HCS verwenden.
Brauchste aber noch nicht, wir hatten einige Jungs hier die wohl mit x hundert GADs hantiert haben und dann Ladezeiten von mehreren Sekunden hatten. Im Normalfall hast Du so 30-60 Gads pro page, da macht das keinen Unterschied ob 1 GAD in 1ms oder 30ms geladen wird.
vg
jörg
Danke, habs dann auch gesehen. Manchmal sieht man den Wald vor lauter Blumen nicht. Oder waren das Bäume :-)
Habe aber ein Problem wenn ich den cache anwachsen will.
Auf dem Smartphone kein problem, aber am Tablet will er immer die reed_contacts.html. Was hat es damit aufsich?
Error accoured in twig-template engine!
error: Unable to find template "reed_contacts.html" (looked into: /var/www/smartvisu/apps, /var/www/smartvisu/pages/Haus, /var/www/smartvisu/pages/base, /var/www/smartvisu/widgets).
file: root.html
line: 93
Da musst Du mal Deine Seiten durchsehen, wo ein {% import "reed_contacts" as irgendwas %} steht. In einem leeren sv kommt so eine Datei nicht vor! Lösch das raus und der Fehler ist weg. Andere Möglichkeit: Alte Stände im Cache! lösch mal den Inhalt von SV/temp dann könnte es auch weg sein!
Nutzen Tablet und Smartphobe den gleichen Pages Folder?
@bgewehr: Gewöhne dich bitte einmal daran, den Editieren Button zu verwenden. Innerhalb von 1 Minute 2 Beiträge zu schreiben (das machst du ja häufiger), bläht diesen ohnehin schon unübersichtlichen Thread nur noch unnötig weiter auf und verwischt auch den Zusammenhang.
Der Beitrag ist gut gemeint, völlig neutral und enthält das Wort "bitte". Ich weiß nicht, was es daran auszusetzen gibt. Nun gut. Kindisches Verhalten möchte ich nicht weiter kommentieren und das gehört hier auch nicht hin.
Hallo Jörg,
Zitat von: herrmannj am 06 März 2015, 09:58:13
richtig wäre es aber alles im eval in Hachkommas zu setzen, dann funktioniert auch basic.formula:
Die Fehlermeldungen sind jetzt zwar weg, aber die Berechnung findet nicht mehr statt. Ist das bei dir auch so? Hab das mit beiden Treibern getestet. (siehe Screenshot bei Stromverbrauch, die berechnung sollte die Werte / 1000 dividieren. Wh -> kWh)
Ich habe auch noch ein paar andere Probleme mit dem neuen Treiber:
- Die dynamischen svg icons (zB batterie icon, meter icon) tun nichts mehr, sprich bleiben "in ausgangs lage". (siehe Screenshot bei Vorzimmer)
- basic.selectmenu (https://github.com/herrmannj/smartvisu-widgets/tree/master/selectmenu) zeigt beim Laden keinen Wert mehr an
- Das UZSU Popup öffnet sich nicht mehr.
[Error] TypeError: undefined is not an object (evaluating 'response[0].list')
(anonyme Funktion) (visu.js, line 725)
onmessage (io_fronthem.js, line 129) - Viele meiner js Scripts funktionieren nicht mehr. Die Beginnen alle mit $(document).delegate. Funktioniert das delegate nicht mehr? Irgendwas hab ich hier im Thread gelesen aber meine JS Kenntnisse halten sich seeeehr in grenzen und ich hab nicht verstanden worum es geht. Kann ich anstatt $(document).delegate etwas anderes verwenden? Ich blendet öfters gads mittels js ein/aus. (siehe screenshot bei Alarmanlage)
Anbei noch 2 Screenshots mit fhemDriver und fronthemDriver.
Grüße
Lach. Ich habe schon mitbekommen, dass du hier einen leichten Höhenflug hast. Ob du zur FHEM-Community aber wirklich mehr beigetragen hast, als ich, sei mal dahin gestellt (vielleicht liest du meine Beiträge einmal). Ich denk eher nicht. Und dass du mir mehr Zeit gewidmet hast, als ich dir, kann ich auch nicht erkennen. Im Gegenteil. Auf meine Verbesseungsvorschläge zu deinem Select-Widget bist du in keinem Thread eingangen. Es fragt sich also, wer hier unberechtigterweise auf einem hohen Ross sitzt!? Im Gegenteil zu dir lese ich alle Beiträge und weiß, mit wem ich es zu tun habe!
Mein Beitrag oben ist völlig wertfrei und keine Zurechtweisung. Es ist viel mehr eine Bitte. Ein Fass auf zu machen, ist gar nicht nötigt. Es ist mir völlig egal, was du von meinem Ton hälst. Die Bitte ist völlig berechtigt und ein einfaches: Ja, ich versuche daran zu denken, wäre auch ok gewesen und würde deine Umgangsformen in ein besseres Locht rücken.
Aber wie gesagt, das gehört hier alles nicht hin und ist kindisches gequengel.
Edit: Und Beitrag löschen macht es nicht besser, @bgewehr.
@fhainz
in Hochkommas funktioniert die Berechnung (meine ich, teste ich sicherheitshalber nochmal)
Generell ist der driver noch nicht produktiv, das ist ein poc um zu testen und um zu lernen - von daher völlig ok wenn einzelne Sachen (noch) nicht gehen.
Ich muss mir nochmal genau anschauen wo ein array und wo ein einzelner Wert übergeben werden muss.
Die delegates funktionieren, werden aber anders verwendet (daher kommt der Geschwindigkeitszuwachs)
vg
jörg
vg
jörg
Zitat von: bgewehr am 07 März 2015, 10:45:10
Da musst Du mal Deine Seiten durchsehen, wo ein {% import "reed_contacts" as irgendwas %} steht. In einem leeren sv kommt so eine Datei nicht vor! Lösch das raus und der Fehler ist weg. Andere Möglichkeit: Alte Stände im Cache! lösch mal den Inhalt von SV/temp dann könnte es auch weg sein!
Super, es lag am Temp Ordner. Da wäre ich nie drauf gekommen. Hätte ich mich dumm und dämlich suchen können.
Mir ist ein doppelpost lieber als überhaupt keine Hilfe. Also kein streit wegen solchen Kleinigkeiten.
Danke an alle für die gute Hilfe und die viele Arbeit die ihr euch macht. Das ist nicht selbstverständlich. Ich glaube ich kenn kein anderes Forum wo einem so gut und schnell geholfen wird.
Vielen Dank nochmal an alle:-)
@herrmannj
Ich habe die Strategie vom POC-Treiber in meinen "Mess-Treiber" eingebaut und gemessen. Das sieht gut aus.
Umgebung:
Das langsame Tablet, mit dem ich die Messungen bisher gemacht habe, die Zeiten sind also mit Werten, die ich früher schon gepostet habe, vergleichbar.
Original SV-widgets, und auch die restliche Umgebung ist wie gehabt.
Page-Cache, AJAX und DOM-cache an.
Auf der Test-page mit den 300 GADs braucht der Monitor 70-80ms, bis er durch ist.
Die Aktualisierung von einem GAD dauert zw. 1 und 3ms.
Die "gefühlte" Geschwindigkeit ist gut.
Bisher keine Auffälligkeiten.
Gut ist, dass Du das auf dem Domotiga aufgebaut hast. Das hat es (diff sei Dank) einfach gemacht, es zu übernehmen.
Ich werde es jetzt in den FHEM-Treiber übernehmen und bei mir hier mal ein, zwei Tage auf dem Produktivsystem laufen lassen.
Da sehe ich dann auch gleich, ob das bei den Charts usw. auch funktioniert.
Wenn da nichts auftritt und auch sonst niemand mit dem POC-Treiber noch Probleme hat, dann würde ich eine Release vom FHEM-Treiber draus machen.
Eventuell mit einem Schalter, um bei Problemen auf die alte Variante umschalten zu können.
Soweit OK der Plan?
klingt gut. Die Zeiten liegen unter dann auch unterhalb der Zeit die fronthem braucht um zu liefern - damit sollte das timeout entfallen können. Siehst Du das auch so ?
Der poc driver hat noch Macken wenn an einigen Stellen, ich sehe da noch Arbeit bevor der produktiv werden kann. Ich glaube da geht es um die Art wie die items übergeben werden (array vs single item).
Wir können den auch noch eine Zeit lang parallel laufen lassen und dann mergen, schließlich kann man den driver ja jederzeit in den sv optionen umschalten. Ich hab aktuelle einige dirs wo ich develope, da hängt wird der geladen. Die produktiven sind alle noch mit dem Standard driver.
vg
jörg
Zitat von: herrmannj am 08 März 2015, 09:56:52
... damit sollte das timeout entfallen können. Siehst Du das auch so ?
Ja, der sollte nicht mehr erforderlich sein. Eventuell bei den Charts, da die etwas länger brauchen, bis sie gezeichnet haben, aber dass muss ich mir anschauen, wenn ich es in den FHEM-Treiber übernommen habe.
Zitat von: herrmannj am 08 März 2015, 09:56:52
Der poc driver hat noch Macken wenn an einigen Stellen, ich sehe da noch Arbeit bevor der produktiv werden kann. Ich glaube da geht es um die Art wie die items übergeben werden (array vs single item).
Werden die nicht immer als Array übergeben?
Aktuell konnte ich auf keiner meiner pages ein Problem feststellen.
Was wären denn die sonstigen Macken?
Zitat von: herrmannj am 08 März 2015, 09:56:52
Wir können den auch noch eine Zeit lang parallel laufen lassen und dann mergen, schließlich kann man den driver ja jederzeit in den sv optionen umschalten. Ich hab aktuelle einige dirs wo ich develope, da hängt wird der geladen. Die produktiven sind alle noch mit dem Standard driver.
Was auch immmer die beiden letzten Sätze bedeuten :)
Ich baue es mal ein, um es auf meiner Umgebung auch mit den Charts zu sehen. Da ich die Aktualisierung der GADs eh schon weggekapselt habe, ist das kein Problem, es noch ein paar mal zu übernehmen.
Dann läuft es zumindest bei mir hier schon mal parallel mit der neuen Variante.
Wann es im FHEM-Treiber "offiziel" erscheint, können wir ja dann schauen.
Deine Strategie, wie das geht, ist auf alle Fälle klasse 8) 8)
Zitat von: herrmannj am 18 Februar 2015, 16:37:57... Wenn das Tablett sich nicht bei fronthem abmeldet (weil zugeklappt) ist für fronthem nicht zu unterscheiden ob das willentlich geschieht (Deckel) oder ob bspw WLAN unterbrochen ist (weil Störung, zu weit weg und so etwas). Daher sammelt es brav die Events für das device und wenn das device sich auf der gleichen (das macht Deins, das ist der Unterschied) Verbindung wieder meldet bekommt es alles das was es verpasst hat.
Das hatte ich heute auf dem Macbook mit Chrom auch. Das ist im Prinzip richtig, aber fronthem sollte die Änderungen pro GAD nur einmal sammeln. Es bringt ja nichts, nachzureichen, dass das GAD sich von a über b nach c geändert hat. Der letzte Wert reicht.
Sonst wird das übel, wenn man es nach zwei Tagen wieder aufklappt.
nee, max 20min, dann muss eine Entscheidung her :) ; Book geht auf disconnected ...
OK, waren wohl nur knapp 20 Minuten. Da kann trotzdem schon einiges zusammenkommen. So oder so, der letzte Wert pro GAD ist genug, die "Historie" macht keinen Sinn.
bekommste aber nicht ;) weil:
Dann müsste sv ja jeden wert explizit quittieren. Läuft aber so das die in einem puffer landen und dann eben vom tcp Stack abgeliefert werden.
vg
jörg
Zitat von: herrmannj am 08 März 2015, 21:13:57... Läuft aber so das die in einem puffer landen und dann eben vom tcp Stack abgeliefert werden.
Und wenn es in den Puffer soll, könnte man doch schauen, ob es schon drin ist und das vorhandene GAD ersetzten, anstatt es nochmal einzufügen?
@herrmannj: Ich habe Deine Strategie aus dem POC in den FHEM-Treiber übernommen. Das von Dir angesprochene Problem mit den arrays ist mir dann auch noch klar geworden, das ist bei widgets wie temprose und comfortchart, die ein array mit Werten benötigen, nicht gegangen. Das habe ich geregelt.
Den timeout habe ich ausgebaut, das geht auch ohne gut.
Den cache der Werte lasse ich in der widget Klasse laufen, der springende Punkt waren ja die delegates.
Die Messungen auf dem Tablet mit der gewohnten Umgebung ergeben:
Monitor incl. splitten der GADs für fronthem und den addon treiber und Aufteilung in "normales GAD", chart und log ca. 80-100ms
Aktualisierung von einem GAD: 1-4ms, überwiegend 1-2ms
Gefühlte Geschwindigkeit: Gut
Das wäre also gemessen knapp an dem POC dran.
Ein Problem gibt es noch:
Bei der Aktualisierung von temprose und comfortchart mit call werden zwar die Werte im widget korrekt gesetzt, aber Chrome zeigt das widget nicht korrekt an. Es werden nur teile davon gezeichnet. In FireFox geht das. Darum habe ich vorerst eine Erkennung eingebaut, um (ausschließlich) diese beiden per trigger zu aktualisieren. Muss mal forschen, wie das kommt.
Ich hänge den Treiber zum Testen an. Wer in testet, sollte den Aktuellen vorher sichern, falls er mit diesem mehr Probleme als Freude hat.
Er ist noch experimentell. Bei mir laufen alle meine pages problemlos, aber ich habe auch nicht alle widgets, die es gibt irgendwo drin.
Wäre echt cool, wenn Jörg die richtige Strategie gefunden hätte, dass wir das leidige performance-Thema abhaken und uns cooleren Dingen wie z.B. charts zuwenden können.
Anbei noch ein Schirmschuss von einer meiner test-pages
Nachtrag: ihr müsst mal schauen, wie unheimlich behaglich es bei mir ist (siehe comfortchart) 8) ;D ;D ;D
Nachtrag2: sorry, das png ist etwas gigantisch groß geworden
Ich habe mal den neuen Treiber getestet.
Bevor ich das Temp Verzeichnis gelöscht habe hatte ich noch Fehlermeldungen erhalten. Danach ging es wirklich schnell aber erst beim zweiten Aufruf der einzelnen Seiten. Beim erstenmal war es langsamer als zuvor. Hatte warscheinlich damit zu tun, dass erst die Temp-Dateien angelegt werden mussten.
Aber Seiten mit Grafiken werden zwar schnell aufgebaut, nur die Grafik dauert ewig. Insgesamt war es bei mir mit dem alten Driver und den widges.js von bgewehr schneller.
Weiterhin habe ich bemerkt, dass die Seiten zwar schnell aufgebaut wurden aber danach noch eine weile blockieren. Ein schnelles hin und her schalten zwischen den Seiten ist nicht möglich.
Das alte Verhalten, etwas langsamere Lieferung der Daten, hatte mir besser gefallen, da ich auch die Seiten schneller wechseln konnte. Ist aber alles subjektiv ohne Messung.
Bitte weiter machen, eure Arbeit finde ich toll!!!!
Das kann ich bestätigen. ich will die Mühe nicht schmälern und würdige sie auch, aber der alte "Treiber" ist in Kombination mit den tiefen delegates deutlich schneller, als der neue. Außerdem blockiert er weniger. Der Seitenwechsel ist mitunter mit dem neuen Treiber wieder merklich nerviger. Ich habe keine Messungen aber ich habe beide Treiber mit identischen Seiten direkt nebeneinander getestet.
Ich habe jedoch auch kein Problem, die widgets zu ändern. Das haben andere vielleicht. Kann man eine "Wahl" zwischen den beiden Varianten einbauen?
Danke!!
hmm, komisch. Was denn für "Grafiken" eigentlich.
Ansonsten: wir haben hier schon Luxusprobleme, die Auswahl zwischen zwei turbo drivern.
Ich habe gestern mal im knx forum gestöbert. Die ganzen Themen mit speed und dem re-connect sind da schon thematisiert, dort wurde das nur nie gelöst. Macht wirklich Spaß hier, den progress hier zu sehen und so. Das nur am Rande, muss man auch mal aussprechen :)
Danke für Unterstützung in die Runde :)
Jörg
Ich denk mich mal an die plots ran
@karl:
oh - überschnitten. Wegen auswählen: sehe ich kein Problem. Du kannst ja den driver auswählen (in den sv optionen).
Ich würde aber versuchen das wegen dem Umbau an den widgets zu vermeiden.
Die Messungen sind da eigentlich recht eindeutig und die von HCS und meine sind auch konsistent. Das hat also vmtl noch andere (individuelle) Ursachen. Wenn Du möchtest dann geh dem doch nochmal auf den Grund, bspw mit einer jungfräulichen Installation (die kannst Du ja recht easy parallel auf dem Server aufsetzen, per git clone)
vg
jörg
Die Frage ist, habt ihr (du und HCS) auch mal den alten Treiber in Kombination mit der alternativen widget.js getestet/gemessen? Das ist nämlich wirklich rasant schnell und blockiert nicht.
Getestet habe ich übrigens auf einer sauberen Installation. Individuelle Ursachen würde ich fast ausschließen. Und ja, der neue Treiber ist deutlich schneller als der "alte" Treiber mit der ursprünglichen widget.js. Von daher ist das gut, kommt aber nicht an die genannte Alternative ran.
Ansonsten ist dein Hinweis mit der Auswahl zwar korrekt, ich gehe aber mal davon aus, dass mögliche Neuerungen nur in den "neuen" Treiber kommen. Wobei das auch nicht unbedingt ein Problem für mich sein muss. Dann muss ich sie eben selber "mergen".
Wie gesagt: Top Arbeit hier und ich will nicht kritisieren. Meine Hinweise sollen nur helfen.
Versuch doch mal den Neuen wie er ist mit der alternativen widget, ob das geht.
Das blockieren könnte ich noch lindern. Ich hatte ja die timeouts rausgenommen, in der von Jörg bestärkten Hoffnung, dass der Treiber schneller als fronthem ist.
Vielleicht liefert bei karl das fronthem so irre schnell, dass der Treiber wieder am Anschlag ist. Im Prinzip ist es so, dass je langsamer fronthem liefert desto weniger es blockt.
Ich schlage vor, dass ich mal den timeout wieder einbaue und wir dann schauen, was passiert.
ja. Danach ist der POC (deutlich) schneller.
Ist er auch von der Logik: auch wenn der delegate "tiefer" liegt muss das event verarbeitet, sprich durchgereicht/getestet usw werden. Die Strecke ist halt kürzer vom widgetcode bis zum handler code - aber sie ist da.
Beim poc ist genau diese Strecke weg, das GAD kommt rein und wird
direkt an den Handler gegeben. Die ø1,5ms gehen für das reine "neuzeichnen" drauf.
ZitatAnsonsten ist dein Hinweis mit der Auswahl zwar korrekt, ich gehe aber mal davon aus, dass mögliche Neuerungen nur in den "neuen" Treiber kommen. Wobei das auch nicht unbedingt ein Problem für mich sein muss. Dann muss ich sie eben selber "mergen".
Ja, das wären Nebeneffekte von zwei driver udn Du musst auch die widget.js immer daran anpassen, deswegen meine Empfehlung da nochmal auf Ursachensuche zu gehen ...
Zitatund ich will nicht kritisieren. Meine Hinweise sollen nur helfen.
Na, alles gut. Der Hinweis wenn was anders funktioniert als es soll ist ja absolut gerechtfertigt.
@HCS
hast Du eine Idee wie man vielleicht eine Mess- und Diagnose Seite erstellen kann ? Dann hätte man zukünftig die "Messmethode" standartisiert ... Ist, glaub ich, aber schwer. Weil müsste ja schon im driver ansetzen ...
vg
jörg
Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:
Uncaught TypeError: Cannot read property 'handler' of undefined
Ich kann dann nach einem manuellen F5 noch eine Seite weiter navigieren (Ajax), auf dieser werden dann schon nur noch die Hälfte der gads aktualisiert. Danach funktioniert die Navigation nicht mehr. Ich nutze den SmartVisu Cache nicht.
Eine Idee voran das liegen kann?
Zitat von: HCS am 10 März 2015, 22:42:56
Versuch doch mal den Neuen wie er ist mit der alternativen widget, ob das geht.
Das blockieren könnte ich noch lindern. Ich hatte ja die timeouts rausgenommen, in der von Jörg bestärkten Hoffnung, dass der Treiber schneller als fronthem ist.
Vielleicht liefert bei karl das fronthem so irre schnell, dass der Treiber wieder am Anschlag ist. Im Prinzip ist es so, dass je langsamer fronthem liefert desto weniger es blockt.
Ich schlage vor, dass ich mal den timeout wieder einbaue und wir dann schauen, was passiert.
ne, die modifizierten widgets gehen nicht weil die delegates in $(document) gesucht werden und da liegen sie nicht. Das umzustellen macht auch keinen Sinn weil der call ja, unabhängig davon wo der delegate mal lag, sowieso direkt ist.
Den timeout würde ich nicht einbauen (sehr dagegen). Die GADs können nicht viel schneller kommen (Bandbreite etc). Und wenn sie es doch würden, geh mal im Schnitt von 2ms aus (bei mir sind es 1.5) dann hast Du 1000GAD in 2Sekunden abgearbeitet. 1000 ...
Der timeout hat ja den drawback das er eine penalty auf
alle GAD addiert - also in 99% (100?) der Fälle genau das Gegenteil bewirkt.
Ohne die Ursache zu des Verhaltens (bei karl) zu kennen würde da einen weiten Bogen drum machen ...
vg
jörg
Zitat von: marvin78 am 10 März 2015, 22:54:23
Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:
Uncaught TypeError: Cannot read property 'handler' of undefined
Ich kann dann nach einem manuellen F5 noch eine Seite weiter navigieren (Ajax), auf dieser werden dann schon nur noch die Hälfte der gads aktualisiert. Danach funktioniert die Navigation nicht mehr. Ich nutze den SmartVisu Cache nicht.
Eine Idee voran das liegen kann?
Hast Du evtl die widgets.js mit den "tiefer gelegten" (sic) Handlern ?
vg
jörg
Zitat von: herrmannj am 10 März 2015, 22:49:45
ja. Danach ist der POC (deutlich) schneller.
Ämm - nach was?
Zitat von: herrmannj am 10 März 2015, 22:49:45
@HCS
hast Du eine Idee wie man vielleicht eine Mess- und Diagnose Seite erstellen kann ? Dann hätte man zukünftig die "Messmethode" standartisiert ... Ist, glaub ich, aber schwer. Weil müsste ja schon im driver ansetzen ...
Die ist in diesem Treiber schon eingebaut.
In Zeile 563 legt man fest, nach wie vielen GADs (so viele muss man auf der page dann mindestens drauf haben) die Messung angezeigt wird.
In Zeile 583 den alert scharf machen.
Der alert zeigt dann die Zeiten an. Entscheidend ist die Zeit in den "OK ..." Zeilen.
Zitat von: marvin78 am 10 März 2015, 22:54:23
Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:
Uncaught TypeError: Cannot read property 'handler' of undefined
Spontan nicht. Gibt es noch eine Zeilennummer?
Ja, 1 ;) ist die min Version. Sorry, aber ich muss zum Flughafen. Ich teste morgen Abend nochmal mit der "normalen" Version. Danke.
Wenn die Werte alle 1,5ms von fronthem kommen und der treiber 2ms für das widget braucht, dann bleibt aber keine Luft, oder?
Die Oberfläche kann doch nur aktualisieren, wenn sie mit dem widget durch ist und noch kein neuer Wert von fronthem ansteht.
Ämm - nach was?
Das war auf karls post, war überschnitten ...
Vergleich war das von Bernd angepasste (da wo die delegates näher am DOM Element liegen) vs POC driver. Beim ersten sind wir auf ø16ms gekommen beim POC auf ø2ms (plus minus)
vg
jörg
OK.
Kannst ja mal die Messung scharf machen und schauen, was Du für Werte hast. Ist ein alert, dass man auch auf tablets und so messen kann.
Sinnvollerweise sollte man auf einer page messen, die basic.values oder floats hat, dass man nicht durch widgets, die lange Verarbeitungszeiten haben, Werte erhält, die nicht mit meinen vergeichbar sind.
In den OK Zeilen steht auch was für ein widget es ist, das sieht man schön, welche schnell und welche langsam sind.
Wenn ich das bei mir so anschaue, dann stelle ich fest, dass fronthem bei mir deutlich langsamer liefert, als die widgets aktualisieren.
Vielleicht merke ich deswegen kaum was vom blockieren.
Zitat von: HCS am 10 März 2015, 23:05:40
Wenn die Werte alle 1,5ms von fronthem kommen und der treiber 2ms für das widget braucht, dann bleibt aber keine Luft, oder?
Die Oberfläche kann doch nur aktualisieren, wenn sie mit dem widget durch ist und noch kein neuer Wert von fronthem ansteht.
Ja, wobei genau dieser seltene und wünschenswerte Fall ja genau dafür sorgt das nach gerade mal 2 sek 1000 GAD auf dem Schirm untergebracht sind. Im Bereich von 2 Sekunden sind mMn auch keine Beeinträchtigungen im Sinn von "ich muss ewig warten bis ich was machen kann". Das laden der Seite an sich braucht ja schon in etwa in diesem Bereich.
Wenn Du jetzt 1ms per timeout dazunimmst sind das in den 99% der anderen Fälle plus 33% bis die 1000 GAD auf dem Schirm sind. Deswegen würde ich da Abstand von nehmen (kostet mAn viel mehr als es bringt)
btw, die 1.5ms muss man auch erst mal schaffen. Du siehst ja das ich die internals "ganz unten" abgreife und da brauchen die 4ms. Im "richtigen Leben" kommen da noch die Zuordnung von GAD zu device via cfg, die Abfrage der permissions, der converter usw dazu.
Ausserdem bremst der ws mit Bandbreite und overhead nochmal mechanisch.
Bei Karl liegt die Ursache vmtl wo anders.
vg
jörg
Da muss ich mal drüber schlafen und wir bräuchten noch ein paar mehr Tester um einen Eindruck zu bekommen, wie der Treiber generell so läuft.
Ich würde es aber nicht so generell ablehnen. Ob man 2 Sekunden nichts tun kann oder responsive ist und dafür erst nach 3 Sekunden alle Werte dran stehen, ist schon eine Überlegung wert.
Notfalls wird es konfigurierbar, dann kann es jeder einstellen, wie er es möchte.
ZitatIch würde es aber nicht so generell ablehnen. Ob man 2 Sekunden nichts tun kann oder responsive ist und dafür erst nach 3 Sekunden alle Werte dran stehen, ist schon eine Überlegung wert.
Ja, hast Du auch wieder recht. Ich bezweifle nur das Antwort (timeout) und Frage (karl) zusammenpassen. Wenn wir die Ursache kennen wird die Weg zwingend logisch sein.
btw: schlafen ist ein guter Plan.
bis morgen
Jörg
Zitathmm, komisch. Was denn für "Grafiken" eigentlich.
Sorry habe mich falsch ausgedrückt, sind nartürlich die Plots gemeint.
Mein Test habe ich auch nur mit der neuen widget.js gemacht! Werde heute Abend noch mal mit einem cleaninstall die Tests durchführen.
VG Lutz
Hallo zusammen,
habe auch gerade versucht den neuen Driver zu testen, dabei ist mir aufgefallen, dass jetzt bei Verwendung des neuen Drivers unter IE keine GADs mehr geladen werden und ich keine Pages mehr aufrufen kann. Untern Chrome funktioniert das einwandfrei.
Habe ich vergessen, irgendetwas zu beachten bezüglich des IE oder ist das normal das dass jetzt nicht mehr unter IE läuft?
viele Grüße
Alexander
Mit IE habe ich es nicht getestet. Muss mal schauen, ob ich einen habe und probieren.
Mir ist aber bei temprose schon aufgefallen, dass es Unterschiede zw. FF und Chrome gibt, für die ich einen Fix drin habe. Evtl ist das das gleiche Thema.
Wobei: Keine GADs geladen könnte ich mir vorstellen, keine Pages laden, da ist mir monetan unklar, welchen Einfluss der Treiber drauf haben sollte.
SV-Page-Cache mal ausgeschaltet und temp-Verzeichnis von SV geleert?
Was sagt die Konsole vom Browser? Errors?
Eine Frage drängt sich mir aber gerade auf: welche Browser werden "offiziell" unterstützt?
Generelles Vorgehen bei seltsamen Erscheinungen:
SV-Page-Cache ausschalten
SV-temp-Verzeichnis leeren
Browser neu starten
Konsole im Browser öffnen und nach Errors schauen
Zitat von: herrmannj am 11 März 2015, 00:29:19
Ja, hast Du auch wieder recht. Ich bezweifle nur das Antwort (timeout) und Frage (karl) zusammenpassen.
Das halte ich für sehr denkbar. Die Frage ist, wie kommen wir dahinter, was bei karl so bremst.
@karl: kannst Du mal, wie oben beschrieben, die Messung im Treiber scharf machen und die Werte übermitteln. Am einfachsten eine HC vom alert.
Zitat von: HCS am 11 März 2015, 12:47:23
Generelles Vorgehen bei seltsamen Erscheinungen:
SV-Page-Cache ausschalten
SV-temp-Verzeichnis leeren
Browser neu starten
Konsole im Browser öffnen und nach Errors schauen
Der Page-Cache ist bei mir derzeit immer ausgeschaltet, das SV-Temp-Verzeichnis habe ich gelöscht, den Browser neu gestartet und dann mit F12 im IE unter Konsole nach Fehlern geschaut, es werden mir dort keine angezeigt.
viele Grüße
Alexander
Hab mich schon gewundert warum er bei mir am Handy die Temperaturen nicht Anzeigt werden.
IE ist also schuld.
Ja, stimmt, geht im IE nicht. Wobei es mich wundert, dass Du im Unterschied zu mir keinen Fehler in der Konsole bekommst.
Das Problem ist, dass der IE wohl new Event(... nicht unterstützt. >:(
Allerdings komme ich da heute nicht mehr dazu.
Eilt aber auch nicht so sehr, nimm FF oder Chrome, da geht es.
Zitat von: HCS am 11 März 2015, 12:47:23
Eine Frage drängt sich mir aber gerade auf: welche Browser werden "offiziell" unterstützt?
Laut der smartVISU page:
Firefox, Chrome, IE, Safari, iPhone, iPad, Android Phone or Android Tablet
Aber hast ja schon gefunden woran es liegt.
Zitat von: HCS am 11 März 2015, 16:19:39
Ja, stimmt, geht im IE nicht. Wobei es mich wundert, dass Du im Unterschied zu mir keinen Fehler in der Konsole bekommst.
Das Problem ist, dass der IE wohl new Event(... nicht unterstützt. >:(
Allerdings komme ich da heute nicht mehr dazu.
Eilt aber auch nicht so sehr, nimm FF oder Chrome, da geht es.
Den Teil mit "new Event" habe ich aus jquery abgespickt weil ich deren Erfahrung in Bezug auf Kompatibilität nutzen möchte (und an der Stelle ja das handling bzgl delegates "nachgebaut" habe). Die haben dort keine browser Weichen drin - könnte also auch was anderes sein.
Wenn es mit dem domotiga driver läuft können wird es hier lösen. Wenn nein dann liegt es in sv (jq, jqm .... ). Teste doch mal.
vg
jörg
Es crasht aber genau da im IE.
Nachtrag: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events
Ganz unten bei "Browser compatibility"
Du hast recht. Hier ist die source https://github.com/jquery/jquery/blob/master/src/event.js#L364
jq behandelt ein bestehendes event - ich musste das erzeugen. Den Weg bin ich gegangen um Problemen aus dem Weg zu gehen. Das müsste aber auch so funktionieren:
var event = $.event.fix( new Event('update'));
var handlers = ($._data($(document)[0], "events") || {} )["update"];
vg jörg
Kannst Du es mal testweise in den Treiber, den ich veröffentlicht habe, einbauen?
Ich komme gerade nicht dazu.
Wenn es geht, dann übernehme ich es morgen bei mir.
Ich habe Heute noch mal den neuen Treiber mit dem Original Widget.js getestet. Die Gad's kommen ohne Verzögerung, die Plots mit leichter Verzögerung. Nur die komplette Seite wird nach dem laden für 1 bis 2 Sekunden geblockt.
Dann habe ich gerade ein komisches Phänomen gehabt. Im SmartVISU hatte ich die Seite mit meiner Terassenjalousie offen. Meine Frau hat die Jalousie über den Taster geschaltet. Danach ist die Jalousie plötzlich nur noch hoch und runter gefahren. Nach dem ich SmartVISU beendet und FHEM neu gestartet habe war wieder alles i.O.
Kann es an dem neuen Treiber liegen? Ich hatte so etwas noch nie vorher!
Im Log wurde angezeigt, dass ständig zwischen 5 und 0 hin und her geschaltet wurde ohne eine Bedienung von mir! Ich war gerade dabei hier die Antwort zu schreiben!
2015.03.11 20:52:40 3: CUL_HM set Jalousie_TR pct 5
2015.03.11 20:52:41 3: CUL_HM set Jalousie_TR pct 0
VG Lutz
EDIT: Bin dann wieder auf den alten Treiber und die geänderte Widget.js zurück gegangen. und habe im Log folgende Fehlermeldung gefunden!
2015.03.11 21:13:08 1: PERL WARNING: Use of uninitialized value $reading in string eq at FHEM/fhconverter.pm line 149.
2015.03.11 21:13:08 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3372.
Zitat von: HCS am 11 März 2015, 18:40:16
Kannst Du es mal testweise in den Treiber, den ich veröffentlicht habe, einbauen?
Ich komme gerade nicht dazu.
Wenn es geht, dann übernehme ich es morgen bei mir.
sorry, hatte not payed work und bin auch schon fast wieder im nächsten boarding ...
Evtl schaffe ich das morgen früh noch, wird aber eher knapp ...
vg
jörg
Wenn es nicht reicht, dann schaue ich morgen Abend danach.
Zitat von: cruser1800 am 11 März 2015, 21:07:55
Ich habe Heute noch mal den neuen Treiber mit dem Original Widget.js getestet. Die Gad's kommen ohne Verzögerung, die Plots mit leichter Verzögerung. Nur die komplette Seite wird nach dem laden für 1 bis 2 Sekunden geblockt.
Welche plot sind das und wo kommen die Daten dafür her?
Warum die Seite blockt, ist mir unklar, das habe ich auf keiner meiner Seiten, auch nicht auf der 300-GAD-Testseite.
Ist das auf allen Seiten generell so?
Zitat von: cruser1800 am 11 März 2015, 21:07:55
Im Log wurde angezeigt, dass ständig zwischen 5 und 0 hin und her geschaltet wurde ohne eine Bedienung von mir! Ich war gerade dabei hier die Antwort zu schreiben!
2015.03.11 20:52:40 3: CUL_HM set Jalousie_TR pct 5
2015.03.11 20:52:41 3: CUL_HM set Jalousie_TR pct 0
VG Lutz
EDIT: Bin dann wieder auf den alten Treiber und die geänderte Widget.js zurück gegangen. und habe im Log folgende Fehlermeldung gefunden!
2015.03.11 21:13:08 1: PERL WARNING: Use of uninitialized value $reading in string eq at FHEM/fhconverter.pm line 149.
2015.03.11 21:13:08 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3372.
Das in der fhconverter.pm muss Jörg sich mal anschauen. Kannst Du das "rauf-runter" Probelem reproduzieren?
ZitatWelche plot sind das und wo kommen die Daten dafür her?
Warum die Seite blockt, ist mir unklar, das habe ich auf keiner meiner Seiten, auch nicht auf der 300-GAD-Testseite.
Ist das auf allen Seiten generell so?
Die Plots sind die beiden funktionierenden (comfortchart und temprose)
Das Blockieren ist auf allen Seiten mit und ohne Plots. Getestet habe ich es mit FF und auf dem Handy mit Dolphin
ZitatKannst Du das "rauf-runter" Probelem reproduzieren?
Gestern Abend bin ich schnell auf die alte Lösung zurück, um nicht noch mehr Ärger zu bekommen! Nachts die Jalousie ständig fahren zu lassen ist nicht schön. Ich werde es Heute noch mal versuchen.
VG Lutz
Ich hab Heute noch mal getestet.
1. Fehler fhconverter
2015.03.12 18:59:35 1: PERL WARNING: Use of uninitialized value $reading in string eq at FHEM/fhconverter.pm line 149.
2015.03.12 18:59:35 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3372.
Der Fehler schein immer beim Neustart von FHEM aufzutreten.
2. das "rauf-runter" Problem konnte ich nicht nachstellen. Scheint wirklich ein dummer Zufall gewesen zu sein.
3. Blockierendes Fenster
Dieses scheint FF typisch zu sein. Habe es noch mit Chrome probiert und hier ist es kaum merkbar!
VG Lutz
Anbei eine angepasste Version, die mit dem IE funktioniert.
Da ist mir beim Testen etwas aufgefallen: Meine 300 GAD Test-page ist im IE richtig langsam. (hatte bisher SV noch nie im IE probiert)
Chrom ist super schnell, FireFox ein klein wenig langsamer aber im IE, da ist es richtig langsam. Der braucht gefühlt drei bis vier mal sol lange.
Zitat von: cruser1800 am 12 März 2015, 19:35:22
Ich hab Heute noch mal getestet.
2. das "rauf-runter" Problem konnte ich nicht nachstellen. Scheint wirklich ein dummer Zufall gewesen zu sein.
Legen wir mal zu den Akten. Du meldest es bestimmt, wenn es nochmal auftritt.
Zitat von: cruser1800 am 12 März 2015, 19:35:22
3. Blockierendes Fenster
Dieses scheint FF typisch zu sein. Habe es noch mit Chrome probiert und hier ist es kaum merkbar!
Ist bei mir im FF nicht so feststellbar.
Dafür lädt der FF meinen addon-Treiber nicht mehr, der Chrome aber tut es.
Das mit den Browsern ist zum :'(
Vielen Dank für die Anpassungen, jetzt klappt es wieder wie vorher nur wesentlich schneller!
Zitat von: HCS am 12 März 2015, 21:55:34
Anbei eine angepasste Version, die mit dem IE funktioniert.
Da ist mir beim Testen etwas aufgefallen: Meine 300 GAD Test-page ist im IE richtig langsam. (hatte bisher SV noch nie im IE probiert)
Chrom ist super schnell, FireFox ein klein wenig langsamer aber im IE, da ist es richtig langsam. Der braucht gefühlt drei bis vier mal sol lange.
Legen wir mal zu den Akten. Du meldest es bestimmt, wenn es nochmal auftritt.
Ist bei mir im FF nicht so feststellbar.
Dafür lädt der FF meinen addon-Treiber nicht mehr, der Chrome aber tut es.
Das mit den Browsern ist zum :'(
Ach, das wird schon. Schau mal im KNX forum (wo der sv support ja seine Heimat hat) und schau mal wo wir hier stehen. Wir sind echt top, und da geht noch mehr !
Zu "blocken": ich würde hier und heute den Antrag einbringen das "blocken" als Begriff auf den index kommt weil er zu unspezifisch ist. In den developer tools der jeweiligen browser sind überall profiler drin die ganz differenzierte Aussagen erlauben. Im Zweifel kann das ja sogar daran liegen das: der ws verzögert geöffnet wird, einzelne ressourcen (bilder, ajax vom google calender etc) später kommen. Whatever ...
Mittlerweile tunen wir doch so spezifisch das es ohne diesen Blick garnicht identifiziert werden kann.
vg
jörg
Zitat von: avg123-de am 12 März 2015, 23:40:56
... jetzt klappt es wieder wie vorher nur wesentlich schneller!
Ist "wesentlich schneller" nach Deinem Empfinden schnell genug?
Kannst Du bitte mal IE und Chrome vergleichen, ob das bei Dir einen Geschwindigkeitsunterschied macht?
Zitat von: herrmannj am 13 März 2015, 00:14:14
Zu "blocken": ich würde hier und heute den Antrag einbringen das "blocken" als Begriff auf den index kommt weil er zu unspezifisch ist.
Ja.
Zitat von: herrmannj am 13 März 2015, 00:14:14
Im Zweifel kann das ja sogar daran liegen das: der ws verzögert geöffnet wird, einzelne ressourcen (bilder, ajax vom google calender etc) später kommen. Whatever ...
Auch ja.
Zitat von: herrmannj am 13 März 2015, 00:14:14
In den developer tools der jeweiligen browser sind überall profiler drin die ganz differenzierte Aussagen erlauben.
Nur auf den Tablets und Telefonen leider (noch) nicht. Und ganau die sind die Langsamen.
Zitat von: herrmannj am 13 März 2015, 00:14:14
Ach, das wird schon.
Glaube ich auch.
Zitat von: herrmannj am 10 März 2015, 22:22:42
Ich denk mich mal an die plots ran
Da habe ich weiter oben mal mein Gedanken und den aktuellen Stand meiner Implementierung ausgeführt.
Wenn Du fertig gedacht hast, sollten wir das mal abgleichen.
Zitat von: cruser1800 am 12 März 2015, 10:03:03
Die Plots sind die beiden funktionierenden (comfortchart und temprose)
Ich glaube fast, dass wir die beiden auch assimilieren sollten. Mit denen (ihrer Implementierung bezüglich Update der Daten, Unkonfigurierbarkeit, ...) bin ich auch nicht so richtig glücklich.
Ich würde sie aber erst mal so laufen lassen und versuchen, den period mit FHEM-Daten an den Start zu bekommen. Mit Daten aus meinem addon Treiber klappt das schon prima. Hatte ja einige Beispiele veröffentlicht.
Den plot.rtr würde ich auch gerne eliminieren, da er zu 90% eine Parallelimplementierung zum period ist, nur dass er valve position halt noch als "PacMan" mit drauf hat.
Der Plan ist, das als Option im period mit abzuhandeln.
Ich finde es in SV eh etwas unglücklich, dass viele Widgets recht unkonfigurierbar genau ihr Ding machen, so dass man für kleine Änderungen der Funktionalität gerade nochmal eins machen muss.
Beim period habe ich da schon mal kräftig gegengesteuert.
Hallo,
vielleicht kann mir hier jemand weiterhelfen.
Ich habe versucht, smartvisu nach der Anleitung (http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem)) zu installieren.
Ich habe es nach diversen Versuchen aber nicht geschafft, php ans laufen zu bekommen.
Ich bleibe quasi bei dem Punkt "Installation überprüfen:" hängen und sehe nur php-Quelltext.
Das habe ich auch schon versucht:
$ sudo cp /var/www/smartvisu/config.ini.default /var/www/smartvisu/config.ini
Hat jemand eine Idee, wie ich weitermachen könnte?
Vielen Dank vorab und Gruß
Manuel
Zitat von: HCS am 12 März 2015, 21:55:34
Anbei eine angepasste Version, die mit dem IE funktioniert.
Da ist mir beim Testen etwas aufgefallen: Meine 300 GAD Test-page ist im IE richtig langsam. (hatte bisher SV noch nie im IE probiert)
Chrom ist super schnell, FireFox ein klein wenig langsamer aber im IE, da ist es richtig langsam. Der braucht gefühlt drei bis vier mal sol lange.
Legen wir mal zu den Akten. Du meldest es bestimmt, wenn es nochmal auftritt.
Ist bei mir im FF nicht so feststellbar.
Dafür lädt der FF meinen addon-Treiber nicht mehr, der Chrome aber tut es.
Das mit den Browsern ist zum :'(
Jetzt läuft's sehr gut im IE.
Ich weiß nicht obs am Treiber liegt. Bei mir waren vorher die eingestellten Uzsu schaltzeiten angezeigt.
Jetzt macht er es nicht mehr.
Zitat von: HCS am 13 März 2015, 07:30:44
Ist "wesentlich schneller" nach Deinem Empfinden schnell genug?
Kannst Du bitte mal IE und Chrome vergleichen, ob das bei Dir einen Geschwindigkeitsunterschied macht?
Also ich habe jetzt nicht die Sekunden gezählt aber ich würde sagen, dass bei mir zwischen IE und Chrom in Sachen Geschwindigkeit kein merklicher Unterschied besteht. Habe jetzt aber auch nicht mit 300 GADs auf einer Seite getestet.
Zitat von: mele am 13 März 2015, 08:06:38
Hallo,
vielleicht kann mir hier jemand weiterhelfen.
Ich habe versucht, smartvisu nach der Anleitung (http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem)) zu installieren.
Ich habe es nach diversen Versuchen aber nicht geschafft, php ans laufen zu bekommen.
Ich bleibe quasi bei dem Punkt "Installation überprüfen:" hängen und sehe nur php-Quelltext.
Das habe ich auch schon versucht:
$ sudo cp /var/www/smartvisu/config.ini.default /var/www/smartvisu/config.ini
Hat jemand eine Idee, wie ich weitermachen könnte?
Vielen Dank vorab und Gruß
Manuel
Scheint so als ob dein webserver nicht richtig arbeitet.
Benutze mal die suche in diesem Thread. Ich glaube dein Problem wurde hier schon öfter angesprochen...
Hallo mele
Ich hatte auch damit zu"kämpfen" das die Start-Website sich einfach nicht anzeigen lassen wollte. Bei mir lag es daran, das ich das smatVISU Verzeichnis einfach nach /var/www/html/ kopieren musste. Dann konnte ich nach der Eingabe der "nackten" IP auf den Ordner von smartVISU zugreifen und die Startseite öffnete sich (damit umgeht man mögliche Fehler bei der Schreibweise). Das ist aber auch von der installierten Webserverversion abhängig. Ich habe ein eher selten verwendetes Linaro Image auf meinem Cubi.
Aber ein Versuch ist es ja mal wert....
Viele Grüße sendet
Gigafix
Hallo Mele,
ich habe fronthem/Smartvisu auch wie in dem Wiki Beitrag installiert. Ich konnte sehen, dass mein nginx läuft, aber ich konnte nicht auf die smartvisu Seite zugreifen.
Bei mir war folgendes Problem:
Im Wiki gibt es die Stelle:
sudo nano /etc/nginx/sites-enabled/default
Und dann habe ich die Zeilen
server {
listen 80;
root /var/www;
index index.html index.php;
server_name localhost;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
dort eingefügt.
Was ich aber nicht gesehen habe, ist, dass in der Datei weiter unten schon ein ähnlicher Block stand, der aber auf ein anderes Document Root zeigte.
Ich habe dann den unteren Block auskommentiert und schon funktionierte es wunderbar.
@HCS
Ich habe mit dem neuen Treiber das Problem, dass wenn ich hintereinander mehrere Seiten durchgehe stopt der Browser und unten stehender 1. Fehler ist in der Console zu sehen.
Nach einem F5 wird die Seite zwar wieder korrekt angezeigt, aber in der Konsole sind jede Menge weitere Fehler zu sehen! Siehe 2. Bild.
Getestet mir Chrome
Zitat von: cruser1800 am 14 März 2015, 17:40:50
@HCS
Ich habe mit dem neuen Treiber das Problem, dass wenn ich hintereinander mehrere Seiten durchgehe stopt der Browser und unten stehender 1. Fehler ist in der Console zu sehen.
Nach einem F5 wird die Seite zwar wieder korrekt angezeigt, aber in der Konsole sind jede Menge weitere Fehler zu sehen! Siehe 2. Bild.
Getestet mir Chrome
Passiert das wahrlos oder immer ab einer einer bestimmten Seite?
Sicher, dass nirgends ein "tiefergelegts" Widget drin ist?
Kannst Du mir mal die erste Seite, ab der das passiert, schicken?
Inzwischen denke ich noch ein wenig darüber nach.
Nachtrag: Nachgedacht bzw. experimentiert.
Das tritt auf, wenn ich an einem Wigdet den update-handler wegnehme.
Ich würde am ehesten drauf tippen, dass Du eins der modifizierten bgewehr Widgets drin hast.
Wenn nicht, muss ich weiter nachdenken.
Den Fehler kann ich abfangen und was schlaues auf die Konsole rausloggen.
Das Verhindert aber nur den kompletten Abbruch der Seite, das Widget wird dann trotzdem nichts anzeigen.
Hallo, gibt es eigentlich auch eine Anleitung für smartVisu, ausser die auf der smarVisu Seite, die mann für 3 Monate gegen eine Spende von 49€ lesen kann?
Ich müsste mich da mal gründlich einlesen! :o
liebe Grüsse
Zitat von: mele am 13 März 2015, 08:06:38
Ich habe versucht, smartvisu nach der Anleitung (http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem)) zu installieren.
Ups, falsch verstanden...
Zitat von: Eckbert0815 am 14 März 2015, 20:40:28
Hallo, gibt es eigentlich auch eine Anleitung für smartVisu, ausser die auf der smarVisu Seite, die mann für 3 Monate gegen eine Spende von 49€ lesen kann?
Wenn sich mindesten 500 Abnehmer finden, dann schreibe ich eine die €29,95 kostet und die man 6 Monate lang lesen darf, allerdings nur Sonntags zwischen 18:00 und 20:00 Uhr ;D ;D ;D
Im Ernst, ich habe auch keine gefunden. Und das macht es für Einsteiger nicht einfach.
Vielleicht findet sich ja jemand, der im Wiki mal die Grundlagen der page-Erstellung, Widgets, usw. erklärt.
....ich wäre ja auch bereit etwas zu zahlen, aber die 3 Monate stören mich schon, zumal der Sommer bald kommt!.....Nunja schönes Wochende noch! ;)
Ich habe das in den vergangenen tagen mal aus einem alten beitrag von bgewehr hervorgeholt und ins wiki übertragen nach bestem wissen und gewissen im bereich "Eigenes smartVISU Projekt anlegen".
http://www.fhemwiki.de/wiki/Installation_Fronthem (http://www.fhemwiki.de/wiki/Installation_Fronthem)
Ergänzungen und erweiterungen gerne erwünscht es ist aktuell auch noch zu/sehr allgemein für anfänger.
Zitat von: HCS am 14 März 2015, 19:31:11
Passiert das wahrlos oder immer ab einer einer bestimmten Seite?
Sicher, dass nirgends ein "tiefergelegts" Widget drin ist?
Kannst Du mir mal die erste Seite, ab der das passiert, schicken?
Inzwischen denke ich noch ein wenig darüber nach.
Nachtrag: Nachgedacht bzw. experimentiert.
Das tritt auf, wenn ich an einem Wigdet den update-handler wegnehme.
Ich würde am ehesten drauf tippen, dass Du eins der modifizierten bgewehr Widgets drin hast.
Wenn nicht, muss ich weiter nachdenken.
Den Fehler kann ich abfangen und was schlaues auf die Konsole rausloggen.
Das Verhindert aber nur den kompletten Abbruch der Seite, das Widget wird dann trotzdem nichts anzeigen.
Ich hab mir Deinen driver diesbezüglich noch nicht angeschaut, aber wenn monitor nicht die bestehenden (ge-cached) handler resettet wäre so ein verhalten denkbar.
Die von Bernd modifizierten widgets können das mMn nicht auslösen (weil deren handler nie ge-cached werden) ..
vg
jörg
Zitat von: Eckbert0815 am 14 März 2015, 21:49:03
....ich wäre ja auch bereit etwas zu zahlen, aber die 3 Monate stören mich schon, zumal der Sommer bald kommt!.....Nunja schönes Wochende noch! ;)
Hi,
hat mich am Anfang auch sehr ... verwundert.
Man kommt aber da aber mit den Demohäusern und der widget-doku wirklich sehr schnell rein. Rückblickend könnte ich mir vorstellen das den "Kauf" der doku bereut hätte .
vg
jörg
Zitat von: HCS am 14 März 2015, 19:31:11
Passiert das wahrlos oder immer ab einer einer bestimmten Seite?
Sicher, dass nirgends ein "tiefergelegts" Widget drin ist?
Kannst Du mir mal die erste Seite, ab der das passiert, schicken?
Ich habe Heute mal das cleaninstal runtergeladen, deinen letzten Treiber kopiert und meine Page reinkpoiert. Dann nach ca. 3-5 Seitenaufrufen belieben die Seiten stehen. In der Console sind die angehängten Fehlermeldungen zu sehen!
Zitat von: cruser1800 am 14 März 2015, 22:16:11
Ich habe Heute mal das cleaninstal runtergeladen, deinen letzten Treiber kopiert und meine Page reinkpoiert. Dann nach ca. 3-5 Seitenaufrufen belieben die Seiten stehen. In der Console sind die angehängten Fehlermeldungen zu sehen!
Das beginnt mit einem Fehler in der visu.js
Kannst Du mir die mal schicken? Die ist ja nicht Bestandteil von SV sondern irgend was individuelles.
Zitat von: herrmannj am 14 März 2015, 22:03:07
Ich hab mir Deinen driver diesbezüglich noch nicht angeschaut, aber wenn monitor nicht die bestehenden (ge-cached) handler resettet wäre so ein verhalten denkbar.
Die von Bernd modifizierten widgets können das mMn nicht auslösen (weil deren handler nie ge-cached werden) ..
Das Problem ist anders herum. An der Stelle, an der es scheppert, wird versucht, ein Update-Handler von einem Widget aufzurufen, der nicht im cache ist.
Wenn der monitor nicht überlebt oder warum auch immer nicht alle Handler cachet, dann rumst es später irgend wann, wenn ein GAD aktualisert werden soll, weil es den Handler nicht findet.
@cruser1800: anbei ein Treiber zum Testen. Der "überlebt" das Problem und loggt auf der Konsole, welches Widget es verursacht.
Die visu.js kannst Du mir (falls Du willst) trotzdem noch geben, dass ich schauen kann, womit die Fehlerserie darin beginnt.
So ich habe mich mal rangewagt, aber irgenwas Läuft schief mit smartvisu, wenn ich in der rooms_menu.html räume erstelle
* -----------------------------------------------------------------------------
* @package smartVISU
* @author Martin Gleiß
* @copyright 2012
* @license GPL [http://www.gnu.de]
* -----------------------------------------------------------------------------
*/
<ul data-role="listview" data-dividertheme="c">
<li data-role="list-divider">Erdgeschoss</li>
<li data-icon="false">
<a href="index.php?page=room1_wohnen">
<img class="icon" src="{{ icon0 }}it_television.png"/><h3>Wohnzimmer</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
<li data-icon="false">
<a href="index.php?page=room1_kueche">
<img class="icon" src="{{ icon0 }}scene_cooking.png"/><h3>Küche</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
<li data-icon="false">
<a href="index.php?page=room1_gaeste">
<img class="icon" src="{{ icon0 }}scene_visit_guests.png"/><h3>Gästezimmer</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
<li data-icon="false">
<a href="index.php?page=room2_schlafen">
<img class="icon" src="{{ icon0 }}scene_sleeping.png"/><h3>Schlafzimmer</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
<li data-icon="false">
<a href="index.php?page=room2_bad">
<img class="icon" src="{{ icon0 }}scene_toilet.png"/><h3>Bad</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
<li data-icon="false">
<a href="index.php?page=room2_flur">
<img class="icon" src="{{ icon0 }}scene_stairs.png"/><h3>Flur</h3>
<div class="ui-li-aside">
</div>
</a>
</li>
</ul>
und dann zum Beispiel room1_wohnen
/**
* -----------------------------------------------------------------------------
* @package smartVISU
* @author Martin Gleiß
* @copyright 2012
* @license GPL [http://www.gnu.de]
* -----------------------------------------------------------------------------
*/
{% extends "rooms.html" %}
{% block content %}
<h1><img class="icon" src='{{ icon0 }}scene_livingroom.png'/>Wohnzimmer</h1>
<div class="preblock">
<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>Licht</h3>
<table width="90%">
<tr><td align="left" width="100px"> {{ basic.switch('LichtDecke', 'LampeWohnzimmer', icon1~'light_floor_lamp.png', icon0~'light_floor_lamp.png') }}</td>
<td>LichtDecke</td>
</tr>
</table>
</div>
</div>
</div>
{% endblock %}
dann bleibt die Anzeige im Webbrowser so wie sie default im template war nur das sich der Raum sleeping nicht mehr öffnen lässt. Error loading page.........Meine Räume werden gar nicht angezeigt.
Hier nochmal meine config
[smartVISU]
version = '2.8'
multiuser = true
ident_by_ip = true
ip_allowed = ''
ident_by_cert = false
ca_cert = ''
auto_add = true
#pages = 'meister'
#design = 'cube'
#cache = true
#animation = true
#title = 'fronthem [smartVISU]'
#lang = 'de'
#driver = 'domotiga'
#driver_address = '192.168.178.33'
#driver_port = '2121'
#driver_realtime = true
#weather_service = 'yr.no'
#weather_location = 'Germany/Hamburg/Hamburg'
#weather_key = ''
#phone_service = 'offline'
#phone_server = '192.168.x.x'
#phone_user = ''
#phone_pass = ''
#calendar_service = 'offline'
#calendar_url = 'http://www.google.com/calendar/feeds/...'
#js = 'js'
[clients]
192.168.1.66 = 'client_192.168.1.66'
[client:client_192.168.1.66]
pages = 'MeinHaus'
design = 'cube'
animation = true
cache = true
driver = 'fhem'
driver_address = '192.168.1.10'
driver_port = '2121'
driver_realtime = true
js = 'js'
title = 'fronthem [MeinHaus]'
lang = 'de'
weather_service = 'yr.no'
weather_location = 'Germany/Hamburg/Hamburg'
weather_key = ''
phone_service = 'offline'
phone_server = '192.168.x.x'
phone_user = ''
phone_pass = ''
calendar_service = 'offline'
calendar_url = 'http://www.google.com/calendar/feeds/...'
Weiss jemand was ich falsch mache?
Sorry Eckbert0815 wenn ich Deine Frage ignoriere, aber ich bin mit dem Treiber im Stress und hoffe, dass sich jemand um solche Fragen kümmert.
Zumal es hier besser aufgehoben wäre: http://forum.fhem.de/index.php?topic=33231
Nur so als Grundlage: page cache in SV ausschalten und wichtig: das temp-Verzeichnis in SV danach leeren und dann die Seite neu laden.
Falls jemand mit dem weiter oben geposteten Treiber keine Werte in einem basic.formula bekommt - nicht wundern, das ist auch noch ein Fehler im Treiber.
Ich arbeite dran.
Ok vielleicht könnte dann jemand meinen Post verschieben, nicht das was wegen doppelpost kommt!
liebe Grüsse
ich habe die cache auf false gestellt und jetzt geht es! Danke für den Tip
Zitat von: Eckbert0815 am 15 März 2015, 10:33:58
ich habe die cache auf false gestellt und jetzt geht es! Danke für den Tip
Na dann ist ja prima und es muss auch nichts mehr verschoben werden.
@WikiSchreiber: Das wäre eine prominente Erwähnung im wiki wert, da fallen viele drauf rein.
ja eindeutig!..jetzt ist das ganze auch einfach..........
jeder ist @WikiSchreiber :D
ich habe leider keine Berechtigung dafür, sonst stände es schon drinn! :P
Ich mache es bei Gelegenheit. Ich habe ja auch noch etwas ins git zu stellen... ;)
Zitat von: Eckbert0815 am 15 März 2015, 11:48:54
ich habe leider keine Berechtigung dafür, sonst stände es schon drinn! :P
Jede helfende Hand ist gerne gesehen :) http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren
ZitatBenutzerkonto beantragen
Neue Benutzerkonten im Fhem-Wiki können nur von den Administratoren angelegt werden. Dazu muss der Antragsteller eine
E-Mail an einen der Administratoren schicken mit
seinem Vor- und Nachnamen
dem gewünschten Benutzernamen (wenn die erste Stelle ein Buchstabe ist, wird das immer ein Großbuchstabe - das macht die Wiki-Software so und lässt sich auch nicht ändern)
einem sicheren(!) Startpasswort
und seiner E-Mail-Adresse
Nur mit vollständigen Angaben wird ein Benutzerkonto angelegt.
Wenn der Antrag nicht umgehend bearbeitet werden sollte, gebt uns trotzdem ein paar Tage Zeit, bevor ihr den nächsten Administrator anschreibt.
vg und danke
Jörg
Zitat von: herrmannj am 15 März 2015, 11:23:10
jeder ist @WikiSchreiber :D
Fast jeder ... ;D
Zitat von: herrmannj am 15 März 2015, 12:08:59
Jede helfende Hand ist gerne gesehen :)
Definitiv
Das basic.formula-Problem habe ich inzwischen verstanden.
Bin dann wieder an der unendlichen Treiber-Geschichte ...
was machst'n da gerade ? Ich wollt heute Abend auch nochmal rein schauen.
Evtl könnten wir via driver einige Infos zum state (zb aktuelle page) an fhem zurückgeben.
Für die handler habe ich mir überlegt das man einen fallback einbauen könnte. Wenn in $(document) kein handler für das GAD liegt könnte als fallback der normale "update" aufgerufen werden - dann wäre der driver auch zu den Anpassungen von Bernd kompatibel.
vg
jörg
Zitat von: herrmannj am 15 März 2015, 12:33:48
was machst'n da gerade ? Ich wollt heute Abend auch nochmal rein schauen.
Gehe jetzt spazieren, solange es nicht regnet ...
Zitat von: herrmannj am 15 März 2015, 12:33:48
Evtl könnten wir via driver einige Infos zum state (zb aktuelle page) an fhem zurückgeben.
Mir ist der Nutzen nicht klar aber warum nicht...
Die Charts wären mir aber primär dringlicher. Ich denke mal an der frischen Luft drüber nach.
Zitat von: herrmannj am 15 März 2015, 12:33:48
Für die handler habe ich mir überlegt das man einen fallback einbauen könnte. Wenn in $(document) kein handler für das GAD liegt könnte als fallback der normale "update" aufgerufen werden - dann wäre der driver auch zu den Anpassungen von Bernd kompatibel.
Die Idee hatte ich auch schon. Ich denke das baue ich so ein.
Ich mache jetzt folgendes in dieser Reihenfolge:
spazieren gehen
basic.formula retten
treiber fallback beim update
treiber testen
auf ein statement von Dir bezüglich charts warten ;)
Hallo HCS,
Deine Vermutung mit der visu.js und den Änderungen von Bernd waren richtig. Die Seiten halten mit dem letzten Fehler in der visu.js Zeile 85 an. Habe diese mal in der Anlage beigefügt. Vielleicht hast du einen Tipp.
Weiterhin erhalte ich folgende Fehler
[io.fhem]: basic.lbutton: Handler not found io_fhem.js:128
[io.fhem]: basic.button: Handler not found io_fhem.js:128
Aber die Sache mit den Handler habt Ihr ja schon auf dem Schirm.
Danke
Zitatauf ein statement von Dir bezüglich charts warten ;)
schon klar ... ;)
Ich habe noch keine zündende Idee wie ich das aufbaue, speziell in Bezug auf den Editor.
Die series teilt sich ja in "historische" Daten (Quelle filelog, dblog) und aktuelle entstehende Daten. Sprich, ich rufe ein Temperaturplot in sv auf. Fhem bekommt den Zeitraum (minus 4h bis now), muss non-blocking die Werte aus dem filelog|dblog holen, abliefern und dann intern den mode umschalten um die aktuellen auflaufenden Messwerte "nachzuschieben" (der Plot läuft dann "mit").
Überlegung: wie finde ich eine Benutzerfreundliche Möglichkeit um im Editor die Datenauswahl darzustellen. Ich benötige eine Datenquelle aus dem Filelog|DBLog und eine Quelle für die "live daten".
Klar kann man da jetzt die große regex Schlacht anfangen. Führt dazu das der Kreis der user die damit umgehen können eher begrenzt ist (vorsichtig formuliert) - was schlussendlich hier den support Aufwand beträchtlich erhöht (und bei denen bei vielen zu Frust führt).
Ergo: will nicht.
Am Ende muss der user eine option im Editor an die Hand bekommen bei der er sagt: "Temperatur von sensor x, Zeitraum, Auflösung".
Lass mal Gedankenspiel machen:
Ich wähle ein device und habe ein reading. (soweit keine thema, TODO: was machen wenn das reading state ist und die Daten dann zb so aussehen (temp,hum): "T:24 H:60")
Ich muss wissen wo die Daten stehen (logfilename). Landen sie dort immer im gleichen Format wie sie im reading stehen ? Ich habe den Namen des readings. Taugt der (ohne Ausnahme) um damit die gewünschten Daten aus dem logfile zu ziehen ? Was passiert mit dblog ? Wie geht man mit logfile um wo vom user "händisch" (also per {} ) Daten reingeschrieben werden ?
Für die GAD Editor hatte ich ursprünglich einen Standard mode geplant und einen erweiterten mode (regex). Das hat sich dann als unnötig erwiesen. Mglw ist es bei den logs (plots) aber angesagt ...
Lasst mal Ideen zusammenwerfen:
vg
jörg
Erstmal einfach gedacht:
Wenn ich angegeben habe, wo die historischen Werte herkommen, warum sollen dann die aktuellen Werte nicht auch daher kommen? Dann reicht es jedenfalls, eine Quelle abzugreifen und zu überwachen! Die meisten Charts müssen ja nicht ereignisgesteuert aktualisiert werden, weil eine definierte Aktualität ausreichend ist (1h oder 60s oder 5s).
Zitat von: cruser1800 am 15 März 2015, 13:01:16
[io.fhem]: basic.lbutton: Handler not found io_fhem.js:128
[io.fhem]: basic.button: Handler not found io_fhem.js:128
Das mit dem basic.lbutton habe ich anlysiert. Das ist ein Widget, das gar keinen Update-handler hat. Somit kann man natürlich auh keinen aufrufen. Da sollte aber mit der letzten Treiber-Version das Laden der Seite nicht mehr anhalten, da das abgefangen ist. Steht nur als info in der Konsole.
Zitat von: herrmannj am 15 März 2015, 13:56:15
Die series teilt sich ja in "historische" Daten (Quelle filelog, dblog) und aktuelle entstehende Daten. Sprich, ich rufe ein Temperaturplot in sv auf. Fhem bekommt den Zeitraum (minus 4h bis now), muss non-blocking die Werte aus dem filelog|dblog holen, abliefern und dann intern den mode umschalten um die aktuellen auflaufenden Messwerte "nachzuschieben" (der Plot läuft dann "mit").
Das "mitlaufen" und "nachschieben" von Werten ist erst mal nicht erforderlich. fronthem bekommt ja die Anfrage, alle x Sekunden die Serie für den Zietraum von t1 bis t2 zu liefern, wobei t1 und t2 relativ sind. Das bedeutet, dass SV mit jedem update die komplette Serie bekommt. Sonst würde das Zeitfenster, das man im Chart sehen will, nicht "wandern" sondern der Startpunkt bei t1 gleich bleiben und das Chart immer länger werden. Üblicherweise will man ja aber etwas wie "die letzten zwei Stunden" sehen. Und nach 1 Minute beginnen die letzten zwei Stunden eine Minute später.
Genau auf diese Strategie habe ich das Chart momentan implementiert.
Gerade beim tippen den Beitrag von bgewehr gesehen. Meinst Du das was ich meine?
Zitat von: herrmannj am 15 März 2015, 13:56:15
Am Ende muss der user eine option im Editor an die Hand bekommen bei der er sagt: "Temperatur von sensor x, Zeitraum, Auflösung".
Zeitraum muss man in fronthem Editor nicht festlegen, der wird von SV schon mitgeschickt.
Über den Editor ansich muss ich mal nachdenken, wie so was aussehen könnte. Kann man sich da nicht an den SVG-Editor anlehnen, den können die meisten vermutlich schon.
Zitat von: HCS am 15 März 2015, 16:03:55
Gerade beim tippen den Beitrag von bgewehr gesehen. Meinst Du das was ich meine?
Ja, genau!
Als Stufe 0 eine gute Lösung, finde ich!
{{ Chart.linechart([gad_line1, gad_line2, ...], xperiod, refreshtime) }} oder so ähnlich?
Zitat von: bgewehr am 15 März 2015, 15:54:44
Erstmal einfach gedacht:
Wenn ich angegeben habe, wo die historischen Werte herkommen, warum sollen dann die aktuellen Werte nicht auch daher kommen? Dann reicht es jedenfalls, eine Quelle abzugreifen und zu überwachen! Die meisten Charts müssen ja nicht ereignisgesteuert aktualisiert werden, weil eine definierte Aktualität ausreichend ist (1h oder 60s oder 5s).
Ja, das hab ich auch schon mal überlegt. Ich habe nur keine systemübergreifend kompatible Möglichkeit gefunden das als in Richtung push zu implementieren. Auf linux wäre inotify das Mittel der Wahl. Das muss aber im Kernel bereits kompiliert sein und mac und win machen das wieder ganz anders. Also Anlehnung an tail, wenn ihr wisst was ich meine. Alternativ müsste ich das pollen.
Wobei die Beschreibung von HCS jetzt anders ist. Ich bin bisher davon ausgegangen das ich einen Wert "nachschiebe" und sv aktualisisert das plot. Ich vertehe Dich (HCS) jetzt so das sv im Anstand von fix (Sekunden, Minuten) bei fhem um aktualisierte Daten bitten würde. Habe ich das richtig verstanden ? Dann wäre der von Bernd vorgeschlagene Weg gut (per poll)
Wie läuft das denn wenn ich zB ein Kardiogramm (nur um ein Beispiel zu illustrieren, nicht ernsthaft :D ) haben möchte. Da brauch ich doch dann 30 Werte pro Sekunde. Würde sv dann 30x pro Sekunde nachfragen ?
vg
jörg
Zitat von: bgewehr am 15 März 2015, 16:17:59
Ja, genau!
Als Stufe 0 eine gute Lösung, finde ich!
{{ Chart.linechart([gad_line1, gad_line2, ...], xperiod, refreshtime) }} oder so ähnlich?
In der doku ist doch "refreshtime" gar nicht erwähnt ? Gibts das ? Btw, wir sollten auch gleich mal im Hinterkopf haben das sich charts-widgets auch ganz easy bauen lassen und Erweiterungen mit bedenken.
vg
jörg
Koennte jemand ein schoenes Beispiel (==Bild) und ein Link zum Doku hier posten, ich wuerde gerne dieses Frontend im fhem.de "Frontend Screenshots" Abschnitt erwaehnen.
ja gern, bei doku sind wir (glaub ich) noch ziemlich blank ::)
edith: da könnten wir doch gleich mal einen thread "Deutschland sucht den SuperSmartVisuScreenshot" (DSDS) aufmachen :)
Zitat von: herrmannj am 15 März 2015, 16:24:58
Wobei die Beschreibung von HCS jetzt anders ist. Ich bin bisher davon ausgegangen das ich einen Wert "nachschiebe" und sv aktualisisert das plot. Ich vertehe Dich (HCS) jetzt so das sv im Anstand von fix (Sekunden, Minuten) bei fhem um aktualisierte Daten bitten würde. Habe ich das richtig verstanden ? Dann wäre der von Bernd vorgeschlagene Weg gut (per poll)
Schau nochmal hier: http://forum.fhem.de/index.php/topic,30909.msg267334.html#msg267334
Da habe ich es mit Beispielen erläutert.
Zitat von: herrmannj am 15 März 2015, 16:24:58
Wie läuft das denn wenn ich zB ein Kardiogramm (nur um ein Beispiel zu illustrieren, nicht ernsthaft :D ) haben möchte. Da brauch ich doch dann 30 Werte pro Sekunde. Würde sv dann 30x pro Sekunde nachfragen ?
Nein. Das funktioniert immer sinngemäß wie "monitor" für "normale" GADs.
SV fragt einmal beim Seitenwechsel mit
cmd": "series" die Charts an. Darauf hin liefert fronthem im gewünschten Intervall jeweils die komplette Serie, die dem Wunsch entspricht, solange, bis mit
cmd": "series" ein neuer Wunsch geäußert wird.
Ich wage auch zu behaupten, dass man den Fall "weitere Werte hinten anhängen" so gut wie nie will (was nicht bedeutet, dass man ihn nicht auch noch irgendwann haben darf) .
Man hat eine page mit einen Chart, das einen Temperaturverlauf der letzten zwei Stunden darstellt. Mit "nur anhängen" hätte man dann morgen einen Tag und zwei Stunden im Chart und in einer Woche ... usw.
Man will aber immer die letzten zwei Stunden.
Zu den Erweiterungsmöglichkeiten: siehe meinen verlinkten Beitrag, soweit es die Konfiguration des Charts angeht.
Da wir zw. SV und fronthem ein object übergeben, ist das auch beliebig erweiterbar.
Ob wir den von SV geerbten Mode (AVG, MIN, MAX) brauchen, ist mir noch unklar, aber kannst ihn ja einfach mal ignorieren.
Hallo,
ich bin ein wenig weiter gekommen, wobei ich meinen Reserve-Rpi neu aufgesetzt habe, um SmartVISU zu testen.
Ich habe die Config dort hinbekommen inkl. Config meiner TestConfig über das SmartVISU-Configmenü.
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
habe ich auch ausgeführt inkl. Neustart.
Ich bekomme bei dem Versuch zu definieren (define meinfronthem fronthem) aber immer folgenden Log-Eintrag (Rechte auf 777):
Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Danach habe ich auch schon gesucht und nochmal sudo cpanm Net::WebSocket::Server ausgeführt. Ergebnis:
Net::WebSocket::Server is up to date. (0.003001)
Kann mir jemand sagen, wie ich fortfahren sollte/könnte?
Danke!!!!
@HCS : ah ok, aber kurzer break.
Bei dem Beispiel hast Du ja schon ein customized chart - da würde ich einen kurzen step auf die eingebauten zurückgehen wollen (erst mal)
http://www.smartvisu.de/docu/2.7/index.php?page=plot/widget_plot.period
Interval ist doch (richtig?) hier die kleinste Auflösung, nicht das Aktualisierungs interval. Die driver versuchen doch Daten an bestehende plots anzuhängen. Nach meinem Verständnis sende ich initial eine Serie (geordnet über die Zeit, Auflösung min zoom size). Dann schiebe ich Daten hinterher und das plot hängt die rechts ran (und links fällt einer raus).
ZitatIch wage auch zu behaupten, dass man den Fall "weitere Werte hinten anhängen" so gut wie nie will (was nicht bedeutet, dass man ihn nicht auch noch irgendwann haben darf) .
Doch, ich schon aber vielleicht meinen wir etwas unterschiedliches. Wunsch lautet: ich hab (zB) auf meiner Seite einen plot mit temp der letzten 24h. Der läuft mit, aktualisiert sich fortlaufend.
mode: the mode: 'avg', 'sum', 'min', 'max'
Sehe ich auch, die logik müsste in fronthem liegen. Beispiel plot: tiefst- und höchsttemperaturen der letzten 30 Tage ... Bei sum bin ich mir unsicher wie ich das implementieren muss. Wozu könnte man das brauchen ? Energie, kumuliert ...
Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren. Idee: Man gibt an um welches device/reading es sich handelt, welches logfile und wie (regex?) die Daten im logfile liegen. Fronthem öffnet das log in einem child prozess (weil evtl langsam), und liefert die Daten, file bleibt offen. Das device/reading wird überwacht (gleiche logik wie jetzt item/GAD). Wenn ein passendes event reinkommt gebe ich dem child einen ping, der liest weiter die quelle (filelog) und schickt das an fronthem, das weiter an sv. So brauch ich nicht ständig zu pollen und die Signale werden trotzdem in realtime produziert. Im Idealfall kann aus device/reading sogar abgeleitet werden WIE das im log liegt, das wäre dann schon in etwa die Art des user comforts den ich ggern sehen würde (user braucht nicht mehr rum-regexen)
Ideen? Einwände? Vorschläge? Whatever ?
vg
jörg
Hi Mele,
fhwebsocket ist bestandteil im git. Ich vermute das bei Dir das update nicht korrekt arbeitet. Frag mich nicht warum :) aber schau mal ins git und schau mal ob Du die files alle hast. fhem ist aktuell ? Wenn nein, updaten bitte läuft sonst eh nicht.
vg
jörg
Zitat von: HCS am 15 März 2015, 16:03:55
Das mit dem basic.lbutton habe ich anlysiert. Das ist ein Widget, das gar keinen Update-handler hat. Somit kann man natürlich auh keinen aufrufen. Da sollte aber mit der letzten Treiber-Version das Laden der Seite nicht mehr anhalten, da das abgefangen ist. Steht nur als info in der Konsole.
Danke für die Handler funktioniert es jetzt.
Ich hatte aber noch 3 andere Fehler behoben! Jetzt läuft es wieder vernünftig! Bei mir ist es aber nur mit Pagecach richtig schnell.
Bei den Fehlern wundert mich einiges. Folgende Funktionen funktionieren jetzt nicht mehr
response[0].replace(/ü/g, "ü")
response[0].match(/prog[123]/g)Das mit den Umlauten ist ja glaube ich gelöst. Nur warum es nicht mehr funktioniert würde mich interessieren.
Weiterhin nimmt der Treiber jetzt fehlende Bilddateien übel. Ich hatte auf meiner Wetterseite ein Platzhalter n_Ersetzen_S.png eingefügt. Jetzt wurden meiner Bilder aber nicht mehr angezeigt. Erst als ich entsprechende Dateien im Ordner erstellt habe hat diese Seite wieder funktioniert und ich konnte den Dummi ersetzen.
Gruß Lutz
Zitat von: herrmannj am 15 März 2015, 19:53:42
Hi Mele,
fhwebsocket ist bestandteil im git. Ich vermute das bei Dir das update nicht korrekt arbeitet. Frag mich nicht warum :) aber schau mal ins git und schau mal ob Du die files alle hast. fhem ist aktuell ? Wenn nein, updaten bitte läuft sonst eh nicht.
vg
jörg
Leider keine Veränderung. Habe die Files aus dem git übernommen. Rechte 777, chmod für user fhem. Update check: nothing to do ...
Noch eine Idee?
start mal über die cmd line und schau nach Meldungen.
vg
jörg
Zitat von: herrmannj am 15 März 2015, 20:46:23
start mal über die cmd line und schau nach Meldungen.
vg
jörg
Damit kann ich nichts anfangen. Beispiel? In FHEM oder Putty?
oh ha. .. log Dich mal auf dem cubi ein, geh console. Beende fhem (service fhem stop), geh in das fhem Verzeichnis (/opt/fhem ?) und starte dort fhem mit perl fhem.pl fhem.cfg.
vg
jörg
Zitat von: herrmannj am 15 März 2015, 20:53:33
oh ha. .. log Dich mal auf dem cubi ein, geh console. Beende fhem (service fhem stop), geh in das fhem Verzeichnis (/opt/fhem ?) und starte dort fhem mit perl fhem.pl fhem.cfg.
vg
jörg
Erledigt, danach im WebIF:
Error messages while initializing FHEM:
configfile: Cannot load module fronthem
Cannot load module fronthemDevice
Zitat von: herrmannj am 15 März 2015, 19:41:40
Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren.
Ideen? Einwände? Vorschläge? Whatever ?
Ich denke die wichtige Überlegung ist Systemlast. Wenn nur die neuen Punkte im refreshzyklus übertragen werden müssen, ist das evtl günstiger als wenn jedesmal alle Daten übertragen werden müssen, erzeugt aber auf der SV Seite eine Aufgabe der Rekombination der Historie mit den neuen Daten.
Wann muss denn ein Chart aktualisiert werden? Da wir ja kein EKG haben, reicht ja ein Zyklus von 5 min, 30s oder 10s sicher immer aus, oder?
Allerdings müssten dann alle x Sekunden alle Daten neu übertragen werden, obwohl die meisten schon da sind, was unglücklich erscheint! Der Mehraufwand des Nachschiebens neuer Daten und des Löschens von alten ist aber auch nicht null.
Wie wäre es, wenn man grundsätzlich vereinbart, dass ein Chartempfänger auf der SV Seite grundsätzlich JSON Pakete empfangen kann, die 1-n Datensätze aus [X, Y1, Y2, ...] beinhalten. Beim initial fill schiebt man einmal den aktuellen Stand rüber und bei jedem scheduled refresh dann nur noch die Differenz bis jetzt. Der JS code des Charts schiebt immer nur die empfangenen Daten zusätzlich ins Chart. Das Chart hat eine definierte x-Länge, also fliegen alte Daten hinten raus. Die Daten können dabei aus derselben Quelle kommen, das ist ja egal für das Ergebnis.
Eine Aktualisierung der Charts bei jedem Datenevent kann auch deutlich zu oft sein, das würde ich gar nicht anstreben.
Zitat von: herrmannj am 15 März 2015, 19:41:40
Bei dem Beispiel hast Du ja schon ein customized chart - da würde ich einen kurzen step auf die eingebauten zurückgehen wollen (erst mal)
Das würde ich nicht machen. Das endet sicher damit, dass wir das wegwerfen und doch mit einem eigenen enden.
Der Domitiga kann übrigens überhaupt keine plots ansteuern, auch die originalen von SV nicht.
Zitat von: herrmannj am 15 März 2015, 19:41:40
Interval ist doch (richtig?) hier die kleinste Auflösung, nicht das Aktualisierungs interval.
Das ist das Intervall, in dem die Serie geschickt werden soll.
Eine Auflösung hatte ich noch gar nicht im Focus. Die stelle ich mir aber auch schwierig vor, wenn die geloggten Werte in einem unregelmäßigen zeitlichen Abstand sind.
Zitat von: herrmannj am 15 März 2015, 19:41:40
Doch, ich schon aber vielleicht meinen wir etwas unterschiedliches. Wunsch lautet: ich hab (zB) auf meiner Seite einen plot mit temp der letzten 24h. Der läuft mit, aktualisiert sich fortlaufend.
Genau das macht meine Implementierung seit einigen Wochen. In dem Beispiel aus dem Link ist ein Chart mit Temperaturen, das immer genau die letzten zwei Tage darstellt. Alle 5 Minuten wird es aktualisiert, da schickt mein addon Treiber die komplette neue Serie rüber.
Zitat von: herrmannj am 15 März 2015, 19:41:40
Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren. Idee: Man gibt an um welches device/reading es sich handelt, welches logfile und wie (regex?) die Daten im logfile liegen. Fronthem öffnet das log in einem child prozess (weil evtl langsam), und liefert die Daten, file bleibt offen. Das device/reading wird überwacht (gleiche logik wie jetzt item/GAD). Wenn ein passendes event reinkommt gebe ich dem child einen ping, der liest weiter die quelle (filelog) und schickt das an fronthem, das weiter an sv. So brauch ich nicht ständig zu pollen und die Signale werden trotzdem in realtime produziert. Im Idealfall kann aus device/reading sogar abgeleitet werden WIE das im log liegt, das wäre dann schon in etwa die Art des user comforts den ich ggern sehen würde (user braucht nicht mehr rum-regexen)
Da stellt sich die Frage: will man, dass ein Chart alle x Minuten, Stunden, .. aktualisiert wird oder will man eine Aktualisierung, sobald sich in dem zugrundeliegenden Log etwas ändert.
Wir könnten das aber auch beides realisieren. Wenn man in der Definition des Widget als Intervall anstatt einem Wert (10s, 60s, ...) "OnChange" angibt, dann könnte fronthem die Daten schicken, sobald ein neuer Wert vorliegt, im anderen Fall alle n Sekunden.
Zitat von: herrmannj am 15 März 2015, 19:41:40
Nach meinem Verständnis sende ich initial eine Serie (geordnet über die Zeit, Auflösung min zoom size). Dann schiebe ich Daten hinterher und das plot hängt die rechts ran (und links fällt einer raus).
Mein bisheriger Plan war, dass fronthem immer die komplette Serie schickt, nicht nur initial sondern auch danach.
Bei den Highcharts fällt links erst mal nichts raus. Der Treiber müsste den Wert ganz links rausnehmen. Das ist aber nicht so einfach.
Beispiel: SV fordert eine Serie für die letzten zwei Stunden an, in FHEM gbit es aber nur Werte für die letzte Stunde. Dann müsste der Treiber erkennen, dass der Wert links nicht weg darf, weil wir noch keine zwei Stunden haben.
Da ist es viel einfacher, in fronthem einfach grundsätzlich bis max. zwei Stunden rückwärts zu holen und stumpf zu liefern und den Treiber das Chart aktualisieren zu lassen.
Zitat von: bgewehr am 15 März 2015, 20:58:37
IWie wäre es, wenn man grundsätzlich vereinbart, dass ein Chartempfänger auf der SV Seite grundsätzlich JSON Pakete empfangen kann, die 1-n Datensätze aus [X, Y1, Y2, ...] beinhalten. Beim initial fill schiebt man einmal den aktuellen Stand rüber und bei jedem scheduled refresh dann nur noch die Differenz bis jetzt. Der JS code des Charts schiebt immer nur die empfangenen Daten zusätzlich ins Chart. Das Chart hat eine definierte x-Länge, also fliegen alte Daten hinten raus. Die Daten können dabei aus derselben Quelle kommen, das ist ja egal für das Ergebnis.
Du schreibst das immer, während ich es auch gerade schreibe :D
Das Chart links zu begrenzen ist eine Sache. Das Problem ist, dass die Werte aus der Datenquelle des Chart (Array) auch raus müssen, sonst zeigt man im Chart zwar nur zwei Tage an, hat aber im Array "3 Monate" drin, was nicht lange gut geht.
Auch wenn es etwas Übertragungsoverhead ist, die stressfreiste und am wenigsten fehlerträchtigste Variante ist komplett schicken.
Mein Ölstand-Chart hat knapp 2000 Werte und aktualisiert z.Zt. testweise alle 10 Sekunden. Da merkt man nichts davon und man sieht auch nichts, da die Highcharts sehr smooth aktualisieren.
Zitaterzeugt aber auf der SV Seite eine Aufgabe der Rekombination der Historie mit den neuen Daten.
Ja, das macht der driver (soll er machen)
ZitatWann muss denn ein Chart aktualisiert werden? Da wir ja kein EKG haben, reicht ja ein Zyklus von 5 min, 30s oder 10s sicher immer aus, oder?
Ich würde da jetzt keinen künstlichen Engpass einbauen wollen. Ob jeder Wert (event) Sinn macht läßt sich mMn nicht so pauschal beantworten.
Nehme ich den aktuellen Energieverbrauch in einer Sicht von 20min hätte ich sicher schon jeden. Mach ich das gleiche auf 14Tage - Sicht brauch ich das nicht. Generell hat so ein plot ja irgendeine Auflösung, schon rein physikalisch auf dem Screen. Die Dichte der Daten müsste sich doch dann an der Auflösung (und evtl gewünschter Zoomfähigkeit) orientieren. Dazu müsste fronthem evtl Daten verdichten (wenn der sensor schneller liefert als Datenpunkte dargestellt werden können)
Bzgl des Daten Paketes brauchen wir mMn keine "neue Vereinbarung" , die plots sind doch schon Bestandteil von sv und ich würde mich dafür aussprechend as erst einmal so zu bedienen - die Kür können wir ja danach mit eigenen widget plots machen.
vg
jörg
Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...
ZitatDas würde ich nicht machen. Das endet sicher damit, dass wir das wegwerfen und doch mit einem eigenen enden.
Nur mal für mich zum Verständnis, woher kommen denn die Vorbehalte gegenüber den mitgelieferten plots - die sehen doch ganz charmant aus ?
ZitatWir könnten das aber auch beides realisieren. Wenn man in der Definition des Widget als Intervall anstatt einem Wert (10s, 60s, ...) "OnChange" angibt, dann könnte fronthem die Daten schicken, sobald ein neuer Wert vorliegt, im anderen Fall alle n Sekunden.
Das hört sich gut an - check.
ZitatDas Problem ist, dass die Werte aus der Datenquelle des Chart (Array) auch raus müssen, sonst zeigt man im Chart zwar nur zwei Tage an, hat aber im Array "3 Monate" drin, was nicht lange gut geht.
Berechtigter Hinweis - das sollten wir im Auge behalten.
Mit Sicht auf die perfomance bin ich mir trotzdem sicher das es besser ist die Daten nur zu ergänzen und die alten Werte aus dem array zu nehmen. Als ich fronthem geschrieben habe wär ich auch nie auf die Idee gekommen das jemand jammert weil 600 GADs einige Sekunden brauchen ;D
vg
jörg
Zitat von: bgewehr am 15 März 2015, 21:20:37
Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...
ich hab den post verpasst, nimm mich mal mit bitte. Für mich sehen die Originale ok aus (was nicht gegen Erweiterungen spricht - das wird kommen!)
vg
jörg
Zitat von: bgewehr am 15 März 2015, 21:20:37
Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts
Das hatte ja schon völlig verdrängt. Das geht meiner Ansicht nach gar nicht.
Um Jörg abzuholen: http://forum.fhem.de/index.php/topic,30909.msg262386/topicseen.html#msg262386
Zitat von: herrmannj am 15 März 2015, 21:24:37
Nur mal für mich zum Verständnis, woher kommen denn die Vorbehalte gegenüber den mitgelieferten plots - die sehen doch ganz charmant aus
Ja. Nur technisch ist das nix.
Die angedockten Parameter.
Keinerlei Konfigurationsmöglichkeit
...
siehe Link oben
Zitat von: bgewehr am 15 März 2015, 21:20:37
Nach den Erfahrungen von HCS mit den blöde angedockten Parametern in den Originalcharts würde ich auch lieber sofort eine neue Chart-widget-Serie beginnen, das ist ja nicht weniger SV- konform. Wir kriegen da sicher was hübsches hin...
Ich habe schon was hübsches ;)
Es sind eh nur zwei, die es da gibt. Den period (habe ich fertig) und den rtr, der auch ein period ist, auf dem noch ein PacMan Chart für die Ventilstellung mit drauf ist. Das kann man beides mit einem erledigen.
ok, die Parameter sind echt blöd. Ich schau mal in den anderen drivern.
Die Series (@fronthem und im driver) so gestalten das sie mit den orignal plots und custom charts laufen muss also klares Ziel sein.
vg
jörg
Zitat von: herrmannj am 15 März 2015, 21:46:23
Die Series (@fronthem und im driver) so gestalten das sie mit den orignal plots und custom charts laufen muss also klares Ziel sein.
Warum?
Damit dokumentierte und beschriebene widgets (plot - out of the box) verwenden kann. Ich seh da auch kein Problem, ich habe fronthem, den driver und Du die charts im Zugriff - woran soll es scheitern ?
vg
jörg
btw, hat jemand einen schicken screenshot / Bild für rudi -> die homepage ?
Das bedeutet, zwei Wege zu implementieren, nur um etwas, das man vollständig durch etwas Besseres ersetzt hat und das nicht mehr kann, auch verwenden zu können. Das verkompliziert die Implementierung, man muss sich später mit beidem (Plots und Charts) bei der Fehlersuche und Unterstützung der Anwender rumschlagen und hat aus FHEM-Sicht keinen Vorteil. Außer, dass man von SV evtl. eines Tages ein weiteres Widget geschenkt bekommt und es einfach verwenden kann.
wieso zwei Wege ? Sorgen wir dafür das es einer ist !
Ein Weg geht nicht. Entweder die Parameter sind an das GAD hinten dran geschlüsselt (original SV) oder wir übergeben eine vernünftige Struktur. Wenn man beides will, muss man je nach Widget unterschiedlich verfahren.
Auch eine Umsetzung von den Alten im Treiber auf eine Struktur ist eine Aktion.
Mein erster Anlauf war, sie rauszuparsen. Habe ich verworfen. Das ist annähernd unmöglich, besonders, wenn man GADs anlegt, die selbst Punkte im Namen haben und SV 1.8 weitere hinten erfindet. Da passt kein von hinten parsen und kein von vorne parsen, dass ist alles lotto spielen.
Zitat von: herrmannj am 15 März 2015, 21:52:00
Damit dokumentierte und beschriebene widgets (plot - out of the box) verwenden kann.
Es gibt inzwischen eine Menge gute Widgets, die nicht in SV dokumentiert sind, weil sie hier erfunden wurden.
@HCS, die Kommunikation (-> Datenstruktur!) in Deinem Beispiel ist gut, passt!
Für avg und sum benötigen wir einen timeframe. Lass uns "interval" dafür nehmen. Mit "refresh" darf sich sv eine Aktualisierungsrate wünschen, alternativ (für plot.*) der im editor vorgegeben Interval (oder on-event).
Fronthem muss dafür sorgen das es einen Startwert gibt (auch wenn der außerhalb der angezeigten Zeitspanne liegt) und ist in diesem Rahmen für min,max,sum und avg zuständig. avg == Einzelwert innerhalb eines "interval".
Die Datendichte ergibt sich aus Anzeigedauer plus Zoom was bedeutet das zoom (minimum time while zooming in sec) auch übertragen werden muss bzw in Interval enthalten sein muss.
Dann haben wir das rund, oder ?
vg
jörg
ZitatMein erster Anlauf war, sie rauszuparsen. Habe ich verworfen. Das ist annähernd unmöglich, besonders, wenn man GADs anlegt, die selbst Punkte im Namen haben und SV 1.8 weitere hinten erfindet.
Ach was, das geht! smarthome.py muss das ja auch wieder auseinander-basteln.
Die lassen sich doch von von hinten nach vorn entwirren - das Format ist doch starr,
Zitat von: herrmannj am 15 März 2015, 22:30:34
Für avg und sum benötigen wir einen timeframe. Lass uns "interval" dafür nehmen. Mit "refresh" darf sich sv eine Aktualisierungsrate wünschen, alternativ (für plot.*) der im editor vorgegeben Interval (oder on-event).
Kannst Du das nochmal andres erläutern? Ist mir jetzt nicht klar, was Du meinst.
Zitat von: herrmannj am 15 März 2015, 22:30:34
Fronthem muss dafür sorgen das es einen Startwert gibt (auch wenn der außerhalb der angezeigten Zeitspanne liegt) und ist in diesem Rahmen für min,max,sum und avg zuständig. avg == Einzelwert innerhalb eines "interval".
Mit einem Startwert vor den echten Daten entsteht ein Chart, das von links kommend eine Linie ausgehend vom Startwert bis zum ersten echten Wert hat.
Den min,max,sum und avg Part habe ich nicht verstanden. Was meinst Du damit?
Zitat von: herrmannj am 15 März 2015, 22:30:34
Die Datendichte ergibt sich aus Anzeigedauer plus Zoom was bedeutet das zoom (minimum time while zooming in sec) auch übertragen werden muss
Ja, kann ich mitschicken.
Würde 0 dann bedeuten: "alles was zu bekommen ist, ohne die Daten zu verdichten" ?
Zitat von: herrmannj am 15 März 2015, 22:33:00
Ach was, das geht! smarthome.py muss das ja auch wieder auseinander-basteln.
Die lassen sich doch von von hinten nach vorn entwirren - das Format ist doch starr,
Schau dir mal das widget der kommenden 1.8 im SV trunk an. Das hängt hinten einen weiteren Parameter an. Nix starr.
Meine Buchstaben sind alle, muss morgen neue kaufen. :)
Dann können wir morgen mal das Format, mit dem der Treiber bei SV anfragt, detaillieren.
so machen wir das, muss auch neue Buchstaben bestellen ;)
Zitat von: herrmannj am 15 März 2015, 21:54:15
btw, hat jemand einen schicken screenshot / Bild für rudi -> die homepage ?
Weis nicht ob es schön ist! Mir gefällts! 8)
Zitat von: cruser1800 am 15 März 2015, 23:02:40
Weis nicht ob es schön ist! Mir gefällts! 8)
Kommen die Wetterdaten von yr.no/Wunderground oder FHEM? Wenn ersteres wäre das Beispiel eher suboptimal, oder? ;D
wieso ? btw, ich mal mal schnell den dsds thread ...
Zitat von: herrmannj am 16 März 2015, 11:12:48
wieso ? btw, ich mal mal schnell den dsds thread ...
Galt das "wieso?" mir?
Naja, ein FHEM-Frontend mit der einzigen Seite zu "bewerben", die keinerlei FHEM-Anbindung benötigt ist ein bißchen so als würde man sein Webdesign mit der "It works"-Seite vom Apachen vorstellen. ;)
Den ersten Screenshot finde ich aber gut.
axo - ja stimmt schon. Btw, ich hab den dsds thread aufgemacht, also immer rin damit :D
Hier der überarbeitete Vorschlag, was der Treiber an fronthem sendet, um Serien für Charts anzufragen:
{
"cmd": "series",
"items": [
{
"gad": "hcs.data.OilLevelChart",
"mode": "avg",
"start": "7y",
"end": "now",
"interval": "300",
"minzoom": "12960000"
},
{
"gad": "hcs.data.OilConsumptionChart",
"mode": "avg",
"start": "5y 6m",
"end": "1y",
"interval": "OnChange",
"minzoom": "0"
}
]
}
Die erste angeforderte Serie:
gad und mode ist klar
start: serie beginnt vor 7 Jahren
end: serie endet mit dem letzten verfügbaren Wert
interval: alle 300 Sekunden schicken
minzoom: meine kleinste Zoomstufe sind 12960000 Sekunden = ein Tag, fronthem darf die Daten so verdichten, dass dieser Zoom noch etwas sinvolles darstellt.
Die zweite angeforderte Serie:
gad und mode ist klar
start: serie beginnt vor 5 Jahren und 6 Monaten
end: serie endet vor einem Jahr
interval: sobald es im logfile einen neuen Wert gibt die Serie schicken
minzoom: die Daten nicht verdichten, alle vorhandenen Werte ausliefern.
Ich hänge noch ein JSON an, wie eine Serie, die von fronthem geliefert wird, aussieht.
Könntest Du in fronthem kurzfristig einbauen, dass es auf ein beliebiges "cmd": "series" immer ganz stumpf mit den angehängten Daten antwortet?
Dann könnte ich die Aktualisierung der Charts, wenn die Daten von fronthem kommen, implementieren und du hättest eine funktionierende Gegenstelle zum Testen, sobald Du echte Daten lieferst.
Zitat von: Carsten am 16 März 2015, 11:11:36
Kommen die Wetterdaten von yr.no/Wunderground oder FHEM? Wenn ersteres wäre das Beispiel eher suboptimal, oder? ;D
Die Daten kommen über Wetter.com, da finde, dass die es am besten treffen ;)
@cruser hab Dich in den dsds thread verlinkt. vg jörg
Zitat von: Carsten am 16 März 2015, 11:21:28
Galt das "wieso?" mir?
Naja, ein FHEM-Frontend mit der einzigen Seite zu "bewerben", die keinerlei FHEM-Anbindung benötigt ist ein bißchen so als würde man sein Webdesign mit der "It works"-Seite vom Apachen vorstellen. ;)
Den ersten Screenshot finde ich aber gut.
Die Daten kommen alle über FHEM. Da es meine Seite mit den meisten Gad's ist habe ich diese als Bsp. mit dargestellt was machbar ist!
Zitat von: mele am 15 März 2015, 19:33:13
Ich bekomme bei dem Versuch zu definieren (define meinfronthem fronthem) aber immer folgenden Log-Eintrag (Rechte auf 777):
Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.
Danach habe ich auch schon gesucht und nochmal sudo cpanm Net::WebSocket::Server ausgeführt. Ergebnis:
Net::WebSocket::Server is up to date. (0.003001)
So, habe die Lösung gefunden.
Bei der Auführung des Codes
curl -L https://cpanmin.us | perl - --sudo App::cpanminus
sudo cpanm Net::WebSocket::Server
sudo cpanm JSONwar ich als root angemeldet und nicht als user fhem.
Vielleicht könnte man das noch in das Installations-Wiki aufnehmen.
Gruß
Manuel
Hallo Manuel,
root wäre aber OK - das ist was spezielles in Deiner Installation. Das "sudo" macht ja nix anderes als Dich zum root ...
vg
jörg
Zitat von: HCS am 16 März 2015, 12:35:54
Hier der überarbeitete Vorschlag, was der Treiber an fronthem sendet, um Serien für Charts anzufragen:
{
"cmd": "series",
"items": [
{
"gad": "hcs.data.OilLevelChart",
"mode": "avg",
"start": "7y",
"end": "now",
"interval": "300",
"minzoom": "12960000"
},
{
"gad": "hcs.data.OilConsumptionChart",
"mode": "avg",
"start": "5y 6m",
"end": "1y",
"interval": "OnChange",
"minzoom": "0"
}
]
}
Die erste angeforderte Serie:
gad und mode ist klar
start: serie beginnt vor 7 Jahren
end: serie endet mit dem letzten verfügbaren Wert
interval: alle 300 Sekunden schicken
minzoom: meine kleinste Zoomstufe sind 12960000 Sekunden = ein Tag, fronthem darf die Daten so verdichten, dass dieser Zoom noch etwas sinvolles darstellt.
Die zweite angeforderte Serie:
gad und mode ist klar
start: serie beginnt vor 5 Jahren und 6 Monaten
end: serie endet vor einem Jahr
interval: sobald es im logfile einen neuen Wert gibt die Serie schicken
minzoom: die Daten nicht verdichten, alle vorhandenen Werte ausliefern.
Ich hänge noch ein JSON an, wie eine Serie, die von fronthem geliefert wird, aussieht.
Könntest Du in fronthem kurzfristig einbauen, dass es auf ein beliebiges "cmd": "series" immer ganz stumpf mit den angehängten Daten antwortet?
Dann könnte ich die Aktualisierung der Charts, wenn die Daten von fronthem kommen, implementieren und du hättest eine funktionierende Gegenstelle zum Testen, sobald Du echte Daten lieferst.
Hi HCS,
das sieht sehr gut aus. Gib mir mal ein wenig Zeit (Tage+), ich fange mal an den Editor und den thread (fork) dafür auf zu bauen. Mag sein das währenddessen was auftaucht, als Ausgangslage perfekt.
Benutzt jemand db-log und hat insights zu dessen funktion ?
vg
jörg
Mag sein, kann ich nicht wiederlegen. Vielleicht hilft es irgendwann Jemandem, der nicht weiterweiß.
Ich komme leider zu dem nächsten Problem.
Ich habe den Ordner MeinHaus erstellt, die Dateien hineinkopiert und die Konfiguration vorgenommen (IP Webserver 192.168.178.22; IP FHEM 192.168.178.250)
Leider sehe ich beim Öffnen von http://192.168.178.22/smartvisu/pages/MeinHaus nur Quelltext.
Zur Verdeutlichung habe ich zwei Screenshots angehängt.
Weiß jemand Rat?
Ruf mal
http://192.168.178.22/smartvisu/ (http://192.168.178.22/smartvisu/)
auf ;)
Zitat von: mele am 17 März 2015, 09:04:27
war ich als root angemeldet und nicht als user fhem.
Und wie hast du dich als user fhem angemeldet?
Zitat von: marvin78 am 17 März 2015, 09:25:33
Ruf mal
http://192.168.178.22/smartvisu/ (http://192.168.178.22/smartvisu/)
auf ;)
Prinzip verstanden! DANKE!
Zitat von: herrmannj am 17 März 2015, 09:15:59
das sieht sehr gut aus. Gib mir mal ein wenig Zeit (Tage+), ich fange mal an den Editor und den thread (fork) dafür auf zu bauen. Mag sein das währenddessen was auftaucht, als Ausgangslage perfekt
OK, bekommst einige Tage.
Zitat von: herrmannj am 17 März 2015, 09:15:59Benutzt jemand db-log und hat insights zu dessen funktion ?
Ich nicht
Hallo zusammen,
hat von euch schon jemand multimedia.music integrieren können?
Ich hab es so definiert:
{{ multimedia.music('iTunesiMac', 'iTunes_play', 'iTunes_ff', 'iTunes_next', 'iTunes_pos', 'iTunes_vol', 'iTunes_title', 'iTunes_artist', 'iTunes_repeat', 'iTunes_playlist') }}
nur leider erscheinen die GAD´s nicht in Fhem...
Habt ihr eine Idee??
Hast du die Widget-Datei denn mit
{% import "multimedia.html" as multimedia %}
importiert?
@marvin78
hab ich das oben geschrieben? Ohhh man(n) sorry...
...der Wald, die Bäume und ein paar Wochen nicht mehr aktiv gewesen... ;D
Danke für den Zaunpfahl...
MFG RockSteadyBeat
Hi RockSteadyBeat,
mit welchen devices verbindest du denn die GAD's? Streamst du Musik? Wenn ja...wie?
Gruß, der Sloot
Hallo jsloot,
ich nutze das iTunes-Modul von justme1968 aus diesem Beitrag: http://forum.fhem.de/index.php/topic,11830.0.html (http://forum.fhem.de/index.php/topic,11830.0.html)
Bei mir läuft nen Mac 24/7 deshalb geht das ohne Probleme... ;)
MFG RockSteadyBeat
@herrmannj: Ich hätte noch eine Erweiterung zum Protokoll zw. fronthem und Treiber:
um die beiden Fälle bei der Aktualisierung einer Serie "Serie jedes mal komplett schicken" und "nur neue Werte schicken" handhaben zu können, sollten wir das im Protokoll vorsehen, dass SV es wünschen kann und fronthem mitteilen kann, was es da gerade schickt (nur so hat der Treiber eine Chance zu wissen, was er damit machen soll).
Die Anfrage würde ich so erweitern:
"cmd": "series",
"items": [
{
"gad": "hcs.data.OilLevelChart",
"mode": "avg",
"start": "7y",
"end": "now",
"interval": "300",
"minzoom": "12960000",
"updatemode": "complete"
},
{
"gad": "hcs.data.OilConsumptionChart",
"mode": "avg",
"start": "5y 6m",
"end": "1y",
"interval": "OnChange",
"minzoom": "0",
"updatemode": "additional"
}
]
}
updatemode kann "complete" sein, bedeutet, immer die komplette Serie schicken oder "additional", bedeutet, nur die neuen Werte schicken.
Wenn fronthem eine Serie schickt, dann teilt es darin mit, was das ist, was es schickt:
{
"cmd": "series",
"items": {
"gad": "hcs.data.OilLevelChart",
"updatemode":"complete",
"plotdata": [
[
"x-Value1",
"y-value1"
],
[
"x-Value2",
"y-value2"
],
[
"x-Value3",
"y-value3"
]
]
}
}
In diesem Beispiel sagt es mit "updatemode":"complete", dass es sich um eine komplette Serie handelt, die geschickt wird.
Ich schlage vor, dass wir im ersten Schritt das "complete" Szenario machen, mit meinem chart.period widget, das genau diesen Fall bereits beherscht.
Wenn das so weit läuft, können wir die restlichen Varianten Stück für Stück aufbauen.
Kannst Du mir mal bitte noch Schreibrechte auf das herrmannj/smartvisu-widgets repository geben, dass ich das chart widget reinpacken kann?
Wenn wir mit dieser Erweiterung konform sind, dann veröffentliche ich heute oder morgen einen Treiber, der bei fronthem entsprechend anfrägt und den complete update für das chart widget kann.
Hat jemand vielleicht ein paar html Codes da, um die icons für eine Fernbedienung schön auszurichten,
ich war gestern 4 std drann aber es sieht nicht wirklich ansprechend aus!
Ich hätte gerne links senkrecht 3 buttons ohne Abstand zu einander----dann mit Abstand, ein 9 Tastenfeld, wieder Abstand und 2 seknrechte. Die In der Höhe passen! Also alles auf einer Linie. Ich erreiche es nur soweit, das alles untereinander ist und Abstand zu einander hat, also links dann darunter rechts und darunter mitte! Weiter gibt es auch eine Controlgroup Vertikal?
Und wie kann man mini und Medi Buttons ausrichten, so das es optisch etwas her macht!
Danke im Voraus :o
Zitat von: HCS am 19 März 2015, 09:05:29
@herrmannj: Ich hätte noch eine Erweiterung zum Protokoll zw. fronthem und Treiber:
gut Idee
Zitat
Kannst Du mir mal bitte noch Schreibrechte auf das herrmannj/smartvisu-widgets repository geben, dass ich das chart widget reinpacken kann?
Logisch, brauch nur Deinen github user account
Zitat
Wenn wir mit dieser Erweiterung konform sind, dann veröffentliche ich heute oder morgen einen Treiber, der bei fronthem entsprechend anfrägt und den complete update für das chart widget kann.
Ich bin noch nicht dazugekommen fronthem in diese Richtung zu erweitern und rechne da insgesamt auch mit größeren Umabauten, von daher bitte keine Hektik :)
Umbau:
Idee den Editor um die plot Seite zu erweitern:
- man gibt das device und das reading an wo die Daten herkommen.
- fronthem schaut sich dann alle filelog definitionen und prüft welche damit matchen
- die werden dann als dropdown angeboten (analog zu den converter), man wählt den richtigen aus.
fronthem forkt beim start ein modul welches das "mechanische" lesen aus den logfiles übernimmt.
wenn ein "monitor" mit entsprechender Anfrage reinkommt gibt fronthem das an den fork, der beginnt zu lesen, reicht die Ergebnisse (evtl in chunks) an fronthem und fronthem reicht das an sv. (bedeutet der driver sollte mit chunks klarkommen, das wird sich aber finden)
Für mich ist zu evaluieren
- ob die Angabe device/reading in Bezug auf das finden in den logs alle Anwendungsfälle abdeckt. (Erweiterung regex wäre denkbar, evtl "experten modus" im editor)
- wie geht man damit um . "T:21 H:52" - landet so i log aber ich will nur "T" plotten. (converter ?)
- converter evtl auch notwendig um aus 0/1 "auf" und "zu" zu machen. Brenner "an" "aus" / "open" "closed" etc.
Da liegt also noch Wegstrecke vor uns :)
vg
jörg
Zitat von: herrmannj am 19 März 2015, 10:33:41
...von daher bitte keine Hektik :)
Es läuft alles ganz cool und ruhig ;)
Ich habe aber im Treiber noch Dinge drin, die ich gerne unters Volk bringen würde, z.B. den Fallback bei den delegates ("Bernd-Kompatibilität") und noch einiges.
Darum würde ich gerne die Treiber-Version offiziell machen.
Die Implementierung der Charts auf Treiberseite ist auch bereits drin und läuft bei mir schon seit Wochen auf dem Produktivsystem. Wenn ich die Kleinigkeit "updatemode" nun noch einbaue, dann ist das mal ein Stand. Dass es der Treiber schon kann und Du ganz in Ruhe die Gegenstelle baust, ist ja nicht schlimm.
Zitat von: herrmannj am 19 März 2015, 10:33:41
...Logisch, brauch nur Deinen github user account
Der, mit dem ich auch schon auf smartvisu-cleaninstall schreiben darf.
Zitat von: herrmannj am 19 März 2015, 10:33:41
(bedeutet der driver sollte mit chunks klarkommen, das wird sich aber finden)
Da kannst Du mich wirklich nicht für begeistern (um es im ersten Anlauf mal ganz dezent zu formulieren).
Zitat von: herrmannj am 19 März 2015, 10:33:41
Umbau:
Idee den Editor um die plot Seite zu erweitern:
- man gibt das device und das reading an wo die Daten herkommen.
- fronthem schaut sich dann alle filelog definitionen und prüft welche damit matchen
- die werden dann als dropdown angeboten (analog zu den converter), man wählt den richtigen aus.
Für mich ist zu evaluieren
- ob die Angabe device/reading in Bezug auf das finden in den logs alle Anwendungsfälle abdeckt. (Erweiterung regex wäre denkbar, evtl "experten modus" im editor)
- wie geht man damit um . "T:21 H:52" - landet so i log aber ich will nur "T" plotten. (converter ?)
- converter evtl auch notwendig um aus 0/1 "auf" und "zu" zu machen. Brenner "an" "aus" / "open" "closed" etc.
Da muss ich jetzt erstmal drüber nachdenken, evtl. beim Radfahren ;)
ZitatDer, mit dem ich auch schon auf smartvisu-cleaninstall schreiben darf.
done
ZitatDa kannst Du mich wirklich nicht für begeistern (um es im ersten Anlauf mal ganz dezent zu formulieren).
das kommt noch 8)
ZitatDa muss ich jetzt erstmal drüber nachdenken, evtl. beim Radfahren ;)
Du hast noch was vom Leben :D
Zitat von: herrmannj am 19 März 2015, 11:31:02
done
Ja, danke. Hat mir git auch gerade mitgeteilt.
Zitat von: herrmannj am 19 März 2015, 11:31:02
Du hast noch was vom Leben :D
Ja. Mit 'nem Treiber auf dem Gepäckträger einen Berg hochradeln und das Publikum am Wegesrand ruft "zu langsam ..." :D :D :D
Wer den Zusammenhang mit Radfahren verstehen will, der muss den dsds thread lesen ;)
Hi,
Zitat von: Badflex am 13 März 2015, 13:30:25
Jetzt läuft's sehr gut im IE.
Ich weiß nicht obs am Treiber liegt. Bei mir waren vorher die eingestellten Uzsu schaltzeiten angezeigt.
Jetzt macht er es nicht mehr.
ist zwar schon etwas her, aber ich denke immer noch aktuell.
ich habe heute mal das UZSU Widget eingebunden.
Ja es liegt am Treiber.
Mit dem Domotiga Treiber läuft es und die Zeiten werden von Fhem aus den angelegten Weekday Timern ausgelesen.
Mit den neuen Treibern fronthem und fhem funktioniert dies nicht mehr.
Ansonsten wollte ich nur noch einmal das Vorzeichen Problem im NumDirect Converter erwähnen. ;-)
Wurde hier breits diskutiert:
Zitat von: marvin78 am 16 Februar 2015, 11:30:54
@hermannj: Wenn ich in Zeile 200 der fhconverter.pm
$event = $1;
durch
$event =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;
und in Zeile 212
$gadval = $1
durch
$gadval =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;
ersetze, funktionieren die Vorzeichen für NumDirect wieder. Hier scheint das RegEx also nicht korrekt in $1 zu stehen.
Grüße
Zitat von: fidel am 21 März 2015, 01:40:10
ist zwar schon etwas her, aber ich denke immer noch aktuell.
ich habe heute mal das UZSU Widget eingebunden.
Ja es liegt am Treiber.
Mit dem Domotiga Treiber läuft es und die Zeiten werden von Fhem aus den angelegten Weekday Timern ausgelesen.
Mit den neuen Treibern fronthem und fhem funktioniert dies nicht mehr.
Welche Versionsnummer hat denn der fhem-Treiber?
1.05
müsste der letzte aus dem thread sein...
OK, dann muss ich mir wohl auf meine Test-page ein UZSU draufpacken und debuggen.
@fidel:muss es so aussehen, wenn es funktioniert?
Wenn ja, dann funktioniert es mit meiner Version vom fhem Treiber
Ja so muss es aussehen.
Die UZSU hat auch bei mir mit dem letztem Treiber (http://forum.fhem.de/index.php/topic,30909.msg273617.html#msg273617) nicht funktioniert.
Grüße
Zitat von: fhainz am 21 März 2015, 13:43:20
Die UZSU hat auch bei mir mit dem letztem Treiber (http://forum.fhem.de/index.php/topic,30909.msg273617.html#msg273617) nicht funktioniert.
Ich veröffentliche meine aktuelle Version dieses Wochenende, versprochen ;)
Nur noch etwas Feintuning ...
Zitat von: HCS am 21 März 2015, 13:40:27
@fidel:muss es so aussehen, wenn es funktioniert?
Wenn ja, dann funktioniert es mit meiner Version vom fhem Treiber
Wenn du save and quit drückst und das popup erneut aufrufst, bleiben die Werte erhalten bzw. werden geladen? Funzt bei mir nicht. Habe auch schon uzsu widget v2 sowie v2.4 versucht... Ansonsten gedulde ich mich auch noch. ;)
Ja, ich lege Einträge an, ändere sie, speichere, beende den Chrome, öffne die SV-Seite neu, klicke die Uhr und habe die drei Einträge wieder.
Geduld ist wohl der entscheidende Faktor ;)
Und der Bug (der nichts mit diesem Problem zu tun hat), den ich nebenbei im UZSU Widget gefunden habe, ist in allen drei branches drin.
Ich melde ihn gerade im git ein und werde ihn hier noch dokumentieren, weil man sonst sehr verwundert auf der Uhr rumcklickt und kein Popup kommt.
Bei mir öffnet sich nicht mal das popup :D
Zitat von: HCS am 21 März 2015, 14:00:05
Ich veröffentliche meine aktuelle Version dieses Wochenende, versprochen ;)
Sehr fein, danke! :)
Zitat von: fhainz am 21 März 2015, 14:10:53
Bei mir öffnet sich nicht mal das popup :D
Das könnte genau der bug sein, den ich gefunden habe.
Was sagte die Konsole vom Browers, nachdem Du die Uhr geklickt hast?
Hmmm... Jetzt öffnet sich plötzlich das Popup, aber ohne Daten.
Vielleicht hängt das mit meinem heutigen UZSU Update auf v2.4 zusammen? Ich bin mir fast sicher das sich das Popup letztens nicht geöffnet hat. In der Konsole kommt keine Meldung.
Also, das Problem in der visu.js vom uzsu ist Folgendes:
// bei designType '0' und '2' wird rrule nach wochentagen
// umgewandelt und ein festes format vogegegebn
// hier sollte nichts versehentlich überschrieben werden
if ((designType == '0') || (designType == '2')) {
var numberOfEntries = response.list.length;
for (var numberOfRow = 0; numberOfRow < numberOfEntries; numberOfRow++) {
// test, ob die RRULE fehlerhaft ist
if ((response.list[numberOfRow].rrule.indexOf('FREQ=WEEKLY;BYDAY=') !== 0) && (response.list[numberOfRow].rrule.length > 0)) {
if (!Confirm('Fehler: Parameter designType ist "0", aber gespeicherte RRULE String in UZSU "' + response.list[numberOfRow].rrule + '" entspricht nicht default Format FREQ=WEEKLY;BYDAY=MO... bei Item ' + item + '. Soll dieser Eintrag überschrieben werden ?')) {
// direkter abbruch bei der entscheidung !
numberOfRow = numberOfEntries;
popupOk = false;
}
}
}
}
Falls dieser Fall eintritt (was üblicherweise nicht passieren sollte), dann möchte das Widget eine Sicherheitsabfrage anzeigen.
Das Problem ist aber der Confirm, der müsste vorne ein kleines c haben. Es gibt Window.confirm(... aber halt mit kleinem c.
Das führt zum crash und es kommt kein Popup hoch.
Da habe ich auch 'ne Runde gegrübelt, warum schlicht nichts passiert, wenn ich auf die Uhr klicke.
Aber wie gesagt, das Problem hat nichts mit dem Problem zu tun, dass keine Listeneinträge kommen (mit der letzten Treiber Version).
Hab gerade deinen Issuse Post in github gesehen und das versucht. Hilft bei mir leider nicht, das popup öffnet sich nicht nur ohne Daten. In der Konsole keine Meldungen.
Mit dem Domotiga auch nicht?
Nachtrag: mit dieser Definnition habe ich getestet:
{{ uzsu.uzsu_icon("uzsuTest", "uzsu_dummy", "Wann an und wan tan", "0") }}
Ich habe den Eindruck, dass das uzsu bei seltsamen Definitionen auch nicht so arg fehlertolerant ist.
Blödsinn. Natürlich öffnet sich das Popup nur ohne Daten. Sry für die Verwirrung ;D
Mit einem älteren FHEM Treiber (~14.02.15) und dem Domotiga funktionierts problemlos.
Zitat von: fhainz am 21 März 2015, 14:31:04
Blödsinn. Natürlich öffnet sich das Popup nur ohne Daten. Sry für die Verwirrung ;D
Mit einem älteren FHEM Treiber (~14.02.15) und dem Domotiga funktionierts problemlos.
Na dann ist ja gut, oder zumindest fast gut :)
Wem es wie mir keinen Spaß macht, die ganzen JS Schnipsel der Widegts in der visu.js zu verwalten sondern sie lieber als einzelne Files haben will, dass man ein Aktualisierung einfach drüber kopieren kann, für den hätte ich da was:
Die JSs der Widgets werden im Page-Verzeichnis unter den gleichen Namen wie die html abgelegt.
Beispiel: widget_uzsu.html und widget_uzsu.js, widget_chart.html und widget_chart.js
Und dann das hier (natürlich angepasst, welche widgets man hat) in die visu.js, und zwar ganz oben:
var scriptFolder = (function() {
var result = document.currentScript.getAttribute("src", 2);
return result.substring(0, result.lastIndexOf("/") +1);
}());
function include(script) {
script = scriptFolder + script;
$.ajax({
url: script,
dataType: "script",
async: false,
error: function () {
alert("Could not load '" + script + "'");
}
});
}
// -----------------------------------------------------------------------------
// W I D G E T S
// -----------------------------------------------------------------------------
include("widget_chart.js");
include("widget_led.js");
include("widget_fhem.js");
include("widget_uzsu.js");
Und nun kann man geänderte widgets einfach drüberkopieren, ohne in der visu.js basteln zu müssen.
Paraktisch wäre, wenn die files im herrmannj/smartvisu-widgets repository so benannt würden, anstatt visu.js, dann müsste man sie nichtmal umbenennen, wenn man sie auf diese Weise einbindet.
Danke! Sowas suche ich schon lange ;D Funktioniert perfekt!
Zitat von: HCS am 21 März 2015, 17:26:15
var scriptFolder = (function() {
var result = document.currentScript.getAttribute("src", 2);
return "./widgets/"
//result.substring(0, result.lastIndexOf("/") +1);
}());
Paraktisch wäre, wenn die files im herrmannj/smartvisu-widgets repository so benannt würden, anstatt visu.js, dann müsste man sie nichtmal umbenennen, wenn man sie auf diese Weise einbindet.
Ich habe inzwischen von dem Ansatz von Jörg Gebrauch gemacht und nutze dieselben Widgets in mehreren Pages-Foldern mit unterschiedlichen Seiten. Daher habe ich mich entschieden, die Widgets und deren Scripte alle im widgets folder statt im pages folder abzulegen und nutze daher die grandiose Idee von HCS etwas anders (s. o.)
Wenn wir uns alle dazu entscheiden könnten, kann man sicher auch im GIT die Files nach diesem Schema umbenennen... Vielleicht sollten wir die visu.js im SV-cleaninstall so anpassen, dass sie das im Standard tut?
btw: Hat das nicht auch schon wieder performance Nachteile, wenn man scripted mehrere Files nachlädt?
Zitat von: bgewehr am 21 März 2015, 18:37:34
Wenn wir uns alle dazu entscheiden könnten, kann man sicher auch im GIT die Files nach diesem Schema umbenennen
Ich glaube wie müssen uns gar nicht alle entscheiden. Ob man den Code aus einer visu.js oder einer widget_chart.js sich holt und in seine visu.js reinbastelt, macht ja keinen Unterschied, wenn man bei der alten Variante bleibt.
Für die Neue hat man umbenannt aber einen Vorteil.
Zitat von: bgewehr am 21 März 2015, 18:37:34
btw: Hat das nicht auch schon wieder performance Nachteile, wenn man scripted mehrere Files nachlädt?
Theoretisch ja, aber es passiert nur bei einem page reload und wenn man sich im Profiler mal anschaut, was da alles nachgeladen wird, kommt es auf die paar mini Files auch nicht an.
Pro eingebundenem widget sind das bei mir ca. 4ms
... die js bleiben ja auch im cache.
sofern man will ...
soll ich's im widget git ändern? Ich nehme dann auch den stabilen Stand der UZSU 2.0 mit auf...
Gesendet von meinem iPad mit Tapatalk
gerne. Ich hab gesehen das Du "voll viel" reingepackt hast. Cool, Danke.
Zitat von: bgewehr am 21 März 2015, 19:03:17
soll ich's im widget git ändern? Ich nehme dann auch den stabilen Stand der UZSU 2.0 mit auf...
ich bin für ändern.
UZSU:
Meinst Du den gefixten "Confirm" bug?
Also den Code ranholen, anstatt zu mworion zu verweisen. Fände ich gut.
fertig.
Gesendet von meinem iPad mit Tapatalk
Zitat von: bgewehr am 21 März 2015, 19:18:30
fertig.
Cool. Langsam wird das Ganze so, dass es Laune macht.
Manche widgets integrieren den JS code einfach in ein Script Tag im html, das wäre ja dann noch einfacher, oder?
Das hat den Nachteil, dass der Code 5 mal drin ist, wenn das Widget 5 mal auf der Seite ist.
Mist, stimmt!
Treiber V1.07
Anbei und im smartvisu-cleaninstall repository commited
Die wesentlichen Änderungen:
- Schnelles Widget Update nach "Jörg-Methode" mit Fallback auf "Bernd-Widgets"
- UZSU funktioniert (zumindest bei mir)
- Implementierung der Kommunikation mit fronthem für Charts
Und noch ein Bonus-Feature: offline
Wenn man in der SV-Konfiguration anstatt einer IP-Adresse offline einträgt, dann greift der Treiber nicht auf fronthem zu (logisch) und generiert sich selbst Zufallswerte. Das funktioniert natürlich nur bei Widgets, die mit einem numerischen Wert was anfangen können und bei Charts (aktuell nicht Plots).
Damit kann man auch jenseits seines Netzwerks einiges basteln und testen.
Warum nicht den offline Treiber von nehmen?
-> Der fhem-Treiber handhabt einiges anders und ist realistischer, da er so tut, als ob er von fronthem Daten bekommen hätte und dann genau das passiert, was auch passieren würde, wenn es live Daten wären.
Der offline Treiber ist eine völlig andere Implementierung, die nur so was ähnliches macht.
Hallo Zusammen,
Ich trage mich hier nur kurz ein um mitzulesen , habe derzeit
Noch keinen Plan wo ich hier anfangen soll....gibt es einen geeigneten Einstieg
Oder eine etwas kompaktere Doku ?
Danke !
Kvo1
http://www.fhemwiki.de/wiki/Fronthem
Hi HCS,
vielen Dank für den neuen Treiber.
Das uszu-widget v2.0 läuft mit dem Treiber.
Bei der 2.4er develop werden zumindest bei mir die Zeiten nicht richtig übernommen.
Kann das jemand bestätigen? Dann vermerke ich es im Wiki...
Grüße
Zitat von: fidel am 21 März 2015, 23:40:23
Das uszu-widget v2.0 läuft mit dem Treiber.
Prima, dann darf ich jetzt ins Bett gehen ;D
Hallo HCS!
Danke für den Treiber, bin gerade am testen. UZSU (die version die bernd gestern ins git gestellt hat) und einige andere Dinge funktionieren nun, die Geschwindigkeit ist super!
Ein Problem hab ich aber noch mit eigenen js scripte.
- console.log bringt keinen Output mehr. Kann das sein?
- Dieses Script benutze ich zB um Icons, abhängig vom Wert, ein/aus zu blenden. Das hat bisher mit dem Domotiga und fhem Treiber (~14.02.15) funktioniert. Mit dem letzten fhem Treiber aber schon nicht mehr.
Bei einem Alarm soll das armed Icon ausgeblendet, leider werden aber beide Icons angezeigt.
$(document).delegate('span[data-item="alarm.3.alarm"]', {
'update': function (event, response) {
if( response > 0 ){
$('#alarm3armed').hide();
}
}
});
Hier soll das span desired-new beim laden ausgeblendet werden. Wenn sich desired-new ändert soll desired-new ein- und und desired ausgeblendet werden. Derzeit wird beim laden nicht mal desired-new ausgeblendet und beim update tut sich auch nichts.
//----- Heizungs Widget desired / desired-new Umschaltung ----------------------
$('.desired-new').hide();
$(document).delegate('.desired-new', {
'update': function (event, response) {
// console.log("[desired-new] update '" + this.id + "': response: " + response, response);
if( response > 0 ) {
$('.desired').hide();
$('.desired-new').show();
}
else {
$('.desired').show();
$('.desired-new').hide();
}
}
});
Kannst du mir erklären was ich an dem Scripts (hab noch andere die ähnlich sind und auch nicht funktionieren) ändern muss dass es funktioniert bzw. warum es nicht mehr funktioniert?
Grüße
Edit:
Hab jetzt noch ein wenig getestet und mal 'update' mit 'click' ersetzt. Dann funktioniert es beim draufklicken. Anscheinend liegt es an dem update.
Hallo ich habe alles gemaes der Wiki beschreibung gemacht.
aber es kommen Gad rein. zudem zeigt Fhem dieses Bild siehe unten.
Die IP ist die des Raspberrys. Wenn ich 192.168.178.27/smartvisu eingebe kommt die Seite von Smartvisu.
Könnt ihr mir helfen
Du musst die IP des Endgerätes eintragen.
ok ,ja habe ich.
aber wie komme jetzt das State auf conncet. Und warum sehe ich mir smartvisu meinHaus nicht, obwohl ich die Config. angelegt habe. Leider ist die Anleitung nicht mehr da.
Danke für die Hilfe
bumbumb
Hallo,
jetzt sehe ich die neue Page.
Wenn ich etwas in der Config ändere wird es aber nicht gespeichert. Habe ich ein Rechteproblem? Wie kann es geändert werden? Help Danke bumbumb
Zunächst noch einmal "Chapeau". Der neue Treiber ist wirklich fix und lässt (bisher) gegenüber dem alten nichts zu wünschen übrig.
Eine kurze Frage:
soweit ich gesehen haben sind jetzt ja auch plots möglich.
Wenn ich jedoch versuche einen Plot in smartvisu einzutragen:
{{ plot.rtr('Wintergartenplot', 'EG.Wintergarten.Temperaturplot.Ist', 'EG.Wintergarten.Temperaturplot.Soll', 50) }}
erscheinen diese GAD´s nicht in der Übersicht.
gibt es hier eine andere Plotfunktion oder muss ich zuätzliche elemente (außer dem Treiber) neu laden?
Danke im Voraus
Kann man den neuen Treiber nicht per FHEM updaten? Ich hatte gehofft, folgendes machen zu können:
update all https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
Aber da kommt immer "nothing to do"...
Der Treiber hat ja mit Fronthem erstmal auch nichts zu tun. Das ist Teil von SmartVisu. Fronthem ist die Schnittstelle zu FHEM auf FHEM Seite, der Treiber auf der Seite von SmartVisu. So wie ich das sehe, ist der Treiber erstmal nur hier im Thread zu bekommen.
Zitat von: Gerd.Ternes am 22 März 2015, 11:23:01
soweit ich gesehen haben sind jetzt ja auch plots möglich.
Noch nicht. Der Treiber kann es generell, aber Jörg muss auf der fronthem-Seite noch was tun.
Also noch etwas Geduld und nicht mit Plots abmühen, es kann noch nicht funktionieren.
Zitat von: marvin78 am 22 März 2015, 12:19:05
So wie ich das sehe, ist der Treiber erstmal nur hier im Thread zu bekommen.
im cleaninstall repository habe ich ihn auch committed.
Zitat von: marvin78 am 22 März 2015, 12:19:05
Der Treiber hat ja mit Fronthem erstmal auch nichts zu tun. Das ist Teil von SmartVisu. Fronthem ist die Schnittstelle zu FHEM auf FHEM Seite, der Treiber auf der Seite von SmartVisu. So wie ich das sehe, ist der Treiber erstmal nur hier im Thread zu bekommen.
Argh, sorry, richtig. Ich war verwirrt. Ich muss natürlich mein SmartVISU updaten... Danke
Hallo.
Ich hab mein Problem von hier (http://forum.fhem.de/index.php/topic,30909.msg276411.html#msg276411) ein wenig eingekesselt. Es liegt an der neuen updateWidget Funktion. Wenn ich diese mit der aus v.1.02 ersetzte dann funktioniert mein js wieder, aber das update ist natürlich wieder langsam.
Kann es sein, dass nur mehr das Attribut data-widget ein update auslöst?
Grüße
ZitatKann es sein, dass nur mehr das Attribut data-widget ein update auslöst?
ich versteh das nicht ganz (Formulierung). Aber im Prinzip vmtl ja: anhand data-widget werden die widgets gesucht, genauer die, die ein event "update" haben.
vg
jörg
Ich hab in einem span ein basic.float widget. Das span soll je nach Wert des widget ein bzw. ausgeblendet werden soll. Bisher (Domotiga oder fhem Treiber v1.02) ging das mit
<span class="desired-new" id="wz.desired.new">{{ basic.float('wz.heizung.desired-new', 'wz.heizung.desired-new', '°C') }}</span>
$(document).delegate('.desired-new', {
'update': function (event, response) {
console.log("[desired-new] update '" + this.id + "': response: " + response, response);
if( response > 0 ) {
$('.desired').hide();
$('.desired-new').show();
}
else {
$('.desired').show();
$('.desired-new').hide();
}
}
});
Nun versuche ich schon den ganzen Tag das umzubauen aber es will nicht klappen ;D
Hast du einen Tipp für ich?
Grüße
Warum machst du dir nicht ein eigenes Widget auf Basis des basic.floats, dass das komplette Widget ein oder ausblendet? So habe ich etwas ähnliches gelöst.
Das war eher ein Unfall (das es ging). Das ist halt kein widget :). Du benötigst eine Struktur wie zB in den rtr widgets. Also: ein übergeordnetes widget (in einer html) welches dann die float kapselt.
vg
jörg
edith überschnitten :)
Noch nicht. Der Treiber kann es generell, aber Jörg muss auf der fronthem-Seite noch was tun.
Also noch etwas Geduld und nicht mit Plots abmühen, es kann noch nicht funktionieren.
... na dann wieder zurück mit den jungen Pferden.
Bin wirklich sehr begeistert von der Kombi fhem und smartvisu. Richtig übersichtlich wird´s aber erst mit plots. Habe mittlerweile meine gesamte Heizung darüber laufen. Gas- und Stromverbrauch werden angezeigt und letzte Woche habe ich auch meine Resol Solaranlage integrieren können. Jetzt muss ich nur noch das Zusammenwirken der Elemente in Plots reinkriegen.
Zitat von: herrmannj am 22 März 2015, 13:35:15
Das war eher ein Unfall (das es ging). Das ist halt kein widget :). Du benötigst eine Struktur wie zB in den rtr widgets. Also: ein übergeordnetes widget (in einer html) welches dann die float kapselt.
Schade das es nur ein Unfall war. Hat einiges erleichtert ;) Ich versuche gerade mir so ein widget zu basteln. Bisher hatte ich noch nicht viel erfolg.
{% macro floatSwitch(id, item1, item2, value) %}
{% import "basic.html" as basic %}
<div id="{{ uid(page, id) }}" data-widget="my.floatSwitch" class="floatSwitch">
<span id="item1">{{ basic.float(id~'item1', item1, '') }}</span>
<span id="item2">{{ basic.float(id~'item2', item2, '') }}</span>
</div>
{% endmacro %}$(document).delegate('div[data-widget="my.floatSwitch"]', {
'update': function (event, response) {
console.log("[my.floatSwitch] update '" + this.id + "': response: " + response, response);
}
});Der Consolen Log kommt aber nie :(
Ich habe im widget GIT ein basic.hider veröffentlicht, das umschließt einfach ein anderes widget und blendet es aus, wenn das GAD keinen Wert hat. Vielleicht taugt das für Dich was?
Hier? https://github.com/herrmannj/smartvisu-widgets
Da liegt im basic folder nur der shifter.
Sehe ich auch grade. Ich schiebe es hinterher!
@HCS: mit dem neuen Treiber werden meine wischgesten nicht mehr ausgeführt, mit denen ich inzwischen die Seiten wechsle. Console Output später...
Gibt kein widget, das läuft so:
Um den html code, der dynamisch ausgeblendet werden soll, mache ich folgende Klammer:
<div data-item="{{id~gad_name}}" data-widget="basic.hider">
...
</div>
Dann in der widget. js oder sonstwo:
// ----- basic.hider-----------------------------------------------------
$(document).delegate('div[data-widget="basic.hider"]', {
'init': function (event) {
},
'update': function (event, response) {
if (response == '') {
$(this).html("");
//css("visibility", "hidden");
}
}
});
Dann ist das weg, wenn das gad leer ist. Kann man ja variieren!
Das ist ja noch viel besser! ;D Danke!!
Ich hab es noch ein wenig umgebaut, damit es zwischen 1 gad und einem div/span toggelt.
$(document).delegate('[data-widget="my.elementToggle"]', {
'init': function (event) {
},
'update': function (event, response) {
hideElement = $(this).attr('hide-element');
//console.log("[basic.hider] update '" + this.id + "': response: " + response + ", hideElement: " + hideElement);
if (response == 0 ) {
$(this).css("display", "none");
$(hideElement).css("display", "inline");
}
else {
$(this).css("display", "inline");
$(hideElement).css("display", "none");
}
}
});
- in data-item kommt das GAD das geprüft wird
- in hide-element kommt die klasse/id die getoggelt wird
<span data-item="wz.heizung.desired-new" hide-element=".desired" data-widget="my.elementToggle">{{ basic.float('wz.heizung.desired-new', 'wz.heizung.desired-new', '°C') }}</span>
zB
<span class="desired">{{ basic.float('wz.heizung.desired', 'wz.heizung.desired', '°C') }}</span>
<span class="desired-new" data-item="wz.heizung.desired-new" hide-element=".desired" data-widget="my.elementToggle">{{ basic.float('wz.heizung.desired-new', 'wz.heizung.desired-new', '°C') }}</span>
Somit wird abwechselnd desired und desired-new angezeigt.
Danke für eure Hilfe!!
Der neue Treiber tut so weit was er soll. Danke dafür. Eines fällt mir im Vergleich zum alten Treiber auf. Hat man ein rtr Widget und man drückt + oder -, dann wird immer gleich um 2 Steps geändert (reproduzierbar). Auf der gleichen Seite passiert das mit dem "alten" Treiber nicht. Folgendes steht in der Konsole bei loglevel 2:
[io.fhem]: send() data: {"cmd":"item","id":"EG.wz.TC.Wohnzimmer.Climate.set","val":"20.5"}
[io.fhem]: write (gad=EG.wz.TC.Wohnzimmer.Climate.set val=20.0)
[io.fhem]: send() data: {"cmd":"item","id":"EG.wz.TC.Wohnzimmer.Climate.set","val":"20.0"}
[io.fhem]: socket.onmessage: data= {"items":["EG.wz.TC.Wohnzimmer.Climate.set","20.5"],"cmd":"item"}
[io.fhem]: socket.onmessage: data= {"items":["EG.wz.TC.Wohnzimmer.Climate.set","20.0"],"cmd":"item"}
Es wird also tatsächlich erst der Wert 20.5 und dann der Wert 20 gesendet , obwohl bei der Einstellung 21 nur einmal das minus angeklickt wurde. Und die Schrittweite steht auch auf 0.5. Mit dem alten Treiber (ohne das Vodoo von hermannj) passiert das reproduzierbar nicht. Habt ihr eine Idee?
Zitat von: karl0123 am 22 März 2015, 17:46:42Hat man ein rtr Widget und man drückt + oder -, dann wird immer gleich um 2 Steps geändert (reproduzierbar).
Das funktioniert bei mir wie es soll (reproduzierbar).
Welchen rtr hast Du denn verwendet?
Widget:
{% macro hmtcrt(id, gad_rtValve, gad_rtBattery, gad_humidity, gad_actual, gad_set, gad_controlmode, gad_daytemp, gad_nighttemp, gad_window, gad_battery, gad_txt, step, dt, nt) %}
{% import "basic.html" as basic %}
<div id="{{ uid(page, id) }}" data-widget="device.rtr" data-step="{{ step|default(0.5) }}"
class="rtr">
<div class="actual">
<div class="temp">
{{ basic.shifter(id~'batteryrt', '', gad_rtBattery, 'icon.battery','', 0, 100) }}
{{ basic.float(id~'actual', gad_actual, '°' ) }}
{{ basic.shifter(id~'battery', '', gad_battery, 'icon.battery','', 0, 100) }}
</div>
<div class="text">{% if gad_humidity %}Hum.: {{ basic.hum_value(id~'humidity', gad_humidity,'%') }} {% endif %}Valve: {{ basic.value(id~'valve', gad_rtValve,'%') }}</div>
</div>
{% if gad_set %}
<div class="set">
<a data-role="button" data-icon="minus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
<div class="temp">{{ basic.float(id~'set', gad_set, '°' ) }}</div>
<a data-role="button" data-icon="plus" data-inline="true" data-iconpos="notext" class="ui-mini"></a>
</div>
{% endif %}
<div class="control" style="width: 90%;">
<table align="center" cellpadding="0">
<tr>
<td>{{ basic.switch(id~'manauto', gad_controlmode, icon1~'sani_heating_automatic.png', icon0~'sani_heating_manual.png', 'auto', 'manual') }}</td>
<td>{{ basic.switch(id~'night', gad_set, icon1~'scene_night.png', icon0~'scene_night.png', nt, dt) }}</td>
<td>{{ basic.switch(id~'day', gad_set, icon1~'scene_day.png', icon0~'scene_day.png', dt, nt) }}</td>
<td>
{{ basic.symbol(id~'windowtilted', gad_window, '', 'icons/ye/fts_window_1w_tilt.png','tilted','or') }}{{ basic.symbol(id~'windowopen', gad_window, '', 'icons/rd/fts_window_1w_open.png','open','or') }}
</td>
</tr>
</table>
</div>
</div>
{% endmacro %}
JS -Standard aus der widget.js
$(document).delegate('div[data-widget="device.rtr"] > div > a[data-icon="minus"]', {
'click': function (event, response) {
var uid = $(this).parent().parent().attr('id');
var step = $('#' + uid).attr('data-step');
var item = $('#' + uid + 'set').attr('data-item');
var temp = (Math.round((widget.get(item) - step) * 10) / 10).toFixed(1);
io.write(item, temp);
}
});
$(document).delegate('div[data-widget="device.rtr"] > div > a[data-icon="plus"]', {
'click': function (event, response) {
var uid = $(this).parent().parent().attr('id');
var step = $('#' + uid).attr('data-step');
var item = $('#' + uid + 'set').attr('data-item');
var temp = (Math.round((widget.get(item) * 1 + step * 1) * 10) / 10).toFixed(1);
io.write(item, temp);
}
});
HTML:
{{ homematic.hmtcrt('KG.wk.TC.Waesche', 'KG.wk.RT.Waesche.Clima.valve', 'KG.wk.RT.Waesche.battery', 'KG.wk.TC.Waesche.Weather.humidity', 'KG.wk.TC.Waesche.Weather.temperature', 'KG.wk.TC.Waesche.Climate.set', 'KG.wk.TC.Waesche.Climate.controlmode', 'KG.wk.TC.Waesche.Climate.dayTemp', 'KG.wk.TC.Waesche.Climate.nightTemp', 'KG.wk.TK.Waesche', 'KG.wk.TC.Waesche.battery', '', '',18,18) }}
Da es genau so mit dem alten Treiber funktioniert, fällt es mir wirklich schwer, zu glauben, dass es an mir liegt. Zumal das JS unverändert verwendet wird.
Zitat von: karl0123 am 22 März 2015, 19:06:31
Da es genau so mit dem alten Treiber funktioniert, fällt es mir wirklich schwer, zu glauben, dass es an mir liegt. Zumal das JS unverändert verwendet wird.
Das habe ich ja auch nicht behauptet. Der neue Treiber arbeitet anders als der alte und da kann es schon sein, dass etwas das bisher warum auch immer funktioniert hat, nicht funktioniert. Hatten wir ja heute schon mal.
Ich baue ihn mal bei mir ein und debugge es.
Ich kann das Verhalten von Karl mit einem ganz ähnlichen Widget bestätigen. Auch bei mir ist mit dem älteren Treiber und den tiefen delegates alles gut. Das Verhalten mit dem neuen Treiber stellt sich bei mir so dar:
Ich klicke auf Minus oder Plus (bei 21). Es wird in der Anzeige sofort um 1 vermindert gewollt ist 0,5), dann springt der Wert (desired) kurz auf den Wert zurück, der tatsächlich gewünscht war (20,5) und dann wieder auf den um 1 verminderten Wert (20). Am Ende steht also ein um 1 verminderter Wert in der Anzeige und dieser wird in FHEM auch vom TC angenommen. Auch die Konsolenausgaben sind bei mir, wie bei karl.
Ich frage mich gerade, wie der erste send() im log zustande kommt, ohne dass ein write vorher kam.
Ist das bei Dir auch so?
Momentan werde ich durch code lesen nicht schlau aus der Sache.
Bekommt eigentlich noch jemand mails bei neuen Beiträgen?
Seit Mitternacht bekomme ich keine mehr.
Nein. Du hast recht, karl hat wohl eine Zeile vergessen. So sieht es aus. Wobei die allerletzte Zeile erst nach einer Weile ausgeführt wird (etwa 1-2 Sekunden).
[io.fhem]: write (gad=EG_ez_TC_Esszimmer_Climate.s val=20.5)
[io.fhem]: send() data: {"cmd":"item","id":"EG_ez_TC_Esszimmer_Climate.s","val":"20.5"}
[io.fhem]: write (gad=EG_ez_TC_Esszimmer_Climate.s val=20.0)
[io.fhem]: send() data: {"cmd":"item","id":"EG_ez_TC_Esszimmer_Climate.s","val":"20.0"}
[io.fhem]: socket.onmessage: data= {"cmd":"item","items":["EG_ez_TC_Esszimmer_Climate.s","20.5"]}
[io.fhem]: socket.onmessage: data= {"items":["EG_ez_TC_Esszimmer_Climate.s","20.0"],"cmd":"item"}
Für mich sieht das so aus, als würde das prellen.
Edit: Und wegen der Mails - ist bei mir auch so. Keine Mails seit letzte Nacht.
Gut, das behebt schon mal eine meiner Verwirrungen :)
Könntest Du mal einen original device.rtr bei Dir draufsetzen und schauen, ob der sich auch so verhält?
{{ device.rtr(..
Meine {{ homematic.hmtc verhalten sich ganz normal mit 1.07...
Ah. Sorry. Hatte ich auch schon getestet. Auch mit dem Standard-Widget das gleiche verhalten. Browser ist übrigens Chrome. Devices: Nexus 5, diverse Samsung Tablets, PC.
Zitat von: marvin78 am 22 März 2015, 19:58:37
Ah. Sorry. Hatte ich auch schon getestet. Auch mit dem Standard-Widget das gleiche verhalten. Browser ist übrigens Chrome. Devices: Nexus 5, diverse Samsung Tablets, PC.
Das ist ja spannend. Mit dem Original geht es bei mir und bei Dir nicht, mit dem homematic.hmtc bei bgewehr geht es.
Bin gerade ratlos, wie ich das nachstellen soll.
Das scheint dann aber nicht an den Widgets zu liegen sondern an anderen Umständen.
Also mein Problem habe ich gelöst. Ich weiß nicht, wo ich diese widget.min.js her habe. In dieser gab es den JS-Code für den rtr zwei mal. Ich habe die Datei jedoch nie geändert. In der widget.js ist alles korrekt, sodass ich das nicht direkt bemerkt habe.
Sorry aber das hier war wohl mein eigener Fehler. Vielleicht ist es ja bei karl ähnlich!? Ich frage mich ehrlich, wo ich diese Datei her habe und auch warum das mit dem alten Treiber trotzdem gut funktioniert...aber das wird wohl an der Art der Umsetzung liegen.
Ich habe noch einen Fehler 'Cannot read property 'attr' of undefined in Zeile 588 des Treibers beim Laden der Seite. ne Idee, wie ich weiter suchen soll?
@bgewehr: Den habe ich auch. Ich kann jedoch kein Problem entdecken, dass hier durch entsteht.
Edit: Wobei ich die Vermutung habe, dass es durch ein Widget verursacht wird, dass nicht das Attribut data-item enthält. Konnte das noch nicht genauer analysieren.
Zitat von: bgewehr am 22 März 2015, 20:12:35
Ich habe noch einen Fehler 'Cannot read property 'attr' of undefined in Zeile 588 des Treibers beim Laden der Seite. ne Idee, wie ich weiter suchen soll?
in fronthem ?
In io_fhem.js
Zitat von: herrmannj am 22 März 2015, 20:15:47
in fronthem ?
In der JS-Konsole. Eintrag bezieht sich auf den Treiber.
Zitat von: bgewehr am 22 März 2015, 20:12:35
Ich habe noch einen Fehler 'Cannot read property 'attr' of undefined in Zeile 588 des Treibers beim Laden der Seite. ne Idee, wie ich weiter suchen soll?
Immer, bei jedem page load?
Das würde bedeuten, dass $.mobile.activePage undefined ist, warum auch immer.
Zitat von: marvin78 am 22 März 2015, 20:09:55
Also mein Problem habe ich gelöst. Ich weiß nicht, wo ich diese widget.min.js her habe. In dieser gab es den JS-Code für den rtr zwei mal. Ich habe die Datei jedoch nie geändert. In der widget.js ist alles korrekt, sodass ich das nicht direkt bemerkt habe.
Sorry aber das hier war wohl mein eigener Fehler. Vielleicht ist es ja bei karl ähnlich!? Ich frage mich ehrlich, wo ich diese Datei her habe und auch warum das mit dem alten Treiber trotzdem gut funktioniert...aber das wird wohl an der Art der Umsetzung liegen.
Das wäre interessant zu wissen, wo die herkommt. Wenn die im Umlauf ist, dann suchen wir Phantom-Fehler.
Ohne es genau zu analysieren, aber mit zwei delegates im Code wird's halt auch zwei mal gemacht. Keine Ahnung, warum es dem "alten" Treiber nichts ausgemacht hat, aber es ist es wohl auch nicht wert, erforscht zu werden.
@karl: kannst Du das bei Dir mal überprüfen?
Ich lege das Thema dann erst mal zu den Akten.
Zitat von: herrmannj link= ;) ;)topic=30909.msg276747#msg276747 date=1427051747
in fronthem ?
Hast Glück, das Problem habe ich mir gerade in die ToDo geschrieben
ah, Glück 8)
ZitatDas würde bedeuten, dass $.mobile.activePage undefined ist, warum auch immer.
Das ist es, ist mir auch schon mal aufgefallen
Zitat von: HCS am 22 März 2015, 20:25:50
Immer, bei jedem page load?
Das würde bedeuten, dass $.mobile.activePage undefined ist, warum auch immer.
Bei mir kommt es bei jedem aktualisieren der Seite. Ajax-Loads kommen ohne Fehler aus.
Habe es ("Zeile 588") auch gerade auf einer meiner Seiten gehabt. Somit habe ich ein Chance, es zu untersuchen.
Das mit den mails ist übel, kann doch nicht ständig F5 drücken ...
Hat das schon jemand irgendwo gemeldet?
Zitat von: HCS am 22 März 2015, 20:31:26
Hat das schon jemand irgendwo gemeldet?
Gerade eben
http://forum.fhem.de/index.php?topic=35354.new#new (http://forum.fhem.de/index.php?topic=35354.new#new)
Ich habe noch ein Thema mit dem Treiber 1.07:
Meine Handy-optimierten-Pages basieren nicht auf den Standard-Seiten (root-base-rooms), sondern werden alle beim Start in die index.html geladen und dann per Wischgesten navigiert (siehe mein git https://github.com/bgewehr/smartVISU-multipage.git).
Mit dem Treiber 1.02 läuft das, mit 1.07 wird nicht mehr auf Wischgesten reagiert und ich bleibe auf der ersten Seite "hängen"...
Ich weiß im Moment nicht, wie ich den Fehler eingrenzen kann, was kann ich tun?
@marvin78: Super.
Kannst Du noch forschen, wo die seltsame widget.min.js herstammt?
Die macht mich etwas nervös. :)
Zitat von: bgewehr am 22 März 2015, 20:37:47
Ich habe noch ein Thema mit dem Treiber 1.07:
Meine Handy-optimierten-Pages basieren nicht auf den Standard-Seiten (root-base-rooms), sondern werden alle beim Start in die index.html geladen und dann per Wischgesten navigiert (siehe mein git https://github.com/bgewehr/smartVISU-multipage.git).
Mit dem Treiber 1.02 läuft das, mit 1.07 wird nicht mehr auf Wischgesten reagiert und ich bleibe auf der ersten Seite "hängen"...
Ich weiß im Moment nicht, wie ich den Fehler eingrenzen kann, was kann ich tun?
Sagt die Konsole etwas dazu?
Oft ist es so, dass ein crash in einem Widget oder sonstwo auch dafür sorgt, dass jquery nichts mehr weiter macht.
Hatte ich bei verschiedenen Fehlern auch schon mal mit der "normalen" Navigation.
Ich würde es erst mal mit leeren Seiten und dann mit genau einem basic.value auf einer Seite versuchen.
Zitat von: HCS am 22 März 2015, 20:44:37
Sagt die Konsole etwas dazu?
Oft ist es so, dass ein crash in einem Widget oder sonstwo auch dafür sorgt, dass jquery nichts mehr weiter macht.
Hatte ich bei verschiedenen Fehlern auch schon mal mit der "normalen" Navigation.
Ich würde es erst mal mit leeren Seiten und dann mit genau einem basic.value auf einer Seite versuchen.
Dumm ist, dass es in Chrome am Desktop funktioniert, aber im mobile Safari auf dem iPhone nicht. Also leider keine Konsoleninfos...
Ich mach mal leere Seiten...
btw: Gibt es keinen Browser für iOS, bei dem man debuggen kann?
Zitat von: HCS am 22 März 2015, 20:44:37
@marvin78: Super.
Kannst Du noch forschen, wo die seltsame widget.min.js herstammt?
Die macht mich etwas nervös. :)
Ich würde dich (und auch mich selbst) gerne beruhigen aber ich weiß nicht sicher, wie das passiert ist. Ich habe das SmartVisu ursprünglich von smartvisu.de. Am Datum war zu sehen, dass ich die widget.min.js nie geändert habe. Ich hatte zwischendurch mal eine widget.js mit den tiefen delegates, habe aber aktuell wieder das Original in Verwendung. Seltsam.
Zitat von: bgewehr am 22 März 2015, 20:12:35
Ich habe noch einen Fehler 'Cannot read property 'attr' of undefined in Zeile 588 des Treibers beim Laden der Seite. ne Idee, wie ich weiter suchen soll?
Das ist kein Problem in dem Sinne. Der Treiber versucht das schon mal zu einem Zeitpunkt, an dem $.mobile.activePage tatsächlich manchmal noch undefined ist.
Kurz danach ruft SV im Treiber aber ein run auf, und spätestens da funktioniert es.
Warum das nur auf manchen pages vom Timing so abläuft ist mir zwar unklar, aber da ist eh nix zu wollen.
Ich bin mir sehr sicher, dass diese Fehlermeldung keinen Einfluss auf die Funktion der geladenen page hat, sie ist einfach nur unschön.
Ich fange das ab. Also einfach vorerst mal ignorieren.
@Bgewehr
Ich habe heute mal die neue Logik der Widget von dir eingebaut. Da ist mir aufgefallen, dass in der widget_homematic.html zwei Fehler sind
{% macro hmtctimer(id, txt, gad_prog, gad_p1_sat, gad_p1_sun, gad_p1_mon, gad_p1_tue, gad_p1_wed, gad_p1_thu, gad_p1_fri, gad_init, gad_save, gad_restore) %}
{% import "basic.html" as basic %}
<div id="{{ uid(page, id) }}" style="font-size:0.8em">
<table width="100%" style="text-align:left">
<tr><td width="80px">Programm:</td>
<td style="float:left width:50%">{% if gad_prog %}{{ basic.selectmenu(id~'prog', gad_prog, '', 'prog1', 'prog2', 'prog3') }}{% endif %}</td>
<td style="width:50% float:right">
<span data-role="controlgroup" data-type="horizontal" style="float:right;">
{% if gad_init %}{{ basic.button(id~'init', gad_init, ' init ', '' ) }}{% endif %}
{% if gad_save %}{{ basic.button(id~'save', gad_save, ' save ', '') }}{% endif %}
{% if gad_restore %}{{ basic.button(id~'restore', gad_restore, 'restore', '') }}{% endif %}
</span>
</td></tr></table>
{{ basic.textinput(id~'p1_mon', gad_p1_mon, 'Montag:') }}
{{ basic.textinput(id~'p1_tue', gad_p1_tue, 'Dienstag:') }}
{{ basic.textinput(id~'p1_wed', gad_p1_wed, 'Mittwoch:') }}
{{ basic.textinput(id~'p1_thu', gad_p1_thu, 'Donnerstag:') }}
{{ basic.textinput(id~'p1_fri', gad_p1_fri, 'Freitag:') }}
{{ basic.textinput(id~'p1_sat', gad_p1_sat, 'Samstag:') }}
{{ basic.textinput(id~'p1_sun', gad_p1_sun, 'Sonntag:') }}
</div>
{% endmacro %}
textinput und selectmenu sind nicht in der basic.html sondern bei dir extra Widget. Hier solltes du einen Hinweis zur Einbindung der zwei Widget geben und den code entsprechend anpassen.
Für den Timecounter habe ich eine Lösung für die Anzeige der Stunden.
{% macro timecounter(id, gad, mode) %}
<script type="text/javascript">
function ZeitAnzeigen (objectID, mode, value) {
var absSekunden = value
if (absSekunden == 'NaN') {absSekunden = 1};
var relSekunden = absSekunden % 60;
var absMinuten = Math.abs(Math.round((absSekunden - 30) / 60));
var relMinuten = absMinuten % 60;
var absStunden = Math.abs(Math.round((absMinuten - 30) / 60));
var anzSekunden = "" + ((relSekunden > 9) ? relSekunden : "0" + relSekunden);
var anzMinuten = "" + ((relMinuten > 9) ? relMinuten : "0" + relMinuten);
var anzStunden = "" + ((absStunden > 9) ? absStunden : "0" + absStunden);
return(anzStunden + ":" + anzMinuten + ":" + anzSekunden);
};
</script>
<span id="{{ uid(page, id) }}" data-widget="basic.timecounter" data-item="{{ gad }}" data="{{ mode }}">-:-:-</span>
{% endmacro %}
Gruß Lutz
@Lutz: Das schaue ich mir an!
@HCS: kann es sein, dass der Treiber sonstige Events von jQuery abfängt, so dass meine Wischgesten nicht mehr aktiviert werden? Das sind ja auch native Events des Frameworks.
Zitat von: bgewehr am 23 März 2015, 07:53:06
@HCS: kann es sein, dass der Treiber sonstige Events von jQuery abfängt, so dass meine Wischgesten nicht mehr aktiviert werden? Das sind ja auch native Events des Frameworks.
Eigentlich nicht. Es geht ja auch nur auf dem Phone nicht.
Bekommst Du den
"'Cannot read property 'attr' of undefined in Zeile 588" Fehler?
Wenn ja, laufen danach möglicherweise die jQuery events nicht mehr.
Falls ja, kannst Du es so abfangen (Zeile 588 in io_fhem.js und nicht vergessen auch eine io_fhem.min.js draus zu machen):
// get all widgets at page
if($.mobile.activePage) {
$('[id^="' + $.mobile.activePage.attr('id') + '-"][data-item]').each(function (idx, e) {
io.allGADs.push(this);
});
}
Könnte bitte jemand einen Anstoß geben, wie man die tempLists bei einem HM-CC-RT-DN gad-mäßig verknotet?
Oder vielleicht einfach eine Beispiel-"fhserver....cfg" hier oder ins Wiki hochladen?
Ich stehe leider auf dem Schlauch, was z.B. die Funktion von den "init", "save" und "restore" Buttons von Bernds feinen Widgets betrifft.
Dank!
Tino
Hey, Tino, das ist vielleicht eine blöde Sache mit diesen TempLists. Die HM-Geräte lassen zwar das Auslesen direkt zu auf die jeweiligen Readings, aber nicht einfach so die Änderung dieser Parameter, daher habe ich von dem FHEM-HMinfo device Gebrauch gemacht und wollte mit init den Initialzustand aus einer tempList Sicherung des Werkszustandes wiederherstellen, mit save eine eigene Konfig in eine andere Datei sichern und mit restore aus dieser wiederherstellen. Das Ganze funktioniert bei mir leider auch nicht, weil ich irgendwie zu blöd bin, das HMInfo device zu begreifen, ich bekomme da immer für mich unverständliche Fehlermeldungen.
Wir können vielleicht zusammen die Nuss knacken, wenn Du herausfindest, wie man mit den TempList- Funktionen des HMInfo device elegant TempListen lesen und schreiben kann, dann kann ich das sicher dem Widget beibringen...
Das hier ist eine ernst gemeinte Frage und nicht despektierlich gemeint: Wie oft ändert ihr eure Templisten in den Devices? Ich mache das in der Regel 1 mal und eventuell noch einmal, falls ich gemerkt habe, dass ich das nicht optimal gemacht habe. Ich bin noch nie darauf gekommen, dass man so etwas seltenes in einem Frontend machen könnte. Das ist für mich ein Backend Ding. Da ich aber hier immer wieder lese (auch an vielen anderen Stellen), dass sich viele User eine bessere GUI für das Setzen der Listen wünschen, frage ich mich, ob es vielleicht doch Sinn hat. Also wie oft setzt ihr die Listen und warum macht ihr es so oft, dass es Sinn macht, das in einem Frontend zu machen?
Hi karl123, wenn Du gerade da bist, hast Du das mal geschaut?
http://forum.fhem.de/index.php/topic,30909.msg276756.html#msg276756
Zitat von: karl0123 am 23 März 2015, 13:39:48
Das hier ist eine ernst gemeinte Frage und nicht despektierlich gemeint: Wie oft ändert ihr eure Templisten in den Devices? Ich mache das in der Regel 1 mal und eventuell noch einmal, falls ich gemerkt habe, dass ich das nicht optimal gemacht habe. Ich bin noch nie darauf gekommen, dass man so etwas seltenes in einem Frontend machen könnte. Das ist für mich ein Backend Ding. Da ich aber hier immer wieder lese (auch an vielen anderen Stellen), dass sich viele User eine bessere GUI für das Setzen der Listen wünschen, frage ich mich, ob es vielleicht doch Sinn hat. Also wie oft setzt ihr die Listen und warum macht ihr es so oft, dass es Sinn macht, das in einem Frontend zu machen?
Ist für mich auch so - aber der Bedarf ist eben doch sehr individuell. Und mei: ist doch schön das man es machen kann . also . vg jörg
@HCS: Ich bin noch nicht dazu gekommen, sorry. Aber bei mir scheint es das gleiche Problem zu sein. Ich habe mir zwar die widget.min.js nicht im Detail anschauen können, aber wenn ich die widget.js verwende, dann ist alles gut. Da hätte ich auch mal selbst drauf kommen können :-\ Danke und sorry.
Hi Karl, im Grunde sehe und mache ich das genau wie Du.
Mein Begehr
in Richtung Herrn Gewehr (ich bin ein Dichter!) ;-)
kommt aktuell von einem Arbeitskollegen, der das irgendwie möchte. Ich frag ihn ma.
Aber auch ich wünschte mir schon ab und an eine benutzerfreundlichere Oberfläche: Wir haben zwei schon ganz schön erwachsene Töchter, die – unzüchtig! – nur noch unregelmäßig daheim sind, und dann immer wieder andere Aufsteh- und Weggeh-Zeiten haben. Die möchte ich eigentlich frühzeitig schon hinterlegen und stoße dabei mit "nur einer" controlParty an die Grenzen.
Zitat von: karl0123 am 23 März 2015, 13:54:31
Ich habe mir zwar die widget.min.js nicht im Detail anschauen können, aber wenn ich die widget.js verwende, dann ist alles gut.
Ja, schau mal, oder schicke sie mir, dann schaue ich.
Evtl. kannst Du ja nachvollziehen, wo diese widget.min.js herstammt. Die sollte auf alle Fälle eliminiert werden.
Hallo Bernd, mit HMInfo war ich auch noch nicht erfolgreich. Ich glaube, das wird nix.
Ich schaue mal, ob ich eine nette Klicki-Bunti-Oberfläche für controlParty und einzelne tempLists hinkriege...
Andere Frage: Ich möchte meiner neuen Liebe smartvisu natürlich auch von unterwegs frönen und dies gerne ohne VPN, also gerne HTTPS und BasicAuth (reicht für mein Sicherheitsempfinden).
Sehe ich das richtig, dass das mit smartvisu nicht so richtig geht, weil er für jede IP einen eigenen Client anlegt? Den Ansatz mit den Zertifikaten habe ich gesehen, aber ist bisher nur ein Ansatz, gell? Kann ich da vielleicht helfen?
Hallo zusammen,
ich hab mal wieder ein "Problem".
Würde gern einen Sleep-Timer in Form eines Slider´s für iTunes einsetzen.
iTunes ist in Fhem bereits integriert mittels 33_iTunes.pm, einen Slider fhem-seitig gibt es auch bereits, diesen aktualisiere ich über ein notify:
define ntfy_iTunesSleep notify Timer_iTunes:.* {
my $timerwert1 = ReadingsVal("Timer_iTunes","state","on");;
my $itunes = ReadingsVal("iTunes_at_home","state","0");;
my $dummy = "Timer_iTunes";;
if (($timerwert1 gt "1") && ($itunes eq "play")) {
fhem ("set $dummy $timerwert1");;
fhem ("define Warten1 at +00:00:01 trigger $dummy ")}
elsif ("$timerwert1" gt "1") {
my $timerwert2 = $timerwert1 - 1;;
fhem ("set $dummy $timerwert2");;
fhem ("define Warten2 at +*00:00:01 trigger $dummy, delete Warten2")}
else {
fhem ("set iTunes_at_home pause");;
fhem ("set $dummy 0");;
fhem ("delete Warten2")}
}
Nun würde ich gerne diesen sich ständig aktualisierenden Slider in SmartVisu einfügen, hab ich nun über:
{{ basic.slider('iTunesTimer', 'itunesTimer', 0, 1800, 1, 'bottomup') }} gemacht,
das GAD erscheint auch, und wurde von mir wie folgt verknüpft:
"itunesTimer" : {
"reading" : "level",
"type" : "item",
"converter" : "Direct",
"device" : "Timer_iTunes",
"set" : "state"
es besteht auch noch ein UserReading "level" um das Reading "state" vom cmd set "state" zu trennen.
Diese Config funktioniert nur leider nicht so wie sie es in Fhem macht.
Kann mich jemand auf den richtigen Weg bringen? (mit Zaunpfahl o.ä. ;) )
MFG RockSteadyBeat
Hi, was steht den in dem reading "level" drin ? und was erwartet "Timer_iTunes" ?
Bzgl certs, vielen Dank für das Angebot der Hilfe. Das "Problem" bei den certs ist nicht so sehr die Umstzung (sicher, keine Selbstläufer - non-blocking ssl zb ist ein Thema). Der Punkt ist das die Enddevice das alle nur "irgendwie" und im Zweifel auch nur halb unterstüzen - ich denke bis dahin ist Aufwand zu Nutzen gegenüber VPN einfach extrem ungünstig (Weil man tausend Spezialfälle abdecken muss und trotzdem nur 50% erreichen kann).
Das wird sich mittelfristig erledigen weil der support auf den Enddevice mit jeder Android/IOS Version besser wird. Aktuell unterstützt aber eben zB das WVC (nicht das von dirk - das von cordova) keine certs. Dort (im wvc) sehe ich die Arbeit aber viel besser investiert - zum Beispiel werden pushmessage, location based etc damit möglich.
vg
jörg
Hi herrmannj,
nun erstmal vielen Dank für die von Dir und den anderen Pro´s hier im Thread geleistete Arbeit... :)
...absolut Geil!!! ;D
das reading "level" ist ein user-reading von state: level {ReadingsVal("Timer_iTunes","state","0")}
Der Wert (state) des dummy´s Timer_iTunes wird über einen slider gesetzt und dann über ein notify ca. sekündlich um 1 reduziert... :D
Also Timer_iTunes erwartet lediglich einen Wert >0.
mfg RockSteadyBeat
Hallo
funktionieren jetzt die Plots aus Fhem heraus?? Wäre schön wenn jemand es sagen kann bumbumb
Nein. Tun sie nicht.
Zitat von: cruser1800 am 22 März 2015, 23:35:54
{% macro hmtctimer(id, txt, gad_prog, gad_p1_sat, gad_p1_sun, gad_p1_mon, gad_p1_tue, gad_p1_wed, gad_p1_thu, gad_p1_fri, gad_init,
...
{% endmacro %}
{% macro timecounter(id, gad, mode) %}
...
{% endmacro %}
Beides im widgets-GIT angepasst. Dank Dir, Lutz!
Zitat von: bgewehr am 23 März 2015, 13:27:40
Hey, Tino, das ist vielleicht eine blöde Sache mit diesen TempLists. Die HM-Geräte lassen zwar das Auslesen direkt zu auf die jeweiligen Readings, aber nicht einfach so die Änderung dieser Parameter, daher habe ich von dem FHEM-HMinfo device Gebrauch gemacht und wollte mit init den Initialzustand aus einer tempList Sicherung des Werkszustandes wiederherstellen, mit save eine eigene Konfig in eine andere Datei sichern und mit restore aus dieser wiederherstellen. Das Ganze funktioniert bei mir leider auch nicht, weil ich irgendwie zu blöd bin, das HMInfo device zu begreifen, ich bekomme da immer für mich unverständliche Fehlermeldungen.
Wir können vielleicht zusammen die Nuss knacken, wenn Du herausfindest, wie man mit den TempList- Funktionen des HMInfo device elegant TempListen lesen und schreiben kann, dann kann ich das sicher dem Widget beibringen...
Hi Bernd,
die Templist 2 und 3 gehen leider nur einzeln pro Wochentag. Hier müßtest du eine Funktion oder converter bauen, welche MOntag bis Sonntag proProgramm einzeln ausliest und schreibt!
VG Lutz
Kann man sagen wann Plots funktionieren
Zitat von: bumbumb am 23 März 2015, 20:51:18
Kann man sagen wann Plots funktionieren
Liest du auch den Thread? Ansonsten erweist sich die Suchfunktion manchmal als äußerst nützlich.
Das Wort "Plots" lässt einen sehr schnell das hier finden:
Zitat von: HCS am 22 März 2015, 12:21:28
Noch nicht. Der Treiber kann es generell, aber Jörg muss auf der fronthem-Seite noch was tun.
Also noch etwas Geduld und nicht mit Plots abmühen, es kann noch nicht funktionieren.
Zitat von: cruser1800 am 23 März 2015, 20:51:01
Hi Bernd,
die Templist 2 und 3 gehen leider nur einzeln pro Wochentag. Hier müßtest du eine Funktion oder converter bauen, welche MOntag bis Sonntag proProgramm einzeln ausliest und schreibt!
VG Lutz
Das lesen klappt ja, nur beim schreiben habe ich ernsthaft Probleme.
Mit dem Selectmenu werden in meinem Widget sauber die drei Wochenprogramme des HMTC angezeigt und man kann auch manuell die Wochentage bearbeiten. leider schaltet der HMTC nicht sehr schnell zwischen prog1 und ProgN um, so dass man irgendwie immer das Falsche bearbeitet! Dann kommt irgendwann "incomplete" und die Show ist vorbei!
Zitat von: bumbumb am 23 März 2015, 20:51:18
Kann man sagen wann Plots funktionieren
Einfach warten und die Posts weiter verfolgen.
Due Jungs hier machen einen guten Job obwohl sie das nicht müssten. Sie sind an den Plots dran und wenn es was neues gibt wird man es lesen können.
Hoffe ich.
ok super Jungs ihr seit Top
Treiber V1.08
Anbei und auch im smartvisu-cleaninstall repository.
Behebt die Cannot read property 'attr' of undefined Fehlermeldung
Gehen damit auch plots
Das hier ist eine ernst gemeinte Frage und nicht despektierlich gemeint: Wie oft ändert ihr eure Templisten in den Devices? Ich mache das in der Regel 1 mal und eventuell noch einmal, falls ich gemerkt habe, dass ich das nicht optimal gemacht habe. Ich bin noch nie darauf gekommen, dass man so etwas seltenes in einem Frontend machen könnte. Das ist für mich ein Backend Ding. Da ich aber hier immer wieder lese (auch an vielen anderen Stellen), dass sich viele User eine bessere GUI für das Setzen der Listen wünschen, frage ich mich, ob es vielleicht doch Sinn hat. Also wie oft setzt ihr die Listen und warum macht ihr es so oft, dass es Sinn macht, das in einem Frontend zu machen?
Noch einmal kurz zu o.a. Frage. Ich nutze schon häufiger unterschiedliche Temp Listen. Z.B. wenn ich in Urlaub fahre reduziere ich die Temperaturen in den Räumen auf ein Minimum. Gleichzeitig, kurz bevor ich zurückkomme nutze ich ein "boost" um die Räume wieder aufzuheizen.
Auch wenn wir an einem Urlaubstag einmal zu Hause bleiben, ändere ich die Temperaturen in den Wohnräumen, bzw. heize Bad u.ä später auf.
Von daher macht es (für mich) schon sinn dies mit einem Frontend zu machen.
Zitat von: bumbumb am 24 März 2015, 07:00:16
Gehen damit auch plots
Bitte lese die letzten Seiten dieses Threads. Die Plots hängen nicht nur vom Treiber ab!
Hallo,
Plots kann man mit einem kleinen Workaround anzeigen lassen, indem man mit dem Chart Frontend Plots erstellt und diese dann einfach in eine div Box einbettet.
Chart Frontend installieren und starten:
http://www.fhemwiki.de/wiki/Neues_Charting_Frontend (http://www.fhemwiki.de/wiki/Neues_Charting_Frontend)
-> Create New Chart
-> Auf den erstellten Chart mit rechter Maustaste klicken
-> Integrate in fhem
Aus der Box lediglich den http link kopieren und mit folgendem Code auf der smartVISU Seite einbetten. Dabei den beispielhaften Link im folgenden Code durch den eigenen ersetzen:
<div class="block">
<iframe src="http://192.168.178.62:8083/fhem/frontend/index.html?showchart=80692925" width="439" height="253">Iframes disabled</iframe>
</div>
Funktioniert bei mir soweit...
Gruß Phil
Dazu benötigt man kein Charting Frontend. DAS funktioniert ganz ähnlich auch mit dei SVG Plots aus FHEMWEB. Ich denke aber, das kann nur ein Workaround für ganz ungeduldige sein.
Zitat von: marvin78 am 24 März 2015, 16:15:37
Ich denke aber, das kann nur ein Workaround für ganz ungeduldige sein.
So sehe ich das auch.
hallo,
kann jemand mal genau beschreiben wie man die Aubfallkalender_2015.ics. Datei für den Calender einbindet. Wäre schön wenn ihr helfen könnt.
Gruß
bumbumb
Ich habe dazu den iCal-sabreDAV Treiber aus dem KNX Userforum verwendet und bin zufrieden.
hallo
kannst du es mal genauer beschreiben?? Vielen Dank.
bumbumb
Hier der Link zum Thread: http://knx-user-forum.de/forum/supportforen/smartvisu/35074-kalender-mit-ics-datei
Hallo,
hier habe ich auch mal eine Lösung veröffentlicht:http://forum.fhem.de/index.php/topic,33231.msg261300.html#msg261300 (http://forum.fhem.de/index.php/topic,33231.msg261300.html#msg261300).
Die aktuellste Version gibt es hier: http://forum.fhem.de/index.php/topic,33231.msg277847.html#msg277847 (http://forum.fhem.de/index.php/topic,33231.msg277847.html#msg277847)
Gruß Norbert
Hallo danke für die Infos.
kann jemand mal den kompletten Import beschreiben.
{#import.......}
wo wird der pfad zur ics Datei eingestellt? Bitte sage mir mal genau was gemacht werden muss. vielen dank bumbumb
Hallo,
steht im Prinzip hier:http://forum.fhem.de/index.php/topic,30909.msg246473.html#msg246473 (http://forum.fhem.de/index.php/topic,30909.msg246473.html#msg246473) und in den anderen beiden Links beschrieben.
Ich muss mir mal einen Wikiaccount beantragen und das mal alles da zusammen fassen.
Gruß Norbert
Wer Lust hat, die feature-Version 2.85 der UZSU (https://github.com/mworion/uzsu_widget/tree/feature) auszuprobieren, braucht eine erweiterte 99_fronthemUtils.pm.
Die Funktion UZSU_execute muss geändert werden:
###############################################################################
#
# Umsetzen der UZSU-Settings für ein device
#
###############################################################################
sub UZSU_execute($$)
{
my ($device, $uzsu) = @_;
$uzsu = decode_json($uzsu);
fhem('delete wdt_'.$device.'_uzsu');
if ($uzsu->{active}){
my $weekdays_part = " ";
for(my $i=0; $i < @{$uzsu->{list}}; $i++) {
my $weekdays = $uzsu->{list}[$i]->{rrule};
$weekdays = substr($weekdays,18,50);
if (($uzsu->{list}[$i]->{active})) {
if ($uzsu->{list}[$i]->{event} eq 'time'){
$weekdays_part = $weekdays_part.' '.$weekdays.'|'.$uzsu->{list}[$i]->{time}.'|'.$uzsu->{list}[$i]->{value};
}
else {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
}
}
}
fhem('define wdt_'.$device.'_uzsu'.' WeekdayTimer '.$device.' en '.$weekdays_part);
fhem('attr wdt_'.$device.'_uzsu room UZSU');
}
}
Nun kann man im sog. Expert-Mode die Zeiten auch in Abhängigkeit von Sunrise und Sunset definieren!
(reload 99_fronthemUtils.pm in fhem nach der Änderung der Datei nicht vergessen!!)
Hallo Bernd,
Sehr geil. Danke.
Ich habe allerdings zuerst keine earliest- und latest-Werte angegeben. Dann wird um 00:00 geschaltet(oder ich habe etwas falsch gemacht).
Kleine Ergänzung in UZSU_execute:
if ($uzsu->{list}[$i]->{timeMin} ne '' and $uzsu->{list}[$i]->{timeMax} ne '') {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
}
else {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs()}|'.$uzsu->{list}[$i]->{value};
}
Jetzt klappts auch mit leeren Werten.
Gruß
Hans
Edit:
Mist. timeOffset vergessen. Ich bin schon zu müde.
Hast Recht, da muss ich nochmal ins Detail gehen! Danke!
Zitat von: Rockojfonzo am 23 März 2015, 17:15:23
Ich möchte meiner neuen Liebe smartvisu natürlich auch von unterwegs frönen und dies gerne ohne VPN, also gerne HTTPS und BasicAuth (reicht für mein Sicherheitsempfinden).
Hier meine Erfahrung zu fronthem/smartvisu und remote access:
Vom Mobile/Tablet funktioniert fronthem/smartvisu über eine IPsec/SSLVPN Verbindung gut. Allerdings trat in meinem Setup das Problem auf, dass eine Firewall (Cisco ASA) den Websocket Traffic blokiert hat, da keine SYN Pakete geschickt wurden, die zum Aufbau neuer TCP Connections notwendig sind. Der Traffic auf dem (ungewöhnlichen) Port 2121 wird wohl nicht als bereits geöffnete Websocket-Verbindung erkannt. Abhilfe schaffte ein tcp-state-bypass für Port 2121. Config siehe unten.
Möchte man von einem x-beliebigen Client, ohne VPN, über das Internet auf die smartvisu Seiten zugreifen, dann tritt das bekannte Problem auf, dass fronthem die IP des Clients nicht kennt und ggf. eine Firewall sogar den den Zugriff auf Port 2121 verweigert. Das kann man durch einen reverse Proxy elegant umgehen. Hier bietet sich z.B. Apache v2.4.5+ mit den Modulen mod_proxy und mod_proxy_wstunnel an. Dabei ist dann zu beachten, dass man in der smartvisu Konfiguration die (von aussen zu erreichende) IP Adresse des rProxies als I/O Connection IP und Port 80 angibt. Zum Schluss noch ein fronthemdevice mit der Adresse des Proxies anlegen. Funktioniert bei mir problemlos. Config ebenfalls unten.
So weit so gut. Was noch nicht sauber funktioniert sind zwei Dinge:
- TLS/SSL:
IE11 und FF36 zeigen die smartvisu https Seiten an, bekommen aber keine Websocket Verbindung. Safari funktioniert dagegen unter Mac OS X und IOS problemlos. Dieses Problem hat aber nichts mit dem remote access über einen Proxy zu tun, denn gleiches Verhalten zeigt mein smartvisu auch beim direkten Zugriff über SSL/TLS.
- Basic Auth:
Funktioniert leider auch nur bedingt. Man kann nur den web traffic authentifizieren und nicht den Websocket traffic, was aber nicht wirklich sicher ist. Keiner meiner getestet Browser hat die Authentifizierung der Webseiten an den Websocket Traffic durchgereicht. Einen Workaround gibt es zumindest für den Firefox: man kann mit der Kombination username:password@host als I/O connection address in der config.ini auch die Credentials übergeben. Allerdings funktioniert mit dem FF die verschlüsselte Verbindung über https nicht :-(
Da ich mich nie näher mit Websockets beschäftigt habe, weiss ich nicht ob diese beiden Probleme generell in Verbindung mit Websockets auftreten, es an smartvisu bzw. io_fhem.js liegt oder ich den Wald vor lauter Bäumen nicht sehe... Vielleicht kann einer der Entwicker etwas dazu sagen?
Btw: Wenn ich es im Wireshark Trace richtig gesehen habe, dann werden die Websockets nur mit http://x.x.x.x:2121/ aufgerufen. Sinnvoll wäre es, wenn dort noch ein eindeutiger Path angegeben wäre, wie zb. http://x.x.x.x:2121/ws/io_fhem/. Dann könnte man den Traffic ggf. besser filtern, wenn es nötig ist.
/Uli
smartvisu config.ini
[clients]
x.x.x.x = 'rProxy'
[client:rProxy]
driver_address = 'x.x.x.x'
driver_realtime = true
driver_port = '80'
# x.x.x.x ist die IP des reverse Proxy
apache conf.d/rproxy.cfg
ProxyPass /smartvisu http://y.y.y.y/smartvisu
ProxyPassReverse /smartvisu http://y.y.y.y/smartvisu
ProxyPass /fhem http://z.z.z.z:8083/fhem
ProxyPassReverse /fhem http://z.z.z.z:8083/fhem
ProxyPass / ws://z.z.z.z:2121/
ProxyPassReverse / ws://z.z.z.z:2121/
# y.y.y.y = IP smartvisu webserver
# z.z.z.z = IP FHEM host
cisco tcp-state-bypass
access-list state-bypass extended permit tcp any host [your-dest-ip] eq 2121
!
class-map class-state-bypass
match access-list state-bypass
!
policy-map global-policy
class class-state-bypass
set connection advanced-options tcp-state-bypass
!
Hi Uli,
:) - vielen Dank..
Zur Nachahmung kann ich das jedoch nicht empfehlen und ich möchte dringend darauf hinweisen das es höchst gefährlich ist das offen ins Netz zu stellen. Ernsthaft ! Nein, No, Njet, Nada ...
aktuell: Extern == VPN !!! (eine ASA ist ja auch nicht ganz ungeeignet ;) )
Ansonsten, fachlich: technisch hast Du ja einige Punkte "kennengelernt" (da fehlt noch ein out of band ssl handshake) - was in Summe auch der Grund ist warum das (stand heute) in fronthem und smartVisu nicht implementiert ist.
Wenn ich vorschlagen darf: auf den Reverse Proxy würde ich verzichten - Du kannst ssl ja direkt über den (sv) webserver bedienen. Dort lässt sich die Validierung der Zertifikate auch mit wenigen Zeilen code (index.php) implementieren, die server vars liefern ja alles wenn die entsprechende root autority (privat oder public) händisch eingerichtet ist.
Die Prüfung der certs hab ich im design in fronthem (im Keim) angelegt, cert und root müssten halt dort auch händisch hinterlegt werden und der wss braucht einen eigenen fork auf eigenem port. Ich habe den ws schon deutlichem Blick auf einen zukünftig sicheren Zugriff gestaltet. (code injection oder dos sollten ausgeschossen sein) - theoretisch zumindest. Bevor da aber niemand anderes nochmal einen code review durchgeführt hat (und ssl steht) ist mMn alles andere als vpn Harakiri (wenn produktiv). Trotzdem sind Experiment richtig, speziell auch um Erfahrung für die Umsetzung zu sammeln. Auf das IE und FF Verhalten bzgl https + ws kann ich mir spontan keinen Reim machen.
An Rande noch: in Deiner cfg teilen sich simultane, externe clients ein fronthemDevice. Bei simultanem Zugriff führt das sofort zu Fehlern weil sich die device gegenseitig die Monitor List überschrieben.
vg
jörg
Hallo
danke fuer die antworten. Aber was stelle ich fuer den kalender in der config.ini ein. Diese ics Datei liegt local in einem ordner. Waere schoen wenn ihr mir die config und den import posten koennt danke bumbumb
Zitat von: herrmannj am 26 März 2015, 22:10:45
Zur Nachahmung kann ich das jedoch nicht empfehlen und ich möchte dringend darauf hinweisen das es höchst gefährlich ist das offen ins Netz zu stellen. Ernsthaft ! Nein, No, Njet, Nada ...
Es ist gut, dass Du das noch einmal klar stellst. Ich hätte es in meinem Betrag deutlicher formulieren sollen, dass weder die Verschlüsselung noch die Authentifzierung über einen reverse Proxy sauber funktionieren und dass das der Showstopper ist. Mir war allerdings nicht klar, dass ein fromthem device nicht von mehrern Geräten angesprochen werden darf. Damit hat sich dann Thema dann eh erledigt.
Nebenbei: fronthem/sv ist ein geniales Projekt, dass FHEM weit nach vorne bringt.
/Uli
Zitat von: bumbumb am 27 März 2015, 06:01:55
Hallo
danke fuer die antworten. Aber was stelle ich fuer den kalender in der config.ini ein. Diese ics Datei liegt local in einem ordner. Waere schoen wenn ihr mir die config und den import posten koennt danke bumbumb
Hallo,
als Kalenderservice wählst du ical aus. Bei der Kalenderurl trägst du den Pfad der ics-Datei ein:file:/tmp/Termine.ics
Wenn du dann noch eine Standardfarbe oder ein Standardicon setzen willst, sieht die Url so aus: /tmp/Termine.ics(#ff69b4,scene_party).
Der Import erfolgt so:
{% import "widget_ical.html" as calendar %}
{{ calendar.list('calendarlist', 'Termine', 20, 14) }}
Wobei die 20 die max. Anzahl der angezeigten Termin ist und die 14 die Anzahl der Tage die im Kalender nach vorne
geprüft wird.
Gruß Norbert
Hallo,
ich habe heute mal versucht, meinen Abfallkalender einzubinden, das hat soweit auch ganz gut funktioniert, jedoch werden mir keine Icons und keine Farben angezeigt.
Eingebunden habe ich den Kalender mit http://172.16.0.4/Abfall.ics(#ff69b4,message_garbage).
da ich mit http://172.16.0.4/Abfall.ics in SV Garnichts angezeigt bekomme außer der Überschrift "Abfallkalender"
viele Grüße
Alexander
Hallo Alexander,
was steckt den hinter der 172.16.0.4 ?
Ist das ein CalDav-Server, oder nur ein Webserver? Wenn es ein Webserver ist, ist das dann der gleiche, auf dem SV läuft?
Wenn ja, solltest du nicht http, sondern file mit dem Pfad zur ics-Datei verwenden.
Diese Konstellation habe ich so nicht getestet. Werde ich heute Abend aber mal ausprobieren.
Gruß Norbert
Hallo,
ich habe mir ein Kalender-Widget gebaut, das auf das Calview-Modul bzw. Calendar-Modul von Fhem aufbaut. Somit kann ich auch den Apple-Kalender nutzen. Jetzt muß ich nur noch die Sekunden bei der Uhrzeit wegbekommen.
Edit: anbei das Widget-File. Einfach in den eigenen Pages-Ordner kopieren. und dann wie folgt einbinden:
{% import "widget_calendar_calview.html" as calview %}
{% set fcs = [1, 2, 3, 4, 5] %}
{{ calview.calendar_view("Kalender", fcs) }}
mit "set fcs = [1, 2, 3, 4, 5]" wird die Anzahl der darzustellenden Zeilen festgelegt. In diesem Fall sind es fünf Zeilen.
Die Verknüfung mit Fhem laüft dann über den GAD-Editor mit dem Calview-Device.
Vielleicht kann mir aber noch einer einen Tip geben, wie ich bei der Uhrzeit nur Stunden und Minuten angezeigt bekomme.
Gruß, Sascha
Zitat von: Cybers am 27 März 2015, 14:34:18
ich habe mir ein Kalender-Widget gebaut, das auf das Calview-Modul bzw. Calendar-Modul von Fhem aufbaut. Somit kann ich auch den Apple-Kalender nutzen. Jetzt muß ich nur noch die Sekunden bei der Uhrzeit wegbekommen.
Stellst du dein Widget bitte auch zur Verfügung?
Vielen Dank!
Gruß Lars
das Widget habe ich im letzten Beitrag bereitgestellt.
Gruß, Sascha
Zitat von: redlav am 27 März 2015, 12:55:06
Hallo Alexander,
was steckt den hinter der 172.16.0.4 ?
Ist das ein CalDav-Server, oder nur ein Webserver? Wenn es ein Webserver ist, ist das dann der gleiche, auf dem SV läuft?
Wenn ja, solltest du nicht http, sondern file mit dem Pfad zur ics-Datei verwenden.
Diese Konstellation habe ich so nicht getestet. Werde ich heute Abend aber mal ausprobieren.
Gruß Norbert
Hallo Norbert,
das ist leider nur ein Webserver, auf dem aber auch SV und FHEM laufen. Ich habe die Pfad jetzt mal in
/var/www/Abfall.ics(#ff69b4,message_garbage). geändert und jetzt wird mir wieder nur die Überschrift "Abfalltermine" in SV angezeigt, jedoch fehlen die Einträge in SV.
viele Grüße
Alexander
nur geraten: hast du mal einen relativen Pfad probiert ? Rechte auf der ics ?
vg
jörg
Zitat von: Hans Franz am 26 März 2015, 00:01:42
Hallo Bernd,
Sehr geil. Danke.
Ich habe allerdings zuerst keine earliest- und latest-Werte angegeben. Dann wird um 00:00 geschaltet(oder ich habe etwas falsch gemacht).
Kleine Ergänzung in UZSU_execute:
if ($uzsu->{list}[$i]->{timeMin} ne '' and $uzsu->{list}[$i]->{timeMax} ne '') {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$uzsu->{list}[$i]->{timeMin}.'","'.$uzsu->{list}[$i]->{timeMax}.'")}|'.$uzsu->{list}[$i]->{value};
}
else {
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs()}|'.$uzsu->{list}[$i]->{value};
}
Jetzt klappts auch mit leeren Werten.
timeOffset vergessen. Ich bin schon zu müde.
Hallo, kann ich so nicht bestätigen, klappt bei mir auch mit dem von mir geposteten Code vollständig korrekt. Woran könnte das liegen?
Ich erhalte bei eingesetzten Zeiten korrekte Zeiten und bei weggelassenen Zeiten korrekt "" im timestring, was der WDT auch korrekt auswertet.
Ist Dein UZSU-Konverter aktuell?
Zitat von: herrmannj am 27 März 2015, 17:18:27
nur geraten: hast du mal einen relativen Pfad probiert ? Rechte auf der ics ?
vg
jörg
Hatte ich gerade nochmal geprüft, hat aber keine Auswirkung.
So, versuche mich da jetzt auch mal einzuarbeiten in diese ganzen SmartVISU-Geschichten. Mal eine Frage: Ihr habt ja SmartVISU praktisch geforkt und da FHEM-spezifische Anpassungen gemacht, richtig? Ist das noch mehr außer dem Treiber?
Sind da auch Änderungen bei, die man evtl. mal Upstream geben sollte? Habe gesehen, dass zB die Config auf ein INI-File umgestellt wurde.
korrekt. Der fork stellt die mandantenfähigkeit in sv überhaupt erst her. Beim driver entweder domotiga oder fhem. (fhem ist schneller, noch beta)
Was haltet ihr davon, die allgemeinen Änderungen an eurem SV per Pull-Request an Upstream zu geben und die FHEM-Spezialitäten in einen eigenen Branch zu packen? Ich denke, dann hätte man eine saubere Trennung zwischen "Vanilla"-SV und FHEM-SV und könnte dadurch auch Änderungen sowohl up- als auch auch downstream gut verwalten.
immer sachte mit den jungen Pferden. Läuft und wächst doch - und im git auch vernünftig wartbar. Ich denke wir schauen erst mal nach plot und co - dann können wir doch immer noch weiter sehen - oder ?
vg
jörg
Zitat von: avg123-de am 27 März 2015, 17:07:30
Hallo Norbert,
das ist leider nur ein Webserver, auf dem aber auch SV und FHEM laufen. Ich habe die Pfad jetzt mal in /var/www/Abfall.ics(#ff69b4,message_garbage). geändert und jetzt wird mir wieder nur die Überschrift "Abfalltermine" in SV angezeigt, jedoch fehlen die Einträge in SV.
viele Grüß
Alexander
Hallo Alexander,
kannst du mal in die Konsole deines Browser gucken? Da müsste eine Zeile ein, in der deine Kalenderurl auftaucht. Da dann auf das +-Zeichen davor klicken und dann unter Antwort oder Html nach einem Fehler ausschau halten.
Tippe aber auch auf nicht korrekten Pfad oder fehlende Rechte. Ich werde aber gleich auch nochmal versuchen, eine Lösung für den Zugriff auf das ics-File über einen Webserver zu finden.
Gruß Norbert
Hallo Norbert,
ich hatte gerade mal in die Konsole geschaut. Leider habe ich keine Meldungen in der Konsole.
Rechte hatte ich mit cd /var/www && sudo chmod -R a+w Abfall.ics && sudo usermod -a -G tty root && sudo usermod -a -G tty fhem vergeben.
viele Grüße
Alexander
Hallo Alexander,
probier mal das ical-Script aus dem Anhang mit deiner Webserveradresse. Ich habe etwas geändert. Damit lief es dann bei mir und ich konnte auch DefaultIcon/Farbe setzen.
Gruß Norbert
Edit: Alexander != Alex. Sorry ;)
hat eigentlich mal jemand von Euch in den "New FHEM Tablet UI" thread reingeschaut ? Ich glaub die widgets (sind gut dabei die Jungs) sind sehr ähnlich aufgebaut wie die sv widgets. Zumnidest was den js Teil betrifft, damit vmtl auch sehr einfach zu portieren. Da könnten gute synergien liegen, allerdings habe ich ausreichend Baustellen um mir das genau anzuschauen - vielleicht mag ja jemand ?
vg
jörg
Zitat von: redlav am 27 März 2015, 20:29:39
Hallo Alexander,
probier mal das ical-Script aus dem Anhang mit deiner Webserveradresse. Ich habe etwas geändert. Damit lief es dann bei mir und ich konnte auch DefaultIcon/Farbe setzen.
Gruß Norbert
Edit: Alexander != Alex. Sorry ;)
Hallo Norbert,
ich habe die Datei jetzt eingebunden. Was mir direkt auffiel, ich konnte jetzt die Kalendereinträge direkt mit
http://172.16.0.4/Abfall.ics anzeigen lassen mit den Standard Icon (Sprechblase).
Wenn ich das gleiche jetzt mit
http://172.16.0.4/Abfall.ics(#ff69b4,message_garbage). einbinde habe ich immer noch das Problem, dass das Icon message_garbage.png nicht angezeigt bekomme, obwohl es in dem verlinkten Ordner enthalten ist.
viele Grüße
Alexander
Hallo Alexander,
kann ich bei mir nicht nachvollziehen. Wenn ich alles so eingebe wir du sieht mein Kalender korrekt aus.
Wenn ich ein nicht existierendes Icon angebe, wird es natürlich auch nicht angezeigt ::)
Dafür bekomme ich aber eine Fehlermeldung in der Konsole.
Merkwürdig.
Hallo
ich habe einen HM -cc-RT- Dn hat jemand eine Beschreibung wie ich diesen in smatvisu Einbinden kann. In fhem habe ich es geschaft.
bitte auch mit Readings etc. oder einen Link wo es genau steht.
danke bumbumb
Hallo
ich habe einen HM -cc-RT- Dn hat jemand eine Beschreibung wie ich diesen in smatvisu Einbinden kann. In fhem habe ich es geschaft.
bitte auch mit Readings etc. oder einen Link wo es genau steht.
danke bumbumb
Wie organisiert ihr eigentlich eure Widgets? Also wohin legt ihr die html-Dateien mit Zusatzwidgets? Im Moment habe ich die in meinem page-Verzeichnis liegen, was ich aber eigentlich nicht so schön finde, da die Widgets ja nicht unbedingt page-spezifisch sind (andere Pages könnten die ja auch nutzen wollen).
Falls es da noch keinen Mechanismus für gibt, würde ich gerne in die index.php ein eigenes konfgurierbares Zusatzverzeichnis für User-Widgets anlegen. Was haltet ihr davon?
Hallo
ich habe den hm cc-rt DN in fhem eingebunden. Dort kann ich aber nicht die neue desire Temp setzen. Warum geht das nicht ich nutze den Channel 4 Clima. Könnt ihr mir helfen. Warum geht es mit smart visu nicht. Auch umschalten zuwischen Auto manuel etc. geht nicht= Smartvise 2.8 habt ihr ne IDee
danke und gruss bumbumb
Zitat von: vbs am 28 März 2015, 00:07:55
Wie organisiert ihr eigentlich eure Widgets? Also wohin legt ihr die html-Dateien mit Zusatzwidgets?
Schau mal hier: http://forum.fhem.de/index.php/topic,30909.msg276209.html#msg276209
und hier: http://forum.fhem.de/index.php/topic,30909.msg276232.html#msg276232
Zitat von: bumbumb am 28 März 2015, 01:12:44
geht nicht= Smartvise 2.8 habt ihr ne IDee
Ich würde aktuell dringend davon abraten, SmartVISU V2.8 aus dem SV-trunk zu verwenden. Wenn wir Fehler und Probleme suchen, ist es schon so schwierig genung. Wenn wir auch noch mit unterschiedlichen Versionen arbeiten, dann wird es noch schwieriger, etwas nachzuvollziehen.
Aktuell solle man die 2.7 aus https://github.com/herrmannj/smartvisu-cleaninstall, wenn man Mandanten benötigt oder den 2.7 Download von der SV-Page verwenden.
Jetzt habe ich aber gerade etwas entdeckt. In der config.ini.default in smartvisu-cleaninstall steht
version = '2.8' drin, das ist doch aber eine 2.7, oder?
Damit ist dann eher unklar, ob bumbumb eine 2.7 oder eine 2.8 verwendet.
Nachtrag: eventuell könnte man die Version in smartvisu-cleaninstall 2.7F (F wie fronthem) nennen, um sie von einer SV-Original-Installation unterscheiden zu können)
Zitat von: vbs am 28 März 2015, 00:07:55
Wie organisiert ihr eigentlich eure Widgets? Also wohin legt ihr die html-Dateien mit Zusatzwidgets? Im Moment habe ich die in meinem page-Verzeichnis liegen, was ich aber eigentlich nicht so schön finde, da die Widgets ja nicht unbedingt page-spezifisch sind (andere Pages könnten die ja auch nutzen wollen).
Falls es da noch keinen Mechanismus für gibt, würde ich gerne in die index.php ein eigenes konfgurierbares Zusatzverzeichnis für User-Widgets anlegen. Was haltet ihr davon?
Ich habe sie inzwischen im widgets Folder abgelegt und mit der JS Import Methode hier aus dem Thread in die jeweiligen visu.js eingebunden.
In einem Fronthem SmartVISU nutzen ja evtl alle Clients unterschiedliche PAGES aber dieselben WIDGETS...
Eine Lösung mit einem customWidgets Folder, der automatisch mit im Suchpfad ist, fände ich aber auch gut!
Zitat von: HCS am 28 März 2015, 07:50:55
In der config.ini.default in smartvisu-cleaninstall steht version = '2.8'
:) ja - das war ich. Hast aber recht, ist nicht mehr ganz eindeutig. Vielleicht besser 2.7-FH oder so ... ?
vg
jörg
Zitat von: bgewehr am 28 März 2015, 09:54:36
Eine Lösung mit einem customWidgets Folder, der automatisch mit im Suchpfad ist, fände ich aber auch gut!
Im Prinzip funktioniert das doch - oder ?
vg
jörg
Zitat von: herrmannj am 28 März 2015, 10:09:41
Im Prinzip funktioniert das doch - oder ?
vg
jörg
Ich muss nochmal genau prüfen, aber ich glaube, wenn ich das sv-cleaninstall clone durch Hinzufügen verändert habe, kann ich kein GIT pull mehr machen ohne vorher git stash, dann sind aber alle meine Veränderungen Weg...
Es ist also der Updatepfad, der mich beschäftigt.
Wir könnten aber einen customwidgets Folder in das cleaninstall aufnehmen, ihn in die Ladeprozesse integrieren und dort den Inhalt des widgets GITs ablegen, dann ist das nicht so kompliziert mit den Updates...
Vorschläge?
Ich hab da mal etwas gebastelt, um eigene Widgets komplett zu trennen vom eigentlichen SmartVisu-Verzeichnisbaum (soll auch unabhängig von pages sein). Und zwar hab ich in die config.ini einen weiteren Parameter "user_directory" hinzugefügt (und entsprechend "lib/functions.config.php") erweitert:
[smartVISU]
version = '2.8'
multiuser = true
ident_by_ip = true
ip_allowed = ''
ident_by_cert = false
ca_cert = ''
auto_add = true
user_directory = 'smartvisu-widgets'
Dann die index.php erweitert, damit dieser Pfad in die Suchpfade aufgenommen wird:
$loader->addPath(const_path.user_directory);
Außerdem zwei Variablen "icon0user" und "icon1user" angelegt, damit Icons auch aus dem User-Dir geladen werden können:
if (config_design == 'ice')
{
$twig->addGlobal('icon1', 'icons/bl/');
$twig->addGlobal('icon0', 'icons/sw/');
$twig->addGlobal('icon1user', user_directory . 'icons/bl/');
$twig->addGlobal('icon0user', user_directory . 'icons/sw/');
}
elseif (config_design == 'greenhornet')
{
$twig->addGlobal('icon1', 'icons/gn/');
$twig->addGlobal('icon0', 'icons/ws/');
$twig->addGlobal('icon1user', user_directory . 'icons/gn/');
$twig->addGlobal('icon0user', user_directory . 'icons/ws/');
}
else
{
$twig->addGlobal('icon1', 'icons/or/');
$twig->addGlobal('icon0', 'icons/ws/');
$twig->addGlobal('icon1user', user_directory . 'icons/or/');
$twig->addGlobal('icon0user', user_directory . 'icons/ws/');
}
In seinen Widgets muss man dann jedoch, je nachdem, ob die Icons aus SmartVISU oder aus dem User-Dir kommen, entweder "icon0" oder "icon0user" angeben (bzw. icon1).
Nun habe ich das smartvisu-widgets-Repository (https://github.com/herrmannj/smartvisu-widgets (https://github.com/herrmannj/smartvisu-widgets)) als Unterverzeichnis in mein SV gelegt (als Submodule, damit Git nicht verwirrt wird). Das klappt auch soweit und ich kann nun Widgets aus dem Verzeichnis zB einbinden mit "{% import "homematic/widget_homematic.html" as homematic %}". Und er lädt dann auch die Icons entsprechend aus "smartvisu-widgets/icons" (musste dazu jedoch zB in dem Homematic-Widget ein Icon umstellen von icon0 auf icon0user).
Was jetzt jedoch noch fehlt, ist ein Mechanismus, um die js-Dateien aus dem User-Dir einzubinden. Da bin ich im Moment noch am Grübeln...
Ich werde die Sachen nachher mal versuchen, sauber in mein Git einzuchecken. Kann ich dann gerne posten bei Interesse. Ist natürlich erstmal nur ein Vorschlag. Was haltet ihr davon? Ideen zur Verbesserung?
Zitat von: bgewehr am 27 März 2015, 17:48:39
Hallo, kann ich so nicht bestätigen, klappt bei mir auch mit dem von mir geposteten Code vollständig korrekt. Woran könnte das liegen?
Ich erhalte bei eingesetzten Zeiten korrekte Zeiten und bei weggelassenen Zeiten korrekt "" im timestring, was der WDT auch korrekt auswertet.
Ist Dein UZSU-Konverter aktuell?
Hallo Bernd,
Ich raff's nicht.
UZSU_execute mit den neuen Zeilen ergibt immer
{sunrise_abs("REAL",0,"","")}, und damit eine Zeit von 00:00. Ist ja auch korrekt lt. commandref:
ZitatThe second and third specify min and max values (format: "HH:MM").
Der UZSU-Konverter:
###############################################################################
# For use with UZSU-Widget in SV and UZSU-notify in fhem
# Setreading a device reading using JSON conversion (gadval => reading=decode_json() => setval => encode_json(reading) )
# the reading (e.g. "uzsu") must be created manually for each USU-enabled device in fhem using "setreading <device> uzsu {}"
# in the fhem commandline
###############################################################################
sub UZSU(@)
{
my ($param) = @_;
my $cmd = $param->{cmd};
my $gad = $param->{gad};
my $gadval = $param->{gadval};
my $device = $param->{device};
my $reading = $param->{reading};
my $event = $param->{event};
my @args = @{$param->{args}};
my $cache = $param->{cache};
if ($param->{cmd} eq 'get')
{
$param->{cmd} = 'send';
}
if ($param->{cmd} eq 'send')
{
$param->{gad} = $gad;
$param->{gadval} = main::fronthem_decodejson(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
return undef;
}
elsif ($param->{cmd} eq 'rcv')
{
$gadval = main::fronthem_encodejson($gadval);
$gadval =~ s/;/;;/ig;
$param->{result} = main::fhem("setreading $device $reading $gadval");
$param->{results} = [];
return 'done';
}
elsif ($param->{cmd} eq '?')
{
return 'usage: UZSU';
}
return undef;
}Irgenwo hakt es noch bei mir.
Gruß
Hans
Edit:
Habe es vorerst 'mal so gelöst:
my $sun_min = $uzsu->{list}[$i]->{timeMin} ne '' ? $uzsu->{list}[$i]->{timeMin} :'00:00';
my $sun_max = $uzsu->{list}[$i]->{timeMax} ne '' ? $uzsu->{list}[$i]->{timeMax} :'23:59';
$weekdays_part = $weekdays_part.' '.$weekdays.'|{'.$uzsu->{list}[$i]->{event}.'_abs("REAL",'.$uzsu->{list}[$i]->{timeOffset} * 60 .',"'.$sun_min.'","'.$sun_max.'")}|'.$uzsu->{list}[$i]->{value};
Hallo
ich habe es jetzt mit dem HM-cc-RT-DN hinbekommen. Was aber noch fehlt ist der aktuelle Baterriestatus. Was muss gemacht werden, damit dieser Funktioniert. Wie kann man die Umschaltzeiten von 2,5 Minuten verkürzen. Wie kann man die Texte für den Status anzeigen ohne die --- Striche
Bin für jeden Tip dank bar. Danke
Bumbumb
Umschaltzeit kann man mMn nicht verändern. Die Striche bekommst du wege, indem du für txt-gad null oder "" übergibst. Batterie musst du ein gad anlegen und mit Batterie-Level-Reading per NumDirect verknüpfen. So zumindest ging es bei mir.
ok,
ich habe es so gemacht. In Fhem steht für Batterylevel 3.2 und battery = ok, das reading ist angelegt aber das Icon ändert sich nicht. Hast du noch eine Idee. Wie ist es bei einem Schalten von Homeatic hat man dort auch die 2m5 min. bis dann das Licht angeht?. Wäre schön wenn es mit der Batterie noch klappen würde. Wofür sind den die --- gewesen?
Gruß
bumbumb
@bumbum: Zur Batterie steht hier eine ganze Menge im Thread.
Der Statuswechsel kommt live. Und das bei JEDEM Homematic Device (max 2-3 Sekunden - in der Regel eher unter 1 Sekunde). Der Zeitversatz beim HM-Thermostat kommt daher, dass das Device nur alle paar Minuten aufwacht und dann den Befehle annimmt. Das ist ein völlig normales Verhalten und hat nichts mit Fronthem und SmartVisu zu tun.
danke für deine Info,
ich habe das homeatic device angelegt, leider fehlen die aktuellen Fhem Einstellungen dafür.
Könnt die die Fhem Einstellung dafür
id, txt, gad_actual, gad_set, gad_controlmode, gad_daytemp, gad_nighttemp, gad_window, gad_battery, gad_state, gad_txt, step, gad_valve, gad_humidity
posten wäre echt toll kann die richtigen einstellungen nicht finden
ich meine natürlich die Readings in Fhem
Zwei Sachen, die mir aufgefallen sind. Zum einen wird in FHEM der lauschende Websocket nicht mehr richtig geöffnet, wenn ich "shutdown restart" eingebe. Im Log erscheint dann sowas und es ist kein Zugriff mehr möglich:
2015.03.28 20:00:29 2: fronthem: ipc listener opened at port 16385
2015.03.28 20:00:29 1: Including ./log/fhem.save
2015.03.28 20:00:29 1: in INITIALIZED
2015.03.28 20:00:29 1: in INITIALIZED
2015.03.28 20:00:29 3: Opening sbserver device 192.168.2.232:9090
2015.03.28 20:00:29 3: sbserver device opened
2015.03.28 20:00:29 3: SB_SERVER_DoInit(sbserver): STATE: opened power: ?
2015.03.28 20:00:29 3: SB_SERVER_DoInit(sbserver): SB-Server is back again.
2015.03.28 20:00:29 2: 1
2015.03.28 20:00:29 0: Server started with 247 defined entities (version $Id: fhem.pl 8265 2015-03-22 13:58:15Z rudolfkoenig $, os linux, user tc, pid 17607)
2015.03.28 20:00:29 1: Perfmon: possible freeze starting at 20:00:25, delay is 4.977
2015.03.28 20:00:29 1: HMLAN_Parse: HMLAN0 new condition ok
2015.03.28 20:00:30 1: tv.fritz.box:55000 reappeared (wz_tv)
2015.03.28 20:00:30 3: ipc fronthem:127.0.0.1:52287 (ws): ws alive with pid 17609
2015.03.28 20:00:30 1: ipc fronthem:127.0.0.1:52287 (ws): ws could not open port 2121
2015.03.28 20:00:30 1: fronthem: thread ws closed for unknown reason
Wenn ich dann korrekt FHEM beende und händisch neu starte, dann funktioniert es wieder.
Und ich habe ziemlich viel solche Sachen im Log:
2015.03.22 12:32:48 1: in DEFINED
2015.03.22 12:32:48 1: in DEFINED
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:32:48 1: in ATTR
2015.03.22 12:33:46 1: in DELETED
Das kommt wohl aus der Datei 01_fronthem.pm:
sub
fronthem_Notify($$)
{
my ($hash, $ntfyDev) = @_;
my $ntfyDevName = $ntfyDev->{NAME};
# responde to fhem system events
# INITIALIZED|REREADCFG|DEFINED|RENAMED|SHUTDOWN
if ($ntfyDevName eq "global")
{
foreach my $event (@{$ntfyDev->{CHANGED}})
{
my @e = split(' ', $event);
Log3 ($hash, 1, "in $e[0]"); #TODO remove
Ist sogar schon mit "TODO remove" kommentiert. Sollte man das mal machen? Ich hab jetzt für mich erstmal das verbose-Level auf 0 gedreht. Das sollte ja erstmal helfen.
Du meinst vmtl nicht shutdown retart sondern was anderes (reload) ?
vg
jörg
Hm, ist das falsch? Doch doch, ich meine "shutdown restart". Das gebe ich als Befehl in FHEM ein, um FHEM neu zu starten.
ok - das "sollte" nicht. Was für ein os ist 'n das ?
btw die Zeile mit dem Log kannste bei Dir auskommentieren.
vg
jötg
Das ist ein TinyCore-Linux (http://distro.ibiblio.org/tinycorelinux/), das auf einem Windows 8.1 mit i5-CPU als VMWare läuft.
Das Problem, dass nach einem FHEM restart der ws nicht geöffnet werden konnte (ws could not open port 2121), hatte ich auch mal, solange bis ich den Server (cubie) neu gestartet habe, dann war wieder gut.
schau ich mir an - wir hatten das schon mal (fhainz?) auf 'nem apple server. Ist nichts wildes - soll aber nicht sein. Evtl startet fhem wg schneller cpu schon wieder durch bevor der ws ganz down ist.
vg
jörg
@HCS meinst Du, Du könntest im SVCI GIT die verschiedenen Versionen des Treibers zur Auswahl hinterlegen? Io_fhem102.js, io_fhem108.js usw? Sicher auch für die Fehleranalyse hilfreich!
Ich habe immer noch keine Lösung mit 1.08 und den swipe Events meiner Smartphone Pages (siehe mein multipage Git), da würde ich gern wählen können. Vielleicht gibt es ja noch andere, die ähnliche Themen haben.
Btw: bisher war bei mir bei weitem die schnellste Lösung mit 102 und tiefen delegates! Alles jetzt dauert Sekunden länger als diese Kombi!
Zitat von: bgewehr am 28 März 2015, 20:32:45
@HCS meinst Du, Du könntest im SVCI GIT die verschiedenen Versionen des Treibers zur Auswahl hinterlegen? Io_fhem102.js, io_fhem108.js usw
Generell schon, aber sobald Jörg mit den charts so weit ist, werden die nur mit 1.08 aufwärts gehen.
Zitat von: bgewehr am 28 März 2015, 20:32:45Btw: bisher war bei mir bei weitem die schnellste Lösung mit 102 und tiefen delegates! Alles jetzt dauert Sekunden länger als diese Kombi!
Das ist interessant. Bei mir ist die 1.08 genauso schnell.
Da sollten wir eher dahinter kommen, warum die bei Dir langsamer ist, als die 1.02 mit tiefergelegten.
Was kann ich tun?
Die swipe Events funktionieren am Desktop chrome und ie, aber nicht am Mobile Safari mit 108.
Zeitmessung und debugging ist ja am Desktop kein Problem, aber wie mache ich die Ursachensuche am iPhone?
Zitat von: herrmannj am 28 März 2015, 20:29:08
schau ich mir an - wir hatten das schon mal (fhainz?) auf 'nem apple server. Ist nichts wildes - soll aber nicht sein. Evtl startet fhem wg schneller cpu schon wieder durch bevor der ws ganz down ist.
das neustart Problem hab ich leider immer noch :( derzeit erledigt den neustart noch ein notify, das fronthem löscht und anschließend FHEM neustartet seinen dienst.
edit:ich hab auch schonmal FHEM auf einem 2. mac installiert. auch hier war nach dem fronthem define schluss mit normalen neustarten.
Hin und wieder quittert fronthem mit diesen meldungen den dienst. Hab aber noch nicht nachgeforscht was das sein könnte.
2015.03.28 16:02:30.352 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/31_fronthemDevice.pm line 465.
2015.03.28 16:02:30.352 3: ENIGMA2 set wzReceiver record
2015.03.28 16:05:59.644 1: fronthem: thread ws closed for unknown reason
@bgewehr: wg. Speed: wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist.
Dazu müsstest Du das (ab Zeile 193):
// -----------------------------------------------------------------------------
// Try to call the update handler of a widget
// -----------------------------------------------------------------------------
callUpdateHandler: function(item, values) {
var cachedWidget = io.action[$(item).attr('data-widget')];
if(cachedWidget) {
cachedWidget.handler.call(item, 'update', values);
}
else {
$(item).trigger('update', values);
}
},
so umbauen:
// -----------------------------------------------------------------------------
// Try to call the update handler of a widget
// -----------------------------------------------------------------------------
callUpdateHandler: function(item, values) {
$(item).trigger('update', values);
},
Dauert es eigentlich lang, bis das erste GAD aktualisiert wird oder von GAD zu GAD lang?
Ist die 1.02 mit den tiefergelegten auf allen Deinen Geräten schneller?
Welchen Einfluss der Treiber beim mobile safari auf swipe haben kann, ist mir momentan völlig unklar.
Funktioniert die page ansonsten auf dem mobile safari wie sie soll?
Da war doch irgendwo ein git, in dem Du das hast und ich mal schauen kann, wie Du das eigentlich implementiert hast?
Hallo,
leider klappt es mit dem Calendar nicht.
die Dateien habe ich gemaes Anleitung in die Ordner kopiert.
http://forum.fhem.de/index.php/topic,33231.msg277847.html#msg277847
Auf der index.html seite kommt aber nichts, einfach nichts.
was kann es sein.
Zitat von: HCS am 28 März 2015, 21:12:21
1) wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist. Dazu müsstest Du das so umbauen...
2) Dauert es eigentlich lang, bis das erste GAD aktualisiert wird oder von GAD zu GAD lang?
3) Ist die 1.02 mit den tiefergelegten auf allen Deinen Geräten schneller?
4) Welchen Einfluss der Treiber beim mobile safari auf swipe haben kann, ist mir momentan völlig unklar.
5) Funktioniert die page ansonsten auf dem mobile safari wie sie soll?
6) Da war doch irgendwo ein git, in dem Du das hast und ich mal schauen kann, wie Du das eigentlich implementiert hast?
1) mache ich morgen
2) das wechseln der Seite dauert bei 108 bis 2s länger als bei 102. wenn eine Seite einmal geladen ist, dauert es einige Zeit < 2s, dann kommen rasch alle Gads. Mit 102 und Tiefen delegates und Cache dauerte alles einmal 1,5s und dann war keine Verzögerung mehr spürbar
3) muss ich morgen mal systematisch analysieren, bisher Haupterkenntnisse auf dem iPhone 6 und einem iPad Air
4) Die swipe Events scheinen einfach nicht zu zünden, sobald der 108 Treiber verwendet wird.
5) Ja, die erste Seite lädt wie gewohnt, ich kann aber nicht auf die anderen Seiten wischen. Prinzipiell könnte auch ein Ladefehler bei einer der Folgeseiten passieren, der einen js Fehler verursacht, der den weiteren Ablauf stört. Kann ich aber auf dem iPhone nicht debuggen...
6) http://github.com/bgewehr - es ist das multipage Git. Ist so nicht lauffähig, weil die Widgets bei mir im widgets Folder liegen und nicht im pages Folder. Schau Dir die Struktur mal an, ich lade in der index.html alle Seiten und navigiere dann mit #wohnzimmer oder per swipe Events aus der Visu.js lief SUPERflott mit 102 und tief und Cache.
Warum wird mein kalender nicht angezeigt
@bgewehr: schau mal das an: http://appletoolbox.com/2014/05/use-web-inspector-debug-mobile-safari/
remote debugging eines mobile safari vom mac aus.
Ich kann es nicht probieren, habe einen mac aber kein i***
Ich hoffe, bei Dir ist es nicht genau umgekehrt.
Ich baue mal in den Treiber noch ein globales exception handling zum Testen ein, das exceptions so gut es geht fängt und als alert ausgibt.
@HCS: Ich kann bgewehrs Beitrag zur Geschwindigkeit der Treiber bestätigen. Auf dem schnellen Laptop sieht der 1.08 sehr schnell aus und hier ist es auch empirisch belegbar, dass er schneller ist, als 1.02 und tief liegende delegates. Die Zeiten kann ich auf anderen Devices in etwa so bestätigen (je nach Anzahl der gads). Auf den langsameren Devices (auf denen auch keine Console möglich ist) ist jedoch die Sache mit den tief liegenden delegates sichtbar schneller. Bei mir handelt es sich nicht im i... Devices sondern um Nexus 5 und aktuelle Samsung Tablets. Das hier ist keinerlei Kritik, nur eine Bestätigung von bgewehrs Beobachtung.
Ich sehe das doch richtig, dass auch tief liegende Widgets als Fallback bedient werden, oder? Leider muss sich dann aber auf den Seiten jeweils mindestens auch ein Widget mit einem document.delegate befinden (es muss mindestens eines gefunden werden), sonst bricht das Laden ab (Fehler in der Console habe ich leider nicht parat, habe ich hier aber schon einmal gepostet).
Zitat von: marvin78 am 29 März 2015, 09:00:55
Das hier ist keinerlei Kritik, nur eine Bestätigung von bgewehrs Beobachtung.
Logisch, fundierte Aussagen zum aktuellen Zustand sind nie Kritik.
Zitat von: marvin78 am 29 März 2015, 09:00:55
Bei mir handelt es sich nicht im i... Devices sondern um Nexus 5 und aktuelle Samsung Tablets.
Ein Nexus 5 habe ich auch, auf dem finde ich es von der Geschwindigkeit her ganz OK. Aber das ist natürlich auch persönliches Empfinden.
Wenn wir irgendwo noch speed rausholen können, macht es Sinn, es zu versuchen.
Zitat von: marvin78 am 29 März 2015, 09:00:55
Auf den langsameren Devices (auf denen auch keine Console möglich ist) ist jedoch die Sache mit den tief liegenden delegates sichtbar schneller
Schau mal in Zeile 650, da kann man definieren, für wie viele GADs eine Zeitmessung durchgeführt werden soll und in Zeile 670 die Messung scharf machen. Das gibt die ermittelten Zeiten als alert aus, geht also auch auf dem Nexus.
Die min.js nicht vergessen.
Zitat von: marvin78 am 29 März 2015, 09:00:55
Ich sehe das doch richtig, dass auch tief liegende Widgets als Fallback bedient werden, oder? Leider muss sich dann aber auf den Seiten jeweils mindestens auch ein Widget mit einem document.delegate befinden (es muss mindestens eines gefunden werden), sonst bricht das Laden ab (Fehler in der Console habe ich leider nicht parat, habe ich hier aber schon einmal gepostet).
Ich glaube, dass das der Fehler war, wenn mindestens ein tiefergelegtes dabei war. Das hier ist ja gerade anders herum.
Da muss ich mir mal eine Testseite mit nur tiefergelegten bauen und debuggen, wo es klemmt.
Ich mache gerade einen größeren Umbau im Treiber, da das bisher übernommene Update-Konzept von SV in Verbindung mit fronthem eigentlich doppelt aktualisiert hat. Es werden erst alle GADs aktualisiert, für die ein Wert im Cache ist, und dann mit Monitor die Daten von fronthem angefragt. fronthem liefert dann alle Werte für die GADs als Initialbefüllung, was dann sowieso alle GADs aktualisiert, somit ist die erste Aktualisierungs-Runde eigentlich recht nutzlos und verschwendete Zeit.
Evtl. gebe ich heute noch einen Treiber raus, um diese neue Update-Strategie von euch testen zu lassen, ob das generell bei allen so hinhaut.
Zitat von: HCS am 28 März 2015, 21:12:21
@bgewehr: wg. Speed: wenn Du willst, kannst Du die 1.08 mal mit den tiefergelegten probieren, ob die damit schneller ist.
Dazu müsstest Du das (ab Zeile 193):
// -----------------------------------------------------------------------------
// Try to call the update handler of a widget
// -----------------------------------------------------------------------------
callUpdateHandler: function(item, values) {
var cachedWidget = io.action[$(item).attr('data-widget')];
if(cachedWidget) {
cachedWidget.handler.call(item, 'update', values);
}
else {
$(item).trigger('update', values);
}
},
so umbauen:
// -----------------------------------------------------------------------------
// Try to call the update handler of a widget
// -----------------------------------------------------------------------------
callUpdateHandler: function(item, values) {
$(item).trigger('update', values);
},
Habe ich so gemacht, erstmal ohne Änderungen an den Widgets ausprobiert. Ergebnis:
- Hauptseite lädt, gefühlt genauso schnell wie vorher
- EINE Navigation ist nun möglich, also entweder eine Seite durch antippen öffnen oder swipeleft für wetter, tel und Cal
- Nach dem swiperight (zurück zu #index) ist die Navigation tot, kein tippen, kein wischen
Mit Treiber 102 alles wieder normal.
Zitat von: bgewehr am 29 März 2015, 13:15:41
- Hauptseite lädt, gefühlt genauso schnell wie vorher
Was das zu erwartende Ergebnis ist.
Zitat von: bgewehr am 29 März 2015, 13:15:41
- EINE Navigation ist nun möglich, also entweder eine Seite durch antippen öffnen oder swipeleft für wetter, tel und Cal
Seltsam.
Wie bekomme ich denn stressfrei Deine Installation ans Laufen?
Hast Du eine Chance, das remote zu debuggen (siehe weiter oben)?
Zitat von: bgewehr am 29 März 2015, 13:15:41- Nach dem swiperight (zurück zu #index) ist die Navigation tot, kein tippen, kein wischen
Ich habe immer noch keine Idee. Aber kann ja noch kommen... :)
Zitat von: HCS am 29 März 2015, 13:23:41
1) Wie bekomme ich denn stressfrei Deine Installation ans Laufen?
2) Hast Du eine Chance, das remote zu debuggen (siehe weiter oben)?
1) ich schicke Dir meinen widgets Folder als zip?
2) leider kein Mac in meiner Nähe... Gibt's da keine VM für?
Zitat von: bgewehr am 29 März 2015, 14:32:43
1) ich schicke Dir meinen widgets Folder als zip?
2) leider kein Mac in meiner Nähe... Gibt's da keine VM für?
1) wenn der reicht, dass es läuft, OK. Den kippe ich einfach in eine "cleaninstall" rein?
2) Vielleicht finde ich jemand, der ein eifon hat, bei dem ich mal debuggen darf. VM: musst googlen
Hallo,
wie kann ich mehrere Clients anlegen. Ich habe ein Laptop darüber rufe ich smartvisu auf. Jetzt möchte ich es über ein Pad machen. Muss ich für jeden Clienten die GADs in Fhem neuanlegen?
Könnt ihr mir helfen
bumbumb
brauchst nur pro client je ein fronthemdevice, die GADs teilen die sich. Entweder jeweils die Rechte vergeben oder whitelist=false
@HCS: hier mein widgets folder.
Wenn ich nicht irre, müsste ein cleaninstall SV damit meine gewehr_multipage_app Seiten wiedergeben können. Die Kamera in der Garage wird meckern, weil die IP...26 kein Bild liefert, aber egal. Ist nichts iPhone spezifisches drin, sollte also auch auf einem Android funktionieren...
Sehr nett, dass Du mir hilfst, danke!
Eben getestet auf einem Galaxy S5 mit Android 4.4.2: Läuft wie geschmiert, auch mit 1.08. Also wahrscheinlich leider keine debugging-Hilfe...
Da fehlt noch einiges mehr, lib/clock/jquery.jdigiclock.js, verschiedene bilder usw.
ZIPst vielleicht besser eine komplette installation zusammen, die kippe ich mir dann auf den webserver.
Mir wird gerade klar, warum ich so peinlich darauf achte, dass meine page auf einem völlig nativen 2.7 läuft ;)
Die Digiclock wird in der visu.js getriggert.
Entferne bitte diesen Teil:
// QLOCK screensaver
// idleTimer() takes an optional argument that defines the idle timeout
// timeout is in milliseconds; defaults to 30000
$(document).on('pageinit', function() {
if (jQuery().idleTimer && navigator.userAgent.match(/iPad/i) != null) {
$.idleTimer(300 * 1000);
}
});
$(document).bind('idle.idleTimer', function() {
$.mobile.changePage("index.php?page=qlock");
});
$(document).bind('active.idleTimer', function() {
parent.history.back();
});
Die Bilder können doch nur Hörmann sein, oder?
und sani heating boost oder so in der Art
Zitat von: HCS am 29 März 2015, 15:37:21
und sani heating boost oder so in der Art
@HCS
whitelist=false / in die config.ini ?
nein, das attribut im fronthemdevice
@bgewehr: die bleibt trotzdem beim Laden stehen.
Ein Forschungsprojekt, wie ich deine page zum Laufen bekomme hatte ich jetzt nicht vor.
ZIP doch einfach die Installation, vorher halt die Geheimnisse austragen und die WebComa schon mal ausbauen.
@HCS: mache ich, heute Abend...
Zitat von: bgewehr am 29 März 2015, 15:06:31Eben getestet auf einem Galaxy S5 mit Android 4.4.2: Läuft wie geschmiert, auch mit 1.08. Also wahrscheinlich leider keine debugging-Hilfe...
"Läuft wie geschmiert" bedeutet Geschwindigkeit gut und swipe geht? Oder langsam und funktioniert?
Zitat von: HCS am 29 März 2015, 16:14:20
"Läuft wie geschmiert" bedeutet Geschwindigkeit gut und swipe geht? Oder langsam und funktioniert?
Ich muss das relativieren: Navigation läuft wie geschmiert und auch sehr schnell, es kommen aber trotz whitelist keine GADS!
Ich hab jetzt meine eeeecht umfangreiche FHEM-Wurst einmal für einen Client alle GADs zusammen geklickt und hübsch gemacht.
Nu würde ich das gerne natürlich nicht für alle anderen Clients nicht auch noch mal machen wollen. Ich habe hier im Forum nix zu "klonen" oder "kopieren" gefunden. Stumpfes copy von "...www/fronthem/clients/meinlaptop/fhclient.meinlaptop.cfg" nach "..www/fronthem/clients/meiniphone/fhclient.meiniphone.cfg" hilft leider nicht. Wo steht denn der Krempel?
Außerdem bekomme ich aufm Eierphone mit dem FHEM-Treiber immer rechts oben in der Ecke das gelbe "Connection" (auch wenn Phone nicht einschläft). Mit Domotiga scheint es stabil zu gehen.
Und ich kann gerne anbieten, bei Debugging iPhone/Mac zu helfen!
Lege ein weiteres fhem device mit entsprechender ip an und setze in diesem das Attribut whitelist false
Der Krempel steht hier mehrmals im Thread und auch ein paar Post über deinem.
Das kopieren so wie du es gemacht, sollte eigentlich gehen, sofern die Dateinamen auch mit den fronthemDevice Namen passen.
Zitat von: bgewehr am 29 März 2015, 17:57:11
Ich muss das relativieren: Navigation läuft wie geschmiert und auch sehr schnell, es kommen aber trotz whitelist keine GADS!
Verdammt! Ich hatte whitelist auf true statt auf false gesetzt!
Nun sauschnell und alles geht mit gads!
Zitat von: bgewehr am 29 März 2015, 18:41:51Nun sauschnell und alles geht mit gads!
Was bedeutet das jetzt konkret? Deine Probleme haben sich gelöst und es geht mit der 1.08 sauschnell?
Alles bestens und nichts mehr zu tun?
Oh, sorry, nein, dies bezog sich auf die Nutzung auf dem Android 4.4.2 Device. Beim iPhone6 alles wie gehabt. Ich verdichte grade ein Git vor, damit das leichter nachvollzogen werden kann!
Warte doch einfach auf das iPhone7, vielleicht wir es ja damit besser :D :D
Im Ernst, das bedeutet, dass es auf dem iPhone6 nicht nur das Problem mit swipe gibt sondern darauf auch noch zusätzlich langsam ist?
Ich blicke nicht mehr durch, wo es bei dir jetzt schnell oder langsam ist.
Ich mach mal ne Tabelle...
soweit ich weiß unterscheiden sich IOS und Android in der Art des touch handlings - das könnte das erklären. Ich bin etwas short on time - kann mit beiden device aber testen und debuggen wenn der case steht.
Wenn sich das erhärtet dürfte die Ursache in jq oder jq mobile zu suchen sein - evtl schafft ein jq/jqm update da Abhilfe. Sehen wir aber dann. Bisher hab ich auf IOS keine degrades gesehen/wahrgenommen - was nicht sagen will das sie nicht existieren können ;)
vg
jörg
@HCS: auf meinem Iphone7SX sauschnell und 3D :P
Zitat von: herrmannj am 29 März 2015, 21:17:51soweit ich weiß unterscheiden sich IOS und Android in der Art des touch handlings - das könnte das erklären.
Das vermute ich auch, nur ist mir noch völlig unklar, was der Treiber da für einen Einfluss hat.
Solange mein Kristallkugel in der Werkstatt ist, ist das ohne zu debuggen kaum zu ergründen.
Zitat von: herrmannj am 29 März 2015, 21:17:51
... kann mit beiden device aber testen und debuggen wenn der case steht.
Das ist super, ich müsste meinen Sohn herzitieren, dass ich mit seinem iPhone debuggen darf.
Aber ich werde die bgewehr Installation mal draufpacken, um zu sehen, wie die auf meinen devices so läuft.
Zitat von: herrmannj am 29 März 2015, 21:20:06@HCS: auf meinem Iphone7SX sauschnell und 3D :P
Dachte ich es mir doch ;D
Zitat von: herrmannj am 29 März 2015, 21:17:51Ich bin etwas short on time -
Logisch, bist ja schließlich mit Hochdruck an den Charts dran ;)
Zitat von: HCS am 29 März 2015, 20:22:49
Ich blicke nicht mehr durch, wo es bei dir jetzt schnell oder langsam ist.
Schnell oder langsam ist meine zweite Sorge - erstmal wieder wischen können!
Hier mein Repo zum testen, läuft bei mit out-of-the-box in den gewünschten Fehler... ;-(
https://github.com/bgewehr/smartVISUTest
Da gibt es aber noch ein kleines Problem: pages/gewehr und pages/gewehr_multipage_app im repo sind leer.
Zitat von: HCS am 29 März 2015, 23:31:00
Da gibt es aber noch ein kleines Problem: pages/gewehr und pages/gewehr_multipage_app im repo sind leer.
Git subrepos habe ich offensichtlich noch nicht begriffen. Jetzt liegen zwei pages drin. Desktop und Smartphone. Das besagte Problem tritt in smartphone auf...
Zitat von: bgewehr am 30 März 2015, 06:56:05Das besagte Problem tritt in smartphone auf...
Sieht so aus, als ob wir Jörg nicht wegen debuggen belästigen müssen. Ich kann das besagte Problem wohl auf einem Desktop-Rechner nachvollziehen.
Navigation (auch Klick) mit 1.08 geht nicht. Ich ahne auch schon, was da generell passiert.
Muss heute Abend debuggen, um das richtig zu verstehen und die konkrete Ursache zu finden.
Hier mal mein angedrohter Vorschlag, wie man ein separates UserDirectory realisieren könnte. Die Idee ist, dass man sich ein Verzeichnis anlegt, in das man eigene Widgets (HTML, JavaScript und Icons) ablegen kann, ohne dass man irgendwas in das originale SmartVISU-Verzeichnis kopieren muss. Dadurch kann man hoffentlich die Widgets sauber verwalten und leicht updaten etc. Ich habe bei mir zum Beispiel das Widgets-Repo von Jörg 1:1 eingebunden.
Dazu hat man in der config.ini einen neuen Eintrag "user_directory":
[smartVISU]
version = '2.8'
multiuser = true
ident_by_ip = true
ip_allowed = ''
ident_by_cert = false
ca_cert = ''
auto_add = true
user_directory = 'smartvisu-widgets'
Dieses Verzeichnis liegt relativ zum SV-Verzeichnis und von dort können dann Widgets, JS und Icons geladen werden. Es bietet sich zum Beispiel an, das Widget-Repo hier als Submodule oder Unterverzeichnis einfach abzulegen (im SV-Verzeichnis).
Von dort können dann diese drei Sachen folgendermaßen geladen werden:
HTML-Widget-Dateien:
Können ganz regulär mit Angabe von Unterverzeichnissen eingebunden werden. Wenn man also das smartvisu-widgets-Repo hat, gibt es ja dort zB den Unterordner "homematic" mit den Dateien "widget_homematic.html" und "widget_homematic.js". Die HTML-Datei kann dann ganz regulär eingebunden werden mit:
{% import "homematic/widget_homematic.html" as homematic %}
JavaScript-Widget-Dateien:
Um die zugehörigen JavaScript-Dateien für die Widgets einzubinden gibt es im pages-Ordner nun die Datei "widgets.js.php". Dort können die JS-Dateien so eingebunden werden:
userInclude("homematic/widget_homematic.js");
Icons:
Zusätlich zu den SmartVISU-Variablen "icon0" und "icon1" gibt es nun die Variablen "icon0user" und "icon1user". Diese Variablen zeigen auf das Verzeichnis "icons" im User-Directory. Also in meinem Beispiel auf "./smartvisu-widgets/icons". Die Logik um normale bzw. highlighted Icons bzw. um theme-spezifische Icons zu laden ist genauso wie für die SmartVISU-Standard-Icons.
EDIT:
Achso, der Haken an der Sache mit den Icons ist natürlich so ein bisschen, dass die Widgets dann auch die neuen Variablen benutzen müssten. Also zum Beispiel müsste man im Homematic-Widget die Zeile mit dem Icon sani_boost_heating so aussehen lassen:
{{ basic.switch(id~'boost', gad_controlmode, icon1user~'sani_heating_boost.png', icon0user~'sani_heating_boost.png', 'boost', 'auto') }}
ENDEDIT
Selbstverständlich ist dies nur ein Vorschlag. Soweit ich sagen kann, funktioniert das Ganze zumindest bei mir bisher ganz gut. Ich würde mich freuen, wenn ihr noch gute Ideen habt, um das Ganze optimieren. Vielleicht gibt es aber jedoch auch noch gänzlich andere Ansätze?
Hier der Pull-Request auf gitHub:
https://github.com/herrmannj/smartvisu-cleaninstall/pull/2
@bgewehr: probier mal bitte diesen Treiber, ob damit deine Navigation funktioniert.
Hi,
bin mir nicht sicher ob meine Fragen besser hier oder in dem Allgemeine smartVISU Fragen Thread aufgehoben sind, aber ich frage sie mal hier- da sie eher fronthem als smartVISU betreffen..
Zunächst mal großen Respekt an alle Beteiligten, ich habe fronthem/smartVISU gestern aufgesetzt und hatte innerhalb einer halben Stunde meine ersten Readings in der Oberfläche, also das funktioniert schon mal sehr geschmeidig 8)
Folgende Fragen habe ich aktuell:
1. Das ganze ist ja heftig in der Entwicklung, wenn ich die Installation aktualisieren will, dann muss ich nur folgenden Befehl wieder eingeben:
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
Richtig?
2. Aktuell schaue ich mir öfter das Layout der bei smarVISU mitgelieferten Demo-Häuser an, schalte also die Pages auf ein anderes Verzeichnis. Dadurch habe ich dann in FHEM natürlich immer die ganzen GAD's, die meine Installation eigentlich gar nicht betreffen. Kann ich das irgendwie unterbinden? Und gibt es eine Möglichkeit, alle unbenutzten GAD's irgendwie zu entfernen, also anders als alle einzeln zu löschen? Sind leider ja recht viele :P
3. Irgendwo habe ich gelesen, dass ich zu den Widgets, beispielsweise die für Homematic, auch ein Javascript-File brauche. Ich habe mir einfach von https://github.com/bgewehr/smartVISU das File widget_homematic.html heruntergeladen und in meine Pages kopiert. Funktioniert soweit, ist das OK so?
4. Was heißt eigentlich "GAD"? klingt doof, aber egal wo man sich über smartVISU einliest, fällt im zweiten Satz die Abkürzung, aber nirgendwo steht was das eigentlich bedeutet ;D
5. Weiterhin habe ich irgendwo gelesen, das Plots noch nicht gehen, stimmt das? In dem Screenshot-Thread sehe ich aber welche, sind das Entwicklungsversionen oder kann ich doch schon Plots nutzen? Habe mal den plots.rtr probiert, hat jedenfalls nicht funktioniert.
Danke für Antworten!
Zu 1. Richtig
Zu 2. Den Treiber vorher auf offline stellen. Eine komfortablere Möglichkeit als die GADs einzeln zu löschen gibt es bisher nicht
Zitat von: HCS am 30 März 2015, 20:40:28
@bgewehr: probier mal bitte diesen Treiber, ob damit deine Navigation funktioniert.
JA, du HELD! Was war das Problem?
Zitat von: bgewehr am 30 März 2015, 20:52:08JA, du HELD!
Nicht übertreiben ;)
Zitat von: bgewehr am 30 März 2015, 20:52:08Was war das Problem?
Das braucht nun mehr als zwei Worte :-)
Der Treiber ruft für jedes GAD, für das fronthem einen Wert sendet, die update methode des widgets auf.
Der JS-Code eines widgets kann scheitern und mit einer Exception sich verabschieden. Das sorgt je nach verwendetem Browser dazu, das jquery auch stirbt und swipe und ähnliche events nicht mehr gehen. In manchen Browsern überlebt es wohl irgendwie. Nach einer exception ist der weitere Ablauf aber eher Zufall.
Da es recht unangenehm ist, dass ein aus dem Ruder gelaufenes Widget die ganze page killt, fange ich jetzt exceptions, die in der update methode eines widgets geworfen werden ab und logge sie auf der console raus. Damit ist das Problem generell erst mal geregelt.
Warum es mit Deiner page nicht geht: Du hast irgendwo im Wohnzimmer für das Licht einen Slider vergraben (und sonst noch wo zwei weitere).
Wenn Deine komplette page direkt zu Beginn geladen wird, sind diese Slider nicht an der Oberfläche und somit nicht initialisiert. Es werden aber initial alle 316 GADs, die Du hast, aktualisiert, also auch die drei Slider. Und die werfen eine exception, dass sie kein Setzten des Werts akzeptieren, solange sie nicht initialistert sind. Und die exception hat dann jquery aus der Bahn geworfen.
Durch das Abfangen der eceptions im Treiber ist also die Ursache nicht behoben, sondern nur die Auwirkung davon verhindert. Da solltest Du noch eine Lösung suchen.
Dein selectmenu und pager sind übrigens auch nicht sehr fehlertolerant. Da der Treiber im offline mode nur numerische Werte liefert, werfen die beiden auch eine exception (was im Echt-Betrieb bei Dir nicht so sein wird, da bei Dir von fronthem wohl etwas kommt, dass passt), weil sie das nicht verarbeiten können.
Der 1.09 Treiber ist nicht so richtig offiziell, ich wollte nur sehen, ob ich mit der Analyse richtig lag.
Wenn ihn aber noch jemand testen will, gerne, dann sehen wir, ob andere Konzeptänderungen, die ich drin habe, verträglich sind.
Allerdings sollte man im Ernstfall darauf gefasst sein, auf den 1.08er zurück zu müssen.
@HCS Diese blöden Fehlermeldungen sind mir zwar auch schon aufgefallen, aber da sie bisher keine schlechte Wirkung erzeugt haben, habe ich sie immer ignoriert. Ich bin mir aktuell nicht klar, was man dagegen tun sollte. Es gab im Netz Vorschläge, ein .selectmenu(). vor das refresh() zu schieben, damit das Objekt instatiiert wird, aber dann passen die Formatierungen nicht mehr...
Die Navigation geht jetzt zwar, aber die UZSU Dialoge poppen nicht mehr hoch, andere Poups laufen normal. Ne Idee, woran das liegen könnte?
Gesendet von meinem iPad mit Tapatalk
Seltsam. Die Leselampe in Deinem Wohnzimmer bring bei mir einen Dialog hoch. Zumindest in Crome auf dem Lapi.
kann ich bestätigen - chrome am Desktop ja und chrome am iPhone nein! Safari mobile ebenfalls nicht, so ein Mist!
Die Uzsu nutzt keine delegates, ist das ein Problem?
Der click handler hängt sich an das document. Kann das auch ein "nicht initialisiert"-problem sein?
Setzt doch mal auf die page, die initial erscheint ein uzsu drauf, ob es da geht. Oder einen alert direkt an den Anfang vom click event handler, ob Du da überhaupt rein kommst.
Wobei - Auf meinem Nexus 5 geht es auch, in Chrom und in Dolphin
Mache ich mal!
Wie gefällt Dir die Navigation?
Zitat von: bgewehr am 30 März 2015, 21:46:47Wie gefällt Dir die Navigation?
Hübsch und praktisch.
Aber das könnte noch problematisch werden. Du hast jetzt schon 300irgedwas GADs, die alle initial befüllt werden müssen und wenn ich die leeren Stellen anschaue, dann wird das wohl noch deutlich mehr. Ob das sich nicht zu einem Performance-Grab entwickelt?
Die "konventionelle" Navigation braucht halt mal hier 50 und mal da 50 aber nie mehrere hundert am Stück.
... Die konventionelle Navigation ist aber dennoch langsamer, stimmts?
Das direct call Gefüge ist doch aber so schnell das auch mehrere Hundert GAD flott gefüllt werden - dafür haben wir doch den Sport betrieben.
Spannend an Projekten (so wie hier) finde ich immer wieder das man doch auch nach Wochen, Monaten noch einzelne Problemstellen (slider un-initialisiert) oder performance Schübe findet. Die Bedeutung der investierten Zeit in aktiven Projekten (mature) ist nie zu unterschätzen - immer wieder interessant das auch so zu erleben.
vg
Jörg
So pauschal kann man das nicht sagen. Meine pages sind auf dem Nexus und den Tablets von den Zeiten OK. Seit das beim Laden responsiv ist, finde ich es eigentlich angenehm.
Kannst den Ansatzt ja mal weiterverfolgen.
Aber das iZeugs solltest Du wegwerfen - nur Probleme damit ;D
Zitat von: Joker am 30 März 2015, 20:41:572. Aktuell schaue ich mir öfter das Layout der bei smarVISU mitgelieferten Demo-Häuser an, schalte also die Pages auf ein anderes Verzeichnis. Dadurch habe ich dann in FHEM natürlich immer die ganzen GAD's, die meine Installation eigentlich gar nicht betreffen. Kann ich das irgendwie unterbinden? Und gibt es eine Möglichkeit, alle unbenutzten GAD's irgendwie zu entfernen, also anders als alle einzeln zu löschen? Sind leider ja recht viele :P
5. Weiterhin habe ich irgendwo gelesen, das Plots noch nicht gehen, stimmt das? In dem Screenshot-Thread sehe ich aber welche, sind das Entwicklungsversionen oder kann ich doch schon Plots nutzen? Habe mal den plots.rtr probiert, hat jedenfalls nicht funktioniert.
2. Ich habe eine weitere SV-Installation auf dem WebServer, die auf den offline Treiber eingestellt ist, mit der ich die Doku und die Beispiele anschaue.
Dann muss man nicht dran denken, vorher umzustellen und bekommt nicht versehentlich fronthem vollgepackt.
5. Wir arbeiten dran. Noch etwas Geduld bitte.
Zitat von: herrmannj am 30 März 2015, 22:12:28Spannend an Projekten (so wie hier) finde ich immer wieder das man doch auch nach Wochen, Monaten noch einzelne Problemstellen (slider un-initialisiert) oder performance Schübe findet.
Dieses Projekt hat auch noch die Eigenschaft, dass es hoch konfigurierbar ist und ungeschickterweise durch den Anwender ;D
Somit kommen Konstellationen zusammen, die man sich vorher kaum vorstellen konnte.
Aber wenn weiter alle zusammen so produktiv an den Problemen und Lösungen arbeiten, dann wird das rund.
Zitat von: herrmannj am 30 März 2015, 22:12:28Die Bedeutung der investierten Zeit in aktiven Projekten (mature) ist nie zu unterschätzen
Wie wahr. Und man hätte es wissen können, es war schon immer so ;)
#5 ausreichend Geduld bitte. (Sorry, workload und so.... Und ist sehr umfangreich. Also nicht morgen)
@vbs
Danke für den patch (@all, der liegt im clean-install git, ich weiß nicht ob den alle sehen können weil noch un-gemerged)
vbs schlägt eine Erweiterung zum einbinden vom user.js vor.
Funktion grob so:
in der config.ini liegt ein Eintrag "user_directory" , die "root" bekommt eine Erweiterung und in die user pages kommt eine php die dann auf ein *js im user_directory" verweist. (alle richtig?)
Im Prinzip kann man das doch jetzt auch alles indem man a: die *js über die pages oder base oder root direkt einbindet. Das erscheint mir geradliniger (einfacher).
Außerdem meine ich das so bestimmte usecase nicht abgedeckt werden. Für einige widgets (clock, weatcher) wird ja zusätzlich eine sep. js benötigt die via twig "once" (das ist ein macro) in der html eingebunden wird wo das widget herkommt.
Kurz, ich sehe den Vorteil und vermutlich auch den use case nicht. Was übersehe ich ? Das frisst jetzt kein Brot, macht es aber mMn auch weniger wartbar .. daher meine Frage.
vg
Jörg
@vbs: bitte nicht falsch verstehen, offene Frage!
Zitat von: HCS am 30 März 2015, 22:22:17
Wie wahr. Und man hätte es wissen können, es war schon immer so ;)
Ja, aber ich meinte das so: im Prinzip sind ja die vergangenen Wochen keine neuen Features dazu gekommen sondern alle Änderungen waren um das Ding robuster zu machen. Obwohl es von "außen" vmtl genauso aussieht wie vor 9 Wochen ist viel Arbeit reingeflossen die man nicht sieht sondern nur bemerkt (oder auch nicht) weil es rund und runder (he?) läuft
Zitat von: HCS am 30 März 2015, 21:44:51
UZSU:
Wobei - Auf meinem Nexus 5 geht es auch, in Chrom und in Dolphin
UZSU develop 2.94 behebt das Problem, warum auch immer!
Jetzt geht alles UND ist schnell - glücklich!
Zitat von: bgewehr am 30 März 2015, 22:43:55Jetzt geht alles UND ist schnell - glücklich!
Dann kann ich ja jetzt ins Bett. :)
Wenn noch zwei drei Leute den 1.09er ausprobieren und auch glücklich sind, dann mache ich ihn offiziell und packe ihn ins repo rein.
Thx an alle für die Antworten auf meine Fragen.
Zum Thema Plots:
Zitat5. Wir arbeiten dran. Noch etwas Geduld bitte.
Na klar, kein Thema. Wenn ich weiß dass es nicht geht, ist das OK. Ich bin eh noch lang genug beschäftig alles auszuprobieren was jetzt schon geht ;D
Zitat von: herrmannj am 30 März 2015, 22:33:08
@all, der liegt im clean-install git, ich weiß nicht ob den alle sehen können weil noch un-gemerged
Yep, ist zu sehen :)
Gruß
Hans
Hi Jörg,
also als erstes: kein Problem. Ich bin neu in dem Thema und ich lass mir gerne sagen, dass ich evtl. Mist gebaut habe und dass das alles viel einfacher geht. Kann ich gut mit leben.
Also ich kann man zu den Punkten sagen, was ich mir gedacht habe. Wenn ich falsch liege, lasse ich mich wie gesagt, gern korrigieren.
Zu dem HTML:
Also ich war der Meinung, man müsse den user_directory Pfad zu twig hinzufügen, um die Templates von dort laden zu können. Jetzt fällt mir noch ein, man könnte evtl. einfach aus dem Standard-SV-Widget-Pfad "ausbrechen" indem man dem Pfad ein ".." voranstellt. Also evtl.
{% import "../smartvisu-widgets/fritzbox/widget_fritzbox.html" as fritzbox %}Hab ich jetzt noch nicht probiert, aber die HTML-Templates sind ohnehin das geringste Problem IMHO. Oder wie würdest du das machen?
Zitat von: herrmannj am 30 März 2015, 22:33:08
Im Prinzip kann man das doch jetzt auch alles indem man a: die *js über die pages oder base oder root direkt einbindet. Das erscheint mir geradliniger (einfacher).
Ok, bei der Suche nach dem "once" habe ich gesehen, dass SV selbst auch einige JS-Files im body nachlädt. Ich hätte halt in meinem Verständnis gedacht, dass es Nebenwirkungen haben würde, wenn man die JS-File erst später im body nachlädt (anstatt direkt im head).
Aber last but not least:
Wie würdest du es machen, dass widgets ihre Icons aus einem anderen Ordner laden können? Die Widgets generieren ja einfach direkt img-Tags, die per icon0 bzw. icon1 aufgelöst werden. Hättest du dazu auch eine Idee?
@HCS
Ich habe ein bischen mit dem neuen Treiber gespielt. Unter FF mit eingeschalteten Casch und nach dem 1. Laden der Seite ist bei mir keine Verzögerung mehr zu bemerken.
Auf Android mit Chrom auch sehr flüsssig.
Auf Android mit Dolphin werden 2 meiner Widget nicht angezeigt. Einmal Timecounter und imgweather mit dem ich img austausche.
Das Problem mit dem imgweather war auch schon bei dem Treiber 1.08.
Insgesamt läuft es aber Top!
VG Lutz
@vbs
ne, ne. Das geht nicht um Mist oder so - ich sehe Sachen die dafür sprechen (die icons) aber eben auch die zusätzlich Konfiguration optionen die das ja normalerweise komplizierter machen. Aber ich kenne eben auch nicht jeden use case und will auch niicht im Weg stehen. Daher die Frage auch @all
Bei den komplexeren widgets mache ich das so
lib / <DIR> / *js und *css
widgets / <bla>.html
Im <bla>.html hab ich dann ein "once" mit dem *js damit bei mehrfachem widget Einsatz die js nur einmal geladen wird.
Btw, Du kannst auch base oder root zusätzlich in das page Verzeichnis legen und damit die defaults aus base überschreiben. Das benutze ich für spezielle mobil pages um cordova einzubinden ohne die pages anfassen zu müssen.
Wie gesagt, es mag jetzt andere use case geben.
vg
jörg
Zitat von: cruser1800 am 30 März 2015, 23:13:21Ich habe ein bischen mit dem neuen Treiber gespielt. Unter FF mit eingeschalteten Casch und nach dem 1. Laden der Seite ist bei mir keine Verzögerung mehr zu bemerken.
Auf Android mit Chrom auch sehr flüsssig.
Gut
Zitat von: cruser1800 am 30 März 2015, 23:13:21Auf Android mit Dolphin werden 2 meiner Widget nicht angezeigt. Einmal Timecounter und imgweather mit dem ich img austausche.
Das Problem mit dem imgweather war auch schon bei dem Treiber 1.08.
Schlecht
Geht das mit dem Domotiga Treiber auch nicht?
Zum Timecounter widget sind mir zwei Dinge aufgefallen:
1. Die function ZeitAnzeigen wäre in der widget_timecounter.js besser aufgehoben, als im html
2. Warum nicht gleich im notify auf hh:mm:ss umrechnen und in SV mit einem ordinären basic.value anzeigen?
@HCS
Ging beides mit dem 1.06!
Hallo,
bisher habe ich immer ohne Pagecache gearbeitet. Jetzt habe ich ihn aber mal in der Configuration aktiviert. Wenn ich jetzt meine Smartvisu-Seite aufrufe bekomme ich folgende Fehlermeldung:
Error accoured in twig-template engine!
error: Unable to find template "reed_contacts.html" (looked into: /var/www/smartvisu/apps, /var/www/smartvisu/pages/home, /var/www/smartvisu/pages/base, /var/www/smartvisu/widgets).
file: root.html
line: 93
Gruß, Sascha
@Cybers: Mach mal das temp Verzeichnis in Deiner SV-Installation leer.
Zitat von: cruser1800 am 31 März 2015, 13:21:01Ging beides mit dem 1.06!
Na dann schaue ich mal ...
@HCS: Danke, jetzt läuft es.
Gruß, Sascha
Zitat von: Cybers am 31 März 2015, 15:13:43@HCS: Danke, jetzt läuft es.
@all: würde sich jemand erbarmen und ein widget schreiben, mit dem man den page cache ein/ausschalten kann und das dabei automatisch das temp-Verzeichnis leert?
oder einen config page Ersatz im cleaninstall bauen, der das macht?
Das ist echt lästig. Und wenn man es vergisst, dann steigt die Verwirrung bis zum Anschlag.
Du: was hältst Du von dieser Idee:
ich hab doch in fronthem den filter für GAD internal.*. Was hältst Du davon die dafür zu nehmen. Ich bau was in fronthem ein (internal.cache-delete = 1) und der driver löscht den cache (via ajax call auf eine *.php). Bei dieser Gelegenheit könnte man evtl auch die Zeitmessung rückwärts via internal GAD an fronthem schicken, dort anzeigen und loggen. Evtl vielleicht sogar einieg js Fehlermeldungen via internal an fronthem zurückschicken. Dann hätten wir auch das Thema iphone hat keine console weg.
vg
jörg
Zitat von: herrmannj am 30 März 2015, 23:37:00
ne, ne. Das geht nicht um Mist oder so - ich sehe Sachen die dafür sprechen (die icons) aber eben auch die zusätzlich Konfiguration optionen die das ja normalerweise komplizierter machen. Aber ich kenne eben auch nicht jeden use case und will auch niicht im Weg stehen. Daher die Frage auch @all
Also meine Idee bzw. mein persönlicher use-case ist, dass man das smartvisu-wigets-Repo (bzw. auch andere Widget-Sammlungen) direkt 1:1 einbinden, nutzen und updaten kann. Out-Of-The-Box sozusagen. Also so dass man keine Dateien händisch irgendwo hinkopieren oder anpassen muss (abgesehen von pages natürlich). Evtl. habt ihr diesen use-case ja gar nicht bzw. ich bin der einzige, der das Feature haben möchte. Kann ja sein. Ich fände das einfach sehr elegant und vor allem modular.
Ich will nicht bestreiten, dass ich in der Sache bestimmt etwas parteiisch bin, da ich halt ein paar Stunden in den Patch gesteckt habe. Trotzdem versuche ich das objektiv zu beurteilen und wenn es eine schon bestehende Lösung (die nicht zu "hackish" ist) bzw. andere, bessere Lösung für diesen use-case gibt, dann bin ich gegen meinen Patch ;)
Zitat von: herrmannj am 30 März 2015, 23:37:00
Bei den komplexeren widgets mache ich das so
lib / <DIR> / *js und *css
widgets / <bla>.html
Im <bla>.html hab ich dann ein "once" mit dem *js damit bei mehrfachem widget Einsatz die js nur einmal geladen wird.
Ok, aber das setzt ja voraus, dass ich die Widgets händisch in das "<SV>/widgets"-Verzeichnis kopiere, oder? Und wenn es später mal Updates für die Widgets gibt, muss ich mich händisch darum kümmern, die upzudaten. Das gleiche für js und css-Dateien. Das wäre eigentlich genau das, was ich gerne vermeiden würde, ehrlich gesagt.
Zitat von: herrmannj am 30 März 2015, 23:37:00
Btw, Du kannst auch base oder root zusätzlich in das page Verzeichnis legen und damit die defaults aus base überschreiben. Das benutze ich für spezielle mobil pages um cordova einzubinden ohne die pages anfassen zu müssen.
Das würde ich ungern machen, da ich dabei ja einen Teil von SmartVISU "forke" sozusagen. Muss gestehen, dass ich bei solchen Sachen aber auch recht pedantisch bin... :/
Mit dem Wissen bzgl. dem "once" bzw. dass man auch ruhig js-Dateien im body-Bereich einbinden kann, würde ich jedoch gerne zumindest den js-Teil meines Patches nochmal überarbeiten. Natürlich nur, wenn der Mechanismus generell überhaupt Zustimmung findet.
Hi,
ja verstehe, das ist immer doof wenn man Arbeit reinsteckt, und dann denkt man sich ja auch was bei - logisch.
Bevor Du noch tiefer eintauchst, geh mal von von der widget js wo die buttons und so drin liegen weg und schau Dir mal die komplexeren 'a la clock oder weather an.
Die bestehen aus 3 Teilen die ohnehin individuell eingebunden werden müssen, html, js und css. (Muss man ja bei mit patch auch)
Jetzt geh mal gedanklich noch weiter und nimm an das Du unterschiedliche pages (mit komplett unterschiedlichen widgets) zum Beispiel für desktop, tablet und phone erstellst. Nicht unwahrscheinlich (habe ich zB) das Du dann zB für das phone ein anderes Weather widget nimmst als für das tablet. Geh noch weiter und nimm die cordova Unterstützung: gleiche Seiten, manchmal soll das geladen werden oder auch nicht. Das passiert ja alles auf Ebene der page dirs (eben nicht zentral)
Da meine ich eigentlich das die Unterstützung die schon eingebaut schon richtig fetten (sic) support für bietet. Zum Beispiel durch die base im page-dir. Der Sinn ist ja genau das Du das nicht "forken" musst. Entweder die Vererbungshierarchie (root->base-> ...) nutzen *oder* pro page-dir eine eigene Vererbung. Die ist nämlich dann auch updatesicher - anders als das was der patch bewirken würde.
Btw, selbst die icons dirs kannst Du so (fast) out-of-the-box relisieren. Das "icon1~" ist ja am Ende des Tages nur eine twig Variable für das icon-dir (im Quelltext macht twig ein replace).
Ich weiß Deine Arbeit sehr wohl zu schätzen, ich glaube aber das Du da in die falsche Richtung läufst, möglicherweise die "Macht" von der twig engine und der Vererbungs struktur in den pages noch unterschätzt.
Ich meine, wenn ich Deinen case richtig verstehe, das sv das (und mehr) schon out-of-the box kann. Ich bitte daher mein Zögern zu entschuldigen :) ...
Ma schauen, gibt es weitere Meinungen ?
vg
jörg
edtih und Nachtrag um da ganz transparent zu sein:
Ich, so wie ich sv einsetze, hätte keine Verwendung für die Funktionen die der patch bereitstellt und würde den patch dann als zusätzliche Fehlerquelle ohne Zuwachs an Nutzen nicht einchecken wollen. Sprich, ich sehe / erkenne den Nutzen nicht.
Wenn es jetzt aber mehrere user gibt die sagen "brauch ich / will ich" (es also nicht um einen Einzelpatch von & für vbs geht ;) ) dann check ich den natürlich (flott!) ein.
vg
jörg
Wir müssen berücksichtigen, dass SV von anderen Autoren weiterentwickelt wird. Je mehr wir ändern, desto mehr müssen wir nachpflegen und desto mehr Fehler müssen wir bei einem Update von SV reparieren. Von mir ein Nein aus vorgenannten Gründen. Ich lege die custom files mit in die original Verzeichnisse, dann kann ich aus einem GIT clone Verzeichnis neue Versionen über meine Installation kopieren ohne dass ich sonst was ändern muss. Mir reicht das (meistens, manchmal wünsche ich mir auch eine stärkere Automation dieser Dinge - aber nur ganz selten!)
@herrmanj:
Also das ist sicherlich die nettes Abfuhr, die ich je für einen Patch bekommen habe ;) Aber mal ernsthaft: Wenn ihr das nicht haben wollt (und das sehe ich jetzt mal als Fakt an), ist das natürlich voll ok. Ich finds auch richtig, dass man als Projekt-Leader (so seh ich dich jetzt erstmal), keine Sachen rein nimmt, die entgegen dem eigenen Konzept laufen (halte ich sogar für deine Pflicht, um "deinen Laden sauber zu halten"). Außerdem hab ich da "nur" ein paar Stunden dran gesessen und nicht Tage oder Woche und zweitens hab ich dabei sehr viel über SmartVISU/twig gelernt, was auch sowieso mit die Motivation war. Und wenn ich dieses Feature weiterhin haben will, steht es mir natürlich eh frei euer FHEM-SmartVISU zu forken und da meinen Patch einzubauen.
Aber nochmal kurz zur Sache: Ich weiß, wir haben jetzt schon hin- und her diskutiert, aber sorry, ich verstehe eine grundsätzliche Sache noch nicht ganz: Bist du der Meinung, dass man das Feature, dass man Widget-Repos direkt ohne Änderungen einbinden und benutzen kann nicht braucht? Oder sagst du, dass das doch jetzt eh schon mit Bordmitteln möglich ist?
@bgewehr
Die Argumentation unterschreibe ich auch sofort. Meiner bescheidenen Meinung nach, ist dieser FHEM-SmartVISU-Fork-Status ja auch nicht unbedingt ideal. Ich hatte ja auch deshalb schon einmal vorgeschlagen, dass man versuchen sollte, die nicht-fhem-spezifischen Änderungen in dem FHEM-SmartVISU möglichst bald nach Upstream zu bekommen (so wie ich gerade versuche, meinen Patch bei euch rein zu bekommen). Das ist erstes technisch mMn gut und wichtig, damit der Fork möglichst nahe am Original bleibt (im Idealfall würde man FHEM mit dem original SmartVISU benutzen können und müsste nur einen FHEM-Treiber hinzufügen, oder?). Zweitens ist es auch nur fair dem Original-Projekt ggü., da man natürlich von deren Vorarbeit enorm profitiert (wobei man da auch argumentieren könnte, dass es denen ja ihrerseits frei steht, sich beliebig bei FHEM-SmartVISU zu bedienen).
Hallo wie koennen reading werte als text ausgeben werden kann jemand mal beschreiben wie das geht. Werte vom buderus km 200 kommen rein und sollen an smartvisu als text uebergeben und ausgewertet werden. Hat jemand ne idee
Sollte hiermit funktionieren:
http://www.smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.value
@vbs
ja, soll eben auch genau keine "Abfuhr" sein. Ist ein Stück weit eine Gratwanderung: viele machen mit und das Projekt lebt davon das sich alle ein Stück weit wiederfinden. Aber deshalb ist es auch ein Ruderboot auf dem jeder ein klein wenig an einen anderen Strand will und das ist für ein Boot in Summe auch nicht gut.
Zu Teil 2,
- widgets (repo) einbinden: ja, nützlich !
- geht mit dem patch nicht einfacher als out-of-the box.
imho besser:
ein updater wie er in fhem vorhanden ist:
einbinden der widgets wie gehabt (individuelle page).
der updater (php?) aktualisiert die widget - files (mit backup, overwrite vielleicht einzelne ausschließen?) anhand einer repo liste die man hinterlegt. Vielleicht sogar rollback oder so ?
vg
jörg
Hi
ich habe auch nochmal ne Frage: Auf fhemweb greife ich öfter via VPN "von außen" zu, z.B. um Einstellungen zu machen oder Status anzuschauen. Jetzt würde ich gerne auch von außen auf smartVISU zugreifen wollen. Ein Test heute hat ergeben, dass das irgendwie nicht geht. Ich bekommen dann zwar meine Seiten angezeigt, aber die ganzen Werte fehlen- also so, wie wenn man mit einem Device zugreift, das nicht als fronthemDevice definiert ist.
Da dachte ich mir dann, ist ja klar, vermutlich habe ich von außen eine andere IP-Adresse, und habe ein fronthemDevice mit eben dieser erstellt. Leider geht es aber trotzdem nicht. Und ein Blick ins Logfile hat auch keinerlei Fehlermeldungen von fehlenden Rechten gezeigt, wie das sonst kommt wenn man mit einem "nicht autorisierten" Device zugreift.
Eine Idee, was hier das Problem ist?
Hi,
die richtigen Schritte, auch zur Diagnose. Wenn es dann nicht geht liegts am vpn, der braucht den 2121 offen. Von Routern kenne ich es das sie mit dem ws niicht können (vmtl irgendeine Form von shaping). Der vpn an einer fb7390 funktioniert in der beschriebenen Konstellation...
vg
jörg
Zitat von: cruser1800 am 30 März 2015, 23:13:21Auf Android mit Dolphin werden 2 meiner Widget nicht angezeigt. Einmal Timecounter und imgweather mit dem ich img austausche.
Den timecounter habe ich auf meine Testseite gebaut. Ging heute Mittag nicht. Heute Abend ging er.
Ob das an dem Android 5.1 Update liegt, das ich gerade bekommen habe? Da kam bestimmt ein neues WebKit mit und da basieren die doch alle drauf, oder?
Zitat von: herrmannj am 31 März 2015, 17:49:06
Du: was hältst Du von dieser Idee:
ich hab doch in fronthem den filter für GAD internal.*. Was hältst Du davon die dafür zu nehmen. Ich bau was in fronthem ein (internal.cache-delete = 1) und der driver löscht den cache (via ajax call auf eine *.php). Bei dieser Gelegenheit könnte man evtl auch die Zeitmessung rückwärts via internal GAD an fronthem schicken, dort anzeigen und loggen. Evtl vielleicht sogar einieg js Fehlermeldungen via internal an fronthem zurückschicken. Dann hätten wir auch das Thema iphone hat keine console weg.
Ich schaue mir das mal an und mache einen Vorschlag, was ich schicken würde, so in der Art wie bei monitor oder eher wie bei angefragten serien.
Was würde fronthem dann damit machen? Irgendwo wegschreiben und einen Viewer dafür anbieten?
vg
jörg
Logs aus dem Treiber nach fronthem schicken ist eine gute Idee. Ich könnte console.log abfangen und alles was da kommt zu fronthem schicken, dann könnte man das dort nachlesen.
Temp-Verzeichnis löschen. Da sehe ich nicht, warum das über fronthem laufen sollte. Ich schalte in SV den cache ab und will das temp verzeichnis automatisch leer haben. Das ist doch etwas, das rein SV intern ablaufen kann / soll.
Zum Thema "widgets einbinden":Ich erkenne in der bisherigen Diskussion verschiedene use-cases. Meiner ist: ich habe eigene widgets, die ich nicht veröffentliche, weil sie eh keinem helfen, die habe ich im page Verzeichnis. Es gibt widgets von SV, die sind eh da und sollten nicht verändert werden. Und dann gibt es noch die widgets der fronthem comunity im git. Die, die ich davon verwende, habe ich momentan auch im page Verzeichnis und sie mit der Nachlade-Methode in der visu.js eingebunden (siehe x posts weiter oben).
An SV sollten wir so wenig wie möglich ändern (meine page läuft aktuell mit dem original 2.7 SV download, da ich keine Mandanten benötige), sonst basteln wir uns bei einer kommenden 2.8 einen ab, bis das wieder geht. Sinnvoll wäre, Dinge wie Mandanten usw. in SV reinzubringen. Ich kann mir nicht vorstellen, dass ein SV Benutzer, egal ob er KNX, Domotiga oder FHEM verwendet, es cool findet, was passiert, wenn man den cahce nach dem Entwickeln wieder einschaltet und dann das Chaos hat.
Dann könnte man auch versuchen, dort eine Lösung für zusätzliche widgets und Bilder einzubringen.
Ein klein wenig forken bringt es nicht, wenn wir uns für forken entscheiden würden, dann könnten wir auch richtig loslegen. Ich würde aber eher den anderen Weg gehen.
Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.
Zitat von: herrmannj am 31 März 2015, 22:36:14
die richtigen Schritte, auch zur Diagnose. Wenn es dann nicht geht liegts am vpn, der braucht den 2121 offen. Von Routern kenne ich es das sie mit dem ws niicht können (vmtl irgendeine Form von shaping). Der vpn an einer fb7390 funktioniert in der beschriebenen Konstellation...
Sorry, kann Dir grad nicht folgen... welche Schritte? Wie, wenn es "dann" nicht geht?
Meine Fritzbox ist übrigens eine 7390.
Zitat von: HCS am 31 März 2015, 23:24:48
Logs aus dem Treiber nach fronthem schicken ist eine gute Idee. Ich könnte console.log abfangen und alles was da kommt zu fronthem schicken, dann könnte man das dort nachlesen.
ok, dann baue ich das ein. Zeitmessung auch ?
Zitat
Temp-Verzeichnis löschen. Da sehe ich nicht, warum das über fronthem laufen sollte. Ich schalte in SV den cache ab und will das temp verzeichnis automatisch leer haben. Das ist doch etwas, das rein SV intern ablaufen kann / soll.
das "via fronthem" ist ein wenig davon getrieben das ich die Einstellungen (bei mir) eigentlich komplett raus nehme. Wozu auch, die Tab sollen an der Wand hängen und laufen, da muss man ja nicht ständig was umstellen - im Gegenteil: stört mich eher. Deine Argumentation ist aber absolut schlüssig, da bin ich dann gefragt weil es das config system betrifft. Wenn der cache abgeschaltet wird einmal ein "rm -R *" ausführen. Baue ich ein.
Zitat
Zum Thema "widgets einbinden":
Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.
Ja genau. Nimm dei uzsu. Der js muss in die visu.js kopiert werden. So richtig automatisch wird schwer - zumal das beim nächsten widget dann wieder anders ist...
vg
jörg
Zitat von: herrmannj am 01 April 2015, 08:22:35
ok, dann baue ich das ein. Zeitmessung auch ?
Halt halt. Lass uns erst klären, was wo wie.
Ich bereite es im Treiber gerade vor.
Wahlweise könnte ich so etwas (analog zu monitor, series) liefern:
{
"cmd": "info",
"type": "console.log",
"data": "[io.fhem]: run (readyState=0)"
}type könnte sein: "console.log" / "exception" / "timing")
oder so etwas:
{
"cmd": "info",
"severity": "info",
"data": "[io.fhem]: run (readyState=0)"
}severity könnte sein: "info" / "warning" / "error"
Was findest Du besser?
Würde fronthem das dann irgendwo in ein logfile wegschreiben und einen Viewer für das log anbieten, oder wie ist Dein Plan?
Nachtrag: evtl. sollten wir das Protokoll zwischen fronthem und dem Treiber noch erweitern. Da es im "Normalbetrieb" keinen Sinn macht, ständig log-Infos an fronthem zu schicken, sollte man es irgendwo konfigurieren können. Nach Deiner Devise "das Tablet an der Wand rühre ich nicht an" wäre das dann eine Einstellung (attribut enableLogging)im fronthemdevice.
fronthem könnte direkt nachdem die ws connection aufgebaut wurde und bei Änderung der Einstellungen (da kommen bestimmt noch weitere) so etwas an den Treiber schicken, dass er weiß, wass er tun soll:
{
"cmd": "settings",
"data": [
{
"setting": "enableLogging",
"value": "true"
},
{
"setting": "measureTimes",
"value": "true"
}
]
}
Hi,
naja, Idee wäre den bestehenden GAD mechanismus dafür zu nehmen und auf alle GAD die mit "internal." (meinetwgen system.* whatever) anfangen als reserved zu betrachten.
Dann zb internal.log.info (.warning, .error ... ) die Meldungen drauf und ich zieh die im fronthem device aus der message Verarbeitung. Danach kann ich die ins log schreiben (abhängig von verbose). Extra anzeigen (so als reading oder so) würde ich eher nicht - die Meldungen sind ja flüchtig. Evtl könnte ich noch events draus machen, dann würde man die im eventmonitor sehhen können, finde ich aber inkonsistent zu der Art wiie das sonst in fhem läuft, system-log würde ich als den richtigen Platz sehen.
Möglich wäre auch das fronthem auf einem GAD (internal.verbose) das fhem verbose an den driver schickt - dann brauchen nur msg losgetreten werden die im loglevel höher sind. (soart traffic sc-> fhem)
Da könnte ich mir auch gut vorstellen das die GAD Zeiten mit gesendet werden um das immer wieder mal fühlbare Mess-Problem zu lösen. Könnte man vielleicht so lösen das der driver eine Durchschnitt führt und 50ms (100??? whatever) nach dem das letzte GAD gekommen ist wird das per "internal.performance.gad" an fhem geschickt - entweder log oder Anzeige.
Das mit den internal GAD hat auch noch einen zweiten Bereich: ich hab einen POC gebaut wo sv via native App auf mobil device geladen wird und Sonderfunktionen wie geo-location, tts, battery, display Helligkeit auch ohne explizit einegerichtete GAD transportiert werden müssen. Da würde die App (zukunft) selber ein GAD erzeugen (internal.app.battery) und zB den Batterieladezustand an fronthem melden.
Im Prinzip isses Wurscht, wir können auch weitere cmds (cmd setting) einführen, bräuchten wir aber mMn nicht wenn wir internal.* dafür deklarieren. Das hätte mMn auch den Vorteil das man die bei Bedarf auch besser in sv integrieren könnte. Beispiel: log Anzeige als widget. Muss man nicht - könnte man dann aber.
vg
jörg
Ich würde das lieber von einander trennen (GADs für Daten und sonstige Kommunikation zwischen fronthem und Treiber). Sonst kämpft man mit GADs, die man irgendwo wegfiltern muss, weil man sie da nicht berücksichtigen darf usw.
Wenn wir es trennen, dann besteht weniger Gefahr, dass es Seiteneffekte gibt.
Es würde auch generel so nicht funktionieren, monitor frägt ja nur mit den Namen der GADs an, gibt aber keine Werte dazu.
Um Werte an fronthem zu schicken, benötigen wir ein Format.
Hier die Beispiele zu Deinen Punkten. Diese Struktur wäre auch aufwärtskompatibel erweiterbar.
{
"cmd": "info",
"type": "battery",
"data": "80%"
}
{
"cmd": "info",
"type": "console.log",
"data": "[io.fhem]: run (readyState=0)"
}
{
"cmd": "info",
"type": "exception",
"data": "nu isses futsch in visu.js Zeile 12 einhalb"
}
{
"cmd": "info",
"type": "performance",
"data": "Average GAD Update time: 12.4ms"
}
Die Gegenrichtung (fronthem -> Treiber) entsprechend erweitert:
{
"cmd": "settings",
"data": [
{
"setting": "enableLogging",
"value": "true"
},
{
"setting": "measureTimes",
"value": "true"
}
{
"setting": "display",
"value": "15%"
}
{
"setting": "tts",
"value": "Guten Morgen Jörg"
}
]
}
na, da versuche ich Dich noch zu überzeugen :)
bisher haben wir ja auch GADs die ungefragt geliefert werden - und die keine Probleme machen. Überschneidungen (unschärfe :) ) habe wir zum Beispiel bei solchen Konstellation:
display Helligkeit, wäre schöön die via fhem programatisch anpassen zu können -> intern. ABER: wäre ja auch nett zwei Tasten dafür auf der Oberfläche zu haben -> normales GAD verhalten.
Lautsärke: dito, Wecker gesteuert über fhem wird langsam lauter (oder Abends sleep, you name it) - Tasten auf der Oberfläche: würden da gut passen.
Im Augenblick filtern wir doch auch ohne Nebenwirkungen ... ich hätte da jetzt keine Bedenken und argumentiere dass das besser skaliert einen namespace in dual use zu nehmen. Wer weiß was später noch dazu kommt. So würde man einen fiilter auf internal.* legen (haben wir ja schon) schauen ob die Funktion implementiert ist - sonst einfach an sv weiterreichen und sv verwirft die sowieso wenn unbekannt.
Das würde zukünftig auch ermöglichen einfach ein plugin auf fronthem zu legen um zB hardware spezifische Funktionen abzubilden ohne das Protokoll dafür anfassen zu müssen. Auf der frontend Seite könnte ich die Funtionen (zB screen) in der App abbilden ohne den driver dazu anfassen zu müssen oder, schlimmer noch, unterschiedliche driver brauche abhängig davon ob sv in einem container läuft der brightness unterstützt oder nicht.
vg
jörg
Zitat von: herrmannj am 01 April 2015, 13:33:25schlimmer noch, unterschiedliche driver brauche abhängig davon ob sv in einem container läuft der brightness unterstützt oder nicht.
Warum unterschiedliche driver? Der io_fhem wird es können, spielt doch keine Rolle, ob es dann in einem Container verwendet wird oder nicht.
Zitat von: herrmannj am 01 April 2015, 13:33:25bisher haben wir ja auch GADs die ungefragt geliefert werden - und die keine Probleme machen.
Der Treiber frägt momentan eine Liste von GADs an, für die er Daten benötigt. Aber nur die Namen. Bisher gibt es nichts, das Werte von GADs an fronthem liefern würde oder könnte.
Kannst Du mal für ein konkretes Beispiel so wie ich oben die Kommunikation zw. fronthem und Treiber aufschreiben, mit konkreten JSONs, die hin und her gehen, vielleich verstehe ich dann, wie Du Dir das vorstellst.
Zitat von: HCS am 01 April 2015, 14:51:38
Warum unterschiedliche driver? Der io_fhem wird es können, spielt doch keine Rolle, ob es dann in einem Container verwendet wird oder nicht.
Ja, hier ist der springende Punkt. Die Funktion "verstelle mal die lautstärke" wird vom container bereitgestellt. Im Falle von cordova lautet das " media.setVolume". Jetzt müsste der driver diese Funktion also selber unterstützen (aufrufen) und wenn es nicht cordova ist oder andere Funktionen bereitgestellt werden dann das auch - anders ..
Woher soll der driver jetzt aber wissen ob der host (container) das unterstützt, wenn ja welche Variante, abgestuft auf platformen (IOS, Android etc.)
Wenn es aber als GAD normal "durchgereicht" wird kann ich in dem container ein widget "faken". So isses jetzt ja auch - der driver weiß nichts um die Funktion des widgets. Der kennt den Namen und wenn was reinkommt gibt er das dort ab, aus die Maus. :)
Will sagen: der driver muss sich im Zweifel dann nicht damit beschäftigen was das GAD kann, bewirkt etc - er reicht das transparent durch. Lediglich im Fall der logs und evtl der zeitmessung muss er selber intelligenz erbringen. Wobei er das nicht müsste, ein Stück javascript in der root (was nach aussen als widget mit "update" auftritt, aber eben keinerlei gui hat) könnte das ja genauso erledigen. Das meine ich auch mit skalierbarkeit - alles was sich wie ein widget verhält kann beliebige Funktionen übernehmen. Die Konvention naming "internal.*" stellt nur sicher das man keine eigenen GAD definiert - weil auf der anderen Seite fronthem lauscht und wenn was mit dem namen "internal.log.info" reinkommt wird aus dem normalen flow rausgekommen und in das log geschrieben.
Besser verständlich ?
Zitat von: herrmannj am 01 April 2015, 17:01:43
Besser verständlich ?
Nö. Kannst Du nicht einfach mal ein Beispiel aufschreiben, was der Treiber tun sollte, wenn er z.B. einen console.log loswerden will, oder wenn er eine exception gefangen hat und sie an fronthem loswerden will, oder wenn er Ergebnisse für eine Zeitmessung hat, die er loswerden will.
Und, woher er weiß, dass er logs, Zeitmessung usw. schicken soll.
Zitat von: herrmannj am 31 März 2015, 21:19:20
Zu Teil 2,
- widgets (repo) einbinden: ja, nützlich !
- geht mit dem patch nicht einfacher als out-of-the box.
Hm ok. Sorry, ich muss gestehen, dass ich jetzt etwas auf dem Schlauch stehe. Um es einfach zu halten: Könntest du mal kurz sagen, wie ich ein Widget-HTML-Template einbinden könnte, wenn es in einem
Unterverzeichnis von SV liegt (zB "smartVISU/smartvisu-widgets/homematic/homematic.html")? Ich habe deine bisherigen Beispiele so verstanden, dass es da um Widgets im pages- bzw. widgets-Ordner ging. Vielleicht kenne ich da einfach irgendwelche twig-Kniffe nicht und bin daher in der falschen Richtung unterwegs.
Zitat von: HCS
Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.
Könntest du sagen, was dich an dem Patch konkret stört? Bzw. könntest du sagen, was deine Anforderungen an so einen Mechanismus wären, die noch nicht erfüllt sind bzw. nicht hinreichend erfüllt sind? Vielleicht kann ich da noch etwas nachbessern.
Falls ihr gerade andere Sachen im Kopf habt, dann könnte ich mich auch in einen separaten Thread zu dem Thema verkrümeln oder wir verschieben die Diskussion...
Zitat von: vbs am 01 April 2015, 17:18:02Könntest du sagen, was dich an dem Patch konkret stört? Bzw. könntest du sagen, was deine Anforderungen an so einen Mechanismus wären, die noch nicht erfüllt sind bzw. nicht hinreichend erfüllt sind? Vielleicht kann ich da noch etwas nachbessern.
Die Änderung an SV. Ich hatte es ja für sinnvoll gehalten, Erweiterungen, die allegemein und nicht nur für uns hier Sinn machen, bei den SV-Leuten reinzubringen.
Ich habe irgendwie etwas Bedenken, ob wir in Salami-Taktik dann doch irgendwie ein spezielles Spezial-SV basteln und beim nächsten SV-Update Probleme bekommen.
Was mir nicht gefällt ist die erforderliche Unterscheidung von user-Bildern und SV-Bildern. Ich fände etwas wie einen Suchpfad, erst user, dann SV eigentlich schöner, da man dann bei der Definition auf den pages das nicht bestimmen muss.
Die erforderlichen css-Schnipsel, die verschieden Widgets benötigen, wäre auch noch ein offener Punkt.
Ich habe mich aber auch nicht extrem detailliert mit Deinem Patch auseinandergesetzt sondern wollte eher meine allgemeinen Gedanken zu dem Thema wiedergeben.
So richtig dagegen bin ich nicht, eher unschlüssig :)
Zitat von: HCS am 01 April 2015, 17:15:41
Nö. Kannst Du nicht einfach mal ein Beispiel aufschreiben, was der Treiber tun sollte, wenn er z.B. einen console.log loswerden will, oder wenn er eine exception gefangen hat und sie an fronthem loswerden will, oder wenn er Ergebnisse für eine Zeitmessung hat, die er loswerden will.
Und, woher er weiß, dass er logs, Zeitmessung usw. schicken soll.
Ja, mach ich
Zitat von: herrmannj am 01 April 2015, 17:57:39
Ja, mach ich
Aktennotiz an mich: nicht immer die Klappe auf reisen!
Offizielles Protokoll:
damit das auch so funktioniert wie ich gesagt habe (uneingeschränkt skaliert) braucht es "körperlose" widgets. Ich hatte das um einige Stunden Arbeit unterschätzt ;) habe jetzt aber ein Erfolg versprechendes Konzept gefunden. Ich teste da morgen noch weiter, sieht aber gut aus soweit.
vg
jörg
Zitat von: herrmannj am 01 April 2015, 23:58:19damit das auch so funktioniert wie ich gesagt habe (uneingeschränkt skaliert) braucht es "körperlose" widgets. Ich hatte das um einige Stunden Arbeit unterschätzt ;) habe jetzt aber ein Erfolg versprechendes Konzept gefunden. Ich teste da morgen noch weiter, sieht aber gut aus soweit.
Es sind ja zwei use cases:
1. Lautstärke, Helligkeit, Sprachausgabe usw.
2. Logging, Exceptions, Zeitmessung.
Zumindest 2. würde ich nicht in einem Widget abhandeln. Ich glaube nicht, dass ich irgendwo in der Page ein widget vergraben haben möchte, das exceptions global wegfängt. Loggen kann es auch nur, wenn es irgendwie erst mal zum Leben erweckt wurde. Alles, was bis da hin nicht klappt, kann nur der Treiber berichten. Infos, z.B. wie viele GADs gefunden wurden, was bei fronthem angefragt wird usw. weiß auch nur der Treiber. Und die Zeitmessung kann auch nur der Treiber machen.
Oder anders formuliert: der Treiber weiß, was er macht und was im System vor sich geht. Ein widget hat keine Ahnung, was der Treiber macht oder nicht machen konnte.
Der Treiber ist der Chef im (widget update)-System, der darf die Überwachung auf Fehlverhalten nicht seinen Untergebenen überlassen. :)
Was mir auf fronthem-Seite gut gefallen würde:
Ein Attribut im fronthem device, in dem man festlegen kann, ob und wie dieses device berichten soll (Nichts, log, Zeitmessung usw.).
Für jedes fronthem device wird ein logfile geschrieben, mit dem Namen des device, in dem alles, was von
diesem device als log gesendet wird, einfach Zeile für Zeile reinläuft.
Einen "Log anzeigen" button beim fronthem device, um das log anzusehen
Zitat von: HCS am 02 April 2015, 03:53:29
Der Treiber ist der Chef im (widget update)-System, der darf die Überwachung auf Fehlverhalten nicht seinen Untergebenen überlassen. :)
Absolut check!
Der Punkt ist das beide, driver oder page-widget, es *könnten*. Log und time gehören, Du sagst es, systematisch in den driver. Kein Zweifel!
Zitat
Ein Attribut im fronthem device, in dem man festlegen kann, ob und wie dieses device berichten soll (Nichts, log, Zeitmessung usw.).
Absolut! passt!
Zitat
Für jedes fronthem device wird ein logfile geschrieben, mit dem Namen des device, in dem alles, was von diesem device als log gesendet wird, einfach Zeile für Zeile reinläuft.
hmm, ... im Augenblick laufen alle Systemmeldungen (error, debug) im Systemlog auf. Die devicelogs sind ja (fhem-style) eher für Messwerte zuständig. Ist aber nur eine nachgelagerte Formalie - beides geht.
vg
Jörg
Zitat von: herrmannj am 02 April 2015, 08:04:34im Augenblick laufen alle Systemmeldungen (error, debug) im Systemlog auf. Die devicelogs sind ja (fhem-style) eher für Messwerte zuständig. Ist aber nur eine nachgelagerte Formalie - beides geht.
Der use-case, den ich da im Kopf hatte:Anwender: "hilfe, bei meinem neuen iPhone8XXXL" zeigt der basic.value als Wert immer nur Apfelmuß an!"
Supporter: "Setze mal beim fronthem-device 'iPhone' das Attribut 'logging' auf 'all', navigiere etwas auf Deiner Page rum und klicke danach beim fronthem-device auf 'Log anzeigen' und den Inhalt schickst Du mir mal, dann schaue ich, was da passiert.
Wenn das im FHEM log zerstückelt evtl. noch von mehreren devices gemixt und vergraben ist, macht das keinen Spaß.
war mir klar, bricht aber eben mit fhem Konventionen.
Schaun mer mal, ist ja erst step 3 ...
vg
jörg
Ja, wobei ein vernünfiges Hilfsmittel zur Analyse von Problemen einges erleichtern würde.
Die Variante, dass ich mir die page von bgewehr (ist keine Kritik oder Reklamation, alles gut) installiere, um das Problem zu suchen, kann nicht der default sein.
So was können wir im Anfangsstadium mal machen, um zu sehen, was in verschiedenen Szenarien denn passiert, aber natürlich nicht auf Dauer und bei jeden Problemchen.
"step 3" verstehe ich so, dass Du mit Prio die charts auf der agenda hast und das hier erst danach konkret wird?
"step 3:"
#1 Strategie entwickeln, testen, POC (heute, morgen und so)
#2 in den driver und in fronthem einbauen, testen, tunen (kommende Woche)
#3 Ausgabe zur Analyse (kommende Woche + x)
Ich hab für #3 was im Hinterkopf. Thema: um schlagkärftig zu sein wäre es doch schön ein Gebinde aus SmartVISU log, fronthemDevice Meldungen und fronthem zu bekommen. Das könnte ich vmtl ins fronthemDevice komfortabel integrieren.
Plots ist ein anderes Projekt.
vg
jör
Zitat von: HCS am 01 April 2015, 17:37:32
Die Änderung an SV. Ich hatte es ja für sinnvoll gehalten, Erweiterungen, die allegemein und nicht nur für uns hier Sinn machen, bei den SV-Leuten reinzubringen.
Ich habe irgendwie etwas Bedenken, ob wir in Salami-Taktik dann doch irgendwie ein spezielles Spezial-SV basteln und beim nächsten SV-Update Probleme bekommen.
Was mir nicht gefällt ist die erforderliche Unterscheidung von user-Bildern und SV-Bildern. Ich fände etwas wie einen Suchpfad, erst user, dann SV eigentlich schöner, da man dann bei der Definition auf den pages das nicht bestimmen muss.
Die erforderlichen css-Schnipsel, die verschieden Widgets benötigen, wäre auch noch ein offener Punkt.
Das sind (leider) ziemlich genau die Stellen, die ich auch als unschön empfinde.
Wie man es dreht und wendet: Man kommt mMn nicht umhin, mindestens Kleinigkeiten an SV und auch an den Widgets zu ändern. Ich hätte nochmal einen Vorschlag für einen etwas anderen Ansatz, der weniger Änderungen an SV nötig macht, aber dafür die Widgets mehr in die Verantwortung nimmt:
-man legt ein paar neue twig-Funktionen an. Das würde bedeuten, dass man in SV nur ein weiteres PHP-File includen müsste und mit "$twig->addFunction" die gewünschten Funktionen laden müsste. Das halte ich zumindest für überschaubar und pflegeleicht.
Man würde zB folgende twig-Funktionen anlegen:
"addWidgetRepo" - fügt ein Verzeichnis-Pfad mit User-Widgets hinzu (zB addWidgetRepo("smartvisu-widgets"))
"importEx" - analog zu "import", sucht jedoch das Template auch in den User-Repos
"iconEx" - generiert einen Icon-Pfad. Sucht das Icon auch in den User-Repos.
"fileEx" - generiert Datei-Pfad. Sucht das File auch in den User-Repos (z.B. für CSS-Dateien)
Also der User würde "importEx" anstatt "import" benutzen, um die Widget-Templates zu laden. Die Widgets selber wiederum müssten zum Einbinden von Icons "iconEx" und zum Einbinden von CSS-Files "fileEx" benutzen. Der Haken ist mMn, dass dadurch die User-Widgets etwas speziell werden und nicht ohne die twig-Erweiterungen funktionieren. Auch hier denke ich jedoch, dass man es leider nicht hin bekommt, ohne Änderungen an Widgets vorzunehmen.
Was würdet ihr von dem Ansatz halten?
ich willl da jetzt echt keine Spaßbremse sein - für mich persönlich stellen sich die Fragen so nicht.
Der Endzustand soll fpr mich sein das es läuft, ganz vorne Plots, die Tabletts sind an die Wand geschraubt die Handys eingerichtet, SSL Zugang. Fire and forget ...
Wenn da jetzt wirklich neue widgets auftauchen dann (die für mich dann spannend sind) dann muss ich die sowieso erst einmal evaluieren, verstehn, auch lernen mit den Grenzen umzugehen. Das macht so ein zwei Abende, ja nach komplexität. Das dann davon vielleicht 1:30min darauf entfallen das ich das händlich reinkopieren muss spielt für mich da keine grosse Rolle.
Zumal ja die widgets auch alle unterschiedlich aufbegaubt sind. Bei dem einen muss man den css in die visu.css kopieren (js genauso) bei anderen sind es komplette Dateinen die eingebunden werden müssen. Vielleicht passe ich dann js und css an - ich bin mir nicht sicher ob ich das einer Autlomatik übertragen würde - auch nicht ob die das überhaupt könnte ?
Aber nochmal: ein bischen Demokratie ;) haben wir schon hier
vg
jörg
Zitat von: herrmannj am 02 April 2015, 09:52:22
#2 in den driver und in fronthem einbauen, testen, tunen (kommende Woche)
Du gehst aber nicht an den Treiber ran, oder?, sonst haben wir einen Konflikt und müssten mergen.
Zitat von: herrmannj am 02 April 2015, 11:37:38Aber nochmal: ein bischen Demokratie ;) haben wir schon hier
Oh. Welches Unterschriftenquorum haben wir hier für ein Volksbegehren? ;D ;D ;D
@herrmannj: Du könntest ein Umfrage starten, wie viele User eine Notwendigkeit sehen, in die Richtung etwas zu verbessern (ernst, kein Scherz).
Das wäre dann gelebte Demokatie, momentan beschränkt es sich auf drei Meinungen.
Wenn nicht im größeren Stil ein Wunch nach so etwas besteht, kann zumindest ich auch gut mit dem aktuellen Stand leben.
Aktuell glaube ich, dass charts ganz oben auf der Wunschliste stehen.
ZitatDu gehst aber nicht an den Treiber ran, oder?, sonst haben wir einen Konflikt und müssten mergen.
Doch geht an den driver ran. (dont panic). Wenn das System so funktioniert wie ich plane siehst Du aber die Funktion sofort so genau das Du das mit wenigen Zeilen einbauen kannst. Bereite ich auch gern vor, muss es ja eh testen. Wenn (!) es so passt fügt sich das soooo geschmeidig ein das es flutscht ... alles easy
vg
jörg
OK, ich arbeite nämlich gerade an Deinem Herzenswunsch, dass die originalen SV plot.* widgets auch verwendbar werden, und nicht nur meine neuen chart widgets.
Zitat von: herrmannj am 02 April 2015, 12:55:00Wenn (!) es so passt fügt sich das soooo geschmeidig ein das es flutscht ... alles easy
Gut, hast meine Panik runtergeregelt. Wollte nur sicher sein, dass wir nichts fabrizieren, das nicht mehr zusammengeht.
Wenn Du höchstpersönlich am Treiber was machen willst / musst, dann gib Bescheid, ansonsten gehe ich generell davon aus, dass ich die Code-Hoheit habe.
Deine Erweiterung geschmeidig reinflutschen lassen ist kein Thema.
Zitatansonsten gehe ich generell davon aus, dass ich die Code-Hoheit habe.
So isses. Ich schlage Dir den code (nur grob) vor und hoffe das Du den gut findest.
vg
jörg
Zitat von: herrmannj am 02 April 2015, 11:37:38
Wenn da jetzt wirklich neue widgets auftauchen dann (die für mich dann spannend sind) dann muss ich die sowieso erst einmal evaluieren, verstehn, auch lernen mit den Grenzen umzugehen. Das macht so ein zwei Abende, ja nach komplexität. Das dann davon vielleicht 1:30min darauf entfallen das ich das händlich reinkopieren muss spielt für mich da keine grosse Rolle.
Mir geht es da weniger um den Zeitaufwand, sondern mehr um die Wartbarkeit. Nicht böse gemeint, aber ich finde so ein Vorgehen unsauber. Wenn ich Code aus verschiedenen externen Quellen für mich zusammen kopieren und ablegen muss, dann hab ich erstens Code dupliziert und ich weiß zum Beispiel vier Wochen später nicht mehr, welche Codeschnipsel ich mal aus welcher Quelle und welchem Stand kopiert habe und wo ich welche Änderungen eingebaut habe. Geschweige denn, dass ich bei den Widgets dann Updates händisch im Quellcode einpflegen muss.
Zitat von: herrmannj am 02 April 2015, 11:37:38
Zumal ja die widgets auch alle unterschiedlich aufbegaubt sind. Bei dem einen muss man den css in die visu.css kopieren (js genauso) bei anderen sind es komplette Dateinen die eingebunden werden müssen. Vielleicht passe ich dann js und css an - ich bin mir nicht sicher ob ich das einer Autlomatik übertragen würde - auch nicht ob die das überhaupt könnte ?
Die Widgets im smartvisu-widgets-Repo sollten mMn einmalig, händisch so angepasst werden, dass sie im Kontext des "einbindbaren" Repos funktionieren. So dass genau nicht die Nutzer html/js/css-Dateien anpassen müssen, sondern out-of-the-box nutzen können.
Ist natürlich völlig ok, wenn du ein solches Feature nicht benötigst. Hatte dich eigentlich gestern so verstanden, dass du das Feature generell sinnvoll findest. Kann ich irgendwas tun, um euch zwei (?) bei einer Entscheidungsfindung zu unterstützen? :) Würde mich weiterhin dann gerne anbieten, eine technisch gute Lösung dafür zu finden, falls ihr das haben wollt.
ZitatHatte dich eigentlich gestern so verstanden, dass du das Feature generell sinnvoll findest.
Ich befürchte da hast Du recht :) mir sind halt beim später-nochmal-drüber nachdenken Zweifel gekommen das man das ohne Nebenwirkungen umsetzen kann.
Denk mal an die widgets fürdie man code in die visu.js einsetzt oder css einfügt. Dann sollten updates später trotzdem zusätzlich eigene Anpassungen oder Änderungen , zb an der css, nicht überschrieben. Da habe ich offen gestanden einfach wegen evtl Nebenwirkungen Angst. Dazu kommt das Kalkül das Entwicklung, debuggen und warten von einer Autmoatik viel mehr Aufwand verursacht als das aktuelle von Hand einfügen.
Aber nochmal, ich will da auch nicht im Weg stehen.
vg
jörg
Ich glaube das Problem ist anders gelagert. Man kann vermutlich mit vertretbarem Aufwand eine solche Integrationslösung erstellen und damit das Spiel der Updates vereinfachen. Ich fürchte aber, dass dadurch implizit den Repository-Verantwortlichen die Aufgabe abverlangt wird, für alle Widgets für Update Kompatibilität zu sorgen, damit nicht jedesmal nach einem Update die Hälfte nicht mehr funktioniert... Also ich möchte diesen Job nicht haben, daher bleibe ich lieber bei der "jeder fummelt für sich" Denke...
Ihr erinnert euch? Ich habe mal eine dynamische Ladefunktionalität für die JSs der widgets gepostet. Aus diesem Grund hat bgewehr die ganzen JSs der widgets passend genannt. Und mit seiner Variante kann man sich die widgets irgendwo hin kippen und muss sie nur noch in die visu.js namentlich eintragen. Beim Update der widgets einfach aus dem Repo drüber kopieren und gut ist.
Verbleibt das css. Das muss man in seiner visu.css zusammenführen, aber da ist der Gedanke von Jörg nicht so falsch, dass man es evtl. dann eh anpassen will. Da müsste man mal schauen, was das so ist, ob man nicht im html defaults machen kann, so dass man das css nur braucht, wenn man anders formatieren will. Damit hätte man evtl. nur noch wenig mit den css zu tun.
@vbs: hast Du Dir diese Variante mal angeschaut oder ist die an Dir vorübergegangen?
@HCS:
Nee, sorry, ist an mir vorbei gegangen und ich konnte es auch gerade per Suche nicht finden. Klingt aber durchaus interessant. Hättest du evtl. einen Link für mich?
@bgewehr:
Also ich denke, dass der User ab und an etwas an seinen pages etwas anpassen muss, wenn sich Widgets ändern. Aber das ist mMn unabhängig von der Art wie die Widgets geupdatet werden. Der Vorteil wäre, dass der User nicht auch auf Widget-Seite anpassen muss, sondern eben nur auf seiner pages-Seite. Also ich denke einfach nicht, dass irgendwer garantiert bzw. erwartet, dass Widgets immer geupdatet werden können und 1:1 so aussehen/funktionieren wie zuvor.
Zum Thema Debug habe ich bei FF eine richtig gute Lösung gefunden WebIDE!
Mit installierten FF auf Android kann man genauso debugen wie am Desktop! Soll mit Chrome auch gehen. Muss ich aber noch suchen!
VG Lutz
Edit: Inklusive Zeitmessung! Und jetzt sehe ich, dass die Uhr und das Wetter ständig Abfragen macht! Ich werde es mal raus schmeißen!
Zitat von: vbs am 02 April 2015, 17:55:41
Nee, sorry, ist an mir vorbei gegangen und ich konnte es auch gerade per Suche nicht finden. Klingt aber durchaus interessant. Hättest du evtl. einen Link für mich?
http://forum.fhem.de/index.php/topic,30909.msg276209/topicseen.html#msg276209
http://forum.fhem.de/index.php/topic,30909.msg276232/topicseen.html#msg276232
Zitat von: cruser1800 am 02 April 2015, 19:01:07
Zum Thema Debug habe ich bei FF eine richtig gute Lösung gefunden WebIDE!
Das ist aber mal praktisch. Mit Chrome wäre cool, aber mit FF ist auch OK.
"
... weil es nachteilige Effekte für das Erlebnis der Endbenutzer hat"Ich muss jedes mal wieder grinsen. ;D ;D ;D
Zitat von: HCS am 02 April 2015, 20:39:31
Das ist aber mal praktisch. Mit Chrome wäre cool, aber mit FF ist auch OK.
Hier die Lösung für Chrome
https://developer.chrome.com/devtools/docs/remote-debugging (https://developer.chrome.com/devtools/docs/remote-debugging)
VG Lutz
Edit: Hab mal ein bisschen gespielt! Für mich als Laie ist FF intuitiver! ;)
Hallo
kann jemand mal genau beschreiben wie man die ics Datei für einen kalender local mit ical einbindet.
in der config steht ical:
adresse file:/var/www/smartvisu/test.ics
bei mir kommt nichts. was ist falsch ich nutze das widget_ical.hmtl und die datei icalcreator ist auch da. HELP
Zitat von: cruser1800 am 02 April 2015, 21:31:57
Hier die Lösung für Chrome
Gerade ausprobiert. Das funktioniert perfekt.
Vielen Dank für's Suchen.
Frage zum Updaten.
Wenn ich diesen Befehl eingebe:
update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
bekomme ich IMMER folgende Ausgabe. Also auch, wenn ich es mehrmals hintereinander mache mit Restart dazwischen etc. Es ändert sich lediglich der Name von dem restoreDir.
RMDIR: ./restoreDir/2015-03-29
UPD FHEM/01_fronthem.pm
UPD FHEM/31_fronthemDevice.pm
UPD FHEM/fhwebsocket.pm
UPD FHEM/fhconverter.pm
UPD www/pgm2/fronthemEditor.js
UPD www/images/default/arrow-down.svg
UPD www/images/default/arrow-up.svg
UPD www/images/default/desktop.svg
New entries in the CHANGED file:
2015-01-18
- minor typo: thx fhainz
update finished, "shutdown restart" is needed to activate the changes.
Please consider using the global attribute sendStatistics
Da sollte sich doch eigentlich was ändern, bzw. dann auch direkt nach einem Update gar nichts mehr stehen oder?
Zweite Sache, könnt ihr mir bitte noch einen Tipp geben zu dem Problem was ich neulich gepostet habe zwecks VPN Zugriff. Was soll ich da jetzt machen um dem Problem auf die Spur zu kommen (bekomme nur Webseiten mit leeren Werten).
Zitat von: Joker am 03 April 2015, 10:30:04
Zweite Sache, könnt ihr mir bitte noch einen Tipp geben zu dem Problem was ich neulich gepostet habe zwecks VPN Zugriff. Was soll ich da jetzt machen um dem Problem auf die Spur zu kommen (bekomme nur Webseiten mit leeren Werten).
Du musst sicherstellen, dass Dein VPN Tunnel sowohl Zugriff auf Port 8083 (fhemweb) als auch Port 2121 (fronthem) zulässt. Dann im fronthem nachsehen welche IP "rejected" wurde (lastError). Für diese IP ein fronthemdevice anlegen und "whitelist=false" setzen. Das ggf. für alle IP Adreesen wiederholen, die per DHCP an Dein VPN Client vergeben werden können oder statische IPs verwenden.
Zu Deiner Updatefrage: das Verhalten ist normal, da update _force_ ...
/Uli
@Joker:
Du musst in deinem Befehl das 'force' durch zB 'all' ersetzen.
http://fhem.de/commandref_DE.html#update (http://fhem.de/commandref_DE.html#update)
Zitat von: HCS am 02 April 2015, 20:26:16
http://forum.fhem.de/index.php/topic,30909.msg276209/topicseen.html#msg276209
http://forum.fhem.de/index.php/topic,30909.msg276232/topicseen.html#msg276232
Achso das, doch das hab ich gesehen und auch mit rum gespielt. Ist auf jeden Fall eine nette Sache, aber hilft wohl nur für einen Teil der Probleme leider :/
Also das Laden von HTML-Templates aus eigenen Verzeichnissen wird wohl nicht ohne zumindest einen kleinen Eingriff in SV zu machen sein und das Laden der Icons aus eigenen Verzeichnissen nicht ohne Eingriff in die Widgets. Also wenn man da nichts verändern will, dann wird man da nichts machen können, fürchte ich.
Danke, das mit dem update ist irgendwie logisch ;D
Zitat von: dev0 am 03 April 2015, 10:49:45
Du musst sicherstellen, dass Dein VPN Tunnel sowohl Zugriff auf Port 8083 (fhemweb) als auch Port 2121 (fronthem) zulässt. Dann im fronthem nachsehen welche IP "rejected" wurde (lastError). Für diese IP ein fronthemdevice anlegen und "whitelist=false" setzen. Das ggf. für alle IP Adreesen wiederholen, die per DHCP an Dein VPN Client vergeben werden können oder statische IPs verwenden.
Im Prinzip habe ich das so gemacht, also ich habe ein Device und die whitelist ist auch gesetzt. Ich vermute jetzt dass die IP nicht stimmt. Allerdings finde ich nichts, dass fronthem eine IP rejected hat. Wo sollte ich diesen lastError finden?
Zitat von: Joker am 03 April 2015, 11:59:49
Allerdings finde ich nichts, dass fronthem eine IP rejected hat. Wo sollte ich diesen lastError finden?
Ist ein Reading in fronthem (Server), nicht im fronthemDevice (Client).
Muss man eigentlich zwingend wirklich für jedes Gerät ein Device in FHEM anlegen oder kann man irgendwie ein Catch-All-*.*-Device anlegen, das für alle IPs gilt, die man nicht explizit angelegt hat?
ZitatIst ein Reading in fronthem (Server), nicht im fronthemDevice (Client).
Also sollte es hier zu finden sein?
(http://www.bernd-schubart.de/downloads/fronthem.png)
Bei mir gibt es da nur ein "ws" Reading...
Zitat von: Joker am 03 April 2015, 12:15:46
Bei mir gibt es da nur ein "ws" Reading...
Dann hast Du vielleicht die Datei fhem.save gelöscht oder FHEM nicht sauber beendet, so dass fhem.save nicht zurückgeschrieben wurde. Das Reading erscheint auch nicht, wenn Du erneut versuchst über den VPN Tunnel zuzugreifen?
Zitat von: vbs am 03 April 2015, 12:14:00
Muss man eigentlich zwingend wirklich für jedes Gerät ein Device in FHEM anlegen oder kann man irgendwie ein Catch-All-*.*-Device anlegen, das für alle IPs gilt, die man nicht explizit angelegt hat?
Leider ist es im Moment so. Ich musste für 3 DHCP Pools kanpp 100 fronthemdevices anlegen and mit "verbose 0" versehen, da sonst das FhemLog zugemüllt wurde. Wäre wirklich toll, wenn es später mal die Möglichkeit gäbe Subnetze ala 172.16.x.x/22 zu definieren.
Kann keiner sagen und beschrieben wie man den kalender local einbinden kann?
Gruß
bumbumb
Hallo bumbumb,
ich habe hier http://forum.fhem.de/index.php/topic,35831.0.html (http://forum.fhem.de/index.php/topic,35831.0.html) noch einmal alles zusammen gefasst.
Lass uns das da weiter diskutieren, wenn du noch fragen hast. Der Thread hier ist dafür nicht der richtige Ort.
Gruß Norbert
@bumbum: Du bist evtl. im falschen Forum, ganz sicher aber im falschen Thread. Vielleicht kann dir deshalb niemand helfen. An deiner Stelle würde ich den smartVisu Thread suchen und dort dein Problem in allen Details beschreiben (Art des Kalenders, dein Code etc.). Dazu gehört auch das aufzuschreiben, was du schon versucht hast. Deine Fragen sind nicht gerade sehr Gehaltvoll.
Zitat von: dev0 am 03 April 2015, 12:39:38
Leider ist es im Moment so. Ich musste für 3 DHCP Pools kanpp 100 fronthemdevices anlegen and mit "verbose 0" versehen, da sonst das FhemLog zugemüllt wurde. Wäre wirklich toll, wenn es später mal die Möglichkeit gäbe Subnetze ala 172.16.x.x/22 zu definieren.
Wir wärs denn, wenn man ein Attribut einführen würde, das zumindest die R/W-Rechteprüfung deaktiviert, wenn gesetzt? Würde das Testen ziemlich erleichtern und ggf. und später den Betrieb.
Zitat von: vbs am 03 April 2015, 16:12:07
Wir wärs denn, wenn man ein Attribut einführen würde, das zumindest die R/W-Rechteprüfung deaktiviert, wenn gesetzt? Würde das Testen ziemlich erleichtern und ggf. und später den Betrieb.
gibt es doch_ "whitelist". vg jörg
Zitat von: dev0 am 03 April 2015, 12:24:02
Dann hast Du vielleicht die Datei fhem.save gelöscht oder FHEM nicht sauber beendet, so dass fhem.save nicht zurückgeschrieben wurde.
Hm, also manuell gelöscht habe ich nichts. Nicht sauber beendet wüßte ich auch nicht, wenn dann mache ich ein shutdown restart...
ZitatDas Reading erscheint auch nicht, wenn Du erneut versuchst über den VPN Tunnel zuzugreifen?
Nein, leider nicht. Es erscheint auch nichts im Log dass irgendwas keine Rechte hat...
Noch Ideen?
Zitat von: herrmannj am 03 April 2015, 16:26:39
gibt es doch_ "whitelist". vg jörg
Argh, ok danke 8)
Aber ist es Absicht, dass whitelist defaultmäßig auf true steht und ich es auf false setzen muss, damit das Gerät alles darf? Hätte ich jetzt eigentlich andersherum erwartet.
Zitat von: Joker am 03 April 2015, 16:32:53
Hm, also manuell gelöscht habe ich nichts. Nicht sauber beendet wüßte ich auch nicht, wenn dann mache ich ein shutdown restart...
Schau mal in die smartvisu Konfiguration ob Teiber, Port and Adresse korrekt eingestellt sind (vom VPN Gerät aus aufrufen).
Zitat von: dev0 am 03 April 2015, 19:00:00
Schau mal in die smartvisu Konfiguration ob Teiber, Port and Adresse korrekt eingestellt sind (vom VPN Gerät aus aufrufen).
Oh mann, was für ein blöder Fehler von mir :P
Tatsächlich war es diese Banalität. Hatte das natürlich schon mal richtig eingestellt wie bei den anderen Geräten auch, aber dann wohl irgendwann mal verstellt und nicht mehr hingeschaut :P
Danke für die Hilfe! Jetzt gehts auch via VPN.
Ok Jungs, neues Spiel, neues Glück ;D
Ich würde gerne einen neuen Parameter 'bin' für den Converter NumDisplay vorschlagen. Wenn angegeben, dann wird nicht der Wert 1:1 durchgereicht, sonder vorher binarisiert. Werte kleiner gleich 0 werden auf 0 gemappt, alles größer 0 wird 1.
Hintergrund ist der, dass man damit Readings, die einen numerischen Wertebereich haben, auf die beiden Werte 0 bzw. 1 reduzieren kann. Zum Beispiel nützlich wenn man das Widget basic.symbol mit der Ventilposition eines Heizungsventils nutzen will. Also das Symbol soll nur angezeigt werden, wenn Ventilposition größer 0 ist.
Das ist der Commit: https://github.com/verybadsoldier/fronthem/commit/a7560c9d7abc50c6dd4054defe513e2b08e8d20f
EDIT:
Achso, kann ja sein, dass das gar nicht nötig ist und ihr einen einfacheren Weg kennt. Viele Sachen in SmartVISU bzw. dem FHEM-Treiber kenne ich vermutlich noch gar nicht...
Ich finde die Idee gut, würde aber einen separaten "bool" Converter vorziehen. Bleibt einfacher dann und muss nicht erklärt werden. Evtl kann man als Parameter die Wertebereiche für 0 und 1 angeben...
Ehrlich gesagt, würde ich ich solche Dinge in FHEM mit einem userReading lösen, dass dann ganz normal über die schon vorhandenen Converter in SmartVisu verwendet werden kann.
Zitat von: bgewehr am 04 April 2015, 10:02:06
Ich finde die Idee gut, würde aber einen separaten "bool" Converter vorziehen. Bleibt einfacher dann und muss nicht erklärt werden. Evtl kann man als Parameter die Wertebereiche für 0 und 1 angeben...
Ok, inhaltlich hätte es auch zu NumDisplay gepasst, aber stimmt schon, der "BoolConverter" ist viel sprechender. Ich hab das jetzt mal umgebaut auf einen Converter "BoolDisplay". Der mappt jetzt Zahlen auf 0 und 1 (erster Parameter ist der Schwellwert, default ist 0). Falls der Input keine Zahl ist, dann wird "off" auf 0 gemappt, ansonsten 1. Hab den PR angepasst.
@marvin78:
Also ich hatte da auch drüber nachgedacht, aber ich würde das lieber einmalig zentral im Converter lösen anstatt an mehreren Stellen in FHEM userreadings anlegen zu müssen. Passt mMn auch zur bisherigen Marschrichtung: OnOffConverter z.B. ist vom Vorgehen ja sehr ähnlich.
Bin dafür, richtige Vorgehensweise, finde ich!
Zitat von: vbs am 04 April 2015, 11:33:00Also ich hatte da auch drüber nachgedacht, aber ich würde das lieber einmalig zentral im Converter lösen anstatt an mehreren Stellen in FHEM userreadings anlegen zu müssen. Passt mMn auch zur bisherigen Marschrichtung: OnOffConverter z.B. ist vom Vorgehen ja sehr ähnlich.
Das entspricht meiner generellen Ansicht.
Wenn man ein Anzeigeproblem im frontend hat, dann sollte man es auch da lösen, und nicht im backend. Das entspricht dann auch den Zuständigkeiten der Komponenten.
Ob ein Konverter oder ein passendes Widget dann der richtige Weg ist, kann man diskutieren. Eher ein Widget, kann ja sein, dass ich den Wert selbst irgend wo anzeigen will und ein "Ventil zu" Icon.
Mit dem Widget wäre es wohl wirklich richtig. Es liegt eine Information einmal vor, und wie die in verschiedenen Varianten visualisiert wird, ist alleinge Zuständigkeit vom Frontend.
Ich will aber niemanden mit Architektur gängeln, das darf natürlich jeder machen, wie er es gerne möchte.
Ich sehe es aber nicht als Anzeigeproblem im Frontend. Es ist ja nicht wirklich ein Bool-Wert, um den es hier geht, sondern ein Fake-Bool. Aufbereitung der Daten gehört aber meiner Ansicht nach ins Backend. Jedoch soll es mir wirklich egal sein.
Zwei Sachen, die mir an fronthemEditor.js aufgefallen sind:
Bei AJAX-Anfragen, die an FHEM gesendet werden, werden die Daten vor dem Absenden nicht URL-kodiert. Aufgefallen ist es mir in Funktion sveGADEditorSave. Da werden alle Daten in einen String kopiert. Sollten aber mMn URL-kodiert werden. Ich vermute, dass das aber auch bei allen anderen Sendefunktion der Fall sein wird.
Zum Beispiel hier:
var dataString ='dev.' + device + '=' + device + '&cmd.' + device + '=get&arg.' + device + '=webif-data&val.' + device + '=' + JSON.stringify(transfer) + '&XHR=1';
Zum anderen werden bei von FHEM empfange Daten die Gänsefüßchen beim Zusammenbau der HTML-Seite nicht escapet. Zum Beispiel hier:
$('#gadeditor').append('<tr><td>' + 'converter' + '</td><td align="right"><input id="gadEditConverter" type="text" size="55" value="' + gad.converter +'"/></td></tr>');
Wenn nun "gad.converter" seinerseits ein Gänsefüßchen enthält, dann wird dadurch das HTML-Attribut nicht richtig geschlossen.
EDIT:
Aufgefallen ist übrigens das erste Problem als ich mal ein +-Zeichen als Converter-Parameter übergeben wollte und beim zweiten Problem war es ein Gänsefüßchen. Kann damit auch reproduziert werden.
EDIT2:
Beim zweiten Problem geht es ja gar nicht nur um Gänsefüßchen, sondern wahrscheinlich ja darum, dass alle Daten HTML-enkodiert werden sollten.
jepp, Danke. Bin da sowieso plot technisch unterwegs - ich schau da mal rein. Das hat imho nicht so sehr mit dem Transprt zu tun sondern mit dem insert, bzw mit dem javascript.
vg
jörg
Ich möchte nochmal das Thema "die originalen plot widgets von SV" aufmachen.
Wir sollten ernsthaft nachdenken, ob wir sie wirklich benutzen können müssen.
Zur Unterscheidung: meine nennen sich chart, die originalen von SV nennen sich plot.
Nachdem ich nun Tage mit den plot widgets gekämpft habe und versucht habe, mit diesen
das Update der Serien hinzubekommen, bin ich noch mehr der Ansicht, dass wir sie nicht verwenden sollten.
Die Routinen dafür werden immer abgefahrener.
Hier die Punkte, warum ich die plot.* widgets direkt vom Start weg nicht nehmen würde:
gilt für plot.period und plot.rtr:
- GAD/Parameter parserei ("hcs.data.OilLevelPlot.avg.5y 6m.0" also konkret das ".avg.5y 6m.0")
- Die Aktualisierung mit neuen Daten ist fast unmöglich. fronthem müsste bei plots, die mehrere Serien
haben, alle Serien von einem Plot gleichzeitig und in der richtigen Reihenfolge liefern und für jede
Serie die passenden neuen Werte. Anders bekommt es das original widget nicht hin.
- Es kann kein Intervall festgelegt werden, in dem das Chart aktualisiert werden soll
- SV kann an ein initialisiertes plot nur Plotpunkte hinten anhängen, Szenerien, bei denen
die Serie ersetzt werden muss, sind nicht möglich
- Ein plot mit mehreren Serien erscheint erst dann, wenn alle Serien Daten geliefert haben
- Solange ein Plot keine Serie bekommen hat, ist er komplett unsichtbar
- Es gibt keinerlei Konfigurationsmöglichkeiten. Viele der coolen Highchart-Features wie z.B. Export des Chart nach png oder pdf, Titel, Tooltips deaktivieren, Zoom-Varianten und vieles mehr lässt sich nicht steuern
- Man sollte die Klasse vom chart div als Parameter im widget setzen können, dass man unterschiedliche Höhen usw. haben kann.
- Der plot.rtr ist ein völlig starres Ding, da kann man noch nicht mal die Farben usw. konfigurieren. Im Prinzip ist er aber ein plot.period, nur dass da noch der Ventil-Stellung-PacMan mit drauf sitzt. Somit würde ich erwarten, dass man den für die Soll- und Istkurve so konfigurieren kann, wie den plot.period
- Ich bin mir absolut sicher, dass man sich bei den plots mehr wünschen wird, als aktuell in SV geht, und dann entstehen so oder so neue widgets, mit dem Nachteil, dass man sich dann mit zwei Sorten, die auch noch vom Treiber unterschiedlich angesteuert werden müssen, rumschlagen muss.
- comfortchart und temprose kann ich in meinen Varianten auch deutlich einfacher ansteuern
- Die restlichen Details lasse ich weg, sonst wird die Liste unendlich lang.
Eine generelle Unterstützung der plot widgets kann man durch einige weitere irre Routinen im Treiber noch hinbekommen, vieles aber ohne Änderung an den Widgets nicht.
Ich hätte in Kürze (aktuell fehlt nur noch der chart.rtr) einen kompletten Ersatz für die vier plot.* widgets:
chart.period, chart.rtr, chart.temprose und chart.comfortchart
bei denen diese Punkte alle erledigt sind.
Im Treiber könnte ich sicherstellen, dass die originalen plot.* widgets nicht verwendet werden und falls einer auf der page sitzt, so einen SV-Dreieck-Error einblenden, dass man die chart-widgets verwenden soll.
Die Parameter der chart.* widgets sind identisch zu den von plot.* nur der period ist unterschiedlich, aber auch den könnte ich Parameter-kompatibel machen, obwohl meine Reihenfolge schöner wäre.
Meine Empfehlung: wir unterstützen die plot.* nicht.
zu plot.* in Bezug auf driver und Alternative widgets bist Du viel tiefer im Thema, ich kann das aktuell nicht beurteilen. Wenn jedoch eine kompatible bessere Variante existiert wüsste ich nicht was dagegen spricht das so zu machen wie Du sagst.
vg
jörg
OK, ich baue den chart.period noch um, dass die Parameter sich mit dem plot.period decken, hinten raus sind die weiteren dann eh optional, so dass man sich, wenn man die zusätzlichen Features nicht nutzt, 1:1 an der SV-Doku orientieren kann.
gehs vielleicht noch etwas ruhiger an. Erfahrungsgemäß ergeben sich ja doch noch neue insights wenn wir näher rankommmen ...
Plots in sv gehen langesam voran - noch ist aber nicht zum vorzeigen. vg jörg
Hier noch ein Vorschlag für einen neuen Converter: UserCode-Converter. Analog zu vielen Stellen in FHEM, kann man damit eigenen Perl-Code angeben, der die Hin- und die Rückkonvertierung durchführt. Der erste Parameter konvertiert FHEM->SV, der zweite SV->FHEM. Wird der zweite Parameter weg gelassen, dann handelt sich um einen read-only-Converter.
Beispieldefinition:
UserCode {sprintf("%.1f", $VALUE / 1000.0)}, {$VALUE * 1000}
PS.
Der Converter funktioniert leider nur, wenn die Bugs aus http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089 (http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089) gefixt sind.
PR:
https://github.com/herrmannj/fronthem/pull/8
Den finde ich praktisch. Der erspart evtl. dann auch unzählige weitere Converter.
Damit lässt sich doch dann auch das "bin" beim NumDisplay erledigen, bzw. der BoolConverter, oder?
Zitat von: vbs am 05 April 2015, 10:49:55
Beispieldefinition:
UserCode {sprintf("%.1f", $VALUE / 1000.0)}, {$VALUE * 1000}
PS.
Der Converter funktioniert leider nur, wenn die Bugs aus http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089 (http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089) gefixt sind.
PR:
https://github.com/herrmannj/fronthem/pull/8
Das ist kein bug - das ist ein feature :) Ich kann mir das leider iA nicht im Detail ansehen (morgen erst)
Ich übernehme den gerne die converter - die Idee ist sehr gut. Folgende Bitte dazu: schau Dir (Ihr, wie auch immer) das Ding bitte nochmal sehr genau auf folgenden Aspekt hin an:
Kann ich via $value über sv (bzw den websocket) code einschleusen der dann im eval mit fhem rechten ausgeführt wird ?
Ich meine damit das Äquivalent zu sql injections. Das müsste bitte unbedingt vermieden werden. Wenn das unmöglich ist würde ich den Bernds Vorschlag folgend in der 99 er sehen. Hintergrund: in der Standard Installation möchte ich keine Einfallstore haben, was der user dann hinterher damit macht liegt in persönlicher Verantwortung jedes Einzelnen.
vg
jörg
Hallo HCS!
Mir ist noch Problem mit dem icon.battery widget in Verbindung mit dem fhem-Treiber v1.08 aufgefallen. Den js Code von icon.battery hab ich mit dem aus dem widget git ersetzt. Da gabs anscheindend im original Code einen Bug?
Das widget zeigt zwar den Wert mit den Füllungs-Balken an geht aber nicht mehr in den "on state", sprich es wird nicht mehr grün. Hab das bei mir wie folgt defieniert und funktioniert bei v1.02 problemlos.
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}
mbaLadedose ist mit dem OnOff Converter verknüpft,
mba.akkuIcon liefert einen Wert zwischen 1-255 und ist mit NumDirekt verknüpft.
Konsole liefert keine ausergewöhnliche Meldungen.
Hast du dazu eine Idee?
Grüße
Zitat von: fhainz am 05 April 2015, 12:45:45Mir ist noch Problem mit dem icon.battery widget in Verbindung mit dem fhem-Treiber v1.08 aufgefallen.
wenn ich irgendwann alle Eier gefunden habe, dann schaue ich mir es mal an ;D
Frohe Ostern @all
Klar, kein Stress!
Frohe Ostern!
@fhainz: Auf die Schnelle, probier mal die 1.09, die ich ein Stück weiter oben gepostet habe.
Nein, leider selbes Problem.
Mit der v1.09 funktioniert auch mein selbstgebautes toggleElement widget (http://forum.fhem.de/index.php/topic,30909.msg276647.html#msg276647) nicht mehr richtig. Beim laden ist alles ok, nach einem klick auf eine andere Seite werden alle Icons aufgeblendet. Muss dem aber erst auf den Grund gehen.
Zitat von: HCS am 05 April 2015, 11:29:25
Den finde ich praktisch. Der erspart evtl. dann auch unzählige weitere Converter.
Damit lässt sich doch dann auch das "bin" beim NumDisplay erledigen, bzw. der BoolConverter, oder?
Freut mich. Ja, damit ist BoolConverter eigentlich überflüssig. Man kann sich damit natürlich theoretisch alle Converter bauen, die man haben möchte. MMn sollte man sich trotzdem überlegen, welche anderen, oft benutzten Converter man aus Convenience-Gründen fertig anbieten will. So dass der normale Benutzer im Normalfall nicht selbst Converter-Code schreiben muss.
Zitat von: herrmannj am 05 April 2015, 12:25:16
Das ist kein bug - das ist ein feature :) Ich kann mir das leider iA nicht im Detail ansehen (morgen erst)
Keine Panik, war wirklich nicht als Wink mit dem Zaunpfahl gedacht oder so :) Eilt ja nicht.
Zitat von: herrmannj am 05 April 2015, 12:25:16
Ich übernehme den gerne die converter - die Idee ist sehr gut. Folgende Bitte dazu: schau Dir (Ihr, wie auch immer) das Ding bitte nochmal sehr genau auf folgenden Aspekt hin an:
Kann ich via $value über sv (bzw den websocket) code einschleusen der dann im eval mit fhem rechten ausgeführt wird ?
Ich meine damit das Äquivalent zu sql injections. Das müsste bitte unbedingt vermieden werden. Wenn das unmöglich ist würde ich den Bernds Vorschlag folgend in der 99 er sehen. Hintergrund: in der Standard Installation möchte ich keine Einfallstore haben, was der user dann hinterher damit macht liegt in persönlicher Verantwortung jedes Einzelnen.
Ok, wichtiger Punkt! Ich hab mal etwas rumgespielt und im Moment kann das offenbar durchaus passieren. Aber ich habe mir das jetzt mal näher angesehen. Vorweg: Ich habe großen Respekt vor diesen Sicherheitsfehlern und bin da kein großer Experte. Wäre gut, wenn da noch jemand anders etwas zu sagen könnte.
Vorschlag wäre, dass man die Variable $VALUE, die von SV rein kommt, mit String::Escape::backslash und mit String::Escape::quote bearbeitet. Damit sollte aus der Variable in jedem Fall ein richtiger String werden, der nicht mehr als Code interpretiert werden kann.
Sagen wir, der Converter sieht so aus {$VALUE + 5}. Wenn eine Zahl kommt, sagen wir 3.17, dann wird daraus {"3.17" + 5} und passt damit. Wenn ein String kommt, sagen wir 'system("reboot");3+', dann wird daraus {"system(\"reboot\");3+" + 5}. Also wurde da der Code korrekt in einen String gewandelt.
Oder?
Setzt natürlich dann Modul String::Escape vorraus.
Euch frohe Ostern übrigens! :)
Hi,
frohe Ostern zurück.
Zitat
MMn sollte man sich trotzdem überlegen, welche anderen, oft benutzten Converter man aus Convenience-Gründen fertig anbieten will. So dass der normale Benutzer im Normalfall nicht selbst Converter-Code schreiben muss.
Sehe ich genauso. Zumal der Aufwand einen converter zu bauen ja wirklich minimal ist.
ZitatVorschlag wäre, dass man die Variable $VALUE, die von SV rein kommt, mit String::Escape::backslash und mit String::Escape::quote bearbeitet. Damit sollte aus der Variable in jedem Fall ein richtiger String werden, der nicht mehr als Code interpretiert werden kann.
Alternativ wäre es evtl mgl nur Zahlen durch zu lassen (regex \d, mit Komma und Vorzeichen natürlich). Ggf könnte man (um das install der Pakete zu vermeiden) auf das Hochkomma einen String replace legen. Da muss man aber immer extremst aufpassen um alle Varianten zu erwischen. Es gibt verschiedene Möglichkeiten system Befehle oder perl code auszuführen. Beispiel, den Code base64 codiert einschleusen und ein eval auf decode base64 (bla). Durch die base64 codierung werden auch pattern wie system('. und co schwer erkennbar.
Daher würde ich dafür voten das auf Zahlen zu beschränken was ja der Intention des converters durchaus gerecht wird. Möglich blieben dann Umrechnungen (Einheiten, Prozent auf 255 und zurück etc) genauso wie auch der Wertebereich bei Markisen (100-$value um den Wert zu invertieren). Das Risiko wäre mMn damit ausreichend reduziert.
vg
jörg
Hm, man könnte das schon so machen und den Converter auf Zahlen beschränken, aber ich kann mir schon einige Szenarien vorstellen, in denen auch das Konvertieren von Strings nützlich wäre. Prinzipiell fände ich es daher schon schöner, wenn das weiterhin möglich wäre.
Was genau spricht denn deiner Meinung nach gegen das Absichern durch String::Escape? Ich halte das erstmal für sicher und würde das einer selbstgebauten replace-Funktion in jedem Fall vorziehen (halte ich, wie du ja auch, für gefährlich). Zur Not könnte man natürlich den Code aus String::Escape rauskopieren.
Zitat von: fhainz am 05 April 2015, 12:45:45Mir ist noch Problem mit dem icon.battery widget in Verbindung mit dem fhem-Treiber v1.08 aufgefallen. Den js Code von icon.battery hab ich mit dem aus dem widget git ersetzt. Da gabs anscheindend im original Code einen Bug?
Das widget zeigt zwar den Wert mit den Füllungs-Balken an geht aber nicht mehr in den "on state", sprich es wird nicht mehr grün.
Kann mir mal mit dem basic.shifter jemand weiterhelfen, da ist mir eine ganze Liste unklar.
1. mit Treiber V1.02 geht der Farbumschlag bei mir auch nicht
2. im widgets repo liegt diese Variante vom basic.shifter:
https://github.com/herrmannj/smartvisu-widgets/blob/master/basic/shifter/basic.html
{% if pic_on|slice(0, 5) == 'icon.' %}
{{ attribute(icon, pic_on|slice(5), [id, gad_switch, gad_value, '', min, max]) }}
{% else %}Welchen Zweck hat der Parameter nach gad_value mit dem Leerstring?
3. Wo ist den irgend ein code, der den Farbumschlag macht?
im update handler auf alle Fälle nicht:
// ----- icon.battery ---------------------------------------------------------
$(document).delegate('svg[data-widget="icon.battery"]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}
var val = Math.round((response[0] - $(this).attr('data-min')) / ($(this).attr('data-max') - $(this).attr('data-min')) * 40);
fx.grid(this, val, [39, 68], [61, 28]);
}
});Der wird ja am Ende zu einem "<svg ..." und das icon macht sich an class="icon icon0" fest.
Ich muss jetzt erst mal verstehen, wie und warum das überhaupt funktionieren kann, bevor ich dahinter kommen kann, was der Treiber damit zu tun haben könnte.
Ganz generell:
Wir sollten überlegen, ob es gut ist, dass wir Schnipsel haben, mit denen Anwender die original widget.js und die original widget htmls umbauen.
fhainz hat es zum Glück dazugeschrieben, aber es kann extrem verwirrend werden, wenn man ein Problem nachvollziehen will, und anders "zusammengebastelte" wigets hat.
Evtl. wäre es besser, für widgets, die einen Fehler haben, einen Ersatz zu schaffen und die originalen uverändert zu lassen.
Zumal dieses umgebaute widget hier auch noch dazu führt, dass man es anders aufrufen muss, als die SV-Doku beschreibt.
SV:
{{ basic.shifter(id, gad_switch, gad_value, pic_on, pic_off, min, max) }}
Aufruf für das umgebaute widget:
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}
Zitat von: vbs am 06 April 2015, 01:09:57... aber ich kann mir schon einige Szenarien vorstellen, in denen auch das Konvertieren von Strings nützlich wäre. Prinzipiell fände ich es daher schon schöner, wenn das weiterhin möglich wäre.
Kann mir auch welche vorstellen und fände es auch schöner, wenn er Strings könnte. Und man hat es auch mal mit einem Datum zu tun oder will aus 90 Sekunden 1:30 machen usw.
Zitat von: HCS am 06 April 2015, 09:45:38
1. mit Treiber V1.02 geht der Farbumschlag bei mir auch nicht
Bei mir ist mit 1.02 alles ok. Mit 1.08 funktioniert der Farbumschlag nicht mehr.
Zitat von: HCS am 06 April 2015, 09:45:38
2. im widgets repo liegt diese Variante vom basic.shifter:
https://github.com/herrmannj/smartvisu-widgets/blob/master/basic/shifter/basic.html
{% if pic_on|slice(0, 5) == 'icon.' %}
{{ attribute(icon, pic_on|slice(5), [id, gad_switch, gad_value, '', min, max]) }}
{% else %}
Welchen Zweck hat der Parameter nach gad_value mit dem Leerstring?
Das verstehe ich auch nicht ganz. Hab gerade gemerkt, dass ich den basic.shifter eigentlich falsch definiert habe.
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}Wenn ich die überflüssigen '' rausnehme (das off icon hab ich jetzt auch mal eingetragen)
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', 'icon.battery' ) }}läuft anscheinend ein endlos prozess nach dem akualisieren. Die gads bis zum shifter werden geladen, ab den shifter nichts mehr. Browser reagiert nicht mehr, prozessor leistung geht auf 100%.
Ohne '0', '255' funktioniert es wieder.
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', 'icon.battery' ) }}Anscheinend liegt es an dem min Wert.
- Mit 0, 255 kommt sofort die Endlosschleife.
- Mit 1, 255 kommt zwar keine Endlosschleife aber das die Striche zeichnen über das Batterie Icon raus.
- Mit '', 255 läd die Seite, das Icon passt, nur die Farbe ändert sich unter 1.08 nicht. Mit 1.02 passt alles.
Kann das jemand bestätigen?
Zitat von: HCS am 06 April 2015, 09:45:38
3. Wo ist den irgend ein code, der den Farbumschlag macht?
im update handler auf alle Fälle nicht:
Ich denke die Farumschaltung macht basic.shifter
// ----- basic.shifter --------------------------------------------------------
$(document).delegate('span[data-widget="basic.shifter"]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}
var step = Math.min((response[0] / $(this).attr('data-max') * 10 + 0.49).toFixed(0) * 10, 100);
if (step > 0 && response[1] != 0) {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-on').replace('00', step));
}
else if (step > 0 && $(this).attr('data-pic-off').substr(-7) == '_00.png') {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-off').replace('00', step));
}
else {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-off'));
}
},
'click': function (event) {
var items = $(this).attr('data-item').explode();
if (items[1]) {
io.write(items[1], (widget.get(items[1]) == 0 ? 1 : 0));
}
}
});
$(document).delegate('span[data-widget="basic.shifter"] > a > img', 'hover', function (event) {
if (event.type === 'mouseenter') {
$(this).addClass("ui-focus");
}
else {
$(this).removeClass("ui-focus");
}
});Zitat von: HCS am 06 April 2015, 09:45:38
Evtl. wäre es besser, für widgets, die einen Fehler haben, einen Ersatz zu schaffen und die originalen uverändert zu lassen.
Sehe ich auch so.
Zitat von: HCS am 06 April 2015, 09:45:38
Zumal dieses umgebaute widget hier auch noch dazu führt, dass man es anders aufrufen muss, als die SV-Doku beschreibt.
..
Aufruf für das umgebaute widget:
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}
Siehe oben. Ist eindeutig ein Fehler von mir, falsch definiert. Aber warum diese definition funktioniert hat ist mir immer noch ein Rätsel.
Zitat von: fhainz am 06 April 2015, 10:28:08Das verstehe ich auch nicht ganz. Hab gerade gemerkt, dass ich den basic.shifter eigentlich falsch definiert habe.
Du hast ihn so definiert, dass er mit dem umgebauten widget funktioniert.
Der Effekt mit der Endlosschleife tritt genau dann auf, wenn man ihn so wie in SV beschrieben definiert und das umgebaute widget verwendet
Dann kommt als max im update handler 0 an und die Division durch 0 führt zur Endlosschleife.
Wenn Du einen min Wert angibst, dann kommt der als max an und darum malt es drüber raus.
Irgend wer muss doch das widget so umgebaut haben und eine Erklärung haben, was der Grund dafür ist.
Zitat von: fhainz am 06 April 2015, 10:28:08Bei mir ist mit 1.02 alles ok. Mit 1.08 funktioniert der Farbumschlag nicht mehr.
Das Problem ist, dass ich noch nicht verstehe, durch was es mit dem Farbumschlag überhaupt funktionieren kann.
ZitatIch denke die Farumschaltung macht basic.shifter
In diesem Fall wird doch ein icon.battery draus, und es ist am Schluss gar kein basic.shifter mehr, oder verstehe ich das falsch.
Auf der fertig gerenderten page wir das draus:
<svg id="room_test-basic_shifter_test" data-widget="icon.battery" data-item="hcs.data.counter, switch_dummy" data-min="0" data-max="999" class="icon icon0" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">
<g>
<rect x="44" y="21" width="12" height="3"></rect>
<rect rx="3" x="35" y="25" width="30" height="45" fill="none"></rect>
</g>
</svg>Und das ist nun eindeutig ein data-widget="icon.battery" und kein shifter mehr, somit kann auch kein update code vom shifter laufen und icons ändern.
Stimmt, da gibts keinen basic.shift mehr, das hab ich übersehen ::)
Kann es das sein? ein paar Zeilen über icon.battery
$(document).delegate('svg[data-widget^="icon."]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}
if (response instanceof Array) {
this.setAttributeNS(null, 'class', 'icon' + (response[0] && response[1] ? ' icon1' : ' icon0'));
}
},
'click': function (event) {
if ($(this).attr('data-item')) {
var items = $(this).attr('data-item').explode();
if (items[1]) {
io.write(items[1], (widget.get(items[1]) == 0 ? 1 : 0));
}
}
}
});
Edit:
Ich hab mir mal mit v1.02 die Konsolen Meldungen angesehen die beim aus/einschalten entstehen.
[Log] [icon.battery] update 'room_wohnzimmer-mba_ladedose': [150.4, 0] (base.js, line 678)
[Log] [icon.battery] update 'room_wohnzimmer-mba_ladedose': [150.4, 1] (base.js, line 678))
on:
<svg id="room_wohnzimmer-mba_ladedose" data-widget="icon.battery" data-item="mba.akkuIcon, mbaLadedose" data-min="0" data-max="255" class="icon icon1" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">
off:
<svg id="room_wohnzimmer-mba_ladedose" data-widget="icon.battery" data-item="mba.akkuIcon, mbaLadedose" data-min="0" data-max="255" class="icon icon0" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">
Die Klassen werden in 1.02 richtig gesetzt.
Hi,
Bernd hatte den basic.shifter angepasst weil der max Wert ignoriert wurde.
vg
jörg
Prima, Du (fhainz) leitest mich gerade in die richtige Richtung.
Ich glaube, ich beginne zu verstehen. Es gibt mehre verschieden Update-Handler, von denen mal der eine und mal der andere und mal mehrere gleichzeitig laufen müssen.
Der Treiber ruft nach der neuen Methode aber genau einen auf. Es müssten aber zwei laufen, der vom icon.battery und der delegate, den Du gerade gepostet hast.
Der Treiber geht mom. fälschlicherweise davon aus, dass er genau einen update handler aufrufen muss.
Da lässt sich dran arbeiten.
Das ändert aber nichts an dem Thema, dass das widget so nicht bleiben kann und an meiner Eingabe, die original SV widgets unverändert zu lassen.
Zitatan meiner Eingabe, die original SV widgets unverändert zu lassen.
Bsp eine LED mit Helligkeit 0 .. 100 wird vom original basic.shifter falsch dargestellt (der shifter geht von 255 max aus und stellt 100 als "kurz vor halb" dar")
vg
jörg
Ich würde die Verzeichnisnamen im widget-Repo als Namespace verstehen wollen, also zB "basic". "basic" wiederum "gehört" SV und das sollten wir nicht editieren, sehe ich auch so. MMn sollten wir unsere von von basic geforkten Widgets in einen eigenen Namespace/Verzeichnis packen, zb "basic_mod" o.ä. Dann kann man weiterhin das Original als "basic/shifter" verwenden oder eben unseren Fork als "basic_mod/shifter".
Ich habe mich auch schonmal an zwei kleineren neuen Widgets versucht. Die habe ich dann zB nach "basic_extra" gepackt.
Zitat von: herrmannj am 06 April 2015, 11:51:58
Bsp eine LED mit Helligkeit 0 .. 100 wird vom original basic.shifter falsch dargestellt (der shifter geht von 255 max aus und stellt 100 als "kurz vor halb" dar")
Ich meinte auch nicht, dass man den Fehler nicht korrigieren sollte, sondern dass man ein neues Widget machen sollte, dass korrekt funktioniert.
Versuch mal mit den "umgebastelten" original widgets einen Fehler von jemandem anderen zu finden.
Der eine hat dies eingebaut, der andere jenes, der nächste nichts davon und das Original in Betrieb und dann versuch mal dahinter zukommen, was warum bei wem passiert.
Wenn man davon ausgehen kann, dass die SV-Grund-Installation bei allen gleich ist und man den gleichen Stand eines widgets aus unserem repo verwendet, hat man auch sicher die gleichen Bedingungen und es wird deutlich einfacher.
Hi,
ZitatIch meinte auch nicht, dass man den Fehler nicht korrigieren sollte, sondern dass man ein neues Widget machen sollte, dass korrekt funktioniert.
ne, das macht ja keinen Sinn. Ziel vom clean-install ist ja das man dort eine definierte Basis findet. Wenn wir jetzt anfangen jedesmal für einen Fehler ein neues widget from scratch zu bauen dann werden wird das ja nie erwachsen.
Im clean-install soll der sv Lieferzustand liegen, inkl der notwendigen bugfixes und in höchster Qualität.
Im widget repo landen dann die Erweiterungen.
btw: ich mach jetzt endgültig diesen thread hier zu, sonst werden wir ja wahnsinnig (wenn wir das nicht schon sind ;) ) und eröffne mal
fronthem Modulsthread
fronthem nextgen driver
smartVisu erste Schritte
smartVisu Widgets
(erste Schnritte und widgets haben wir eigentlich schon)
wenn ich was vergessen habe macht die zusätzlich auf - Ziel ist es wieder etwas mehr Struktur reinzubekommen
vg
jörg