CometVisu - (interner) Beta-Test

[vlamers]

seltsames Verhalten

Hallo,

weiß jetzt nicht genau in welchen Thread das gehört...

Folgendes Verhalten ist mir aufgefallen:

Zuerst kann ich die Visu ganz normal bedienen, kein Problem soweit (ausser das ich nur 2 mal schalten kann) Dimmer funktionieren ohne Probleme.

Wenn ich jetzt den Browser schließe (seis Pc oder Android) ist auch noch alles gut

Wenn ich aber dann angenommen 16 Stunden Später die Visu wieder aufmache.
(Angenommen es war beim 1. mal dunkel und im Flur hat der BM angesprochen und das Licht ist an)
Es ist aber jetzt Tag und der BM spricht aufgrund der Helligkeit nicht an, da er ja so parametisiert ist.
Die CometVisu scheint sich aber den alten Status zu merken bei der Sie im Browser Beendet wurd!? Und schaltet mir das Gang Licht ein, weil es ja letztes mal an war wo ich den Browser geschlossen hab...

ist das einigermaßen Verständlich was ich meine? Ist bei allen Lichtern so, wenn Sie zum Zeitpunkt des schließens des Browsers an sind, gehen Sie nächstes mal wieder an wenn ich die Visu öffne.

Der BM schaltet dann nicht mehr ab da er denkt er hat ja gar nicht eingeschalten... Dadurch bin ich erst drauf gekommen.

Sorry für den langen Text und das ständige gemosere!!!

Wenn ein Display 24/7 damit läuft dürfte es aber auch keine Probleme geben!

Gruß Volker

[makki]

Also, den FF4-Beta bekomm ich hier gerade partout nicht installiert (Aufm N900 alles kein Problem, 3 Minuten-Aktion, geht alles perfekt, wie aufm Desktop (Ok, alles ausser dem scrollen - wie aufm Desktop).. aber das war ja nicht die Frage..)

Mitm Android (Builtin-Webkit/Opera-Mini) kann ich das Problem nicht nachvollziehen.

(@vlamers: wie hiessen die im Chat erwähnten Tools, um auf dem Java-Spass einfach mal nur endlich ne simple Konsole zu bekommen? weil die einfache Konsole wäre zum Debuggen gold wert, den Debugger (adb) hab ich bisher nur mit der VM am laufen [mag auch an meinen ziemlich derben China-Geräten liegen aber die sind halt jetzt grad da])

@Chris: bzgl #3204682: was soll man machen? Ich bin relativ ratlos, der Webserver sagt ja ggfs.&sofort das es (not/)modified ist, nur wenn der Browser nicht frägt
Also mod_expire, das hilft aber auch erst viel zu spät - ausser man lädt alles & immer (was nun aber wirklich keine Option ist, weil auf den mobiles ist das mit Cache schon jetzt grenzwertig "schnell").. Julian hat da IMHO recht, wir müssen trotzdem irgendwie aus der Nummer schadfrei rauskommen..
Ich glaube der Ansatz mit anhängen einer Rev-ID (irgendein dummy, Zeitstempel des starts?) könnte da glaube ich eher klappen: dem server ists bei statischen Files ja total egal, der sagt trotzdem 304 wenn nicht geändert, aber der Client wird quasi gezwungen zu Fragen.

Makki

*P.S.: Ich bin wirklich totaler Android-Neuling aber versuche mich gerade - eher zwangsweise - damit anzufreunden, weil das mit dem Maemo/Meego wird wohl jetzt nichts mehr werden nachdem M$ Nokia mit ein paar Milliarden bestochen hat und der Ex-MSler den Chefposten übernommen hat.. ausser für Freaks..
Und am Ende des Tages geht es darum, was Anwender im Feld haben - und das sind dann wohl wie es aussieht druid oder iGitt (was ja vom Browser her praktischerweise fast dasselbe ist)
Weil der Windows-Mobile-Käse wird 200% sicher auch im 10. Anlauf kläglich scheitern, die letzte dessen Aktion hat halt nur offenbar vorher leider Maemo/Meego ins bereits geschaufelte Grab geschubst, weil ohne einen einzigen Hersteller wird das nun halt auch nichts..
Nokia hat sich damit mittelfristig IMHO auch den letzten Sargnagel reingehämmert aber das ist in dem Kontext letztlich egal: ich hätte die CometVisu gerne auf allen gängigen Endgeräten am laufen, welche auch immer das sein mögen

[vlamers]

So hier nochmal zum angucken, da ich das Gefühl hab das ihr ihr nicht ganz versteht was ich meine:

MyDrive - Your free online storage

