[Gelöst] Klassische Homematic Aktoren über WLAN steuern ?

Lumixnik · 18 Oktober 2021, 21:31:44

Hallo und guten Abend,

ich habe derzeit ausschließlich Homematic Heizkörper- Wand-Thermostate, Türkontakte, Aussenthermometer über ein HM-CFG-LAN (den kleinen Puck) an einer FHEM in Betrieb.

2 Fragen hab ich hier.
Was ist notwendig, damit ich Firmwareupdates einspielen kann ? Mit dem HM-CFG-LAN geht das nicht.
Ist es in irgendeiner Weise möglich die Aktoren auch über das hausinterne WLAN zu steuern, ohne gleich alle Endgeräte auf Homematic IP umstellen zu müssen ?

Danke für Eure Tipps.

viele Grüße Nick

onkel-tobi · 18 Oktober 2021, 23:14:06

Zitat von: Lumixnik am 18 Oktober 2021, 21:31:44
Was ist notwendig, damit ich Firmwareupdates einspielen kann ? Mit dem HM-CFG-LAN geht das nicht.

Zum Beispiel der HM-USB

Zitat
Ist es in irgendeiner Weise möglich die Aktoren auch über das hausinterne WLAN zu steuern, ohne gleich alle Endgeräte auf Homematic IP umstellen zu müssen ?

Nein, nur in Verbindung mit einem Gateway.

Gruß,
Tobi

MadMax-FHEM · 18 Oktober 2021, 23:28:51

Homematic IP ist auch KEIN WLAN!!

Funk zwischen den Geräten ist trotzdem/weiterhin auf 868MHz!

FW-Update geht auch mit dem HMOD-PCB (weil den HM-CFG-USB2 gibt es ja nicht mehr "normal" zu kaufen): https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
(geht auch per LAN/WLAN oder USB)
EDIT: wobei Anbindung des HMOD-PCB per WLAN wegen Latenz etc. nicht wirklich zu empfehlen ist...

Gruß, Joachim

Lumixnik · 19 Oktober 2021, 16:23:17

Hallo ihr danke für die Antworten und Hinweise!

Also könnte das der Ersatz für einen HM-CFG-LAN sein
https://de.elv.com/elv-komplettbausatz-funk-modulplatine-fuer-raspberry-pi-3-b-rpi-rf-mod-fuer-homematic-und-homematic-ip-152941

Wird auf meine pi3 gesteckt und ersetzt den lan Adapter.
Ist die Annahme korrekt ?

So ich habe auf der pi sowohl eine FHEM , als auch eine debmatic laufen.
Leider musste ich feststellen, dass die Geräte nur jeweils an eine Steuerungssoftware gepairt werden können.

Viele Grüße Nick

frank · 19 Oktober 2021, 16:56:20

falsch.
madmax-fhem hat doch extra verlinkt.

Lumixnik · 25 Oktober 2021, 14:36:59

Hallo MadMax,

danke für den Link.

Modul ist gekauft gelötet und eingebaut.
Leider kann es sich nicht connecten.

Ich habe eine Pi3b mit Debian Buster und darauf ein HM-MOD-RPI-PCB.
Steuerung über FHEM. Auch eine debmatic läuft auf der gleichen PI.

Ich habe nun heute entsprechend der Anleitung im WIKI Betriebssystem (config-txt, cmdline.txt, etc) angepasst.
Bei der PI3b ist das ttyAMA0 ja die Bluetooth-Schnittstelle, weshalb auch BT deaktiviert werden muss.
Allerdings gibt bei mir unter /dev kein Device ttyAMA0, es ist nicht vorhanden.
Ich habe gelesen, dass man stattdessen für die UART das Device /dev/ttyS0 verwenden muss.

Leider geht wedet das device ttyAMA0 , noch ttyS0 bei der DEF im HM-UART Modul des FHEM.

Das Modem kann sich einfach nicht connecten.

Fehler im Log sehen so aus (sowohl für ttyAMA0, als auch ttyS0):

