Hauptmenü

FHEM Dashboard

Begonnen von svenson08, 14 November 2013, 21:34:33

Vorheriges Thema - Nächstes Thema

fron

Habe mir die HTTP-Kommunikation im Debugger angesehen:
* direkt nach dem (erfolgreichen) http-GET "fhemicon.png"
kommt ein http-POST https://<IP>:<port>/[b]fhem[/b]?cmd=get VIEW config&XHR=1

leider falsch, das kann nicht funktionieren: Ich war so frei, das "webname"-Attribut meines FHEM-Webservers zu ändern
* "fhem" ist nicht das "webname"-Attribut meines WebServers
* der Zugriff führt unweigerlich zu "403: FORBIDDEN"

wenn ich den POST manuell korrigiere:
* https://<IP>:<port>/<korrektes webname-attribut>?cmd=get VIEW config&XHR=1
antwortet der FHEM-Webserver wie gewünscht mit "200: OK"

Zwischenstand: Es scheint jemand den String "fhem" hardcoded zu haben.
=> der Übeltäter findet sich in "opt/fhem/www/pgm2/dashboard.js"

/opt/fhem/www/pgm2# egrep "'/fhem'" dashboard.js
[b]var fhemUrl = '/fhem';[/b]


Ich habe testweise mein "webname"-Attribut manuell eingepflegt und sofort läufts:
* korrekt dargestellte Tabs
* die drei Buttons werden dargestellt.

So richtig gut ist das natürlich auch nicht.

?! Wahrscheinlich ist es möglich, das webname-attribut dynamisch auszulesen!?
Cubietruck
2x CUL: CUL-868 (MAX, MAX-Basic, Wandtermostat, ECO-Taster, Türkontakt) ; CUL-433 (4x SomfyRTS Rolladenmotor)
2x Jeelink (div Lacrosse/Technoline TX29DTH) ; (div PCA301)
HMUSB (KFM100 Füllstandssensor, HM-LC-BL1-FM)

Talkabout

Zitat von: fron am 07 November 2015, 21:04:18
da liegt der Hund begraben:
=> ich sehe überhaupt keinen Button in der Dashboard-Ansicht

=> ich erwarte Buttons: Damit wäre ich für's erste zufrieden, der Ort der Buttons wäre mir egal (oben rechts, wie im Wiki wäre prima)

Readings
lockstate / unlock / 2015-11-05 18:59:52

Ich glaube ich hatte Dich noch nicht nach dem verwendeten Browser gefragt?

Gruss

GeZi3560

Hallo zusammen,

wie kann ich verhindern das im Dashboard bei den FibaroWallplugs  das Auswahlfeld statt  "on" angezeigt wird ?

Siehe Pics:

Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

Talkabout

Zitat von: GeZi3560 am 08 November 2015, 11:55:34
Hallo zusammen,

wie kann ich verhindern das im Dashboard bei den FibaroWallplugs  das Auswahlfeld statt  "on" angezeigt wird ?

Siehe Pics:
Hast Du es schon mit webCmd probiert?

Gruss

GeZi3560

Ja, in Webcmd steht On:off.
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

Talkabout

Zitat von: GeZi3560 am 08 November 2015, 12:52:04
Ja, in Webcmd steht On:off.
Dann wird es wohl ein Problem mit dem Modul sein, zu dem das Device gehört. Kannst Du mal die Definition posten?

Gruss

fron

"So" - ich möchte eine allgemeingültige Lösung vorschlagen, eine kleine Änderung für "dashboard.js"

IST: Hard-Coded Path => funktioniert nur, wenn kein "webname" gesetzt wird
//var fhemUrl = '/fhem';

SOLL: dynamisches Ermitteln des fhem-Pfades via Regex (ab Beginn der Script-URL suchen, ein Slash muss am Anfang stehen, danach alles nehmen, wass kein Slash ist - bei Normalinstallation läuft das auf /fhem hinaus
var fhemUrl = document.location.pathname.match('^\/[^\/]+');

Cubietruck
2x CUL: CUL-868 (MAX, MAX-Basic, Wandtermostat, ECO-Taster, Türkontakt) ; CUL-433 (4x SomfyRTS Rolladenmotor)
2x Jeelink (div Lacrosse/Technoline TX29DTH) ; (div PCA301)
HMUSB (KFM100 Füllstandssensor, HM-LC-BL1-FM)

GeZi3560

Zitat von: Talkabout am 08 November 2015, 17:10:05
Dann wird es wohl ein Problem mit dem Modul sein, zu dem das Device gehört. Kannst Du mal die Definition posten?

Gruss

Aber gerne .. bitte schön  !

define FirbaroWP_3 ZWave d29xxxx 6
attr FirbaroWP_3 IODev ZWAVE1
attr FirbaroWP_3 alias Technik Mediaroom
attr FirbaroWP_3 classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD MARK SWITCH_BINARY METER SENSOR_MULTILEVEL
attr FirbaroWP_3 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr FirbaroWP_3 group Licht
attr FirbaroWP_3 icon black_Steckdose.off
attr FirbaroWP_3 room CUL_ZWave,Licht,Mediaroom
attr FirbaroWP_3 webCmd on:off
define FileLog_FirbaroWP_3 FileLog /opt/fhem/log/FirbaroWP_3-%Y.log FirbaroWP_3
attr FileLog_FirbaroWP_3 logtype text
attr FileLog_FirbaroWP_3 room CUL_ZWave
define SVG_FileLog_FirbaroWP_3_1 SVG FileLog_FirbaroWP_3:SVG_FileLog_FirbaroWP_3_1:CURRENT
attr SVG_FileLog_FirbaroWP_3_1 room CUL_ZWave,Mediaroom
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

Talkabout

Zitat von: fron am 08 November 2015, 23:21:36
"So" - ich möchte eine allgemeingültige Lösung vorschlagen, eine kleine Änderung für "dashboard.js"

IST: Hard-Coded Path => funktioniert nur, wenn kein "webname" gesetzt wird
//var fhemUrl = '/fhem';

SOLL: dynamisches Ermitteln des fhem-Pfades via Regex (ab Beginn der Script-URL suchen, ein Slash muss am Anfang stehen, danach alles nehmen, wass kein Slash ist - bei Normalinstallation läuft das auf /fhem hinaus
var fhemUrl = document.location.pathname.match('^\/[^\/]+');
Hallo fron,

welches Problem siehst Du mit der aktuellen Implementierung? Hast Du einen Fehlerfall oder ist das aus Deiner Sicht eine Optimierung?

Gruss

Talkabout

Zitat von: GeZi3560 am 09 November 2015, 07:44:02
Aber gerne .. bitte schön  !

define FirbaroWP_3 ZWave d29xxxx 6
attr FirbaroWP_3 IODev ZWAVE1
attr FirbaroWP_3 alias Technik Mediaroom
attr FirbaroWP_3 classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD MARK SWITCH_BINARY METER SENSOR_MULTILEVEL
attr FirbaroWP_3 devStateIcon on:black_Steckdose.on off:black_Steckdose.off
attr FirbaroWP_3 group Licht
attr FirbaroWP_3 icon black_Steckdose.off
attr FirbaroWP_3 room CUL_ZWave,Licht,Mediaroom
attr FirbaroWP_3 webCmd on:off
define FileLog_FirbaroWP_3 FileLog /opt/fhem/log/FirbaroWP_3-%Y.log FirbaroWP_3
attr FileLog_FirbaroWP_3 logtype text
attr FileLog_FirbaroWP_3 room CUL_ZWave
define SVG_FileLog_FirbaroWP_3_1 SVG FileLog_FirbaroWP_3:SVG_FileLog_FirbaroWP_3_1:CURRENT
attr SVG_FileLog_FirbaroWP_3_1 room CUL_ZWave,Mediaroom
Die Definition sieht für mich ok aus. Da ich mich aber mit dem ZWave Modul so gar nicht auskenne, da ich auch keine Gräte dieser Art besitze, kann ich Dir nicht mehr sagen. Ich würde versuchen das Problem in dem jeweiligen Unterforum für ZWave zu posten, vielleicht hat man dort eine Lösung für Dich.

Gruss

fron

#1600
Zitat von: Talkabout am 10 November 2015, 20:33:20
Hallo fron,

welches Problem siehst Du mit der aktuellen Implementierung? Hast Du einen Fehlerfall oder ist das aus Deiner Sicht eine Optimierung?

Gruss

ich hatte ja vergangene Woche festgestellt, wir hatten uns im Forum ausgetauscht, dass Dashboard auf meiner Installation fehlerhaft arbeitet. (Buttons fehlen gänzlich, Tabs nicht wie üblich dargestellt und so)

Ich hatte das Szenario im Javascript-Debugger untersucht, und festgestellt, dass dashboard.js eine in meinem Fall ungültige URL aufruft:
=> "/fhem" ist nicht in jedem Fall eine URL des FHEM-Webservers.
=> mein Vorschlag ermittelt dynamisch die gültige URL, bzw. den Pfadbestandteil.

Ich möchte keinesfalls die großartige Leistung des dashboard.js schmälern, jedoch erlaube ich mir den Hinweis auf:
http://www.fhemwiki.de/wiki/DevelopmentFHEMWEB
...
$FW_ME
When using FHEMWEB, you have to specify a base path in all requests; this value is stored in the variable $FW_ME and defaults to /fhem. The user may change it by setting the webname attribute.
...


=>  "defaults to /fhem" ist ungleich "equals to /fhem", nicht wahr? ;-)

Ich verwende auf meinem FHEM-Server diverse FHEM-webnames, und keiner lautet "/fhem" - might be security by obscurity ;-)

