vorschau: neues modul stateMachine

Begonnen von justme1968, 04 April 2016, 21:26:30

Vorheriges Thema - Nächstes Thema

amithlon

Hallo,

die oben angesprochene Zustandserkennung bei E3000 Messgeräten kenne ich irgendwie. Bei meiner Billg-Kaffemaschine gibt es zum Glück nur 0W oder rund 800W...
Der Ansatz, über den Momentanverbrauch den Zusand zu erfassen, ist aber interessant.

Zitat von: Doggiebert am 07 April 2016, 13:28:18

Das Ganze noch etwas komplexer mit einem Raspi, der hinter einer Funksteckdose hängt und der nur als XBMC-Device fungiert; wenn er oben ist, natürlich den Receiver einschalten und wenn er unten ist, die Steckdose wieder abschalten, etc.


Hier werkelt ein RasPi als Streamplayer für einen internen Icecast-Stream. Warum? RasPi lag rum und USB-Soundkarte auch...
Hängt auch an einer Funksteckdose zusammen mit dem aktiven Subwoofer, hat sich so ergeben.

Einschalten über IR-Fernbedienung beim Starten des alten Sony-Receivers über "Video-In", da hängt der RasPi Sound dran. Weiter parallel zu FHEM (IR-Receiver), Raspi wird per LAN-Ping überwacht und wenn er da ist. Dann wird aus dem roten LED im Statusbild in FHEM ein Ausschaltbutton.
Der fährt den RasPi per telnet runter und schaltet 30s später die Funksteckdose aus.

Ließ sich eigentlich ganz gut in FHEM realisieren wenn man von meiner "Diskussion" absieht, den shutdown now zum RasPi zu bekommen...

Ich müßte meine Konstrukte vermutlich mal aus Sicht stateMachine betrachten.

PS: ich hatte vor Jahrzehnten mit einer Honywell Delta 1000 zu tun, Gebäudeautomatisation.
Das war alles Event-basiert und man mußte manchmal seltsame Wege gehen für eine bestimmte Funktion.
Trotzdem finde ich jetzt vieles vom Konzept in FHEM wieder, was mir das Verständnis leichter macht.

Gruß aus Berlin
Michael

akw

Hallo justme,

ist die Entwicklung an dem Modul noch aktiv?

Ich benötige eine Sequenzerkennung. (Siehe https://forum.fhem.de/index.php/topic,60088.0.html )

Ich möchte ein paar Knöpfe in einer bestimmten Sequenz innerhalb einer bestimmten Zeit drücken und dann soll was passieren.

Ciao, Arno
FHEM-SVN auf MacMini OSX 10.7.5

FS20,FHT,HMS,CUL_WS,CUL_HM,KS300,HUE,FB_DECT

FHEMobile: www.fhemobile.de

justme1968

hallo arno,

das modul soll noch weiter entwickelt und dann auch eingecheckt werden.

aber schau dir für deine anwenung sequence noch mal an. das macht schon genau das was du möchtest.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

knopf_piano

anlehnung an uml?
timer, event, transition, entry, exit, condition, laufvariablen
wish-list: state-anzeige, welches event schlägt zu, event als enumwert, , debugging, simulation der SM

idee, das attr in eine cfg-txt/xml-table zu schieben? die könnte dann aus nem egal-was-tool oder pl-script generiert werden

viele, viele ideen...
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

Wenn jemand hier nach Mitternacht Ideen einträgt, kommt mir manchmal das Wort "Geisterstunde" in den Sinn...

Die Beschreibung eines komplexem Systems wie einer State Machine ist auch mit UML noch eine schwarze Kunst. Ein anderer erfolgversprechender Ansatz wird hier geboten:
https://sourceforge.net/projects/smdl/

Der langen Rede kurzer Sinn: Für ganz einfache Automaten kann das so umgesetzt werden, wie Andre es vorhat. Der gegenwärtige Stand der Forschung lässt mich aber stark daran zweifeln, dass komplexere oder allgemeinere Automaten mit einem FHEM-Modul gebaut werden können.

LG

pah

rudolfkoenig

ZitatDer gegenwärtige Stand der Forschung lässt mich aber stark daran zweifeln, dass komplexere oder allgemeinere Automaten mit einem FHEM-Modul gebaut werden können.

Dieser Satz kann leicht von Leuten ohne tiefere Kenntnisse falsch interpretiert werden deswegen eine kleine Ergaenzung: Mit FHEM bzw Perl koennen beliebig komplexe Automaten gebaut werden, ich meine hier wird nur bezweifelt, ob das mit in einer tabellenartigen Struktur / XML-Dokument (im Gegensatz zu einer klassischen Programmiersprache) geht. Meine Erfahrung ist: das geht, ist aber je nach Problemstellung deutlich aufwendiger zu bauen oder zu pflegen, als es mit klassischen Programmiersprachen der Fall ist, und damit waeren wir bei schwarzer Kunst.

justme1968

oder noch anders ausgedrückt:

wenn das projekt so komplex wird das die beschreibung in einer state machine ohne weitere hilfsmittel nicht mehr genügt und die hilfsmittel selber in komplexität und implementierungsaufwand in richtung einer kompletten programmiersprache gehen, dann kann man auch gleiche eine solche verwenden. zumal wir mit fhem die perfekte integration einer solchen schon haben :).
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

