Last call für Flug sV 2.9

[schuma]

[USER="38027"]
Stell doch in deinem GIRA-Gerät einfach das Status-Format auf "KNX-Konform", dann funktioniert der normale RTR. Ich möchte in der smartVISU nicht ein proprietäres Format implementieren.

Ja, das stimmt. Aber es gab da irgendein Problem unter den Gira Sensoren bei KNX-konform. Weiß es aber nicht mehr so genau. Ist schon lange her wo ich das mal eingebaut habe....
Wenn ich mal Zeit habe, werde ich das noch mal versuchen nachzuvollziehen.
Ich lasse das erstmal so bei mir...

Am WE mache ich mich dann mal an die Example2KNXD.

[Steph]

Ich verwende "wunderground" als Wetterdienst.
Wie schon gesagt. Ein Druck auf F5 richtet es grossteils, jedoch fehlt jetzt noch das Hauptbild.

Bei mir funktioniert in der aktuellen Develop die Anzeige vom Wetterdienst und die Uhrzeit stimmt auch immer, allerdings wird das Datum nicht aktualisiert!

[smai]

allerdings wird das Datum nicht aktualisiert!

Ja, das dürfte in der Tat so sein. Im Code finde ich jedenfalls keinen Hinweis für eine Aktualisierung. Ich schau mir das an.

[smai]

1.) Das Datum aktualisiert sich nicht automatisch

allerdings wird das Datum nicht aktualisiert!

[schuma]

Arbeit mit dem Template Checker:

Aus: {{ basic.float('wohnen_temperatur', '0/0/4/9.xxx', ' °C') }}
wird: {{ basic.print('wohnen_temperatur', '0/0/4/9.xxx', ' °C') }}
Da habe ich dann erst einmal '°' von gemacht.

Es wäre gut, wenn auskommentierte Stellen nicht berücksichtigt werden würden.
Sonnst hat man in jeder Seite in Zeile 6 einen Fehler.

Example2.knxd:
Ich habe das jetzt so wie Du gesagt hast, mit dem Template Checker gemacht. Ich habe die vorgschlagenen Änderungen relativ stumpf so übernommen.
Allerdings habe ich da einiges auch nicht richtig verstanden, so dass mir nur ein einfaches ersetzen übrig blieb.
Da sind auch eine Handvoll eigener Widgets drinne die ich auch auf den neueseten Stand gebracht habe.

Generell würde ich evtl. von diesen kompletten Beispielen abstand nehmen. Das Nachpflegen auf einen neuen Stand beinhaltet bestimmt noch mehr als nur stumpf die neuen Widges zu übernehmen.
Da werden z.B. auch "eigene" Widges benutzt, die im Master ja nicht vorhanden sind (widget_rtr_small.html, widget_shutter.html, widget_shutter_small.html) Die jetzt aber nachgepflegt werden müssen.
Dann haben einige Aufrufe in Widges keine Eingangs-Adressen ist das so gewollt?
Wenn nicht, kann ich nicht nachvollziehen welche adressen da jetzt in Frage kämen.

Würde sich hier nicht EINE Seite mit allen Möglichkeiten (Master-Widges) in einer relativ sinnvollen Anwendung besser machen?

Hier die neue Example2.knxd
example2.knxd.zip

[Hochpass]

Und du wolltest nivht erst mal die vorwngehenden Beiträge lesen?
Wende dich vertrauensvoll an Mozilla. Ich habe leider keine Möglichkeit gefunden, deren neusten Unfug zu korrigieren.

Ich hab mir zwar einen eingefangen. Aber ich versuchs nochmal.
W10 Edge zeigt es korrekt an. Chrom auf nem Galaxy4 xcover aber nicht. Liegt das wirklich am Firefox?

[schuma]

Eine Sache noch für das Finale....

Könnte man noch das aktuelle Iconset mit übernehmen?

[schuma]

Ich hab mir zwar einen eingefangen. Aber ich versuchs nochmal.
W10 Edge zeigt es korrekt an. Chrom auf nem Galaxy4 xcover aber nicht. Liegt das wirklich am Firefox?

Das Problem liegt lediglich an der Breite des Eingabefeldes. Wird das größer, sieht man auch wieder alles.

Also in der base.css folgendes:

.uzsuTimeInput, .uzsuTimeMaxMinInput, .uzsuTimeOffsetInput, .uzsuValueInput{
    width: 6ex !important;
    padding: 0.1em !important;
}

ändern in:

.uzsuTimeInput, .uzsuTimeMaxMinInput, .uzsuTimeOffsetInput, .uzsuValueInput{
    width: [MARKIEREN]10[/MARKIEREN]ex !important;
    padding: 0.1em !important;
}

Grüße, Marc

[Hochpass]

Eine Sache noch für das Finale....

Könnte man noch das aktuelle Iconset mit übernehmen?

Neee
https://knx-user-forum.de/forum/supp...80#post1149380

[schuma]

smai Wenn das mit dem example2 so in Ordnung ist, würde ich mit dem example3 weitermachen.

[schuma]

Ich habe da noch drei Probleme in der UZSU gefunden:

Von diesen Einträgen lässt sich nur der erste (80) ausführen. Für den zweiten (100) wird kein Scheduler Eintrag erstellt.
Die beiden Einträge sind beide Expert-Sonnenuntergang Einträge. Lediglich die Offsetzeit weicht ab.
Der Sinn der Einträge: Sonnenuntergang +5 Minuten Rolladen auf 80%, Sonnenuntergang +22 Minuten Rolladen auf 100%.

