Originally posted by: <email address deleted>
Hallo Miteinander und EnOcean Spezialisten,
ich bin neu in diesem Forum und ebenso in der Thematik Fhem mit
EnOcean.
An meiner Frtiz!Box 7390 haengt ein BSC-Bor jedoch mit eingebautem
TCM300 (nicht 120, nicht 310). Ich habe ihn als TCM 310 deklariert und
kann die EnOcean Telegramme meines
4-Kanal Handsensers (steuert ueber 2-Kanaele meine Markise, 2 Kanaele
sind noch frei) und meines
2-Kanal Schalters (soll meine Bad-Beleuchtung dimmen) erkennen und
sehen.
Ein Senden eines Telegramms ist mir jedoch noch nicht geglueckt weder
per set Befehl und auch nicht ueber die Web-Oberflaeche! Die Befehle
werden zwar geloggt jedoch die Aktoren reagieren nicht.
Kann ich ueberhaupt ueber die angelernten Sender, Schalter mit Fhem
die Aktoren ansprechen oder muss ich ueber den CUL "pseudo" Schalter
definieren, die dann in der Lage sind die Aktoren anzusprechen?
Ich bin fuer jede Hilfe dankbar.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Kann ich ueberhaupt ueber die angelernten Sender, Schalter mit Fhem
> die Aktoren ansprechen
Nein (bzw. nicht beim EnOcean), da die TCM's weigern sich beliebige Adressen
auszusenden. D.h. man muss einen Switch konfigurieren, dessen Adresse im
erlaubten Bereich ist (id bis id+127, wobei id = get TCM idbase), Beispiel:
define switch1 EnOcean ffc54500
und den Aktor lernt man mit
set switch1 BI
an, auf B0 hoert es mWn automatisch.
Theoretisch kann man mit jedem ID (4*2 * 4*2 = 64) Schalterkombinationen
verwenden (A0/AI, B0/BI, C0/CI, D0/DI und jeweils Zweierkombinationen),
weiss aber nicht, wie Aktoren mit Zweierkombinationen anzulernen sind.
Die andere Moeglichkeit ist statt idbase 00000000 zu verwenden, da wird es mWn
mit _einem_ nicht aenderbaren ID ersetzt. Das ist die von EnOcean empfohlene
Methode. Ich wuerde das nicht verwenden, da es damit nur 64 Schalter zu
schalten sind, und auch beim Austausch des PC-Sticks alles neu anzulernen ist,
aber vielleicht verstehe ich noch was nicht.
Achtung: idbase kann man beim TCM nur 10-mal aendern.
Siehe auch http://fhem.de/commandref.html#EnOceanset:
In order to control devices, you cannot reuse the ID's of other devices (like
remotes), instead you have to create your own, which must be in the allowed
ID-Range of the underlying IO device. For this first query the TCM with the
"get idbase" command. You can use up to 128 ID's starting with the base
shown there. If you are using an ID outside of the allowed range, you'll see
an ERR_ID_RANGE message in the fhem log.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo zusammen,
ich habe das selbe Problem und bekomme es leider nicht gelöst.
Ich habe meinen physischen Schalter mit autocreate erstellt
Das sieht dann wie folgt aus:
eventMap
BI:off B0:on
deleteattr
fm_fav
999
deleteattr
room
Wohnzimmer
deleteattr
subType
switch
deleteattr
DEF
001A928F
LASTIODev
TCM310_0
MSGCNT
4
NAME
wz_RolloHoch
NR
47
STATE
off
TCM310_0_DestinationID
FFFFFFFF
TCM310_0_MSGCNT
4
TCM310_0_RSSI
68
TCM310_0_SecurityLevel
0
TCM310_0_SubTelNum
1
TCM310_0_TIME
2012-09-05 20:17:17
TYPE
EnOcean
Dann habe ich einen "Software Schalter" definiert:
CFGFN
DEF
FFBC4981
NAME
switch1
NR
128
STATE
off
TYPE
EnOcean
Vorher habe ich über get idbase meine ID ermittelt. Diese lautet FFBC4980.
Entsprechend habe ich den Schalter +1 mit FFBC4981 benannt.
Jetzt ist mir aber nicht klar, wie ich meinen physischen Schalter mit
meinem manuell erstellten verbinde bzw. angelernt bekommen.
Muss ich wie bei der eigentlichen Schalterprogrammierung die passenden
Eltako Aktoren in den Lernmodus versetzen (Schalter auf LRN drehen) oder
passiert das alles in der Software. Und wenn wie ?
Leider reagiert mein Rollo weder bisher weder auf meinen physischen (per
autocreate erstellten) noch auf meinen manuell erstellten Schalter.
Für Hilfe bin ich sehr dankbar.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo!
versetze Eltako-Aktor in den Lernmodus und lerne den Software-Switch
FFBC4981 wie einen physischen Taster an. Dann kannst Du mit dem
Software-Switch über FHEM schalten.
Den physichen Taster kannst Du mit FHEM nicht direkt emulieren! Daher zeigt
FHEM "nur" den Status des physischen Schalters an.
Viel Erfolg!
Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Also bringt mir die autocreate Funktion im Prinzip leider nichts ?! Werde
mich am We mal damit beschäftigen und berichten.
Am Montag, 10. September 2012 22:05:54 UTC+2 schrieb krikan:
>
> Hallo!
> versetze Eltako-Aktor in den Lernmodus und lerne den Software-Switch
> FFBC4981 wie einen physischen Taster an. Dann kannst Du mit dem
> Software-Switch über FHEM schalten.
> Den physichen Taster kannst Du mit FHEM nicht direkt emulieren! Daher
> zeigt FHEM "nur" den Status des physischen Schalters an.
> Viel Erfolg!
> Christian
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Also bringt mir die autocreate Funktion im Prinzip leider nichts ?!
Es erkennt immerhin alle normalen Wand-Schalter.
Wenn man Aktoren ohne Sender automatisch erkennen will, dann hat man ein
prinzipielles Problem. Oder ich habe einen Knoten im Hirn.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die autocreate Funktion ist bei Schaltern in der Tat nicht sehr hilfreich.
Sinnvoll hingegen ist sie bei dem erstellen der Thermostate. Diese werden
vom autocreate zuverlässig gefunden und können so vom ersten Tag ihre
logging Funktion übernehmen.
joerg
On Thursday, September 13, 2012 7:50:26 AM UTC+2, Sebastian wrote:
>
> Also bringt mir die autocreate Funktion im Prinzip leider nichts ?! Werde
> mich am We mal damit beschäftigen und berichten.
>
> Am Montag, 10. September 2012 22:05:54 UTC+2 schrieb krikan:
>>
>> Hallo!
>> versetze Eltako-Aktor in den Lernmodus und lerne den Software-Switch
>> FFBC4981 wie einen physischen Taster an. Dann kannst Du mit dem
>> Software-Switch über FHEM schalten.
>> Den physichen Taster kannst Du mit FHEM nicht direkt emulieren! Daher
>> zeigt FHEM "nur" den Status des physischen Schalters an.
>> Viel Erfolg!
>> Christian
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 13. September 2012 10:15:30 UTC+2 schrieb joerg:
>
> Die autocreate Funktion ist bei Schaltern in der Tat nicht sehr hilfreich.
>
>
Hallo Joerg!
Ich verstehe das nicht. Habe ich einen Gedankenfehler?
Die Stati der physischen Taster braucht man doch grundsätzlich bei allen
Steuerungsvarianten:
Indirekte Variante:
Realer Taster ist nicht und Software-Switch ist am Aktor angelernt.
Wenn der reale Taster gedrückt wird, muss FHEM das doch auswerten können,
um per Software-Switch den Aktor schalten zu können. Achtung: Wenn FHEM
nicht läuft, dann passiert beim Druck auf den Taster nichts. Nach meiner
Meinung nur für Komfortfunktionen nutzen.
Direkte Variante:
Realer Taster und Software-Switch sind am Aktor angelernt.
Um hier zu wissen, welchen Zustand der Aktor hat, musst Du den realen
Taster auch in FHEM auswerten. Die WEB-Darstellung wäre ohne
Berücksichtigung des Status des realen Tasters doch unter Umständen falsch.
Zugegeben, bei den neuen Bidi-Enocean-Aktoren (davon habe ich leider nur
3) könnte man dies (besser?) auch anders lösen :
Rücksignal des Aktors auf Schaltbefehl von FHEM auswerten.
Wenn ich die Taster manuell anlegen müsste, würde das wenig Spaß bereiten.
Danke,
Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Christian,
technisch gesehen betreibst Du zwei Sensornetzwerke parallel.
Einmal das Sensor-Netzwerk mit den "physischen" Schaltern und das
"Sensor-Netzwerk" welches aus der FB mit TCM besteht.
Die physischen Schalter (Sensoren) lernst du manuell bei den Aktoren an.
Somit ist der Kommunikationsweg:
"physischer Schalter" -> Aktor -> Verbraucher
Das hast Du wahrscheinlich gemacht
Den "FHEM-Schalter" lernst Du nach korrekter definition auch am Aktor an.
Somit ist der Kommunikationsweg:
Webfrontend->Fhem->FB/TCM->Aktor->Verbraucher
Der physische Schalter hat im zweiten Fall keine Bedeutung.
Du kannst die Veränderung der Schaltzustände die von einem physischen
Schalter getätigt wurden nicht so einfach im FHEM Frontend sichtbar machen.
(über notify aber wahrscheinlich möglich)
So schlimm ist das manuelle Anlegen der Schalter nicht. Man bekommt Übung
darin :-)
Joerg
On Thursday, September 13, 2012 10:26:05 AM UTC+2, krikan wrote:
>
>
> Am Donnerstag, 13. September 2012 10:15:30 UTC+2 schrieb joerg:
>>
>> Die autocreate Funktion ist bei Schaltern in der Tat nicht sehr hilfreich.
>>
>>
>
> Hallo Joerg!
>
> Ich verstehe das nicht. Habe ich einen Gedankenfehler?
>
> Die Stati der physischen Taster braucht man doch grundsätzlich bei allen
> Steuerungsvarianten:
>
> Indirekte Variante:
> Realer Taster ist nicht und Software-Switch ist am Aktor angelernt.
> Wenn der reale Taster gedrückt wird, muss FHEM das doch auswerten können,
> um per Software-Switch den Aktor schalten zu können. Achtung: Wenn FHEM
> nicht läuft, dann passiert beim Druck auf den Taster nichts. Nach meiner
> Meinung nur für Komfortfunktionen nutzen.
>
> Direkte Variante:
> Realer Taster und Software-Switch sind am Aktor angelernt.
> Um hier zu wissen, welchen Zustand der Aktor hat, musst Du den realen
> Taster auch in FHEM auswerten. Die WEB-Darstellung wäre ohne
> Berücksichtigung des Status des realen Tasters doch unter Umständen falsch.
> Zugegeben, bei den neuen Bidi-Enocean-Aktoren (davon habe ich leider nur
> 3) könnte man dies (besser?) auch anders lösen :
> Rücksignal des Aktors auf Schaltbefehl von FHEM auswerten.
>
> Wenn ich die Taster manuell anlegen müsste, würde das wenig Spaß bereiten.
>
> Danke,
> Christian
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Joerg!
Am Donnerstag, 13. September 2012 13:30:33 UTC+2 schrieb joerg:
>
> Hallo Christian,
>
> technisch gesehen betreibst Du zwei Sensornetzwerke parallel.
> Einmal das Sensor-Netzwerk mit den "physischen" Schaltern und das
> "Sensor-Netzwerk" welches aus der FB mit TCM besteht.
>
aber die will/muss ich koppeln...
>
> Die physischen Schalter (Sensoren) lernst du manuell bei den Aktoren an.
> Somit ist der Kommunikationsweg:
> "physischer Schalter" -> Aktor -> Verbraucher
> Das hast Du wahrscheinlich gemacht
>
Habe ich teilweise gemacht. Ist das, was ich als direkte Steuerungsvariante
bezeichnet habe.
> Den "FHEM-Schalter" lernst Du nach korrekter definition auch am Aktor an.
> Somit ist der Kommunikationsweg:
> Webfrontend->Fhem->FB/TCM->Aktor->Verbraucher
>
Einen FHEM-Switch habe ich immer am Aktor angelernt. Nicht nur bei den
direkt gesteuerten Aktoren, sondern auch wenn am Aktor kein physischer
Schalter angelernt ist (indirekte Variante: Taster->FHEM->Aktor).
>
> Der physische Schalter hat im zweiten Fall keine Bedeutung.
>
Du kannst die Veränderung der Schaltzustände die von einem physischen
> Schalter getätigt wurden nicht so einfach im FHEM Frontend sichtbar machen.
> (über notify aber wahrscheinlich möglich)
>
>
Doch physischer Schalter hat aus meiner Sicht immer eine Bedeutung. Ich
möchte unbedingt die Sichtbarkeit im Frontend. Wenn das nicht gegeben ist,
ist WAF weg und ich selbst fände es auch seltsam. Und darum brauche ich
auch die physischen Taster im FHEM. Die Abbildung im Frontend habe ich mit
folgendem notify erreicht:
define noWoDecke notify pWoDecke:o.* setstate fWoDecke %
wobei
pWoDecke=physischer Schalter
fWoDecke=FHEM-Switch
und jeweils
attr eventMap AI:on A0:off
Das o.* im Pattern nutze ich, damit nur die Stati on und off weitergegen
werden; ansonsten schießt mir event:released immer quer.
Das funktioniert anscheinend; bessere Vorschläge sind* gerne *willkommen ;-)
(Am Rande: Ich bin derzeit noch in der FHEM-Erprobungsphase; das ganze
läuft nur im Testbetrieb. Ich scheitere seit ca. 3 Wochen an der
Inbetriebnahme des MD15 und der Raffstoresteuerung mit dem FSB61. Bei
letzterem bekomme ich enocean.pm nicht so umgebastelt, dass die
Laufzeitsteuerung vernünftig funktioniert.)
> So schlimm ist das manuelle Anlegen der Schalter nicht. Man bekommt Übung
> darin :-)
>
> Joerg
>
Darum ist nach meiner Meinung autocreate auch für physische Taster
notwendig und ich will keine Übung im manuellen Anlegen haben ;-)
Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Ich scheitere seit ca. 3 Wochen an der Inbetriebnahme des MD15 ...
Daran bin ich auch gescheitert...
Allerdings war meine Motivation auch sehr begrenzt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Doch physischer Schalter hat aus meiner Sicht immer eine Bedeutung. Ich
> möchte unbedingt die Sichtbarkeit im Frontend. Wenn das nicht gegeben ist,
> ist WAF weg und ich selbst fände es auch seltsam. Und darum brauche ich
> auch die physischen Taster im FHEM. Die Abbildung im Frontend habe ich mit
> folgendem notify erreicht:
>
> define noWoDecke notify pWoDecke:o.* setstate fWoDecke %
>
> wobei
> pWoDecke=physischer Schalter
> fWoDecke=FHEM-Switch
> und jeweils
> attr eventMap AI:on A0:off
>
Hallo Christian
Deine losung funktioniert immer wenn Du eine 1:1:1-verhältnis zwischen
physischer Schalter und FHEM-Switch und aktuatoren.
FHEM-Switch und aktuatoren machen in der regel nuer sinn im 1:1-verhältnis.
Ich habe aber mehrere n:N:N
z.b Schlafzimmer
- ein einzehl_physischer_Schalter (AI:Light_on A0:Light_off) und
- ein doppel_physischer_Schalter (BI:Light_on B0:Light_off) und
- ein 4xphysischer_Schalter (BI:Light_on B0:Light_off)
fuer die gleiche lampe.
Der Doppel_physischer_Schalter steuert mir auch die Rollo (AI:Rollo_open A0:
Rollo_close) und der 4xphysischer_Schalter ist ein art von fehrnbedinung.
d.h ich muesste flessig fleissig mehrere define-notify mit viele if&else :(
immi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 13. September 2012 22:50:54 UTC+2 schrieb immi:
>
>
> - ein einzehl_physischer_Schalter (AI:Light_on A0:Light_off) und
> - ein doppel_physischer_Schalter (BI:Light_on B0:Light_off) und
> - ein 4xphysischer_Schalter (BI:Light_on B0:Light_off)
>
> fuer die gleiche lampe.
> Der Doppel_physischer_Schalter steuert mir auch die Rollo (AI:Rollo_open
> A0:Rollo_close) und der 4xphysischer_Schalter ist ein art von
> fehrnbedinung.
> d.h ich muesste flessig fleissig mehrere define-notify mit viele if&else :(
>
> immi
>
Hallo Immi!
Dann kannst Du in Deinem Fhem-Frontend nicht erkennen, ob die Lampe im
Schlafzimmer an ist? Kann doch nicht sein. Das wäre das KO-Kriterium für
Fhem.
Sorry, bin verwirrt; vielleicht sind meine Ausführung unverständlich. Ich
versuch es noch mal:
Im Frontend möchte ich den Zustand jedes Verbrauchers erkennen könnnen.
Daher muss FHEM immer den Schaltzustand des zugehörigen Aktors wissen.
Sofern der Aktor nur über FHEM geschaltet wird, ist der Schaltzustand FHEM
immer bekannt (indirekte Steuerung). Wenn der Aktor direkt über einen
Taster geschaltet wird (direkte Steuerung), muss FHEM bei undirektionalen
Enocean-Aktoren im Funkverkehr die physichen Taster belauschen, um eine
korrekte Abbildung im Frontend zu erreichen. Ich brauche daher alle
physischen Taster in FHEM (autocreate!).
Mein Weg:
Jedem Aktor wird genau ein FHEM-Switch angelernt. (AI = on; A0 = off. Die
anderen Schaltzustände des FHEM-Switches (Bx-Dx) nutze ich nicht)
Im Frontend soll dieser FHEM-Switch immer den korrekten Schaltzustand
anzeigen.
Dies passiert bei indirekter Steuerung eben automatisch.
Bei der direkten Steuerung muss ich jeden direkt im Aktor angelernten,
physischen Taster überwachen. Per genannter notify-Regel wird bei Druck auf
den physischen Taster der state des FHEM-Switches fürs Frontend anpassen.
Tatsächlich habe ich bisher immer eine 1:1:1 Verbindung getestet. Aber das
sollte doch auch bei einer n:N:N möglich sein. Dem FHEM-Switch für den
Deckenlampen-Aktor muss doch nur per notify der letzte physische
Tasterdruck als state zugeordnet werden, damit im Frontend der
Schaltzustand der Lampe erkennbar ist. Jeder Deiner physischen
Schalter/Schaltzustände für die Deckenlampe bekäme dazu die
passende notify-Regel für den FHEM-switch. Dafür benötige ich doch keine
if&else!? (Ich will nicht den state der physischen Taster in FHEM
anpassen!). Den FHEM-Switch für Dein Rollo müsste man bei physischen
Tastendruck per notify ebenfalls im state anpassen.
Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei
direkter Steuerung so leider nicht vernünftig lösen.
Gruß, Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei
> direkter Steuerung so leider nicht vernünftig lösen.
Wieso nicht? Will sagen, ich verstehe das Problem noch nicht.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudolf
kein Problem. Nuer mein deutsch wahrscheinlich :(
Hallo Christian
> Dann kannst Du in Deinem Fhem-Frontend nicht erkennen, ob die Lampe im
> Schlafzimmer an ist? Kann doch nicht sein....
>
Doch. Ich kann in Meinem Fhem-Frontend erkennen, ob die Lampe im
Schlafzimmer an ist.
> Bei der direkten Steuerung muss ich jeden direkt im Aktor angelernten,
> physischen Taster überwachen. Per genannter notify-Regel wird bei Druck auf
> den physischen Taster der state des FHEM-Switches fürs Frontend anpassen.
>
Genau das gleiche mache ich. Dafuer benutze ich aber bei n:N:N eine/mehrere
Bedingte Anweisung in "define-notify"
d.h fleissig unelegante Arbeit. :)
immi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Freitag, 14. September 2012 08:47:24 UTC+2 schrieb Rudolf Koenig:
>
> > Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei
> > direkter Steuerung so leider nicht vern�nftig l�sen.
>
> Wieso nicht? Will sagen, ich verstehe das Problem noch nicht.
>
Hallo Rudi,
Die alten unidirektionalen Dimmer reagieren folgendermaßen auf die direkt
eingelernten Taster:
kurzer phy. Tastendruck = Dimmer an/aus
langer phy. Tastendruck = Dimmer auf/abdimmen
Was ein langer und kurzer Tastendruck ist und auf wieviel % die Dimmer dann
stehen oder gar an oder aus sind, kann ich leider aus den phy. Tastendruck
nicht vernünftig ableiten. Ein Rücksignal liefern die unidirektionalen
Dimmer leider auch nicht. Ein notify an den FHEM-Switch kann ich daher
nicht sinnvoll weitergeben. Nach ein paar phy. Tastenbetätigungen stimmt
der state des FHEM-Switches nicht mehr mit der Realität überein. Wen ich
dann den state des FHEM-Switches für Komfortfunktionen (bspw. Überwachung)
nutzen will, habe ich nur noch Zufallsergebnisse. Einzig mir bekannter
Ausweg: Nur indirekte Steuerung der Dimmer über FHEM
(Taster->FHEM->Dimmer); aber dann bei FHEM-Ausfall, keine Dimmer-Steuerung
möglich.
Oder, habe ich mein grundsätzliches Problem noch nicht vernünftig erklärt?
Gruß, Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Oder, habe ich mein grundsätzliches Problem noch nicht vernünftig erklärt?
Doch, ich meine das jetzt zu verstehen. Loesung habe ich aber keine :(
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Freitag, 14. September 2012 11:19:20 UTC+2 schrieb Rudolf Koenig:
>
> > Oder, habe ich mein grunds�tzliches Problem noch nicht vern�nftig
> erkl�rt?
>
> Doch, ich meine das jetzt zu verstehen. Loesung habe ich aber keine
Das ist softwareseitig wohl nicht zu lösen. Einzig vernünftige, aber nicht
bezahlbare, Lösung ist wohl Austausch gegen Bidi-Dimmaktoren. Bidi-Aktoren
würden die Notify-Menge sowieso verschlanken....
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hat denn jemand alternativ Erfahrungen mit dem von Eltako angebotenen
Produkt FAM-USB ?
Lassen sich damit die Zustände einfacher (physisch/software) ablesen ? Und
wie ist insgesamt das Handling ?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Sebastian
> Hat denn jemand alternativ Erfahrungen mit dem von Eltako angebotenen
> Produkt FAM-USB ?
>
Wozu alternativ? Der FAM-USB ist doch nur das Hardware-Gateway. Welchen
Chip (TCMxxx) hat das Ding? Wird es von FHEM erkannt? Wenn ja, ändert das
meines Wissens nach derzeit(?) nichts am Handling. Zumindest ist das bei
meinen getesteten Gateways so (USB300, Bootup und BOR).
> Lassen sich damit die Zustände einfacher (physisch/software) ablesen ? Und
> wie ist insgesamt das Handling ?
>
Im Prinzip ist das Problem doch überall gleich -> man kann bei
ENOCEAN keine phy. Taster-Adressen per Software emulieren; wenn man einen
Aktor gleichzeitig mit eingelernten Software-Switch und phy. Taster
schalten will, muss man den Zustand des Aktors ermitteln. Bei den neuen
Bidi-Aktoren relativ einfach. Bei meinen alten unidirektionalen nur
schwierig (Sorry, wenn ich Dich mit meinen Ausführung oben im Thread
verwirrt habe).
Vielleicht sagst Du mal, was Du für Komponenten hast. Wenn Du den FAM schon
hast, kannst Du auch FVS nutzen. Nach meinem Kenntnisstand aus
2009, erkennst Du auch dort das grundsätzliche Problem.
Gruß, Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sorry, ich meinte nicht den FAM-USB sondern die von Dir auch genannte
Software FVS - hast du damit bereits Erfahrungen gemacht ?
Mit dieser müsste man nur leider ständig einen Computer im Netzwerk haben,
während FHEM auf der Fritzbox läuft.
Ich habe einen BSC Smart Connect EnOcean TCM310 USB Stick.
Es wird sich noch um die alten unidirektionalen Aktoren handeln, da ich das
System seit 2 Jahren habe.
Und da ich in dem Thema absolut kein Experte bin, möchte ich es mir so
einfach wie möglich machen.
Grüße, Sebastian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Samstag, 15. September 2012 13:56:46 UTC+2 schrieb Sebastian:
>
> Sorry, ich meinte nicht den FAM-USB sondern die von Dir auch genannte
> Software FVS - hast du damit bereits Erfahrungen gemacht ?
> Mit dieser müsste man nur leider ständig einen Computer im Netzwerk haben,
> während FHEM auf der Fritzbox läuft.
> Ich habe einen BSC Smart Connect EnOcean TCM310 USB Stick.
> Es wird sich noch um die alten unidirektionalen Aktoren handeln, da ich
> das System seit 2 Jahren habe.
> Und da ich in dem Thema absolut kein Experte bin, möchte ich es mir so
> einfach wie möglich machen.
>
Ja, ich kenne FVS. Aber nur bis Entwicklungsstand Anfang 2010. Mir gefiel
es persönlich nicht. Probier es doch aus. Es gibt - glaube ich -
Testversionen (FVS oder als Original-Herstellerprodukt BSC Bosehome).
Produktiv läuft bei mir das Konkurrenzprodukt myHomecontrol. Das setzt aber
auch einen ständig laufenden Server voraus; aber den brauche ich sowieso.
Beide Programme halte ich für einen recht einfachen Weg für
Enocean-PC-Steuerung. Die Handbücher zu den Programmen geben Dir jeweils
einen guten Überblick -auch allgemein- zu Enocean.
Ob FHEM für "so einfach wie möglich machen" das Richtige ist, bezweifel ich
ein wenig. Es bietet Dir aber eine enorm hohe Flexibilität. Darum teste ich
derzeit intensiv FHEM und investiere (zu viel) Zeit vor dem PC (siehst Du
an meiner schnellen Reaktionszeit auf Deine Frage;-)) mit ungewissen
Ausgang...
Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com