CometVisu - (interner) Beta-Test

[makki]

Aber, hast Du wirklich "1" oder "1.xxx"?

1.001 5.001 9.001
(Kannst ja auch immer die config anschauen, wenn ich was schreibe, meine ich immer die zugängliche /visu-svn ..)

Der Ruf verhallt nicht ungehört - aber: ich nutze den Slider so, dass ich reinklicke und den über's Ende hinaus ziehe.

Geht das beu Euch nicht? Ist das unintuitiv?

Auf den kleinen geht das ziehen des Sliders ja nicht, das ist glaube ich das Hauptproblem.. selbst wenn man versucht zu klicken, scrollt man meistens unabsichtlich (hoffe das war verständlich)

Für ein "Mobile-design":
Das scrollen gehörte IMHO ganz abgeschaltet (geht ja soweit ich sah)

Hm, ich frage mich, wie man das automatisch umsetzen kann...

Ich erst Aber mal so im Ansatz: ich hab ein Design mit Widgets + minimum-size und weiss wieviele hinpassen.
While ... foreach.... (mach ein jQ-Tab + Navi-Button); so oder so ähnlich

Makki

[Chris M.]

Ich schon auch, DPT1,5,9

1, 5 und 9 sind implementiert. Aber, hast Du wirklich "1" oder "1.xxx"? Da wird jetzt streng unterschieden...

Den aufm Touch auf 0 oder 100 zu bekommen ist auch sportlich (wird nebenbei schon fast ein Featurewunsch: links neben dem Slider=0, rechts =100%)

Der Ruf verhallt nicht ungehört - aber: ich nutze den Slider so, dass ich reinklicke und den über's Ende hinaus ziehe.

Geht das beu Euch nicht? Ist das unintuitiv?

@Chris/Julian: was haltet ihr davon, das pages unterhalb einer gewissen Auflösung einfach in mehrere "Tabs" (oder whatever, was jQuery halt so hergibt) gesplittet werden ? Und das scrollen deaktiviert, Navigation ähnlich der /oldvisu.

Hm, ich frage mich, wie man das automatisch umsetzen kann...

[vlamers]

Ich hab dafür die slider von -15 bis 115. Genommen dann treff ich besser die 0. Werte unter 0 gehen eh nicht.
Oder von -15 bis 270

Gruß Volker

[luigi4711]

[...]wird nebenbei schon fast ein Featurewunsch: links neben dem Slider=0, rechts =100% [...]

Dafür !
Hatte auch schon das Problem (Gefummel) auf nem Android Handy (Samsung Galaxy S) RGB LEDs über die Slider auch wirklich aus (0%) zu kriegen.


luigi

PS: Falls zwei Buttons zu breit werden, könnte es von mir aus auch ein An/Aus Toggle Button werden.

PS2: Ähnlichen Vorschlag vielleicht auch für den Colorchooser. Der könnte evt. auch
nen 'Alles aus' Button brauchen...

[makki]

Nicht die GA (die ist egal), den Datentyp meine ich...

Ich schon auch, DPT1,5,9

Feature Complete muss es IMHO nicht sein.

Hmm, da grummelts bei mir ehrlichgesagt.. Sicher nicht Feature Complete, aber elementare Basics sollten halt machbar sein. Der erste Schuss sollte sitzen, die Erwartungshaltung ist glaube ich recht hoch..
Rolladen mit nem Slider ist halt evtl. "etwas ausgefallen" Den aufm Touch auf 0 oder 100 zu bekommen ist auch sportlich (wird nebenbei schon fast ein Featurewunsch: links neben dem Slider=0, rechts =100%)

Das hat sich zum printf-Formatstring geändert...

Stimmt, da war was, das das schon umgesetzt wurde hab ich aber wohl verpasst oder verdrängt Ist in der SVN-Demo-config gefixed (sieht einfach sonst k*** aus)

