Homematic Wired - Homebrew Devices

Begonnen von Thorsten Pferdekaemper, 27 April 2014, 00:13:17

Vorheriges Thema - Nächstes Thema

loetmeister

Zitat von: aperoap am 12 August 2019, 21:54:33
Irgendwie will HBW-SC-10-Dim-6 bei mir nicht laufen. Wird zwar von FHEM erkannt aber passiert nichts wenn die Pins gegen gnd geschaltet werdn. Eine Idee?
Gegen GND schalten ist gut... passt deine Pin Zuordnung? Der erste KEY Kanal ist Nr. 17 an Pin 7 im "DEBUG" modus, mit #define USE_HARDWARE_SERIAL aber Pin 12.... :)
Wie hast du denn den "KEY" Kanal konfiguriert? Ich glaube PUSHBUTTON ist die Standard Einstellung. Ändert sich der "SENSOR" Kanal? (Diese müssen aber mit FHEM abgefragt werden.)
Siehst du was im Seriellen Monitor von der Arduino IDE? Mit "#define DEBUG_OUTPUT" in HBWKey.h gibt es ein paar mehr Details.

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: loetmeister am 12 August 2019, 18:25:28
Der Fall, denn du beschrieben hast, wäre z.B. 1 sensor Kanal auf Device A - verknüpft mit 2 oder mehreren aktor Kanälen auf Device B?
Genau.

Zitat
Würde die CCU die peerings so in die Homebrew geräte schreiben? Also im sensor einen peering Eintrag, im aktor zwei oder mehr, mit dem Zielkanal?
Nein, ich glaube nicht, dass die CCU das so macht. Ich habe zwar keine CCU, aber es würde mich wundern. Ich denke eher, dass das im Sensor-Device beim Tastendruck erledigt wird. D.h. auch wenn es mehrere Peerings zu einem Device gibt, wird nur eine Nachricht geschickt.

Zitat
Müsste das nicht sogar schon jetzt funktionieren? (wenn FHEM das EEPROM so beschreiben würde?)
Im Prinzip schon, aber nur, wenn das Aktor-Device ein Original-eq3-Teil ist. Bei HBW prüfen wir ja, ob der Empfänger-Kanal richtig gesetzt wurde, oder?
Allerdings wird es beim Löschen eines Peerings schwierig. Woher soll das Sensor-Device wissen, dass man nur einen der zwei "Endpunkte" rauswerfen will. Theoretisch könnte man das irgendwie in FHEM erledigen, aber momentan würde sowas von Sensor-Seite aus wahrscheinlich "falsch" angezeigt werden.

Zitat
In vorangegangenen Fall war die Situation aber ein Sensor (Key) soll mehrere Aktoren (angenommen 1 Kanal pro Aktor) schalten. D.h. es sind unterschiedliche Adressen/Devices an den die Key Nachricht gesendet werden muss.
Ich meinte das ja auch gar nicht als komplette Lösung des Problems. Ich hatte mir nur überlegt, wie man die Anzahl der Nachrichten ggf. reduzieren kann. Ansonsten muss man ja jedesmal auf ein ACK warten, was dann in der Summe dazu führen kann, dass der ganze Vorgang ein paar Sekunden dauert. Das wäre natürlich sehr lästig. Wenn man dann wenigstens alle Kanäle eines Device zusammenfassen könnte, dann wäre schon viel geholfen.

Gruß,
    Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: aperoap am 12 August 2019, 21:54:33Somit wäre die arduino Lösung mit homebrew viel besser auch wenn es mir viel Zeit kosten würde.
Na dann, wenn Du Zeit hast, dann geh mal das Homebrew-Tutorial durch und baue den HMW-Sen-SC-12-DR/FM nach.
Gruß,
   Thorsten
FUIP

loetmeister

#573
Zitat von: Thorsten Pferdekaemper am 13 August 2019, 10:46:55
Ich denke eher, dass das im Sensor-Device beim Tastendruck erledigt wird. D.h. auch wenn es mehrere Peerings zu einem Device gibt, wird nur eine Nachricht geschickt.
[...] Bei HBW prüfen wir ja, ob der Empfänger-Kanal richtig gesetzt wurde, oder?
Ja, es müssen Senderadresse, Senderkanal und Zielkanal übereinstimmen, sonst wird das peering im Aktor nicht angewendet.

