Einbinden meines Bussystems in FHEM

[Kiwibird]

Hallo liebe Hausautomatisierer!

Nach längerem stillen mitlesen will ich nun auch meine Schreibberechtigung in diesem Forum nutzen und ein paar Fragen zu FHEM und der Einbindung von "eigener" Hardware stellen.

Aber erstmal der Reihe nach. Ich bin 43 und habe vor über 12 Jahren damit angefangen ein CAN basiertes Hausbussystem zu entwickeln. Seit rund 10 Jahren läuft die Hard- und Software ohne größere Auffälligkeiten in unserem Haus  Nach vielen Jahren mit anderen Prioritäten kam vor einiger Zeit der Wunsch auf, die Haussteuerung wieder weiter zu entwickeln. Ganz oben Stand der Wunsch nach einem Web-Frontend, welches ich dann auch auf einem Raspi mit CAN Anbindung umsetzte. Das funktioniert zwar alles ganz nett, aber ich stellte schnell fest, dass alle Dinge, die ich mir so vorstellte in meiner freien Zeit nicht umzusetzen sind  Nach einigem Hadern bin ich dann auf FHEM gestoßen und war sofort von der breiten Basis und der aktiven Entwicklergemeinde überzeugt! Schnell war ein zweiter RasPI2 aufgesetzt, ein HM-LAN angeschlossen und die bereits vorhandenen  Rauchmelder integriert. Ich besorgte mir einen HM Funktaster und Aktuator und hatte ein neues Spielfeld 

Ich habe dann angefangen mir die Programmierung von FHEM anzuschauen. Inzwischen ist es mir gelungen über eine Web-Socket Verbindung die Umweltdaten meines Hausbussystems in FHEM sichtbar zu machen und diese auch grafisch hübsch darzustellen. Als nächster Schritt stand dann die Einbindung meiner Aktuatoren (Licht, Rolläden, Jalousien, Markise, Fensterkontakte usw) an. Leider bin ich hier dann noch nicht wirklich weiter gekommen 

Mein erstes Ziel ist die Einbindung und die Darstellung des Schaltzustandes von verschiedenen Lampen. Mein Ansatz war des in meinem FHEM2CAN Modul umzusetzen. Bislang wurden dort nur alle 10 Sekunden die Umweltdaten ausgelesen. Jetzt wollte ich die "Senderichtung" in Betrieb nehmen und habe dazu eine FHEM2CAN_Set Funktion eingeführt. Prinzipiell klappt das auch, ich kann also Botschaften von FHEM auf meinen CAN senden, allerdings wird die Set-Funktion alle 10 Sekunden aufgerufen  ohne dass ich den SET Button auf der Oberfläche drücke (liegt das an dem Notify für das Lesen der Umweltdaten?).  "Kurz" gesagt, ich glaube, ich habe noch nicht verstanden, wie FHEM hier arbeitet  Könnt ihr mir hier ein wenig auf die Sprünge helfen und mir erklären, wie FHEM hier intern werkelt? Ich habe mir zwar einige Module angeschaut und auch in den verfügbaren Dokumentationen gestöbert, aber so richtig schlau bin ich daraus nicht geworden...

Nochmals in kurz: Wie binde ich meine Aktuatoren möglichst elegant in die FHEM Oberfläche ein? Ich stelle mir das ähnlich wie die HM Taster und Aktuatoren vor  Das Interface zu meinem Hausbus ist die oben angesprochene Web-Socket Verbindung.

So, nun hoffe ich auf ein paar Stupser in die richtige Richtung 

Danke und viele Grüße

Volker

[Thorsten Pferdekaemper]

Hi,
hast Du das hier nicht gefunden oder hat es nicht geholfen:
http://www.fhemwiki.de/wiki/DevelopmentModuleIntro
Gruß,
   Thorsten

[Kiwibird]

Hi,
hast Du das hier nicht gefunden oder hat es nicht geholfen:
http://www.fhemwiki.de/wiki/DevelopmentModuleIntro
Gruß,
   Thorsten

