Gibt es Probleme im EnOcean-Modul bei FWZ12-16A wie meintechblog schreibt?

[krikan]

Hallo!

auf http://www.meintechblog.de/2017/07/smart-metering-mit-fhem-und-loxone-den-stromverbrauch-im-smart-home-immer-im-griff/ gibt es eine Darstellung der Einbindung eines Eltako FWZ12-16A in FHEM. Dort wird von Schwierigkeiten von FHEM mit der Visualisierung/Auswertung des Eltako FWZ12-16A durch das EnOcean-Modul geschrieben und ein unnötig komplizierter Weg zur Sensorauswertung gewählt. Diese Probleme gibt es aber in meiner Trockenübung (besitze das Gerät nicht) nicht, wenn man das Device korrekt entsprechend der commandref mit den Attributen

Code Auswählen Erweitern

attr <device> subType autoMeterReading.01
attr <device> manufID 00D
einbindet. Diese Attribute scheinen bei meintechblog zu fehlen.

Könnte jemand das bitte gegenchecken und bestätigen. Ich würde dann meintechblog mit der Bitte um Richtigstellung anschreiben.

Danke, Christian

[CoolTux]

Hallo Chris,

Bedeutet das, das Du im Reading state einen Wert größer Null zu stehen hast? Denn das ist es ja wohl was die da "Bemängeln". Habe den schon geschrieben das sie stateFormat nehmen können. Denn ein Reading mit korrekten Wert haben sie ja.
Den Misst mit Dummy und DOIF oder notify haben sie schon bei der Waschmaschinen Geschichte vor 2 Jahren so umständlich gemacht.


Grüße

[krikan]

das Du im Reading state einen Wert größer Null zu stehen hast?

Ja, wenn das FHEM-Device korrekt angelegt wird.

Bei meintechblog sind vermutlich die für FHEM-EnO-Devices wichtigen Attribute subType und manufId nicht gesetzt. Darauf deuten die Rohwerte-Readings D0 ... sensor3 und fehlendes state hin. Wenn man die Attribute setzt, wie es in der commandref steht und es im wiki erläutert wird, dann kommen die korrekten Events/Readings:

Code Auswählen Erweitern

    P/W
    power: P/W
    energy<0 ... 15>: E/kWh
    currentTariff: 0 ... 15
    serialNumber: S-<nnnnnn>
    state: P/W

(siehe commandref bei der Suche nach "FWZ12-16A")

Diese Dummy/notify/DOIF-Konstrukte sind dann auch gänzlich unnötig. Zur Sinnhaftigkeit insgesamt mag ich nichts schreiben.

Mir ist nur wichtig, dass die EnO-Deviceanlage korrekt beschrieben wird und falls es tatsächlich Probleme im Modul geben sollte, auf die man dort verweist, dass diese behoben werden (können).

[CoolTux]

Ich stelle jetzt einfach mal was in den Raum.

"Denn Sie wissen nicht was Sie tun"

Ich werde den Herrn mal schreiben das er bitte die entsprechenden Attribute testen möge 

[krikan]

Bin mir eben nicht 100% sicher, da ich das Gerät nicht besitze und nur Telegramme simulieren kann. Darum wollte ich eine Bestätigung.

[CoolTux]

Lass wir Ihn das mal testen. Er hat ja schließlich einen.

[CoolTux]

Hallo Christian,

Gute Nachricht für Dich, es lag nicht am Modul sondern wie so oft am User. Christoph hat gerade bestätigt das es mit den korrekten Attributen läuft.

Habe ihm auch gleich noch mal meine Meinung zu so einem Auftritt gegeigt.
Hoffen wir das meintechblog in Zukunft sauberer arbeitet.


Grüße
Leon

[CoolTux]

Mal kurz OFF-TOPIC

Glaubst Du es lohnt sich ihnen technische Expertise an zu bieten. Ich meine, gut allein schon um den guten FHEM Ruf zu waren ja, aber auch so? Ihnen die Möglichkeit zu geben einen Artikel vorab auf technische Mängel hin Korrektur zu lesen?
Obwohl sie ja eigentlich nur im Forum fragen bräuchten. Ich weiß auch nicht.



Grüße

[krikan]

es lag nicht am Modul sondern wie so oft am User. Christoph hat gerade bestätigt das es mit den korrekten Attributen läuft.

Schön, das ist aber nur die halbe Miete:
Der gewählte Weg zur FHEM-Einbindung von EnOcean-Geräten ist die manuelle und mMn aufwendigste Variante bspw. ohne automatische Plotanlage. Die empfehle ich gerade den Einsteigern nicht und ich vermute der Modulmaintainer sieht das auch so.
Besser wäre es, das Gerät per Lerntelegramm einzubinden. Dann hätte man wohl direkt ein korrekt angelegtes FHEM-Device mit einem zugehörigen Plot.
Alternativ wäre noch der Weg über modify und das zugehörige EEP A5.12.01. Auch dadurch würden die wesentlichen Attribute inklusive Plot angelegt.
Dies wird in commandref, Forum und https://wiki.fhem.de/wiki/EnOcean_Starter_Guide bzw. den anderen Wiki-Artikel ausführlich erläutert.

Mal kurz OFF-TOPIC

Schwieriges Thema.

Grundsätzlich biete ich bei FHEM gerne meine Hilfe an, wo ich kann. Ich mag aber eigentlich nicht Support und Artikel für kommerzielle FHEM-Inhalte liefern, obwohl ich jedem, der mit FHEM Geld verdienen möchte, gegenüber offen bin. Auf der anderen Seite lese ich, dass vermutlich Einsteiger in bestimmte FHEM-Thematiken Artikel mit enormer Reichweite für Einsteiger schreiben, die mMn nicht ideal sind und somit hier zu erhöhtem Support führen könnten. Es fehlt bei den Blogs ein wenig die Kontrolle, die auf den fhem.de Domains (Forum, wiki, usw.) im Wesentlichen gegeben ist. Auf den hier diskutierten Artikel wurde ich bspw. durch PM aufmerksam gemacht. Im Fazit würde ich vermutlich meine Sicht bei Fragen zu Inhalten (auch kommerzieller Seiten) abgeben, wenn man denn im Forum fragen würde. Ob meine Sicht richtig ist, ist etwas anderes.

Verwundert bin ich darüber, dass man angebliche "Probleme" in Modulen in einem Blog thematisiert und nicht hier meldet. Das stört mich deutlich. Ich würde mich freuen, wenn die Blogger sich hier im Forum insbesondere vor Artikelveröffentlichungen aktiver zeigen würden. Mir ist zumindest keine aktive Teilnahme in Form von Forenbeiträgen bekannt. Das ist als freundliche Einladung zu lesen.  Es geht hier um das Wohl von FHEM und das erreichen wir mMn nur, wenn wir gemeinsam Wege/Lösungen suchen und nicht aneinander vorbei arbeiten.

Soweit meine eigene, persönliche Sicht.

Gruß, Christian