Reported values got stuck sometimes

Discussion about Z-Uno product. Visit http://z-uno.z-wave.me for more details.
michap
Posts: 321
Joined: 26 Mar 2013 10:35
Contact:

Re: Reported values got stuck sometimes

Post by michap » 01 Aug 2018 21:31

yes, looks right for your application ;)

Best regards
Michael

ondrej_bajer
Posts: 33
Joined: 17 May 2018 09:55

Re: Reported values got stuck sometimes

Post by ondrej_bajer » 03 Aug 2018 10:49

Well, so I've tried to modify one of my older devices and implement the above method of sending unsolicited reports.
- It has 2 multilevel sensors/channels.
- Each channel sends a report if the value has changed, but not more often than one report per 10 seconds per channel.
- Each channel sends at least one report per 1 minute, even if the values are steady.

With 2 multilevel sensors, this works great and both values got updated regularly, as you can see on the enclosed chart.
2 channels.JPG
2 channels.JPG (30.38 KiB) Viewed 580 times

But, if I use the same approach for a sketch with 7 sensors, it still suffers from the original issue - some of values got stuck, while other are being updated regularly :(

michap
Posts: 321
Joined: 26 Mar 2013 10:35
Contact:

Re: Reported values got stuck sometimes

Post by michap » 03 Aug 2018 12:07

Have you a chance to make a log file?
I mean from Z-Uno - with Serial.print as sample to log the reported values (in the getter procedure - and maybe at other place before).
Only to be sure that here is all ok.

Michael

ondrej_bajer
Posts: 33
Joined: 17 May 2018 09:55

Re: Reported values got stuck sometimes

Post by ondrej_bajer » 03 Aug 2018 13:17

Hi Micheal,

yes of course. I'm printing all the values and actions taken to the USB serial console, to see what's happening.

Looks like I have to create a super-simple testing sketch over the weekend. Something what will increment 7 variables and then report them periodically through multichannel. It will wait for serial console input before each report being sent. That way, one can cleary see what's going on.

Luckilly, I have 4 pcs of Z-UNO, so it's a lot of test gear to play with :)

p0lyg0n1
Posts: 160
Joined: 04 Aug 2016 07:14

Re: Reported values got stuck sometimes

Post by p0lyg0n1 » 03 Aug 2018 18:18

Hi, the new beta was released. It has logging event for sending queue overflow.
To check this you need:
1. Upgrade to beta 2.1.5
2. Connect UART to USB adapter to UART0(RX0,TX0 pins), open it in any software to see the output. We use for this CoolTerm.
3. Enable logging in IDE (logging->UART0)
4. Upload your sketch.
5. You have to see diagnostic messages in the output (CoolTerm):
format
TTTT:EE PP
Where TTTT is a time in seconds from the start of device (hexadecimal)
EE - code of event (hexadecimal)
PP - parameter of event (hexadecimal)
Event codes:

Code: Select all

	ZUNO_LOGGING_EVENT_START 	= 					0x00,
	ZUNO_LOGGING_EVENT_GOSLEEP 	= 					0x01,
	ZUNO_LOGGING_EVENT_RESCUEMODE = 				0x10,
	ZUNO_LOGGING_EVENT_SETDEFAULT = 				0x11,
	ZUNO_LOGGING_EVENT_LEARNCOMPLETE = 				0x12,
	ZUNO_LOGGING_EVENT_EEPROMRESET 	= 				0x13,
	ZUNO_LOGGING_EVENT_WRONGCONFIGDATA = 			0x20,
	ZUNO_LOGGING_EVENT_ASSOCIATIONSEND_DROPPED = 	0x90,
	ZUNO_LOGGING_EVENT_OUTGOING_POLICY_DROPPED = 	0x91,
	ZUNO_LOGGING_EVENT_INCOMING_POLICY_DROPPED = 	0x92,
	ZUNO_LOGGING_EVENT_STACKOVERFLOW 		= 		0xA0,
	ZUNO_LOGGING_EVENT_PARAMSTACKOVERFLOW 	= 		0xA1,
	ZUNO_LOGGING_EVENT_PARAMSTACKUNDERFLOW 	= 		0xA2,
	ZUNO_LOGGING_EVENT_NOSENDCALLBACK 	    = 		0xA5,
	ZUNO_LOGGING_EVENT_CHANNELNOTFOUND 	= 			0xA7,
	ZUNO_LOGGING_EVENT_WRONGUSERCODE 	= 			0xB0,
	ZUNO_LOGGING_EVENT_WRONGSYSFUNC 	= 			0xB1,
	ZUNO_LOGGING_EVENT_SENDQUEUE_OVERFLOW  = 		0xC0
So, If you will see C0 int the output it means that the queue is full.

ondrej_bajer
Posts: 33
Joined: 17 May 2018 09:55

Re: Reported values got stuck sometimes

Post by ondrej_bajer » 05 Aug 2018 12:24

Hi p0lyg0n1,

I've upgraded to 2.1.5 and enabled loging to UART0, but there's no output. Only during reset, it writes a single character to UART0, as visible on the attached screenshot.Looks like I'm doing something wrong...
The attachment serial - serial0.png is no longer available
serial - serial0.png
serial - serial0.png (28.76 KiB) Viewed 554 times

ondrej_bajer
Posts: 33
Joined: 17 May 2018 09:55

Re: Reported values got stuck sometimes

Post by ondrej_bajer » 05 Aug 2018 12:25

logging.png
logging.png (15.6 KiB) Viewed 554 times

ondrej_bajer
Posts: 33
Joined: 17 May 2018 09:55

Re: Reported values got stuck sometimes

Post by ondrej_bajer » 05 Aug 2018 13:50

So, I made a simple sketch, that reads input from Serial console and acts like this:
- When any key is pressed, it increment values and print them out.
- When "a" is pressed, it increment values, print them out and then calls ZunoSendReport 1-7.
- When any getter function is called, it logs this event to the Serial console and prints the value being returned.

Changing the delays between keystrokes, one can see what's happening and monitor whether the reported values are changing in HC2 too.
This way I found:

1) When ZunoSendReport is called, a corresponding Getter function is being called externally.
2) If ZunoSendReport is called too early, a Getter function is NOT being called at all. (Which is OK, as I assume that there's a system routine in Z-UNO that checks conditions before each transmit and should the transmit break Z-Wave Plus rules, it just ommits the getter part too.)
3) Getter1 is always being called twice. Other Getters are being called only once. This behavior is the very same for ZunoSendReport and for polling too.

