HM-CC-TC MISSING-ACK bei Einstellen desired-temp

Begonnen von Guest, 29 Oktober 2012, 18:30:27

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hallo,

ich habe dieses Thema in einem anderen Thread gepostet und da dort kein
Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in
Ordnung.

Nun zum Problem.

Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich habe
mir viele andere Threads durchgelesen und es heißt, dass die Funktionalität
schon da sein soll. Bei mir funktioniert das Setzen der desired-temp nur 1
von 10 mal (ca.).

Ich erhalte folgendes Log:

*2012-10-26 00:26:09 CUL_HM az_Thermostat desired-temp 10.0*
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur T: 26.4 H: 100
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur temperature: 26.4
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur humidity: 100
2012-10-26 00:26:25 CUL_HM sz_Thermostat T: 22.4 H: 60
2012-10-26 00:26:25 CUL_HM sz_Thermostat measured-temp: 22.4
2012-10-26 00:26:25 CUL_HM sz_Thermostat humidity: 60
2012-10-26 00:27:02 CUL_HM az_Thermostat T: 22.9 H: 62
2012-10-26 00:27:02 CUL_HM az_Thermostat measured-temp: 22.9
2012-10-26 00:27:02 CUL_HM az_Thermostat humidity: 62
2012-10-26 00:27:04 CUL_HM wz_Thermostat T: 22.7 H: 60
2012-10-26 00:27:04 CUL_HM wz_Thermostat measured-temp: 22.7
2012-10-26 00:27:04 CUL_HM wz_Thermostat humidity: 60
*2012-10-26 00:27:06 CUL_HM az_Thermostat MISSING ACK*

Jemand aus dem anderen Thred meinte ich solle ein msec genaues Log
erstellen. Dazu habe ich leider nichts finden können wie ich das erstellen
kann. Auch wurde diese Frage leider nicht im anderen Thread beantwortet
(kein Vorwurf, ist wahrscheinlich nur untergegangen).

Ich hoffe, dass der eine oder andere mir weiterhelfen kann.

Vielen Dank,
kohrti




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

UliM

                                                 

Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:
>
> msec genaues Log erstellen. Dazu habe ich leider nichts finden können wie
> ich das erstellen kann.
>

attr global mseclog 1

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Billy

                                                         

Ich hatte deinen Beitrag im anderen Thread gelesen.
Was mich gewundert hatte war deine Aussage:

Der Thermostat ist mit keinem Aktor sondern nur mit fhem verknüpft, Mode:
Manual oder Auto.!!!

Was soll dein TC steuern, wenn er mit keinem VD verknüpft ist?
Oder habe ich da was falsch verstanden?

Billy

Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:
>
> Hallo,
>
> ich habe dieses Thema in einem anderen Thread gepostet und da dort kein
> Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in
> Ordnung.
>
> Nun zum Problem.
>
> Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich habe
> mir viele andere Threads durchgelesen und es heißt, dass die Funktionalität
> schon da sein soll. Bei mir funktioniert das Setzen der desired-temp nur 1
> von 10 mal (ca.).
>
> Ich hoffe, dass der eine oder andere mir weiterhelfen kann.
>
> Vielen Dank,
> kohrti
>
>
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

Hallo,

@Billy
Ich weiß, dass sich das eigentlich verrückt anhört. Ich habe mir das PID
Modul geschnappt und für meine Fußbodenheizung angepaßt. Ich kann meine
Aktoren nur auf ON/OFF setzen, daher mußte ich eine PWM
(Pulsweitenmodulation) einbauen. Jetzt heißt das Modul eben PIDPWM (mit
zusätzlicher Begrenzung des I-Anteils). Nun werden die Aktoren nicht direkt
über die Thermostate angesteuert, sondern dieses PIDPWM Modul steuert sie.
Die Thermostate liefern eigentlich nur die Soll/Ist Temperatur und erlauben
die Programmierung der Zeiten. So kam ich zu der Aussage, dass ich keine
Aktoren direkt verknüpft habe sodern nur fhem. Mit Manual/Auto meinte ich
die Programme die man am Thermostat einstellen kann.

@Uli
Vielen Dank, werde ich gleich ausprobieren und Ergebnisse liefern!

Schöne Grüße,
Kohrti


