Stapelbare Busware SCC mit ser2net am Raspberry PI

[pipp37]

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

Code Auswählen Erweitern

2003:raw:0:/dev/ttyAMA0:38400 NONE 1STOPBIT 8DATABITS
Weiters werden die GPIOs wie folgt am RPI initalisiert.

Code Auswählen Erweitern


#!/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.

Code Auswählen Erweitern


#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:

Code Auswählen Erweitern

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



[rudolfkoenig]

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.

[pipp37]

Hallo Rudolf.
Vielen Dank für deine rasche und kompetente Hilfe.
So geht es einstweilen, perfekt.


list CUL_Connect_notify

Code Auswählen Erweitern


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.

Code Auswählen Erweitern

#!/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.

Code Auswählen Erweitern

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'

Code Auswählen Erweitern


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.

[pipp37]

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.

Code Auswählen Erweitern

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


[rudolfkoenig]

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.

[pipp37]

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.

[rudolfkoenig]

define nReopen notify global:INITIALIZED sleep 60;; set SCC1 reopen

[pipp37]

Perfekt, Danke so gehts. Da hätte ich auch selbst drauf kommen können.
Ich habe das in mein Startup eingebunden.

list setStartup

Code Auswählen Erweitern


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.

Code Auswählen Erweitern

==> /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.

Code Auswählen Erweitern


==> /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

Code Auswählen Erweitern


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

[rudolfkoenig]

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.

[pipp37]

Hallo Rudolf. Danke für die Änderung.

Alle notifys sind aus.

1.)
Bei einem RECONNECT passt alles , perfekt.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern


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

Code Auswählen Erweitern

service ser2net stop

Code Auswählen Erweitern

#!/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

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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


[rudolfkoenig]

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.

[QuesT]

Hallo,

gibt es hier was neues?
Bekomme auch nur scc1 wieder zum laufen mit set SCC1 reopen. SCC2 nicht.

Danke

[rudolfkoenig]

reopen ist nur fuer das "unterste" SCC implementiert.
Das wiederum sollte als "CUL" definiert sein.

[QuesT]

Also,

SCC1 868 Max!
SCC2 433Mhz SlowRF
aber wie bekomme ich scc2 wieder zum laufen?

[pipp37]

Hallo.
Nachdem es bei mir einstweilen mit einen NOTIFY läuft, habe ich es so gelassen.

Code Auswählen Erweitern


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