Erster Test smartVISU 2.9 mit jQuery Mobile 1.4.5

[schuma]

smai das mit dem Ausdruck "wie bei KNX üblich" war nicht böse gemeint.
ich wollte damit nur zum Ausdruck bringen, dass die Option bei so ziemlich jedem Tastsensor vorhanden ist.
Natürlich nutze ich auch bei Schaltern die Rückmeldung der Aktoren. Aber es gibt ja auch immer mal wieder Dinge die man einfach aufruft und keine Rückmeldung bekommt.

z.B. Eine Szene oder eine Logic oder einfach ein Objekt was gar kein Status Objekt besitzt. Auch bei Rolläden könnte es sinnvoll sein die einfach nach oben zu fahren und den Tastendruck nur zu bestätigen.

Das mit dem Eindrücken des Button ist so eine Sache. Klar gebe ich Dir recht, dass der Button ja in dem Moment wo man drauf drückt eingedrückt wird. Nur wenn man den Button wieder loslässt und der komplette Finger den Button überdeckt hat, sieht man nicht mehr ob der Butten wirklich gedrückt wurde. Gerade bei Telefonen von unterwegs ist das eine ärgerliche Geschichte. Weil man ja auch nicht den direkten Visuellen Kontakt mit dem z.B. Rolladen hat.
Liegt natürlich an meinen Wurstfingern... ;-)

Aber so wie Du es vorgeschlagen hast, meinte ich es ja auch. Die Option per Parameter aktivierbar machen. Ob das jetzt 3 Sekunden lang blinkt oder leuchtet, könnte man ja noch durch einen erweiterten Parameter herstellen.
0 = aus, 1 = blinken, 2 = leuchten für jeweils 3 Sekunden.

Grüße, Marc

[smai]

Ich habe das auch nicht böse aufgefasst, kein Problem. Meine Antwort war übrigens ebenfalls nicht so böse gemeint, wie es vielleicht gewirkt hat.

Da ich weiterhin icon1 nicht in jedem Fall sinnvoll finde, mein Vorschlag: Man kann entweder eine Farbe angeben oder 'blink'.

Logic ist übrigens ein gutes Stichwort, beim basic.trigger müsste das ebenfalls rein.

[schuma]

Das wäre doch super!
Vielen Dank wenn sich das Umsätzen lässt.
In dem Beispiel aus der Doku zu den internen Szenen wird diese Funktion übrigens mit einer Logik gelöst. Das könnte dann damit auch entfallen.

[ramann]

smai
Das Übersetzen funktioniert jetzt wieder. Nur in plot.html müssten noch die entsprechenden Befehle für comfortchart und rtr angepasst werden. Sonst wird nichts übersetzt. Was damit auch zusammenhängt ist, dass in den ini-Dateien für die Sprachen unter plot je 2x für label und axis verschiedene Werte angegeben sind. Hier müsste man noch eine Unterscheidung zwischen comfortchart und rtr einbauen.

Was mir noch aufgefallen ist: Bei der Verwendung von yr.no in Kombination mit einer custom.ini (übrigens eine echt gute Erweiterung!) wird die Einheit der Windgeschwindigkeit nicht in der richtigen Sprache angezeigt, da im Code der yr.no.php auf config_lang geprüft (Z 53) wird (kann ja jetzt Werte annehmen, die nicht de, en, .. sind). Hier könnte man vielleicht wie für wunderground in die ini-Dateien einen Wert lang aufnehmen und für diesen in den if-Anweisungen prüfen.

Die Einstellung Client (cookie) wird jetzt bei mir übernommen, aber leider nicht nur für die einzelnen Clients, sondern global für alle. Wenn ich auf dem PC einen Cookie setze, dann werden die Einstellungen auch auf dem Tablet übernommen und umgekehrt.

[smai]

Die Einstellung Client (cookie) wird jetzt bei mir übernommen, aber leider nicht nur für die einzelnen Clients, sondern global für alle. Wenn ich auf dem PC einen Cookie setze, dann werden die Einstellungen auch auf dem Tablet übernommen und umgekehrt.

Werden bei dir die Cookies synchronisiert (z.B. zwischen Chrome auf PC und Chrome auf Tablet)? Das habe ich nicht bedacht, so sind die Einstellungen eigentlich pro Benutzer und nicht pro Gerät.
Ist nun die Frage, ob dies Bug oder Feature ist.

Ich werde mal nachlesen, wie man das verhindern kann. Gibt sicher eine Lösung.
IP finde ich eben keine sinnvolle Lösung, um einen Client zu identifizieren. Bei DHCP kann diese ändern und wenn ich mit demselben Gerät einmal per WLAN, einmal per LAn und einmal per VPN verbinde, habe ich auch jedes Mal eine andere IP.

Das mit den Sprachen klingt alles sehr nachvollziehbar, muss ich so umsetzen.

[ramann]

