mapleCUN WMBUS_T stellt nach FHEM restart den Empfang ein

Begonnen von arthur_dent_2015, 17 Februar 2018, 13:10:35

Vorheriges Thema - Nächstes Thema

carpenoctem

Moin,

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

In der rf_mbus.c:
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():
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
RPi mit SelbstbauCUL, JeeLink und DS18B20
MAX N Basic Thermostate

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.