FLiRS - zunoSetBeamCountWU() question

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

FLiRS - zunoSetBeamCountWU() question

Post by michap »

Hi,

I have attached a simple sketch showing the problem I have with FLiRS device.
Want to set a pin to "HIGH" using controller and reset it after 10 seconds to "LOW" (as sample).
Using zunoSetBeamCountWU(10) for wake up after 10 seconds to reset the pin - do not want to have the device in waiting state for this time.

So - if pin is "high", zunoSetBeamCountWU(10) will be set, if "low" zunoSetBeamCountWU(0) - no wakeup is required.

I have tried different things, but nothing is working stable as expected.
The output pin will be set to low immediately again.
Looks like if zunoSetBeamCountWU will be redefined then it will called without delay - but not sure about this.

"Sometimes" it is working, (not changing anything) - but in most cases not.

Maybe somebody have an idea how to change it?

Thanks!
Michael
Attachments
flirs_pin1.zip
(616 Bytes) Downloaded 229 times
michap
Posts: 437
Joined: 26 Mar 2013 10:35
Contact:

Re: FLiRS - zunoSetBeamCountWU() question

Post by michap »

Maybe it is something else... by design,... not zunoSetBeamCountWU related.

I have tried the old sample with FLiRS switch:
https://z-uno.z-wave.me/examples/FLiRSSimpleSwitch/

Have replaced the "ZUNO_SWITCH_BINARY" with "ZUNO_FLOWSTOP" - and it does not work.

I think the digital pin status will not be saved when the device is going to sleep mode (FLiRS) - may this be possible?
In such a case a FLiRS switch (sirene, flow stop) must be designed by other way as in sample described (using NZRAM).

Michael
petergebruers
Posts: 255
Joined: 26 Jul 2015 17:29

Re: FLiRS - zunoSetBeamCountWU() question

Post by petergebruers »

I wrote this sketch some time ago:

https://github.com/petergebruers/Z-Uno-FLiRS-LED-DEMO

And I noted:

"If you notice an unexpected "blink" of the LED, this is "by design". The Z-Uno initializes the pins, and it takes some time to get the LED pin back to output. The only way I can think of, to avoid this, is by adding a flip-flop or serial register... I have some ideas, but I have not yet tested them."
michap
Posts: 437
Joined: 26 Mar 2013 10:35
Contact:

Re: FLiRS - zunoSetBeamCountWU() question

Post by michap »

No, I'm not about the blink - this I have noticed also.
But as sample at pin3 and pin4 it seems not to be a problem.

It was my mistake - I have looked at the old FLiRS example (see above) and thought that the state of the pins will be saved - but it isn't.. device is sleeping at all.
So if I need to remember about the last state it should be done via NZRAM.

Question solved ;)

EDIT: not solved - even if remember about state in NZRAM wakeup will be called immediately...

Michael
petergebruers
Posts: 255
Joined: 26 Jul 2015 17:29

Re: [solved] FLiRS - zunoSetBeamCountWU() question

Post by petergebruers »

Thanks for the feedback. Indeed, there are 2 issues with sleep: pin state and NZRAM. Have fun with your Z-Uno!
p0lyg0n1
Posts: 242
Joined: 04 Aug 2016 07:14

Re: [solved] FLiRS - zunoSetBeamCountWU() question

Post by p0lyg0n1 »

Hi, I have an idea. Try to move logic inside the loop instead of handler. Make a small delay in the loop ~5 microseconds. I'll try to check the internals of FLIRS using your sample code till the next release.
michap
Posts: 437
Joined: 26 Mar 2013 10:35
Contact:

Re: FLiRS - zunoSetBeamCountWU() question

Post by michap »

It does not help.

As I thought before - the Wakeup procedure will be called immediately at first, and then again after defined time in zunoSetBeamCountWU(n).
Maybe in some cases it is not critical, but for resetting a state it can not be used.

The only way seems to put a delay in loop() or the Wakeup procedure withe the needed time.
But in this case the chip will be active for this seconds.
Maybe a counter in wakeup procedure can help - so execute the real procedure only on second call.

Anyway I think that wakeup call could be checked.

Thanks,
Michael
Post Reply