FHT actuator7, alle 4 Minuten

[Martin Fischer]

Hiya,

nu muss ich als alter FHEM-Hase auch mal wieder 'ne Frage stellen:

ich habe die Tage mal nach langer Zeit autocreate eingeschaltet und stelle nun
nach 3 Tagen fest, das ich neue Devices aus den Klassen CUL_WS, FS20 und FHT
habe.

Alle Geräte kann ich nicht zuordnen, also wahrscheinlich "funkt" mir ein
Nachbar mit rein. Da in letzter Zeit ab und an mal wieder eine bestimmte
Stelle im Haus scheinbar für ein paar Stunden in einem Funkloch verschwindet,
habe ich mittels CUL und "raw RSSI" versucht den "Störsender" zu finden. Zwar
habe ich im ganzen Haus über alle Etagen verteilt ziemlich häufig einen
"Träger" mit Stärke "c" aber mehr auch nicht.

Was mich jedoch stutzig macht ist ein per autocreate angelegter FHT_2ec5 der
laut Logfile rund alle 4 Minuten folgendes meldet:

fhem-2012-01.log:2012.01.09 19:26:25 2: autocreate: define FHT_2ec5 FHT 2ec5
fhem-2012-01.log:2012.01.09 19:26:25 2: autocreate: define FileLog_FHT_2ec5
FileLog /var/log/fhem/devices/FHT_2ec5-%Y.log FHT_2ec5
fhem-2012-01.log:2012.01.09 19:26:25 2: autocreate: define weblink_FHT_2ec5
weblink fileplot FileLog_FHT_2ec5:fht:CURRENT
fhem-2012-01.log:2012.01.09 19:26:26 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:30:27 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:30:28 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:34:29 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:34:30 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:38:31 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:38:32 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:42:33 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:42:34 4: FHT FHT_2ec5 actuator7: 0%
fhem-2012-01.log:2012.01.09 19:46:35 4: FHT FHT_2ec5 actuator7: 0%

und das geht so weiter.

Wie wahrscheinlich ist es, das es sich dabei tatsächlich um einen FHT handelt?
Ganz so gesprächig sind die ja eigentlich nicht. Auch das der Aktuator 7 in
gebrauch ist macht micht stutzig. Was aus dem Logauszug oben nicht hervorgeht,
das der "actuator7" auch mal für längere Zeit 99% meldet.

Bei den anderen Devices verhält es sich so, das sie lediglich angelegt wurden
und keinen Status besitzen. Insgesamt handelt es sich um 2x FHT, 6x FS20 und
1x CUL_WS.

Ich habe in den letzten Jahren einen ziemlich grossen Ausbauzustand erreicht:
1x CM11
1x X10
14x CUL_FHTTK
4x CUL_WS
1x CUL
1x CUN
1x CUNO
1x FHZ1300
19x FS20, (fs20st, Fernbedienungen, Wandschalter, Dämmerungsschalter, PIRI)
7x HMS (Wasser Detektor, Gas Detektor, Temp/Hum, 3x Rauchmelder)
1x KS555
13x 1-Wire (Temp, Switch, LCD)

Dazu lagern im Keller noch etliche Devices (hoffentlich) ohne Batterien. Vom
CUL_WS über FS20ST, CUL_FHTTK, Fernbedienung und wat weiss ich noch alles

Bin ich evtl. mittlerweile soweit, das hier langsam die Meldungen der Devices
so schnell überlagert kommen, das CUL / CUN diese "Falschmeldungen / Devices"
"erfindet"?

Oder tappe ich hier langsam in die LTE-Falle? Sender auf dem Dach ist in
unmittelbarer Sichtweiter (3-4 Häuser weiter).

Ideen?

Gruß Martin

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

[rudolfkoenig]

                                                   

> Wie wahrscheinlich ist es, das es sich dabei tatsächlich um einen FHT
> handelt?
 
Ich halte es fuer unwahrscheinlich. FHT80b's senden in 115+x*0.5 (mit x zw. 0
und 7) Sekunden Abstand, was nicht in deinem Raster faellt. Wuesste ich auch
gerne, was es ist.


> Bei den anderen Devices verhält es sich so, das sie lediglich angelegt wurden
> und keinen Status besitzen. Insgesamt handelt es sich um 2x FHT, 6x FS20 und
> 1x CUL_WS.


Meiner Ansicht nach ist das bei deinem vielen Geraeten plausibel: Das Ein-Byte
Checksum der FHT/FS20/S300 ist nicht so schrecklich sicher.

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

