Update Issues from Master request(...)

[UweK]

Hi folks!

I'd built my first Mysensors Node with two relays and one input. I am using fhem.

Instead of writing into the EEPROM, the node is requesting the status of both relays from fhem.
Thus i have this two lines in setup():
request(CHILD_ID_Rel1, V_LIGHT,0);
request(CHILD_ID_Rel2, V_LIGHT,0);

I am getting only an update for Relay2.
Then i tought it is a timing issue and i added two waits to test:
request(CHILD_ID_Rel1, V_LIGHT,0);
wait(1000);
Serial.print("Relais 2 anfragen");
request(CHILD_ID_Rel2, V_LIGHT,0);
wait(1000);

And yes, now i am receoving both updates!

Q: Is there no logic to serialize requests to Master?
And if no, wait() is not a good solution i believe. How can i handle such
syncronization issues?

Another Question:
When i let fhem setup my Code_100, i am getting two readings named "power".
I doesn't know what it means and i can't find it in 10_Mysensors where it is coming from.

Thanks in advance!
Uwe

[mfalkvidd]

@uwek could you post a debug log from the node when it requests and receives (without wait)?

The gateway (or fhem) log could be useful as well. I don't use fhem though so I am not sure where to find it.

What does your receive function look like?

[rejoe2]

Without the "wait()" statement, messages from and to the GW may interferre with each other. You may get around that by using Ack's in the requests (most likely "1" instead of "0" as the third argument). But as this is just initializing code (?), imo the wait() isn't really an issue.

The other thing with FHEM adding one reading named powerx for each of the relais is a result of line 113 in the device-module. To be honest, I'm not quite sure if that makes much sense, but this is the behaviour since ages...

[UweK]

@mfalkvidd
The Log is not saying much.
While debug is on @ the node, i just see one message coming from fhem, this one for Relay2.
I guess the node is sending both request in short period, so fhem is only getting the last one.

@rejoe2
Yes, Ack would be a solution, but then i need something like a queue or so to buffer the messages.
request-> wait
Ack
next request...

feels like a bit to complicated for micros...
btw: the wait command has a possibility to wait for time OR for a specific answer from master.
Do you know an example where this is used?

btw:
I build a logic to send RSSI to fhem, because i can't get the internal RSSI running:

void loop()
{
  //Alle 120Sekunden den RSSI Level schicken
  if (rssi_send > 12000){
  //Sende-Empfangsstaerke
  Serial.print("RSSI Send");
  wait(500); // Allow time for radio if power used as reset
  Send_rssi = RFM69_getSendingRSSI();             // read RSSI in RFM69. Measure reception signal from gw
  send(msgRSSI1.set(Send_rssi));                  // send RSSI level
  wait(500);                                 // wait to get idle
  Rec_rssi = RFM69_getReceivingRSSI();           // read RSSI in RFM69. Wait and measure background noise
  send(msgRSSI2.set(Rec_rssi));                  // send RSSI level
  rssi_send = 0;
  sendHeartbeat();
  }
  rssi_send +=1;

Works well, but i don't know why internal RSSI is not doing what expected...

[UweK]

@rejoe2
Line 113 is

S_BINARY => { receives => [V_STATUS,V_WATT], sends => [V_STATUS,V_WATT] }, # Binary device (on/off)```

Cant find "Power" as a name for a reading.
And: For what the hell is Power good for, if it can only get a "1" as parameter? makes that sense?

LG
 Uwe

[mfalkvidd]

@uwek if the log is saying that both outgoing messages were st=OK and there was only one incoming message, the problem is likely with fhem yes. You could check the gateway log to see if the gateway receives one or two messages from fhem, to determine if the message gets lost on the way from fhem to the node (or from the node to fhem).

[rejoe2]

@uwek wrt to ACK: If a node sends with ack, it will be resend as long as the parent (eg. the GW) has indicated reception; no need to queue on the arduino side. On FHEM side, the IO module enqueues also the ACK messages. So you may test the use of ACK on controller side also?
To see, what was sent from FHEM side, you can set your IO device to verbose 5.
Sounds a little as your IO has transmission problems, because I'm almost sure, the module code itself will not loose any information on it's path throughout FHEM.
Wait() in combination with a specific answer expected is also new to me, but sounds interesting.

Wrt. RSSI, afai remember, the RSSI feature also has to be activated on the Arduino side. If you've done so, this also points to transmission problems at the gw hardware - I'd bet, the node never "hears" the request.

Wrt. to line 113: V_WATT will be transated in a readingname "powerx" with "x" beeing the child ID; same with V_STATUS => statusx. This is line 179 resp. 158. As this is the original authors code, I'm also not sure wheter that setup makes to much sense, but on the other hand - besides some more aestetical aspects - don't see the neccessity to put much effort in that; you effectively are not limited to "1", it's just the GUI that's missleading here...

[UweK]

@mfalkvidd
Hi, you're right. I used the Node verbose=5, but indead, verbose=5 on the Mysensor serial is much more saying!

@rejoe2
Hmm, i'm using this line numbers. Line 179?? haha, gues i'm looking into something wrong :-)
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm

Ok, will play with the verbose messages now to see whgats going on and where my message will die on the way.
Then i will try to use
request(CHILD_ID_Rel1, V_LIGHT,1);
and
wait(500, CHILD_ID_Rel1, V_LIGHT)
if this will work better.

Once finished i will share my solution (2Ch Relay (230V for light) with ESP12E and one input (for Ring) with all.

Thanks!
LG
Uwe

[rejoe2]

@uwek said in Update Issues from Master request(...):

@rejoe2
Hmm, i'm using this line numbers. Line 179?? haha, gues i'm looking into something wrong :-)

Sorry, that was 3 lines to much, but most likely you noticed the principle :-) . But why looking at some github repo? Most recent code is always in svn: https://svn.fhem.de/trac/browser/trunk/fhem/

[UweK]

Hi
Here is my Log from fhem:

2019.04.16 11:29:42 4 : MYSENSORS/RAW: /0;255;3;0;9;316561201 TSF:MSG:RE
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561201 TSF:MSG:RE/AD,100-100-0,s=1,c=2,t=2,pt=0,l=
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561201 TSF:MSG:READ,100-100-0,s=1,c=2,t=2,pt=0,l=/0,sg=0: 100;1;2;0;2;
2019.04.16 11:29:42 4 : MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 '316561201 TSF:MSG:READ,100-100-0,s=1,c=2,t=2,pt=0,l=0,sg=0:'
2019.04.16 11:29:42 5 : MYSENSORS gateway MySensors_Serial: 316561201 TSF:MSG:READ,100-100-0,s=1,c=2,t=2,pt=0,l=0,sg=0:
2019.04.16 11:29:42 4 : MYSENSORS Read: Rx: fr=100 ci=001 c=002(C_REQ ) st=002(V_STATUS ) ack=0 ''
2019.04.16 11:29:42 5 : MYSENSORS **send: Rx: fr=100 ci=001 c=001(C_SET ) st=002(V_STATUS ) ack=1 'off'**
2019.04.16 11:29:42 5 : SW: 3130303b313b313b313b323b6f66660a
2019.04.16 11:29:42 1 : PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/00_MYSENSORS.pm line 542.
2019.04.16 11:29:42 4 : MYSENSORS/RAW: /0;255;3;0;9;316561860 !TSF:MSG:S
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561860 !TSF:MSG:S/END,0-0-100-100,s=1,c=1,t=2,pt=0
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561860 !TSF:MSG:SEND,0-0-100-100,s=1,c=1,t=2,pt=0/,l=3,sg=0,ft=0,st=NACK:off
2019.04.16 11:29:42 4 : MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 '316561860 !TSF:MSG:SEND,0-0-100-100,s=1,c=1,t=2,pt=0,l=3,sg=0,ft=0,st=NACK:off'
2019.04.16 11:29:42 5 : MYSENSORS gateway MySensors_Serial: 316561860 !TSF:MSG:SEND,0-0-100-100,s=1,c=1,t=2,pt=0,l=3,sg=0,ft=0,st=NACK:off
2019.04.16 11:29:42 4 : MYSENSORS/RAW: /0;255;3;0;9;316561871 TSF:MSG:RE
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561871 TSF:MSG:RE/AD,100-100-0,s=2,c=2,t=2,pt=0,l=
2019.04.16 11:29:42 4 : MYSENSORS/RAW: 0;255;3;0;9;316561871 TSF:MSG:READ,100-100-0,s=2,c=2,t=2,pt=0,l=/0,sg=0: 100;2;2;0;2;
2019.04.16 11:29:42 4 : MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL ) st=009(I_LOG_MESSAGE ) ack=0 '316561871 TSF:MSG:READ,100-100-0,s=2,c=2,t=2,pt=0,l=0,sg=0:'
2019.04.16 11:29:42 5 : MYSENSORS gateway MySensors_Serial: 316561871 TSF:MSG:READ,100-100-0,s=2,c=2,t=2,pt=0,l=0,sg=0:
2019.04.16 11:29:42 4 : MYSENSORS Read: Rx: fr=100 ci=002 c=002(C_REQ ) st=002(V_STATUS ) ack=0 ''
2019.04.16 11:29:42 5 : **MYSENSORS send: Rx: fr=100 ci=002 c=001(C_SET ) st=002(V_STATUS ) ack=1 'off'**
2019.04.16 11:29:42 5 : SW: 3130303b323b313b313b323b6f66660a