2021.10.25 14:18:29 3: myHmUART device closed
2021.10.25 14:18:29 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 14:18:29 1: /dev/ttyS0 reappeared (myHmUART)
2021.10.25 14:18:33 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2021.10.25 14:18:36 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2021.10.25 14:18:39 1: HMUARTLGW myHmUART did not respond for the 3. time, resendin

Ein Firmwareupdate über die Console hab ich durchgeführt, das hat auch funktioniert.
Hier die Readings:

D-HMIdAssigned A23456 2021-10-25 13:22:28
D-HMIdOriginal 71CA49 2021-10-25 13:22:28
D-firmware 1.4.1 2021-10-25 13:22:29
D-serialNr <vorhanden> 2021-10-25 13:22:29
D-type HM-MOD-UART 2021-10-25 14:02:19
cond init 2021-10-25 14:28:11
load 0 2021-10-25 13:22:29
loadLvl suspended 2021-10-25 14:02:19
state opened 2021-10-25 14:13:42

Welchen Denkfehler mache ich gerade ?

viele Danke für eine konstruktive Antwort.

MadMax-FHEM · 25 Oktober 2021, 14:48:00

Post doch mal ein list.

Die Readings, also das opened sieht doch gut aus...
...wenn es dabei bleibt.

Wenn es (wie im Log) immer wechselt, dann greift wohl (doch) noch was auf die Schnittstelle zu.

Wie sieht denn cmdline.txt aus?

Wie hast du BT deaktiviert?
Neu gebootet danach?

FW-Update?
Tatsächlich durchgeführt und geklappt? -> dann muss es ja gehen... Bzw.: wie hast du den Update gemacht?

Gruß, Joachim

Lumixnik · 25 Oktober 2021, 16:11:51

Hi Joachim,

während ich die Antwort schreibe hat sich das Reading für die Firmware von 1.4.1 auf unsupportet geändert (Frag mich nicht warum).
Danach hab ich das Firmwareupdate erneut durchgeführt (mittels FHEM nicht von Konsole).
Jetzt ist die condition ok

Aber trotzdem hier die Antworten auf Deine Fragen.

1. BT deaktivieren:
Da gibt es leider mehrere Artikel. Am logischen klingt:
Eintrag in die config.txt
dtoverlay=pi3-disable-bt
Dort stehen dann auch
enable_uart=1
und
systemctl disable hciuart
Dieser Service ist doch aber ein allgemeiner UART Service (irritiert mich etwas, steht aber fast in jedem Artikel)
gebootet mehrfach

2. list zeigt nicht viel zum GW:

HMUARTLGW:
myHmUART (disconnected) --> jetzt (open)

3. FW-Update analog zu dieser Anleitung
sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

Ergebnis war ok

Firmwarestand ist jetzt 1.4.1
Habe jetzt sicherheitshalber nochmals das Binary runtergeladen und dieses Mal über die FHEM das Firmwareupdate durchgeführt:
mittels: set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3
Auch das hat funktioniert.

Status ist jetzt im L0g wie folgt:
2021.10.25 16:00:26 1: 192.168.178.47:1000 disconnected, waiting to reappear (HM_LAN_GW)
2021.10.25 16:00:26 1: HMLAN_Parse: HM_LAN_GW new condition disconnected
2021.10.25 16:00:29 1: HMLAN_Parse: HM_LAN_GW new condition init
2021.10.25 16:00:29 1: 192.168.178.47:1000 reappeared (HM_LAN_GW)
2021.10.25 16:00:29 1: HMLAN_Parse: HM_LAN_GW new condition ok
2021.10.25 16:00:58 1: HMLAN_Parse: HM_LAN_GW new condition disconnected
2021.10.25 16:00:58 1: 192.168.178.47:1000 disconnected, waiting to reappear (HM_LAN_GW)
2021.10.25 16:00:58 1: HMLAN_Parse: HM_LAN_GW new condition disconnected
2021.10.25 16:01:08 3: myHmUART device closed
2021.10.25 16:01:08 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 16:01:08 1: /dev/ttyAMA0 reappeared (myHmUART)
2021.10.25 16:01:09 1: HMUARTLGW myHmUART starting firmware upgrade
2021.10.25 16:01:34 1: HMUARTLGW myHmUART firmware update successfull
2021.10.25 16:02:07 1: HMLAN_Parse: HM_LAN_GW new condition init
2021.10.25 16:02:07 1: 192.168.178.47:1000 reappeared (HM_LAN_GW)
2021.10.25 16:02:07 3: myHmUART: Unknown code A09998112AAAAA0000000::-54:myHmUART, help me!
2021.10.25 16:02:07 1: HMLAN_Parse: HM_LAN_GW new condition ok

