Modul für ENIGMA2 Receiver

Loredo · 17 Juni 2015, 21:49:15

da das Modul hier nicht in die FHEM Standardfunktion eingreift, ist es wohl kein Modul spezifisches Problem (zumindest wenn das state Reading den korrekten Status hat)

Tommy82 · 17 Juni 2015, 22:03:59

Ja das state reading wird richtig aktualisiert, woran könnte es denn liegen wenn es nicht am Module liegt?
Hat immer funktioniert

Loredo · 17 Juni 2015, 22:44:25

du kannst nur devStateIcon vergleichen. Ansonsten ist es wohl ein seltener Bug im FHEM Code. dabei kann ich allerdings nicht helfen

FunkOdyssey · 18 Juni 2015, 22:33:20

So, ich hatte das gestern mal wieder ausprobiert und nun nach 24 Stunden wieder deaktiviert. Die Dreambox war kaum noch bedienbar. Port 80 . Intervall 60s. Schade.

Ich habe Merlin3 mit nem MetrixHD-Skin aktiv. Das Skin schluckt schon Performance. So vermute ich, dass das permanente Web-Polling die Box hochschauckelt oder ähnlich.

satprofi · 19 Juni 2015, 08:55:38

MerlinHD ist doch das beste. Bei mir klappt das Modul schon seit Monaten reibungslos.
Ich tippe da eher auf die Dream, warum auch immer die noch gekauft wird

Elektrolurch · 11 Juli 2015, 19:55:26

Hallo,

bin aus Zufall hier auf das ENIGMA2 - Modul gestossen, da ich gerade einen SAT-Receiver suche, der muss aber unicable - tauglich sein.
Nutzt jemand einen solchen Receiver und funktioniert er auch mit fhem ohne Probleme?
Den hier hatte ich schon mal ausgeguckt: Telestar Starsat LX

Elektrolurch

FunkOdyssey · 11 Juli 2015, 19:59:53

Ich nutze den Receiver und habe mit der Performance ein paar Probleme (s.o.). Momentan versuche ich es übrigens erneut und zwar mit dem lightmode-Attribut. Mal schauen wie sich die Box heute Abend bedienen lässt.

FunkOdyssey · 29 Juli 2015, 21:17:36

Es scheint sich zu beruhigen und die Box läuft trotz FHEM ganz stabil.
Ich habe das Attribut "http-method" auf POST geändert.

Loredo · 01 August 2015, 16:04:22

Ja, einige Images mögen POST lieber, andere GET. Ganz seltsame Geschichte... deshalb kann man es auch umschalten.

marvin78 · 22 August 2015, 12:14:16

Dass nun im ENIGMA2 Modul bei "on" und "absent" IMMER ein WOL Wakeup gesendet wird (ohne "on"-Event), ist natürlich für Receiver ohne WOL nicht wirklich hilfreich. Entweder müsste zusätzlich auch ein on EVENT generiert werden oder man müsste das ganze konfigurierbar machen (Attribut). Das Aufwachen der Box mit FHEM mit einem IR-Tranceiver fällt sonst nämlich aus. Eine andere Alternative wäre ein selbst zu bestimmender PowerOn Befehl der Perl Code enthalten kann.

Loredo · 23 August 2015, 17:14:50

Das war nie anders. Für Menschen mit WOL fähigem Gerät ist es eine tolle Sache, für jene ohne WOL Gerät macht es keinen Unterschied. Ein Paket zu senden tut nicht weh; bei all den verschiedenen Geräten da draußen ist hier und da sicher eins dabei, welches sich dann doch einschaltet. nur lässt sich das eben nicht automatisch erkennen.

Übrigens wird das WOL Paket natürlich nur geschickt, wenn das Gerät wirklich nicht im Netzwerk erreichbar ist (presence=absent). Sobald das Gerät aber übers Netz erreichbar ist, werden nur Kommandos über die API zum ein/ausschalten geschickt.

Das mit dem zusätzlichen Event verstehe ich nicht. Du willst ein Event vom Modul, wenn du dort ein "on" sendest, um über ein anderes Gerät wie einem IR dann ein Kommando alternativ abzusetzen? Es macht aus Modulsicht keinen Sinn hier ein Event zu generieren. Stattdessen solltest du deine Automation eher so schreiben, dass direkt dad IR Signal abgesetzt wird.

marvin78 · 23 August 2015, 20:02:50

Es wurde "früher" (ich nicht sicher, wasnn sich das geändert hat) auch ein "on" Event generiert, wenn man

Code Auswählen

set ENIGMA2DEVICE on

gesendet hat. Das ist nicht mehr der Fall.

Und sag bitte nicht, das war schon immer so (

), denn mein notify hat darauf sehr lange prima reagiert. Es gab ein ordentliches Event. Jetzt würde das Event erst kommen, wenn das Device tatsächlich gebootet hat. Ob das am Modul selbst oder an Änderungen im FHEM liegt, weiß ich natürlich nicht.

Loredo · 23 August 2015, 20:05:31

Nein, es wurde noch nie ein "on" Event erzeugt, nur weil man "on" gesendet hat. Das würde voraussetzen, dass sich beim bloßen senden eines Befehls bereits ein Reading ändert. Das ist aber nicht der Fall, da es keinen Sinn ergibt.

Ein Event wurde und wird immer erst dann erzeugt, wenn die Box eine entsprechende Rückmeldung gegeben hat -> keine Rückmeldung, kein Event. Logisch oder?

Das von dir beschriebene Verhalten ist also in der Tat korrekt und schon immer so.

PS: Wenn die Box nur im Standby und nicht im Deep-Standby ist, also nicht erst hochfahren muss, dann hat man in der Tat den Eindruck, dass ein Event für "on" generiert wird. Tatsächlich wird das Event aber dadurch generiert, dass die Box sofort reagiert und sich angeschaltet hat.

marvin78 · 23 August 2015, 20:29:53

Nun gut. Ich habe auch keine Hilfe von dir erwartet. Es hat sich definitiv etwas geändert, da man auch bei Senden eines on aus der Device-Ansicht nur noch ein Popup mit der Rückmeldung erhält. Das wird der Unterschied sein und es liegt wohl an der entsprechenden Änderung an FHEMWEB. Ich weiß, wie FHEM und Events funktionieren. Ich werde darüber aber jetzt nicht diskutieren sondern mir selbst (mal wieder) einen Workaround bauen.

Loredo · 23 August 2015, 20:35:58

Die Zeile

Code Auswählen


return "wake-up command sent";

ist in der Tat neu hinzugekommen. Hat aber mit dem grundsätzlichen Event-Verhalten nichts zu tun.
FHEM handhabt solche Rückgaben unterschiedlich. In der Detailansicht werden sie auf einer neuen Seite angezeigt. Normale Nutzer erhalten jedoch eine Popover-Nachricht oben in der Commandline (oder dort, wo sie wäre, wenn man sie ausgeblendet hat). Der Hinweis, dass ein Wakeup gesendet wurde, erschien mir insofern sinnvoll, als dass der Nutzer dann weiß, dass die Box erst hochfahren muss. Jemand, der kein WOL Gerät hat, sendet auch kein "on" Kommando, wenn die Box im Deep-Standby ist, da es bei ihr ja nicht bewirkt. So meine Annahme.