Originally posted by: <email address deleted>
Hallo,
ich habe angefangen mich mit fhem und Enocean zu befassen.
Als erstes habe ich versucht einen Eltako-Dimmer direkt mit dem EUL
anzusteuern,
Es funtioniert soweit, ich bin mir nur nicht sicher, ob ich es richtig
in die fhem Strukturen einpaßt habe.
Es wurden 2 subTypes hinzugefügt. Einer für die Rückmeldung des Aktors
(dimmer), einer zum Ansteuern des Dimmers (dimmCtrl).
dimmer liefert zwei Events: state und dimmValue
dimmCtrl hat 2 set-Kommandos: teach und dimm.
Genaue Beschreibung unten (in der angehängten Commit-Messages).
Eigentlich wollte ich das Ganze möglichst universell halten, aber
Eltako hat die (Central-Control-)Profile scheinbar nicht exakt nach
den EEP implementiert, so daß es wohl nur mit Eltako-Dimmern
funktioniert.
So richtig gefällt mir das mit den zwei Devices nicht. Besser wäre es,
man hätte nur das dimmer-device und könnte dem dann einen der 128-
SubIds zuordnen und damit den Dimmer ansteuern. Geht das ? Kann man im
Code auf die BaseId des EUL zugreifen ?
Der Sourcecode liegt in einem github-repo auf dem branch
'enocean' (der Branch 'master' ist ein Mirror des svn-repos):
git://github.com/mhop/fhem-mirror.git
Kurze Erläuterung zum auschecken:
repo holen:
git clone git://github.com/mhop/fhem-mirror.git
legt ein Verzeichnis fhem-mirror an. Dorthin wechseln
cd fhem-mirror
auf den enocean-branch wechseln:
git checkout -t origin/enocean
Differenzen zeigen
git diff master
Wenn Ihr wollt kann ich auch patches posten.
Grüße
Marc
Hier die Commit-Messages meiner Änderungen
commit 4a1c808cd4a50a8f537480f08eea3aeefe8773af
Author: Marc Hoppe
Date: Mon Dec 26 12:42:02 2011 +0100
Enocean: added new subType 'dimmer'. The responses of a (Eltako-
FUD61NPN)-Dimmer
are evaluated and the data is added to the events state:(on/off)
and
dimmValue:(Percent-Value)
After you defined the device (here:mydimmer) you need to set some
attributes:
attr mydimmer subType dimmer
attr mydimmer eventMap B0:on BI:off
commit 7d9d7ca20e08f150ed4999a0096708b29cc9830b
Author: Marc Hoppe
Date: Mon Dec 26 19:34:30 2011 +0100
Enocean: new subType dimmCtrl - To send dimm-value directly to
(Eltako-)Dimm-actor.
There are 2 new Commands for this subtype:
- teach
- dimm dimmVal [time] [on/off]
dimmVal(%): 0-100
time: 0-255 dimm-time, where 0:default 1:fastest
255:slowest
on/off: on:lamp on off:lamp off
Usage:
-define an Enocean device with id from your idbase-range:
define mydimctrl EnOcean ffabcd81
-set subtype:
attr mydimctrl subType dimmCtrl
-set the actor to learn mode
-send the teach command:
set mydimctrl teach
-actor back to normal-mode
-now you can control the dimmer
set mydimctrl dimm 50 100 on
time is optional (then 0 is used)
on/off is optional (then on is used)
The commands (A5/38/08) are not 100% compliant to the EEP, I think
it will only work with eltako-Dimmers
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> ich habe angefangen mich mit fhem und Enocean zu befassen.
Klasse, hab die Aenderungen auch uebernommen. Hoffentlich habe ich nichts
uebersehen, da ich inzwischen auch einiges geaendert habe. Testen konnte ich es
mangels dimmer nicht. Du kannst mir gerne auch ein sourceforge-id schicken
zwecks Aufgaben-Vereinfachung.
> Es funtioniert soweit, ich bin mir nur nicht sicher, ob ich es richtig
> in die fhem Strukturen einpaßt habe.
Was mir fehlt ist ein Eintrag in commandref.html :)
> Es wurden 2 subTypes hinzugefügt. Einer für die Rückmeldung des Aktors
> (dimmer), einer zum Ansteuern des Dimmers (dimmCtrl).
> dimmer liefert zwei Events: state und dimmValue
> dimmCtrl hat 2 set-Kommandos: teach und dimm.
Verstehe ich nicht. Wozu braucht man zwei Geraete? Bzw. kann man die beiden
irgendwie als zusammengehoerig erkennen und in fhem nur eins haben? Die
Frontends sind auf "Gewaltenteilung" nicht so recht vorbereitet.
> Genaue Beschreibung unten (in der angehängten Commit-Messages).
Wie kann man die anschauen?
> So richtig gefällt mir das mit den zwei Devices nicht. Besser wäre es,
> man hätte nur das dimmer-device und könnte dem dann einen der 128-
> SubIds zuordnen und damit den Dimmer ansteuern. Geht das ? Kann man im
> Code auf die BaseId des EUL zugreifen ?
Sicher, wir muessen im TCM_Define() BaseID abfragen und es in $hash->{BASEID}
speichern. Dann waere es in EnOcean_Parse unter $iohash->{BASEID} zu finden,
oder beim Set unter $hash->{IODev}{BASEID}.
Z.Zt. wird in commandref.html das manuelle Abfragen/Setzen der ID vorgeschlagen.
support@enocean.com hat mir aber gesagt, dass das "fest eingebrannte id"
verwendet werden sollte, und nicht der im Flash 10-mal aenderbare (==BaseID).
Ersteres wird mWn automatisch eingesetzt, wenn man einen ID verwendet, was nicht
mit FF anfaengt.
Bin im moment verunsichert, weil das ein Austausch des USB-Sticks unmoeglich
macht. Und wie man den fest eingebrannten rauskriegt, weiss ich auch nicht.
Was ist Deine Meinung dazu?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Klasse, hab die Aenderungen auch uebernommen.
Und gleich in die neue Release. Damit habe ich jetzt nicht gerechnet.
Inzwischen habe ich das Wiki und die developer-Doku entdeckt. Demnach
habe ich ein falsches Kommando (dimm statt dimto/dimup/dimdown) und
Event (dimmValue statt level) verwendet.
Das will ich nochmal ändern.
> Testen konnte ich es mangels dimmer nicht.
Ich hab die Release probiert. Scheint alles bestens zu sein.
> Du kannst mir gerne auch ein sourceforge-id schicken
Kommt per PM.
> Was mir fehlt ist ein Eintrag in commandref.html :)
hmm, ich liebe doku...mal sehen.
> Verstehe ich nicht. Wozu braucht man zwei Geraete?
Das Problem ist, dass ich eine Enocean ID für den zu empfangenden
Aktor brauche (Eltako kann bidirektional) und eine andere wenn der EUL
'Sensor' spielt und zum Aktor sendet.
Besser wäre es natürlich diese Sende-ID als Attribut dem Aktor
zuzuorden.
>> Genaue Beschreibung unten (in der angeh ngten Commit-Messages).
> Wie kann man die anschauen?
Folgten doch als Text (der Englische)
> Sicher, wir muessen im TCM_Define() BaseID abfragen und es in $hash->{BASEID}
> speichern. Dann waere es in EnOcean_Parse unter $iohash->{BASEID} zu finden,
> oder beim Set unter $hash->{IODev}{BASEID}.
Das werd ich mal einbauen (automatisch beim öffnen des EUL).
> Z.Zt. wird in commandref.html das manuelle Abfragen/Setzen der ID vorgeschlagen.
> supp...@enocean.com hat mir aber gesagt, dass das "fest eingebrannte id"
> verwendet werden sollte, und nicht der im Flash 10-mal aenderbare (==BaseID).
> Ersteres wird mWn automatisch eingesetzt, wenn man einen ID verwendet, was nicht
> mit FF anfaengt.
Ich habe das so verstanden:
Man braucht zum Ansteuern jedes Aktors eine eigene ID.
Wenn ich die eingebrannte Chip-ID verwende, kann ich also nur einen
Aktor ansteuern.
Wenn ich die Base-ID verwende kann ich die letzten 7 Bits selber
bestimmen, also 128 Geräte ansteuern.
> Bin im moment verunsichert, weil das ein Austausch des USB-Sticks unmoeglich macht
Das ist ein weiterer Grund fuer das Verwenden der Base-Id
> Und wie man den fest eingebrannten rauskriegt, weiss ich auch nicht.
Hmm wo du es sagst. Ich auch nicht.
Da wir aber mehrere Geräte ansteuern wollen ist wohl nur die BaseId
geeignet.
Ich werde mal folgendes angehen:
- BaseId beim Start des EUL lesen und in $hash->{BASEID} speichern
- Kommandos zum Dimmer: dimto, dimup, dimmdown, on, off, teach
- Events level, on/off (automatisch fuer den subtype ohne manuell ein
attr EventMap zu setzen)
- nur noch ein Gerät und mit 'attr subId' eine der 128 Ids des EUL
verwenden
- Da die Hersteller die Auslegung des Enocean-Standards scheinbar sehr
locker sehen, will ich den subtype in eltakodimmer aendern.
- Ich hab noch einen eltako Stromstoßschalter, den will ich auch noch
einbauen.
- Evtl. noch die anderen Eltako-Typen ohne Test nach Eltako-Doku.
und ..... commandref.html ergänzen
falls schon jemand was ähnliches gemacht hat (man will ja keine
doppelte Arbeit machen) oder Einwände hat (man will ja keine
unsinnige Arbeit machen) , bitte melden.
Marc
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hello Marc
i've tested Your code wih Eltako dimmer FUD61NPN and i don't
understand why it generates two messages with different id's for org=5
and org=7 ? did you have the same issue?
regards
noxx
On 3 Sty, 21:50, Marc Hoppe wrote:
> > Klasse, hab die Aenderungen auch uebernommen.
>
> Und gleich in die neue Release. Damit habe ich jetzt nicht gerechnet.
> Inzwischen habe ich das Wiki und die developer-Doku entdeckt. Demnach
> habe ich ein falsches Kommando (dimm statt dimto/dimup/dimdown) und
> Event (dimmValue statt level) verwendet.
> Das will ich nochmal ändern.
>
> > Testen konnte ich es mangels dimmer nicht.
>
> Ich hab die Release probiert. Scheint alles bestens zu sein.
>
> > Du kannst mir gerne auch ein sourceforge-id schicken
>
> Kommt per PM.
>
> > Was mir fehlt ist ein Eintrag in commandref.html :)
>
> hmm, ich liebe doku...mal sehen.
>
> > Verstehe ich nicht. Wozu braucht man zwei Geraete?
>
> Das Problem ist, dass ich eine Enocean ID für den zu empfangenden
> Aktor brauche (Eltako kann bidirektional) und eine andere wenn der EUL
> 'Sensor' spielt und zum Aktor sendet.
> Besser wäre es natürlich diese Sende-ID als Attribut dem Aktor
> zuzuorden.
>
> >> Genaue Beschreibung unten (in der angeh ngten Commit-Messages).
> > Wie kann man die anschauen?
>
> Folgten doch als Text (der Englische)
>
> > Sicher, wir muessen im TCM_Define() BaseID abfragen und es in $hash->{BASEID}
> > speichern. Dann waere es in EnOcean_Parse unter $iohash->{BASEID} zu finden,
> > oder beim Set unter $hash->{IODev}{BASEID}.
>
> Das werd ich mal einbauen (automatisch beim öffnen des EUL).
>
> > Z.Zt. wird in commandref.html das manuelle Abfragen/Setzen der ID vorgeschlagen.
> > supp...@enocean.com hat mir aber gesagt, dass das "fest eingebrannte id"
> > verwendet werden sollte, und nicht der im Flash 10-mal aenderbare (==BaseID).
> > Ersteres wird mWn automatisch eingesetzt, wenn man einen ID verwendet, was nicht
> > mit FF anfaengt.
>
> Ich habe das so verstanden:
> Man braucht zum Ansteuern jedes Aktors eine eigene ID.
> Wenn ich die eingebrannte Chip-ID verwende, kann ich also nur einen
> Aktor ansteuern.
> Wenn ich die Base-ID verwende kann ich die letzten 7 Bits selber
> bestimmen, also 128 Geräte ansteuern.
>
> > Bin im moment verunsichert, weil das ein Austausch des USB-Sticks unmoeglich macht
>
> Das ist ein weiterer Grund fuer das Verwenden der Base-Id
>
> > Und wie man den fest eingebrannten rauskriegt, weiss ich auch nicht.
>
> Hmm wo du es sagst. Ich auch nicht.
> Da wir aber mehrere Geräte ansteuern wollen ist wohl nur die BaseId
> geeignet.
>
> Ich werde mal folgendes angehen:
> - BaseId beim Start des EUL lesen und in $hash->{BASEID} speichern
> - Kommandos zum Dimmer: dimto, dimup, dimmdown, on, off, teach
> - Events level, on/off (automatisch fuer den subtype ohne manuell ein
> attr EventMap zu setzen)
> - nur noch ein Gerät und mit 'attr subId' eine der 128 Ids des EUL
> verwenden
> - Da die Hersteller die Auslegung des Enocean-Standards scheinbar sehr
> locker sehen, will ich den subtype in eltakodimmer aendern.
> - Ich hab noch einen eltako Stromstoßschalter, den will ich auch noch
> einbauen.
> - Evtl. noch die anderen Eltako-Typen ohne Test nach Eltako-Doku.
>
> und ..... commandref.html ergänzen
>
> falls schon jemand was ähnliches gemacht hat (man will ja keine
> doppelte Arbeit machen) oder Einwände hat (man will ja keine
> unsinnige Arbeit machen) , bitte melden.
>
> Marc
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hello noxx,
> i've tested Your code wih Eltako dimmer FUD61NPN and i don't
> understand why it generates two messages with different id's for org=5
> and org=7 ? did you have the same issue?
The behavour is correct.
It is documented in
http://www.eltako.com/fileadmin/downloads/en/_catalogue/wireless_system_chapterT_low_res.pdf
on the last page (T-9)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hello Marc
thanks for the answer but if this behaviour is correct and one device
is sending messages with two different id's so how can You can
distinguish that they belong to one device , and further more how
system can know different between for example : FADS60-230V relay and
dimmer FUD61NP-230V ?
On 4 Sty, 18:46, Marc Hoppe wrote:
> Hello noxx,
>
> > i've tested Your code wih Eltako dimmer FUD61NPN and i don't
> > understand why it generates two messages with different id's for org=5
> > and org=7 ? did you have the same issue?
>
> The behavour is correct.
>
> It is documented inhttp://www.eltako.com/fileadmin/downloads/en/_catalogue/wireless_syst...
> on the last page (T-9)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@noxx
Sorry, it was a misunderstanding on my side.
There is only one ID for my FUD61NPN dimmer (wohn.dimm)
I logged the Data:
Switched on by Wall-Switch(wohn.schalt):
2012.01.04 20:46:42 4: wohn.schalt: ORG:F6 DATA:10 ID:00222B33 STATUS:
30
2012.01.04 20:46:42 4: wohn.schalt: ORG:F6 DATA:00 ID:00222B33 STATUS:
20
2012.01.04 20:46:43 4: wohn.dimm: ORG:F6 DATA:70 ID:01027D33 STATUS:30
2012.01.04 20:46:47 4: wohn.dimm: ORG:A5 DATA:02480009 ID:01027D33
STATUS:00
Switched on by EUL:
2012.01.04 20:52:18 2: dimmCtrl.dimm: A502370009FFA8958100
2012.01.04 20:52:18 4: /fhem?cmd=set+wohn.dimmCtrl+dimm+55 / RL: 937 /
text/html; charset=UTF-8 / Content-Encoding: gzip
2012.01.04 20:52:19 4: wohn.dimm: ORG:F6 DATA:70 ID:01027D33 STATUS:30
2012.01.04 20:52:24 4: wohn.dimm: ORG:A5 DATA:02370009 ID:01027D33
STATUS:00
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Marc,
strange for me is that i get two different id from one device:
2012.01.03 13:37:43 2: dimmCtrl.dimm: A5026401090102971E00
2012.01.03 13:37:44 2: EnO_switch_0102512C: ORG:A5 DATA:02640109 ID:
0102512C STATUS:01
2012.01.03 13:37:45 2: EnO_switch_0102971E: ORG:F6 DATA:70 ID:0102971E
STATUS:30
2012.01.03 13:37:50 2: EnO_switch_0102971E: ORG:A5 DATA:02640009 ID:
0102971E STATUS:00
also i don't know why status:01 with this second id.
Also like i wrote before is there way to know different between
FADS60-230V relay and
dimmer FUD61NP-230V ?
On 4 Sty, 20:56, Marc Hoppe wrote:
> @noxx
>
> Sorry, it was a misunderstanding on my side.
> There is only one ID for my FUD61NPN dimmer (wohn.dimm)
>
> I logged the Data:
>
> Switched on by Wall-Switch(wohn.schalt):
> 2012.01.04 20:46:42 4: wohn.schalt: ORG:F6 DATA:10 ID:00222B33 STATUS:
> 30
> 2012.01.04 20:46:42 4: wohn.schalt: ORG:F6 DATA:00 ID:00222B33 STATUS:
> 20
> 2012.01.04 20:46:43 4: wohn.dimm: ORG:F6 DATA:70 ID:01027D33 STATUS:30
> 2012.01.04 20:46:47 4: wohn.dimm: ORG:A5 DATA:02480009 ID:01027D33
> STATUS:00
>
> Switched on by EUL:
> 2012.01.04 20:52:18 2: dimmCtrl.dimm: A502370009FFA8958100
> 2012.01.04 20:52:18 4: /fhem?cmd=set+wohn.dimmCtrl+dimm+55 / RL: 937 /
> text/html; charset=UTF-8 / Content-Encoding: gzip
> 2012.01.04 20:52:19 4: wohn.dimm: ORG:F6 DATA:70 ID:01027D33 STATUS:30
> 2012.01.04 20:52:24 4: wohn.dimm: ORG:A5 DATA:02370009 ID:01027D33
> STATUS:00
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@noxx
You do not use a base-id.
> 2012.01.03 13:37:43 2: dimmCtrl.dimm: A5026401090102971E00
The ID you use is: 0102971E, but the EUL will send it's Chip-ID
instead.
In a base-Id the first 9 bits need to be set (FF8...).
When you use the base-id you can control 128 different actuators (the
last 7 bits can be changed)
I think the second ID you see is from another device you also teached
the Chip-Id of the EUL.
Try this:
-Clear all the learned devices in the dimmer
-read the the base-id : 'get EUL baseid'
-the id you get will start with FF and end in 80 or 00 (mine is
FFA89580)
-set the cimmctrl id to the base-id you read and set last bit to 1
(sub-id = 1) (mine is FFA89581)
-now teach dimmer to dimmctrl again.
If you want to Control other devices use another subid in range 0-
EF(my range FFA8580-FFA85FF)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
oops
> ... subid in range 0-EF ...
should be: subid in range 0-7F
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hello Marc
i did like You said and it looks OK so getting things together
1. Every dimmer which will be auto-created with fhem has to get
subtype: dimmer
2 Additionally to this created device will have to be added another
device with subtype : dimmerCtrl wit the appropriate sub-id range.
but is there way to discover during auto create that this deceive is
dimmer? that system will add automatically correct subtype?
On 4 Sty, 23:22, Marc Hoppe wrote:
> @noxx
>
> You do not use a base-id.> 2012.01.03 13:37:43 2: dimmCtrl.dimm: A5026401090102971E00
>
> The ID you use is: 0102971E, but theEULwill send it's Chip-ID
> instead.
> In a base-Id the first 9 bits need to be set (FF8...).
> When you use the base-id you can control 128 different actuators (the
> last 7 bits can be changed)
> I think the second ID you see is from another device you also teached
> the Chip-Id of theEUL.
>
> Try this:
> -Clear all the learned devices in the dimmer
> -read the the base-id : 'getEULbaseid'
> -the id you get will start with FF and end in 80 or 00 (mine is
> FFA89580)
> -set the cimmctrl id to the base-id you read and set last bit to 1
> (sub-id = 1) (mine is FFA89581)
> -now teach dimmer to dimmctrl again.
>
> If you want to Control other devices use another subid in range 0-
> EF(my range FFA8580-FFA85FF)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi noxx,
On 7 Jan., 20:55, noxx wrote:
> 2 Additionally to this created device will have to be added another
> device with subtype : dimmerCtrl wit the appropriate sub-id range.
I am going to change this. There will be an attribute 'subid' in
dimmer,
so we do not need dimmctrl anymore. (Details in the last german
message above,
try google translate).
> but is there way to discover during auto create that this deceive is
> dimmer? that system will add automatically correct subtype?
The onocean-protocol is little bit hmm ... strange. The element the
dimmer sends is of type A5/38/08 but you can see only the A5 in the
message. For the rest you need to know which type of data the actuator
sends to interpret the message.
Maybe it will work another way. When we first define the Device with a
dummy-id the return data of the teach command could be used to
identify the device. I will try to implement it.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Marc,
On 8 Sty, 22:03, Marc Hoppe wrote:
> Hi noxx,
>
> On 7 Jan., 20:55, noxx wrote:> 2 Additionally to this created device will have to be added another
> > device with subtype : dimmerCtrl wit the appropriate sub-id range.
>
> I am going to change this. There will be an attribute 'subid' in
> dimmer,
> so we do not need dimmctrl anymore. (Details in the last german
> message above,
> try google translate).
>
> > but is there way to discover during auto create that this deceive is
> > dimmer? that system will add automatically correct subtype?
>
> The onocean-protocol is little bit hmm ... strange. The element the
> dimmer sends is of type A5/38/08 but you can see only the A5 in the
> message. For the rest you need to know which type of data the actuator
> sends to interpret the message.
>
> Maybe it will work another way. When we first define the Device with a
> dummy-id the return data of the teach command could be used to
> identify the device. I will try to implement it.
, additionally to that:
1. I talk to the Eltako Engineers and the replay to me how They are
checking for bidirectional actuators types:
so we will have to make in fhem two subtypes for bidirectional
actuators :
a) Relay
b) Dimmer
Now how to recognize?
If we receive a telegram with a single ID with both ORG 5 and ORG 7 it
comes from a dimmer.
Else
if we receive only ORG 5 then check Data_byte_3 -----------if will
be 0x70 for ON and 0x50 for OFF -----------Then it will be 1 channel
RELAY
Else additional 0x30 for ON and 0x10 for OFF----------------- then it
will be 2 channel RELAY.
Exception is FSB61 (blind or shade control) 0x70 = end position up,
0x50 end position down, 0x00 motor is currently running
Also: it will be good to make table will all telegrams (1. RPS / 1BS
2. 4BS) parsed like it is done in for MD15 and for manufacturers, to
have in AtrrList all needed subtypes for EnOcean protocol with
additional Eltako telegrams .
Regards
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Derzeit versuche ich Eltako Dimmer FUD70-230V und FSG70/1-10V in Fhem zu
parameterieren. Ein- und Ausschalten über die "switch"-Funktion ist
möglich. Die Dimmfunktionen werde ich jetzt testen. Zwei Fragen hierzu:
- Welcher Sensortyp ist dabei zu verwenden? Lt. Anleitung gibt es
Universal-, Richtung- und Lichtszenentaster sowie den PC-Modus (Eltako
FVS-Software).
- Sind die Änderungen und Ergänzungen, die diskutiert wurden, z. B. dimmup,
schon umgesetzt? In der aktuellen 10_EnOcean-Datei, die verteilt wird,
scheint noch der unten beschriebene Stand enthalten zu sein.
Am Dienstag, 27. Dezember 2011 22:11:55 UTC+1 schrieb Marc Hoppe:
> Hallo,
>
> ich habe angefangen mich mit fhem und Enocean zu befassen.
> Als erstes habe ich versucht einen Eltako-Dimmer direkt mit dem EUL
> anzusteuern,
> Es funtioniert soweit, ich bin mir nur nicht sicher, ob ich es richtig
> in die fhem Strukturen einpaßt habe.
> Es wurden 2 subTypes hinzugefügt. Einer für die Rückmeldung des Aktors
> (dimmer), einer zum Ansteuern des Dimmers (dimmCtrl).
> dimmer liefert zwei Events: state und dimmValue
> dimmCtrl hat 2 set-Kommandos: teach und dimm.
> Genaue Beschreibung unten (in der angehängten Commit-Messages).
>
> Eigentlich wollte ich das Ganze möglichst universell halten, aber
> Eltako hat die (Central-Control-)Profile scheinbar nicht exakt nach
> den EEP implementiert, so daß es wohl nur mit Eltako-Dimmern
> funktioniert.
>
> So richtig gefällt mir das mit den zwei Devices nicht. Besser wäre es,
> man hätte nur das dimmer-device und könnte dem dann einen der 128-
> SubIds zuordnen und damit den Dimmer ansteuern. Geht das ? Kann man im
> Code auf die BaseId des EUL zugreifen ?
>
> Der Sourcecode liegt in einem github-repo auf dem branch
> 'enocean' (der Branch 'master' ist ein Mirror des svn-repos):
> git://github.com/mhop/fhem-mirror.git
>
> Kurze Erläuterung zum auschecken:
> repo holen:
> git clone git://github.com/mhop/fhem-mirror.git
> legt ein Verzeichnis fhem-mirror an. Dorthin wechseln
> cd fhem-mirror
> auf den enocean-branch wechseln:
> git checkout -t origin/enocean
>
> Differenzen zeigen
> git diff master
>
> Wenn Ihr wollt kann ich auch patches posten.
>
> Grüße
> Marc
>
>
>
> Hier die Commit-Messages meiner Änderungen
>
> commit 4a1c808cd4a50a8f537480f08eea3aeefe8773af
> Author: Marc Hoppe
> Date: Mon Dec 26 12:42:02 2011 +0100
>
> Enocean: added new subType 'dimmer'. The responses of a (Eltako-
> FUD61NPN)-Dimmer
> are evaluated and the data is added to the events state:(on/off)
> and
> dimmValue:(Percent-Value)
>
> After you defined the device (here:mydimmer) you need to set some
> attributes:
>
> attr mydimmer subType dimmer
> attr mydimmer eventMap B0:on BI:off
>
> commit 7d9d7ca20e08f150ed4999a0096708b29cc9830b
> Author: Marc Hoppe
> Date: Mon Dec 26 19:34:30 2011 +0100
>
> Enocean: new subType dimmCtrl - To send dimm-value directly to
> (Eltako-)Dimm-actor.
> There are 2 new Commands for this subtype:
> - teach
> - dimm dimmVal [time] [on/off]
> dimmVal(%): 0-100
> time: 0-255 dimm-time, where 0:default 1:fastest
> 255:slowest
> on/off: on:lamp on off:lamp off
>
> Usage:
> -define an Enocean device with id from your idbase-range:
> define mydimctrl EnOcean ffabcd81
> -set subtype:
> attr mydimctrl subType dimmCtrl
> -set the actor to learn mode
> -send the teach command:
> set mydimctrl teach
> -actor back to normal-mode
> -now you can control the dimmer
> set mydimctrl dimm 50 100 on
>
> time is optional (then 0 is used)
> on/off is optional (then on is used)
>
> The commands (A5/38/08) are not 100% compliant to the EEP, I think
> it will only work with eltako-Dimmers
>
>
>
>
>
>
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> - Sind die Änderungen und Ergänzungen, die diskutiert wurden, z. B. dimmup,
> schon umgesetzt? In der aktuellen 10_EnOcean-Datei, die verteilt wird,
> scheint noch der unten beschriebene Stand enthalten zu sein.
Ich benoetige eine definitive Aussage, ob/was funktioniert, bevor ich etwas
einchecke. Ich haette auch nichts dagegen, das EnOcean Modul an jemanden
abzugeben :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Kommandos im aktuell verteilten Stand funktionieren beim Eltako Dimmer
FUD70-230V. Fhem "dimmctrl" wurde mit der Eltako-Sensorvariante "PC-Modus
(Eltako FVS-Software)" und dem Befehl "teach" angelernt.
Falls es einen neueren Stand mit geänderten und erweiterten Funktionen zur
Erprobung gibt, kann ich das gerne an meinen Aktoren testen. Gut wäre
natürlich eine kurze Beschreibung der Neuerungen als Einstieg.
Am Donnerstag, 29. November 2012 18:13:55 UTC+1 schrieb Rudolf Koenig:
> > - Sind die �nderungen und Erg�nzungen, die diskutiert wurden, z. B.
> dimmup,
> > schon umgesetzt? In der aktuellen 10_EnOcean-Datei, die verteilt wird,
> > scheint noch der unten beschriebene Stand enthalten zu sein.
>
> Ich benoetige eine definitive Aussage, ob/was funktioniert, bevor ich
> etwas
> einchecke. Ich haette auch nichts dagegen, das EnOcean Modul an jemanden
> abzugeben :)
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudi!
> Ich benoetige eine definitive Aussage, ob/was funktioniert, bevor ich
> etwas
> einchecke.
Bei mir funktioniert die aktuelle 10_Enocean.pm mit den unidirektionalen
und einem bidirektionalen Eltako-Dimmern FUD61NPN-230V ohne Probleme.
> Ich haette auch nichts dagegen, das EnOcean Modul an jemanden
> abzugeben :)
>
Mmh, an die Programmierung traue ich mich nicht ran; meine Versuche mit dem
MD15 sind auch nach 3 Monaten nicht weitergekommen. Ich könnte Dir
höchstens eine (kleine) Hilfe beim Übersetzen der Commandref von Enocean
anbieten.
Gruß, Christian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Mit dem Enocean-Modul auf
https://github.com/mhop/fhem-mirror/blob/enocean/FHEM/10_EnOcean.pm hatte
ich anfangs mal experimentiert; habe es aber nicht vernünftig zum Laufen
gebracht. Ob es am Modul liegt oder (wahrscheinlicher) an mir kann ich
nicht sagen...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Nur zur Info:
Ich setzte Enocean Dimmaktoren von Jäger ein (BestNr. 561.162) oder link:
http://www.jaeger-direkt.com/App/WebObjects/XSeMIPS.woa/cms/page/locale.deDE/pid.10.13.130.814/agid.4305.4317/ecm.ag/gN-Aktor-u_P_-230-V-Universal-Dimmen-1-fach.html
Das Protokoll sollte vermutlich dem Eltako FUD61 entsprechen
Funktioniert nach meinen anfänglich in diesem Thread geposteten Problemen
https://groups.google.com/forum/?hl=de&fromgroups=#!searchin/fhem-users/enocean/fhem-users/16FDx3YO_4A/0bRsEwwGlyEJ
reibungslos.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com