FHEM Forum

Hallo

ich habe da ein Problem.    ;)

Auch nach vielem Suchen und vielen guten Beispielen im Forum habe ich meinen Wunsch bei der Web Anzeige nicht hinbekommen. Vielleicht kann mir ja bitte jemand auf die Sprünge helfen. Das wäre super.

define ManualUseTemp dummy
attr ManualUseTemp stateFormat lastused state
attr ManualUseTemp setList on off
attr ManualUseTemp webCmd on:off

define ManualUseTempJob notify ManualUseTemp:.* {\
  my $lastused = ReadingsTimestamp('ManualUseTemp','state','');;\
  fhem("setreading ManualUseTemp lastused $lastused");;\
  # und andere jobs \
}


Also ich habe den Dummy "ManualUseTemp" im Web zum Umschalten zwischen manueller und automatischer Temperatureinstellung. Das klappt alles wunderbar. Im Web wünsche ich die Anzeige was der aktuelle Status ist und wann der gesetzt worden ist. Daher habe ich ein Reading mit Namen "lastused" eingefügt. Das funktioniert, wird auch mit "ReadingsTimestamp()" beschrieben. Nur die Anzeige funktioniert nicht. Wenn ich beispielsweise ein "rereadcfg" oder so aufrufe, dann erscheinen drei Fragezeichen "???" und keine Inhalte von "lastused" noch "state". In "lastused" ist der Zeitpunkte der letzten Nutzung drin. Wenn ich "on" oder "off" anklicke, dann kommt die Anzeige korrekt. Mach ich ein "rereadcfg" ist wieder alles weg.

ManualUseTemp                           ???   on off
ManualUseTemp       2019-03-07 11:46:33 off   on off

Ich habe ein anderes Dummy, welches ich Readings aller Daten zur Heizung gegeben habe, da liste ich die Readings auch in "stateFormat" und dort funktioniert das immer. Es irritiert mich, daß es hier nicht funktioniert. Ich hatte zuerst das "ReadingsTimestamp()" direkt im "stateFormat" was das gleiche Ergebnis zur Folge hatte.

Was habe ich nicht verstanden oder falsch gemacht?

Ich habe irgendwie noch nie ein rereadcfg gemacht?! Wozu tut man das?
Ich denke das von dir gezeigte Verhalten ist so, weit der Inhalt vom Reading nicht gespeichert ist. weil setstate genauso arbeitet. Siehe Doku (https://commandref.fhem.de/#setstate).

Deine Lösung hätte ich mit einem userReadings gemacht, das tut genau das Gleiche aber "einfacher". Ändert aber sicher an dem Verhalten nichtsattr ManualUseTemp  userReadings lastused {ReadingsTimestamp($name,'state','')}

Aber scheinbar passiert ja dort noch mehr. Also nur als Anregung :)

Gruß Otto

Zitat von: Otto123 am 07 März 2019, 12:28:31
Ich habe irgendwie noch nie ein rereadcfg gemacht?! Wozu tut man das?

Geht mir genauso. Verstehe auch nicht wofür man das braucht, es sei denn man editiert manuell die fhem.cfg (was bekanntlich absolut nicht empfohlen ist).

Zitat von: Otto123 am 07 März 2019, 12:28:31Aber scheinbar passiert ja dort noch mehr.

Kann mich ansonsten Ottos Vorschlag nur anschließen mit dem userReading. Auch im userReading kann man das "passiert ja dort noch mehr" abbilden.
Und Du spart Dir ein zusätzliches notify.

Mein Vorschlag:
defmod ManualUseTemp dummy
attr ManualUseTemp cmdIcon on:general_an@green off:general_aus@red
attr ManualUseTemp setList on off
attr ManualUseTemp stateFormat lastused state
attr ManualUseTemp userReadings lastused:on|off {\
  # hier passiert noch so einiges\
  # und hier wird der Wert für lastused zurückgegeben\
  return ReadingsTimestamp($name,"state","")\
}
attr ManualUseTemp webCmd on:off

Gruß
Dan

Danke für die schnellen und netten Antworten.

ZitatIch denke das von dir gezeigte Verhalten ist so, weit der Inhalt vom Reading nicht gespeichert ist.

Hmm. Aber alle Readings sind doch gespeichert. Und wenn ich "stateFormat" mit Readings verwende die nur Zahlenwerte enthalten, dann funktioniert das doch auch. Hier nicht, obwohl das Reading einen Inhalt hat.

