Re: OWX wird aus cfg gelscht, warum?

[Guest]

Originally posted by: <email address deleted>

Einfache Antwort:

OWX löscht alle Devices, die
- bei denen der TYPE-String mit "OW" anfängt UND
- bei denen NICHT present=1 ist UND
- bei denen das IODev-Attribut gesetzt ist aber ungleich dem Namen des
momentanen Busmasters

Denn das sind devices, die für den momentanen Bus definiert sind, aber auf
ihm nicht gefunden wurden.

OWio1 kann sich also nur selbst löschen, wenn es fälschlicherweise ein
IODev-Attribut bekommt...

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich meine das "OWX" (resp OWio1) selber wurde gelöscht und nicht dessen
devices, die devices wären angelegt worden hätte ich autosave = 1 gehabt.
Und IODev kann man bei "OWX" nicht setzen: "OWio1: unknown attribute IODev,
choose one of room group comment alias eventMap "
Und preset = 0 kenn ich nicht, wo steht denn das?

Aber wenn IODev bei "OWX" nicht gesetzt werden kann würde es nach Deiner
logischen Verküpfung:
"OW" & preset=1|0 & IODev = Busmaster (immer false, da nicht setzbar?)
Nie automatisch gelöscht werden...was ja auch sinn macht, es ist ja der
"Busmaster"

Also ich verstehe es noch immer nicht ganz, weil:
preset --> keine Ahnung
IODev --> geht bei "OWX" nicht, nur bei Devices, ist es dann false oder
true?

Oder, wie kann ich verhindern das das "define OWio1 OWX COC01" gelöscht
wird?

Gruß
VT

Am Montag, 12. November 2012 13:05:01 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Einfache Antwort:
>
> OWX löscht alle Devices, die
> - bei denen der TYPE-String mit "OW" anfängt UND
> - bei denen NICHT present=1 ist UND
> - bei denen das IODev-Attribut gesetzt ist aber ungleich dem Namen des
> momentanen Busmasters
>
> Denn das sind devices, die für den momentanen Bus definiert sind, aber auf
> ihm nicht gefunden wurden.
>
> OWio1 kann sich also nur selbst löschen, wenn es fälschlicherweise ein
> IODev-Attribut bekommt...
>
> LG
>
> pah
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ach jaaa, preset = present

Nun das OWX zeigt "active" an wenn ich "get OWio1 devices" aufrufe.
Aber bei OWX wird bei INTERFACE wird "" (also nichts) angezeigt, aber STATE
ist "active"

OK wie kann ich also verhindern das es gelöscht wird?

LG
VT

Am Montag, 12. November 2012 14:34:58 UTC+1 schrieb V T:
>
> Ich meine das "OWX" (resp OWio1) selber wurde gelöscht und nicht dessen
> devices, die devices wären angelegt worden hätte ich autosave = 1 gehabt.
> Und IODev kann man bei "OWX" nicht setzen: "OWio1: unknown attribute
> IODev, choose one of room group comment alias eventMap "
> Und preset = 0 kenn ich nicht, wo steht denn das?
>
> Aber wenn IODev bei "OWX" nicht gesetzt werden kann würde es nach Deiner
> logischen Verküpfung:
> "OW" & preset=1|0 & IODev = Busmaster (immer false, da nicht setzbar?)
> Nie automatisch gelöscht werden...was ja auch sinn macht, es ist ja der
> "Busmaster"
>
> Also ich verstehe es noch immer nicht ganz, weil:
> preset --> keine Ahnung
> IODev --> geht bei "OWX" nicht, nur bei Devices, ist es dann false oder
> true?
>
> Oder, wie kann ich verhindern das das "define OWio1 OWX COC01" gelöscht
> wird?
>
> Gruß
> VT
>
> Am Montag, 12. November 2012 13:05:01 UTC+1 schrieb Prof. Dr. Peter A.
> Henning:
>>
>> Einfache Antwort:
>>
>> OWX löscht alle Devices, die
>> - bei denen der TYPE-String mit "OW" anfängt UND
>> - bei denen NICHT present=1 ist UND
>> - bei denen das IODev-Attribut gesetzt ist aber ungleich dem Namen des
>> momentanen Busmasters
>>
>> Denn das sind devices, die für den momentanen Bus definiert sind, aber
>> auf ihm nicht gefunden wurden.
>>
>> OWio1 kann sich also nur selbst löschen, wenn es fälschlicherweise ein
>> IODev-Attribut bekommt...
>>
>> LG
>>
>> pah
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich sehe immer noch nicht, warum das überhaupt passiert - ist bei mir noch
nie vorgekommen.

