Mehrere CUN's in ein Setup benutzen

[Guest]

Originally posted by: <email address deleted>

Hallo Zusammen,

ich habe seit kurzem hier in 12 Räume 14 FHT80b's verteilt und 50
FHT8v's.
Jetzt sind die Räumlichkeiten so, das ich nicht alle 14 FHT80b's auf
einmal "anfunken" kann und habe deswegen 2 CUNO's bestellt.
Es gibt aber ein Bereich wo dann beide CUNO's sich überschneiden.

Wie richtet man das korrekt ein?
  - konfiguriert man in FHEM 2x ein CUL mit die gleiche Hauscode?
  - konfiguriert man in FHEM 2x ein CUL mit jeweils eine eigene
    Hauscode?
  - oder nimmt man 1 CUL und ein CUL_RFR
  - muss ich ein "sendpool" definieren, da es ein Bereich gibt wo sich
    die beide CUNO's überschneiden?
  - muss ich jede FHT mittels "attr IODev CUNx" an ein CUNO
    binden?

Momentan habe ich 2 CUL's definiert mit jeweils eine eigene Hauscode
und jede FHT80b ist mit ein der beiden gepaired.

Ganz zufrieden bin ich momentan noch nicht da es noch für mich
unerklärbare Probleme gibt.

  - ich bekomme sehr häufig die Meldung "CUNxx: unknown message LOVF"
  - manche FHT80b's liefern manchmal stundenlang keine Temperaturwerte
    zurück
  - andersrum dauert es manchmal auch sehr lange bis ein Auftrag durch
    ein FHT80b angenommen und/oder verarbeitet wurde

Viele Grüße,
Edwin Top

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Zrrronggg!]

                                                     

Mal im Wiki folgendes durchgelesen:

http://fhemwiki.de/index.php/Maximal_nutzbare_Geräte
http://fhemwiki.de/index.php/LOVF

Den Problem ist, das 14 FHT80bs sehr grenzwertig ist. Nahe am maximal
möglichen.


> Wie richtet man das korrekt ein?

>   - oder nimmt man 1 CUL und ein CUL_RFR

ja. Wäre meiner Aufassung nach Mittel der Wahl.


>   - muss ich jede FHT mittels "attr IODev CUNx" an ein CUNO
>     binden?

ggf. ja, z.b. wenn du CUL und RFR CUL verwendest.


beachte dann auch bitte dies:
http://fhemwiki.de/index.php/FHT_mit_RFR_CUL_pairen



> Momentan habe ich 2 CULs definiert mit jeweils eine eigene Hauscode
> und jede FHT80b ist mit ein der beiden gepaired.

Hm, ich bin mir nicht sicher ob es das bringt. Wichtig ist nicht nur
der Hauscode, sondenr auch die FHT-ID. Dies wird soweit ich weiss bei
direkt angeschlossenen Geräten durch FHEM automatisch gesetzt. Ich
weiss nicht was passiert wenn man zwei "Zentralen" (hier:CULs)
anschlisst. Wenn die nun die SELBE FHT-ID bekommen, dann wird's lustig
und deine Probleme wundern mich nicht.



>   - ich bekomme sehr häufig die Meldung "CUNxx: unknown message LOVF"
>   - manche FHT80b's liefern manchmal stundenlang keine Temperaturwerte
>     zurück
>   - andersrum dauert es manchmal auch sehr lange bis ein Auftrag durch
>     ein FHT80b angenommen und/oder verarbeitet wurde

Zu viele Geräte an einer Zentrale unter einer FHT-ID, überschreiten
der 1% Sendezeit, dadurch alle obigen Problem erklärbar.

Lies die Artikel. 14 80bs sind grenzwertig. Meiner Aufassung nach mit
CUL und RFR CUL noch machbar...

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Hm, ich bin mir nicht sicher ob es das bringt. Wichtig ist nicht nur
> der Hauscode, sondenr auch die FHT-ID. Dies wird soweit ich weiss bei
> direkt angeschlossenen Geräten durch FHEM automatisch gesetzt.

Bevor hier Geruechte entstehen
FHT-ID's werden nicht automatisch vergeben.

> Ich weiss nicht was passiert wenn man zwei "Zentralen" (hier:CULs)
> anschliesst.

Alle nach dem zweiten CUL definierten Geraete werden diesem zugeordnet, es sei
denn man setzt "attr Schalter7 IODev CUL1".

Zu den anderen Vorschlaegen habe ich nichts hinzuzufuegen, ich wuerde es
genauso sagen.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 12/10/2010 04:28 AM, Zrrronggg! wrote:
> Mal im Wiki folgendes durchgelesen:
>
> http://fhemwiki.de/index.php/Maximal_nutzbare_Geräte
> http://fhemwiki.de/index.php/LOVF
>
> Den Problem ist, das 14 FHT80bs sehr grenzwertig ist. Nahe am maximal
> möglichen.

OK, der Wiki-Link zu LOVF hatte ich noch nicht gefunden. Als ich Google
befragt hatte fand ich nur postings über nicht-gepairte Devices.

> Zu viele Geräte an einer Zentrale unter einer FHT-ID, überschreiten
> der 1% Sendezeit, dadurch alle obigen Problem erklärbar.
>
> Lies die Artikel. 14 80bs sind grenzwertig. Meiner Aufassung nach mit
> CUL und RFR CUL noch machbar...

OK, soweit verstanden. Trotzdem möchte ich dieses Setup ans rennen
bekommen

Ich werde ein bisschen weiter ausholen.

Es handelt sich hier um ein Bürogebäude, es gibt hier 2 "Gebäudehälften"
die direkt benachbart sind.
Ich habe in jede Hälfte ein CUNO hingestellt. Wenn man jede CUNO mit
seine angeschlossene FHT80b's als ein System betrachtet, gibt es nur je
7 FHT80b's pro CUNO. Das müsste doch von der Sendezeit passen?

Das ist auch der eigentliche Grund warum ich zwei Hauscodes vergeben habe.

Wenn ich dann pro Gebäudehälfte ein FHEM-Instanz laufen lasse, hätte ich
dann mein Problem gelöst?

Wenn ich der Wiki-Eintrag zu LOVF lese, meldet der CUL ein Limit
Overflow. Wie kann das sein wenn ich jedes Gerät eigentlich nur mit ein
der CUNO's gepaired habe und es deswegen eigentlich nur 7 Geräte pro
CUNO geben sollte?

Gruß,
Edwin

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Wenn ich der Wiki-Eintrag zu LOVF lese, meldet der CUL ein Limit
> Overflow. Wie kann das sein wenn ich jedes Gerät eigentlich nur mit ein
> der CUNO's gepaired habe und es deswegen eigentlich nur 7 Geräte pro
> CUNO geben sollte?

Evtl. hoeren manche FHT's nicht richtig zu, und das CUL (CUNO?) versucht Daten
immer wieder zu senden. Schau mal mit "get CUL raw T02" den FHT Puffer des
CUL's an. Oder du schaust den ganzen FHT Verkehr an mit:
- set CUL raw X61 (sendet FHT Protokollinformationen an fhem weiter)
- inform timer (in einem telnet)

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 12/10/2010 09:37 AM, Rudolf Koenig wrote:
>> Wenn ich der Wiki-Eintrag zu LOVF lese, meldet der CUL ein Limit
>> Overflow. Wie kann das sein wenn ich jedes Gerät eigentlich nur mit ein
>> der CUNO's gepaired habe und es deswegen eigentlich nur 7 Geräte pro
>> CUNO geben sollte?
>
> Evtl. hoeren manche FHT's nicht richtig zu, und das CUL (CUNO?) versucht Daten
> immer wieder zu senden. Schau mal mit "get CUL raw T02" den FHT Puffer des
> CUL's an. Oder du schaust den ganzen FHT Verkehr an mit:
> - set CUL raw X61 (sendet FHT Protokollinformationen an fhem weiter)
> - inform timer (in einem telnet)

OK, ich rede mal von CUL, mal von CUNO. Es sind 2x CUNO, die aus sicht
von FHEM ein CUL sind (funktionieren ja aehnlich).

Wenn ich die FHT Puffer angucke sehe ich momentan folgendes:

fhem> get CUN01 raw T02
CUN01 raw => N/A
fhem> get CUN02 raw T02
CUN02 raw => 3439:6304,6400 3F46:6304,6400 2014:6304,6400 1A16:6304,6400
2257:6304,6400 2D48:6304,6400 3439:6304,6400 3F46:6304,6400
2014:6304,6400 1A16:6304,6400 2257:6304,6400 2D48:6304,6400 115B:412C
3439:412C

Wenn ich ein der angemeldete FHT's mit "list" anzeige sehe ich folgendes:

fhem> list Adminbuero_1
Internals:
    CODE       2508
    CUN01_MSGCNT 6
    CUN01_RAWMSG T25084B7747EE
    CUN01_RSSI -83
    CUN01_TIME 2010-12-10 09:57:45
    CUN02_MSGCNT 671
    CUN02_RAWMSG T25087E7747FA
    CUN02_RSSI -77
    CUN02_TIME 2010-12-10 09:57:45
    DEF        2508
    IODev      CUN02
    LASTIODev  CUN02
    MSGCNT     671
    NAME       Adminbuero_1
    NR         19
    STATE      measured-temp: 21.1 (Celsius)
    TYPE       FHT
    Readings:
[...]

Was soll mir das sagen das bei "Internals" beide CUN's aufgelistet sind,
obwohl CUN02 da zuständig sein sollte?

Gruß,
Edwin

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> CUN02 raw => 3439:6304,6400 3F46:6304,6400 2014:6304,6400 1A16:6304,6400
> 2257:6304,6400 2D48:6304,6400 3439:6304,6400 3F46:6304,6400
> 2014:6304,6400 1A16:6304,6400 2257:6304,6400 2D48:6304,6400 115B:412C
> 3439:412C

Das ist ein Problem: die 6 FHT's (1A16 2014 2257 2D48 3439 3F46) hoeren nicht
richtig zu. Weiterhin werden manche Nachrichten wiederholt ins Puffer gesteckt,
dieses Problem wurde mit dem aktuellen CVS fhem schon geloest.


> Was soll mir das sagen das bei "Internals" beide CUN's aufgelistet sind,
> obwohl CUN02 da zuständig sein sollte?

Das ist nicht schlimm, und sagt nur, dass beide CUNO's die Kommunikation
mitbekommen haben. Wenn die CUNO's unterschiedliche IDs haben, dann sollte nur
derjenige mit dem FHT reden, mit dem es gepaart wurde. Btw. ich hoffe dass die
ersten beiden Stellen der CUNO ID's unterschiedlich ist, da es beim reden mit
der FHT nur darauf ankommt. Moment.... Vielleicht liegt hier dein Problem?

Wie man das ID des gepaarten CUNO's rauskriegt, steht hier:
http://fhemwiki.de/index.php/Hauskode_der_FHZ1300_herausfinden

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On Fri, 10 Dec 2010 16:45:55 +0100, Rudolf Koenig
wrote:
>> CUN02 raw => 3439:6304,6400 3F46:6304,6400 2014:6304,6400
1A16:6304,6400
>> 2257:6304,6400 2D48:6304,6400 3439:6304,6400 3F46:6304,6400
>> 2014:6304,6400 1A16:6304,6400 2257:6304,6400 2D48:6304,6400 115B:412C
>> 3439:412C
>
> Das ist ein Problem: die 6 FHT's (1A16 2014 2257 2D48 3439 3F46) hoeren
> nicht richtig zu.

Hmmm, diese 6 FHT's sollten auch mit CUN01 gepaired sein, nicht mit CUN02.
Diese Nachrichten haben also nichts in diese Puffer zu suchen.

> Weiterhin werden manche Nachrichten wiederholt ins Puffer
> gesteckt, dieses Problem wurde mit dem aktuellen CVS fhem schon geloest.

OK, das kann ich aber erst Montag testen.

>> Was soll mir das sagen das bei "Internals" beide CUN's aufgelistet
sind,
>> obwohl CUN02 da zuständig sein sollte?
>
> Das ist nicht schlimm, und sagt nur, dass beide CUNO's die Kommunikation
> mitbekommen haben. Wenn die CUNO's unterschiedliche IDs haben, dann
sollte
> nur derjenige mit dem FHT reden, mit dem es gepaart wurde. Btw. ich
hoffe dass
> die ersten beiden Stellen der CUNO ID's unterschiedlich ist, da es beim
reden
> mit der FHT nur darauf ankommt. Moment.... Vielleicht liegt hier dein
Problem?
>
> Wie man das ID des gepaarten CUNO's rauskriegt, steht hier:
> http://fhemwiki.de/index.php/Hauskode_der_FHZ1300_herausfinden

Uh ja, die ersten beiden Stellen des ID's sind identisch...

Ich werde dann Montag auch die FHT-ID von ein der CUNO's ändern und alle
FHT's neu pairen.

Vielen Dank so weit und weitere Nachrichten folgen Montag.

Schönes Wochenende,
Edwin Top

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 12/10/2010 04:45 PM, Rudolf Koenig wrote:
>> CUN02 raw =>  3439:6304,6400 3F46:6304,6400 2014:6304,6400 1A16:6304,6400
>> 2257:6304,6400 2D48:6304,6400 3439:6304,6400 3F46:6304,6400
>> 2014:6304,6400 1A16:6304,6400 2257:6304,6400 2D48:6304,6400 115B:412C
>> 3439:412C
>
> Das ist ein Problem: die 6 FHT's (1A16 2014 2257 2D48 3439 3F46) hoeren nicht
> richtig zu. Weiterhin werden manche Nachrichten wiederholt ins Puffer gesteckt,
> dieses Problem wurde mit dem aktuellen CVS fhem schon geloest.

Ich habe dieses Problem bis jetzt noch nicht wieder gesehen. Wenn es
wieder auftritt werde ich ein update auf dem aktuellsten CVS Version
versuchen.

>> Was soll mir das sagen das bei "Internals" beide CUN's aufgelistet sind,
>> obwohl CUN02 da zuständig sein sollte?
>
> Das ist nicht schlimm, und sagt nur, dass beide CUNO's die Kommunikation
> mitbekommen haben. Wenn die CUNO's unterschiedliche IDs haben, dann sollte nur
> derjenige mit dem FHT reden, mit dem es gepaart wurde. Btw. ich hoffe dass die
> ersten beiden Stellen der CUNO ID's unterschiedlich ist, da es beim reden mit
> der FHT nur darauf ankommt. Moment.... Vielleicht liegt hier dein Problem?

Ich habe jetzt die beide CUNO's ein völlig verschiedene Hauscode gegeben
und die FHT's neu gepaired. Bis jetzt läuft alles reibungslos.
Ich werde das ganze noch eine Weile beobachten..

Die Info das die erste 2 Stellen ausschlaggebend sind, war gut
versteckt. Da war ich sonst nie drauf gekommen.

Viele Dank so weit!

Gruß,
Edwin Top

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Mein Setup funktioniert jetzt schon eine Weile relativ gut.

Momentan habe ich die 2 CUNO Devices wie folgt definiert:

define CUN01 CUL 192.168.2.101:2323 3302
attr CUN01 sendpool CUN01,CUN02

define CUN02 CUL 192.168.2.102:2323 4102
attr CUN02 sendpool CUN01,CUN02

Des weiteren habe ich jedes FHT Gerät explizit mit "attr IODev
CUNxx" mit ein der CUNO Devices verknüpft.

Ich habe aber noch folgendes Problem:

fhem> get CUN02 raw T02
CUN02 raw => 2D48:411F

Die FHT mit ID "2d48" ist aber mit CUN01 verknüpft und ist hier im
Gebäude so platziert das er wahrscheinlich nie CUN02 empfangen wird.

Wie kann dieses Telegramm dann bei CUN02 gelandet sein?

Gruß,
Edwin

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Wie kann dieses Telegramm dann bei CUN02 gelandet sein?

Entweder ein Bug, oder der IODev von 2d48 war zwischenzeitlich CUN02.
Wenn das wiederholt auftritt, dann sollten wir es debuggen...

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.