[Martin Fischer]

hiya rudi,

Am Donnerstag, 12. Januar 2012 schrieb Rudolf Koenig:
> > Wie wahrscheinlich ist es, das es sich dabei tatsächlich um einen FHT
> > handelt?
>
> Ich halte es fuer unwahrscheinlich. FHT80b's senden in 115+x*0.5 (mit x zw.
> 0 und 7) Sekunden Abstand, was nicht in deinem Raster faellt. Wuesste ich
> auch gerne, was es ist.

ja, genau das ist mir ja auch bewusst und machte mich stutzig. und hast du
eine idee, wie wir das raus bekämen? raw rssi war ja schon mal ein versuch von
mir, hat aber nicht so wirklich licht ins dunkel gebracht ausser dem nahezu
dauer-"c"-träger.

> > Bei den anderen Devices verhält es sich so, das sie lediglich angelegt
> > wurden und keinen Status besitzen. Insgesamt handelt es sich um 2x FHT,
> > 6x FS20 und 1x CUL_WS.
>
> Meiner Ansicht nach ist das bei deinem vielen Geraeten plausibel: Das
> Ein-Byte Checksum der FHT/FS20/S300 ist nicht so schrecklich sicher.

tja.. auch hier wird es ja kaum viele alternativen geben. was über kurz oder
lang wegfällt werden die S300er sein, da ich diese alle durch 1-wire ersetzen
werde, wenn ich endlich die module für fhem fertig habe.

dann bleiben quasi nur noch (mal abgesehen von dem wasserstand und
gasdetektor) die fhts und die ks555 die von sich aus "gesprächig" sind über.

meinst du, das die ablösung von fs20 nach homematic eine besserung erzielen
könnte? also mischbetrieb fht / hm oder sogar komplett weg von fht und fs20 zu
hm?

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

[tostmann]

                                                 

Am 12.01.2012 um 23:30 schrieb Martin Fischer:

> hat aber nicht so wirklich licht ins dunkel gebracht ausser dem nahezu
> dauer-"c"-träger.

Manche ELV Geräte, bei mir der Helligkeitsender, stürzen bei "Batterie low" ab und senden Dauerträger ... Das kann es nicht sein?

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

[rudolfkoenig]

                                                   

> meinst du, das die ablösung von fs20 nach homematic eine besserung erzielen
> könnte? also mischbetrieb fht / hm oder sogar komplett weg von fht und fs20 zu
> hm?

HM wird sicher vom CUL besser empfangen (auf beiden Seiten der gleiche Chip),
aber ich habe noch keine Reichweitenvergleiche mit FS20 gemacht.  Hat nicht
jemand Lust mal sowas durchzufuehren?


Ich meine HM hat auch 2 statt 1 byte checksum, und autocreate erzeugt nur nach
einem Anlern-Telegramm neue Geraete. Weiterhin ist die Funkdauer fuer eine
Nachricht etwa  10-mal kuerzer als beim FS20 (beim CUL<->FHT etwa 100-mal),
Ueberschneidungen also entsprechend (quadratisch?) seltener.


Aus dieser Sicht ist also HM sicher besser, die fhem Unterstuetzung ist aber
nicht komplett. Und HM aufsetzen ist aufwendiger, aber Du bist ja kein
Anfaenger

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

[Zrrronggg!]

                                                     

> HM wird sicher vom CUL besser empfangen (auf beiden Seiten der gleiche Chip),
> aber ich habe noch keine Reichweitenvergleiche mit FS20 gemacht.  Hat nicht
> jemand Lust mal sowas durchzufuehren?

Mein nächstes Projekt ist einen am Rande der Reichweite des CUL
liegende FS20ST durch ein HM Pendant zu ersetzen, um zu sehen, ob das
dann besser geht, allerdings mit dem HMLAN Adapter.
Der Kram liegt hier rum. Der Plan war, dazu vorher Reichweitentests zu
machen.

Vorher muss ich aber von FHEM 4.9 hoch, da hapert's gerade noch ein
bischen...

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

[Martin Fischer]

Am Donnerstag, 12. Januar 2012 schrieb Dirk Tostmann:
> Am 12.01.2012 um 23:30 schrieb Martin Fischer:
> > hat aber nicht so wirklich licht ins dunkel gebracht ausser dem nahezu
> > dauer-"c"-träger.
>
> Manche ELV Geräte, bei mir der Helligkeitsender, stürzen bei "Batterie low"
> ab und senden Dauerträger ... Das kann es nicht sein?

