HMCCU: Version 4.3 verfügbar

Begonnen von zap, 11 September 2018, 10:40:03

Vorheriges Thema - Nächstes Thema

amenomade

Der rpcserver kann nicht ohne rpcinterfaces starten.
Aber ich vermute, wenn Du versuchst, attr myHMCC3 rpcinterfaces auf bidcos zu setzen, dass er dir auch Illegal RPC interface sagt? Genauso bei  attr rpcports?

Ich hatte vor ein paar Tage das gleiche Problem, und ich habe nicht ganz verstanden, was das Problem war. Das einzige, was geholfen hat war: die HMCCU in Fhem zu löschen, und neu anzulegen. Problem: wenn man das macht, wird die HMCCU ganz am Ende der config neu kreiert, was dazu führt, dass Fhem gar nicht mehr (neu)starten kann, weil er wegen fehleden Routinen (vom HMCCU Modul) bei der Definition von den devs und chn meckert... Am Ende habe ich nach der Neuanlage der HMCCU manuell durch Perl Kommandos die { $defs{myCCU}{NR} } angepasst !  Es gibt aber sicher eine elegantere Lösung, und die möchte ich gerne kennen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

frank

bei meiner debmatic habe ich gerade folgende theorie:

- kein internet vorhanden
- nach reboot kommt die ccu nicht hoch:
unter "systemctl status debmatic" ist stundenlang "starting debematic...." zu sehen.
ausserdem waren 2 tasks zu sehen: 1. irgendwas mit init und 2. ein wget mit irgendwas mit google.

- solange die ccu nicht gestartet ist, erfolgt bei fhem start das löschen des attr rpcinterfaces.
- ohne ccu auch kein neues setzen möglich (illegal)

- zufällig hatte der rpi dann einige zeit internet
- seit dem ist wieder alles ok.

ich vermute meine debmatic braucht hin und wieder internet. wenn das dann fehlt, bleibt sie beim start hängen.
zumindest gibt es dann ein timeout, der frühestens nach 1-2 tagen greift.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

amenomade

Zitat von: frank am 10 Juli 2020, 22:06:26
bei meiner debmatic habe ich gerade folgende theorie:

- kein internet vorhanden
- nach reboot kommt die ccu nicht hoch:
unter "systemctl status debmatic" ist stundenlang "starting debematic...." zu sehen.
ausserdem waren 2 tasks zu sehen: 1. irgendwas mit init und 2. ein wget mit irgendwas mit google.

- solange die ccu nicht gestartet ist, erfolgt bei fhem start das löschen des attr rpcinterfaces.
- ohne ccu auch kein neues setzen möglich (illegal)

Ähnliches Gefühl, obwohl ich dieses "Stunden lang" Problem anscheinend nicht habe. Ich werde mal beobachten.
Das Problem bei mir ist: selbst wenn debmatic endlich wieder hoch war (nach 3-4 Minuten), hat sich die HMCCU in Fhem nie von alleine erholt, und selbst das manuelle Setzen von rpcinterfaces war immer noch nicht möglich. Nur mit Löschen und wieder Anlegen in Fhem hat es wieder funktioniert. Irgendwie sperrt sich die HMCCU in Fhem selbst.

Ich habe jetzt die Abhängigkeit zwischen debmatic und fhem in meinem systemd wieder eingebaut (hatte die bei der neue Installation von Buster bei Seite gelassen). Mit dem Risiko bei einem Stromausfall, dass fhem nicht mehr startet, so lange debmatic nicht fertig ist. Aber gut, mal sehen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

amenomade

Zitat von: frank am 10 Juli 2020, 22:06:26

ausserdem waren 2 tasks zu sehen: 1. irgendwas mit init und 2. ein wget mit irgendwas mit google.


Hab ein bisschen tiefer nachgeschaut: debmatic testet, ob er Internet hat, wie folgt:
  wget -q --spider http://google.com/
  if [[ $? -eq 0 ]]; then
    touch /var/status/hasInternet

/usr/share/debmatic/bin/ifup.sh

wget hat ein default read-timeout von 900 Sekunden...

Ich verstehe aber nicht, warum debmatic (und anscheinend ist es bei der "Hardware" CCU das gleiche) unbedingt Internet braucht.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

zap

@bmwfan: das Problem ist, dass in Deinem Fall bereits bei der Definition des IO Device keinerlei Geräte und vor allem keine Interfaces von der CCU gelesen werden. Steht alles auf 0. FHEM kann also nicht auf die CCU zugreifen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

frank

@amenomade

genau das hat systemctl angezeigt.

leider war bei mir definitiv nicht nach 15min ende.  :)
ich habe das letztens intensiv über stunden verfolgt. nachdem der timer beim systemctl status über 4 std gezeigt hat, bin ich schlafen gegangen. am nächsten tag lief debmatic dann.

