MQTT or Rest for automation

[dev-inside]

first of all thank you, it is a really great app :) It does almost everything I expect and hope for an kiosk app. The only thing which would it make a killer for people who don't use any kind of management system would be a way to communicate with the app via MQTT or REST. This would be great for example in Home Assistant to change the url when a automation has been triggered. It could replace for me and many others Fully Kiosk Browser.

[dev-inside]

Well, I guess to control the Kiosk browser via Home Assistant, NodeRED, OpenHAB or n8n might be the main purpose for the most people using MQTT. Or for crazy Linux or Iot-Nerds :D

I would say other features needed for a proper usage with MQTT might be:

Possible MQTT-Features

• Quality of Service (QoS)
• -QoS 0: „At most once“: Send message once without verification
• • QoS 1: „At least once“: Send message once until a notification has been received
• • QoS 2: „Exactly once“: Makes shure that the verification only happens once
• Last Will and Testament (LWT)
  Send a message in case the client loses unexpected the connection
• Maybe Message Persistence
  Stores messages to avoid lost messages

MQTT-Topics

• Current URL of the Kiosk-Browser
• All other settings you find find necessary^^
• Lock-State (Screen Locked, Screen Unlocked)
• Brightness-Level of the active-screen (Maybe controllable via 0-255 or in Percentage)
• Battery of the device (if possible - would be really cool)
• Power state (Charging, Battery)

These are the things which came to my mind

[nktnet1]

Thanks for this :).

Also, do you happen to know any small to mid-size apps that implements the MQTT protocol that are FOSS and written in Kotlin?

[dev-inside]

Hey,
of course:
Droid Pad
https://github.com/UmerCodez/DroidPad

Sensorspot
https://github.com/UmerCodez/SensorSpot

[nktnet1]

Hey @dev-inside,

Just letting you know, I've started work for this, and aiming to release for v0.25.0.

Out of curiosity, would you be willing to help test the feature prior to launch? (e.g. downloading test APKs or building from the mqtt branch directly). Totally fine if not 👍.

[dev-inside]

@nktnet1
You are really a hard worker 🥳
Of course I will participate in beta tests. Just tell me when I have to download a test APK or smth

[nktnet1]

Hey @dev-inside,

I've published the APK for the first draft here:

• https://github.com/nktnet1/webview-kiosk/tree/v0.25.0-mqtt-beta

Can you give it a try?

You can also build the APK from source using the mqtt branch:

• https://github.com/nktnet1/webview-kiosk/tree/mqtt

---

If you're using a local MQTT broker (localhost), make sure that:

1. Your device is on the same network as the broker
2. Set MQTT -> Connection -> Use TLS to false
3. Set MQTT -> Connection -> Port to 1883 (unless you've configured your broker differently)

---

Some example payload you can send to the configured "Command" topic (default is wk/command) are:

{ "command": "go_back" }

{ "command": "go_forward" }

{ "command": "go_home" }

{ "command": "refresh" }

{ "command": "go_to_url", "url": "https://github.com" }

{ "command": "lock" }

{ "command": "unlock" }

With settings, you can change any setting using their respective key similar to app restrictions. For example, you can change the theme by sending to the topic wk/settings (default):

{
  "settings": {
      "appearance.theme": "LIGHT"
  }
}

[dev-inside]

Hey, I'd tested it with Home Assistant and with Mosquitto, works well but it would be amazing to wake up the display as an additional attribute like:

{ "command": "go_to_url", "url": "https://github.com", "wakeup": "true", "brightness": "50" }

Alternative to wakeup could be display or smth.

Also a list of the avialable wk/settings would be amazing. Or atleast the fiile where I could find the ids like webcontent.url or however the name scheme is.

If you have other entities/sensor to like

• homepage url
• camera access
• mic access
• battery
• wifi

or whatever would be amazing, but I guess it's covered (except battery/wifi) with wk/settings. Maybe for this the topic wk/device would make sense

Otherwise really amazing!

[nktnet1]

Thanks for the app suggestion :), I'll look into updating the docs.

Are you able to give 1-2 use cases for how the app can be utilised in the context of a Kiosk device?

---

I'll look into adding docs for Home Assistant + any broker in general, e.g. EMQX which I'm using to test + develop.

---

