Problem mit CUL_RFR nach updatefhem

[Guest]

Originally posted by: <email address deleted>

Ich habe schon seit sehr langem einen CUL_RFR in Betrieb, der auch immer
stabil funktioniert hat. Wegen des interessanten Wiki-Eintrags über
FHT80-Kommunikation und da ich noch CULFW 1.43 draufhatte, habe ich
folgendes gemacht:

Alle CULs (1xV3.2 433, 2xV3.2 868) auf CULFW 1.46 geflasht, da damit ja
auch FHT-IODev funktionieren soll.  Außerdem ein updatefhem gemacht.

Anschließend habe ich den CUL_RFR partout nicht mehr ansprechen können.
Auch mehrmaliges setzen der IDs, Positionsänderung, EEPROM-Resets etc.
haben nicht geholfen.

Nun habe ich das Problem mit einer Minimalen fhem.cfg nachvollziehen
können. Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
in der fhem.cfg definiert wird. Ich habe verbose-5 logs von beiden
Zuständen gemacht, darin ist aber nichts wirklich hilfreiches zu sehen,
außer dass die beiden CULs in unterschiedlicher Reihenfolge definiert
werden und anschließend bei der nicht funktionierenden Version "get
RFR868 version" einen timeout liefert.

Hier die minimale (funktionierende) fhem.cfg:

attr global autoload_undefined_devices 1
attr global logfile /tmp/fhem/fhem-%Y-%m.log
attr global modpath /usr/share/fhem
attr global pidfilename /var/run/fhem/fhem.pid
define telnetPort telnet 7072 global
attr global statefile /tmp/fhem.save
attr global verbose 5
attr global dupTimeout 0.9
attr global latitude 49.7022
attr global longitude 8.6192

define WEB_Simple FHEMWEB 8083 global
attr   WEB_Simple plotmode SVG
#attr   WEB plotsize 800,180
attr   WEB_Simple stylesheetPrefix dark

#define CUL433 CUL /dev/cul433@9600 1122
#attr   CUL433 addvaltrigger 1

define CUL868 CUL /dev/cul868@9600 1234
#attr   CUL868 addvaltrigger 1

define RFR868 CUL_RFR 02 01
#set    RFR868 raw T012334

Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
RFR868 version immer ein timeout.

Ab dort, wo sich die Logs unterscheiden, habe ich die Reste mal angehängt.

Danke schonmal für jeden Tipp,
Thomas

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

5: Cmd: >define CUL433 CUL /dev/cul433@9600 1122<
5: Loading /usr/share/fhem/FHEM/00_CUL.pm
3: Opening CUL433 device /dev/cul433
3: Setting CUL433 baudrate to 9600
3: CUL433 device opened
5: SW: V
5: CUL/RAW (ReadAnswer): V 1.46 CUL433

5: SW: ?
5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A G M R T V W X e f m l t u x

3: CUL433: Possible commands: BCFiAGMRTVWXefmltux
5: SW: X21
5: SW: T01
5: CUL/RAW (ReadAnswer): 1122

5: GOT CUL fhtid: 1122
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Cmd: >attr   CUL433 addvaltrigger 1<
5: Cmd: >define CUL868 CUL /dev/cul868@9600 1234<
3: Opening CUL868 device /dev/cul868
3: Setting CUL868 baudrate to 9600
3: CUL868 device opened
5: SW: V
5: CUL/RAW (ReadAnswer): V 1.46 CUL868

5: SW: ?
5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A G M R T V W X e f m l t u x

3: CUL868: Possible commands: BCFiAGMRTVWXefmltux
5: SW: X21
5: SW: T01
5: CUL/RAW (ReadAnswer): 1234

