Home » Archived » Eclipse SmartHome » System Battery Channel(Why it is not a number)
| | | | | |
| Re: System Battery Channel [message #1699342 is a reply to message #1699286] |
Tue, 23 June 2015 13:48   |
 Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Kai Kreuzer wrote on Tue, 23 June 2015 10:05>
> I would suggest that there should be a battery level in addition to the low battery warning...
Note that all devices are free to offer such a channel - this is the normal case in general. I am VERY reluctant to add new system channels, especially if there is already a more generic one in place (like for the battery).
What is the reason for having 'system' channels? In my mind, it's to provide some commonality, so that the UI (and other parts of the system) can treat things in a standard way. If we just say that everyone can create their own channel, then we loose this commonality.
I can understand not wanting to generate loads of channels, and to use a generic channel where possible, but in this case, the channel should be the most generic, so that it's most useful. Applying this to the battery, I would then agree with @Smart Home that the battery should be a number, and not a switch. Then, for the stated majority of devices that only support a battery low indicator, they can set this to 0% or 100%, but for those devices that do support a more detailed reading, it can be used.
|
|
|
| Re: System Battery Channel [message #1699362 is a reply to message #1699342] |
Tue, 23 June 2015 15:44 |
Mark Clark
Messages: 4
Registered: January 2014
Location: California |
Junior Member |
|
|
I agree with Chris and @Smart Home, battery level should be represented as a Pct value, not a binary "good-bad" style value. If needed, the spec can recommend an interpretation of this value so that folks dealing with Legacy battery devices, that don't support rich usage values, can be appropriately mapped to UI's (and/or simple rule engines)
ie. Above 50% Green
ie. 50% or less Orange
ie. 20% or less Red
My modern devices support a notion of battery level (Phone, Z-Wave devices, My Laptops, iPads) and it's my legacy devices lack this support (my Alarm System's Wireless Zones). For the latter case, I map them to the Battery Level/Pct values to normalize the Rule scripting (at least, that's what I do in my older HA Controller - where it's the UI that simplifies the presentation of this data, not the Data-Model)
The other upside of a Battery-level/Pct is that you often get warning ahead of when the batteries actually need to be changed, and this can be scripted against as well (eg. warning Emails before the "I'm 30 seconds from death" event) 
|
|
| | |
| Re: System Battery Channel [message #1700659 is a reply to message #1700610] |
Mon, 06 July 2015 09:31 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Well, I do not agree to the arguments above. While it is true that a pct value provides many more possibilities for different devices to map into it, it at the same time increases the "fuzziness" of the meaning of this channel. The whole idea of the system channels is that they have VERY CLEAR semantics. A "I'm low on battery" switch channel imho fulfills this requirement: If it is on, you can blink a battery symbol in the UI, you can send a push notification to replace batteries asap, etc. Having a "0%" instead, does not tell me anything specific: Is it 0% because the device can only report ON/OFF and thus maps to 0%? Or is the battery already dead because I did not replace it in time?
Note that the system channels are a lowest common denominator. If a device is battery-powered, it should almost always be able to provide a low-bat information. If it also can report a battery level: Fine, it can have an additional pct channel with #battery tag.
> My modern devices support a notion of battery level (Phone, Z-Wave devices, My Laptops, iPads)
Imho this is not the case for usual HA hardware. If you look at the curve of NiMH batteries (http://www.stefanv.com/electronics/using_nimh/nimh_vs_alkaline.gif), you will see that there is no chance for a simply device to determine any sensible value for its battery level. Only devices with a cpu-powered charging mechanism (like your iPhone) can algorithmically provide this. This again means that the "meaning" of pct values is more like guessing and every device will do it completely differently. The only thing they can REALLY determine is whether they are running low or not.
Just my 2 cents,
Kai
|
|
|
| Re: System Battery Channel [message #1700702 is a reply to message #1700659] |
Mon, 06 July 2015 14:32 |
Mark Clark
Messages: 4
Registered: January 2014
Location: California |
Junior Member |
|
|
The last project team I worked with did extensive work building a product that operated with different battery chem's, so I became familiar with the HW & SW issues.
... and still our device recorded/transmitted it as a percent battery usage (along with raw Volts), and it was the UI that dumbed-down the value for the user, not the internal data model.
It was this difference between battery chem's that triggered us to record the lower level values in order to provide the raw data (V and calibrated %) to enable the customer/user to make decisions based upon their specific deployment needs.
eg. frequency of transmission vs field-deployment lifetime
Internally we experimented with using LiPo vs NiMH vs straight Alkaline's for the core power (backed by super-capacitors) since the device had to run for months on Batteries, and we needed to provide meaningful data to the CT's (as well as internal HW & SW eng)
For field-deployment the device (UI) simplified this by presenting a coloured-LED, at the appropriate time, but the raw (Volt & %) data was bubbled up to the customer for use in their dashboard & alerting (for logistics folks, mostly).
> Imho this is not the case for usual HA hardware.
There have been analog was to do this for a long time, I was doing it as a kid before the chips became available to do it.
IMHO it's more of a question of weather we want software standards built around the lowest-common denominator, or something that'll address a broader requirement.
Unfortunately, the last version of IPSO SO I read didn't cover this [practical] level of measurement, so I don't have a standards body to point to, just the practical examples I see around me.
|
|
|
| Re: System Battery Channel [message #1700754 is a reply to message #1700702] |
Mon, 06 July 2015 19:40 |
John Cocula
Messages: 21
Registered: June 2015 |
Junior Member |
|
|
I worry that a binding developer, presented with a voltage or percentage of battery level from a source, will be encouraged to present an "ok/replace" value, when they really have no idea what they're supposed to base it on, and having no access to reliable answers. And so you will end up with bad guesses, all different from one another, per developer.
I also worry, more generally, that a rigid model for things could lead OH2 into a similar place as Vera with their UPnP model, where pre-conceived notions of composite devices and their semantics just doesn't fit the real world very well. This is not to discount all that has been done to avert such a corner, but for example, Vera hurt themselves by making rigid declarations like "all thermostats really only have one setpoint," when in fact it's not true. They broke lots of user-contributed code just for a pretty UI that doesn't work any more. That's all I'll bang on about on this subject, but please don't go there!
|
|
|
| Re: System Battery Channel [message #1700757 is a reply to message #1700754] |
Mon, 06 July 2015 20:09 |
Dennis Nobel
Messages: 166
Registered: September 2014 |
Senior Member |
|
|
Quote:IMHO it's more of a question of weather we want software standards built around the lowest-common denominator, or something that'll address a broader requirement.
When building is a smart home system the hardest decision is always on which level to draw the abstraction layer. Of course you could take Number with percentage or even be more precise with voltage. But there are definitely a lot of devices out there, which only provides "low battery" state. If we would decide to take number as the abstraction, what value should these bindings provide? 100% for "no low battery" and 10% for "low battery"? This actually leads to wrong values and wrong expectations. So I agree with Kai, that it makes sense, that the system channel is a boolean only and each binding, that supports more accurate values can make a good decision when to indicate low battery and for sure also define an additional channel with percentage or voltage.
Quote:I worry that a binding developer, presented with a voltage or percentage of battery level from a source, will be encouraged to present an "ok/replace" value, when they really have no idea what they're supposed to base it on
I´m sure that a binding developer can at least better decide what will be "ok" or "replace" than an average user, if he only sees a voltage value. In my HomeMatic CCU2 I can see a voltage value, but I have really no idea if the battery is fine or not. What Eclipse SmartHome does with all the new APIs is trying to avoid guesses from the user. The system should at least provide the possibility that also unexperienced, non-technical users can use it.
Quote:I also worry, more generally, that a rigid model for things could lead OH2 into a similar place as Vera with their UPnP mode
Eclipse SmartHome does not define a common model for different devices. It only provides a meta-model, so that each developer or manufacturer can describe their devices. One of the main differences compared to other Smart Home models is, that we don´t have a device ontology. We only provide an abstraction of functionality on a very high level. That´s why you can´t find something like a thermostat, an oven or a lamp in the smart home abstraction model.
Regards
Dennis
|
|
|
| Re: System Battery Channel [message #1700761 is a reply to message #1700757] |
Mon, 06 July 2015 20:44 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Quote:
you will see that there is no chance for a simply device to determine any sensible value for its battery level
Firstly, this is incorrect. It is possible to establish this with 'some' accuracy - it may not be perfect, but there are plenty of models available to do this without a 'fuel gauge' type system. Measuring and displaying voltage is, I agree, not particularly meaningful, but that's not to say that a reasonable battery capacity can't be established through voltage monitoring.
Secondly, we shouldn't have to decide if a manufacturer is doing a good job of designing their device and providing a 'sensible' value (I would hope most are  ). I would like to think that manufacturers have spent some time understanding how their device works and are providing information that IS useful to the user. Also, often a manual might explain when to change the battery...
Quote:
Of course you could take Number with percentage or even be more precise with voltage
I don't think voltage would be a good idea! Displaying voltage definately doesn't provide any indication of capacity or life to the user as there are so many battery technologies in use - unless you add a battery model or gauging algorithm behind it the information doesn't equate to life. We should be providing a useful indicator of remaining life - it doesn't necessarily have to be perfectly accurate - just useful. Also, from what I've seen, not too many devices provide a voltage reading - it's more often percentage or some other relative scale...
I log the battery levels on my zwave devices, and in general they are reasonably linear. They do go up and down a little, so they are probably linked to battery voltage, but it's not a direct reading, but a modelled output. Is it accurate - probably not - is it a good representation of life - yes.
Anyway, I get the impression that we're not going to change this. I'm perfectly happy to have a low battery indicator, however I think that as this is common information for battery devices, that an additional system channel should be added. If we leave it to everyone to invent their own channel name, we might have a different one for every binding, and then it's of little use to a UI that might want to display battery state in a consistent way (with a simple gauge icon for example). If system channels aren't meant for common data that would be provided by multiple things/bindings, then I'm not sure of their purpose?
Chris
|
|
|
| Re: System Battery Channel [message #1700853 is a reply to message #1700761] |
Tue, 07 July 2015 15:24 |
Mark Clark
Messages: 4
Registered: January 2014
Location: California |
Junior Member |
|
|
Quote:I agree, not particularly meaningful, but that's not to say that a reasonable battery capacity can't be established through voltage monitoring.
And that's exactly what we did. I referenced Voltage to provide background as to how the % was calculated/derived. I don't suspect it would be exposed to end-users, since it's not that meaningful.
I know people that are using the Battery % values from their HA devices, along with some historical data for that device, to make intelligent decisions about when to change batteries.
In one case it's for their Vacation Property, where they're not present often, in another it's for Managed Rentals. ... But I can also see cases for Managed (Elderly) Care properties.
They avoid the need to know whether level X is good and Y is bad, since they can (and do) interpret the % level based upon historical state information.
This is also important for intelligent homes where the user may not always be present and/or capable of changing out batteries when they bail out.
I've left the house (for travel) only to have the Battery alarm go off on one of my Panel sensors (Paradox Alarm sensors typically go off with <24 hrs of life left). Had I known a relative-battery-level before I left, I would have swapped out their batteries rather than being blind to the issue (motion in the front yard, as it turned out).
People are already used to fuzzy values in this space (Dimmer levels anyone?) I don't think it's an issue when it's intended for intelligent automation.
PS: If we're worried about fuzzy logic, you definitely don't want to look behind the curtains for how folks are calculating their current good/bad indicators
|
|
| | | | | | | | | | |
Goto Forum:
Current Time: Fri Apr 26 03:35:51 GMT 2024
Powered by FUDForum. Page generated in 0.03619 seconds |
] 
Search
Help
Register
Login
Home
