FHEM Programmierung Urschleim

[Deckoffizier]

Hallo,

möchte mal eine Frage an die erfahrenen FHEM Nutzer stellen die mich schon von Anfang an um treibt.
Sachen die FHEM selber betreffen werden hier soweit ja bestmöglich abgehandelt aber für mich sitzt das Problem aber eigentlich schon weit vorher.

Einfache Sachen wie nur eine Steckdose oder Lampe an und aus kann man ja noch so aus dem "Stehgreif" machen

aber

wenn es komplexer wird mit vielen Abhängigkeiten und Verriegelungen wie Heizprogramm mit manuell und autom. Steuerung und Fensterkontakte  Temp. Absenkung und und.
Wie geht Ihr an die Sache ran, welchen Modulen den Vorzug geben, gibt es da eine Art Flussplan Zeichnung sorry bin Laie wenn ich so naiv Frage aber meine Heizungssteuerung hatte mich schon paar graue Haare gekostet bis es mit Versuch und Irrtum bis zum Erbrechen lief. Ich weiß ist die falsche herangehensweise.
Knifflig ist auch für mich in Übereinstimmung zu bringen, dass die Elemente in der Webansicht das Selbe zur Ansicht bringen wie der Programmcode a la card update wie in einer Datenbank.

Danke für eine konstruktive Antwort sagt der schon etwas betagte

Hans-Jürgen

[franky08]

Hallo, da schwören viele User auf DOIF, andere, wie ich z.B. löse solch komplexe Sachen mit Perl in der 99_myUtils.

VG
Frank

[igami]

Also ich nehme mir immer erst einen Zettel und schreibe auf was es alles gibt und spiele dann in gedanken durch was passiert bei event x und bedingungen yz

[Deckoffizier]

Hallo franky08,

da sind wir wider mal aneinander vorbei 

Im Kern geht es mir was davor kommt eine Art Flussplan ??

Mit den ganzen wenns und aber zB. wenn z.B. Fenster Offen dann darf Temperatur Button nicht klickbar sein und auf 12°C wechseln. Die Heizautomatik zum Schaltpunkt 18 Uhr darf
dies nicht überschreiben, ich weiß Heating Control hat hierfür die Lösung dies im Optionsteil zu setzen. Aber gibt ja noch mehr.

Deswegen auch meine Frage die Anzeigeebene stimmig in Übereinstimmung mit dem Code zu bringen.

Gruß
Hans-Jürgen

[Deckoffizier]

Hallo igami,

gut da kommen wir der Sache schon näher Deine Antwort geht für mich in die richtige Richtung!!

Bloß ja nichts übersehen das sich Fehler einschleichen können, gibt es dafür Tools die einem das erleichtern ?
Ganz tief im Gedächtnis hatte ich mal so was in Erinnerung bei Basic Programmen mit Kästchen Dreiecken Flusspfeilen oder so ?

Was ist bei gleichzeitigen Events Temperaturerhöhung um 18 Uhr durch Heating Control und Fensteröffnung um 18 Uhr =Temperaturabsenkung wer ist der Gewinner.

Gruß
Hans-Jürgen

[igami]

Bloß ja nichts übersehen das sich Fehler einschleichen können, gibt es dafür Tools die einem das erleichtern ?
Ganz tief im Gedächtnis hatte ich mal so was in Erinnerung bei Basic Programmen mit Kästchen Dreiecken Flusspfeilen oder so ?

Zettel und Stift helfen mir sehr

Was ist bei gleichzeitigen Events Temperaturerhöhung um 18 Uhr durch Heating Control und Fensteröffnung um 18 Uhr =Temperaturabsenkung wer ist der Gewinner.

Gleichzeitig gibt es nicht

[franky08]

Na dann Zettel und Stift...

[igami]

Flussdiagramm sollte das sein was du meinst. Da gibt es ja sogar eine DIN zu. Wenn du nun google bemühst und dort 'Flussdiagramm' mit dem Wort 'Tool' und vielleicht noch 'Linux' oder 'online' oder 'Windows 10' kombinierst wirst du sicher etwas finden.

[Deckoffizier]

Hallo igami

Danke igami ja so was waberte noch noch in meinem Haupt umher 

Wenn es erlaubt sei  Indiskrete Frage benutzte Du dies bei den Problemlösungen in FHEM oder bekommst Du durch Erfahrung Wissen es so auf die Reihe ?
Eventuell Alternativen.
Lasse es für mich dann erst mal gut sein....

Gruß und nochmals Danke Euch Hans-Jürgen

[igami]

Wie gesagt Zettel und Stift. Manchmal kommt da auch eine Art Flussdiagramm raus, aber das dürfte nicht nach DIN sein.