5: GOT CUL fhtid: 1234
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Cmd: >define RFR868 CUL_RFR 02 01<
5: Loading /usr/share/fhem/FHEM/16_CUL_RFR.pm
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Interface "interface": readings "", getters "", setters ""
5: Interface "switch": readings "onoff", getters "onoff", setters ""
5: Interface "switch_active": readings "onoff", getters "onoff", setters ""
5: Interface "switch_passive": readings "onoff", getters "onoff", setters "on:off"
5: Interface "dimmer": readings "onoff:level", getters "onoff:level", setters "on:off:dimto:dimup:dimdown"
5: Interface "temperature": readings "temperature", getters "temperature", setters ""
5: Interface "humidity": readings "humidity", getters "humidity", setters ""
5: Interface "wind": readings "wind", getters "wind", setters ""
5: Interface "power": readings "power:maxPower:energy", getters "power:maxPower:energy", setters ""
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
2: SecurityCheck:  WEB_All,WEB_Simple,WEB_Small,WEB_Touch has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 27470)
4: Connection accepted from telnet:192.168.242.32:42933
5: Cmd: >get RFR868 version<
5: SW: u0201V
5: CUL/RAW (ReadAnswer): 0102UV 1.46 CUL868;

5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
0: Server shutdown
5: SW: X00
5: SW: X00
1: WriteStateFile: Cannot open /etc/fhem/fhem2.save: Permission denied
5: Cmd: >define CUL433 CUL /dev/cul433@9600 1122<
5: Loading /usr/share/fhem/FHEM/00_CUL.pm
3: Opening CUL433 device /dev/cul433
3: Setting CUL433 baudrate to 9600
3: CUL433 device opened
5: SW: V
5: CUL/RAW (ReadAnswer): V 1.46 CUL433

5: SW: ?
5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A G M R T V W X e f m l t u x

3: CUL433: Possible commands: BCFiAGMRTVWXefmltux
5: SW: X21
5: SW: T01
5: CUL/RAW (ReadAnswer): 1122

5: GOT CUL fhtid: 1122
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Cmd: >attr   CUL433 addvaltrigger 1<
5: Cmd: >define RFR868 CUL_RFR 02 01<
5: Loading /usr/share/fhem/FHEM/16_CUL_RFR.pm
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Cmd: >define CUL868 CUL /dev/cul868@9600 1234<
3: Opening CUL868 device /dev/cul868
3: Setting CUL868 baudrate to 9600
3: CUL868 device opened
5: SW: V
5: CUL/RAW (ReadAnswer): V 1.46 CUL868

5: SW: ?
5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A G M R T V W X e f m l t u x

3: CUL868: Possible commands: BCFiAGMRTVWXefmltux
5: SW: X21
5: SW: T01
5: CUL/RAW (ReadAnswer): 1234

5: GOT CUL fhtid: 1234
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Interface "interface": readings "", getters "", setters ""
5: Interface "switch": readings "onoff", getters "onoff", setters ""
5: Interface "switch_active": readings "onoff", getters "onoff", setters ""
5: Interface "switch_passive": readings "onoff", getters "onoff", setters "on:off"
5: Interface "dimmer": readings "onoff:level", getters "onoff:level", setters "on:off:dimto:dimup:dimdown"
5: Interface "temperature": readings "temperature", getters "temperature", setters ""
5: Interface "humidity": readings "humidity", getters "humidity", setters ""
5: Interface "wind": readings "wind", getters "wind", setters ""
5: Interface "power": readings "power:maxPower:energy", getters "power:maxPower:energy", setters ""
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
2: SecurityCheck:  WEB_All,WEB_Simple,WEB_Small,WEB_Touch has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 27374)
5: CUL/RAW: /T172A00A67A00

5: CUL868: T172A00A67A -74
5: CUL868 dispatch 810c04xx0909a001172a0000a67a
5: Loading /usr/share/fhem/FHEM/11_FHT.pm
3: FHT Unknown device 172a, please define it
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
4: Connection accepted from telnet:192.168.242.32:42932
5: CUL/RAW: /0102UT270E00AA00FE;

5: CUL868: 0102UT270E00AA00FE;
5: CUL868 dispatch 0102UT270E00AA00FE;
5: RFR868: T270E00AA00 -75
5: RFR868 dispatch 810c04xx0909a001270e0000aa00
3: FHT Unknown device 270e, please define it
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: Cmd: >get RFR868 version<
5: SW: u0201V
5: CUL/RAW: /T0C3400AA000F

5: CUL868: T0C3400AA00 -66.5
5: CUL868 dispatch 810c04xx0909a0010c340000aa00
3: FHT Unknown device 0c34, please define it
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
5: CUL/RAW: /0102UT0C3400AA0037;

5: CUL868: 0102UT0C3400AA0037;
5: CUL868 dispatch 0102UT0C3400AA0037;
5: RFR868: T0C3400AA00 -46.5
5: RFR868 dispatch 810c04xx0909a0010c340000aa00
5: Triggering global (1 changes)
5: global trigger: Checking Logfile for notify
5: global trigger: Checking WEB_All for notify
5: global trigger: Checking WEB_Simple for notify
5: global trigger: Checking WEB_Small for notify
5: global trigger: Checking WEB_Touch for notify
5: global trigger: Checking telnetPort for notify
0: Server shutdown
5: SW: X00
5: SW: X00
1: WriteStateFile: Cannot open /etc/fhem/fhem2.save: Permission denied

[Zrrronggg!]

                                                     

Nochmal zum Verständniss:

- entgegen dem Titel des threads hast gehts nicht um updatefhem,
sondern um eine Updaten der culFW, richtig?

- du schreibst
>Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
>in der fhem.cfg definiert wird.

Dann fügst du einen config bei die funktionieren soll, in der aber das
RFR nach dem CUL definiert wird. Was eigentlich nicht funktionieren
soll.

Übersehe ich was oder widerspricht sich das tatsächlich?


On 21 Okt., 15:14, Thomas Herrmann wrote:
> Ich habe schon seit sehr langem einen CUL_RFR in Betrieb, der auch immer
> stabil funktioniert hat. Wegen des interessanten Wiki-Eintrags �ber
> FHT80-Kommunikation und da ich noch CULFW 1.43 draufhatte, habe ich
> folgendes gemacht:
>
> Alle CULs (1xV3.2 433, 2xV3.2 868) auf CULFW 1.46 geflasht, da damit ja
> auch FHT-IODev funktionieren soll.  Au�erdem ein updatefhem gemacht.
>
> Anschlie�end habe ich den CUL_RFR partout nicht mehr ansprechen k�nnen.
> Auch mehrmaliges setzen der IDs, Positions�nderung, EEPROM-Resets etc.
> haben nicht geholfen.
>
> Nun habe ich das Problem mit einer Minimalen fhem.cfg nachvollziehen
> k�nnen. Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
> in der fhem.cfg definiert wird. Ich habe verbose-5 logs von beiden
> Zust�nden gemacht, darin ist aber nichts wirklich hilfreiches zu sehen,
> au�er dass die beiden CULs in unterschiedlicher Reihenfolge definiert
> werden und anschlie�end bei der nicht funktionierenden Version "get
> RFR868 version" einen timeout liefert.
>
> Hier die minimale (funktionierende) fhem.cfg:
>
> attr global autoload_undefined_devices 1
> attr global logfile /tmp/fhem/fhem-%Y-%m.log
> attr global modpath /usr/share/fhem
> attr global pidfilename /var/run/fhem/fhem.pid
> define telnetPort telnet 7072 global
> attr global statefile /tmp/fhem.save
> attr global verbose 5
> attr global dupTimeout 0.9
> attr global latitude 49.7022
> attr global longitude 8.6192
>
> define WEB_Simple FHEMWEB 8083 global
> attr   WEB_Simple plotmode SVG
> #attr   WEB plotsize 800,180
> attr   WEB_Simple stylesheetPrefix dark
>
> #define CUL433 CUL /dev/cul433@9600 1122
> #attr   CUL433 addvaltrigger 1
>
> define CUL868 CUL /dev/cul868@9600 1234
> #attr   CUL868 addvaltrigger 1
>
> define RFR868 CUL_RFR 02 01
> #set    RFR868 raw T012334
>
> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
> RFR868 version immer ein timeout.
>
> Ab dort, wo sich die Logs unterscheiden, habe ich die Reste mal angeh�ngt.
>
> Danke schonmal f�r jeden Tipp,
> Thomas
>
>  geht.log
> 5KAnzeigenHerunterladen
>
>  geht_nicht.log
> 7KAnzeigenHerunterladen

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

