This sounds like quite a niche requirement to me and not one that many people would want, and therefore probably not something that developers would want to invest a lot of time and effort in creating.
If you have a way of displaying widgets on your desktop already, then if I were you I would investigate how to use them to extract data from Home Assistant REST API.
Personally I have a Pi Zero on my desktop running an MQTT client and driving a Pimoroni ScrollPhat (supported by a little home-made Python script, based initially off the recent one in the MagPi magazine).
For return messages I have HA set up with the MQTT broker, and for notifications it just sends a message to the Pi which displays them on the Phat. In my case I mostly use it with an internet radio (Volumio) to display the song name when a new song plays, plus also volume and station name when switching them.
In this case, the display could be combined with a trigger such as the one I described above, so that clicking an icon sends a command to HA, which then responds with an MQTT message to the display. And the responses could also be viewed on something like MQTT Explorer if you donât want to set up some other display option.
To explain this a bit more for you, the Home Assistant User Interface (Lovelace) is already a web interface. To display views on a device, you only need a browser that can handle the Jinja/YAML display language.
In order to display a particular device as a widget, one would have to duplicate much of that capability. Either one displays a device in a preset manner with a few preset options (a la ActionTiles) or one would have to have a widget that can parse Jinja/YAML.
If you go the former route, many folks who have worked hard on coding their Lovelace interface wouldnât find it very useful. In addition, you have the development time of creating and maintaining this display capability.
If you go the latter route, youâve got the coding overhead that goes with the parsing. I wouldnât be surprised if the overhead for this and the necessary windows display setup would get to a level where placing more than a couple of widgets onscreen would require the same memory as an Edge app window. (Chrome, as we know, consumes mass quantities. Thatâs why Iâm not using it anymore.)
For the later route certainly, youâd either have to set up the basis for the widget in a Lovelace view so it could be âreadâ by the widget and displayed, which would duplicate a lot of our current Lovelace code or have some way of identifying an individual Lovelace object as a widget source which would require some widget-side code to scan for and read it.
To be candid, I dislike the sort of answer Iâm giving here. I donât like saying, âYou probably donât want to do [whatever it is that you clearly want to do].â but I also donât like heroically working to get something only to be disappointed with the result and later discard it anyway.
Iâm fairly sure there is no yaml or jinja in your browser.
All that is handled in HA and a html is feed to the browser.
But I agree with others that this is a very niche request that not many will find useful.
Thanks for clarifying that. I thought it was handled on the browser side. I stand corrected.
Still, parsing HTML is no small thing either.
I donât want to get into this discussion, but thanks for the code snippets. Iâve been using Home Assistant for two years and I had never heard of WebHooks. (But, then, I have never been able to write an automation). This is a solution to an issue where my wife wants to control a few lights from the tablet without opening a browser. The tablet is already slow enough without opening a browser.
what about this
If the tablet supports the android app, you can add widgets to the homescreen which can execute services. Is a bit slow, but less steps then opening the app/browser.
@stevemann - on an Android or iOS tablet (or phone), you can also install the HA companion app and use that, either directly or via widgets (for Android) or the today view (the one on the far left if you swipe between screens, at least on my iPhone - not sure what itâs officially called) on iOS.
But youâre welcome to the code snippets anyway
Thanks for the widgets tip, but one challenge at a time. The tablet is a MS Surface Pro. But in just five minutes I now have a working automation (yay) and my wife has an icon on her desktop to toggle the kitchen light.
Iâm so glad I managed to kick off a constructive and creative discussion around this subject.
We are different and we have different needs and preferences. But maybe we all have the WAF factor in common ?
For me, my HA is growing out of proportions. With hundreds of Entities and too many dashboards with too many cards on each. For me, thatâs ok. I have a high power i7 computer with 2x28inch high-res monitors. But the HA-companion on my cellphones are no longer able to cope. They stall.
And my WAF is down to zero until I find a way to put small leight-weight widgets or icons on her kitchen and bedside tablets.
Is this a nich requirement? Am I the only one here with a not-so-nerdy wife?
I tried giving her scene buttons, but after a while it proved less flexible. She lost them under the bed, unless I glued them to the night table (or kitchen top) and labeling them never looked professional. I even tried the Magic Cube, but she wouldnât touch it.
(Beside the point; I do love my wife though)
âmaybe we all have the WAF in common?â Yes. I think thatâs a given.
To be sure, my wifeâs an engineer, so thereâs probably some built-in modifier to the WAF right there Nonetheless, she was not nearly as enthusiastic in embracing smart home things as I was.
She was also adamant that lights should have switches that turn them on and off.
What goosed the WAF in my case was when I mentioned that she could turn the outside water tap on (to water her gardens) and have it automatically turn itself off after 2 hours. After I implemented that, she came up with a few ideas herself. (eg: Can you get both sets of lights in the kitchen to turn on or off no matter which of the switches I use? (Really easily done.))
Sheâs OK with using her phone to control things, but I still installed a button for her to turn on her desk lamp and to switch from overhead to zoom-friendly lighting.
Thought you might like to know that I followed up on your suggestion to use VBScript. Instead of having it call a batch file (containing the curl
command), it calls the command directly:
See VBScript command
CreateObject("Wscript.Shell").Run "curl -d ""{\""entity_id\"":\""switch.whatever\""}"" -H ""Content-Type: application/json"" -X POST http://homeassistant:8123/api/webhook/toggle_entity", 0, True
Half the battle was escaping the meaning of the double-quotes correctly (i.e. for VBScript the double-quote is preceded by another double-quote whereas for curl
itâs preceded by a backslash). Once that was sorted, the command executes correctly for all contexts.
FWIW, I also created an equivalent in PowerShell which was straightforward:
See PowerShell command
$p = @{
Body = '{"entity_id": "switch.whatever"}'
ContentType = "application/json"
Method = "Post"
Uri = "http://homeassistant:8123/api/webhook/toggle_entity"
}
Invoke-RestMethod @p
However, I used the VBScript approach because it executes silently whereas PowerShell briefly displays a blank console window. Itâs cosmetically unappealing and I couldnât find a workaround for it.
For my intended application, I also wanted to pass data to the webhook as a JSON dictionary.
{"entity_id": "switch.whatever"}
The main benefit is that itâs extensible and can be used to pass other parameters, for example a lightâs brightness
, if thereâs a need to do more than simply toggle an entityâs state.
The automation to listen for the webhook and toggle the specified entity can be as trivial as this:
See simple version
- alias: Toggle Entity
trigger:
- platform: webhook
webhook_id: toggle_entity
action:
- service: homeassistant.toggle
target:
entity_id: "{{ trigger.json.entity_id }}"
Or more advanced like this one which ensures the received data is in the correct format and specifies an existing switch
or light
entity (otherwise it reports the error).
See advanced version
- alias: Toggle Entity
trigger:
- platform: webhook
webhook_id: toggle_entity
action:
- choose:
- conditions: >
{{ trigger.json.entity_id is defined and
states(trigger.json.entity_id) != 'unknown' and
trigger.json.entity_id.split('.')[0] in ['switch', 'light'] }}
sequence:
- service: homeassistant.toggle
target:
entity_id: "{{ trigger.json.entity_id }}"
default:
- service: notify.persistent_notification
data:
title: "Toggle Entity: Received Invalid Data"
message: "{{ trigger.json | string | replace('{', '') | replace('}', '') }}"
I never understood the fuss about webhooks until now. Thanks Taras.
Youâre welcome!
Truth be told, it was mostly an academic exercise; I am more likely to continue using Alexa or the browser UI to control something.
Likewise, but itâs a good tool to understand.
The OPs request can actually be solved very easily and by the OP himself without any further assistance. Here are the steps:
- Trash your Win machine and get a Mac.
- Read this HA blog posting about HA companion for macOS.
The result:
Itâs SO easy!
Beside that let me quote the old forum saying:
Donât feed the trolls.
You may have a look at Rainmeter, but I didnât test it:
There seem to be something cooking here:
@123 Thanks for that - indeed most interesting.
My set-up evolved initially with the batch file only, which worked but popped up the terminal. The vbs part was basically to hide/suppress the terminal, which also worked so just kept things simple.
As you say, the escaping of the curl command would be the tricky part, but as youâve been kind enough to give that on a plate I will look to update and streamline things later. A very nice tutorial
Editted to add - lamp now switching directly on the vbs using your advanced automation. Nice one
Had to build the automation rather than doing a yaml copy/paste as it was complaining about expecting a dictionary. But itâs working now using yours as guidance to make it manually.