Page 4 of 5

Re: New 2.1.4 beta

Posted: 03 Jul 2018 02:55
by Tillsy
OMG..... OMG...... OMG.....

This very thing was doing my absolute head in a few months ago - totally and utterly doing my head in. It made so little sense and I got so %^&*#^$# with it that I reverted to using old fashioned relays instead of the optocouplers.

So it was a bug with the Z-Uno all that time...?

Re: New 2.1.4 beta

Posted: 03 Jul 2018 12:58
by Riri
Hi,
No all the time, some pin works, other not.
No need to pass by relay, a pullup resistor to 3.3V suffice.
The electrical schema is :
tlp.png
tlp.png (96.52 KiB) Viewed 8725 times
But it overloads everything!
Eric.

Re: New 2.1.4 beta

Posted: 10 Jul 2018 18:42
by p0lyg0n1
Hi,
First of all. It's a software problem. I hope we could resolve this in the next beta, but it's a good practice to use 100KOhms pull-ups to economy power for battery supplied devices instead of internal pull-ups (about 10 KOhms).
I misunderstood what do you mean about "overload". It have to work with 4.7K normally. If you have some issues with it, please report.

Alex.

Re: New 2.1.4 beta

Posted: 10 Jul 2018 19:36
by Riri
Hi,
Big thank for your answer. really nice.

I meant by "overload" that it is the electrical schematics that will have to have more resistance for each input. It's only that.
No electrical problem. And I confirm that with 4.7K external pull resistors all inputs work perfectly.
I'll wait for your update, just that will allow me not to redo all my drawings.
and I can simply test with my schema at least 15 inputs, if you want.
Really thank you for your listening and impeccable follow-up, and really good job with this z-uno.

I have some problem with incude with eedomus box and i contact them for this issue.
The z-uno is detected instantly but the channels are poorly paired. and the number of channels that works is never the same.
I have test with 15 channels and it's very delicate for include the 15 channels.
We get there but it's very very long

Eric.

Re: New 2.1.4 beta

Posted: 11 Jul 2018 13:16
by Riri
Hi,
I found a another issue with the compiler and S2 security.
The burning of the bootloader is going very well, and when l load the program to the z-uno we have a mismatch error.
I did the test with compiler 1.6.5 and 1.8.5 and it's the same problem.
It works very well with version 2.1.3.

With 2.1.3 :
2018-07-11 (1).png
2018-07-11 (1).png (53.75 KiB) Viewed 8650 times
With 2.1.4 :
2018-07-11 (2).png
2018-07-11 (2).png (45.13 KiB) Viewed 8650 times
Is there anything else to do with 2.1.3?

Param :
2018-07-11 (3).png
2018-07-11 (3).png (37.5 KiB) Viewed 8650 times
Thank.
Eric.

Re: New 2.1.4 beta

Posted: 14 Jul 2018 17:44
by p0lyg0n1
Hi, we work on the pullup issue. S2 issues was in the first beta. Could you check that you use "the last" beta and have this issue too? I couldn't reproduce it on my build.
Thank you! You really help us a lot!
Alex.

Re: New 2.1.4 beta

Posted: 15 Jul 2018 11:03
by Riri
Hi,
Really with pleasure, this z-uno is great. And thank you for all these developments.
Great for pullup resistors, I hope it will not be too complicated.

For S2 issues, I just reproduced the problem with the latest beta (by remove all from packages/Z-Uno & staging/packages and reload board from test-ucxx repository). The compiler is 1.8.5.
I Restart Arduino IDE.
I change the card type, the frequency (europe), the security (S2) and the programmer.
I upgrade the bootloader first and ok.
I upload the sketch just after and error.

it does not matter to me because I'm not going to use security, but maybe it can happen to someone else :)
2018-07-15 (1).png
2018-07-15 (1).png (103.21 KiB) Viewed 8601 times
Thank you for your reactivity
Eric.

Re: New 2.1.4 beta

