Hallo.
Ein kleines Problem ist in folgender Konstellation aufgetreten.
Ein Raspi hat 2 stapelbare SCC und einen SCD on Top.
1. SCC 433Mhz SlowRF
2. SCC 868Mhz Max
3. SCD on Top 868Mhz WMBUS
Dieser Raspi macht die CULs per ser2net verfügbar.
/etc/ser2net.conf
2003:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITSWeiters werden die GPIOs wie folgt am RPI initalisiert.
#!/bin/sh
echo Enable busware gpio scc
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
Am Haupt-FHEM Server und Debian7 (MacMini) werden die CULs wie folgt eingebunden.
#define SCC1 CUL /dev/ttyAMA0@38400 1234
define SCC1 CUL fhem1.local:2003 1234
attr SCC1 alias SCC1 433Mhz SlowRF
attr SCC1 group CUL
attr SCC1 model CUL
attr SCC1 rfmode SlowRF
attr SCC1 room CUL
attr SCC1 verbose 3
define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2
attr SCC2 group CUL
attr SCC2 model CUL
attr SCC2 rfmode MAX
attr SCC2 room CUL
attr SCC2 verbose 3
define SCC3 STACKABLE_CC SCC2
attr SCC3 alias SCC3
attr SCC3 group CUL
attr SCC3 model CUL
attr SCC3 rfmode WMBus_T
attr SCC3 room CUL
attr SCC3 verbose 5
Folgendes Problem.
Wird der Raspi mit den SCC-Culs neu gestartet oder der Haupt-Fhem verliert die Verbindung, dann wird nur der 1. CUL (433) wieder vom Haupt-FHEM reconnected.
Die 2 anderen Culs empfangen keine Daten mehr.
Im Moment kann das System nur wie folgt zum Laufen gebracht werden.
- Stoppen des FHEM am Debian Hauptserver
- Stoppen von ser2net am Raspi
- Neu Init der GPIOs am Raspi
- Starten ser2net am Raspi
- Starten Fhem am Haupt-Debian
Ich vermute, dass bei einem Reconnect des Haupt-Fhem Servers nur der 1. CUL die INIT Befehle erhält.
Das ist auch im Log zu sehen.
Wie kann ich die 2 anderen gestackten SCC-CULs automatisch nach einem Reconnect initialisieren lassen?Vielen Dank im Voraus.
Gruss.
LOG:
2015.05.25 15:06:15 1: fhem1.local:2003 disconnected, waiting to reappear (SCC1)
==> /opt/fhem/log/fhem-2015-05.log <==
2015.05.25 15:08:17 1: fhem1.local:2003 reappeared (SCC1)
2015.05.25 15:08:18 3: SCC1: Possible commands: mBbCFiAZGMYRTVWXef*ltux
Bei einem reconnect sollte rfMode gesetzt werden, aber die SCCs kriegen das reconnect nicht mit. Eigentlich sollte das im SCC Modul geloest werden, bis das erfolgt muss das Problem mit einem notify auf CUL:CONNECTED geloest werden, der "attr SCC2 rfmode SlowRF;; attr SCC2 rfmode MAX;; attr SCC3 rfmode SlowRF;; attr SCC3 rfmode WMBus_T" ausfuehrt.
Hallo Rudolf.
Vielen Dank für deine rasche und kompetente Hilfe.
So geht es einstweilen, perfekt.
list CUL_Connect_notify
Internals:
DEF SCC1:CONNECTED attr SCC1 rfmode SlowRF ; attr SCC2 rfmode SlowRF ; attr SCC2 rfmode MAX ; attr SCC3 rfmode SlowRF ; attr SCC3 rfmode WMBus_T ; set myHMSwitch1 on-for-timer 10 ; save
NAME CUL_Connect_notify
NOTIFYDEV SCC1
NR 464
NTFY_ORDER 50-CUL_Connect_notify
REGEXP SCC1:CONNECTED
STATE active
TYPE notify
Readings:
2015-05-25 18:34:24 state active
Attributes:
room CUL
Ein weiteres Problem habe ich eigentlich schon seit Monaten.
Bis gestern lief FHEM noch am selben Raspi wie die Busware SCC.
Bei einem 'shutdown restart' wurden die einzelnen SCCs nicht richtig initialisiert.
Der Workaround bestand darin, einfach FHEM zu beenden und neu zu starten.
Jetzt läuft die Sache mit einem FHEM am MacMini unter Debian7 und die SCCs werden, wie im 1. Post beschrieben, per ser2net angebunden.
Wenn ich nun FHEM am Debian7 Hauptserver beende und dann wieder starte, ohne die SCCs am Raspi mit dem Script am Remote Raspi zu initialisieren, dann läuft auch nur der erste SCC1/433Mhz.
Dieser Code wird am Remote Raspi bei einem Neustart von Fhem am Hauptserver nicht ausgeführt.
#!/bin/sh
echo Enable busware gpio scc
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
Diese Meldungen habe ich dann im Fhem Log.
2015.05.25 18:34:42 3: SCC3: Unknown code Z1D4EBBE5EFB0D12ED73FFFFC7F5FB3427FEFEAFF7BEB3FAEF3FE2BA7FCBB, help me!
2015.05.25 18:34:42 2: SCC2: unknown message D7F9F3CFFF3780DBFA45F6BFF2971F4F9BFDD4EBFC87F7625CFFFAFFCF9C
2015.05.25 18:34:42 2: SCC2: unknown message D38ADFEFED3EFE39D6F7D36FBAFE7B7FBFF2A47FF5FF9FF8BEA57A27BABF
2015.05.25 18:35:01 4: CUL_Parse: SCC3 Z1DAD7FFDDDEFAB964FE5E4CDBD37D36FBAFE7B7FBFF2A47FF5FF9FF8BEA57A -13
2015.05.25 18:35:01 5: SCC3 dispatch Z1DAD7FFDDDEFAB964FE5E4CDBD37D36FBAFE7B7FBFF2A47FF5FF9FF8BEA5
2015.05.25 18:35:01 3: SCC3: Unknown code Z1DAD7FFDDDEFAB964FE5E4CDBD37D36FBAFE7B7FBFF2A47FF5FF9FF8BEA5, help me!
2015.05.25 18:35:01 2: SCC2: unknown message BFAE7DAE3DFFDED1C7FC98F7EDFDED5EFAB6BFDFEF31F7EB78F9F9DD1E7F
2015.05.25 18:35:01 3: SCC2: Unknown code 812504xx0101a001ac9fd700b7afeefdebff8d8c8afbefced59e4c7ff1fa3bd91f8fc5ff59bde, help me!
2015.05.25 18:35:11 4: CUL_Parse: SCC3 Z1DF777E7FAC9FD7B7AFEEFDEBFF8D8C8AFBEFCED59E4C7FF1FA3BD91F8FC5F -26.5
2015.05.25 18:35:11 5: SCC3 dispatch Z1DF777E7FAC9FD7B7AFEEFDEBFF8D8C8AFBEFCED59E4C7FF1FA3BD91F8FC
2015.05.25 18:35:11 3: SCC3: Unknown code Z1DF777E7FAC9FD7B7AFEEFDEBFF8D8C8AFBEFCED59E4C7FF1FA3BD91F8FC, help me!
2015.05.25 18:35:11 2: SCC2: unknown message DEF6FDFFF36BE77F1F93EEF26CDDDFBBF76F99C9BBF957F7F79EF4BD
2015.05.25 18:35:11 2: SCC2: unknown message 51EDF3AC55DFEDB9CB1ED77BFEEEFBFFEDE9E756BFBFD2B9531BFFC6FCDF
2015.05.25 18:35:20 4: CUL_Parse: SCC3 Z1D5DF2873F8BFBF776BFCB1ED77BFEEEFBFFEDE9E756BFBFD2B9531BFFC6FC -76
2015.05.25 18:35:20 5: SCC3 dispatch Z1D5DF2873F8BFBF776BFCB1ED77BFEEEFBFFEDE9E756BFBFD2B9531BFFC6
2015.05.25 18:35:20 3: SCC3: Unknown code Z1D5DF2873F8BFBF776BFCB1ED77BFEEEFBFFEDE9E756BFBFD2B9531BFFC6, help me!
2015.05.25 18:35:20 2: SCC2: unknown message 5AFA1F7EEBFFEFFBE77FFCBDD7603B2EF9035C5D5AEC2FF6ED9FDFBC93F9
2015.05.25 18:35:20 3: SCC2: Unknown code EE7F7DBFF53D383D3F9FC5D675BEBEDB, help me!
Hättest du dafür auch eine Lösung oder einen Workaround?
Ich habe mir im Moment so beholfen.
Wenn ich FHEM am Hauptserver starte, werden am Remote-Raspi per SSH mit installiertem authorized_keys ein Init der GPIOs gemacht und der ser2net Dienst neu gestartet.
Dazu wurde die /etc/init.d/fhem am Hauptserver geändert.
sudo ssh root@fhem1.local '/etc/init.d/ser2net restart'
if test "$2" != "noaptmark"; then
apt-mark hold fhem > /dev/null
fi
case "$1" in
'start')
echo "Starting fhem..."
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
# /opt/hmcfgusb/hmland -d -p 1234 -r 0
#
sudo ssh root@fhem1.local '/etc/init.d/ser2net restart'
sleep 2
perl fhem.pl fhem.cfg
Am Raspi wurde die /etc/init.d/ser2net so abgeändert, dass die GPIOs des Raspi bei einem start oder restart initialisiert werden.
Nachtrag:
Wenn ich bei dem obigen Fehlerlogs mit dem Unknown Code dann die ser2net Services am Remote-Raspi neu starte und der neu gemachte Notify, wie von Dir vorgeschlagen, ausgeführt wird, dann läuft es wieder.
2015.05.25 19:01:58 5: SCC3 dispatch Z1DBBEB6BDCE1CC70DB0ABE77F32E0494CFBFD2C26EEBEDCFBEEF67FCCECC
2015.05.25 19:01:58 3: SCC3: Unknown code Z1DBBEB6BDCE1CC70DB0ABE77F32E0494CFBFD2C26EEBEDCFBEEF67FCCECC, help me!
2015.05.25 19:01:58 2: SCC2: unknown message 46FD7B9C7DEFC1FB57CEE2
2015.05.25 19:01:58 2: CUL_MAX_Parse: Got unhandled message type 39
2015.05.25 19:02:02 1: fhem1.local:2004 disconnected, waiting to reappear (jeelink)
2015.05.25 19:02:02 1: fhem1.local:2003 disconnected, waiting to reappear (SCC1)
2015.05.25 19:03:03 1: fhem1.local:2003 reappeared (SCC1)
2015.05.25 19:03:04 3: SCC1: Possible commands: mBbCFiAZGMYRTVWXef*ltux
2015.05.25 19:03:04 2: Switched SCC2 rfmode to SlowRF
2015.05.25 19:03:05 2: Switched SCC2 rfmode to MAX
2015.05.25 19:03:05 2: Switched SCC3 rfmode to SlowRF
2015.05.25 19:03:05 2: Switched SCC3 rfmode to WMBus_T
2015.05.25 19:03:05 3: CUL_HM set myHMSwitch1 on-for-timer 10
2015.05.25 19:03:05 3: CUL_Connect_notify return value: Wrote configuration to fhem.cfg
2015.05.25 19:03:05 1: fhem1.local:2004 reappeared (jeelink)
2015.05.25 19:03:06 2: SCC2: unknown message OFF
2015.05.25 19:03:06 4: CUL_Parse: SCC3 TMODE
2015.05.25 19:03:06 5: CUL_Parse: switched to TMODE
--- Ab hier wieder ok - notify startete
2015.05.25 19:06:51 4: CUL_Parse: SCC3 b2644C514350060310007FBAC7AD02000202F2F046D0832F9150413E867656E000001FD17000478CB66E60076E680E8 -86
2015.05.25 19:06:51 5: SCC3 dispatch b2644C514350060310007FBAC7AD02000202F2F046D0832F9150413E867656E000001FD17000478CB66E60076E680::-86
2015.05.25 19:06:51 5: WMBUS raw msg b2644C514350060310007FBAC7AD02000202F2F046D0832F9150413E867656E000001FD17000478CB66E60076E680::-86
Das Problem ist, dass FHEM nicht weiss, in welchem Mode die SCCs sind, nimmt SlowRF an, und da sind die Z's und D's unbekannt. Abhilfe schafft ein reset, wie gezeigt. Allerding passt der Fall "FHEM wird neugestartet" nicht so wirklich zu diese Theorie, da beim Neustart eigentlich auch die richtigen rfmode Werte gesetzt werden.
Ich habe Fhem nun seit ein paar Tagen mit ser2net laufen und fakt ist, dass bei jedem Start die remote über ser2net angebundenen SCC nicht richtig arbeiten.
Etwas habe ich allerdings rausgefunden. Ein reopen auf das 1. SCC löst das Problem.
Wenn ich nach dem Start von FHEM ein
set SCC1 reopen
mache werden alle 3 Remote-SCC über das obige notify korrekt initialisiert und alles läuft.
2. Workaround.
1 Minute nach dem Start von Fhem sollte nochmal ein set SCC1 reopen gemacht werden.
Wie kann ich das lösen? Über at?
fheminfo hat ja eine upTime.
Gib mir bitte ein at Codeschnipsel oder einen Denkanstoß.
Danke.
define nReopen notify global:INITIALIZED sleep 60;; set SCC1 reopen
Perfekt, Danke so gehts. Da hätte ich auch selbst drauf kommen können.
Ich habe das in mein Startup eingebunden.
list setStartup
Internals:
DEF global:INITIALIZED {readingsSingleUpdate($main::defs{StartUp}, 'state', TimeNow(), 1) ; sleep 10 ; fhem("set SCC1 reopen")}
NAME setStartup
NOTIFYDEV global
NR 500
NTFY_ORDER 50-setStartup
REGEXP global:INITIALIZED
STATE 2015-05-28 10:54:17
TYPE notify
Readings:
2015-05-28 10:54:16 state active
Attributes:
room System
Noch eine Sache funktioniert mit dem ser2net SCCs nicht.
Wenn beim Starten vom Haupt-Fhem der Remote-ser2net Raspi nicht erreichbar ist, wird kein reconnect vom SCC1 durchgeführt, auch wenn danach der Remote Raspi wieder läuft.
Der auch über ser2net angebundene Jeelink wird aber im Log als "reappeared" angezeigt.
==> /opt/fhem/log/fhem-2015-05.log <==
2015.05.28 11:06:32 1: fhem1.local:2004 reappeared (jeelink)
Wenn ich dann händisch ein set SCC1 reopen mache, wird der 2. SCC (Max) nicht korrekt initialisiert.
==> /opt/fhem/log/fhem-2015-05.log <==
2015.05.28 11:06:32 1: fhem1.local:2004 reappeared (jeelink)
2015.05.28 11:08:53 1: fhem1.local:2003 reappeared (SCC1)
2015.05.28 11:08:53 3: SCC1: Possible commands: mBbCFiAZGMYRTVWXef*ltux
2015.05.28 11:08:53 2: Switched SCC2 rfmode to SlowRF
2015.05.28 11:08:53 2: Switched SCC2 rfmode to MAX
2015.05.28 11:08:53 2: Switched SCC3 rfmode to SlowRF
2015.05.28 11:08:53 2: Switched SCC3 rfmode to WMBus_T
2015.05.28 11:08:53 3: CUL_HM set myHMSwitch1 on-for-timer 10
2015.05.28 11:08:53 3: CUL_Connect_notify return value: Wrote configuration to fhem.cfg
2015.05.28 11:08:53 4: CUL_Parse: SCC3 TMODE
2015.05.28 11:08:53 5: CUL_Parse: switched to TMODE
Dann ein
set SCC2 reopen ; set SCC3 reopen
2015.05.28 11:11:52 4: CUL_Parse: SCC3 b2644C514350060310007FBAC7AD12000202F2F046D0D2AFC150413FF0BEC70000001FD17000478CB66E60058B380E5 -87.5
2015.05.28 11:11:52 5: SCC3 dispatch b2644C514350060310007FBAC7AD12000202F2F046D0D2AFC150413FF0BEC70000001FD17000478CB66E60058B380::-87.5
2015.05.28 11:11:52 5: WMBUS raw msg b2644C514350060310007FBAC7AD12000202F2F046D0D2AFC150413FF0BEC70000001FD17000478CB66E60058B380::-87.5
2015.05.28 11:12:14 1: PERL WARNING: Use of uninitialized value $nameOrConf in -f at /usr/lib/perl5/Device/SerialPort.pm line 285.
2015.05.28 11:12:14 1: PERL WARNING: Use of uninitialized value in subroutine entry at /usr/lib/perl5/Device/SerialPort.pm line 311.
SCC1 - läuft
SCC2 - nur defined - wahrscheinlich ist diese Errormeldung schuld
SCC3 - läuft
Anbei die 2 Bilder.
Workaround:
Über at kann, wenn SCC1 auf disconnected steht, alle 5 Minuten versucht werden ein SCC1 reopen zu machen.
Ist das erfolgreich, kann Fhem mit shutdown restart wieder zum Arbeiten überredet werden.
Für eine define at Anweisung wäre ich dir sehr dankbar.
Vielleicht kann man diese Logik ja auch in die CUL Module einbauen?
Gruss
Ich habe im SCC Modul ein notifyFn fuer das drunterliegende CUL/SCC eingebaut: falls eine Nachricht mit CONNECTED/DISCONNECTED kommt dann wird darauf reagiert. Damit sollten keine notify/at Definitionen mehr notwendig sein.
Da ich kein SCC habe, habe ich es nicht getestet. Kannst du das bitte uebernehmen und berichten?
Was die WARNINGs bedeuten, weiss ich nicht, finde aber sehr merkwuerdig, wenn damit CUL und SCC3 initialisiert werden konnte, SCC2 aber nicht.
Hallo Rudolf. Danke für die Änderung.
Alle notifys sind aus.
1.)
Bei einem RECONNECT passt alles , perfekt.
2015.05.30 23:46:56 1: fhem1:2003 disconnected, waiting to reappear (SCC1)
2015.05.30 23:48:00 1: fhem1:2003 reappeared (SCC1)
2015.05.30 23:48:01 3: SCC1: Possible commands: mBbCFiAZGMYRTVWXef*ltux
2015.05.30 23:48:17 4: CUL_Parse: SCC3 b1944C41823579814010241327A5A0000A00405285A0A0002FD08E14465EC801C -60
2015.05.30 23:48:17 5: SCC3 dispatch b1944C41823579814010241327A5A0000A00405285A0A0002FD08E14465EC80::-60
2015.05.30 23:48:17 5: WMBUS raw msg b1944C41823579814010241327A5A0000A00405285A0A0002FD08E14465EC80::-60
2.)
Wenn allerdings beim Start von FHEM der Remote-ser2net Raspi nicht erreichbar ist und erst danach gestartet wird, dann wird nur SCC1 initialisiert. SCC2 und SCC3 empfangen nichts.
Wenn z.B beim Max (SCC2) die Temperatur eines Thermostates geändert wird, erscheint das im Log.
2015.05.31 00:08:11 1: CUL_MAX_Check: No IODev has no VERSION
2015.05.31 00:08:12 1: CUL_MAX_Parse: len mismatch
2015.05.31 00:08:17 1: CUL_MAX_Check: No IODev has no VERSION
2015.05.31 00:08:18 1: CUL_MAX_Parse: len mismatch
2015.05.31 00:08:24 1: CUL_MAX_Check: No IODev has no VERSION
2015.05.31 00:08:25 1: CUL_MAX_Parse: len mismatch
2015.05.31 00:08:30 1: CUL_MAX_Check: No IODev has no VERSION
2015.05.31 00:08:31 1: CUL_MAX_Parse: len mismatch
2015.05.31 00:08:34 2: CUL_MAX_SendQueueHandler: Missing ack from 0d739a for 0b3300401234560d739a0070
2015.05.31 00:09:59 1: CUL_MAX_Parse: len mismatch
WMBUS-SCC3 bekommt gar keine Daten.
Nach einem shutdown restart geht es wieder.
3.) Wenn nur FHEM am Hauptserve runtergefahren wird und neu gestartet wird erscheinen immer noch die Fehler mit dem unknown message und SCC2 sowie SCC3 stehen zwar auf Initialzed, empfangen aber nichts.
Abhilfe schafft nur ein
service ser2net stop
#!/bin/sh
echo Enable busware gpio scc
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
service ser2net start
Nach dem Reappear von SCC1 geht nur SCC1, die anderen empfangen weiterhin nichts.
Ein shutdown restart in Fhem bringt den gewünschten Erfolg.
Gruss
2015.05.31 00:23:17 5: SCC3 dispatch Z1DD6EDDFB72FEF395B3F3F33E9F7F36F7DDE7CBDEEFB63F4EDFE7F9DFCFF
2015.05.31 00:23:17 3: SCC3: Unknown code Z1DD6EDDFB72FEF395B3F3F33E9F7F36F7DDE7CBDEEFB63F4EDFE7F9DFCFF, help me!
2015.05.31 00:23:17 3: SCC2: Unknown code 812504xx0101a0015cfda800b9cdfdbd66ff4a2c77ff7f957bf74e9def6edffb9f7cff9e00f76, help me!
2015.05.31 00:23:17 3: SCC2: Unknown code AE72EF5743E2FEA5FEB6D5A47D77B95EEFE1B4EFF5DC1726F3C4FDF92::-112.5:SCC2, help me!
2015.05.31 00:23:18 4: CUL_Parse: SCC3 Z1DB3449FFAE72EF5743E2FEA5FEB6D5A47D77B95EEFE1B4EFF5DC1726F3C4F -34.5
2015.05.31 00:23:18 5: SCC3 dispatch Z1DB3449FFAE72EF5743E2FEA5FEB6D5A47D77B95EEFE1B4EFF5DC1726F3C
2015.05.31 00:23:18 3: SCC3: Unknown code Z1DB3449FFAE72EF5743E2FEA5FEB6D5A47D77B95EEFE1B4EFF5DC1726F3C, help me!
2015.05.31 00:23:18 2: SCC2: unknown message B3EBDA7FDBEFEAAFBDFB79E1E3CFBFDFCD9FBF
2015.05.31 00:23:18 2: SCC2: unknown message 1D7F7F1FF757FF73FE4ED9DEAB796DAFD0F6FE2965F7E376F187F897BBA64F
Statt "shutdown restart" muesste auch ein "set SCC1 reopen" reichen. Kannst du das bitte testen?
Und die Problemfaelle bitte mit "attr global verbose 5" protokollieren.
Hallo,
gibt es hier was neues?
Bekomme auch nur scc1 wieder zum laufen mit set SCC1 reopen. SCC2 nicht.
Danke
reopen ist nur fuer das "unterste" SCC implementiert.
Das wiederum sollte als "CUL" definiert sein.
Also,
SCC1 868 Max!
SCC2 433Mhz SlowRF
aber wie bekomme ich scc2 wieder zum laufen?
Hallo.
Nachdem es bei mir einstweilen mit einen NOTIFY läuft, habe ich es so gelassen.
Internals:
DEF SCC1:CONNECTED attr SCC1 rfmode SlowRF ; attr SCC2 rfmode SlowRF ; attr SCC2 rfmode MAX ; attr SCC3 rfmode SlowRF ; attr SCC3 rfmode WMBus_T
NAME CUL_Connect_notify
NOTIFYDEV SCC1
NR 455
NTFY_ORDER 50-CUL_Connect_notify
REGEXP SCC1:CONNECTED
STATE 2015-09-29 11:07:46
TYPE notify
Readings:
2015-09-29 11:07:33 state active
Attributes:
disable 0
room CUL
Also:
define CUL_Connect_notify notify SCC1:CONNECTED attr SCC1 rfmode SlowRF ; attr SCC2 rfmode SlowRF ; attr SCC2 rfmode MAX
Der Workaround-Trick funktioniert meines Wissens so.
Den RFMODE auf einen anderen Modus umstellen und dann wieder zurück.
Wenn das deine Konstellation ist:
SCC1 868 Max!
SCC2 433Mhz SlowRF
define CUL_Connect_notify notify SCC1:CONNECTED attr SCC1 rfmode SlowRF ; attr SCC1 rfmode MAX ; attr SCC2 rfmode MAX ; attr SCC2 rfmode SlowRF
Danke
define CUL_Connect_notify notify SCC1:CONNECTED attr SCC1 rfmode SlowRF ;; attr SCC1 rfmode MAX ;; attr SCC2 rfmode MAX ;; attr SCC2 rfmode SlowRF
so geht es. Werde es mal testen.
Hallo,
ich habe einen CUL am RPi, (CUL_1), den anderen an einem anderen RPi (CUL_2) über ser2net angebunden.
Wenn der zweite aktiv ist bekomme ich ständige disconnects am CUL_1 :
2015.10.20 23:00:12 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_1)
2015.10.20 23:00:15 3: Setting CUL_1 serial parameters to 9600,8,N,1
2015.10.20 23:00:15 1: /dev/ttyACM0 reappeared (CUL_1)
2015.10.20 23:00:15 3: CUL_1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.10.20 23:00:41 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_1)
2015.10.20 23:00:41 3: Setting CUL_1 serial parameters to 9600,8,N,1
2015.10.20 23:00:41 1: /dev/ttyACM0 reappeared (CUL_1)
2015.10.20 23:00:42 3: CUL_1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.10.20 23:00:59 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_1)
2015.10.20 23:01:01 3: Setting CUL_1 serial parameters to 9600,8,N,1
2015.10.20 23:01:01 1: /dev/ttyACM0 reappeared (CUL_1)
2015.10.20 23:01:01 3: CUL_1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.10.20 23:01:14 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_1)
2015.10.20 23:01:16 3: Setting CUL_1 serial parameters to 9600,8,N,1
2015.10.20 23:01:16 1: /dev/ttyACM0 reappeared (CUL_1)
2015.10.20 23:01:16 3: CUL_1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.10.20 23:01:22 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_1)
2015.10.20 23:01:23 3: Setting CUL_1 serial parameters to 9600,8,N,1
2015.10.20 23:01:23 1: /dev/ttyACM0 reappeared (CUL_1)
2015.10.20 23:01:23 3: CUL_1: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
und so gehts immer weiter...
Wenn ich den CUL_2 aus der fhem.cfg auskommentiere ist mit CUL_1 alles gut.
In der ser2net.cfg auf dem zweiten RPi steht:
50123:raw:0:/dev/ttyACM0:9600 8DATABITS NONE 1STOPBIT
Wo kann das Problem liegen?
Zitat von: Syntaxterror am 20 Oktober 2015, 23:21:56
2015.10.20 23:01:23 1: /dev/ttyACM0 reappeared (CUL_1)
Wenn ich den CUL_2 aus der fhem.cfg auskommentiere ist mit CUL_1 alles gut.
In der ser2net.cfg auf dem zweiten RPi steht:
50123:raw:0:/dev/ttyACM0:9600 8DATABITS NONE 1STOPBIT
Wo kann das Problem liegen?
Bei mir ist in der ser2net (Busware SCC) folgendes.
2003:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITS Poste doch mal die CFGs deiner beiden CUL's in Fhem.
sieht so aus:
define CUL_1 CUL /dev/ttyACM0@9600 4567
attr CUL_1 hmId 345678
attr CUL_1 model CUL
attr CUL_1 rfmode HomeMatic
define CUL_2 CUL /dev/ttyACM0@9600:50123 0000
attr CUL_2 hmId 345678
attr CUL_2 model CUL
attr CUL_2 rfmode HomeMatic
######################################################
# vCCU
#######################################################
define vCCU1 CUL_HM 345678
attr vCCU1 IOList CUL_1,CUL_2
attr vCCU1 expert 2_full
attr vCCU1 model CCU-FHEM
attr vCCU1 room CUL_HM,System
attr vCCU1 subType virtual
attr vCCU1 webCmd virtual:update
Was genau wird mit
Zitatdefine CUL_2 CUL /dev/ttyACM0@9600:50123 0000
beabsichtigt?
Das ist der CUL am USB-Anschluss vom entfernten RPi.
Der wird auch korrekt initialisiert und da gibts auch keinen disconnect, aber solange der existiert disconnectet CUL_1 am Haupt-RPi.
Und woraus soll FHEM die Adresse des entfernten Rechners ableiten?
Oder im Klartext: FHEM spricht mit beiden Definitionen das gleiche lokale Geraet (/dev/ttyACM0) an, was natuerlich zu Problemen fuehrt. Korrekt waere sowas wie:
define CUL_2 CUL RemoteRPi:50123 0000
Klar, danke, das war's, jetzt gehts! :)