USB-Dreckskram... Erfahrungswerte CUNO?

[Guest]

Originally posted by: <email address deleted>

Hi.

USB und Linux, das ist ungefähr so spaßig wie Videoschnitt mit Linux. Es klappt auf Anhieb
mit dem ersten kleinen Projekt, aber wenn man es richtig nutzen will, näßt es sich unterwegs
ein, spielt Trotzkopf und ist in den besten Zeiten ein latenter Ausfall der auf seine Chance
wartet, richtig Ärger zu machen. Letzteres habe ich nun wieder[1], vielleicht hätte ich den
Verlust der Präsenz des 7-Port-USB-Hubs (powered) einfach hinnehmen sollen, aber seit dem Re-
boot, der zwar nun wieder Geräte am Hub zeigt, dafür aber CUL zum zickigen Satensbraten mal
wieder hat mutieren lassen, habe ich nun die Nase voll.

USB und Linux ist ein Minenfeld das ich nun loswerden will. Und da CUL hier der zickigste
Akteur ist, ich aktuell weder vorbereitete Mittel (== Laptop nicht dabei) noch Lust habe, das
kleine Mistding mal wieder kompromißbereit zu flashen (ein beherzter Flash behob bislang dies
plötzliche auftretende Fehlverhalten --- aber alle paar Monate Flashen ist nur eines, nämlich
indiskutabel für einen Wirkbetrieb, habe ich mittlerweile schlicht keine Zeit mehr zu) und mein
CUN nun schon gefühlt jahrelang einfach funktioniert: wie sind denn die Erfahrungen mit CUNO?

Ich hätte ja lieber noch 'n CUN erstanden, zumal mir ein CUNO mit Gehäuse recht teuer vorkommt,
aber was nicht ist, ist halt nicht.

Fragen also an die CUNO-Nutzer (da ich die Entwicklung nur mit halbem Ohr verfolgte):

  - Läuft CUNO über Monate hinweg stabil, auch bei wiederholtem Aus- und Wiedereinschalten?
  - Kann man den 1Wire-Port auf dem CUNO für DS-Temperatursensoren (Phantomspeisung) in FHEM
    schon nutzen?
  - Welche PoE-Möglichkeiten gibt's für CUNO, insbesondere, da im Shop da nur "ohne" anzuwählen
    ist? Nutzt das schon wer? Mit würde ja ein Injection-Set reichen, da ich keine PoE-fähigen
    Switche habe, ein Kabel aber besser ist als zwei

MfG,
-kai


[1] Endlosschleife (ja, altes FHEM; Update nicht möglich, da erst Module portiert werden müssten):