da ich sie, nachdem sie wieder lief, auch ohne internet über systemctl start/stop problemlos mehrmals starten konnte, denke ich, dass dieser internet test nur hin und wieder läuft.

es gibt sogar bei fhem module, die mit gesetztem attr disable, wenigstens bei fhem restart versuchen ins internet zu kommen.

diese unsitte scheint also weit verbreitet zu sein.

auch bei der fritzbox, die als router noch am rpi hängt, habe ich noch nichts gefunden, wie ich manuell die zeit setzen kann. die ist nach reboot nämlich in 1970.

eventuell ist das bei mir die ursache für den extremen timeout gewesen. denn nach dem zwischenzeitlichen internet anschluss hatte sie wieder aktuelle zeit.
die zeit am rpi hatte ich vorher schon manuell gesetzt gehabt.


aber selbst 15min timeout wären inakzeptabel. eigentlich müsste man auch den internet spyder ganz auschalten können.

das sollte man mal @deimos berichten.


@zap

das problem ist aber auch, dass das attr rpcinterfaces gelöscht wird.

wenn das löschen beim start nicht bemerkt wird und man macht anschliessend ein fhem save, ist das attribut für immer weg, oder?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

amenomade

Jetzt habe ich den Skript geändert: statt google zu wgetten und pingen, nutze ich meine Box.  Das wird natürlich nicht eine Aktualisierung von debmatic überleben (mache ich auch nicht so oft), und das könnte Nebeneffekte haben, falls die Konnektivität zu Box vorhanden ist, aber diese tatsächlich kein Internet hat (ntp & co). Sollte aber beim Start nicht mehr so lange dauern.

Ich habe dann tatsächlich die gleiche Frage @deimos (bzw. @eq3, da deimos es nur übernommen hat) wie Du: warum braucht man beim Start Internet. Ok spätestens bei der Suche nach neue Firmware o.ä. wird Internet gebraucht. Aber beim Start? Ist das nur eine "Zeit" Geschichte?

Ich habe irgendwo bei homematic gelesen, dass es eine Möglichkeit gäbe, dieses internetCheck zu deaktivieren. Weiss aber nicht mir der jetzige Version von debmatic, wo das ist.

Und gleiche Anmerkung @zap: Fhem, insb. das HMCCU Device, sollte in der Lage sein, sich selbst zu erholen, falls debmatic/piVccu/CCU beim Start nicht verfügbar ist, sondern erst später. Im Moment scheint es zu ungewünschte Situation zu führen, wo die Konfiguration dann möglicherweise beschädigt wird.



Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

bmwfan

@amenomade: Stimmt. Beim setzen des attr rpcinterfaces kam der genannte Fehler, bevor ich unten beschriebenen Versuch durchführte

Inzwischen geht es wieder, aber ich bin mir nicht sicher welcher meiner laienhaften Versuche erfolgreich war.
Ich hatte in einem Forum diesen Befehl gefunden und eingegeben:
sudo dpkg-reconfigure pivccu-modules-dkms
Danach neustart des Raspi und in FHEM waren dann die rpcinterfaces weg (denke das kam von der Aktion, sicher bin ich mir aber nicht). Diese neu gesetzt und es lief wieder.

Aber ob das jetzt tatsächlich das Problem behoben hat oder ob es ein Timing-Problem beim Hochfahren von FHEM ist, kann ich nicht sagen.

Wie ist denn das korrekte Vorgehen bei einem FHEM-Update, wenn der rpcserver läuft?

Muss ich zuerst explizit set rpcserver off eingeben bevor ich das Update in FHEM mache oder fährt FHEM beim Neustart selber und auch ordentlich den rpcserver herunter?

Grüße Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

zap

Ich würde vor dem Update ein set rpcserver off ausführen. Normalerweise werden zwar die RPC Server korrekt gestoppt, kann aber auch sein, dass sie mal hängen bleiben. Sind ja separate Prozesse. Wenn die auf IO warten, klappt es,ggf nicht mit dem Stoppen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

bmwfan

Ich habe mal in einem Beitrag gelesen, dass man FHEM auch per Script herunterfahren kann, aber kein Beispiel dazu gefunden. Damit könnte man doch sicher den rpcserver stoppen, 15 sec. warten und dann erst FHEM herunterfahren. Dann wäre man auf der sicheren Seite mit dem Timing beim Beenden der rpc Prozeße.

Weis jemand, wie solch ein Script zu schreiben ist oder hat sogar ein Beispiel?

Grüße Jürgen
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

dancatt

Hallo zusammen,

seit 2 Tage habe ich folgende Meldung im Log:

HMCCURPCPROC: [...] Sending data to FHEM failed 100 times. select found no reader


Meine Devices HMCCURPCPROC "CCU RPC HmIP-RF" und "CCU RPC BidCos-RF" haben den Status "inactive/OK".
Meine HMCCU ebenfalls.