@Otto123:

Das mit dem "userReadings" (*) funktioniert genauso wie gehabt. Bringt auch drei Fragezeichen nach einem "rereadcfg" anstatt der Inhalte. Danke für den Tipp, aber mir ist meine ausführlichere Version lieber, da ich es dann von verschiedenen "$EVENT"s abhängig machen kann. Also nur speichern, wenn es ein gültiger Befehl mit mehreren Abhängigkeiten war (im Beispiel, das nur zur Verdeutlichung ist, natürlich nonsens).

@DeeSPe:

Deine Version verstehe ich noch nicht ganz: Wird da innerhalb des "attr ... userReadings" praktisch das gleiche ausgeführt wie wenn ich ein "define ... notify ... :on|off" erstelle? Wenn ja, was hat das für Vorteile?

ZitatIch habe irgendwie noch nie ein rereadcfg gemacht?! Wozu tut man das?

Tja, ganz einfach: Um die Konfiguration neu zu laden. Oder wie macht Ihr das? Habe ich was übersehen?

ZitatVerstehe auch nicht wofür man das braucht, es sei denn man editiert manuell die fhem.cfg (was bekanntlich absolut nicht empfohlen ist).

Ob empfohlen oder nicht. Der eine arbeitet direkt in der Konfiguration, der andere eben über die Oberfläche. Über die Oberfläche arbeiten finde ich absolut grausam und brauche ich nicht. Zudem wird dort sicher auch ein "rereadcfg" gemacht, wenn was geändert wurde.

Ich habe eine "fhem,cfg" die enthält ein "include" auf meine Konfigurationsdateien auf die FHEM ausschließlich Lesezugriff hat. Mir fummelt da FHEM zuviel in der Konfiguration rum, so daß schon mal eine ausgefummelte Konfiguration einfach weg war oder irgendwie ersetzt wurde. Oder war was doppelt drin und es kommen dauernd Fehlermeldungen. Deswegen nur Lesezugriff. Und die "fhem.cfg" wird bei mir über die "crontab" immer wieder mit einem Original überschrieben. Eben wegen der sehr negativen Erfahrungen. FHEM muß laufen, sonst brauche ich das nicht.


(*) Wieso eigentlich "userReadings", wenn es nur um ein Reading geht!? Manchmal ist FHEM ein bißchen schwierig.  ;)

Zitat von: der-sigi am 07 März 2019, 14:38:53
@DeeSPe:

Deine Version verstehe ich noch nicht ganz: Wird da innerhalb des "attr ... userReadings" praktisch das gleiche ausgeführt wie wenn ich ein "define ... notify ... :on|off" erstelle? Wenn ja, was hat das für Vorteile?

Ja, es wird das selbe ausgeführt.

Ich antworte mal mit einem Zitat von mir:

Zitat von: DeeSPe am 07 März 2019, 13:25:57
Und Du spart Dir ein zusätzliches notify.

Gruß
Dan

Zitat von: der-sigi am 07 März 2019, 14:38:53
(*) Wieso eigentlich "userReadings", wenn es nur um ein Reading geht!? Manchmal ist FHEM ein bißchen schwierig.  ;)

Doku

ZitatuserReadings
A comma-separated list of definitions of user-defined readings. Each definition has the form:
<reading>[:<trigger>] [<modifier>] { <perl code> }

Es geht um mehr :)

Man könnte sagen: userReadings ist eine Art notify für ein spezielles Gerät, dort wo es definiert wurde. Es wird dann getriggert, wenn diese Gerät getriggert wird. Man braucht also den primären trigger device: nicht.

Zitatrereadcfg [fhem-config-file]

Re-read the active configuration file, or the optionally specified file.
The sequence: the statefile will be saved first, then all devices will be deleted, then the currently active config file (or the specified file) will be read and at last the statefile will be reloaded.
Upon completion it triggers the global:REREADCFG event. All existing connections up to the one issuing the rereadcfg will be closed.

Das passiert bei mir mit Sicherheit nicht, wenn ich nur ein device anlege, modifiziere o.ä.  :o

Das setzen des Readings beim Start erfolgt so:
setstate ManualUseTemp 2019-03-07 14:51:10 lastused 2019-03-07 14:45:49
Damit ist das Verhalten klar denke ich, denn:

Nochmal die Doku:

Zitatsetstate <devspec> <value>

