mapleCUN WMBUS_T stellt nach FHEM restart den Empfang ein

[carpenoctem]

Moin,

ich habe mir das mal angesehen, und zumindest zum Max! (Moritz Betrieb) einen Unterschied festgestellt.

In der rf_mbus.c:

Code Auswählen Erweitern

void rf_mbus_func(char *in) {
  if((in[1] == 'r') && in[2]) {     // Reception on
#ifdef USE_RF_MODE
    if(in[2] == 's') {
      set_RF_mode(RF_mode_WMBUS_S);
    } else if(in[2] == 't') {
      set_RF_mode(RF_mode_WMBUS_T);
    } else {                        // Off
      set_RF_mode(RF_mode_off);
    }
.
.
.

  mbus_status();
}

und in mbus_status():

Code Auswählen Erweitern

static void mbus_status(void) {
  if (radio_mode == RADIO_MODE_RX ) {
    switch (mbus_mode) {
    case WMBUS_SMODE:
      MULTICC_PREFIX();
      DS_P(PSTR("SMODE"));
      break;
    case WMBUS_TMODE:
      MULTICC_PREFIX();
      DS_P(PSTR("TMODE"));
      break;
    default:
      MULTICC_PREFIX();
      DS_P(PSTR("OFF"));
    }
  }
  else {
    MULTICC_PREFIX();
    DS_P(PSTR("OFF"));
  }
  DNL();
}

wird das TMODE geschickt.

In der rf_moritz.c  wird am ende der moritz_func kein "status" aufgerufen, wie es bei der rf_mbus.c der Fall ist. Somit wird auch keine weitere Nachricht geschickt.

Was jetzt das richtige Verhalten ist, oder auf welcher Seite es gelöst wird, muss man sich mal ansehen. Dafür stecke ich nicht genug drin wer sich hier nicht Ordnungsgemäß verhält.

Grüße

[rudolfkoenig]

Die WMBUS-Initialisierung mit brt produziert eine Ausgabe, diese wird aber vom Initialisierungscode nicht gelesen.
Das fuehrt zu falschen Log-Meldungen, und sinnloses Setzen der FHTID.
Fixen kann man es entweder in CUL.pm (Antwort lesen), oder in culfw (keine Ausgabe produzieren).

Mir ist aber noch nicht klar, wieso es zum Einstellen des WMBUS-Betriebes fuehrt.