fhem.pl anpassen für stateFormat

rudolfkoenig · 04 Januar 2016, 22:36:29

Und Nu?

justme1968 · 04 Januar 2016, 22:38:42

wie oben schon geschrieben: ich wüsste nicht warum ein / probleme machen sollte. er wird auch noch an anderen stellen gebraucht. ich würde ihn erlauben.

rudolfkoenig · 04 Januar 2016, 23:34:02

Habe / zu den erlaubten Buchstaben bei Readingnamen hinzugefuegt.
Sorry, bin etwas durcheinander, wer was will, und was Konsens ist.

tupol · 04 Januar 2016, 23:56:07

Hallo Rudi,

Deine Warnungen im log sind inzwischen bei mir aufgeschlagen
http://forum.fhem.de/index.php/topic,46718.0.html

Ich nutze in statistics den Doppelpunkt, um ein verstecktes Reading aus dem Gerätenamen und dem Gerätewert zu erzeugen. Der Doppelpunkt war für mich das einzige sichere Zeichen, das nicht in Geräten oder Readings vorkommt. Mir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.

Gibt es eine Zusammenfassung in der wiki anhand der ich verstehen kann, was die neuen Restriktionen für Modulautoren sind? Evtl. Auch warum.
Wenn nicht, wäre es möglich eine zu schreiben?

Gruss tupol

Markus Bloch · 05 Januar 2016, 00:21:30

Zitat von: tupol am 04 Januar 2016, 23:56:07
Ich nutze in statistics den Doppelpunkt, um ein verstecktes Reading aus dem Gerätenamen und dem Gerätewert zu erzeugen. Der Doppelpunkt war für mich das einzige sichere Zeichen, das nicht in Geräten oder Readings vorkommt. Mir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.

wegen: http://sourceforge.net/p/fhem/code/10208/

siehe dazu auch die commandref zu devspec.

Gruß
Markus

rudolfkoenig · 05 Januar 2016, 08:26:36

ZitatMir ist jetzt nicht klar, warum das auch plötzlich für internalValues nicht mehr erlaubt ist.

Zu "Mir ist jetzt nicht klar": Das ist genau hier in diesem Thread zu lesen.
Zu "ploetzlich": In meinen "Belehrungen" nach der Erteilung der SVN-Schreibberechtigung steht

Zitat- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.

Beim Entfernen des Doppelpunkts habe keine Gegenargumente gehoert, nur "Zustimmung".

rudolfkoenig · 05 Januar 2016, 08:28:35

Sorry, ich hatte gerade Tomaten auf den Augen: Fuer Internalvalues gibt es keine Einschraenkungen, nur fuer Readings.

tupol · 05 Januar 2016, 11:52:46

Zitat von: rudolfkoenig am 05 Januar 2016, 08:26:36
Zu "ploetzlich": In meinen "Belehrungen" nach der Erteilung der SVN-Schreibberechtigung steht
- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
Beim Entfernen des Doppelpunkts habe keine Gegenargumente gehoert, nur "Zustimmung".

Also ich habe beide Foren abonniert. Nur konnte ich in "Developer" nichts dazu finden.

Zudem ist das mit dem Abonnieren etwas vertrackt. Ich werde mit Emails geflutet, wenn ich mich per Email benachrichtigen lasse. Es gibt keine Möglichkeit, sich nur über neue Themen per Email benachrichtigen zu lassen. So wie ich es verstehe, geht Deine derzeitige "Belehrung" davon aus, dass man entweder die Email-Benachrichtigung einschaltet oder ständig die Foren nach relevanten Themen bzw. Antworten durchsucht. Beides kann ich nicht bewerkstelligen.

Es wäre für mich einfacher mitzuarbeiten, wenn es eine Möglichkeit gibt, sich in größeren Abständen gezielt über vorgeschlagene Änderungen am Framework informieren zu können. Die derzeitige Vorgehensweise über das Forum ist für mich nicht handelbar. Ich kriege es erst mit, wenn es zu spät ist. Wobei "spät" relativ ist, weil das anscheinend einfach so kurzfristig durchgezogen wurde.
Eine Abstimmungsfunktion (nur) für Developer bei neuen Features fände ich übrigens auch sinnvoll.

