CUL/COC HM-Firmwaretester gesucht

mgernoth · 21 Juni 2013, 19:35:36

Hallo,

nachdem ich größere Probleme hatte, einen HM-LC-SW1-FM zuverlässig mit einem CUL anzusprechen (obwohl RSSI weit im grünen Bereich), der gleiche Aktor aber mit einem HM-CFG-USB absolut problemlos lief, habe ich mir mal den AskSin-Mode der culfw genauer angeschaut und habe zu meinen Kommunikationsproblemen folgendes gefunden:

Nach dem Absetzen eines Funkbefehls kann es (im schlechtesten Fall) 5ms dauern, bis der RX-Modus wieder aktiviert wird. Alles was dazwischen gesendet wird, geht verloren. Anscheinend antwortet der HM-LC-SW1-FM recht schnell, weshalb ich zwar (mit dem HM-CFG-USB mitgesniffed) die Antwort des Aktors in der Luft gesehen habe, der CUL diese aber ignortiert hat, da er sich nicht mehr einsynchronisieren konnte.
Einige Aktoren (anscheinend mindestens der HM-LC-SW1-FM) brauchen eine etwas längere Präambel vor dem eigentlichen Befehl, um sich sicher auf die übertragenen Daten zu synchronisieren.
Durch die Art, wie der Empfangsmodus in der culfw implementiert ist, kann es bei vielen gleichzeitigen Paketen in der Luft (z.B. Antworten auf ein "set" auf eine große structure) zu Paketverlusten kommen, da der RX-Modus nach jedem empfangenen Paket abgeschaltet wird und erst wieder aktiviert wird, wenn der Mikrocontroller das Paket vollständig gelesen hat. So scheint aber auch der HM-CFG-USB zu arbeiten.

Alle drei Punkte habe ich versucht zu verbessern:

Der CC1101 ist jetzt so konfiguriert, dass er nach dem Verlassen des TX-Modus sofort selbstständig in den RX-Modus wechselt.
Vor dem Absetzen eines Funkbefehls wird jetzt immer eine 10ms lange Präambel (im Burst-Fall 360ms) gesendet.
Die Empfangslogik wurde komplett überarbeitet, der CC1101 verlässt den RX-Modus nun nicht mehr und der Mikrocontroller kümmert sich darum, immer komplette Pakete aus dem FIFO des CC1101 zu holen und an den Host weiterzugeben.

Mit diesen Änderungen kann ich meinen Problemaktor zuverlässig bedienen (kein verlorenes Paket bei 200 Versuchen, davor mindestens 1 verlorenes Paket bei 5 Versuchen) und bekomme auch alle Antworten, wenn ich den Zustand einer Struktur mit 7 Aktoren ändere, ohne das eine Retransmission (durch CUL_HM) nötig wird.

An diesem Post hängen Firmware-Dateien für CUL und COC, die meine Änderungen (Patch) enthalten. Sollte irgendjemand auch Probleme bei der Kommunikation mit einzelnen Aktoren haben, verschafft diese Firmware vielleicht Besserung. Über positive (und auch negative) Rückmeldungen würde ich mich freuen.

Gruß
Michael

marc2 · 30 Juni 2013, 20:27:06

Hallo Michael,

ich habe einen HM-LC-SW2-FM der über einen direkt gepairten Taster wunderbar funktioniert
mit CUL und CUNO (trotz recht guten RSSI Werte) immer wieder Probleme macht. Ich habe den
CUL der als primäres IODev genutzt wird mal mit Deinem Patch versehen. Bisher funktioniert
der HM-LC-SW2-FM jetzt über den CUL ohne die bisherigen Probleme. Werde ich mal weiter
beobachten und ggf. auch noch den CUNO mit dem Patch versehen.

Es wundert micht, dass es in diesem Thread so ruhig zugeht ! Hat wirklich sonst noch niemand
den Patch getestet ? Beim gestrigen Update kamen zwar neuen HEX Dateien mit, das CULFW SVN
ist aber unverändert . Warum dann die neuen HEX Files für CUL und Co. ?

Gruß, Marc

mgernoth · 30 Juni 2013, 21:28:07

Hallo Marc,

Zitat von: marc2 schrieb am So, 30 Juni 2013 20:27ich habe einen HM-LC-SW2-FM der über einen direkt gepairten Taster wunderbar funktioniert
mit CUL und CUNO (trotz recht guten RSSI Werte) immer wieder Probleme macht. Ich habe den
CUL der als primäres IODev genutzt wird mal mit Deinem Patch versehen. Bisher funktioniert
der HM-LC-SW2-FM jetzt über den CUL ohne die bisherigen Probleme. Werde ich mal weiter
beobachten und ggf. auch noch den CUNO mit dem Patch versehen.

