Give us a desktop alternative to the Browser, please?

Feature Requests
21

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.

1 Like
22

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.

23

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.

1 Like
24

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.

26

Thanks for clarifying that. I thought it was handled on the browser side. I stand corrected.
Still, parsing HTML is no small thing either.

27

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.

28

what about this

3 Likes
29

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.

30

@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 :wink:

1 Like
31

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.

1 Like
34

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('}', '') }}"
5 Likes
35

I never understood the fuss about webhooks until now. Thanks Taras.

36

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.

37

Likewise, but it’s a good tool to understand.

38

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:

image

It’s SO easy!

Beside that let me quote the old forum saying:
Don’t feed the trolls.

1 Like
39

You may have a look at Rainmeter, but I didn’t test it:

40

There seem to be something cooking here:

41

@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 :smiley:

Editted to add - lamp now switching directly on the vbs using your advanced automation. Nice one :+1:

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.

42

I use webhooks a lot for my server processing scripts. They are freaking AWESOME.

1 Like
43

One functionality that a native app will need to have even if its just a simple webview wrapper is being able to switch between Internal and External URIs, like the mobile apps do,
I am interested in building a minimal Tauri based rust app for this that will be cross platform,
just a webview wrapper with the ability to add internal and external uris and will switch from ine to the other based on the network just like the mobile apps,
is there anything that is planned of this sort in roadmap if anyone knows ?

1 Like