Potential problem.
While looking at my HA logs for something else, I saw this:
2021-03-31 22:28:47 WARNING (MainThread) [homeassistant.loader] No ‘version’ key in the manifest file for custom integration ‘dexcom’. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of ‘dexcom’
I would hate for the Dexcom add-on to stop working in a future HA update. The github for this project is archived and the owner hasn’t been on github for more than a year.
Could it be as easy to fix this by simply adding "version": "1",
to the manifest.json file?
Custom intergrations aren’t really in my wheel-house for editing. But i thought i saw the dexcom intergration in the official home assistant list? Not sure. But if not, maybe someone can fork the custom one
The suggestion of statistics wasn’t in response to you @stevemann
The code for the custom component is archived because it is now an official ha integration. The original coder is now the codeowner with ha. I hope he has not gone AWOL - I have three days left on my Freestyle, then trialling dexcom!
Well my Dexcom G6 has been working through the first sensor (it needs to be changed in a few hours). I also have the panel up and going, thanks @CaptainSweatpants and other contributors.
I confirm the HA inbuilt dexcom integration works straight away, although I am stuck with some readings in the hundred for the short period before I switched to mmol/L. I’ll see if I can delete those from the DB.
I thought the db was off limits to us mortal users.
I wouldn’t sweat the anomalies. In 24 hours they won’t show on a graph anyway.
Are you using their $$$device, or an Android phone?
There was one reading in the mg/dL units, I deleted that from the commandline. I use a mysql database and I speak mysql (poorly but sufficiently for this).
I could wait for it to sort itself out, but my OCD doth protest.
You will like the Dexcom- too bad you can’t get NHS to cover it. My insurance initially wouldn’t cover it for a T2 (I am really T3C but few have heard of that type). But I had experienced some really scary overnight hypos and my endo convinced the insurance that the CGM and its alarms were a life-saving necessity.
My favorite application is a set of Wemos D1 Mini modules around the house that receive an MQTT message with the value and trend, so I can see my BG at a glance.
# Average out BG over 90 days (aka eAG value)
- platform: average
name: 'Glucose Avg 90d'
duration:
days: 90
entities:
- sensor.dexcom_glucose_value # This is from the Dexcom Custom Component. I Labeled it this
# Calculate HbA1C % based off 90 day BG averge sensor above
# NOTE: These calculations are based on HbA1C from mmol/L values.
# The math is different for MG/DL. If you cant figure it out, let me know and ill make a template
# for HbA1C based off MG/DL
- platform: template
sensors:
jons_hba1c_value:
entity_id: sensor.glucose_avg_90d
value_template: >
{% set a = ( states("sensor.glucose_avg_90d") | float + 2.59 ) %}
{% set a1c = (a / 1.59) %}
{{a1c}}
# Format the Date and Time of the dexcom sensor start to “January 1, 2000 // 1:00 AM” format.
- platform: template
sensors:
cgm_sensor_start:
friendly_name: "G6 Sensor Started: "
value_template: >
{{ state_attr('input_datetime.cgm_sensor_start', 'timestamp') | timestamp_custom('%B %-d, %Y')}} // {{state_attr('input_datetime.cgm_sensor_start', 'timestamp') | timestamp_custom('%-I:%M %p') }}
icon_template: >
mdi:leak
# Do the same formatting of the date and time for sensor expiry.
- platform: template
sensors:
cgm_sensor_expire:
friendly_name: "G6 Sensor Expires on: "
value_template: >
{{ (state_attr('input_datetime.cgm_sensor_start', 'timestamp') + 864000) | timestamp_custom('%B %-d, %Y')}} // {{state_attr('input_datetime.cgm_sensor_start', 'timestamp') | timestamp_custom('%-I:%M %p') }}
icon_template: >
mdi:leak-off
# The Dexcom G6 Sensors only last 10 days before it expires in the dexcom app.
# This sensor Counts Down from 10 days from the start date and displays it as “X Days” left.
# When you get down to 2 days remaining, it will change to “Tomorrow...” and then “TODAY!”
- platform: template
sensors:
cgm_sensor_expire_days:
friendly_name: "G6 Sensor Expires in: "
value_template: >
{% set days = (( as_timestamp(strptime(states.input_datetime.cgm_sensor_start.state, "%Y-%m-%dT%H:%M:%S")) + 864000 - as_timestamp(now()) )/ (3600*24)) | round(1) | int %}
{%- if days < 1 -%}
TODAY!
{%- else -%}
{%- if days < 2 -%}
Tomorrow...
{%- endif -%}
{%- if days > 1 -%}
{{ days }} Days
{%- endif -%}
{%- endif -%}
icon_template: >
mdi:leak-off
# These Sensor templates follow the same templates for the Transmitter start, expiry, and days left as the G6 Sensor templates above.
- platform: template
sensors:
cgm_trans_start:
friendly_name: "G6 Transmitter Started: "
value_template: >
{{ state_attr('input_datetime.cgm_trans_start', 'timestamp') | timestamp_custom('%B %-d, %Y')}} // {{state_attr('input_datetime.cgm_trans_start', 'timestamp') | timestamp_custom('%-I:%M %p') }}
icon_template: >
mdi:leak
# Format Expiry date/time
- platform: template
sensors:
cgm_trans_expire:
friendly_name: "G6 Transmitter Expires on: "
value_template: >
{{ (state_attr('input_datetime.cgm_trans_start', 'timestamp') + 7776000) | timestamp_custom('%B %-d, %Y')}} // {{state_attr('input_datetime.cgm_trans_start', 'timestamp') | timestamp_custom('%-I:%M %p') }}
icon_template: >
mdi:leak-off
# The Dexcom G6 Transmitters have a life of 90 days before they’re “expired” in the Dexcom App.
# This template Counts Down from 90 Days.
- platform: template
sensors:
cgm_trans_expire_days:
friendly_name: "G6 Transmitter Expires in: "
value_template: >
{% set days = (( as_timestamp(strptime(states.input_datetime.cgm_trans_start.state, "%Y-%m-%dT%H:%M:%S")) + 7776000 - as_timestamp(now()) )/ (3600*24)) | round(1) | int %}
{%- if days < 1 -%}
TODAY!
{%- else -%}
{%- if days < 2 -%}
Tomorrow...
{%- endif -%}
{%- if days > 1 -%}
{{ days }} Days
{%- endif -%}
{%- endif -%}
icon_template: >
mdi:leak-off
Hi, where did I have to put that code in? configuration.yaml
Scroll up to the original post. All the specific directions and requirements are there. But keep in mind, this was setup a long time ago. Some things may have changed. For example I believe the Dexcom G6 has its own hass intergration now.
Kudos to your dashboard. I love it. I have a similar setup. I may give you a few ideas to implement if you so desire. I keep track of my current insulin pod and CGM time and log that to an influx db every pod and sensor change (via calling a script using an NFC tag) and display and average pod and CGM sensor length.
I also keep an inventory of how many supplies I have left. I have separate counters for vials, pods, and insulin vials left. Every set change I run a script that will notify me if it’s time to order more supplies. Dash shows how many sets I have left.
I stopped using this particular dash when I started “bypassing” the kill-dates on the CGM supplies. As some people know, the Dexcom G6 sensors don’t really stop working after only 10 days, that’s a kill command set by Dexcom (obviously for $), same goes for the transmitters… they last upwards of 5-6 months on that battery, not just 90 days. So those kill commands can be bypassed. So the “expiry dates” of this dash aren’t really relevant to me anymore.
I currently don’t have a pump, but that would be a nice addition for anyone that does. I like your setup description for yourself. You should definitely post it up in this forum topic for other T1Ds. Many would appreciate it; probably me as well once I’m all setup with a closed loop system etc.
Been playing with this for a bit now and finally got it to work perfectly for one of my kids. I’ve since been trying to get it to work for a second child on the same HA system, and struggling to get that to work. I know all the sensors and inputs need different names, which I’ve done and if I only activate one child1_sensor.yaml at a time it works. But when I enable both then which ever comes first in the code does not render any of the calculated data from the template correctly. I’m guessing there is some label or reference that I’m missing that’s causing the issue, just not familiar enough with this code to spot it.
At this point I’m curious if “platform: average”, “platform: template” or maybe the “friendly names” have to be specific to each child as well?
Honestly I’m not sure. I think the custom component for the Dexcom will only pull one child’s sensor readings through a follow account. I could be wrong though. I also know there is an official Dexcom intergration now. If the intergration/component only can pull one, maybe copying it, and renaming every with a “2” including all sensors and input variable as well, that might work. But this would involve diving into the component coding to change every single thing that referenced a sensor creation and anything to “2” otherwise it would overwrite.
Maybe go to the components GitHub page and contact them and see what they have to say. I could be wrong about all of this.
I can pull multiple dexcom sensors at the same time, they have the entities tied back to the dexcom account which I have a separate account for each child. I built a mini test page that shows me both their base data. It’s only when I’m trying the page with all the average values that I see issues and only with those values that are coming from the sensor template.
For the a1c I’m seeing normal numbers for each child 6.37 and 7.71.
- platform: template
sensors:
child1_hba1c_value:
entity_id: sensor.child1_glucose_avg_90d
value_template: >
{% set a = ( states("sensor.child1_glucose_avg_90d") | float + 46.7 ) %}
{% set a1c = (a / 28.7) %}
{{a1c | round(2) }}
As an example of the issue I’m seeing I tested the below code for just the a1c value for each child, and as noted before whichever child is first in the list their value does not get displayed while the second child in the order a1c shows every time. I feel like there is some variable I’m missing or maybe it’s just the way code is read/fed into the system that parts of it don’t work. The code for the Card’s are identical with the exception of the “entity” which is specific to each child.
I’m hoping whatever I’m not seeing is blatantly obvious to one of you.
- platform: average
name: 'Child1 Glucose Avg 90d'
duration:
days: 90
entities:
- sensor.dexcom_child1_glucose_value
- platform: template
sensors:
child1_hba1c_value:
entity_id: sensor.child1_glucose_avg_90d
value_template: >
{% set a = ( states("sensor.child1_glucose_avg_90d") | float + 46.7 ) %}
{% set a1c = (a / 28.7) %}
{{a1c | round(2) }}
- platform: average
name: 'Child2 Glucose Avg 90d'
duration:
days: 90
entities:
- sensor.dexcom_child2_glucose_value
- platform: template
sensors:
child2_hba1c_value:
entity_id: sensor.child2_glucose_avg_90d
value_template: >
{% set a = ( states("sensor.child2_glucose_avg_90d") | float + 46.7 ) %}
{% set a1c = (a / 28.7) %}
{{a1c | round(2) }}
Card example only difference would be the entity line being child1 vs child2
I have this working now but I’m a little confused as to why. Originally when setting up the templates for my kids I used two separate yaml files and added them into the configuration with include commands. This is where I was having problems and only the second child data would show. I decided to combine them into a single script just to see if it would work and it does now. Both kids information is now showing. I’m a little confused as to why includes would cause an issue, but maybe I just need to read up on them more to make sure I fully understand them.
#seperate templates for each child - 1st child data would not show.
#sensor: !include sensors_child1.yaml
#sensor: !include sensors_child2.yaml
#current setup in configuration.yaml using a combined template for both kids.
sensor: !include Dexcom_combined.yaml
In short, I love the interface and all the info it shows me, and I’m happy that it does work for more then one diabetic in the house, just requires minor adjustments for the entities to make them unique.
