Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ich glaube hier müssen wir uns entscheiden, für wen das "einfach" sein soll. Man könnte ja auch einfach ein attribute "option" einführen. Beim colorChooser wird das für die Farbe "r", "g", "b" verwendet, hier dann für "info" und "actor".
Die Idee mag ich - grundsätzlich. Was zu klären wäre, ist dass hier die Datenstruktur sauber bleibt, d.h. dass nicht mehrere Informationen gleichzeitig in dieses Universal-Attribut geschrieben werden. (Nach Datenbank-Theorie ganz böse...)
Wird uns auf absehbare Zeit ein Attribut reichen?
Ich schätze ja. Dann würde ich das einfach "type", "variant" o.ä. nennen ("option" finde ich nicht so gut, da es hier ja keine Option der Adresse ist, sondern deren Art festlegt)
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Ich schätze ja. Dann würde ich das einfach "type", "variant" o.ä. nennen ("option" finde ich nicht so gut, da es hier ja keine Option der Adresse ist, sondern deren Art festlegt)
Da würde ich für "variant" plädieren, weil du "type" ja schon für "text", "2d" und "3d" verwenden willst. Auch wenn das nicht direkt kollidiert, fände ich der Übersicht wegen verschiedene Begriffe besser.
Erster Teil wurde vorhin commited (jnotify-Statusbar statt alert, ich finds erheblich weniger "intrusiv"); ich hoffe ich hab nix kaputtgemacht
Geht sicherlich eleganter und schöner (das komplette jQuery-UI CSS müsste sicher nicht sein aber statt rausfriemlen nimmt man sowas komplett denke ich)
Ein Teil des RRD-holens war auch schon mit drin, das was man unabhängig eh braucht. Der Rest hab ich nicht commited, weil halb unfertig und gedanklich auch nicht ganz durch..
Was tun? Ich bin da gar unschlüssig..:
1a) Ein weiteres Attribut zu address. So hab ichs jetzt angefangen weil erscheint mir auch am sinnigsten.
Im Endeffekt geht es um GA+RRD die meist eh "zusammengehören"; ich stelle mir wiegesagt sowieso als zusätzliches info_diagram -Widget eine (oder mehrere) Wertanzeige + Diagramm-popup bei klick vor.
address/address transform sollten dann aber nicht mehr mandatory sein bzw. weiterhin möglich das preview statt dem (KNX-) Wert anzuzeigen. Weil es könnte ja auch die USV sein..
Gedanklich passt das aber garnicht zum ursprünglichen Sinn von multi-address, ist mir auch klar (ist ja primär für hörende GA's)
1b) Ein "klon" von address, address_rrd, selbiger multiedit ?
-> Das knickt natürlich die aktuelle config beides komplett, gehe aber davon aus das mehrere rrd= Attribute im jetzigen diagram_* eh nicht so richtig erlaubt sind.
-> Hat aber den Vorteil das es vermutlich sauberer ist und man auch noch weitere Attribute/Wert einfach hinzufügen kann. (Farben der Linien; gehört zwar vermutlich wieder eher ins CSS aber..)
2a) wäre mehrere rrd-Attribute, gehen tuts aber ist das "gut"?
Zum Rest halte ich mich Meinungsfrei, bin froh da durchgestiegen zu sein (wenn die 2h nicht wären, bis man mal drin ist.. hoffte da heute eigentlich weiterzukommen aber..)
Andere Sache: meine Slider zappeln schon wieder fürchterlich, ich *glaube* das ist neu und ich fühle mich unschuldig..
Szenario: Slider, 1 Dimmwert-GA, 1 Rückmelde-GA (readonly) -> es wird ständig geschrieben (damit ständig gelesen), zwar eine gute Performance-Demo aber...
Falls kein Einzelschicksal mach ich nen Bug auf und falls nicht nachvollziehbar: in der Demo /visu-svn "Terasse Spots Dimmwert" und Terasse Spots Dimmwert Status" mal hinzufügen (ich hab aktuell die Rückmelde-GA rausgenommen weil das fürchterlich knattert..)
Makki
P.S.: Das ist übrigens wirklich das Licht auf der Terasse, wenn so wie vorgestern jemand Nachmittag um 2 einschaltet darf ers auch nach dem testen gerne wieder ausmachen
Wo ich gerade vom Slider lese,
tut zwar nix zum aktuell interessanten Thema aber vielleicht kann mir schnell einer eine Lösung zu meinem Problem sagen.
Vorhanden:
Taster von MDT (sendet 4bit für "Heller/Dunkler")
funktioniert auch mit Dali GW Siemens N141/02 und Leuchtmittel wird brav heller und dunkler.
Aber in der Visu habe ich eine weitere Adresse angelegt die dem Dali-GW einen 8bit-Wert schickt (0-100 in 10% Schritten)
Funkt auch - aber es werden nicht die aktuellen Werte vom Taster übernommen.
Es muss doch eine Möglichkeit geben dass die Visu den aktuellen Wert auslesen kann.
Verstehe schon dass "Dimm UP oder DOWN" nur Prozentveränderungen sind und keine absoluten Werte, aber wie kann ich Taster und Visu vereinen?
(das komplette jQuery-UI CSS müsste sicher nicht sein aber statt rausfriemlen nimmt man sowas komplett denke ich)
Das ganze jQuery-UI CSS finde ich ungeschickt. Mal vom unnötigen Speicherplatz (= Bandbreite) abgesehen, ist das nicht wirklich optimal, wenn man eigene Designs erstellen will - denn was von dem ganzen Schmodder muss man nun anfassen? Was kann man lassen?
Auch die bestehenden CSS sind da schon ziemlich unübersichtlich. Eigentlich müsste man da mal drüberfräsen und die Elemente identifizieren, die entscheidend sind...
Andere Sache: meine Slider zappeln schon wieder fürchterlich, ich *glaube* das ist neu und ich fühle mich unschuldig..
Passen die DPT bei Dir? Sind die alle gleich? Und sind manche GAs ggf. nicht read-only?
Das könnte so ein Verhalten verursachen...
Zur Zeit sind die Slider noch so, dass die einen KNX Wert empfangen, den anzeigen, so gut die können, und sollte ihr bester Versuch einen anderen KNX-Wert entsprechen, diesen versenden (damit Anzeige zum Wert passt).
Da aber eine 100% Umrechnung von KNX-Wert zu Slider-Position nicht immer möglich ist, kann es da zu komischen Effekten kommen.
(Das muss ich mal ändern...)
aber vielleicht kann mir schnell einer eine Lösung zu meinem Problem sagen.
[...]
Funkt auch - aber es werden nicht die aktuellen Werte vom Taster übernommen.
Du musst dem Gateway irgendwie beibringen, dass es bei Wert-Änderung den neuen absoluten Ist-Wert verschickt
Es muss doch eine Möglichkeit geben dass die Visu den aktuellen Wert auslesen kann.
Das Problem ist dabei, dass die Visu nicht weiß, dass der Wert sich geändert hat...
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Am Bild im Anhang ist zu sehen was der Busmonitor aufzeichnet.
Dem Dali-GW hab ich schon begebracht auf realive und absolute Dimmwerte zu reagieren.
Aber die Visu erkennt die relativen nicht.
Im Dali-GW gibt es drei Positionen pro EVG.
1: Ein/Aus (2/1/1)
2: Heller/Dunkler (2/1/101)
3: 8-Bit (2/1/102)
ich habe jetzt einen Taster angesteuert betreffend (2/1/1) für Ein/Aus (Tastendruck kurz)
bzw. Dimmen +/- (2/1/101) (Tastendruck lang)
von der Visu aus kommt ein 8-Bit Befehl auf 2/1/102
Zitat MDT:
"Bei der Übertragung der Funktion "Heller/Dunkler" wird ein 4Bt Telegramm geschick und es ist von KNX eine vordefinierte Größe für Dimmfunktion.Deshalb vermute ich, dass die Visualisierung diese Werte auch auslesen kann."
Ich habe mir Mühe gegeben und auch getestet, aber die unbekanntenn Seitenwirkungen sind->?
Das ganze jQuery-UI CSS finde ich ungeschickt. Mal vom unnötigen Speicherplatz (= Bandbreite) abgesehen, ist das nicht wirklich optimal, wenn man eigene Designs erstellen will - denn was von dem ganzen Schmodder muss man nun anfassen? Was kann man lassen?
b) Bandbreite: bin ich echt immer dabei, ich hab sogar die rrdfetch nach 2h Performance-Analyse mit 6 Endgeräten gezippt -> Aber bitte nicht beim Editor, IMHO ziemlich sekundär.. Klar, es soll keine Minuten dauern aber hier ja absolut nicht der Fall.. Wir reden von 33kB die der Webserver eh (Default wird alles gzipped) auf 6 kB eindampft. Da wirds echt esotherisch in Zeiten von ADSL, VDSL und UMTS oder LTE, gegen sinnlose Verschwendung aber..
a) eigene Designs
Ehrlich, viel weniger optimal finde ich nach dem ganzen hacken heute, das eher Eigenstrick-CSS und nicht jQuery-UI verwendet wird. Das gibts schon x-hundertfach fertig, warum nochmal neu erfinden?
(draufgekommen bin ich nur, weil in ähnlichem hatte ich jQuery-UI.js+CSS nach Qucikstart-Guide eingebunden und mich dann gewundert warum die Notifications/Statusbar im Editor so hässlich aussah)
Hey, das interessiert mich doch nicht, warum es cool aussieht, wenn es cool aussieht! (und es nicht die Welt kostet)
Auch die bestehenden CSS sind da schon ziemlich unübersichtlich. Eigentlich müsste man da mal drüberfräsen und die Elemente identifizieren, die entscheidend sind...
Wenn man da das fräsen anfängt, dann bitte auf ein verbreitetes UI-Framework migrieren (jQuery-UI, qooxdoo)..
Halte ich ehrlichgesagt für am zielführendsten, gutes verwenden, ggfs. ergänzen, bitte nicht neu erfinden.
Passen die DPT bei Dir? Sind die alle gleich? Und sind manche GAs ggf. nicht read-only?
Das könnte so ein Verhalten verursachen...
die DPT's sollten passen, mit diesen GAs mache ich seit Jahren meine tests Eine ist schreibend (dimmwert setzen), eine ist feedback, RO (Dimmwert-Status); reine KNX Lehre glaube ich..
Zur Zeit sind die Slider noch so, dass die einen KNX Wert empfangen, den anzeigen, so gut die können, und sollte ihr bester Versuch einen anderen KNX-Wert entsprechen, diesen versenden (damit Anzeige zum Wert passt).
Nochmal, IMHO sollte die Visu niemals irgendetwas senden, wenn nicht auf dieser Visu gedrückt wurde.
Beispiel: Ich schalte am B.IQ das Terassenlicht ein. Dimmzeit 60sek. Status-Rückmeldunng ist 5.10,15,20% usw. -> am Ende waren aber 100% (oder was auch immer) gefragt, nicht das irgendeine Visu anhand des Statustelegramms von 5% dann den Sollwert auf 5% zurücksetzt
So vermute ich, flickert mein Slider böse rum.. Aber ich schau mir das am Mo nochmal im Detail an.. (morgen ist Kommunion der Grossnichte, super,
Du musst dem Gateway irgendwie beibringen, dass es bei Wert-Änderung den neuen absoluten Ist-Wert verschickt
Naja, Du kennst die DALI-GW's selber, es geht was geht und die einzelne Status-Rückmeldung beim N141/01 (/02 geht so) ist schon ein selbergestrickter HS-Baustein (ginge natürlich auch mitm WG, ich hab des HS-BS geschrieben )
Das Problem ist dabei, dass die Visu nicht weiß, dass der Wert sich geändert hat...
Schon, aber lieber zeigt die Visu IMHO ggfs. bei Fehlkonfiguration einen falschen Ist-Wert an, als ungefragt einen falschen Ist-Wert zu versenden
Ersteres ist unschön in der Visu, zweiteres ein reales WAF-desaster weil ein Licht nicht so angeht wie es wollte
Makki
P.S./Edit: genau dieses Thema hatten wir übrigens bei der /oldvisu auch schonmal (das die Visu niemals etwas senden darf, nachdem sie nicht gefragt wurde) und auch gelöst (MA, nicht ich), wenn man diese Ansicht allgemein teilt, wirds auch nochmal implementiert
Zitat MDT:
"Bei der Übertragung der Funktion "Heller/Dunkler" wird ein 4Bt Telegramm geschick und es ist von KNX eine vordefinierte Größe für Dimmfunktion.Deshalb vermute ich, dass die Visualisierung diese Werte auch auslesen kann."
Die Visu kann mit den 4 Bit Dingern ziemlich wenig anfangen, denn die sagen ja nur wie relativ gedimmt werden soll. Die Visu braucht zum Anzeigen aber einen absoluten Wert.
(Was natürlich geht, ist die 4 Bit GAs auf den Trigger oder der Multitrigger zu legen und die Werte zu versenden - aber wie soll man die vernünftig anzeigen?)
b) Bandbreite: bin ich echt immer dabei, ich hab sogar die rrdfetch nach 2h Performance-Analyse mit 6 Endgeräten gezippt -> Aber bitte nicht beim Editor, IMHO ziemlich sekundär..
OK, mir war nicht klar, dass sich die Änderung nur auf den Editor bezogen hatte.
Ich hatte da noch im Ohr, dass wir das auch hernehmen wollten um z.B. eine abgebrochene Verbindung anzuzeigen u.ä.
a) eigene Designs
Ehrlich, viel weniger optimal finde ich nach dem ganzen hacken heute, das eher Eigenstrick-CSS und nicht jQuery-UI verwendet wird. Das gibts schon x-hundertfach fertig, warum nochmal neu erfinden?
Man kann sicher ein paar Dinge vereinheitlichen. Aber die ganze Struktur der Darstellung liegt im CSS, d.h. eine "Eigenstrick-CSS" wird es zwingend immer geben.
Der einzige Vorteil am jQ-UI.CSS ist der Design-Editor von deren Homepage.
Nochmal, IMHO sollte die Visu niemals irgendetwas senden, wenn nicht auf dieser Visu gedrückt wurde.
Ist ja gut, das hab ich schon in meinen ToDos.
(Lustiger Effekt bei mir: in der Früh fahren wir den Rollladen bisschen hoch, so in Lüftungsstellung. Wenn dann der erste in den Flur geht, geht dort per PM die Visu an - die sieht die Rollladenposition und will die auf den darstellbaren Wert ändern => der Rollladen zuckt etwas...)
Naja, Du kennst die DALI-GW's selber, es geht was geht und die einzelne Status-Rückmeldung beim N141/01 (/02 geht so) ist schon ein selbergestrickter HS-Baustein (ginge natürlich auch mitm WG, ich hab des HS-BS geschrieben )
Ich wusste gar nicht, das das Siemens-Teil da zu zickt. Mein ABB macht da was ich erwarte...
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Die Visu kann mit den 4 Bit Dingern ziemlich wenig anfangen, denn die sagen ja nur wie relativ gedimmt werden soll. Die Visu braucht zum Anzeigen aber einen absoluten Wert.
(Was natürlich geht, ist die 4 Bit GAs auf den Trigger oder der Multitrigger zu legen und die Werte zu versenden - aber wie soll man die vernünftig anzeigen?)
Eigentlich einfach, die Visu-Anzeige erfolgt IMHO ausschliesslich über das RO-Dimmwert-Rückmeldeobjekt, aus den 4Bit Telegrammen ist ebenso wie aus dem Dimmwert-setzen nichts zu schliessen (wenn z.B. die Dimmzeit einfach auf 1h eingestellt ist )
Mein Vorschlag wäre, das sobald ein RO-Rückmeldeobjekt angelegt ist, keine Visu-Aktualisierung über das schaltobjekt mehr stattfindet. Also, in flexibler: ein Write-only flag. (Für Dimmwert setzen, 4bit, ..)
Jeder halbwegs vernümftige KNX-Dimmaktor/DALI-GW kann das ja..
OK, mir war nicht klar, dass sich die Änderung nur auf den Editor bezogen hatte.
Ich hatte da noch im Ohr, dass wir das auch hernehmen wollten um z.B. eine abgebrochene Verbindung anzuzeigen u.ä.
Stimmt schon, das fände ich schön (auch als eine Art Growl-Notification, wo man ein noch nicht existierendes Widget bestimmte Infos zeitlich begrenzt einblenden lässt - jeder mit HS kennt das Problem: ein Popup steht auf einer von mehreren Visus die man seit Tagen nicht angeschaut hat und man muss es wegklicken obwohl die Papiertonne vor 3 Tagen war..)
Gegeben folgendes: könnte man dann das jQ-UI-CSS natürlich auf das verwendete ausdünnen. aber wiegesagt, 6kB on wire..naja.. (das jQ-UI js ist aktuell dafür nicht verwendet/notwendig!)
Man kann sicher ein paar Dinge vereinheitlichen. Aber die ganze Struktur der Darstellung liegt im CSS, d.h. eine "Eigenstrick-CSS" wird es zwingend immer geben.
Ok, das kann ich ehrlichgesagt nicht beurteilen aber der Laie findet jQ-UI schön, weils schon dutzende Styles (designs,flavours, oder wie auch immer man es nennt) fertig gibt.
Sollte sich der Laie irren, zumindest sowas wie Statusbar-boxen muss man nicht nochmal im CSS malen und es erschiene mir praktisch wenn man dafür eben sich einfach sein jQ-ui design aussuchen kann.
Ist ja gut, das hab ich schon in meinen ToDos.
Sollte ja nicht negativ pushen aber das sehe ich eben so Vielleicht wäre o.g. Write-only Flag zumindest eine einfach handhabbare Zwischenlösung ? Ich denke viele (die KNX verstanden haben) haben das eh so mit sep. KO's für Schalten/Dimmwert/Statusrückmeldung z.B. beim Dimmer, Rolladen etc.
(zugegeben: das hat bei mir aber auch gedauert, das zu verinnerlichen! deswegen das Beispiel mit 1h Dimmzeit, so richtig kapiert man das erst wenn man die Dinger auf der Visu hat..)
Ich dachte an etwas globales im update/senden jeglichen Wertes, dies grundsätzlich zu blocken wenn einfach nicht gedrückt wurde. In der /oldvisu ist das ja ziemlich kompliziert gemacht..
Ich wusste gar nicht, das das Siemens-Teil da zu zickt. Mein ABB macht da was ich erwarte...
OT/egal, aber das N141/01 sendet bei Ansteuerung der einzelenen EVG's (in 16 Gruppen schon!) keinen Dimmwert-/Schaltstatus pro EVG sondern alle zusammen in einem obskuren Format (ist ein 3-Zeiler aber..)
Anderes: Sorry, #3187464 (flavour im Editor), habs versucht, die Fundstelle in den Bug geschrieben aber am Fix bin ich schlicht gescheitert, ich finde nicht wo die weiteren Attribute der page sich verstecken..
Multi-RRD: address klonen oder erweitern, jegliches fachliches Feedback willkommen!
Die hälfte hätte ich schon fertig und ich will da die Tage weiter/fertigmachen bevor ich wieder raus bin..
Und gehört die Farbe verschiedener Datenkurven ins CSS (sagt der Verstand) oder ham die defaultwerte (evtl. abgeleitet von flavour?) und snd pro Wert im Editor als attribut einstellbar.
Anderes: Sorry, #3187464 (flavour im Editor), habs versucht, die Fundstelle in den Bug geschrieben aber am Fix bin ich schlicht gescheitert, ich finde nicht wo die weiteren Attribute der page sich verstecken..
Den Editor habe ich komplett Julian überlassen. Meine Hoffnung ist, dass er sich bald hier meldet...
(Sein Input wäre auch für diese Frage hilfreich: )
Multi-RRD: address klonen oder erweitern, jegliches fachliches Feedback willkommen!
Die hälfte hätte ich schon fertig und ich will da die Tage weiter/fertigmachen bevor ich wieder raus bin..
Und gehört die Farbe verschiedener Datenkurven ins CSS (sagt der Verstand) oder ham die defaultwerte (evtl. abgeleitet von flavour?) und snd pro Wert im Editor als attribut einstellbar.
Ich bin für ein <address>-Element pro RRD.
Farbe sollte erst mal aus dem Design-abhängigen CSS kommen, aber der User übersteuern können. Reicht da unser "universal"-Attribut "variant", oder haben wir da jetzt schon den Fall, von dem ich gehofft habe, dass der nie auftritt? (D.h. dass wir noch mehr Attribute pro <address>-Element brauchen?)
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
(Sein Input wäre auch für diese Frage hilfreich: )
Definitiv. Ich hab mich vorgestern ja ganz gut durch den Editor gekämpft, aber da ist Schluss (wobei das sicher mit meinen 3 Problemen zu tun hat: OO, OO&OO..)
Ich bin für ein <address>-Element pro RRD.
Farbe sollte erst mal aus dem Design-abhängigen CSS kommen, aber der User übersteuern können.
Also address, kein Duplikat davon? Falls kein Einspruch kommt setze ich es so um..
(muss ich ausprobieren aber die Farben halt so, das sie zum design/flavour passen und trotzdem unterscheidbar sind..)
Reicht da unser "universal"-Attribut "variant",
Denke schon, man kann pro address ja dann optional z.B. eine Farbe, eine Legende etc.pp. hinzufügen.
Letzte Frage: in der SVN-Version das diagram_popup ändern und damit config-seitig komplett breaken oder ein neues? Ich bin für letzteres, info_diagram o.ä.
Dito, wenn kein Einspruch kommt (spart Antwort) mache ich ein sep.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
(wenn die 2h nicht wären, bis man mal drin ist.. hoffte da heute eigentlich weiterzukommen aber..)
Eigentlich müsste man da mal drüberfräsen und die Elemente identifizieren, die entscheidend sind...
-> Aber bitte nicht beim Editor, IMHO ziemlich sekundär.. Klar, es soll keine Minuten dauern aber hier ja absolut nicht der Fall.. Wir reden von 33kB die der Webserver eh (Default wird alles gzipped) auf 6 kB eindampft. Da wirds echt esotherisch in Zeiten von ADSL, VDSL und UMTS oder LTE, gegen sinnlose Verschwendung aber..
Kommentar