knopf_piano

#22
Zitat von: Prof. Dr. Peter Henning am 06 November 2016, 08:29:06
Wenn jemand hier nach Mitternacht Ideen einträgt, kommt mir manchmal das Wort "Geisterstunde" in den Sinn...
der jemand sagt: "Danke für die Blumen".
Schade, dass Denkanstöße oder Ideen deinerseits pauschal mit dieser Wortwahl kommentiert werden.
Wenn eine SW-Entwicklung und Ideen dazu in der freien Wirtschaft identisch attributiert werden, sieht's in Zukunft schlecht aus...
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

@Rudi: Fast voll Zustimmung. Mit Perl: Ja. Mit FHEM: Da habe ich so meine Zweifel, ob beliebig komplexe Automaten gebaut werden können. Die Komplexität ist übrigens der Grund dafür, dass die verlinkte SDML nicht so richtig weiter verfolgt wird.

@knopf_piano: Nach Mitternacht kommen auch in der "freien Wirtschaft" meist keine guten Ideen mehr. Und abgewürgt habe ich auch nichts: Es steht jedem frei, mich durch die Realisierung eines von mir als eher aussichtslos eingestuften Projektes zu widerlegen. Allerdings sollte derjenige das dann auch selbst machen, und nicht einfach wilde Ideen äußern, die andere dann btte programmieren sollen.

LG

pah

knopf_piano

@pah:
Ich habe nichts gegen eine persönliche und sachliche Einschätzung einer Machbarkeit, im Gegenteil.
Der süffisante Unterton "Geisterstunde" wirkt für mich jedoch nicht sehr respektvoll.
zotac nano mit proxmox und ganz viel zeug drauf

Prof. Dr. Peter Henning

Hm, da stehen wir wohl auf verschiedenen Seiten. Denn ich finde es nicht sonderlich respektvoll, einfach einen Wust von Wünschen und Ideen hier auszukippen.

LG

pah

uniqueck

Hi André,

ich hatte gestern auch die Idee eine StateMachine als Modul zu entwickeln und dachte du schaust lieber mal noch im Forum danach, ob nicht jemand schon solch eine Idee hatte.
Und siehe da, du hast dir schon die Mühe gemacht.

Ich würde es noch als sinnvoll erachten, die erkannten States als Reading bereitzustellen, da ich gestern beim Anlegen ein oder zwei Fehler gemacht hatte, welche zwar syntaktisch keine Auswirkung hatten, aber dazu geführt hatten, dass die möglichen states nicht erkannt wurde.

Ich kann das auch gerne übernehmen, des Weiteren wollte ich noch anmerken, dass ich es für mich erstmal in ein git Repository gepackt habe, damit ich bei Anpassungen es nicht immer manuell hin und her kopieren muss.
Es soll allerdings nicht der Eindruck entstehen, dass es von mir ist, ich würde es nur solange da halten, sobald es entweder von dir in einem bereitgestellt wird, oder aber natürlich in FHEM Standard mit übergeht.

Für die gemeinsame Entwicklung finde ich es allerdings in einem Repository geschickter, als es hier immer an einen entsprechenden Post zu hängen.

Hättest du da etwas dagegen?

Link zu Repository: https://github.com/uniqueck/fhem-statemachine

gruß constantin

justme1968

nur zu. tob dich aus. ich komme gerade nicht dazu.

wenn das modul in einem verwendbaren zustand ist soll es auf jeden fall ganz normal eingecheckt werden.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

uniqueck

Zitat von: gandy am 05 April 2016, 13:00:35
Eine meiner ersten FHEM-Gehversuche war ein Modul für eine Statemachine, das zwar seinen Dienst tut, es aber nie auf einen veröffentlichungswürdigen Level geschafft hat. Mir fehlt die Zeit, es dahin zu bringen, aber vielleicht kann ich ein paar Ideen zu Deinem Modul beitragen:

