OWL+USB-Energiemonitor in FHEM: 60_CM160.pm liefert falsche Daten

Begonnen von Raspi-Newbie, 14 November 2015, 11:40:40

Vorheriges Thema - Nächstes Thema

MecHome

Hallo zusammen,

ich habe mich hier mal registriert, weil ich seit kurzem meine ersten Erfahrungen mit einem Raspberry Pi2 ModelB mache. Die FHEM-Software ist installiert und jetzt will ich mich mal so langsam mit der Materie vertraut machen. Als erstes würde ich gerne meine neue OWL+USB einbinden. Mein erster Versuch nach einer gefundenen Anleitung scheiterte an dem geforderten zurückdrehen des Kernels. Ich hatte zum Glück vorher eine Sicherheitskopie der SD-Card gezogen.

Gibt es eine Möglichkeit für relative Anfänger wie mich, die Eule an einen Raspi2B mit dem aktuellen Kernel 4.1.17-v7+ zu hängen um die Daten regelmässig abrufen zu lassen und zu speichern, so dass ich nicht mindestens alle 30 Tage die OWL zum PC zu tragen?
Und wenn ja, was kann ich eventuell noch so mit der Kombination FHEM und OWL anstellen?

Ich bin für Eure Tipps dankbar :)
Mec

Wolfi


MecHome

Hi Wolfi,

danke für die schnelle Antwort. Den Thread hatte ich auch schon gesehen, da steht jedoch das hier:

ACHTUNG: Dieses Modul ist nur für genau diese Kernel-Version auf dem RPi2 (nicht auf B, B+, etc) geeignet.

Ich habe aber den Pi2 Model B. Deswegen glaube ich nicht, das der Treiber passt.


und den zweiten Link kenne ich auch. Da hat mich dann folgender Abschnitt dazu verleitet mein Raspi-System komplett zu schrotten, so dass es nicht mehr gebottet hat.

