Moinsen,
Danke erstmal an Matthias für seine großartige Arbeit an der
MAX-Implementation.
Meine Problemsituation habe ich jetzt nochmal nachvollzogen. Bei den
CUBE-gepairten HT funktioniert jetzt alles wieder, der CUBE scheint
irgendwo gehakt zu haben, nach einem Reset des CUBE springen die dort
angelernten HT einwandfrei, so wie es soll.
Bei dem einzelnen, an einen CUL angelernten HT allerdings bekomme ich
bei z.B. "set desiredTemperatur eco" nur ein "Command was discarded" als
Antwort. Nach einem kurzen Blick in die Sourcen sieht es für mich so aus
(bitte um Korrektur, falls ich Müll schreibe), als wenn die Nachricht
via MAX_LAN, also den CUBE, raus geht. Denn nur in MAX_LAN kommt diese
Fehlermeldung überhaupt vor. Und das muss natürlich schief gehen, denn
der CUBE kennt den (nicht am CUBE angelernten) HT ja garnicht.
Logauszug:
2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
2012.12.12 21:20:38 5: Msg S:0f,1,32
2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
2012.12.12 21:20:38 2: Command was discarded
Define des HT.Bad:
CULMAX0_MSGCNT
2
CULMAX0_RAWMSG
Z0F00046002608B00000000195B2900BA
CULMAX0_TIME
2012-12-12 22:14:19
DEF
HeatingThermostat 02608b
LASTIODev
CULMAX0
MSGCNT
2
NAME
HT.Bad
NR
331
STATE
20.5 °C
TYPE
MAX
addr
02608b
dstsetting
1
mode
1
rferror
0
type
HeatingThermostat
usingCube
0
Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode MAX) über den
CUBE?
Danke & Gruß
Hausautomat
-------- Original-Nachricht --------
Betreff: [MAX] Antennensymbol bei CUL statt CUBE?
Datum: Mon, 10 Dec 2012 22:57:10 +0100
Von: Hausautomat
Kopie (CC): hausautomat@googlemail.com
Hallo zusammen,
da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
"sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
desiredTemperature auch erst beim zweiten Senden übernommen.
Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
geantwortet. Das Setting/STATE ist unverändert.
Danke & Gruß
Jens
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Bei den MAX devices, die über CUL_MAX laufen sollen, am besten
das attr IODev auf das CUL_MAX device setzten.
Es gibt zwar eine gewisse Automatik, aber so ist es eindeutiger.
Am 12. Dezember 2012 22:17 schrieb Hausautomat :
> Moinsen,
>
> Danke erstmal an Matthias für seine großartige Arbeit an der
> MAX-Implementation.
>
> Meine Problemsituation habe ich jetzt nochmal nachvollzogen. Bei den
> CUBE-gepairten HT funktioniert jetzt alles wieder, der CUBE scheint
> irgendwo gehakt zu haben, nach einem Reset des CUBE springen die dort
> angelernten HT einwandfrei, so wie es soll.
>
> Bei dem einzelnen, an einen CUL angelernten HT allerdings bekomme ich bei
> z.B. "set desiredTemperatur eco" nur ein "Command was discarded" als
> Antwort. Nach einem kurzen Blick in die Sourcen sieht es für mich so aus
> (bitte um Korrektur, falls ich Müll schreibe), als wenn die Nachricht via
> MAX_LAN, also den CUBE, raus geht. Denn nur in MAX_LAN kommt diese
> Fehlermeldung überhaupt vor. Und das muss natürlich schief gehen, denn der
> CUBE kennt den (nicht am CUBE angelernten) HT ja garnicht.
>
> Logauszug:
> 2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
> 2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
> 2012.12.12 21:20:38 5: Msg S:0f,1,32
> 2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
> 2012.12.12 21:20:38 2: Command was discarded
>
> Define des HT.Bad:
> CULMAX0_MSGCNT
> 2
> CULMAX0_RAWMSG
> Z0F00046002608B00000000195B2900BA
> CULMAX0_TIME
> 2012-12-12 22:14:19
> DEF
> HeatingThermostat 02608b
>
> LASTIODev
> CULMAX0
> MSGCNT
> 2
> NAME
> HT.Bad
> NR
> 331
> STATE
> 20.5 °C
> TYPE
> MAX
> addr
> 02608b
> dstsetting
> 1
> mode
> 1
> rferror
> 0
> type
> HeatingThermostat
> usingCube
> 0
>
>
> Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode MAX) über den
> CUBE?
>
> Danke & Gruß
> Hausautomat
>
> -------- Original-Nachricht -------- Betreff: [MAX] Antennensymbol bei
> CUL statt CUBE? Datum: Mon, 10 Dec 2012 22:57:10 +0100 Von: Hausautomat
> Kopie (CC):
> hausautomat@googlemail.com
>
> Hallo zusammen,
>
> da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
> habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
>
> Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
> "sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
> Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
> desiredTemperature auch erst beim zweiten Senden übernommen.
>
> Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
> stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
> geantwortet. Das Setting/STATE ist unverändert.
>
> Danke & Gruß
> Jens
>
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Matthias,
vielen Dank - das war der entscheidende Tipp - jetzt kann ich langsam
alles auf CUL umstellen und den CUBE abschalten. Sehr gut. :-)
Werde versuchen, mir die Automatik mal anzuschauen.
Gruß
Jens
Am 12.12.2012 23:25, schrieb Matthias Gehre:
> Bei den MAX devices, die über CUL_MAX laufen sollen, am besten
> das attr IODev auf das CUL_MAX device setzten.
> Es gibt zwar eine gewisse Automatik, aber so ist es eindeutiger.
>
>
> Am 12. Dezember 2012 22:17 schrieb Hausautomat
> >:
>
> Moinsen,
>
> Danke erstmal an Matthias für seine großartige Arbeit an der
> MAX-Implementation.
>
> Meine Problemsituation habe ich jetzt nochmal nachvollzogen. Bei
> den CUBE-gepairten HT funktioniert jetzt alles wieder, der CUBE
> scheint irgendwo gehakt zu haben, nach einem Reset des CUBE
> springen die dort angelernten HT einwandfrei, so wie es soll.
>
> Bei dem einzelnen, an einen CUL angelernten HT allerdings bekomme
> ich bei z.B. "set desiredTemperatur eco" nur ein "Command was
> discarded" als Antwort. Nach einem kurzen Blick in die Sourcen
> sieht es für mich so aus (bitte um Korrektur, falls ich Müll
> schreibe), als wenn die Nachricht via MAX_LAN, also den CUBE, raus
> geht. Denn nur in MAX_LAN kommt diese Fehlermeldung überhaupt vor.
> Und das muss natürlich schief gehen, denn der CUBE kennt den
> (nicht am CUBE angelernten) HT ja garnicht.
>
> Logauszug:
> 2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
> 2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
> 2012.12.12 21:20:38 5: Msg S:0f,1,32
> 2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
> 2012.12.12 21:20:38 2: Command was discarded
>
> Define des HT.Bad:
> CULMAX0_MSGCNT
>
> 2
> CULMAX0_RAWMSG
>
> Z0F00046002608B00000000195B2900BA
> CULMAX0_TIME
>
> 2012-12-12 22:14:19
> DEF
> HeatingThermostat 02608b
>
> LASTIODev
>
> CULMAX0
> MSGCNT
>
> 2
> NAME
>
> HT.Bad
> NR
>
> 331
> STATE
>
> 20.5 °C
> TYPE
>
> MAX
> addr
>
> 02608b
> dstsetting
>
> 1
> mode
>
> 1
> rferror
>
> 0
> type
>
> HeatingThermostat
> usingCube
>
> 0
>
>
>
> Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode MAX)
> über den CUBE?
>
> Danke & Gruß
> Hausautomat
>
> -------- Original-Nachricht --------
> Betreff: [MAX] Antennensymbol bei CUL statt CUBE?
> Datum: Mon, 10 Dec 2012 22:57:10 +0100
> Von: Hausautomat
>
> Kopie (CC): hausautomat@googlemail.com
>
>
>
>
> Hallo zusammen,
>
> da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
> habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
>
> Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
> "sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
> Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
> desiredTemperature auch erst beim zweiten Senden übernommen.
>
> Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
> stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
> geantwortet. Das Setting/STATE ist unverändert.
>
> Danke & Gruß
> Jens
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Die Automatik funktioniert so: Wenn was über MAXLAN reinkommt, dann wird
das IODev auf MAXLAN gesetzt, wenn
der CUL ein Paket empfängt, dessen Empfänger mit der Adresse des CUL_MAX
übereinstimmt, dann wird das IODev auf den CUL_MAX gesetzt.
Kann aber nach dem Neustart etwas dauern, bis ein Paket empfangen wird und
so das richtige IODev gefunden.
Am 13. Dezember 2012 21:15 schrieb Hausautomat :
> Hallo Matthias,
>
> vielen Dank - das war der entscheidende Tipp - jetzt kann ich langsam
> alles auf CUL umstellen und den CUBE abschalten. Sehr gut. :-)
>
> Werde versuchen, mir die Automatik mal anzuschauen.
>
> Gruß
> Jens
>
>
> Am 12.12.2012 23:25, schrieb Matthias Gehre:
>
> Bei den MAX devices, die über CUL_MAX laufen sollen, am besten
> das attr IODev auf das CUL_MAX device setzten.
> Es gibt zwar eine gewisse Automatik, aber so ist es eindeutiger.
>
>
> Am 12. Dezember 2012 22:17 schrieb Hausautomat <
> hausautomat@googlemail.com>:
>
>> Moinsen,
>>
>> Danke erstmal an Matthias für seine großartige Arbeit an der
>> MAX-Implementation.
>>
>> Meine Problemsituation habe ich jetzt nochmal nachvollzogen. Bei den
>> CUBE-gepairten HT funktioniert jetzt alles wieder, der CUBE scheint
>> irgendwo gehakt zu haben, nach einem Reset des CUBE springen die dort
>> angelernten HT einwandfrei, so wie es soll.
>>
>> Bei dem einzelnen, an einen CUL angelernten HT allerdings bekomme ich bei
>> z.B. "set desiredTemperatur eco" nur ein "Command was discarded" als
>> Antwort. Nach einem kurzen Blick in die Sourcen sieht es für mich so aus
>> (bitte um Korrektur, falls ich Müll schreibe), als wenn die Nachricht via
>> MAX_LAN, also den CUBE, raus geht. Denn nur in MAX_LAN kommt diese
>> Fehlermeldung überhaupt vor. Und das muss natürlich schief gehen, denn der
>> CUBE kennt den (nicht am CUBE angelernten) HT ja garnicht.
>>
>> Logauszug:
>> 2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
>> 2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
>> 2012.12.12 21:20:38 5: Msg S:0f,1,32
>> 2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
>> 2012.12.12 21:20:38 2: Command was discarded
>>
>> Define des HT.Bad:
>> CULMAX0_MSGCNT
>> 2
>> CULMAX0_RAWMSG
>> Z0F00046002608B00000000195B2900BA
>> CULMAX0_TIME
>> 2012-12-12 22:14:19
>> DEF
>> HeatingThermostat 02608b
>>
>> LASTIODev
>> CULMAX0
>> MSGCNT
>> 2
>> NAME
>> HT.Bad
>> NR
>> 331
>> STATE
>> 20.5 °C
>> TYPE
>> MAX
>> addr
>> 02608b
>> dstsetting
>> 1
>> mode
>> 1
>> rferror
>> 0
>> type
>> HeatingThermostat
>> usingCube
>> 0
>>
>>
>> Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode MAX) über den
>> CUBE?
>>
>> Danke & Gruß
>> Hausautomat
>>
>> -------- Original-Nachricht -------- Betreff: [MAX] Antennensymbol bei
>> CUL statt CUBE? Datum: Mon, 10 Dec 2012 22:57:10 +0100 Von: Hausautomat
>> Kopie (CC):
>> hausautomat@googlemail.com
>>
>> Hallo zusammen,
>>
>> da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
>> habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
>>
>> Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
>> "sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
>> Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
>> desiredTemperature auch erst beim zweiten Senden übernommen.
>>
>> Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
>> stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
>> geantwortet. Das Setting/STATE ist unverändert.
>>
>> Danke & Gruß
>> Jens
>>
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Kann nicht per "usingCube" (0|1) aus den Device-Infos das entschieden
werden? Denn im Prinzip wird ja bereits beim Pairing entschieden, ob es
über CUL oder CUBE laufen soll. Dann müsste diese Info "nur" via
State-Infos weggeschrieben werden.
Ist das dann im "backend" setting drin?
Ich gehe erstmal über das attr IODev.
Am 13.12.2012 21:41, schrieb Matthias Gehre:
> Die Automatik funktioniert so: Wenn was über MAXLAN reinkommt, dann
> wird das IODev auf MAXLAN gesetzt, wenn
> der CUL ein Paket empfängt, dessen Empfänger mit der Adresse des
> CUL_MAX übereinstimmt, dann wird das IODev auf den CUL_MAX gesetzt.
>
> Kann aber nach dem Neustart etwas dauern, bis ein Paket empfangen wird
> und so das richtige IODev gefunden.
>
>
> Am 13. Dezember 2012 21:15 schrieb Hausautomat
> >:
>
> Hallo Matthias,
>
> vielen Dank - das war der entscheidende Tipp - jetzt kann ich
> langsam alles auf CUL umstellen und den CUBE abschalten. Sehr gut. :-)
>
> Werde versuchen, mir die Automatik mal anzuschauen.
>
> Gruß
> Jens
>
>
> Am 12.12.2012 23:25, schrieb Matthias Gehre:
>> Bei den MAX devices, die über CUL_MAX laufen sollen, am besten
>> das attr IODev auf das CUL_MAX device setzten.
>> Es gibt zwar eine gewisse Automatik, aber so ist es eindeutiger.
>>
>>
>> Am 12. Dezember 2012 22:17 schrieb Hausautomat
>> >:
>>
>> Moinsen,
>>
>> Danke erstmal an Matthias für seine großartige Arbeit an der
>> MAX-Implementation.
>>
>> Meine Problemsituation habe ich jetzt nochmal nachvollzogen.
>> Bei den CUBE-gepairten HT funktioniert jetzt alles wieder,
>> der CUBE scheint irgendwo gehakt zu haben, nach einem Reset
>> des CUBE springen die dort angelernten HT einwandfrei, so wie
>> es soll.
>>
>> Bei dem einzelnen, an einen CUL angelernten HT allerdings
>> bekomme ich bei z.B. "set desiredTemperatur eco" nur ein
>> "Command was discarded" als Antwort. Nach einem kurzen Blick
>> in die Sourcen sieht es für mich so aus (bitte um Korrektur,
>> falls ich Müll schreibe), als wenn die Nachricht via MAX_LAN,
>> also den CUBE, raus geht. Denn nur in MAX_LAN kommt diese
>> Fehlermeldung überhaupt vor. Und das muss natürlich schief
>> gehen, denn der CUBE kennt den (nicht am CUBE angelernten) HT
>> ja garnicht.
>>
>> Logauszug:
>> 2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
>> 2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
>> 2012.12.12 21:20:38 5: Msg S:0f,1,32
>> 2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
>> 2012.12.12 21:20:38 2: Command was discarded
>>
>> Define des HT.Bad:
>> CULMAX0_MSGCNT
>>
>> 2
>> CULMAX0_RAWMSG
>>
>> Z0F00046002608B00000000195B2900BA
>> CULMAX0_TIME
>>
>> 2012-12-12 22:14:19
>> DEF
>> HeatingThermostat 02608b
>>
>> LASTIODev
>>
>> CULMAX0
>> MSGCNT
>>
>> 2
>> NAME
>>
>> HT.Bad
>> NR
>>
>> 331
>> STATE
>>
>> 20.5 °C
>> TYPE
>>
>> MAX
>> addr
>>
>> 02608b
>> dstsetting
>>
>> 1
>> mode
>>
>> 1
>> rferror
>>
>> 0
>> type
>>
>> HeatingThermostat
>> usingCube
>>
>> 0
>>
>>
>>
>> Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode
>> MAX) über den CUBE?
>>
>> Danke & Gruß
>> Hausautomat
>>
>> -------- Original-Nachricht --------
>> Betreff: [MAX] Antennensymbol bei CUL statt CUBE?
>> Datum: Mon, 10 Dec 2012 22:57:10 +0100
>> Von: Hausautomat
>>
>> Kopie (CC): hausautomat@googlemail.com
>>
>>
>>
>>
>> Hallo zusammen,
>>
>> da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
>> habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
>>
>> Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
>> "sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
>> Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
>> desiredTemperature auch erst beim zweiten Senden übernommen.
>>
>> Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
>> stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
>> geantwortet. Das Setting/STATE ist unverändert.
>>
>> Danke & Gruß
>> Jens
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
usingCube reicht nicht aus, da es mehrere MAXLAN/CUL_MAX geben kann. Daher
gibts usingCube auch seit ein paar Tagen nicht mehr.
Dafür dann die neue Automatik.
Wäre natürlich schön, wenn man beim Pairing direkt das attr IODev setzen
würde.
Würde das beim fhem.cfg speichern mit gespeichert werden?
Am 13. Dezember 2012 22:58 schrieb Hausautomat :
> Kann nicht per "usingCube" (0|1) aus den Device-Infos das entschieden
> werden? Denn im Prinzip wird ja bereits beim Pairing entschieden, ob es
> über CUL oder CUBE laufen soll. Dann müsste diese Info "nur" via
> State-Infos weggeschrieben werden.
>
> Ist das dann im "backend" setting drin?
>
> Ich gehe erstmal über das attr IODev.
>
>
>
> Am 13.12.2012 21:41, schrieb Matthias Gehre:
>
> Die Automatik funktioniert so: Wenn was über MAXLAN reinkommt, dann wird
> das IODev auf MAXLAN gesetzt, wenn
> der CUL ein Paket empfängt, dessen Empfänger mit der Adresse des CUL_MAX
> übereinstimmt, dann wird das IODev auf den CUL_MAX gesetzt.
>
> Kann aber nach dem Neustart etwas dauern, bis ein Paket empfangen wird und
> so das richtige IODev gefunden.
>
>
> Am 13. Dezember 2012 21:15 schrieb Hausautomat > >:
>
>> Hallo Matthias,
>>
>> vielen Dank - das war der entscheidende Tipp - jetzt kann ich langsam
>> alles auf CUL umstellen und den CUBE abschalten. Sehr gut. :-)
>>
>> Werde versuchen, mir die Automatik mal anzuschauen.
>>
>> Gruß
>> Jens
>>
>>
>> Am 12.12.2012 23:25, schrieb Matthias Gehre:
>>
>> Bei den MAX devices, die über CUL_MAX laufen sollen, am besten
>> das attr IODev auf das CUL_MAX device setzten.
>> Es gibt zwar eine gewisse Automatik, aber so ist es eindeutiger.
>>
>>
>> Am 12. Dezember 2012 22:17 schrieb Hausautomat <
>> hausautomat@googlemail.com>:
>>
>>> Moinsen,
>>>
>>> Danke erstmal an Matthias für seine großartige Arbeit an der
>>> MAX-Implementation.
>>>
>>> Meine Problemsituation habe ich jetzt nochmal nachvollzogen. Bei den
>>> CUBE-gepairten HT funktioniert jetzt alles wieder, der CUBE scheint
>>> irgendwo gehakt zu haben, nach einem Reset des CUBE springen die dort
>>> angelernten HT einwandfrei, so wie es soll.
>>>
>>> Bei dem einzelnen, an einen CUL angelernten HT allerdings bekomme ich
>>> bei z.B. "set desiredTemperatur eco" nur ein "Command was discarded" als
>>> Antwort. Nach einem kurzen Blick in die Sourcen sieht es für mich so aus
>>> (bitte um Korrektur, falls ich Müll schreibe), als wenn die Nachricht via
>>> MAX_LAN, also den CUBE, raus geht. Denn nur in MAX_LAN kommt diese
>>> Fehlermeldung überhaupt vor. Und das muss natürlich schief gehen, denn der
>>> CUBE kennt den (nicht am CUBE angelernten) HT ja garnicht.
>>>
>>> Logauszug:
>>> 2012.12.12 21:20:37 5: Cmd: >set HT.Bad desiredTemperature eco<
>>> 2012.12.12 21:20:37 5: MAXLAN_SimpleWrite: s:AABAAAAAAmCLAGI=
>>> 2012.12.12 21:20:38 5: Msg S:0f,1,32
>>> 2012.12.12 21:20:38 5: dutycyle 15, freememoryslot 32
>>> 2012.12.12 21:20:38 2: Command was discarded
>>>
>>> Define des HT.Bad:
>>> CULMAX0_MSGCNT
>>> 2
>>> CULMAX0_RAWMSG
>>> Z0F00046002608B00000000195B2900BA
>>> CULMAX0_TIME
>>> 2012-12-12 22:14:19
>>> DEF
>>> HeatingThermostat 02608b
>>>
>>> LASTIODev
>>> CULMAX0
>>> MSGCNT
>>> 2
>>> NAME
>>> HT.Bad
>>> NR
>>> 331
>>> STATE
>>> 20.5 °C
>>> TYPE
>>> MAX
>>> addr
>>> 02608b
>>> dstsetting
>>> 1
>>> mode
>>> 1
>>> rferror
>>> 0
>>> type
>>> HeatingThermostat
>>> usingCube
>>> 0
>>>
>>>
>>> Also geht die MSG trotz IODev CULMAX0 (ein CUL mit rfmode MAX) über den
>>> CUBE?
>>>
>>> Danke & Gruß
>>> Hausautomat
>>>
>>> -------- Original-Nachricht -------- Betreff: [MAX] Antennensymbol bei
>>> CUL statt CUBE? Datum: Mon, 10 Dec 2012 22:57:10 +0100 Von: Hausautomat
>>> Kopie (CC):
>>> hausautomat@googlemail.com
>>>
>>> Hallo zusammen,
>>>
>>> da ich via CUBE bei drei Thermostaten nur "Command discarded" bekomme,
>>> habe ich testweise mal eins direkt an einen MAX-CUL angelernt.
>>>
>>> Verbindung scheint zu bestehen, denn der Anlernmodus war sozusagen
>>> "sofort" beendet. Allerdings steht kein Antennensymbol im Thermostat?
>>> Soweit ich eben kurz getestet habe, hat der HT die Einstellung der
>>> desiredTemperature auch erst beim zweiten Senden übernommen.
>>>
>>> Kann das sein? Werde das Log nochmal durchflöhen, aber auf ersten Blick
>>> stand da sowas wie "Got ACK (but no match)", der HT hat an den MAX-CUL
>>> geantwortet. Das Setting/STATE ist unverändert.
>>>
>>> Danke & Gruß
>>> Jens
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this group, send email to
>>> fhem-users+unsubscribe@googlegroups.com
>>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com