Hauptsächlich verwende ich die Statemachine, um aus dem Energieverbrauch von Geräten (gemessen über EC3000) deren Zustand abzuleiten und mich dann z.B. von FHEM informieren zu lassen, wenn Geschirrspüler oder Waschmaschine fertig sind. Ein reines on/off aus einem fixen Threshold abgeleitet ist mir hier zu wenig. Auch andere Zustände lassen sich aus Sensorwerte ableiten, wie der Homestatus oder der Zustand der Bewohner nach dem Bierbrauen  ;)

Zur zuverlässigen Erkennung eines Zustandswechsel hat es sich bei den Haushaltsgeräten als notwendig erwiesen, angeben zu können, wie lange eine Bedingung erfüllt sein muss, um ein hinreichendes Kriterium für den Übergang zu sein. Beispiel aus der Konfiguration für die Waschmaschine (bitte nicht an der Syntax stören):

from OFF to TIMED_DELAY if{(0.5 <= $p1) and ($p1 <= 5)} for{25}
from OFF to ACTIVE if{$p1 > 5} for{20}
from TIMED_DELAY to ACTIVE if{$p1 > 5} for{20}
 
$p1 ist hier das Reading des Leistungsmessgeräts, dessen Events ausgewertet werden. Wenn es 25 Sekungen lang zwischen 0.5W und 5W bleibt, wird der Timer-Betrieb (TIMED_DELAY) erkannt (Verzögertes Starten des Waschvorgangs), ist der Verbauch für 20 Sekunden mehr als 5W, sartet der Waschvorgang (ACTIVE). Während diese Übergänge noch einfach zu erkennen sind, folgt der Verbrauch anderen manchen Zuständen komplexeren Mustern, hier wäre eine Möglichkeit zur Erkennung von allgemeineren Sequenzen vorteilhaft.

Für jeden der Zustände kann ich in meiner Statemachine Callback-Funktionen onenter und onleave definieren, zum Beispiel:

onleave OFF { fhem("attr PowerMeterGS event-on-update-reading power"); }
onenter OFF { fhem("attr PowerMeterGS event-on-update-reading 0"); }

Das ist nicht so flexibel wie action, könnte in Kombination damit aber den Code lesbarer machen.

Zusätzlich zum Auslösen von Aktionen habe ich meiner Statemachine die Möglichkeit gegeben, Berechnungen für readings anzustellen: So kann z.B. der Verbrauch und die Zeitdauer von Erreichen oder Verlassen eines Zustands bis zum Erreichen oder Verlassen eines anderen (oder des gleichen Zustands) ermittelt werden:

reading waschgang_verbrauch PowerMeterGS:consumption delta [ACTIVE]
reading waschgang_dauer     ::timestamp              delta [ACTIVE]
reading laufzeit_verbrauch  PowerMeterGS:consumption delta ]OFF[
reading laufzeit_dauer      ::timestamp              delta ]OFF[
reading standby_verbrauch   PowerMeterGS:consumption delta [OFF]

Die Klammerung für die States bezeichnet, ob Betreten oder Verlassen des Zustands ausschlaggebend ist. Damit die Berechnung korrekt sein kann, müssen die beteiligten ReadingValues immer dann zwischengespeichert werden, wenn ein Zustandswechel wahrscheinlich wird. Im obigen Beispiel wäre das für den Wechel OFF->ACTIVE dann der Fall, wenn $p1 das erste Mal über 5W steigt. Der Zustandswechsel selbst wird anerkannt, wenn die Bedingung 20s lang erfüllt bleibt, für die Berechnung ist aber ausschlaggebend, welchen Wert PowerMeterGS:consumption zu Beginn dieser 20s hatte.

Vielleicht ergeben sich daraus ja ein paar (zusätzliche) Diskussionsansätze.

Beste Grüße,
Andy.

Möchtest du dein Modul hier teilen, dann kann ich ja mal schauen, was davon alles in das stateMachine Modul übernommen werden kann, oder du hilfst selber mit.

Ich denke das wichtigste sind dann erstmal Bedingungen, bei den events.

Gruß Constantin

gandy

Hi Constantin,

den Code teile ich gerne, allerdings habe ich daran seit längerem nichts mehr gemacht, außer auf Probleme bei FHEM-Updates oder neuen Perl-Versionen zu reagieren. Die Konfiguration einer Statemachine funktioniert beim beigefügten Modul über eine Konfigdatei, davon habe ich ein paar beigefügt. Das würde ich inzwischen nicht mehr so lösen, weil es beim Aufsetzen und Optimieren einer neuen Statemachine zu sperrig ist.

Leider habe ich im Moment nicht wirklich die Zeit, mich intensiv mit einzubringen, konkrekte Fragen zum Code beantworte ich aber gerne.

Grüße,
Andy.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1