Hätte denn diese KeyEvent Nachricht, die mehrere Kanäle im Aktor schaltet auch mehrere Kanalnummern im Frame? Der Aktor kann ja nicht einfach den Ziel- oder Quellkanal ignorieren und nur auf die Quelladresse schauen...

Leicht erweitertes Setup:
Sensor A ch 1 -> Aktor B ch 1 (short action, toggle)
Sensor A ch 1 -> Aktor B ch 2 (short action, toggle)
Sensor A ch 2 -> Aktor B ch 1 (short action, on)

Aktor B sollte ja nur die ersten beiden peering Aktionen bei einem 'short' KeyEvent von Sensor A ch 1 ausführen... bin mir nicht sicher wie das gehen könnte.. :)


Zitat
Ich meinte das ja auch gar nicht als komplette Lösung des Problems. Ich hatte mir nur überlegt, wie man die Anzahl der Nachrichten ggf. reduzieren kann. Ansonsten muss man ja jedesmal auf ein ACK warten, was dann in der Summe dazu führen kann, dass der ganze Vorgang ein paar Sekunden dauert. Das wäre natürlich sehr lästig. Wenn man dann wenigstens alle Kanäle eines Device zusammenfassen könnte, dann wäre schon viel geholfen.
Stimmt, mit nur drei peerings ist schon eine leichte Verzögerung sichtbar. Wäre gut weniger auf die Leitung zu schicken.


PS: Hab mal ein bisschen in den XML geschaut, bzgl. den Key Events... "KEY_SIM_*" hat im Frame receiver_channel_field="11" (id="KEY_SIM_SHORT" direction="from_device" type="#K" channel_field="10" receiver_channel_field="11")
Im "normalen" Key Event ist das nicht vorhanden, d.h. HBW nutzt immer "KEY_SIM_*"? (da die Zielkanalnummer mit geschickt wird)
id="KEY_EVENT_SHORT" direction="from_device" event="true" type="#K" channel_field="10"
Ich hatte bisher nur gesehen das beim KeyEvent an die Broadcast Adresse Kanal 0 genutzt wird...

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: loetmeister am 13 August 2019, 22:44:26
Hätte denn diese KeyEvent Nachricht, die mehrere Kanäle im Aktor schaltet auch mehrere Kanalnummern im Frame? Der Aktor kann ja nicht einfach den Ziel- oder Quellkanal ignorieren und nur auf die Quelladresse schauen...
Nein, es gibt nicht mehrere Kanalnummern im Frame. Der Aktor ignoriert nur den Ziel-Kanal, der Quell-Kanal wird aber beachtet.

Zitat
Leicht erweitertes Setup:
Sensor A ch 1 -> Aktor B ch 1 (short action, toggle)
Sensor A ch 1 -> Aktor B ch 2 (short action, toggle)
Sensor A ch 2 -> Aktor B ch 1 (short action, on)
Aktor B sollte ja nur die ersten beiden peering Aktionen bei einem 'short' KeyEvent von Sensor A ch 1 ausführen... bin mir nicht sicher wie das gehen könnte.. :)
Es geht, indem das Ziel-Device nur die Peerings mit Quell-Kanal 1 beachtet. Im Aktor ist in den Links sowohl die Quell-Adresse als auch der Quell-Kanal gespeichert. So weiß der Aktor, dass in diesem Fall nur die ersten beiden Peerings in Frage kommen.

