Neues Charting / Plotting - GUI Redesign?

[Johannes]

Ich brauche eure Hilfe.
Es ist wirklich problematisch festzustellen, ob ein Gerät nun einen Button, Slider oder was auch immer braucht.
Ich nehme mal als Beispiel die Weihnachtsbeleuchtung ausm Vorgarten von Thomas.
So wie ich das sehe, stecken alle potentiellen Kandidaten für einen Button oder Slider in den Sets:

Code Auswählen Erweitern


{
      "list": "FS20",
      "devices": [
        {
          "BTN": "00",
          "DEF": "7775 00",
          "NAME": "eg_xmaslights_outside",
          "NR": "61",
          "STATE": "on",
          "TYPE": "FS20",
          "XMIT": "7775",
          "ATTR": {
            "alias": "Weihnachtsbeleuchtung Vorgarten",
            "fp_floorplan_EG": "368,242,1,Weihnachtsbel.",
            "icon": "icoBaum",
            "room": "Garten"
          },
          "READINGS": [
            {
              "state": "on",
              "measured": "2013-03-20 17:00:00"
            }
          ],
        "sets": [
          "dim06%",
          "dim100%",
          "dim12%",
          "dim18%",
          "dim25%",
          "dim31%",
          "dim37%",
          "dim43%",
          "dim50%",
          "dim56%",
          "dim62%",
          "dim68%",
          "dim75%",
          "dim81%",
          "dim87%",
          "dim93%",
          "dimdown",
          "dimup",
          "dimupdown",
          "off",
          "off-for-timer",
          "on",
          "on-100-for-timer-prev",
          "on-for-timer",
          "on-old-for-timer",
          "on-old-for-timer-prev",
          "on-till",
          "ramp-off-time",
          "ramp-on-time",
          "reset",
          "sendstate",
          "timer",
          "toggle",
          "dim:slider,0,6.25,100",
          "blink",
          "intervals",
          "off-till"
        ],
        "attrs": [
          "room",
          "group",
          "comment",
          "alias",
          "eventMap",
          "userReadings",
          "IODev",
          "follow-on-for-timer:1,0",
          "follow-on-timer",
          "do_not_notify:1,0",
          "ignore:1,0",
          "dummy:1,0",
          "showtime:1,0",
          "loglevel:0,1,2,3,4,5,6",
          "event-on-change-reading",
          "event-on-update-reading",
          "event-min-interval",
          "stateFormat",
          "model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,
fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,
fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,
fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,
fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze",
          "devStateIcon",
          "fp_EG",
          "fp_Grundriss_DG",
          "fp_Grundriss_EG",
          "fp_Grundriss_OG",
          "fp_eg",
          "fp_floorplan_DG",
          "fp_floorplan_EG",
          "fp_floorplan_OG",
          "fp_fp_test",
          "fp_image",
          "icon",
          "sortby",
          "webCmd"
        ]
        }
      ]
    }


Hier hätte ich die Möglichkeit, an "dim:slider,0,6.25,100" zu erkennen, dass ein Slider benötigt wird.
Es gibt aber auch einfach Textkeys wie "on" oder "off", die sich ja wunderbar als Button eignen würden. Da ich aber hier keine Unterscheidung machen kann zu den anderen keys (z.B. ramp-off-time, toggle, ...) müsste ich gezwungenermaßen alle keys nehmen und als Button verwenden. Dann hätte man aber sehr viele und auch überflüssige Buttons. Vermutlich lässt sich auch garnicht jeder key sinnvoll als Button verwenden...

Es ist also relativ schwierig aus den Informationen die ich zu den verschiedenen Devices habe, die gewünschten Buttons etc zu bauen.
Denkbar wäre ja zu sagen, ich nehme für Buttons aus den sets nur die Werte "on,off,toggle", aber damit stellt man garantiert nicht jeden zufrieden...

Wie wäre es wenn man den Devices ein neues Userattribut zuweist das den Typ des Gerätes darstellt?

also quasi generische Typen: Dimmer, Switch, Value (Anzeige), Shutter (Rolladen), etc.

Wäre prinzipiell nicht schlecht, aber wer soll das machen? Jeder User einzeln? Ist vielleicht auch etwas umständlich...


Vielleicht kennt jemand noch einen anderen oder besseren Weg herauszubekommen ob und wenn ja was bei einem Gerät als Button / Slider etc. verwendet werden soll?!

[rudolfkoenig]

Um dieses Problem zu loesen hat FHEMWEB in der Raumansicht eine Default-Reihenfolge
(Temperatur, Dimmer, on/off Schalter), was vom Benutzer per webcmd ueberschrieben werden kann.
Im Detailansicht kann/muss man das Kommando aus einem Dropdown auswaehlen (ist etwas komplizierter),
dafuer stehen aber alle zum Auswahl.
Will nicht sagen, dass nichts besseres gibt, es faellt mir nur nicht ein :)

P.S.: bitte demnaechst beim verwenden von CODE-Bloecken lange Zeilen meiden, die machen das
UI hier im Forum unbrauchbar.

[Johannes]

Hallo Rudi,

Danke für die Erklärung. Jsonlist hat keine möglichkeit, die "sortierte" raumansicht abzufragen, oder? Gäbe es noch andere Möglichkeiten? Jedes device hat ja einen mehr oder weniger generellen Type, z.b. "Heatingthermostat". Für diese scheint ja irgendwo vorgegeben zu sein, dass desiredtemperature automatisch als dropdown auftaucht. Gibt es da vielleicht irgendwo eine Auflistung dieser zusammenhänge?

[rudolfkoenig]

Was ein Frontend anbietet, sollte es aus der Liste der moeglichen Befehle (siehe sets) ableiten, Vorschiften (bei on/off hat der Frontend einer Schalter anzuzeigen, usw) gibt es keine.

Ein Typ (im Sinne von Interface) gibt es in FHEM nur halbherzig.

