Hat jemand mehr als 4 - 1wire Temp. Sensoren am CunoV2?

[Guest]

Originally posted by: <email address deleted>

Hallo alle zusammen,

bei mir laufen aktuelle 3 Temperatursensoren an einem CUNO (mit 3.3V) im
NICHT parasitären Betrieb. Der Bus ist aktuell schätzungsweise (kenne die
genaue Kabellänge nicht mehr - ist CAT5e - meine Netzwerkverkabelung) 50m
lang. Es funktionieren auch 4 Sensoren, wenn ich direkt an der ersten
Messstelle (im Bus vielleicht nach ca. 10m) einen zweiten Sensor dazu
nehme.

Ich habe haber nun das Problem, dass sobald ich den Bus nur verlängere -
also dort, wo die letzte Messstelle sitzt wird der Bus verlängert um einen
weiteren Sensor (auch Temperatur) zu integrieren - fhem keinen Sensor mehr
erkennt.

Ich lese nun hier, dass "Pull-ups" oder "Kondensatoren" verwendet werden.
Kann mir bitte jemand einen Schaltplan" für diese Modifikationen geben?
Wird mir die Modifikation aus dem Wiki helfen? Oder gibt es andere
Vorschläge? Was passiert, wenn ich die Versorgungsspannung seperat in den
Bus einspeise (also z.B. von einem USB die 5V als Versorgungsspannung nutze
und die Datenleitung zum CUNO lege - ich hatte es versucht, aber es hat
auch mit der "kurzen" Leitung nicht mehr funktioniert)?

Danke für eure Hilfe!
Gruß
fossy

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

[UweH]

                                                   

Schau mal hier: http://www.fhemwiki.de/wiki/CUNO_und_1-wire
Bei mir hat der Levelshifter nichts gebracht, bei Peter funktioniert's.

Gruß
Uwe



Am 17. November 2012 18:51 schrieb fossy :

> Hallo alle zusammen,
>
> bei mir laufen aktuelle 3 Temperatursensoren an einem CUNO (mit 3.3V) im
> NICHT parasitären Betrieb. Der Bus ist aktuell schätzungsweise (kenne die
> genaue Kabellänge nicht mehr - ist CAT5e - meine Netzwerkverkabelung) 50m
> lang. Es funktionieren auch 4 Sensoren, wenn ich direkt an der ersten
> Messstelle (im Bus vielleicht nach ca. 10m) einen zweiten Sensor dazu
> nehme.
>
> Ich habe haber nun das Problem, dass sobald ich den Bus nur verlängere -
> also dort, wo die letzte Messstelle sitzt wird der Bus verlängert um einen
> weiteren Sensor (auch Temperatur) zu integrieren - fhem keinen Sensor mehr
> erkennt.
>
> Ich lese nun hier, dass "Pull-ups" oder "Kondensatoren" verwendet werden.
> Kann mir bitte jemand einen Schaltplan" für diese Modifikationen geben?
> Wird mir die Modifikation aus dem Wiki helfen? Oder gibt es andere
> Vorschläge? Was passiert, wenn ich die Versorgungsspannung seperat in den
> Bus einspeise (also z.B. von einem USB die 5V als Versorgungsspannung nutze
> und die Datenleitung zum CUNO lege - ich hatte es versucht, aber es hat
> auch mit der "kurzen" Leitung nicht mehr funktioniert)?
>
> Danke für eure Hilfe!
> Gruß
> fossy
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

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

[UweH]

                                                   

Nachtrag: Die Länge des Busses hat offenbar keinen Einfluss auf das
Problem, zumindest nicht bei denen, die sich bisher zu dem Thema hier
geäußert haben. Externe Versorgungsspannung ändert auch nichts, siehe
Erklärung des Ganzen im Wiki und in den diversen Threads.

Sollte der Levelshifter bei Dir nicht helfen, dann musst auch Du warten,
bis die Experten hier eine Lösung gefunden haben.


Am 17. November 2012 18:58 schrieb Uwe Hofmann :