Viele Grüße!
Cubietruck
2x CUL: CUL-868 (MAX, MAX-Basic, Wandtermostat, ECO-Taster, Türkontakt) ; CUL-433 (4x SomfyRTS Rolladenmotor)
2x Jeelink (div Lacrosse/Technoline TX29DTH) ; (div PCA301)
HMUSB (KFM100 Füllstandssensor, HM-LC-BL1-FM)

Talkabout

Zitat von: fron am 10 November 2015, 20:50:47
ich hatte ja vergangene Woche festgestellt, wir hatten uns im Forum ausgetauscht, dass Dashboard auf meiner Installation fehlerhaft arbeitet. (Buttons fehlen gänzlich, Tabs nicht wie üblich dargestellt und so)

Ich hatte das Szenario im Javascript-Debugger untersucht, und festgestellt, dass dashboard.js eine in meinem Fall ungültige URL aufruft:
=> "/fhem" ist nicht in jedem Fall eine URL des FHEM-Webservers.
=> mein Vorschlag ermittelt dynamisch die gültige URL, bzw. den Pfadbestandteil.

Ich möchte keinesfalls die großartige Leistung des dashboard.js schmälern, jedoch erlaube ich mir den Hinweis auf:
http://www.fhemwiki.de/wiki/DevelopmentFHEMWEB
...
$FW_ME
When using FHEMWEB, you have to specify a base path in all requests; this value is stored in the variable $FW_ME and defaults to /fhem. The user may change it by setting the webname attribute.
...


=>  "defaults to /fhem" ist ungleich "equals to /fhem", nicht wahr? ;-)

Ich verwende auf meinem FHEM-Server diverse FHEM-webnames, und keiner lautet "/fhem" - might be security by obscurity ;-)

Viele Grüße!
Hört sich doch alles schlüssig an :)

Mir gefällt jedoch das Parsen über Javascript in diesem Fall nicht. Ich werde mir überlegen, wie ich die Information aus FHEMWEB zum Client übertragen kann, damit der Pfad immer vom Server kommt, wo er bekannt ist.

Danke Dir für Deine Mühe!

Gruss

rudolfkoenig

ZitatDann wird es wohl ein Problem mit dem Modul sein, zu dem das Device gehört.
@Talkabout: ich kann mich mit dieser Theorie nicht anfreunden, da die Anzeige in FHEMWEB wie erwartet ausschaut.

Talkabout

#1603
Zitat von: rudolfkoenig am 11 November 2015, 16:38:29
@Talkabout: ich kann mich mit dieser Theorie nicht anfreunden, da die Anzeige in FHEMWEB wie erwartet ausschaut.
Hallo Rudi,

ja, das stimmt wohl. Die Frage ist dann aber, was den Unterschied ausmacht. Das Dashboard geht davon aus, dass es über die Funktion:

FW_devState($d, $rf, \%extPage);

die Darstellung der Schalter bekommt. Es gibt dann noch eine spezielle Behandlung für die "FW_atPageEnd"-Devices. Scheinbar ist dies bei diesem speziellen Device aber so nicht korrekt. Ist hier noch eine andere Abfrage notwendig?

Gruss

Edit: mein Kommentar kam zu früh. Intern baut das Dashboard die Commands über folgendes Code-Snippet auf:

foreach my $cmd (split(":", $cmdlist)) {
                                my $htmlTxt;
                                my @c = split(' ', $cmd);
                                if($allSets && $allSets =~ m/$c[0]:([^ ]*)/) {
                                        my $values = $1;
                                        foreach my $fn (sort keys %{$data{webCmdFn}}) {
                                                no strict "refs";
                                                $htmlTxt = &{$data{webCmdFn}{$fn}}($FW_wname, $d, $FW_room, $cmd, $values);
                                                use strict "refs";
                                                last if(defined($htmlTxt));
                                        }
                                }
                                if($htmlTxt) {
                                        # add colspan to avoid squeezed table cells
                                        $htmlTxt =~ s/<td>/<td colspan="10">/;
                                        $ret .= $htmlTxt;
                                } else {
                                        $ret .= FW_pH "cmd.$d=set $d $cmd$rf", $cmd, 1, "col3", 1;
                                }
                        }

Kann es sein, dass bei diesem Device der Code-Teil

$htmlTxt = &{$data{webCmdFn}{$fn}}($FW_wname, $d, $FW_room, $cmd, $values);
greift und die Darstellung dadurch unterschiedlich ist? Was wäre der richtige Weg die Darstellung wie im Fhemweb zu erreichen?

Danke!

Gruss

Talkabout

Zitat von: Talkabout am 11 November 2015, 18:37:45
Hallo Rudi,

ja, das stimmt wohl. Die Frage ist dann aber, was den Unterschied ausmacht. Das Dashboard geht davon aus, dass es über die Funktion:

FW_devState($d, $rf, \%extPage);

die Darstellung der Schalter bekommt. Es gibt dann noch eine spezielle Behandlung für die "FW_atPageEnd"-Devices. Scheinbar ist dies bei diesem speziellen Device aber so nicht korrekt. Ist hier noch eine andere Abfrage notwendig?

Gruss

Edit: mein Kommentar kam zu früh. Intern baut das Dashboard die Commands über folgendes Code-Snippet auf:

foreach my $cmd (split(":", $cmdlist)) {
                                my $htmlTxt;
                                my @c = split(' ', $cmd);
                                if($allSets && $allSets =~ m/$c[0]:([^ ]*)/) {
                                        my $values = $1;
                                        foreach my $fn (sort keys %{$data{webCmdFn}}) {
                                                no strict "refs";
                                                $htmlTxt = &{$data{webCmdFn}{$fn}}($FW_wname, $d, $FW_room, $cmd, $values);
                                                use strict "refs";
                                                last if(defined($htmlTxt));
                                        }
                                }
                                if($htmlTxt) {
                                        # add colspan to avoid squeezed table cells
                                        $htmlTxt =~ s/<td>/<td colspan="10">/;
                                        $ret .= $htmlTxt;
                                } else {
                                        $ret .= FW_pH "cmd.$d=set $d $cmd$rf", $cmd, 1, "col3", 1;
                                }
                        }

Kann es sein, dass bei diesem Device der Code-Teil

$htmlTxt = &{$data{webCmdFn}{$fn}}($FW_wname, $d, $FW_room, $cmd, $values);
greift und die Darstellung dadurch unterschiedlich ist? Was wäre der richtige Weg die Darstellung wie im Fhemweb zu erreichen?

Danke!

Gruss
Hallo Rudi,

ich glaube ich habe das Problem. Kann es sein, dass im Dashboard nach dem Aufruf zu "FW_devState" noch der Aufruf zu "$allSets = FW_widgetOverride($d, $allSets);" fehlt? Das ist der einzige Unterschied, den ich bisher zu der Implementierung in FHEMWEB gefunden habe?

Gruss