And here from node:

37780 MCO:REG:REQ
38444 TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
38659 TSF:MSG:READ,0-0-100,s=255,c=3,t=27,pt=1,l=1,sg=0:1
38664 MCO:PIM:NODE REG=1
38667 MCO:BGN:STP
38677 TSF:MSG:SEND,100-100-0-0,s=3,c=1,t=16,pt=4,l=4,sg=0,ft=0,st=OK:0
Relais 1 anfragen
39192 TSF:MSG:SEND,100-100-0-0,s=1,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
Relais 2 anfragen
39861 TSF:MSG:SEND,100-100-0-0,s=2,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK:
39867 MCO:BGN:INIT OK,TSP=1
Switched!
39879 TSF:MSG:SEND,100-100-0-0,s=3,c=1,t=16,pt=4,l=4,sg=0,ft=0,st=OK:0
40098 TSF:MSG:READ,0-0-100,s=3,c=1,t=16,pt=4,l=4,sg=0:0
40103 TSF:MSG:ACK
Sensor:3, Payload: 0
This is an ack from gateway
40115 TSF:MSG:READ,0-0-100,s=2,c=1,t=2,pt=0,l=3,sg=0:off
40120 TSF:MSG:ACK REQ
40331 TSF:MSG:SEND,100-100-0-0,s=2,c=1,t=2,pt=0,l=3,sg=0,ft=0,st=OK:off
Sensor:2, Payload: 0
Incoming change for relay:2, New status: 0

And to complete this post, my actual rubbish code :-)

/*
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2018 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Henrik Ekblad
 *
 * DESCRIPTION
 * Example sketch showing how to control physical relays.
 * This example will remember relay state after power failure.
 * http://www.mysensors.org/build/relay
 */
#define SKETCH_NAME "Klingelmodul"                // Change to a fancy name you like
#define SKETCH_VERSION "1.0"                    // Your version

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_SPECIAL_DEBUG

// Enable and select radio type attached
//#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
#define MY_RADIO_RFM69
#define MY_RFM69_TX_POWER_DBM (12)
#define MY_RFM69_NEW_DRIVER

//#define MY_RADIO_RFM95

// Enable repeater functionality for this node
//#define MY_REPEATER_FEATURE

#include <Bounce2.h>
#include <MySensors.h>

#define RELAY1_PIN 2  // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define RELAY2_PIN 4  // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define INPUT1_PIN 16  // Arduino Digital I/O pin number for first relay (second on pin+1 etc)

#define NUMBER_OF_RELAYS 2 // Total number of attached relays
#define RELAY_ON 0  // GPIO value to write to turn on attached relay
#define RELAY_OFF 1 // GPIO value to write to turn off attached relay

#define CHILD_ID_Rel1       1 //Msg ID für Relais 1
#define CHILD_ID_Rel2       2 //Msg ID für Relais 1
#define CHILD_ID_Inp        3  //Msg ID für Klingelknopf
#define CHILD_ID_RSSI_HIGH  4                // RSSI received signal level
#define CHILD_ID_RSSI_LOW   5                // RSSI background noise level

Bounce debouncer = Bounce(); 

int Send_rssi, Rec_rssi;                                    // Sende/Empfangslevel vomRSSI RFM69 chip
int oldValue=-1;
int rssi_send = 0; //Schleifenzähler für RSSI Level Senden

MyMessage msgRSSI1(CHILD_ID_RSSI_HIGH,  V_LEVEL);
MyMessage msgRSSI2(CHILD_ID_RSSI_LOW,   V_LEVEL);
MyMessage msgRel1 (CHILD_ID_Rel1,       V_LIGHT);
MyMessage msgRel2 (CHILD_ID_Rel2,       V_LIGHT);
MyMessage msgInp  (CHILD_ID_Inp,        V_TRIPPED);
//###############################################################################################
void before()
{
		// Then set relay pins in output mode
    pinMode(RELAY1_PIN, OUTPUT);
    pinMode(RELAY2_PIN, OUTPUT);
    pinMode(INPUT1_PIN,INPUT);
		// Set relay to last known state (using eeprom storage)
    digitalWrite(RELAY1_PIN, loadState(1)?RELAY_ON:RELAY_OFF);
    digitalWrite(RELAY2_PIN, loadState(2)?RELAY_ON:RELAY_OFF);
    digitalWrite(INPUT1_PIN,HIGH);
}
//###############################################################################################
void setup()
{
  debouncer.attach(INPUT1_PIN);
  debouncer.interval(5);
  debouncer.update();
  int value = debouncer.read();
  send(msgInp.set(value==HIGH ? 1 : 0));
  Serial.print("Relais 1 anfragen");
  request(CHILD_ID_Rel1,       V_LIGHT,0);
  //wait(1000);  
  Serial.print("Relais 2 anfragen");
  request(CHILD_ID_Rel2,       V_LIGHT,0);
  //wait(1000);
}
//###############################################################################################
void presentation()
{
  // Send the Sketch Version Information to the Gateway
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  present(CHILD_ID_Rel1,S_LIGHT,      "Relais1", true);
  present(CHILD_ID_Rel2,S_LIGHT,      "Relais2", true);
  present(CHILD_ID_Inp,S_DOOR,        "Klingel", true);  
  present(CHILD_ID_RSSI_HIGH, S_SOUND,"RSSI_SendLevel", true);
  present(CHILD_ID_RSSI_LOW, S_SOUND, "RSSI_ReceiveLevel", true);
}
//###############################################################################################
void loop()
{
  //Alle 120Sekunden den RSSI Level schicken
  if (rssi_send > 12000){
  //Sende-Empfangsstaerke
  Serial.print("RSSI Send");
  wait(500); // Allow time for radio if power used as reset
  Send_rssi = RFM69_getSendingRSSI();             // read RSSI in RFM69. Measure reception signal from gw
  send(msgRSSI1.set(Send_rssi),true);                  // send RSSI level
  wait(500);                                 // wait to get idle
  Rec_rssi = RFM69_getReceivingRSSI();           // read RSSI in RFM69. Wait and measure background noise
  send(msgRSSI2.set(Rec_rssi),true);                  // send RSSI level
  rssi_send = 0;
  sendHeartbeat();
  }
  rssi_send +=1;

  //Klingeltaster
  debouncer.update();
  // Get the update value
  int value = debouncer.read();
  if (value != oldValue) {
     // Send in the new value
     Serial.print("Switched!");
     send(msgInp.set(value==HIGH ? 1 : 0),true);
     oldValue = value;
  }
 wait(10);//10ms warten
}