[Guest]

Originally posted by: <email address deleted>

On 10/21/2012 10:46 PM, Zrrronggg! wrote:
> Nochmal zum Verständniss:
>
> - entgegen dem Titel des threads hast gehts nicht um updatefhem,
> sondern um eine Updaten der culFW, richtig?

Ich habe beides gemacht; updatefhem und culfw-update. Da ich durch
Änderungen an der fhem.cfg den Fehler provozieren kann, vermute ich,
dass es ein fhem-Problem ist, kein culfw-Problem. Falls Du ein
culfw-Problem vermutest, kann ich auch nochmal downgraden und testen was
dann passiert.

> - du schreibst
>> Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
>> in der fhem.cfg definiert wird.
>
> Dann fügst du einen config bei die funktionieren soll, in der aber das
> RFR nach dem CUL definiert wird. Was eigentlich nicht funktionieren
> soll.

Ich habe eine config angefügt, zu der ich "funktionierend" geschrieben
habe. Direkt unter der config steht folgendes:

>> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
>> RFR868 version immer ein timeout.

Damit meinte ich die beiden Zeilen in der Datei. Man kann sich die nicht
funktionierende Datei also selbst erzeugen.

> Übersehe ich was oder widerspricht sich das tatsächlich?

War vielleicht etwas unklar, aber prinzipiell nicht Widersprüchlich.

Thomas

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

[rudolfkoenig]

                                                   

> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
> RFR868 version immer ein timeout.

Ist normal, da RFR868 damit keinen passenden IODev hat.

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

[Guest]

Originally posted by: <email address deleted>

On 10/22/2012 09:11 AM, Rudolf Koenig wrote:
>> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
>> RFR868 version immer ein timeout.
>
> Ist normal, da RFR868 damit keinen passenden IODev hat.

Hmm, ich könnte wetten, dass das früher mal ohne IODev funktioniert hat.
Aber jetzt gehts! Danke!

Thomas

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

[Guest]

Originally posted by: <email address deleted>

On 10/22/2012 07:48 AM, Thomas Herrmann wrote:
>> - du schreibst
>>> Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
>>> in der fhem.cfg definiert wird.
>>
>> Dann fügst du einen config bei die funktionieren soll, in der aber das
>> RFR nach dem CUL definiert wird. Was eigentlich nicht funktionieren
>> soll.

Stimmt, da hatte ich spät abends den Kopf schon etwas am rauchen, weil
ich an sehr viele Setups ausprobiert hatte, bis ich das ganze
einigermaßen reproduzieren konnte (inklusive FHEM-Neuinstallation auf
einem zweiten Linuxrechner).

Es muss heißen:

"Es tritt reproduzierbar auf, wenn ich den CUL_RFR _vor_ dem CUL
in der fhem.cfg definiert wird."

So hatte ich lange Zeit mein Setup definiert. Denn dadurch, dass der CUL
zuletzt definiert wurde, musste ich nur für wenige, weit entfernte
Geräte explizit IODev CUL_RFR setzen (ohne IODev wird das zuletzt
definierte passende Gerät genommen).

Thomas

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

