Etliche Fragen
Gerhard Pfeffer
war jetzt lange Zeit weg vom Fenster und was muss ich feststellen, als
ich zurück komme? Es hat sich unglaublich viel getan. :-)
Nachdem ich nicht am aktuellen Stand bin, wollte ich hier einmal ein
paar Fragen stellen, auf die ich auf "die Schnelle" keine passenden
Antworten gefunden habe:
1) Habe immer noch mein FHZ1300 daheim und ständig gibt es Probleme
mit Empfangen/Senden der Zentraleinheit. Entweder das Gerät nimmt
keine Befehle an - erst wenn ich eine gewisse Zeit warte, können
wieder Befehle von Fernbedienungen angenommen werden oder aber ich
führe einen Befehl über das Webif aus, danach können auch wieder die
FBs mit der FHZ plaudern. Keine Ahnung woran es liegt. Des weiteren
habe ich auch immer wieder Probleme beim Senden an FS20-Geräte. Einmal
funktionierts, ein anderes Mal nicht... Ich komm nicht dahinter, woran
es liegt. Die Haupteinheit steht ständig am selben Platz und andere
Funkgeräte (zB DECT-Telefone) habe ich nicht (nur eine eigenständige
Wetterstation mit Aussensensor und WLAN daheim). Rein gefühlsmäßig ist
unter Tags schlechter als in der Nacht. Vielleicht hat jemand eine
Idee, woran es jeweils liegen könnte bzw. was man dagegen könnte.
2) Ich habe von dem CUL/CUN in den Threads gelesen und mich auch auf
der busware.de-Seite umgesehen. Scheint recht nett zu sein - vorallem,
da viel mehr möglich ist. Aber wie sieht es denn nun im Detail aus?
a) Hat das Teil eine bessere Empfangs-/Sendeleistung als das original
FHZ? Vielleicht könnte ich damit auch die in Punkt 1 genannten
Probleme in den Griff kriegen?
b) Wie sieht es mit dem Einsatz mehrerer solcher Teile aus? Mich würde
neben einem CUL noch zumindest ein weiteres CUN interessieren (sind
die überhaupt kombinierbar?). Ist ein Clone-Betrieb möglich? Also das
beide Geräte immer die gleichen Signale aussenden (unterschiedlicher
Standort), um auch sicher jede Ecke in der Wohnung abzudecken? Oder
könnte es (falls es überhaupt möglich ist), zu Problemen bei
Sendebefehlen wie 'toggle' kommen, da ein Aktor diese dann auch
zweimal ausführen würden?
c) Sehr gerne würde gemeinsam mit den CUL natürlich auch mehrere
S555TH verwenden. Gibt es eine maximale Anzahl an Geräten, die ich
hier nutzen kann?
d) Was sind die Vor-/Nachteile zwischen CUL/CUNs?
3) Gibt es bekannte Nachteile des CULs gegenüber dem FHZ?
4) Hab auch noch gesehen, dass 1-wire-Systeme unterstützt werden. Gibt
es da bestimmte Systeme? Wie funktioniert die Ansteuerung und was kann
man machen?
So, dass war es fürs Erste. Würde mich freuen, wenn Ihr euch mir
erbarmen könntet um mich ein wenig am aktuellen Stand der Dinge zu
bringen. ;-)
Thx a lot!
Greetz,
Gerhard
Joachim
Hi Gerhard,
ich steige gerade in das Thema ein mit CUL, FHT 80b, FHEM auf
synology NAS und S555TH.
S555TH machen nur 8 Sinn, da man nur max. 8 Adressen einstellen kann.
Habe mein CUL mit ner Antenne (+20€) gekauft, wollte da kein Risiko
eingehen.
Gruss Joachim
Michael Röhrig
ich habe bei mir die Kombination FHT80b und CUN laufen.
Der CUN h�ngt im EG, die FHT's im OG, die Decke ist aus Beton, l�uft
ohne Probleme, ich habe aber auch zur Sicherheit die Version mit Antenne
(RP-SMA dreh- und neigbar) gekauft...
klappt super...
Viele Gr��e aus K�ln
Michael
Gerhard Pfeffer schrieb:
> Hi folks,
>
> war jetzt lange Zeit weg vom Fenster und was muss ich feststellen, als
> ich zur�ck komme? Es hat sich unglaublich viel getan. :-)
> Nachdem ich nicht am aktuellen Stand bin, wollte ich hier einmal ein
> paar Fragen stellen, auf die ich auf "die Schnelle" keine passenden
> Antworten gefunden habe:
>
> 1) Habe immer noch mein FHZ1300 daheim und st�ndig gibt es Probleme
> mit Empfangen/Senden der Zentraleinheit. Entweder das Ger�t nimmt
> keine Befehle an - erst wenn ich eine gewisse Zeit warte, k�nnen
> wieder Befehle von Fernbedienungen angenommen werden oder aber ich
> f�hre einen Befehl �ber das Webif aus, danach k�nnen auch wieder die
> FBs mit der FHZ plaudern. Keine Ahnung woran es liegt. Des weiteren
> habe ich auch immer wieder Probleme beim Senden an FS20-Ger�te. Einmal
> funktionierts, ein anderes Mal nicht... Ich komm nicht dahinter, woran
> es liegt. Die Haupteinheit steht st�ndig am selben Platz und andere
> Funkger�te (zB DECT-Telefone) habe ich nicht (nur eine eigenst�ndige
> Wetterstation mit Aussensensor und WLAN daheim). Rein gef�hlsm��ig ist
> unter Tags schlechter als in der Nacht. Vielleicht hat jemand eine
> Idee, woran es jeweils liegen k�nnte bzw. was man dagegen k�nnte.
>
> 2) Ich habe von dem CUL/CUN in den Threads gelesen und mich auch auf
> der busware.de-Seite umgesehen. Scheint recht nett zu sein - vorallem,
> da viel mehr m�glich ist. Aber wie sieht es denn nun im Detail aus?
> a) Hat das Teil eine bessere Empfangs-/Sendeleistung als das original
> FHZ? Vielleicht k�nnte ich damit auch die in Punkt 1 genannten
> Probleme in den Griff kriegen?
> b) Wie sieht es mit dem Einsatz mehrerer solcher Teile aus? Mich w�rde
> neben einem CUL noch zumindest ein weiteres CUN interessieren (sind
> die �berhaupt kombinierbar?). Ist ein Clone-Betrieb m�glich? Also das
> beide Ger�te immer die gleichen Signale aussenden (unterschiedlicher
> Standort), um auch sicher jede Ecke in der Wohnung abzudecken? Oder
> k�nnte es (falls es �berhaupt m�glich ist), zu Problemen bei
> Sendebefehlen wie 'toggle' kommen, da ein Aktor diese dann auch
> zweimal ausf�hren w�rden?
> c) Sehr gerne w�rde gemeinsam mit den CUL nat�rlich auch mehrere
> S555TH verwenden. Gibt es eine maximale Anzahl an Ger�ten, die ich
> hier nutzen kann?
> d) Was sind die Vor-/Nachteile zwischen CUL/CUNs?
>
>
> 3) Gibt es bekannte Nachteile des CULs gegen�ber dem FHZ?
>
> 4) Hab auch noch gesehen, dass 1-wire-Systeme unterst�tzt werden. Gibt
> es da bestimmte Systeme? Wie funktioniert die Ansteuerung und was kann
> man machen?
>
> So, dass war es f�rs Erste. W�rde mich freuen, wenn Ihr euch mir
> erbarmen k�nntet um mich ein wenig am aktuellen Stand der Dinge zu
> bringen. ;-)
>
> Thx a lot!
>
> Greetz,
> Gerhard
>
> --
>
> You received this message because you are subscribed to the Google Groups "FHEM users" group.
> To post to this group, send email to fhem-...@googlegroups.com.
> To unsubscribe from this group, send email to fhem-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
>
>
>
Rudolf Koenig
> mit Empfangen/Senden der Zentraleinheit. Entweder das Ger�t nimmt
> keine Befehle an - erst wenn ich eine gewisse Zeit warte, k�nnen
> wieder Befehle von Fernbedienungen angenommen werden oder aber ich
> FBs mit der FHZ plaudern.
Das klingt entweder nach dem OS Fehler (wie Peter fuer den kernel 2.6.31.5 es
berichtet hat), oder etwas blockierendes im fhem. Eventuell kann man es mit
"attr global verbose 5" eingrenzen.
> a) Hat das Teil eine bessere Empfangs-/Sendeleistung als das original
> FHZ? Vielleicht k�nnte ich damit auch die in Punkt 1 genannten
> Probleme in den Griff kriegen?
Nach meinem Gefuehl ist Empfang vergleichbar bis leicht schlechter, senden
besser. Und das bei der default Einstellung. Senden kann man eine Stufe noch
verstaerken.
> Ist ein Clone-Betrieb m�glich? Also das beide Ger�te immer die gleichen
> Signale aussenden (unterschiedlicher Standort), um auch sicher jede Ecke in
> der Wohnung abzudecken?
Das macht wenig Sinn, da man nicht beide Signale aufs usec genau steuern kann,
und damit stoeren die sich ziemlich sicher gegenseitig. Parallel-Empfang ist
aber moeglich, und auch sowas wie CUL_RFR, um Geraete RF-guenstig platzieren zu
kooennen.
> c) Sehr gerne w�rde gemeinsam mit den CUL nat�rlich auch mehrere
> S555TH verwenden. Gibt es eine maximale Anzahl an Ger�ten, die ich
> hier nutzen kann?
Ja, wie schon geschrieben, 8. Wenn man sicherstellen kann, dass
unterschiedliche CUL's nicht die gleichen S555TH's empfangen dann #CUL*8.
Manche experimentieren mit ID+Signalstaerke in CUL_WS, aber ich glaube nicht
daran...
> d) Was sind die Vor-/Nachteile zwischen CUL/CUNs?
CUL: Billiger/kleiner
CUN: hat alle culfw featuers auf einmal onboard + Ethernet + local logging :)
> 3) Gibt es bekannte Nachteile des CULs gegen�ber dem FHZ?
Etwas schlechteren Empfang fuer KS300
Gerhard Pfeffer
vielen Dank für die Antworten. Wird bestimmt zu meiner Entscheidung
beitragen. ;-)
@Rudi:
> > 1) Habe immer noch mein FHZ1300 daheim und st ndig gibt es Probleme
> > mit Empfangen/Senden der Zentraleinheit. Entweder das Ger t nimmt
> > keine Befehle an - erst wenn ich eine gewisse Zeit warte, k nnen
> > wieder Befehle von Fernbedienungen angenommen werden oder aber ich
> > f hre einen Befehl ber das Webif aus, danach k nnen auch wieder die
> > FBs mit der FHZ plaudern.
>
> Das klingt entweder nach dem OS Fehler (wie Peter fuer den kernel 2.6.31.5 es
> berichtet hat), oder etwas blockierendes im fhem. Eventuell kann man es mit
> "attr global verbose 5" eingrenzen.
Der OS-Fehler ist vermutlich auszuschließen, da ich auf dem Rechner
einen 2.6.26er installiert habe.
Bezüglich dem Log hab ich jetzt einmal nachgesehen und da gibt es
ständig 'Unparsed'-Nachrichten:
### cut begin ###
2009.12.28 09:36:02 4: FHZ/RAW: 810c (Unparsed: )
2009.12.28 09:36:03 4: FHZ/RAW: 04930909a0010a234b006701 (Unparsed:
810c)
2009.12.28 09:36:03 5: FHZ dispatch 810c04930909a0010a234b006701
2009.12.28 09:36:03 4: FHT hr_00 ack: 1
2009.12.28 09:36:03 5: Triggering hr_00 (1 changes)
2009.12.28 09:36:03 5: hr_00 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:36:03 5: hr_00 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:36:03 4: FHZ/RAW: 810c04c60909a0010a237e006701
(Unparsed: )
2009.12.28 09:36:03 5: FHZ dispatch 810c04c60909a0010a237e006701
2009.12.28 09:36:03 4: FHT hr_00 end-xmit: 1
2009.12.28 09:36:03 5: Triggering hr_00 (1 changes)
2009.12.28 09:36:03 5: hr_00 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:36:03 5: hr_00 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:36:25 5: exec at command do_timesync
2009.12.28 09:36:25 5: Cmd: >set FHZ time<
2009.12.28 09:36:25 2: FHZ set FHZ time
2009.12.28 09:36:25 5: Sending 810ac9c2020161090c1c0924
2009.12.28 09:36:25 5: Triggering FHZ (1 changes)
2009.12.28 09:36:25 5: FHZ trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:36:25 5: FHZ trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:36:25 5: redefine at command do_timesync as +*00:01:00
set FHZ time
2009.12.28 09:36:53 4: FHZ/RAW: 81 (Unparsed: )
2009.12.28 09:36:53 4: FHZ/RAW: 0c04270909a00155600000a619 (Unparsed:
81)
2009.12.28 09:36:53 5: FHZ dispatch 810c04270909a00155600000a619
2009.12.28 09:36:53 4: FHT hr_01 actuator: 10%
2009.12.28 09:36:53 5: Triggering hr_01 (1 changes)
2009.12.28 09:36:53 5: hr_01 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:36:53 5: hr_01 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:37:03 4: FHZ/RAW: 81 (Unparsed: )
2009.12.28 09:37:03 4: FHZ/RAW: 0c04960909a0010a230000a610 (Unparsed:
81)
2009.12.28 09:37:03 5: FHZ dispatch 810c04960909a0010a230000a610
2009.12.28 09:37:03 4: FHT hr_00 actuator: 6%
2009.12.28 09:37:03 5: Triggering hr_00 (1 changes)
2009.12.28 09:37:03 5: hr_00 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:37:03 5: hr_00 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:37:25 5: exec at command do_timesync
2009.12.28 09:37:25 5: Cmd: >set FHZ time<
2009.12.28 09:37:25 2: FHZ set FHZ time
2009.12.28 09:37:25 5: Sending 810ac9c3020161090c1c0925
2009.12.28 09:37:25 5: Triggering FHZ (1 changes)
2009.12.28 09:37:25 5: FHZ trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:37:25 5: FHZ trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:37:25 5: redefine at command do_timesync as +*00:01:00
set FHZ time
2009.12.28 09:38:25 5: exec at command do_timesync
2009.12.28 09:38:25 5: Cmd: >set FHZ time<
2009.12.28 09:38:25 2: FHZ set FHZ time
2009.12.28 09:38:25 5: Sending 810ac9c4020161090c1c0926
2009.12.28 09:38:25 5: Triggering FHZ (1 changes)
2009.12.28 09:38:25 5: FHZ trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:38:25 5: FHZ trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:38:25 5: redefine at command do_timesync as +*00:01:00
set FHZ time
2009.12.28 09:38:48 4: FHZ/RAW: 810c04a60909a0 (Unparsed: )
2009.12.28 09:38:48 4: FHZ/RAW: 01556000002618 (Unparsed:
810c04a60909a0)
2009.12.28 09:38:48 5: FHZ dispatch 810c04a60909a001556000002618
2009.12.28 09:38:48 4: FHT hr_01 actuator: 9%
2009.12.28 09:38:48 5: Triggering hr_01 (1 changes)
2009.12.28 09:38:48 5: hr_01 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:38:48 5: hr_01 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:38:59 4: FHZ/RAW: 810c04960909a0010a230000a610
(Unparsed: )
2009.12.28 09:38:59 5: FHZ dispatch 810c04960909a0010a230000a610
2009.12.28 09:38:59 4: FHT hr_00 actuator: 6%
2009.12.28 09:38:59 5: Triggering hr_00 (1 changes)
2009.12.28 09:38:59 5: hr_00 trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:38:59 5: hr_00 trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:39:25 5: exec at command do_timesync
2009.12.28 09:39:25 5: Cmd: >set FHZ time<
2009.12.28 09:39:25 2: FHZ set FHZ time
2009.12.28 09:39:25 5: Sending 810ac9c5020161090c1c0927
2009.12.28 09:39:25 5: Triggering FHZ (1 changes)
2009.12.28 09:39:25 5: FHZ trigger: Checking bm_00log for notify
.
.
.
2009.12.28 09:39:25 5: FHZ trigger: Checking n_ta_02_bn3 for notify
2009.12.28 09:39:25 5: redefine at command do_timesync as +*00:01:00
set FHZ time
### cut end ###
Ungewöhnlicheres kann ich auch zu anderen Zeiten nicht feststellen.
>
> > a) Hat das Teil eine bessere Empfangs-/Sendeleistung als das original
> > FHZ? Vielleicht k nnte ich damit auch die in Punkt 1 genannten
> > Probleme in den Griff kriegen?
>
> Nach meinem Gefuehl ist Empfang vergleichbar bis leicht schlechter, senden
> besser. Und das bei der default Einstellung. Senden kann man eine Stufe noch
> verstaerken.
>
Mit welcher Art von Antenne hast du diese Erfahrungen gemacht?
> > d) Was sind die Vor-/Nachteile zwischen CUL/CUNs?
>
> CUL: Billiger/kleiner
> CUN: hat alle culfw featuers auf einmal onboard + Ethernet + local logging :)
Was darf man sich unter dem 'local logging' bei den CUNs vorstellen?
RAW-Messages von den Sende-/Empfangsvorgängen?
Thx a lot! :-)
Greetz,
Gerhard
Rudolf Koenig
> st�ndig 'Unparsed'-Nachrichten:
Das ist normal, das sind die noch nicht verarbeiteten Daten aus der vorherigen Nachricht.
> ### cut begin ###
Ich sehe nichts auf Anhieb. Was ich mit "logging" gemeint habe ist: "Ich habe XY
gedrueckt, aber es hat Z Sekunden gebraucht bis es im Log auftaucht, siehe
Log-Ausschnitt +- 10 Zeilen um den Zeitpunkt"
> Mit welcher Art von Antenne hast du diese Erfahrungen gemacht?
Siehe http://www.koeniglich.de/fhem/commandref.html#CUL_RFR
> RAW-Messages von den Sende-/Empfangsvorg�ngen?
Raw, nur Empfang.
Gerhard Pfeffer
> gedrueckt, aber es hat Z Sekunden gebraucht bis es im Log auftaucht, siehe
> Log-Ausschnitt +- 10 Zeilen um den Zeitpunkt"
Ok, bin zur Zeit nur kaum daheim. Aber werde ich die Tage einmal
machen.
>
> > Mit welcher Art von Antenne hast du diese Erfahrungen gemacht?
Also im Prinzip tendiere ich mehr zum CUN, dürfte sich über kurz oder
lang mehr damit machen lassen. :-)
Was ich noch nicht ganz heraus lesen konnte... Das CUN ist doch
genauso wie das CUL über USB verwendbar. Oder ist das USB-Interface
'nur' für Firmware-Upload und Stromzufuhr?
Prozessoren gibt es auch zwei (andere) als bei der CUL-Variante. Wird
wohl (unter anderem) mit dem Ethernet-IF zu tun haben.
Greetz,
Gerhard
Kai 'wusel' Siering
Gerhard Pfeffer wrote:
> Also im Prinzip tendiere ich mehr zum CUN, d�rfte sich �ber kurz oder
> lang mehr damit machen lassen. :-)
Im Prinzip schon, ja. Nettes Teil, leider mit einem nennenswerten
finanziellen Offset zum CUL (insbesondere mit Geh�use); aber irgend-
was ist ja immer ;)
> Was ich noch nicht ganz heraus lesen konnte... Das CUN ist doch
> genauso wie das CUL �ber USB verwendbar. Oder ist das USB-Interface
> 'nur' f�r Firmware-Upload und Stromzufuhr?
CUN braucht *immer* USB f�r Strom (oder man bastelt sich was wildes,
um PoE zu machen; leider kann CUN kein PoE direkt, andererseits: wer
hat schon PoE-Ports zu Hause?), geht aber ggf. auch �ber so ein lus-
tiges 240-zu-5-Volt-Netzteil mit USB-Ausgang, wie sie grade in Mode
kommen. CUN *kann* man dann �ber Ethernet ansprechen => 2 Kabel zum
CUN-Platz. Alternativ kann man CUN auch nur per USB mit einem Rechner
verbinden, dann ist's ein teurer CUL mit Geh�use ;) (Er k�nnte auch
dann wohl mehr als ein CUL (da war was mit Speicherbegrenzung im CUL,
die im CUN wohl nicht so schlimm ist), aber IIRC wird das derzeit
seitens der Firmware nicht wirklich genutzt.)
> Prozessoren gibt es auch zwei (andere) als bei der CUL-Variante. Wird
> wohl (unter anderem) mit dem Ethernet-IF zu tun haben.
Hmm? Ach so, 64X vs. 128X? IIRC ist das der Onboard-Speicher, lt. Data-
sheet ...162: 16 KByte Flash/512 Bytes SRAM, 64X 64 KByte Flash/4 KB SRAM
und schlie�lich 128X 128 KByte Flash/8 KB SRAM. In das Flash mu�, IIRC,
die Firmware reinpassen, mit dem RAM mu� die Firmware auskommen -- diese
"Gr��en" erinnern mich an die guten alten VC-20-Zeiten ;)
kai
Gerhard Pfeffer
@Kai: vielen Dank für die Erklärungen - wieder einiges gelernt.
Werde mir aber auf alle Fälle das CUN nehmen. Das ganze Projekt
schluckt nicht unbedingt wenig, da kommt es auf das auch nicht mehr
an. :-)
@Rudolf: Habe mir das ganze gestern nun ein wenig angesehen. Den
Fehler, dass keine Befehle mehr angenommen, konnte ich gestern auch
nicht reproduzieren (seit der 4.8er Version soweit ich mich erinnere
noch gar nicht). Und sonst dürften es einfach Störungen sein, dass die
Geräte nicht schalten. Denn empfangen dürften die Funksignale bei der
Haupteinheit immer. Die Endgeräte scheinen dann immer wieder einmal zu
streiken. Aber hier schafft das CUN hoffentlich Abhilfe. :-)
Was mir noch eingefallen ist, ich aber nichts passendes gefunden habe:
*) Wie sieht es mit der Funktionalität/Erfahrungen der CURs aus?
Scheint im Grunde ein guter Ersatz zu den üblichen Geräten zu sein.
Die Frage ist nun, was für Möglichkeiten habe ich dann und wie ist
vorallem der WAF zu dem Teil?
*) Ich kann bei dem CUL/CUN/CUR? die Sendeleistung etwas verstärken
(ist mir sehr wichtig)... Was ich mich jetzt noch Frage, welchen
nutzen habe ich als FHEM-User von den Möglichkeiten, die Frequenz und
Bandbreite der Sender zu verändern?
Nochmals Danke für eure Antworten. :-)
Lg,
Gerhard
Rudolf Koenig
Der CUR (Mein Liebling :) ist anur als Prototyp vorhanden, weil (meine
Interpretation) TOSTi Angst hat, das es wegen den hohen Preises nicht gekauft
wird.
Das Original mit (nicht unterstuetzten) IR Sender und Empfaenger haette sich
erst ab 100++ EUR oder so rentiert, der Nachbau so ab 80. Aber vielleicht habe
ich auch falsche Zahlen im Kopf.
Deswegen Liebling, weil ich relativ viel Zeit reingesteckt habe, ich habe damit
zum ersten mal Displaysteuerung, Antialiased fonts, Filesystem,
Akku-Kalibrierung, Helligkeits- steuerung mit PWM usw. programmiert.
> Scheint im Grunde ein guter Ersatz zu den 锟絙lichen Ger锟絫en zu sein.
Man koennte den CUR zwar auch so betreiben, aber es ist eigentlich als
Fernbedienung gedacht.
> Die Frage ist nun, was f锟絩 M锟絞lichkeiten habe ich dann und wie ist
> vorallem der WAF zu dem Teil?
- Man kann es als FS20 Fernbedienung nutzen, und _alle_ Geraete aus fhem mit 2
Befehlen reinladen.
- Da alle Geraete als Baum angeordnet sind, und man nur ein "Joystick" hat, ist
die Bedienung etwas langsamer als mit einem FS20 Sxx, dafuer aber hat man
alle Geraete, und man kann alle Befehle (toggle/on/off/dim... absenden)
Andererseits ist es schneller als ein iPhone-Frontend, da es sofort (0.1 sec)
an ist.
- Man kann den Status aller Geraete abfragen, wenn ein CUL am fhem
angeschlossen ist, und FHT Parameter setzen.
Bzw. man konnte, das waere aber leicht zu reparieren.
- Eine Akkuladung haelt ca 10 Tage, aufgeladen wird es in 4-6 Stunden, das 2.te
Prototyp kann das schneller.
Weitere komische Features:
- Es loggt (wie der CUN) die empfangenen Telegramme, das kann man auf dem
Geraet direkt anschauen ("more").
- Es hat einen "grafischen" RF-Monitor, mit dem man die 1 KHz Signale mit
Empfangsstaerke "live" beobachten kann.
- Man kann viele RF Parameter ohne PC direkt einstellen
- Man kann (statische) Bilder anzeigen (130x130, 12 bit!)
Ich plante Plots vom FHEM via CUL (FastRF) abrufen zu koennen, mein Interesse
ist aber mangels Publikum erloschen.
> (ist mir sehr wichtig)... Was ich mich jetzt noch Frage, welchen
> nutzen habe ich als FHEM-User von den M锟絞lichkeiten, die Frequenz und
> Bandbreite der Sender zu ver锟絥dern?
Das ist eher fuer den Experimentierer als fuer den Enduser. Ich habe
Messreihen durchgefuehrt (culfw/docs/FREQTEST), um die Parameter fuer den
besten Empfang zu finden, dazu waren die Befehle nuetzlich. So konnte ich es
mit fhem Skripten.
Eigentlich optimal ist eine kleine Bandbreite mit genauen Frequenz. Wenn man
viele Geraete hat, muss man auf eine groessere Bandbreite ausweichen, da die
Geraete nicht genau abgestimmt sind.
Beim Frequenz: Am Anfang hatten wir 868.35 als default, aber viele EM's sind
nur mit 868.3 zu empfangen (aktuelles default). Da ist es praktisch, wenn man
es direkt umstellen kann, ohne neuen Firmware zu flashen.
Gruss,
Rudi
Gerhard Pfeffer
> Interpretation) TOSTi Angst hat, das es wegen den hohen Preises nicht gekauft
> wird.
>
> Das Original mit (nicht unterstuetzten) IR Sender und Empfaenger haette sich
> erst ab 100++ EUR oder so rentiert, der Nachbau so ab 80. Aber vielleicht habe
> ich auch falsche Zahlen im Kopf.
>
> Deswegen Liebling, weil ich relativ viel Zeit reingesteckt habe, ich habe damit
> zum ersten mal Displaysteuerung, Antialiased fonts, Filesystem,
> Akku-Kalibrierung, Helligkeits- steuerung mit PWM usw. programmiert.
*hurray* - das kenne ich gut. Aber so wie das in deinem Fall klingt,
scheinst du da ja wirklich auf recht viel Neuland gestoßen zu
sein. ;-)
Kann man nur gratulieren. *applause*
> > Scheint im Grunde ein guter Ersatz zu den blichen Ger ten zu sein.
>
> Man koennte den CUR zwar auch so betreiben, aber es ist eigentlich als
> Fernbedienung gedacht.
>
> > Die Frage ist nun, was f r M glichkeiten habe ich dann und wie ist
> > vorallem der WAF zu dem Teil?
>
> - Man kann es als FS20 Fernbedienung nutzen, und _alle_ Geraete aus fhem mit 2
> Befehlen reinladen.
> - Da alle Geraete als Baum angeordnet sind, und man nur ein "Joystick" hat, ist
> die Bedienung etwas langsamer als mit einem FS20 Sxx, dafuer aber hat man
> alle Geraete, und man kann alle Befehle (toggle/on/off/dim... absenden)
> Andererseits ist es schneller als ein iPhone-Frontend, da es sofort (0.1 sec)
> an ist.
> - Man kann den Status aller Geraete abfragen, wenn ein CUL am fhem
> angeschlossen ist, und FHT Parameter setzen.
> Bzw. man konnte, das waere aber leicht zu reparieren.
> - Eine Akkuladung haelt ca 10 Tage, aufgeladen wird es in 4-6 Stunden, das 2.te
> Prototyp kann das schneller.
>
> Weitere komische Features:
> - Es loggt (wie der CUN) die empfangenen Telegramme, das kann man auf dem
> Geraet direkt anschauen ("more").
> - Es hat einen "grafischen" RF-Monitor, mit dem man die 1 KHz Signale mit
> Empfangsstaerke "live" beobachten kann.
> - Man kann viele RF Parameter ohne PC direkt einstellen
> - Man kann (statische) Bilder anzeigen (130x130, 12 bit!)
Also das klingt echt prima... Wie kommt man am besten an so ein
Teil? ;-)
> Ich plante Plots vom FHEM via CUL (FastRF) abrufen zu koennen, mein Interesse
> ist aber mangels Publikum erloschen.
Das finde ich allerdings schade... Ich schau mir regelmäßig meine
Plots an - und sollte ich so ein Teil mal mein Eigen nennen, dann wäre
das prima gewesen. Vielleicht küsst dich ja doch noch einmal die
Muse. :-)
Bestellt habe ich mein CUN mittlerweile schon. Jetzt heißt es nur noch
abzuwarten und sich ein paar Dinge zur Ablenkung zu finden. :-)
Rudolf Koenig
> Teil? ;-)
Beim TOSTi noergeln. Ich gebe meins nicht ab, und es gibt noch zwei weitere,
eins bei TOSTi (neuere Version) und eins bei Peter.
Dirk Tostmann
Am 06.01.2010 um 08:02 schrieb Rudolf Koenig:
> Beim TOSTi noergeln.
Ich weiss ja, aber ich halte iPhones und Adroiden mittlerweile für
bessere Fernbedienungen. Somit kann CUR nur ein Erfolg werden, wenn es
deutlich billiger ist. Und das rechnet sich erst so ab 50 Stück ...
Henne->Ei-Problem
Bis Q2 hoffe ich aber dennoch ein paar CUR in Handfertigung anbieten zu
können.
Manfred Caspari
Dirk Tostmann schrieb:
>
> Bis Q2 hoffe ich aber dennoch ein paar CUR in Handfertigung anbieten zu
> kï¿œnnen.
>
Ich wï¿œre interessiert, bitte vormerken :-)
Grￜￜe,
Manfred
Gerhard Pfeffer
also grundsätzlich hätte ich auch nichts über eine vernünftige Lösung
am Handy.
Mein Symbian-Handy würde da auch sicher mitmachen, aber mit welcher
Software (welchen Webinterface) ist das einigermaßen brauchbar
machbar? ;-)
Greetz,
Gerhard
On 6 Jan., 12:05, Manfred Caspari <effjott...@online.de> wrote:
> Moin Dirk,
>
> Dirk Tostmann schrieb:
>
> > Bis Q2 hoffe ich aber dennoch ein paar CUR in Handfertigung anbieten zu
> > k nnen.
>
> Ich w re interessiert, bitte vormerken :-)
>
> Gr e,
>
> Manfred
Gerhard Pfeffer
mein bestelltes CUN ist mittlerweile bei mir eingetroffen und läuft
zur Zeit in der Testphase.
Leider habe ich immer wieder Abbrüche in der Verbindung:
2010.01.17 13:18:09 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.17 13:18:14 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.17 14:06:54 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.17 14:06:59 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.17 14:28:26 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.17 14:28:31 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.17 15:24:54 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.17 15:25:00 1: CUL 10.0.0.240:2323 reappeared (CUL)
meistens steht die Verbindung nach 5 Sekunden wieder (wie auch hier
oben) - gelegentlich aber auch nicht. Per telnet komme ich allerdings
nach wie vor auf das CUN - nur fhem kriegt erst Daten nach dem
Neustart wieder. :-/
Vielleicht weiß jemand von euch Rat.
Vielen Dank!
Rudolf Koenig
Ist das jeweils ein reboot?
Den uptime der CUL/CUN kann man feststellen, indem man den von "t" bzw. fhem:
"get CUL raw t" gelieferte Hex-Zahl durch 125 dividiert, das Ergebnis sind dann
Sekunden.
Kai 'wusel' Siering
Gerhard Pfeffer wrote:
> mein bestelltes CUN ist mittlerweile bei mir eingetroffen und l�uft
> zur Zeit in der Testphase.
>
> Leider habe ich immer wieder Abbr�che in der Verbindung:
>
> 2010.01.17 13:18:09 1: 10.0.0.240:2323 disconnected, waiting to
> reappear
> 2010.01.17 13:18:14 1: CUL 10.0.0.240:2323 reappeared (CUL)
> 2010.01.17 14:06:54 1: 10.0.0.240:2323 disconnected, waiting to
> reappear
> 2010.01.17 14:06:59 1: CUL 10.0.0.240:2323 reappeared (CUL)
> 2010.01.17 14:28:26 1: 10.0.0.240:2323 disconnected, waiting to
> reappear
> 2010.01.17 14:28:31 1: CUL 10.0.0.240:2323 reappeared (CUL)
> 2010.01.17 15:24:54 1: 10.0.0.240:2323 disconnected, waiting to
> reappear
> 2010.01.17 15:25:00 1: CUL 10.0.0.240:2323 reappeared (CUL)
Komisches Intervall.
> meistens steht die Verbindung nach 5 Sekunden wieder (wie auch hier
> oben) - gelegentlich aber auch nicht. Per telnet komme ich allerdings
> nach wie vor auf das CUN - nur fhem kriegt erst Daten nach dem
> Neustart wieder. :-/
Nochmal zur Klarstellung: Du kannst *dauerhaft* per Telnet auf dem
CUN sein, *w�hrend* FHEM l�uft?
Also, mein CUN kann genau eine Verbindung (V 1.31.4 CUN; eigene FW noch
aus der Zeit, als die Firmware f�r CUN 'nen Bug hatte), alle anderen
Versuche, ihn �ber's Netz zu kontaktieren, h�ngen dann.
Welche culfw-Version hast Du drauf?
> Vielleicht wei� jemand von euch Rat.
Disconnected/reappeared deutet erst mal, wie Rudi schon schrieb, auf Re-
boot hin. Spannend w�re daher erst mal die Uptime der culfw zu wissen,
damit kann man das eingrenzen oder ausschlie�en. Falls es kein culfw-
Problem ist: die 10.0.0.240 wird per DHCP vergeben oder ist fest? Ist
es eine durchgehende LAN-Verbindung oder hast Du WLAN-Br�cken drin?
kai
Gerhard Pfeffer
danke für deine rasche Antwort. Neustart findet keiner statt, nein.
get CUL raw t
CUL raw => 0109C7F2 = 17418226/125/60/60/24=1,61 Tage
Läuft also, seitdem ich es angesteckt habe. :-/
Gerhard Pfeffer
vielen Dank für die ausführliche Antwort. Werde mir das ganze noch
näher ansehen. :-)
Wann wird denn eigentlich der Output vom Log in den interenen Speicher
geschrieben?
Vielleicht automatisch (weil zuvor mit X87 aktiviert) - und kann es
sein, dass der Speicher übergelaufen ist und das Gerät deshalb den
Dienst quitiert hat?
Grüße,
Gerhard
Hallo Gerhard,
> > Läuft das CUN-Modul brav vor sich hin... nur die Verbindung geht
> > immer wieder verloren und ist meistens nach 5 Sekunden wieder da.
Ich habe leider keine Langzeiterfahrung mit dem CUN, hab nur am Anfang
es im
Betrieb gehabt fuer ca 2 Tage. Dabei hatte ich keine Probleme
festgestellt.
Ich hatte aber Probleme waehrend der Entwicklung, da der Netzwerk-Chip
enc28j60
oder sein Trieber (stammt aus dem avr-uip Projekt) nicht perfekt sind,
und
immer wieder Muell liefern. Ich habe deswegen, wenn der enc28j60
angeblich ein
Paket mit mehr als MAX_FRAMELEN empfangen hat, ein ethernet_init
durchgefuehrt:
vielleicht siehst Du das. Laut TOSTi ist der enc28j60 Treiber aus
ethersex
wesentlich besser, ich hatte aber keine Energie, den zu portieren,
insb. da ich
den CUN nicht wirklich verwende.
> > Weiters habe ich Probleme mit der Ansteuerung meiner FHTs. Ich bekomme zwar
> > ständig brav die aktuelle Prozentangabe der Ventilöffnung, aber mehr leider
> > auch schon nicht (keine Temperaturen oder sonstige Einstellungen), genauso
> > wenig lässt sich das FHT ansteuern.
Das ist ein Hinweis darauf, dass der FHT nicht mit dem CUN gepaart
ist.
- Schalte FHT Meldungen mit "set CUL raw X61" ein, und schau nach
Nachrichten
des Typs start-xmit/can-xmit/can-rcv . Das Argument dahinter ist der
vom FHT
aktuell akzeptierte FHZ/CUL Code. Wenn dieser nicht dem ersten Byte
der CUL
Code entspricht, dann die Paarung wahrscheinlich auch mit dem
Aendern des
codes (set CUL raw T01XXYY) aendern, XX muss dem start-xmit Argument
entsprechen.
- Schau mal ob der T02 Puffer leer ist (get CUL raw T02): wenn ja,
dann meint
der CUL die Nachrichten abgeben zu koennen.
> > Wie sieht es denn mit der Steuerung aus, wenn ich mehrere
> > 'Zentralen' im Einsatz habe. Also zB mein altes FHZ1300 und das CUN.
Das ist nicht unterstuetzt. Der FHZ krallt sich gerne die FHT's, und
ich weiss
nicht wie ich es abstellen kann. Der FHZ code (set FHZ fhtid XX) ist
der code
XX vom oberen Abschnitt.
> > Beim Empfangen habe ich schon gelesen, dass es von fhem richtig
> > erkannt und nur einmal ausgeführt wird - aber wie ist das Vorgehen
> > beim Senden? Kann ich (und falls ja wie) steuern, welches Modul den
> > Befehl von sich gibt?
Ja siehe IODev Attribut der logischen (FS20/FHT) Geraetes. Beim
definieren
wird das zuletzt definierte Geraet verwendet, der dazu in der Lage
ist.
> > Etwas enttäuscht bin ich auch über den ausgebliebenen Erfolg bei der
> > Umstellung zum CUN, dass nach wie vor die Rollläden oft nicht auf
> > den Befehl reagieren und erst nach ewigem Ausrichten des CUNs der
> > Befehl angenommen wird.
Ich habe andere Erfahrung gemacht: mit dem FHZ blieben manche Rolladen
mal
haengen (ca 5%), seitdem ich den CUL verwende, habe ich das Problem
noch nicht
einmal gesehen.
Habe auch bereits die Sendeleistung
> > Keine Ahnung, was nun die ganzen Buchstaben genau bedeuten - gehe
> > aber einfach einmal davon aus, dass es Schrott ist, der nicht
> > verarbeitet werden kann.
Falsch: der CUL ist so konfiguriert (X..), dass es die Empfangstaerke
bei jedem
Flankenwechsel ausgibt (a==Signal schwach, p==stark). Ist eigenlich
nur zum
debuggen gedacht, und nicht im zusammenhang mit FHEM.
Weiterhin gibt er auch die Raw-Bits samt 0/1 Laengeninformation aus,
auch nur
zum debuggen gedacht.
> > PS: Eine Sache noch... wie funktioniert das eigentlich mit dem Reset
> > am CUN. Wenn ich ein B00 absetze, ist das CUN nicht mehr erreichbar,
> > aber laut Readme hätte ich es so verstanden, um zu rebooten:
Das sollte auch der Fall sein. Wir hatten mal Probleme, dass der
reboot nicht
sauber durchgefuehrt wurde, und ein Manuelles an/abstekcen noetig war,
ich
dachte das sei aber behoben.
Gruss,
Rudi
Rudolf Koenig
> geschrieben?
Interner Speicher? Meinst Du den Flash? Den muss man explicit aktivieren (set
CUL raw w01). Man kann mit "r." anschauen, welche Dateien angelegt sind. Es
gibt maximal 4 syslog files (Syslog.0-3), die beim vollwerden jeweils umbenannt
werden.
Gerhard Pfeffer
erreichbar war. :-/
Macht es eigentlich zur Zeit (und in absehbarer Zukunft) einen Sinn,
zusätzlich noch eine MicroSD-Karte hinein zu stecken oder macht es
optisch einfach mehr her? ;-)
Grüße,
Gerhard
Gerhard Pfeffer
wollte nochmal wegen der SD-Karte nachfragen - macht es zur Zeit einen
Sinn, das CUN mit einer zu erweitern (dh kann ich Logs darauf
speichern)?
Und gestern habe ich einmal 'set CUL verbose 25' gesetzt und im fhem-
log angesehen, ob alles so funktioniert, wie ich es gerne hätte.
Dabei sehe ich immer wieder 'unkown messages', die zusammen mit den
actuator-Übermittlungen auftreten. Aber weshalb sind diese unbekannt?
Kann es damit zu tun haben, dass ich meine alte FHZ1300 und das CUL im
Betrieb habe und die FHTs noch immer mit der FHZ gepaart ist? Habe das
ganze heute morgen auch noch einmal gemacht und einmal unten angehängt
- wäre klasse, wenn mir jemand weiter helfen könnte. ;-)
### cut begin ###
2010.01.21 08:39:02 4: FHZ/RAW: 810c04120909a00155 (Unparsed: )
2010.01.21 08:39:02 4: FHZ/RAW: 600000aa00 (Unparsed:
810c04120909a00155)
2010.01.21 08:39:02 4: FHT hr_01 actuator: lime-protection
2010.01.21 08:39:02 4: CUL: T556000AA00 -57.5
2010.01.21 08:39:02 4: CUL: p 3 384 352 576 544 11 6 6 21
5530001540035C
2010.01.21 08:39:02 2: CUL: unknown message p 3 384 352 576 544
11 6 6 21 5530001540035C
2010.01.21 08:39:02 4: CUL: p 3 384 368 560 576 12 6 6 21
5530001540035C
2010.01.21 08:39:02 2: CUL: unknown message p 3 384 368 560 576
12 6 6 21 5530001540035C
2010.01.21 08:40:24 4: FHZ/RAW: 810c049b0909a0010a23 (Unparsed: )
2010.01.21 08:40:24 4: FHZ/RAW: 0000a615 (Unparsed:
810c049b0909a0010a23)
2010.01.21 08:40:24 4: FHT hr_00 actuator: 8%
2010.01.21 08:40:24 4: CUL: p 3 384 368 528 576 9 3 2 3B
4C15FA40
2010.01.21 08:40:24 2: CUL: unknown message p 3 384 368 528 576
9 3 2 3B 4C15FA40
2010.01.21 08:40:24 4: CUL: T0A2300A615 -45
2010.01.21 08:40:24 4: CUL: p 3 352 384 576 592 12 6 6 39
0A11C014C15FA4
2010.01.21 08:40:24 2: CUL: unknown message p 3 352 384 576 592
12 6 6 39 0A11C014C15FA4
2010.01.21 08:40:57 4: FHZ/RAW: 810c04120909a0015560 (Unparsed: )
2010.01.21 08:40:57 4: FHZ/RAW: 0000aa00 (Unparsed:
810c04120909a0015560)
2010.01.21 08:40:57 4: FHT hr_01 actuator: lime-protection
2010.01.21 08:40:57 4: CUL: T556000AA00 -57.5
2010.01.21 08:40:57 4: CUL: p 3 384 368 560 560 12 6 6 20
5530001540035C
2010.01.21 08:40:57 2: CUL: unknown message p 3 384 368 560 560
12 6 6 20 5530001540035C
2010.01.21 08:40:57 4: CUL: p 3 368 368 560 576 12 6 6 21
5530001540035C
2010.01.21 08:40:57 2: CUL: unknown message p 3 368 368 560 576
12 6 6 21 5530001540035C
### cut end ###
Vielen Dank für eure Unterstützung.
Grüße,
Gerhard
Rudolf Koenig
> Sinn, das CUN mit einer zu erweitern (dh kann ich Logs darauf
> speichern)?
Logs kann man mit culfw z.Zt nicht auf eine SD-Karte speichern.
> Und gestern habe ich einmal 'set CUL verbose 25' gesetzt und im fhem-
> log angesehen, ob alles so funktioniert, wie ich es gerne h�tte.
> Dabei sehe ich immer wieder 'unkown messages', die zusammen mit den
> actuator-�bermittlungen auftreten. Aber weshalb sind diese unbekannt?
Weil CUL nicht alle Ausgaben der verbose 25 versteht, sondern nur verbose "21"
oder verbose "01". Da 01 auch nicht ueberall konsequent unterstuetzt wird,
werde ich das Befehl verbose entfernen.
Vergleichbare Funktionalitaet hat man mit "set CUL raw X21", hier sollte aber
klar sein, dass man "Mist" bauen kann. Fuer Details siehe culfw/README,
Abschnitt fuer Befehl X.