danke dirk.. nein, das ist es nicht.. das thema hatten wir ja auch schon mal
vor jahren.. damals wars glaub ich eine wetterstation

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

[Martin Fischer]

Am Freitag, 13. Januar 2012 schrieb Rudolf Koenig:
> [...]
> Aus dieser Sicht ist also HM sicher besser, die fhem Unterstuetzung ist
> aber nicht komplett. Und HM aufsetzen ist aufwendiger, aber Du bist ja
> kein Anfaenger

danke rudi... ist ja auch nicht so, das ich noch keine hm komponenten
liegen habe. die habe ich nur ganz vergessen. sind zwar nur zwei dimmer und
zwei steckdosen aber immer etwas.

tja, deine argumente ziehen natürlich. ich werde mir wohl mal einen kopf
machen ob ich komplett umsteige.

wichtig sind mir vorallem die fht's zu ersetzen. zwar habe ich den einen oder
anderen thread immer wieder mitgelesen, bin aber im moment nicht auf dem
aktuellen stand. was wird bei dem hm pendant davon derzeit noch nicht
unterstützt? wo liegt bei hm das maximimum von thermostaten? ähnlich wie bei
fht ca. 10-12?

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

[rudolfkoenig]

                                                   

>  was wird bei dem hm pendant davon derzeit noch nicht unterstützt?

Ich hoffe nichts wichtiges, andererseits ist mein HM-CC-TC nicht in der
"Produktion". Und die direkte Steuerung der Ventile ist nicht implementiert.

Direkte Steuerung ueber PID ist mir eh unheimlich , ich habe es nie getestet,
und bisher so gut wie kein Feedback dafuer erhalten.


> wo liegt bei hm das maximimum von thermostaten? ähnlich wie bei
> fht ca. 10-12?

Weiss nicht genau, sollte aber deutlich hoeher sein. Das 10-12 kommt daher,
weil das CUL/FHZ fuer den Empfang der FHT-Temperaturmeldungen viel _senden_
muss, und die 1% Grenze theoretisch bei 17, praktisch bei 10-12 FHT erreicht
wird.
Das HM-CC-TC sendet etwa alle 3 Minuten Temperatur und Feuchte (statt alle 15
wie ein FHT), verbraucht dafuer aber etwa 50-mal weniger Sendezeit pro
Nachricht als ein FHT.  Nach diesem Formel liegt die theoretische Grenze
(wg. 1%) fuer HM-CC-TC's pro CUL/HMLAN bei etwa 50 * 17 / 5 = 170.

Mich wiederum stoert, dass ein HM-CC-TC (angeblich) nur 4 Ventile steuern kann.

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

[Martin Fischer]

Am Samstag, 14. Januar 2012 schrieb Rudolf Koenig:
> Direkte Steuerung ueber PID ist mir eh unheimlich , ich habe es nie
> getestet, und bisher so gut wie kein Feedback dafuer erhalten.

ja, das interessiert mich auch nicht

> [...]
> Das HM-CC-TC sendet etwa alle 3 Minuten Temperatur und Feuchte (statt alle
> 15 wie ein FHT), verbraucht dafuer aber etwa 50-mal weniger Sendezeit pro
> Nachricht als ein FHT.  Nach diesem Formel liegt die theoretische Grenze
> (wg. 1%) fuer HM-CC-TC's pro CUL/HMLAN bei etwa 50 * 17 / 5 = 170.

na das ist ja ne ganz andere hausnummer als bei den fhts. da sollte dann doch
etwas mehr puffer sein auch wenn mein nicht an die theoretische grenze kommen
wird.

> Mich wiederum stoert, dass ein HM-CC-TC (angeblich) nur 4 Ventile steuern
> kann.

ok.. aber in wie vielen fällen wird man mehr als 4 ventile steuern wollen? das
muss dann ja schon ein ziemlich grosser raum mit mehreren radiatoren sein oder
man missbraucht es für eine fussbodenheizung mit mehreren kreisläufen..

für meine (momentan) bzw. seit den letzten 4 jahren mit fhem benötigten
anforderungen liegt bei max. 2 ventilen.

dann werde ich wohl mal im laufe des jahres auf hm umsteigen, denn jetzt wird
es zeitlich erstmal eng, da ich darauf warte, das mein "bengel" in den
nächsten tagen das licht der welt erblickt.. und das ganz ohne hilfe von fhem


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