UPDATE: Unter diesem Link (http://tech.enekochan.com/en/2014/03/08/upgradedowngrade-to-a-specific-firmware-kernel-version-with-rpi-update-in-raspbian/) wird erklärt, wie man seinen Kernel auf eine vorherige Version downgraden kann, damit der OWL-Treiber passt.

Wolfi

Hallo MecHome,

Ich habe vor ca. 3 Wochen einen P2 gekauft und FHEM komplett Neu installiert genau mit diesem Kernel. (hatte zuvor einen p1)
Mit B, B+ geht es um den P1 so wie ich das verstehe.
Diesen Kernel :

https://forum.fhem.de/index.php?action=dlattach;topic=15993.0;attach=47834

Und OWL habe ich nach der besagten Anleitung installiert natürlich mit der Neuen Kernel .
Und wen das Owl dann grundsätzlich mal funzt  solltest du die 60_CM160 austauschen wie hier beschrieben.

Und als weiteres kannst du noch folgende Anleitung mit in die Installation einfließen  lassen oder später  umbauen.

http://www.meintechblog.de/2013/11/fhem-logfiles-und-graphen-datenlast-reduzieren-und-werte-ordentlich-visualisieren/

Das War natürlich Falsch!!!!!!!

und den zweiten Link kenne ich auch. Da hat mich dann folgender Abschnitt dazu verleitet mein Raspi-System komplett zu schrotten, so dass es nicht mehr gebottet hat.

UPDATE: Unter diesem Link (http://tech.enekochan.com/en/2014/03/08/upgradedowngrade-to-a-specific-firmware-kernel-version-with-rpi-update-in-raspbian/) wird erklärt, wie man seinen Kernel auf eine vorherige Version downgraden kann, damit der OWL-Treiber passt.

dadoc

Moyn,
es wurde in diesem Thread ja schon verschiedentlich gefragt: Wo kann man die letzte (im Sinne von "am fehlerkorrigierteste") Version des Moduls ziehen? Theoretisch müsste sie im letzten Beitrag von ste87 vom 3.1.2016 anhängen - tut sie aber nicht:
Zitat
Anbei die aktuelle Version mit der geänderten Berechnung (siehe letzten Post).

Beachte: Die Attributes: costPerKwh currency co2Factor sind nicht mehr enthalten.
« Letzte Änderung: 10 Januar 2016, 14:58:21 von ste87 »
Könnte jemand so nett sein und diese noch einmal hochladen?
Danke & Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

ste87

Hallo,

ich lade hier noch mal die Version hoch, die ich immer noch selber nutze. Die Datenaufnahme klappt damit reibungslos.

ABER: Das Setzten der Events, vor allem der addierten Werte, ist noch nicht/gut umgesetzt. Ich habe leider in den letzten Jahren nichts mehr daran gemacht, dass heißt es ist noch nicht rund und auch sonst "veraltet" (Logging, aktuelle FHEM Konzepte).

ACHTUNG: Vor Benutzten des Moduls ein Backup machen !!!

Die Benutzung ist auf eigene Gefahr.


dadoc

Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Habe ein paar Dinge am Modul aktualisiert (Benutzung des Moduls auf eigene Gefahr - Vorsicht, bin kein Programmierer!):
- Aktualisierung der Log-Funktionen auf log3
- Neues Attribut debugpwr, mit dem das Schreiben bzw. Nicht-Schreiben der Debug-Informationen (inkl. Raw data) ins fhem-Log gesteuert werden kann. In der letzten Version wurden sie immer komplett ins Log geschrieben, das dadurch schnell extrem anwuchs.

Was m.E. noch fehlt ist der Komplex "Event-on-change-reading" und Verwandte, denn auch das normale Datenlog wird schnell sehr voll, da auch unveränderte Daten reingeschrieben werden. Das macht insbesondere komplexere Chart-Darstellungen (ftui Chart Widget) unnötig langsam. Soweit ich mich da eingelesen habe, braucht es dafür eine Umstellung im Modul auf readingsBulkUpdate und Konsorten. Das übersteigt aber definitiv meine derzeitigen Perl-Bastelkenntnisse. Vielleicht kann ja ein Kundiger Hilfestellung leisten?
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Wolfi

Hallo habe vor mein FHEM  vom pi2 auf einen P3 zu zügeln?
Hat das schon mal jemand gemacht?
Was ist bezüglich OWL USB zu beachten bzw zu unternehmen?
Gibt es Anleitungen?

dadoc

zügeln?
Umzug ist kein Problem, läuft bei mir mit Stretch auf Raspi 3 B rev. 1.2; ebenso OWL (auf demselben Pi). Du musst halt das richtige Kernel-Modul nehmen (in meinem Fall 4.9.59-v7+). Konkrete Anleitung kenne ich keine, aber wenn konkrete Fragen auftreten, kann ich sie gern versuchen, sie zu beantworten.
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

dadoc

Zitat von: ste87 am 02 Februar 2018, 18:20:15
ABER: Das Setzten der Events, vor allem der addierten Werte, ist noch nicht/gut umgesetzt. Ich habe leider in den letzten Jahren nichts mehr daran gemacht, dass heißt es ist noch nicht rund und auch sonst "veraltet" (Logging, aktuelle FHEM Konzepte).
Ich habe nun noch etwas im Modul herumgefuhrwerkt, damit:
- das doppelte und dreifache Loggen der Werte aufhört
- man event-on-change-update usw. verwenden kann.
Ich bin kein Programmierer, auch wenn ich dieses Modul jetzt mal zum Anlass genommen habe, Zeile für Zeile verstehen zu wollen und so meine rudimentären Perl-Kenntnisse voranzutreiben (was mir nur bedingt gelungen ist).
Bei mir läuft es seit zwei Wochen stabil, die Logfile ist nun richtig schlank; aber dennoch Benutzung auf eigene Gefahr. Vielleicht kann ja mal jemand draufschauen, der mehr Ahnung hat als ich. Änderungen sind mit # mk gekennzeichnet.
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

MarkusEd

Hallo,

ich habe das Modul von dadoc im Einsatz und es funktioniert bislang ganz gut. Einzig die Erkennung der "historischen Daten" die nach jeden Reconnect (USB aus-an stecken und seltsamerweise jeden Morgen) der Eule gesendet werden, funktioniert nicht => es werden hunderte alt-Werte übertragen und geloggt. Problem: Die Eule setzt MODE schon auf "live data" obwohl noch historische Werte übertragen werden.

Ich habe das gelöst mit:

Attributes
event-aggregator W:30:linear:mean
event-min-interval .*:30


Damit unterdrücke ich die meisten der unnützen Daten nach einem CM160 Reconnect, da diese innerhalb weniger Sekunden gesendet werden. Nun verliere ich aber die Anzeige der aktuell vom CM160 gesendeten Werte da diese ja über 30 Sekunden gemittelt werden.

FRAGE:
Wie kann ich das W Reading kopieren in ein neues Reading z.B. W0 vor dem event-aggregator?
Also loggen will ich nur die aggregierten Werte, anzeigen will ich aber alle.

Gibt es die Möglichkeit evtl. mit Dummy ein Reading zu verdoppeln/kopieren?

Danke Markus