MAX Eco Switch BC-PB-2-WM - mehrere MAX packets

Deutsche Foren Geräte
#1

Hallo zusammen.

Ich bin noch ziemlich neu in der Materie, habe aber schon rumgesucht und auch einen Beitrag von 2016 gefunden, dachte aber ich mach lieber einen neuen.

Ich habe einen MAX Cube mit a-culfw geflashed und setze diesen im Netzwerk ein. Pairing in homegear läuft tadellos für den Eco Switch und auch mit den Thermostaten.

Wenn ich den Eco Switch betätige bekomme ich allerdings mehrere events in Homegear (und OpenHab2) und er blinkt auch 3 mal. (version 0.7.30-1900) Wenn ich am Thermostat die Solltemperatur umstelle, wird dies korrekt nur einmal gemeldet.

Hier der Logauszug:

01/20/19 19:06:35.133 Module MAX: Info: PRESS on channel 1 of peer 4 with serial number MKF0065430 was set to 0x10.
01/20/19 19:06:35.170 Module MAX: CUNX "cunx_gateway": Info: Sending (cunx_gateway, WOR: no): 0B080202FD3F6913C1860000
01/20/19 19:06:35.378 MAX packet received (cunx_gateway, RSSI: 0x3A): 0C08020213C186FD3F69008100
01/20/19 19:06:35.379 Module MAX: Info: PRESS on channel 1 of peer 4 with serial number MKF0065430 was set to 0x00.
01/20/19 19:06:37.360 MAX packet received (cunx_gateway, RSSI: 0x3C): 0C08025013C186FD3F69001000
01/20/19 19:06:37.362 Module MAX: Info: PRESS on channel 1 of peer 4 with serial number MKF0065430 was set to 0x10.
01/20/19 19:06:37.399 Module MAX: CUNX "cunx_gateway": Info: Sending (cunx_gateway, WOR: no): 0B080202FD3F6913C1860000
01/20/19 19:06:43.058 MAX packet received (cunx_gateway, RSSI: 0x40): 0C08025013C186FD3F69001000
01/20/19 19:06:43.059 Module MAX: Info: PRESS on channel 1 of peer 4 with serial number MKF0065430 was set to 0x10.
01/20/19 19:06:43.064 Module MAX: CUNX "cunx_gateway": Info: Sending (cunx_gateway, WOR: no): 0B080202FD3F6913C1860000

Ist Homegear für das senden der Bestätigung an den Switch zuständig oder der CUNX?

Danke für Eure Hilfe

#2

Keiner?

Im Openhab Forum hab ich gelesen das das “normal” sei was ich mir beim besten Willen nicht vorstellen kann.

@sathya
Sorry dass ich dich hier direkt anschreibe, aber du hattest im alten Post von 2016 (siehe OP) nach den Logs gefragt und ich könnte jetzt liefern. :slight_smile:

2 Likes
#3

Hallo @noidea,

Im Openhab Forum hab ich gelesen das das “normal” sei was ich mir beim besten Willen nicht vorstellen kann.

Nein, das ist nicht so. Der Switch sendet die Pakete erneut, weil er die Antwortpakete nicht empfängt. Das kann am CUNX liegen. Beim CUNO - dem Vorgänger - waren die Latenzen sehr unterschiedlich, so dass da keine zuverlässige Kommunikation möglich war. Beim CUNX ist es besser, ich weiß aber nicht, ob es gut genug ist. Du kannst aber mal mit der Einstellung responseDelay in der max.conf spielen. Reduzier diese mal angefangen bei 50ms in 2er-Schritten bis runter auf 10ms. Nach jeder Änderung muss das MAX-Modul einmal mit homegear -e mrl mod_max.so neu geladen werden. Funktioniert es mit einer der Einstellungen?

Viele Grüße

Sathya

#4

Hi @sathya,

danke fürs Einsteigen.

Ich habe zunächst mit der aktuellsten a-culfw firmware probiert und bin dann mal ein paar Versionen zurückgegangen um zu schauen, wie es dort aussieht. (dort habe ich mir die 2ms Schritte jedoch gespart)

Hier die Ergebnisse mit homegear 0.7.30-1900

a-culfw 1.26.05

response delay finding
90 did not work
75 did not work
60 did not work
50-10, 2ms steps did not work
21 did not work
06 did not work

a-culfw 1.26.02

response delay finding
95 did not work
60 did not work
50-15, 5ms steps did not work
22 did not work
10 did work 2 times
09 did not work
08 did work 2 times
07 did not work
06 worked multiple times (10%)
04 did work at first try of one button

Ich habe vom Raspi mit Openhab und Homegear mal den umgeflashten cube gepingt und die (durchaus schwankenden) Werte bewegen sich in dem Bereich, in dem es funktioniert hat. Allerdings sind mir die Zusammenhänge nicht klar, weshalb das natürlich auch totaler Zufall sein kann. :slight_smile:

