Originally posted by: <email address deleted>
Verzweiflung... seit Tagen versuche ich einige Temperatursensoren DS18S20
am CunoV2 anslaufen zu bringen, Weder ein herabsetzen des Pullup von 4,7k
stufenweise herunter, noch das ändern der Spannung am Cuno von 3,3 auf 5V
haben Erfolg. Über telnet kann ich 4 Sensoren einwandfrei auslesen - danach
auch über fhem auswerten!
Meine ursprüngliche 2x2x0,6 Verkabelung habe ich durch Cat7 ersetzt. Die
Verkabelungstopologie ist eigentlich ideal, Ringförmig mit ca 1- 1,5m
abgeschirmtes Sensorkabel. Die Sensoren stecken in Messinghüllen und sind
verklebt.
Hat jemand einen Rat für mich?
Oi ergibt bei 4 Sensoren,deren Adresse,
Oi ergibt bei 5 Sensoren nur ok.
Oi bei weniger als 3k Pullup, neustart des Cuno
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Das Thema hatten wir vor geraumer Zeit schonmal (Suche benutzen: "1wire:
unplausible Daten?") ...Der CUNO "kann" nur ein paar wenige Devices, dann
schmiert er ab.
pah hat eine Lösung, die er sicher bald genauer vorstellen wird. Erfordert
eine kleine Lötarbeit.
Gruß
Uwe
Am 5. November 2012 21:11 schrieb Hmm001 :
> Verzweiflung... seit Tagen versuche ich einige Temperatursensoren DS18S20
> am CunoV2 anslaufen zu bringen, Weder ein herabsetzen des Pullup von 4,7k
> stufenweise herunter, noch das ändern der Spannung am Cuno von 3,3 auf 5V
> haben Erfolg. Über telnet kann ich 4 Sensoren einwandfrei auslesen - danach
> auch über fhem auswerten!
> Meine ursprüngliche 2x2x0,6 Verkabelung habe ich durch Cat7 ersetzt. Die
> Verkabelungstopologie ist eigentlich ideal, Ringförmig mit ca 1- 1,5m
> abgeschirmtes Sensorkabel. Die Sensoren stecken in Messinghüllen und sind
> verklebt.
> Hat jemand einen Rat für mich?
>
> Oi ergibt bei 4 Sensoren,deren Adresse,
> Oi ergibt bei 5 Sensoren nur ok.
> Oi bei weniger als 3k Pullup, neustart des Cuno
>
> --
> 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
Nachtrag: pah hat schon veröffentlicht...(ups...)
http://www.fhemwiki.de/wiki/CUNO_und_1-wire
Am 5. November 2012 21:20 schrieb Uwe Hofmann :
> Das Thema hatten wir vor geraumer Zeit schonmal (Suche benutzen: "1wire:
> unplausible Daten?") ...Der CUNO "kann" nur ein paar wenige Devices, dann
> schmiert er ab.
> pah hat eine Lösung, die er sicher bald genauer vorstellen wird. Erfordert
> eine kleine Lötarbeit.
>
> Gruß
> Uwe
>
>
>
>
> Am 5. November 2012 21:11 schrieb Hmm001 :
>
> Verzweiflung... seit Tagen versuche ich einige Temperatursensoren DS18S20
>> am CunoV2 anslaufen zu bringen, Weder ein herabsetzen des Pullup von 4,7k
>> stufenweise herunter, noch das ändern der Spannung am Cuno von 3,3 auf 5V
>> haben Erfolg. Über telnet kann ich 4 Sensoren einwandfrei auslesen - danach
>> auch über fhem auswerten!
>> Meine ursprüngliche 2x2x0,6 Verkabelung habe ich durch Cat7 ersetzt. Die
>> Verkabelungstopologie ist eigentlich ideal, Ringförmig mit ca 1- 1,5m
>> abgeschirmtes Sensorkabel. Die Sensoren stecken in Messinghüllen und sind
>> verklebt.
>> Hat jemand einen Rat für mich?
>>
>> Oi ergibt bei 4 Sensoren,deren Adresse,
>> Oi ergibt bei 5 Sensoren nur ok.
>> Oi bei weniger als 3k Pullup, neustart des Cuno
>>
>> --
>> 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
Originally posted by: <email address deleted>
Hat er ...
Derzeit hängen an meinem CUNO 3 Thermometer, ein A/D-Wandler, ein Counter
und zwei verschiedene Switches und laufen ohne Probleme.
Dann ist aber auch da bald Ende - das Maximum beim CUNO liegt ohne
Neucompilierung der Firmware bei 10 Devices, das ist vom Ersteller der
Firmware so gewollt.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
leider habe ich dazu keinen Erfolg zu vermelden...ich habe den Levelshifter
sowohl mit dem BS170 als auch mit dem 2N7000 aufgebaut und getestet. Beide
funktionieren, aber trotzdem kann ich nur 4 Devices an den CUNO hängen.
Beim 5. schmiert er ab. Schlussfolgerung: CUNO ist eine Fehlinvestition.
Dabei hatte ich ihn speziell wegen der 1-wire-Anbindung angeschafft, um
meinen 1-wire-Bus aufzuteilen. Inzwischen befeuert mein aktives
Selbstbau-USB/1-wire-Interface ungeplant den gesamten Bus. Funktioniert
wenigstens :)
Frustrierte Grüße
Am 5. November 2012 21:51 schrieb Prof. Dr. Peter A. Henning <
prof.dr.peter.a.henning@gmail.com>:
> Hat er ...
>
> Derzeit hängen an meinem CUNO 3 Thermometer, ein A/D-Wandler, ein Counter
> und zwei verschiedene Switches und laufen ohne Probleme.
>
> Dann ist aber auch da bald Ende - das Maximum beim CUNO liegt ohne
> Neucompilierung der Firmware bei 10 Devices, das ist vom Ersteller der
> Firmware so gewollt.
>
> pah
>
>
>
> --
> 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
Originally posted by: <email address deleted>
Diese Frustration mit CUNO und COC habe ich auch schon - gestern erst - an
anderer Stelle geäußert. Ich tippe mal, dass der Prozessor in den beiden
Geräten etwas überfordert ist ...
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich bin im Moment am probieren, wie sich ein USB/1Wire Converter sich an
einem Ethernet/USB Converter macht.....
Gibts beides im kristech.eu Shop.
Funktionieren müsste es zwar wenn man einen logischen Seriellen Port per
socat erzeugt, aber besser wäre eine reine TCP-Kommunikation.
Dann bräuchte man keinen Cuno mehr
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 12.11.2012 um 07:51 schrieb Prof. Dr. Peter A. Henning:
> Diese Frustration mit CUNO und COC habe ich auch schon - gestern erst - an anderer Stelle geäußert. Ich tippe mal, dass der Prozessor in den beiden Geräten etwas überfordert ist
Wie wäre es denn bei aller Meckerei wenn die Herren einfach mal mithelfen die Probleme zu finden und ggfs zu beheben? culfw ist eine OpenSource Firmware, CUNO Schaltpläne liegen alle offen - Mitmachen ist angesagt - das ist mitunter der mit Sinn von freier Hausautomation ...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
"Die Herren" arbeiten hier schon nach Kräften mit ...
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 12.11.2012 um 12:50 schrieb Prof. Dr. Peter A. Henning:
> "Die Herren" arbeiten hier schon nach Kräften mit ...
Es wäre zuerst überhaupt mal abzuklären, ob die 1wire Implementierung in "culfw" OWX tauglich ist oder nicht. Zu Erinnerung: Es wurde für die HMS Emulation dort aufgenommen nicht als Gateway o.ä.
Ich empfehle zudem für 1wire Zugriff auf einem nativen Linuxgerät wie Raspberry die entsprechenden Kernel-Module zu nutzen.
Da mittlerweile dieses Forum von OWX und 1wire Themen/Problemen übersät ist, wäre es zudem auch mal Zeit den Sinn von 1wire-Bussen für verlässliche Automation zu überprüfen und ggfs das OWX Modul zu überarbeiten und konkrete Hardwareempfehlungen auszugeben. Ich bitte solange vom Kauf COC/CUNO abzuraten so der User auf OWX setzen muss/will und nicht mit gewöhnlicher HMS Emulation für Temp.-Sensoren oder nativem Linux-Modul-Zugriff auskommt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
"native Linux-Module" für 1-Wire ??
Gemeint ist wohl OWFS - und der Status von OWFS in FHEM ist eher
unbefriedigend, weil bisher nur Thermometer unterstützt werden.
Es hat auch (fast) niemand Probleme mit OWX und der direkten Ansteuerung
von 1-Wire-Interfaces am USB-Port.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Moin @ all,
könnte mal bitte einer derjenigen, die das Problem mit mehr als 4 Sensoren
am 1-Wire haben,
ein Log bis zur ersten Temperaturmessung posten.
Einstellung in der fhem.cfg:
attr global mseclog
alle Sensoren gelöscht, also nur den Eintrag fuer 1-Wire und fhem.save
bitte leeren, ich habe da einen bestimmten Verdacht.
Mfg
Joachim
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Nachtrag zum oberen Post,
bitte in der OWX.pm in Zeile 92 den debuggingmodus auf 3 setzen.
Gruß Joachim
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Bin ein wenig "spät" - mein CUNO2 hat hier 10 DS18S20 unter sich. Die
Daten werden fleissig einmal die Minute unter der HMS-Simulation
geliefert, keine Probleme. Nebenbei läuft HomeMatic hier komplett über
den CUNO2, keine wesentlich sichtbaren Verzögerungen wahrnehmbar.
Allerdings hat das "Einrichten" multiple (sprich: hunderte) Reboots des
CUNO gekostet. Jetzt läuft er stabil und ich fasse ihn nicht an.
Firmware ist 1.44.
Der Bus ist hier ca. 15m lang und läuft auf 3,3V, davon werden 6
Sensoren nach ca. 9m über eine kleine Platine mit den drei "Schienen"
abgezweigt, dort sitzt sowohl ein kleiner Puffer-Elko (glaube nur 10µF),
Block-Kondensator (100nF) und ein Pullup mit 4k7. Weiter "hinten" am Bus
dann nochmal ein Puffer-Elko (wie vor) und Block-Kondensator (wie vor)
mit den verbleibenden 4 Sensoren.
Kabel ist ein hochflexibles Mikrofon-Kabel, 2-adrig plus Schirmung.
Masse liegt auf der Schirmung und in dem Raum ist die Funkverseuchung
hier wohl am größten. WLAN, HS20, HM, MAX, Server, PV-Anlage usw.
Hoffe es hilft. Vielleicht habe ich aber auch einfach nur Glück. An der
HMS-Simulation werde ich so erstmal nix ändern.
Gruß
Hausautomat
Am 05.11.2012 21:11, schrieb Hmm001:
> Verzweiflung... seit Tagen versuche ich einige Temperatursensoren
> DS18S20 am CunoV2 anslaufen zu bringen, Weder ein herabsetzen des
> Pullup von 4,7k stufenweise herunter, noch das ändern der Spannung am
> Cuno von 3,3 auf 5V haben Erfolg. Über telnet kann ich 4 Sensoren
> einwandfrei auslesen - danach auch über fhem auswerten!
> Meine ursprüngliche 2x2x0,6 Verkabelung habe ich durch Cat7 ersetzt.
> Die Verkabelungstopologie ist eigentlich ideal, Ringförmig mit ca 1-
> 1,5m abgeschirmtes Sensorkabel. Die Sensoren stecken in Messinghüllen
> und sind verklebt.
> Hat jemand einen Rat für mich?
>
> Oi ergibt bei 4 Sensoren,deren Adresse,
> Oi ergibt bei 5 Sensoren nur ok.
> Oi bei weniger als 3k Pullup, neustart des Cuno
> --
> 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
Am 12.11.2012 um 14:55 schrieb Prof. Dr. Peter A. Henning:
> Es hat auch (fast) niemand Probleme mit OWX und der direkten Ansteuerung von 1-Wire-Interfaces am USB-Port.
Dann bitte nur noch diese USB Devices als OWX-supported referenzieren und nicht arme User in die Irre führen, dass OWX stabil mit CUNO oder COC funktionieren würde!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
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
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
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
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
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
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
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
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
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
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
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
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
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