Also bitte mal alle 1-Wire-Zeilen (und nur diese, falls der Wink mit dem
Zaunpfahl kar ist...) aus der Konfiguration posten.

pah
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Die hast Du schon...siehe oben (gleicher Zaunpfahl)...vor dem Aufruf "get
OWio1 devices" sieht die cfg wie im ersten Post aus

Wenn ich autosave aktiviere verschwindet der "OWX" aber alle "OW-Devices
werden neu eingetragen"   ...siehe Log oben und dann beschwert sich FHEM
das ich kein OWX definiert habe...

Aber ich kann die Übung gern nochmal machen, dann bekomme ich aber wieder
schlechte Kritiken wegen zu langer Posts und schon alles geschrieben.....

Also wenn bei ...siehe oben... was fehlt, nochmal melden und ich kann es
dann Bedarfsgerecht portionieren.

Ich kann es ja mal vorbereiten....

LG
VT

Am Montag, 12. November 2012 14:57:41 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Ich sehe immer noch nicht, warum das überhaupt passiert - ist bei mir noch
> nie vorgekommen.
>
> Also bitte mal alle 1-Wire-Zeilen (und nur diese, falls der Wink mit dem
> Zaunpfahl kar ist...) aus der Konfiguration posten.
>
> pah
>  
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Joachim]

                                                   

bitte mal das Log bis zur ersten Temperaturmessung posten.
Einstellung in der fhem.cfg:
attr global mseclog
attr global verbose 3
fuer die Ubersichtlichkeit nur die Eintraege fuer 1-Wire und fhem.save
bitte leeren,
in Zeile 92 von OWX.pm den debugmodus auf 3, die
ich habe da einen bestimmten Verdacht.

Mfg
Joachim

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Vorher:
define OWio1 OWX COC01
attr OWio1 buspower real
attr OWio1 room OWX

Nachher:
define OWX_20_F5930C000000 OWAD DS2450 F5930C000000
attr OWX_20_F5930C000000 IODev OWio1
attr OWX_20_F5930C000000 room OWX
define OWX_10_CD1670010800 OWTHERM DS1820 CD1670010800
attr OWX_10_CD1670010800 IODev OWio1
attr OWX_10_CD1670010800 room OWX
define OWX_28_B03863010000 OWTHERM DS18B20 B03863010000
attr OWX_28_B03863010000 IODev OWio1
attr OWX_28_B03863010000 room OWX
define OWX_28_18F0A0010000 OWTHERM DS18B20 18F0A0010000
attr OWX_28_18F0A0010000 IODev OWio1
attr OWX_28_18F0A0010000 room OWX
define OWX_28_753863010000 OWTHERM DS18B20 753863010000
attr OWX_28_753863010000 IODev OWio1
attr OWX_28_753863010000 room OWX
define OWX_29_BCAD02000000 OWSWITCH DS2408 BCAD02000000
attr OWX_29_BCAD02000000 IODev OWio1
attr OWX_29_BCAD02000000 model DS2408
attr OWX_29_BCAD02000000 room OWX
attr OWX_29_BCAD02000000 stateS ☇;
define OWX_29_AFAD02000000 OWSWITCH DS2408 AFAD02000000
attr OWX_29_AFAD02000000 IODev OWio1
attr OWX_29_AFAD02000000 model DS2408
attr OWX_29_AFAD02000000 room OWX
attr OWX_29_AFAD02000000 stateS ☇;

define OWX ist halt weg...