[Zrrronggg!]

                                                     

Das es so funktioniert hat, überrascht mich.

On 22 Okt., 16:32, Thomas Herrmann wrote:
> On 10/22/2012 07:48 AM, Thomas Herrmann wrote:
>
> >> - du schreibst
> >>> Es tritt reproduzierbar auf, wenn ich den CUL_RFR _nach_ dem CUL
> >>> in der fhem.cfg definiert wird.
>
> >> Dann f gst du einen config bei die funktionieren soll, in der aber das
> >> RFR nach dem CUL definiert wird. Was eigentlich nicht funktionieren
> >> soll.
>
> Stimmt, da hatte ich sp t abends den Kopf schon etwas am rauchen, weil
> ich an sehr viele Setups ausprobiert hatte, bis ich das ganze
> einigerma en reproduzieren konnte (inklusive FHEM-Neuinstallation auf
> einem zweiten Linuxrechner).
>
> Es muss hei en:
>
> "Es tritt reproduzierbar auf, wenn ich den CUL_RFR _vor_ dem CUL
> in der fhem.cfg definiert wird."
>
> So hatte ich lange Zeit mein Setup definiert. Denn dadurch, dass der CUL
> zuletzt definiert wurde, musste ich nur f r wenige, weit entfernte
> Ger te explizit IODev CUL_RFR setzen (ohne IODev wird das zuletzt
> definierte passende Ger t genommen).
>
> Thomas

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

[Guest]

Originally posted by: <email address deleted>

Hallo Thomas,

ich lese gerade hier auf der Arbeit, dass Du nach dem fhem & cul update
kein Zugriff mehr auf den CUL_RFR hattest.
Hast Du das Problem gelöst?

Bei mir lief der CUL_RFR vor dem FHEM Update auf 5.3 und CUL-Update auf
1.43 ohne Probleme.
Jetzt kann ich ihn nicht mehr mal mit *get CUL2 version* abfragen.

Die Änderung der Reihenfolge der defines habe ich noch nicht ausprobiert,
versuche ich heute Abend mal.

Oder hast Du noch etwas andere gemacht?

Gruß
Markus


Am Montag, 22. Oktober 2012 10:52:02 UTC+2 schrieb Thomas Herrmann:
>
> On 10/22/2012 09:11 AM, Rudolf Koenig wrote:
> >> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
> >> RFR868 version immer ein timeout.
> >
> > Ist normal, da RFR868 damit keinen passenden IODev hat.
>
> Hmm, ich k�nnte wetten, dass das fr�her mal ohne IODev funktioniert
> hat.
> Aber jetzt gehts! Danke!
>
> Thomas
>

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

[Markus Hermann]

Also bei mir geht das nicht, egal welche Reihenfolge ich den CUL oder
CUL_RFR definiere.

define CUL CUL /dev/ttyACM0@38400 1234
define CUL2 CUL_RFR 02 01

oder

define CUL2 CUL_RFR 02 01
define CUL CUL /dev/ttyACM0@38400 1234

Beide Konstellationen wollen nicht, sprich ich bekomme kein Zugriff auf CUL2

Aber beide CULs kann ich an der FB abfragen (also get CUL version etc.),
wenn sie direkt am USB der FB hängen.

Hat noch jemand eine Idee?

Gruß
Markus



