Automatisierung mittels State Machine

Begonnen von Eistee, 22 Februar 2018, 18:33:01

Vorheriges Thema - Nächstes Thema

Eistee

Hallo Comunity,

ich habe eine Idee wie man in FHEM Automatisierung auf das nächste Level bringen könnte.
Ich möchte gern ein neues Modul verwirklichen das mittels State Machine alles in FHEM Steuern kann. Und zwar wollte ich es stark an das DOIF Modul anhängen und so bauen das man dieses State Machine Modul nur 1x pro FHEM laden kann.
Die Visualisierung stelle ich mir so vor wie dies hier gemacht wird (https://state-machine-cat.js.org/) allerdings mit der möglichkeit dies grafisch zusammen zu klicken.

Es ist also so gedacht das man sich Module zusammen Baut und den Status weiter schalten kann bei einem Event.

Ablauf:







Pos.WasBeschreibung
1.ZustandEin Zustand "Lampe aus" ist aktiv.
2.Event (wie in DOIF)Ein Event "ich komme nach hause" wird ausgelößt.
2.1Bedingung (wie in DOIF nur ohne Event)zusätzlich ist die Bedingung "es ist schon dunkel" WAHR
4.Aktion (wie in DOIF)Der Zustand wechselt von "Lampe aus" zu "Lampe an"
4.1EventDurch den Zustandswechsel wird wieder ein Event ausgelöst was an anderer stelle verarbeitet werden könnte.

Das ganze soll dann so sein das man dies auch ineinander schachteln kann und soll auch nicht auf einen aktiven Stat beschränkt sein. Was man denke ich dann einbauen müsste ist ein Filter um das Bearbeiten zu erleichtern da so ein Konstrukt dann schnell sehr groß wird und man nicht immer alles sehen muss.

Ich habe vor zunächst den Editor für die State Machine zu entwerfen. Er soll grafisch funktionieren und eine textuelle Form der State Machine erzeugen. Andersherum soll er diese Textform auch wieder grafisch darstellen können und Filterung bei der grafischen Darstellung ermöglichen.
Der nächste Schritt ist dann das eigentliche FHEM Modul was wohl recht ähnlich zu DOIF im Backend aufgebaut werden müsste.

Ich hoffe ich konnte es so einigermaßen erklären. Nun möchte ich mal wissen was ihr davon haltet und ob es eventuell interessierte Programmierer hier gibt die lust hätten bei diesem "Projekt" mit zu machen.

LG Alina

rudolfkoenig

Nur zu, das Modul zum Bier brauen fehlt in FHEM seit vielen Jahren, auch wenn schon etliche Plaene und halbfertige Realisierungen gab.

Meiner Meinung nach ist ein grafisches Frontend eine interessante Uebung fuer den Programmierer, und ermutigt den unerfahrenen Anfaenger, ist aber hinderlich in einem aufwendigen Projekt. Aber womoeglich irre ich mich beim letzten Punkt.

Zitatso bauen das man dieses State Machine Modul nur 1x pro FHEM laden kann.
Ein Modul kann man auch jetzt nur einmal laden, aber es ist immer moeglich, mehrere Geraetedefinitionen des gleichen Modul-Typs anzulegen. Ich vermute, du moechtest nicht mehr als eine Definition anlegen, und ich verstehe z.Zt. noch nicht, warum das sinnvoll oder gar wichtig ist.

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Damian

#3
Zitat von: rudolfkoenig am 24 Februar 2018, 08:55:43
Nur zu, das Modul zum Bier brauen fehlt in FHEM seit vielen Jahren, auch wenn schon etliche Plaene und halbfertige Realisierungen gab.

Meiner Meinung nach ist ein grafisches Frontend eine interessante Uebung fuer den Programmierer, und ermutigt den unerfahrenen Anfaenger, ist aber hinderlich in einem aufwendigen Projekt. Aber womoeglich irre ich mich beim letzten Punkt.


sehe ich genauso, es wäre schön, wenn es klappen würde. Ich persönlich bin da skeptisch.

Ich gehe jetzt den umgekehrten Weg (ohne grafisches Frontend, für komplexere Projekte): ereignisgesteuertes Perl: https://forum.fhem.de/index.php/topic,84692.0.html
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

crusader

Zitat von: Eistee am 22 Februar 2018, 18:33:01
...
Die Visualisierung stelle ich mir so vor wie dies hier gemacht wird (https://state-machine-cat.js.org/) allerdings mit der möglichkeit dies grafisch zusammen zu klicken.

Es ist also so gedacht das man sich Module zusammen Baut und den Status weiter schalten kann bei einem Event.
...

Der Witz bei einem grafischen Entwurfstool für Statemachines besteht IMO darin, dass man die Maschine dann auch auf der grafischen Ebene simulieren kann, bevor man den endgültigen Code generiert.
Dieses Rad muss man aber nicht neu erfinden. Yakindu ist z. B. ein sehr leistungsfähiges Freeware-Tool.

Ich habe dazu mal ein Beispiel aus Yakindu manuell auf DOIF Code umgesetzt und festgestellt, dass DOIF eigentlich alle wesentlichen Eigenschaften für eine Statemachine besitzt.
https://forum.fhem.de/index.php/topic,49109.msg412377.html#msg412377

Schön wäre natürlich ein Code Generator, der aus Yakindu (oder einem anderen Tool) automatisch FHEM Code erzeugt - entweder für DOIF oder für das stateMachine-Modul von justme.

Gruß
crusader


justme1968

die herausforderung ist weder eine state machine zu implementieren noch ein grafisches frontend dafür zu bauen. die eigentliche schwierigkeit entsteht dann wenn man zulassen will das man sowohl per normalen fhem kommandos als auch per gui änderungen machen und dabei beliebig hin und her wechseln kann. fhem ist so mächtig das der rückweg aus bestehenden fhem code wieder die grafische darstellung zu machen nicht in jedem fall sinnvoll möglich ist.

und wenn genau dieses hin und her nicht möglich ist verliert so ein tool/frontend seine nützlichkeit wenn man über die ersten schritte hinaus ist.

das ganze ist zwar eine schöne idee und arbeit aber in der praxis eher unhandlich bis unnütz wenn man fhem wirklich voll nutzen möchte.

ps: ich habe zwar für meine state machine kein frontend gebaut aber habe es mal mit blockly ganz allgemein für fhem versucht. und das scheitert genau am gleichen problem. jedenfalls wenn es wirklich nützlich sein soll. und dann ist es nebenbei noch ziemlich unhandlich weil es eine heiden klickerei ist selbst einfache abläufe zusammen zu bauen.

bevor du also viel zeit in das frontend investierst schau dir erst mal an ob du einen du funktionierenden ansatz hast zwischen gui und kommandozeile hin und her zu wechseln.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

crusader

Zitat von: justme1968 am 24 Februar 2018, 15:11:00
die herausforderung ist weder eine state machine zu implementieren noch ein grafisches frontend dafür zu bauen. die eigentliche schwierigkeit entsteht dann wenn man zulassen will das man sowohl per normalen fhem kommandos als auch per gui änderungen machen und dabei beliebig hin und her wechseln kann. fhem ist so mächtig das der rückweg aus bestehenden fhem code wieder die grafische darstellung zu machen nicht in jedem fall sinnvoll möglich ist.

Ist klar.
Code Generatoren haben ja nicht den Sinn, einen Entwurf bereitzustellen, den man anschliessend manuell verbessern muss.
Wer sich auf Autocode einlässt, muss sich halt auf die Möglichkeiten des Generators beschränken.

Bei Statemachines machen sie aber durchaus Sinn, weil man bei manueller Codierung schnell mal Lücken bei den State
Übergängen übersieht oder widersprüchliche Bedingungen formuliert. Solche Fehler lassen sich per Simulation vorab finden und korrigieren.

Die vielen FHEM User, die ihre zusammengestrickten Spaghetti-Machines hier reinstellen mit der (verzweifelten) Frage "Warum schaltet meine Lampe nicht ?", zeigen ja diese Problematik.

Prof. Dr. Peter Henning

Erstens: Dass viele (insbesondere Anfänger) mit ihren einfachen Zustandsautomaten Fehler machen, ist kein Grund, dafür ein komplexes Simulations- und Visualisierungswerkzeug zu bauen. Das Problem steckt dabei nämlich nicht im Code, sondern zwischen den Ohren der User, die erst einmal lernen müssen, mit solchen Dingen umzugehen. In einem sinnvollen konstruktivistischen Lernermodell heißt das: Sie müssen Fehler machen und diese debuggen.

Zweitens: Ich war seinerzeit sehr skeptisch bezüglich des Versuches, ein Modul für beliebige Zustandsautomaten zu bauen. Ohne Schadenfreude stelle ich fest, dass ich damit durchaus richtig lag.

Drittens: In der Forschung ist das Thema  schon seit vielen Jahren ad acta gelegt worden, weil ein solches Modul im Prinzip einer Abbildung zwischen zwei Zustandsautomaten entspricht. Dafür gibt es, wie Alan Turing schon in den 1930er Jahren zeigte, keinen allgemeinen Algorithmus - und spezielle Algorithmen werden mit zunehmender Anzahl der Zustände extrem komplex. Das hat ganz einfach damit zu tun, dass die Zahl der möglichen unterschiedlichen Automaten bei gegebener Zustandsanzahl so stark wächst, siehe z.B. https://de.wikipedia.org/wiki/Flei%C3%9Figer_Biber#Praktische_Betrachtung für eine kleine Einführung in das Problem.

Also: Gute Idee, aber nicht sinnvoll realisierbar.

LG

pah

crusader

Die Erkenntnisse von Turing lassen keineswegs die Schlussfolgerung zu, dass es keine standardisierten Entwurfstools für Automaten geben kann.
Ansonsten würde die Firma Mathworks wohl kaum soviel Geld für ihr Stateflow-Modul verlangen (und die Firma dSpace für einen passenden Codegenerator).

Allerdings ist die Komplexität dieser Tools schon recht groß. Daher ja mein Vorschlag, sich an ein Freewaretool dranzuhängen und die dafür bereits existierenden Codegeneratoren auf Perl umzuschreiben. Der generierte Code könnte nach meinem Verständnis von dem neuen DOIF(Perl) ausgeführt werden.

Ob eine solche Toolchain in der FHEM-Welt viele Anwender finden würde, ist natürlich eine andere Frage.

Prof. Dr. Peter Henning

ZitatDie Erkenntnisse von Turing lassen keineswegs die Schlussfolgerung zu, dass es keine standardisierten Entwurfstools für Automaten geben kann.

Das hat auch niemand behauptet, bitte einfach mal etwas genauer lesen, was ich geschrieben habe. Oder mal einen Blick in meine Vorlesung "Semantic Web Technologies" werfen...

Turing kommt ins Spiel, weil - wie André richtig ausgeführt hat - eigentlich zur sinnvollen Bedienung eine bijektive Abbildung zwischen dem existierenden Code und dem grafischen Werkzeug nötig ist.

Darüber hinaus ist es seit vielen Jahren nachgewiesen, dass bei höherer Komplexität die erzeugten Codes oft nicht nur ineffizient sind, sondern ebensoft fehlerhafte Teile enthalten. Vor zehn Jahren habe ich eine sehr schöne Master Thesis betreut, in der wir durch eine Inferenzmaschine solche Fehler aufspüren konnten.

Aber, nur zu, ich will niemanden hindern, seine Lebenszeit zu verschwenden.


pah

crusader

Da scheint wohl ein grundsätzliches Verständnisproblem für den Begriff 'Codegenerierung' vorzuliegen.

Bei diesem Prozess wird lediglich aus einer grafischen Vorlage (herkömmlicher) Programmcode generiert. Eine Weiterbearbeitung auf Textebene mit entsprechender Rücktransformation ist bei diesen Tools nicht vorgesehen.

Insofern führt der Begriff der 'bijektiven Abbildung' hier in die Irre.

Natürlich muss der Tool-Hersteller gewährleisten, dass der erzeugte Code die gleichen Ergebnisse liefert wie das simulierte Eingabemodell.
Das gelingt der IT-Industrie heutzutage mit erstaunlicher Zuverlässigkeit, möglicherweise weil sie sich nicht auf Master-Thesen beschränkt und keine Semantikvorlesung deutscher Fachhochschul-Professoren zu Rate zieht.

Prof. Dr. Peter Henning

ZIemlich dick aufgetragen für 77 eigene Beiträge - und über das Textverstehen schweigen wir.

Der sollte sich einfach eine andere Spielwiese suchen, hier wird er nicht alt.

pah


vbs

Nicht dass ich mich einmischen will, aber ich kannte mal Foren, die propagierten etwas was sich "Netiquette" nannte. Kein Scherz: eine Regel, die es da gab, war sinngemäß "wer in einer Argumentation den Post-Count des Gegenübers ins Feld führt, der hat automatisch verloren" :)

Eistee

Hi ich mal wieder. Habe mir natürlich auch gedanken gemacht wie man so eine grafische State Machine speichert und einigermaßen auch in textform lesbar und verarbeitbar macht. ich bin dabei auf SCXML (https://de.wikipedia.org/wiki/SCXML) gestoßen das als XML Format auch ganz easy in JSON und ähnliches umwandelbar ist. Vielleicht gibt es ja von euch noch ideen was geeignet wäre. Ich habe auch schon einige renderer gefunden wobei ich aber denke das man das grafische auf FHEM im speziellen anpassen muss um so auch die Limits zu setzen was man eingeben kann.

Freue mich über weitere Konstruktive Diskussionen zu dem Thema.

Gruß Alina

Prof. Dr. Peter Henning

Na Prima, zum selbst ernannten Experten kommt auch noch ein selbst ernannter Schiedsrichter.

Nun, dann eben einfach selbst machen, und ich lehne mich in Ruhe zurück und sehe mir das Ergebnis an.

pah

HubertM

"Ziemlich dick aufgetragen für xx eigene Beiträge" ist doch seine neue Masche  ;)

Prof. Dr. Peter Henning

Na, damit wären es dann schon 8. Das nennen wir konstruktiv.

pah

crusader

Zitat von: Eistee am 27 Februar 2018, 23:46:09
ich bin dabei auf SCXML (https://de.wikipedia.org/wiki/SCXML)

...
Freue mich über weitere Konstruktive Diskussionen zu dem Thema.

Hallo Alina,

Ein Grafik-Frontend für Statechart-Entwicklung mit SCXML Ausgabe brauchst Du nicht zu schreiben.
Das gibt es schon:
https://www.itemis.com/en/yakindu/state-machine/documentation/examples/example/scxml.generator

Die Herausforderung besteht IMO eher darin, ein FHEM-Modul zu entwickeln, das eine solche Beschreibung in FHEM ausführbar macht.

Wenn man sich die diversen eingeschlafenen Threads zum Thema Statemachine anschaut, scheint das Interesse daran aber nicht allzu groß zu sein. Ob sich der Aufwand dann lohnt, musst Du halt selber beurteilen.

Gruß
crusader

Prof. Dr. Peter Henning

Noch einmal: Das ist keine Frage des Interesses, sondern der praktischen Realisierbarkeit.

LG

pah

crusader

Zitat von: Prof. Dr. Peter Henning am 28 Februar 2018, 19:04:30
Noch einmal: Das ist keine Frage des Interesses, sondern der praktischen Realisierbarkeit.

LG

pah

Wer in diesem Land ein nicht allzu bejahrtes Automobil fährt, beweist täglich das Gegenteil.

Die Automobilindustrie setzt nämlich seit mindestens 10 Jahren auf modellbasierte Entwicklung und Autocoding.
Hier mal ein Link auf das Tool, das bei Daimler bevorzugt eingesetzt wird:
https://de.mathworks.com/products/stateflow.html

Einfach mal das Video anschauen.
Da gibt's auch günstige Lizenzen für Studenten.

Gruß
crusader

Lorenz

Die letzten 10 Jahre bei Daimler - jetzt wird mir klar, warum ich in dieser Zeit so oft mit meinen Autos in der Werkstatt wegen Software-Fehlern war.

Duck und weg ...  ;)

LG
. . . . . .
Fhem auf NUC7i3BNH, Raspberry Pi B und B+, Raspberry Pi 2 B, Peripherie: FB7490, 1-Wire, Homematic, FS20, Lampen, Briefkasten, Klingel, Sonos, GardenaSmart, Unifi, Gaszähler an GPIO, Stromzähler EFR SGM-C4, Heizung Buderus GBH 172, Alarmanlage EMA und BMA von Bosch

crusader

Dann handelt es sich bei Deinem Fahrzeug wahrscheinlich um eine Produktfälschung.

Preiswert im Internet erstanden ?

Prof. Dr. Peter Henning

Nur zu, selbst ist der Mann. Oder sollte hinter den flotten Sprüchen nur heiße Luft stecken ? Der Gegenbeweis muss noch erbracht werden.

pah

JoWiemann

Vielleicht etwas Off Topic, aber für mich kumulieren diese und auch andere immer wieder geführte Diskussionen im Forum auf die generelle Frage: Wie viel muss ich verstanden haben, um mit Fhem arbeiten zu können?

Vergleichbar für mich mit grundlegenden Entwicklungen in allen Zweigen von Komplexität, wie:

- kochen wird reduziert auf das geführte Bedienen einen Maschine
- rechnen auf das Tippen auf einer Maschine
- verstehen auf das machen lassen von Anderen
- lesen auf das ansehen von Videos
- usw.

Ich persönlich glaube, dass Fhem im Standard einen guten Kompromiss zwischen Bedienbarkeit, Verständnis und Lust auf das aneignen von Wissen darstellt. Allerdings habe ich auch kein Problem damit, wenn jemand eine Oberfläche entwickelt, die angelehnt an z.B. Lego Mindstorms, funktioniert. In diesem Sinne: Machen nicht plappern  :)

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

