THANK YOU THANK YOU THANK YOU…so much.
The problem is that < pre > doesn’t show up if I just put my endpoint into a browser. Which is where I was pulling it from as I was also testing the apache server I have it on.
The question is…is it possible to put all these states into one device as attributes? Or does each have to have it’s own entity?
I also don’t want it making more than a call an hour would scan interval just be 3600?
You can’t make a device out of it. Just use normal triggers, not device triggers for automations.
yes
But each one like Door Locks, Doors Opened etc each have to have their own entity? I can’t have one entity called Ram Truck that has the attributes from .results.device.deviceStatus parsed into the attributes? I don’t know how much sense that would make compared to this method but curious.
You can do either with the rest integration: 1 entity with attributes or multiple entities. The rest sensor integration only makes 1 entity.
Can you point me in the right direction on how to do this?
You can’t use json attributes path because it requires a json object. That might keep you at individual sensors unless you use the custom rest integration on HACS.
I have it set up like below after commenting out the < pre > on the .php. I get the lat/long in the state and get each of those attributes in the attributes now. Very cool. Thank you for your help. I’m not sure if I should ask in here or open a new question but it’s in regards to this same rest point. So this is for a remote starter that has limits on the api calls. The endpoint I’ve been using is the “refresh (state)” endpoint. There’s also three other end points for lock, unlock and remote start. I would like to integrate the lock/unlock into one entity but it’s two different api’s. FYI these endpoints also return the same json as the req_extended_status endpoint. I don’t want the refresh entity, the lock entity, the unlock entity and the remote start entity all making a call at hour scan intervals. So my idea was say when the doors unlock that sends the attribute to the state of the lock/unlock switch and the refresh entity, have the other 3 on like 100 hour scan intervals or something like that and continue with the hour scan interval on the refresh one. Does that all make sense? lol. Use virtual switches…run an automation that when the doors unlock via a rest_command/switch(???), the refresh end point refreshes? Idk there’s got to be a better way to do it.
Node red maybe?
rest:
- authentication: basic
scan_interval: 3600
resource: "http://localhost/vip.php?apiKey=ahhhhh&cmd=req_extended_status"
sensor:
- name: "Ram Truck"
value_template: "{{ value_json.results.device.latitude, value_json.results.device.longitude }}"
json_attributes_path: "$.results.device.deviceStatus"
json_attributes:
- "remoteStarterActive"
- "securitySystemTriggered"
- "securitySystemArmed"
- "dtcCodePresent"
- "ignitionOn"
- "doorsLocked"
- "doorsOpen"
I setup the DroneMobile integration to do a status update on a user-configurable time basis. The default value is every 5 minutes. This results in 288 API calls in a 24-hour period. The important thing to note here though, is that this is NOT the same as polling the DroneMobile device on their cell network. Calling the API to get the last known settings does not hit the device, thus saving battery life and cell network bandwidth. That poll is considerably more limited (as DroneMobile has a limit of like 500 requests per month or something like that to limit cell network activity). This way, whenever any command is carried out (lock, unlock, remote start, trunk, alarm, etc.) through any medium (Home Assistant, the app, google home, alexa, etc.), those actions update the last known state, which is constantly being polled on the API side. When a command is executed via Home Assistant, I manually update the sensors to what the API response is so that Home Assistant updates faster. Obviously I can’t do that when someone executes a command using the official app, so it has the delay of waiting until that update interval triggers a call to the API to update sensors.
I use a couple automations in Home Assistant on my personal install at 10p.m. and 5:30a.m. to force a refresh of the data so that my auto lock and auto start automations have the most up to date information (namely lock status and temperature) for their execution events a few minutes later.
Viper is a bit differet in that the api calls also count against your monthly cap…which is something like 500 a month as well. I think it’s 500 a month/5000 a year if you’re on a yearly plan, as I am.
What I was looking at without knowing how to create a custom integration. Is having the sensor as I do above from the request status end point, updating the sensors. Someone told me he does an hourly scan interval and hasn’t hit his limit, so I figure I can do hourly.
I then was thinking of having, unlock, lock and remote as restful commands. Create a virtual lock or something of the like for the locks. Create a button for the remote starter. Have an automation that calls these rest commands to lock or unlock the car/toggle the remote starter, delay 5 seconds and then call the refresh request. This is just doubling the calls though too, especially when all the same info is already provided when you request one of these actions. I could also run the refresh call like you say on my good night and good morning routine. I was thinking I could cut down on the calls if I was able to send the json data from the unlock, lock and remote start to the sensor I created with all the attributes.
Couldn’t you create your locks etc using the template integration - with the state of them provided by the attributes of your main sensor? Then when trigger say your lock - use an automation to detect the state change and use homeassistant.update_entity service call with your rest sensor so that it gets the latest data. Then yes, you could lower the scan interval of the rest sensor significantly.
I’m sure I could lol. I’m not quite there skill wise. lol.
lock:
- platform: template
name: Ram Locks
value_template: "{{ state_attr('sensor.ram_truck', 'doorsLocked') }}"
lock:
service: rest_command.lock_the_ram
unlock:
service: rest_command.unlock_the_ram
1 Like
Almost -
lock:
- platform: template
name: Ram Locks
value_template: >
{% if state_attr('sensor.ram_truck', 'doorsLocked') is defined %}
{{ 'True' if state_attr('sensor.ram_truck', 'doorsLocked') == true else 'False' }}
{% else %}
False
{% endif %}
lock:
service: rest_command.lock_the_ram
unlock:
service: rest_command.unlock_the_ram
Just to ensure there is only a true or false result.
Perfect!!! Thank you.
One last question, I think…
I created a button for the remote starter as there’s only one end point for the remote starter which turns it on and off. Except I can’t use value_template for a button…hmmm. How would a switch work with the same end point? Would a binary_sensor work? 
A switch probably works better once I move my voice assistant over…vs. a button.
I came up with this for a switch. Again thank you for the help. Having to call it ram_remote in this integration is a little annoying but I can deal with it.
switch:
- platform: template
switches:
ram_remote:
value_template: >
{% if state_attr('sensor.ram_truck', 'remoteStarterActive') is defined %}
{{ 'True' if state_attr('sensor.ram_truck', 'remoteStarterActive') == true else 'False' }}
{% else %}
False
{% endif %}
turn_on:
- service: 'rest_command.remote_start_ram'
- delay:
milliseconds: 100
- service: switch.turn_off
target:
entity_id: switch.ram_remote
turn_off:
- service: switch.turn_off
target:
entity_id: switch.ram_remote
I was thinking this is much cleaner but I’ll still be making two calls per command…when I unlock the doors…I’m sending a rest command to the api. When that state changes it’s updating the main sensor…so still two calls. I don’t think it’s going to be too much of a big deal. I believe it’s the same way the integration is on ST and HE and I used them both and never met my yearly calls. I also wasn’t calling state every hour. I guess I can only test and work with it to see if I hit the limits. When I look at my device status on Postman it shows 500 calls for the month with 0 actions used…and I can guarantee I’ve made a lot more than 0 calls while testing this.
that template doesn’t really make sense.
is defined is meant for properties of an object but it’s being used on state_attr. That will always be defined. If you’re trying to check for a value, you just need
if state_attr()
The only caveat is if that attribute is a number, 0 will make that hit false. But for you, it doesn’t matter because that value is true/false/none(when doesn’t exist). Also, you don’t need to return true/false as a string from the code either, it will naturally do that.
value_template: >
{% if state_attr('sensor.ram_truck', 'remoteStarterActive') %}
{{ state_attr('sensor.ram_truck', 'remoteStarterActive') }}
{% else %}
False
{% endif %}
lastly, if you really want this to be optimized with the simplest code, this is the shortest and safest way to get a result. If the attribute doesn’t exist, it will be false. If it does, it will be the attribute.
value_template: >
{{ state_attr('sensor.ram_truck', 'remoteStarterActive') or False }}
Thank you @petroe. Yes I always prefer the K.I.S.S. method. If it’s more simple than it’s easier to find problems when they crop up.
So one other question. Currently I have lat and long in the state of my main sensor as seen below. I used that basically while testing. I need that same info in the attributes now as I’m trying to put the truck on the map as a device tracker. Can I have two different paths for json_attributes_path? Or if I do $.results.device will that pull info from “deviceStatus” as well?
rest:
- authentication: basic
scan_interval: 3600
resource: "http://localhost/vip.php?apiKey=ahhhhh&cmd=req_extended_status"
sensor:
- name: "Ram Pickup"
value_template: "{{ value_json.results.device.latitude, value_json.results.device.longitude }}"
json_attributes_path: "$.results.device.deviceStatus"
json_attributes:
- "doorsLocked"
- "doorsOpen"
- "remoteStarterActive"
- "ignitionOn"
- "securitySystemTriggered"
- "securitySystemArmed"
- "dtcCodePresent"
You’d make a second sensor with lat and lon. You can’t have 2 json paths on the same entity.
Thank you! That should work I’ll just put it under that same integration to save api calls. I wonder if it can be moved in the php file…or if that’s how the external api is sending it back. I’ll have to look…