Soweit ich weiß kann man den umgeflashten Cube ebenfalls als CUL per USB einsetzen, das werde ich die Tage mal testen. Spielt das response delay da ebenfalls eine Rolle?

Gibt es noch weitere Ansätze?

1 Like
#5

Habe meinen Cube auch mit der aCulFW (aCube) als CUL per USB laufen:

/etc/homegear/families/max.conf

[CUL]
id = My-MAX-CUL
default = true
deviceType = cul
device = /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00

## Should be "40" for MAX!
responseDelay = 40
#6

Es kann durchaus daran liegen, dass die Werte schwanken - um wieviele Millisekunden schwanken sie denn?. Per USB angeschlossen wäre tatsächlich interessant.

#7

Hi @pmayer,

danke schon einmal für die config. Welche FW Version hast du im Einsatz?

#8

Uff… hab den vor zwei Jahren mal geflasht. Die damals aktuelle aCube-FW…

#9

Hi @sathya.

Gute Nachrichten: per USB angeschlossen und als CUL konfiguriert läuft es anstandslos mit der response delay Vorgabe von 40.

Für mich ist das damit geklärt, auf einen Ping der immer gleich sein muss will ich mich nicht verlassen und noch sind freie USB-Plätze am Pi. :slight_smile:

Falls du dran bleiben willst und noch irgendetwas brauchst sag Bescheid.
(ich poste die Alternative noch bei OpenHAB)

1 Like
#10

Hallo zusammen,

ich habe ein ähnliches Problem mit mehreren Signalen vom PC-PB-2-WM im openHAB. Mein homegear Protokoll sieht wie folgt aus:

05/07/19 22:48:38.848 MAX packet received (cul868, RSSI: 0x42): 0C2802500873A9FDF22E001000
05/07/19 22:48:38.850 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x10.
05/07/19 22:48:38.888 Module MAX: CUL "cul868": Info: Sending (cul868, WOR: no): 0B280202FDF22E0873A90000
05/07/19 22:48:39.025 MAX packet received (cul868, RSSI: 0x41): 0C2802020873A9FDF22E008140
05/07/19 22:48:39.026 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x00.
05/07/19 22:48:39.264 MAX packet received (cul868, RSSI: 0x40): 0C2802500873A9FDF22E005000
05/07/19 22:48:39.265 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x50.
05/07/19 22:48:39.303 Module MAX: CUL "cul868": Info: Sending (cul868, WOR: no): 0B280202FDF22E0873A90000
05/07/19 22:48:40.368 MAX packet received (cul868, RSSI: 0x3F): 0C2802500873A9FDF22E005000
05/07/19 22:48:40.369 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x50.
05/07/19 22:48:40.370 Module MAX: CUL "cul868": Info: Sending (cul868, WOR: no): 0B280202FDF22E0873A90000
05/07/19 22:48:42.510 MAX packet received (cul868, RSSI: 0x3F): 0C2802500873A9FDF22E005000
05/07/19 22:48:42.511 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x50.
05/07/19 22:48:42.511 Module MAX: CUL "cul868": Info: Sending (cul868, WOR: no): 0B280202FDF22E0873A90000
05/07/19 22:48:46.699 MAX packet received (cul868, RSSI: 0x3F): 0C2802500873A9FDF22E005000
05/07/19 22:48:46.700 Module MAX: Info: PRESS on channel 1 of peer 3 with serial number KEQ0373946 was set to 0x50.
05/07/19 22:48:46.700 Module MAX: CUL "cul868": Info: Sending (cul868, WOR: no): 0B280202FDF22E0873A90000

Für mich als Laien sieht das OK aus. Allerdings empfängt openHAB aus irgendeinem Grund 4-5 ON Switches:

2019-05-07 22:48:38.853 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '-66' for 'KEQ0373946:0#RSSI_DEVICE' from gateway with id '84bd6c34'

2019-05-07 22:48:38.868 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:38.891 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

2019-05-07 22:48:39.028 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:39.034 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

2019-05-07 22:48:39.267 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:39.306 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

2019-05-07 22:48:40.372 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:40.387 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

2019-05-07 22:48:42.515 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:42.527 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

2019-05-07 22:48:46.704 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'false' for 'KEQ0373946:0#LOWBAT' from gateway with id '84bd6c34'

2019-05-07 22:48:46.714 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Boolean) value 'true' for 'KEQ0373946:1#PRESS' from gateway with id '84bd6c34'

Dementsprechend oft schaltet natürlich mein Aktor. Ich kann mir nicht erklären, woran das liegt - der Switch scheint ja korrekter Weise nur ein mal zu senden.

Kann mir jemand von euch helfen?

Viele Grüße
goddib

#11

Hi @goddib.

Ich würde schon sagen das der Switch mehrfach sendet, sonst hättest du ja nicht mehrere “packet received” im Homegear-Protokoll. (aus der Homegear Perspektive wird empfangen, du hast ja kein Protokoll vom Switch)