Hallo Thorsten,,

vielen Dank für deine Rückmeldung.
Das verlinkte Dokument kenne ich. Daran habe ich mich auch ein Stück weit orientiert.
Mir ist daraus leider nicht klar geworden, weshalb meine Set Funktion ausgeführt wird, obwohl der entsprechende Button nicht gedrückt wurde?

Viele Grüße

Volker

[Thorsten Pferdekaemper]

Mir ist daraus leider nicht klar geworden, weshalb meine Set Funktion ausgeführt wird, obwohl der entsprechende Button nicht gedrückt wurde?

Tja, da müsste man einiges mehr wissen...
Die Set-Funktion wird dann ausgeführt, wenn ein "set <device> ..." gemacht wird. Ob das direkt über die Oberfläche, ein Notify, ein At oder sonstwie passiert ist egal.
Gruß,
   Thorsten

[Markus Bloch]

Es wird ebenfalls durch FHEMWEB unter bestimmten Umständen ein "set <name> ?" ausgeführt um die möglichen Kommandos abzufragen. Dies ist bspw. beim Aufruf der Detail-Seite oder Raum-Übersicht der Fall.

Gruß
Markus

[Kiwibird]

Hallo zusammen,

vielen Dank schon mal für die Antworten. Ich bin gestern nun tatsächlich einen (großen) Schritt weiter gekommen. Ich habe meine Set-Routine komplett neu geschrieben und mich an den Artikel aus dem Wiki angelehnt. Inzwischen kann ich über die FHEM Oberfläche innerhalb meines CAN Moduls über den Set-Button und Drop Down Menüs verschiedene Lichter ein- und ausschlten! 

Als nächstes möchte ich nun, über die FHEM Oberfläche die Lampen schalten, und deren augenblicklichen Zustand sehen können. Wie komme ich nun von meinen Get/Set Funktionen meines Moduls zur (schicken) Oberfläche (ähnlich wie bei meinen HM Komponenten)?  Die Umweltdaten von meinem CAN Bus kopiere ich zyklische auf "dummies", das alles wird über "at" gesteuert. Nur wie geht die andere Richtung?

Wie gesagt, ich bin für jeden Hinweis dankbar

Viele Grüße

Volker

[Thorsten Pferdekaemper]

Hi,

um den Zustand eines Geräts darzustellen verwendet man Readings. Aus dem Modul-Coding heraus setzt man Readings so wie hier beschrieben: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Readings. Dann werden sie in Fhemweb automatisch angezeigt.
Je nachdem, von wo man die readings-Funktionen aufruft kann es problemtisch sein, daher behelfe ich mir oft mit folgendem Konstrukt:

Code Auswählen Erweitern


# Helper function to set a single reading asynchronously
# It seems that it only works properly like this
sub HM485_ReadingUpdate($$$) {
my ($hash, $name, $value) = @_;

    if($name){  # do it later
InternalTimer(gettimeofday(),'HM485_ReadingUpdate',[$hash,$name, $value],0);
}else{ # this is the "later" call
    ($hash, $name, $value) = @$hash;
readingsSingleUpdate($hash, $name, $value, 1);
}
}


D.h. sobald Du einen Wert ermittelt hast, schreibst Du ihn in ein passendes Reading. Jetzt kommt es halt darauf an, wie Dein Gerät verbunden ist bzw. woher das System weiß, dass Daten vorliegen. Das kannst Du entweder per Polling machen, wobei hier die Funktion InternalTimer ganz nützlich ist (siehe oben).
...oder Du verwendest die selectlist von Fhem. Näheres dazu steht in http://www.fhemwiki.de/wiki/DevelopmentModuleIntro (nach "select" und "Filedeskriptor" suchen).
Auch die Sache mit den zweistufigen Geräten könnte interessant sein, es kann aber auch sein, dass das Overkill ist.

Gruß,
   Thorsten

[Kiwibird]

Hallo Thorsten,