2011.06.13 12:34:11 0: Server started (version =VERS= from =DATE= ($Id: fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 2756)
2011.06.13 12:34:11 3: CUN: K51324242 -89.5
2011.06.13 12:34:25 3: CUL: K21454345 -81
2011.06.13 12:34:25 3: CUL: ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:25 3: CUL: unknown message ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:37 2: FS20 set Flur_LED on
2011.06.13 12:34:38 2: FS20 set TV_LED off
2011.06.13 12:34:39 2: FS20 set Flur_LED off
2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:56 3: CUN: T320200AA00 -50
2011.06.13 12:34:59 3: CUL: K11292245 -68
2011.06.13 12:34:59 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:59 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:59 3: CUL: ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:34:59 3: CUL: unknown message ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:35:10 3: CUL: K41876258 -50.5
2011.06.13 12:35:10 3: CUN: K41876258 -88.5
2011.06.13 12:35:11 3: CUN version => V 1.31.4 CUN
2011.06.13 12:35:11 3: Please define CUL433 first
2011.06.13 12:35:17 1: /dev/busware_cul disconnected, waiting to reappear
2011.06.13 12:35:22 3: CUL version => No answer
Select error -1 / Bad file descriptor

2011.06.13 12:36:12 0: Server started (version =VERS= from =DATE= ($Id: fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 2820)
2011.06.13 12:36:32 3: CUL: K71277250 -79
2011.06.13 12:36:32 3: CUL: ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:32 3: CUL: unknown message ? (K is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:37 2: FS20 set Flur_LED on
2011.06.13 12:36:38 2: FS20 set TV_LED off
2011.06.13 12:36:39 2: FS20 set Flur_LED off
2011.06.13 12:36:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:39 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:52 3: CUN: T320200AA00 -49
2011.06.13 12:36:56 3: CUL: K61409245 -91
2011.06.13 12:36:56 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:56 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
2011.06.13 12:36:56 3: CUN: K61409245 -51.5
2011.06.13 12:36:58 3: CUL: K31699327 -89
2011.06.13 12:36:58 3: CUN: K31699327 -58
2011.06.13 12:37:05 3: CUN: K51324242 -88.5
2011.06.13 12:37:11 3: CUN version => V 1.31.4 CUN
2011.06.13 12:37:11 3: Please define CUL433 first
2011.06.13 12:37:14 1: /dev/busware_cul disconnected, waiting to reappear
2011.06.13 12:37:19 3: CUL version => No answer
Select error -1 / Bad file descriptor

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

[Guest]

Originally posted by: <email address deleted>

Hallo Kai,

ich setze CUNO seit der Prototyp-Phase ein, mit PoE-Speisung.
Funktioniert super. Ich hab auch einen Injektor, gabs irgendwo für
15,-€. Wichtig ist, dass er volle 48V gemäß PoE-Standard macht.

Zur OneWire Frage:
Ich habe den OneWire Teil der CUNO Firmware geschrieben. Da es dazu noch
keine FHEM-Entsprechnung gibt, war ein einfacher Ansatz unser Ziel:
Für die DS-OneWire Sensoren gibt es eine HMS-Emulation, so dass FHEM am
CUNO HMS-Sensoren "sieht" aber tatsächlich DS-Sensoren dran hängen.
Kann man per RAW Befehl am CUNO einschalten. Funktioniert auch seit
Monaten stabil. Phantom ist nicht nötig, da CUNO durchaus eine 3V
Speisung des OneWire Busses macht (soweit ich mich recht erinner).

Ethernet-Konfig ist wohl extrem Switch abhängig. Bei vielen geht DHCP
nicht (bei mir auch nicht) aber wenn man die IP einkonfiguriert, ist
alles wunderbar. Bei manchen geht DHCP aber durchaus gut.

Ich hab dann noch Add-Ons wie IRDA-Empfang mit dran gebastelt, dass hat
aber manchmal Timing-Probleme mit FHTs, da sind wir noch dran.

Hoffe das hilft.

Gruß,
Olaf

Am 13.06.2011 13:13, schrieb Kai 'wusel' Siering:
> Hi.
>
> USB und Linux, das ist ungefähr so spaßig wie Videoschnitt mit Linux. Es
> klappt auf Anhieb
> mit dem ersten kleinen Projekt, aber wenn man es richtig nutzen will,
> näßt es sich unterwegs
> ein, spielt Trotzkopf und ist in den besten Zeiten ein latenter Ausfall
> der auf seine Chance
> wartet, richtig Ärger zu machen. Letzteres habe ich nun wieder[1],
> vielleicht hätte ich den
> Verlust der Präsenz des 7-Port-USB-Hubs (powered) einfach hinnehmen
> sollen, aber seit dem Re-
> boot, der zwar nun wieder Geräte am Hub zeigt, dafür aber CUL zum
> zickigen Satensbraten mal
> wieder hat mutieren lassen, habe ich nun die Nase voll.
>
> USB und Linux ist ein Minenfeld das ich nun loswerden will. Und da CUL
> hier der zickigste
> Akteur ist, ich aktuell weder vorbereitete Mittel (== Laptop nicht
> dabei) noch Lust habe, das
> kleine Mistding mal wieder kompromißbereit zu flashen (ein beherzter
> Flash behob bislang dies
> plötzliche auftretende Fehlverhalten --- aber alle paar Monate Flashen
> ist nur eines, nämlich
> indiskutabel für einen Wirkbetrieb, habe ich mittlerweile schlicht keine
> Zeit mehr zu) und mein
> CUN nun schon gefühlt jahrelang einfach funktioniert: wie sind denn die
> Erfahrungen mit CUNO?
>
> Ich hätte ja lieber noch 'n CUN erstanden, zumal mir ein CUNO mit
> Gehäuse recht teuer vorkommt,
> aber was nicht ist, ist halt nicht.
>
> Fragen also an die CUNO-Nutzer (da ich die Entwicklung nur mit halbem
> Ohr verfolgte):
>
> - Läuft CUNO über Monate hinweg stabil, auch bei wiederholtem Aus- und
> Wiedereinschalten?
> - Kann man den 1Wire-Port auf dem CUNO für DS-Temperatursensoren
> (Phantomspeisung) in FHEM
> schon nutzen?
> - Welche PoE-Möglichkeiten gibt's für CUNO, insbesondere, da im Shop da
> nur "ohne" anzuwählen
> ist? Nutzt das schon wer? Mit würde ja ein Injection-Set reichen, da ich
> keine PoE-fähigen
> Switche habe, ein Kabel aber besser ist als zwei
>
> MfG,
> -kai
>
>
> [1] Endlosschleife (ja, altes FHEM; Update nicht möglich, da erst Module
> portiert werden müssten):
>
> 2011.06.13 12:34:11 0: Server started (version =VERS= from =DATE= ($Id:
> fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 2756)
> 2011.06.13 12:34:11 3: CUN: K51324242 -89.5
> 2011.06.13 12:34:25 3: CUL: K21454345 -81
> 2011.06.13 12:34:25 3: CUL: ? (K is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:34:25 3: CUL: unknown message ? (K is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:34:37 2: FS20 set Flur_LED on
> 2011.06.13 12:34:38 2: FS20 set TV_LED off
> 2011.06.13 12:34:39 2: FS20 set Flur_LED off
> 2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:34:56 3: CUN: T320200AA00 -50
> 2011.06.13 12:34:59 3: CUL: K11292245 -68
> 2011.06.13 12:34:59 3: CUL: ? (? is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:34:59 3: CUL: unknown message ? (? is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:34:59 3: CUL: ? (K is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:34:59 3: CUL: unknown message ? (K is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:35:10 3: CUL: K41876258 -50.5
> 2011.06.13 12:35:10 3: CUN: K41876258 -88.5
> 2011.06.13 12:35:11 3: CUN version => V 1.31.4 CUN
> 2011.06.13 12:35:11 3: Please define CUL433 first
> 2011.06.13 12:35:17 1: /dev/busware_cul disconnected, waiting to reappear
> 2011.06.13 12:35:22 3: CUL version => No answer
> Select error -1 / Bad file descriptor
>
> 2011.06.13 12:36:12 0: Server started (version =VERS= from =DATE= ($Id:
> fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 2820)
> 2011.06.13 12:36:32 3: CUL: K71277250 -79
> 2011.06.13 12:36:32 3: CUL: ? (K is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:36:32 3: CUL: unknown message ? (K is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:36:37 2: FS20 set Flur_LED on
> 2011.06.13 12:36:38 2: FS20 set TV_LED off
> 2011.06.13 12:36:39 2: FS20 set Flur_LED off
> 2011.06.13 12:36:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:36:39 3: CUL: unknown message ? (? is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:36:52 3: CUN: T320200AA00 -49
> 2011.06.13 12:36:56 3: CUL: K61409245 -91
> 2011.06.13 12:36:56 3: CUL: ? (? is unknown) Use one of B C F R T V W X
> e l t u x
> 2011.06.13 12:36:56 3: CUL: unknown message ? (? is unknown) Use one of
> B C F R T V W X e l t u x
> 2011.06.13 12:36:56 3: CUN: K61409245 -51.5
> 2011.06.13 12:36:58 3: CUL: K31699327 -89
> 2011.06.13 12:36:58 3: CUN: K31699327 -58
> 2011.06.13 12:37:05 3: CUN: K51324242 -88.5
> 2011.06.13 12:37:11 3: CUN version => V 1.31.4 CUN
> 2011.06.13 12:37:11 3: Please define CUL433 first
> 2011.06.13 12:37:14 1: /dev/busware_cul disconnected, waiting to reappear
> 2011.06.13 12:37:19 3: CUL version => No answer
> Select error -1 / Bad file descriptor
>

--
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager              Tel.  : +49-561-82020-410
DHS - Computertechnik GmbH   Fax.  : +49-561-82020-399
Carlsdorfer Straße 3         E-Mail: O.Droegehorn@dhs-
                                        computertechnik.de
D-34128 Kassel               WEB:    www.dhs-computertechnik.de
------------------------------------------------------------------------

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

[Guest]

Originally posted by: <email address deleted>

> 2011.06.13 12:34:39 2: FS20 set Flur_LED off
> 2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
> 2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x
> 2011.06.13 12:34:39 3: CUL: ? (? is unknown) Use one of B C F R T V W X e l t u x
> 2011.06.13 12:34:39 3: CUL: unknown message ? (? is unknown) Use one of B C F R T V W X e l t u x


Hi Kai,
genau damit habe ich auch das ganze Wochenende verbracht. Mir scheint
langsam, da steckt irgendwo der Wurm drin, wenn schon zwei User das
Problem haben.


LG Jörg

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

[rudolfkoenig]

                                                   

> Mir scheint langsam, da steckt irgendwo der Wurm drin, wenn schon zwei User
> das Problem haben.

Oh, das Problem haben mehr als zwei Leute gehabt, und bisher hat sich
das als
Problem der Linux-Distribution rausgestellt (jedenfalls aus meiner
Standpunkt
heraus), der jede serielle Schnittstelle mit Unsinn wie echo und
Editierfunktionen belegt.

Neuere Linux-Versionen haben auch noch das "Feature" mitgebracht, dass
nach
einem fork() (d.h. nachdem das Programm sich ins Hintergrund
verabschiedet)
alle vorher verstellten Parameter zurueckgestellt werden.

Aus diesem Grund habe ich das Initialisieren beim fhem umgestellt.
Diese
Aenderung ist aber nur in der CVS Verison vorhanden, und deswegen
meine Frage
nach der Version.

Die CVS Version ist mindestens so stabil wie Version 5.0, es wird
langsam Zeit
fuer ein neues Release. Wenn jemand unbedingt noch was da drin haben
will, der
soll sich melden.  HomeMatic ist zwar nicht so ausgereift wie ich es
mir
gewuenscht habe, aber irgendetwas ist immer.

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

[Guest]

Originally posted by: <email address deleted>

> Oh, das Problem haben mehr als zwei Leute gehabt, [...]

Ahaaaa !!! - Und ich habe schon gedacht, dass ich zu blöde bin :-D
Um ehrlich zu sein, habe ich schon Fotos von den CUL's gemacht um sie
heute bei eBay los zu werden.


> Die CVS Version ist mindestens so stabil wie Version 5.0, es wird
> langsam Zeit fuer ein neues Release.

Ja, bitte !!!   )

> Wenn jemand unbedingt noch was da drin haben
> will, der soll sich melden.  HomeMatic ist zwar nicht so ausgereift wie ich es
> mir gewuenscht habe, aber irgendetwas ist immer.

Das kann ja dann noch nachträglich eingebaut werden?

Was meinst Du denn, bis wann Du das Release fertig hast?
Ich möchte nicht drängeln, aber bei mir im Haus funktionieren viele
Dinge gar nicht, oder nicht mehr richtig, da fast alles über FHEM
läuft.


LG Jörg

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

[rudolfkoenig]

                                                   

> Ich möchte nicht drängeln, aber bei mir im Haus funktionieren viele
> Dinge gar nicht, oder nicht mehr richtig, da fast alles über FHEM
> läuft.

Dan draengele auch nicht , sondern verwende die CVS Version, am
besten
einfach ueber das auf dem HomePage hinterlegte Link.

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

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>> Mir scheint langsam, da steckt irgendwo der Wurm drin, wenn schon zwei User
>> das Problem haben.
>
> Oh, das Problem haben mehr als zwei Leute gehabt, und bisher hat sich
> das als Problem der Linux-Distribution rausgestellt (jedenfalls aus meiner
> Standpunkt heraus), der jede serielle Schnittstelle mit Unsinn wie echo und
> Editierfunktionen belegt.

Kann man glauben. Muß man aber nicht.

Hier ist's ein PogoPlug mit Debian, und das Teil tat nun wochenlang ordentlich.
Dann gingen die Geräte am USB-Hub verlustig (USB-Soundkarte und USB2Serial, an
dem der TV hängt) und es wurde unspßig. (Lies: mitten in einem Meeting ruft ein
Kind an und sagt mir, da0 die Wii nicht angeht -- klar, kann se nich', wenn der
TV nicht mehr abgefragt wird, weil der Wii-Eingang am TV über FHEM den FS20-ST
für die Wii einschaltet.) Pfingsten länger da, also mal versucht, das Rätsel zu
lüften. Nach 1 Tag stromlos lassen des USB-Hubs rennt der wieder am PogoPlug --
und CUL bockt, wieder einmal.

Und die Scheiße mit dem sich abmeldenden CUL, die ist nicht neu. Die passiert
nicht-deterministisch einfach irgendwann, und ohne neu flashen (auf gerne die
alte Version) geht da nix. Flashen, dranstöpseln, glücklich sein. Was keine
Lösung ist sondern eine Zumutung, aber das habe ich lange nicht so gesehen, als
ich vor Ort noch Zeit für Bastelleien hatte.

Ich muß dazu sagen, daß ich meinen zweiten 868er CUL nun seit rd. 9 Monaten ab-
solut problemlos an einem DockStar (gleiches ARM-Debian, evtl. anderer Kernel)
in meinem Berliner Appartment laufen habe, da fragt er 4 S555TH ab und läuft
und läuft und läuft -- und hängt aber, abgesehen vom USB-Stick als /dev/sda,
alleine am USB. Hier in Gütersloh hängen noch etliche andere Geräte am Bus, und
damit kommt ganz offensichtlich CUL/die culfw nicht klar und schießt sich über
Zeit ins Knie.

Und die Probleme sind auch nicht auf die ARM-HW zurückzuführen; vorher lief mein
FHEM-Kram auf einem P3, und auch da zeigte CUL schon dieses zickige Verhalten.

Ergo: weg mit Schaden, und CUNO als letzten Versuch. Vielleicht kann ich dann
auch endlich wieder den Plugwise Stick nutzen, denn die beiden kamen sich auch
gerne mal in die Quere Es kann natürlich auch ein "simples" Linux-Treiber-
thema sein ...
-kai

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

[Guest]

Originally posted by: <email address deleted>

Hi,
hier wieder die Frage des noop: Was genau leistet der CUNO?
Wird per LAN ins Netz eingebunden und man steckt am USB-Port den CUL
an? Oder beinhaltet der CUNO bereits die Funktionalitaet des CUL?
In der reference habe ich zum CUN(O) gefunden, dass dieser ueber eine
IP angesprochen wird. Liegt also der Unterschied ausschliesslich in
der Addressierung ueber LAN statt USB?
An anderer Stelle las ich, dass der CUNO nicht immer mit DHCP
klarkommt - wie wuerde man dem guten Stueck denn eine feste IP
verpassen?
Gruessle, Uli

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

[Guest]

Originally posted by: <email address deleted>

UliM wrote:
> Hi,
> hier wieder die Frage des noop: Was genau leistet der CUNO?
                             ^^^^
Um welche no operation geht's?

Ein CUN (und AFAIK also auch der CUNO) ist ein CUL mit angeflanschtem Ethernet.

Den hängst Du also irgendwo hin, wo Du a) Ethernet (nein, keine WLAN-Option
existent) und b) Strom (CUN ist USB-powered) hast und er möglichst gut Deine
FS20-Geräte erreicht. Also z. B. Flur EG oder im OG.

Dein FHEM-Server z. B. im Keller spricht CUN dann einfach per TCP an, anstatt
über USB (der sich nur schwer über ganze Stockwerte funktional verteilen läßt).

Also: CUN = CUL+Ethernet. (CUNO hat noch ein paar Schmankerl mehr.)
-kai

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

[tostmann]

                                                 

Am 13.06.2011 um 16:51 schrieb Kai 'wusel' Siering:

> Also: CUN = CUL+Ethernet.

Um wieder mal was Konstruktives beizutragen:

Im CUL steckt der USB controller im Prozessor und wird per LUFA-Firmware bedient. Durchaus möglich, dass sich dort eine Update lohnen würde ...

Beim CUNO ist eine serielle-USB Bridge (MCP2200) für die Datenkommunikation zuständig. Diese emuliert per CDC ACM eine serielle Verbindung.

Ich bitte bei CUNO als auch CUL zu bedenken, dass diese 8bit Controller mit relativ niedriger Taktfrequenz einsetzen. USB und Ethernet zu bedienen ist mit derartigen Ressourcen möglich aber grenzwertig, daher wurde auch TuxRadio erfunden ...


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

[Guest]

Originally posted by: <email address deleted>

Dirk Tostmann wrote:

> Im CUL steckt der USB controller im Prozessor und wird per LUFA-Firmware bedient.
> Durchaus möglich, dass sich dort eine Update lohnen würde ...

Möglich ist vieles. Die bisherigen Updates haben die chronischen Ausfälle nicht
erledigt.

> Ich bitte bei CUNO als auch CUL zu bedenken, dass diese 8bit Controller mit relativ
> niedriger Taktfrequenz einsetzen. USB und Ethernet zu bedienen ist mit derartigen
> Ressourcen möglich aber grenzwertig, daher wurde auch TuxRadio erfunden ...

Die Frage ist: stellen mehr Geräte am USB für ein einzelnes Gerät einen Unterschied
dar bezüglich des Aufwandes, den Bus zu bedienen? Aber selbst das erklärte nicht,
warum plötzlich und unerwartet CUL rumzuzicken beginnt. Und das gerne wieder; bis-
lang aber für mich zumindest nicht reproduzierbar.
-kai

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

[rudolfkoenig]

                                                   

> >Im CUL steckt der USB controller im Prozessor und wird per LUFA-Firmware bedient.
> >Durchaus möglich, dass sich dort eine Update lohnen würde ...
>
> Möglich ist vieles. Die bisherigen Updates haben die chronischen Ausfälle nicht
> erledigt.

Mit Update meint Herr Tostmann "erst LUFA update im culfw" und dann "culfw
update im CUL".


> Aber selbst das erklärte nicht, warum plötzlich und unerwartet CUL
> rumzuzicken beginnt.

Waere interessant zu wissen, ob solche herumzickende CULs alleine an einem
anderen "richtigen" Rechner immer noch Probleme bereiten. Evtl. ist das Problem
auf der anderen Seite zu suchen.

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

[Guest]

Originally posted by: <email address deleted>

Rudolf Koenig wrote:
>>> Im CUL steckt der USB controller im Prozessor und wird per LUFA-Firmware bedient.
>>> Durchaus möglich, dass sich dort eine Update lohnen würde ...
>> Möglich ist vieles. Die bisherigen Updates haben die chronischen Ausfälle nicht
>> erledigt.
>
> Mit Update meint Herr Tostmann "erst LUFA update im culfw" und dann "culfw
> update im CUL".

Ah. Vom Aufwand her ... rechnet sich ein funktionierender CUNO dann mehr

>> Aber selbst das erklärte nicht, warum plötzlich und unerwartet CUL
>> rumzuzicken beginnt.
>
> Waere interessant zu wissen, ob solche herumzickende CULs alleine an einem
> anderen "richtigen" Rechner immer noch Probleme bereiten. Evtl. ist das Problem
> auf der anderen Seite zu suchen.

Nun, zumindest wenn meine CULs sich tot stellten, half auch ein andererer Rechner
nix. (Andere HW mit einem ggf. anderen Linux, that is.) Ich flashe das Mistding
jetzt, dfu-programmer gibt's ja zum Glück auch für ARM, also hoffentlich nicht so
dramatisch wie gedacht.
-kai

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

[Guest]

Originally posted by: <email address deleted>

FTR, und zur Theorie, die Serverhardware/das Server-OS wären veantworlich: Drecksteil abgezogen, CUL_HM.hex geflasht, drangesteckt, festgestellt, daß es nun ein "CUL_HM" ist statt "CUL868", udev-Regeln geändert, im board.h nachgelesen, daß CUL V2 mit HM dann kein FHT kann, geflucht, wieder runtergerannt, neu geflasht, drangesteckt, FHEM restartet (wg. uninitialized value-Meldungen nach jeder empfangenen CUL-Nachricht), und siehe, CUL rennt einfach, wie er soll. Nix am OS geändert ...

2011.06.13 20:34:11 0: Server started (version =VERS= from =DATE= ($Id: fhem.pl,v 1.97 2010/01/01 15:18:09 rudolfkoenig Exp $), pid 17602)
2011.06.13 20:34:23 3: CUN: T320200AA00 -48
2011.06.13 20:34:37 2: FS20 set Flur_LED on
2011.06.13 20:34:38 2: FS20 set TV_LED off
2011.06.13 20:34:39 2: FS20 set Flur_LED off
2011.06.13 20:34:39 3: CUN: F1EBE0211 -84.5
2011.06.13 20:34:39 2: FS20 Flur_LED on
2011.06.13 20:34:40 3: CUN: F1EBE0000 -85
2011.06.13 20:34:40 2: FS20 TV_FMS off
2011.06.13 20:34:40 2: FS20 TV_LED off
2011.06.13 20:34:40 3: CUN: F1EBE0200 -84.5
2011.06.13 20:34:40 2: FS20 Flur_LED off
2011.06.13 20:35:10 3: CUL: E020897C6831C002200 -39.5
2011.06.13 20:35:10 3: CUL_EM TerSrv_EM: CUM_DAY: 12.199 CUM: 1934.278 COST: 0.00
2011.06.13 20:35:11 3: CUN version => V 1.31.4 CUN
2011.06.13 20:35:11 3: Please define CUL433 first
2011.06.13 20:35:11 3: CUL version => V 1.40 CUL868
2011.06.13 20:35:12 1: WSx got WS3600 message: WS3600 WS3600 Ti 24.1
2011.06.13 20:35:12 1: WSx WS3600 message parsed as: devicename WS3600 type Ti notifyvalue temperature
[...]

Und wieder insgesamt >1 Stunde sinnlos verbraten. Fsck.
-kai

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

[rudolfkoenig]

                                                   

On Mon, Jun 13, 2011 at 08:44:11PM +0200, Kai 'wusel' Siering wrote:
> FTR, und zur Theorie, die Serverhardware/das Server-OS wären veantworlich:

Ich hab auch was fuer das Protokoll: ich hatte so ein Problem noch nicht, mein
Haupt-CUL und RFR haben beide Version 1.37 (etwas ueber ein Jahr alt). Das RFR
hat ein uptime von knapp 274 Tagen, das Haupt-CUL nur 141 Tage wg. Neustart des
Rechners.

Btw.: Vor dem flashen das naechste mal bitte zuerst ein Factory-Reset (e)
probieren.

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