So, I've uploaded the sketch while having a test-board on my desk, tried it and everything was working great. Once I've pressed "a", all the values appeared in HC2. The shortest working interval for ZunoSendReport is 30 seconds. Anything shorter will result in Getter not being called at all.

(Here, I wonder what's exact Z-Wave Plus specification... is it that every channel can send an unsolicited report once per 30 seconds, or is the condition more complex? I can imagine that it is way more complicated than just that. For example: Isn't there a limit on number of reports that a device can send in an interval, regardeless of channel? Is it really allowed to have a device with 30 channels and sending a report for each channel once per 30 seconds?)

Like I said, everything was working as expected on my desk, using a test-board. So, I went to a two production-boards and modified the code in a same way - not only printing the values, but also priting a note whenever each specific Getter is called. And I've found a really strange behavior:

1) All the getters were called even if the polling was disabled for that device in HC2 and ZunoSendReport command was not called.
2) Some of the getters were called twice in a row. This is okay for a Getter1, but not for the others:

Getter1 called.
Getter1 called.
Getter2 called.
Getter3 called.
Getter3 called.
Getter4 called.
Getter5 called.
Getter5 called.
Getter6 called.

The production-boards are 5m away from the HC2, but there's a ton of cables in the walls/floor and a lot of other z-wave devices in the network. So I did this in the response:
- Deleted both production board from HC2.
- Relocated HC2 to be in the same room as production boards.
- Did a new inclusion of the boards.

