putParamSet -> LOVF über viele Stunden

Deutsche Foren Allgemein
#1

Hallo,

ich will gerade ein paar neue Wochenprogramme auf unsere MAX! Komponenten überspielen. Ich mache das Ganze über ein php-Skript:

#!/usr/bin/env php
<?php
include_once("Connect.php");

print_r($Client->send("putParamset", array(5, -1, "MASTER", array(
        "TEMPERATURE_MONDAY_1" => 17.0,
        "ENDTIME_MONDAY_1" => 360,
        "TEMPERATURE_MONDAY_2" => 21.0,
        "ENDTIME_MONDAY_2" => 540,
        "TEMPERATURE_MONDAY_3" => 17.0,
        "ENDTIME_MONDAY_3" => 960,
        "TEMPERATURE_MONDAY_4" => 21.0,
        "ENDTIME_MONDAY_4" => 1200,
        "TEMPERATURE_MONDAY_5" => 17.0,
        "ENDTIME_MONDAY_5" => 1440,
        "TEMPERATURE_TUESDAY_1" => 17.0,
        "ENDTIME_TUESDAY_1" => 360,
        "TEMPERATURE_TUESDAY_2" => 21.0,
        "ENDTIME_TUESDAY_2" => 540,
        "TEMPERATURE_TUESDAY_3" => 17.0,
        "ENDTIME_TUESDAY_3" => 960,
        "TEMPERATURE_TUESDAY_4" => 21.0,
        "ENDTIME_TUESDAY_4" => 1200,
        "TEMPERATURE_TUESDAY_5" => 17.0,
        "ENDTIME_TUESDAY_5" => 1440,
        "TEMPERATURE_WEDNESDAY_1" => 17.0,
        "ENDTIME_WEDNESDAY_1" => 360,
        "TEMPERATURE_WEDNESDAY_2" => 21.0,
        "ENDTIME_WEDNESDAY_2" => 540,
        "TEMPERATURE_WEDNESDAY_3" => 17.0,
        "ENDTIME_WEDNESDAY_3" => 960,
        "TEMPERATURE_WEDNESDAY_4" => 21.0,
        "ENDTIME_WEDNESDAY_4" => 1200,
        "TEMPERATURE_WEDNESDAY_5" => 17.0,
        "ENDTIME_WEDNESDAY_5" => 1440,
        "TEMPERATURE_THURSDAY_1" => 17.0,
        "ENDTIME_THURSDAY_1" => 360,
        "TEMPERATURE_THURSDAY_2" => 21.0,
        "ENDTIME_THURSDAY_2" => 540,
        "TEMPERATURE_THURSDAY_3" => 17.0,
        "ENDTIME_THURSDAY_3" => 960,
        "TEMPERATURE_THURSDAY_4" => 21.0,
        "ENDTIME_THURSDAY_4" => 1200,
        "TEMPERATURE_THURSDAY_5" => 17.0,
        "ENDTIME_THURSDAY_5" => 1440,
        "TEMPERATURE_FRIDAY_1" => 17.0,
        "ENDTIME_FRIDAY_1" => 360,
        "TEMPERATURE_FRIDAY_2" => 21.0,
        "ENDTIME_FRIDAY_2" => 540,
        "TEMPERATURE_FRIDAY_3" => 17.0,
        "ENDTIME_FRIDAY_3" => 960,
        "TEMPERATURE_FRIDAY_4" => 21.0,
        "ENDTIME_FRIDAY_4" => 1200,
        "TEMPERATURE_FRIDAY_5" => 17.0,
        "ENDTIME_FRIDAY_5" => 1440,
        "TEMPERATURE_SATURDAY_1" => 17.0,
        "ENDTIME_SATURDAY_1" => 480,
        "TEMPERATURE_SATURDAY_2" => 21.0,
        "ENDTIME_SATURDAY_2" => 1200,
        "TEMPERATURE_SATURDAY_3" => 17.0,
        "ENDTIME_SATURDAY_3" => 1440,
        "TEMPERATURE_SUNDAY_1" => 17.0,
        "ENDTIME_SUNDAY_1" => 480,
        "TEMPERATURE_SUNDAY_2" => 21.0,
        "ENDTIME_SUNDAY_2" => 1200,
        "TEMPERATURE_SUNDAY_3" => 17.0,
        "ENDTIME_SUNDAY_3" => 1440,
))));
?>