Am Montag, 29. Oktober 2012 19:59:32 UTC+1 schrieb littlebilly:
>
> Ich hatte deinen Beitrag im anderen Thread gelesen.
> Was mich gewundert hatte war deine Aussage:
>
> Der Thermostat ist mit keinem Aktor sondern nur mit fhem verknüpft, Mode:
> Manual oder Auto.!!!
>
> Was soll dein TC steuern, wenn er mit keinem VD verknüpft ist?
> Oder habe ich da was falsch verstanden?
>
> Billy
>
> Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:
>>
>> Hallo,
>>
>> ich habe dieses Thema in einem anderen Thread gepostet und da dort kein
>> Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in
>> Ordnung.
>>
>> Nun zum Problem.
>>
>> Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich
>> habe mir viele andere Threads durchgelesen und es heißt, dass die
>> Funktionalität schon da sein soll. Bei mir funktioniert das Setzen der
>> desired-temp nur 1 von 10 mal (ca.).
>>
>> Ich hoffe, dass der eine oder andere mir weiterhelfen kann.
>>
>> Vielen Dank,
>> kohrti
>>
>>
>>
>>
>>

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

UliM

                                                 

>
> Hi,
>>
> wenn ich das richtig verstanden habe, steht in dem anderen fred zum
missing ACK bei desired-temp für HM-TC-CC:
Das timing bei der Kommunikation ist sehr fragil. Es funktioniert z.T. nur,
wenn Du am HMLAN bzw CUL hmProtocolEvents auf 3 setzt, z.T. nur, wenn Du es
auf <3 setzt.
Vll kannst Du damit etwas testen.
=8-)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Hallo,

hier habe ich nun die Log Ergebnisse aus dem Event monitor. Leider sieht
man da auch nicht mehr, oder übersehe ich irgendwas?
Auf jeden Fall werde ich jetzt mal den Vorschlag von Uli testen und
berichten.

VG,
Kohrti

*2012-10-29 21:55:45.999 CUL_HM az_Thermostat desired-temp 11.0*
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat T: 20.6 H: 55
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat measured-temp: 20.6
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat humidity: 55
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat T: 20.8 H: 52
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat measured-temp: 20.8
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat humidity: 52
2012-10-29 21:56:17.663 CUL_HM ka_Heizkreis3 off
2012-10-29 21:56:17.730 Global global DELETED Timer_ka_Heizkreis3
2012-10-29 21:56:17.981 CUL_HM ka_Heizkreis3 deviceMsg: off (to CUNO)
2012-10-29 21:56:17.981 CUL_HM ka_Heizkreis3 off
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur T: 22.1 H: 48
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur temperature: 22.1
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur humidity: 48
2012-10-29 21:56:33.475 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 21:56:33.475 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 21:56:33.475 CUL_HM az_Thermostat humidity: 55
*2012-10-29 21:56:37.502 CUL_HM az_Thermostat MISSING ACK*
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat T: 21.6 H: 59
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat measured-temp: 21.6
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat humidity: 59
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat T: 20.6 H: 55
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat measured-temp: 20.6
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat humidity: 55
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat T: 20.8 H: 52
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat measured-temp: 20.8
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat humidity: 52
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat T: 22.2 H: 55
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat measured-temp: 22.2
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat humidity: 55
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat T: 22.1 H: 57
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat measured-temp: 22.1
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat humidity: 57
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur T: 22.1 H: 48
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur temperature: 22.1
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur humidity: 48
2012-10-29 21:59:28.690 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 21:59:28.690 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 21:59:28.690 CUL_HM az_Thermostat humidity: 55



Am Montag, 29. Oktober 2012 21:37:03 UTC+1 schrieb kohrti:
>
> Hallo,
>
> @Billy
> Ich weiß, dass sich das eigentlich verrückt anhört. Ich habe mir das PID
> Modul geschnappt und für meine Fußbodenheizung angepaßt. Ich kann meine
> Aktoren nur auf ON/OFF setzen, daher mußte ich eine PWM
> (Pulsweitenmodulation) einbauen. Jetzt heißt das Modul eben PIDPWM (mit
> zusätzlicher Begrenzung des I-Anteils). Nun werden die Aktoren nicht direkt
> über die Thermostate angesteuert, sondern dieses PIDPWM Modul steuert sie.
> Die Thermostate liefern eigentlich nur die Soll/Ist Temperatur und erlauben
> die Programmierung der Zeiten. So kam ich zu der Aussage, dass ich keine
> Aktoren direkt verknüpft habe sodern nur fhem. Mit Manual/Auto meinte ich
> die Programme die man am Thermostat einstellen kann.
>
> @Uli
> Vielen Dank, werde ich gleich ausprobieren und Ergebnisse liefern!
>
> Schöne Grüße,
> Kohrti
>
>
> Am Montag, 29. Oktober 2012 19:59:32 UTC+1 schrieb littlebilly:
>>
>> Ich hatte deinen Beitrag im anderen Thread gelesen.
>> Was mich gewundert hatte war deine Aussage:
>>
>> Der Thermostat ist mit keinem Aktor sondern nur mit fhem verknüpft, Mode:
>> Manual oder Auto.!!!
>>
>> Was soll dein TC steuern, wenn er mit keinem VD verknüpft ist?
>> Oder habe ich da was falsch verstanden?
>>
>> Billy
>>
>> Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:
>>>
>>> Hallo,
>>>
>>> ich habe dieses Thema in einem anderen Thread gepostet und da dort kein
>>> Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in
>>> Ordnung.
>>>
>>> Nun zum Problem.
>>>
>>> Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich
>>> habe mir viele andere Threads durchgelesen und es heißt, dass die
>>> Funktionalität schon da sein soll. Bei mir funktioniert das Setzen der
>>> desired-temp nur 1 von 10 mal (ca.).
>>>
>>> Ich hoffe, dass der eine oder andere mir weiterhelfen kann.
>>>
>>> Vielen Dank,
>>> kohrti
>>>
>>>
>>>
>>>
>>>

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

Guest

Originally posted by: <email address deleted>

Hi,

ich habe nun hmProtocolEvents=0/1/2/3 ausprobiert und keine wesentlichen
Änderungen feststellen können. Bei hmProtocolEvents=3 sehe ich nur etwas
mehr Informationen, die aber (glaube ich) nicht wirklich hilfreich sind.

Kann es vielleicht daran liegen das ich einen CUNO v2 im Einsatz habe und
sich dieser anders verhält als HMLan und CUL?

Gruß,
Kohrti

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

Guest

Originally posted by: <email address deleted>

Hallo,

hab nochmal darüber nachgedacht. Der einzige Workaround wäre in den PIDPWM
Reglern einen Parameter "desired-temp" einzufügen, der dann die
"desired-temp" der Thermostate überschreibt falls er angelegt wurde. Nicht
schön aber immerhin kann ich dann von der Arbeit aus die Temperatur
bestimmen - und zu Hause dann die Thermostate verwenden.

Gibt es denn sonst nichts das ich machen kann?

Das Problem ist doch (irgendwie) dass der Thermostat die "desired-temp"
nicht annehmen will. Er schläft normalerweise und wacht alle ca. 3 Min.
auf. Dann hat fhem die Gelegenheit etwas zu senden, weil er dann ja wach
sein sollte. Und genau dieses Timing ist das Problem. Es wurde ja schon mit
Resend usw. gearbeitet soweit ich gesehen habe. In welche Ecke muss ich
denn schauen?

Gruß,
Kohrti

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

UliM

                                                 

Hi,
was willst Du denn eigentlich erreichen?
Wenn Du die desired-temp gesetzt hast, dann....?

Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch
kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch,
siehe https://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion
Da ist wohl noch etwas Entwicklungsarbeit zu tun.
Erster Schritt wäre, dass jemand, der ein HM-CC-VD besitzt, den Funkverkehr
beim Anlernen des VD an den TC mitschneidet und hier postet. Das kann dann
eventuell als Basis für das pairing eines virtuellen VD dienen. Ob's dann
wirklich funktioniert, muss man sehen - wahrscheinlich schickt ja der VD
auf jede Nachricht des CC einen ACK, auch den müsste man dann emulieren.

Solange hier niemand diesen Funkverkehr kundtut, geht's nicht weiter.

Es bleibt also spannend :)

Gruß, Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Hallo,

grundsätzlich will ich die Solltemperatur "desired-temp" von fhem
einstellen können. Manchmal geht es ja sogar (1 v. 10 Versuchen). Momentan
geht es nur über das EInstellrad zuverlässig.  