User: KNXUF@vlamers
PW: KNXUF2010



Gruß

[vlamers]

Sind die Plugins aktiviert

Hi,

ja das plugin ist aktiviert,

- also noch optionale Buttons für day/week/month/year

Das wäre spitze, hab schon mit dem gedanken gespielt das Seitenweise Aufzuteilen (Day, Week, Month,Year), aber Button wäre um einiges besser!

Mit der neuen Version aus der SVN ist die Rot-Grün schwäche verschwunden
Leider lässt sich jeder Switch immer nur noch 1 mal an-> ausschalten. Slider und diagramme sind kein Problem. Werde mal das Android meines Handys Überprüfen...
Auf dem PC ist es kein Problem da klappt alles wunderbar!

Gruß Volker

Edit:
Vorläufig nur im Miren-Browser, und im Dolphin Browser
Orginal Android Browser geht.
FireFox Beta Android geht nicht (stürzt ab)

Edit2:

- orginal Browser geht "manchmal"; Miren und Firefox gehen nicht. woran das "manchmal" liegt konnte ich noch nicht feststellen.... Hab schon 2 versch. Rom´s durchprobiert. Ich kann jeden schalter an und ausschalten, und dann kann ich ihn gar nicht mehr bedienen. Dann mit dem nächsten switch dasselbe usw.? Die switches gehen erst wieder nach löschen der Daten (Cache, Cookie)

[makki]

Bitte als Feature Request eintragen, sonst ist's nächste Woche wieder vergessen...

Done..

Wer sieht dieses Problem und wo?

Hier kein Problem.

Der colorChooser wird vom Editor zur Zeit nicht wirklich unterstützt. In der aktuellsten Demo-Config habe ich das Widget wieder gefixt - und genau der funktioniert bei mir.
=> Bitte mal testen.

Geht wieder, war wohl nur die XML-Syntax (siehe Demo ?config=mobile)

(Flot/diagram)

Aber, zu klären wäre dann:

Alles interessante Fragen
-> Ich plädiere erstmal für ein Popup das den verfügbaren Schirm füllt und fertig. Die Inline-Variante würde ich persönlich nicht überpriorisieren, weil IMHO eh trotzdem immer zu klein; mein wunsch wäre eher ein Popup mit oder ohne preview, wo der aktuelle/letzte Wert in der Übersicht textuell angezeigt wird (aber das ist jetzt vermutlich wieder stark geschmackssache, also eher ein sep. Widget!)

Etwas ausgeholt, man sollte da auch an das erhoffte "Endprodukt" denken:
Mit
- auswählbaren Datenquellen (ok, da ist diskutabel ob das wirklich was für die Frontend-Visu ist..)
- Zooming (dahinter müsste dann ein neuer rrdfetch stattfinden, damit das rrdtool auch granuliertere Daten liefert!) - das dürfte aber mit den realisierten Tooltips kollidieren
- also noch optionale Buttons für day/week/month/year
Weil fix vordefinierte "series" werden auf Dauer nicht reichen..
Und dann kommt sicher jemand, der zwei Y-Achsen oder Stacking (für energieverbräuche sicher gut)

Was ich damit sagen will: ich glaube man sollte da nicht allzuviele Hacks einarbeiten (ich scheitere schon daran, die Höhe aufm Druiden zu fixen*), weil es warten noch 10 quasi fast fertige Features..

Makki

*Aufm Andriod-eigenen Browser gehen die flot ganz oben auf (also muss man ggfs. hochscrollen) und im Opera-mobile gehen die diagram-popups garnicht - im Opera-mobile-simulator (also dem mit der Javascript-console) - aufm Desktop gehts natürlich - ich forsche da aber weiter, bin noch blutiger Android-anfänger.. (warum weiss der geneigte Leser auch, der Grund beginnt mit J)

[Chris M.]

Bei inline Diagrammen ist es das selbe.

Hast Du auch das Diagram-Plugin aktiviert? (Geht nur per Text-Editor, nicht per online Editor):

    <plugins>
      <plugin name="colorchooser"/>
      <plugin name="diagram"/>
    </plugins>

Und wenns dafür stimmen gibt: Featurewunsch: bei allen Widgets die nur eine Funktion aufrufen (also alles ausser slider): egal wo man im Widget-Rahmen drückt: machen. (also beispiel switch: egal ob man auf den Text oder den An/Aus-Button drückt: toggeln.. dicke daumen auf einem Smartphone..)

Bitte als Feature Request eintragen, sonst ist's nächste Woche wieder vergessen...

Ich hab seit 311 das Problem das RedGreen und GreenRed gehn nicht mehr gehen. Steht bloß An/Aus da... woran könnte das liegen?