Ein "set HMCCU rpcserver on" bringt auch keinen Erfolg.

im Log steht folgendes:

2020.08.21 11:07:19.259 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 24332] Sending data to FHEM failed 100 times. select found no reader
2020.08.21 11:08:01.692 2: HMCCU: [CCU3 : 17011] Get RPC device for interface BidCos-RF
2020.08.21 11:08:01.694 2: HMCCU: [CCU3 : 17011] Get RPC device for interface HmIP-RF
2020.08.21 11:08:01.728 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] RPC server process started for interface BidCos-RF with PID=17828
2020.08.21 11:08:01.773 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17828] Initializing RPC server CB2001178100178049 for interface BidCos-RF
2020.08.21 11:08:01.784 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17828] Can't create RPC callback server CB2001178100178049 on port 7411. Port in use?
2020.08.21 11:08:01.785 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17828] Can't initialize RPC server CB2001178100178049 for interface BidCos-RF
2020.08.21 11:08:01.923 4: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Set state to busy
2020.08.21 11:08:01.924 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] RPC server starting
2020.08.21 11:08:01.925 4: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Set rpcstate to starting
2020.08.21 11:08:02.104 2: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] RPC server process started for interface HmIP-RF with PID=17829
2020.08.21 11:08:02.205 2: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17829] Initializing RPC server CB2010178100178049 for interface HmIP-RF
2020.08.21 11:08:02.239 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17829] Can't create RPC callback server CB2010178100178049 on port 7420. Port in use?
2020.08.21 11:08:02.240 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17829] Can't initialize RPC server CB2010178100178049 for interface HmIP-RF
2020.08.21 11:08:02.487 4: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Set state to busy
2020.08.21 11:08:02.489 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] RPC server starting
2020.08.21 11:08:02.490 4: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Set rpcstate to starting
2020.08.21 11:08:26.740 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Checking if RPC server process is running
2020.08.21 11:08:26.741 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] RPC server process not running. Cleaning up
2020.08.21 11:08:26.742 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Housekeeping called. Cleaning up RPC environment
2020.08.21 11:08:26.804 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] RPC server process CB2001178100178049 not runnning
2020.08.21 11:08:26.805 4: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Set rpcstate to inactive
2020.08.21 11:08:26.807 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Stop I/O handling
2020.08.21 11:08:26.807 3: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Close child socket
2020.08.21 11:08:26.808 3: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Close parent socket
2020.08.21 11:08:26.808 4: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Reset RPC state
2020.08.21 11:08:26.860 4: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] Set state to OK
2020.08.21 11:08:26.912 2: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17011] RPC server stopped. Cancel delayed shutdown.
2020.08.21 11:08:27.116 2: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Checking if RPC server process is running
2020.08.21 11:08:27.117 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] RPC server process not running. Cleaning up
2020.08.21 11:08:27.118 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Housekeeping called. Cleaning up RPC environment
2020.08.21 11:08:27.180 1: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] RPC server process CB2010178100178049 not runnning
2020.08.21 11:08:27.181 4: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Set rpcstate to inactive
2020.08.21 11:08:27.182 2: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Stop I/O handling
2020.08.21 11:08:27.183 3: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Close child socket
2020.08.21 11:08:27.184 3: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Close parent socket
2020.08.21 11:08:27.184 4: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Reset RPC state
2020.08.21 11:08:27.237 4: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] Set state to OK
2020.08.21 11:08:27.288 2: HMCCURPCPROC: [d_rpc178049HmIP_RF : 17011] RPC server stopped. Cancel delayed shutdown.


Was kann ich hier tun?

Vielen Dank.

MfG
Daniel
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Wernieman

2020.08.21 11:08:01.784 1: HMCCURPCPROC: [d_rpc178049BidCos_RF : 17828] Can't create RPC callback server CB2001178100178049 on port 7411. Port in use?

1. Kannst Du einen neuen Thread aufmachen? Hat jetzt erstmal KEINEN Zusammenhang mit dem Therad-Start
2. Ist der Port auf Deinem FHEM-Rechner belegt?
netstat -lntp | grep 7411
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

dancatt

Zitat von: Wernieman am 21 August 2020, 11:34:58
2. Ist der Port auf Deinem FHEM-Rechner belegt?
netstat -lntp | grep 7411
Danke. Hätte ich selber sehen müssen. Danke.

Zitat von: Wernieman am 21 August 2020, 11:34:58
1. Kannst Du einen neuen Thread aufmachen? Hat jetzt erstmal KEINEN Zusammenhang mit dem Therad-Start
netstat -lntp | grep 7411
Sorry. Mache ich dann das nächste Mal.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

slor

Hallo zusammen,

hat schon jemand das RaspberryMatic 3.53.30.20200919 Update vom 19. eingespielt? Läuft? Probleme?
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Ralli

Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa