FHEM > fhem-users

Problem mit CUL_RFR nach updatefhem

(1/4) > >>

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
attr   CUL433 addvaltrigger 1
define CUL868 CUL /dev/cul868@9600 1234
define RFR868 CUL_RFR 02 01
get RFR868 version
define CUL433 CUL /dev/cul433@9600 1122
attr   CUL433 addvaltrigger 1
define RFR868 CUL_RFR 02 01
define CUL868 CUL /dev/cul868@9600 1234
get RFR868 version

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

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln