erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[Jojo11]

kann mir jemand folgendes ICOn schicken?

sani_heating_boot.svg und png

die fehlen mir leider...

Schau mal im github von bgewehr nach, da habe ich es auch gefunden  Danke bgewehr!

schöne Grüße
Jo

[hyper2910]

Hat schon jemand max Komponenten Integriert?

[reichi]

Ich hab MAX Komponenten integriert aber derzeit nur die reine Temperatur-Regelung mit minimal veränderten standard-widgets (noch ohne auto, eco, boost, etc, bau ich aber bestimmt "mal").

[bgewehr]

Hallo, Leute, gestern habe ich mir weitere Design Möglichkeiten angesehn, konkret das Layout von 2ndsky aus dem knx Userforum. Es baut sehr kompakte Tabellen und die Widgets sind alle in Popups:

[oniT]

Hallo,

noch eine Feststellung. NumDisplay ist ja laut Wiki angedacht:

NumDisplay
NumDisplay arbeitet nur in eine Richting, FHEM zu Frontend. Die Werte werden ohne Umwandlung weitergegeben. Es ist dazu gedacht Zahlenwerte zu übergeben, ohne etwas zu verändern.
z.B. für Temperaturwerte

um Temperaturwerte 1:1 zu übergeben. Bei Minustemperaturen wird das Vorzeichen jedoch weggelassen. Stellt man den Converter auf Direct oder NumDirect wird das Vorzeichen mit übergeben.

Gruß
Tino

[Thomas_Homepilot]

Hallo, Leute, gestern habe ich mir weitere Design Möglichkeiten angesehn, konkret das Layout von 2ndsky aus dem knx Userforum. Es baut sehr kompakte Tabellen und die Widgets sind alle in Popups:

...Sieht echt klasse aus. Hab mir das auch mal angesehen. Die Buttons für die Rolladen müssten noch vom Button-Rahmen befreit werden - mal sehen, wie das geht. Ansonsten finde ich die von Dir ergänzten Daten (Temp, Energieverbrauch etc.) in der Raumübersicht super. Bei der Version von 2ndsky finde ich es toll, dass er den Raumnamen und das Raumicon oben im Titelmenü anzeigt. Das spart nochmals Platz...

Gruß
Thomas

[bgewehr]

Raumname im Titelmenü bedeutet aber Anpassung der base.html - also wieder ein Stück weniger updatefest!

[Thomas_Homepilot]

...stimmt. Aber das letzte Update ist sowieso sehr alt. Einmal im Jahr bin ich dazu bereit

Gruß
Thomas

[bgewehr]

Für die Buttons hat 2ndsky schon ein eigenes lbutton widget in seiner widget_visu.html angelegt. Ich hab diese bisher noch nicht übernommen!

[Thomas_Homepilot]

OK. Werd ich mir mal ansehen. Danke.

Gruß
Thomas

[herrmannj]

Raumname im Titelmenü bedeutet aber Anpassung der base.html - also wieder ein Stück weniger updatefest!

Hi zusammen,

das muss man den sv Leuten lassen, sie haben dafür mit gedacht. Die Anpassung in base.html (ich mache das bei einer speziellen root.html) kann man update fest machen wenn man die modifizierte base.html im eigenen /page Verzeichnis liegen hat.

Die template engine schaut zuerst dort nach und danach in /base, deswegen sind Anpassungen an (root, base) etc für spezielle Geräte möglich - und werden später auch nötig sein.

Mittlerweile sind wir mNn auch an einem Punkt an dem wir uns aber über das Thema sv updates tatsächlich noch mal Gedanken machen sollten. Während der Entwicklung habe ich die Jungs von sv sporadisch informiert und habe auch die Mandantenfähigkeit angesprochen.

Das fanden die auch cool und wollten das übernehmen. Die entsprechenden Anpassungen habe ich denen geschickt - seid dem dann aber auch kein feedback mehr bekommen. Insofern stellt sich jetzt wirklich die Frage ob wir das forken wollen. Wenn ja sollten wir das mMn mit Bedacht machten: folgendes Szenario: wir verändert die core files (widget.js und co) - dann kommt ein update von sv mit vielleicht neuen coolen widgets. Dann würde sich das nur noch händisch mergen lassen.

Habt ihr Ideen , Vorschläge ?