With copy/paste, you can copy the Instance ID from the About screen (tap the entry under App -> Instance ID. But yes, I'll also add a way to copy the values with variable replacement - will be for both Client ID and topic names (which I plan to support variables).

---

I think in terms of Webview Kiosk publishing topics, we can have 3:

1. Event - changes to system, e.g. plugged/unplug, url change, etc
2. Responses - e.g. when receiving a "get battery status" command
3. Status - periodically send info at regular (configurable) intervals, e.g. 60 seconds.

Does this cover all of your use cases?

The fewer topics there are, the easier it'll be for me to implement.

[dev-inside]

Good morning,
sipping on my morning coffee and answer, so ignore any typos :D

Why KDE Connect is useful

1. If you set up many devices and you want to copy settings, passwords between Tablet A and Tablet B or your desktop and any of your Tablets
2. If you don't feel comfortable with ADB and you want to copy all the APKs to the devices from your desktop to your devices
3. If you want to use your desktop as Keyboard, Mouse from your desktop to setup your device
4. You don't have FMD and you wanna find your device with an alert tone

These are the usecases I had in mind :)

---

I would make a screenrecording today how it works so you don't have to start from the scratch. Make also some screenshots

---

In my opinion we could make status and event one topic. In the end they both just send infos or you could do it simpler!

wk/command => stays
wk/settings => stays

but you could make it like
wk/command/get/
wk/settings/get/

Could be simpler. I am with you, keep it simple, but I would say I would keep it also intuitive. Just an idea.

[dev-inside]

@nktnet1
Hey, here a video I might publish about WK v HA:
https://download.drive.shadow.tech/s/fXGMZSr6WwEy9ni

[nktnet1]

Wow I just saw the video... that was insane, how did you produce and edit this so quickly?
Very impressive.

---

I've added KDE Connect to app suggestions :) - thank you.

---

With topics, yeah, I'll keep the wk/command and wk/settings for subscribing.

With publishing, the goal for wk/event was to also support variables, e.g.

wk/${APP_INSTANCE_ID}/event/${EVENT_NAME}

where EVENT_NAME can be

• url_change
• locked/unlocked
• inactive/active (i.e. when there's no user interactions)

(the event name will also be included in the payload, in case topic variables aren't used).

But when it comes to the request-response model (referencing these):

• https://www.emqx.com/en/blog/mqtt5-request-response
• https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern

I was planning to use the responseTopic and correlationData introduced in MQTT 5, although not sure if it's well supported in home assistant or other platforms, hence the potential need for wk/response as a fallback.

With wk/status, combining it with wk/event like you said is probably a good idea for the first release.

[nktnet1]

Can you try testing v0.25.0.1-mqtt-beta from here:

• https://github.com/nktnet1/webview-kiosk/tree/v0.25.0-mqtt-beta

New changes are below.

Publish Event

You can use a topic like wk/event/${EVENT_NAME}

Examples of what will be published

• wk/event/url_visited

  {
    "event": "url_visited",
    "identifier": "5a836b10-ee7e-410a-9b29-066e8c718875",
    "appInstanceId": "4795d2af-a20f-4a84-ba58-b9ce4dc2e673",
    "url": "https://webviewkiosk.nktnet.uk"
  }

• wk/event/lock

  {
    "event": "lock",
    "identifier": "32a8ca65-ea57-4efb-aacc-066cc4c51d43",
    "appInstanceId": "4795d2af-a20f-4a84-ba58-b9ce4dc2e673"
  }

• wk/event/unlock

  {
    "event": "unlock",
    "identifier": "befc354d-b217-4763-92a9-82beae521ab5",
    "appInstanceId": "4795d2af-a20f-4a84-ba58-b9ce4dc2e673"
  }

The identifier for "event" is just a UUID for each message.

Publish Response

Currently only supports get_status. Topic is wk/response.

I will probably also support wk/response/${RESPONSE_TYPE} in the future.

{
  "command": "get_status",
  
  // Optional
  "identifier": "example-id",  // response will use the same value
  "responseTopic": "",         // if specified, response will be published here instead of `wk/response`
  "correlationData": ""        // response will use the same value
}

The responseTopic and correlationData in the payload will be overridden if those same values are provided in the MQTT 5 protocol.

An example status response is:

{
   "type": "status",
   "identifier": "example-id",
   "appInstanceId": "4795d2af-a20f-4a84-ba58-b9ce4dc2e673",
   "data": {
      "isInteractive": true,
      "lastInteractionTime": 1762863218783,
      "isLocked": false,
      "batteryLevel": 54,
      "currentUrl": "https://webviewkiosk.nktnet.uk"
   }
}

Happy to take suggestions on other data points - although for anything that requires additional android permissions, I'll reserve it for a future release. Will release v0.25.0 with no additional perms.

Restrictions

Basically this: https://hivemq.github.io/hivemq-mqtt-client/docs/mqtt-operations/connect/#restrictions

• receive maximum
• send maximum
• maximum packet size
• send maximum packet size
• topic alias maximum
• send topic alias maximum
• request problem information
• request response information

Misc/Other

• hold setting item to copy (for Client ID, variables such as APP_INSTANCE_ID will be evaluated)
• topic names and client id now also supports the USERNAME variable
• added mqtt.connection.socket_connect_timeout (default 5s to connect before considered failed)

[dev-inside]

Video
Well, have some experience and had some time on my Hand :D I could much better but 5 hours are only this long

---

KDE Connect is amazing! It doesn't really consume battery and does soooo much. It's the best alternative to something like AirDrop. Freaking love it.

---

I'd installed last night (around 10-12h ago) the new version. First thing I saw was: the wk/event/${EVENT_TYPE} placeholder was still on webviewkiosk/event. I guess left from testing.

Had to type it then. Guess it would be cool if you don't type anything to any MQTT-Topic-Fields, then it would default to wk/topicname ^^

I played around with it, but so far I couldn't really use it, but this is user-error, cause you surpassed already my knowledge in MQTT, you goddamn nerd haha :D

---

Personal question: do you use MQTT since I'd recommended to you? Might it change how you work with your devices at work in the future or do you use MDMs or smth else? Had the feeling you really like the MQTT feature :D

AAAAND: can I reach you also via E-Mail?

[nktnet1]

Hmm okay, I'll look into it.

---

Btw, I've tried out localsend and it's great - much better experience than KDE Connect for me (at least on Linux).

Not sure what you mean by

you have always to give permission to send things

Since I seem to just be able to send without any hassl. There's also a way to save automatically:

Will be adding this to App Suggestions for sure :).

[dev-inside]

Thanks :) I guess, we are almost ready with the MQTT-Release - except ehm :D Wakeup/Unlock display (yeah I know you avoid it hahaha)

---

Oh, didn't know that's a thing. Maybe I'd ignored it or it's a newer feature. Anyways, I can recommend KDE Connect and Localsend to anyone. BTW: which Linux did you use? Not shure if it matters, but there are forks for KDE-Connect cause normally it integrates natively with KDE Desktop. Zorin OS (what you for shure wouldn't use) has Zorin Connect and there is also a Gnome Fork as shell extension which might be the best solution if you use Gnome DE in general or related ones like Budgie, the Ubuntu shit (belive Unity or smth) https://extensions.gnome.org/extension/1319/gsconnect. If your issue was iPhone related, well then blame Tim Apple :D

[nktnet1]

@dev-inside try v0.25.0.5-mqtt-beta :)

• https://github.com/nktnet1/webview-kiosk/tree/v0.25.0-mqtt-beta

The payload is

{
  "command": "get_system_info"
}

A typical response could be:

{
  "responseType": "system_info",
  "appInstanceId": "7af9b962-b0a9-4b77-bd29-f4214b469006",
  "data": {
    "app": {
      "name": "Webview Kiosk",
      "packageName": "uk.nktnet.webviewkiosk",
      "versionName": "0.25.0.5-mqtt-beta",
      "versionCode": 90,
      "minSdk": 21,
      "targetSdk": 36,
      "isDebug": true,
      "installer": null,
      "isDeviceOwner": false,
      "isLockTaskPermitted": false,
      "instanceId": "7af9b962-b0a9-4b77-bd29-f4214b469006"
    },
    "device": {
      "releaseVersion": "15",
      "sdkVersion": 35,
      "incrementalVersion": "12592187",
      "webViewVersion": "141.0.7390.122",
      "screenWidth": 1080,
      "screenHeight": 2400,
      "screenDensity": 2.625,
      "isManagedProfile": false,
      "timeZone": "Australia/Sydney",
      "locale": "en_US",
      "totalMemory": 2070986752,
      "totalStorage": 6228115456,
      "manufacturer": "Google",
      "model": "sdk_gphone64_arm64",
      "brand": "google",
      "device": "emu64a",
      "product": "sdk_gphone64_arm64",
      "hardware": "ranchu",
      "board": "goldfish_arm64",
      "bootloader": "unknown",
      "securityPatch": "2024-09-05",
      "supportedAbis": [
        "arm64-v8a"
      ],
      "supported32BitAbis": [],
      "supported64BitAbis": [
        "arm64-v8a"
      ],
      "buildFingerprint": "google/sdk_gphone64_arm64/emu64a:15/AE3A.240806.036/12592187:user/release-keys"
    }
  }
}

I included all the info just because the code is re-used from the about screen.

---

Wakeup/Unlock display

Still contemplating his, since it might mean Webview Kiosk needs to run in the background + require permissions that may be disliked by certain users.

Will need to do some research into what's first needed though.

Would an alternative like dimming the screen on inactivity (set brightness to 0), then reset brightness when a message is received, suffice?

Update: introduced this option in v0.24.31.

---

BTW: which Linux did you use

Arch

If your issue was iPhone related

Nope 😅. Never owned an iphone - although Android is becoming more and more like iOS so...

• https://f-droid.org/en/2025/10/28/sideloading.html

Maybe one day.

[dev-inside]

hey,
have to look into it tonight. Was busy af :|

[nktnet1]

Understandable 😅 - no worries!

I've pushed v0.25.0.10-mqtt-beta (edited) - there are quite a few breaking API changes (sorry).

1. wk/settings, you will now need payload like this:

   {
     "messageId": "helloworld", // optional
     "showToast": true, // optional - whether to show a message saying settings was updated from MQTT
     "refresh": true, // whether to refresh the activity (some settings needs this to apply)
   
     // Notice that this is now nested (before you just send the setting keys at the top level)
     "data": {
       "appearance.theme": "SYSTEM",
       "device.rotation" : "auTo"
     }
   }

2. I've removed all GET wk/command - this will now be reserved for actions on the webview only (lock/unlock/go_home/go_to_url/go_back/go_forward etc)

   Instead, you can use wk/request, with a payload like:

   {
     "requestType": "get_status"   // or get_system_info, get_settings
   }

3. When you first connect to MQTT, there will be a "connected" event that gets sent to wk/event, with the following payload (it's similar to wk/request's get_status):

   {
     "eventType": "connected",
     "messageId": "0e6fcb66-9810-4185-9258-936be7fc045d",
     "appInstanceId": "a3f4fd20-cd1b-46bf-81df-28244de01baf",
     "data": {
       "currentUrl": "https://webviewkiosk.nktnet.uk",
       "isInteractive": true,
       "lastInteractionTime": 1763442134505,
       "isLocked": false,
       "batteryPercentage": 62,
       "appBrightnessPercentage": -1,
       "systemBrightness": 255
     }
   }

[kiddyfurby]

This is great. Being able to control webview-kiosk over MQTT really make it stands out and I could imagine lots of applications.
May I suggest we add a prefix settings, such that if i set prefix to "KIOSK1", then the mqtt paths becomes: wk/KIOSK1/command, wk/KIOSK1/settings, etc.

This would be very useful when you have multiple kiosk connected to the same mqtt server doing different roles.

[nktnet1]

Hey @kiddyfurby,

Actually, the whole topic name is configurable, so you can change it to anything you want in the app settings.

Variables are also supported - e.g. you could change the command topic to

wk/${USERNAME}/${APP_INSTANCE_ID}/command

All of these will be properly documented on the official website when v0.25.0 is released.

[dev-inside]

Hey @nktnet1
Lotta delay,
looks good to me so far! You know what is left hahaha - really happy how it tutned out so far. I gonna demonstrate now what I want

WHAT DO WE WANT?
UNLOCK SCREEN VIA MQTT

WHEN DO WE WANT IT?
UNLOCK SCREEN VIA MQTT

😁 😁 😁 😁 😁 😁 😁 😁 😁 😁

[nktnet1]

Yeah the video would be really cool! But no pressure - I know you've been quite busy :).

I'm probably also going to create a Websocket MQTT client somewhere on

• https://webviewkiosk.nktnet.uk

Similar to the web version of MQTTX:

• https://mqttx.app/web-client

But dedicated for Webview Kiosk (i.e. with buttons/UI in place) so that the features can be tested more easily.

[dev-inside]

I'm probably also going to create a Websocket MQTT client somewhere on

If you need help with the UI, let me know. I do sexy stuff from time to time:
https://gitlab.com/fmd-foss/fmd-server/-/issues?show=eyJpaWQiOiIxMjMiLCJmdWxsX3BhdGgiOiJmbWQtZm9zcy9mbWQtc2VydmVyIiwiaWQiOjE3NjkxNTQyM30%3D

[dev-inside]

@nktnet1
So, how is it going? When do you release your MQTitties 😁 I mean the 25.0 :D
So far I'm really satisfied with the feature!

[nktnet1]

Maybe some time this week or the next.

Currently writing documentations + making final tweaks. You can track progress in #52.

I'll be releasing 99 (v0.24.41) with all of the current changes pending in the main branch first, before doing a major release for 100 (v0.25.0) :).

My company is also trialling it this week at an official event (using it for interactive forms), so I'll get to see how well the MQTT features runs in a live environment.

---

P.s. I also wrote a small guide for how to run the EMQX broker on Dokploy with Traefik (should be similar steps for other PaaS that supports Docker Compose, e.g. Coolify)

• EMQX - MQTT broker (with SSL/TLS support for MQTTS and WSS) Dokploy/dokploy#3126

[nktnet1]

@dev-inside I've written the first draft of the docs.

If you have time, could you try installing v0.25.0.13-mqtt-beta:

• https://github.com/nktnet1/webview-kiosk/tree/v0.25.0-mqtt-beta

And use it based according to the documentation here:

• https://mqtt-webview-kiosk.tamkhietnguyen1.workers.dev/docs/settings/mqtt/

Thanks :D - I see the light at the end of the tunnel.