image2.png

Kann es evtl. sein, da beides sunset Einträge sind und sich nur durch die +Zeit (Offset) unterscheiden, der zweite Eintrag nicht ausgewertet wird da er evtl. für die UZSU der gleiche Eintrag ist (ohne Beachtung der offset Zeit)?

2.
Wenn man das Telefon hochkannt hat, wird der Expert Button nicht mehr angezeigt. Quer geht natürlich:
image1.png
3. Unter Safari ist das Popupfenser auch noch etwas in der Breite zu klein. Beim Erscheinen der Bildlaufleiste (drücken des Expert Knopfes bei genügend Einträgen) wird der "entf" Button durch die Bildlaufleiste umgebrochen.
image3.png

[smai]

Von diesen Einträgen lässt sich nur der erste (80) ausführen. Für den zweiten (100) wird kein Scheduler Eintrag erstellt.

Wird auch nur der erste gespeichert oder wird er nur nicht ausgeführt?
Da ich es mit dem Offline-Treiber nicht nachvollziehen kann, würde ich eher auf einen Bug im Plugin von SHNG tippen als auf das Widget.

Wenn man das Telefon hochkannt hat, wird der Expert Button nicht mehr angezeigt.

Das scheint gewollt zu sein:

@media screen and (max-width: 625px){
    .uzsuRowExpert, .uzsuRowHoliday, .uzsuRowCondition, .uzsuRowDelayedExec, .uzsuCellExpert{
        display: none;
    }
}

Wohl weil auf einem solchen Bildschirm zu wenig Platz für eine sinnvolle Bedienung ist. Vielleicht kann Orion etwas genaueres zu den Beweggründen sagen.

Unter Safari ist das Popupfenser auch noch etwas in der Breite zu klein. Beim Erscheinen der Bildlaufleiste (drücken des Expert Knopfes bei genügend Einträgen) wird der "entf" Button durch die Bildlaufleiste umgebrochen.

Gleiches Verhalten wie unter Firefox ab 57, leider habe ich keine sinnvolle Lösung gefunden, bei der das Design responsive bleibt. Ich nehme gerne Ratschläge an.

W10 Edge zeigt es korrekt an. Chrom auf nem Galaxy4 xcover aber nicht. Liegt das wirklich am Firefox?

Ich füge mich den Standardverstössen der Browser und mache das Feld breiter (das ist ja wie früher mit IE). Im Standard steht nirgends, dass die Schriftart aus CSS ignoriert werden soll, ich habe extra nochmal nachgelesen.
Chrome 63 unter Windows macht es übrigens richtig.
Der Nachteil ist halt, dass das Feld dann in konformen Browsern viel zu breit erscheint.

[schuma]

Wird auch nur der erste gespeichert oder wird er nur nicht ausgeführt?

Im Scheduler ist nach dem Ausführen des ersten Eintrags (80) der übernächste gespeichert.
Der Eintrag 100 erscheint also nicht im Scheduler (Geprüft mit dem Backend). Wird also nicht gespeichert. Und dem entsprechend auch nicht ausgeführt.

Gleiches Verhalten wie unter Firefox ab 57, leider habe ich keine sinnvolle Lösung gefunden, bei der das Design responsive bleibt. Ich nehme gerne Ratschläge an.

Wenn Du mir sagst, wo ich das Fenster breiter machen kann, teste ich mal um wieviele px es sich handelt. Wenn es nur 2-3 sind, kann man da ja evtl. einen Kompromiss eingehen.

Der Nachteil ist halt, dass das Feld dann in konformen Browsern viel zu breit erscheint.

Es würden auch 9ex reichen. Das wäre dann vielleicht ebenfalls ein Kompromiss.

[smai]

Im Scheduler ist nach dem Ausführen des ersten Eintrags (80) der übernächste gespeichert.
Der Eintrag 100 erscheint also nicht im Scheduler (Geprüft mit dem Backend). Wird also nicht gespeichert. Und dem entsprechend auch nicht ausgeführt.

Aber wird er im Item gespeichert?
Also wenn du die Seite in der smartVISU aktualisierst (F5) und das Popup erneut öffnest, ist dann die Zeile noch da?
Falls ja, dürfte es am Plugin liegen. Der Eintrag wäre dann korrekt vorhanden, aber er wird beim erstellen des Schedules nicht berücksichtigt.

Wenn Du mir sagst, wo ich das Fenster breiter machen kann, teste ich mal um wieviele px es sich handelt. Wenn es nur 2-3 sind, kann man da ja evtl. einen Kompromiss eingehen.

Da liegt ja das Problem: Ich weiss es nicht. An sich müsste sich die Breite das Fensters dem Inhalt anpassen.
In Chrome, IE und Edge geschieht dies auch, wenn die Scrollbar da ist.
In Firefox und Safari bleibt aber das Fenster bei Erscheinen der Scrollbar unverändert, so dass der Inhalt dann zu wenig Platz kriegt.

Es würden auch 9ex reichen.

Jup, habe ich auch so gesehen. Ich füge noch ein text-align: center hinzu, dann ist es nicht mehr ganz so störend.

[schuma]

Der Eintrag wäre dann korrekt vorhanden, aber er wird beim erstellen des Schedules nicht berücksichtigt.

OK, dann melde ich das noch mal im SHNG Forum.

War das mit dem Example2 ok? Dann würde ich mit 3 weiter machen.