[HM-Wired] universelles Homebrew IO-Modul

[Ralf9]

Hallo,

ich bin gerade am programmieren eines universellen Homebrew IO-Moduls. Ich verwende dazu ein
"MEGA 2560 R3 ATMEGA Board compatible Arduino AR01002"  und ein  "Ethernet Shield w5100"
Das Modul funktioniert z.Zt. nur über Ethernet. Damit es auch über RS485 funktioniert, müssten die seriellen Routinen und Definitionen und die debug-Routinen in die HMWRS485.cpp verschoben werden.
In meiner Version erfolgt die Debugausgabe über eine zusätzliche Telnetsession.

In das Modul habe ich Sensor-, Taster- und analog Eingänge und auch Ausgänge eingebaut. Siehe Anlage.
Als Vorlage habe ich das HMW-LC-Sw2-DR aus dem git verwendet. Ein großteil fuktioniert schon.

Damit ich bei den Ein- und Ausgängen flexibel bin, habe ich einiges umprogrammiert:

Code Auswählen Erweitern


#define NUM_SENSORS 12      // Anzahl Sensoreingaenge
#define NUM_KEYS 4          // Anzahl Tastereingaenge
#define NUM_SWITCHES 4      // Schalter (Aktoren)
#define NUM_ANALOG 4        // analoge Eingänge

#define CHANNEL_START_SENSORS 0
#define CHANNEL_END_SENSORS 11
#define CHANNEL_START_KEYS 12
#define CHANNEL_END_KEYS 15
#define CHANNEL_START_SWITCHES 16
#define CHANNEL_END_SWITCHES 19
#define CHANNEL_START_ANALOG 20
#define CHANNEL_END_ANALOG 23

#define SENSOR_CHANNEL_PORTS byte sensorChannelPorts[NUM_SENSORS] = {22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33};
#define KEY_CHANNEL_PORTS byte keyChannelPorts[NUM_KEYS] = {40, 41, 42, 43};
#define SWITCH_CHANNEL_PORTS byte switchChannelPorts[NUM_SWITCHES] = {5, 6 ,7, 8};
#define ANALOG_CHANNEL_PORTS byte analogChannelPorts[NUM_ANALOG] = {A8, A9, A10, A11};



Bei der handleKeys() könnte ich Hilfe gebrauchen. Ich habe die Routine aus der HMW-LC-Sw2-DR übernommen, da ich kein Doppelklick benötige.
Ich möchte gerne die Routine, so wie ich es auch bei der handleSensors() mache, nur alle 50 millisek aufrufen, damit das Entprellen über die Abfrage der millis() nicht mehr nötig ist. Außerdem hätte ich sie gerne umschaltbar zwischen Pushbutton und Switch.
Mir ist auch nicht klar warum da steht "der Teufel ist ein Eichhoernchen"?
"lastSentLong = now ? now : 1; // der Teufel ist ein Eichhoernchen"

Code Auswählen Erweitern


// Tastenkey,  es sind 12 Tasten definiert
void handleKeys() {
  // millis() zum Zeitpunkt eines Tastendrucks
  // verwendet zum Entprellen, lange Tastendruecke und wiederholtes Senden langer Tastendruecke
  static unsigned long keyPressedMillis[12] = {0,0,0,0,0,0,0,0,0,0,0,0};
  static byte keyPressNum[12] = {0,0,0,0,0,0,0,0,0,0,0,0};
  static unsigned long lastSentLong[12] = {0,0,0,0,0,0,0,0,0,0,0,0};    // wann wurde das letzte mal "short" gesendet?
  boolean portStat;
 
  unsigned long now = millis();

  for(byte i = 0; i < NUM_KEYS; i++) {
   // INPUT_LOCKED?
   if(!config.keys[i].input_locked) continue;   // inverted logic, locked = 0
   // Taste nicht gedrueckt (negative Logik wegen INPUT_PULLUP)
   portStat = bitRead(keyPortStatus[i/8],i%8);
   if (!config.keys[i].input_inverted) {       // inverted
          portStat = !portStat; 
   }
   if (portStat) {
// Taste war auch vorher nicht gedrueckt kann ignoriert werden
     // Taste war vorher gedrueckt?
if(keyPressedMillis[i]){
   // entprellen, nur senden, wenn laenger als 50ms gedrueckt
   // aber noch kein "long" gesendet
   if(now - keyPressedMillis[i] >= 50 && !lastSentLong[i]){
     keyPressNum[i]++;
             // TODO: muss das eigentlich an die Zentrale gehen?
     hmwmodule->broadcastKeyEvent(i + CHANNEL_START_KEYS, keyPressNum[i]);
     // gleich ein Announce hinterher
             // hmwmodule->broadcastAnnounce(i);
   }
   keyPressedMillis[i] = 0;
}
   }
   else{
// Taste gedrueckt
// Taste war vorher schon gedrueckt
if(keyPressedMillis[i]){
       // muessen wir ein "long" senden?
   if(lastSentLong[i]) {   // schon ein LONG gesendet
  if(now - lastSentLong[i] >= 300){  // alle 300ms wiederholen
// keyPressNum nicht erhoehen
lastSentLong[i] = now ? now : 1; // der Teufel ist ein Eichhoernchen
// TODO: muss das eigentlich an die Zentrale gehen?
hmwmodule->broadcastKeyEvent(i + CHANNEL_START_KEYS, keyPressNum[i], true);
  }
   }
           else if (millis() - keyPressedMillis[i] >= long(config.keys[i].long_press_time * 100)) {
  // erstes LONG
  keyPressNum[i]++;
          lastSentLong[i] = millis();
  // TODO: muss das eigentlich an die Zentrale gehen?
  hmwmodule->broadcastKeyEvent(i + CHANNEL_START_KEYS,keyPressNum[i], true);
      // gleich ein Announce hinterher
  //hmwmodule->broadcastAnnounce(i);
   }
}
         else{
   // Taste war vorher nicht gedrueckt
   keyPressedMillis[i] = now ? now : 1; // der Teufel ist ein Eichhoernchen
   lastSentLong[i] = 0;
}
    }
  }
}


Und hier ist die handleSensors()

Code Auswählen Erweitern

void handleSensors() {
  static byte sensorState[2] = {0,0};
  static byte flag[12] = {0,0,0,0,0,0,0,0,0,0,0,0};
  boolean portStat = 0;
  static byte si = 0;
   
  if (si == 0) {    // init
    si = 1;
    for (byte i = 0; i < NUM_SENSORS; i++) {
      bitWrite(sensorState[i/8], i%8, bitRead(sensorPortStatus[i/8],i%8));
    }
  }
 
  for (byte i = 0; i < NUM_SENSORS; i++) {
    // INPUT_LOCKED?
    if (!config.sensors[i].input_locked) continue;         // inverted logic, locked = 0
    portStat = bitRead(sensorPortStatus[i/8], i%8);
    if (portStat != bitRead(sensorState[i/8], i%8)) {          // Flanke
      if (flag[i] == 1) {
        bitWrite(sensorState[i/8], i%8, portStat);
        if (!config.sensors[i].input_inverted) {       // inverted
          portStat = !portStat; 
        }
        if (portStat == 0) {
           hmwmodule->broadcastSensorEvent(i, 0, 0);
        } else {
           hmwmodule->broadcastSensorEvent(i, 200, 0);
        }
      }
      else {
         flag[i] = 1;
      }
    }
    else {
      flag[i] = 0;
    }
  }
}


Und hier ist die Struktur in der HMWRegister.h

Code Auswählen Erweitern

// Sensor
struct hmw_config_sensor {
byte input_locked          :1;   //     0=LOCKED, 1=UNLOCKED
        byte input_inverted        :1;   //     0=inverted 1=normal
        byte input_pullup          :1;   //                1=PULLUP
        byte                       :5;   //
};

// Taster
struct hmw_config_key {
byte input_type            :1;   //     0=SWITCH,  1=PUSHBUTTON
byte input_locked          :1;   //     0=LOCKED,  1=UNLOCKED
byte input_inverted        :1;   //     0=inverted 1=normal
        byte input_pullup          :1;   //                1=PULLUP
        byte                       :4;
byte long_press_time;            //     in sec/10
};

// Analog Eingänge
struct hmw_config_analog { 
        byte analog_factor         :7;  //      divisions faktor
        byte analog_logging        :1;   //      0=ON, 1=OFF   
        byte calibration;                //      -127 bis + 127
};

struct hmw_config {
byte logging_time;             // 0x01
long central_address;          // 0x02 - 0x05
byte direct_link_deactivate:1; // 0x06 
byte                       :7; 
     hmw_config_sensor sensors[16];    // 0x07 - 0x16
     hmw_config_key keys[16];          // 0x17 - 0x36
        byte switch_inverted;          // 0x37  Bit 0-7  0=inverted 1=normal
        byte switch_logging;           // 0x38  Bit 0-7    0=OFF, 1=ON
unsigned int analog_log_time;          // 0x39   in sec    0 und ffff = off       
     hmw_config_analog analog[8];      // 0x3b - 0x4a
};


Bei den analogen Eingängen habe ich das Problem, daß durch das zusammenfassen von   analog_factor (Bit 0-6) und  analog_logging (Bit 7)  die Konfiguration im fhem nicht funktioniert.

@honk, kann es sein, daß in der "sub convertSettingsToEepromData($$)" nicht programmiert ist, daß Teilbytewerte auch größer als 0.1 Bit sein dürfen?

Gruß Ralf

[Thorsten Pferdekaemper]

Bei der handleKeys() könnte ich Hilfe gebrauchen. Ich habe die Routine aus der HMW-LC-Sw2-DR übernommen, da ich kein Doppelklick benötige.
Ich möchte gerne die Routine, so wie ich es auch bei der handleSensors() mache, nur alle 50 millisek aufrufen, damit das Entprellen über die Abfrage der millis() nicht mehr nötig ist.

Da machst Du einen Fehler. Beim Entprellen per Software sollte man öfter aufrufen als die "Prellzeit" lang ist. Sonst bekommt das System nicht mit, wenn die Taste zwischendurch wieder auf "nicht gedrückt" geht. Natürlich ist auch das eine Sache von Wahrscheinlichkeiten. Ich versuche jedenfalls solche Sachen immer so oft wie möglich aufzurufen.

Außerdem hätte ich sie gerne umschaltbar zwischen Pushbutton und Switch.

Da würde ich für "Switch" eine komplett neue Funktion schreiben. Das ist schon ziemlich anders.

Mir ist auch nicht klar warum da steht "der Teufel ist ein Eichhoernchen"?
"lastSentLong = now ? now : 1; // der Teufel ist ein Eichhoernchen"

Das hat meine Oma immer gesagt, wenn irgendwas unwahrscheinliches, aber nicht sehr schönes passiert ist. Es bedeutet in etwa "Man sollte sich auch gegen unwahrscheinliche Gefahren wappnen.".
Ich habe da lastSentLong für zwei Sachen verwendet. Einmal, um zu wissen, ob schon ein "press_long" gesendet wurde und dann noch, wann es gesendet wurde. Wenn das Device jetzt gerade 2^32 Millisekunden läuft und ausgerechnet da ein press_long gesendet wurde, dann ist lastSentLong Null, obwohl gerade ein press_long gesendet wurde. Daher setze ich es für den Fall auf 1.

Gruß,
   Thorsten

[hglaser]

@honk, kann es sein, daß in der "sub convertSettingsToEepromData($$)" nicht programmiert ist, daß Teilbytewerte auch größer als 0.1 Bit sein dürfen?

Hallo Ralf

Verwendest Du denn meine Version? Zu der offiziellen kann ich derzeit nichts sagen, da gibts ja schon gerade bei convertSettingsToEepromData einige Unterschiede. Ich kann mir allerdings gut vorstellen, daß es nicht programmiert ist. Bei meiner ist es das jedenfalls nicht. Du könntest Dir aber "updateBits" in peeringManager.pm einmal ansehen, dort sollte es gehen. Ich wollte "updateBits" schon einmal in convertSettingsToEepromData implementieren sah aber bis jetzt keinen Bedarf.

lg Harald

[Ralf9]

Verwendest Du denn meine Version? Zu der offiziellen kann ich derzeit nichts sagen, da gibts ja schon gerade bei convertSettingsToEepromData einige Unterschiede. Ich kann mir allerdings gut vorstellen, daß es nicht programmiert ist. Bei meiner ist es das jedenfalls nicht. Du könntest Dir aber "updateBits" in peeringManager.pm einmal ansehen, dort sollte es gehen.

Hallo Harald,

Ich verwende bei meinem Testsystem z.Zt. die aktuelle Version von Thorsten, ich habe aber Deine Version auch schon getestet. Es wird aber in beiden Versionen bei Werten kleiner ein Byte die size nicht berücksichtigt.
Ich habe mir die "updateBits" mal angeschaut, dies ist mir zu komliziert.
Mir würde es reichen, wenn die size nur bei dem Adressindex von 0.0 berücksichtigt wird.