Jetzt bekomme ich aber schon seit mehreren Stunden LOVF-Meldungen im Log, was ja bedeuten würde, dass der CUL die 1% Grenze erreicht hat. Gut, das da oben sind ja auch deutlich mehr als 36 Pakete, aber auch wiederum weniger als 72. Das Skript habe ich nun vor mehr als 3 Stunden abgesetzt und die queue ist immer noch voll.
Gestern Abend habe ich ein paar Links zwischen Fensterkontakten und Stellwerken gesetzt und bin auch sofort auf LOVF gestoßen. Habs dann über Nacht laufen lassen und jetzt scheint alles OK zu sein.
Auf den Stellwerken ist auch noch eine volle queue, obwohl ich die vor gut 4 Stunden programmiert habe. Vielleicht gehe ich ja auch prinzipiell falsch an das Übertragen von Wochenprogrammen ran, aber es erscheint mir irgendwie seltsam, dass das Einspielen von den Temperaturen hier meinen CUL für viele Stunden bzw. über Nacht komplett blockiert…

Stellwerks-Queue (Kinderzimmer):

> queues info
Number of Pending queues: 1
Queue 1:
  Number of packets: 14
  Packet 1 (Type: Packet): 19020010FD0AB610750E0000446054F045204520452045204520
  Packet 2 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 3 (Type: Packet): 19010010FD0AB610750E0001446054F045204520452045204520
  Packet 4 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 5 (Type: Packet): 19020010FD0AB610750E00024448546C44C054F0452045204520
  Packet 6 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 7 (Type: Packet): 19030010FD0AB610750E00034448546C44C054F0452045204520
  Packet 8 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 9 (Type: Packet): 19040010FD0AB610750E00044448546C44C054F0452045204520
  Packet 10 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 11 (Type: Packet): 19050010FD0AB610750E00054448546C44C054F0452045204520
  Packet 12 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 13 (Type: Packet): 19060010FD0AB610750E00064448546C44C054F0452045204520
  Packet 14 (Type: Message): Type: 02 Subtype: FFFFFFFF

Stellwerks-Queue (Schlafzimmer, linker Radiator):

> queues info
Number of Pending queues: 1
Queue 1:
  Number of packets: 14
  Packet 1 (Type: Packet): 19000010FD0AB60B725500004520550845204520452045204520
  Packet 2 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 3 (Type: Packet): 19360010FD0AB60B725500014520550845204520452045204520
  Packet 4 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 5 (Type: Packet): 191E0010FD0AB60B725500024520546C44CC5514452045204520
  Packet 6 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 7 (Type: Packet): 19030010FD0AB60B725500034520546C44CC5514452045204520
  Packet 8 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 9 (Type: Packet): 19040010FD0AB60B725500044520546C44CC5514452045204520
  Packet 10 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 11 (Type: Packet): 19050010FD0AB60B725500054520546C44CC5514452045204520
  Packet 12 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 13 (Type: Packet): 19060010FD0AB60B725500064520546C44CC5514452045204520
  Packet 14 (Type: Message): Type: 02 Subtype: FFFFFFFF

Stellwerks-Queue (Schlafzimmer, rechter Radiator):

