devStateIcon auf Readings

Begonnen von noanda, 10 November 2014, 23:41:20

Vorheriges Thema - Nächstes Thema

justme1968

#30
das problem ist aber doch eher das es falsch ist auf STATE zu reagieren. zumal es als internal überhaupt keine events erzeugt.

richtig wäre es auf readings zu reagieren. nicht umsonst erzeugen diese auch events.

STATE ist eigentlich nur für die darstellung in fhemweb. nicht um es in einer automatisierung weiter zu verarbeiten. nicht umsonst ist fhem event basiert.

unabhängig davon: nein, man muss nicht die quelltexte lesen um fhem zu verstehen. ein paar konzepte, wie z.b. die events, reichen. das manche erweiterungen wie z.b. leider auch das DOIF versuchen den anwender von den grundlegenden konzepten abzuschirmen bzw. noch etwas drauf setzen das zwar ähnlich ist aber dann doch nicht genau so ist leider nicht hilfreich. einfach ist nicht immer besser.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

swsmily

Zitat von: Beta-User am 28 November 2019, 07:23:36
Ja, Perl-Variante von devStateIcon nutzen. Das verändert STATE nicht.

Danke, dieser kleine Anstoß hat mir gereicht um genauer nach weiteren Infos zu suchen und ich habe es nun so gelöst bekommen, wie ich es für mich brauchte.


Zur Allgemeinen Diskussion: Für Einsteigern ist FHEM sicherlich sehr sehr kompliziert. Man muss eben klein Anfangen, sehr viel nachlesen und so dann verstehen.
Einen Überblick über sämtliche Funktionen, Module usw. kann man fast gar nicht mehr haben. Oft genug ist es mir schon passiert, dass ich Lösungen gesucht habe, es auch geschafft habe, dass alles so funktioniert wie es soll - und paar Wochen später stoß ich zufällig auf ein ähnliches Problem, dass z.b. durch ein Modul viel einfacher zu lösen gewesen wäre.
Aber genau das finde ich, ist das tolle an FHEM und der Community. Das System ist so offen für alles mögliche und die Community ist einfach nur Spitze, sei es bei sich immer wiederholenden Fragen, bei echten Schwierigkeiten, Feature-Wünschen in Modulen oder generell die Weiterentwicklung.
Ich bin froh, dass ich auf FHEM gesetzt habe und nicht auf eine fertige, einfache Lösung, die vielleicht sogar noch Geld kostet, aber bei weiten nicht so viel könnte.
Gerade in meiner Anfangszeit hatte ich viele viele Fragen, aber mit Hilfe von Google, CommandRef, Forum und auch YouTube-Videos lernt man FHEM schnell kennen finde ich. Auch wenn ich kein Perl programmieren kann (allerhöchstens Codeschnippsel zusammenkopieren und für mich anpassen  ;D)

Btw: Ich nutze überwiegend DOIF, weil es das "komplizierte" FHEM für mich einfacher macht als Notifys zu nutzen.

Beta-User

Zitat von: swsmily am 28 November 2019, 16:12:34
Danke, dieser kleine Anstoß hat mir gereicht um genauer nach weiteren Infos zu suchen und ich habe es nun so gelöst bekommen, wie ich es für mich brauchte.
Danke für die Rückmeldung.

Ansonsten klingt das für mich so, als würdest du genau immer wieder in das von justme1968 genannte Problem reinlaufen, dass DOIF (scheinbar) alles einfach möglich macht, du dir den Wolf konfigurierst, bis es (halbwegs) so funktioniert, wie du das vorstellst und dabei übersiehst, dass es für viele "Standardfälle" kleine "Spezialisten" gibt, die bestimmte typische Anwendungsfälle (meistens viel einfacher) abdecken.

Man mag darüber denken, was man will, aber ich für meinen Teil bin froh, dass ich kein DOIF mehr im Einsatz habe; ich bin einfach zu doof für die Syntax, die dieses Modul haben will, und bin früher gefühlt immer wieder in irgendeine Falle gelaufen, nicht selten, ohne das gleich zu merken. (Apropos Syntax: Vermutlich reagiert das fragliche DOIF nicht wegen STATE, sondern auf ein Event von state..., aber das ist pure Spekulation.)
Zwischenzeitlich nutze ich eben für alles mögliche event-basierte in der Regel eine notify+Perl-Variante. Finde ich deutlich übersichtlicher, und meistens macht das dann tatsächlich irgendwann das, was ich will (und in der Regel versuche ich, generalisierte Varianten zu nutzen, also z.B. nur noch ein (kurzes) notify für alle Fenster-open/tilt/closed-Events).
(Und nein, ich konnte früher weder programmieren, noch hatte ich einen Schimmer von Perl (ob das jetzt in den Augen wirklicher Experten wesentlich besser ist, sei mal dahingestellt). FHEM kann man m.E. jedenfalls ohne DOIF aber auch dann nutzen, wenn man bei beidem nur rudimentäre Kenntnisse hat; es reicht, wenn man Kausalitäten zwischen Ursache und Wirkung nachverfolgen kann).

Ich kann mich daher nur der Empfehlung von justme1968 anschließen, sich als FHEM-Nutzer auch und vor allem erst mal mit den grundlegenden Mechanismen zu beschäftigen. Persönlich finde ich auch den Rahmen der commandref immer wieder aufschlußreich: https://fhem.de/commandref_modular_DE.html. Überfliegt man das jeden Monat ein Mal, macht man vermutlich nichts falsch und findet immer wieder was, was man brauchen kann...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wzut

Zitat von: Beta-User am 28 November 2019, 16:58:57
ich bin einfach zu doof für die Syntax, die dieses Modul haben will
da bin ich aber froh das ich genau mit diesem Problem doch nicht sooo alleine bin :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 28 November 2019, 17:16:21
da bin ich aber froh das ich genau mit diesem Problem doch nicht sooo alleine bin :)
Da gibt's noch einige mehr ;D ...

Aber wenn man die Syntax drauf hat, scheint es das zu machen, was es soll. An sich also eine echt gewaltige Leistung des Entwicklers, das sei mal an der Stelle ausdrücklich betont!

Ich bin da irgendwann mal vor ein paar Jahren gedanklich ausgestiegen, hatte dann noch ein paar halbherzige Versuche unternommen, und es dann irgendwann aufgegeben. Das waren mir zu viele via Attribut einstellbaren Verhaltensweisen, deren Wechselwirkungen scheinbar nicht mal Experten völlig klar zu sein schienen...
Dann war es einige Zeit still, bis ich mir dann den Ruck gegeben habe, alle DOIF wieder auszubauen. In 3/4 der gut 20 Fälle war das jeweils in wenigen Minuten erledigt, (WeekdayTimer, THRESHOLD, ein paar notify), bei ein paar hat es länger gedauert, aber das auch nur, weil ich zwischenzeitlich ein paar Ideen hatte, wie man das effizienter und generalisierter lösen könnte (auch mittels DOIF kann man generalisieren, ist schon klar).
Wie dem auch sei, der Rest war auch kein Hexenwerk und jetzt weiß ich jedenfalls (halbwegs), wie FHEM tickt und kann in der Regel auch ohne dieses Modul so eingreifen, wie ich das will, ohne groß rumzuraten ;D .

Aber lassen wir das, führt ja nicht weiter.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DasQ

Mir hat ja des doiftools auf die Sprünge geholfen. Teilweise hab ich aber auch nach längerer Pause auch einfach Knoten im Kopf und kapier erst aufn zweiten Anlauf, was ich schon zusammen gebastelt hab.

Und des ist auch mein tip, nehmt vorhandenes als Template

Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org