forum

Posted: **23 Nov 2017 08:27**

I've had a z-uno wired into my bedroom fan for a little while now and it was working fine until one day it stopped. I have to connected to my Samsung SmartThings hub with a custom device handler running. Now the z-uno (and my code) still receive commands but does not appear to send any reports back. My getter functions are still being called though but it doesn't seem like they make it to the hub. However if I reset the Z-Uno (either with the button or power cycling), it will get an initial report off. You can see the code here. Excluding and including the Z-Uno seemed to fix the problem but after a few restarts it stopped working.

Here's the serial output when trying the turn the fan on via Z-Wave:

Code: Select all

setPower(255)
getPower() # => 0
getPower() # => 0
setPower(255)
getPower() # => 0
getPower() # => 0
powerValue is now 255 (ON)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
setPower(255)
getPower() # => 255
getPower() # => 255
speedValue is now 1 (LOW)
getSpeed() # => 1
getSpeed() # => 1
setPower(255)
getPower() # => 255
getPower() # => 255

As you can see it's just calling setPower and getPower over and over. And after I tried a dozen times to exclude it and then including it back in, it works as expected for a bit:

Code: Select all

setPower(255)
getPower() # => 0
getPower() # => 0
powerValue is now 255 (ON)
getPower() # => 255
getPower() # => 255

Any advice on debugging the Z-Uno or has anyone encountered this before? I also find it strange I need to triple press the service button many times trying to exclude it from my network. What's up with that?

Posted: **23 Nov 2017 11:52**

I've had a look at your code and I see you have a really big decision tree, an external device, and of course getters and setters can be called at any time, so lots of possibilities. My poor little brain has a hard time reading this, but I'll try.

Your getter and setter use different variables, this is a starting point for me. I am thinking out loud, please bear with me...

Code: Select all

byte getPower() {
  Serial.print("getPower() # => ");
  Serial.println(powerValue);

  return powerValue;
}
void setPower(byte value) {
  Serial.print("setPower(");
  Serial.print(value);
  Serial.println(")");

  changePower = true;
  targetPower = value == 0 ? POWER_OFF : POWER_ON;
}

So it is no surprise the getter and setter can report different values.

If your controller sets the speed, this is what happens:

Code: Select all

if (changePower) {
    if (targetPower != powerValue) {
      digitalWrite(ONOFF_BUTTON_PIN, HIGH);
      delay(BUTTON_WAIT);
      digitalWrite(ONOFF_BUTTON_PIN, LOW);
      delay(BUTTON_WAIT);
    }

    changePower = false;
  }

I suppose it pushers a button on your fan. Your fan may or may not turn on or change speed, so you have a function to detect this: readState().

Every 50 ms you call this readState, here is a snippet:

Code: Select all

byte readState() {
  byte previousPowerValue = powerValue;
  byte previousSpeedValue = speedValue;

  if (digitalRead(LOW_SPEED_PIN) == HIGH) {
    powerValue = POWER_ON;
    speedValue = LOW_SPEED;
  }
  ...

I think that is the ONLY part of the code that sets powerValue, used in the getter.

If I understand this correctly, the setter "pushes" the button on the fan then the "getter" reflects the true state of the fan. So it depends on how fast your external device responds. Without timing information on your debug output, I cannot tell if this is correct.

If I where you, I'd add (a lot) more debug printing and see if you can figure out the sequence of events.

If your hub keeps sending the same setter value in less than about one second, it might also be a communication problem. If the controller does not hear an ACK within a certain period of time, it will repeat its last message.

Posted: **23 Nov 2017 23:06**

I don't think that the hub is actually spamming the commands to the Z-Uno. While I was working on the code I saw the normal behaviour and it would only ever send the set once and then poll every second for the status. That's why I think something is going wrong on the Z-Uno and it's just getting caught in a loop and spamming my code. That plus I cannot exclude it reliably but once it is excluded, it gets included with no issue.

I didn't want my code to lie to the Z-Wave hub and it seemed to be okay with that because it would poll until the value actually changed and to me that seems like a reasonable thing to do like if this was a dimmer it would update the value as it was changing instead of reporting the ('fake'/)target value. That said, I'll try running my code and returning the target values but I doubt that will change anything.

Posted: **23 Nov 2017 23:14**

I am sorry if I caused confusion. I do not want your code to return the target value! I was merely trying to understand your code! You are actually doing it correctly! As stated by Z-Wave spec, your getter should return the situation at the moment of the request. It should not return some future value. So please do not change it.

But I do think adding more debug printing might show where and when your Z-Uno fails.

Posted: **23 Nov 2017 23:23**

Today I posted a script with lots of debugging info. It also prints timestamps, so it is easier to see how fast or slow things are. Maybe it can inspire you.

viewtopic.php?f=3427&t=25768#p71723

Posted: **24 Nov 2017 00:25**

Gotcha. Then yeah you are understanding correctly. I've soldering to the fan's PCB and can simulate pressing the 3 buttons. My code does that (waits for micro) then reads the state. Rinse and repeat. That while loop did lead to a fun infinite loops when the fan starts up because it always starts at medium speed and then changes to the previous speed so my code would just keep pressing the button and it would beep.

It's hard to capture the moment it fails because it seems to break between power cycles. So when I remove my USB cord and plug it into AC (Z-Uno is using the 5V rail from the fan PCB) it often breaks then. Is there a way to get debug logs from the Z-Uno itself?

Posted: **24 Nov 2017 09:21**

That is good news. Yes, you can get debug output with the addition of a bit of inexpensive hardware and without powering your Z-Uno through USB. Please give me some time, I'll make a document with explanation, pictures and links... As far as I can tell, it cannot be done over the radio, only via UART.

Maybe it has to do with noise (on the supply, on an input), maybe it is a level translation issue between input or output. Maybe it is a timing issue or the fan controller does not always respond the way you think it does... It is hard to tell.

Maybe add code to detect if something does or does not happen within a certain amount of time? Or maybe do not do that right now, becausse adding this increases complexity on top of something that misbehaves and is not yet understood why this happens...

Posted: **02 Dec 2017 18:02**

I have had similar, but not exactly the same issue of the controller communication failing (HomeSeer). During a power cycle the initial setting would be sent and received, after that there would be no further communication, the getter function was called but the controller never seemed to receive the data. The main difference is the system would work fine if it was reset rather than power cycled. I added a 1 sec delay at power up to see if there was any fluctuations that might be causing an issue, it made no difference.

Moving the initial send report from setup() into the top of the loop() function stopped the problem. This required making another loop using while(true).

Can't really explain this as if there was an problem with the system I would expect more reports, possible just an issue with some boards or implementations.

forum

Z-Uno not sending reports properly

Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly

Re: Z-Uno not sending reports properly