An einem jetzt behobenen Fehler...

Mit der neuesten Version aus der Svn kann ich jeden Switch nur noch einmal bedienen (einmal an einmal aus) danach --> Cache leeren um sie wieder bedienen zu können. Am android, ohne standby, auch nach 5 min.

Hm, kann ich am FF nicht nachvollziehen.
Wer sieht dieses Problem und wo?
(Und bitte einen Bug-Report in SF schreiben, sonst wird's auch vergessen...)

Weiterhin habe ich gestern Abend mal versucht, RGB-LEDs über die Visu anzusteuern. Mit den drei einzelnen Slidern hat das sehr gut geklappt, allerdings ging es über den Colorchooser nicht (der Colorchooser hat sich auch nicht verändert, wenn ich über die Slider die Farbe eingestellt habe). Was mir dabei noch aufgefallen ist, er behält, wenn man die Einstellung im edit-Mode anschaut, die Gruppenadressen der jeweiligen Farben nicht, aber im xml sind sie eingetragen. Mache ich da was falsch oder ist das evtl. noch ein Bug?

Der colorChooser wird vom Editor zur Zeit nicht wirklich unterstützt. In der aktuellsten Demo-Config habe ich das Widget wieder gefixt - und genau der funktioniert bei mir.
=> Bitte mal testen.

Keine Ahnung ob machbar, aber läßt sich denn Größe des Widgets und Größe der
eingebetteten Grafik ermitteln? Falls eine Seite der Grafik > als die des Widget, Grafik
entsprechend kleiner skalieren, so dass sie reinpasst??

Ja, dass sollte machbar sein.

Aber, zu klären wäre dann:

• soll nur skaliert werden?
• oder soll dann per Klick auf die skalierte Grafik ein Popup mit der unskalierten geöffnet werden? Was ist, wenn auch die nicht auf den Bildschirm passt?
• Wie soll mit den vom User angebbaren Bildgrößen umgegangen werden, wenn die nicht auf den Bildschirm passen?

[StefanW]

...bei allen Widgets die nur eine Funktion aufrufen (also alles ausser slider): egal wo man im Widget-Rahmen drückt: machen.

Im Prinzip bin ich auch dafür, nichts ist schlimmer als eine schwer bedienbare Visu, weil man auf kleinen Devices den Punkt nicht trifft.

Anmerken möchte ich, dass die beiden Touch-Technologien "resistiv" und "kapazitiv" unterschiedlich gut Auflösen in der Praxis. Wenn nun das Touch-Feldes eines Widgets zu groß ausfällt, insbesondere wenn das nächste Widget-Feld relativ nah benachbart ist, besteht bei den kapazitiven Touch die Gefahr, dass schwerer unterschieden werden kann, ob nun das eine oder das andere Element betätigt wurde.

Ist nur meine theoretische Einschätzung. Mir fehlt die tatsächliche Erfahrung damit und ich habe auch keine kapazitiven Devices zum Testen hier.

Stefan

[luigi4711]

Eine Alternative wäre es, im Widget-Dialog die Option anzubieten, dass das Widget einfach doppelt so breit ist.

Was ist denn der Wunsch der "Community"?

Ich denke mit einem doppelt breiten Widget wäre schon mal viel geholfen.

Was ist die beste Lösung?

Keine Ahnung ob machbar, aber läßt sich denn Größe des Widgets und Größe der
eingebetteten Grafik ermitteln? Falls eine Seite der Grafik > als die des Widget, Grafik
entsprechend kleiner skalieren, so dass sie reinpasst??

Wäre aber für mich etwas, das ganz klar irgendwann später angegangen werden kann.

...allerdings ging es über den Colorchooser nicht...

Mit dem hab ich auch noch so meine Probleme. Dachte schon, es liegt an mir und
ich hätte die Konfig verbeutelt. Ich glaub ich schau doch noch mal rein und versuche
mal rauszufinden was da wie funktioniert / nicht funktioniert.

luigi

[christian523]

Hi Chris,

den Vorschlag von Makki

Zitat von makki
Und wenns dafür stimmen gibt: Featurewunsch: bei allen Widgets die nur eine Funktion aufrufen (also alles ausser slider): egal wo man im Widget-Rahmen drückt: machen. (also beispiel switch: egal ob man auf den Text oder den An/Aus-Button drückt: toggeln.. dicke daumen auf einem Smartphone..)
Was meinen andere?

fänd ich auch sehr gut.

Weiterhin habe ich gestern Abend mal versucht, RGB-LEDs über die Visu anzusteuern. Mit den drei einzelnen Slidern hat das sehr gut geklappt, allerdings ging es über den Colorchooser nicht (der Colorchooser hat sich auch nicht verändert, wenn ich über die Slider die Farbe eingestellt habe). Was mir dabei noch aufgefallen ist, er behält, wenn man die Einstellung im edit-Mode anschaut, die Gruppenadressen der jeweiligen Farben nicht, aber im xml sind sie eingetragen. Mache ich da was falsch oder ist das evtl. noch ein Bug?

Viele Grüße
Christian

[makki]

Sehr gut!
Nach dem Aufwachen sollte es deutlich schneller gehen (~5 Sek, wenn Du länger als 60 Sek geschlafen hast)

Nee das dauert mitm Opera mobile aufm Android im mittel 30 sek.. Ich versuche das mal am Desktop zu simulieren, weil ich da keine JS-konsole hab (der XHR müsste doch nen Fehler werfen?)

Was fehlt wo? (Bzw. wie kann ich das nachstellen?)

.diagram_preview glaube ich (oder es ist nur bei mir verhunzt..)
-> Design pure in die config, da kommen keine previews (?config=pure fürn Schnelltest)

Überschrift weg sollte professionell per "display:none" gehen.

Klingt besser, erledigt

Eat your own dog food, sagt der Engländer

Jep..

Die Rot-Grün-Schwäche seit einem der letzten 3 svn up kann ich bestätigen, styling= scheint nicht mehr zu tun.

Makki

[Chris M.]

Watchdog: scheint zu funzen

Sehr gut!

Auf dem Smartphone dauerts aber indeed teils knapp 60 sek. nach dem aufwachen, bis sich wieder "was rührt"

Nach dem Aufwachen sollte es deutlich schneller gehen (~5 Sek, wenn Du länger als 60 Sek geschlafen hast)

Bei einem Netzwerk-Ausfall dagegen könnte es zum Worst-Case von 65 Sekunden kommen

(eher sekundär aber im css des Design pure fehlt übrigens IMHO was für den preview? geht nur wenn man im design discreet aufruft und dann auf pure wechselt)

Was fehlt wo? (Bzw. wie kann ich das nachstellen?)

Ich hab heute mal versucht sowas wie ein 3"-taugliches Design/config (Kopie von pure, nur die Schrift ist ein px keliner und die Seiten-Überschrift laienhaft mit 0px getilgt) zusammenzubauen: hier (userasswd321@.. geht irgendwie nicht immer, also lieber eingeben)

Muss ich mir noch mal genauer ansehen. Überschrift weg sollte professionell per "display:none" gehen.

@Chris: vielleicht magst Du mal gucken, auf der page LEDs wird bei zweispaltig nach rot ein "leerfeld" eingefügt (??), untereinander stimmts..

Mal schaun.

Und wenns dafür stimmen gibt: Featurewunsch: bei allen Widgets die nur eine Funktion aufrufen (also alles ausser slider): egal wo man im Widget-Rahmen drückt: machen. (also beispiel switch: egal ob man auf den Text oder den An/Aus-Button drückt: toggeln.. dicke daumen auf einem Smartphone..)

Was meinen andere?
Hier kann jeder mit Meinungen helfen - auch wer nicht programmiert...

P.S.: Ich mache seit ein paar Wochen den "CometVisu-hardcore-Test", das hüttchen wirklich ausschliesslich statt HS-Client/HSAV damit zu bedienen (PC, Netbook, N900, Android phone+tablet, N800) und da kommen im Alltagsbetrieb halt die sonst unischtbaren hässlichkeiten wie z.B. dicke daumen zu Tage.. Da ist aber die Realität, der man sich IMHO damit stellen muss.

Eat your own dog food, sagt der Engländer

Meine beiden Touchs + PCs laufen auch nur mit der CometVisu (aktuell der SVN-Stand, da doch ein paar wichtige Bugs zum letzten Release behoben sind. => Es wird Zeit für den ersten Release Candidate...)

[vlamers]

Die Funktion für die dicken Daumen find ich gut hab selbst 2 davon.

Ich hab seit 311 das Problem das RedGreen und GreenRed gehn nicht mehr gehen. Steht bloß An/Aus da... woran könnte das liegen?

In der Demo_config gehen sie auch nicht. auf 3 Computern und 1 Handy getestet. Die config sieht aber passabel aus!? und in der css dürfte es auch passen!?

Einzigste bei dem ich mir nicht sicher bin: braucht das norepeat in der css nicht ne eigene Zeile bzw durch irgendwas von dem center center getrennt??

War aber auch die einzigste idee die ich dazu hatte
Bei BluePurpleRed ist zumindest die Schrift "Purple"

Gruß

Edit:

Achja Cache wurde geleert.
Hab während den Versuchen auch mal das komplette visu verzeichniss entfernt und aus dem svn neu geladen. Auch eine neue config datei erstellt. alles ohne Erfolg...

Edit2:
Mit der neuesten Version aus der Svn kann ich jeden Switch nur noch einmal bedienen (einmal an einmal aus) danach --> Cache leeren um sie wieder bedienen zu können. Am android, ohne standby, auch nach 5 min.

[makki]

Watchdog: scheint zu funzen
Auf dem Smartphone dauerts aber indeed teils knapp 60 sek. nach dem aufwachen, bis sich wieder "was rührt" (nach 8h pth[reads] ist da im Kopf aber grad kein Platz mehr für recherchen oder gar bessere Ideen )
Bei kurz gehts aber einwandfrei (auch ohne Watchdog), hier muss ich aber auch noch die Spezialitäten von Android (mit/ohne Opera - ist ja wohl usus da) kennenlernen.
Auf meinem N900 mit FF geht das alles irgendwie immernoch viel flauschiger, aber das ist eben nicht wirklich relevant/die Messlatte..

Flot: ja, ich hab mich da ja auch schonmal mit gar wenig Erfolg versucht (eher sekundär aber im css des Design pure fehlt übrigens IMHO was für den preview? geht nur wenn man im design discreet aufruft und dann auf pure wechselt)

Ich hab heute mal versucht sowas wie ein 3"-taugliches Design/config (Kopie von pure, nur die Schrift ist ein px keliner und die Seiten-Überschrift laienhaft mit 0px getilgt) zusammenzubauen: hier (userasswd321@.. geht irgendwie nicht immer, also lieber eingeben)

@Chris: vielleicht magst Du mal gucken, auf der page LEDs wird bei zweispaltig nach rot ein "leerfeld" eingefügt (??), untereinander stimmts..


Und wenns dafür stimmen gibt: Featurewunsch: bei allen Widgets die nur eine Funktion aufrufen (also alles ausser slider): egal wo man im Widget-Rahmen drückt: machen. (also beispiel switch: egal ob man auf den Text oder den An/Aus-Button drückt: toggeln.. dicke daumen auf einem Smartphone..)

Makki

P.S.: Ich mache seit ein paar Wochen den "CometVisu-hardcore-Test", das hüttchen wirklich ausschliesslich statt HS-Client/HSAV damit zu bedienen (PC, Netbook, N900, Android phone+tablet, N800) und da kommen im Alltagsbetrieb halt die sonst unischtbaren hässlichkeiten wie z.B. dicke daumen zu Tage.. Da ist aber die Realität, der man sich IMHO damit stellen muss.

[Chris M.]

dass eine embedded Grafik [...] über ihren Bereich hinaus gehen.

Also Lösung hatte ich mir ausgedacht, dass nach einem Resize (+ Initial nach dem die Seite zum ersten mal geladen wurde) alle Widgets durchgegangen wird und wenn deren Inhalt zu groß ist, wird das Widget einfach auf ganze Bildschirmbreite gesetzt (d.h. bei "pure" die Widget-Bereite verdoppelt).

Aber: ein erster Check hat gezeigt, dass dann die Performance des Browsers beim Resize sehr niedrig ist...

Eine Alternative wäre es, im Widget-Dialog die Option anzubieten, dass das Widget einfach doppelt so breit ist.

Was ist denn der Wunsch der "Community"?
Was ist die beste Lösung?

[Chris M.]

Festhalten wollte ich folgendes Verhalten [...], dass [...] ein inline Diagram über ihren Bereich hinaus gehen.

Tja, das ist tricky.

So wie ich das die letzte Stunde nachvollziehen konnte, scheint man zwei Möglichkeiten zu haben:

1. Man lässt Flot die breite automatisch bestimmen (per null und nicht per "auto" wie es aktuell fälschlicher Weise der Fall ist)
2. Man gibt die Breite in Pixeln einfach selbst vor.

Behebe ich den Fehler mit dem "auto" bei 1., dann macht Flot einen wahnsinnig breiten Rand auf der linken Seiten - was fast so hässlich ist, wie die aktuelle Lösung.
Und Lösung 2. ist keine Lösung, da ich nicht pauschal weiß, wie breit die Labels sein werden (und der User kann auch keinen richtigen Wert angeben, da dieser je nach Device unterschiedlich sein kann...)

=> Ich werde das ganze Diagramm noch etwas nach rechts verschieben, eine wirkliche Lösung ist das nicht. Dafür bräuchten wir wohl eine neue Flot Version - die es aber nicht gibt...