Hallo,
habe 5 Homematic Heizkörperthermostate HM-CC-RT-DN welche bisher mit meinen FHEM funktioniert haben.
Habe jetzt ein Strompi3 (Notstrom) auf meinen Raspberry installiert. Dieser wird auf die GPIO gesteckt. Auf diese habe ich wiederum das Funkmodul Homematic HM-MOD-RPI-PCB gesteckt.
Laut Anleitung kann man vom Strompi3 die GPIO so einstellen, dass die Kommunikation nicht über die serielle Schnittstelle geht.
So steht es in der Anleitung und so habe ich es auch konfiguriert:
Der Serialless Modus ermöglicht es Ihnen jegliche serielle
Kommunikation des StromPi zu unterdrücken, so können Sie z.B. ein
anderes HAT, welches die serielle Schnittstelle benutzt, zeitgleich mit
dem StromPi nutzen.
Bei allen 5 Heizkörpern wird mir jetzt aber im "Hauptdevice" z.B. bei WOH_HEIZUNG_3 vom Thermostat
STATE CMDs_pending
angezeigt
Bei
WOH_HEIZUNG_3_ClimaTeam
WOH_HEIZUNG_3_Climate
WOH_HEIZUNG_3_remote
wird
unpeered
angezeigt
Kann es sein, dass es mit dem Strompi3 doch nicht funktioniert?
Was könnte ich noch machen, damit es funktioniert bzw. hat es schon jemand geschafft?
Hier wäre noch das list von WOH_HEIZUNG_3
Internals:
DEF 62FACF
FUUID 5c65c66e-f33f-194f-db67-869f4db009b57c92
IODev HmUART
NAME WOH_HEIZUNG_3
NOTIFYDEV global
NR 22
NTFY_ORDER 48-WOH_HEIZUNG_3
STATE CMDs_pending
TYPE CUL_HM
channel_01 WOH_HEIZUNG_3_Weather
channel_02 WOH_HEIZUNG_3_Climate
channel_03 WOH_HEIZUNG_3_WindowRec
channel_04 WOH_HEIZUNG_3_Clima
channel_05 WOH_HEIZUNG_3_ClimaTeam
channel_06 WOH_HEIZUNG_3_remote
protCmdPend 19 CMDs_pending
protState CMDs_pending
Helper:
DBLOG:
state:
DbLog:
TIME 1646651973.63757
VALUE CMDs_pending
READINGS:
2022-03-07 12:06:18 Activity dead
2022-03-03 10:29:53 CommandAccepted yes
2021-04-20 05:25:06 D-firmware 1.4
2021-04-20 05:25:06 D-serialNr OEQ1704682
2022-03-07 11:47:08 IODev HmUART
2022-01-17 15:47:47 PairedTo 0xFA3B12
2018-11-23 19:21:41 R-backOnTime 10 s
2018-11-23 19:21:41 R-burstRx on
2018-11-23 19:21:41 R-cyclicInfoMsg on
2018-11-23 19:21:41 R-cyclicInfoMsgDis 0
2018-11-23 19:21:41 R-pairCentral 0xFA3B12
2022-03-07 10:11:02 actuator 0
2022-03-07 10:11:02 battery ok
2022-03-07 10:11:02 batteryLevel 3
2022-03-07 12:19:33 cfgState updating
2022-03-07 12:19:33 commState CMDs_pending
2022-03-07 10:11:02 desired-temp 21.5
2022-03-07 10:11:02 measured-temp 22.2
2022-03-07 10:11:02 motorErr ok
2022-01-17 15:44:57 powerOn 2022-01-17 15:44:57
2022-01-17 15:44:57 recentStateType info
2022-03-07 12:19:33 state CMDs_pending
2022-03-07 00:17:56 time-request -
cmdStack:
++803FFA3B1262FACF020229B8A152
++A001FA3B1262FACF00050000000007
++A001FA3B1262FACF0008144D15202E4D2F20484D4920624D
++A001FA3B1262FACF000863207C4D7D20964D9720B04DB120
++A001FA3B1262FACF0006
++A001FA3B1262FACF00040000000000
##A001FA3B1262FACF0103
##A001FA3B1262FACF01040000000001
##A001FA3B1262FACF0203
##A001FA3B1262FACF02040000000001
##A001FA3B1262FACF0303
##A001FA3B1262FACF03040000000001
##A001FA3B1262FACF0403
##A001FA3B1262FACF04040000000001
##A001FA3B1262FACF00040000000007
##A001FA3B1262FACF0503
##A001FA3B1262FACF05040000000001
##A001FA3B1262FACF0603
##A001FA3B1262FACF06040000000001
helper:
HM_CMDNR 121
cfgStateUpdt 1
mId 0095
peerFriend -
peerOpt -:thermostat
regLst 0
rxType 140
cmds:
TmplKey :no:1646650029.41773
TmplTs 1646650029.41773
cmdKey 0:1:0::WOH_HEIZUNG_3:0095:00:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
inhibit [(on|{off})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sysTime noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 2
newChn +62FACF,02,00,00
rxt 2
vccu
p:
62FACF
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
dev 1
prs 1
shRegW:
07 04
tmpl:
Attributes:
IODev HmUART
actCycle 000:10
actStatus dead
autoReadReg 4_reqStatus
commStInCh off
expert defReg,rawReg
firmware 1.4
group Heizung
model HM-CC-RT-DN
room Wohnzimmer
serialNr OEQ1704682
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Und vom WOH_HEIZUNG_3_Climate als Beispiel
Internals:
DEF 62FACF02
FUUID 5c65c66e-f33f-194f-090d-bb7c8ee932f32f96
NAME WOH_HEIZUNG_3_Climate
NR 25
NTFY_ORDER 48-WOH_HEIZUNG_3_Climate
STATE unpeered
TYPE CUL_HM
chanNo 02
device WOH_HEIZUNG_3
disableNotifyFn 1
READINGS:
2018-11-23 19:21:43 R-sign off
2022-03-07 12:19:33 cfgState updating
2022-03-07 11:47:09 state unpeered
helper:
getCfgListNo
peerFriend peerRtTc
peerIDsState complete
peerOpt p:thermostat
regLst 1
cmds:
TmplKey :no:1646650029.43072
TmplTs 1646650029.43072
cmdKey 1:0:0::WOH_HEIZUNG_3:0095:02:
cmdLst:
burstXmit noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
inhibit [(on|{off})]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerSmart -peerOpt-
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
sign [(on|{off})]
sysTime noArg
tplDel -tplDel-
tplSet_0 -tplChan-
lst:
condition slider,0,1,255
peer
peerOpt KIND_HEIZUNG_1_Climate,KIND_HEIZUNG_2_Climate,WOH_HEIZUNG_1_Climate,WOH_HEIZUNG_2_Climate
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
00000000 broadcast
role:
chn 1
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000
Zitat von: Christoph Morrison am 09 März 2019, 17:30:24
Du benutzt einen HM-MOD-RPI-PCB? Ich meine mich zu erinnern, dass der StromPI auch UART für die Konsole benutzt. Beides auf den gleichen Pins geht nicht.
Folgende Info habe ich aus einen älteren Beitrag gefunden.
Alles Pins sind beim StromPi3 durchgeschleift - Außer der Spannungsversorgung über die 5V Pins, wird nur die serielle Schnittstelle (GPIO14/GPIO15) für die Konfiguration und das abfangen des Schutdown-Signals für die essentiellen Grundfunktionen benötigt.
Was jedoch den Hinweis in der Anleitung wiedersprechen würde, dass jegliche serielle Kommunikation unterdrückt werde.
Aber wie sollte sonst die Kommunikation erfolgen, wenn nicht über die GPIOs?
Habe hier einen Schaltplan noch gefunden.
https://github.com/joy-it/strompi3/blob/master/Schematic%20Files%2BHardware%20Layout/Schematic.pdf
Wie wäre es mit einem list des HMUART-Devices?
Daran sollte man doch erkennen können, ob er auf die seriellen Schnittstellen kommt oder nicht?
Also ob dieser überhaupt "opened" (so glaube ich sollte das sein) ist...
...wenn der "opened" ist und "dauerhaft" bleibt, dann kann es doch eigentl. nur was anderes sein?
Wenn nicht, dann ist ja wohl klar, dass es (so) nicht geht...
Evtl. "verdeckt" das StromPI die Funkerei?
Oder "spuckt" sonst wie rein?
Gruß, Joachim
Hier das List vom HMUART
Internals:
CNT 1
Clients :CUL_HM:
DEF /dev/ttyAMA0
DevState 1
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 4
FUUID 5c65c66d-f33f-194f-4045-889e949e578221c0
LastOpen 1646660691.08849
NAME HmUART
NOTIFYDEV global
NR 17
NTFY_ORDER 47-HmUART
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
AckPending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 2
time 1646660692.08986
LastSendLen:
3
Log:
IDs:
MatchList:
1:CUL_HM ^A......................
PeerQueue:
HASH(0x10bace0)
HASH(0x4306250)
HASH(0x430ca38)
HASH(0x10bacc8)
HASH(0x42fd438)
HASH(0x430b1d0)
HASH(0x430dac0)
HASH(0x430eba8)
HASH(0x430b740)
HASH(0x43079b0)
HASH(0x2c65838)
HASH(0x41e5c90)
HASH(0x41b4fd0)
HASH(0x41b36b0)
HASH(0x41b3ad0)
HASH(0x41b2458)
HASH(0x41b2848)
HASH(0x41b22f0)
HASH(0x41b2398)
HASH(0x41b52d0)
Peers:
1906AC pending
544B10 pending
5E1A04 pending
62FAC4 pending
62FAC8 pending
62FACF pending
62FB0B pending
62FB6A pending
6BAE85 pending
70FFF4 pending
READINGS:
2022-01-28 14:39:53 D-HMIdAssigned FA3B12
2022-01-28 14:39:53 D-HMIdOriginal 6A567E
2022-01-28 14:39:53 D-firmware 1.4.1
2022-01-28 14:39:53 D-serialNr PEQ0533840
2022-03-07 13:29:13 D-type HM-MOD-UART
2022-03-07 14:44:52 cond init
2022-03-07 10:10:24 load 6
2022-03-07 13:29:13 loadLvl suspended
2022-03-07 14:44:51 state opened
helper:
Attributes:
hmId FA3B12
Hier wäre noch ein Ausschnitt aus dem Event Monitor:
(Bedeutet das, dass HmUART immer trennt und wieder neu verbindet?)
2022-03-07 14:45:30 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:30 HMUARTLGW HmUART CONNECTED
2022-03-07 14:45:31 HMUARTLGW HmUART cond: init
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0019
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur IOerr
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur commState: CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0010
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 IOerr
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 commState: CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 CMDs_done_Errors:1
2022-03-07 14:45:43 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:43 HMUARTLGW HmUART CONNECTED
2022-03-07 14:45:44 HMUARTLGW HmUART cond: init
2022-03-07 14:45:56 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:56 HMUARTLGW HmUART CONNECTED
Zitat von: Ruggy am 07 März 2022, 14:47:54
Hier wäre noch ein Ausschnitt aus dem Event Monitor:
(Bedeutet das, dass HmUART immer trennt und wieder neu verbindet?)
2022-03-07 14:45:30 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:30 HMUARTLGW HmUART CONNECTED
2022-03-07 14:45:31 HMUARTLGW HmUART cond: init
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0019
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur commState: CMDs_pending
2022-03-07 14:45:41 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:41 CUL_HM KIND_virt_Temperatur CMDs_pending
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0009
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur IOerr
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur commState: CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0010
2022-03-07 14:45:43 CUL_HM KIND_virt_Temperatur CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 IOerr
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 commState: CMDs_done_Errors:1
2022-03-07 14:45:43 DbLog DbLog notify_processing_time: 0.0008
2022-03-07 14:45:43 CUL_HM WOH_virt_Temperatur_2 CMDs_done_Errors:1
2022-03-07 14:45:43 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:43 HMUARTLGW HmUART CONNECTED
2022-03-07 14:45:44 HMUARTLGW HmUART cond: init
2022-03-07 14:45:56 HMUARTLGW HmUART cond: disconnected
2022-03-07 14:45:56 HMUARTLGW HmUART CONNECTED
Sieht für mich so aus...
Also sind wohl die Tx/Rx doch nicht frei...
Gruß, Joachim
Zu der Firmwareversion 1.7 steht auf Github zum Strompi3
https://github.com/joy-it/strompi3
Revised Serial-Less Mode: There is now a second stage of the Serial-Less Mode which disconnects the UART Pins of the StromPi3 STM32 Controller completely from the TX/RX-Lines of the Raspberry Pi. As for this the compatibility of HATs/Expansions, which are also using the UART interface, is increased. Please refer to the Manuals and Scripts for activating and deactivating this mode.
Das wäre doch genau das, was anscheinend das Serial-Less bezwecken sollte?
2022-03-07 14:44:52 cond init
2022-03-07 10:10:24 load 6
2022-03-07 13:29:13 loadLvl suspended
2022-03-07 14:44:51 state opened
meins
2022-02-02 17:23:52 cond ok
2022-02-02 17:23:52 load 0
2022-02-02 17:23:52 loadLvl low
2022-02-02 17:23:49 state opened
du siehst de Unterschied?
Habe jetzt den HM-MOD-RPI-PCB wieder ohne den Strompi3 auf den Raspberry gesteckt und nun sieht es so wie bei dir aus.
2022-03-07 19:07:17 cond ok
2022-03-07 21:28:59 load 6
2022-03-07 19:07:17 loadLvl low
2022-03-07 19:05:23 state opened
Beim Hautpdevice Heizung_3 ist jetzt
STATE CMDs_done
WOH_HEIZUNG_3_ClimaTeam
WOH_HEIZUNG_3_Climate
WOH_HEIZUNG_3_remote
Aber bei diesen drei ist STATE immer noch auf unpeered
Ich habe jetzt auch festgestellt, dass ich noch die Version Jessie habe.
Beim Udaten und Upgraden hat es Fehler (bzgl. mosquitto) gehagelt.
Kann es sein, dass es auch damit zusammenhängt und der Strompie + HM-MOD-RPI-PCB auf z.B. Bullseye funktioniert?
Aufgrund eines anderen Threads habe ich jetzt festgestellt, dass ich um eine Neuinstallation nicht herumkommen werde um wieder ein aktuelles System zu haben.
Bevor ich mich über eine Neuinstallation mache wollte ich noch etwas testen.
Ich möchte testen, ob der Strompi3 wegen meinem veralterten Jessie nicht funktioniert.
Ich hätte jetzt auf meinem "Testraspberry", mit welchem der Strompi3 schon grundsätzlich funktioniert hatte, das Funkmodul HM-MOD-RPI-PCB installiert, um zu sehen, ob es dann hier funktioniert.
Dieser Testraspberry läuft mit dem aktuelle Bullseye.
Dazu müsste ich dann das UART neu einrichten und das Funkmodul HM-MOD-RPI-PCB darauf installieren.
Dann könne ich sehen, ob hier auch die Verbindung immer wieder unterbrochen und neu verbunden wird oder ob es funktioniert und tatsächlich am Jessie liegt.
Da ich die Neuinstallation nicht gleich machen werde, möchte ich bis dahin noch meine alte Installation nutzen.
Bringt es mir die alten Installation durcheinander (bzw. die angelernten Devices), wenn ich das Funkmodul HM-MOD-RPI-PCB zu testzwecken auf den Testraspberry nutze?
Naja, wenn du kurze Zeit auf fhem verzichten kannst, dann einfach eine neue SD nehmen, Bullseye drauf.
PI runter fahren, SD stecken, OS fertig machen und vorbereiten (Einstellungen bzgl. Seriell für HMOD-PCB inkl. Strompi ohne, dass Rx/Tx geblockt wird).
fhem installieren und einfach mal schnell das HMOD definieren.
Wenn du keine (= es wird die "HW-HMID" des HMOD-PCB genommen) oder eine andere HMID angibst, dann "ignorieren" die vorhandenen HM-Geräte die neue Probeinstallation komplett...
...selbst wenn du dieselbe angibst würde nichts passieren, du hast ja keine Devices definiert (also wenn du nur mit dem "default fhem" hochläufst).
Damit solltest du ja bereits sehen können, ob das damit dann geht: Status des HMOD-PCB / HMUART
Oder du vergibst die HMID deines jetzigen Systems, pairst ein vorhandenes Gerät "drüber", also:
set HMOD-PCB / HMUART pairForSec 60
Anlernknopf des Gerätes drücken
Dann wird im neuen fhem das Device angelegt und gepaired (evtl. öfter "Knöpfchen drücken")...
Keine Angst: für das Gerät ändert sich nichts (HMID=Kennung der Zentrale leibt ja)...
(es denkt sich höchstens: warum noch mal anlernen, ich kenn doch meine Zentrale schon ;) )
Wenn die HMID nicht passt verweigert das Gerät das erneute Anlernen und Kommandos sowieso...
Du solltest (bei passender HMID) halt Kommandos vermeiden, die etwas an den Registern ändern (set regSet / Peering usw.). "Normale" Kommados, also ein/aus etc. sind unproblematisch (funktionieren aber halt auch nur, wenn die HMID passt)...
Wenn du fertig getestet hast, dann einfach die alte SD in den PI (Strompi runter) und gut...
Gruß, Joachim
Danke für die ausführliche Antwort.
Werde es heute oder morgen mal testen.
Es ist dann wahrscheinlich auch kein Problem, wenn ich meinen Test-Raspberry nehmen würde und hiermit das HMOD definiere und was noch dazugehört?
Der würde nämlich vor mir auf den Schreibtisch liegen.
Oder wird der andere Raspberry als andere Hardware erkannt?
Wer soll was als anderes System erkennen?
Dem HMOD-PCB ist es egal wo es steckt...
Die HMID wird ja durch fhem bestimmt bzw. kann/sollte...
Ob sich das Zusammenspiel zw. PI, Strompi und HMOD-PCB beim Test-PI dann auch das Verhalten auf dem tatsächlichen PI nachstellt: keine Ahnung (aber wahrscheinlich ja)...
Ansonsten weiß ich nicht was du meinst...
Gruß, Joachim
Dachte mir, dass es so wie beim Computer sein könnte, wenn man z.B. das Mainboard tauscht.
Aber ist dann beim Raspberry ja nicht so.
Wobei Du schon recht hast, bzgl. dem Zusammenspiel mit dem tatsächlichen PI.
Werde es dann doch am tatsächlichen PI nachstellen.
Du kannst doch alles auf dem Test-PI vorbereiten und sogar dort testen...
Dann einfach Strompi, HMOD-PCB und SD umstecken und kurz am "Real-System" testen und dann wieder das aktuelle System in Betrieb nehmen...
So verzichtest du ja nur kurz auf dein "Real-fhem"...
Gruß, Joachim
Zitat von: Ruggy am 08 März 2022, 20:07:27
Dachte mir, dass es so wie beim Computer sein könnte, wenn man z.B. das Mainboard tauscht.
Aber ist dann beim Raspberry ja nicht so.
Das liegt wohl weniger am Raspberry sondern eher am OS.
Linux ist gegenüber HW-Wechsel deutlich unempfindlicher als z.B. Windows.
Ein Motherboardwechsel muss schon sehr extrem sein und das Linux nicht aktuell (sofern das neue MB sehr neu ist), bis das nicht mehr (vernünftig) läuft...
Gruß, Joachim
Habe das HM-MOD-RPI-PCB mit Strompi3 und Bulleyes getestet und es funktioniert trotzdem nicht.
HM-MOD-RPI-PCB trennt und verbindet sich immer wieder.
Habe beim Herstellen von Strompi3 angefragt, welche mir mitgeteilt haben, dass es direkt eine serialless Firmware geben würde.
Aber das Firmwareupdate funktioniert nicht.
Folgender Befehl:
stm32flash /dev/serial0 -w RB-StromPi3_V-1_73.bin -b 9600
Bringt folgende Fehlermeldung
http://stm32flash.sourceforge.net/
Using Parser : Raw BINARY
Interface serial_posix: 9600 8E1
Failed to init device.
das fhem device hast du hoffentlich still gelegt damit es nicht dazwischen quatscht.
Habe ich nicht ???
Mit folgenden Befehl?
sudo service fhem stop
Habe mit folgenden Befehlt FHEM angehalten
sudo systemctl stop fhem
Es kam aber wieder die selbe Fehlermeldung beim Firmwareupdate
Die Vorbereitungen bzgl. Serieller Schnittstelle beim PI hast du durchgeführt?
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_an_die_GPIO_im_Raspberry
https://wiki.fhem.de/wiki/Raspberry_Pi
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Geht denn das HMOD-PCB OHNE Strompi überhaupt?
Gruß, Joachim
Ich würde schon sagen, dass ich es richtig installiert habe.
Auch bei der Eingabe der Befehle zur Kontrolle der seriellen Schnittstelle wie in der verlinkten Anleitung unter Troubleshooting, werden die richtigen Ausgaben geliefert.
Das HM-MOD-RPI-PCB ohne Strompi3 funktioniert richtig und die Verbindung wird nicht unterbrochen.
Zitat von: Ruggy am 10 März 2022, 16:36:01
Das HM-MOD-RPI-PCB ohne Strompi3 funktioniert richtig und die Verbindung wird nicht unterbrochen.
Tja, dann ist halt doch noch was mit Strompi, dass da halt wohl doch (noch) die seriellen Schnittstellen blockiert werden...
Gruß, Joachim
Wahrscheinlich liegs am Strompi3.
Das Serialless Firmware bekomme ich momentan nicht rauf, weil auch das Firmwareupdate nicht funktioniert. Hierzu habe ich kontakt mit der "Strompi-Firma" aufgenommen.
Evlt. liegt doch an meiner Installation. Obwohl ich schon meine, dass ich es so wie beschrieben durchgeführt habe. Und ohne Strompi funktionierts ja anscheinend (zumindest keine Verbindungsabbrüche).
Noch mal: wenn du den Strompi flashen wilst, dann nat. das HMOD-PCB runter nehmen UND auch fhem stoppen...
Wenn es dann auch nicht geht, dann ist je was "komisch" mit dem Strompi...
Viel Erfolg, Joachim