Am Freitag, 21. Dezember 2012 09:24:35 UTC+1 schrieb Markus Hermann:
>
> Hallo Thomas,
>
> ich lese gerade hier auf der Arbeit, dass Du nach dem fhem & cul update
> kein Zugriff mehr auf den CUL_RFR hattest.
> Hast Du das Problem gelöst?
>
> Bei mir lief der CUL_RFR vor dem FHEM Update auf 5.3 und CUL-Update auf
> 1.43 ohne Probleme.
> Jetzt kann ich ihn nicht mehr mal mit *get CUL2 version* abfragen.
>
> Die Änderung der Reihenfolge der defines habe ich noch nicht ausprobiert,
> versuche ich heute Abend mal.
>
> Oder hast Du noch etwas andere gemacht?
>
> Gruß
> Markus
>
>
> Am Montag, 22. Oktober 2012 10:52:02 UTC+2 schrieb Thomas Herrmann:
>>
>> On 10/22/2012 09:11 AM, Rudolf Koenig wrote:
>> >> Wenn man die Position des CUL868 und RFR868 vertauscht, kommt bei get
>> >> RFR868 version immer ein timeout.
>> >
>> > Ist normal, da RFR868 damit keinen passenden IODev hat.
>>
>> Hmm, ich k�nnte wetten, dass das fr�her mal ohne IODev funktioniert
>> hat.
>> Aber jetzt gehts! Danke!
>>
>> Thomas
>>
>

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

[rudolfkoenig]

> Also bei mir geht das nicht, egal welche Reihenfolge ich den CUL oder
> CUL_RFR definiere.

Sind die RFR Adressen auf den beiden Kontrahenten richtig eingestellt?
Es muesste folgendes sein:
  get CUL  raw u -> 0100
  get CUL2 raw u -> 0201

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

[Markus Hermann]

Hallo Rudolf,

ja die RFR sind nach dem Flashen auf 1.49 wieder eingestellt worden:

Haupt-CUL in der Fritzbox (CUL)
*get CUL raw u
CUL raw => 0100*

dann den RFR (CUL2) in die Fritzbox:

*get CUL raw u
CUL raw => 0201*

Wenn ich mich richtig erinnere habe ich vor Monate bei beiden die bWidth
auf 400 erhöht.
Wenn ich aber jetzt:

*set CUL bWidth 400* eingebe, dann

*get CUL ccconf
CUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB*

bleibt die bWidth auf 325.

Hat sich da etwas geändert? Vielleicht liegt es daran, das der CUL den CUL2
nicht wegen der bWidth sehen kann, vor dem flashen war ja alles ok.

Gruß
Markus




Am Samstag, 22. Dezember 2012 08:38:43 UTC+1 schrieb Rudolf Koenig:
>
> > Also bei mir geht das nicht, egal welche Reihenfolge ich den CUL oder
> > CUL_RFR definiere.
>
> Sind die RFR Adressen auf den beiden Kontrahenten richtig eingestellt?
> Es muesste folgendes sein:
>   get CUL  raw u -> 0100
>   get CUL2 raw u -> 0201
>

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

[Markus Hermann]

Nachtrag:

Wenn ich den CUL2 im Steckernetzteil betreibe und

*get CUL2 version*
oder
*get CUL2 uptime*

abfrage, bekomme ich

*=> No answer* angezeigt

bei einem:;
*get CUL2 raw u*

erhalte ich aber die Meldung:
*CUL2 raw => K9720807804567CF8*

Komisch, oder?




Am Samstag, 22. Dezember 2012 09:27:48 UTC+1 schrieb Markus Hermann:
>
> Hallo Rudolf,
>
> ja die RFR sind nach dem Flashen auf 1.49 wieder eingestellt worden:
>
> Haupt-CUL in der Fritzbox (CUL)
> *get CUL raw u
> CUL raw => 0100*
>
> dann den RFR (CUL2) in die Fritzbox:
>
> *get CUL raw u
> CUL raw => 0201*
>
> Wenn ich mich richtig erinnere habe ich vor Monate bei beiden die bWidth
> auf 400 erhöht.
> Wenn ich aber jetzt:
>
> *set CUL bWidth 400* eingebe, dann
>
> *get CUL ccconf
> CUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB*
>
> bleibt die bWidth auf 325.
>
> Hat sich da etwas geändert? Vielleicht liegt es daran, das der CUL den
> CUL2 nicht wegen der bWidth sehen kann, vor dem flashen war ja alles ok.
>
> Gruß
> Markus
>
>
>
>
> Am Samstag, 22. Dezember 2012 08:38:43 UTC+1 schrieb Rudolf Koenig:
>>
>> > Also bei mir geht das nicht, egal welche Reihenfolge ich den CUL oder
>> > CUL_RFR definiere.
>>
>> Sind die RFR Adressen auf den beiden Kontrahenten richtig eingestellt?
>> Es muesste folgendes sein:
>>   get CUL  raw u -> 0100
>>   get CUL2 raw u -> 0201
>>
>

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