Danke für die Rückmeldung. Schön, dass der Patch auch bei Dir hilft. :-)

ZitatEs wundert micht, dass es in diesem Thread so ruhig zugeht ! Hat wirklich sonst noch niemand
den Patch getestet ?

Anscheinend hat sonst niemand diese Probleme, oder es faellt nicht auf (meistens kommt ja einer der Retransmits trotzdem beim Aktor an)...

ZitatBeim gestrigen Update kamen zwar neuen HEX Dateien mit, das CULFW SVN
ist aber unverändert . Warum dann die neuen HEX Files für CUL und Co. ?

Die Firmware-Dateien enthalten die Änderungen der ersten beiden Punkte. Die Änderungen für den letzten Punkt hatte ich mich nicht getraut zu committen, da ich manchmal noch Probleme habe, die Paketgrenzen richtig zu erkennen.
Der aktuelle Code im SVN hat noch ein paar mehr Änderungen, womit jetzt auch CCA benutzt wird (es wird vor dem senden geschaut, ob gerade anderer Funkferkehr stattfindet und solange gewartet, bis dieser vorbei ist). Da habe ich aber noch keine neuen HEX-Dateien committed.

Evtl. hast Du einen alten SVN-Checkout, sourceforge hat das Repository umgezogen:
svn checkout svn://svn.code.sf.net/p/culfw/code/trunk/culfw">svn://svn.code.sf.net/p/culfw/code/trunk/culfw

Gruß
Michael

marc2 · 30 Juni 2013, 22:44:48

Hallo Michael !

ZitatDer aktuelle Code im SVN hat noch ein paar mehr Änderungen, womit jetzt auch CCA benutzt wird (es wird vor dem senden geschaut, ob gerade anderer Funkferkehr stattfindet und solange gewartet, bis dieser vorbei ist). Da habe ich aber noch keine neuen HEX-Dateien committed.

Wenn CCA bislang nicht implementiert war, bin ich verblüfft, wie gut das ganze bisher auch ohne CCA funktioniert hat :-)

ZitatEvtl. hast Du einen alten SVN-Checkout, sourceforge hat das Repository umgezogen:
svn checkout svn://svn.code.sf.net/p/culfw/code/trunk/culfw">svn://svn.code.sf.net/p/culfw/code/trunk/culfw

Ja, in der Tat, das ist an mir vorbei gegangen. Danke für den Hinweis ! Das scheint für FHEM selbst ja auch zu gelten, wobei
das auf FHEM.de referenzierte SVNLOG noch auf die alte Lokation verweist (Revision 3274).

http://fhem.de/SVNLOG

Gruß, Marc

mgernoth · 02 Juli 2013, 21:21:45

Hallo Marc,

soeben habe ich neugebaute Firmwaredateien (Version 1.57) ins SVN committed, d.h. ab morgen gibts CCA per update.

Zitat von: marc2 schrieb am So, 30 Juni 2013 22:44Wenn CCA bislang nicht implementiert war, bin ich verblüfft, wie gut das ganze bisher auch ohne CCA funktioniert hat :-)

Naja, die "alte" Version hat schon ein bisschen CCA gemacht: Sie hat das aktuelle Paket weggeschmissen und nicht gesendet.
Mein Änderungen in 1.56 haben dann CCA komplett umgangen, weil ccTX() sich etwas unerwartet verhält (es kämpft aktiv gegen CCA). Das habe ich zwar schonmal festgestellt aber wieder verdrängt. Deswegen habe ich dann die ccTX()-Funktionalität nochmal etwas abgewandelt in rf_asksin.c implementiert.

ZitatDas scheint für FHEM selbst ja auch zu gelten, wobei das auf FHEM.de referenzierte SVNLOG noch auf die alte Lokation verweist (Revision 3274).

http://fhem.de/SVNLOG

Danke, ich schreibs mal Rudi, damit er sich die Links anschaut.

Gruß
Michael

marc2 · 02 Juli 2013, 23:13:30

Hallo Michael,

ich habe die Version 1.57 mal auf meinen CUL und nach ein paar kurzen erfolgreichen Tests (der problematische Aktor funktioniert nach wie vor fehlerfrei), auf beide CUNOs geflasht. Nachdem auch die von Hand gepatchte 1.55 auf den CUL keinerlei Probleme gemacht hat, bin ich bei Deiner 1.57 auch guter Dinge :-) Ich werde es die kommenden Tage mal beobachten.

