Announcement

Collapse
No announcement yet.

History failure

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by RoChess View Post
    My suggestion would be to add smart logic that sees the small number per day, and then calculates it for a year, if it is more than 100% then divide by 12 to use months, so for two example values you would get:
    • Average Rate: 0.08% per day (29% per year)
    • Average Rate: 0.72% per day (22% per month)
    For month value to go over 100% the daily value would be high enough rate that it makes no sense to use weeks and more than likely an issue with the device.

    I would round the year/month to integer, because accuracy is not important here, but to get a rough idea on how long the batteries will last.

    If text string becomes too long, then perhaps call it just "Average: 0.08% per day (29% per year)" as it is right below "Battery Rate:...." and within that context it is okay to leave out Rate again for Average, or otherwise go the other way with "Average Rate: 0.08%/day (29%/year)", but that always looks funky even when it is proper notation.

    Think there is enough space for full notation though, and my suggestion would be to just drop " Rate", but will leave that up to you.
    I am playing around with a few options around what information to show and how to show it roughly along the lines of what you are suggesting. I like the idea of keeping the per day, for direct comparison but adding the per month, per year as appropriate. I'll also be adding the ability to override the display of averages for individual devices because I for one will want to turn it off on some devices where the rates reported are meaningless. That's more of a fundamental change so I've been putting it off until I'm generally happy with how it is working.

    Originally posted by RoChess View Post
    Another option is to take another approach and that is to calculate total year/months they would last, so you get:
    • Average Rate: 0.08% per day (~ 3 years)
    • Average Rate: 0.72% per day (~ 4 months)
    The only crux then is do you show "how long will fresh new batteries last" (which is the method I prefer and calculations I used), or do you take into account the battery level the batteries already have and do a rough "this is how much time you will have left"?

    Guess you could add options to offer users to switch between either, but I know how dangerous feature creep is, so I'm only suggesting, and you get to make the tough decision
    The thing about calculating how long the batteries will last is that, like the start level, it brings in the complication of what end level to use as few of these devices run down to a zero level. Whilst I could get smart and perhaps use the trigger level that has been set by the user, or the lowest level before the last battery change, it's all getting a bit complex for something that for many devices will probably yield fairly meaningless results. Even with a device that reports accurately there is significant variance between different types and makes of batteries. Probably about half of my Z-Wave devices report fairly spurious battery levels and one or two stick at 0%. The most useful aspect of the pi for me is alerting on missed wake-ups. The rest of the information is interesting and sometimes useful but not worth getting to sophisticated with.

    Perhaps Z-Wave batter level reporting will one day reach the accuracy that mobile phones achieve but they have much more powerful processing power on board which uses sophisticated algorithms to estimate the battery level.

    Originally posted by RoChess View Post
    Hopefully, for HS4 they will change policy to allow this, especially for developers that have a long positive track record like yourself.
    HS have now granted me access to the Beta section of the updater so that is good news for future testing

    Thanks,
    Steve

    Comment


    • #32
      Originally posted by SteveMSJ View Post
      I am playing around with a few options around what information to show and how to show it roughly along the lines of what you are suggesting. I like the idea of keeping the per day, for direct comparison but adding the per month, per year as appropriate. I'll also be adding the ability to override the display of averages for individual devices because I for one will want to turn it off on some devices where the rates reported are meaningless. That's more of a fundamental change so I've been putting it off until I'm generally happy with how it is working.
      RoChess
      Updated version 3.0.7.5. in the Beta section of the updater.

      See new format in device string, some rewording of the Config page and some explanation on Battery Discharge Rate in the updated guide.
      (//Docs folder)

      Click image for larger version

Name:	Door Bell.JPG
Views:	39
Size:	20.4 KB
ID:	1349768

      Click image for larger version

Name:	Config.JPG
Views:	26
Size:	73.9 KB
ID:	1349769


      Click image for larger version

Name:	Guide Discharge.JPG
Views:	26
Size:	240.8 KB
ID:	1349770
      Decided to keep Show Average Discharge Rate as a global option but limit it to displaying only when the normal Discharge Rate is set to Display. As the normal one can be overridden for individual devices it means that the averages can be prevented from displaying for individual devices by setting the former on the SDJ-Health tab of the device.

      Steve

      Comment


      • #33
        Congrats on getting beta area access, that'll make things a lot easier on you I'm sure.

        Been under the weather a bit, but can play around with it on mobile

        Comment

        Working...
        X