Set the STATE entry for the device specified by <devspec>, which is used for displaying the device state in different frontends. No signals will be sent to the device, no events will be generated, and no eventMap or stateFormat translation will be done either. This command is also used in the statefile. See the Device specification section for details on <devspec>.

Works as designed :)

Gruß Otto

@Otto123:

Du bist super.   ;)

Ok, dann ist ja alles gut, sollte man meinen. Gefällt mir aber nicht. Ist es denn möglich ein globales "schuck es an" durchzuführen? Oder sollte ich einen Job einrichten der bei Neustart und NeuKonfiguration eben die "notifizierten" Bereiche mit einem "blinden" Befehl anschuckt die ich mit einem "lastused" eingerichtet habe? Gibt es eine Möglichkeit alle "notifizierten" Bereiche anzuschucken, die ein Reading mit namen "lastused" haben? Wenn ja, würde ich mich über ein Beispiel oder eine Info freuen wo ich sowas finde.

Nochmal dickes Danke.

So eine Art:
trigger *:lastused quatsch

Idee - ein notify mit dieser DEF :
global:INITIALIZED set ManualUseTemp [ManualUseTemp:state]

das könnte man vielleicht globalisieren mit einem passenden .*:FILTER ....

auch wenn du es vermutlich nicht einsehen magst: 99% deiner probleme kommen genau von deinem vorgehen mit manuell editieren, include, rereadcfg, ...

lass fhem sich um sein config file kümmern und pfusch nicht zwischen rein. dann gibt es auch keine probleme.

Ist ja nett, wenn man hier gleich als Pfuscher bezeichnet wird. Und das von einem Entwickler.

@Otto123: Danke für die Info. Werd mal sehen wie man sowas macht.
@DeeSPe: Dir natürlich auch Danke.

Falls mal jemand das gleiche Problem hat, ich habe das auf folgende Weise gelöst:

define InitJob notify global:INITIALIZED|REREADCFG {\
  fhem("trigger ManualUseTemp ?");;\
  # --- und weitere  \
}

Damit werden die Daten auch nach einem "rereadcfg" oder Neustart (oder "shutdown restart") angezeigt. Man muß halt alle eintragen, die so konfiguriert worden sind.

Zitat von: der-sigi am 07 März 2019, 17:47:39
Ist ja nett, wenn man hier gleich als Pfuscher bezeichnet wird. Und das von einem Entwickler.

Niemand hat Dich hier als Pfuscher bezeichnet!!!
Dir wurde lediglich anhand mehrerer Beispiele aufgezeigt woher Deine Probleme kommen können.
Diese können ganz leicht umgangen werden wenn man die integrierten Möglichkeiten von FHEM benutzt (die von einem langjährigen Entwickler vorgeschlagen werden) anstatt hartnäckig sein eigenes Ding durchziehen zu wollen.

Zitat von: justme1968 am 07 März 2019, 17:12:30
auch wenn du es vermutlich nicht einsehen magst: 99% deiner probleme kommen genau von deinem vorgehen mit manuell editieren, include, rereadcfg, ...

lass fhem sich um sein config file kümmern und pfusch nicht zwischen rein. dann gibt es auch keine probleme.

Gegen Beratungsresistenz kann man als FHEM Entwickler auch nicht viel tun.

Gruß
Dan

Hallo DeeSpe

was geht denn jetzt ab!?

1) justme1968 schrieb unter anderem:

Zitatund pfusch nicht zwischen rein

Wenn ich in meinen alten Tagen noch richtig deutsch kann, heute verändert man ja so gerne, dann ist das eine eindeutige Bezeichnung für Pfuscher. Also ist Dein Einwand nicht korrekt.

2) Ich hatte geschrieben, daß ich mit der Klickerlösung von FHEM nicht klarkomme (ich komme aus einer anderen Generation wo es noch keine KlickerProgrammierung gab) und daß das mir immer die Konfiguration zerhaut (für mich ein no go). Zudem bietet FHEM ja explizit beide Möglichkeiten an. Warum also nur die Klickerlösung!?

3) Deine Unterstellung

Zitatanstatt hartnäckig sein eigenes Ding durchziehen zu wollen

finde ich nicht ganz fair. Warum muß das sein. Ich habe nur vermittelt, wie auch hier, daß die Klickerlösung für mich nicht in Frage kommt. Was hat das mit hartnäckig und eigenes Ding zu tun? Die Konfiguration in den Konfigurationsdatei(en) machen viele andere auch so, ja sogar Entwickler, wie ich schon gelesen habe. Warum muß man einen da gleich so negativ darstellen!? Das Gleiche gilt für die Unterstellung der

