Problem mit CUL_RFR nach updatefhem

[Thomas Herrmann]

Ich habe schon seit sehr langem einen CUL_RFR in Betrieb, der auch immer
stabil funktioniert hat. Wegen des interessanten Wiki-Eintrags 锟絙er
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锟絜rdem ein updatefhem gemacht.

Anschlie锟絜nd habe ich den CUL_RFR partout nicht mehr ansprechen k锟絥nen.
Auch mehrmaliges setzen der IDs, Positions锟絥derung, EEPROM-Resets etc.
haben nicht geholfen.

Nun habe ich das Problem mit einer Minimalen fhem.cfg nachvollziehen
k锟絥nen. 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锟絥den gemacht, darin ist aber nichts wirklich hilfreiches zu sehen,
au锟絜r dass die beiden CULs in unterschiedlicher Reihenfolge definiert
werden und anschlie锟絜nd 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锟絥gt.

Danke schonmal f锟絩 jeden Tipp,
Thomas

[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 <to...@gmx.de> 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

[Thomas Herrmann]

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

[Rudolf Koenig]

> 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.

[Thomas Herrmann]

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

Thomas

[Thomas Herrmann]

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

[Zrrronggg!]

Das es so funktioniert hat, überrascht mich.

[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.

[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

[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

[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

[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?

[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.

[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?

[Rudolf Koenig]

> 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.

[Markus Hermann]

Danke für die Rückmeldung.

Ich habe jetzt die 1.46 drauf und mein CUL_RFR redet wieder mit mit.
Das bleibt jetzt erstmal so, bis sich andere Zwänge ergeben die FW "upzudaten"

Gruß
Markus

--
sent via http://forum.fhem.de