Mein PIDPWM Regler benötigt die Solltemperatur desired-temp, um dann die
aktoren für die Fußbodenheizung zu steuern. Die Aktoren werden von dem
Modul gesteuert, nicht von dem Thermostat. Letzteres benutze ich nur als
Sensor mit etwas Intelligenz weil man dort ja auch Programme hinterlegen
kann für die Solltemperatur desried-temp.
Damit sollen Bewohner die Möglichkeit haben die Heizung im Raum zu
beeinflussen, aber ich möchte das auch von Remote tun, daher will ich
desried-temp setzen können.

Ich hoffe es ist jetzt etwas klarer, dass NICHT der Thermostat den sollwert
schickt sondern MEIN Regler.

Gruß,
Kohrti

Hier noch ein aktuelles Log:
*2012-10-29 23:33:10.108 CUL_HM az_Thermostat desired-temp 15.0*
2012-10-29 23:33:16.757 CUL CUNO RCV L:0C N:BB F:86 CMD:70
SRC:ku_Thermostat DST:broadcast 00D73A (WeatherEvent TEMP:21.5 HUM:58)
(,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat T: 21.5 H: 58
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat measured-temp: 21.5
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat humidity: 58
2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70
SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55)
(,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234
DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-29 23:33:24.797 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 23:33:24.797 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 23:33:24.797 CUL_HM az_Thermostat humidity: 55
*2012-10-29 23:33:28.824 CUL_HM az_Thermostat MISSING ACK*


--> Sind denn 124ms genug für den Thermostat nach WAKEUP? Ich mache nochmal
ein positives Log um das Timing dafür zu sehen....

Am Montag, 29. Oktober 2012 23:34:02 UTC+1 schrieb UliM:
>
> Hi,
> was willst Du denn eigentlich erreichen?
> Wenn Du die desired-temp gesetzt hast, dann....?
>
> Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch
> kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch,
> siehe https://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion
> Da ist wohl noch etwas Entwicklungsarbeit zu tun.
> Erster Schritt wäre, dass jemand, der ein HM-CC-VD besitzt, den
> Funkverkehr beim Anlernen des VD an den TC mitschneidet und hier postet.
> Das kann dann eventuell als Basis für das pairing eines virtuellen VD
> dienen. Ob's dann wirklich funktioniert, muss man sehen - wahrscheinlich
> schickt ja der VD auf jede Nachricht des CC einen ACK, auch den müsste man
> dann emulieren.
>
> Solange hier niemand diesen Funkverkehr kundtut, geht's nicht weiter.
>
> Es bleibt also spannend :)
>
> Gruß, Uli
>
>

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

locodriver

                                                         

Nun will ich mich hier auch mal mit einklinken (habe das spezielle Thema
bis jetzt nur mitgelesen).
Mein Fhem (noch 5.2 aber mit neuer Struktur) läuft auch auf der FB 7390 und
ich verwende einen CUNO2. Ich habe 2 CC mit einem bzw. zwei VD in
Verwendung und jeweils noch einen Drehgriffkontakt (Threestate). Alles erst
einzeln gepaired und dann zu Fhem, damit die CCs auch bei Ausfall von Fhem
die VDs ansteuern können.
Mir ist es bis jetzt nur einmal gelungen, den CC zu einer Übernahme einer
desired-temp zu bewegen. Was ich bei der Kommunikation der Komponenten
nicht verstehe: Der CC registriert sofort eine Veränderung des Status' des
Threestate und regelt nach ca. 3 Min. die VDs in Frostschutz. Also muss
doch der CC immer lauschen und nicht nur alle drei Minuten - der Threestate
sendet ja den Statuswechsel nicht drei Minuten lang - oder?
Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie der
HMLAN und deshalb der CC die Befehlsumsetzung verweigert. Der CUL/CUNO
müsste also nicht sagen: "Hallo CC - ich bin der CUNO und schicke dir mal
ein paar Befehle" sondern "Ich bin ein CUNO tue aber so als wäre in ein
HMLAN und ..."
Loggen und testen geht bei mir nur alle zwei Wochen, da ich sonst nur per
VPN zugreife und auch keine Updates darüber einspiele (schlechte
Erfahrungen gemacht).