[Thorsten Pferdekaemper]

Hi,
interessanter Thread, mal sehen was daraus wird.

wenn es komplexer wird mit vielen Abhängigkeiten und Verriegelungen wie Heizprogramm mit manuell und autom. Steuerung und Fensterkontakte  Temp. Absenkung und und.
Wie geht Ihr an die Sache ran, welchen Modulen den Vorzug geben, gibt es da eine Art Flussplan Zeichnung

Etwas fertiges oder eine irgendwie aufgeschriebene Methodik gibt es ziemlich sicher nicht. Mein persönlicher Ansatz ist, irgendwo anzufangen und dann nach und nach Sachen einzubauen. Dabei fängt man mit dem an, was einem am wichtigsten ist. Es kann dann natürlich passieren, dass man einiges wieder umbauen muss, aber man hat inzwischen ja einen gewissen Lernprozess hinter sich, so dass das Umbauen nicht so das große Problem ist.

Jetzt zu dem Thema "welche Module":
Ich gehe mal davon aus, dass wir nicht über die Auswahl der Hardware reden. D.h. die Module, die die physikalischen Geräte in FHEM abbilden, sind einigermaßen klar. Ich meine damit: Mit dem FS20-Modul kann man kein Homematic steuern.
Es bleiben also so Sachen wie at, notify, DOIF, THRESHOLD, PID20 usw. Hier kann man mal die komplette Commandref durchzugehen. Die "Hardware-Module" kann man natürlich weglassen. Dabei kann es gut sein, dass einem etwas auffällt, was man brauchen kann.
Ansonsten mache ich es so: Was zu einem bestimmten Zeitpunkt oder immer wieder passieren soll: at. Was abhängig von einem Ereignis ist: notify. Bei allem komplexeren: Mal commandref durchsehen oder im Forum fragen. (Ich habe jetzt DOIF weggelassen, weil ich von mir rede. Andere schwören auf DOIF.)
Jetzt kommt es natürlich auch darauf an, was man schon kennt. Ich selbst schreibe z.B. lieber mal ein paar Zeilen Perl-Coding hin als stundenlang nach dem perfekt geeigeneten Modul zu suchen.
Ach ja, noch etwas: Oft können die Geräte selbst schon einiges. Bei Homematic (Wired oder Funk) geht z.B. einiges per direktem Peering. Da kann man sich einiges an Modul-Suche und auch Server-Prozessorzeit sparen. 

sorry bin Laie wenn ich so naiv Frage aber meine Heizungssteuerung hatte mich schon paar graue Haare gekostet bis es mit Versuch und Irrtum bis zum Erbrechen lief. Ich weiß ist die falsche herangehensweise.

Warum ist das falsch?

Im Kern geht es mir was davor kommt eine Art Flussplan ??

Ich denke, dass die typischen Programmablaufpläne da nicht so ganz geeignet sind. Die ganze Automatisierung ist recht stark ereignisgesteuert. Das würde den eher Petri-Netze oder sowas geben. Aber das Zeugs ist dann auch kompliziert.

Mit den ganzen wenns und aber zB. wenn z.B. Fenster Offen dann darf Temperatur Button nicht klickbar sein und auf 12°C wechseln. Die Heizautomatik zum Schaltpunkt 18 Uhr darf
dies nicht überschreiben,

Auch hier: Erst einmal klein anfangen und dann eins nach dem anderen einbauen. Man kann sich das auch alles auf einmal überlegen, aber das kann schwierig werden. Wenn, dann sollte man sich überlegen, in welchen Zuständen der zu modellierende Teil des Systems sein kann und welche Ereignisse zu welchen neuen Zuständen führen sollen.

Deswegen auch meine Frage die Anzeigeebene stimmig in Übereinstimmung mit dem Code zu bringen.

Das habe ich noch nicht ganz verstanden. Das kommt doch stark auf Dein UI an, oder?

Gruß,
   Thorsten

[Deckoffizier]

Hallo Thorsten

schön das Du Dir die Zeit genommen hast für die Langen Ausführungen !
Ja Thema Module ist klar es waren von mir die Software Module gemeint ist also erst mal Geschmackssache ohne jetzt in den DOIF Thread zu wechseln 

Na Versuch und Irrtum ist ja eben nur stümperhaft statt aus Wissen welches mal gelernt bekommen hat anzuwenden.
Was habe ich mich bis jetzt dumm angestellt um hinter zu kommen was bedeutet erstmal .* einfaches Anführungszeichen, Gänsefüßchen Klammer so wieder andere Klammer %1f und und, natürlich ist noch kein Meister vom Himmel gefallen und man auch hochbetagt noch lernwillig und liest sich ein, deswegen ist probieren nicht die effektivste Methodik für mich.