> Schau mal hier: http://www.fhemwiki.de/wiki/CUNO_und_1-wire
> Bei mir hat der Levelshifter nichts gebracht, bei Peter funktioniert's.
>
> Gruß
> Uwe
>
>
>
> Am 17. November 2012 18:51 schrieb fossy :
>
> Hallo alle zusammen,
>>
>> bei mir laufen aktuelle 3 Temperatursensoren an einem CUNO (mit 3.3V) im
>> NICHT parasitären Betrieb. Der Bus ist aktuell schätzungsweise (kenne die
>> genaue Kabellänge nicht mehr - ist CAT5e - meine Netzwerkverkabelung) 50m
>> lang. Es funktionieren auch 4 Sensoren, wenn ich direkt an der ersten
>> Messstelle (im Bus vielleicht nach ca. 10m) einen zweiten Sensor dazu
>> nehme.
>>
>> Ich habe haber nun das Problem, dass sobald ich den Bus nur verlängere -
>> also dort, wo die letzte Messstelle sitzt wird der Bus verlängert um einen
>> weiteren Sensor (auch Temperatur) zu integrieren - fhem keinen Sensor mehr
>> erkennt.
>>
>> Ich lese nun hier, dass "Pull-ups" oder "Kondensatoren" verwendet werden.
>> Kann mir bitte jemand einen Schaltplan" für diese Modifikationen geben?
>> Wird mir die Modifikation aus dem Wiki helfen? Oder gibt es andere
>> Vorschläge? Was passiert, wenn ich die Versorgungsspannung seperat in den
>> Bus einspeise (also z.B. von einem USB die 5V als Versorgungsspannung nutze
>> und die Datenleitung zum CUNO lege - ich hatte es versucht, aber es hat
>> auch mit der "kurzen" Leitung nicht mehr funktioniert)?
>>
>> Danke für eure Hilfe!
>> Gruß
>> fossy
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>

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

[Guest]

Originally posted by: <email address deleted>

Zu Erklärung: der Level-Shifter hilft dann (oder MUSS dann) eingesetzt
werden, wenn der 1-Wire Bus vom CUNO auf 3,3V läuft, und

1. die Kommunikation mit einzelnen Devices zwar grundsätzlich möglich, aber
instabil ist.
2. einzelne Sensoren zwingend 5V Bus-Spannung brauchen.

Bei mir war es ein einzelner DS1820 älteren Produktionsdatums, der bei 3,3V
bis zu 10x am Tag einen Wert von 85°C lieferte. Insgesamt war der Bus mit
OWX sehr instabil. Ich hab alle sinnvollen Kombinationen aus Pull-Up und
Pufferkondensatoren ohne Erfolg probiert.
Seit ich den Level Shifter nach Philips in Betrieb habe, sind alle diese
Probleme weg.

Aktuell habe ich aber auch nur 3 Temp Sensoren und einen Switch am Bus.

VG
Ralf

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

[UweH]

                                                   

Den Levelshifter hab ich auch eingebaut, leider ohne Erfolg. Keine Ahnung
im Moment, woran es liegt. Muss noch Ursachenforschung betreiben...




Am 18. November 2012 08:46 schrieb dougie@m1n1.de :

>
> Zu Erklärung: der Level-Shifter hilft dann (oder MUSS dann) eingesetzt
> werden, wenn der 1-Wire Bus vom CUNO auf 3,3V läuft, und
>
> 1. die Kommunikation mit einzelnen Devices zwar grundsätzlich möglich,
> aber instabil ist.
> 2. einzelne Sensoren zwingend 5V Bus-Spannung brauchen.
>
> Bei mir war es ein einzelner DS1820 älteren Produktionsdatums, der bei
> 3,3V bis zu 10x am Tag einen Wert von 85°C lieferte. Insgesamt war der Bus
> mit OWX sehr instabil. Ich hab alle sinnvollen Kombinationen aus Pull-Up
> und Pufferkondensatoren ohne Erfolg probiert.
> Seit ich den Level Shifter nach Philips in Betrieb habe, sind alle diese
> Probleme weg.
>
> Aktuell habe ich aber auch nur 3 Temp Sensoren und einen Switch am Bus.
>
> VG
> Ralf
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

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

[Guest]

Originally posted by: <email address deleted>

Seit ca. 6 Monaten bis vor ein paar Tagen liefen meine 1Wire-Sensoren
DS18S20  mit einer CUNO.
Die ganze Einrichterei war mit Höhen und Tiefen verbunden und alles andere
als stabil. Mal ging gar nichts, dann konnte ich wieder einen mehr dazu
aktivieren.

Glücklich bin ich mit CUNO und 1Wire DS18S20 nicht geworden. Nach dem seit
einer Woche gar kein Temperatur-Wert mehr erfasst wurde, war ich CUNO und
1-Wire einfach leid

Seit gestern läuft hier zusätzlich ein AVR-NET-IO für den es ja einen super
WIKI-Eintrag gibt: http://www.fhemwiki.de/wiki/AVR-NET-IO
Das läuft prima (eben mit 6 Sensoren).