Und jetzt mein beliebter Log
LOG: (reverse LOG)
u.s.w.
2012.11.12 15:10:34 3: OWTHERM: Could not get values from device
OWX_28_753863010000, reason 28.753863010000.64 not accessible
2012.11.12 15:10:34 3: OWX: Complex called with unknown interface on bus
OWio1
2012.11.12 15:10:34 3: OWX: Reset called with undefined interface
2012.11.12 15:10:34 3: OWX: Complex called with unknown interface on bus
OWio1
2012.11.12 15:10:34 3: OWX: Reset called with undefined interface
2012.11.12 15:10:34 3: OWX: Complex called with unknown interface on bus
OWio1
2012.11.12 15:10:34 3: OWX: Reset called with undefined interface
2012.11.12 15:10:34 3: OWX: Complex called with unknown interface on bus
OWio1
2012.11.12 15:10:34 3: OWX: Reset called with undefined interface
2012.11.12 15:10:24 1: OWX: 1-Wire devices found on bus OWio1:
(OWX_20_F5930C000000,OWX_10_CD1670010800,OWX_28_B03863010000,OWX_28_18F0A0010000,OWX_28_753863010000,OWX_29_BCAD02000000,OWX_29_AFAD02000000)
2012.11.12 15:10:24 1: OWX: Deleting unused 1-Wire device OWio1 of type OWX
2012.11.12 15:10:24 3: OWSWITCH:   Device OWX_29_AFAD02000000 defined.
2012.11.12 15:10:24 3: OWSWITCH:   Device OWX_29_BCAD02000000 defined.
2012.11.12 15:10:24 3: OWTHERM: Device OWX_28_753863010000 defined.
2012.11.12 15:10:24 3: OWTHERM: Device OWX_28_18F0A0010000 defined.
2012.11.12 15:10:24 3: OWTHERM: Device OWX_28_B03863010000 defined.
2012.11.12 15:10:24 3: OWTHERM: Device OWX_10_CD1670010800 defined.
2012.11.12 15:10:24 3: OWAD:   Device OWX_20_F5930C000000 defined.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Vielleicht sollte man das hier tun:

foreach my $fhem_dev (sort keys %main::defs) {
    #-- skip if malformed device
    #next if( !defined($main::defs{$fhem_dev}{NAME}) );
    #-- all OW types start with OW
    next if( substr($main::defs{$fhem_dev}{TYPE},0,2) ne "OW");
    #-- skip all types start with OWX
    next if( substr($main::defs{$fhem_dev}{TYPE},0,3) eq "OWX");
    #-- skip if the device is present.
    next if( $main::defs{$fhem_dev}{PRESENT} == 1);
    #-- skip if different IODev
    next if( $main::defs{$fhem_dev}{IODev}{NAME} ne $hash->{NAME} );
    Log 1, "OWX: Deleting unused 1-Wire device $main::defs{$fhem_dev}{NAME}
of type $main::defs{$fhem_dev}{TYPE}";
    CommandDelete(undef,$main::defs{$fhem_dev}{NAME});

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Joo, da haben wir uns überholt...
Werd ich mal machen, aber erst heute Abend, soviel geschnitze schaffe ich
erst nach Feierabend.
Bis bald

Am Montag, 12. November 2012 15:10:49 UTC+1 schrieb joachim herold:
>
> bitte mal das Log bis zur ersten Temperaturmessung posten.
> Einstellung in der fhem.cfg:
> attr global mseclog
> attr global verbose 3
> fuer die Ubersichtlichkeit nur die Eintraege fuer 1-Wire und fhem.save
> bitte leeren,
> in Zeile 92 von OWX.pm den debugmodus auf 3, die
> ich habe da einen bestimmten Verdacht.
>
> Mfg
> Joachim

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Schnüff, heul...
@Joachim
Nach Löschen der fhem.save läßt sich dieser Fehler leider nicht mehr
reproduzieren. Mist.

Dafür habe ich jetzt so ein bissel die Grenze des Machbaren ausgelotet.
Mit Oc bekomme ich noch bis zu 7 1-wire Devices im fhem.log angezeigt (als
unknown message  nach "set COC raw Oc".
Hänge ich das 8. Device an, wird keine Antwort mehr auf "set COC raw Oc"
geloggt.

Nun sehe ich leider nicht ob das COC noch antwortet, oder das FHEM einfach
nicht lange genug wartet.
Ich müßte mal das COC rein seriell bespielen ohne FHEM, um zu sehen ob das
COC noch was antwortet.

Es gibt da zwei Möglichkeiten
1. Das COC antwortet nicht mehr ab 8 Devices
2. Das FHEM wartet nicht lange genug auf das COC

Wo ist denn eigentlich das Timeout beim FHEM definiert?
Oder wartet das FHEM gar nicht, sondern reicht nur jedes Telegramm was
irgendwann reinkommt asynchron durch alle Module durch?

Gute Nacht
VT



Am Montag, 12. November 2012 15:19:08 UTC+1 schrieb V T:
>
> Joo, da haben wir uns überholt...
> Werd ich mal machen, aber erst heute Abend, soviel geschnitze schaffe ich
> erst nach Feierabend.
> Bis bald
>
> Am Montag, 12. November 2012 15:10:49 UTC+1 schrieb joachim herold:
>>
>> bitte mal das Log bis zur ersten Temperaturmessung posten.
>> Einstellung in der fhem.cfg:
>> attr global mseclog
>> attr global verbose 3
>> fuer die Ubersichtlichkeit nur die Eintraege fuer 1-Wire und fhem.save
>> bitte leeren,
>> in Zeile 92 von OWX.pm den debugmodus auf 3, die
>> ich habe da einen bestimmten Verdacht.
>>
>> Mfg
>> Joachim
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das ist dann aber nicht FHEM.

Sondern der Raspberry - denn der müsste die gesamte Response vom COC
abwarten. Das kann man statt mit "set" besser mit "get COC raw Oc"
ausprobieren.

Auch OWX.pm parst die gesamte Response, die es vom COC auf den Befehl Oc
erhält. Und wenn diese eben vom Raspberry nicht weitergereicht wird, landet
auch OWX im Nirwana.


LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Denkst Du wirklich das RasPi unterschlägt serielle Telegramme?
Ich kann das nicht so recht glauben, da das FHEM ja direkt auf der
Schnittstelle aufsetzt...also COC schreibt in einen Speicher und FHEM liest
von selbigen.
Was soll da eigentlich schiefgehen?

Wie auch immer, ich denke das der Atmega1284p irgend ein RAM
Zugriffsproblem hat, weil er hin und wieder bei einfachsten Aufrufen
abstürzt.
Da kommt dann immer diese "COC possible Commands ...." unter anderem auch
"NoCmdsforDummies" als response.

Für mich sieht das nach einem Speicherüberlauf im Atmega aus. Die Reaktion
des Chips ist ja dann auch wie immer,
"Wenn ich nicht mehr weiß was ich machen soll fange ich von vorne an" und
Startet seine Firmware von neuem. Dann kennt er natürlich seine 1-wire
Devices nicht mehr und und und.

Hier mal ein LOG von gestern, zeigt die Reanimation nach 8 Devices.
Habe da willkürlich raw Messages rausgehauen, wo ich dachte ich krieg ihn
wieder.
Da sieht man dann (meiner Meinung nach) auch den "Neustart" des COC nach
einem Überlauf.
Wenn der Atméga dann alle 1-wires wieder gefunden hat (nach "Oc"), starte
ich FHEM wieder, da das sich sonst nie wieder mit dem COC zusammenfindet.
ReverseLog (von unten nach oben lesen):

2012.11.13 07:52:47.022 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.021 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.020 3: OWTHERM: Could not get values from device OWX_10_CD1670010800, reason 10.CD167001080000 not accessible in 2nd step
2012.11.13 07:52:47.019 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.018 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.017 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.017 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.016 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.015 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.014 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.013 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.008 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.007 3: OWX: Reset called with undefined interface
2012.11.13 07:52:47.006 3: OWX: Complex called with unknown interface on bus OWio1
2012.11.13 07:52:47.006 3: OWX: Reset called with undefined interface
2012.11.13 07:52:38.545 3: COC01: Possible commands: mCFAZOGMRTVWXefltux
2012.11.13 07:52:38.388 1: /dev/ttyAMA0 reappeared (COC01)
2012.11.13 07:52:38.378 3: Setting COC01 baudrate to 38400
2012.11.13 07:52:38.365 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2099 2012-11-08 20:56:21Z borisneubert $, pid 2574)
2012.11.13 07:52:38.161 1: Including /var/log/fhem/fhem.save
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
Unknown command , try help
2012.11.13 07:52:38.159 1: configfile: Unknown command , try help
2012.11.13 07:52:38.128 3: OWSWITCH:   Device OWX_29_BCAD02000000 defined.
2012.11.13 07:52:38.087 3: OWTHERM: Device OWX_28_753863010000 defined.
2012.11.13 07:52:38.046 3: OWTHERM: Device OWX_28_18F0A0010000 defined.
2012.11.13 07:52:37.949 3: OWSWITCH:   Device OWX_29_AFAD02000000 defined.
2012.11.13 07:52:37.819 3: OWTHERM: Device OWX_28_B03863010000 defined.
2012.11.13 07:52:37.779 3: OWTHERM: Device OWX_10_CD1670010800 defined.
2012.11.13 07:52:37.643 3: OWAD:   Device OWX_20_F5930C000000 defined.
2012.11.13 07:52:35.254 3: SmartPhone: port 8085 opened
2012.11.13 07:52:35.200 3: WEB: port 8083 opened
2012.11.13 07:52:34.732 3: telnetPort: port 7072 opened
2012.11.13 07:52:34.644 1: OWX: 1-Wire bus OWio1: interface in COC01 could not be addressed
2012.11.13 07:52:34.142 1: OWX: 1-Wire bus OWio1: interface not found, answer was
2012.11.13 07:52:33.630 1: OWX: 1-Wire bus OWio1: interface not found, answer was
2012.11.13 07:52:33.119 1: OWX: 1-Wire bus OWio1: interface not found, answer was
2012.11.13 07:52:32.590 1: OWX: 1-Wire bus OWio1: interface not found, answer was
2012.11.13 07:52:27.586 1: /dev/ttyAMA0 disconnected, waiting to reappear
2012.11.13 07:52:26.563 1: OWX: CUNO/COC device COC01 defined
2012.11.13 07:52:26.361 3: COC01: Possible commands: mCFAZOGMRTVWXefltux
2012.11.13 07:52:26.206 3: COC01 device opened
2012.11.13 07:52:26.195 3: Setting COC01 baudrate to 38400
2012.11.13 07:52:25.894 3: Opening COC01 device /dev/ttyAMA0
2012.11.13 07:52:25.127 1: Including /etc/fhem.cfg
2012.11.13 07:52:21.895 0: Server shutdown
2012.11.13 07:52:02.657 3: OWX: returned from CUNO �D
2012.11.13 07:52:02.656 3: OWX: Send to CUNO/COC 0xcc 0x44
2012.11.13 07:52:01.577 2: COC01: unknown message 6:8300000002ADAF29
2012.11.13 07:52:01.554 2: COC01: unknown message 5:8100000002ADBC29
2012.11.13 07:52:01.529 2: COC01: unknown message 4:6400000163387528
2012.11.13 07:52:01.505 2: COC01: unknown message 3:100000016338B028
2012.11.13 07:52:01.479 2: COC01: unknown message 2:BB0008017016CD10
2012.11.13 07:52:01.455 2: COC01: unknown message 1:9D0000000C93F520
2012.11.13 07:52:01.393 3: set COC01 raw Oc
2012.11.13 07:51:56.147 2: COC01: unknown message OK:1
2012.11.13 07:51:56.068 3: set COC01 raw ORb
2012.11.13 07:51:50.191 2: COC01: unknown message ? (�ORm is unknown) Use one of m C F A Z O G M R T V W X e f l t u x
2012.11.13 07:51:50.128 3: set COC01 raw ORm
2012.11.13 07:51:28.727 3: set COC01 raw ORb
2012.11.13 07:51:23.299 3: set COC01 raw Oi
2012.11.13 07:51:17.449 2: COC01: unknown message OK
2012.11.13 07:51:17.388 3: set COC01 raw ORm
2012.11.13 07:50:08.567 3: set COC01 raw Oc
2012.11.13 07:50:02.654 3: OWX: returned from CUNO �D
2012.11.13 07:50:02.653 3: OWX: Send to CUNO/COC 0xcc 0x44

Meine Vermutung: der Fehler muß irgendwo im Ringpuffer des Atmega für das Senden vom COC zum RasPi liegen.
Weil:
Wenn ich arge Empfangsprobleme habe und der COC jedes Telegramm was vom FS20 reinkommt bearbeiten muß,
um festzustellen ist es ein Telegramm oder eine Störung,
lief dieser Puffer immer voll.
Irgendwann wenn der Atmega mal wieder Zeit hatte sich um den UART zu kümmern,
sendete er mir alle empfangenen Telegramme ohne CR als Block ans FHEM und stürzte dabei ab,
wahrscheinlich weil beim Auslesen der Pointer über den Ringpuffer hinauslief.
Weil das Énde von diesem Telegramm war immer verstümmelt.
Das war meine Spekulation...

Ist halt bald Weihnachten und Spekulatius ist doch toll. ;o)