Ich stricke gerade an einem Designvorschlag für "kleine" Androids (Handys, ~3"); Die Überschrift mit dem Page-namen muss IMHO weg, die Texte viiiel kleiner..
Mit meinem N900 geht das ja aktuell halbwegs zu bedienen (das hat aber nen FF und das hat eben kein Mensch, die Zukunft von Maemo/Meego ist auch mehr als ungewiss), mit nem 7" Tablet auch halbwegs Ok; aber auf den kleinen: ehrlichgesagt bin ich da gerade ziemlich geerdet, weil es leider IMHO relativ unbedienbar ist.
@Chris/Julian: was haltet ihr davon, das pages unterhalb einer gewissen Auflösung einfach in mehrere "Tabs" (oder whatever, was jQuery halt so hergibt) gesplittet werden ? Und das scrollen deaktiviert, Navigation ähnlich der /oldvisu.
So wie jetzt macht das jedenfalls IMHO auf einem android-Smartphone (setze ich mal gleich mit iPhone/Pod, selbe Thematik) eher nicht so richtig Spass..

Makki

P.S.: Ack: keine Logikfunktionen/Workarounds in die Visu. Das mit der Laufzeit/Pos kann der Aktor oder es ist per Logik hinzufummeln (ich hab mit Markise auch selber sowas, weil geiz-ist-geil den uralt-Siemens-Aktor dafür nehmen musste.. selber schuld )

[Chris M.]

Das sehe ich auch so.

Positionsbestimmung durch Laufzeit ist eigentlich eine Aktor-Aufgabe.
Sollte der das nicht können, kann man als Notlösung(!) eine Logik-Engine verwenden.

Eine Visu hat damit nie etwas zu tun - die zeigt nur die oben bestimme Höhe an, bzw. gibt eine neue Höhe vor.

[vlamers]

Ah ok.
Da weiß ich überhaupt nix was ihr mit dem pywiregate vorhabt. Ist erst für nach der visu geplant??
Derzeit Regel ich das mehr oder weniger gut/zuverlässig über linknx.

Gruß

[netzkind]

So dass wenn ich ihm sag 20% auf --> 30s/100% * 80% = Zeit zum Zufahren; oder wenn zu 30s / 100% * 20% = Zeit zum Auffahren

Obwohl ich das gleiche Problem habe sehe ich eine Lösung nicht in der Visu, sondern in einer zentralen Logik. Also eher bei pyWiregate als bei der Visu.

Grüße,
Julian

[vlamers]

Zu den Rolladen hätte ich noch gleich einen Wunsch:

Da ich nur Rolladen Aktoren hab und keine Jalousie Aktoren:

- Ist es Möglich (und auch nicht zu aufwendig) eine Auswahl zu schaffen (Jalousie od. Rolladen Aktor)

Den Rolladen Aktor dann so zu schalten (kurz auf; lang auf; kurz zu; lang zu) das man ihm ne gesamt Fahrzeit eingibt. z.B 30s

So dass wenn ich ihm sag 20% auf --> 30s/100% * 80% = Zeit zum Zufahren; oder wenn zu 30s / 100% * 20% = Zeit zum Auffahren

Oder:

Würde auch gehen:

- 31s Zufahren und anschließend 30/100 * 20 = Zeit zum Auffahren
So könnte man die längere Fahrzeit je nach Aussentemperatur kompensieren.

(Wäre natürlich für mein Garagentor auch cool bis jetzt krieg ich nur auf oder zu)
Ist sowas möglich oder viel zu kompliziert für die Visu und eher im Logik Editor anzusiedeln?

Gruß

[Chris M.]

Eigentlich nicht, 1/5/9, das wars.. Es wirft ja auch nur den mobilen Webkit.

Nicht die GA (die ist egal), den Datentyp meine ich...

Wäre glaube ich auch ne Sache, insgesamt im zusammenhang mit Statusmeldungen sollte der Visu-client "sagen" wenn keine Verbindung/Timeout/!=HTTP 200 oder das Backend eben einen Fehler melden will

Das Thema Zuverlässigkeit, Fehlermeldung, etc. hab ich noch fest vor der öffentlichen Beta eingeplant - aber vermutlich nicht in den Release Candidate 1 (gerade beim Slider sind ein paar Bugs gefixt worden, die die teilweise unbedienbar gemacht haben. Und deren Lösung möchte ich möglichst bald ausrollen)

Addon zu "was fehlt": Rolladen/Raffstoren-Widget (ist ja auch eher ne KNX-Spezialität mit Rückmeldung, step, move usw.)

Aber erst nach der öffentlichen Beta. Es gibt keinen Grund wegen ein paar nicht vollständigen Widgets die noch weiter zu verschieben.
Ziel der öffentlichen Beta ist es, in der breite einen stabilen Eindruck zu machen. Feature Complete muss es IMHO nicht sein.
Rollladen funktioniert bei mir übrigens sehr gut mit einem Slider...

P.S.: ist mir nur vorhin nebenbei aufgefallen: entweder ich bin grad zu dämlich oder es geht mit precision=X in der aktuellen SVN gerade nichts mehr?

Das hat sich zum printf-Formatstring geändert...

[makki]

Verwendest Du vielleicht einen DPT der im transforms/transform_knx.js nicht enthalten ist?

Eigentlich nicht, 1/5/9, das wars.. Es wirft ja auch nur den mobilen Webkit.

Über den Inhalt steht da nichts - folglich dürfen wir den noch festlegen

Wäre glaube ich auch ne Sache, insgesamt im zusammenhang mit Statusmeldungen sollte der Visu-client "sagen" wenn keine Verbindung/Timeout/!=HTTP 200 oder das Backend eben einen Fehler melden will (access denied, ...) - insbesondere auf anderen Plattformen wird das interessant, welches File vergessen wurde
(jqnotify hatte ich schon erwähnt, kann man im GA-Editor bewundern )

Wie die Meldung vom Backend aussehen soll: bitte frei wählen; denke aber es ist sinnvoller zu sagen, was nicht geht als einen dämlichen 404 zurückzugeben oder so.. Meldungen für gängige Probleme sollten jetzt drin sein.

Das Backend sollte natürlich auch nicht mit einem segfault abkacheln, daran arbeite ich (vielleicht nimmt man doch so eine libcgi, statt hier selber zu frickeln, v.a. wenn man eh keine Ahnung von C hat ), aber wenn wäre es glaube ich trotzdem schön, wenn der Client auch direkt sagt, das es einen 500 gab, das verkürzt die Problemsuche deutlich..


Addon zu "was fehlt": Rolladen/Raffstoren-Widget (ist ja auch eher ne KNX-Spezialität mit Rückmeldung, step, move usw.)

Makki

P.S.: ist mir nur vorhin nebenbei aufgefallen: entweder ich bin grad zu dämlich oder es geht mit precision=X in der aktuellen SVN gerade nichts mehr?

[Chris M.]

Hmm, ich dachte ich hätte svnup & clear cache.. Geht jetzt mit r310, allerdings steht da 01/00 statt An/Aus

Verwendest Du vielleicht einen DPT der im transforms/transform_knx.js nicht enthalten ist?

@Chris: promt: "enum" in "" löst das erstere, der andere (structure_plugin.js:166) bleibt auch mit true/false ""

Ha, dafür bin ich nun nicht mehr zuständig

Bzgl. dem Android: nun, ich teste erstmal das, was man hier und heute real in Händen hält, hier 2.2.1

Das finde ich auch richtig. Man muss natürlich irgendwo die Grenze ziehen (Die britische Regierung setzt z.B. auf IE 6...), aber zumindest das aktuell gängige sollte gehen.

Zwischenfrage: wurde im CometVisu-Protokoll das Thema Fehlermeldung eigentlich behandelt? Ich fürchte das

{'error': 'SAG WAS NICHT STIMMT'}

als Response vom Backend habe ich mir nur so ausgedacht

Ein schneller Check auf SourceForge.net: CometVisu/Protocol - Open Automation zeigt, dass das Protokoll (aktuell) nur mit HTTP Codes arbeitet. Über den Inhalt steht da nichts - folglich dürfen wir den noch festlegen

[netzkind]

was haben aktuell verbreitete, beliebte Geräte drauf ? (3.0 nun sicher ned, das gibbet erst seit letzter Woche )

Im Smartphone-Bereich ausschließlich 2.2(.1). Nur für das Nexus S gibt es 2.3 (siehe Golem-News von heute zu 2.3 auf dem Galaxy S).

Tablets ist bunt gemischt, da gibt es von 1.6 ab alles - für 3.0 ist AFAIK erst angekündigt aber noch nichts erhältlich.

Grundsätzlich ist 3.0 Tablet only!

Grüße,
Julian

[StefanW]

Und um es richtig zu machen, haben wir das mit der X-Achse in GMT als Bug im tracker angelegt, da ich nun mittlerweile einen SF-Account habe, ich hoffe das war richtig so....

https://sourceforge.net/tracker/?fun...6&atid=1251141

[hugoo]

Derzeit ist es so programmiert dass:
- tooltips können über den editor an und ausgeschaltet werden
- wenn tooltips aktiv sind, wird bei Click ins Popup-Diagram dieses nicht mehr geschlossen, da sonst auf touch-devices der tooltip witzlos ist
- das Datumsformat in der Anzeige ist aus der Javascript-Methode "toLocale"; das muss nicht jedem gefallen, aber dann bräuchte man zusätzlich eine Lib um richtige Datumsformatierungen zu erlauben (vgl. date-Funktion in bspw. PHP) _und_ müsste dem User erklären wie er es einstellen muss _und_ müsste ein Feld dafür im Editor anbieten (das kleineste Problem inzwischen)
- Das Text-Format wird über die "basic.css"-Datei des jeweiligen Designs gesteuert

Grüße,
Julian

Hallo Julian,

nur zur Info, wenn ich das richtig sehe gibt es bei den Diagram noch ein grundsätzliches Problem mit der Datum/Uhrzeit-Anzeige.

Alle Diagramme zeigen die Werte mit GMT, im Tooltip (mit Datum/Uhrzeit "toLocale") ist es dann aber GMT+1 (was eigentlich richtiger wäre), was dann aber z.B. dazu führt das laut x-Achse der Wert 12 Uhr ist und im Tooltip 13 Uhr angezeigt wird.

Gruß Karl