Zitat
PS: Hab mal ein bisschen in den XML geschaut, bzgl. den Key Events... "KEY_SIM_*" hat im Frame receiver_channel_field="11" (id="KEY_SIM_SHORT" direction="from_device" type="#K" channel_field="10" receiver_channel_field="11")
Im "normalen" Key Event ist das nicht vorhanden, d.h. HBW nutzt immer "KEY_SIM_*"? (da die Zielkanalnummer mit geschickt wird)
id="KEY_EVENT_SHORT" direction="from_device" event="true" type="#K" channel_field="10"
Die Devices nutzen die "normalen" Key-Events und schicken einen Target-Kanal mit, auch wenn das nicht im XML steht. (Wenn man von eq3-Standard-Devices ausgeht, dann müssten sie das nicht einmal tun.) Soweit ich das verstehe, sind die XMLs ja vor Allem für die Zentrale gedacht. Die Devices selbst werten das XML ja nicht aus. Außerdem reagieren die Geräte auf einen KEY_SIM-Event genauso wie auf einen "normalen".
Man kann KEY_SIM-Events und normale Events auch nur daran unterscheiden, dass normale das zweite Bit im "Event"-Byte gesetzt haben. KEY_SIM-Events sollten auch nur von der Zentrale geschickt werden (also einer CCU oder eben FHEM), um einen Tastendruck zu "simulieren". Wahrscheinlich müssen KEY_SIM- und normale Events nur deshalb unterschiedlich sein, weil sonst ein KEY_SIM-Event vom Empfänger fälschlicherweise als Wiederholung eines normalen Events missverstanden werden kann.

Gruß,
  Thorsten
FUIP

aperoap

Zitat von: loetmeister am 12 August 2019, 23:19:40
Gegen GND schalten ist gut... passt deine Pin Zuordnung? Der erste KEY Kanal ist Nr. 17 an Pin 7 im "DEBUG" modus, mit #define USE_HARDWARE_SERIAL aber Pin 12.... :)
Wie hast du denn den "KEY" Kanal konfiguriert? Ich glaube PUSHBUTTON ist die Standard Einstellung. Ändert sich der "SENSOR" Kanal? (Diese müssen aber mit FHEM abgefragt werden.)
Siehst du was im Seriellen Monitor von der Arduino IDE? Mit "#define DEBUG_OUTPUT" in HBWKey.h gibt es ein paar mehr Details.

Gruß,
Thomas

ich wusste nicht, dass ich den Zustand von Sensoren aktiv mit fhem abfragen soll. Mit der abfrage funktioniert das schon, wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet? Der Tutorial hat mich da nicht weiter (wenn ich nichts übersehen habe :))

Gruß

loetmeister

Zitat von: aperoap am 14 August 2019, 19:55:28
ich wusste nicht, dass ich den Zustand von Sensoren aktiv mit fhem abfragen soll. Mit der abfrage funktioniert das schon, wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet?

Hi,

du testest noch mit HBW-SC-10-Dim-6? Oder hast du HMW-Sen-SC-12-DR schon nachgebaut?  ;D

Hab grad noch mal selber kurz getestet.... bei den "Sensor" Kanälen hatte ich die "notify" Nachricht standardmäßig deaktiviert. Da musst du per FHEM in die Kanalkonfiguration gehen und "NOTIFY" aktivieren. Dann sieht man in FHEM auch die Änderung, ohne es Abfragen zu müssen.
Die "Key" Kanäle sind aber standardmäßig aktiv. Sie sollten sich wie normale Taster verhalten. Umschalten auf DOORSENSOR geht auch hier in der Kanalkonfiguration.

Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: aperoap am 14 August 2019, 19:55:28wie bekomme ich das hin, dass der Arduino bei eine Zustandsänderung bei Sensoren per rs485 automatisch sendet? Der Tutorial hat mich da nicht weiter (wenn ich nichts übersehen habe :))
Im Prinzip müsstest Du das aus dem letzten Post herauslesen können (https://forum.fhem.de/index.php/topic,61780.msg560544.html#msg560544). Du bastelst Dir eine eigene Kanal-Implementierung (wie DimmerChannel) und schickst per sendInfoMessage in der Methode loop den aktuellen Status raus, wenn sich was geändert hat.
Gruß,
   Thorsten
FUIP

aperoap

Werde es mir mal am Wochenende intensiv anschauen.
HMW-Sen-SC-12-DR Habe ich noch nicht ausprobiert, werde es auch am Wochenende bzw. am Sonntag machen.  ;)
Danke und Lg

aperoap