[rudolfkoenig]

> Wenn ich aber jetzt:
> *set CUL bWidth 400* eingebe, dann
>
> *get CUL ccconf
> CUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB*


Das ist komisch. Ich wuerde alle Einstellungen mit "e" zuruecksetzen, und es
neu versuchen. Wenn das Verstellen immer noch nicht geht, dann scheint was mit
dem EEPROM nicht zu stimmen.


> Hat sich da etwas geändert?

Eigentlich nicht. Ich habe kein Problem, mit culfw 1.47 als Base und culfw 1.45
als RFR.



> bei einem:;
> *get CUL2 raw u*
>
> erhalte ich aber die Meldung:
> *CUL2 raw => K9720807804567CF8*

Letzteres ist normal, wenn man keine Verbindung zum RFR hat.  Wenn man das
weiter debuggen moechte, dann waere ein drittes CUL zwischen den beiden
notwendig, der mit "fr" die Kommunikation belauschen koennte. Ist aber was
fuer Fortgeschrittene.

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

[Markus Hermann]

set CUL raw e hat leider bei beiden nichts gebracht.
Ich kann bei beiden CULs auch nicht die bWidth auf 400 setzen.

Ich vermute mit der 1.49 Firmware stimmt was nicht.

Da ich inzwischen Windows 8pro habe kann ich auch nicht den Treiber für den
CUL installieren um mit FLIP die 1.47 zu flashen
und über FHEM die culfw auf 1.47 downgraden geht bestimmt nicht, oder?

Gruß
Markus


Am Sonntag, 23. Dezember 2012 14:04:36 UTC+1 schrieb Rudolf Koenig:
>
> > Wenn ich aber jetzt:
> > *set CUL bWidth 400* eingebe, dann
> >
> > *get CUL ccconf
> > CUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB*
>
>
> Das ist komisch. Ich wuerde alle Einstellungen mit "e" zuruecksetzen, und
> es
> neu versuchen. Wenn das Verstellen immer noch nicht geht, dann scheint was
> mit
> dem EEPROM nicht zu stimmen.
>
>
> > Hat sich da etwas ge�ndert?
>
> Eigentlich nicht. Ich habe kein Problem, mit culfw 1.47 als Base und culfw
> 1.45
> als RFR.
>
>
>
> > bei einem:;
> > *get CUL2 raw u*
> >
> > erhalte ich aber die Meldung:
> > *CUL2 raw => K9720807804567CF8*
>
> Letzteres ist normal, wenn man keine Verbindung zum RFR hat.  Wenn man das
> weiter debuggen moechte, dann waere ein drittes CUL zwischen den beiden
> notwendig, der mit "fr" die Kommunikation belauschen koennte. Ist aber was
> fuer Fortgeschrittene.
>

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

[rudolfkoenig]

> Ich vermute mit der 1.49 Firmware stimmt was nicht.

Bei mir funktioniert ein CUL V1.1 (Basis, culfw 1.45) und ein CUL V2.1 (RFR,
culfw 1.47) ohne Probleme. Ich habe jetzt beide auf den aktuellen Stand der
culfw gebracht (1.49), und es klappt immer noch.

Um Dein Problem zu lokalisieren ist wohl ein aufwendigeres debugging notwendig,
kokrete Hilfe kann ich aber leider keine geben.

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