With this change, it's behaving much better. Since now, values are updated okay. Only strange thing is, that for one of the boards the channel #7 was showing itself as a number 0 in HC2 despite the fact that it was supposed to have a type of Voltage and scale Volts. I did a several device deletes/inluclusions, but it did not helped. Being desperate, I defined channel #8.....and it was producing the same error. Since it was after midnight, I gave up. In the morning, I found that channel #7 and channel #8 started to report itself correctly as Volts overnight, also reporting the actual values correctly. It's strange.

After the relocation of HC2, I tested what my other z-wave devices are saying and it looks that they don't mind. Truth is, that my standard devices are not really chatty as majority of them are just electric power meters, thermostats, fibaro plugs and modules.

Conlusion is, that there are things that I don't understand, but I'm underqualified to solve them too. Looks like I have to live with that. Also learned, that z-wave is a home automation tool, but not a telemetry.

Code: Select all

/*
Testing ZunoSendReport with multiple multilevel channels

All the debug messages are logged to USB Serial console. USB Serial console servers as input device, too.

1) When a Z-Wave controller polls a device, event for each Getter is logged.
2) When "a" is pressed, values are incremented AND ZunoSendReport for every channel is called.
3) When some other key is pressed, values are incremented ONLY, without calling ZunoSendReport.

*/

ZUNO_SETUP_CHANNELS(
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_VOLTAGE, SENSOR_MULTILEVEL_SCALE_VOLT, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_ONE_DECIMAL, getter1),           // PV1InputVoltage
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_CURRENT, SENSOR_MULTILEVEL_SCALE_AMPERE, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_TWO_DECIMALS, getter2),        // PV1InputAmps
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_VOLTAGE, SENSOR_MULTILEVEL_SCALE_VOLT, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_ONE_DECIMAL, getter3),           // PV2InputVoltage
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_CURRENT, SENSOR_MULTILEVEL_SCALE_AMPERE, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_TWO_DECIMALS, getter4),        // PV2InputAmps
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_TEMPERATURE, SENSOR_MULTILEVEL_SCALE_CELSIUS, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_ZERO_DECIMALS, getter5),  // InnerTemperature
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_CURRENT, SENSOR_MULTILEVEL_SCALE_AMPERE, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_ONE_DECIMAL, getter6),         // ChargingCurrent, pozor muze nabyvat i negativnich hodnot pri vybijeni baterie
        ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_VOLTAGE, SENSOR_MULTILEVEL_SCALE_VOLT, SENSOR_MULTILEVEL_SIZE_FOUR_BYTES, SENSOR_MULTILEVEL_PRECISION_ONE_DECIMAL, getter7)            // BatteryVoltage
); 

#define LED1_PIN 13
#define SERIAL_Console Serial   // Seriovy interface pro DEBUG.Serial=USB.Serial0=UART0.Serial1=UART1.

long VAL_PV1InputVoltage = 0; 
long VAL_PV2InputVoltage = 0;
long VAL_PV1InputAmps = 0;
long VAL_PV2InputAmps = 0;
long VAL_BatteryVoltage = 0;          
long VAL_InnerTemperature = 0;
signed long VAL_ChargingCurrent = 0;
 
void setup ()
  {
  SERIAL_Console.begin (9600);
  pinMode(LED1_PIN, OUTPUT);
  } // end of setup