Beinhaltet diese Version nun alle drei Änderungen + CCA ? Haben die Änderungen eigentlich ausschließlich Auswirkungen
auf "rfmode HomeMatic" oder auch z.B. "rfmode MAX" oder andere. MAX nutzt zwar kein asksin, aber es wurde ja auch
einiges mehr angepackt.

Gruß, Marc

mgernoth · 03 Juli 2013, 08:20:48

Hallo Marc,

Zitat von: marc2 schrieb am Di, 02 Juli 2013 23:13ich habe die Version 1.57 mal auf meinen CUL und nach ein paar kurzen erfolgreichen Tests (der problematische Aktor funktioniert nach wie vor fehlerfrei), auf beide CUNOs geflasht. Nachdem auch die von Hand gepatchte 1.55 auf den CUL keinerlei Probleme gemacht hat, bin ich bei Deiner 1.57 auch guter Dinge :-) Ich werde es die kommenden Tage mal beobachten.

Sehr gut :-)

ZitatBeinhaltet diese Version nun alle drei Änderungen + CCA ?

Nein, nur die ersten beiden und CCA. Wobei ich diese Version jetzt einsetze, seit ich die Änderungen committed habe und dabei keine Funkprobleme mehr aufgetreten sind. Wahrscheinlich war das Problem also eher das fehlende CCA als das kurze Abschalten des Receive-Mode nach dem Empfang eines Pakets.

ZitatHaben die Änderungen eigentlich ausschließlich Auswirkungen auf "rfmode HomeMatic" oder auch z.B. "rfmode MAX" oder andere. MAX nutzt zwar kein asksin, aber es wurde ja auch einiges mehr angepackt.

Meine Änderungen betreffen nur Homematic (und Support für die RFbee). Die anderen Änderungen stammen von Dirk Tostmann und sind für die Implementierung von Aktoren/Sensoren mit culfw relevant (wenn ich das richtig sehe).
Die Moritz-Implementierung sieht für mich auf den ersten Blick so aus, als ob sie die Probleme der AskSin-Implementierung nicht hätte, genau hab ich mir das aber noch nicht angeschaut.

Gruß
Michael

thunder · 04 Juli 2013, 08:05:11

sorry für die dumme Frage... aber wo finde ich die compilierte 1.57 für den CUNO2?

mgernoth · 04 Juli 2013, 08:26:18

Hallo,

Zitat von: thunder schrieb am Do, 04 Juli 2013 08:05sorry für die dumme Frage... aber wo finde ich die compilierte 1.57 für den CUNO2?

Das ist gar keine dumme Frage. Da ich die culfw-Webseite nicht aktualisieren kann, findest Du die kompilierte Version für alle Geräte nur im SVN-Repository. Das hat aber auch ein Web-Interface: https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/

Die Firmware für den CUNO2 gibts direkt hier: https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUNO2/CUNO2.hex?format=raw

Gruß
Michael

thunder · 04 Juli 2013, 09:45:28

Vielen Dank!!!!

betateilchen · 21 Juli 2013, 22:22:20

Ich habe grade die COC radio-only 1.57 auf meinen COC geladen, danach tut der gar nicht mehr, weder senden noch empfangen.

Wenn ich wieder die 1.49 einspiele, ist alles in Ordnung. Hat jemand einen konstruktiven Tipp für mich?

Nachtrag: die 1.55 hier aus dem Thread scheint zu funktionieren.

mgernoth · 22 Juli 2013, 08:47:12

Hi,

Zitat von: betateilchen schrieb am So, 21 Juli 2013 22:22Ich habe grade die COC radio-only 1.57 auf meinen COC geladen, danach tut der gar nicht mehr, weder senden noch empfangen.

Wenn ich wieder die 1.49 einspiele, ist alles in Ordnung. Hat jemand einen konstruktiven Tipp für mich?

Nachtrag: die 1.55 hier aus dem Thread scheint zu funktionieren.

Hmm, das ist komisch.
Die Version in diesem Thread hat im Gegensatz zur 1.57 einen anderen CC1101-FIFO-Lesealgorithmus, der Sendealgorithmus ist aber fast identisch.
Die 1.57 hat einen CC1101-FIFO-Lesealgorithmus, der sich wieder näher an dem der Release-FW <= 1.55 ist.
Der eingesetzte Compiler ist bei beiden Versionen identisch (habe beide auf dem selben Rechner kompiliert).