BETA ZWEI:
geht planmäßig voran. In BETA EINS waren noch viele fliegende Verdrahtungen drin, ich leg die alle schön in Dosen und unter Putz. Fertigstellungsgrad etwa 60-70%. Damit haben sich auch bereits fast alle Probleme aus BETA EINS erledigt. Die Aussteiger wegen unterbrochener Verbindungen schaffe ich überhaupt nicht mehr zu provozieren, da kommen trotzdem noch einige Sicherheitsschaltungen zu. Dann fehlen noch die "minor" Bugs, hauptsächlich in Bezug auf die converter.

vg
Jörg

[hyper2910]

Ich hab MAX Komponenten integriert aber derzeit nur die reine Temperatur-Regelung mit minimal veränderten standard-widgets (noch ohne auto, eco, boost, etc, bau ich aber bestimmt "mal").

Hi,

wie hast du die Temperatur Regelung gebaut?`

Code Auswählen Erweitern

{{ device.rtr('HZ01', 'Wohnzimmer', 'WZ_rtr_act', 'WZ_rtr_set', 'WZ_rtr_state', 'WZ_rtr_comfort', 'WZ_rtr_night','WZ_rtr_frost', 'WZ_rtr_state', 'WZ_rtr_text'  ) }}
<td></td></tr>

habe dies so gemacht.

aber die Steps bekomme ich nicht hin, welches GAD hast du wie belegt?

[herrmannj]

Hallo zusammen,

Mir ist noch was komfortables zum Thema Attribute via smartvisu verändern eingefallen:

Problem:
Attribute lassen sich zwar schalten, weil das keine events produziert bekommen die anderen smartVisu Displays nichts davon mit.

Lösung
ein dummy und ein notify in fhem:
sv schaltet die den dummy (der die anderen sv aktualisiert) und das notify setzt das attrib (pari zum dummy) auf dem device.

In den seltenen Fällen wo das schalten von Attributen überhaupt Notwendig ist lässt sich so die fhem limitation smart umschippern.

Für "disable" wird es unabhängig eine komfortable build-in Lösung geben.

vg
Jörg

[Thomas_Homepilot]

Habt ihr Ideen , Vorschläge ?

Das SV-Projekt war bis Ende 2013 sehr aktiv. Die aktuelle Version ist jedoch  über 1 Jahr alt. Hier im Forum besteht aktuell reges Interesse an dem Projekt und offensichtlich auch die Bereitschaft, das Projekt voranzutreiben. Da die SV-Jungs z. Zt. wenig motiviert scheinen bzw. vielleicht auch zeitlich enge Grenzen haben, gibt es meiner Meinung nach 3 Möglichkeiten:
1. Die SV-Jungs geben Dir Zugriff auf die Sourcen und Du übernimmst (temporär) das Projekt.
2. Wir machen getrennt weiter, bleiben aber möglichst kompatibel zu allen anderen SV-Schnittstellen. Dann können auch die Leute aus dem KNX-Forum von unseren Erweiterungen profitieren und wenn der harte Kern wieder da ist kann die Weiterentwicklung auf dem erweiterten Code aufsetzen.
3. Wir machen getrennt weiter und lassen alles, was man für fronthem nicht benötigt einfach links liegen. Dann müssen wir natürlich die >>neuen coolen Widgets<< von Hand mergen. Die Frage ist: Wie wahrscheinlich ist es, dass sooo viele neue coole Widgets kommen, dass sich diese Arbeit nicht bewerkstelligen ließe - zumal die letzten neuen Widgets auch nicht im Release gelandet sind, sondern aus dem Forum manuell eingepflegt werden müssen.
Ich glaube, dass Nr. 3 aktuell den geringsten Aufwand (Abstimmung, Test mit anderen Systemen etc.) bedeuten würde und somit in der aktuell sehr dynamischen Phase von fronthem die zielführendste Möglichkeit ist.

Gruß
Thomas

[oniT]

Hallo,

ich habe auch nochmal eine Frage zu cmd set. Mal angenommen ich möchte ein On oder Off in einen Dummy schreiben. Allerdings nicht mit

Code Auswählen Erweitern


set dummy on


in den State, sondern in ein eigenes Reading "test" mit

Code Auswählen Erweitern


setreading dummy test on


ist das möglich? Das Auswahlfeld im cmd set zeigt mir, trotz dass das Reading "test" vorhanden ist, dies nicht an. Es wird immer nur "state" zur Auswahl vorgeschlagen. Ist das Überhaupt möglich?

Hintergrund ist, ich müsste wenn ich ein Notify zum Schalten auslösen möchte nicht immer einen extra Dummy anlegen, sondern könnte diesen mit mehrere Readings füllen.

Danke

Gruß
Tino