crusader

Zitat von: JoWiemann am 28 Februar 2018, 20:43:44
Allerdings habe ich auch kein Problem damit, wenn jemand eine Oberfläche entwickelt, die angelehnt an z.B. Lego Mindstorms, funktioniert. In diesem Sinne: Machen nicht plappern  :)

Grüße Jörg

Nee, von einer neuen Klickibunti-Oberfläche für FHEM war in diesem Thread nicht die Rede.

Diskutiert wurde hier vielmehr ein externes (i.d.R. nicht auf dem Zielsystem laufendes) grafisches Frontend zur automatischen Erzeugung von Statechart-Code, der dann von einem passenden FHEM-Modul ausgeführt wird.

Dass das für ein System wie FHEM Overkill ist, sehe ich auch so, aber realisierbar wäre es durchaus.


JoWiemann

Hm, was diskutiert worden ist hat mich schon intellektuell erreicht [emoji23]

Der Hinweis auf Lego Mindstorms halt eine Zuspitzung.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

herrmannj

Bitte, Bitte. Eistee hat eine Idee geäußert und angekündigt das sie das umsetzen möchte. Keine Forderungen, reine Info und die Einladung an andere mitzumachen -> wer das möchte.

Innerhalb von Sekunden ist der thread dann .... abgeglitten. Lasst sie doch bitte machen. Einige haben andere Meinungen, ok - sind geäußert. Lasst Raum für diejenigen die _dafür_ sind. Wo auch immer die Reise dann hingeht.

Maus36

Ich finde die Idee gut, auch wenn mir die Umsetzung sehr komplex erscheint.
Deshalb der Hinweis auf:
http://www.fizzim.com/
Die grafische Oberfläche zum Zeichnen der Zustandsmaschine ist in Java realisiert. Die Codegenerierung mittels Perl soll der Beschreibung nach flexibel sein.