Z-UNO blocked after several hours of operation

[schmidmi]

I've created a sketch providing a temperature and a binary switch to my HC 2.
In the first point of view everything seems to work smoothly.
The temperature value is calculated via a DS18B20 which is read every 30 seconds.
To my Z-UNO I've connected an OLED display which shows the temperature and the state of the switch.
The display is updated in case of a change of the switch or the temperature.

After updating to Version 2.1.0 I've got the problem, that my device is blocked after several hours of operation. In this case the green LED doesn't blink but is switched on. After resetting the device it will operate again for about 12 hours.

Is there an issue known?

[petergebruers]

I run a BH1750 sketch (an improved version of the version published on the forum) and it does not crash. It runs until I reboot the Z-Uno or change the sketch. The longest time between 2 reboots was about 24 hours.

If you could share your code, I'll see if I can find anything suspicious...

[schmidmi]

I don't think, that there is something strange in the code, because it was running several weeks without any problems under previous versions.
But nevertheless, here it is:

Code: Select all

// Z-UNO used to connect a Mitsubishi A/C controller to Fibaro HC 2
// It provides the actual temperature and an ON/OFF switch.
// The device can be operated via HC 2 or with a local push button.
// Due to the small amount of ram, it was not possible to implement a connection to 
// the A/C controller via IR within this device.
// So the task of sending the 288 Bit IR codes is done by an additional Arduino device.
// The Z-UNO provides an binary output to talk to the Arduino.
// September 2017
// by Michael Schmidt

#include <ZUNO_DS18B20.h>
#include <ZUNO_OLED_I2C.h>
#include <EEPROM.h>


// pin connection ds18b20
#define PIN_DS18B20 11

// Shows the state of the device
#define LED_PIN 13

// Output to control the Arduino
#define ControlPin 6

// Input for the local On/Off button
#define SWITCH_LOCAL 18

// local push button handled with ISR
ZUNO_SETUP_ISR_INT0(int0_handler);

OneWire ow(PIN_DS18B20);

// local Display for temperature an state
OLED oled;
// onewire connection temperature sensors
DS18B20Sensor ds1820(&ow); 

byte addr1[8];
int temp = 0;           // here we will store the actual temperature
int lastTemp;           // temperature during the last scan cycle
byte currentLEDValue;   // Last saved LED value
float temperature;

// set up channel
ZUNO_SETUP_CHANNELS(
   ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_TEMPERATURE, 
                          SENSOR_MULTILEVEL_SCALE_CELSIUS, 
                          SENSOR_MULTILEVEL_SIZE_TWO_BYTES, 
                          SENSOR_MULTILEVEL_PRECISION_TWO_DECIMALS,
                          getterTemp),
   ZUNO_SWITCH_BINARY(getSWBin,setSWBIN)
);

void setup() {
    byte lastState = 0;
    pinMode(LED_PIN, OUTPUT);
    pinMode(SWITCH_LOCAL,INPUT_PULLUP);
    zunoExtIntMode(ZUNO_EXT_INT0, FALLING);

    pinMode(ControlPin, OUTPUT); 
    digitalWrite(ControlPin, LOW); 
  
    oled.begin();
    oled.clrscr();
      

    // Get the last state before shut down
    EEPROM.get(0,&currentLEDValue,1);
    
    setSWBIN(currentLEDValue);
    oled.gotoXY(0,5);
    oled.print("Status    : ");
    if (currentLEDValue == 0)
    {
      oled.print("Aus");
    }
    else
    {
      oled.print("Ein");
    }
}

void loop() {
    ds1820.scanAloneSensor(addr1);
    // obtaining readings from the sensor ds18b20
    temperature = ds1820.getTemperature(addr1);
    // make scaled word value for report
    temp=int((temperature*100));
     
    // send data to channel
    // data will be send in case of a change of value only
    if (abs(temp - lastTemp) >= 5)
    {
      zunoSendReport(1);
      lastTemp = temp; // store the actual value for the next compare

      oled.gotoXY(0,2);
      oled.print("Temperatur: ");
      oled.print(temperature);
      oled.print(" C");
    }
    delay(30000);
}