Boris wollte, dass ein Modul explizit zusichert, welche Kommandos/Events/etc es sendet,
(siehe http://www.fhemwiki.de/wiki/DevelopmentInterfaces), ich meine das ist nicht notwendig, und es ist mWn auch in keinem FHEM Modul implementiert.

Die gleiche fhemwiki Seite beinhaltet aber auch, wie man was Einschaltet/Ausschaltet/dimmt/usw., das sollte man als Modulauthor befolgen, sonst spielen spaeter die Frontends nicht mit. Leider ist diese "Vereinbarung" noch in vielen wichtigen Modulen nicht nachgezogen (TODO), Beispiel: FHT:desired-temp statt desiredTemperature (wie bei MAX).

Was mir noch fehlt ist eine Abfrage der moeglichen Events je Modul, damit man die Erstellung von notify/FileLog/etc auch in Frontend unterstuetzen kann, aber das ist z.Zt noch Zukunftsmusik.

Wenn ich es richtig verstanden habe, dann gehen die mobile-Frontend-Jungs einen anderen (statischen?) Weg, sonst wuesste ich nicht, wieso manche Module da nicht von Haus aus unterstuetzt werden.

[Johannes]

Rudi, danke für die Zusammenfassung. Den Wiki Link hatte ich schon wieder vergessen..
Gut, damit steht für mich erstmal fest, das ich mit dem "Inhalt" von den Sets arbeiten muss. Ein paar Defaults werde ich also händisch abfangen (listen, Dimmer, toggles...) und entsprechende Komponenten einbauen. Anpassung durch den user ist ja über webCmd gegeben.

[Johannes]

Update:
Ein neues Update ist verfügbar. Änderungen:

  * Geräte können jetzt gesteuert werden mit Hilfe von Buttons und Dropdownlisten
  * Anzeige eines Gerätes (mit seinen Messwerten und Status) aktualisiert sich regelmäßig selbstständig
  * Bugfix im Chart, dass beim Hovern keine Messwerte angezeigt wurden
  * Bugfix in DbLog, Statistiken waren nicht immer korrekt wegen fehlendem Type Cast
  * neue Startseite
  * viele kleine Bugfixes

(siehe Anhang / see attachement)

Wenn man nun also im linken Tree ein Gerät / Device ausgewählt hat, erscheint wie üblich das Gerätepanel in der Mitte.
Oben habe ich jetzt einen Bereich eingeführt, wo sich "Controls", derzeit Buttons und Listen, zum Setzen von Werten befinden.

Je nach Gerät taucht dieser Bereich erst garnicht auf (wenn es nichts zum setzen gibt), oder er wird mit einigen Controls aufgefüllt.
Hat ein Benutzer ein webCmd gesetzt, so wird ausschließlich dieses benutzt und keine anderen Controls hinzugefügt.
Gibt es kein webCmd, wird aus der Liste der sets (die ja oben besprochen wurden) jeder Kandidat genommen, der dort mit einem Doppelpunkt auftaucht.
Gibt es zu diesem Set mehr als 3 Werte, wird eine Dropdown gebaut, gibt es weniger, werden Buttons erzeugt.

Alle in dem "Gerätefenster" angezeigten Daten (Readings in den Tabellen, Zustände der Listen, Buttons) werden im Abstand von 5 Sekunden über einen Ajax Request aktualisiert.
Wird ein Zustand geändert mittels Button oder Dropdown, wird eine sofortige Abfrage der aktuellen Werte gestartet, um einen aktuellen Stand abzubilden. Es kommt natürlich trotzdem mal vor, dass man z.B. etwas an oder ausschaltet, der Status in FHEM sich aber erst nach einer gewissen Zeit ändert. Also nicht wundern, wenn man den Button "an" drückt, und er wenig später selbstständig wieder auf aus springt. Der Button stellt in diesem Falle einfach nur den aktuellen Zustand dar. Sobald in FHEM bzw. den Readings die Änderung angekommen ist, ändern sich auch die Buttons / Listen automatisch auf den aktuellen Wert.

Ich bin gespannt auf Feedback.

Code Auswählen Erweitern


update thirdparty http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/www/frontend frontend


[thoweiss]

Das sieht doch schon vielversprechend aus.

Hab es gleich mal getestet, läuft gut bei mir.

Die Optik ist allerdings etwas "technisch" - aber es geht ja erstmal primär um die Funktion - dann um die Optik.

Ich will einmal versuchen deinen Code zu verstehen, allerdings finde ich JS noch etwas kompliziert...

Mit welcher IDE programmierst Du? Eclipse?

gruß,
Thorsten

[Johannes]

Hi,

Vorschläge für die Optik sind willkommen. Ich bekomme sehr wenig Feedback was Funktionen / Aussehen angeht, deswegen mache ich einfach wie es mir passt.
Fokus liegt natürlich immer zuerst auf Funktion, dann auf Aussehen. Andersrum wäre Quatsch :-)

Zum Programmieren habe ich Eclipse Java EE IDE for Web Developers im Einsatz.

Grüße!

[Johannes]

Apropos Style.
Ich kann demnächst mal noch eine Dropdownliste einbringen, in der man seinen gewünschten Style auswählen kann.
Falls Interesse besteht...

Z.B.:

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

[Puschel74]

Hallo,

ich habe mich heute auch breit schlagen lassen und habe auf meinem "Ersatz-"RasPi das neue Frontend installiert.

Ok. War nicht ganz so einfach wenn man mysql und sqlite und php das erste mal hört ;-)
Die Infos für die Installation sind etwas weit verteilt im Netz, aber der Suchmaschinenfreund findet ja zum Glück alles.
sqlite3 dbi dbd perl und alles drum herum, ok. Wer suchet der findet, und ich habe gefunden.

Die ersten Daten werden seit heute mittag in die Datenbank geschrieben und die ersten Grafiken lassen sich schon anschauen.

Erstes Fazit: Nur weiter so - das sieht gut aus.

Erste Frage: Im Frontend bekomme ich beim abspeichern zwar die Fehlermeldung das der Chart nicht gespeichert werden konnte aber
wenn ich das Frontend erneut aufrufe ist der Chart abrufbar - so weit so gut.
Leider habe ich in meiner Euphorie einen Chart 2-mal abgespeichert (ich hab ja nicht gesehen das der Chart schon angelegt war).
Wie kann ich den "überflüssigen" Chart löschen?