Die Cookies werden nicht synchronisiert.
Ich habe aber festgestellt, wenn ich in jedem Browser, den ich verwende, den Cookie setze, dann geht es!
Sonst werden scheinbar aber nicht die globalen Einstellungen übernommen, sondern die des zuerst gesetzen Cookies.

Ergänzung1:
Bei einem Refresh von SV im Browser sind die individuellen Einstellungen bei mir wieder weg.

Ergänzung2:
Das Problem tritt bei mir nur mit aktiviertem Page cache auf.

[smai]

Das Problem tritt bei mir nur mit aktiviertem Page cache auf.

Das ist es!
Weil dies in 2.9 ja nun ein Output Cache ist, werden damit die generierten Seiten inkl. konfigurierten Werten gecached.
Entweder müssen die Seiten also je Client mit Cookie separat gecached werden, oder ich muss die Konfiguration irgendwie nachladen.

[ramann]

smai
Ich hab gerade festgestellt, dass mit den neusten Änderungen die Wochentage im UZSU-Popup bei mir mit Dienstag anfangen.
Wenn man in den html-Code schaut, ist nur die Beschriftung (label) betroffen, der Wert für input nicht.
Das liegt anscheinend an den Änderungen in base.php.
Wenn hier für Montag der Wert 1 übergeben wird (case 'l' und case 'D'),

return weekday[(val.getDay() + 1) % 7];

dann wird als Übersetzung Dienstag zurückgegeben.

[smai]

Tom Bombadil hat gestern schon sowas beim Kalender berichtet.
Das +1 ist an dieser Stelle anscheinend falsch und das % 7 wird dann auch nicht mehr gebraucht. Ist nun korrigiert.
Ich hatte dies für eine andere Stelle implementiert und kopiert, dort war offensichtlich der Wochenanfang (index 0) am Montag, hier ist er am Sonntag.

[thorschtn]

Hallo smai,

ich hab auch mal ne 2.9er Umgebung aufgesetzt und nahezu alles zum laufen bekommen. Hut ab vor Deiner Leistung, tolle Arbeit.

Lediglich die UZSU mit FHEM macht mir Probleme. Ich hatte die unter der 2.8 bereits eingebunden und wollte sie jetzt auf die 2.9 umstellen:

Der Aufruf von

{{ device.uzsuicon('fernseher.01', 'eg.fernseher.uzsu', 'Fernseher', '', '', 'text') }}

führt zu einem Fehler

No UZSU data available in item 'eg.fernseher.uzsu' for widget index-fernseher_01.

Sollte die UZSU grundsätzlich auch bereits mit FHEM laufen? Die gad ist angelegt, der Fehler tritt unabhängig davon auf, ob UZSU Daten bereits in FHEM angelegt sind. Sitzt der Fehler vor dem Bildschirm oder in der aktuellen Implementierung?

Danke & viele Grüße

thorschtn

[smai]

Hallo thorschtn

ramann hatte folgendes geschrieben:

UZSU-Plugin funktioniert bei mir im Zusammenhang mit fhem nur, wenn ich damals nötige Änderung in SV2.8 für die 5.0-Version im io_fhem.js Treiber wieder rückgängig mache.

io_fhem.js:

- 262 io.callUpdateHandler(this, value.list instanceof Array ? values : [values]);
+ 262 io.callUpdateHandler(this, [values]);

(Die Zeilenzahl stimmt wahrscheinlich nicht mehr ganz in der aktuellsten Version.)

Da ich kein FHEM habe und bisher niemand sonst sowas berichtet hat, habe ich die Änderung noch nicht gemacht.
Kannst du das mal probieren?

[thorschtn]

Hab ich probiert. Ich kann berichten, dass die UZSUs in FHEM damit offensichtlich funktionieren - bereits bestehende können angezeigt und neue angelegt werden, danke für den Tip!

Sollten sich bei intensiveren Tests noch Problem oder unerwünschte Seiteneffekte ergeben, melde ich mich nochmal, aber auf den ersten Blick siehts gut aus!

Viele Grüße

thorschtn

[smai]

Dann werde ich das gleich anpassen.

Edit: Erledigt

[smai]

Könnte man dem basic.Button und evtl. auch dem Switch, wie bei KNX üblich, eine Option "Betätigungsanzeige" hinzufügen?

Man kann entweder eine Farbe angeben oder 'blink'.

Das ist jetzt so umgesetzt, es gibt bei basic.stateswitch einen neuen Parameter 'indicator' dafür.

[smai]

Nur in plot.html müssten noch die entsprechenden Befehle für comfortchart und rtr angepasst werden. Sonst wird nichts übersetzt. Was damit auch zusammenhängt ist, dass in den ini-Dateien für die Sprachen unter plot je 2x für label und axis verschiedene Werte angegeben sind. Hier müsste man noch eine Unterscheidung zwischen comfortchart und rtr einbauen.

Ist auch erledigt.