(http://up.picr.de/15396931jr.png)
Was muss ich tun, damit man über die Buttons auch "get" auswählen kann und nicht nur "set"? Sowohl in der set als auch in der get Routine meines Moduls gibt es eine $usage, trotzdem wird nur der set-Button angezeigt. Dort funktioniert auch die Auswahl perfekt, aber ich finde es unlogisch, den set-Befehl verwenden zu müssen, wenn ich Daten BEKOMMEN (also get) will.
Evtl. kann man ja statt einem Button ein DropDown-Menü mit "get / set" machen und dann am Ende einen "execute"-Button. Ist mir auch schon ein paar mal negativ aufgefallen.
Viele Grüße
Markus
bitte keinen zusätzlichen execute Button... das charmante ist ja grade, dass man nach der Auswahl in den DropDownListen einfach nur enter drücken muss, was viel schneller geht, als mit der Maus noch einen Button betätigen zu müssen..
> Was muss ich tun, damit man über die Buttons auch "get" auswählen kann und nicht nur "set"?
Hier fragen.
Get Anzeige ist im FHEMWEB nicht implementiert. Ich habe es vor paar Monaten wieder einbauen wollen, leider sind aber viele wichtige Module nicht passend gepflegt. Ich setze es auf meine TODO Liste.
Wenn ich Dich irgendwie dabei unterstützen kann, lass es mich bitte wissen.
Ich habe es in FHEMWEB eingebaut, es wird angezeigt, falls die Rueckgabe auf "get dev ?" analog zu set mit "unknown command XX, choose one of" anfaengt (bzw. /unknown.*choose one of /i um genau zu sein).
Das ist nicht der Fall bei folgenden Modulen, die get anbieten:
EIB FileLog CUL_HM DbLog ECMD ECMDDevice FLOORPLAN FRM_AD Heating_Control IPWE LGTV M232 M232Counter M232Voltage NetIO230B OWServer OWX POKEYS SCIVT SWAP SWAP_0000002200000003 TCM Twilight WS2000 WS300 Weather OWAD OWCOUNT OWID OWLCD OWMULTI OWSWITCH OWTHERM
FileLog baue ich nicht um, das dropdown wuerde eher verwirren.
ACHTUNG bei EIB: es wird selbst bei ? als Argument ein Befehl ausgeloest, das ist evtl. schaedlich. Hab maz per PM benachtichtigt, EIB Anwaender sollten aber vorsichtig sein.
Langsam wird die Detailseite ueberfuellt.
für SWAP und SWAP_0000002200000003 gefixed
Zitat von: rudolfkoenig schrieb am Mi, 07 August 2013 15:16Ich habe es in FHEMWEB eingebaut, es wird angezeigt, falls die Rueckgabe auf "get dev ?" analog zu set mit "unknown command XX, choose one of" anfaengt (bzw. /unknown.*choose one of /i um genau zu sein).
(http://up.picr.de/15427052lr.png)
cool :) Danke!
Zitat von: rudolfkoenig schrieb am Mi, 07 August 2013 15:16Langsam wird die Detailseite ueberfuellt.
Idee dazu: Kann man nicht sogar die beiden "Set" und "Get" in einen Button als Dropdown darstellen? Beide Zeilen gleichzeitig dargestellt wird man eher selten brauchen.
Kann man auch nicht sagen (siehe CUL), weiterhin waere das mAn nicht viel besser und ich habe keine Funktionen, die die dropdowns in so einem Fall korrekt fuellen wuerden.
Also 3x dagegen :)
war ja auch nur eine Idee :)
übrigens, im dark-style sieht das noch reichlich merkwürdig aus:
(http://up.picr.de/15431733tu.png)
Stimmt, es sah merkwuerdig aus.
Habs gefixed, war aber mehr Umbau als ich dachte, und ich musste alle styles anfassen. Hoffentlich ging nichts schief, wenn ja bitte melden.
Weiterhin ist der modifier :noArg dazugekommen, um fuer ein "get CUL ccconf" kein weiteres Input-Feld zu presentieren. Angepasst ist aber nur das CUL get, alle anderen Module habe ich noch nicht angefasst.
geht das :noArg nur für get oder auch bei set ?
Sollte bei set/get/attr gehen, habs aber bisher nur mit get getestet.
Zitat von: rudolfkoenig schrieb am Do, 08 August 2013 18:38Weiterhin ist der modifier :noArg dazugekommen
cool... Du bist damit meiner nächsten Frage zuvorgekommen *lach*
funktioniert perfekt, solange man beachtet, dass es ein großes A sein muss.
55_GDS
71_LISTENLIVE
98_openweathermap
wurden entsprechend angepaßt.
(http://up.picr.de/15437720cc.png)
-----
ein kleines problem scheint es noch zu geben (zumindest mit dem dark style): die 'Probably associated with' überschrift steht in der set zeile statt ganz am ende vor der tabelle zu der sie eigentlich gehört.
Du meinst das hier?
(http://up.picr.de/15445491im.png)
was mich da mehr irritiert ist die Tatsache, dass die Buttons nicht untereinander stehen - bei anderen Modulen sind das anders aus.
(http://up.picr.de/15445530sb.png)
Da sind die Buttons untereinander ausgerichtet und gleichlang.
ja. genau. die überschrift gehört fast ganz nach unten auf die seite.
das ist nicht nur im dark so, sondern auch im default.
(http://up.picr.de/15445574bk.png)
Sieht so aus, als würde das außerhalb einer Tabelle stehen. Wobei der Inhalt von "Probably associated" ja an der richtigen Stelle auftaucht, nur die Überschrift nicht.
Lösungsvorschlag:
Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 3643)
+++ 01_FHEMWEB.pm (working copy)
@@ -892,7 +892,8 @@
my ($txt,$class,@obj) = @_;
if (@obj>0) {
my $row=1;
- FW_pO "<br>";
+ FW_pO "<div class='makeTable wide'>";
+# FW_pO "<br>";
FW_pO "$txt";
FW_pO "<table class=\"block wide $class\">";
foreach (sort @obj) {
Hallo zusammen,
bei mir klappt das ganze noch nicht wirklich.
Bei meinem YAMAHA Receiver gebe ich folgenden String zurück:
Unknown argument ?, choose one of on off volume:slider,-80,1,16 input:audio,av1,av2,av3,av4,av5,av6,airplay,hdmi1,hdmi2,hdmi3,hdmi4,netradio,server,tuner,usb,v-aux,ipod_usb mute:on,off
remoteControl:setup,up,down,left,right,return,option,display,enter scene:scene1,scene2,scene3,scene4 statusRequest
Dennoch bekomme ich nur noch die Hauptbefehle, die Zusatzargumente (z.B. bei Input die einzelnen Möglichkeiten) werden mir nicht mehr angezeigt, genauso wie der slider für Volume und die Auswahl zwischen on/off bei mute.
Kann es sein, dass sich hier ein Fehler durch das noArg eingeschlichen hat?
Vielen Dank für eure Hilfe
Gruß
Markus
Zitat von: Markus Bloch schrieb am Fr, 09 August 2013 18:37Hallo zusammen,
bei mir klappt das ganze noch nicht wirklich.
Bei meinem YAMAHA Receiver gebe ich folgenden String zurück:
Bei meinem Yamaha funktioniert das perfekt:
(http://up.picr.de/15446820kk.png)
(http://up.picr.de/15446821yd.png)
hast Du die gesamten style-Dateien aktualisiert und auch die neue Datei noArg.js (oder so ähnlich) in Deinem System?
Das einzige, was beim slider hier nicht funktioniert: nach jeder Änderung steht der wieder ganz links auf -80 anstatt auf dem eingestellten Wert.
Sieht Spitze aus, vielen Dank für die neue Funktionalität.
Gruß Niko
Hab ich heute via update alles installiert und mehrfach mit "shutdown restart" neugestartet :-/
laut Logfile wurde folgendes geupdatet
2013.08.09 18:15:14 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2013.08.09 18:15:14 1: update check Releases => local: Fhem 5.4 (DEVELOPMENT) remote: Fhem 5.4 (DEVELOPMENT)
2013.08.09 18:15:14 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2013.08.09 18:15:15 1: update saving statefile
2013.08.09 18:15:15 2: Backup with command: tar -cf - /usr/local/FHEM/etc/fhem.cfg /usr/local/FHEM/var/log/fhem.save /usr/local/FHEM/share/fhem/CHANGED /usr/local/FHEM/share/fhem/contrib /usr/local/FHEM/share/fhem/docs /usr/local/FHEM/share/fhem/FHEM /usr/local/FHEM/share/fhem/unused /usr/local/FHEM/share/fhem/www |gzip > /usr/local/FHEM/share/fhem/backup/FHEM-20130809_181515.tar.gz
2013.08.09 18:15:25 1: backup tar: removing leading '/' from member names
2013.08.09 18:15:25 1: backup done: FHEM-20130809_181515.tar.gz (5444628 Bytes)
2013.08.09 18:15:25 3: update get http://fhem.de/fhemupdate4/svn/./fhem.pl.txt
2013.08.09 18:15:25 3: update get http://fhem.de/fhemupdate4/svn/FHEM/00_CUL.pm
2013.08.09 18:15:26 3: update get http://fhem.de/fhemupdate4/svn/FHEM/01_FHEMWEB.pm
2013.08.09 18:15:26 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_CUL_HM.pm
2013.08.09 18:15:27 3: update get http://fhem.de/fhemupdate4/svn/FHEM/31_HUEDevice.pm
2013.08.09 18:15:27 3: update get http://fhem.de/fhemupdate4/svn/FHEM/34_SWAP.pm
2013.08.09 18:15:27 3: update get http://fhem.de/fhemupdate4/svn/FHEM/34_panStamp.pm
2013.08.09 18:15:27 3: update get http://fhem.de/fhemupdate4/svn/FHEM/35_SWAP_0000002200000003.pm
2013.08.09 18:15:27 3: update get http://fhem.de/fhemupdate4/svn/FHEM/55_GDS.pm
2013.08.09 18:15:28 3: update get http://fhem.de/fhemupdate4/svn/FHEM/71_LISTENLIVE.pm
2013.08.09 18:15:28 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_HMinfo.pm
2013.08.09 18:15:28 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_RandomTimer.pm
2013.08.09 18:15:29 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_openweathermap.pm
2013.08.09 18:15:29 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_telnet.pm
2013.08.09 18:15:29 3: update get http://fhem.de/fhemupdate4/svn/docs/commandref.html
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/images/fhemSVG/hm_lan.svg
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/images/fhemSVG/hue_bridge.svg
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/darkstyle.css
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/fhemweb_noArg.js
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/ios7smallscreenstyle.css
2013.08.09 18:15:30 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/ios7style.css
2013.08.09 18:15:31 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/smallscreenstyle.css
2013.08.09 18:15:31 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/style.css
2013.08.09 18:15:31 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/touchpadstyle.css
2013.08.09 18:15:31 1: update 24 file(s) have been updated.
2013.08.09 18:15:31 1: update A new version of fhem.pl was installed, 'shutdown restart' is required!
Dennoch sieht es auch nach Cache leeren der Browser so aus:
(siehe Anhang / see attachement)
Keine Ahnung, aber ich wüsste nicht was das sein könnte.
Viele Grüße
Markus
@Markus: longpoll ist evtl aus?
@betateilchen: ja, nur mit schliessenden </div> :)
Habs kurz mit default, dark und ios7 getestet und eingecheckt.
<br> muss nach und nach entfernt werden, es steht beim CSS styling nur im Weg.
naja, an Deinem Modul liegt es definitiv nicht.
am gewählten Style auch nicht:
(http://up.picr.de/15447230yr.png)
Bleibt eigentlich fast nur der Browser als Übeltäter.
Hmmm,
ich verwende primär:
Google Chrome: 28.0.1500.95 m
Firefox: 23.0
beides die aktuellsten Versionen. Und bereits mehrfach den Cache gelöscht. Da muss ich wohl mal ein komplettes FHEM Update von vorne bis hinten machen.
Schauhen wir mal.
Aber trotzdem vielen Dank für deine Hilfe.
Gruß
Markus
Zitat von: rudolfkoenig schrieb am Fr, 09 August 2013 19:46@betateilchen: ja, nur mit schliessenden </div> :)
wo Du recht hast, hast Du recht :)
Ein "update force" hat die gewünschte Lösung gebracht. :-)
Gruß
Markus
Hallo Rudi,
hast Du eine Idee, woher sowas kommen kann?
(siehe Anhang / see attachement)
Gleiches Betriebssystem, gleicher Browser, anderer PC.
Im "default" Style sieht alles ordentlich aus.
(siehe Anhang / see attachement)
Viele Grüße
Udo
Kann es nicht reproduzieren:
(siehe Anhang / see attachement)
Habs mit FF(23) und Chrome(28) getestet.
Was mir sonst noch aufgefallen ist:
- get dev stationByGeo ohne Argument spuckt ein haufen Fehlermeldungen aus (die anderen stationBy... auch)
- in der Doku steht "define myWeather openweather" (vmtl. falsch)
Beim Pixelzaehlen auf deinem Screenshot faellt mir auf, dass dein Browser den alten Version der darkstyle.css verwendet.
Hallo Rudi,
ich arbeite auch mit Chrome, der Screenshot von gestern abend war auf dem imac, die anderen Screenshots hier im Thread ware von einem Macbook, alle mit gleichen Versionsständen. Im Chrome unter Windows sieht es übrigens auch richtig aus. Es funktioniert nur im dark auf dem imac nicht, sehr komisch.
Das falsche define in der Doku kann ICH nicht nachvollziehen, denn da steht bei mir:
<a name="openweathermapdefine"></a>
<b>Define</b>
<ul>
<br/>
<code>define <name> openweathermap</code>
<br/><br/>
This module provides connection to openweathermap-network www.openweathermap.org (owo)<br/>
You can use this module to do three different tasks:<br/>
und auch in der commandref steht es richtig. Wo hast Du den Fehler gesehen? Das Modul hieß ursprünglich tatsächlich nur openweather, wurde aber vor der ersten Veröffentlichung umbenannt.
(siehe Anhang / see attachement)
Zu den Fehlermeldungen:
Im Moment ist das API von openweathermap nicht erreichbar. Gestern betraf das "nur" das Senden von Daten, heute scheint auch der Abruf nicht mehr zu funktionieren. Einen "Haufen" Fehlermeldungen kann ich aber nicht feststellen. Auf der Konsole erscheint eine einzige Fehlermeldung, weil kein JSON-Text vorhanden ist und der gescheiterte Verbindungsaufbau wird auch völlig korrekt im Frontend angezeigt:
(siehe Anhang / see attachement)
Viele Grüße
Udo
Zitat von: rudolfkoenig schrieb am Mi, 14 August 2013 09:11Beim Pixelzaehlen auf deinem Screenshot faellt mir auf, dass dein Browser den alten Version der darkstyle.css verwendet.
Das heißt heute abend mal Browser-Cache leeren... obwohl es eigentlich gar keinen Cache geben sollte laut meiner Konfiguration. Aber ich probiers aus. Danke für den Tip.
Zitat von: betateilchen schrieb am Mi, 14 August 2013 09:22Zitat von: Rudiget dev stationByGeo ohne Argument spuckt ein haufen Fehlermeldungen aus
Zu den Fehlermeldungen:
Im Moment ist das API von openweathermap nicht erreichbar. Gestern betraf das "nur" das Senden von Daten, heute scheint auch der Abruf nicht mehr zu funktionieren. Einen "Haufen" Fehlermeldungen kann ich aber nicht feststellen.
Die get-Befehle funktionieren bei mir im Moment einwandfrei.
(siehe Anhang / see attachement)
Zitat von: rudolfkoenig schrieb am Mi, 14 August 2013 09:05- in der Doku steht "define myWeather openweather" (vmtl. falsch)
ah, ich habs gefunden. Und korrigiert. Danke für den Hinweis.
> Die get-Befehle funktionieren bei mir im Moment einwandfrei.
Bei mir jetzt auch. Vorhin kam:
2013.08.14 08:42:12 3: openweather owo_dg1udo: response:
{"message":"Error: Not found city","cod":"404"}
2013.08.14 08:42:12 3: openweather owo_dg1udo: decoding JSON
Use of uninitialized value in localtime at ./FHEM/98_openweathermap.pm line 456.
Use of uninitialized value in localtime at ./FHEM/98_openweathermap.pm line 457.
Use of uninitialized value in localtime at ./FHEM/98_openweathermap.pm line 458.
usw.
Ich bekomme jetzt auch mit einer frischen Definition keine Fehlermeldungen.
Boah... das bedeutet, der owo Server schickt auf den http-request ein "200 OK" und in der zurückgelieferten Antwort steckt eine Fehlermeldung. Ziemlich übel, an sowas hab ich noch gar nicht gedacht.
Erschwerend kommt hinzu, dass ich das "cod":"404" nur in der JSON Antwort bekomme und nicht, wenn die Daten per XML abgerufen werden. Interessant wäre gewesen, wie die XML Antwort in Deinem Fehlerfall ausgesehen hat.
-----
Zitat von: rudolfkoenig schrieb am Mi, 07 August 2013 15:16Ich habe es in FHEMWEB eingebaut, es wird angezeigt, falls die Rueckgabe auf "get dev ?" analog zu set mit "unknown command XX, choose one of" anfaengt (bzw. /unknown.*choose one of /i um genau zu sein).
Das ist nicht der Fall bei folgenden Modulen, die get anbieten:
EIB FileLog CUL_HM DbLog ECMD ECMDDevice FLOORPLAN FRM_AD Heating_Control IPWE LGTV M232 M232Counter M232Voltage NetIO230B OWServer OWX POKEYS SCIVT SWAP SWAP_0000002200000003 TCM Twilight WS2000 WS300 Weather OWAD OWCOUNT OWID OWLCD OWMULTI OWSWITCH OWTHERM
...
Hab gestern ein update von 70_VIERA eingechecket, was die Funktion implementiert hat.
Zitat von: betateilchen schrieb am Mi, 14 August 2013 09:23Zitat von: rudolfkoenig schrieb am Mi, 14 August 2013 09:11Beim Pixelzaehlen auf deinem Screenshot faellt mir auf, dass dein Browser den alten Version der darkstyle.css verwendet.
Das heißt heute abend mal Browser-Cache leeren... obwohl es eigentlich gar keinen Cache geben sollte laut meiner Konfiguration. Aber ich probiers aus. Danke für den Tip.
Das hats gebracht.