Deswegen hätte ich erwartet, dass zumindest eine der beiden Operationen Senden/Empfangen funktioniert.

Hast Du evtl. irgendwelche SlowRF-Geräte die den COC als IODev benutzen? Das geht im HM-Modus nicht, da nach dem umschalten auf SlowRF die AskSin-Configuration nicht wieder hergestellt wird.

Ich versuche mal draufzukommen, warum die 1.57 bei Dir dieses Verhalten zeigt. (Bei mir läuft sie problemlos auf einem COC).

Gruß
Michael

betateilchen · 22 Juli 2013, 10:06:31

Hallo Michael,

der COC wird bei mir ausschließlich für SlowRF (FS20 und S300TH) benutzt und nie umgeschaltet. Für HomeMatic habe ich separate Hardware im Einsatz.

Was mir noch aufgefallen ist:
Bei 1.49 und 1.55 wird mir der COC als "initialized" in FHEM angezeigt, mit 1.57 steht da nur "opened" und es wird auch keine Versionsnummer angezeigt.

Viele Grüße
Udo

mgernoth · 22 Juli 2013, 10:59:59

Hallo Udo,

Zitat von: betateilchen schrieb am Mo, 22 Juli 2013 10:06Was mir noch aufgefallen ist:
Bei 1.49 und 1.55 wird mir der COC als "initialized" in FHEM angezeigt, mit 1.57 steht da nur "opened" und es wird auch keine Versionsnummer angezeigt.

Also kommt gar keine Kommunikation mit dem COC zustande.
Hast Du ihn nach dem Flashen nochmals testweise resettet und war der Bootloader-Pin (gpio18) sicher wieder high?

Der grundlegende Kommunikationscode wurde zwischen den Versionen nicht angefasst, deswegen ist dieses Verhalten noch sonderbarer als gedacht...

Gruß
Michael

betateilchen · 22 Juli 2013, 11:12:03

Zitat von: mgernoth schrieb am Mo, 22 Juli 2013 10:59Hast Du ihn nach dem Flashen nochmals testweise resettet und war der Bootloader-Pin (gpio18) sicher wieder high?

Hallo Michael,

Alles probiert. Inkl. spannungslos machen und wieder Einschalten der gesamten Hardware. Die beiden anderen Versionen laufen direkt nach dem Aufspielen und dem Neustart von fhem los (beim Start von fhem wird der COC resettet)

Viele Grüße
Udo

betateilchen · 22 Juli 2013, 13:46:55

Hallo Michael,

könntest Du mir die Datei bitte mal hier im Thread anhängen?
Ich habe die nämlich zweimal aus SVN geladen - mit zwei unterschiedlichen Dateigrößen (Differenz = 2 Bytes)
Vielleicht geht da einfach beim Download irgendwas schief, obwohl sich beide Dateien fehlerfrei flashen lassen - beide mit negativem Ergebnis.

Viele Grüße
Udo

mgernoth · 22 Juli 2013, 22:11:16

Hallo Udo,

Zitat von: betateilchen schrieb am Mo, 22 Juli 2013 13:46könntest Du mir die Datei bitte mal hier im Thread anhängen?

Klar, kein Problem. Hier die Datei aus dem SVN, habe sie auch testweise geflasht, läuft (bei mir) problemlos.

Gruß
Michael

betateilchen · 22 Juli 2013, 22:46:14

Hallo Michael,

mit dieser Datei funktioniert der COC problemlos. Sehr komisch.