guten Abend zusammen,

habe mir seit gestern Zeit genommen, habe versucht mit Hilfe von Thorstens Tutorial und HBW_SC_10_Dim_6 ein HMW-Sen-SC-12-DR nachzubauen.
Bin jedoch langsam am verzweifeln. Habe vielen Ausprobiert. Endergebnis ist Folgendens
FHEM erkennt das xml Datei wandelt um in das benötigte pm.
Arduino nano Wird von FHEM erkannt, die 12 Sensor Inputs werden in FHEM generiert, es funktioniert jedoch nur ein Sensor und zwar der Letzter :)
hab anfänglich gedacht, dass das chanal Array nicht funktioniert und habe alles manuell eingetragen - ohne erfolg :(

anbei mein Sketch
#define HARDWARE_VERSION 0x01
#define FIRMWARE_VERSION 0x0004

//#define NUMBER_OF_INPUT_CHAN 0 //10   // input channel - pushbutton, key, other digital in
#define NUMBER_OF_SEN_INPUT_CHAN 12  // equal number of sensor channels, using same ports/IOs as INPUT_CHAN
//#define NUMBER_OF_DIM_CHAN 6  // PWM & analog output channels
//#define NUMBER_OF_VIRTUAL_INPUT_CHAN 6


#define HMW_DEVICETYPE 0x97 //device ID (make sure to import hbw_io-10_dim-6.xml into FHEM)

//#define USE_HARDWARE_SERIAL   // use hardware serial (USART) - this disables debug output


#include "FreeRam.h"

// HB Wired protocol and module
#include <HBWired.h>
#include <HBWLinkKey.h>
#include <HBWSenSC.h>


// Pins

  #define RS485_RXD 4
  #define RS485_TXD 2
  #define RS485_TXEN 3  // Transmit-Enable
  #define BUTTON 8  // Button fuer Factory-Reset etc.
  #define ADC_BUS_VOLTAGE A7  // analog input to measure bus voltage

 
  #define IO1 A3
  #define IO2 10
  #define IO3 11
  #define IO4 A0
  #define IO5 A1
  #define IO6 A2
  #define IO7 A4
  #define IO8 A5
  #define IO9 9  // dummy pin to fill the array elements
  #define IO10 7  // dummy pin to fill the array elements
  #define IO11 6
  #define IO12 5
 
  #include "HBWSoftwareSerial.h"
  // HBWSoftwareSerial can only do 19200 baud
  HBWSoftwareSerial rs485(RS485_RXD, RS485_TXD); // RX, TX


#define LED LED_BUILTIN        // Signal-LED




struct hbw_config {
  uint8_t logging_time;     // 0x01
  uint32_t central_address;  // 0x02 - 0x05
  uint8_t direct_link_deactivate:1;   // 0x06:0
  uint8_t              :7;   // 0x06:1-7
   hbw_config_senSC senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x13 - 0x1C (address step 1)
} hbwconfig;


HBWChannel* channels[NUMBER_OF_SEN_INPUT_CHAN];  // total number of channels for the device


class HBDimIODevice : public HBWDevice {
    public:
    HBDimIODevice(uint8_t _devicetype, uint8_t _hardware_version, uint16_t _firmware_version,
               Stream* _rs485, uint8_t _txen,
               uint8_t _configSize, void* _config,
               uint8_t _numChannels, HBWChannel** _channels,
               Stream* _debugstream, HBWLinkSender* linksender = NULL, HBWLinkReceiver* linkreceiver = NULL) :
    HBWDevice(_devicetype, _hardware_version, _firmware_version,
              _rs485, _txen, _configSize, _config, _numChannels, ((HBWChannel**)(_channels)),
              _debugstream, linksender, linkreceiver) {
    };
    //virtual void afterReadConfig();
};


HBDimIODevice* device = NULL;



void setup()
{




  byte digitalInput[12] = {IO1, IO2, IO3, IO4, IO5, IO6, IO7, IO8, IO9, IO10, IO11, IO12};  // assing pins
 
  for(uint8_t i = 0; i < NUMBER_OF_SEN_INPUT_CHAN; i++) {
   channels[i] = new HBWSenSC(digitalInput[i], &(hbwconfig.senCfg[i]));
  }


  Serial.begin(19200);
  rs485.begin();    // RS485 via SoftwareSerial
 
   
   
  device = new HBDimIODevice(HMW_DEVICETYPE, HARDWARE_VERSION, FIRMWARE_VERSION,
                             &rs485, RS485_TXEN, sizeof(hbwconfig), &hbwconfig,
                             NUMBER_OF_SEN_INPUT_CHAN, (HBWChannel**)channels,
                             &Serial, NULL, NULL);
 
  device->setConfigPins(BUTTON, LED);  // 8 (button) and 13 (led) is the default
  device->setStatusLEDPins(LED, LED); // Tx, Rx LEDs

  hbwdebug(F("B: 2A "));
  hbwdebug(freeRam());
  hbwdebug(F("\n"));
 

}


void loop()
{
  device->loop();
};


mein XML Datei

<?xml version="1.0"?>
<device eep_size="1024" version="14">
<supported_types>
<type priority="2" id="HBW-Sen-Win-12" name="RS485 6-channel master dimming actuator and 10 Digital inputs">
<parameter const_value="0x97" size="1" index="0"/><!--HMW_DEVICETYPE-->
<parameter const_value="1" size="1" index="1"/><!--HARDWARE_VERSION-->
<parameter const_value="0x0004" size="2" cond_op="GE" index="2"/><!--Min. FIRMWARE_VERSION-->
</type>
</supported_types>

<paramset id="HBW-Sen-Win-12_dev_master" type="MASTER">
<parameter id="LOGGING_TIME">
<logical type="float" unit="s" default="5.0" max="25.5" min="0.1"/>
<physical size="1.0" type="integer" interface="eeprom">
<address index="0x0001"/>
</physical>
<conversion type="float_integer_scale" offset="0.0" factor="10"/>
</parameter>
<parameter id="CENTRAL_ADDRESS" hidden="true">
<logical type="integer"/>
<physical size="4" type="integer" interface="eeprom">
<address index="0x0002"/>
</physical>
</parameter>
<parameter id="DIRECT_LINK_DEACTIVATE" hidden="true">
<logical type="boolean" default="false"/>
<physical interface="eeprom" size="0.1" type="integer">
<address index="0x0006"/>
</physical>
</parameter>
<enforce id="CENTRAL_ADDRESS" value="1"/>
<enforce id="DIRECT_LINK_DEACTIVATE" value="true"/>
</paramset>

<frames>
<frame id="LEVEL_SET" type="#x" channel_field="10" direction="to_device">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
</frame>
<frame id="LEVEL_GET" type="#S" channel_field="10" direction="to_device"/>
<frame id="INFO_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="LEVEL"/>
<parameter size="0.3" index="12.4" type="integer" param="STATE_FLAGS"/>
</frame>
<frame id="STATE_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="STATE"/>
</frame>
<frame id="KEY_EVENT_SHORT" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_EVENT_LONG" type="#K" channel_field="10" direction="from_device" event="true">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_SHORT" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="0" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="KEY_SIM_LONG" type="#K" channel_field="10" direction="from_device" receiver_channel_field="11">
<parameter const_value="1" size="0.1" index="12.0" type="integer"/>
<parameter size="0.6" index="12.2" type="integer" param="COUNTER"/>
</frame>
<frame id="SET_LOCK" type="#l" channel_field="11" direction="to_device">
<parameter param="inhibit" size="1.0" index="12.0" type="integer"/>
</frame>
<frame id="TOGGLE_INSTALL_TEST" type="#x" channel_field="10" direction="to_device">
<parameter param="toggle_flag" size="1.0" index="11.0" type="integer"/>
</frame>
</frames>

<channels>
<channel index="0" type="MAINTENANCE" count="1" class="maintenance" ui_flags="internal">

</channel>



<channel index="1" physical_index_offset="-1" count="12" type="SENSOR"> <!-- input sensor contact chan -->
<paramset type="MASTER" id="hmw_sensor_ch_master" address_start="0x13" address_step="1">
    <parameter id="INPUT_LOCKED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.0"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="INVERTED">
<logical type="boolean" default="false"/>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.1"/>
</physical>
<conversion type="boolean_integer" invert="true"/>
</parameter>
<parameter id="NOTIFY">
<logical type="option">
<option id="ON"/>
<option id="OFF" default="true"/>
</logical>
<physical size="0.1" type="integer" interface="eeprom">
<address index="+0.2"/>
</physical>
</parameter>
</paramset>

<paramset type="VALUES" id="hmw_sensor_ch_values">
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean"/>
<physical type="integer" interface="command" value_id="STATE">
<event frame="STATE_LEVEL" auth_violate_policy="reject"/>
<get request="LEVEL_GET" response="STATE_LEVEL"/>
</physical>
</parameter>
<parameter id="INSTALL_TEST" operations="event" ui_flags="internal">
<logical type="action"/>
<physical type="integer" interface="command" value_id="TEST_COUNTER">
<event frame="STATE_LEVEL"/>
</physical>
</parameter>
</paramset>
</channel>



</channels>
</device>


natürlich kann mann die <frames> noch kürzen, werde das machen Sobald die Sensoren funktionieren :)

