- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Fehlerberichte / Aw: homematic empfang wird bei...
Letzter Beitrag von frank - 16 April 2024, 15:47:38moin,
mein cul funktioniert endlich wieder ohne probleme.
das problem waren letztendlich daten im eeprom, die diesen "trouble-modus" aktiviert haben.
ein einfaches "set cul raw e" (eeprom reset) hätte das problem beseitigt.
1. die initialisierungsprobleme lassen sich reproduzieren, indem man im rfmode=HomeMatic zusätzlich die RF_ROUTER funktionen für einen remote cul eingeschaltet hat (zb "set cul raw ui0201").
beim einschalten verstellt sich allerdings zunächst die empfangskonfiguration auf:
eigentlich müsste man den RF_ROUTER verriegeln, wenn im attr rfmode=HomeMatic gesetzt ist. bekommt man einen gebrauchten cul, kann es einen auch eiskalt erwischen.
2. die prozedur der eeprom initialisierung (ein "eeprom reset" wird nur ausgeführt, wenn sich die versions nummer der fw ändert) hat vermutlich die "bösen" daten geliefert.
ich hatte wie beschrieben, zunächst von 1.58 auf 1.67 updated. dabei wurde der eeprom wahrscheinlich neu initialisiert.
einen tag später habe ich dann in einer nacht-und-nebel-aktion versucht, die tsculfw zum laufen zu bringen. da 00_TSCUL.pm aber mittlerweile diverse abhängigkeiten zu weiteren eigenen modul-dateien hat, die ich noch nicht installiert hatte, hat fhem natürlich ständig 00_TSCUL nicht geladen. zu später stunde habe ich die aktion abgebrochen und bin zurück zur "normalen" culfw v1.67.
bei diesem hin und her müssen die eeprom daten entstanden sein, denn in meinen alten logs habe ich die genannte konfiguration des funkchips gefunden.
vielleicht sollte man mal einen hinweis platzieren (culfw.de), dass es sinn macht, nach jedem flashen ein eeprom reset (raw e) auszuführen?
meine selbst kompilierten fw haben ja auch kein eeprom reset gemacht, da die fw version gleich geblieben ist.
erst das flashen der cul_v3.hex (v1.68) von sourceforge hat zufällig den eeprom neu initialisiert und das problem behoben.
mein cul funktioniert endlich wieder ohne probleme.
das problem waren letztendlich daten im eeprom, die diesen "trouble-modus" aktiviert haben.
ein einfaches "set cul raw e" (eeprom reset) hätte das problem beseitigt.
1. die initialisierungsprobleme lassen sich reproduzieren, indem man im rfmode=HomeMatic zusätzlich die RF_ROUTER funktionen für einen remote cul eingeschaltet hat (zb "set cul raw ui0201").
beim einschalten verstellt sich allerdings zunächst die empfangskonfiguration auf:
Code Auswählen
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:12dBalso manuell wieder auf die default homematic konfiguration umgestellen:Code Auswählen
ccconf: freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dBda im rfmode=HomeMatic manuelle einstellungen verhindert werden, muss man während der konfiguration den SlofRF mode im attribut setzen!!!eigentlich müsste man den RF_ROUTER verriegeln, wenn im attr rfmode=HomeMatic gesetzt ist. bekommt man einen gebrauchten cul, kann es einen auch eiskalt erwischen.
2. die prozedur der eeprom initialisierung (ein "eeprom reset" wird nur ausgeführt, wenn sich die versions nummer der fw ändert) hat vermutlich die "bösen" daten geliefert.
ich hatte wie beschrieben, zunächst von 1.58 auf 1.67 updated. dabei wurde der eeprom wahrscheinlich neu initialisiert.
einen tag später habe ich dann in einer nacht-und-nebel-aktion versucht, die tsculfw zum laufen zu bringen. da 00_TSCUL.pm aber mittlerweile diverse abhängigkeiten zu weiteren eigenen modul-dateien hat, die ich noch nicht installiert hatte, hat fhem natürlich ständig 00_TSCUL nicht geladen. zu später stunde habe ich die aktion abgebrochen und bin zurück zur "normalen" culfw v1.67.
bei diesem hin und her müssen die eeprom daten entstanden sein, denn in meinen alten logs habe ich die genannte konfiguration des funkchips gefunden.
Code Auswählen
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:12dBvielleicht sollte man mal einen hinweis platzieren (culfw.de), dass es sinn macht, nach jedem flashen ein eeprom reset (raw e) auszuführen?
meine selbst kompilierten fw haben ja auch kein eeprom reset gemacht, da die fw version gleich geblieben ist.
erst das flashen der cul_v3.hex (v1.68) von sourceforge hat zufällig den eeprom neu initialisiert und das problem behoben.
#2
Einplatinencomputer / Aw: Umzug auf Raspberry Pi OS ...
Letzter Beitrag von RalfRog - 16 April 2024, 15:17:34Hi
Vielleicht hilft das https://forum.fhem.de/index.php?topic=137916.msg1310836#msg1310836 und die Beiträge vorher. Bei den serial-dev's hat sich unter bookworm die Gruppe geändert => plugdev statt dialout
Schau dir die Dateien an, auf die die Links zeigen.
-> ../../ttyACM0
-> ../../ttyUSB0
Gruß Ralf
Vielleicht hilft das https://forum.fhem.de/index.php?topic=137916.msg1310836#msg1310836 und die Beiträge vorher. Bei den serial-dev's hat sich unter bookworm die Gruppe geändert => plugdev statt dialout
Schau dir die Dateien an, auf die die Links zeigen.
-> ../../ttyACM0
-> ../../ttyUSB0
Gruß Ralf
#3
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von michael.winkler - 16 April 2024, 15:05:51@All
ich bin noch da, nur halt nicht jeden Tag im Forum. Was geht den aktuell nicht?
ich bin noch da, nur halt nicht jeden Tag im Forum. Was geht den aktuell nicht?
#4
Unterstützende Dienste / Aw: Update SYSMON: Unterstützu...
Letzter Beitrag von Aurel_B - 16 April 2024, 14:36:41Super, merci für deine Nachricht. Unter was für einem OS läuft dein FHEM?
#5
Einplatinencomputer / Aw: Umzug auf Raspberry Pi OS ...
Letzter Beitrag von Der-Eine - 16 April 2024, 14:08:35Hi, ich habe das selbe Problem und komme nicht ganz mit.
So sieht die Ausgabe von ls -lha /dev/serial/by-id aus:
So sieht die Ausgabe von ls -lha /dev/serial/by-id aus:
Code Auswählen
lrwxrwxrwx 1 root root 13 16. Apr 00:29 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2251864-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 16. Apr 00:29 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ../../ttyUSB0
#6
MQTT / Aw: MQTT2 für Worx Landroid Mä...
Letzter Beitrag von pillepalle12 - 16 April 2024, 14:04:22Zitat von: Allgaeuer am 11 Februar 2024, 10:27:25Hallo zusammen,
ich denke, ich habe das Problem identifiziert und eine Lösung gefunden.
Zum Testen hatte ich ja ein neues, ganz schlankes System (RPI2) aufgesetzt. Das hat sehr schnell gebootet und auch ganz schnell FHEM gestartet. Offensichtlich waren noch nicht alle Netzwerkdienste aktiv und deshalb der 3-Minuten reconnect. Als Abhilfe habe ich die fhem.service (unter /etc/systemd/system ) leicht modifiziert. Die beiden Einträge mit "network.target" auskommentiert und dafür die beiden Einträge mit "network-online.target" eingefügt. Jetzt sind die 3-Min-Reconnects weg.
Das erklärt auch, warum bei anderen der Fehler nicht auftritt.Code Auswählen[Unit]
Description=FHEM Home Automation
#Wants=network.target
#After=network.target
Requires=network-online.target
After=network-online.target
#Requires=postgresql.service
Viele Grüße,
Allgäuer
Hallo Allgäuer, da ich nach 2 Tagen Betrieb auch schon wieder aus meinem Worx Account ausgesperrt wurde, habe ich Deinen Vorschlag ausprobiert und dieser läuft nun schon seit Tagen Perfekt ohne Aussperren.
Vielen Dank!
#7
Zigbee / zigbee2tasmota Probleme mit He...
Letzter Beitrag von dieter114 - 16 April 2024, 13:51:21Hallo in die Runde,
ich habe mit eine Zigbee Bridge mit Tasmota geflasht und eingebunden.
Das Ganze war recht problemlos und läuft auch.
Der "billig" Thermostat aus Fernost war ebenfalls sofort sichtbar und wurde automatisch abgelegt.
Dies Teil ist aber offsichtlich wenig kompatibel mit dem Rest der Welt:
https://www.zigbee2mqtt.io/devices/TV01-ZB.html oder ein Nachbau davon.
Er sendet z.b. die Temperatur (sollwert) mit Faktor 10, also 210 für 21 Grad usw.
Ebenfalls sind die Empfangenen Label absolut nicht sofort lesbar:
EF00/0210 = eingestellte Solltemperatur, EF00/0218 = gemessene Temperatur usw
Dieser Eigenbau funktioniert eigentlich nur hätte ich gern z.b. die Temperatur mit 21 und nicht mit 210 eigegeben.
Das Attribut setList temperature:slider,50,5,300 cmnd/ZigBee2MQTT/6EF5/SENSOR/ZbSend {"device":"0x6EF5","Write":{"EF00/0210": $EVTPART1}} sendet auch richtig.
Nun müsste nur noch der Inhalt von $EVTPART1 *10 und alles wäre wieder normal.
Nur das bekomme ich so einfach nicht hin, habt ihr nen Tip dazu?
Grüße Wolfdieter
ich habe mit eine Zigbee Bridge mit Tasmota geflasht und eingebunden.
Das Ganze war recht problemlos und läuft auch.
Der "billig" Thermostat aus Fernost war ebenfalls sofort sichtbar und wurde automatisch abgelegt.
Dies Teil ist aber offsichtlich wenig kompatibel mit dem Rest der Welt:
https://www.zigbee2mqtt.io/devices/TV01-ZB.html oder ein Nachbau davon.
Er sendet z.b. die Temperatur (sollwert) mit Faktor 10, also 210 für 21 Grad usw.
Ebenfalls sind die Empfangenen Label absolut nicht sofort lesbar:
EF00/0210 = eingestellte Solltemperatur, EF00/0218 = gemessene Temperatur usw
Code Auswählen
[code]define MQTT2_z2t_6EF5 MQTT2_DEVICE z2t_6EF5
attr MQTT2_z2t_6EF5 autocreate 1
attr MQTT2_z2t_6EF5 comment Temperaturen *10 zum Regler senden
attr MQTT2_z2t_6EF5 genericDeviceType thermostat
attr MQTT2_z2t_6EF5 icon hm-cc-rt-dn
attr MQTT2_z2t_6EF5 model tasmota_zigbee2tasmota_eigenbau
attr MQTT2_z2t_6EF5 readingList tele/ZigBee2MQTT/6EF5/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x6EF5.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_6EF5 room MQTT2_DEVICE
attr MQTT2_z2t_6EF5 setList EF00/0210:slider,50,5,300 cmnd/ZigBee2MQTT/6EF5/SENSOR/ZbSend {"device":"0x6EF5","Write":{"EF00/0210": $EVTPART1}}
attr MQTT2_z2t_6EF5 setStateList on off
attr MQTT2_z2t_6EF5 stateFormat Gemessene Temp: gemessen°C Soll Temp: temperature°C
attr MQTT2_z2t_6EF5 userReadings temperature { ReadingsVal("MQTT2_z2t_6EF5","EF00/0210",200)/10;; },\
gemessen { ReadingsVal("MQTT2_z2t_6EF5","EF00/0218",200)/10;; }
# CFGFN
# CID z2t_6EF5
# DEF z2t_6EF5
# FUUID 6619370c-f33f-b48a-80c0-bdb8066a81ddaaf6
# IODev MQTT2_PI4_Server
# LASTInputDev MQTT2_PI4_Server
# MQTT2_PI4_Server_CONN MQTT2_PI4_Server_192.168.178.14_64846
# MQTT2_PI4_Server_MSGCNT 610
# MQTT2_PI4_Server_TIME 2024-04-16 13:29:46
# MSGCNT 610
# NAME MQTT2_z2t_6EF5
# NR 976
# STATE Gemessene Temp: 20.8°C Soll Temp: 21°C
# TYPE MQTT2_DEVICE
# eventCount 731
# Helper:
# DBLOG:
# 0000/FFE2:
# myDbLog:
# TIME 1713263230.78465
# VALUE 31
# 0000/FFE4:
# myDbLog:
# TIME 1713263230.78465
# VALUE 0
# AppVersion:
# myDbLog:
# TIME 1713263230.78465
# VALUE 69
# Cluster:
# myDbLog:
# TIME 1713263489.82607
# VALUE 10
# Config_1:
# myDbLog:
# TIME 1712931884.8396
# VALUE ~01.1
# Device:
# myDbLog:
# TIME 1713266986.82229
# VALUE 0x6EF5
# EF00/0210:
# myDbLog:
# TIME 1713266372.83129
# VALUE 210
# EF00/0218:
# myDbLog:
# TIME 1713266986.82229
# VALUE 208
# EF00/0268:
# myDbLog:
# TIME 1713035813.84685
# VALUE 210
# EF00/0269:
# myDbLog:
# TIME 1713035812.51775
# VALUE 170
# EF00/0402:
# myDbLog:
# TIME 1713199697.60973
# VALUE 1
# Endpoint:
# myDbLog:
# TIME 1713266986.82229
# VALUE 1
# Endpoints_1:
# myDbLog:
# TIME 1712931884.8396
# VALUE 1
# IEEEAddr:
# myDbLog:
# TIME 1712931884.8396
# VALUE 0x50325FFFFE7A448F
# LastSeen:
# myDbLog:
# TIME 1712931884.8396
# VALUE 213
# LastSeenEpoch:
# myDbLog:
# TIME 1712931884.8396
# VALUE 1712931671
# LinkQuality:
# myDbLog:
# TIME 1713266986.82229
# VALUE 200
# Manufacturer:
# myDbLog:
# TIME 1712931884.8396
# VALUE _TZE200_e9ba97vf
# ModelId:
# myDbLog:
# TIME 1712931884.8396
# VALUE TS0601
# Reachable:
# myDbLog:
# TIME 1712931884.8396
# VALUE true
# ReadNames_LocalTime:
# myDbLog:
# TIME 1713263489.82607
# VALUE true
# Read_1:
# myDbLog:
# TIME 1713263489.82607
# VALUE 7
# SENSOR_ZbReceived_0x6EF5_Device:
# myDbLog:
# TIME 1712930397.56498
# VALUE 0x6EF5
# SENSOR_ZbReceived_0x6EF5_EF00/0210:
# myDbLog:
# TIME 1712928780.35623
# VALUE 200
# SENSOR_ZbReceived_0x6EF5_EF00/0218:
# myDbLog:
# TIME 1712930397.56498
# VALUE 241
# SENSOR_ZbReceived_0x6EF5_EF00/0402:
# myDbLog:
# TIME 1712928774.11536
# VALUE 0
# SENSOR_ZbReceived_0x6EF5_Endpoint:
# myDbLog:
# TIME 1712930397.56498
# VALUE 1
# SENSOR_ZbReceived_0x6EF5_LinkQuality:
# myDbLog:
# TIME 1712930397.56498
# VALUE 189
# attrTemplateVersion:
# myDbLog:
# TIME 1712930678.44179
# VALUE 20210811
# desired-temp:
# myDbLog:
# TIME 1713197885.19991
# VALUE set 19.5
# gemessen:
# myDbLog:
# TIME 1713266986.82229
# VALUE 20.8
# state:
# myDbLog:
# TIME 1712930688.27978
# VALUE attrTemplate speechcontrol_siri_specials RADIO_KEEPsiriNAME=0 RADIO_SETsiriNAME=0 RADIO_DoNotSetsiriName=1 RADIO_Delete_gDT=0
# temp-offset:
# myDbLog:
# TIME 1712930730.32245
# VALUE set temp-offset 0.0
# temperature:
# myDbLog:
# TIME 1713266986.82229
# VALUE 21
# OLDREADINGS:
# READINGS:
# 2024-04-16 12:27:10 0000/FFE2 31
# 2024-04-16 12:27:10 0000/FFE4 0
# 2024-04-16 12:27:10 AppVersion 69
# 2024-04-16 12:31:29 Cluster 10
# 2024-04-16 13:29:46 Device 0x6EF5
# 2024-04-16 13:19:32 EF00/0210 210
# 2024-04-16 13:29:46 EF00/0218 208
# 2024-04-15 18:48:17 EF00/0402 1
# 2024-04-16 13:29:46 Endpoint 1
# 2024-04-16 13:29:46 LinkQuality 200
# 2024-04-16 12:31:29 ReadNames_LocalTime true
# 2024-04-16 12:31:29 Read_1 7
# 2024-04-16 13:29:46 gemessen 20.8
# 2024-04-16 13:29:46 temperature 21
#
setstate MQTT2_z2t_6EF5 Gemessene Temp: 20.8°C Soll Temp: 21°C
setstate MQTT2_z2t_6EF5 2024-04-16 12:27:10 0000/FFE2 31
setstate MQTT2_z2t_6EF5 2024-04-16 12:27:10 0000/FFE4 0
setstate MQTT2_z2t_6EF5 2024-04-16 12:27:10 AppVersion 69
setstate MQTT2_z2t_6EF5 2024-04-16 12:31:29 Cluster 10
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 Device 0x6EF5
setstate MQTT2_z2t_6EF5 2024-04-16 13:19:32 EF00/0210 210
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 EF00/0218 208
setstate MQTT2_z2t_6EF5 2024-04-15 18:48:17 EF00/0402 1
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 Endpoint 1
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 LinkQuality 200
setstate MQTT2_z2t_6EF5 2024-04-16 12:31:29 ReadNames_LocalTime true
setstate MQTT2_z2t_6EF5 2024-04-16 12:31:29 Read_1 7
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 gemessen 20.8
setstate MQTT2_z2t_6EF5 2024-04-16 13:29:46 temperature 21
[/code]Dieser Eigenbau funktioniert eigentlich nur hätte ich gern z.b. die Temperatur mit 21 und nicht mit 210 eigegeben.
Das Attribut setList temperature:slider,50,5,300 cmnd/ZigBee2MQTT/6EF5/SENSOR/ZbSend {"device":"0x6EF5","Write":{"EF00/0210": $EVTPART1}} sendet auch richtig.
Nun müsste nur noch der Inhalt von $EVTPART1 *10 und alles wäre wieder normal.
Nur das bekomme ich so einfach nicht hin, habt ihr nen Tip dazu?
Grüße Wolfdieter
#8
Homematic / Aw: MISSING ACK nach Umzug in ...
Letzter Beitrag von Otto123 - 16 April 2024, 13:47:01Hallo Andreas,
Zitat von: AndreasGaus am 16 April 2024, 13:01:50Auch im Homematic Bereich wird geschraubt.Kann ich irgendwie nicht erkennen? Ich habe aktuell update gemacht.
Code Auswählen
10_CUL_HM.pm 26934 2022-12-31 16:24:33Z martinp876
98_HMinfo.pm 26935 2022-12-31 16:25:33Z martinp876
00_HMLAN.pm 25204 2021-11-09 05:41:42Z martinp876
98_HMtemplate.pm 24835 2021-08-08 16:00:50Z martinp876
00_HMUARTLGW.pm 25203 2021-11-08 09:18:29Z mgernoth
HMConfig.pm 25160 2021-10-30 17:38:52Z martinp876
hm.js 2008 2021-03-01 12:00:00Z frank
Gruß Otto #9
RFXTRX / Aw: RFXTRX refuses to connect
Letzter Beitrag von Wernieman - 16 April 2024, 13:12:52you are not the first person, which have the "permission denied". So it was easy to see the problem.
#10
Homematic / Aw: MISSING ACK nach Umzug in ...
Letzter Beitrag von AndreasGaus - 16 April 2024, 13:01:50Hallo Alex, hallo zusammen,
hoffentlich out of topic, oder vielleicht doch ein größeres Problem mit der aktuellen Homematic FHEM Implementierung?
Ich habe ohne Docker Umzüge etc. seit 13.04.2024 (exakt der erste Post von Alex) auch massive Verbindungs-Probleme mit meinen Homematic Geräten.
Homematic ActionDectector:
alive:39 dead:0 unkn:10 off:0
HMInfo:
Vor ein paar Stunden:
I_actTotal
alive:26,dead:10,unkn:13,off:0
Aktuell:
I_actTotal
alive:39,dead:0,unkn:10,off:0
D.h. Dead hat sich wieder etwas verbessert, aber immer noch 10 Unknown Geräte. Prptokollfehler;
ERR__protocol
CmdDel:30,IOerr:12,ResndFail:25
ACK MISSING / PENDING Fehler das Hauptproblem. Einige Geräte arbeiten, andere sehr langsam, manche überhaupt nicht mehr.
Viele Schalter lassen sich aktivieren, aber der Status kommt nicht oder sehr langsam an.
Direkte Peer Verbindungen mit Wandtastern funktionieren jedoch an den besagten Geräten einwandfrei, was Funkstörungen sehr unwahrscheinlich macht.
- Funkstörungen in Analyse
- Verdacht: HM relevante FHEM Modulanpassungen in den letzten Wochen? Auch im Homematic Bereich wird geschraubt.
- Hardware Fehler ist bereits ausgeschlossen, da ich ein neues HMLANGW mit neuester Firmware konfiguriert habe, das sich exakt gleich verhält.
Werde berichten, ob sich bei mir etwas genaueres herausfinden lässt, oder ob das Problem mit dem von Axel übereinstimmt. Bin für Tipps auch sehr dankbar...
Viele Grüße
Andreas
hoffentlich out of topic, oder vielleicht doch ein größeres Problem mit der aktuellen Homematic FHEM Implementierung?
Ich habe ohne Docker Umzüge etc. seit 13.04.2024 (exakt der erste Post von Alex) auch massive Verbindungs-Probleme mit meinen Homematic Geräten.
Homematic ActionDectector:
alive:39 dead:0 unkn:10 off:0
HMInfo:
Vor ein paar Stunden:
I_actTotal
alive:26,dead:10,unkn:13,off:0
Aktuell:
I_actTotal
alive:39,dead:0,unkn:10,off:0
D.h. Dead hat sich wieder etwas verbessert, aber immer noch 10 Unknown Geräte. Prptokollfehler;
ERR__protocol
CmdDel:30,IOerr:12,ResndFail:25
ACK MISSING / PENDING Fehler das Hauptproblem. Einige Geräte arbeiten, andere sehr langsam, manche überhaupt nicht mehr.
Viele Schalter lassen sich aktivieren, aber der Status kommt nicht oder sehr langsam an.
Direkte Peer Verbindungen mit Wandtastern funktionieren jedoch an den besagten Geräten einwandfrei, was Funkstörungen sehr unwahrscheinlich macht.
- Funkstörungen in Analyse
- Verdacht: HM relevante FHEM Modulanpassungen in den letzten Wochen? Auch im Homematic Bereich wird geschraubt.
- Hardware Fehler ist bereits ausgeschlossen, da ich ein neues HMLANGW mit neuester Firmware konfiguriert habe, das sich exakt gleich verhält.
Werde berichten, ob sich bei mir etwas genaueres herausfinden lässt, oder ob das Problem mit dem von Axel übereinstimmt. Bin für Tipps auch sehr dankbar...
Viele Grüße
Andreas