Ich habe bei Deiner Version die "sub convertSettingsToEepromData($$)" etwas abgeändert, damit müsste es funktionieren. Ich hoffe es ist so ok:

Code Auswählen Erweitern


## alt ##

if ($value) { #value=1
my $bitMask = 1 << $bit;
$value = $addressData->{$adrKey}{'value'} | $bitMask;
} else { #value=0
my $bitMask = unpack ('C', pack 'c', ~(1 << $bit));
$value = $addressData->{$adrKey}{'value'} & $bitMask;
}

## neu ##

if ($bit == 0) {    # index = 0
my $bitMask = (2 ** ($size * 10)) - 1;
$value &= $bitmask;                           # bei size 0.5 -> & 00011111
$bitmask = $bitmask ^ 255;                    # xor
$addressData->{$adrKey}{'value'} &= $bitmask; # eepromvalue, bei size 0.5 ->  & 11100000
$addressData->{$adrKey}{'value'} |= $value;
} else {
if ($value) { #value=1
my $bitMask = 1 << $bit;
$value = $addressData->{$adrKey}{'value'} | $bitMask;
} else { #value=0
my $bitMask = unpack ('C', pack 'c', ~(1 << $bit));
$value = $addressData->{$adrKey}{'value'} & $bitMask;
}
}



Ich habe mal Deine Version mit der von gevoo / Thorsten verglichen. Mir ist dabei aufgefallen, daß Du recht umfangreiche Änderungen und Vereinfachungen vorgenommen hast. Hast Du getestet ob nach Deinen Anpassungen noch alles funktioniert?
Damit meine Änderung auch bei der Version von Thorsten funktioniert, müssen einige Deiner anpassungen übernommen werden.
Es reicht nicht aus nur die "sub convertSettingsToEepromData($$)" zu übernehmen.
Aus der "Device.pm" müssen auch noch die folgenden Routinen übernommen werden. Ich hoffe ich habe nichts vergessen wo es noch Abhängigkeiten gibt.
Dies ist mir alleine zu heftig. Kannst Du es Dir mal anschauen ob man es so machen kann?

Code Auswählen Erweitern