void processIncomingByte (byte inByte)    // Tato funkce bude zavolana pokazde, kdyz na seriove rozhrani prijde novy znak
  {
  digitalWrite(LED1_PIN, HIGH);
  delay (50);
  digitalWrite(LED1_PIN, LOW);
  SERIAL_Console.println();
  SERIAL_Console.println();
  SERIAL_Console.println("**********************************************************");
  SERIAL_Console.print("*KEY PRESSED: "); SERIAL_Console.print(inByte); SERIAL_Console.print(" "); SERIAL_Console.println(char(inByte));
  SERIAL_Console.println("*INCREMENTING VALUES");
  ++VAL_PV1InputVoltage;
  ++VAL_PV1InputAmps;
  ++VAL_PV2InputVoltage;
  ++VAL_PV2InputAmps;
  ++VAL_InnerTemperature;
  ++VAL_ChargingCurrent;
  ++VAL_BatteryVoltage;
  
  SERIAL_Console.print("*VAL_PV1InputVoltage "); SERIAL_Console.println(VAL_PV1InputVoltage);
  SERIAL_Console.print("*VAL_PV1InputAmps "); SERIAL_Console.println(VAL_PV1InputAmps);
  SERIAL_Console.print("*VAL_PV2InputVoltage "); SERIAL_Console.println(VAL_PV2InputVoltage);
  SERIAL_Console.print("*VAL_PV2InputAmps "); SERIAL_Console.println(VAL_PV2InputAmps);
  SERIAL_Console.print("*VAL_InnerTemperature "); SERIAL_Console.println(VAL_InnerTemperature);
  SERIAL_Console.print("*VAL_ChargingCurrent "); SERIAL_Console.println(VAL_ChargingCurrent);
  SERIAL_Console.print("*VAL_BatteryVoltage "); SERIAL_Console.println(VAL_BatteryVoltage);

  if (char(inByte) == 'a')
    {
    SERIAL_Console.println("*SENDING REPORTS");
    zunoSendReport(1); // pv1 volts, lifeline
    zunoSendReport(2); // pv1 amps
    zunoSendReport(3); // pv2 volts
    zunoSendReport(4); // pv2 amps
    zunoSendReport(5); // Inner Temperature
    zunoSendReport(6); // Charging Current
    zunoSendReport(7); // Battery Voltage
    }
  SERIAL_Console.println("**********************************************************");
  SERIAL_Console.println();
  SERIAL_Console.println();
  } 

void loop()           // Main loop
  {
  while (SERIAL_Console.available () > 0)
    {
    processIncomingByte (SERIAL_Console.read ());
    }
  } // End of main loop

word getter1()
  {
  SERIAL_Console.println("-----------------------------------");
  SERIAL_Console.print("Getter1 called. VAL_PV1InputVoltage "); SERIAL_Console.println(VAL_PV1InputVoltage);
  return VAL_PV1InputVoltage;
  }
  
word getter2(){
  SERIAL_Console.print("Getter2 called. VAL_PV1InputAmps "); SERIAL_Console.println(VAL_PV1InputAmps);
  return VAL_PV1InputAmps;
  }
  
word getter3(){
  SERIAL_Console.print("Getter3 called. VAL_PV2InputVoltage "); SERIAL_Console.println(VAL_PV2InputVoltage);
  return VAL_PV2InputVoltage;
  }
  
word getter4(){
  SERIAL_Console.print("Getter4 called. VAL_PV2InputAmps "); SERIAL_Console.println(VAL_PV2InputAmps);
  return VAL_PV2InputAmps;
  }

word getter5(){
  SERIAL_Console.print("Getter5 called. VAL_InnerTemperature "); SERIAL_Console.println(VAL_InnerTemperature);
  return VAL_InnerTemperature;
  }

signed long getter6(){
  SERIAL_Console.print("Getter6 called. VAL_ChargingCurrent "); SERIAL_Console.println(VAL_ChargingCurrent);
  return VAL_ChargingCurrent;
  }

word getter7(){
  SERIAL_Console.print("Getter7 called. VAL_BatteryVoltage "); SERIAL_Console.println(VAL_BatteryVoltage);
  SERIAL_Console.println("-----------------------------------");
  SERIAL_Console.println();
  return VAL_BatteryVoltage;
  }

Post Reply