Yeah I’ve been contemplating stripping the GB but I’ll have to determine if it’s MB or something else to do some math to convert it. I am not sure which data sets they use but I like the idea of graph form
Maybe just make an expected usage sensor that can be put up next to the actual usage.
That actually makes more sense.
With some help from the FBs HA Group I have made the following sensor that shows Expected Usage in Percent:
sensor:
- platform: template
sensors:
cox_expected_usage:
value_template: >
{% set bill_day = 18 %}
{% set today = now().strftime('%d') | float %}
{% set next = as_timestamp(now()) + 86400 * ( 35 - now().strftime('%d') | float ) %}
{% set prior = as_timestamp(now()) - 86400 * ( now().strftime('%d') | float ) %}
{% set days_last_month = prior | timestamp_custom('%d') | float %}
{% set days_this_month = ( next - 86400 * ( next | timestamp_custom('%d') | float ) ) | timestamp_custom('%d') | float %}
{% if today >= bill_day %}
{% set total = days_this_month %}
{% set used = today - bill_day %}
{% else %}
{% set total = days_last_month %}
{% set used = today + days_last_month - bill_day %}
{% endif %}
{{ ( 100 * used / total ) | round(2) }}
OK to simplify, If i took the number of days in the billing period, figured out what percentage of data you should be using each day, then compared it to the number of days left, it would spit out if your using more than you should be in percent.
Sounds simple enough, that’s a killer template though. I’ll probably have something ready soon, i am going to make it as an option to enable in configuration.yaml.
I had to change it a bit to get it to update every day. Here is the final version:
sensor:
- platform: time_date
display_options:
- 'date'
- platform: template
sensors:
cox_expected_usage:
value_template: >
{% set bill_day = 18 %}
{% set today = states('sensor.date') | regex_replace('....-..-') | int %}
{% set next = as_timestamp(now()) + 86400 * ( 35 - now().strftime('%d') | float ) %}
{% set prior = as_timestamp(now()) - 86400 * ( now().strftime('%d') | float ) %}
{% set days_last_month = prior | timestamp_custom('%d') | float %}
{% set days_this_month = ( next - 86400 * ( next | timestamp_custom('%d') | float ) ) | timestamp_custom('%d') | float %}
{% if today >= bill_day %}
{% set total = days_this_month %}
{% set used = today - bill_day %}
{% else %}
{% set total = days_last_month %}
{% set used = today + days_last_month - bill_day %}
{% endif %}
{{ ( 100 * used / total ) | round(2) }}
1 Like
The only issue I have noticed is Cox is not great about updating the usage, it can be a day behind. So I am using the measurements between Cox’s last measured date and the service end date rather than now date as that can skew the readings.
Ok v0.0.6 has the correct math to calculate percentage that should be used.
So if actual usage sensor is above expected usage sensor you are on track to being over usage.
Your new sensor shows the same value as my template, so that’s great. I’ll switch to just using yours.
1 Like
This stopped working for me because Cox changed how you login. I created a similar flow in using docker: https://github.com/dejanzelic/coxusage-docker It outputs the JSON to a file so you shouldn’t have to change anything up in HA.
I noticed this yesterday too. I have not abandoned it, and will have a fix at some point.
Could be wrong, but it looks like they have implemented some form of validation/authorization redirect. I think it will be hard to fix unless you have access to some tool like selenium to interact with the page. Not sure if HA has anything built in that can be used.
Anyway to use this with a windows version of HA? I don’t have docker.
Yeah it looks like they might be now doing auth via okta. Which is an IDM/SSO company. We might very well have an issue but i will continue to investigate.
I am not familiar with windows HA but if you can get the integration HACS installed, you can add my github repo to add it. However right now Cox broke the authentication, so it won’t work until hopefully i can fix.
I love this idea. At first the JSON file that got output was huge. I think I did something wrong. So I reinstalled and get a much smaller JSON file but it does not have any of the data usage info. I ran the script over many days and the only info that changes in the JSON file is the dateStamp value. I will post the contents here. Any ideas? Thank you
{"businessUnit": "res:sign-in", "channel": "cox:res:signin", "currentMonthDays": 31, "dateStamp": 1595080865964, "language": "en", "pageName": "cox:res:sign-in", "pageType": "signin", "purchaseStep": "signin", "responsiveDisplayType": "desktop", "selfHelpName": "signin:page", "subSection": "cox:res:signin", "visitCount": "", "visitorLoginStatus": "loggedout", "zip": ""}
Ok I see where the problem is with the script as I run it. The above data is the value in the variable utag_data from the login page. It appears the script is not getting logged in. I assumed since the code was updated 5 days after the above comment about the login issue it was fixed. I will monitor.
Yeah sorry still not fixed. I am not sure if I will be able to pull this off. Okta makes it difficult to webscrape login.
Since I realized it was a login issue. I tried to duplicate it with AppleScript on my Mac. I could find and enter username and password into the correct fields. But it would register as bad password when the script clicked the login button. So I back stepped. Just used the script to enter the username and password and end. Then I would click the login button. Same result. So I think it knows some how that a script is entering the data and not liking it. Even though I can see in the fields the data is correct.
Thanks
K
I have decoded it to a point where I am now able to go from the cox site(retrieve a key) for https://cci-res.okta.com/login/login.htm?fromURI=/oauth2/v1/authorize/redirect?okta_key=REALLYLONGKEYHERE
From there i am able to do a manual log in which will authenticate me with cox. I just need to figure out how to “log in” and get myself a token from the above url. I am close but still pretty far off.