Selbstbau CUN (MapleCUN)

[vbs]

Hat mir keine Ruhe gelassen... hab es noch schnell angeschlossen... krieg es aber natürlich gar nicht zum Laufen.

Dacht ich wäre schlau und ich muss evtl. den HM-UART gar nicht von der Maple-Platine runterlöten und hab den USB-UART gleich da auf der Platine angeschlossen. Hab alle Pins gemessen und ist meiner Meinung nach korrekt. Also 3,3 V VCC, GND, RX und TX.
Geht das prinzipiell so oder ist das ne blöde Idee? 

Was mich stutzig macht, ist die Messung auf dem Oszilloskop. Das ist die RX-Leitung des HM-UART. Ich hätte eigentlich gedacht, dass der Pegel zwischen den 3,3 V und 0 V wechselt. Aber der Pegel geht nur bis 2,7 V runter wenn ich was sende. Kann mir jemand einen Tip geben? Danke!

[vbs]

Ok, hab es jetzt doch runter gelötet. Und ich glaub dabei haben sich ein paar Pads verabschiedet 

Aber jetzt habe ich den HM-MOD-UART direkt per USB-Adapter am Rechner, ohne Maple und die RTTs sehen jetzt tatsächlich wesentlich besser aus:

Code Auswählen Erweitern

2019.01.08 08:36:15.050 5: HMUARTLGW sys_culHm roundtrip delay: 0.0039
2019.01.08 08:36:30.060 5: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.08 08:36:45.065 5: HMUARTLGW sys_culHm roundtrip delay: 0.0093
2019.01.08 08:38:05.711 0: HMUARTLGW sys_culHm roundtrip delay: 0.0052
2019.01.08 08:38:20.719 0: HMUARTLGW sys_culHm roundtrip delay: 0.0084
2019.01.08 08:38:35.728 0: HMUARTLGW sys_culHm roundtrip delay: 0.0088
2019.01.08 08:38:50.735 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:05.744 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:20.751 0: HMUARTLGW sys_culHm roundtrip delay: 0.0154
2019.01.08 08:39:35.747 0: HMUARTLGW sys_culHm roundtrip delay: 0.0059
2019.01.08 08:39:50.754 0: HMUARTLGW sys_culHm roundtrip delay: 0.0085
2019.01.08 08:40:05.762 0: HMUARTLGW sys_culHm roundtrip delay: 0.0126
2019.01.08 08:40:20.771 0: HMUARTLGW sys_culHm roundtrip delay: 0.0153
2019.01.08 08:40:35.778 0: HMUARTLGW sys_culHm roundtrip delay: 0.0183
2019.01.08 08:40:50.779 0: HMUARTLGW sys_culHm roundtrip delay: 0.0155
2019.01.08 08:41:05.787 0: HMUARTLGW sys_culHm roundtrip delay: 0.0124
2019.01.08 08:41:20.784 0: HMUARTLGW sys_culHm roundtrip delay: 0.0055

Also scheint wohl tatsächlich am MapleCUL zu liegen.

[Telekatz]

Es muss aber auch an deinem System liegen. An einem Raspberry Pi sehen die Zeiten vom MapleCUL normal aus:

Code Auswählen Erweitern

2019.01.08 11:44:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0077
2019.01.08 11:44:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:44:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:45:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:45:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0066
2019.01.08 11:45:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:45:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:46:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:46:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0065
2019.01.08 11:46:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0064
2019.01.08 11:46:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:47:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0065
2019.01.08 11:47:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0083
2019.01.08 11:47:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0079
2019.01.08 11:47:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:48:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:48:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:48:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0073
2019.01.08 11:48:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:49:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0069
2019.01.08 11:49:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0080
2019.01.08 11:49:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:49:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0073
2019.01.08 11:50:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:50:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0069
2019.01.08 11:50:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:50:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:51:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0074
2019.01.08 11:51:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:51:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:51:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0081


[vbs]

Ok danke, sehr interessant. Heißt einerseits, dass es prinzipiell geht. Andererseits hab ich erstmal keine Idee, warum der bei mir mit dem Maple so Zicken macht

Welche Firmware war das bei deinem Test? Die gestern angehängte?
Und welche Hardware hast du an dem Maple dran? Nur den HM-MOD-UART? Und in FHEM vermtl. auch nur den HMUARTLGW definiert?

[Telekatz]

Die Firmware ist die von gestern. Und die FHEM Konfiguration ist sehr reduziert:

Code Auswählen Erweitern

attr global userattr alexaName alexaRoom cmdIcon devStateIcon devStateStyle fp_Heizung genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global commandref modular
attr global exclude_from_update 21_VBUSDEV.pm 19_VBUSIF.pm
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB has no associated allowed device with basicAuth.\
telnetPort has no associated allowed device with password/globalpassword.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\

attr global room System
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3
#attr global backupdir /media/fritzbox-usb/raspberry

define telnetPort telnet 7073 global
attr telnetPort room System

define WEB FHEMWEB 8083 global
attr WEB hiddenroom DashboardRoom
attr WEB room System


# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
attr Logfile room System

define autocreate autocreate
attr autocreate disable 0
attr autocreate room System

define eventTypes eventTypes ./log/eventTypes.txt
attr eventTypes room System

# Disable this to avoid looking for new USB devices on startup
# define initialUsbCheck notify global:INITIALIZED usb create
define CUL_0 CUL /dev/serial/by-id/usb-STM32_MapleCUL_68e0d57e-if00@9600 1122
attr CUL_0 rfmode SlowRF
attr CUL_0 room System
attr CUL_0 verbose 3


define myHmUART HMUARTLGW /dev/serial/by-id/usb-STM32_MapleCUL_68e0d57e-if02@115200
attr myHmUART hmId F11135
attr myHmUART logIDs sys
attr myHmUART room System
attr myHmUART verbose 3
define FHT_282a FHT 282a
attr FHT_282a IODev CUL_0
attr FHT_282a room FHT
define FHT_311c FHT 311c
attr FHT_311c IODev CUL_0
attr FHT_311c room FHT
define FHT_3755 FHT 3755
attr FHT_3755 IODev CUL_0
attr FHT_3755 room FHT
define CUL_WS_1 CUL_WS 1
attr CUL_WS_1 room CUL_WS
define KS300 KS300 1234
attr KS300 IODev CUL_0
attr KS300 room KS300
define CUL_EM_4 CUL_EM 4
attr CUL_EM_4 IODev CUL_0
attr CUL_EM_4 room CUL_EM
define CUL_WS_5 CUL_WS 5
attr CUL_WS_5 room CUL_WS
define vccu CUL_HM F11135
attr vccu IODev myHmUART
attr vccu IOList myHmUART
attr vccu IOgrp vccu
attr vccu expert 2_raw
attr vccu model CCU-FHEM
attr vccu room System
attr vccu subType virtual
attr vccu webCmd virtual:update
define Aussen_TH_HUM CUL_HM 2F24D0
attr Aussen_TH_HUM IODev myHmUART
attr Aussen_TH_HUM IOgrp vccu
attr Aussen_TH_HUM autoReadReg 4_reqStatus
attr Aussen_TH_HUM expert 2_raw
attr Aussen_TH_HUM genericDeviceType thermometer
attr Aussen_TH_HUM model HM-WDS10-TH-O
attr Aussen_TH_HUM peerIDs 00000000,
attr Aussen_TH_HUM subType THSensor
define CUL_WS_2 CUL_WS 2
attr CUL_WS_2 room CUL_WS

[vbs]

Ok, danke, werde ich mal genau so nachbauen mit einem frischen Maple. Hattest du weitere Hardware außer dem HM-MOD-UART am Maple?

[Telekatz]

Am MapleCUL waren zwei RF Module und der HM-MOD-UART angeschlossen.

[RaspiLED]

Hi,
Ich tippe auf die vmware! Wie hast du die usb bereitgestellt? Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[vbs]

Habe einfach den MapleCUL an den Host gesteckt und dann in VMWare an den Guest connectet. Also der Guest hat direkt das USB-Device bekommen und dafür entsprechend die Treiber geladen.. Auf die gleiche Art hab ich aber auch den USB-Serial-Wandler angeschlossen, mit dem dann die Latenzen aber gut waren:
https://forum.fhem.de/index.php/topic,60458.msg883623.html#msg883623

[vbs]

Ich hab nochmal einen anderen Maple genommen und da den HM-MOD-UART angeschlossen und das dann mit Telekatz' FHEM-Config laufen lassen, aber leider gleiches Verhalten 