Fazit für mich:
Es wäre schön wenn das OWX selber nicht gelöscht werden würde, in welchem Falle auch immer.
Theoretisch dürfte es ja nie verschwinden, aber um ein Autodelete des OWX zu vermeiden, wäre es ganz nett wenn eine Zeile das Ausschließen würde...

So in diesem Sinne, Danke für den netten Dialog.
Bis bald
VT



Am Dienstag, 13. November 2012 06:49:58 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Das ist dann aber nicht FHEM.
>
> Sondern der Raspberry - denn der müsste die gesamte Response vom COC
> abwarten. Das kann man statt mit "set" besser mit "get COC raw Oc"
> ausprobieren.
>
> Auch OWX.pm parst die gesamte Response, die es vom COC auf den Befehl Oc
> erhält. Und wenn diese eben vom Raspberry nicht weitergereicht wird, landet
> auch OWX im Nirwana.
>
>
> LG
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Eine solche Zeile kann ich problemlos einbauen und werde das auch für das
nächste Update machen.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Joachim]

                                                   

Moin VT,

hattest du die Zeile 93 von OWX.pm  auf
#-- Debugging 0,1,2,3
my $owx_debug=3; geändert?
wenn nicht bitte nocheinmal das aus meinem post von gestern ausführen.
-->
bitte mal das Log bis zur ersten Temperaturmessung posten.
Einstellung in der fhem.cfg:
attr global mseclog
attr global verbose 3
fuer die Ubersichtlichkeit nur die Eintraege fuer 1-Wire und fhem.save
bitte leeren,
in Zeile 92 von OWX.pm den debugmodus auf 3, die
ich habe da einen bestimmten Verdacht.

