Last call für Flug sV 2.9

[oli82]

... aber nie vom Proxy. Zudem gibt es einen "test proxy server".
Ich habe keine Informationen dazu gefunden, ohne einen Account anzulegen. Und wenn jemand so undurchsichtig kommuniziert, habe ich auch keine Lust dazu.

ja, habe da auch nicht zu Ende gelesen. Habe noch eine Lösung gefunden, teste sie aber erstmal. Evtl schaffe ich es ja noch vor dem Release.

[smai]

War das nicht immer so? Ich nutze das selbst nivht, aber zumindest die Examples sehen in 2.8 auch etwa so aus.
Ändert kannst du das inndividuell in deiner visu.css mit einer Regel für .ul-li-aside .icon, .ul-li-aside .fx-icon (wie in base.css Zeilen 228-232).

[whe]

das sieht im "master" branch dort so aus:

.ui-li-aside {
 margin: 0;
 font-size: 14px;
}

.ui-li-aside .icon {
 width: 32px;
 height: 32px;
}

und wurde in "develop" angepasst:

.ui-li-aside {
 font-size: 0.8em; /* 0.875em; */
 right: .6em !important;
}

.ui-li-aside .icon,
.ui-li-aside .fx-icon {
 width: 1.7em;
 height: 1.7em;
}

das sah m.E. vorher besser aus.

[smai]

whe ich weiss jetzt, wo es herkommt.

Im master waren nur diejenigen Icons klein, welche per basic.symbol eingefügt wurden (bzw. genauer: welche die CSS-Klasse "symbol" besassen):

base.css Zeile 856 im master:

.ui-li-aside .symbol .icon,
.ui-li-aside .symbol .fx-icon {
    vertical-align: middle;
    width: 22px;
    height: 22px;
}

Irgendwie hat das auch nicht wirklich Sinn ergeben, die einen klein und die anderen gross.
Aber ich gebe dir recht, rein optisch sind die grösseren schöner. Aber man hat halt auch weniger Platz.
Ich frage mich, ob es Sinn machen würde, dafür eine separate Klassen anzubieten (z.B. <div class="ui-li-aside micro> für die kleinen und <div class="ui-li-aside"> für die grossen Icons.

[TheMax74]

Hello
I don't know if already requested, but a MQTT driver will make integration with, for example, Node-Red very useful.

[Msinn]

TheMax74 If you use SmartHomeNG as the backend for smartVISU, you can use the existing MQTT plugin for SmartHomeNG for the integration.

[yachti]

Ich denke Flug SV2.9 Last call sollte langsam zum Start und zur Landung ansetzen. Ich würde das RTSP streaming auf den nächsten Flug verschieben. Dann haben wir Zeit für ein richtiges Design, die Implementierung und Tests. Ich denke ein Schnellschuß bringt uns nichts. Die Entscheidung liegt aber bei Dir smai
oder wie denkst Du darüber?

Gruß Michael

[smai]

Ich sehe das ebenfalls so.
Die letzten Tage war ich zwar weniger kommunikativ, dafür habe ich umso mehr programmiert.

Ich habe die Widgets auf eine komplett neue Codebasis gestellt.
Ganz nebenbei ist es mir dabei gelungen, die Aktualisierung der Widgets auf ca. einen Viertel der Zeit zu reduzieren! Damit läuft die Visu merklich flüssiger.
Ich bin noch an den letzten Feinarbeiten, werde das aber bald committen.

TheMax74 I will have a look at this, but I'm nit shure if I can implement it with release 2.9.
For the following up release I'm planning a complete refactoring of the drivers, so this could be a better time for a new driver.

[yachti]

Danke, wenn wir was testen sollen dann gib Bescheid. Wenn es eine komplett neue Codebasis ist denke ich muss ausführlich getestet werden.
Ich muss dann genau wissen was und könnte ne Checkliste erstellen

[smai]

Ja, so ist es.
Ich kann dir auch schon sagen, was zu testen ist: Einfach alles.

Da jedes Widget davon betroffen ist, könnten sich überall Fehler eingeschlichen haben.

[Tom Bombadil]

Da jedes Widget davon betroffen ist, könnten sich überall Fehler eingeschlichen haben.

Meine (nicht mit Stefan abgesprochene) Empfehlung an alle: Bitte die develop mal parallel zum Produktivsystem installieren, siehe hier oder auch hier. Die ganze Übung dauert keine Viertelstunde, und die Basis der Tester wird dadurch deutlich breiter. Bestimmt gibt's dann auch was zu Weihnachten.

/tom

[yachti]

Da jedes Widget davon betroffen ist, könnten sich überall Fehler eingeschlichen haben.

Ich hab nen Testumgebung parellel zum Produktivsystem aber kann damit halt nur widgets testen wo ich die entsprechenden items im Backend habe. Bin schon angefangen einige Konfigurationen nachzustellen von Fragen oder Problemen die in den letzten Wochen hier aufgetaucht sind soweit es mit meiner Umgebung möglich ist.
Für die nächste Version werde ich mal nen Clone machen und versuchen soweit wie möglich für alle Widgets eine reale Testumgebung herzustellen. Der Start ist aber erst ab den Weihnachtstagen umsetzbar.

[smai]

Auch wenn es nicht abgesprochen ist, teile ich die Einschätzung von Tom.

Wenn ihr so auf das Testen brennt, habe ich nun mal committed.

[Sisamiwe]

smai
Kann es sein, dass die dynamischen Icons nicht mehr funktionieren? (Bin auf der aktuellen SV2.9 develop.)
Es wird nichts mehr gerendert..

Danke fürs nachschauen.

[Sisamiwe]

smai
Ich habe noch etwas gefunden.
Verwendet man basic.stateswitch mit der Option 'icon' benötigt das mehr Pixel (zumindest in der Höhe) als basic.symbol.
Ich habe in einer Anwendung eine Kombination (Aneinanderreihung von basic.stateswitch und basic.symbol und dies führt zu einem größeren Block als nur die Verwendung einer Aneinanderreihung von basic.symbol.
Die verwendeten icons sind es nicht, das habe ich geprüft.

Also:

 {{ basic.stateswitch(id~'mode', gad_comfort, 'icon', [1,0], ['sani_heating_automatic.svg', 'sani_heating_manual.svg'], '', ['icon1', '#25ea4e']) }}

braucht mehr Platz als

 {{ basic.symbol(id~'state12', gad_comfort, '', ['sani_heating_manual.svg', 'sani_heating_automatic.svg'], [0,1], '', ['icon0', 'icon1']) }}

Würdest Du das noch korrigieren.
DANKE.