kann mir jemand von euch Profis ein Tipp geben wo mein Fehler ist, bzw was ich übersehen habe?

Gruß

Ralf9

ZitatArduino nano Wird von FHEM erkannt, die 12 Sensor Inputs werden in FHEM generiert, es funktioniert jedoch nur ein Sensor und zwar der Letzter

Interessant wäre der log vom HM485d Dämon. Bei jeder änderung open/close müsste da ungefähr folgendes im log stehen:
2019.08.18 19:34:20.271 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42ABFFEE -> 00000001 [6] 69(i) 00C800 {EC7C}
Dabei ist bei 00C800 das Hexbyte am Anfang der Kanal - 1 (00 ist Kanal 1 und 0B ist Kanal 12) 
und das zweite Hexbyte der Zutand open oder close

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

aperoap

Zitat von: Ralf9 am 18 August 2019, 19:57:06
Interessant wäre der log vom HM485d Dämon. Bei jeder änderung open/close müsste da ungefähr folgendes im log stehen:
2019.08.18 19:34:20.271 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42ABFFEE -> 00000001 [6] 69(i) 00C800 {EC7C}
Dabei ist bei 00C800 das Hexbyte am Anfang der Kanal - 1 (00 ist Kanal 1 und 0B ist Kanal 12) 
und das zweite Hexbyte der Zutand open oder close