die erste Temperaturmessung wird mit dieser bytefolge angestossen:

OWX: Sending out 0xe1 0xcc 0x44
OWX: Receiving 0xcc 0x44

MfG
Joachim

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Joachim,

ja ich hatte das debug auf 3 gesetzt. Ich kann Dir einen ganzen Haufen
dieser Logeinträge senden.
Einer dieser Einträge steht ja ganz unten im obigen Log.

Oder eben hier (reverse Log, von unten nach oben):
2012.11.12 20:39:51.528 3: OWX: returned from CUNO �D
2012.11.12 20:39:51.528 3: OWX: Send to CUNO/COC 0xcc 0x44
2012.11.12 20:36:11.636 3: OWX: returned from CUNO 000000000�/d��  x
2012.11.12 20:36:11.636 3: OWX: Receive from CUNO/COC 9 bytes = 0x2F 0x00
0x64 0x00 0xFF 0xFF 0x02 0x10 0x78
2012.11.12 20:36:11.539 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:36:11.016 3: OWX: Sending match ROM to CUNO OmBB0008017016CD10
2012.11.12 20:36:08.635 3: OWX: returned from CUNO 000000000�� d_�  �
2012.11.12 20:36:08.634 3: OWX: Receive from CUNO/COC 9 bytes = 0x8A 0x01
0x64 0x00 0x5F 0xFF 0x06 0x10 0xBB
2012.11.12 20:36:08.537 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:36:08.015 3: OWX: Sending match ROM to CUNO Om100000016338B028
2012.11.12 20:35:58.372 3: OWX: returned from CUNO 000000000�         ��
2012.11.12 20:35:58.371 3: OWX: Receive from CUNO/COC 10 bytes = 0x0F 0x01
0x0F 0x01 0x0F 0x01 0x0F 0x01 0xA6 0x94
2012.11.12 20:35:58.263 3: OWX: Send to CUNO/COC 0xaa 0x08 0x00
2012.11.12 20:35:57.720 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:35:57.697 3: OWX: returned from CUNO 000000000� ������
2012.11.12 20:35:57.696 3: OWX: Receive from CUNO/COC 10 bytes = 0x00 0xFA
0x00 0xFA 0x00 0xFA 0x00 0xFA 0xFF 0xD9
2012.11.12 20:35:57.588 3: OWX: Send to CUNO/COC 0xaa 0x10 0x00
2012.11.12 20:35:57.044 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:35:57.021 3: OWX: returned from CUNO 000000000�f � z � �
2012.11.12 20:35:57.020 3: OWX: Receive from CUNO/COC 10 bytes = 0x66 0x03
0x84 0x03 0x7A 0x03 0x86 0x03 0xF8 0x1A
2012.11.12 20:35:56.913 3: OWX: Send to CUNO/COC 0xaa 0x00 0x00
2012.11.12 20:35:56.369 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:35:56.336 3: OWX: returned from CUNO 000000000< ��
2012.11.12 20:35:56.336 3: OWX: Send to CUNO/COC 0x3c 0x0f 0x00 0xff 0xff
2012.11.12 20:35:55.771 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:35:55.718 3: OWX: returned from CUNO 000000000�������d
2012.11.12 20:35:55.717 3: OWX: Receive from CUNO/COC 10 bytes = 0x00 0xFF
0xFF 0x00 0x00 0x88 0xFF 0xFF 0xE0 0x64
2012.11.12 20:35:55.610 3: OWX: Send to CUNO/COC 0xf0 0x88 0x00
2012.11.12 20:35:55.066 3: OWX: Sending match ROM to CUNO Om8300000002ADAF29
2012.11.12 20:35:02.644 3: OWX: returned from CUNO 000000000�| d_�  �
2012.11.12 20:35:02.644 3: OWX: Receive from CUNO/COC 9 bytes = 0x7C 0x01
0x64 0x00 0x5F 0xFF 0x04 0x10 0x9E
2012.11.12 20:35:02.547 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:35:02.024 3: OWX: Sending match ROM to CUNO Om6400000163387528
2012.11.12 20:34:51.427 3: OWX: returned from CUNO �D
2012.11.12 20:34:51.426 3: OWX: Send to CUNO/COC 0xcc 0x44
2012.11.12 20:31:11.636 3: OWX: returned from CUNO 000000000�0d��  �
2012.11.12 20:31:11.636 3: OWX: Receive from CUNO/COC 9 bytes = 0x30 0x00
0x64 0x00 0xFF 0xFF 0x10 0x10 0xAB
2012.11.12 20:31:11.539 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:31:11.016 3: OWX: Sending match ROM to CUNO OmBB0008017016CD10
2012.11.12 20:31:08.644 3: OWX: returned from CUNO 000000000�� d_�  �
2012.11.12 20:31:08.643 3: OWX: Receive from CUNO/COC 9 bytes = 0x8A 0x01
0x64 0x00 0x5F 0xFF 0x06 0x10 0xBB
2012.11.12 20:31:08.546 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:31:08.023 3: OWX: Sending match ROM to CUNO Om100000016338B028
2012.11.12 20:30:58.372 3: OWX: returned from CUNO 000000000�         ��
2012.11.12 20:30:58.371 3: OWX: Receive from CUNO/COC 10 bytes = 0x0F 0x01
0x0F 0x01 0x0F 0x01 0x0F 0x01 0xA6 0x94
2012.11.12 20:30:58.263 3: OWX: Send to CUNO/COC 0xaa 0x08 0x00
2012.11.12 20:30:57.719 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:30:57.696 3: OWX: returned from CUNO 000000000� ������
2012.11.12 20:30:57.695 3: OWX: Receive from CUNO/COC 10 bytes = 0x00 0xFA
0x00 0xFA 0x00 0xFA 0x00 0xFA 0xFF 0xD9
2012.11.12 20:30:57.588 3: OWX: Send to CUNO/COC 0xaa 0x10 0x00
2012.11.12 20:30:57.044 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:30:57.021 3: OWX: returned from CUNO 000000000�n � � � ��
2012.11.12 20:30:57.020 3: OWX: Receive from CUNO/COC 10 bytes = 0x6E 0x03
0x86 0x03 0x9C 0x03 0xAA 0x03 0xD3 0xD6
2012.11.12 20:30:56.912 3: OWX: Send to CUNO/COC 0xaa 0x00 0x00
2012.11.12 20:30:56.368 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:30:56.336 3: OWX: returned from CUNO 000000000< ��
2012.11.12 20:30:56.336 3: OWX: Send to CUNO/COC 0x3c 0x0f 0x00 0xff 0xff
2012.11.12 20:30:55.771 3: OWX: Sending match ROM to CUNO Om9D0000000C93F520
2012.11.12 20:30:55.718 3: OWX: returned from CUNO 000000000�������d
2012.11.12 20:30:55.718 3: OWX: Receive from CUNO/COC 10 bytes = 0x00 0xFF
0xFF 0x00 0x00 0x88 0xFF 0xFF 0xE0 0x64
2012.11.12 20:30:55.610 3: OWX: Send to CUNO/COC 0xf0 0x88 0x00
2012.11.12 20:30:55.066 3: OWX: Sending match ROM to CUNO Om8300000002ADAF29
2012.11.12 20:30:02.644 3: OWX: returned from CUNO 000000000�| d_�  �
2012.11.12 20:30:02.644 3: OWX: Receive from CUNO/COC 9 bytes = 0x7C 0x01
0x64 0x00 0x5F 0xFF 0x04 0x10 0x9E
2012.11.12 20:30:02.547 3: OWX: Send to CUNO/COC 0xbe
2012.11.12 20:30:02.024 3: OWX: Sending match ROM to CUNO Om6400000163387528
2012.11.12 20:29:51.326 3: OWX: returned from CUNO �D
2012.11.12 20:29:51.325 3: OWX: Send to CUNO/COC 0xcc 0x44