Hab aber was interessantes rausgefunden:
ich hab mal ein simples C++-Testprogramm (https://gist.github.com/verybadsoldier/049597bd2251a330574fef1a4a6da2dd) geschrieben, welches nur die Credits-Anfrage an den HM-UART schickt, auf die Antwort wartet und die vergangene Zeit stoppt (das gleiche was die roundtrip-Time in FHEM macht). Das Ganze mache ich in einer Schleife mit einem random-Sleep zwischen den einzelnen Durchläufen.

Das sieht dann so aus (also immer die Angabe der Pause und die daraufhin gemessene RTT, die ich hier "RRT" nenne ):

Code Auswählen Erweitern

Slept: 3.064 s RRT: 288
Slept: 3.27 s RRT: 80
Slept: 2.006 s RRT: 13
Slept: 3.003 s RRT: 348
Slept: 1.819 s RRT: 7
Slept: 3.465 s RRT: 230
Slept: 2.318 s RRT: 33
Slept: 1.535 s RRT: 7
Slept: 1.714 s RRT: 7
Slept: 3.285 s RRT: 67
Slept: 2.909 s RRT: 442
Slept: 2.477 s RRT: 215
Slept: 2.879 s RRT: 474
Slept: 2.822 s RRT: 530
Slept: 2.826 s RRT: 526
Slept: 2.156 s RRT: 23
Slept: 1.963 s RRT: 6
Slept: 3.241 s RRT: 111
Slept: 2.151 s RRT: 29
Slept: 2.937 s RRT: 414
Slept: 3.382 s RRT: 313
Slept: 2.206 s RRT: 143
Slept: 3.013 s RRT: 339
Slept: 2.837 s RRT: 513
Slept: 2.785 s RRT: 566
Slept: 2.361 s RRT: 332
Slept: 2.919 s RRT: 433
Slept: 2.249 s RRT: 102

Man sieht, dass die roundtripetime super ist, solange die vorherige Abfrage weniger als 2 Sekunden zurück liegt. Sobald die Pause größer wird, entsteht bei der nächsten Abfrage eine Latenz.

Ich hab mal das FHEM-Modul so verändert, dass die RTT-Messungen nicht nur alle 15 Sek. passieren, sondern sekündlich. Und tatsächlich sind dann auch die RTT-Werte in FHEM super.

Also ich vermute sehr stark, dass sich da irgendwas nach 2 Sek. schlafen legt. Energiesparmodus oder sowas. Ich war mir sehr sicher, dass es dieser Kernel-Mechanismus ist, der USB-Geräte schlafen legen kann wenn sie idle sind:
https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html

Der Default-Wert ist tatsächlich 2000 ms. Würde also genau passen.

Code Auswählen Erweitern

power/autosuspend_delay_ms

This file contains an integer value, which is the number of milliseconds the device should remain idle before the kernel will autosuspend it (the idle-delay time). The default is 2000. 0 means to autosuspend as soon as the device becomes idle, and negative values mean never to autosuspend. You can write a number to the file to change the autosuspend idle-delay time.

Passt auch dazu, dass ich mit einem "normalen" USB-Serial-Converter den Effekt nicht habe. Der benutzt eben einen anderen Linux-Treiber (nicht den cdc_acm). Könnte in dem Treiber anders implementiert sein. Das ist offenbar der Patch der autosuspend in den cdc_acm bringt:
https://www.systutorials.com/linux-kernels/151457/usb-autosuspend-for-cdc-acm-linux-2-6-25/

Ich finde, das passt alles. Aber blöderweise: Ich hab das Autosuspend jetzt schon auf drei Arten deaktiviert. Aber leider bleibt das Verhalten unverändert Also entweder ist es doch etwas anderes oder das Abschalten klappt nicht.

Telekatz für ein Linux benutzt und was für einen Kernel? Ich hab ein Ubuntu 18.04 mit Kernel 4.15.0-43.

[Telekatz]

Es ist ein Raspbian Wheezy mit Kernel 4.1.19-v7+

[frank]

@vbs
hast du anstatt ab zu schalten, mal versucht die 2000ms zu erhöhen? also zb auf 20000ms.

[vbs]

Nee bisher noch nicht, aber werde ich gerne mal machen. Gefühlt habe ich jedoch nicht viel Hoffnung, muss ich sagen.

Für mich wäre der nächste Schritt, das Ganze mal auf einem älteren Kernel (aber weiterhin in einer VM) zu testen. Telekatz' Kernel ist auch etwas älter. Würde gerne wissen, ob es am Kernel oder VM liegt. Ich tippe ja (und hoffe) auf Kernel. Eigentlich passen für mich auch alle Indizien zusammen. Nur mit dem kleinen Haken, dass die Gegenmaßnahmen einfach nicht greifen

[vbs]

Es ist zum Weinen... bekomme es einfach nicht raus... hab das "autosuspend_delay" auf 50000 gedreht, aber auch keine Änderung. Eigentlich bin ich der Meinung, dass der ganze Mechanismus sowieso für das Device defaultmäßig ausgeschaltet ist laut sysfs.
Hab auch in Windows 10 ein "USB selective suspend" (https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices) gefunden. Ausschalten brachte aber auch nichts.

Nochmal kurz, was ich bisher getestet habe. Vielleicht fällt jemandem was dazu ein:

• Windows 10 -> VMWare 15 -> Ubuntu 18.04 MapleCUL: Fehler
• Windows 10 -> VMWare 15 -> Ubuntu 12.04 MapleCUL: Fehler
• Windows 10 -> VMWare 15 -> Ubuntu 18.04 - FTDI-USB-Serial (anstatt MapleCUL): OK
• Ubuntu 12.04 -> VMWare 9 -> Ubuntu 18.04 MapleCUL: OK
• Ubuntu 12.04 MapleCUL: OK

Sieht halt aus, als läge es an Windows 10 oder an der Kombination Windows10+VMWare. Dagegen spricht, dass es aber unter der Konstellation mit FTDI-Adapter anstatt MapleCUL trotzdem funktioniert.
Außerdem kann ich mich nur schwer damit abfinden, dass es nicht dieses Linux-autosuspend sein soll, weil es ja eben genau auf diese 2 Sekunden passt. Es scheint ja kein Bug vorzuliegen, sondern offenbar ein Mechanismus zu sein, der gezielt nach 2 Sekunden irgendwie eingreift und für so eine Delay sorgt.

[juergs]

Hallo vbs,
vielleicht das hier?
https://askubuntu.com/questions/185274/how-can-i-disable-usb-autosuspend-for-a-specific-device