Mein Tipp für DS18S20-Interessierte ist eindeutig AVR-NET-IO anstatt CUNO.

Grüße,
Martin

P.S.: ECMDDevice wird somit in Kürze auch in pgm3 erkannt

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

[Guest]

Originally posted by: <email address deleted>

Ich kann diese Frustration nachvollziehen.

Es maulen immer wieder Leute herum, dass das Modul OWX dafür verantwortlich
sei, dass CUNO/COC in die Knie gehen - nur, komisch, hier sind die gleichen
Leute dann still.

LG

pah

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

[det.]

                                                 

Hallo pah, hallo auch an die übrigen "Herren"

Ist schon erstaunlich, wie die Beteiligung an der Problemlösung durch die Fachleute, welche offenbar wissen wie es geht so einschläft. Da gibt es außer pah niemanden mehr, der z.B. den Post
https://groups.google.com/forum/m/?hl=de&fromgroups#!topic/fhem-users/as2p3ZG7Rf4
weiterführt.
Mein COC ist erst mal in eine untere Schreibtischschublade gewandert und bleibt da, bis es was Neues zum Testen gibt. Bislang funktioniert es definitiv mit 1-wire +COC am RasPi nicht wie erwartet und die Reaktion der Hardwarefraktion erinnert mich an die 90er Jahre wo man gezwungen wurde zur Software beim Distributor die teure Hardware mit zu kaufen, sonst gab es keine Funktionsgarantie. Falls sich noch jemand erinnern kann.
lg det.

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

[Guest]

Originally posted by: <email address deleted>

Nun, die Maulereien der "Hardware-Fraktion" über angeblich grottenschlecht
programmierte OWX-Module, und die unflätigen Pöbeleien einer ganz
bestimmten anderen Person (die sich neuerdings auch darin gefällt, in den
von mir erstellten Wiki-Seiten herumzupfuschen) sind eigentlich als
Motivation reichlich ungeeignet.

Ich bleibe aber an dem Thema dran - sozusagen Eigeninteresse. Mein
eigentlicher Beruf erlaubt das aber immer wieder für längere Zeit gar
nicht, das verständnis müsst ihr schon aufbringen.

In der Zwischenzeit überlege ich reumütig, erst mal wieder zur FritzBox als
Hardware zurückzukehren...

LG

pah


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

[Guest]

Originally posted by: <email address deleted>

Ich bleibe an dem Thema dran - sozusagen Eigeninteresse. Mein eigentlicher
Beruf erlaubt das aber immer wieder für längere Zeit gar nicht, das
Verständnis müsst ihr schon aufbringen.

In der Zwischenzeit überlege ich reumütig, erst mal wieder zur FritzBox als
Hardware zurückzukehren...

LG

pah


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

[Guest]

Originally posted by: <email address deleted>

> Mein Tipp für DS18S20-Interessierte ist eindeutig AVR-NET-IO anstatt CUNO.
>
> Meine Aussage möchte ich relativieren. Auch hier mit  ECMDDevice und
AVR-NET-IO läuft das nicht so rund wie erhofft. Ja, sogar FHEM läuft auf
einmal manchmal mit 100% CPU-Last, weil die Antwort von AVR-NET-IO als
ECMDDevice  nicht so kommt wie erhofft.
Die 1-Wire-Abfrage habe ich eben wieder aus FHEM herausgenommen und nutze
bis auf weiteres Shell-Scripte.

Evtl. liegen meine Probleme also einfach nur an Verkabelung etc. Insofern
kann ich hier nicht sagen, ob nun CUNO, AVR-NET-IO oder etwas anderes nun
die bessere Wahl ist.

Grüße,
Martin

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

[LuckyDay]

                                         

Welche Version hast du verwendet von 66_ECMD.pm? orginal oder die vom
MichaS?
letztere tut bei mir seit 16.Oktober ohne 100% cpulast

Hary

On 19 Nov., 21:50, Martin Haas wrote:
> > Mein Tipp für DS18S20-Interessierte ist eindeutig AVR-NET-IO anstatt CUNO.
>
> > Meine Aussage möchte ich relativieren. Auch hier mit  ECMDDevice und
>
> AVR-NET-IO läuft das nicht so rund wie erhofft. Ja, sogar FHEM läuft auf
> einmal manchmal mit 100% CPU-Last, weil die Antwort von AVR-NET-IO als
> ECMDDevice  nicht so kommt wie erhofft.
> Die 1-Wire-Abfrage habe ich eben wieder aus FHEM herausgenommen und nutze
> bis auf weiteres Shell-Scripte.
>
> Evtl. liegen meine Probleme also einfach nur an Verkabelung etc. Insofern
> kann ich hier nicht sagen, ob nun CUNO, AVR-NET-IO oder etwas anderes nun
> die bessere Wahl ist.
>
> Grüße,
> Martin

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