Was muß ich eigentlich tun das dieser Wildcarts " �D"  verschwinden?

Kann es sein das "unsere" Probleme mit ASCII und Unicode zusammenhängen?
COC läuft ja mit char und RasPi versucht das vielleicht als Unicode zu
interopretieren?

Wie auch immer, vielleicht helfen die Logs ja weiter...

Gruß
VT

Am Dienstag, 13. November 2012 10:58:30 UTC+1 schrieb joachim herold:
>
> Moin VT,
>
> hattest du die Zeile 93 von OWX.pm  auf
> #-- Debugging 0,1,2,3
> my $owx_debug=3; geändert?
> wenn nicht bitte nocheinmal das aus meinem post von gestern ausführen.
> -->
> bitte mal das Log bis zur ersten Temperaturmessung posten.
> Einstellung in der fhem.cfg:
> attr global mseclog
> attr global verbose 3
> fuer die Ubersichtlichkeit nur die Eintraege fuer 1-Wire und fhem.save
> bitte leeren,
> in Zeile 92 von OWX.pm den debugmodus auf 3, die
> ich habe da einen bestimmten Verdacht.
>
> die erste Temperaturmessung wird mit dieser bytefolge angestossen:
>
> OWX: Sending out 0xe1 0xcc 0x44
> OWX: Receiving 0xcc 0x44
>
> MfG
> Joachim
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com