//###############################################################################################
void receive(const MyMessage &message)
{
      Serial.print("Sensor:");
      Serial.print(message.sensor);
      Serial.print(", Payload: ");
      Serial.println(message.getBool());
	// We only expect one type of message from controller. But we better check anyway.
  if (message.isAck()) {
      #ifdef MY_DEBUG
      Serial.println("This is an ack from gateway");
      #endif
      return;
  }
  
  if (message.type==V_LIGHT) {
      // Change relay state
      int outputPin = (message.sensor == CHILD_ID_Rel1)?RELAY1_PIN:RELAY2_PIN;
      digitalWrite(outputPin, message.getBool()?RELAY_ON:RELAY_OFF);
      // Store state in eeprom
      //saveState(message.sensor, message.getBool());
      #ifdef MY_DEBUG
      // Write some debug info
      Serial.print("Incoming change for relay:");
      Serial.print(message.sensor);
      Serial.print(", New status: ");
      Serial.println(message.getBool());
      #endif
      // Update the state variables
	}
  else {
      #ifdef MY_DEBUG
      // Write some debug info
      Serial.print("Sensor:");
      Serial.print(message.sensor);
      Serial.print(", Payload: ");
      Serial.println(message.getBool());
      #endif 
  }
}```

[UweK]

Somehow, Acks are lost and Msg as well.
Both modules are lying away here just 30cm from each other.

Ratlos

[mfalkvidd]

@uwek 30cm might be too close, especially with such high TX power as 12dBm

[rejoe2]

If there's no ACK, messages will be resent, so your log excerpt from FHEM may be to short (repetition should start with +1 sec, times will be prolonged lateron).

Remarks on your code:

• better keep hands off from PINs 2+3 and reserve them for interrupt-based tasks (might be here input Pin 3 for your button, but debounce2() and using differen PIN is ok also)
• RFM69: Better connect interrupt (PIN2)?
• RSSI may need #define MY_SIGNAL_REPORT_ENABLED

[UweK]

@rejoe2
I am using a pcb i bought 2 years ago, thus most pins are used somehow.
I was able to cut some lines and use wire to reconnect to RFM69 for example.
IT's quite a small pcb to be build inside walls behind switches etc.

I am using GPIO15 even it's used to start the ESP into programming mode.
Btw: I am not using WLAN. It was used for that before, but, as i am living on LaPalma,
the walls include stones with hight part of iron. WLAN is not crossinfg my 60cm walls :-(
Thats the reason why i am switching to 800MHz. It is working much better, but with 5dbm,
no chance, thus 12 dbm...

Because this is my very first experience with MySensors, it is a bit like an adventure :-)
Maybe later on i can reduce the power...

Thanks for the tips!

uwe

[rejoe2]

So ok, you want to learn the hard way :grinning: ...
If the mcu is an ESP8266 also on the node's side, forget about PIN2/3 beeing special, this applies to standard ATMega32P. But perhaps you'd have to define a different interrupt pin for the RFM.
Frankly spoken, imo it's easier to start off with a more default setup...

[UweK]

@mfalkvidd
Put it 3m away with same result.
A monster is eating my packages...

If it works with wait(), it must be a timing issue!

Also, i wonder why i am getting only ONE Ack if a request every time a ack.
I have now added #define MY_SPECIAL_DEBUG as well to see more on serial console.

[UweK]

@rejoe2
Do you believe the interrupt is not working correctly?

[rejoe2]

@uwek Special-Debug only gives some more info about the sketch, so this most likely will not help.
Wrt to ACK, I'm not familiar how the MySensors lib handles that internally, but FHEM will keep all the messages seperate from each other.
I also have little experience with RFM modules; for nRF interrupt handling is not necessary, but most likely, this is the exception. Anyhow: It seems to work to some extend, so I'd not bet to much on this as the root cause of your problems.

[UweK]

Hi all

I solved this issue, this is the solution:
I am using wait with additional parameter to wait 1000ms OR for a specific data packet from fhem. This works well!

Now i don't need to write into EEPROM, after reboot the node is requesting actual status of the relays from fhem.

 //request status of Relais 1
  request(CHILD_ID_Rel1,       V_WATT,0);
  wait(1000,1,2); 
  
  //request status of Relais 2 
  request(CHILD_ID_Rel2,       V_WATT,0);
  wait(1000,1,2);

Another "enhancement":
I am using the Power readings to set/reset relays and i use the status reading to get the actual status back.
I guess this was the initial logic of the fhem modul, but as power only produce a "1" as setpoint, i changed it to "on,off", equal the Power reading.
The primitive setup in fhem looks like thios:

defmod MYSENSOR_100 MYSENSORS_DEVICE 100
attr MYSENSOR_100 DbLogExclude .*
attr MYSENSOR_100 IODev mysensors
attr MYSENSOR_100 mapReading_armed3 3 armed
attr MYSENSOR_100 mapReading_armed4 4 armed
attr MYSENSOR_100 mapReading_armed5 5 armed
attr MYSENSOR_100 mapReading_level4 4 level
attr MYSENSOR_100 mapReading_level5 5 level
attr MYSENSOR_100 mapReading_power1 1 power
attr MYSENSOR_100 mapReading_power2 2 power
attr MYSENSOR_100 mapReading_status1 1 status
attr MYSENSOR_100 mapReading_status2 2 status
attr MYSENSOR_100 mapReading_tripped3 3 tripped
attr MYSENSOR_100 mapReading_tripped4 4 tripped
attr MYSENSOR_100 mapReading_tripped5 5 tripped
attr MYSENSOR_100 mode node
attr MYSENSOR_100 requestAck 1
attr MYSENSOR_100 room mysensor
attr MYSENSOR_100 setReading_power1 on,off
attr MYSENSOR_100 setReading_power2 on,off
attr MYSENSOR_100 setReading_status1 on,off
attr MYSENSOR_100 setReading_status2 on,off
attr MYSENSOR_100 showtime 1
attr MYSENSOR_100 timeoutAlive 240
attr MYSENSOR_100 verbose 5

setstate MYSENSOR_100 alive
setstate MYSENSOR_100 2019-04-22 10:54:10 R_RSSI_from_Parent -89
setstate MYSENSOR_100 2019-04-22 10:54:09 R_RSSI_to_Parent -82
setstate MYSENSOR_100 2019-04-22 10:54:11 R_TX_Powerlevel_Pct 100
setstate MYSENSOR_100 2019-04-22 10:54:11 R_TX_Powerlevel_dBm 13
setstate MYSENSOR_100 2019-04-22 10:54:12 R_Uplink_Quality -89
setstate MYSENSOR_100 2019-04-20 21:20:19 SKETCH_NAME Klingelmodul
setstate MYSENSOR_100 2019-04-20 21:20:19 SKETCH_VERSION 1.1
setstate MYSENSOR_100 2019-04-22 11:01:15 heartbeat last
setstate MYSENSOR_100 2019-04-22 11:01:14 level4 -93
setstate MYSENSOR_100 2019-04-22 11:01:15 level5 -88
setstate MYSENSOR_100 2019-04-20 21:20:19 parentId 0
setstate MYSENSOR_100 2019-04-21 22:49:37 power1 on
setstate MYSENSOR_100 2019-04-20 21:32:44 power2 on
setstate MYSENSOR_100 2019-04-22 11:01:15 state alive
setstate MYSENSOR_100 2019-04-21 22:49:37 status1  1
setstate MYSENSOR_100 2019-04-20 21:32:45 status2  1
setstate MYSENSOR_100 2019-04-22 10:48:49 tripped3 off

tripped3 is my Input from the Doorbell.

Ok, guys, 1000 thanks for your help!
BR
Uwe