InternalValues sind Readings mit Punkt am Anfang (attr global showInternalValues). Ich benötige Werte, die von FHEM vor dem Neustart gespeichert werden und zumindest bei einem List sichtbar sind. Gibt es dafür auch andere Lösungen? Dann hätte ich auch kein Problem mehr mit dem Doppelpunkt.

rudolfkoenig · 05 Januar 2016, 12:22:58

ZitatAlso ich habe beide Foren abonniert. Nur konnte ich in "Developer" nichts dazu finden.

Sorry, wieder meine Schuld. Wir sind ja im Sonstiges, eigentlich haette im Developer dafuer ein Thema geben muessen. Ich versuche demnaechst aufzupassen.

ZitatEs gibt keine Möglichkeit, sich nur über neue Themen per Email benachrichtigen zu lassen.

Das muss aber gehen, da bei mir genau das aktiviert ist. Ich vermute es reicht dafuer auf Bereichs-Ebene die emails zu aktivieren. Ich habe auch Verstaendnis dafuer, wenn jemand keine Zeit fuer die vielen Mails hat, dann braucht man sich aber nicht zu beschweren. Aber wie gesagt, war meine "Ruege" in diesem Fall komplett fehl am Platz, da ich mich an meine eigenen Regeln nicht gehalten habe.

ZitatInternalValues sind Readings mit Punkt am Anfang (attr global showInternalValues).

Da habe ich dich missverstanden. InternalValues ist fuer mich das, was bei "list" und in FHEMWEB unter Internals gezeigt wird, und die per "InternalVal()" abgefragt werden koennen. Das Attribut showInternalValues ist aus dieser Sicht ungluecklich benannt (*seufz*), wir reden in deinem Fall ueber Readings.

Nach etwas Nachdenken ueber dein Problem schlage ich vor, diese Regexp-Pruefung nur auf "immer Sichtbare" (also kein . am Anfang) Readings zu beschraenken, haette aber gerne Meinungen dazu.

tupol · 05 Januar 2016, 12:37:38

Einverstanden.
Wäre es möglich, Werte abzuspeichern, die nicht unter {READINGS} laufen. Dann hätte ich/wir das Problem nicht.

Vielleicht kann sich ein Forum-Admin mal meine Einstellungen anschauen. Derzeit bekomme ich entweder all Emails oder keine. Auch kann ich im nachhinein nicht mehr ein Thema "abwählen" zu dem ich einmal etwas geschrieben habe.

Markus Bloch · 05 Januar 2016, 12:51:40

Schau dir mal die Funktionen setKeyValue() und getKeyValue in fhem.pl an.

Die sind genau dafür gedacht. Nutze ich in FB_CALLLIST um die Anrufliste abzuspeichern und bei Start wieder einzulesen.

Gruß
Markus

herrmannj · 05 Januar 2016, 13:03:07

ZitatNach etwas Nachdenken ueber dein Problem schlage ich vor, diese Regexp-Pruefung nur auf "immer Sichtbare" (also kein . am Anfang) Readings zu beschraenken, haette aber gerne Meinungen dazu.

finde ich gut und passt ja auch.

Hidden/Internal Values dürfen anderen Regeln gehorchen und evtl benötigte Flexibilität bleibt erhalten.

vg
jierg

rudolfkoenig · 06 Januar 2016, 08:10:32

Habs eingecheckt.

betateilchen · 06 Januar 2016, 10:50:24

Zitat von: rudolfkoenig am 05 Januar 2016, 12:22:58

Das muss aber gehen, da bei mir genau das aktiviert ist. Ich vermute es reicht dafuer auf Bereichs-Ebene die emails zu aktivieren.

Auf der Übersichtsseite eines Unterforums den Button "Benachrichtigen" klicken

(http://up.picr.de/24200842su.jpg)

tupol · 06 Januar 2016, 11:28:52

Zitat von: Markus Bloch am 05 Januar 2016, 12:51:40
Schau dir mal die Funktionen setKeyValue() und getKeyValue in fhem.pl an.

Die sind genau dafür gedacht. Nutze ich in FB_CALLLIST um die Anrufliste abzuspeichern und bei Start wieder einzulesen.

Das passt glaube ich nicht richtig. setkeyvalue ist doch mehr für Passwörter. Ich ändere ja die Readings nach jedem Geräte:Wert-Update. Das sind zu viele Schreibprozesse. Sichern reicht eigentlich pro Shutdown oder einmal täglich.