sub getValueFromEepromData($$$$;$) {

sub dataConversion($$;$)

sub dataConvertValue ($$$)

# bei honk ist der Parameter hex dazugekommen
sub getValueFromHexData($;$$$) {
my ($data, $start, $size, $hex) = @_;


Wenn es ohne größeren Aufwand machbar ist die relevanten Anpassungen in die Version von Thorsten zu übernehmen, werde ich dafür ein neues Thema aufmachen. Es wäre schön, wenn Thorsten auch mithelfen könnte.

Gruß Ralf

[hglaser]

Ich habe bei Deiner Version die "sub convertSettingsToEepromData($$)" etwas abgeändert, damit müsste es funktionieren. Ich hoffe es ist so ok:

Ja natürlich ist das ok. obwohl ich früher oder später zwecks Vereinfachung "updateBits" übernehmen will. Dann sollte nicht nur Adressindex von 0.0 berücksichtigt werden. Wenn du mir einen pull-reqest im github machen könntest, übernehme ich es.

Mir ist dabei aufgefallen, daß Du recht umfangreiche Änderungen und Vereinfachungen vorgenommen hast. Hast Du getestet ob nach Deinen Anpassungen noch alles funktioniert?

Ja hoffentlich.

Dies ist mir alleine zu heftig. Kannst Du es Dir mal anschauen ob man es so machen kann?

Zur Zeit will ich mich eigentlich noch nicht in die Version von Thorsten einmischen. Ich habe auch derzeit kein zweites Testsystem um die aktuelle Version von Thorsten zu installieren. Da müsst ich erst mal auf meinem zweiten Raspi aufräumen

Wenn es ohne größeren Aufwand machbar ist die relevanten Anpassungen in die Version von Thorsten zu übernehmen, werde ich dafür ein neues Thema aufmachen. Es wäre schön, wenn Thorsten auch mithelfen könnte.

Wenn es nur um die vier subs geht, denke ich würde das schon machbar sein. Da gibts aber noch ein paar Sachen zu tun. z.B. die Angleichung der Xml-Device.pm Dateien. Ich habe auch diese verändert. Thorsten weiß darüber Bescheid.

lg Harald

[hglaser]

Hallo Ralf

Ich habe mir die "updateBits" mal angeschaut, dies ist mir zu komliziert.

Ich habe nun "updateBits" auch in "convertSettingsToEepromData" eingepflegt und ins dev hochgeladen, damit müsste mann dann auch andere indexe als nur Adressindex von 0.0 verwenden können. Es ist so einfach Universeller und ich kann es auch fürs peering verwenden.

Könntest Du es bitte einmal mit deinem HBW testen ?

lg Harald   

[Ralf9]

Hallo Ralf

Ich habe nun "updateBits" auch in "convertSettingsToEepromData" eingepflegt und ins dev hochgeladen, damit müsste mann dann auch andere indexe als nur Adressindex von 0.0 verwenden können. Es ist so einfach Universeller und ich kann es auch fürs peering verwenden.

Könntest Du es bitte einmal mit deinem HBW testen ?

lg Harald

Hallo Harald,

ich kann es in Deinem Git nicht finden
https://github.com/hresalg/FHEM-HM485/tree/dev/FHEM/lib/HM485

Hast Du mir mal den link?


Ich werde es in der Version von Thorsten testen, und mal versuchen ob es reicht, wenn ich die folgenden Routinen übernehme:

sub convertSettingsToEepromData(

sub getValueFromEepromData($$$$;$)

sub dataConversion($$;$)

sub dataConvertValue ($$$)

sub getValueFromHexData($;$$$)

Gruß Ralf

[hglaser]

Hallo Ralf

Ups hab glatt vergessen zu pushen. Jetzt ist es da wo Du gesucht hast

lg Harald

[Ralf9]

Hallo Harald,

sieht schon recht gut aus passt aber noch nicht ganz.

Das hier passt:

Code Auswählen Erweitern


2015.07.29 21:57:07 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = logging Wert = 1 msg =
2015.07.29 21:57:07 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = calibration Wert = -120 msg =
2015.07.29 21:57:07 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = factor Wert = 60 msg =
2015.07.29 21:57:07 3: ConfigManager:convertSettingsToEepromData:  eepromvalue = 37 value = 60 size = 0.7 adrid = 61
2015.07.29 21:57:07 3: ConfigManager:convertSettingsToEepromData:  value nach updatebit = 60
2015.07.29 21:57:07 3: ConfigManager:convertSettingsToEepromData:  eepromvalue = 60 value = 1 size = 0.1 adrid = 61.7
2015.07.29 21:57:07 3: ConfigManager:convertSettingsToEepromData:  value nach updatebit = 188
2015.07.29 21:57:07 3: HM485: Set config for HBW_IO_SW_HBW8555631_22:  factor=60 logging=1

2015.07.29 22:08:38 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = factor Wert = 5 msg =
2015.07.29 22:08:38 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = calibration Wert = 3 msg =
2015.07.29 22:08:38 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_22 Key = logging Wert = 0 msg =
2015.07.29 22:08:38 3: ConfigManager:convertSettingsToEepromData:  eepromvalue = 188 value = 0 size = 0.1 adrid = 61.7
2015.07.29 22:08:38 3: ConfigManager:convertSettingsToEepromData:  value nach updatebit = 60
2015.07.29 22:08:38 3: ConfigManager:convertSettingsToEepromData:  eepromvalue = 60 value = 5 size = 0.7 adrid = 61
2015.07.29 22:08:38 3: ConfigManager:convertSettingsToEepromData:  value nach updatebit = 5
2015.07.29 22:08:38 3: HM485: Set config for HBW_IO_SW_HBW8555631_22:  logging=0 factor=5



Hier passt es noch nicht. Der channeltyp ist switch und es ist nur ein Optionsfeld mit dem Name inverted:

Code Auswählen Erweitern


2015.07.29 21:41:24 3: HM485_SetConfig: name = HBW_IO_SW_HBW8555631_20 Key = inverted Wert = yes msg =
2015.07.29 21:41:24 3: ConfigManager:convertSettingsToEepromData:  eepromvalue = 244 value = yes size = 0.1 adrid = 55.3
2015.07.29 21:41:24 1: PERL WARNING: Argument "yes" isn't numeric in left bitshift (<<) at FHEM/lib/HM485/Device.pm line 1391.
2015.07.29 21:41:24 3: ConfigManager:convertSettingsToEepromData:  value nach bitupdate= 244
2015.07.29 21:41:24 3: HM485: Set config for HBW_IO_SW_HBW8555631_20:  inverted=yes


Hier ist der Ausschnitt vom devicefile:

Code Auswählen Erweitern


},
"peer_param" => "sensor",
"type" => "link"
},
"master" => {
"address_start" => 0x37,
"address_step" => 0.1,
"parameter" => {
"inverted" => {
"id" => "inverted",
"logical" => {
"option" => {
"yes" => {},
"no" => {
"default" => true
}
},
"type" => "option"
},
"physical" => {
"address" => {
"index" => 0
},
"interface" => "eeprom",
"size" => 0.1,
"type" => "integer"
}
}
},
"type" => "master"
},


Gruß Ralf

[hglaser]

PERL WARNING: Argument "yes" isn't numeric in left bitshift (<<) at FHEM/lib/HM485/Device.pm line 1391.

Hallo Ralf

Dieses "yes" kommt hier irgendwie Durch. Sollte ja eigentlich laut deinem devicefile "0" sein. options sind in meinen devicefiles in Arrays gepackt, keine Hashes. Versuche es einmal mit:

Code Auswählen Erweitern

"id" => "inverted",
"logical" => {
                     "option" => [
{
    "id" => "yes"
},
{
    "default" => true,
    "id" => "no"
}
    ],
"type" => "option"
},


lg Harald

[Ralf9]

Hallo Ralf

Dieses "yes" kommt hier irgendwie Durch. Sollte ja eigentlich laut deinem devicefile "0" sein. options sind in meinen devicefiles in Arrays gepackt, keine Hashes. Versuche es einmal mit:

Nein damit funktioniert es nicht. In der ConfigurationManager.pm habe ich nur die "sub convertSettingsToEepromData" in die Version von Thorsten übernommen. Deine "sub getConfigFromDevice" habe ich nicht übernommen, da ich nicht weiß ob dann die Version von Thorsten noch funktioniert, wenn ich die nicht angepassten devicefiles beibehalte.

Wenn ich in der "sub convertSettingsToEepromData" bei  " $optText = convertOptionToValue("  das $optText in $value ändere funktioniert es. Zu was wird $optText überhaupt benötigt?

Code Auswählen Erweitern


if ($configData->{$config}{'config'}{'logical'}{'type'} &&
$configData->{$config}{'config'}{'logical'}{'type'} eq 'option') {
$value = convertOptionToValue(
$configData->{$config}{'config'}{'logical'}{'option'}, $value
);
} else {
$value = HM485::Device::dataConversion(
$value, $configData->{$config}{'config'}{'conversion'}, 'to_device'
);
}



Gruß Ralf

[Thorsten Pferdekaemper]

Hi,

Es wäre schön, wenn Thorsten auch mithelfen könnte.

Ja, klar. Momentan habe ich aber einige Baustellen (nicht nur im übertragenen Sinne) und es kann etwas dauern.

Zur Zeit will ich mich eigentlich noch nicht in die Version von Thorsten einmischen.

Mach ruhig. Momentan würden wir alle Zeit sparen, wenn wir nur eine Version hätten...

Gruß,
   Thorsten

[hglaser]

Zu was wird $optText überhaupt benötigt?

Hallo

Der wird derzeit nur beim logging verwendet.

Mach ruhig. Momentan würden wir alle Zeit sparen, wenn wir nur eine Version hätten...

Ich kann mich noch nicht recht dazu durchringen. Ich wollte warten, bis das ganze ein bisschen aufgeräumter aussieht.

lg Harald

[Thorsten Pferdekaemper]

Ich kann mich noch nicht recht dazu durchringen. Ich wollte warten, bis das ganze ein bisschen aufgeräumter aussieht.

Darüber brauchst Du Dir keine Gedanken zu machen. Im Aufräumen von Coding bin ich relativ gut, glaube ich. Ich habe Dir übrigens auch eine Mail zu dem Thema geschickt.

[Thorsten Pferdekaemper]

Bei den analogen Eingängen habe ich das Problem, daß durch das zusammenfassen von   analog_factor (Bit 0-6) und  analog_logging (Bit 7)  die Konfiguration im fhem nicht funktioniert.

Hi,
bei der Zusammenführung unserer Versionen (http://forum.fhem.de/index.php/topic,39643.0.html) ist mir aufgefallen, dass in "meiner" Version zu dem Thema etwas implementiert ist. Mir ist nur nicht ganz klar, ob das nur mit einzelnen Bits oder auch mit Deinem Fall funktioniert. Hast Du das mal ausprobiert?
Gruß,
   Thorsten