vielen Dank für deine wertvollen Hinweise. Readings verwende ich bereits beim Einlesen meiner Umweltdaten. Ein anderer RasPI stellt diese über eine WebSocket Verbindung als JSON Daten bereit. Diese polle ich über die Timer-Funktion. Funktioniert soweit prächtig 

Die Zustände meiner Beleuchtung, der Rolläden, Jalousien usw. liegen in anderen Datenstrukturen vor und müssen über andere Kommandos von dem RasPI abgefragt werden. Kann ich die Timer-Funktion innerhalb meines CAN Moduls mehrfach verwenden? Möglichst auch mit einer höheren Frequenz? Bislang habe ich mich nur mit dem Polling auseinander gesetzt. Für ein schnelles Darstellen eines Zusatandswechsels (Lampe ein/aus) kann es aber zu langsam sein (ich polle momentan alle 10 Sekunden). Für die Steuerung meiner Markise ist das deutlich zu langsam. Bei böigem Wind oder Regen muss die Steuerung schneller reagieren.

Der nächste Schritt ist dann den aktuellen Beleuchtungszustand in der FHEM Oberfläche als Symbol darzustellen und über dieses Symbol auch einen Zustandswechsel zu initiieren. Nach welchen Stichworten muss ich hier suchen? 

Viele Grüße

Volker

[Thorsten Pferdekaemper]

Kann ich die Timer-Funktion innerhalb meines CAN Moduls mehrfach verwenden?

Ja.

Möglichst auch mit einer höheren Frequenz? Bislang habe ich mich nur mit dem Polling auseinander gesetzt. Für ein schnelles Darstellen eines Zusatandswechsels (Lampe ein/aus) kann es aber zu langsam sein (ich polle momentan alle 10 Sekunden).

Das kommt darauf an, was sonst noch so auf dem RasPi läuft. Probier's halt aus...

Der nächste Schritt ist dann den aktuellen Beleuchtungszustand in der FHEM Oberfläche als Symbol darzustellen und über dieses Symbol auch einen Zustandswechsel zu initiieren. Nach welchen Stichworten muss ich hier suchen? 

Da bin ich mir nicht sicher. Ich glaube aber, dass das Device (oder der Kanal) ein Reading "state" haben muss, dass den Zustand "on" bzw. "off" kennt. Außerdem sollte es "set... on" bzw. "set... off" verstehen.
Gruß,
  Thorsten

[Kiwibird]

Hallo Thorsten,

Danke nochmal für deine Antworten!

Ich werde das natürlich ausprobieren 

Ich habe jetzt noch ein wenig gestöbert und bin im Wiki (http://www.fhemwiki.de/wiki/Script_mit_Webschalter_ausl%C3%B6sen) auf folgende Stelle gestoßen:

Zunächst ist ein FS20 Dummy anzulegen:

define Licht_an FS20 11114444 1a
attr Licht_an dummy 1
attr Licht_an room HAUS

In der Beschreibung steht:

Das erzeugt auf der Weboberfläche erstmal einen normal aussehenden FS20 Schalter im Raum HAUS

Wenn ich das jetzt auf mein Modul übertrage, welche Dienste/Services/Funktionen muss mein Modul zur Verfügung stellen, dass ich über ein define einen "normal aussehenden Schalter" auf der Weboberfläche anlegen kann? (Quasi ein CAN-Modul Schalter-Dummy)

Viele Grüße

Volker

[rudolfkoenig]

welche Dienste/Services/Funktionen muss mein Modul zur Verfügung stellen, dass ich über ein define einen "normal aussehenden Schalter" auf der Weboberfläche anlegen kann?

Ich weiss nicht genau was du meinst, ich rate: automatisch wird das "on/off" Toggle mit den zwei Gluehbirnen im Status dann angeboten, falls das Geraet im Antwort auf "set dev ?" on und off in der Liste erwaehnt. Ansonsten muss der Benutzer das Feature manuell mit devStateIcon nachbauen, damit sind auch komplexere Reihenfolgen moeglich.

[Kiwibird]

Schönen guten Morgen!

So langsam lichtet sich wenigstens ein Teil des Nebels  Inzwischen kann ich über die FHEM Oberfläche meine Beleuchtung schalten!  Ich hab es auch geschafft über einen vorhandenen HomeMatic Schalter nach long/short getrennt Aktionen auszulösen. Das ist schon ein großer Schritt nach vorne. Das Schalten über einen "Dummy" mit den Glühbirnen als Status sollte auch machbar sein, muss ich aber noch ausprobieren.

Was ich aber noch nicht wirklich verstanden habe:
Wenn ich eine HomeMatic Komponente neu verwende (z.B. ein Schalter), dann wird der Schalter auf der FHEM Oberfläche sichtbar (ich bin mir jetzt nicht mehr sicher, ob ich dazu ein "define" brauchte). Dieser Schalter hat dadurch sofort Eigenschaften zugewiesen bekommen. Meine Frage ist nun, welche Komponent in FHEM ist dafür veranwortlich? Läuft das alles über das CUL_HM.pm Modul? Mein Ziel ist es, meine in meinem Bus System vorhandenen Schalter ebenfalls in FHEM zu integrieren und diese auch zu konfigurieren. Dazu möchte ich natürlich nicht jeden Schalter separat programmieren, sondern über Instanzen (defines?) arbeiten.  Ich hoffe, das ist jetzt nicht zu wirr (mir fehlen einfach die Fachbegriffe), ich kann das gerne noch durch Screenshots darstellen, dann wirds hoffentlich einfacher.

Gibts eigentlich eine gesamthafte Darstellung der FHEM Architektur, bzw. der einzelnen Module? Das würde mir bestimmt einige Fragen beantworten  Mit Enterprise Architect könnte ich umgehen

Danke nochmals für eure Hilfe!

Viele Grüße

Volker

[CoolTux]

Hallo Volker,

Für das automatische anlegen ist das autocreate verantwortlich. Dies bindet jeder Entwickler entsprechend in sein Modul ein und kann dann dort auch gleich festlegen welche zusätzlichen Dinge noch gemacht sollen. So zum Beispiel diverse Attribute für Beschreibung oder devStateIcon und so weiter.
Ich gehe davon aus, das Du für Deine selbsterstellte Umgebung dabei bist ein Modul zu schreiben.




Grüße
Leon

[rudolfkoenig]

Dieser Schalter hat dadurch sofort Eigenschaften zugewiesen bekommen.

Ich weiss nicht genau, was du meinst, ich rate:

- Falls ein Modul ein Event bekommt, was es keinem FHEM-Instanz zuordnen kann, dann liefert die ParseFn Funktion des Moduls "UNDEFINED <NamensVorschlag> <ModulName> <Parameter>" zurueck, was als global Event weitergegeben wird, woraufhin autocreate ein define durchfuehrt, ein FileLog und (falls konfiguriert) ein Plot erzeugt, und auch bestimmte Attribute (Raum) setzt. Falls das Modul kein ParseFn hat (bzw. nicht zweistufig ist), dann kann es selbst das Event mit DoTrigger generieren.

- HM Geraete bekommen beim Anlegen vom CUL_HM Modul Attribute verpasst. Das ist falsch, weil Attribute dem Benutzer gehoeren, und die Module in Abwesenheit von Attributen auf sinnvolle Defaults zurueckfallen sollten. Es mag sein, dass in manchen Faellen das nicht reicht, das muss aber thematisiert und anders geloest werden.

[justme1968]

@rudi: ja. attribute gehören dem anwender. aber ich finde es nicht falsch wenn ein modul im define attribute mit den defaults vorbelegt. das hat den riesen vorteil das der benutzer sieht was er alles einstellen kann, das er die defaults sieht und es oft auch ein hinweis auf mögliche änderungen ist.

natürlich könnte man das auch anders lösen. mir fällt aber zumindest keine variante ein die sowohl für anwender und modulentwickler ähnlich einfach ist und so wenig overhead erzeugt.

falsch wird es erst dann wenn das modul auf 'seine' gesetzten attribute besteht und änderungen des benutzers verhindert oder ignoriert.