Danke für die Zeit.

viele Grüße Dirk

MadMax-FHEM · 25 Oktober 2021, 16:14:59

Na dann viel Spaß!

Für die Zukunft: Posts von Ausgaben etc. bitte in code-Tags, das '#' im "Menü"...

Gruß, Joachim

frank · 25 Oktober 2021, 16:38:42

Zitatwährend ich die Antwort schreibe hat sich das Reading für die Firmware von 1.4.1 auf unsupportet geändert (Frag mich nicht warum).

nach einem reboot?
ist das neu gekaufte hmuart modul das, welches am gpio der maschine sitzt, wo fhem und debmatic laufen?
https://forum.fhem.de/index.php/topic,97295.msg987827.html#msg987827
der tip mit "apt remove" aus dem folgenden post hat bei mir funktioniert.

Lumixnik · 25 Oktober 2021, 19:13:04

Hallo Joachim,

es hat nicht lange gehalten.

Nachdem ich erfolgreich einen Heizkörperthermostat (HM-CC-RT-DN) an den HM-MOD-RPI-PCB pairen konnte, wollte ich auf diesem ein Firmwareupate auf 1.5 durchführen.
Das ging schief ( Grund hab ichhoch nicht herausgefunden) , der Thermostat steht auf CrC.
Seit dem kommt im Log permanent das Folgende:

Code Auswählen

021.10.25 19:04:14 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 19:04:14 1: /dev/ttyAMA0 reappeared (myHmUART)
2021.10.25 19:04:18 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2021.10.25 19:04:21 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2021.10.25 19:04:24 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2021.10.25 19:04:27 1: HMUARTLGW myHmUART did not respond after all, reopening
2021.10.25 19:04:27 3: myHmUART device closed
2021.10.25 19:04:27 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 19:04:27 1: /dev/ttyAMA0 reappeared (myHmUART)
2021.10.25 19:04:31 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2021.10.25 19:04:34 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2021.10.25 19:04:37 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2021.10.25 19:04:42 1: HMUARTLGW myHmUART did not respond after all, reopening
2021.10.25 19:04:42 3: myHmUART device closed
2021.10.25 19:04:42 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 19:04:42 1: /dev/ttyAMA0 reappeared (myHmUART)
2021.10.25 19:04:42 3: myHmUART device closed
2021.10.25 19:04:42 3: Setting myHmUART serial parameters to 115200,8,N,1
2021.10.25 19:04:42 1: /dev/ttyAMA0 reappeared (myHmUART)
2021.10.25 19:04:46 1: HMUARTLGW myHmUART did not respond for the 1. time, resending

Irgendwie komisch.
Besteht die Möglichkeit, dass sich debmatic und fhem irgendwie beeinflussen ?

Im syslog steht außerdem seit dieser Zeit:

Code Auswählen

Oct 25 19:10:05 raspberrypi rfd: MEQ0313914: Could not connect to host
Oct 25 19:10:20 raspberrypi rfd: MEQ0313914: Could not connect to host
Oct 25 19:10:35 raspberrypi rfd: MEQ0313914: Could not connect to host
Oct 25 19:10:50 raspberrypi rfd: MEQ0313914: Could not connect to host
Oct 25 19:11:05 raspberrypi rfd: MEQ0313914: Could not connect to host

Alles etwas schräg. Vor Allem der rfd ist komisch, ich hab ja nichts neues installiert.

Noch ne Idee ?