(http://up.picr.de/15267027ul.png)

Danke & viele Grüße
Udo

cerberus · 16 Oktober 2013, 18:42:24

Hallo mgernoth, wo bekomme ich die Version 1.57 mit allen Optionen wie Uhr, EEProm her (also nicht die radio_only)?

Die Version unter folgendem Link funktioniert bei mir jedenfalls nicht.

http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/

Gruß
cerberus

roli · 26 November 2013, 17:57:13

Hi,
das hört sich ja alles wie Spielwiese und nicht wie HArdware an, welche brauchbar ist.

Ich habe eine RASPI Mod B rev 2 und eine BUSWARE COC ( denke RAdio only ) geschenkt bekommen und würde sie gerne mit FS20 einsetzten.
Leider bin ich nach 2 Tagen nicht weiter, da alle Versuche diese mit einigermaßen Beschreibung zum laufen zu bringen gescheitert ist.
Viele Threads aber noch mehr Verwirrung. Erst mal scheint es wohl eine GPIO Pin belegungsänderung zwischen REv1 und Rev2 PIs zu geben.
Ich denke dies könnte eine Rolle spielen weshalb ich nicht weiterkomme. D.h. wohl auch die Bus adresse ist bei Rev2 nicht mehr 0 sondern 1.

Ich verwende Debian und wie gesagt, bisher geht noch nichts, weshalb auch immer. Immer wieder liest man, dass eine version der Firmware tut, eine andere
aber nicht - chaos kann nicht größer sein.
An den Pins kann es bei mir nicht liegen, da mein COC bombenfest passt und sitzt und hier beim Radio only wohl auch besser gelöst ist.
Trotzdem, was tur und welche Firmware spiele ich wie auf ?

Hat überhaupt jemand erfolgreich di eRadio only COC auf einer Raspi Rev2 am laufen ?
Prinzipiell fehlt auch eine strukturierte diagnose Anleitung, wie man rausfinden kann was jetzt wirklich nicht tut.
Wie finde ich heraus ob eine aufgespielte Firmware überhaupt tut - sprich im Ansatz korrekt war ?
Sorry ich bin kein Linux experte und wollte ursprünglich nicht tiefer blicken, sondern mich um eine App mit FHEM kümmern.
Eigentlich hätte ich schon erwartet, dass es eine Anleitung gibt, welche klar erklärt wie ich
das Busware Teil zum laufen bringe. Und da es eine Raspi Rev 1 und Rev 2 gibt, auch klar strukturiert wenn Unterschiede relevant sind --
wie soll man denn da weiterkommen, wenn man ein stück board geschickt bekommt und dies nicht mal mehr auf der Webseite von busware findet
( radio only ).

Also HOFFE ich, dass es jemand doch geschafft hat und mir sagen kann wie ?

Danke

betateilchen · 26 November 2013, 21:06:41

solange Du die COC Platine falschrum auf dem Raspberry hast, wird das auch nicht funktionieren können!

(http://up.picr.de/16584172px.jpg)

Link zur Bildquelle vom Fragesteller...l

roli · 27 November 2013, 10:13:08

Danke für den Hinweis. Habe ich jetzt bereits von jemand gesagt bekommen. Leider ging das Ding anders herum nicht drauf ohne etwas abzuschleifen
(Stecker un der Mitte ging nicht durch - auch nicht nach abheben des einen Teils - no way - minimal zu eng. Und mit zuviel Kraft hätte ich eventuell
die Raspi und das Board kaputt gemacht.
Sowas kann man auch besser herstellen - dann sitzt der Stecker auch besser und es beklagt sich nicht jeder wegen Kontakt-Problemen.
Wäre die Steckleiste unten angelötet würde alles bombensicher gehn und auch wenn das Board dann etwas höher sitzt stört es nicht - im Gegenteil.

Waldmensch · 18 Januar 2014, 18:53:10

Hallo Forum

Ich bin neu hier. Ich habe seit heute ein COC vollbestückt und das gleiche Problem, das keine LED blinkt und nur "opened" angezeigt wird. Ich hatte diese Firmware geflasht http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/COC.hex?revision=HEAD

Jetzt war ich mal so dreist die hier verlinkte Radio only Version zu flashen. Sofort nach Reset blinkt die LED am COC und die Meldung lautet nun "initialized". Jetzt laufen auch FHT Daten auf. Vermutlich geht aber mit dieser Firmware dann OneWire und der Rest nicht. Das ist zwar für den Moment nicht weiter wild aber auch nicht schön.

Es wäre nett, wenn mgernoth die Version noch mal als Vollversion posten würde.

Vielen Dank!

Zitat von: mgernoth am 22 Juli 2013, 22:11:16
Hallo Udo,

Klar, kein Problem. Hier die Datei aus dem SVN, habe sie auch testweise geflasht, läuft (bei mir) problemlos.

Gruß
Michael

chris1284 · 18 Januar 2014, 19:13:13

die mit onewire/rtc/eeprom funzt genau so gut wenn du den ensprechende COC-Erweiterung hast. Wichtig ist die Meldung von avrdude beim flashen genau zu lesen (auch wenn es für den leihen so aussieht als hätte es funktioniert). Denn der 1. Schritt ist das löschen der Firmware auf dem COC, dann wird die zu flashende Datei geprüft, haut damit was nicht hin (vertippt beim Namez.B) hört das flashen auf.
Ergebniss ist wie hier beschrieben ein nicht blinkender coc mit status opened.

Waldmensch · 18 Januar 2014, 20:33:45

Ich habe leider das Log vom flashen nicht mehr. Aber sowohl mit der, die nicht geht als auch mit der, die jetzt drauf ist liefen bei avrdude der write und der read Balken voll uns unten stand "vielen Dank"

Seltsamerweise ist die COC kleiner als die COC.radio_only obwohl man es andersrum erwarten würde

Code Auswählen

-rw-r--r-- 1 root root 19818 Jan 15 20:21 COC.hex
-rw------- 1 root root 43255 Jan 18 18:11 COC.radio_only.hex

Waldmensch · 18 Januar 2014, 20:40:14

Krass! Hat sich scheinbar erledigt. Ich habe von hier http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/COC.hex nochmal das COC.hex geladen und geflasht. Das ist größer! Nun geht es.

Code Auswählen

-rw------- 1 root root 65071 Jan 18 20:35 COC.hex
-rw-r--r-- 1 root root 19818 Jan 15 20:21 COC.hex_old
-rw------- 1 root root 43255 Jan 18 18:11 COC.radio_only.hex

chris1284 · 18 Januar 2014, 22:00:05

und noch eine Info falls es interessiert:

Ich habe bei Busware angefragt ob es die Kernelpatches und das Busware-Image auch in der aktuellen Rasbian Version geben wird.
Folgende erfreuliche Rückmeldung habe ich erhalten:

ZitatDie Komponenten RTC und EEPROM werden mittlerweile vom Rasbian direkt unterstützt, sodass keine Patches nötig sind.
Die Kommunikation mit dem Co-Prozessor läuft seriell, nach setzen der beschriebenen GPIOs.

gerade geschaut... Leider läufts bei mir noch nicht mit der RTC und dem EEPROM. Ich muss "Die Kommunikation mit dem Co-Prozessor läuft seriell, nach setzen der beschriebenen GPIOs." noch machen aber wie?
Jemand da mit dem nötigen wissen`?

chris1284 · 18 Januar 2014, 22:44:57

Und auch hierzu direkt Rückmeldung von Busware

ZitatRTC
empty or delete /etc/modprobe.d/raspi-blacklist.conf (habe bei mir nur diese #blacklist spi-bcm2708 #blacklist i2c-bcm2708 auskommentiert)

modprobe i2c-bcm2708
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
hwclock

Funktioniert. Vielen Dank an noch einmal an Busware (Hr. Tostmann).

Waldmensch · 20 Januar 2014, 08:50:15

Zumindest für die RTC kann ich die Funktion, nach Anleitung der letzten beiden Beiträge (Danke dafür), bestätigen. OneWire habe ich mangels Anwendungsfall noch nicht getestet.

chris1284 · 24 Januar 2014, 09:37:28

1-Wire habe ich nun getestet, funktioniert (mit einem Temp-Sensor).
Mit

Code Auswählen

define OWio OWX <NameDesCOC> und einem

Code Auswählen

get OWio devices
hinterher wird der Sensor direkt erkannt und ausgelesen. Wie in einigen Anleitungen zu COC und 1-Wire beschrieben die Radio-Only Firmware zu flashen und den OWServer zu installieren scheint nicht notwendig zu sein.

eldrik · 24 Januar 2014, 10:01:58

Zitat von: chris1284 am 24 Januar 2014, 09:37:28
Wie in einigen Anleitungen zu COC und 1-Wire beschrieben die Radio-Only Firmware zu flashen und den OWServer zu installieren scheint nicht notwendig zu sein.

Das war meines Verständnisses nach bisher notwendig, da die 1Wire Benutzung direkt über COC Firmware bei mehreren Sensoren nicht zuverlässig/stabil genug war, der Test mit einem Sensor ist wahrscheinlich kein Garant dafür, dass dies Problem nun auch entschärft ist

Greetz
Eldrik

chris1284 · 24 Januar 2014, 10:20:42

OK, und ich dachte dies wäre ein allgemeines Problem des COC und wäre nur mit dem hier im Forum beschriebenen Filternetzwerkes zu beheben http://forum.fhem.de/index.php/topic,10426.msg64924.html#msg64924 oder bezieht sich dies ausschließlich auf 1-Wire Netze über weite Strecken. Ich habe noch 4 andere Sensoren. Kann ich ja mal testen. Außerdem hatte ich irgendwo noch etwas von einer 10 Sensoren-Beschränkung gelesen, finde ich jedoch nicht wieder...