Since over a year ago I reduced the load on the PI by removing the USB attached SSD harddisk and putting it elsewhere; total power usage now is 600-700 mA. This PI is (apart from UPiS) connected to one webcamera, one 1-wire busmaster and one Arduino Nano.All work well and power budget should be OK.

But I've had another UPS related mishap (again...) - power is lost for some half hour and the UPiS keep my PI running, but UPiS fail to detect power is restored after 30 minutes!. It keep running on battery (even though mains [USB] is back) until bat level says its time to call FSSD which is made OK, but the unit remain in OFF status until I manually reset it. This is no good! When the PI come back up after resetting the UPiS the battery is fully charged; so the UPiS did eventually decide to start using the power; but it a) never reacted on mains back, b) asked my PI to perform FSSD c) never started it again and d) eventually recharged the battery.

In my opinion, this is not how a UPS should work.

I also see that the since long promised firmware update(s) to UPiS seem to have been postponed another week, or two...... just read your own words on my first complaints... next week, next month... nothing happens.

You don't even have to lose power to not get the battery to charge. I've been running a RPi 2.0 (I think) so it has the older less efficient power regulator. It is being powered by a UPiS basic and has an attached 16x2 LCD display and some hardware that I am gradually coded stuff for (a relay, a 2 channel RC receiver, two USB RFID tag readers - although only one is current connected the other is already glued/cabled in place to the inside of the glass in my front door ) there is also some breadboard with a few transistor driven LED indicator drivers and a reed-switch to emulate the one on the front door frame. As it happens only the LED-circuitry, the LCD display and the one USB RFID reader are powered from the RPi and the reported load is pretty much 0.50A . Under these conditions the setup is stable and maintains the battery in a charged state. However a few days ago I abandoned a coding session but happened to leave a couple of outputs and thus the LEDs switched on and thus drawing a few milli-amps more current. I was surprised to see that the LCD which, as part of the daemons I have coded, cycles through displaying information about the UPiS system, was reporting that the battery was quite low (3.5 Volts or so). Just in case I had accidentally disabled the charger I got the daemon to try and turn the charger off and then on again (by sending "@CHGR OFF" and 30 seconds or so later "@CHGR ON", these were acknowledged but did not change things, the CHR LED did not light up. In frustration I pulled off the connection to the bread-board that was cause one LED to be illuminated and pretty much instantly the CHG LED illuminated, the total current rose to the expected 0.72 miili-amps and the battery voltage started heading upwards as I hoped/expected.

It looks like I am right on the limit with how much current I can draw at just 500mA and hope for the UPiS to work as intended, and a few milli-amps more (2.5mA extra, say from driving a low current red LED) will break things - hang on, though after allowing some minutes I've reconnected the LED and it is illuminated AND the charging LED is staying alight, the total current is now reported as 0.71A and the battery voltage has risen to 3.77V .

tl;dr; The UPiS models will NOT energise the battery charger, even if it is enabled, if the total current demand of the RPi AND the Charger is TOO MUCH, and for the Version 1.00 firmware that limit seems to be very close to 0.72A even though the published limit is 0.75A, if the RPi and associated stuff is taking enough current that the addition of the charger load will exceed the limit then the charger will never switch on - even at a reduced rate (but then the Li-Po charging routine is pretty rigid and must not be under-charged OR over-charged) - no matter how much the battery needs that electron flow...