Von Vorpostern kam der Hinweis erstmal  events und Bedingungen zu erfassen, na ja in meiner Gedanklichen Unschuld denkt man da erst mal an eine Tabellarische Verknüpfung duck und weg.

Dies von Dir Geschriebene trifft eigentlich des Pudels Kern !

Auch hier: Erst einmal klein anfangen und dann eins nach dem anderen einbauen. Man kann sich das auch alles auf einmal überlegen, aber das kann schwierig werden. Wenn, dann sollte man sich überlegen, in welchen Zuständen der zu modellierende Teil des Systems sein kann und welche Ereignisse zu welchen neuen Zuständen führen sollen.

Was ich meine mit der Anzeige Ebene(visuell)  ist der Code z.B. Temperaturregelung oder Licht an/aus funktioniert richtig aber das sichtbare im UI stimmt nicht überein am einfachsten sichtbar beim hier mal beispielhaft genannt Lampen Icon. Geht in Richtung eventMap stateFormat wird so etwas besser verständlich ?

Gruß
Hans-Jürgen

[DeeSPe]

Hallo Hans-Jürgen,

gerade weil der (erweiterte) Einstieg, also wenn es über manuelles Licht an und aus hinausgeht, in FHEM für viele Anfänger so komplex ist, habe ich versucht so allgemeine Sachen, die eigentlich jeder in seiner Automation irgendwann umsetzt, in ein möglichst einfach zu bedienendes Modul zu stecken.
Da sich die Komplexität einer Automation mit dem Hinzukommen von nur einem Sensor aber schlagartig erhöhen kann, ist es denke ich gar nicht so verkehrt dass in einer Art PAP (Programmablaufplan) oder auch Flussdiagramm festzuhalten bzw. vorauszuplanen. Das wiederum macht m.E. aber eben erst Sinn wenn man mit FHEM bereits gut vertraut ist und alle möglichen Kniffe bereits kennt.
Ansonsten bleibt nur der gute alte "Trial & Error" Weg! Auch ich habe diesen beschritten, denn wie immer war aller Anfang schwer. Und mit zunehmendem Wissensstand erhöhte sich auch die Komplexität.
Gestern noch erfolgreich was umgesetzt und heute neues Wissen und neue Methoden kennengelernt und schon fängt man wieder an das bereits Funktionierende wieder umzubauen, weil es mit dem neuen Wissen wieder komfortabler wird.
Als ich im Januar 2016 mit FHEM begonnen habe, dachte ich ich würde mir nur ein paar Sachen per Siri einrichten und gut ist's!
Aber denkste! Damals hätte ich mir nie erträumen können mal selbst zu programmieren, geschweige denn mal selbst Module zu FHEM beizusteuern! Vor einem Jahr wußte ich noch nicht mal wie man Perl (Pearl??) richtig schreibt!!!!!
Ich denke wenn man echt Bock auf individuelle Automatisierungslösungen hat, dann kommt man nicht drum herum sich geeignetes Wissen anzunehmen. Ob und welche Tools man dafür einsetzt ist dann einem selbst überlassen.

Allgemein vertrete ich aber auch die Meinung: Klein anfangen und die Komplexität Stück für Stück steigern.

Gruß
Dan

P.S. Einen Nachteil hat der Automatisierungswahn aber! Die Zeit!!!! Mittlerweile ist FHEM zu meinem Haupt- und Lieblingshobby geworden und verschlingt damit immense Zeit.

[Thorsten Pferdekaemper]

Von Vorpostern kam der Hinweis erstmal  events und Bedingungen zu erfassen, na ja in meiner Gedanklichen Unschuld denkt man da erst mal an eine Tabellarische Verknüpfung duck und weg.

Ja, warum keine Tabelle? Wenn einem das liegt? Andere brauchen halt irgendwas mit Kringeln und Pfeilen.

Was ich meine mit der Anzeige Ebene(visuell)  ist der Code z.B. Temperaturregelung oder Licht an/aus funktioniert richtig aber das sichtbare im UI stimmt nicht überein am einfachsten sichtbar beim hier mal beispielhaft genannt Lampen Icon. Geht in Richtung eventMap stateFormat wird so etwas besser verständlich ?

Achso. Naja, das würde ich erstmal links liegen lassen. Vielleicht die Geräte in Gruppen und Räume einsortieren, aber das war's. Wenn man ein schönes UI will, dann rate ich eher zum TabletUI.
Gruß,
   Thorsten