Bei mir war das Problem vermeintlich die Latenz, da der umgeflashte MAX Cube als CUNX per Netzwerk angebunden war und die Button-Press Message in einem gewissen kurzen Zeitfenster vom Homegear bestätigt werden muss. (zumindest hatte ich es so verstanden) Als ich auf USB umgestiegen bin lief alles reibungslos. Das allerdings kann es bei dir ja nicht sein.

Ich bin leider auch totaler Anfänger im Homegear,würde aber als ersten Schritt mal mit dem Response Delay in der config spielen und dabei beobachten ob sich etwas verändert.

Bisschen komisch finde ich auch, dass einmal 0x10, dann 0x00 und anschließend 4 mal 0x50 kommt. Du hast aber nur einen Schalter einmal betätigt?

Grüße
Steffen

#12

Hallo @goddib, hallo @noidea,

kann es vielleicht sein, dass 0x50 so etwas wie LONG_PRESS ist? Ich kann doppelte Pakete Filtern. Vermutlich da der ECO-Switch nicht so häufig verwendet wird, war das bisher nie ein Thema. Könntet ihr noch ein paar Mal kurz den ECO-Switch drücken und ein paar Mal für mehrere Sekunden und mir anschließend das Homegear-Log mit den aufgezeichneten Paketen posten? Falls kurzer und langer Druck unterschieden werden, baue ich die Unterscheidung in die XML-Datei ein.

Viele Grüße

Sathya

#13

@sathya ich habe die Arbeit mit dem Taster jetzt aufgegeben und versuche mit Zigbee Schaltern zu arbeiten. Da MAX! ausgephased wird, wird es wohl auch in Zukunft nicht mehr viele Menschen geben, die an dieser Stelle stolpern und die Zeit ist vielleicht woanders besser investiert.

Vielen Dank für dein Angebot, viele Grüße
goddib

#14

Ist das so? Hast Du eine Quelle?

#15

Bei Conrad werden die Taster gerade für 5, die Thermostate für 10 Euro verkauft. Mir wurde dort mitgeteilt, dass das System nicht weiter angeboten wird. Im Forum https://www.elv.de/forum/max-funk-heizungsregler-system.html gibt es einige Threads und vor allen Dingen viel Stille, die darauf hinweisen. Und es gibt schon ewig keine Updates mehr vom Hersteller und Lieferschwierigkeiten bei einigen Modulen

Also, nein, ich habe keine offizielle Quelle, aber viele Hinweise.

#16

Hi @sathya.

Ich habe mal aufgezeichnet. Beim lang drücken (ca. 4s) blinkt die Lampe am Schalter ohne aufzuhören. Dann dauert es einen kurzen Moment bis der Eintrag im Log erscheint. Wenn ich den Knopf erneut drücke hört das Blinken auf - das ist Zeile 2 bei den “long presses”.

Falls du mehr brauchst sag Bescheid.

eco short press
05/27/19 19:19:28.882 MAX packet received (cunx_gateway, RSSI: 0x24): 0C73025013C186FD3F69001000
05/27/19 19:19:28.883 Module MAX: Info: PRESS on channel 1 of peer 4 with serial number MKF0065430 was set to 0x10.
05/27/19 19:19:28.921 Module MAX: CUL “cunx_gateway”: Info: Sending (cunx_gateway, WOR: no): 0B730202FD3F6913C1860000

eco long press
05/27/19 19:20:28.844 MAX packet received (cunx_gateway, RSSI: 0x28): 1775040013C186FD3F69001005004D4B4630303635343330
05/27/19 19:20:33.748 MAX packet received (cunx_gateway, RSSI: 0x28): 1775040013C186FD3F69001005004D4B4630303635343330

auto short press
05/27/19 19:21:56.765 MAX packet received (cunx_gateway, RSSI: 0x26): 0C76025013C186FD3F69001001
05/27/19 19:21:56.766 Module MAX: Info: PRESS on channel 2 of peer 4 with serial number MKF0065430 was set to 0x10.
05/27/19 19:21:56.804 Module MAX: CUL “cunx_gateway”: Info: Sending (cunx_gateway, WOR: no): 0B760202FD3F6913C1860000

auto long press
05/27/19 19:22:44.246 MAX packet received (cunx_gateway, RSSI: 0x22): 1778040013C186FD3F69001005004D4B4630303635343330
05/27/19 19:22:49.153 MAX packet received (cunx_gateway, RSSI: 0x22): 1778040013C186FD3F69001005004D4B4630303635343330

#17

Danke für die Info.

#18

Hallo @noidea,

beim langen Drücken geht der Taster in den Anlernmodus. D. h. das wird nicht unterstützt - schade. Beim kurzen Druck kam jetzt auch nur ein Paket. Vermutlich kommt es zur Wiederholung, wenn die Antwort von Homegear an den Taster vom Taster nicht empfangen wurde.

Viele Grüße

Sathya