Z-UNO blocked after several hours of operation

Discussion about Z-Uno product. Visit http://z-uno.z-wave.me for more details.
schmidmi
Posts: 52
Joined: 01 Dec 2016 16:45
Location: Germany (Karlsruhe)

Re: Z-UNO blocked after several hours of operation

Post by schmidmi » 04 Oct 2017 09:41

Z-UNO.PNG
Temperature in HC 2
Z-UNO.PNG (43.77 KiB) Viewed 2836 times
An influence of internal interrupts? May be. I can't check this. The Z-UNO was not in the cyclic calling queue of my HC 2. But I don't know, what the Z-UNO is doing with all radio telegrams of the Z-Wave.
Nevertheless, I did some more investigations based on the helpful discussions here. I understood, that there is a problem, using oled.print(float) and zunoSendReport() together. So in the first step I checked what is happening, when I call these methods in different cycles of the main loop. I saw a significant improvement of stability. Instead of about every 140 cycles the device was blocked only every 900 cycles.

That lead me to the last test. Instead of writing a float value to the oled display, I divided into 2 integers, which I write in a sequence to the display (see the attached nasty lines of code ;) ).
With that solution the device isn't blocked anymore and running smoothly as desired :!:
Now I can go on to finish my project of controlling my Mitsubishi A/C systems via HC 2.
The only thing to do is, to create some PCBs and put all the things together in a case :)

Code: Select all

 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(72,2);
      //oled.print(temperature); // This will cause the Z-UNO to block

      // Some nasty lines of code to avoid blocking
      // The float value for the temperature is converted into 2 integers
      // to write them to the OLED display
      int temp4Display = ((highByte(temp) * 256 ) + lowByte(temp));
      int temp4DisplayH = temp4Display / 100;
      int temp4DisplayL = temp4Display - (temp4DisplayH * 100); 
      oled.print(temp4DisplayH);
      oled.print(",");
      oled.print(temp4DisplayL);
      zunoSendReport(1);
    }
    delay(30000);

petergebruers
Posts: 230
Joined: 26 Jul 2015 17:29

Re: Z-UNO blocked after several hours of operation

Post by petergebruers » 04 Oct 2017 09:59

Thank you for reporting back! Great to see you are using a HC too ;-) For what it is worth: I think printing the temperature like that is a good workaround!

Now this is solved... Did you say need an Arduino because the Z-Uno cannot send 288 IR codes? I think I have read somewhere that the IR buffer is 300 bytes (edit: it was mentioned in a topic about controlling 24 WS2812) but in fact it may be limited to 256... But if you really want to get rid of that 2nd device... Unfortunately, I cannot test it for you, I do not have an IR test receiver at the moment!

schmidmi
Posts: 52
Joined: 01 Dec 2016 16:45
Location: Germany (Karlsruhe)

Re: Z-UNO blocked after several hours of operation

Post by schmidmi » 04 Oct 2017 10:18

Yes, the IR buffer has a size of 300 bytes. But to send the 288 Bit Code, it would need 576 bytes minimum. And the IR code has to be sended twice with a certain amount of delay. This couldn't be done with Z-UNO.
I already hat a longer discussion with the Z-UNO developers (see the topic "IR-lib and long Raw seqences" in this forum).

So I took a normal Arduino UNO (only costs of 8 EURO :D ) for generating the IR codes. It will also provide the power supply for Z-UNO.
I will produce an adapted Arduino shield which takes Z-UNO and the additional devices like temperature sensor, OLED display, push button, IR sender and so on. At the end I will have a nice and easy package to put in a standard Arduino housing. I will produce two devices like this for my two rooms connected to my A/C system.

petergebruers
Posts: 230
Joined: 26 Jul 2015 17:29

Re: Z-UNO blocked after several hours of operation

Post by petergebruers » 04 Oct 2017 10:43

I have read your topic right now.
In essence:

0x122 * sizof(word) = 580 bytes!
580 > 300 bytes => Overflow.

And when using GPT you do not get the expected timing... Hmmm... I have not toyed with the GPT yet. If I ever find an explanation as to why it did not work, I'll let you know... I suppose you're happy with your Arduino solution anyway, 8 EUR for the hardware - that is not a lot of "programmer's time" ;-)

Have fun with your project!

schmidmi
Posts: 52
Joined: 01 Dec 2016 16:45
Location: Germany (Karlsruhe)

Re: Z-UNO blocked after several hours of operation

Post by schmidmi » 04 Oct 2017 11:50

Yes, I tried a lot of things with the GPT, but it was not working as expected. I'm rather sure, that there is or was a problem in the GPT firmware too.
Another reason could be, that the write access to an output pin is too slow to react within a timescale of a few hundreds microseconds.
But as you say, it's not worth the time...
And the difference are exactly the 8 EUROS. All other investment would be the same. And the most important thing is, that it is working perfectly (at the moment on my breadboard :P )

MastrUsr
Posts: 11
Joined: 13 Sep 2017 18:54

Re: Z-UNO blocked after several hours of operation

Post by MastrUsr » 04 Oct 2017 16:56

*Off-topic*
Sorry for hitting the thread but I'm too new to send pm's. schmidmi, I'd very much like to put together my own A/C controller. Is there a post i can read of that project?
*Off-topic*

schmidmi
Posts: 52
Joined: 01 Dec 2016 16:45
Location: Germany (Karlsruhe)

Re: Z-UNO blocked after several hours of operation

Post by schmidmi » 05 Oct 2017 16:14

@MastrUsr:
I've sent a PM to you :)

pjpankhurst
Posts: 31
Joined: 07 Sep 2017 00:40

Re: Z-UNO blocked after several hours of operation

Post by pjpankhurst » 25 Oct 2017 23:27

As a general observation here, you really shouldn't be running all that code in the interrupt handler, whilst it may appear to work on the face of it doing it that way, I would say its asking for trouble and you may well get some weird side effects that aren't immediately obvious.

I'd recommend setting a flag in the interrupt handler so that you can then process it asynchronously in the main loop

Post Reply