Zweite Frage: Ich betreibe mein Haupt-FHEM auch auf einem RPi - von diesen sammle ich alles per fhem2fhem ein um es an meinem
SQLite-RasPi in die Datenbank zu stopfen.
Funktioniert soweit.
Das ich nichts bedienen kann ist mir soweit auch klar - ist ja nichts vorhanden zum bedienen.
Es wird ja nur geloggt.

Gehe ich recht in der Annahme das die Datenbank fhem.db heisst in der die Daten landen?
Ich habe unter opt/fhem die db.conf angelegt und verweise darin auf opt/fhem/fhem.db
Allerdings habe ich mittlerweile noch 2 Files unter opt/fhem nämlich
fhem.db-shm und
fhem.db-wal

Nun zur Frage: Reicht es diese fhem.db auszulagern (auf einen USB-Stick z.B oder auf ein NAS) um die SD-Karte zu "schonen"?

So. Das wars fürs Erste.

Danke nochmal für die Bemühungen rund um FHEM und für das Frontend und für die Antworten ;-)

Grüße

Edith: Wäre es vllt. möglich bei einem CUL_WS einen avg_max_day und einen avg_min_day in einem Chart anzuzeigen?

[Johannes]

Hallo Puschel,

Ich nehme deine Fragen mal auseinander :-)

Ok. War nicht ganz so einfach wenn man mysql und sqlite und php das erste mal hört ;-)
Die Infos für die Installation sind etwas weit verteilt im Netz, aber der Suchmaschinenfreund findet ja zum Glück alles.

Ich hoffe du hast kein php installiert, das ist nämlich schon lange nicht mehr nötig..
Der schwierigste Schritt ist eigentlich, DbLog ans laufen zu bekommen. Falls du Lust hast, deine Funde bzw. Installationsablauf ins Wiki zu schreiben (oder mir zukommen zu lassen), würde das bestimmt auch anderen helfen .

Die ersten Daten werden seit heute mittag in die Datenbank geschrieben und die ersten Grafiken lassen sich schon anschauen.

Sehr schön.

Erste Frage: Im Frontend bekomme ich beim abspeichern zwar die Fehlermeldung das der Chart nicht gespeichert werden konnte aber
wenn ich das Frontend erneut aufrufe ist der Chart abrufbar - so weit so gut.

Ich kann es kaum glauben dass das Problem immer noch bei einigen auftritt, das müsste schon lange gelöst sein.
Bitte gib mir mal folgende Infos dazu:
Versionsnummer im Frontend (steht ganz unten in der Statuszeile).
Letztes Änderungsdatum der Datei 93_DbLog.pm im Ordner FHEM (am besten auch Dateigröße!).

Leider habe ich in meiner Euphorie einen Chart 2-mal abgespeichert (ich hab ja nicht gesehen das der Chart schon angelegt war).
Wie kann ich den "überflüssigen" Chart löschen?

In der Liste der Charts ist rechts in der Tabelle ein kleines rotes Icon zu sehen. Schau dazu mal in den Screenshots über deinem Post in das erste Bild, da kann man es erkennen.
Ein Klick darauf, und der Chart wird gelöscht.

Zweite Frage: Ich betreibe mein Haupt-FHEM auch auf einem RPi - von diesen sammle ich alles per fhem2fhem ein um es an meinem
SQLite-RasPi in die Datenbank zu stopfen.
Funktioniert soweit.
Das ich nichts bedienen kann ist mir soweit auch klar - ist ja nichts vorhanden zum bedienen.
Es wird ja nur geloggt.

Du benutzt also 2 RPi, einen für die Steuerung bzw. FHEM, den anderen ausschließlich zur Datenspeicherung?
Wenn ja könnte ich mir vorstellen, dass du das Frontend trotzdem sinnvoll nutzen kannst, indem du es auf dem Haupt Pi installierst und dort in der db.conf die Datenbank des anderen RPi einträgst.
Wenn beide miteinander kommunizieren können (was sie ja scheinbar schon tun), sollte das funktionieren ( ich weiss allerdings nicht genau wie FHEM2FHEM arbeitet, vielleicht habe ich hier auch einen Denkfehler)