[nobody0472]

                                                                 

HI all,

es ist recht einfach. CUNO/COC wird nicht gescheit von OWX
unterstützt. Daher funktioniert die Kommuniaktion nicht richtig, und
die Daten werden nicht vollständig abgeholt. Dies hat zur Folge, dass
bei langsamen Devices (RPI, etc.) die culfw (TEIL von COC) aus dem
Tritt/Sync kommt. Dies ist nicht neu, liegt aber weder an der Hardware
noch an der Firmware. Ähnliche Probleme gibt es übrigens auch mit OWX
und USB-Interfaces auf langsamen Maschinen. In einem anderen Thread
nachzulesen.

1-Wire in der culfw war für eine HMS-Emulation gedacht, die auf einem
3.3V Bus läuft. Dies ist auch stabil aufbaubar, und läuft bei einigen
mit mehr als 8 Sensoren. Für diejenigen, die mehr wollen, wurde in der
culfw ein Bit/Byte Kommuniaktionsinterfache für 1-Wire hinterlegt,
welches sich den Regeln der culfw-Schnittstelle unterwirft. Und die
ist nunmal ASCII-basiert und terminiert mit LF. In der culfw Doku
nachzulesen, und mehrfach von Kollegen Tostmann beschrieben.

Dies ist alles erst einmal kein Problem, sofern man nicht mit
einfachen, unsynchrosnisierten "reads" (ala DevIO) versucht irgendwas
zu lesen. Gleiches gilt auch für USB-Devices auf langsamer Hardware.
Dort tritt nämlich das gleiche Problem auf, wie auch schon durch
Kollegen pah dokumentiert.

Daher folge ich mal Kollegen Tostmann, und empfehle CUNO/COC nur für
diejenigen, die eben nicht OWX einsetzen wollen, denn mit dem Modul
läuft die 1-Wire Unterstützung für CUNO/COC nicht rund zusammen.

Da alles OpenSource ist, kann jeder ändern, was er mag, und zumidnest
Vorschläge und Änderungswünsche posten. Wer dies nicht will, und
trotzdem meckert, ist in einem OpenSource Projekt falsch aufgestellt,
denn keiner hier verkauft funktionsgeprüfte Software, die garantiert
mit irgendwas zusammen läuft.

Für die Anwendungsfälle, die die culfw abdecken soll, läuft sie (meist
kommerzielle Hintergründe). Wer mehr will, soll sie entweder ändern,
oder die Module entsprechend anpassen. Ansonsten bitte eine explizite
Hardware-Empfehlung abgeben. Was bei USB-Devices hier wohl auch nicht
geht, da auf langsamen Maschinen gleiches Sync-Problem auftritt.

Also bitte erst Einsatzgebiet klären, und dann überlegen, welche
Lösung helfen könnte. Und wenn man professionelle Hilfe haben will,
sollte man auch bereit sein, professionelle Preise zu bezahlen. Und
bis dahin machen wir das alle, weil wir Spaß dran haben, und eben
nicht aus anderen Gründen.

Gruß,
Olaf

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

[Guest]

Originally posted by: <email address deleted>

Danke Olaf,

hilft mir bei der Beurteilung der Situation sehr viel weiter. Nachdem ich
gestern die nächste Versuchsreihe mit RPi/COC und einem MP00202 USB/1W
Adapter gestartet habe, und der RPi sich damit ebenfalls mit prall
gefülltem Log_File abmeldet, passt das leider lückenlos zu deiner
Beschreibung.

Ich hätte mir viel Arbeit und Ärger sparen können, wenn man mir von
vornherein gesagt hätte, was OWX kann und was nicht. Eine so oft
vorgetragene Aussage wie "Bei mir läuft alles fehlerfrei", das ich es gar
nicht mehr zählen kann, hat mich immer wieder dazu veranlasst, den Fehler
in MEINER Konfiguration zu suchen. Das ist der einzige wirkliche
Kritikpunkt, den ich habe. Meine Erwartungshaltung bei einem
OpenSource-Projekt ist immer den Gegebenheiten angemessen.

Meine Beobachtung ist: RPi (als "langsames System") und OWX ist aktuell in
keiner Konfiguration stabil lauffähig, und damit KEIN Ersatz für z.B. die
FritzBox.