Number of Pending queues: 1
Queue 1:
  Number of packets: 14
  Packet 1 (Type: Packet): 19000010FD0AB60B728800004520550845204520452045204520
  Packet 2 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 3 (Type: Packet): 19340010FD0AB60B728800014520550845204520452045204520
  Packet 4 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 5 (Type: Packet): 19270010FD0AB60B728800024520546C44CC5514452045204520
  Packet 6 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 7 (Type: Packet): 19060010FD0AB60B728800034520546C44CC5514452045204520
  Packet 8 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 9 (Type: Packet): 19060010FD0AB60B728800044520546C44CC5514452045204520
  Packet 10 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 11 (Type: Packet): 19050010FD0AB60B728800054520546C44CC5514452045204520
  Packet 12 (Type: Message): Type: 02 Subtype: FFFFFFFF
  Packet 13 (Type: Packet): 19060010FD0AB60B728800064520546C44CC5514452045204520
  Packet 14 (Type: Message): Type: 02 Subtype: FFFFFFFF

Poste auch gerne Auszüge aus den logs, aber im Wesentlichen sinds halt solche Zeilen, die sich ständig wiederholen:

[quote]-03/10/15 14:38:15.606 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 19340010FD0AB60B728800014520550845204520452045204520
102204:03/10/15 14:38:15.609 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF[/quote]

#2

Hallo,

hmm, sind denn übermäßig viele Sendeeinträge im Log? Entscheidend ist “WOR: yes”. Nur dann kostet das Senden gut eine Sekunde. Poste vielleicht mal das Log vom letzten Ereignis.

Liebe Grüße

Sathya

#3

Woran erkenne ich denn, ob es übermäßig viele sind? Es scheint so, als würde Homegear alle ~3 Minuten versuchen, Pakete abzusenden. Die sind alle mit WOR: yes gekennzeichnet.

Ich hatte zwischendurch mal über openHAB ein Stellwerk, was direkt mit dem CUL gepaart ist, steuern können. Diese Pakete waren WOR: no und gingen durch. Mittlerweile gibt es auch dabei LOVF-Meldungen im Log. Das komplette Logfile ist jetzt auch schon ~10 mb groß, also vielleicht ein bisschen zuviel zum Anhängen?

Hier mal ein Ausschnitt. Im Wesentlichen zeigt der eigentlich so ziemlich alles was immer wieder periodisch vorkommt:

[quote]03/10/15 17:44:10.343 MAX packet received (CUL, RSSI: 0x38): 0E0A02020B7255FD0AB60001180022
03/10/15 17:44:10.383 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 19560010FD0AB60B725500014520550845204520452045204520
03/10/15 17:44:10.385 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF

03/10/15 17:44:13.503 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 19570010FD0AB60B725500014520550845204520452045204520
03/10/15 17:44:13.506 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF

03/10/15 17:44:16.506 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 19580010FD0AB60B725500014520550845204520452045204520
03/10/15 17:44:16.508 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF

03/10/15 17:44:20.593 Info: Peer 7 is unreachable.
03/10/15 17:44:20.598 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:44:20.599 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:44:20.601 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1940
03/10/15 17:45:26.902 MAX packet received (CUL, RSSI: 0x38): 0F0104600B72550000000018252A00BF
03/10/15 17:45:26.908 Module MAX: Info: ACTUAL_TEMPERATURE on channel 1 of peer 7 with serial number KEQ0445136 was set to 0x00BF.
03/10/15 17:45:26.911 Module MAX: Info: CONTROL_MODE on channel 1 of peer 7 with serial number KEQ0445136 was set to 0x00.
03/10/15 17:45:26.914 Module MAX: Info: LOCKED on channel 1 of peer 7 with serial number KEQ0445136 was set to 0x00.
03/10/15 17:45:26.916 Module MAX: Info: SET_TEMPERATURE on channel 1 of peer 7 with serial number KEQ0445136 was set to 0x2A.
03/10/15 17:45:26.919 Module MAX: Info: VALVE_STATE on channel 1 of peer 7 with serial number KEQ0445136 was set to 0x25.
03/10/15 17:45:26.920 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:45:26.921 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:45:26.923 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1941
03/10/15 17:45:26.931 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:45:26.931 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:45:26.933 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1942
03/10/15 17:45:26.943 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:45:26.944 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:45:26.946 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1943
03/10/15 17:46:01.864 MAX packet received (CUL, RSSI: 0x3B): 0CB7044210AF3D0B61FB002AD6
03/10/15 17:46:01.867 Module MAX: Info: ACTUAL_TEMPERATURE on channel 1 of peer 2 with serial number LKF0028151 was set to 0x00D6.
03/10/15 17:46:01.870 Module MAX: Info: SET_TEMPERATURE on channel 1 of peer 2 with serial number LKF0028151 was set to 0x2A.
03/10/15 17:46:01.871 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:01.872 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:01.873 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1944
03/10/15 17:46:01.879 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:01.880 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:01.882 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1945
03/10/15 17:46:01.910 MAX packet received (CUL, RSSI: 0x31): 0EB702020B61FB10AF3D000118142A
03/10/15 17:46:01.914 Module MAX: Info: CONTROL_MODE on channel 1 of peer 3 with serial number KEQ0450079 was set to 0x00.
03/10/15 17:46:01.916 Module MAX: Info: LOCKED on channel 1 of peer 3 with serial number KEQ0450079 was set to 0x00.
03/10/15 17:46:01.918 Module MAX: Info: SET_TEMPERATURE on channel 1 of peer 3 with serial number KEQ0450079 was set to 0x2A.
03/10/15 17:46:01.921 Module MAX: Info: VALVE_STATE on channel 1 of peer 3 with serial number KEQ0450079 was set to 0x14.
03/10/15 17:46:01.922 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:01.923 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:01.924 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1946
03/10/15 17:46:01.930 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:01.931 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:01.933 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1947
03/10/15 17:46:08.320 RPC Server (Port 2001): Info: Connection from 192.168.3.21:50167 accepted. Client number: 1948
03/10/15 17:46:08.324 RPC Server (Port 2001): Info: Client number 1948 is calling RPC method: setValue Parameters:
(String) LKF0030734:1
(String) SET_TEMPERATURE
(Float) 17.5
03/10/15 17:46:08.336 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 0B2E0440FD0AB61074980163
03/10/15 17:46:08.340 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:08.348 RPC Server (Port 2001): Info: Connection to client number 1948 closed (3).
03/10/15 17:46:08.351 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:08.356 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1949
03/10/15 17:46:09.177 RPC Server (Port 2001): Info: Connection from 192.168.3.21:50169 accepted. Client number: 1950
03/10/15 17:46:09.180 RPC Server (Port 2001): Info: Client number 1950 is calling RPC method: setValue Parameters:
(String) LKF0030734:1
(String) SET_TEMPERATURE
(Float) 17
03/10/15 17:46:09.189 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:09.197 RPC Server (Port 2001): Info: Connection to client number 1950 closed (3).
03/10/15 17:46:09.191 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:09.203 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1951
03/10/15 17:46:09.405 MAX packet received (CUL, RSSI: 0x3E): 0E2E0202107498FD0AB60001390023
03/10/15 17:46:09.409 Module MAX: Info: CONTROL_MODE on channel 1 of peer 1 with serial number LKF0030734 was set to 0x01.
03/10/15 17:46:09.412 Module MAX: Info: LOCKED on channel 1 of peer 1 with serial number LKF0030734 was set to 0x01.
03/10/15 17:46:09.414 Module MAX: Info: VALVE_STATE on channel 1 of peer 1 with serial number LKF0030734 was set to 0x00.
03/10/15 17:46:09.415 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:09.415 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:09.417 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1952
03/10/15 17:46:09.445 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: no): 0B2E0002FD0AB61074980000
03/10/15 17:46:09.468 Info: Calling XML RPC method “system.multicall” on server binary://192.168.3.21 and port 9123.
03/10/15 17:46:09.468 Info: Connecting to host 192.168.3.21 on port 9123…
03/10/15 17:46:09.470 Info: Connected to host 192.168.3.21 on port 9123. Client number is: 1953
03/10/15 17:46:09.484 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: no): 0B2F0440FD0AB61074980162
03/10/15 17:46:12.577 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 0B300440FD0AB61074980162
03/10/15 17:46:12.581 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF

03/10/15 17:46:15.580 Module MAX: CUL “CUL”: Info: Sending (CUL, WOR: yes): 0B310440FD0AB61074980162
03/10/15 17:46:15.583 Module MAX: CUL “CUL”: Warning: Too short packet received: LOVF[/quote]

EDIT:
Die Queues sind immer noch genauso voll wie vorhin, also scheint sich nichts getan zu haben?!

#4

Der CUL rechnet mit 15-Minuten-Blöcken. Maximal können 8 WOR-Pakete in 15 Minuten gesendet werden. Ich spiel mal kurz etwas und melde mich gleich noch einmal.

Liebe Grüße

Sathya

#5

Also, das Problem ist, dass jedes der Config-Pakete ein WOR-Paket sein muss - total blöd. Das Gerät könnte doch wenigstens für 200ms empfangsbereit bleiben (so ist es auch bei HomeMatic)? Da der CUL maximal 8 Pakete in 15 Minuten zulässt, sind die Queues zu lang. Homegear fängt bei einem Fehler immer wieder am Anfang der Queue an - das ist bei MAX! natürlich bescheuert. Letzteres Verhalten habe ich jetzt geändert. Es wird gerade ein neues Stable-Release kompiliert (0.5.24-5). Da habe ich die Queues verkleinert und entsprechend sollten die Queues langsam kleiner werden. Allerdings musst du die alten Queues mit “queues clear” im CLI einmal löschen.

Welches Betriebssystem hast du auf deinem BeagleBoard am Laufen? Dann kann ich dir schnell ein Paket zum Testen bauen - der Build-Server wird ein paar Tage brauchen.

Liebe Grüße

Sathya

#6

Cool, dass du den Fehler gefunden hast. Das war ja mal wieder megafix!

Ich hab Homegear mittlerweile auf meinen RPi 1 B+ migriert, weil ich nicht zwei Geräte parallel betreiben wollte, wenn die Resourcen auch auf einem reichen :slight_smile: Als Distro benutz ich Raspbian Wheezy.

Die queues sind jetzt leer und ich gebe dem CUL mal ne Stunde Zeit und setze die (Familien-)kritischen Wochenpläne dann in Etappen bis die neue Version raus ist.

#7

Hey,

Raspbian Wheezy ist super. Das Paket ist in wenigen Stunden fertig :wink:. Bin gespannt auf deine Rückmeldung. Ich hoffe, damit funktioniert es besser…

Liebe Grüße

Sathya

#8

Ich gehe mal stark davon aus, dass du den Fehler korrekt identifiziert hast. Ich habe jetzt nämlich das Stellwerk im Kinderzimmer korrekt programmieren können, indem ich den putParamset-Befehl in mehreren kleinen Häppchen abgesetzt habe. So musste ich tatsächlich nur einmal wegen LOVF unterbrechen.
Komme allerdings erst morgen spätabends zum Testen der neuen Version :wink:

#9

Die neue Version (0.5.24-5) hat das Problem mit den zu großen Queues behoben. Jetzt kann man auch “große” Wochenpläne per Skript in einem Rutsch übertragen und Homegear/CUL arbeiten das dann brav in 15 min Blöcken ab :slight_smile:

#10

Hallo,
ich benutze aktuell 0.5.24-6 und habe ein ähnliches Problem mit einem HM-Dis-WM55 bei dem ich versuche die Texte überein PHP Script zu setzen.

mit

$Client->send("putParamset", array($id, 1, "MASTER", array("TEXTLINE_1" => "Test42")));
$Client->send("putParamset", array($id, 1, "MASTER", array("TEXTLINE_2" => "Hallo Welt")));

gibt es folgende Ausgabe im Log:

03/30/15 22:59:03.869 RPC Server (Port 2001): Info: Connection from 127.0.0.1:36033 accepted. Client number: 148
03/30/15 22:59:03.871 RPC Server (Port 2001): Info: Client number 148 is calling RPC method: getServiceMessages Parameters:
03/30/15 22:59:03.967 RPC Server (Port 2001): Info: Connection to client number 148 closed.
03/30/15 22:59:03.968 RPC Server (Port 2001): Info: Connection from 127.0.0.1:36035 accepted. Client number: 149
03/30/15 22:59:03.976 RPC Server (Port 2001): Info: Client number 149 is calling RPC method: putParamset Parameters:
(Integer) 19
(Integer) 1
(String) MASTER
(Struct length=1)
{
  [TEXTLINE_1]
  {
    (String) Test42
  }
}
03/30/15 22:59:03.997 Module HomeMatic BidCoS: Info: Parameter TEXTLINE_1 of peer 19 and channel 1 was set to 0x54657374343200546573743432.
03/30/15 22:59:04.001 Info: Calling XML RPC method "system.multicall" on server binary://192.168.42.4 and port 9123.
03/30/15 22:59:04.001 Info: Connecting to host 192.168.42.4 on port 9123...
03/30/15 22:59:04.001 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Info: Sending (My-HM-CFG-LAN): 101BA001FD0AAE3515FC01050000000001
03/30/15 22:59:04.002 Info: Connected to host 192.168.42.4 on port 9123. Client number is: 150
03/30/15 22:59:04.656 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Info: No response to packet after 3 tries: 101BA001FD0AAE3515FC01050000000001
03/30/15 22:59:09.009 RPC Server (Port 2001): Info: Connection to client number 149 closed.
03/30/15 22:59:09.010 RPC Server (Port 2001): Info: Connection from 127.0.0.1:36038 accepted. Client number: 151
03/30/15 22:59:09.011 RPC Server (Port 2001): Info: Client number 151 is calling RPC method: putParamset Parameters:
(Integer) 19
(Integer) 1
(String) MASTER
(Struct length=1)
{
  [TEXTLINE_2]
  {
    (String) Hallo Welt
  }
}
03/30/15 22:59:09.012 Module HomeMatic BidCoS: Info: Parameter TEXTLINE_2 of peer 19 and channel 1 was set to 0x48616C6C6F2057656C740048616C6C6F2057656C74.
03/30/15 22:59:13.581 HomeMatic BidCoS packet received (My-HM-CFG-LAN, RSSI: 0x4A): 0F58861028BC850000000A88BD0E0040

und die Queue des Devices zeigt:

Dies wird auch über einen längeren Zeitraum nicht abgearbeitet. Wenn dann auf dem Displaytaster eine Taste gedrückt wird erscheint im log:


03/30/15 23:07:25.937 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Info: Sending (My-HM-CFG-LAN): 101BA001FD0AAE3515FC01050000000001
03/30/15 23:07:26.781 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "My-HM-CFG-LAN": Info: No response to packet after 3 tries: 101BA001FD0AAE3515FC01050000000001

Kann man irgendwie einsehen wie es mit der Sendeauslastung aussieht?

Danke und Gruss

#11

Hallo,

zur Zeit kannst du die Sendeauslastung noch nicht einsehen (kommt aber). Das ist bei dir aber nicht das Problem. Der HM-Dis-WM55 ist ein bisschen kompliziert. Ich poste morgen mal eine kleine Anleitung (falls ich es vergessen sollte, hau mich noch einmal an :wink:).

Liebe Grüße

Sathya

#12

Also…

Die Datenübertragung der Textzeilen an den HM-Dis-WM55 findet nach einem Tastendruck statt. Sie lässt sich nicht von Homegear aus triggern. Die Übertragung muss auch mit jedem Tastendruck stattfinden, sonst steht auf dem Display “Keine Daten empfangen”. Um das zu bewerkstelligen, würde ich mittels der RPC-Funktion “addEvent” jeweils ein Ereignis hinzufügen, welches auf “PRESS_SHORT” und “PRESS_LONG” reagiert und über ein Skript die Textzeilen setzt.

Die Textzeilen selbst müssen in einer recht merkwürdigen Kodierung als Hexadezimalwerte an die Variable “SUBMIT” übergeben werden. Also:

setValue(<GERÄTEID>, 1, "SUBMIT", "<DATEN>").

Hier der Aufbau der Daten:

Erst einmal ein paar Zahlen:

Farben:
[ul]
[li] 0x80 weiß[/li]
[li] 0x81 rot[/li]
[li] 0x82 orange[/li]
[li] 0x83 gelb[/li]
[li] 0x84 grün[/li]
[li] 0x85 blau[/li][/ul]

Symbole:
[ul]
[li] 0x80 aus[/li]
[li] 0x81 an[/li]
[li] 0x82 offen[/li]
[li] 0x83 geschlossen[/li]
[li] 0x84 Fehler[/li]
[li] 0x85 ok[/li]
[li] 0x86 Info[/li]
[li] 0x87 neue nachricht[/li]
[li] 0x88 Servicemeldung[/li]
[li] 0x89 Signal grün[/li]
[li] 0x8A Signal gelb[/li]
[li] 0x8B Signal rot[/li][/ul]

Vordefinierte Texte:
[ul]
[li] 0x80 Text 0, Kanal 1[/li]
[li] 0x81 Text 1, Kanal 1[/li]
[li] …[/li]
[li] 0x93 Text 19, Kanal 10[/li][/ul]

Die vordefinierten Texte kannst du als Konfigurationsparameter einstellen (was du bereits probiert hast). Nach dem Setzen der Konfirationsparameter musst du den Knopf hinten am Taster drücken und anschließend “Übernehmen” auswählen.

Die Daten sind jetzt folgendermaßen aufgebaut:

Start: 0x02
Zeile 1 bis Zeile 6: 0x12 oder <HEX für vordefinierten Text> 0x11 0x13 0x0A
Ende: 0x03

Farbe und Icon sind dabei optional und Zeilen am Ende können weggelassen werden.

Also als Beispiel:

Liebe Grüße

Sathya

#13

Danke!

Das hat mich schon mal ein ganz kleines Stück weitergebracht.

Folgendes erscheint noch im Log:

3/31/15 23:16:49.506 RPC Server (Port 2001): Info: Connection from 127.0.0.1:48025 accepted. Client number: 9421
03/31/15 23:16:49.506 RPC Server (Port 2001): Info: Client number 9421 is calling RPC method: setValue Parameters:
(String) MEQ0022733:1
(String) SUBMIT
(String) 021280118313860A03
03/31/15 23:16:49.507 Module HomeMatic BidCoS: Error constructing packet. param "SUBMIT" not found. Peer: 19 Serial number: MEQ0022733 Frame: SEND_TEXT
03/31/15 23:16:49.511 RPC Server (Port 2001): Info: Connection to client number 9421 closed (3).

irgendwie scheint noch was nicht zu passen. Den vordefinierten Text habe ich zuvor gesetzt:

print_r($Client->send("putParamset", array($id, 1, "MASTER", array("TEXTLINE_1" => "021280118313820A0A13810A0A12333411830A0A03"))));
print_r($Client->send("putParamset", array($id, 1, "MASTER", array("TEXTLINE_2" => "021280118313820A0A13810A0A12333411830A0A03"))));

Die Ausgabe am Display scheint immer noch “Keine Daten empfangen”.

Ich bin gerade dabei das Display in mein homegar openHAB Universum zu integrieren … aber das Dingen ist echt bockig. Wenn ich es fertig habe währe das vll Interessant für Dein wiki ?

Tausend Dank für Deine Hilfe!

#14

Ja, das wäre auf jeden Fall interessant für das Wiki!

Das ist mein Fehler. Da habe ich geschlafen und die funktionierende XML-Datei nicht aus meiner Testumgebung übertragen. Ändere in der Datei “/etc/homegear/devices/0/rf_dis_wm55.xml” die Zeile

in

Dann sollte es gehen. Ist auch im nächsten Update :wink:.

Liebe Grüße

Sathya

#15

Perfekt, Danke ! Funktioniert!

ich mach dann mal weiter mit der Integration und sage Dir bescheid, wenn ich mir der docu fertig bin. Das kannst dann gerne übernehmen,

Viele Grüße

Jan