Hoanoho Frontend

[dansch]

Vielleicht könnte man auf der Basis ein FHEM-Modul bauen, dass die Events in eine message queue wie rabbit mq einfügt. Dann könnte man etwas eleganter aus Node/PHP darauf zugreifen. Die Kommunikation in die andere Richtung könnte dann vielleicht auch über eine MQ laufen, sodass man für Hin- und Rückrichtung die selbe Technik verwenden kann.

Ich denke das wäre machbar.

[mmattern]

Vielleicht könnte man auf der Basis ein FHEM-Modul bauen, dass die Events in eine message queue wie rabbit mq einfügt. Dann könnte man etwas eleganter aus Node/PHP darauf zugreifen. Die Kommunikation in die andere Richtung könnte dann vielleicht auch über eine MQ laufen, sodass man für Hin- und Rückrichtung die selbe Technik verwenden kann.

Hallo,

ich experimentiere gerade mit MQTT (http://mqtt.org/) - weil ich ein Polling vermeiden möchte...

Für die mich interessierenden Devices rufe ich über ein FHEM-Notify eine kurze Perl-Routine auf, die dann per MQTT Status-Updates weitergibt.
Im Webserver wartet eine MQTT-Websocket-Bridge, die die Updates dann ans Frontend liefert:

in FHEM:

99_MyUtils.pm:

Code Auswählen Erweitern


use WebSphere::MQTT::Client;

sub connectMQTT
{
my $force = $_[0];
if ((!(defined $mqtt_sender)) || ($force eq "force")) {
$mqtt_sender  = new WebSphere::MQTT::Client(
              Hostname => "localhost",
          Port => 1883,
clientid => 'fhempl_sender_mqtt',
  );

# connect to MQTT server
my $res = $mqtt_sender->connect();
if ($res) {
Log(3, "connectMQTT: Failed to connect mqtt_sender: $res");
}
}

}

sub pingMQTT
{
connectMQTT();

$mqtt_sender->status();
}

sub sendMQTT
{
my $topic = $_[0];
my $payload = $_[1];

connectMQTT();

my $result = $mqtt_sender->publish($payload,$topic);
if ($result eq "CONNECTION_BROKEN") {
connectMQTT("force");
$result = $mqtt_sender->publish($payload,$topic);
}
}


in fhem.cfg:

Code Auswählen Erweitern

define atMQTT at *00:00:05 { pingMQTT();; }

define nfMQTTRolladen notify Rolladen.*:.* {\
  if ($EVENT =~ m/^on$/) {\
     sendMQTT("Rolladen/$NAME/on", ReadingsVal($NAME, "pct", 0));;\
  } elsif ($EVENT =~ m/^off$/) {\
     sendMQTT("Rolladen/$NAME/off", ReadingsVal($NAME, "pct", 0));;\
  } elsif ($EVENT =~ m/^level: (1)?[0-9]{1,2}$/) {\
    my (undef, $level) = $EVENT =~ /(level: )(.*)/s;;\
    sendMQTT("Rolladen/$NAME/level", "$level");;\
  } elsif ($EVENT =~ m/^pct: (1)?[0-9]{1,2}$/) {\
    my (undef, $pct) = $EVENT =~ /(pct: )(.*)/s;;\
    sendMQTT("Rolladen/$NAME/pct", "$pct");;\
  } elsif ($EVENT =~ m/^(1)?[0-9]{1,2}$/) {\
    sendMQTT("Rolladen/$NAME/level", "$EVENT");;\
  }\
}


Das funktioniert schon ganz gut - ohne Longpoll etc...

Man könnte das vermutlich analog FileLog-Modul o.ä. auch leicht zu einem vollwertigen Modul machen...

Ich habe es allerdings noch nicht hinbekommen, FHEM zu einem funktionierenden MQTT-Listener zu machen...

Viele Grüße
Michael

[justme1968]

der inform mechanismus in fhem verarbeitet und verteilt alle events innerhalb von fhem. ganz generell und unabhängig von hard codierten device namen und riesigen if abfragen.

wenn man aus welchem grund auch immer das inform nicht nutzen möchte kann man auf ein modul mit einer notifyFn verwenden wie z.b. readingsHistory und so alle events weiterleiten.

es gibt keinen grund die backend seite die die events einsammelt und weiter sendet noch mal zu implementieren. das ist in fhem alles schon vorhanden. das einfachste ist sich einfach zur fhem installation zu konnecten und den gleichen mechanismus zu verwenden wie der eventmonitor. das geht einfach out of the box ohne auf fhem seite irgendetwas zusätzlich implementieren zu müssen.

gruss
  andre

[mmattern]

der inform mechanismus in fhem verarbeitet und verteilt alle events innerhalb von fhem. ganz generell und unabhängig von hard codierten device namen und riesigen if abfragen.

Hallo André,

"inform" liefert derzeit doch nur nach Telnet, oder?

[man kann] auf ein modul mit einer notifyFn verwenden wie z.b. readingsHistory und so alle events weiterleiten.

Klingt interessant - wie meinst du das genau? readingsHistory sammelt aufgrund der notifyFn die Events ein - wie kommen sie dann z.B. nach MQTT? Schlägst du vor, z.B. readingsHistory zur Basis einer Bridge nach MQTT zu machen (wenn man denn gerne ausgewählte FHEM-Updates nach MQTT geliefert haben möchte)?

Geht natürlich nicht darum, "das Rad neu zu erfinden"...
Mein Beispiel ist aktuell eher als eine Fingerübung/"Proof of concept" zu verstehen - ging eher darum zu testen, ob MQTT stabil die Updates bekommt...

Viele Grüße
Michael

[justme1968]

"inform" liefert derzeit doch nur nach Telnet, oder?

telnet ist auch nur ein socket auf dem du zu fhem hin inform xxx sendest und ab da die events zurück bekommst.

der eventMonitor macht es im prinzip ähnlich in dem er in www/pgm2/console.js eine verbindung zu fhem öffnet und die events anfragt.


readingsHistory war nur ein beispiel. aber wenn du da den DoTrigger aufruf  durch das sendMQTT von oben ersetzt und $name und $msg sendest war es das im prinzip schon.

alwaysTrigger muss natürlich gesetzt sein da sonst die events nur weitergeleitet werden wenn readingsHistory auch im browser zu sehen ist.

gruss
  andre

[drdownload]

Das ist wirklich sehr beeindruckend wie "mature" es schon aussieht. Ich habe selber mit einem Dashboard auf Basis von Angular angefangen und wollte ähnlich eher auf Widget-Basis für einzelne Aufgaben arbeiten. (bin aber knapp davor jetzt alles hinzuwerfen, wenn jemand schon so weit ist)

[dansch]

Also das sind keine Mockups oder sowas, dass ist so bei mir im Einsatz und funktioniert

Ich stehe gerade noch vor der Namensfindung und dann geht es für alle an die Öffentlichkeit.

[tobias.gj]

sehr cool, Kompliment!

[Marcel85]

Wahnsinn!!!
Das ganze sieht wirklich richtig gut aus, ganz nach meinem Geschmack.
Genau DAS habe ich gesucht.
Ich bin auf den Tag der Veröffentlichung gespannt. (Hoffentlich dauert es nicht mehr lange)

[cpramhofer]

Da wäre ich gerne bereit auch was dafür zu bezahlen!
Bitte halte uns auf dem Laufenden wie der Entwicklungsstatus aussieht.

Vielen Dank für die tolle Arbeit!

[Carsten]

Hallo,

gefällt mir auch gut ( bis auf das Holzfurnier  )

Hoffe, das Wetter der letzten Woche verzögert den Relase nicht zu sehr.

Gruß

Carsten

[olli84]

Wahnsinn, das sieht super aus!

SO stelle ich mir eine benutzerfreundliche Oberfläche vor!

SUPER!

[punker]

Also das sind keine Mockups oder sowas, dass ist so bei mir im Einsatz und funktioniert

Ich stehe gerade noch vor der Namensfindung und dann geht es für alle an die Öffentlichkeit.

Die Namensfindung dauert aber lange.
Wann isses denn soweit, dass man das testen kann?

[dansch]

gefällt mir auch gut ( bis auf das Holzfurnier  )

Hoffe, das Wetter der letzten Woche verzögert den Relase nicht zu sehr.

Die Hintergründe kann man individuell für jeden User einstellen.
Im Moment habe ich leider mehr am Haus zutun als an der Haussteuerung.

[dansch]

Die Namensfindung dauert aber lange.
Wann isses denn soweit, dass man das testen kann?

Ich hoffe bald, ich nehme Namensvorschläge dankend entgegen