Moin Kinnaz,
ich schreibe das mal hier, weil ich nicht genau weiß, wo es besser passen würde...
Ich hatte zu dem Thema im Zusammenhang schon mit Klaus W. (52_I2C_MCP342x.pm) Kontakt bezgl. einer anderen Sache damit...
Untenstehend mal das Listing...
Die Readings des Devices (ChannelX) bleiben so wie sie sind, da keine Hardware an den Eingängen angeschlossen (lediglich mit C's geblockt), Ebenso bleiben die Offset- korrigierten UserReadings alle brav bei "0"...
Aber: In den per "stateFormat ||| CH1 ||| CH2 ||| CH3 ||| CH4 |||" zusammengefassten Werten aus den UserReadings tauchen sporadisch auf beliebigen Kanälen Werte auf, die mit den Device- resp. UserReadings nichts zu tun haben.
Die meiste Zeit steht da ebenfalls vier mal eine "0". Dann aber, ohne erkennbaren Zusammenhang, taucht mal bei diesem, mal bei jedem Kanal ein Wert auf in der Form ...
||| -1.95400000000001 ||| 0 ||| 0 ||| 1.95400000000001 |||
Oft ist es genau dieser Wert "1.95400000000001", manchmal aber auch ein anderer Wert, immer aber dezimal zwischen -2 und +2.
Ich hatte jetzt auch schon die optischen Trennzeichen weggelassen oder andere Zeichen hergenommen, aber das ändert an dem Verhalten nichts.
Jemand eine glorreiche Idee, woher das kommt? Auf dem System läuft nur der AD und 1W, nichts weiter; keine DoIf's oder ähnliches... Vollkommen jungfräuliches System... (Hinweis: Pollintervall ist 30 Sekunden und nicht 30 Minuten auf Grund modifizierter pm)
Internals:
CHANGED
DEF 0x69 4
FUUID 5c97e9e8-f33f-5bb0-be14-6b415fe4ff1caaa3
I2C1_SENDSTAT Ok
I2C_Address 105
IODev I2C1
NAME AD.02
NR 15
STATE ||| -1.95400000000001 ||| 0 ||| 0 ||| 0 |||
TYPE I2C_MCP342x
channels 4
.attraggr:
.attreocr:
Channel1
Channel2
Channel3
Channel4
.attrminint:
.userReadings:
HASH(0xe4aa08)
HASH(0xeeff60)
HASH(0xeee908)
HASH(0xeefb88)
READINGS:
2019-03-31 15:24:26 CH1 -1.95400000000001
2019-03-31 15:24:26 CH2 0
2019-03-31 15:24:26 CH3 0
2019-03-31 15:24:26 CH4 0
2019-03-31 15:24:24 Channel1 -72.266
2019-03-31 15:24:25 Channel2 -70.312
2019-03-31 15:24:25 Channel3 -76.172
2019-03-31 15:24:26 Channel4 -72.266
2019-03-31 15:24:26 state Ok
Attributes:
IODev I2C1
ch1factor 1000000
ch1gain 8
ch1resolution 18
ch1roundDecimal 3
ch2factor 1000000
ch2gain 8
ch2resolution 18
ch2roundDecimal 3
ch3factor 1000000
ch3gain 8
ch3resolution 18
ch3roundDecimal 3
ch4factor 1000000
ch4gain 8
ch4resolution 18
ch4roundDecimal 3
event-on-change-reading Channel1,Channel2,Channel3,Channel4
poll_interval 30
room Sensoren
stateFormat ||| CH1 ||| CH2 ||| CH3 ||| CH4 |||
userReadings CH1 { ReadingsVal("AD.02", "Channel1", "0") + 70.312 }, CH2 { ReadingsVal("AD.02", "Channel2", "0") + 70.312 },
CH3 { ReadingsVal("AD.02", "Channel3", "0") + 76.172 }, CH4 { ReadingsVal("AD.02", "Channel4", "0") + 72.266 }
Zitat von: M_I_B am 31 März 2019, 15:25:38
Ebenso bleiben die Offset- korrigierten UserReadings alle brav bei "0"...
READINGS:
2019-03-31 15:24:26 CH1 -1.95400000000001
sieht so eine brave 0 aus ?
... ok, der ist jetzt neu und mir gerade gar nicht aufgefallen ...
Ich hatte ein Bildschirm- Video mitgeschnitten und da war es in allen Fällen so, das zumindest dort die UserReadings nicht betroffen waren...
Ok, also definiere ich das mal um: Manchmal sind die UserReadings betroffen, manchmal nicht.
glaube ich nicht.
da du eh schon event-on-change-reading für die Channels 1-4 drin hast würde ich mal die vier Readings in einem Filelog mitschreiben.
Nach deiner Therorie müsste das dann ja leer bleiben
... gute Idee. Schmeiße ich gleich mal an und lasse es während meiner Abwesenheit laufen; muss gleich ein paar Stunden weg ...
ich wette das Log wird sich füllen , schau dir nochmal an was du gepostet hast :
Channel1 -72.266
der ist da ungleich Channel 2
Zitatder ist da ungleich Channel 2
... warum sollten die unbeding gleich sein? Das ist doch Bauteiltolleranzen und der hohen Verstärkung geschuldet. Das die teilweise auch um ein paar Hundertstel jittern, ist auch normal ...
Aber zum Thema:
Im Logfile sind keine Auffälligkeiten zu entdecken. Diese merkwürdigen Brüche im Nano- Bereich müssen daher m.E. irgendwo aus der Berechnung der UserReadings entstehen...
Edit: Habe noch mal ein Export nach Kanal sortiert als Bild angefügt
2019-03-31_16:00:38 AD.02 Channel4: -70.312
2019-03-31_16:01:41 AD.02 Channel4: -72.266
2019-03-31_16:04:50 AD.02 Channel1: -72.266
2019-03-31_16:05:22 AD.02 Channel1: -70.312
2019-03-31_16:08:00 AD.02 Channel1: -72.266
2019-03-31_16:08:01 AD.02 Channel4: -70.312
2019-03-31_16:08:32 AD.02 Channel1: -70.312
2019-03-31_16:09:36 AD.02 Channel4: -72.266
2019-03-31_16:10:38 AD.02 Channel1: -72.266
2019-03-31_16:11:10 AD.02 Channel1: -70.312
2019-03-31_16:11:42 AD.02 Channel2: -68.359
2019-03-31_16:11:43 AD.02 Channel4: -70.312
2019-03-31_16:12:14 AD.02 Channel2: -70.312
2019-03-31_16:12:46 AD.02 Channel4: -72.266
2019-03-31_16:13:49 AD.02 Channel4: -70.312
2019-03-31_16:14:21 AD.02 Channel4: -72.266
2019-03-31_16:16:27 AD.02 Channel4: -70.312
2019-03-31_16:16:59 AD.02 Channel4: -72.266
2019-03-31_16:24:21 AD.02 Channel1: -72.266
2019-03-31_16:24:52 AD.02 Channel1: -70.312
2019-03-31_16:28:34 AD.02 Channel1: -72.266
2019-03-31_16:29:06 AD.02 Channel1: -70.312
2019-03-31_16:30:41 AD.02 Channel1: -72.266
2019-03-31_16:31:12 AD.02 Channel1: -70.312
2019-03-31_16:31:44 AD.02 Channel1: -72.266
2019-03-31_16:31:45 AD.02 Channel4: -70.312
2019-03-31_16:32:15 AD.02 Channel1: -70.312
2019-03-31_16:32:17 AD.02 Channel4: -72.266
2019-03-31_16:34:54 AD.02 Channel1: -72.266
2019-03-31_16:34:55 AD.02 Channel4: -70.312
2019-03-31_16:35:27 AD.02 Channel4: -72.266
2019-03-31_16:35:57 AD.02 Channel1: -70.312
2019-03-31_16:38:36 AD.02 Channel4: -70.312
2019-03-31_16:39:08 AD.02 Channel4: -72.266
2019-03-31_16:39:39 AD.02 Channel2: -68.359
2019-03-31_16:40:10 AD.02 Channel2: -70.312
2019-03-31_16:41:45 AD.02 Channel1: -72.266
2019-03-31_16:42:17 AD.02 Channel1: -70.312
2019-03-31_16:42:48 AD.02 Channel1: -72.266
2019-03-31_16:43:20 AD.02 Channel1: -70.312
2019-03-31_16:43:21 AD.02 Channel4: -70.312
2019-03-31_16:43:53 AD.02 Channel4: -72.266
2019-03-31_16:45:27 AD.02 Channel1: -72.266
2019-03-31_16:45:58 AD.02 Channel1: -70.312
2019-03-31_16:46:31 AD.02 Channel4: -70.312
2019-03-31_16:47:03 AD.02 Channel4: -72.266
2019-03-31_16:49:09 AD.02 Channel4: -70.312
2019-03-31_16:49:40 AD.02 Channel1: -72.266
2019-03-31_16:49:41 AD.02 Channel4: -72.266
2019-03-31_16:50:11 AD.02 Channel1: -70.312
2019-03-31_16:51:47 AD.02 Channel4: -70.312
2019-03-31_16:52:19 AD.02 Channel4: -72.266
2019-03-31_16:57:35 AD.02 Channel4: -70.312
2019-03-31_16:58:07 AD.02 Channel4: -72.266
2019-03-31_16:58:38 AD.02 Channel1: -72.266
2019-03-31_16:59:09 AD.02 Channel1: -70.312
2019-03-31_17:00:14 AD.02 Channel4: -70.312
2019-03-31_17:00:45 AD.02 Channel4: -72.266
2019-03-31_17:01:17 AD.02 Channel4: -70.312
2019-03-31_17:01:49 AD.02 Channel4: -72.266
2019-03-31_17:04:58 AD.02 Channel4: -70.312
2019-03-31_17:05:30 AD.02 Channel4: -72.266
2019-03-31_17:07:04 AD.02 Channel1: -72.266
2019-03-31_17:08:07 AD.02 Channel1: -70.312
2019-03-31_17:08:39 AD.02 Channel1: -72.266
2019-03-31_17:09:10 AD.02 Channel1: -70.312
2019-03-31_17:10:14 AD.02 Channel1: -72.266
2019-03-31_17:10:45 AD.02 Channel1: -70.312
2019-03-31_17:11:18 AD.02 Channel4: -70.312
2019-03-31_17:11:50 AD.02 Channel4: -72.266
2019-03-31_17:12:20 AD.02 Channel1: -72.266
2019-03-31_17:12:52 AD.02 Channel1: -70.312
2019-03-31_17:16:33 AD.02 Channel1: -72.266
2019-03-31_17:17:05 AD.02 Channel1: -70.312
2019-03-31_17:17:37 AD.02 Channel1: -72.266
2019-03-31_17:18:08 AD.02 Channel1: -70.312
2019-03-31_17:20:47 AD.02 Channel1: -72.266
2019-03-31_17:21:18 AD.02 Channel1: -70.312
2019-03-31_17:22:21 AD.02 Channel1: -72.266
2019-03-31_17:23:25 AD.02 Channel1: -70.312
2019-03-31_17:23:56 AD.02 Channel1: -72.266
2019-03-31_17:24:28 AD.02 Channel1: -70.312
2019-03-31_17:25:31 AD.02 Channel1: -72.266
2019-03-31_17:26:03 AD.02 Channel1: -70.312
2019-03-31_17:27:07 AD.02 Channel4: -70.312
2019-03-31_17:27:38 AD.02 Channel1: -72.266
2019-03-31_17:27:39 AD.02 Channel4: -72.266
2019-03-31_17:28:41 AD.02 Channel1: -70.312
2019-03-31_17:29:44 AD.02 Channel1: -72.266
2019-03-31_17:29:46 AD.02 Channel4: -70.312
2019-03-31_17:30:17 AD.02 Channel4: -72.266
2019-03-31_17:30:48 AD.02 Channel1: -70.312
2019-03-31_17:31:52 AD.02 Channel4: -70.312
2019-03-31_17:32:24 AD.02 Channel4: -72.266
2019-03-31_17:39:14 AD.02 Channel1: -72.266
2019-03-31_17:40:17 AD.02 Channel1: -70.312
2019-03-31_17:41:52 AD.02 Channel1: -72.266
2019-03-31_17:42:25 AD.02 Channel4: -70.312
2019-03-31_17:42:55 AD.02 Channel1: -70.312
2019-03-31_17:42:57 AD.02 Channel4: -72.266
2019-03-31_17:44:30 AD.02 Channel1: -72.266
2019-03-31_17:45:02 AD.02 Channel1: -70.312
2019-03-31_17:46:05 AD.02 Channel1: -72.266
2019-03-31_17:46:37 AD.02 Channel1: -70.312
2019-03-31_17:49:15 AD.02 Channel1: -72.266
2019-03-31_17:50:18 AD.02 Channel1: -70.312
2019-03-31_17:51:23 AD.02 Channel4: -70.312
2019-03-31_17:52:26 AD.02 Channel4: -72.266
2019-03-31_17:52:56 AD.02 Channel1: -72.266
2019-03-31_17:53:28 AD.02 Channel1: -70.312
2019-03-31_17:59:48 AD.02 Channel1: -72.266
2019-03-31_18:00:51 AD.02 Channel1: -70.312
2019-03-31_18:01:54 AD.02 Channel1: -72.266
2019-03-31_18:01:55 AD.02 Channel4: -70.312
2019-03-31_18:02:26 AD.02 Channel1: -70.312
2019-03-31_18:02:27 AD.02 Channel4: -72.266
2019-03-31_18:03:29 AD.02 Channel1: -72.266
2019-03-31_18:04:01 AD.02 Channel1: -70.312
2019-03-31_18:05:04 AD.02 Channel1: -72.266
2019-03-31_18:05:36 AD.02 Channel1: -70.312
2019-03-31_18:06:39 AD.02 Channel1: -72.266
2019-03-31_18:06:40 AD.02 Channel4: -70.312
2019-03-31_18:07:12 AD.02 Channel4: -72.266
2019-03-31_18:07:42 AD.02 Channel1: -70.312
2019-03-31_18:11:56 AD.02 Channel3: -78.125
2019-03-31_18:12:28 AD.02 Channel3: -76.172
2019-03-31_18:12:58 AD.02 Channel1: -72.266
2019-03-31_18:14:02 AD.02 Channel1: -70.312
2019-03-31_18:14:33 AD.02 Channel1: -72.266
2019-03-31_18:15:05 AD.02 Channel1: -70.312
2019-03-31_18:16:40 AD.02 Channel1: -72.266
2019-03-31_18:17:43 AD.02 Channel1: -70.312
2019-03-31_18:17:43 AD.02 Channel2: -68.359
2019-03-31_18:18:15 AD.02 Channel2: -70.312
2019-03-31_18:18:46 AD.02 Channel1: -72.266
2019-03-31_18:18:48 AD.02 Channel4: -70.312
2019-03-31_18:19:18 AD.02 Channel1: -70.312
2019-03-31_18:19:19 AD.02 Channel4: -72.266
2019-03-31_18:21:56 AD.02 Channel1: -72.266
2019-03-31_18:22:28 AD.02 Channel1: -70.312
2019-03-31_18:24:34 AD.02 Channel1: -72.266
2019-03-31_18:25:06 AD.02 Channel1: -70.312
2019-03-31_18:27:44 AD.02 Channel1: -72.266
2019-03-31_18:28:47 AD.02 Channel1: -70.312
2019-03-31_18:34:36 AD.02 Channel4: -70.312
2019-03-31_18:35:08 AD.02 Channel4: -72.266
2019-03-31_18:35:40 AD.02 Channel4: -70.312
2019-03-31_18:36:11 AD.02 Channel4: -72.266
2019-03-31_18:37:15 AD.02 Channel4: -70.312
2019-03-31_18:37:46 AD.02 Channel4: -72.266
2019-03-31_18:38:48 AD.02 Channel1: -72.266
2019-03-31_18:39:20 AD.02 Channel1: -70.312
2019-03-31_18:40:55 AD.02 Channel1: -72.266
2019-03-31_18:43:33 AD.02 Channel1: -70.312
2019-03-31_18:44:05 AD.02 Channel1: -72.266
2019-03-31_18:44:36 AD.02 Channel1: -70.312
2019-03-31_18:45:08 AD.02 Channel1: -72.266
2019-03-31_18:45:40 AD.02 Channel1: -70.312
2019-03-31_18:46:11 AD.02 Channel1: -72.266
2019-03-31_18:46:43 AD.02 Channel1: -70.312
2019-03-31_18:47:46 AD.02 Channel1: -72.266
2019-03-31_18:47:47 AD.02 Channel4: -70.312
2019-03-31_18:48:18 AD.02 Channel1: -70.312
2019-03-31_18:48:19 AD.02 Channel4: -72.266
2019-03-31_18:48:51 AD.02 Channel4: -70.312
2019-03-31_18:49:22 AD.02 Channel4: -72.266
2019-03-31_18:49:53 AD.02 Channel1: -72.266
2019-03-31_18:49:54 AD.02 Channel4: -70.312
2019-03-31_18:50:24 AD.02 Channel1: -70.312
2019-03-31_18:50:25 AD.02 Channel4: -72.266
2019-03-31_18:50:56 AD.02 Channel1: -72.266
2019-03-31_18:50:56 AD.02 Channel2: -68.359
2019-03-31_18:51:27 AD.02 Channel1: -70.312
2019-03-31_18:51:28 AD.02 Channel2: -70.312
2019-03-31_18:52:32 AD.02 Channel4: -70.312
2019-03-31_18:53:04 AD.02 Channel4: -72.266
2019-03-31_18:55:42 AD.02 Channel4: -70.312
2019-03-31_18:56:13 AD.02 Channel4: -72.266
2019-03-31_18:56:44 AD.02 Channel1: -72.266
2019-03-31_18:57:15 AD.02 Channel1: -70.312
2019-03-31_19:00:25 AD.02 Channel1: -72.266
2019-03-31_19:00:26 AD.02 Channel4: -70.312
2019-03-31_19:00:58 AD.02 Channel4: -72.266
2019-03-31_19:02:00 AD.02 Channel1: -70.312
2019-03-31_19:02:32 AD.02 Channel1: -72.266
2019-03-31_19:02:33 AD.02 Channel4: -70.312
2019-03-31_19:03:03 AD.02 Channel1: -70.312
2019-03-31_19:03:05 AD.02 Channel4: -72.266
2019-03-31_19:04:08 AD.02 Channel4: -70.312
2019-03-31_19:04:40 AD.02 Channel4: -72.266
2019-03-31_19:09:23 AD.02 Channel1: -72.266
2019-03-31_19:09:55 AD.02 Channel1: -70.312
2019-03-31_19:12:34 AD.02 Channel4: -70.312
2019-03-31_19:13:36 AD.02 Channel1: -72.266
2019-03-31_19:13:37 AD.02 Channel4: -72.266
2019-03-31_19:14:08 AD.02 Channel1: -70.312
2019-03-31_19:18:21 AD.02 Channel2: -68.359
2019-03-31_19:18:53 AD.02 Channel2: -70.312
2019-03-31_19:19:25 AD.02 Channel4: -70.312
2019-03-31_19:20:29 AD.02 Channel4: -72.266
2019-03-31_19:24:09 AD.02 Channel1: -72.266
2019-03-31_19:24:40 AD.02 Channel1: -70.312
2019-03-31_19:29:26 AD.02 Channel4: -70.312
2019-03-31_19:29:58 AD.02 Channel4: -72.266
2019-03-31_19:33:38 AD.02 Channel1: -72.266
2019-03-31_19:34:10 AD.02 Channel1: -70.312
2019-03-31_19:35:45 AD.02 Channel1: -72.266
2019-03-31_19:36:18 AD.02 Channel4: -70.312
2019-03-31_19:36:48 AD.02 Channel1: -70.312
2019-03-31_19:36:49 AD.02 Channel4: -72.266
2019-03-31_19:40:29 AD.02 Channel1: -72.266
2019-03-31_19:42:04 AD.02 Channel1: -70.312
2019-03-31_19:43:08 AD.02 Channel1: -72.266
2019-03-31_19:43:39 AD.02 Channel1: -70.312
Zitat von: M_I_B am 31 März 2019, 20:00:14
... warum sollten die unbeding gleich sein?
Keine Ahnung, du addierst doch in deinem userReading für beide Kanäle den gleichen Offset.
So langsam versteh ich weder dein Problem noch den Sinn dahinter nicht mehr, deine Werte zappeln um einen wert X und du addierst fixe Offsets dazu und erwartest dann das immer 0 dabei herauskommt ?
Edit oder stört dich nur das dort -1.95400000000001 steht statt -1.954 ?? also lediglich die 00000000001 sollen weg ?
Wenn das alles ist so ist sprintf mit "%.3f" dein Freund für die user Readings, allerdinsg wird dann auch die simple 0 zur 0.000. Die wird aber mit einem zusätzlichen +=0 wieder zur nackten 0
... ja, wir reden offensichtlich aneinander vorbei, also der Reihe nach:
1. RAW- Werte: Damit ist im späteren Umfeld doof zu rechnen und erst recht schlecht zu erkennen, wenn was nicht so ist wie es soll
2. Offset- korrigierte Werte:Haben den Sinn, ohne Einganssignal einen Wert umzu "0" zu generieren (siehe 1.). Der bereits in den RAW- Werten enthaltene Jitter (entsprechend +/-1bit aus dem A/D) wird im späteren Verlauf eliminiert
3. Das Problem: Die in den UserReadings korrigierten Werte (siehe 2.) sollten entweder "0" sein oder aber um den Betrag des Jitters von "0" abweichen. Da hier in beiden Fällen (RAW und Offset-Korrektur) mit drei Dezimalstellen gerechnet wird und ausschließlich mit einer Addition, kann als Ergebnis auch nur ein Wert mit drei Dezimalstellen heraus kommen.
*** Tut es aber nicht! ***Es tauchen hier Werte auf mit 14 Dezimalstellen, was mathematisch unmöglich ist. Und genau das ist mein ProblemWo kommen diese Werte resp. mathematischen Unmöglichkeiten bei einer schnöden Addition her ????
ZitatEdit oder stört dich nur das dort -1.95400000000001 steht statt -1.954 ?? also lediglich die 00000000001 sollen weg ?
Ja, genau das soll weg, aber mir geht es hier mehr darum, die Ursache dieser Unmöglichkeit zu eliminieren und nicht um Symtombekämpfung per sprintf
Die Ursache ist Perl selbst und wie math Operationen intern durchgeführt werden.
... ufff! ... Ernsthaft jetzt?
Wie an anderer Stelle bemerkt bin ich kein Coder und habe von PERL selbst keine Ahnung. Aber ich bin eigentlich davon ausgegangen, das Sprachen wie PERL & Co. solcherlei Probleme bei simplen Additionen gar nicht kennen ... Das finde ich jetzt echt schräg :o
Aber immerhin sprechen wir jetzt vom selben Problem ;D
Kann man PERL irgendwie korrektes Verhalten beibiegen, so das hier spätere Symtombekämpfungen vermeidbar sind?
Nunja , simple Addition wäre 72 -71 du benutzt aber keine simplen Integer Zahlen sondern Fließkomma,
und hier muß man einfach im Hinterkopf haben wie eine Fließkomma Zahl intern Binär abgelegt und behandelt wird. Das ist kein wirkliches Perl Problem sondern betrifft auch andere Sprachen.
Hier mal ein simples Beispiel zum Testen :
#!/bin/perl
$a = -72.266;
$b = 70.312;
$c = $a+$b;
print $c."\n";
$c= sprintf("%.3f",$c);
print $c."\n\n";
$b = $a;
$c = $a-$b;
$c= sprintf("%.3f",$c);
print $c."\n";
$c+=0;
print $c."\n";
ergibt als Ausgabe :
-1.95400000000001
-1.954
0
0.000
0
... japp, habe ich mal gemacht... Tatsächlich; is ja doof :o
Nun gut... Lässt sich an der Basis nicht ändern; habe alles auf sprintf umgestellt ...
Vielen Dank für die Erklärung! Muss ich mir unbedingt merken für's nächste mal ...