Gehe ich recht in der Annahme das die Datenbank fhem.db heisst in der die Daten landen?
Ich habe unter opt/fhem die db.conf angelegt und verweise darin auf opt/fhem/fhem.db

Wenn du es so (/opt/fhem/fhem.db) definiert hast, dann heisst die Datenbank auch so. In SQLite kann man auf der Kommandozeile durch den Befehl
  sqlite3 test.db
Eine neue Datenbank mit dem Namen test erstellen. Exisitert bereits eine unter diesem Namen an diesem Ort, wird damit verbunden (SQLite Eigenheit :-)
DbLog hat sie also vermutlich für dich bereits erstellt.

Allerdings habe ich mittlerweile noch 2 Files unter opt/fhem nämlich
fhem.db-shm und
fhem.db-wal

Die Dateien gehören zur DB und sollten auch da bleiben (sind zuständig für Indexes / Rollbacks)

Nun zur Frage: Reicht es diese fhem.db auszulagern (auf einen USB-Stick z.B oder auf ein NAS) um die SD-Karte zu "schonen"?

Das ist das schöne an SQLite, du kannst die DB einfach woanders hinkopieren, es reichen die 3 von dir genannten Dateien aus. Anschließend muss du natürlich die db.conf anpassen an den neuen Ort.

Edith: Wäre es vllt. möglich bei einem CUL_WS einen avg_max_day und einen avg_min_day in einem Chart anzuzeigen?

Ich habe bisher aus Faulheit die Statistikfunktion nur für die erste Y-Achse integriert. Bisher habe ich auch kein Feedback bekommen und es daher erstmal so gelassen.
Mich selber hats aber auch schon genervt. Das ist leider meine größte Baustelle im Code wo ich dringend mal aufräumen müsste. Mein Wunschziel wäre unbegrenzte Zahl an Achsen mit unbegrenzten Statistikfunktion, unbegrenzten Solllinien und unbegrenzter Generalisierung mit generischen Funktionen. Derzeit leider noch alles etwas hart verdrahtet und bis maximal 3 an der Zahl möglich.
Ich denke diesem Punkt werde ich mich ziemlich bald widmen...

Danke nochmal für die Bemühungen rund um FHEM und für das Frontend und für die Antworten ;-)

Bitte bitte

[Puschel74]

Hallo und Guten morgen,

Danke Johannes für die Antworten - es kann so einfach sein (rotes x für delete ^^ ).

PHP. Nein, PHP habe ich keins mehr installiert - ich habe zum Glück vorher den gesamten Beitrag hier nochmal überflogen ;-)

Da ich aber zum Glück noch Urlaub habe (Überstunden abfeiern) kann ich mich ja mal dran setzen und eine Zusammenfassung inkl. Links erstellen - aber leider nur SQLite3 auf RPi Model B (aber besser als nichts denke ich mal).
Ich werd mich heute nachmittag mal dran setzen und dir das evtl. am Abend mal per pm zukommen lassen zum quer lesen wenn du möchtest. (Aber gerade DBLog war das einfachste finde ich ;-) ).

Versionsnummer im Frontend (steht ganz unten in der Statuszeile).

Frontend Version: 0.4 - 2013-03-23

Letztes Änderungsdatum der Datei 93_DbLog.pm im Ordner FHEM (am besten auch Dateigröße!).

Ähem. Ja. Ok. Wurde per update getauscht ;-) Ich schau mal wo ich diese Infos finde.
Größe: 59739 Byte
Für diesen RPi habe ich WinSCP noch nicht eingerichtet - werde ich auch heute nachmittag nach holen.

Bzgl. FHEM2FHEM ist bei mir erstmal nur Einbahn.
Der Datenbank-RPi holt sich die Daten am Haupt-RPi ab und schreibt erstmal alles in die DB weg.
Im Endausbau soll alles dann auf nur einem RPi laufen - ich wollte nur zu Testzwecken nicht riskieren das evtl. die Heizung
steht (der WAF sinkt schlagartig wenn die Temperatur im Wohnzimmer sinkt ;-) ).

DbLog hat sie also vermutlich für dich bereits erstellt

Nein nein. DBLog hat nichts gemacht (soweit war ich nocht garnicht).
Mit