Gruß Ralf


Hi Ralf, ich sehe an Status led von arduino dass die Sensoren nicht geschaltet werden, daher wird der  hm485 log keine Infos anzeigen. Nichtsdestotrotz würde ich gerne wissen wie ich an diese Logs komme. Bei mir sind in FHEM kein logfile zu sehen.
Gruß

loetmeister

Hi,

Das device sieht ganz gut aus... Bis auf die falsche Startadresse der config sehe ich nichts problematisches.

Start ist 0x07, nicht 13..
senCfg[NUMBER_OF_SEN_INPUT_CHAN]; // 0x13 -

Aktiviere mal das logging in HBWSenSC.h. Dann kannst du erst mal das device ans laufen bringen, dann weiter schauen wo es mit FHEM klemmt..

Gruß,
Thomas

Ralf9

ZitatNichtsdestotrotz würde ich gerne wissen wie ich an diese Logs komme. Bei mir sind in FHEM kein logfile zu sehen.
dafür gibts die beiden Attribute

HM485d_logVerbose
If this is set to a nonzero value, then the output from the HM485d process goes into the main FHEM logfile or into the HM485d logfile, if the next attribute is set.

HM485d_logfile
The HM485d process can write an own log file with HM485d_logfile as filename.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

aperoap

Hi habe HM485d_logVerbose auf 5 gestellt, ein logfile definiert und HM485d_logfile eingestellt. Die logs werden jedoch noch in fhem logfile geschriebem und nicht in HM485d_logfile. Mache ich was falsch?