Driver

Hi, I have both habitat and home assistant. I rely mainly on hubitat and use home assistant for other devices discovery

I want to create a global variable in hubitat which is updated periodically from HA to show battery level of an on wall tablet.

HA provides APIs to get devices info, I am super new with groovy, need a code example that calls the http and store the battery level in the global variable.

Probably could do this with Rule Machine easier…

Or setup Node Red in Home Assistant and do it that way. The device integration is in Home Assistant correct?

1 Like

The fire tablet battery level is in HA, I am open yo use RM also. Stick with the code to update a global variabel in HE

You could probably also store the battery level in a virtual Omni Sensor in HE. I used to send the battery level of my Android Phone to HE with the Tasker App using an http request to HE's Maker API for an Omni Sensor. I don't use Automations in HA but you should be able to send an HTTP Request from Home Assistant every time that the Fire Tablet reports a change in battery level. If you try doing it by HE sending an API request to Home Assistant, you are polling and won't have instant updates. However, I am not 100% sure what the process is you are doing.

2 Likes

Is the battery level a sensor entity in HA? If you can get it to be a sensor of device_class battery, then you could use Home Assistant Device Bridge to bring it in to a Hubitat virtual device. What do you want to do with the value once it is in Hubitat?

FYI @SmartHomePrimer, who always knows a clever way to get data moving in the right direction between HA and HE.

4 Likes

@Maja - Link to HADB...

2 Likes

Thanks for your replies, home assistant bridge integrates light bulbs only, not sure if this is the normal behavior or I am doing something wrong. I would say the best way is creating a taker profile which updates either a global variable or a virtual device. The question is which url should I use to update either of them.

Talking about the purpose, it is to be able to switch on and off a zwave socket attached to the tablet to allow battery power cycling

If you have Tasker on your Fire Tablet, then you don't need to even make a rule, global variable, or virtual device if all you want to it to do is turn a switch off/on based on the battery level,

I do this exact thing for an Android phone I use as an on-wall tablet. First, install Maker API app in HE if you haven't already then authorize that switch to be used by app. Then goto Tasker on tablet.

I have two profiles in Tasker:

  1. State -> Battery Level = 95-100, then Task -> Send Http Request in the Maker API format of http://[Your Hub IP Address]/apps/api/[App ID for Maker API]/devices/[Device ID]/off?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. This can be copied from your Maker API app page directly when using tablet.

  2. State -> Battery Level = 0-75, the Task -> Send Http Request in the Maker API format of http://[Your Hub IP Address]/apps/api/[App ID for Maker API]/devices/[Device ID]/on?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

You can obviously choose whatever battery level values you want. You could also have one Profile and use the Task in #2 as an Exit Task in that Profile.

If you ever want to do more than just send a single device command, then you would use a local or cloud endpoint in RM as a trigger that will then give you ability to do multiple actions in HE.

Additionally, if you ever wanted to control something from your Android phone when it may or may not be at home, you could use the Cloud version of the Maker API Send Command URL. However, instead, I have a variable in Tasker that changes based on whether I am connected to my home Wifi or not then Tasker sends either the local Maker API Command URL or Cloud version based on that variable.

2 Likes

That is great info, I created a virtual device (omni sensor). decided to use relative humidity field to store the battery level, added to maker API. In tasker I created a profile which runs every 5 minutes, added a task with Http and used the URL from maker API and all works perfect.

The only missing part is that the profile is not firing automatically, however when I run the task manually it updates HE.

I used the time from 12:00 AM to 11:59 PM, every 5 minutes.

what can be wrong ?

I am not sure what is wrong with your Tasker. That is a TIME profile correct???

Hubitat did make the Omni Sensor code available so you can add "battery" capability and setBattery Command to it, delete the rest, and save as your own unique driver type to use.

I have no idea is this is the most efficient way to do it but here is my code:

// Copyright 2016-2019 Hubitat Inc.  All Rights Reserved

metadata {
    definition (name: "Virtual Battery", namespace: "hubitat", author: "Bruce Ravenel") {

        capability "Battery"
        command "setBattery", ["Number"]

    }
    preferences {
        input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true
        input name: "txtEnable", type: "bool", title: "Enable descriptionText logging", defaultValue: true
    }
}

def logsOff(){
    log.warn "debug logging disabled..."
    device.updateSetting("logEnable",[value:"false",type:"bool"])
}

def installed() {
    log.warn "installed..."

    setBattery(50)

    runIn(1800,logsOff)
}

def updated() {
    log.info "updated..."
    log.warn "debug logging is: ${logEnable == true}"
    log.warn "description logging is: ${txtEnable == true}"
    if (logEnable) runIn(1800,logsOff)
}

def parse(String description) {
}



def setBattery(bat) {
    def descriptionText = "${device.displayName} is ${bat} %"
    if (txtEnable) log.info "${descriptionText}"
    sendEvent(name: "battery", value: bat, descriptionText: descriptionText, unit: "Degrees")

I quickly tested and it seems to work. I probably could delete more of the code but I don't do Groovy so I didn't want to delete something that might be important.

2 Likes

I do something similar if not the same, sending battery levels for my phone and tablets via tasker to a virtual battery sensor. Allows me to manage a smart plug when charging each of them.

@Maja Listen to @sburke781. He is an experienced Groovy coder. He can tell us what to do to my quick Virtual Battery device to get rid of the extraneous info in it.

1 Like

Flattery will only get you so far... Laziness is strong in this one.... :wink:

Jokes aside.... I probably leant more towards the Omni Sensor at one point given it was being managed by others.... but let me dig out what I eventually used...

haha, no ignorance of Groovy is strong in me. :grinning:

1 Like

That's right, I wrote my own.... :slight_smile:
(Also available via HPM)

I've probably included these instructions elsewhere, but can't be bothered finding them...:slight_smile:

  • Install this driver via HPM or manually (or the Omni sensor...)
  • Create a virtual device using this driver
  • Add the new device to an existing or new instance of Maker API
  • Identify the device id for the new device by opening the device edit page for the device and copying the Device ID from the URL

On your phone / tablet:

  • Open the Maker API page, copy the command URL that includes the secondary parameter
  • In Tasker
    • Create a new profile based on an Event of a Battery Change
    • Add a New Task of a HTTP GET
    • Enter the URL as the command URL copied from Maker API, replacing the device id with that identified earlier and replacing the command and parameter with (for my driver) setBattery/%BATT

I then have some rules to manage smart plugs, but maybe setting this up can be a first step and rules can come later....

1 Like

Perhaps the simpler answer / alternative would be to use the battery change event I mention in my notes....?

HADB does indeed handle way more than just light bulbs. One thing that does have to happen for the HA entities/devices to show up in Hubitat is that the device in HA needs to send a status update. This is due to the fact that no custom code is used on the HA side, as HADB just listens to a webSocket from HA that sends events in real-time.

3 Likes

That did seem a little blunt in retrospect.... "Just use my driver".... Yours does seem correct, without having tested it, or checking the capability setup for batteries, so I can't see any reason not to use your driver. I think the only additional feature I added was the status of charging or discharging, which I've never really made use of personally, but is a nice option if you want that indication on a dashboard or to use in some automations.

I literally took the Omni Driver, started deleting things, and changed the setIlluminance command to setBattery. I claim no ownership nor pride in what I did nor took any offense if you thought you were blunt. :grin:

I also did it quickly and have no idea if it works long term.

1 Like