MadMax-FHEM · 25 Oktober 2021, 20:31:43

Naja das Log sieht (immer noch /wieder) so aus, als ob irgendwas den HM-UART schnappt.

Du hast irgendwas CCU auf demselben PI laufen?
Oder hab ich da was falsch im Kopf?

Gepaired? Sicher?
Also nicht nur "angelegt" sondern tatsächlich gepaired, also R-PairCentral / PairedTo steht deine (vergebene) HMID drin?
OHNE set_ ?
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen

Hast du eine vccu?
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Hast du hminfo definiert?
https://wiki.fhem.de/wiki/HomeMatic_HMInfo

Da du ja erst mit CUL_HM angefangen hast: mal einlesen bevor du zu viel rumtust...

EDIT: wie aktuell ist dein fhem?

Aber zuerst mal den HM-UART sauber zum Laufen bringen!

Gruß, Joachim

Lumixnik · 25 Oktober 2021, 20:53:09

Ergänzung:

die myHMUART hängt bisher an der

Code Auswählen

DEF /dev/ttyAMA0
Das in Kombination it dem Devicetree-Overlay der Debmatic-Installation scheint nicht zusammen zu spielen.
Alles reboot hilft da nix.
Testweise:
1. debmatic komplett entfernt, dann läuft auch der lighttpd wieder korrekt mit PT-Hole
2. my HMUART lief immenoch nicht.
3. DEF

Code Auswählen

/dev/ttyAMA0 auf

Code Auswählen

/dev/ttyS0 umgestellt. Dann shutdown restart
Dann zeit er wieder an

Code Auswählen

Firmware not supported
4. Wieder zurückstellen auf

Code Auswählen

/dev/ttyAMA0
5, Firmware erneut aufspielen

Code Auswählen

set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3

myHMUART läuft zumindest mit FHEM wieder.

Jetzt probiere ich mal das was Joachim mittlerweile geschrieben hat.

MadMax-FHEM · 25 Oktober 2021, 21:07:19

Ich denke deMatic und CUL_HM auf demselben PI, da muss bestimmt was getan werden (in debMatic), dass die sich das Modul nicht "schnappt"...
Ich hab schon gesucht aber noch nichts gefunden... $:-\$

Zitat
Eintrag in die config.txt
dtoverlay=pi3-disable-bt

Ist aber "outdated" (funktioniert aber wohl noch).
Neu (Buster/aktuelles Raspbi-OS) ist: dtoverlay=disable-bt

Was mir noch fehlt: bearbeiten der cmdline.txt!
Drum wollte ich die ja mal sehen...

Gruß, Joachim

Lumixnik · 25 Oktober 2021, 21:17:31

ZitatGepaird? Sicher?
Also nicht nur "angelegt" sondern tatsächlich gepaired, also R-PairCentral / PairedTo steht deine (vergebene) HMID drin?

Ja mittels hmPairforSec und Druck des mittleren Knopfs am Thermostat.
Da der Thermostat vorher am HM-CFG-LAN gepaart war, musste ich das Device löschen. Bei Pairen wurde es angelegt.
So hab ich das schon immer gemacht (sonst kommt F4).
Im Gegennsatz dazu hab ich bei einigen Thermostaten einzelne Channels gepeert an den Wandthermostat, zwecks gemeinsamer Steuerung.

ZitatHast du hminfo definiert?

ja, sieht aber komisch aus irgendwie

Code Auswählen


DeviceOverview hm ??? update protoEvents short rssi peerXref configCheck models

ZitatDu hast irgendwas CCU auf demselben PI laufen?

Ja debmatic mit pivCCU

ZitatWas mir noch fehlt: bearbeiten der cmdline.txt!

Code Auswählen

console=tty1 root=PARTUUID=5e3da3da-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

ZitatHast du eine vccu?

Bei der Installation von debmatic wird/kann eine pivCCU mit installiert werden. Das hab ich gemacht. Kann natürlich auch genau mein Problem auslösen.

Ich muss morgen mal versuchen den gebrickten Thermostat zu heilen.