Battery Reports and Fibaro HC2

[Gotty101]

Hi im building my own bind controller using my zuno and its working well in FLIRS. The only problem im having is the battery reports. Ive setup the ZUNO_SETUP_BATTERY_HANDLER() (as im using a external regulator) and it pairs fine with my Fibaro HC2.

Ive also setup zunoSetBeamCountWU(240) to get the device to push reports incase HC2 stops talking to it for some reason.

Im guessing with the ZUNO_SETUP_BATTERY_HANDLER() 0 = battery empty and 255 is full as thats how ive got it?

The issue is when i pair the device and ive got my bench powersupply set so ZUNO_SETUP_BATTERY_HANDLER() returns 255 the battery shows full in HC2, when i lower my bench supply HC2 reports the battery is low which is good. But when i raise the voltage back to simulate a full battery (as if its charged back up) HC2 still reports a low battery.


Many Thanks

Trev

[petergebruers]

Haven't tried this myself, but... According to the Z-Uno docs:

https://z-uno.z-wave.me/Reference/ZUNO_ ... Y_HANDLER/

I quote "name of the function returning % value as a BYTE"

It doesn't clearly state so but I interprete that as a number between 0..100, as that page starts by saying "By default Z-Uno automatically maps battery voltage from 2.8V–3.0V to 0%–100% measuring the voltage on the 3V pin."

I would not use 255 for another reason, th Z-Wave spec says (see SDS13782 Z-Wave Management Command Class Specification.pdf)

4.10.2 Battery Level Report Command
This field MUST be in the range 0x00..0x64 or set to 0xFF.
Values in the range 0x00..0x64 MUST indicate the battery percentage level from 0 to 100%
The value 0xFF MUST indicate a low-battery warning.

So 255 is special but actually for instance OpenZWave considers a 0 or 255 reported both to mean "empty".

[Gotty101]

Thanks for the reply Peter. I had tried 0 to 100 at first (as i assumed it was the same as a multilevel switch setter) but i dont think it was working right either, but it may have been me being dumb. Also like you say that PDF says it should be 0 to 100.
Ill try again in the next day or so and report back. Fingers crossed it does.

Thanks again

Trev

[Gotty101]

Hi Peter,