ZitatBeratungsresistenz

Warum so feindselig. Ich habe Euch nichts getan. Ich hatte Fragen. Ich bekam Antworten. Und ich habe mich gerne dafür bedankt. Warum so ein Nachsatz!? Und warum auch noch zwei Wochen nach meiner gelöst Meldung. Warum kann man sich nicht auf die Fragen konzentrieren anstatt emotional irgendwas aufzuheizen?

Viele Grüße
in der Hoffnung auf besseres ForenWetter
Sigi

Hallo Sigi,

das hat nichts mit Feindseligkeit zu tun und hier soll auch nichts emotional aufgeheizt werden.
Ich wollte Dich nur darauf hinweisen dass es "Dienstältere" gibt (die auch noch Programmierer für FHEM sind), die Dir gute Ratschläge mitgeben wollen.
Mag sein dass Du es schöner findest selbst in der fhem.cfg zu editieren, dies hebelt aber alle Kontrollmöglichkeiten von FHEM selbst aus.
Auch ich habe schon diverse Module für FHEM entwickelt und jede Menge Zeit dafür aufgebracht alle möglichen Fehleingaben (z.B. beim Setzen von Attributen) abzufangen. Eben genau diese "Mechanismen" hebelt Dein manuelles Editieren komplett aus und somit musst Du Dich nicht wundern wenn nach so einem Editieren FHEM eben nicht mehr startet und Du dann mühevoll nach dem Problem suchen musst. Dann wird (erfahrungsgemäß) noch das angebliche Problem im Forum gepostet und auf eine Antwort vom Entwickler (oder anderen Usern) gewartet. Das müsste alles nicht sein, denn die meisten Entwickler haben schon das entsprechende "Gehirnschmalz" beim Entwickeln in das Abfangen von Fehlern gesteckt.

Denkst Du tatsächlich dass ich als Entwickler mit einer "Klickoberfläche" besser zurecht komme als mit einem Editor? Ganz sicher nicht. Trotzdem benutze ich die internen Mechanismen von FHEM um genau solchen Problemen aus dem Weg zu gehen, denn ich habe eingesehen (auch als Entwickler) dass man unbeabsichtigt Fehler machen kann.
Und wenn Du die "Verantwortung" für die fhem.cfg ganz bei FHEM lässt, können Dir auch Deine eventuell in der fhem.cfg gemachten Kommentare egal sein. Es gibt übrigens auch in jedem FHEM Device das Attribut "comment", welches eben für entsprechende Kommentare zum Device benutzt werden kann.

Wenn Du meine Aussagen als feindselig empfindest, dann tut es mir leid, so war es ganz sicher nicht gemeint.
Es ging mir darum "Best-Practices" zu vermitteln.

Gruß
Dan

P.S. Ja, manchmal schaue ich auch noch 2 Wochen später wieder mal in Beiträge in denen ich jemanden geantwortet habe. Meist weil nach Lösungsvorschlägen keine Antworten mehr kommen. Das trifft jetzt nicht auf Dich zu.

Hallo DeeSpe

ich nehme mal Deine Entschuldigung an, auch wenn Du das nicht explizit ausgedrückt hast.   ;)
Es war trotzdem nicht die feine Art wie man miteinander umgeht.

Aber mal ein Vorschlag: Wie wäre es, wenn mal statt (immer) nur auf das "Hände weg von der Konfiguration" Information ein konstruktiver Beitrag kommen würde und meinen Fall als "Klickerlösung" beschreibt? Das wäre doch ein erhebliches Plus für Leute, die mit der "Klickeroberfläche" Probleme haben (wie ich), oder?

Außerdem: Es ging NICHT um ein nicht starten von FHEM oder Problemen. Es ging bei meinem Beitrag NUR um eine Darstellung, die ich gerne hätte und die mit meinem Wissen nicht funktioniert hat. Da habe ich tolle Antworten (auch von Dir) bekommen, die mir weitergeholfen haben. Wofür ich mich auch bedankt habe. Es ging auch in keiner Weise um Klicker- oder direkter Konfiguration. Dies hat erst justme1968 mit seinem Einwurf losgetreten. Konstruktiv war das keinesfalls.

Viele Grüße
Sigi