// methode to update the state of the device
void setSWBIN(byte value) {
  // value is a variable, holding a "new value"
  // which came from the controller or other Z-Wave device
  if (value > 0) {               // if greater then zero
    digitalWrite (LED_PIN, HIGH); //turn the LED on (HIGH is the voltage level)
  } else {                         // if equals zero
    digitalWrite(LED_PIN, LOW);   //turn the LED off by making the voltage LOW
  }
  // we'll save our value for the situation, when the controller will ask us about it
  if (currentLEDValue != value)
  {
    currentLEDValue = value;

    // Store the actual state in EEProm
    EEPROM.put(0,&currentLEDValue,1);

    // Update HC 2
    zunoSendReport(2);

    // Update local display
    oled.gotoXY(0,5);
    oled.print("Status    : ");
    
    if (currentLEDValue == 0)
    {
      oled.print("Aus");
    }
    else
    {
      oled.print("Ein");
    }
  }
  
}

// Interrupt handler to read the local switch
void int0_handler()
{
  if (currentLEDValue == 0)
  {
    setSWBIN(255);
  }
  else
  {
    setSWBIN(0);
  }
  
}

// Binary value read by HC2
byte getSWBin() {
  return currentLEDValue;
}

// Temperature read by HC2
word getterTemp() {
    return temp;
}

[petergebruers]

Thank you for sharing your code. I am convinced that sharing code is always interesting, for educational purposes! I'll run your code on my Z-Uno and see if I can find something. At the moment, after a quick look, I'd say the green LED stops blinking if your code hangs in loop() or getter(). The only explanation I see at the moment is either the oled or the ds1820 library. I have not yet used them on a Z-Uno, so I am not sure if this could happen. What I do now is that you do not check if the ds1820 reported a sane value or the 1-wire bus had an error, for instance invalid CRC. Could it be a data glitch due to the wiring of the DS18B20? I am thinking out loud now... Sorry for that. I'll be back when I've run the code.

[petergebruers]

I've loaded your scene. No sensor or OLED attached. So it reports -327.67 °C as I expected, but that is not the issue here... The main thing is that the green LED keeps blinking, it does not crash...

Another thing is that your interrupt routine violates a requirement mentioned on the reference pages of the Z-Uno, I quote: "The code in the user interrupt handler function should be as fast as possible and should not contain ANY function calls except few listed: pinMode(), digitalRead() and digitalWrite() with constant (a number) or s_pin as pin argument, all GPT and External Interrupts functions. Also don't use local variables — use global variables instead!"

I've fed a square wave to INT0 and I've noticed that I cannot blink the LED faster than 1.5 Hz. I am not sure this explains why it would hang, but it certainly is not "fast". The reason is the speed of the oled library. But even when you remove it, the loop still is not really "fast".

I have an idea on how to fix this: use only the interrupt to set or reset a variable, then restructure loop() to check in smaller intervals if the variable changed and if you need to write to the oled... In fact I think you do not need an interrupt routine at all if you just want to display the status of pin 17, but I could be wrong.

Unfortunately, I am about to leave on a short holiday, and my wife forbids me to bring along my beloved Z-Uno. I'll be back on Monday...

[schmidmi]

Thank you for all your help.
But my problem ist not the interrupt or something.
The interrupt is used by a push button to switch my A/C device on or off. For the sketch it means, it's used nearly never.
But the Z-UNO hangs just processing the loop Methode without any influence from outside.

[petergebruers]

Fair enough! So when you connect pin 17 to ground, the green led stops blinking if you leave it powered for about one day?

If you exclude the Z-Uno, and ground that pin, does it still crash within a day?

What happens if you remove the oled code?

[schmidmi]

Nice ideas.
But my problem is, that the code was working for days and days without any problems with the firmware 1.8.
And now with 2.1 I got this issue.
Strange....

[petergebruers]

I see. So you think the issue was introduced by upgrading the framework? I do not know how to test that hypothesis... In that case maybe other user have similar problems. Let us wait and see...

[PoltoS]

1.8.x is very different from 2.1.x. The problem might be in many places. If you can reproduce it on some minimal use case, we can test it in our lab.

We will also release a 2.1.1 soon. May be worth to try