Ive swapped the code back to the one that reports the battery percentage in the range of 0 to 100 and varied the bench supply before report 1 is sent (the sketch just has one control of:
ZUNO_SETUP_CHANNELS(
ZUNO_BLINDS(getterBlindPos, setterBlindPos)
);

just before i send the device to sleep in the main loop i check the voltage, then send the report and delay 500ms before calling zunoSendDeviceToSleep();

Im my main loop i enabled the debug prints the percent value is the actual output from the battery get code that should normally report the battery percent.


byte getterBatteryVal() {
float usable = (batteryMaxVoltage-batteryMinMotorVoltage);
byte percents = ((currentBusVoltage - batteryMinMotorVoltage)/usable)*100;
if(percents > 100){percents = 100;}
else if(percents < 0){percents = 0;}
return (byte) percents;
}

these are defined as constants at the top, they are used for other things in the main code
const float batteryMaxVoltage = 7.4;
const float batteryMinMotorVoltage = 5.6;

So you can see in the screen shot the current buss voltage was at 5.70v resulting in a reported 6% battery value, but fibaro is not showing that. The only time fibaro seems to correctly show it, is if i unpair and re include the device.

Ive even tryed this

byte getterBatteryVal() {
return (byte) 50;
}

and fibaro still report the same value as when it was originally paired. The little scroll bar displaying the blind position correctly updates if it alter the blinds position using physical buttons attached to the zuno so reports must be beeing sent to the controller, and its defiantly in FLIRS as all the LEDs go out and it only wakes up on the BEAM time out or zunoSetWUOptions(ZUNO_WUPFLAGS_INT1_HIGH)

Battery report.png (707.38 KiB) Viewed 9323 times

Any ideas?

Only last thing ive spotted but i haven't done any debugging yet, after pairing the device by pressing the service button 3 times, the unit does not go back to sleep, and i have to press the reset button on the zuno to resume normal functionality. Is there something i need to do? Im guessing i could detect a "ZUNO_LOGGING_EVENT_LEARNCOMPLETE" event and tell the zuno to reboot in code but is the way its currently working normal before i implement any code?

Appart from that my code seems to be working well, just going to bench test it for a few weeks now before i move forward but would like to get battery reports sorted first.

Many thanks

Trev

[petergebruers]

I haven't used my Z-Uno in while and on top of that haven't used "battery level" in... say... 2 years? So time for me to catch up with current firmware. I haven't tried to update my FLiRS code, I try to avoid batteries, but it should work.

Tough to diagnose without tools.

Would be easier if we get access to HC logfiles but that is not going to happen I think.

I might be able to setup a minimal test, I own both Z-Uno and Zniffer.If you are serious about Z-Wave I recommend you by a Silabs UZB3 dongle (about 30$) and follow this guide (you'll have to register to see content)

https://forum.fibaro.com/topic/29923-tu ... ent-147847

Another possibility is you try to compile for instance http://www.openzwave.com and ozwcp but then you would have to learn to read the logfiles. Nah. Not quick solution either.

Can't you enable some sort of logging in the Arduino Z-Uno menu?

When you remove the custom battery code, exclude and include, does the standard reporting 2.8 to 3.0 V work?

Also toy with the "S" and "M" columns in the "association" panel, the ones next to your controller. I'd set both for testing.

I own 4x FGT-001 which are Fibaro FLiRS and they do have battery status, so batteries and FLiRS seem to work on HC2.

[petergebruers]

I ran a few tests and I would not jump to conclusions, but I think I know where this is going... It might be a problem we're stuck with...

What I did was adapt an older sketch of mine, and add

Code: Select all

ZUNO_SETUP_BATTERY_HANDLER(my_battery_handler);

byte my_battery_handler() {
  LoopCount10ms=0;
  NZRAM.get(FakeBatteryLevelAddr, &FakeBatteryLevel, 1);
  PG_DEBUG_LOG_DOTNEWLINE("my_battery_handler called, data to controller = ", FakeBatteryLevel);
  decrement_fake_battery_level();
  return FakeBatteryLevel;
}

decrement_fake_battery_level makes the level loop from 100 ... 90 to zero and bacl again.

It is also in the INT1 handler, so I expect that value to change each time the Z-Uno request battery level, and also when I push the button.

I then use OpenZWave to check the device. It shows battery level and on/off state of my device after inclusion.

Here's the interesting bit... The INT1 changes the value on the ZUno, but the ZUno does not report.

In OZW I hit the "Refresh" button. It gets updated and decremented once.

This is not a surprise if you look at the OZW_Log.txt (edited)

Code: Select all

2019-11-17 17:49:31.822 Info, Node017, Sending (Send) message (Callback ID=0xba, Expected Reply=0x04) - BatteryCmd_Get (Node=17): 0x01, ...
...
2019-11-17 17:49:31.880 Detail, Node017,   Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x11, 0x03, 0x80, 0x03, 0x28, 0xd0, 0x00, 0x99
2019-11-17 17:49:31.881 Detail, Node017, Refreshed Value: old value=70, new value=40, type=byte

You see? OZW has to ask the value (BatteryCmd_Get) and the ZUno replies and old value=70, new value=40 in this case is correct because I also triggered INT1 twice.

Preliminary conclusion: it looks to me as if the FLiRS mode does not have a set interval to report battery level. This makes sense because it acts as if it is an always on device (almost... cannot act as repeater and needs BEAM to wake up). If it was a true battery device, it would have a "wake up interval" - set by the controller and maybe, just maybe, I haven't checked, the ZUno would report battery at each interval automatically. I see no equivalent to "zunoSendReport" for battery level.

I have not been able to run longer tests, and not even a single test on HC2 yet, but I make some educated guesses. The HC2 gets the level at inclusion time. All gateways do that, it is part of the "interview(ing) of the device". But after that, it never asks battery level again. And if I am right, the Zuno never sends one. But as you can see, OZW can "refresh" aka "poll" that device and you can schedule that, so it would work. The HC2 supports "polling" too but here I see a problem... last time I tested that on my FGT-001 it did not work. There is no "poll" button on this type of device and a Lua command to manually poll does nothing on an FGT-001. I checked that a few months ago, ideally I should recheck.

If I find the time, I'll now include this device on my HC2 network and see if I can poll it. Maybe this week.

[Gotty101]

Hi, i would really like to thank you for all your help with this. It looks like you hit the nail on the head.

If it is the case it seems crazy that a flirs device (one would assume its made as a flirs device to conserve power ie battery powered) that battery reports would not be key in the day to day process of the device.

with regards to doing a HC2 test, i dropped the power on my bench supply and clicked the "Read configuration" button and when the screen refreshed i got a low battery, i then upped the supply back to full and did the same and the voltage went back up.

HC2.png (85.32 KiB) Viewed 9247 times

So i think this helps prove what you said. Thing to work on now is a way to automate hc2 to do a "Read configuration" on each of my blinds if i get this project dialed in say once every 24 hours.

Thanks again

Trev

[petergebruers]

You can automate that, the command is hidden but works...

Lua

a,b=api.post("/devices/899/action/readWholeConfiguration")
fibaro:debug(a)
fibaro:debug(b)

The 899 is the master ID of your device, the a and b are status messages, not too important.

There is a downside: it causes a lot of traffic, it really interviews the device (command classes, associations, parameters, ...)! It keeps your device awake for a while (about the time it takes for that popup to appear).

But it might be acceptable if you do that only once every 24h

[Gotty101]

Hi Peter, thanks again for all your help with this.

Ive done a LUA script for my HC2, only got one node so far but the idea is i add the ids into the blinds array and it will issue the commands out. Not sure if i need to add hold offs between the calls yet. But then i can set it to run once a day. Such a shame that the battery state cant be pushed on from the Zuno (i know its a ZWave thing). Im going to do more bench testing of my device. Ive got it saving the Config to eeprom should the power go, should it go well Ill look to get a Zuno Module and design some PCBs

Code: Select all

fibaro:call(11, 'sendPush', "Battery Poll started")

local blinds = {89} --IDs of blinds to poll 
local nrblinds = #blinds --nr of blind devices listed above
local curblind

for i = 1, nrblinds do 
  	curblind = tonumber(blinds[i]) 
  	fibaro:debug('device:'..curblind)
  	a,b=api.post("/devices/"..curblind.."/action/readWholeConfiguration")
	fibaro:debug(a)
	fibaro:debug(b)
  
end

Trev

[petergebruers]

I would add a 30 second delay. I don't think there is an easy way to monitor the progress (there is a log at the top in the status window, so technically speaking there is "something").

I know the guys from Z-Wave.me follow this forum, they will chime in if there is something interesting to be said...

Nioe project btw, interesting application of a FLiRS.

What average stand by current do you get? The sketch I wrote long ago used about 70 uA.