Code Auswählen Erweitern

sqlite3 fhem.db habe ich die DB erstellen lassen und dann die beiden TABLES eingefügt (current und history).
Erst hatte ich mich an mysql versucht - da muss die DB noch ausgewählt werden, das muss bei sqlite3 scheinbar nichtmehr da
alles funktioniert (hoffe ich).
Aber gut zu wissen das ich nur die 3 Dateien aufs NAS verschieben muss und dann nur in der db.conf den Pfad anpassen.
So kann ich schonmal die SD-Karte entlasten.

Das mit den avg_max und avg_min kam auch nur von mir weil du i-wo im Beitrag mal geschrieben hast das keine Wünsche geäussert
werden und du einfach mal so vor dich hin arbeitest.
Dachte ich mir, gut. Ich hab schon einen Wunsch ;-)

Nur viel mir gestern auf das auf meinem Android-Tablet das Frontend beinahe unbedienbar ist.
Aber das liegt vermutlich am Tablet und nicht am Frontend ;-)
Am PC und am Laptop läuft es ja wunderbar.

DAnke nochmal und weiter so.

Grüße

[Johannes]

Hi,

Ähem. Ja. Ok. Wurde per update getauscht ;-) Ich schau mal wo ich diese Infos finde.
Größe: 59739 Byte

Ok, die Versionen sind schonmal aktuell. Kannst du mir bitte den "exakten" Wortlaut der Fehlermeldung, die du bekommst, hier rein kopieren?
Und, was noch besser wäre (falls du Firebug installiert hast in deinem Firefox), ein Screenshot von der Netzwerkkonsole von Firebug, nachdem du auf speichern geklickt hast.
Ich hänge mal 2 Screenshots an die zeigen, was ich genau meine.
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
Nämlich den Reiter "Parameter" und den Reiter "JSON" im Netzwerktab von Firebug für den POST-Request, der "savechart" in den Parametern trägt.

Das mit den avg_max und avg_min kam auch nur von mir weil du i-wo im Beitrag mal geschrieben hast das keine Wünsche geäussert
werden und du einfach mal so vor dich hin arbeitest.
Dachte ich mir, gut. Ich hab schon einen Wunsch ;-)

Steht jetzt auf meiner TODO Liste ziemlich weit oben.

Nur viel mir gestern auf das auf meinem Android-Tablet das Frontend beinahe unbedienbar ist.

Ja, prinzipiell ist das Frontend lauffähig auf iPhone, Tablets etc. Aber es ist in keinster Weise dafür optimiert, und das  werde ich mir auch nicht vornehmen, denn der Arbeitsaufwand ist leider enorm.
Da die Bibliothek sich nicht allzu gut mit mobilen Geräten versteht (man merkt es vor allem, wenn man mal eine Dropdown aufgemacht hat auf einem Android Tablet), müsste ein "mobiles" Frontend parallel entwickelt werden. Und ich denke da gibt es ja schon genug "Produkte" in der Ecke für FHEM.
Ziel von diesem Frontend ist eine umfangreiche Oberfläche mit vielen nützlichen Funktionen.
Zum kurz mal Readings auf dem Handy nachschauen eignen sich andere Frontends wohl besser.

Grüße,
Johannes

[Puschel74]

Hallo,

ich hab mal wieder eine Frage.

So sehen die Einträge für die Wasserpumpe aus wie sie durch fhem2fhem übermittelt werden

(siehe Anhang / see attachement)

Kann es sein das sich da evtl. auch irgendwas mit addLog nicht verträgt?

(siehe Anhang / see attachement)

Der Chart wird mir allerdings ob mit oder ohne addLog-Eintrag durchgehend bei 0 angezeigt obwohl die Wasserpumpe heute schon 2 mal Ein war.

(siehe Anhang / see attachement)

Oder muss ich da noch irgendwo was eintragen?

Danke nochmal für die Hilfe.

Grüße

[Puschel74]

Hallo,

anbei die Fehlermeldung beim speichern.

(siehe Anhang / see attachement)

Und so sieht es Firebug:

(siehe Anhang / see attachement)
(siehe Anhang / see attachement)

Grüße