Posted: 22 Jul 2018 16:10
by niles23
Hello!

I have problems with the BatteryHandler. I can't FLIRS and an own battery handler:

Code: Select all

ZUNO_SETUP_SLEEPING_MODE(ZUNO_SLEEPING_MODE_FREQUENTLY_AWAKE);
ZUNO_SETUP_BATTERY_HANDLER(getBatteryVal);
    byte getBatteryVal() {
      // 100= "> 12,8" bzw. 0 = "< 11.5"
    
      byte percents = 99;
    
      if ( percents > 100 )
        percents = 100;
    
      return percents;
    }
--> error: member reference type '_xd_ZUNOChannelHandler_t' (aka 'ZUNOChannelHandler_s') is not a pointer; did you mean to use '.'?

To verify it, I added my lines above to the example "simple switch":

Code: Select all

/*
 * That is a Simple Sensor Multilevel example
 * It measures the value on the potentiometer
 * And sends report to the controller if changed
 */
 
// LED pin number
#define LED_PIN 13


// Last saved LED value
byte currentLEDValue;

// next macro sets up the Z-Uno channels
// in this example we set up 1 switch binary channel
// you can read more on http://z-uno.z-wave.me/Reference/ZUNO_SWITCH_BINARY/
ZUNO_SETUP_CHANNELS(ZUNO_SWITCH_BINARY(getter, setter));


    ZUNO_SETUP_SLEEPING_MODE(ZUNO_SLEEPING_MODE_FREQUENTLY_AWAKE);
    
    ZUNO_SETUP_BATTERY_HANDLER(getBatteryVal);
    
    byte getBatteryVal() {
      // 100= "> 12,8" bzw. 0 = "< 11.5"
    
      byte percents = 99;
    
      if ( percents > 100 )
        percents = 100;
    
      return percents;
    }




void setup() {
  pinMode(LED_PIN, OUTPUT); // setup pin as output
}

void loop() { 
  // loop is empty, because all the control comes over the Z-Wave
}

// function, which sets new relay state
// this function runs only once the controller sends new value
 void setter (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 LED on
  } else {            // if equals zero
    digitalWrite(LED_PIN, LOW);   //turn LED off
  } 
  // let's save our value for the situation, when the controller will ask us about it
  currentLEDValue = value;
}

// function, which returns the previously saved relay value
// this function runs only once the controller asks
byte getter (){
  return currentLEDValue;
}
is this a bug or am I doing something wrong?

Thank you guys!

Re: New 2.1.4 beta

Posted: 23 Jul 2018 01:28
by PoltoS
Looks like a bug. We will check it

Re: New 2.1.4 beta

Posted: 23 Jul 2018 12:51
by Zixwater
PoltoS wrote:
02 Jun 2018 19:22
This build introduces new channel types and cool features.

You can get it from our test repo: https://z-uno.z-wave.me/files/z-uno/tes ... index.json

What's new:

New features
  • If only one channel, MultiChannel will be supressed (Command Classes outside channel will represent your single channel)
  • Three new channel types: Color Switch, Thermostat and Door Lock
  • Handling of incoming reports from other devices. Handled reports are Basic/Sensor Binary/Alarm/Sensor Multilevel/Switch Binary/Switch Multilevel/Battery/Meter.
  • New inclusion mode: double click for unsecure inclusion, triple click for secure (as it was before). New security parameter added to zunoStartLearn(timeout, secure)
  • Two new functions: tone() and noTone()
Bug fixes
  • Fixed multiple ADC influencing each other
  • Fixed OTA (broken since 2.1.3)
  • Fixed interrupts handlers inside libraries (was broken since 2.1.3)
  • Fixed compiler diagnostic messages if a too big sketch is uploaded. Before it was silently ignored.
We are starting two weeks beta period and then we will make a public release.
Is it possible to supply a string/char value when setting up channels to describe/setting a name because currently I'm only getting "Z-wave.Me..." names. Or have I missed a release with this feature?