Guten Morgen,
ich habe eine neue Version von OWCOUNT eingecheckt. Neben diversen kleineren Fixes enthält diese alle Modifikationen, die Norbert Truchsess seit meinem letzten Update vorgenommen hatte (meine Güte, das war im Februar ... irgendetwas frisst meine Zeit).
Zusätzlich läuft jetzt das tägliche und monatliche Logging stabil.
Unerwünschte Effekte sind nicht ausgeschlossen, also bitte testen.
LG
pah
Und leider im letzten Schönheits-Edit einen Bug eingebaut - gefixt.
LG
pah
Hallo pah,
ist das eine Auswirkung Deines Updates von heute früh?
2014.01.12 15:01:03 1: Caluclating rate from oldval=23368.9, vval=23369, delt=300 as 0.000333333333328483
2014.01.12 15:01:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:06:03 1: Caluclating rate from oldval=23369, vval=23369.1, delt=300 as 0.000333333333328483
2014.01.12 15:06:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:11:03 1: Caluclating rate from oldval=23369.1, vval=23369.2, delt=300 as 0.000333333333340609
2014.01.12 15:11:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:16:03 1: Caluclating rate from oldval=23369.2, vval=23369.3, delt=300 as 0.000333333333328483
2014.01.12 15:16:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:21:03 1: Caluclating rate from oldval=23369.3, vval=23369.5, delt=300 as 0.000666666666669092
2014.01.12 15:21:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:26:03 1: Caluclating rate from oldval=23369.5, vval=23369.6, delt=300 as 0.000333333333328483
2014.01.12 15:26:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:31:03 1: Caluclating rate from oldval=23369.6, vval=23369.7, delt=300 as 0.000333333333340609
2014.01.12 15:31:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:36:03 1: Caluclating rate from oldval=23369.7, vval=23369.8, delt=300 as 0.000333333333328483
2014.01.12 15:36:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:41:03 1: Caluclating rate from oldval=23369.8, vval=23369.9, delt=300 as 0.000333333333340609
2014.01.12 15:41:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:46:05 1: Caluclating rate from oldval=23369.9, vval=23370, delt=302 as 0.000331125827809751
2014.01.12 15:46:05 1: Caluclating rate from oldval=0.828, vval=0.828, delt=302 as 0
2014.01.12 15:51:04 1: Caluclating rate from oldval=23370, vval=23370.1, delt=299 as 0.00033444816053025
2014.01.12 15:51:04 1: Caluclating rate from oldval=0.828, vval=0.828, delt=299 as 0
2014.01.12 15:56:04 1: Caluclating rate from oldval=23370.1, vval=23370.2, delt=300 as 0.000333333333340609
2014.01.12 15:56:04 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 16:01:04 1: Caluclating rate from oldval=23370.2, vval=23370.3, delt=300 as 0.000333333333328483
nach Rückspielen der Version 21_OWCOUNT.pm 4199 2013-11-10 19:59:29Z ntruchsess $
sind die Log Ausgaben weg
Ach ja, seufz ... tut mir leid.
Das war die Debug-Ausgabe, die ich nicht wieder herausgenommen habe. Zum Trost: Mein Log ist auch vollgemüllt.
Ist bereinigt.
LG
pah
Hallo pah,
Nicht so schlimm, die Vorversion macht's ja bisher auch. Kannst Du bitte gelegentlich ein Beispiel in die comandref integrieren, wie die Monats- und Jahreswerte richtig definiert werden. Hier im Forum steht dazu an vielen Stellen immer mal was, hat mich aber leider nicht zum Ziel geführt.
In Summe läuft OWX seit vielen Monaten wesentlich stabiler als der FS20 CUL Funk, der zum Glück nur noch für paar Sachen mit optischer Rückmeldung verantwortlich ist.
hab die Änderungen grade in meinen Branch owx_asnc (https://github.com/ntruchsess/fhem-mirror/tree/owx_async) auf github übernommen.
- Norbert
ach ja, wie wäre es denn wenn man die Tageszähler optional genauso filebasiert wie die Monatszähler machen würde? Dann würde die nämlich auch mit den ATiny25 basierten Countern von dougie funktionieren.
@det:
Nach meiner Semantik gehört das nicht in die Commandref. Hier mein Testbeispiel:
- Der A-Kanal zählt Tastendrücke, ist also im inkrementierenden ("normalen") Modus = wird nicht täglich auf Null gesetzt. Diese Tastendrücke haben den Namen "GPunkte" erhalten (steht für Gummipunkte, um Fehlinterpretationen zuvorzukommen ...), die Anzahl der Gummipunkte/Minute heißt "GRate".
- Der B-Kanal zählt Impulse (à la Stromzähler - obwohl hier zu Testzwecken ein Timer dranhängt, der im Moment alle4 Sekunden ein Signal abgibt). Dabei steht jeder Impuls für 0,001 kWh => BFactor ist 0.001. Außerdem ist dieser Kanal im BMode=daily, es wird also jeden Nacht kurz vor Mitternacht der Mitternachtswert extrapoliert und als "day" Wert ausgegeben. Dieser Wert wird auch im internen Memory als "midnight B" gespeichert und vom Zählerstand abgezogen. Bei dem Testgerät sind das also pro Tag 21,6 kWh = 86400 Sekunden / 4 Sekunden * 0,001 kWh
- Das monatliche Logging erfolgt durch das FileLog OWCM.FL, siehe dessen Definition darunter. Darin stehen Zeilen wie:
2014-01-09_23:59:42 OWC day: D09 GPunkte: 49.0 cts GPunktem: 49.0 cts E-Energy: 21.6 kWh E-Energym: 21.60 kWh
2014-01-10_23:59:43 OWC day: D10 GPunkte: 89.0 cts GPunktem: 89.0 cts E-Energy: 21.6 kWh E-Energym: 43.20 kWh
2014-01-11_23:59:39 OWC day: D11 GPunkte: 89.0 cts GPunktem: 89.0 cts E-Energy: 21.6 kWh E-Energym: 64.80 kWh
2014-01-12_23:59:55 OWC day: D12 GPunkte: 89.0 cts GPunktem: 89.0 cts E-Energy: 21.6 kWh E-Energym: 86.4 kWh
2014-01-13_23:59:11 OWC day: D13 GPunkte: 89.0 cts GPunktem: 89.0 cts E-Energy: 21.6 kWh E-Energym: 108.0 kWh
Damit wird also in der 9. und der 15. Spalte der kumulierte monatliche Wert berechnet. Dazu muss natürlich das Modul wissen, in welchem Device das Logging erfolgt - dazu wird das Attribut LogM auf OWCM.FL gesetzt. Man kann also jederzeit mit "get OWC month" fragen, was der bisherige monatliche Verbrauch ist - das Modul liest dann die entsprechende Datei.
- Das jährliche Logging wird ganz ähnlich gemacht, dazu muss dann natürlich LogY auf den Namen des Filelog OWCY.FL gesetzt werden.
define OWC OWCOUNT 1D.CE780F000000 60
attr OWC model DS2423
attr OWC room Obergeschoss
attr OWC AName GPunkte|
attr OWC ARate GRate|
attr OWC APeriod minute
attr OWC BName E-Energy|energy
attr OWC BRate E-Power|power
attr OWC BUnit kWh|kWh
attr OWC BFactor 0.001
attr OWC BMode daily
attr OWC LogM OWCM.FL
attr OWC LogY OWCY.FL
define OWC.FL FileLog /home/fhem/fhemlogs/OWC-%Y-%m-%d.log OWC.*GPunkte.*E-Energy.*
attr OWC.FL room Obergeschoss
define OWCM.FL FileLog /home/fhem/fhemlogs/OWCM-%Y-%m.log OWC.*day.*
attr OWCM.FL room Obergeschoss
define OWCY.FL FileLog /home/fhem/fhemlogs/OWCY-%Y.log OWC.*month.*
attr OWCY.FL room Obergeschoss
LG
pah
@ntruchsess:
Ein Beispiel dafür findet sich in meinem Modul 15_EMX.pm - da wird der Midnight-Wert in eine Datei gespeichert. Ich fand es aber hier einfach lustiger, mal den internen Speicher zu nutzen. Ich wusste bisher nicht, dass der DS2423-Nachbau - der übrigens von Tobias Müller stammt, siehe hier: http://www.tm3d.de/index.php/1-wire-device-mit-avr - keinen RAM hat. Einerseits wäre es keine Schwierigkeit, die Software von Müller so zu erweitern, dass sie auch den RAM anbietet.
Andererseits aber, und da bin ich konsequent: Ich werde nicht auch noch in diese Arbeit einsteigen, die Zeit habe ich einfach nicht. Mal sehen, ob ich nicht stattdessen einfach das aus dem EMX ins OWCOUNT übernehme, das erweitert die Anwendungsmöglichkeiten von OWCOUNT doch deutlich.
Frag mich in 2 Monaten noch einmal ...
LG
pah
@pah: Mir geht's da schon fast genauso. Bei mir ist es aber nicht nur der Broterwerb - ich hab auch Opensource-seitig mittlerweile auch so viele Baustellen, dass es halt nur noch langsam weitergeht. Den Zeitaufwand seine eigene Software zu supporten, wenn sie unerwartet erfolgreich ist, unterschätzt man leicht. Aber vieleicht finde ich ja mal zwischendrin Zeit, das mit dem Tageszähler zu implementieren.
Gruß,
Norbert
@pah,
vielen Dank für das anschauliche Beispiel. Das wird sicher vielen beim Verständnis der Sache hilfreich sein.
Ich habe die Anregung aufgegriffen und eine Version von OWCOUNT erstellt, die beim Setzen des Attributes "nomemory=1" statt des internen Speichers eine Datei verwendet.
Selbstverständlich wird auch automatisch geprüft, ob es sich um die Software-Nachbildung des DS2423 handelt - und dann automatisch "nomemory=1" gesetzt.
Diese Software-Nachbildung bekommt dann auch den Attributwert "model=DS2423emu".
Da das noch mit heißer Nadel genäht ist, hänge ich es hier mal zum Testen an.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 15 Januar 2014, 21:26:03
beim Setzen des Attributes "nomemory=1" statt des internen Speichers eine Datei verwendet.
Diese Datei bzw Dateien werden allerdings nicht automatisch erzeugt sondern müssen von Hand im FHEM/ angelegt werden ( OWCOUNT_<name>_14.dat & -15.dat ) sonst gibt es jede Menge Einträge im log :)
Ich habe mit der aktuellen Version aber noch das Problem das ich wesentlich mehr Einträge in meinen logs habe als es nach eingestelltem Intervall sein dürften ( Intervall auf 120 log Einträge aber ca. im 30 Sekunden Takt )
Auszug aus dem log kurz vor Mitternacht (D13 sollte ja eigentlich nur 1x drin stehen) :
2014-02-13_23:58:01 Zaehler day: D13 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 101.8 kWh DG-EnergyM: 188.6 kWh
2014-02-13_23:58:32 Zaehler day: D13 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 101.8 kWh DG-EnergyM: 290.4 kWh
2014-02-13_23:59:00 Zaehler day: D13 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 101.8 kWh DG-EnergyM: 392.1 kWh
2014-02-13_23:59:11 Zaehler day: D13 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 101.8 kWh DG-EnergyM: 494.0 kWh
2014-02-13_23:59:31 Zaehler day: D13 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 101.8 kWh DG-EnergyM: 595.8 kWh
Zuerst hatte ich einen ähnlichen Fehler vermutet wie die letzten Tage in OWTHERM, aber nach einigem Suchen bin ich fündig geworden in der get Abfrage
$hash->{PRESENT} = 1;
#-- only one counter will be returned
OWCOUNT_FormatValues($hash);
return "OWCOUNT: $name.raw $a[2] => ".$hash->{owg_val}->[$page-14];
#-- check syntax for getting counters
}elsif( $reading eq "counters" ){
return "OWCOUNT: Get needs no parameter when reading counters"
if( int(@a)==1 );
$ret1 = OWCOUNT_GetPage($hash,14);
$ret2 = OWCOUNT_GetPage($hash,15);
#-- process results
$ret .= $ret1
if( defined($ret1) );
$ret .= $ret2
if( defined($ret2) );
if( defined($ret1) || defined($ret2) ){
return "OWCOUNT: Could not get values from device $name, reason: ".$ret;
}
$hash->{PRESENT} = 1;
#-- both counters will be returned
return "OWCOUNT: $name.counters => ".OWCOUNT_FormatValues($hash);
Die Aufrufe von OWCOUNT_FormatValues sind verantwortlich für die zusätzlichen Ausgaben.
Hintergrund bei mir : Ich habe auf einem anderen Server einen cronjob laufen der alle 30 Sekunden vom FHEM Server mit get <name> raw (A,B) die aktuellen Zählerstände holt. Ich habe für mich jetzt den ersten der beiden OWCOUNT_FormatValues Aufrufe auskommentiert und liefere damit meinem anderen Server halt den letzten zyklisch ermittelteten Wert von GetValues.
It's not a bug, it's a feature.
Das Modul ist nicht darauf eingerichtet, dass alle paar Sekunden externe Abfragen nach dem Zählerstand kommen - das triggert nämlich jedesmal den Bus.
Warum denn nicht einfach den Wert verwenden, der im Hash steht ?
LG
pah
Ok , in der Form ( aus der Ferne )
/opt/fhem/fhem.pl 192.168.0.10:7072 '{sprintf("%i",$defs{Zaehler}{owg_val}[1])}'
statt
/opt/fhem/fhem.pl 192.168.0.10:7072 "get Zaehler raw B"
oder geht es noch eleganter ?
Hallo zusammen,
Habe heute ein Update von fhem gemacht bei dem auch OWCOUNT upgedatet wurde. Seither habe ich bei der Anzeige cts/h immer 0 stehen, obwohl der Zähler korrekt zählt.
Gibt es hier ein bekanntes Problem?
Benutzt ein DS2423-Nachbau.
Gruß,
Stefan
Hallo Stefan
den gleichen Effekt habe ich auch seit dem update von OWCOUNT 12.02.
Was auch auffällig ist, dass sich in den Readings die Werte von B und B_Rate nicht mehr aktualisieren.
Der Reading Wert mit der Definion BName funktioniert einwandfrei
nur der Reading Wert mit der Definition BRate bleibt auf Null.
Gruß Hannes
Gesendet von Unterwegs mit Tapatalk 4
Ich seh mal nach.
LG
pah
Hallo,
habe es gerade quer gecheckt mit der vorherigen Version,
und nun funktioniert es wieder.
Gruß Hannes
Was heißt denn "quergecheckt" ?
LG
pah
Hallo,
sorry für die Ausdrucksweise ???.
Ich habe die alte Version getestet, ob es mit dieser wieder funktioniert.
Ja bei der alten Version funktionieren die BRate wieder.
Das die Readings von B und B_rate nicht mehr aktualisiert werden, ist bei dieser Version auch,
spielt aber keine Rolle da ich die Rohwerte sowieso nicht mehr verwende.
Gruß und Danke
Hannes
PS:Ich muss sagen, dieses Modul ist echt genial wie einfach man damit eine Leistungserfassung realisieren kann :)
Danke hierfür.
Also, dass die Readings in Kanal B nicht mehr aktualisiert würden, halte ich für ein Gerücht - bei mir funktioniert das auch mit dem fehlerhaften Modul problemlos.
Betreffend die fehlende Rate: Ist auch ein unerwünschter Nebeneffekt des inneren Umbaus gewesen. Bitte mal die anliegende Datei ausprobieren, damit sollte es behoben sein.
LG
pah
Hallo,
mit der angehängten Version wird Rate sowohl bei Kanal A als auch bei B aktualisiert.
Danke.
Das Update des B-Kanals hat in allen Versionen funktioniert. Geht gar nicht anders.
LG
pah
Ja, geht wieder.
Vielen Dank für die schnelle Hilfe.
LG
Stefan
Ich meinte auch nicht das der Kanal B nicht funktioniert,
sondern das die Rohwerte nicht angezeigt werden.
Kanal A ist im Moment unbenutzt.
(http://img.tapatalk.com/d/14/02/17/ypugegum.jpg)
Die umgerechneten Werte werden aktualisiert.
Man sieht es am Datum der Readings, dass war die Uhrzeit als ich die Attribute (BRate , BName,BFactor...) hinzugefügt habe.
Gruß Hannes
Gesendet von Unterwegs mit Tapatalk 4
Hallo,
Habe auch noch festgestellt, dass (beim DS2423emu) im daily -Modus nach einem Restart von FHEM nicht der daily-Wert angezeigt wird sondern der Gesamtwert. Erst nach der ersten Abfrage wird dann der daily-Wert angezeigt. Ist eigentlich nicht weiter schlimm, führt aber zu einem unschönen Ausreißer im Plot.
Hat noch jemand das Problem?
Gruß,
Stefan
Dies scheint mir etwas wirr zu sein.
Welcher "daily"-Wert denn ? Was soll der "Gesamtwert" sein ?
Ein Event wird nur bei einem Auslesen des Zählers erzeugt - auch ein beim Restart falscher Wert kann deshalb nicht im Log landen (nicht im "Plot"...)
LG
pah
Hallo pah,
mit daily-Wert ist der Wert gemeint der im Modus "daily" unter Name angezeigt wird. Und mit Gesamtwert ist der Wert welcher im Modus "normal" unter Name angezeigt wird. Nach dem Restart erhalte ich definitiv einen falschen Eintrag im FileLog.
Kann dir morgen mal ein paar Screenshots schicken.
Wo kommt den der Wert nach dem Restart her, wenn der Counter nicht ausgelesen wird?
Danke für deine Hilfe.
Gruß,
Stefan
Noch einmal: Dieser Wert kann gar nicht im Log landen - und natürlich ist nach einem Restart bis zum ersten Kontakt mit dem Sensor der Messwert nicht definiert.
LG
pah
Kann es sein, dass bei der Verwendung von OWX beim Restart die Werte bei der Initzialisierung abgefragt werden?
Wenn ich heute Nachmittag dazu komme, schicke ich dir ein paar Screenshots als Beleg.
Gruß,
Stefan
Zitat von: Haecksler am 21 Februar 2014, 12:45:29
Kann es sein, dass bei der Verwendung von OWX beim Restart die Werte bei der Initialisierung abgefragt werden?
Wenn ich heute Nachmittag dazu komme, schicke ich dir ein paar Screenshots als Beleg.
Gruß,
Stefan
Anbei die versprochenen Screenshots.
(//)
Versteh ich nicht. Ich schaue aber bei Gelegenheit mal nach.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Januar 2014, 05:42:18
Außerdem ist dieser Kanal im BMode=daily, es wird also jeden Nacht kurz vor Mitternacht der Mitternachtswert extrapoliert und als "day" Wert ausgegeben. Dieser Wert wird auch im internen Memory als "midnight B" gespeichert und vom Zählerstand abgezogen.
- Das monatliche Logging erfolgt durch das FileLog OWCM.FL, siehe dessen Definition darunter. Darin stehen Zeilen wie:
2014-01-09_23:59:42 OWC day: D09 GPunkte: 49.0 cts GPunktem: 49.0 cts E-Energy: 21.6 kWh E-Energym: 21.60 kWh
2014-01-10_23:59:43 OWC day: D10 GPunkte: 89.0 cts GPunktem: 89.0 cts E-Energy: 21.6 kWh E-Energym: 43.20 kWh
sorry , da muss ich nochmal nachfassen : im internen Memory als "midnight B" gespeichert , beim DS2423emu ist das dann aber die Datei FHEM/OWCOUNT_<name>_-15.dat ?
-> und vom Zählerstand abgezogen , aber nicht beim DS2423emu ? denn anders kann ich mir die Einträge im LogM nicht erklären :
2014-02-21_23:59:52 Zaehler day: D21 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 138.3 kWh DG-EnergyM: 1091.4 kWh
2014-02-22_23:59:40 Zaehler day: D22 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 144.1 kWh DG-EnergyM: 1235.5 kWh
2014-02-23_23:59:50 Zaehler day: D23 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 149.7 kWh DG-EnergyM: 1385.2 kWh
2014-02-24_23:59:59 Zaehler day: D24 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 153.5 kWh DG-EnergyM: 1538.7 kWh
2014-02-25_23:59:47 Zaehler day: D25 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 158.3 kWh DG-EnergyM: 1697.0 kWh
2014-02-26_23:59:55 Zaehler day: D26 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 162.5 kWh DG-EnergyM: 1859.5 kWh
2014-02-27_23:59:37 Zaehler day: D27 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 166.8 kWh DG-EnergyM: 2026.2 kWh
2014-02-28_23:59:35 Zaehler day: D28 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 171.8 kWh DG-EnergyM: 2198.1 kWhhier wird doch der aktuelle Stand von DG-Energy auf DG-EnergyM aufsummiert, denn ich verbrauche an diesem Stromzähler zwischen 4-5 kWh am Tag und nicht 140-170 :)
Doch, sollte abgezogen werden.
Was ergibt denn "get Zaehler midnight B" ?
Übrigens: Ich finde es nervig, wenn Hilfesuchende immer nur bröckchenweise Informationen herausrücken. Mal ist es nur ein Screenshot, mal ein paar Zeilen aus dem Log oder dem Eventmonitor - Konfiguration aber bisher nicht. Und die Ergebnisse von so einfachen Kommandos wie dem oben genannten fehlen auch.
LG
pah
OK, ich werde versuchen in Zukunft vollständige Informationen zu liefern ....
FHEM und OWCOUNT aus dem SVN
# $Id: 21_OWCOUNT.pm 5035 2014-02-24 03:47:01Z pahenning $
config :
define Zaehler OWCOUNT DS2423emu A2D984000002 30
attr Zaehler APeriod hour
attr Zaehler AUnit kWh|kWh
attr Zaehler BFactor 0.001
attr Zaehler BMode daily
attr Zaehler BName DG-Energy|energy
attr Zaehler BPeriod hour
attr Zaehler BRate DG-Power|power
attr Zaehler BUnit kWh|kWh
attr Zaehler IODev OW_intern
attr Zaehler LogM OWCM.FL
attr Zaehler LogY OWCY.FL
attr Zaehler event-on-update-reading DG-Energy,DG-Power,day,month
attr Zaehler interval 30
attr Zaehler model DS2423emu
attr Zaehler nomemory 1
attr Zaehler room Dach
define OWCM.FL FileLog ./log/OWCM-%Y-%m.log Zaehler.*day.*
define OWCY.FL FileLog ./log/OWCY-%Y.log Zaehler.*month.*
define Zaehler_log FileLog ./log/Zaehler-%Y-%m.log Zaehler
attr Zaehler_log group Zaehler
attr Zaehler_log logtype text
attr Zaehler_log room Logs
define Zaehler_DB DbLog ./db.conf Zaehler
cat FHEM/OWCOUNT_Zaehler_14.dat
2014-02-28 midnight 0.00
cat FHEM/OWCOUNT_Zaehler_15.dat
2014-02-28 midnight 171.79
get Zaehler midnight A
OWCOUNT: Zaehler.midnight [14] =>0
get Zaehler midnight B
OWCOUNT: Zaehler.midnight [15] =>171.79
das Ende des FHEM logs von gestern (28.2) :
2014.02.28 23:59:35 1: OWCOUNT_store: Zaehler 2014-02-28 midnight 0.00
2014.02.28 23:59:35 1: OWCOUNT_store: Zaehler 2014-02-28 midnight 171.79
Use of uninitialized value in sprintf at ./FHEM/21_OWCOUNT.pm line 554, <OWXFILE> line 31.
Use of uninitialized value in sprintf at ./FHEM/21_OWCOUNT.pm line 554, <OWXFILE> line 31.
Beim Start von FHEM auf der Konsole :
Argument "" isn't numeric in subtraction (-) at ./FHEM/21_OWCOUNT.pm line 445.
der Abschnit des aktuellen logs nach dem Start:
2014.03.01 19:45:50 1: OWX: 1-Wire devices found on bus OW_intern (Temp_intern,Zaehler)
2014.03.01 19:45:50 1: OWX: 1-Wire devices found on bus OW_intern (Temp_intern,Zaehler)
2014.03.01 19:45:52 1: OWCOUNT: model attribute of Zaehler set to DS2423emu because no memory found
nach der Eingabe von get Zaehler midnight hat sich im log was geändert:
2014-03-01_20:05:22 Zaehler DG-Energy: 176.452
2014-03-01_20:05:22 Zaehler DG-Power: 0.6
2014-03-01_20:05:52 Zaehler DG-Energy: 176.456
2014-03-01_20:05:52 Zaehler DG-Power: 0.48
2014-03-01_20:06:12 Zaehler DG-Energy: 4.67
2014-03-01_20:06:12 Zaehler DG-Power: -19124.9999
2014-03-01_20:06:22 Zaehler DG-Energy: 4.671
2014-03-01_20:06:22 Zaehler DG-Power: 0.36
2014-03-01_20:06:52 Zaehler DG-Energy: 4.676
2014-03-01_20:06:52 Zaehler DG-Power: 0.6
2014-03-01_20:07:22 Zaehler DG-Energy: 4.681
2014-03-01_20:07:22 Zaehler DG-Power: 0.6
2014-03-01_20:07:42 Zaehler DG-Energy: 4.681
2014-03-01_20:07:42 Zaehler DG-Power: 0
2014-03-01_20:07:52 Zaehler DG-Energy: 4.686
2014-03-01_20:07:52 Zaehler DG-Power: 1.8
Update :
nach einem Neustart von FHEM sind wieder die absoluten Werte im log. Nach einem get <name> raw , get <name> midnight stimmt die Ausgabe im log,
allerdings stimmt nach Mitternacht der Wert wieder nicht :
2014-03-02_23:59:38 Zaehler DG-Energy: 5.639
2014-03-02_23:59:38 Zaehler DG-Power: 0.12
2014-03-02_23:59:38 Zaehler day: D02 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 5.6 kWh DG-EnergyM: 11.2 kWh
2014-03-03_00:00:08 Zaehler DG-Energy: 5.639
2014-03-03_00:00:08 Zaehler DG-Power: 0
2014-03-03_00:00:38 Zaehler DG-Energy: 5.64
2014-03-03_00:00:38 Zaehler DG-Power: 0.12
2014-03-03_00:01:08 Zaehler DG-Energy: 5.64
2014-03-03_00:01:08 Zaehler DG-Power: 0
Ich glaube das Problem gefunden zu haben :
$hash->{owg_midnight}->[1] hat nach dem Start keinen Wert ( auch nach einigen Minuten, Stunden nicht ) Wird allerdings einmal ein get Kommando aufgerufen steht der richtige Wert sofort zur Verfügung.
Die Frage war für mich also was passiert bei bestimmten get Kommandos was im normalen Ablauf eben nicht passiert ?
Meine Antwort : sowie einmal OWCOUNT_GetPage ausgeführt wurde hat $hash->{owg_midnight}->[1] den richtigen Wert.
Ich habe jetzt den Abschnitt in sub OWCOUNT_GetValues($) geändert :
alt :
if( $interface eq "OWX" ){
$ret1 = OWXCOUNT_GetPage($hash,14,0);
$ret2 = OWXCOUNT_GetPage($hash,15,1);
}elsif( $interface eq "OWServer" ){
neu:
if( $interface eq "OWX" ){
$ret1 = OWCOUNT_GetPage($hash,14,0);
$ret2 = OWCOUNT_GetPage($hash,15,1);
}elsif( $interface eq "OWServer" ){
mal schauen ob heute nach Mitternacht das Problem damit gelöst ist , zumindest beim Neustart sieht es schon mal gut aus
Hallo Wzut,
würdest du bitte nochmals den Teil "alt/neu" in der OWCOUNT_GetValues Routine posten. Ich sehe da keinen Unterschied.
Ich habe gedacht, mein Counter läuft richtig, war wohl falsch gedacht.....
Viele Grüße
Achim
der alt /neu Teil ist schon richtig gepostet , ich musste im Quelltext auch dreimal hinschauen ...
OWXCOUNT vs. OWCOUNT d.h. einmal mit X und einmal ohne :)
Zitat von: Wzut am 03 März 2014, 10:49:44
mal schauen ob heute nach Mitternacht das Problem damit gelöst ist
BINGO : )
2014-03-03_23:59:19 Zaehler DG-Energy: 4.153
2014-03-03_23:59:19 Zaehler DG-Power: 0.48
2014-03-03_23:59:49 Zaehler DG-Energy: 4.156
2014-03-03_23:59:49 Zaehler DG-Power: 0.36
2014-03-03_23:59:49 Zaehler day: D03 A: 0.0 kWh AM: 0.0 kWh DG-Energy: 4.2 kWh DG-EnergyM: 15.3 kWh
2014-03-04_00:00:19 Zaehler DG-Energy: 0
2014-03-04_00:00:19 Zaehler DG-Power: 0
2014-03-04_00:00:49 Zaehler DG-Energy: 0.003
2014-03-04_00:00:49 Zaehler DG-Power: 0.36na also geht doch .....
Das sollte aber nicht so sein.
Denn nach der Abfrage, ob das Interface OWX ist, sollten nur noch die OWX-Routinen aufgerufen werden.
Habe das soeben überprüft: Ja, korrekte Fehlerbeschreibung - mit den Emulatoren wurde der Midnight-Wert nicht richtig aus der Datei geholt.
Ist mir beim Testen nicht aufgefallen, weil ich keinen ATTiny mit dem Originalcode von Tobias Müller betreibe. In meiner Testversion gibt es schon ein internes Memory...
Die bereinigte Version (die im Wesentlichen dasselbe enthält wie der o.a. Workaround) wird heute noch eingecheckt.
LG
pah
OK, danke
Zitat von: Prof. Dr. Peter Henning am 04 März 2014, 08:38:03
weil ich keinen ATTiny mit dem Originalcode von Tobias Müller betreibe. In meiner Testversion gibt es schon ein internes Memory...
gibt es für diese Test Version eine Source Code Quelle ? Auf der Webseite von Tobias Müller steht nach wie vor nur die V1.2 zu Verfügung.
bzw. es gibt wohl noch Versionen die bei Stromausfall den letzten Wert im EEPROM speichern bzw. eine die den SFR02 Sensor direkt unterstützt, auch diese finde ich nicht.
Hallo pah
habe auch noch ein kleines Problem mit Version 5.06. Zum Monatswechsel hat es das hier ins Log geschrieben.
2014-01-31_23:58:11 OWX_1D_AAF60D000000 month: M01 Strom_G: 288.3 kWh Strom_Gy: 0.0 kWh Strom_H: 23.2 kWh Strom_Hy: 0.0 kWh
2014-02-28_23:59:24 OWX_1D_AAF60D000000 month: M02 Strom_G: 528.8M kWh Strom_GY: 41.6 kWh Strom_H: 0.0M kWh Strom_HY: 0.0 kWh
Warum es keine Werte in den B-Kanal geschrieben weiß ich auch nicht, obwohl die Tageslogs richtig sind.
Den Fehler mit den M hab ich schon gefunden.
#-- string buildup for monthly and yearly logging
$dvalue .= sprintf( " %s: %5.1f %s %sM: %%5.1f %s", $owg_channel[$i],$dval,$unit,$owg_channel[$i],$unit);
$mvalue .= sprintf( " %s: %%5.1fM %s %sY: %%5.1f %s", $owg_channel[$i],$unit,$owg_channel[$i],$unit);
Könntest du das auch gleich mit ändern und noch einmal überprüfen ob der Monatswechsel dann richtig funktioniert.
Gruß Bernd
Der "M-Fehler" ist in Version 5.09 ebenfalls behoben. Das mit den fehlenden Werten im B-Kanal kann ich nicht nachvollziehen, denn der wird mit dem A-Kanal gleich behandelt. Muss ggf. noch testen. Dazu wird es aber heute nicht kommen, weil ich heute 7 Stunden Lehre abzuleisten habe und danach in der Regel KO bin.
LG
pah
@Wzut: nein, das gibt es noch nicht öffentlich.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 04 März 2014, 13:40:46
Der "M-Fehler" ist in Version 5.09 ebenfalls behoben. Das mit den fehlenden Werten im B-Kanal kann ich nicht nachvollziehen, denn der wird mit dem A-Kanal gleich behandelt. Muss ggf. noch testen. Dazu wird es aber heute nicht kommen, weil ich heute 7 Stunden Lehre abzuleisten habe und danach in der Regel KO bin.
LG
pah
Kann es sein, dass es nicht am Kanal liegt, sondern im Modus in dem dieser betrieben wird?
Wenn ich es richtig gesehen habe ist nur Kanal B im "daily" Modus.
Ich hatte bei mir das gleich Ergebnis beim MonatsLog, auch bei mir war nur Kanal B im "daily" Modus und hat nichts ins MonatsLog geschrieben.
lg
Stefan
Hallo Pah,
ich habe OWCOUNT grade für das asynchrone OWX fit gemacht (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm), es wäre nett, wenn Du auch noch mal draufschaust, bevor ich das ins SVN committe. Ich habe selber (noch) keinen echten DS2423, nur einen ATTiny-emulierten und kann deshalb nicht die komplette Bandbreite abtesten.
Was mir aufgefallen ist (schon bevor ich die asynchronen Anteile feingeschliffen habe), das mit den midnight-werten in Files funktioniert noch nicht sauber, weil die Files initial ja erst mal noch nicht da sind:
Use of uninitialized value $strval in pattern match (m//) at ./FHEM/21_OWCOUNT.pm line 1752.
Use of uninitialized value $strval in substitution (s///) at ./FHEM/21_OWCOUNT.pm line 1757.
Use of uninitialized value $data in concatenation (.) or string at ./FHEM/21_OWCOUNT.pm line 1768.
Use of uninitialized value in substr at ./FHEM/21_OWCOUNT.pm line 1135.
Use of uninitialized value $strval in pattern match (m//) at ./FHEM/21_OWCOUNT.pm line 827.
Use of uninitialized value $strval in substitution (s///) at ./FHEM/21_OWCOUNT.pm line 832.
Use of uninitialized value $strval in pattern match (m//) at ./FHEM/21_OWCOUNT.pm line 827.
Use of uninitialized value $strval in substitution (s///) at ./FHEM/21_OWCOUNT.pm line 832.
(Die Zeilennummern beziehen sich auf die oben verlinkte OWCOUNT-version in meinem Github-repository).
Gruß,
Norbert
Hm, ich bin derzeit vollständig ausgebucht, weil ich in der nächsten Woche ein Treffen meines Projektteams in Israel zu koordinieren habe. Kann ich also derzeit nicht vor der übernächsten Woche versprechen.
LG
pah
Hallo ich lasse mir den Verbrauch momentan und den bisher verbrauchten Strom
Anzeigen mit.
attr Strom_A1 stateFormat { sprintf("%.1f kWh %.3f kWh", ReadingsVal("Strom_A1","E-Energy","kwh"), ReadingsVal("Strom_A1","E-Power","kwh"));; }
Soweit so gut aber wenn ich jetzt ein Update von Fhem mache wird es nicht mehr
Angezeigt ist da was geändert worden??
Gruß
Martin
Hallo Martin,
ist eine gute Frage. Mein Log sieht jetzt so aus:
2014-04-02_13:22:10 H.U.ST.HK Stromverbrauch: 3.443 kWk Stromverbrauch_rate: 0.3480 kWk/h Stromverbrauch2: 5.140 kWk Stromverbrauch2_rate: 0.8760 kWk/h
2014-04-02_13:27:11 H.U.ST.HK Stromverbrauch: 3.473 kWk Stromverbrauch_rate: 0.3588 kWk/h Stromverbrauch2: 5.227 kWk Stromverbrauch2_rate: 1.0405 kWk/h
2014-04-02_19:02:49 H.U.ST.HK Stromverbrauch: 2112.681 kWk Stromverbrauch_rate: 0.0000 kWk/h Stromverbrauch2: 1872.374 kWk Stromverbrauch2_rate: 0.0000 kWk/h
2014-04-02_19:07:49 H.U.ST.HK Stromverbrauch: 2112.697 kWk Stromverbrauch_rate: 0.1920 kWk/h Stromverbrauch2: 5.914 kWk Stromverbrauch2_rate: -21611.0879 kWk/h
2014-04-02_19:07:49 H.U.ST.HK Stromverbrauch: 2112.697 kWk Stromverbrauch_rate: 0.0000 kWk/h Stromverbrauch2: 1872.384 kWk Stromverbrauch2_rate: 0.0000 kWk/h
2014-04-02_19:12:49 H.U.ST.HK Stromverbrauch: 2112.712 kWk Stromverbrauch_rate: 0.1800 kWk/h Stromverbrauch2: 5.924 kWk Stromverbrauch2_rate: -21611.0879 kWk/h
2014-04-02_19:12:49 H.U.ST.HK Stromverbrauch: 2112.712 kWk Stromverbrauch_rate: 0.0000 kWk/h Stromverbrauch2: 1872.394 kWk Stromverbrauch2_rate: 0.0000 kWk/h
Version von OWCOUNT $Id: 21_OWCOUNT.pm 5383 2014-03-31 14:27:23Z ntruchsess $
Die ersten beiden Zeilen waren noch vor dem Update. Danach gab es einen FHEM Neustart und OWX war aus der Konfig verschwunden.
Zitat von: Martin am 02 April 2014, 19:22:09
Angezeigt ist da was geändert worden??
hm, meine Änderung vom 31.03.2014 dürfte nach menschlichem Ermessen keine Auswirkungen haben, wenn man das normale (00_OWX.pm) OWX-modul verwendet, da ist nur der Autodetect von 00_OWX_ASYNC.pm drin. Die für OWX_ASYNC überarbeitete Version ist noch nicht im SVN-trunk, sondern nur im meinem Github-repository (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm), ich muss da noch etwas mehr testen.
Die Änderungen von Pah vom 27.03.2014 sind da schon umfangreicher (Unterstützung der unterschiedlichen DS2423-emulationen). Da kann ich auf die Schnelle jetzt aber auch nicht überblicken, ob das mit Deinem stateFormat zusammenspielt, da fehlt mir Deine Definition von E-Power und E-Energy dafür, das sind ja keine originären OWCount-readings.
@Alexander: überprüfe mal, ob die IODevs an den OWX-clients richtig gesetzt sind. Das OWX selbst kann ja nicht so einfach verschwinden, das müsste 'wenigstens' eine Fehlermeldung (auf STDOUT) wenn es nicht compilieren würde, weil z.B. vom Update nicht vollständig geladen, auswerfen. (In dem Fall wäre es zwar nicht in der Config, aber auf der Webconsole verschwunden)
Zitat von: Prof. Dr. Peter Henning am 02 April 2014, 16:53:30
Hm, ich bin derzeit vollständig ausgebucht
Passt schon, ich habe grade von Tobias einen echten DS2423 gekauft, wenn der da ist, kann ich selber testen.
Muss eh noch das asynchrone DS2480-Busmaster-Modul fertig machen, ist bisher ja nur für FRM im SVN committet.
Gruß,
Norbert
Eher eine generelle Frage: wie könnte der Workaround sein, dass der Wert pro Auslesen (z.b. alle 30sec) genullt wird? Möchte den OWCOUNT für einen Windsensor (bereits mit einem DS2423 installiert) verwenden.
Hallo zusammen,
seit dem Update bekomme ich keine Werte mehr von meinen Countern.
Benutze 2 DS2423eold.
Hat noch jemand Probleme damit?
Gruß,
Stefan
Hallo,
nach dem Update am 02.04. ging bei mir die Kombination FRM, OWX, OWTHERM und OWCOUNT nicht mehr. Da ich momentan keine Zeit habe mir das genauer anzusehen, habe ich das Backup wieder eingespielt. Bei mir ging aber schon die Kommunikation Arduino mit FRM nicht mehr richtig.
Auch ein Restart des Arduino mit erneutem Neustart von FHEM brachte keine Besserung. Ich poste mal den Inhalt meines Logfiles.
Zitat2014.04.02 21:41:01 3: OWTHERM: Device Heizraum_DS2 defined.
2014.04.02 21:41:02 3: OWCOUNT: Device OWX_Z1 defined.
2014.04.02 21:41:04 1: Including /var/log/fhem/fhem.save
2014.04.02 21:41:05 3: Ardu_Nano1: port 3030 opened
2014.04.02 21:41:05 1: OWX: 1-Wire bus NANO1_D3: interface Firmata detected in Ardu_Nano1
2014.04.02 21:41:06 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
2014.04.02 21:41:06 1: usb create starting
2014.04.02 21:41:09 1: usb create end
2014.04.02 21:41:09 3: myOWServer: Opening connection to OWServer localhost:4304...
2014.04.02 21:41:09 3: myOWServer: Successfully connected to localhost:4304.
2014.04.02 21:41:10 2: SecurityCheck: telnetPort has no password/globalpassword attribute. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.04.02 21:41:10 0: Server started with 159 defined entities (version $Id: fhem.pl 5369 2014-03-30 06:58:52Z rudolfkoenig $, os linux, user fhem, pid 25446)
Use of uninitialized value $strval in pattern match (m//) at /usr/share/fhem/FHEM/21_OWCOUNT.pm line 1741.
Use of uninitialized value $strval in substitution (s///) at /usr/share/fhem/FHEM/21_OWCOUNT.pm line 1746.
Use of uninitialized value $data in concatenation (.) or string at /usr/share/fhem/FHEM/21_OWCOUNT.pm line 1757.
Use of uninitialized value in substr at /usr/share/fhem/FHEM/21_OWCOUNT.pm line 1130.
2014.04.02 21:41:12 1: OWCOUNT: model attribute of OWX_Z1 set to DS2423eold because no memory found
2014.04.02 21:41:15 1: OWX: 1-Wire devices found on bus NANO1_D3 ()
2014.04.02 21:41:46 3: set Therme_Steuerung defined : Unknown argument defined, choose one of eco interval mode off on
2014.04.02 21:41:46 3: Therme_Steuerung_at1: Unknown argument defined, choose one of eco interval mode off on
2014.04.02 21:42:06 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
2014.04.02 21:43:06 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
2014.04.02 21:44:06 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
2014.04.02 21:45:06 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
Viele Grüße
Achim
Hallo Achim,
poste doch mal bitte alles relevante zu 'HCS Therme_Steuerung' aus Deiner config. Das versucht ja schon zu schalten, bevor der Arduino sich über das Netzwerk gemeldet hat, das kann in dem Moment gar nicht funktionieren.
Die 'Use of uninitialized value' habe ich mit meinem emulierten DS2423 auch. Zählt dann aber trotzdem (natürlich ohne midnight-werte).
Gruß,
Norbert
Hallo,
Habe auch das Backup eingespielt jetzt geht es wieder.
Gruß,
Haecksler
Hallo Norbert,
mein Logfile sieht bei "Normalbetrieb" folgendermaßen aus:
Zitat2014.04.04 19:41:58 1: Including /etc/fhem.cfg
2014.04.04 19:42:01 3: WEB: port 8083 opened
2014.04.04 19:42:02 3: WEBphone: port 8084 opened
2014.04.04 19:42:02 3: WEBtablet: port 8085 opened
2014.04.04 19:42:04 3: Opening COC device /dev/ttyAMA0
2014.04.04 19:42:05 3: Setting COC baudrate to 38400
2014.04.04 19:42:05 3: COC device opened
2014.04.04 19:42:05 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2014.04.04 19:42:05 3: telnetPort: port 7072 opened
2014.04.04 19:42:12 3: OWTHERM: Device Heizraum_DS2 defined.
2014.04.04 19:42:13 3: OWCOUNT: Device OWX_Z1 defined.
2014.04.04 19:42:16 1: Including /var/log/fhem/fhem.save
2014.04.04 19:42:17 3: Ardu_Nano1: port 3030 opened
2014.04.04 19:42:17 1: OWX: 1-Wire bus NANO1_D3: interface Firmata detected in Ardu_Nano1
2014.04.04 19:42:18 1: HCS Therme_Steuerung An error occurred while switching device 'Therme_EinAus': Therme_EinAus, Ardu_Nano1 is not connected at /usr/share/fhem/FHEM/10_FRM.pm line 588.
2014.04.04 19:42:18 1: usb create starting
2014.04.04 19:42:21 1: usb create end
2014.04.04 19:42:21 3: myOWServer: Opening connection to OWServer localhost:4304...
2014.04.04 19:42:21 3: myOWServer: Successfully connected to localhost:4304.
2014.04.04 19:42:22 0: Server started with 159 defined entities (version $Id: fhem.pl 5369 2014-03-30 06:58:52Z rudolfkoenig $, os linux, user fhem, pid 29716)
2014.04.04 19:42:29 3: querying Firmata Firmware Version
2014.04.04 19:42:29 3: Firmata Firmware Version: Eth1.ino V_2_05
2014.04.04 19:42:29 3: received String_data: Unhandled sysex command
2014.04.04 19:42:31 3: Therme_Steuerung_Set2 return value: Unknown argument $EVTPART1, choose one of eco interval mode off on
2014.04.04 19:42:32 3: received String_data: Unhandled sysex command
2014.04.04 19:42:32 1: HCS Therme_Steuerung monitoring of devices started
2014.04.04 19:42:35 1: OWCOUNT: model attribute of OWX_Z1 set to DS2423eold because no memory found
2014.04.04 19:42:38 1: OWX: 1-Wire devices found on bus NANO1_D3 (Heizraum_DS2,OWX_Z1)
2014.04.04 19:42:41 1: OWX: 1-Wire devices found on bus NANO1_D3 (Heizraum_DS2,OWX_Z1)
2014.04.04 19:42:58 1: HCS Therme_Steuerung monitoring of devices started
der Auszug aus der fhem.cfg
Zitatdefine Ardu_Nano1 FRM 3030 global
attr Ardu_Nano1 room FRM_Nano
define Heizung_Hauptschalter FRM_IN 14
attr Heizung_Hauptschalter IODev Ardu_Nano1
attr Heizung_Hauptschalter room FRM_Nano
attr Heizung_Hauptschalter stateFormat reading
define NANO1_D3 OWX 3
attr NANO1_D3 IODev Ardu_Nano1
attr NANO1_D3 room FRM_Nano
define Heizraum_DS2 OWTHERM DS18B20 F0EBCA040000 60
attr Heizraum_DS2 IODev NANO1_D3
attr Heizraum_DS2 model DS1822
attr Heizraum_DS2 resolution 12
attr Heizraum_DS2 room FRM_Nano,Temperaturen
attr Heizraum_DS2 tempHigh 75
attr Heizraum_DS2 tempLow 70
define FileLog_Heizraum_DS2 FileLog /var/log/fhem/Heizraum_DS2-%Y.log Heizraum_DS2:temperature:\s*-{0,1}\d+[\.\d]*$
attr FileLog_Heizraum_DS2 logtype temp4,text
attr FileLog_Heizraum_DS2 room FRM_Nano,Temperaturen
define SVG_UG_Heizraum_DS2 SVG FileLog_Heizraum_DS2:temp4:CURRENT
attr SVG_UG_Heizraum_DS2 label "Heizraum Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_UG_Heizraum_DS2 room FRM_Nano
define OWX_Z1 OWCOUNT DS2423eold A2D988000002 60
attr OWX_Z1 AFactor 0.01
attr OWX_Z1 AMode daily
attr OWX_Z1 AName Gas|volume
attr OWX_Z1 AOffset 164403.0
attr OWX_Z1 ARate hour
attr OWX_Z1 AUnit Kubikmeter|m³
attr OWX_Z1 IODev NANO1_D3
attr OWX_Z1 LogM FileLog_Gasverbrauch_Monat
attr OWX_Z1 LogY FileLog_Gasverbrauch_Jahr
attr OWX_Z1 nomemory 1
attr OWX_Z1 room FRM_Nano
define FileLog_Gasverbrauch_Tag FileLog /var/log/fhem/Gasverbrauch_Tag-%Y-%m.log OWX_Z1.*m³.*
attr FileLog_Gasverbrauch_Tag room FRM_Nano
define FileLog_Gasverbrauch_Monat FileLog /var/log/fhem/Gasverbrauch_Monat-%Y-%m.log OWX_Z1:*day.*
attr FileLog_Gasverbrauch_Monat room FRM_Nano
define FileLog_Gasverbrauch_Jahr FileLog /var/log/fhem/Gasverbrauch_Jahr-%Y.log OWX_Z1:*month.*
attr FileLog_Gasverbrauch_Jahr room FRM_Nano
define SVG_UG_Gas SVG FileLog_Gasverbrauch_Tag:gasg4gasa6:CURRENT
attr SVG_UG_Gas label "Gasverbrauch Min $data{min2}, Max $data{max2}, Gesamt $data{max1}"
attr SVG_UG_Gas room FRM_Nano
define Therme_Steuerung HCS Therme_EinAus
attr Therme_Steuerung deviceCmdOff on
attr Therme_Steuerung deviceCmdOn off
attr Therme_Steuerung event-on-change-reading state,devicestate,eco,overdrive,Heizung_Ein,Heizung_Aus
attr Therme_Steuerung fp_EG 87,1040,1,Therme Steuerung
attr Therme_Steuerung idleperiod 10
attr Therme_Steuerung interval 1
attr Therme_Steuerung loglevel 4
attr Therme_Steuerung mode thermostat
attr Therme_Steuerung room FHT
attr Therme_Steuerung sensor Aussenfuehler1
attr Therme_Steuerung sensorReading temperature
attr Therme_Steuerung sensorThresholdOff 19
attr Therme_Steuerung sensorThresholdOn -20
attr Therme_Steuerung thermostatThresholdOff 0.2
attr Therme_Steuerung thermostatThresholdOn 0.2
attr Therme_Steuerung valveThresholdOff 40
attr Therme_Steuerung valveThresholdOn 35
define Therme_Steuerunglog FileLog /var/log/fhem/Therme_Steuerung-%Y-%m.log Therme_Steuerung
define Therme_Steuerungslog_at1 at *23:59 {addLog("Therme_Steuerung","devicestate")}
define Therme_Steuerungslog_at2 at *00:01 {addLog("Therme_Steuerung","devicestate")}
define SVG_W_Therme_Steuerung SVG Therme_Steuerunglog:therme:CURRENT
attr SVG_W_Therme_Steuerung label "Therme_Ein/Aus Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_W_Therme_Steuerung room FHT
# definiertes Ein/Ausschalten der Therme_Steuerung nach einem Neustart aufgrund des Heizungs Hauptschalters
define Therme_Steuerung_Set1 notify global:INITIALIZED define Therme_Steuerung_at1 at +00:00:40 {fhem ("set Therme_Steuerung ".Value("Heizung_Hauptschalter"))}
# Ein/Ausschalten der Themesteuerung aufgrund des Heizungs Hauptschalters
define Therme_Steuerung_Set2 notify Heizung_Hauptschalter set Therme_Steuerung $EVTPART1
Der HCS Error mit FRM und der Error mit dem EVTPART1 kommt wohl daher, das zu der Ausführungszeit die Firmataverbindung noch nicht aktiv ist und daher die Eingänge noch keine Werte haben.
Viele Grüße
Achim
ja, das sehe ich genauso. Das ist mit dem OWX in deinem Logfile vom 02.04 auch so, da läuft das OWX los und macht seinen Device-scan bevor der Arduino verbunden hat. Das ist im synchronen OWX aber eigentlich schon immer so, das läuft nach dem Initialisieren nach 10 Sekunden per InternalTimer los und macht den DeviceScan.
Wenn FRM dann betriebsbereit ist, findet es dazugehörige OWX, configuriert die 1-Wire-pins und ruft dann OWX_Discover (noch mal) auf. Ab da sollte dann alles passen.
Keine Ahnung, warum sich Dein Arduino nicht beim FRM gemeldet hat. Hört das Log vom 02.04. denn da einfach auf?
Gruß,
Norbert
Hallo,
nach dem letzten Update habe ich auch mit dem OWCOUNT Probleme.
Es tauche folgende Einträge im Log auf:
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.49
2014-04-05_12:10:36 OWC Gasverbrauch_rate: 1.08
2014-04-05_12:10:36 OWC B: 1
2014-04-05_12:10:36 OWC B_rate: 0
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.490 m3 Gasverbrauch_rate: 1.0800 m3/h B: 1.0 cts B_rate: 0.00 cts/h
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.49
2014-04-05_12:10:36 OWC Gasverbrauch_rate: 0
2014-04-05_12:10:36 OWC B: 1
2014-04-05_12:10:36 OWC B_rate: 0
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.490 m3 Gasverbrauch_rate: 0.0000 m3/h B: 1.0 cts B_rate: 0.00 cts/h
---------
Es sieht so aus, als ob da was doppelt ausgeführt wird. Im ersten Durchlauf wird alles korrekt gerechnet, und im zweiten dann die Differenz zu dem Aufruf direkt davor,...
Fehlt da eine Konfigurationseinstellung?
Grüße
Dennis
Hallo Norbert,
es ist nichts mehr weiter im Logfile was FRM, OWX und OWxxx Module betrifft. Ich habe auch max. 2-3 min gewartet bis ich erneute Restarts und Resets des Arduino gemacht habe. Bei diesem Update bin ich auch sehr schnell ohne größere Tests wieder auf das Backup zurück. Ich bin ab morgen bis Ostern weg und da will ich das System nicht instabil "zurücklassen" (wegen dem WAF Faktor) ;)
Viele Grüße
Achim
Hallo zusammen,
ich habe soeben auch ein Update durchgeführt und bekomme folgenden Meldungen:
2014.04.05 14:28:13 3: myOWFS: Opening connection to OWServer localhost:4304...
2014.04.05 14:28:13 3: myOWFS: Successfully connected to localhost:4304.
2014.04.05 14:28:13 0: Server started with 116 defined entities (version $Id: fhem.pl 5413 2014-04-02 11:05:28Z rudolfkoenig $, os linux, user root, pid 840)
2014.04.05 14:28:15 3: OWX: Reset called with undefined interface
2014.04.05 14:28:15 3: OWX: Complex called with undefined interface
2014.04.05 14:28:15 3: OWX: Reset called with undefined interface
2014.04.05 14:28:15 3: OWX: Complex called with undefined interface
2014.04.05 14:28:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!
2014.04.05 14:28:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_15.dat for reading!
2014.04.05 14:28:16 3: OWX: Reset called with undefined interface
2014.04.05 14:28:16 3: OWX: Complex called with undefined interface
2014.04.05 14:28:16 3: OWX: Reset called with undefined interface
2014.04.05 14:28:16 3: OWX: Complex called with undefined interface
2014.04.05 14:28:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_14.dat for reading!
2014.04.05 14:28:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_15.dat for reading!
2014.04.05 14:28:18 3: OWX: Answer to CUNO device search is 1:C10008028A843B10
2014.04.05 14:28:18 1: OWX: 1-Wire devices found on bus OWCUNO (temp_wohnzimmer)
2014.04.05 14:33:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!
2014.04.05 14:33:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_15.dat for reading!
2014.04.05 14:33:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_14.dat for reading!
2014.04.05 14:33:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_15.dat for reading!
2014.04.05 14:38:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!
2014.04.05 14:38:16 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_15.dat for reading!
2014.04.05 14:38:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_14.dat for reading!
2014.04.05 14:38:17 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C1_15.dat for reading!
Grüße
Rainer
Zitat von: ergerd am 05 April 2014, 14:42:18ich habe soeben auch ein Update durchgeführt und bekomme folgenden Meldungen:
Hallo Rainer,
kannst Du bitte auch deine fhem.cfg dazu posten, so kann ich nicht wissen welches Interface OWX eigentlich nutzen möchte.
Die 'Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!' habe ich beim Testen mit meinem DS2423-nachbau auch bekommen, die Nutzt OWCOUNT um die Midnight-werte abzuspeichern. Beim ersten Starten sind die natürich noch nicht da (das führt dann auch noch zu weiteren Fehlern). Ich bin grade am untersuchen, ob das nur kosmetisch ist, oder ernsthaft stört (wenn die ersten midnight-werte gespeichert wurden, gibt's die Dateien und alles scheint zu gehen).
Gruß,
Norbert
Hallo Norbert,
hier der Part aus meiner fhem.cfg:
define myOWFS OWServer localhost:4304
attr myOWFS nonblocking 1
attr myOWFS room hidden
define myOWFS_C1 OWCOUNT DS2423 2BD20D000000 300
attr myOWFS_C1 AFactor 0.001
attr myOWFS_C1 AMode daily
attr myOWFS_C1 AName Stromverbrauch1|energy
attr myOWFS_C1 APeriod hour
attr myOWFS_C1 ARate Leistung1|power
attr myOWFS_C1 AUnit kWh|kWh
attr myOWFS_C1 BFactor 0.001
attr myOWFS_C1 BMode daily
attr myOWFS_C1 BName Stromverbrauch2|energy
attr myOWFS_C1 BPeriod hour
attr myOWFS_C1 BRate Leistung2|power
attr myOWFS_C1 BUnit kWh|kWh
attr myOWFS_C1 IODev myOWFS
attr myOWFS_C1 LogM FileLog_myOWFS_C_M
attr myOWFS_C1 fp_Erdgeschoss 820,200,0,
attr myOWFS_C1 model DS2423
attr myOWFS_C1 room hidden
define myOWFS_C2 OWCOUNT DS2423 404C0F000000 300
attr myOWFS_C2 AFactor 0.001
attr myOWFS_C2 AMode daily
attr myOWFS_C2 AName Stromverbrauch3|energy
attr myOWFS_C2 APeriod hour
attr myOWFS_C2 ARate Leistung3|power
attr myOWFS_C2 AUnit kWh|kWh
attr myOWFS_C2 BFactor 0.001
attr myOWFS_C2 BMode daily
attr myOWFS_C2 BName Stromverbrauch4|energy
attr myOWFS_C2 BPeriod hour
attr myOWFS_C2 BRate Leistung4|power
attr myOWFS_C2 BUnit kWh|kWh
attr myOWFS_C2 IODev myOWFS
attr myOWFS_C2 LogM FileLog_myOWFS_C_M
attr myOWFS_C2 fp_Erdgeschoss 830,200,0,
attr myOWFS_C2 model DS2423
attr myOWFS_C2 room hidden
define FileLog_myOWFS_C FileLog /volumeUSB1/usr/local/FHEM/var/log/myOWFS_C-%Y-%m.log (myOWFS_C1|myOWFS_C2).*(kWh).*
attr FileLog_myOWFS_C room 90_logfiles
define wl_FileLog_myOWFS_C_1 SVG FileLog_myOWFS_C:wl_FileLog_myOWFS_C_1:CURRENT
attr wl_FileLog_myOWFS_C_1 room 41_keller_grafik
define FileLog_myOWFS_C_M FileLog /volumeUSB1/usr/local/FHEM/var/log/myOWFS_C_M-%Y-%m.log (myOWFS_C1|myOWFS_C2):day.*
attr FileLog_myOWFS_C_M room 90_logfiles
define DS1420_16D030000000 OWDevice 81.16D030000000
attr DS1420_16D030000000 IODev myOWFS
attr DS1420_16D030000000 model DS1420
attr DS1420_16D030000000 room hidden
define DS2423_404C0F000000 OWDevice 1D.404C0F000000 60
attr DS2423_404C0F000000 IODev myOWFS
attr DS2423_404C0F000000 model DS2423
attr DS2423_404C0F000000 room hidden
define DS2423_2BD20D000000 OWDevice 1D.2BD20D000000 60
attr DS2423_2BD20D000000 IODev myOWFS
attr DS2423_2BD20D000000 model DS2423
attr DS2423_2BD20D000000 room hidden
Grüße
Rainer
Zitat von: Dennis_S am 05 April 2014, 12:15:29
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.490 m3 Gasverbrauch_rate: 1.0800 m3/h B: 1.0 cts B_rate: 0.00 cts/h
...
2014-04-05_12:10:36 OWC Gasverbrauch: 1001.490 m3 Gasverbrauch_rate: 0.0000 m3/h B: 1.0 cts B_rate: 0.00 cts/h
---------
Es sieht so aus, als ob da was doppelt ausgeführt wird. Im ersten Durchlauf wird alles korrekt gerechnet, und im zweiten dann die Differenz zu dem Aufruf direkt davor,...
kannst Du mal bitte mit dieser gepatchten Version testen: 21_OWCOUNT.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm), ich denke, ich habe da schon einen Fix für dieses doppelt-drucken drin.
Gruß,
Norbert
Zitat von: ergerd am 05 April 2014, 21:21:46
Hallo Norbert,
hier der Part aus meiner fhem.cfg:
...
Hallo Rainer,
da werd ich nicht schlau draus, der Part mit der OWX-config fehlt da wohl?
Gruß,
Norbert
Hallo Norbert,
OWX-config ... hm ...
da habe ich nur das:
define OWCUNO OWX CUNO
attr OWCUNO buspower real
attr OWCUNO room hidden
Das habe ich allerdings nicht mit dem OWServer in Zusammenhang gebracht.
Der Einfachheit halber hänge ich meine ganze fhem.cfg mal an.
Grüße
Rainer
Zitat von: ntruchsess am 05 April 2014, 22:48:12
kannst Du mal bitte mit dieser gepatchten Version testen: 21_OWCOUNT.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm), ich denke, ich habe da schon einen Fix für dieses doppelt-drucken drin.
Gruß,
Norbert
Hi Norbert,
danke, die gepatchte Version hat die doppelten Einträge beseitigt.
Grüße
Dennis
Es geht hier längst nicht mehr um die von mir aufgespielte Version von OWCOUNT. Im einen Fall sind es Arduino-Probleme, im anderen Fall hat der Post mit OWX gar nichts zu tun, sondern dreht sich um OWServer/OWDevice.
Bitte macht dazu neue Threads auf.
LG
pah
Zitat von: ergerd am 06 April 2014, 08:20:16
Das habe ich allerdings nicht mit dem OWServer in Zusammenhang gebracht.
Hallo Rainer,
das hat auch nix mit dem OWServer oder OWCOUNT zu tun, nur konnte ich das ohne Deine fhem.cfg nicht wissen.
Funktionieren die OWCOUNTs denn nach den 'Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!'-Startupmeldungen? Nach meinem Verständnis sollten sie das. Die Fehlenden Dateien sollten später (mit der generierung der ersten midnight-werte) automatisch angelegt werden.
Falls das OWTHERM am CUNO nach den 'Reset called with undefined interface' nicht funktioniert, mach bitte wie von Pah gewünscht einen neuen Thread auf, das wäre eine andere Baustelle.
Gruß,
Norbert
Hallo
habe heute auch ein Update von Version 5.09 auf 5.11 und 5.12 gemacht. Habe zwei richtige DS2423.
Bei den neuen Versionen werden die Midnight Werte leider nicht richtig ausgelesen sind alle 0.
Dadurch stimmen natürlich die Readings nicht. Müsste wieder zurück zur 5.09.
Gruß Bernd
Hallo Norbert,
Grundsätzlich funktionierten sie, jedoch waren die Werte nicht zu gebrauchen (sie waren um den Faktor 10 höher als zuvor), teilweise habe ich negative Werte gesehen.
Leider kann ich kein Beispiel posten, da ich die fehlerhaften Einträge nach Rücksetzen auf die alte Version aus den Logs entfernt habe.
Wenn das wichtig ist kann ich das Update nochmal durchführen, es gibt ja immer ein zurück :-)
Grüße
Rainer
Zitat von: ergerd am 06 April 2014, 16:23:15
Grundsätzlich funktionierten sie, jedoch waren die Werte nicht zu gebrauchen (sie waren um den Faktor 10 höher als zuvor), teilweise habe ich negative Werte gesehen.
Das ist natürich remote schlecht nachzuvollziehen. Es gibt in der 5.11 wohl ein Problem mit doppelter Ausführung der OWCOUNT_FormatValues-methode, das könnte hier für 'Verwirrung' gesorgt haben. Das sollte in der Version, die ich aktuell für das asynchrone OWX fit gemacht habe (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm) schon gefixed sein. Vieleicht machst Du zum Testen noch mal das Update und spielst anschließend diese Version noch manuel ein. Die läuft auch mit dem normalen OWX, ich kann aktuell leider nur mit FRM testen, mein DS2480-Busmaster ist mir grade kaputtgegangen, der Ersatz ist aber unterwegs.
Gruß,
Norbert
Hallo Norbert,
ich habe das Update gemacht, dann die alte mit der neuen 21_OWCOUNT.pm überschrieben und shutdown restart durchgeführt.
fhem Logfile:
2014.04.07 18:46:52 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_14.dat for reading!
2014.04.07 18:46:52 1: OWCOUNT_recall: Cannot open OWCOUNT_myOWFS_C2_15.dat for reading!
Logfile der Counter:
Einträge VOR dem Update:
2014-04-07_18:38:35 myOWFS_C1 Stromverbrauch1: 1112.120 kWh Leistung1: 0.00 kW Stromverbrauch2: 596.050 kWh Leistung2: 0.21 kW
2014-04-07_18:38:35 myOWFS_C2 Stromverbrauch3: 1281.940 kWh Leistung3: 0.00 kW Stromverbrauch4: 640.160 kWh Leistung4: 0.00 kW
Einträge NACH dem Update:
2014-04-07_18:41:52 myOWFS_C2 Stromverbrauch3: 1287.059 kWh Leistung3: 93.5452 kW Stromverbrauch4: 640.164 kWh Leistung4: 0.0731 kW
2014-04-07_18:41:52 myOWFS_C2 Stromverbrauch3: 1287.059 kWh Leistung3: 0.0000 kW Stromverbrauch4: 1594.024 kWh Leistung4: 0.0000 kW
2014-04-07_18:41:53 myOWFS_C1 Stromverbrauch1: 1117.233 kWh Leistung1: 92.9636 kW Stromverbrauch2: 596.067 kWh Leistung2: 0.3091 kW
2014-04-07_18:41:53 myOWFS_C1 Stromverbrauch1: 1117.233 kWh Leistung1: 0.0000 kW Stromverbrauch2: 1482.427 kWh Leistung2: 0.0000 kW
2014-04-07_18:46:52 myOWFS_C2 Stromverbrauch3: 1287.061 kWh Leistung3: 0.0240 kW Stromverbrauch4: 640.166 kWh Leistung4: -10659.8639 kW
2014-04-07_18:46:52 myOWFS_C2 Stromverbrauch3: 1287.061 kWh Leistung3: 0.0000 kW Stromverbrauch4: 1594.026 kWh Leistung4: 0.0000 kW
2014-04-07_18:46:53 myOWFS_C1 Stromverbrauch1: 1117.233 kWh Leistung1: 0.0000 kW Stromverbrauch2: 596.084 kWh Leistung2: -9849.6839 kW
2014-04-07_18:46:53 myOWFS_C1 Stromverbrauch1: 1117.233 kWh Leistung1: 0.0000 kW Stromverbrauch2: 1482.444 kWh Leistung2: 0.0000 kW
Grüße
Rainer
Hallo Rainer,
danke für's testen. Jetzt sehe ich auch, dass da was nicht stimmt, ich hab die ganze Zeit nur auf die eigentlichen Zählerwerte, nicht auf die daraus abgeleiteten Größen geachtet. Ich schau mir mal an, wo das herkommt bzw. was sich da im Vergleich zur 5.09 geändert hat.
Gruß,
Norbert
Hallo Rainer,
ich denke ich war da schon auf der richtigen Spur, nur hatte ich den Fix für OWX und nicht auch für OWServer gemacht. Das habe ich jetzt nachgezogen (https://github.com/ntruchsess/fhem-mirror/commit/a535e37909d1da08055631658537e6f3bf3edf0e).
Kannst Du bitte noch mal testen: 21_OWCOUNT.pm Version 5.14 (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm). Ich habe grade leider keine OWServer-installation zur Hand.
Gruß,
Norbert
Zitat von: Wzut am 14 Februar 2014, 19:41:42
/opt/fhem/fhem.pl 192.168.0.10:7072 '{sprintf("%i",$defs{Zaehler}{owg_val}[1])}'
statt
/opt/fhem/fhem.pl 192.168.0.10:7072 "get Zaehler raw B"
oder geht es noch eleganter ?
Hallo Jürgen,
Eleganter wäre ein Aufruf von 'ReadingsVal("Zaehler","B","")' (alternativ auch ReadingsNum...).
Noch eleganter wäre es ein notify zu benutzen.
get-Aufrufe in Programcode zu benutzen ist eher eine Notlösung, wenn es kein Reading dafür gibt. Die sind ja eher für Frontends gedacht, bei denen der User nach dem Klicken (vermutlich) tatsächlich einen frisch aktualisierten Wert sehen möchte. Das ist u.a. ein Grund, warum ich die get-Aufrufe auch mit OWX_ASYNC weiterhin synchron ausführen lasse und nicht einfach nur das bestehende Reading zurückgebe.
Gruß,
Norbert
Also bei mir sieht es dann so aus
Error messages while initializing FHEM:
configfile: OWCOUNT: Wrong 1-Wire device model DS2423emu
Please define Gas_B1 first
Nach dem shutdown restart
attr Gas_B1 stateFormat { sprintf("%.1f m3 %.3f m3", ReadingsVal("Gas_B1","Gas","m3"), ReadingsVal("Gas_B1","G-Power","m3"));; }
geht dann auch nicht mehr.
Fhem log
2014.04.08 12:13:31 0: Server shutdown
2014.04.08 12:13:34 1: Including fhem.cfg
2014.04.08 12:13:34 3: WEB: port 8083 opened
2014.04.08 12:13:34 3: WEBS: port 8084 opened
2014.04.08 12:13:35 3: Opening CUL_1 device /dev/ttyACM0
2014.04.08 12:13:35 3: Setting CUL_1 baudrate to 9600
2014.04.08 12:13:35 3: CUL_1 device opened
2014.04.08 12:13:35 3: CUL_1: Possible commands: BCFiAZEGMRTVWXefmltux
2014.04.08 12:13:36 3: OWCOUNT: Device Gas_B1 defined.
2014.04.08 12:13:36 3: OWCOUNT: Device Strom_A1 defined.
2014.04.08 12:13:36 1: Including ./log/fhem.save
2014.04.08 12:13:36 3: OW: Opening connection to OWServer 127.0.0.1:4304...
2014.04.08 12:13:36 3: OW: Successfully connected to 127.0.0.1:4304.
2014.04.08 12:13:36 3: myOWFS: Opening connection to OWServer localhost:4304...
2014.04.08 12:13:37 3: myOWFS: Successfully connected to localhost:4304.
2014.04.08 12:13:39 0: Server started with 64 defined entities (version $Id: fhem.pl 5452 2014-04-06 06:24:47Z rudolfkoenig $, os linux, user fhem, pid 7177)
2014.04.08 12:13:46 3: OWX: Reset called with undefined interface
2014.04.08 12:13:46 3: OWX: Complex called with undefined interface
2014.04.08 12:13:46 1: OWCOUNT: model attribute of Gas_B1 set to DS2423emu because no memory found
2014.04.08 12:13:46 3: OWX: Reset called with undefined interface
2014.04.08 12:13:46 3: OWX: Complex called with undefined interface
2014.04.08 12:13:46 1: OWCOUNT: model attribute of Strom_A1 set to DS2423emu because no memory found
Gruß
Martin
Hallo Norbert,
bei mir so,
Version 5.14
Fhem log
2014.04.08 12:10:45 1: OWCOUNT_recall: Cannot open OWCOUNT_OWX_1D_A8FA0D000000_14.dat for reading!
2014.04.08 12:10:46 1: OWCOUNT_recall: Cannot open OWCOUNT_OWX_1D_A8FA0D000000_14.dat for reading!
2014.04.08 12:10:46 1: OWCOUNT_recall: Cannot open OWCOUNT_OWX_1D_A8FA0D000000_14.dat for reading!
2014.04.08 12:10:46 1: OWCOUNT_recall: Cannot open OWCOUNT_OWX_1D_A8FA0D000000_15.dat for reading!
Readings
5.09 = 2014-04-08_12:06:42 OWX_1D_AAF60D000000 Strom_G: 3.056 kWh Strom_G_rate: 3.8700 kW Strom_H: 0.239 kWh Strom_H_rate: 0.0240 kW
5.14 = 2014-04-08_12:10:48 OWX_1D_AAF60D000000 Strom_G: 2540.614 kWh Strom_G_rate: 37134.9878 kW Strom_H: 155.581 kWh Strom_H_rate: 2273.2902 kW
Wie schon geschrieben, es werden keine Midnight Werte mehr ausgelesen ,sind 0.
Version 5.09 ging noch richtig.
Gruß Bernd
Ich zitiere hier jetzt mal den Peter:
Zitat von: Prof. Dr. Peter Henning am 01 März 2014, 18:51:44
Übrigens: Ich finde es nervig, wenn Hilfesuchende immer nur bröckchenweise Informationen herausrücken. Mal ist es nur ein Screenshot, mal ein paar Zeilen aus dem Log oder dem Eventmonitor - Konfiguration aber bisher nicht. Und die Ergebnisse von so einfachen Kommandos wie dem oben genannten fehlen auch.
Ich bin ja froh, wenn Ihr testet, aber ich kann nicht hellsehen wenn ich abgesehen von der Versionsnummer des Moduls nichts über die konkret verwendete Hardware und Konfiguration weiß.
Gruß,
Norbert
Hallo Norbert,
dazu die
fhem.cfg
define OWX_1D_AAF60D000000 OWCOUNT DS2423 AAF60D000000 300
attr OWX_1D_AAF60D000000 AFactor 0.00125
attr OWX_1D_AAF60D000000 AMode daily
attr OWX_1D_AAF60D000000 AName Strom_G
attr OWX_1D_AAF60D000000 AOffset 15620
attr OWX_1D_AAF60D000000 APeriod hour
attr OWX_1D_AAF60D000000 AUnit kWh|kWh
attr OWX_1D_AAF60D000000 BFactor 0.0005
attr OWX_1D_AAF60D000000 BMode daily
attr OWX_1D_AAF60D000000 BName Strom_H
attr OWX_1D_AAF60D000000 BOffset 1600
attr OWX_1D_AAF60D000000 BPeriod hour
attr OWX_1D_AAF60D000000 BUnit kWh|kWh
attr OWX_1D_AAF60D000000 IODev TEMP
attr OWX_1D_AAF60D000000 LogM Strom_M
attr OWX_1D_AAF60D000000 LogY Strom_Y
attr OWX_1D_AAF60D000000 model DS2423
attr OWX_1D_AAF60D000000 nomemory 0
attr OWX_1D_AAF60D000000 room OWX
Arduino mit Firmata v2.05 über USB
Gruß Bernd
Zitat von: Martin am 08 April 2014, 12:21:18
configfile: OWCOUNT: Wrong 1-Wire device model DS2423emu
In der define-Zeile muss jetzt entweder DS2423, DS2423eneu oder DS2423eold stehen, DS2423emu gibt's nicht mehr (weil nicht eindeutig, es gibt mitlerweile mehr als eine Version des emulierten DS2423). stateFormat geht dann natürlich nicht - das Modul wurde ja nicht geladen.
Zitat von: Martin am 08 April 2014, 12:21:18
2014.04.08 12:13:46 1: OWCOUNT: model attribute of Strom_A1 set to DS2423emu because no memory found
Die logausgabe kommt von welcher Version? 5.14 kann es nicht sein, da würde stehen 'set to DS2423
eold because no memory found'
Zitat von: Bastelbernd am 08 April 2014, 16:13:15
Hallo Norbert,
dazu die
fhem.cfg
danke...
Bin das im code grade noch mal durchgegangen. Mir ist nicht so recht klar, ob Pah das tatsächlich so beabsichtigt hat, dass die OWCOUNT_OWX_1D_A8FA0D000000_14/15.dat auch bei einem echten DS2423 versucht wird zu lesen (beim echten DS2423 kommt der Midnight-wert ja aus dem internen Speicher, die Datei-lösung ist ja nur ein Workaround für die emulierten Counter, die keinen internen Speicher haben).
Ohne die Datei gab's in der 5.11 jedenfalls Fehler mit unititialized Values und regex..., in der 5.14 wird der midnight-wert auf Null gesetzt, wenn die Datei nicht gelesen werden kann. (in der 5.09 gabs noch gar keine Datei...) Werde mir dazu mal was sinnvolles ausdenken... nachher gibt's wieder ein update.
Gruß,
Norbert
Natürlich habe ich das nicht beabsichtigt. Kommt bei mir aber auch nicht vor - irgendetwas läuft da durcheinander.
Ich habe abe rim moment weder die Möglichkeit zum Testen, noch Zeit zum Programmieren.
LG aus Tel Aviv
pah
Hallo und danke das mit DS2423eold hat geklappt aber wo hätte ich das lesen können ??
damit ich das zukünftig gleich ändern kann wenn sich so was ändert.
Gruß
Martin
Zitat von: Prof. Dr. Peter Henning am 08 April 2014, 21:29:23
Natürlich habe ich das nicht beabsichtigt. Kommt bei mir aber auch nicht vor
In Deiner Version vom 27.03. wird OWCOUNT_recall (https://github.com/ntruchsess/fhem-mirror/blob/2ae63e776925b5a052e377e64d0c1e374b31554e/fhem/FHEM/21_OWCOUNT.pm#L812) innerhalb von OWCOUNT_GetPage immer aufgerufen, wenn page 14 oder 15 abgerufen wird, unabhängig vom model des Counters. Bis auf dauernde Logmeldungen, dass die Datein fehlen (wenn man einen echten DS2423 benutzt) und Fehlern wg. unititialized values ($strval) in den nachfolgenden Regexps macht das in dieser Version wohl auch nichts. Der Effekt, dass es damit den midnight-val dabei löscht, war eine Folge, dass ich die Fehlermeldungen beseitigt, die Aufruflogik unter der Annahme, dass diese so beabsichtig ist, aber unverändert gelassen hatte.
hier gibt's die 21_OWCOUNT.pm, Version 5.15 (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm) zum testen.
Änderungen gegenüber 5.14:
- Problem mit Überschreiben der Midnight-werte beim echten DS2423 behoben.
- Support für File-basierte Midnight-werte bei nomem=1 und OWServer.
- keine unnötigen 'Datei fehlt' und Folgefehler beim Parsen der nicht gelesenen Datei mehr.
Bekannte Fehler:
- beim Inititialisieren beschreibt OWCOUNT testweise das memory eines echten DS2423. Wenn in diesem Zusammenhang ein Fehler (z.B. CRC wg. instablilem Bus) auftritt, können die Midnight-werte korrumpiert werden. Ich überlege, ob man das Testen des DS2423-models überspringen (oder optional machen) sollte, wenn das Model schon vom letzten Lauf her bekannt ist.
Gruß,
Norbert
Zitat von: Martin am 08 April 2014, 22:43:16
Hallo und danke das mit DS2423eold hat geklappt aber wo hätte ich das lesen können ??
In der commandref (http://fhem.de/commandref.html#OWCOUNT), die Fehlermeldung war in dem Fall ja recht zielweisend.
oder irgendwo weiter vorne hier im Thread.
... oder wie immer in der besonders ausführlichen, in perl geschriebenen Dokumentation (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/21_OWCOUNT.pm#L227).
Gruß,
Norbert
Hallo Norbert,
ich bin erst jetzt dazu gekommen 21_OWCOUNT.pm, Version 5.15 zu testen.
Bei mir wird jetzt nur noch ein einziges Mal in das Logfile der Counter geschrieben, und zwar beim Start von FHEM, dann nie wieder.
Muss ich irgend etwas in der fhem.cfg anpassen?
Was mir aufgefallen ist:
Ich habe versucht fhem von der Commandline aus zu killen und wieder zu starten, dabei habe ich folgende Meldungen bekommen:
DiskStation> /usr/local/perl/bin/perl /usr/local/FHEM/bin/fhem.pl /usr/local/FHEM/etc/fhem.cfg
DiskStation> Can't exec "lsusb": No such file or directory at /usr/local/FHEM/share/fhem/FHEM/98_autocreate.pm line 366.
Use of uninitialized value $strval in pattern match (m//) at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1511.
Use of uninitialized value $strval in substitution (s///) at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1516.
Use of uninitialized value $value_length in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $val in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $size in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 359.
Use of uninitialized value $ret in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 281.
Use of uninitialized value $strval in pattern match (m//) at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1511.
Use of uninitialized value $strval in substitution (s///) at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1516.
Use of uninitialized value $value_length in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $val in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $size in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 359.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1133.
Use of uninitialized value $ret in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 281.
Use of uninitialized value $ret in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/local/FHEM/share/fhem/FHEM/10_OWServer.pm line 281.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Ist es überhaupt möglich FHEM so von der Commandline zu starten?
Grüße
Rainer
Hallo Norbert,
bei mr läuft die Version 5.15 bisher sehr gut. :D
Gruß Bernd
@ntruchsess: Maybe, danke für den Fix dann.
Ich bin noch ein paar Tage lahmgelegt.
LG aus Tel Aviv
pah
Zitat von: ergerd am 09 April 2014, 19:56:58
ich bin erst jetzt dazu gekommen 21_OWCOUNT.pm, Version 5.15 zu testen.
Bei mir wird jetzt nur noch ein einziges Mal in das Logfile der Counter geschrieben, und zwar beim Start von FHEM, dann nie wieder.
Muss ich irgend etwas in der fhem.cfg anpassen?
Hallo Rainer,
in der fhem.cfg müsste nichts geändert werden. Ich konnte den Fix mit OWServer aber gestern mangels funktionierendem Busmaster nicht testen, da scheint irgendwas noch nicht zu passen. Heute ist der DS2480 von Tobias gekommen, damit kriege ich das schon hin.
Von der Kommandozeile starten geht schon. Bei Dir scheint nur 'lsusb' nicht im Suchpfad zu sein. (Du kannst aber autocrate in der fhem.cfg auch einfach ausschalten, das braucht man bei einem fertig aufgesetztem fhem-system ja nicht mehr, das verlängert nur die Startup-zeit).
Gruß,
Norbert
Zitat von: Bastelbernd am 09 April 2014, 20:46:51
bei mr läuft die Version 5.15 bisher sehr gut. :D
Schick, dann ist der OWX-part von OWCOUNT für echte DS2423 jetzt wohl in trockenen Tüchern ;-)
Dann schau ich mir den OWServer-part jetzt noch mal genauer an.
Gruß,
Norbert
Zitat von: ergerd am 09 April 2014, 19:56:58
ich bin erst jetzt dazu gekommen 21_OWCOUNT.pm, Version 5.15 zu testen.
Bei mir wird jetzt nur noch ein einziges Mal in das Logfile der Counter geschrieben, und zwar beim Start von FHEM, dann nie wieder.
mein Fix für filebasierte mignight-values für OWServer + emulierte DS2423 war nicht ganz vollständig, da gab's noch einen parse-fehler, wenn (mangels internem memory des emulierten DS2423) beim SetPage keine Werte da waren.
das ist in 21_OWCOUNT.pm Version 5.16 (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_nothread/fhem/FHEM/21_OWCOUNT.pm) behoben.
Was aber noch Probleme macht: die automatische Erkennung des DS2423-models (mit oder ohne internen Speicher) erkennt den Chip zwar korrekt, korrumpiert aber vorher vorhandene Midnight-values bei echten DS2423 plus OWServer :-(
Mit emulierten DS2423 geht's, die files werden jetzt sauber geschrieben und gelesen.
Was mir noch nicht so gefällt: die midnight-files werden in das FHEM-verzeichnis (zu den Modulen) geschrieben. Das Verzeichnis ist auf manchen Installationen readonly. Ablage im log-verzeichnis (oder konfigurierbar) ware sinnvoller.
Happy testing ;-)
Gruß,
Norbert
Hallo Norbert,
ich habe 21_OWCOUNT.pm installiert, aber es hat sich nichts geändert. Wenn ich FHEM auf der Synology neu starte wird ein Eintrag in dem Logfile eines Counters erzeugt, dann nichts mehr. Auch habe ich ja Logfiles für 2 Counter (myOWFS_C1 und myOWFS_C2) definiert, es wird aber nur in myOWFS_C2 der eine Eintrag geschrieben.
Grüße
Rainer
hm... schade. Nachdem gestern der neue DS2480 von Damian pünktlich angekommen ist, hab extra dafür den Pi wieder ausgegraben und OWserver drauf installiert. Ging (bis auf den behobenen Fehler beim Parsen der midnight-werte) eigentlich auf Anhieb.
Dein OWCOUNT bleibt vermutlich beim initialen Test des DS2423-typs hängen. Hab grade gesehen in Deiner config ist das Attribut nonblocking beim OWServer gesetzt, das hatte ich bei meinen Tests nicht drin. Versuchs mal ohne. Ich hab heute abend vorraussichtlich selber keine Zeit was zu machen, ich komme erst spät nach Hause.
Gruß,
Norbert
Hallo also bei mir wird mit deiner neuen Version nichts mehr geloggt
Gruß
Martin
Hallo Martin,
ich würde Dir wirklich gerne helfen, aber in dem Fall kann ich mal wieder nur auf den Beitrag von Pah (http://forum.fhem.de/index.php/topic,18662.msg144113.html#msg144113) verweisen.
OWCount kann mittlerweile in so vielen möglichen Kombinationen aus Busmaster, DS2423-model, IODev plus über die attribute beeinflussbare Verhaltensweisen betrieben werden, die kann ich gar nicht alle testen und erst recht nicht wissen, welche davon jetzt bei Dir (nicht) läuft.
ins Blaue geraten:
OWServer, attribute 'nonblocking' (http://fhem.de/commandref.html#OWServer): Note: unset nonblocking if you experience lockups of FHEM.
Gruß,
Norbert
Zitat von: ntruchsess am 09 April 2014, 23:39:35
Was aber noch Probleme macht: die automatische Erkennung des DS2423-models (mit oder ohne internen Speicher) erkennt den Chip zwar korrekt, korrumpiert aber vorher vorhandene Midnight-values bei echten DS2423 plus OWServer
Fehler gefunden und behoben (https://github.com/ntruchsess/fhem-mirror/commit/513367a3cad381c24d3af100b85c8c0e3b430ca4#diff-2e622807a7bce491ceba2f39f3a472a6L1123).
Der OWServer-relevante Pfad im InitializeDevice hatte Aufrufe für OWX drin :-(
Damit sind diese Fehler bei Verwendung von OWCOUNT mit OWServer auch Vergangenheit:
2014.04.11 10:02:32 3: OWX: Reset called with undefined interface
2014.04.11 10:02:32 3: OWX: Complex called with undefined interface
Version ist jetzt 5.17, da mir jetzt kein für mich nachvollziehbarer Bug mehr bekannt ist, ist die Version diesmal ins Fhem-SVN commitet und damit per update verfügbar.
Gruß,
Norbert
Hallo Norbert,
bei mir geht nach wie vor nichts.
Grüße
Rainer
Hallo Rainer,
ich brauche da schon etwas mehr Infos, wie gesagt - bei mir geht OWCOUNT mit OWServer problemlos. Wobei mein owserver-prozess mit einem DS2480 als Busmaster auf einem Pi läuft und vieleicht auch anders als bei Dir konfiguriert ist?
Hast Du das Attribut 'nonblocking' am OWServer entfernt bzw. auf 0 gesetzt?
kannst Du Deine owfs-konfiguration anhängen?
Bleibt fhem komplett stehen (kann man die Weboberfläche noch aufrufen)?
Könntest Du fhem manuel von der Konsole starten (und die Konsole offen lassen), damit Du auch perl-fehlermeldungen die nicht ins Logfile geschrieben werden, sehen kannst?
(gleiches gilt auch für Dich Martin, falls Du möchtest, dass ich Dir dabei helfe).
Gruß,
Norbert
Hallo Norbert,
nonblocking ist auskommentiert. Ich bin nicht sicher was du mit owfs-konfiguration meinst, das was in der fhem.cfg steht? Das habe ich in diesem Thread schon hochgeladen, es hat sich nur nonblocking geändert.
Hier die Ausgabe von der Konsole:
DiskStation> Can't exec "lsusb": No such file or directory at /usr/local/FHEM/share/fhem/FHEM/98_autocreate.pm line 366.
Use of uninitialized value $value_length in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $val in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $size in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 359.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1133.
DiskStation> Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/00_OWX.pm line 726.
Ich hoffe es hilft dir.
Grüße
Rainer
Hallo Norbert,
noch ein Hinweis:
Seit einiger Zeit sind folgende Einträge in meiner fhem.cfg, die ich nicht eingefügt habe (autocreate enabled):
define DS2423_404C0F000000 OWDevice 1D.404C0F000000 60
attr DS2423_404C0F000000 IODev myOWFS
attr DS2423_404C0F000000 model DS2423
attr DS2423_404C0F000000 room hidden
myOWFS_C1:
define DS2423_2BD20D000000 OWDevice 1D.2BD20D000000 60
attr DS2423_2BD20D000000 IODev myOWFS
attr DS2423_2BD20D000000 model DS2423
attr DS2423_2BD20D000000 room hidden
Warum sind die da? Ich habe sie doch schon definiert:
define myOWFS_C1 OWCOUNT DS2423 2BD20D000000 300
attr myOWFS_C1 AFactor 0.001
attr myOWFS_C1 AMode daily
attr myOWFS_C1 AName Stromverbrauch1|energy
attr myOWFS_C1 APeriod hour
attr myOWFS_C1 ARate Leistung1|power
attr myOWFS_C1 AUnit kWh|kWh
attr myOWFS_C1 BFactor 0.001
attr myOWFS_C1 BMode daily
attr myOWFS_C1 BName Stromverbrauch2|energy
attr myOWFS_C1 BPeriod hour
attr myOWFS_C1 BRate Leistung2|power
attr myOWFS_C1 BUnit kWh|kWh
attr myOWFS_C1 IODev myOWFS
attr myOWFS_C1 LogM FileLog_myOWFS_C_M
attr myOWFS_C1 fp_Erdgeschoss 820,200,0,
attr myOWFS_C1 model DS2423
attr myOWFS_C1 room hidden
define myOWFS_C2 OWCOUNT DS2423 404C0F000000 300
attr myOWFS_C2 AFactor 0.001
attr myOWFS_C2 AMode daily
attr myOWFS_C2 AName Stromverbrauch3|energy
attr myOWFS_C2 APeriod hour
attr myOWFS_C2 ARate Leistung3|power
attr myOWFS_C2 AUnit kWh|kWh
attr myOWFS_C2 BFactor 0.001
attr myOWFS_C2 BMode daily
attr myOWFS_C2 BName Stromverbrauch4|energy
attr myOWFS_C2 BPeriod hour
attr myOWFS_C2 BRate Leistung4|power
attr myOWFS_C2 BUnit kWh|kWh
attr myOWFS_C2 IODev myOWFS
attr myOWFS_C2 LogM FileLog_myOWFS_C_M
attr myOWFS_C2 fp_Erdgeschoss 830,200,0,
attr myOWFS_C2 model DS2423
attr myOWFS_C2 room hidden
Grüße
Rainer
Zitat von: ergerd am 11 April 2014, 22:26:33
Ich bin nicht sicher was du mit owfs-konfiguration meinst
Ich meine die owfs.conf (http://owfs.org/uploads/owfs.conf.html). Das fhem-modul OWServer setzt auf owfs auf. D.h. wenn OWCOUNT bei mir mit owfs funktioniert, und bei Dir nicht, dann liegt da vermutlich irgendwo der Hund begraben.
Zitat von: ergerd am 11 April 2014, 22:26:33
Use of uninitialized value $value_length in concatenation (.) or string at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $val in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 558.
Use of uninitialized value $size in pack at /usr/local/FHEM/share/fhem/FHEM/lib/OWNet.pm line 359.
Use of uninitialized value in substr at /usr/local/FHEM/share/fhem/FHEM/21_OWCOUNT.pm line 1133.
...
Den Fehler habe ich auch schon gesehen, der kommt, wenn im OWCOUNT_InitializeDevice beim Testen des DS2423-typs ein Fehler passiert ist und dann versucht wird einen undefinierten Wert zurückzuschreiben. Also Symptom und nicht Ursache.
Zitat von: ergerd am 11 April 2014, 23:11:53
Seit einiger Zeit sind folgende Einträge in meiner fhem.cfg, die ich nicht eingefügt habe (autocreate enabled):
define DS2423_404C0F000000 OWDevice 1D.404C0F000000 60
...
Warum sind die da? Ich habe sie doch schon definiert:
define myOWFS_C1 OWCOUNT DS2423 2BD20D000000 300
Die werden vom OWServer angelegt, wenn autocreate enabled ist. OWServer + OWDevice kommen von Boris Neubert und Martin Fischer, OWCOUNT + OWX von Peter Henning. P. Henning hat in seine Module Unterstützung für das OWServer backend eingebaut, allerdings wird das von B.Neubert und M.Fischer nicht aktiv unterstützt. U.a. ignoriert OWServer beim Autocreate existierende OWX-moduleinträge. Also entweder autocreate ausstellen oder OWX als Backend für OWCOUNT benutzen (oder OWDevice nehmen, je nachdem, was besser für Deine Zwecke passt).
Gruß,
Norbert
Hallo Norbert,
der Groschen ist gefallen. An die owfs.conf habe ich mich nicht erinnert, aber die muss ich wohl eingerichtet haben, ist allerdings auch schon über 1 Jahr her :-)
Hier der Inhalt:
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.
# setup owserver's port
server: port = 4304
# all programs BUT not owserver see this line
!server: server = 192.168.48.228:4304
# setup owserver's device
# only owserver connects to the USB device
#server: device = /dev/ttyS0
server: usb = all
# setup owhttpd's port
http: port = 3001
# random simulated device
#server: FAKE = DS2406,DS2413
# fuseow
mountpoint = /mnt/1wire
allow_other
Grüße
Rainer
danke für die Info, hab das grade mal mit meiner owfs.conf verglichen, sieht im Prinzip völlig equivalent aus.
Bin leider nicht der Experte, was owfs angeht - das Verhalten kann natürlich von der owfs-version abhängen, die wird für Dein Synology-NAS vermutlich nicht die gleiche sein, wie auf meinem Pi.
Was mir aber sinnvoll erscheint, wäre die automatische Deviceerkennung im OWCOUNT so zu ändern, dass sie nur stattfindet, wenn das DS2423-model noch nicht bekannt (und per Attribut) gesetzt ist. Damit könnte man bei Installationen, die hier hängenbleiben das model-attribut manuell setzen. Das muss ich aber noch genauer durchdenken, wie das wirklich sinnvoll und benutzerfreundlich zu machen wäre, weil die Erkennung ja beim AutoCreate der OWX-devices ja trotzdem erst mal laufen sollte (und da prinzipiell zu den gleichen Hängern führen könnte). Schon ein bischen blöd, dass ich das bei mir nicht reproduzieren kann.
Gruß,
Norbert
Hallo heute ein Update gemacht und mit der neuen Version Owcount sieht mein logg so aus.
2014-04-15_18:41:57 Strom_A1 E-Energy: 12.455 kWh E-Power: 0.0000 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-15_18:49:57 Strom_A1 E-Energy: 12.4551
2014-04-15_18:49:57 Strom_A1 E-Energy: 12.455 kWh E-Power: 0.0000 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-15_18:57:57 Strom_A1 E-Energy: 12.4551
2014-04-15_18:57:57 Strom_A1 E-Energy: 12.455 kWh E-Power: 0.0000 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-15_19:05:57 Strom_A1 E-Energy: 12.4551
2014-04-15_19:05:57 Strom_A1 E-Energy: 12.455 kWh E-Power: 0.0000 kW B: 0.0 cts B_rate: 0.00 cts/h
Meine Config
define Strom_A1 OWCOUNT DS2423eold A2D987000002 480
attr Strom_A1 AFactor 0.00266
attr Strom_A1 AMode daily
attr Strom_A1 AName E-Energy|energy
attr Strom_A1 ARate E-Power|power
attr Strom_A1 AUnit kWh|kWh
attr Strom_A1 IODev OW
attr Strom_A1 LogM StromM
attr Strom_A1 LogY StromY
attr Strom_A1 fp_Grundriss 150,700,1,Stromverbrauch
attr Strom_A1 model DS2423eold
attr Strom_A1 nomemory 1
attr Strom_A1 room Strom/Gas
attr Strom_A1 stateFormat { sprintf("%.1f kWh %.3f kWh", ReadingsVal("Strom_A1","E-Energy","kwh"), ReadingsVal("Strom_A1","E-Power","kwh"));; }
#attr Strom_A1 event-on-update-reading E-Energy,E-Power,day,month
#attr Strom_A1 APeriod hour
define FileLog_Strom_A1 FileLog ./log/Strom/Strom-%m-%Y.log Strom_A1.*E-Energy.*
attr FileLog_Strom_A1 room Logsb
define StromM FileLog ./log/Strom-Monat/StromM-%m-%Y.log Strom_A1:day.*
attr StromM archivedir ./log
attr StromM nrarchive 3
attr StromM room Logsb
define StromY FileLog ./log/Strom-Jahr/StromY-%m-%Y.log Strom_A1:month.*
attr StromY room Logsb
define weblink_Strom_A1 SVG FileLog_Strom_A1:count:CURRENT
attr weblink_Strom_A1 room Strom/Gas
Gruß
Martin
Willst Du uns mit Deinem kommentarlos geposteten Log-auszug mitteilen, dass es bei Dir jetzt geht?
Hab Deine Config mit einem DS2423eold (Dougie-counter) probiert, funzt einwandfrei. Sowohl OWX, als auch OWX_ASYNC, beide male mit einem DS2480 Busmaster.
Gruß,
Norbert
Hallo nein geht eben nicht wie man am logg sehen kann schreibt er immer E-Power: 0.0000 kw
Wenn es gehen würde dann sieht es so aus.
2014-04-16_11:41:30 Strom_A1 E-Energy: 7.9469
2014-04-16_11:41:30 Strom_A1 E-Energy: 7.947 kWh E-Power: 0.6383 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-16_11:49:30 Strom_A1 E-Energy: 8.0347
2014-04-16_11:49:30 Strom_A1 E-Energy: 8.035 kWh E-Power: 0.6585 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-16_11:57:30 Strom_A1 E-Energy: 8.1145
2014-04-16_11:57:30 Strom_A1 E-Energy: 8.114 kWh E-Power: 0.5985 kW B: 0.0 cts B_rate: 0.00 cts/h
2014-04-16_12:05:30 Strom_A1 E-Energy: 8.1943
2014-04-16_12:05:30 Strom_A1 E-Energy: 8.194 kWh E-Power: 0.5985 kW B: 0.0 cts B_rate: 0.00 cts/h
Das ist mit der alten Version von Owcount.
Meine Frage was Läuft da schief ???
Gruß
Martin
Zitat von: Prof. Dr. Peter Henning am 14 April 2014, 21:30:46
@Norbert: Bitte im Moment mal keine neuen Commits für OWCOUNT - habe da ein paar Dinge aufgeräumt und muss erst testen. Außerdem noch einen Fehler in Zeile 762 behoben.
Hallo Peter,
wie schaut's denn mit Deiner Anpassungen im OWCOUNT von letzter Woche aus? Ich habe den asynchronen code aller anderen Devices auf Protothreads umgestellt. Das garantiert die individuelle Nichtunterbrechbarkeit einer Abfolge von 1-Wire Kommandos pro Device und vereinfacht den asynchronen code deutlich. Ich möchte natürlich Konflikte mit Deinen Änderungen schon im Vorfeld möglichst vermeiden...
Gruß,
Norbert
Betraf nur das Aufräumen im Code - und der "vermeintliche" fehler in Zeile 762.. Schicke ich per Mail, denn ich komme für den Rest der Woche kaum noch dazu, daran etwas zu machen.
LG
pah
Danke, dann arbeite ich das ein, wenn ich es habe. Meine noch 'ungeputzte', aber auf ProtoThreads umgestellte Version ist im OWX asynchron überarbeitet (http://forum.fhem.de/index.php/topic,13580.msg161431.html#msg161431)-Thread verlinkt.
Gruß,
Norbert
Hallo
da das mit den Y-Logs zum Monatswechsel immer noch nicht richtig geklappt hat, habe ich das mal bei mir so geändert,
alt
#-- put in monthly and yearly sums
$dvalue = sprintf("D%02d ",$day).$dvalue;
$dvalue = sprintf($dvalue,$total0,$total1);
readingsBulkUpdate($hash,"day",$dvalue);
if ( $monthbreak == 1){
$mvalue = sprintf("M%02d ",$month+1).$mvalue;
$mvalue = sprintf($mvalue,$total2,$total3);
readingsBulkUpdate($hash,"month",$mvalue);
}
neu
#-- put in monthly and yearly sums
$dvalue = sprintf("D%02d ",$day).$dvalue;
$dvalue = sprintf($dvalue,$total0,$total1);
readingsBulkUpdate($hash,"day",$dvalue);
if ( $monthbreak == 1){
$mvalue = sprintf("M%02d ",$month+1).$mvalue;
$mvalue = sprintf($mvalue,$total0,$total2,$total1,$total3);
readingsBulkUpdate($hash,"month",$mvalue);
}
nun klappt das auch mit den Y-Logs zum Monatswechsel richtig.
2014-05-31_23:58:43 OWX_1D_AAF60D000000 month: M05 Strom_GM: 246.4 kWh Strom_GY: 1305.5 kWh Strom_HM: 13.5 kWh Strom_HY: 89.3 kWh
ich glaube hier ist auch noch ein kleiner Fehler
if( $daily==1){
for (my $j=0;$j<int(@year);$j++){
$total += $year[$j][$i];
}
}else{
$total = $year[int(@year)-1][$i]
if (int(@year)>0);
};
da bei daily=0 die Monatswerte immer dazugezählt werden. Habe das beim mir mal so geändert.
if( $daily==1){
for (my $j=0;$j<int(@year);$j++){
$total += $year[$j][$i];
}
}else{
$total = $year[int(@year)-1][$i]
if (int(@year)==0);
};
vielleicht kann sich das jemand von den Profis mal ansehen und gegebenfalls ändern.
Gruß Bernd
Nach Update geht mein Owcount nicht mehr hat sich was geändert ??
meine Config
define Strom_A1 OWCOUNT DS2423eold A2D987000002 480
attr Strom_A1 AFactor 0.00266
attr Strom_A1 AMode daily
attr Strom_A1 AName E-Energy|energy
attr Strom_A1 ARate E-Power|power
attr Strom_A1 AUnit kWh|kWh
attr Strom_A1 IODev OW
attr Strom_A1 LogM StromM
attr Strom_A1 LogY StromY
attr Strom_A1 fp_Grundriss 150,730,1,Stromverbrauch
attr Strom_A1 model DS2423eold
attr Strom_A1 nomemory 1
attr Strom_A1 room Strom/Gas
Gruß
Martin
Zitat von: Martin am 11 Juli 2014, 17:39:12
Nach Update geht mein Owcount nicht mehr hat sich was geändert ??
Kommt darauf an, von welcher Version du upgradest: Die letzte relevante Änderung am OWCOUNT war am 13.05.2014, der letzte potentiell für OWCOUNT relevante commit am OWX am 30.03.2014, beim OWX_ASYNC am 14.06.2014.
Fehlermeldung, verwendeten Busmaster, OWX, OWSERVER oder OWX_ASYNC usw... dürfen wir jetzt vermutlich raten.
Gruß,
Norbert
Ok beim Letzten mal musste ich nur ein Old dahinter hängen im Log steht
2014.07.12 12:32:26 1: OWCOUNT: model attribute of Gas_B1 set to DS2423eold because no memory found
2014.07.12 12:32:27 1: OWCOUNT: model attribute of Strom_A1 set to DS2423eold because no memory found
Gruß
Martin
das ist keine Fehlermeldung. Die Meldung dient zur Information, dass OWCOUNT beim Initialisieren die DS2423 als emulierte Version (dougie-counter (http://forum.fhem.de/index.php/topic,10962.0.html)) ohne beschreibbaren Speicher identifiziert hat.
Gruß,
Norbert
Ok danke habe jetzt mein 21_OWCOUNT.pm aus dem Backup rauskopiert
Und jetzt geht wieder alles lag also am neuen Owcount meins ist glaube ich vom April
Gruß
Martin
Hallo Norbert,
der dougie-counter läuft bei mir mit OWX_ASYNC ansich wunderbar. Allerdings nur, wenn noch ein weiterer
1w Sensor am Bus hängt (z.B. ein DS18S20). Hängt er allein am Bus wir er nicht erkannt
2016.04.01 00:12:21 5: OWX_ASYNC_Schedule master: OWHAR, task: OWHAR
2016.04.01 00:12:21 2: OWX: 1-Wire devices found on bus OWHAR ()
2016.04.01 00:12:21 4: OWX_ASYNC_RunTasks: OWHAR task exited: OWX: 1-Wire devices found on bus OWHAR
Hängt der DS18S20 mit am Bus, dann klappt es sofort wieder:
2016.04.01 00:13:32 5: OWX_ASYNC_Schedule master: OWHAR, task: OWHAR
2016.04.01 00:13:32 2: OWX: 1-Wire devices found on bus OWHAR (Thermometer_HAR2,gaszaehler)
2016.04.01 00:13:32 4: OWX_ASYNC_RunTasks: OWHAR task exited: OWX: 1-Wire devices found on bus OWHAR
10.20A48C020800 DS18S20/DS1920 Thermometer_HAR2
1D.A2D984000002 DS2423 gaszaehler
Hättest Du eine Idee ?
Danke & Gruß, Marc
Das ist ein Uralt-Thread aus dem Jahr 2014 !
Bitte hier posten. https://forum.fhem.de/index.php/topic,51642.0.html
pah