Am Montag, 29. Oktober 2012 23:34:02 UTC+1 schrieb UliM:
>
> Hi,
> was willst Du denn eigentlich erreichen?
> Wenn Du die desired-temp gesetzt hast, dann....?
>
> Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch
> kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch,
> siehe https://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion
> Da ist wohl noch etwas Entwicklungsarbeit zu tun.
> Erster Schritt wäre, dass jemand, der ein HM-CC-VD besitzt, den
> Funkverkehr beim Anlernen des VD an den TC mitschneidet und hier postet.
> Das kann dann eventuell als Basis für das pairing eines virtuellen VD
> dienen. Ob's dann wirklich funktioniert, muss man sehen - wahrscheinlich
> schickt ja der VD auf jede Nachricht des CC einen ACK, auch den müsste man
> dann emulieren.
>
> Solange hier niemand diesen Funkverkehr kundtut, geht's nicht weiter.
>
> Es bleibt also spannend :)
>
> Gruß, Uli
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

Guest

Originally posted by: <email address deleted>

Hallo Uwe,

Am Montag, 29. Oktober 2012 23:53:59 UTC+1 schrieb Uwe:
>
> Der CC registriert sofort eine Veränderung des Status' des Threestate und
> regelt nach ca. 3 Min. die VDs in Frostschutz.
>

Gibt es dazu zufällig ein Log?
Wie siehst du denn, dass es SOFORT angenommen wird?

Ich kenne mich (noch) nicht so gut mit den Messages aus, aber ich wäre
jetzt eher davon ausgegangen, dass es ein Timing Problem ist. Evtl. Gibt es
ja doch die Möglichkeit dem CC sofort aufzuwecken. Mit einem Log täte man
sich leichtes das zu beurteilen. Oder die Experten hier können auf Anhieb
was dazu sagen.

Gruß,
Kohrti

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

locodriver

                                                         

Wie gesagt, momentan bin ich nicht zu Hause. Aber sobald ich das Fenster
öffne, wird im Display des CC das "Fenstersymbol" angezeigt. Also muss der
CC die Änderung sofort mitbekommen. Ob sich dieses "Lauschverhalten" aber
nur auf den Fensterkontakt bezieht, weiß ich auch nicht (wäre mir aber
etwas unlogisch).

Am Dienstag, 30. Oktober 2012 00:15:53 UTC+1 schrieb kohrti:
>
> Hallo Uwe,
>
> Am Montag, 29. Oktober 2012 23:53:59 UTC+1 schrieb Uwe:
>>
>> Der CC registriert sofort eine Veränderung des Status' des Threestate und
>> regelt nach ca. 3 Min. die VDs in Frostschutz.
>>
>
> Gibt es dazu zufällig ein Log?
> Wie siehst du denn, dass es SOFORT angenommen wird?
>
> Ich kenne mich (noch) nicht so gut mit den Messages aus, aber ich wäre
> jetzt eher davon ausgegangen, dass es ein Timing Problem ist. Evtl. Gibt es
> ja doch die Möglichkeit dem CC sofort aufzuwecken. Mit einem Log täte man
> sich leichtes das zu beurteilen. Oder die Experten hier können auf Anhieb
> was dazu sagen.
>
> Gruß,
> Kohrti
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

Guest

Originally posted by: <email address deleted>

Hallo nochmal,
 

> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie
> der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>
--> Also das der Sender Typ irgendwie übermittelt wird? Das können
hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
nicht... so ganz allgemein ausgedrückt.

Gruß,
Kohrti

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

Guest

Originally posted by: <email address deleted>

Habe mit der neusten Version (5.3 + Update) mit HMLAN, leider auch nur
MISSING ACKS

Hier mein Post aus dem anderen Thread:

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue
Version hat leider 0% Erfolg.
Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

[/opt/share/fhem/FHEM] # Use of uninitialized value in bitwise or (|) at
/opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.
Use of uninitialized value in bitwise or (|) at
/opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.
Use of uninitialized value in substitution (s///) at
/opt/share/fhem/FHEM/10_CUL_HM.pm line 3107.

Version:
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 2035 2012-10-28 21:28:41Z martinp876 $

Ideen?
Danke & Grüße,
Merhan

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