Zum Thema FritzBox und CUNO: die Aussage, das der CUNO nur unter grosser
Last einknickt, kann ich ebenfalls mittels LogFile widerlegen. Auch hier
müssen andere Prozesse ausschlaggebend sein, denn mein CUNO macht in der
Nacht in der Halle wirklich gar nichts, ausser periodisch die 3Stk. 1W
TempSensoren und einen Switch ab zu fragen. Dennoch bringt ihn OWX dazu
immer wieder neu zu starten.

Alle diese Schwierigkeiten tauchen immer nur im Zusammenhang mit OWX auf.
Ohne läuft auch ein RPi mit COC und CUL tagelang absolut störungsfrei.
Ich hab mal gelernt was "fit for purpose" heisst, und das sehe ich hier als
gegeben an. Ich fände es unfair, wenn culfw, CUL, CUNO oder COC hier als
unzureichend dargestellt würden ... das käme mir so vor, als würde der
Schwanz versuchen mit dem Hund zu wedeln (scnr).

Ich sage das auch nur so klar und deutlich, um anderen ggf. die Zeit zu
sparen, die ich inzwischen damit verplempert habe das selber raus zu finden.

VG
Ralf

PS: Zur Verdeutlichung des Gesagten, anbei mal ein Ausschnitt meines
LogFiles von dieser Nacht (sieht JEDE Nacht so aus). Vielleicht hilft es
ja, das Problem irgendwie einzugrenzen.

2012.11.19 22:30:00 2: dummy set Casa_Nachtlicht off
2012.11.19 22:30:46 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.19 23:04:46 1: OWX: Received unexpected number of 33 bytes from
CUNO/COC
2012.11.19 23:59:01 2: dummy set BlowerTime 0
2012.11.20 00:10:47 1: 192.168.1.14:2323 disconnected, waiting to reappear
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
770.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
771.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
772.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
773.
2012.11.20 00:10:53 1: 192.168.1.14:2323 reappeared (CUNO_1)
2012.11.20 00:10:53 3: CUNO_1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.11.20 00:10:53 1: OWX: Received unexpected number of 24 bytes from
CUNO/COC
2012.11.20 00:36:45 1: OWX: Received unexpected number of 33 bytes from
CUNO/COC
2012.11.20 00:36:45 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 00:49:17 1: 192.168.1.14:2323 disconnected, waiting to reappear
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
770.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
771.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
772.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
773.
2012.11.20 00:49:23 1: 192.168.1.14:2323 reappeared (CUNO_1)
2012.11.20 00:49:23 3: CUNO_1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.11.20 01:31:48 1: 192.168.1.14:2323 disconnected, waiting to reappear
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
770.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
771.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
772.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
773.
2012.11.20 01:31:53 1: OWX: Received unexpected number of 88 bytes from
CUNO/COC
2012.11.20 01:31:53 1: 192.168.1.14:2323 reappeared (CUNO_1)
2012.11.20 01:31:53 3: CUNO_1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.11.20 01:48:45 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 02:18:47 1: 192.168.1.14:2323 disconnected, waiting to reappear
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
770.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
771.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
772.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
773.
2012.11.20 02:18:53 1: 192.168.1.14:2323 reappeared (CUNO_1)
2012.11.20 02:18:53 3: CUNO_1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.11.20 02:18:53 1: OWX: Received unexpected number of 8 bytes from
CUNO/COC
2012.11.20 03:04:46 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 03:10:46 1: OWX: Received unexpected number of 35 bytes from
CUNO/COC
2012.11.20 03:40:18 1: 192.168.1.14:2323 disconnected, waiting to reappear
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $ob in substr at ./FHEM/00_OWX.pm line 1987.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
770.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
771.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
772.
Use of uninitialized value $data[0] in ord at ./FHEM/21_OWSWITCH.pm line
773.
2012.11.20 03:40:24 1: 192.168.1.14:2323 reappeared (CUNO_1)
2012.11.20 03:40:24 3: CUNO_1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.11.20 03:40:25 2: CUNO_2: unknown message A0CF582C819DDFA0318
2012.11.20 03:40:26 2: CUNO_2: unknown message OK:1
2012.11.20 03:42:46 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 03:42:46 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 04:50:46 1: OWX: Received unexpected number of 39 bytes from
CUNO/COC
2012.11.20 05:08:45 3: Bad ist zu kalt. (55 )
2012.11.20 05:08:45 3: Dusche ist zu kalt. (63 )
2012.11.20 05:08:45 2: dummy set Casa_Heizung on
2012.11.20 05:08:45 3: Wärme benoetigt: Heizung AN!

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