FHEM > fhem-users

Problem mit CUL_RFR nach updatefhem

<< < (2/4) > >>

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln