web_server v3 -- home assistant styling

[proper pawn]

Just a small show off what I am working on - as for now as an external component.

Key improvements::

• web server styling resembles to the home assistant entitites card theme
• icons are sent for all entitites
• entity_categories are introduced and entities are grouped by sensor+control/config/diag
• device uptime experiment from ping
• you need to host the www.js file to try this
• auto fallback for a very minimal web_server in case you are offline

config:

web_server:
  port: 80
  ota: false
  js_url: https://attilafarago.hu/smarthome/esphome_web_server/www.js

feel free to check out: https://github.com/afarago/esphome/tree/webserver-improvements
optionally: https://github.com/afarago/esphome-webserver/tree/ha-styling

According to my tests the new webserver consumes same RAM, and 1k additional flash.

Please comment what are your ideas, comments, hints and what would you be happy to see.

[rotund willow]

how does the *auto fallback for a very minimal web_server in case you are offline look like?

[proper pawn]

if index.html does not detect the js being loaded the js redirects to ?redirect where web_server renders a minimal js compiled from server_index_fallback.h
(entitites + update from the eventsource)

with gz the fallback is 511 bytes total in addition

[rotund willow]

that's just showing states?

[proper pawn]

yep, at the moment i did a minimal implementation
https://github.com/afarago/esphome-webserver/blob/ha-styling/v2fallback/index.html
could be reduced even further if needed 🙂

<script>
(() => {
  window.s = new EventSource('events');

  let entities = [];
  let uptime = -1;
  let config = {};

  window.s?.addEventListener("ping", (e) => {
    uptime = e.lastEventId;

    if (e.data) {
      const data = JSON.parse(e.data);
      config = data;

      let div = document.createElement("tr");
      div.innerHTML = `<th colspan=2>${data.title} - ${data.comment}</th>`;
      const main = document.getElementById("m");
      main.insertBefore(div, main.firstChild);
    }
  });

  window.s?.addEventListener("state", (e) => {
    uptime = e.lastEventId;

    const data = JSON.parse(e.data);
    let idx = entities.findIndex((x) => x.id === data.id);
    if (idx === -1 && data.id) {
      entities.push(data);
      let tr1 = document.createElement("tr");
      tr1.id = data.id;
      tr1.innerHTML = `<td>${data.name.replace(config.title,`<n>${config.title}</n>`)}</td><td >${data.value??''}</td>`;
      const main = document.getElementById("m");
      main.append(tr1);
    } else {
      document.querySelector(`#${data.id} .v`).innerHTML = data.value;
    }
  });
})();
</script>

<style>html,td{font-family:Calibri} n{font-size:smaller;color:lightgray} td:first-child{padding-right:2em}</style>
<table id="m">
</table>

[supple heart]

I like this very much 😉

I tend to use the webserver a lot on some devices, I swapped over to this version yesterday and I am already used to its layout and like the design and layout

[supple heart]

lol i went thro all the sensors and made icons for them all now 😉

[rotund willow]

would be nice to be able to host the resurces locally. Not necessarily locally to the node, but locally to the network, eg. in the dashboard's webserver or in a custom folder under www in HA.

[frozen rain]

Is it possible to add more light controls (rgb)

[proper pawn]

It is quite possible, just use the js_url
this is mine -

web_server:
  port: 80
  ota: false
  js_url: http://192.168.0.2/local/esphome-webserver-v2/www.js

[proper pawn]

Would you detail this out a bit more?

[frozen rain]

For lights, you only get brightness control on the web server page.
Could you also add color temperature or rgb sliders?

[rotund willow]

A color picker

[proper pawn]

Great idea!
My only RGB control is a Wemos WS2812B RGBx7 shield, yet happy to experiment.
Would you come up with a few design ideas?

I could e.g. add a button to open up an RGB popup.
Any ideas for an RGB picker?
I have found these two, but if you find a nicer one that could be OK as well.
https://github.com/yairEO/color-picker
https://www.cssscript.com/hsv-hsl-color-wheel-picker-reinvented/

Please do some mockuping and I will do the coding 😄

I'd prefer the SHelly solution, but cannot find any js libs for that.

[inland relic]

Looks nice, great work

[vast gull]

cant you just use the color picker built into the browser?

[rotund willow]

Just make sure it's mobile friendly though

[rotund willow]

And the icons?

[proper pawn]

You are completely right. Seems tricky as iconify uses its own api.
https://github.com/iconify/iconify/issues/2
We might consider extracting a set of icons and bundle them. This however varies per app.
A possible option would be to generate a specific set (locally), use it instead of the on demand option and then rebuild the app.

[rotund willow]

This has to be handled. So if the .js is locally hosted the UI should still be usable without the icons if they are not accessible.

Not the read-only fallback, as that doesn't allow interactivity. Or simply fallback to something like webserver v1 which is still interactive at a degree. (Switches, Covers etc)

[proper pawn]

Checked it.
Basically the client device (your browser / mobile) is requesting the iconify resources. If they are unavailable fallback is that no icon is rendered.
I think this is quite OK.

[proper pawn]

Great idea.
Completed first iteration, happy testing.

updated at https://attilafarago.hu/smarthome/esphome_web_server/www.js

[vast gull]

nice to use the browsers built ins but its crazy how different they are between browsers 😅

so i like that youre overhauling the frontend of what esphome webserver serves, but would it be a good idea, as a separate project, to have an web app/pwa that esphome hosts or you can host locally that would just interact with the device/sensors via a rest api or whatever api. that would keep the on device storage use to nothing and allow you to get as fancy as you want for the frontend. you would go to this frontend and point it at all of your devices type thing.

[supple heart]

great work

[proper pawn]

The concept of the web_server component is just as you describe if I understand you clearly.
This pwa is external and by default not using any memory of the esp device.

[vast gull]

ya i guess my question is, how do you feel about making an external frontend to talk to the rest api?

[proper pawn]

Apologies - still I might not follow completely. 😄
This is an external frontend. Backend is the ESP node, FE is hosted on an external site (e.g. https://oi.esphome.io/v2/www.js), ESP node server a lightweight FE, primarily for including the www.js (and in my case adding a fallback mechanism for an ESP hosted fallback JS).

If you refer to creating a complete backend+separate frontend - I'd suggest e.g. an AppDaemon under HA.

[vast gull]

oh i thought you were overhauling the stock esphome web server component frontend.

[rotund willow]

Since it's fundamentally pretty different, this should be named as web_server v3 - to avoid confusion later

v2 is still something which can be 100% offline and run from the node, can be configured so no external resources would needed

[proper pawn]

As I understand normally v2 does not really run from the device either, but from https://oi.esphome.io/v2/www.js.
The only difference is the icons, where we currently see a graceful degradation.

For me v2 or v3 seems all the same, but maybe I miss a point. I cannot really see the real use of coexistance of v2 and v2+/v3. (yet similarly I do not know ho uses v1)
What do you think?

[rotund willow]

Think of the user perspective.
v1, v2, you have controls r/w all offline from internet. If you embed js, you get everything afaik.

With your pack, when you're offline, you fallback to a r/o status page. You can embed the js without the icons.

It's a small step back functionally, a big step ahead visually (if you're online).

That's why I say pack it as v3, one can choose whichever he/she wants...

But maybe I misunderstand smth.

[supple heart]

maybe Jesse and Keith need to have a look at this

[proper pawn]

You are right, I agree that from the theoretical perspective this introduces a visible degradation (inability to fully embed as local).
I would think that as the graceful degradation is in place and there is no big difference of not having icons with the local js option.

Yet I must admit that I am too engaged with the new look and feel and my vision might be shaded to form a real opinion of my own 😄

So whichever option is decided I am happy with it, just let me know the repo owner preference. @spark crown

[spark crown]

You can set local: true to embed the js and be served from the webserver too

I think it would be fine to keep v2 with an updated style like this

[dawn basin]

Need to see the sliders

[proper pawn]

would you care to add more details?

[dawn basin]

Brightness sliders on lights along with colour selection tools. I posted this before reading the recent messages in this thread. Value selection could be great along with the brightness slider to manually meter brightness/colour value in text box.

[dawn basin]

first one with this

OTA option is missing from this dashboard ```yaml
esp8266:
board: esp01_1m

colour picker 😍

effects menu

[dawn basin]

effects changes when we click away from the selection

[crimson pilot]

Is it possible to have multiple color selectors?
For example if I have multiple WS2812 strips or one is indicator/status and the other is the LED strip

Great work btw!

[fleet cloak]

When you say one is indicator, what does that mean?

[crimson pilot]

I only have one of these. But both Status and LEDs are neopixelbus instances

Am I missing something or the current implementation only supports one color picker?

[fleet cloak]

You didn't answer my question.

[crimson pilot]

What is an indicator?
If I have a single WS2812 LED on the board that is used as an indicator (ie. red -> bad, green->good, teal-> active etc)

[fleet cloak]

How is it configured? Does it have a name?

[crimson pilot]

# Example configuration entry
light:
  - platform: neopixelbus
    id: StatusLED
    variant: SK6812
    type: GRBW
    pin: GPIO10
    method:
      type: esp32_rmt
      channel : 0
    num_leds: 1
    name: "Status"
  - platform: neopixelbus
    id: LedsStrip
    variant: WS2812
    type: GRB
    pin: GPIO6
    method:
      type: esp32_rmt
      channel : 1
    num_leds: 60
    name: "LEDs"

[fleet cloak]

Ok

[dawn basin]

you are using Esp32S3 or Esp32C3?

[proper pawn]

You have two variants. Could you please open upe the eventstream and post it here? Currenty I add color picker for rgb compatible displays only.
You will find it in http://<your_ip>/events

[crimson pilot]

It's C3

[crimson pilot]

You are right, one is RGB (WS2812) and the other one is RGBW (SK6812).

[crimson pilot]

Here is the output of the the /events

retry: 30000
id: 121753
event: ping
data: {"title":"sk-esp32c3-test","comment":"","ota":true,"log":true,"lang":"en"}

event: state
data: {"id":"light-status","name":"Status","state":"ON","effect":"None","color_mode":"rgbw","brightness":119,"color":{"r":255,"g":255,"b":255,"w":255},"white_value":255,"effects":["None","Random","Random Effect With Custom Values"]}

event: state
data: {"id":"light-leds","name":"LEDs","state":"OFF","effect":"None","color_mode":"rgb","brightness":255,"color":{"r":255,"g":255,"b":255},"effects":["None","Random","Random Effect With Custom Values"]}

retry: 30000
id: 130669
event: ping
data: 

retry: 30000
id: 140670
event: ping
data: 

retry: 30000
id: 150672
event: ping
data: 

retry: 30000
id: 160668
event: ping
data: 

retry: 30000
id: 170667
event: ping
data: 

retry: 30000
id: 180674
event: ping
data: 

I changed the config to test random effects but otherwise it's the same as the one I posted before

@proper pawn So if I change the other LED from GRBW to GRB both of them have color picker.
I guess at some point it would be nice if we could use color selector for RGBW as well. 🙂

[dawn basin]

there are other beside RGB eg GRB and BRG etc etc too

[fleet cloak]

That point is that when you add the W, it needs a different color picker.

[dawn basin]

RGBW and RGBW + CCT etc?

[fleet cloak]

yes

Although I've never heard of RGW before. 🙂

[dawn basin]

corrected

[proper pawn]

I can simply use the same system color picker perhaps. Would that be good here?

[dawn basin]

I am fine with current one

[crimson pilot]

I think that should work. Just acknowledging that RGBW should also have a color picker is nice.
Later on, having the mapping to utilize the W channel as well would be really nice.

[proper pawn]

Any details or ideas on that from UI perspective? How would you envision the user flow?

[crimson pilot]

Probably it makes most sense to keep the color picker always the same.
In the "background" you could detect if you have RGB or RGBW and do the "correction" with white channel.

The W can also be warm-white and cool-white... but at some point you should draw the line and say this is an edge case, we can cover it if there is a really good use-case for it.
For my usage; even just having the color picker for both RGB and RGBW and completely ignoring the W channel would be enough.
I just want the user to be able to select a custom color through UI. If W channel is not used, it's not as bad as if the entire color picker is missing. 🙂

[proper pawn]

OK, for the time being I am fine to add it, let's see if that gets approved, merged 😄

[proper pawn]

all done, please check it

[crimson pilot]

Awesome, thank you!

[proper pawn]

We need to just wait for the official review and merge of the two PRs on esphome and esphome-webserver patiently 😄

[frozen rain]

sorry, how do I install this, do I just compile from your esphome branch?
or I add these in the yaml

web_server:
  port: 80
  ota: false
  js_url: https://attilafarago.hu/smarthome/esphome_web_server/www.js

[supple heart]

just add this ^^

[frozen rain]

am i missing something? i don't see the color picker

[proper pawn]

No idea, we are blind without the config and the eventstream.
Please add your yaml and http://your-device/events content 😉

[frozen rain]

For events

retry: 30000
id: 12261392
event: ping
data: {"title":"treatlife-corner","comment":"","ota":false,"log":true,"lang":"en"}

event: state
data: {"id":"light-treatlife-corner","name":"treatlife-corner","state":"ON","color_mode":"cwww","brightness":209,"color":{"c":255,"w":0},"effects":["None"]}

retry: 30000
id: 12262148
event: ping
data: 

retry: 30000
id: 12272152
event: ping
data: 

retry: 30000
id: 12282148
event: ping
data: 

retry: 30000
id: 12292148
event: ping
data: 

id: 12292778
event: log
data: [D][dgr:687]: Sending corner1 message to network: seq=2, flags=64

retry: 30000
id: 12302152
event: ping
data: 

id: 12311182
event: log
data: [D][dgr:687]: Received corner1 message from 192.168.1.33: seq=138, flags=64

retry: 30000
id: 12312150
event: ping
data: 

retry: 30000
id: 12322148
event: ping
data: 

retry: 30000
id: 12332148
event: ping
data: 

retry: 30000
id: 12342152
event: ping
data: 

retry: 30000
id: 12352148
event: ping
data: 

id: 12355526
event: log
data: [D][dgr:687]: Sending corner1 message to network: seq=2, flags=64

retry: 30000
id: 12362148
event: ping
data: 

retry: 30000
id: 12372152
event: ping
data: 

retry: 30000
id: 12382148
event: ping
data: 

event: state
data: {"id":"light-treatlife-corner","name":"treatlife-corner","state":"ON","color_mode":"cwww","brightness":209,"color":{"c":255,"w":0},"effects":["None"]}

[crimson pilot]

I think you are experiencing same issue as the one I reported before.
Color picker appears for RGB but not for RGBW or RGBWW 🙂

[proper pawn]

cwww color model?
The control reports color as "color":{"c":255,"w":0}
No idea what should I do after the color picker returns RGB in this case.
Any ideas?

At the moment I am adding the ones I'm sure will work. If there is a more general solution, happy to add it 😉

[frozen rain]

Ok, so this is probably a bug for now

[frozen rain]

How to know which cww color model?

[dawn basin]

if we could input numbers for the sliders,, that could be awrsome

and presence Icons

[hot tulip]

What about two sliders for CW+WW instead of a color picker?

[proper pawn]

OK, I promise once we get an approve and an official merge from the esphome team I will put effort to add all color models supported.

[fleet cloak]

I thought there already was an approval of it in general. It would be better to have more working before merging.

[proper pawn]

Yes, as I understood as well in general both parts (esphome, esphome-webserver) are OK to go.

Webserver code can be enhanced to an infinity, and the key concept of the PR is not adding more control but to move it to a HomeAssistant styled upgrade.
Before investing endless amount of time to add controls and improvements I do want to wait for the merge. This is my first PR for these repos and would like to avoid adding too big and complex increments at once.

[dawn basin]

I am already using these in my new nodes

[dawn basin]

uptime time doesn't update unless you refresh the page

[proper pawn]

It updates for me allright. Could you elaborate on your details, config?

[dawn basin]

If you leave the page for some time and revisit without pressing F5 time is not updated.

In my screenshot actual uptime is 1904s =/= 21mins

[proper pawn]

interesting - to start understanding it better I would need the '/events', eventsource and the full screenshot.

[dawn basin]

/events is subdomian on same ip?

[proper pawn]

yes, exactly

[dawn basin]

https://pastebin.com/9HdFAVZA

I am on Mobile and this node is running

[dawn basin]

https://pastecode.io/s/zbdjvfiw

on the node I noticed it

[proper pawn]

New feature: line graph and expand

While patiently waiting for the PR merge I have added a few features I had in mind.
Graph for numeric sensors - with Click to expand graph
Control-click to expand entitites or log table.
https://github.com/afarago/esphome-webserver/tree/ha-styling-improvements-2

[proper pawn]

Hi! Your screenshot shows th 8min 38sec mark, while the log show 337 s (5min) mark. I have no idea, but happy to debug - if you could please create a screenshot of the problem and add the respective eventsource listing for the same/overlapping interval - I could have a chance.

[dawn basin]

retry: 30000
id: 2313483
event: ping
data: {"title":"esps2","comment":"","ota":false,"log":true,"lang":"en"}

event: state
data: {"id":"light-sys_status","name":"sys_status","state":"OFF","color_mode":"onoff","color":{},"effects":["None"]}

event: state
data: {"id":"sensor-uptime_sensor","name":"Uptime Sensor","value":2256.583984,"state":"2257 s","icon":"mdi:timer-outline"}

event: state
data: {"id":"sensor-wifi_signal_db","name":"WiFi Signal dB","value":-47,"state":"-47 dBm","icon":""}

event: state
data: {"id":"sensor-bme280_temperature","name":"BME280 Temperature","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-bme280_pressure","name":"BME280 Pressure","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-bme280_humidity","name":"BME280 Humidity","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-wifi_signal_percent","name":"WiFi Signal Percent","value":100,"state":"100 Signal %","icon":""}

event: state
data: {"id":"sensor-a_uptime_sensor","name":"A Uptime Sensor","value":2280.39209,"state":"2280 s","icon":"mdi:timer-outline"}

event: state
data: {"id":"button-s2__restart","name":"S2  restart"}

event: state
data: {"id":"button-s2_restart__safe_mode_","name":"S2 Restart (Safe Mode)"}

event: state
data: {"id":"text_sensor-device_info","name":"Device Info","value":"2023.12.0-dev|Chip: ESP32-S2 Features:WIFI_BGN, Cores:1 Revision:0|ESP-IDF: 4.4.5|EFuse MAC: 48:27:E2:59:EB:E8|Reset: Software Reset Digital Core|Wakeup: Unknown","state":"2023.12.0-dev|Chip: ESP32-S2 Features:WIFI_BGN, Cores:1 Revision:0|ESP-IDF: 4.4.5|EFuse MAC: 48:27:E2:59:EB:E8|Reset: Software Reset Digital Core|Wakeup: Unknown","icon":"mdi:chip"}


id: 2316588
event: log
data: [D][sensor:094]: 'Uptime Sensor': Sending state 2316.58691 s with 0 decimals of accuracy

event: state
data: {"id":"sensor-uptime_sensor","value":2316.586914,"state":"2317 s"}

retry: 30000
id: 2317356
event: ping

event: state
data: {"id":"text_sensor-reset_reason","name":"Reset Reason","value":"Software Reset Digital Core","state":"Software Reset Digital Core","icon":"mdi:restart"}

event: state
data: {"id":"text_sensor-a_uptime_human_readable","name":"A Uptime Human Readable","value":"38m 0s","state":"38m 0s","icon":"mdi:clock-start"}

event: state
data: {"id":"text_sensor-esphome_version","name":"ESPHome Version","value":"2023.12.0-dev Dec 12 2023, 07:48:59","state":"2023.12.0-dev Dec 12 2023, 07:48:59","icon":"mdi:new-box"}

events and screenshot from same device at same time/just took the time for the screenshot

during this 1 hour I did flashed this node. which means top uptime is calculated from the moment this node is powered up. while internal esphome uptime sensor calculates from the last boot

[dawn basin]

retry: 30000
id: 724883
event: ping
data: {"title":"esps2","comment":"","ota":false,"log":true,"lang":"en"}

event: state
data: {"id":"light-sys_status","name":"sys_status","state":"OFF","color_mode":"onoff","color":{},"effects":["None"]}

event: state
data: {"id":"sensor-uptime_sensor","name":"Uptime Sensor","value":706.875,"state":"707 s","icon":"mdi:timer-outline"}

event: state
data: {"id":"sensor-wifi_signal_db","name":"WiFi Signal dB","value":-48,"state":"-48 dBm","icon":""}

event: state
data: {"id":"sensor-bme280_temperature","name":"BME280 Temperature","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-bme280_pressure","name":"BME280 Pressure","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-bme280_humidity","name":"BME280 Humidity","value":null,"state":"NA","icon":""}

event: state
data: {"id":"sensor-wifi_signal_percent","name":"WiFi Signal Percent","value":100,"state":"100 Signal %","icon":""}

event: state
data: {"id":"sensor-a_uptime_sensor","name":"A Uptime Sensor","value":697.7509766,"state":"698 s","icon":"mdi:timer-outline"}

event: state
data: {"id":"button-s2__restart","name":"S2  restart"}

event: state
data: {"id":"button-s2_restart__safe_mode_","name":"S2 Restart (Safe Mode)"}

event: state
data: {"id":"text_sensor-device_info","name":"Device Info","value":"2023.12.0-dev|Chip: ESP32-S2 Features:WIFI_BGN, Cores:1 Revision:0|ESP-IDF: 4.4.5|EFuse MAC: 48:27:E2:59:EB:E8|Reset: Power On Reset|Wakeup: Unknown","state":"2023.12.0-dev|Chip: ESP32-S2 Features:WIFI_BGN, Cores:1 Revision:0|ESP-IDF: 4.4.5|EFuse MAC: 48:27:E2:59:EB:E8|Reset: Power On Reset|Wakeup: Unknown","icon":"mdi:chip"}

event: state
data: {"id":"text_sensor-reset_reason","name":"Reset Reason","value":"Power On Reset","state":"Power On Reset","icon":"mdi:restart"}

event: state
data: {"id":"text_sensor-a_uptime_human_readable","name":"A Uptime Human Readable","value":"11m 38s","state":"11m 38s","icon":"mdi:clock-start"}

situation in reverse

[proper pawn]

Thanks -- your logs seems to be complete and OK.

id: 2316588
event: log
data: [D][sensor:094]: 'Uptime Sensor': Sending state 2316.58691 s with 0 decimals of accuracy

event: state
data: {"id":"sensor-uptime_sensor","value":2316.586914,"state":"2317 s"}

retry: 30000
id: 2317356
event: ping

• Does the heart icon do the "beat" animation
• opening the dev tools (F12), no errors on the console?
• which browser, version & op system w version are you using?
• info: the time is updated on the ping event, using the id (https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent/lastEventId) in ms
• when looking at the event log, you do see ping messages coming in at regular pace? (~10s if I recall right)

[dawn basin]

Chrome is up to date
Version 121.0.6167.8 (Official Build) beta (64-bit)

[dawn basin]

heart only beats when refreshed

time on sensor and in logs does updates regularly

WIndows 11 beta

13:28:02
[I]
[ota:117]
Boot seems successful, resetting boot loop counter.
13:28:02
[D]
[esp32.preferences:114]
Saving 1 preferences to flash...
13:28:02
[D]
[esp32.preferences:143]
Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
13:28:07
[D]
[sensor:094]
'WiFi Signal dB': Sending state -59.00000 dBm with 0 decimals of accuracy
13:28:07
[D]
[sensor:094]
'WiFi Signal Percent': Sending state 82.00000 Signal % with 0 decimals of accuracy
13:28:44
[D]
[sensor:094]
'Uptime Sensor': Sending state 342.31400 s with 0 decimals of accuracy
13:28:49
[D]
[text_sensor:064]
'A Uptime Human Readable': Sending state '5m 48s'
13:28:49
[D]
[sensor:094]
'A Uptime Sensor': Sending state 347.89600 s with 0 decimals of accuracy
13:29:07
[D]
[sensor:094]
'WiFi Signal dB': Sending state -58.00000 dBm with 0 decimals of accuracy
13:29:07
[D]
[sensor:094]
'WiFi Signal Percent': Sending state 84.00000 Signal % with 0 decimals of accuracy
13:29:44
[D]
[sensor:094]
'Uptime Sensor': Sending state 402.31400 s with 0 decimals of accuracy
13:29:49
[D]
[text_sensor:064]
'A Uptime Human Readable': Sending state '6m 48s'
13:29:49
[D]
[sensor:094]
'A Uptime Sensor': Sending state 407.89600 s with 0 decimals of accuracy
13:30:07
[D]
[sensor:094]
'WiFi Signal dB': Sending state -57.00000 dBm with 0 decimals of accuracy
13:30:07
[D]
[sensor:094]
'WiFi Signal Percent': Sending state 86.00000 Signal % with 0 decimals of accuracy
13:30:44
[D]
[sensor:094]
'Uptime Sensor': Sending state 462.31000 s with 0 decimals of accuracy
13:30:50
[D]
[text_sensor:064]
'A Uptime Human Readable': Sending state '7m 48s'
13:30:50
[D]
[sensor:094]
'A Uptime Sensor': Sending state 467.89600 s with 0 decimals of accuracy
13:31:07
[D]

[proper pawn]

I think I got it. You are using esp-idf framework, while I use Arduino.
For some reason esp-idf does not send the ping regularly for the eventstream. Please raise a ticket for esphome/web_server_idf component owner is @little lotus .

I will do a workaround and update the "uptime header" not only for ping, but for all incoming event messages that has the id field set (that is log messages). It seems that state updates miss this field.

[proper pawn]

updated, committed and built: https://attilafarago.hu/smarthome/esphome_web_server/www.js

[dawn basin]

got some new

if this is some kind of graph in webpage it will be a awesome feature

Live graphs I am loving it 😻

[dawn basin]

yes now heart is beating on each event too

[dawn basin]

most useful on ith presnce radars

[supple heart]

I am getting that instead of the heart icon for the heartbeat

[dawn basin]

my heart beat has no arrhythmia on ECG

[supple heart]

strange - it worked on the other versions of the js

[dawn basin]

graphs working for you?

[supple heart]

yes fine

[proper pawn]

Strange -- any hints on the browser, OS and project? 😄

[supple heart]

win10, Opera + Firefox

[proper pawn]

Strange: on my win11+ff 120.0.1 it shows perfectly.

[inland relic]

Is there a option to switch between dark mode and light mode in the portal page?

The page works great, graphs are a nice addition

[wispy flame]

have you ever thought about building 2 versions, one with human readable javascript and one with minimized javascript. Minimized could save 30%+ in final size
I tried to put your code into the following but it has a bunch of errors for javascript standard notations
https://jscompress.com/

[proper pawn]

The build process of the project performs minimize and compress steps already.

[dawn basin]

working fine with bk231n

would it possbile to add a relay/button history graph?

[dawn basin]

https://media.discordapp.net/attachments/1186555583684427837/1186579200988168192/image.png?ex=6593c2ff&is=65814dff&hm=39ab8e33cef168318da0b87f47e36593e13e4875c187ed32612063bd2605db7e&

Number component is missing units

#1186555583684427837 message

[dawn basin]

old web

[fleet cloak]

The new one doesn't have a state column, so the unit needs to get combined with the slider.

[dawn basin]

is it possbile to fix it?

[fleet cloak]

I would expect so.

[grand bone]

I love the graph, but wonder if there is a way to save some historical values in the ESP, so that the graph is not empty on initial load? e.g. store an array of 96 values for chosen entities (15-minutes over 24 hours), and provide those to the UI on initial load?

[proper pawn]

Would be a nice idea, yet I have not clue were this from architecture perspective could fit into esphome.
Sensors do not store this, and would be awkward on webserver side.
I was playing around with a similar idea to store the last X log strings and already show it on reload (also making sure that already connected client do not get that from the eventstream).
Any ideas/hints?

Is the code owner of web_server also OttoWinter? (only web_server_base has CODEOWNERS)

[grand bone]

I presume you collect values via the events channel. Do you time stamp them when they arrive, or do they come with the timestamp in the event?

I’m wondering whether one could add an optionally compiled “history: count: 96 interval: 15m type: average” to the sensor entity. That could also support local displays that want to show a graph, which is an existing use case with a not-entirely satisfactory solution.

Then, on connection to the web server, either the server spams the event stream with time stamped entity values which you can collect, or they can be requested

[proper pawn]

This is not working like this.
Eventstream is an incremental thing, client only sees thing after it is connected (e.g. web page loaded). For an initial load there is a one time initial payload (e.g. effects, entity icon etc) that could convey this data.
Yet esphome would need to store it somewhere to emit the data once a client is connected.
I have no idea where this would fit into the current esphome architecture.

[grand bone]

As I was saying, it could be included as an optional part of the sensor entity. Space would be allocated for it only if a history: node was configured for the sensor, and some details provided about how large to make the history, and how to update that history. That could conditionally make a getHistory() function available, that returns a list of timestamped float values, or else a set of int getHistoryCount(), int getHistoryInterval(), float getHistoricalValue(int n) would also allow the necessary information to be calculated within esphome.

Here's an example of how it has been done in the past: https://community.home-assistant.io/t/history-chart-or-graph-for-hardware-display-in-esphome/285516/6

And here is the display: 'graph: component: https://beta.esphome.io/components/display/index.html#display-graphs
which clearly must have some overlap with what I am suggesting.

[proper pawn]

Nice catch! Implemented and added to the existing PRs
https://github.com/esphome/esphome/pull/5854 and
https://github.com/esphome/esphome-webserver/pull/49

Help needed -- I have implemented a local_fallback option to the web_server.
https://github.com/esphome/esphome/pull/5853

I received a quite correct request to create the build process for the fallback page - where I am short on knowledge.
(minify html+js, gzip, encode to hex, create .h file)

Is someone willing to give some guidance or a helping hand on this?

manual steps:

1. minify https://www.toptal.com/developers/html-minifier
2. rename to something short (gzip stores name) - like "p"
3. gzip with max/9 setting
4. encode to hex https://tomeko.net/online_tools/file_to_hex.php?lang=en

[proper pawn]

Love the examples. There the storeage is accomplished by a manually added globals variable.
I am not yet seeing a proper place for this in the architecture between the entity_base and the and the web_server components, but if you create a PoC implementation we can work together to make it happen.

[proper pawn]

Could be nice, yet not idea how that would look like in reality.
Would you create a fiddle mock using https://chartjs.org and some sample data?

[grand bone]

Also not seeing how to switch between light and dark mode?

[dawn basin]

Already have some in history graph

[dawn basin]

I will check chart. Js for more examples

[grand bone]

trying to figure out the best way to define the history variable in sensor.h. Ideally, the variable size should be compiled in, to benefit from warnings/errors when compiling the firmware, rather than running out of memory trying to allocate the memory after the firmware is installed.

I'm a novice at C++, unfortunately, even though I can generally manage to cargo-cult my way around! 🙂

[rotund willow]

Adding SD card as sink for such data has been a feature request for a long time

There are many ESP32 boards equipped with SD card slots and ESPHome never used them

[grand bone]

I mean, sure, that’s fine for long term/persistent storage, but that’s quite a different thing to what I am proposing.

[dawn basin]

more organization

[grand bone]

I like the organisation, but it doesn't seem to be happening in my instance:

config file snippet:

binary_sensor:
  - platform: wireguard
    status:
      name: 'WireGuard Status'
      entity_category: diagnostic

text_sensor:
  - platform: template
    name: "Status 1A"
    icon: mdi:eye
    entity_category: diagnostic
    update_interval: 10s

I also noted that in your initial (or early) video, you could click on the header tab or "Debug Log" tab to expand that portion of the screen. It doesn't seem to work for me.

Snippet from /events:

retry: 30000
id: 2365791
event: ping
data: {"title":"growatt","comment":"","ota":true,"log":true,"lang":"en"}

event: state
data: {"id":"binary_sensor-wireguard_status","name":"WireGuard Status","value":true,"state":"ON"}

event: state
data: {"id":"sensor-uptime_sensor","name":"Uptime Sensor","value":2333.512,"state":"2334s","icon":"mdi:timer-outline"}

For some reason, doesn't seem to include the entity_category field in the Wireguard Status entity?

[dawn basin]

not working on my older nodes, which weren't flashed yesterday

[dawn basin]

flashed today and now tabs are working fine

with dark and light mode also

these just visible and animated graphs 😻

[grand bone]

Odd, will try reflash and see. I assumed that the URL was not changing even though the contents were, and would not need to be reflashed to benefit from any updates. Just a refresh in the browser should do it?

talking about light and dark mode, should there not be a cookie or similar to record the preferred display mode? If I refresh, I go back to light mode by default. (This could possibly be affected by a Third Party Cookies setting I have disabled in Chrome, though?)

[dawn basin]

mine are all on dark mode

[dawn basin]

working with 7231n chips too, on device energy graphs 😻

[grand bone]

Nice!

[proper pawn]

Here you are missing the key updates from the updated esphome/web_service component that contains the additional icon / entity_category fields. Would you care to share the full config?
This PR change is now accepted, hope we will see this in 2023.12.6 version 😄

[proper pawn]

Yes, I have modified that. Currently it is ctrl-click, but also a bit tricky and works OK on the sensor side, but only works on the header of the debug log table.
I am not happy with the access, might move it to some other combo that is more fitting e.g. double click .

[grand bone]

Give me a moment. I may need to pull the latest dev version.

[proper pawn]

OK, going to theatre, will check back in the night.
Just make sure you add a sample full config if sg is not working as a pastebin reference.

[grand bone]

ok, will do

My config has a bunch of modbus values in it, which I think I can can safely leave out.

[grand bone]

Yeah, it was just the sync'ing of forks that was the problem. All looks beautiful now!

[dawn basin]

https://github.com/esphome/esphome/pulls?q=is%3Apr+is%3Aclosed not seen here

[proper pawn]

Improved and changed "expand" behaviour to double click.

[proper pawn]

Hey @spark crown could I ask for a little bit of help? I seem to be a bit lost in the PR process.
https://github.com/esphome/esphome-webserver/pull/49 seems to be in blocked status, yet I am unsure if I do have any pending actions on my side.
I have made the requested change.

[fleet cloak]

It looks fine. He's been away for a while on vacation and this isn't the time of year for quick responses. 🙂

[proper pawn]

Ok thanks for the reply, take the time, no hurry.

[wintry wyvern]

@proper pawn thanks for your work. It looks great.
I downloaded your repo to build the js file, but it seems that some files are missing

The following dependencies are imported but could not be resolved:

iconify-icon (imported by C:/Users/Matt/Documents/Git/esphome-webserver/v2/esp-entity-table.ts)
chart.js (imported by C:/Users/Matt/Documents/Git/esphome-webserver/v2/esp-entity-chart.ts)

[proper pawn]

I assume you have already done the npm install step, right? They are both in the package.json .

[wintry wyvern]

ah my bad. I didn`t re install it once loaded your repo

Do you have any plans on adding sorting of the entities? I guess this would get a bit more involved since it can not easily done on the webserver side only

[proper pawn]

They are grouped by entity_category and sorted by name. Anything else?

[wintry wyvern]

By sorting i meant beeing able to set like a z index to each entity to be able to sort them manually

[proper pawn]

ESPHome entitites do not store such information, so would be quite troublesome from esphome perspective.
(web_server component takes the data from the entity components themselves)

[grand bone]

Store order in localstorage, perhaps?

drag and drop to get your preferred sorting, and store the details in the browser's localstorage, I mean.

won't carry to other browsers, but that's about the best you will get.

Especially since sort order is not really a thing that translates well into Home Assistant at large, it is unlikely that a patch implementing it would be accepted into ESPHome.

[wintry wyvern]

One way would be over the Name of the entity.
Right now i could just add 1,2,3 ,4,.. in front of the name and it would display in the order i like but it's ugly.

Why not implement a spezial char sequenz, like "@pos1_name of the entity", "@pos2_name of the entity" and so on.
And then just trim the "@posN_" part for the displayed name?

[grand bone]

Because the name is also sent to Home Assistant or any other API/MQTT clients

[wintry wyvern]

Sure, but if we use HA the sorting of the Webserver entities is not needed.

We would only use the special char sequenz if we use the webserver, so i dont see any conflict.

[grand bone]

Eh, I don't care enough about the topic, I'm not going to comment further.

[inland relic]

Is the PR waiting on a review to be merged? I like your work on the webserver a lot!

if i want to use the latest version, must i add js_url: https://attilafarago.hu/smarthome/esphome_web_server/www.js to the web server?

[inland relic]

How do you split them?

[dawn basin]

I didn't it is already spilt based on type

[inland relic]

Find it, i install it on a other esp32 with more sensors and it works now

[proper pawn]

Thanks for the kind words.
Yes it is waiting for review, no idea why, but I'm a patient dev 😉

[inland relic]

Would it also be possible to add an background picture as a option like this example

Maybe ask a review in the dev channel? ( i think more people can accept the change now)

[dawn basin]

We are already using in its current form

[proper pawn]

This would imply a more complex config in the yaml file, right? How would you envision this?

[dawn basin]

Just like what wled does?

[grand bone]

Care to expand a bit further for those less familiar with wled?

[grand bone]

Literally just a background image?

No live updates to portions of it, etc?

Probably not too complex (from the non-javascript developer), but you would also need to think about things like how it appears on PC vs mobile devices, etc

[fleet cloak]

I think if you want precise positioning of values like that, you will need to make your own web interface.

[grand bone]

Not sure if that is actually a requirement. Given the wled example, perhaps just a pretty/distinguishing background is enough.

[fleet cloak]

If the values aren't included, then the background picture doesn't really make sense.

[grand bone]

certainly not the one shown, no

[proper pawn]

The whole web_server component architecture comes down to three pillars

• user config yaml file with all the sensor and binary_sensor etc components that have their own predefined and hard-to-influence data structures. These are iterated, listed and change-watched in the web_server component (esphome core project)
• user config yaml file with the web_server: component, that might include any further config keys (esphome core project)
• web_server lit frontend (html/js/css) (esphome-webserver project) that is hosted either on esphome.io by default or anywhere else if you configure your own - this is loaded into your browser does literally know ~nothing about the ESP, has a narrow info interface through the eventstream

aspect to consider: where is the "thing" we want to add resides in configuration, memory, get connunicated, and runs and gets hosted (if applicable).

Key challenge is that many changes influence both esphome core and esphome-webserver project.
Also components cannot and maybe should not be extended for the sake of the web_server (unless we start a very cumbersome decorator pattern).

In the above example of background image it seems pretty doable:

• configuration would go to the web_server component
• would need to get communicated to the web_server Lit app though the ESP eventstream
• where would it be hosted? perhaps a local network resource? like http://192.168.0.22:8128/local/my-fancy-background.jpg

This implies two PR changes: one in esphome/esphome and one in esphome/esphome-webserver project.

I have a similar struggle with icons.
Icons are part of the sensor configuration and are optional.
If I set them it is possible to convey the config to the frontend web_app via the eventstream and show on the web_server interface.

However this implies that they will be fixed -- that is problematic in case of a binary motion sensor.

1. If an esphome a binary motion sensor has no icon configured, HA assigns one and also changes based on the state (detected/not detected) - yet web_server will not be able to show any icons.
2. If an esphome a binary motion sensor has an icon configured, HA takes that as fixed and displays it no matter what the state is - yet web_server will show at least that fixed icon.

It would be possible to "decorate" sensors, like so

binary_sensor:
  - id: first
    # icon: mdi:motion-sensor # no icon so that HA will assign it automatically

web_server:
  custom_entity_decorations:
    - entity_id: first
      icon: mdi:motion-sensor

But that would be quite hard to follow and unpleasant...

[rotund willow]

you should draw an endline...
in the end you'll end up re-developing HA functionalities - completely useless imho.
just fancy good lookin' things which apart from design, have little real functionality.
a waste of resources.
for such things, there's a dedicated tool, it's called Home Assistant or whatever other home automation tool you'd like.

[fleet cloak]

There have been requests to allow the icon to change at runtime. That would be useful for both HA and the web server.

[drifting yarrow]

I agree about drawing a line. give web_server a project scope and stick to it. is it a end user daily use tool, or an initial config/test/diag tool?

for the latter, it's great as it is, in fact it's wonderful. the only improvement I personally would like is branding, like either replacing the top logo or adding a branded one with it. I know this can be done by hosting my own copy of the files, but then I'd have to keep patching it.

[dawn basin]

can we have icons for the binary sensors? e.g window/light/power icons?

[proper pawn]

What is the practical use to draw a clear end line for this project?
I completely agree that re-developing HA functionalities makes little sense, yet esphome is a great open source project that gets features on demand and popularity based on the community.

At the moment there is no energy / community to expand the web-server further, yet I think many of us would see more functionality as long as it does not have drawbacks (performance / flash / RAM) and someone invests the time to develop them.
I personally love to think on esphome as potential part of the HA ecosystem that is fully functional and capable on its own as a low-code Arduino alternative.

We still have the above improvements pending as far as I see anyhow.

[dawn basin]

open-source means PRs are allowed 😉

[wintry wyvern]

@proper pawn on mobile devices the time component of the log gets cut after the hour value. Displaying the minutes or even the seconds too would be nice

[wintry wyvern]

what could we do to push this PR? I guess @spark crown is responsible for the review?

[proper pawn]

No idea, this is my first PR for esphome repos yet.

[dawn basin]

love the comments section

just below the title

[grand bone]

This is a bit odd, not sure if I need to flash a new version or not? Firstly, the upper value of the range of the number is not to the right of the slider, it ends up below it? And the actual value that the number is set to is not displayed anywhere, not even if I hover over the slider handle.

[wintry wyvern]

I cant remember the value being displayed anywhere ever

[wintry wyvern]

@proper pawn maybe it would be a good idea to allow the user to decide if he wants to use v2 or your v2+
Because it seems your version takes up a lot more space on PROGMEM when the js is included and not loaded from the internet than v2

With your PR v2 is simply replaced with your v2+. Maybe it would be better to add a config to let the user choose if he wants v2 or v2+

[proper pawn]

Jesse had a decision to fully replace V2 as far as I cane member.

Actually the PR is getting 2 moths old now. I am not sure how esphome-webserver review process is or what is the decision process to progress.

There could be a list of things to adds, bur that list go on and on unfortunately...

[wintry wyvern]

sure, but i still think it would be better to let the user choose between v2 and v2+.
Maybe you should do that and prepare a PR for that, so it can not brake anything and so it would be likelier to get merged.

[fleet cloak]

It could even be v3. That makes it an easy change.

[proper pawn]

I understand all the ideas and with many I can agree, with some I can accept, even would implement some of them for the sake of the community receiving a next step in the web_server. Yet for each decision there needs to be a codeowner who considers and completes that decision.

It could be an option that Jesse creates a forum to collect input and discuss future of webserver and ultimately decides on what to accomplish.
I am happy to actively accompany this awesome project on that route, yet - sorry to say- just changing the PR indefinitely without a clear end-goal is Balaam's donkey that just is a waste of effort .

I think we would need a next step from @spark crown on the future of this project.

[fleet cloak]

My vote is V3. @torn relic ?

[torn relic]

oh, I have a lot of catching up to do...

what are we trying to decide exactly?

[fleet cloak]

Should this new web client option replace V2 or be added as V3.

It's much nicer, but it's also somewhat larger.

[supple heart]

I think its past V2 now and should be V3 with ofc option to choose

[torn relic]

I don't use the web server...I might not be the best person to ask 😅
that said, I think the ability to choose what's in use would be good -- no webserver, a "lite" webserver and a "full" webserver, for example

if we are distinguishing what features/functionality will be available to the user, "v1", "v2" and "v3" probably isn't the best nomenclature...

[supple heart]

i think we are just going along with what its called now

[torn relic]

that's fair. 🙂

[supple heart]

the current default one is V2

[torn relic]

yeah, as I'm catching up, I'm leaning towards a "v3", too

maybe once it's merged & available, we can look at rebranding them so the differences are more clear

[grand bone]

According to my tests the new webserver consumes same RAM, and 1k additional flash.

Is it really worth it for 1k flash?

That comment was in the original post, fwiw, not my observation

[torn relic]

if it's really just 1K, that's not bad, unless maybe you are unforunate enough to have an ESP with < 1 MB of flash, haha

[fleet cloak]

Is the web server being changed as well? I thought it was just the client.

[grand bone]

the bulk of it is externally hosted anyway, isn't it? Unless you choose to build it in because your browser has no internet connection, or you don't trust external resources.

There have been changes to the C++ code, mainly to support a fallback javascript if the external resource can't be loaded. This take the majority of the 1k mentioned above.

and a few other tweaks, it seems

[spark crown]

There have been a few supporting changes merged on the device side. But it's mostly just the frontend.

I'm fine with it being a v3. Sorry it hasn't gone anywhere officially yet, i have been overseas for the past 2 months working on and off.
As for reviewing the actual webserver frontend, I have almost no idea about frontend code 😅

If we change the webserver code to become a v3 subfolder of the repo, then it's a lot easier to merge and allow people to use without altering the V2 experience

[wintry wyvern]

Thats what i was thinking.
I would also like to see @proper pawn marked as codeowner for v3 so he could add features more quickly

[inland relic]

I want to compliment you for all the nice work and really love the enhancement to the web server.

[proper pawn]

I am all OK with any additional requests from the codeowner as long as there is clear decision. It might worth a broader discussion if there is a longer debate needed or just a simple decision.
As a next step I would ask @spark crown - would you please help me and add any further list of requested changes to the PR directly that allows the PR to be merged & closed.

If I see a full list of further requests, I can do it in one go. I would like to avoid us having much delay, and reiteration before the merge.
Is this OK this way?

[dawn basin]

V3 it should, let people choose between v1, v2 and V3.

[spark crown]

Will do, just have not had time yet to spend on reviewing the actual code.
I probably wont have real time until after the February release next week

[dawn basin]

can't it be included in feb release?

we are really inpatient 🫣

[torn relic]

it might be a bit tight to get into this coming release. Jesse is going to be away for a few days and I'm probably lacking sufficient background to approve 😇

[dawn basin]

or we can coincide it with 2024.3 release and call this V3

90% of nodes are running this webserver now

[grand bone]

90% of which nodes?

[spark crown]

76% of all statistics are made up 😉

[grand bone]

yes, exactly

Was wondering how he could see which nodes are not referring to the JS on his web server.

[wintry wyvern]

Simply revert to the original V2 files. Put yours in a V3 folder and modify vite to build both separately.
I already opend a PR to modify the web_server component to support V3 and load the right js file
https://github.com/esphome/esphome/pull/6203

[dawn basin]

Oh I see now, I missed the the word "my"

my 90% nodes are on v3, obviously, I don't know esphome stats

[dawn basin]

@proper pawn included in beta

[proper pawn]

Happy about the enabling PR is making it to esphome.
Yes this is though, as webserver Lit-HTML is definitely not part of the esphome core ecosystem, still many of us love it and use it, so should be a quite conscious decision which direction to go.

Honestly I had some time to think, also looking at some projects and alternatives and definitely there is a lot of improvement potential.
Today this thread shows that while there is a zillion of ideas and requests, it will be tough to agree.

Still from visual perspective many improvements might do it to the codebase and thus will evolve/change significanty what we know and love as webserver V2.

Thus my suggestion to would be to accept the request and go for a new version, that for the time will not be default, but could be a non-default version: 2plus or version: 3.
Here more exploration and brave changes could be done as a bleeding edge.

Alternative cost: Ultimately this version would still be hosted remotely, and would even make less sense to include/build statically. As long as a user is OK with that I think this is OK. (33k->200k due to graph component)
We might add a minimal built-in fallback version to prep for no-internet situation.
Could worth researching later if there is a smaller graph library for Lit - probably there is.

Some interesting links:

• https://community.home-assistant.io/t/announcing-esphome-web-app-control-esphome-microcontrollers-without-home-assistant-esphome/686878
• https://community.home-assistant.io/t/esphome-web-server-dashboard/599717/7

[dawn basin]

this one looks nice

[proper pawn]

Nice, but giving so much space for one entity is not a good option for me.
For an energy meter (Slimmelezer+) unit I have 20ish entities.

[dawn basin]

No, your will remain same, this is as second options.. This one works without additional code, you can use both at the same.

[proper pawn]

Yes, I know, sorry if my reply was confusing. I more like reflected to the visual concept.

[hazy lion]

the current values of sliders is not reported. (only the values corresponding to slider endpoints are displayed)

[grand bone]

Yeah, I reported this as well. Also the upper value is often wrapped to below the slider

[grand bone]

Here. Didn't really get any attention.

I see in your case, the lower value forces the slider onto the next line too.

[hazy lion]

'giving' the wrong impression that it is current value

[grand bone]

yeah

[proper pawn]

You are right, for the slider the current value is to be added.
I wonder what is the real value of 56.79999924 as a max value of the slider. Also do not see how this could be shown in a friendly way.
Frontend dows not parse the values, and it has no right-knowledge what is the adequate precision.
So I would say, that we leave X% space there and assume that a few digits fit there.

I would not want to fit all 3 values there (too much space), still thinking of a good solution.
Any hints?

I just paused making changes until we see a review and decision on where / how to move on with the refresh of the web_server frontend. Currently it is pending on esphome.

[grand bone]

Worst case, show the current value above the slider when hovering or starting to move the slider, like HA does.
Better (imo) is to show the value under the slider all the time.
But surely the precision is reported, if only at the beginning when the entities are enumerated? How does HA know, otherwise?

[fleet cloak]

HA uses the esphome api. This is the REST api. There's not as much information available.

[grand bone]

Ah, I see. That's unfortunate.

[fleet cloak]

I wonder if the value is sent as a number or as text.

If it's text, then it should be rounded properly before being sent.

[grand bone]

look slike it should be:

std::string WebServer::sensor_json(sensor::Sensor *obj, float value, JsonDetail start_config) {
  return json::build_json([obj, value, start_config](JsonObject root) {
    std::string state;
    if (std::isnan(value)) {
      state = "NA";
    } else {
      state = value_accuracy_to_string(value, obj->get_accuracy_decimals());
      if (!obj->get_unit_of_measurement().empty())
        state += " " + obj->get_unit_of_measurement();
    }
    set_json_icon_state_value(root, obj, "sensor-" + obj->get_object_id(), state, value, start_config);
    if (start_config == DETAIL_ALL) {
      if (!obj->get_unit_of_measurement().empty())
        root["uom"] = obj->get_unit_of_measurement();
    }
  });
}

std::string value_accuracy_to_string(float value, int8_t accuracy_decimals) {
  if (accuracy_decimals < 0) {
    auto multiplier = powf(10.0f, accuracy_decimals);
    value = roundf(value * multiplier) / multiplier;
    accuracy_decimals = 0;
  }
  char tmp[32];  // should be enough, but we should maybe improve this at some point.
  snprintf(tmp, sizeof(tmp), "%.*f", accuracy_decimals, value);
  return std::string(tmp);
}

Seems like there needs to be a truncation to that number of decimals after the separator?

I suspect I don't understand the format string specifier, though.

Seems like maybe the browser is converting the string back to a floating point representation, and losing the "accuracy" conveyed. Perhaps leaving it as a string would be a better approach?

[fleet cloak]

yes, that looks like where the problem is.

[grand bone]

So, fixable inside this component, at any rate 🙂

[fleet cloak]

I expect so.

[hazy lion]

- platform: template
    name: "${name} Bulk voltage"
    id: "bulk_voltage"
    step: 0.1
    min_value: 54
    max_value: 56.8
    mode: slider
    initial_value: "${bulk_v}"
    unit_of_measurement: V
    icon: mdi:battery-charging
    optimistic: true
  - platform: template
    name: "${name} Float voltage"
    id: "float_voltage"
    step: 0.1
    min_value: 52.8
    max_value: 54
    mode: slider
    initial_value: "${float_v}"
    unit_of_measurement: V
    icon: mdi:battery-charging
    optimistic: true

This is the corresponding code for the sliders.

I would not want to fit all 3 values there (too much space), still thinking of a good solution.
Any hints?
Showing current values and the endpoint values is bare minimum functionality. This is the only thing preventing me from using this js for my Solar battery node.

I just paused making changes until we see a review and decision on where / how to move on with the refresh of the web_server frontend. Currently it is pending on esphome.

[grand bone]

I think more important than the lower and upper values is the current actual value, in my opinion

[hazy lion]

Exactly, even if you don't show the endpoint values and only the current value, it is fine for me.

Just fixing the above would be sufficient for me to switch from V2.

[wintry wyvern]

If you change your PR to revert the V2 files and make your version V3 merging would be easier like jesserrockz sad.
So I guess they are waiting for you to make those changes

[proper pawn]

I will get back to this project after the February release is out as mentioned above.

In the meantime if someone has time to rework the complete build process it would be nice.

@wintry wyvern would you want to make the split on a branch?
At the moment v2 build is performed in a single vite step that does not seem to be flexible enough for any additional build artifacts.

I have started this work back in December, but had no time to finish (more details on this branch).
https://github.com/afarago/esphome-webserver/tree/build-restructure-with-fallback

[mortal river]

I mostly do web stuff and am interested in helping. While I don't understand the current problem or goal just yet, I'll have a look and see if I can help out.

[mortal river]

Circled back this evening, read through the thread and associated code a bit, and have a better understanding of the scenario. I agree with the sentiment that v2 should likely remain as it was and v3 should probably be a modified copy. While a v3 fork of sorts means that fixes to v2 may also need to be made to v3, that isn't as bad as never being able to update v2 again.

[mortal river]

Although I'm learning vite on the fly, it is all familiar concepts and one in particular we should leverage: chunking. The memory concerns and considerations are fair points for the device targets and chart.js is an excellent example of a bundle chunk that should be broken out. That way, this large dependency will only be loaded if/when necessary.

[grand bone]

Is that something that would have a separate config setting in the YAML? i.e. allow the main JS to be compiled into the firmware with the associated storage costs, so that people can benefit from the new look/feel, but still load the graph.js stuff externally or even skip it totally if it is not something that is needed.

[mortal river]

As I'm new to web_server as well, do I understand correctly that embedding via local, js_include, and/or css_include requires you to provide your own copy of those assets or does it implicitly use the remotely hosted assets normaly in use?

The default remotely loaded assets can benefit from chunking with minimal changes, but offline copies may require different bundles to be made and explicitly included (e.g. minimal vs everything)

[grand bone]

as I understand it, the JS is normally loaded from an internet-accessible webserver. There is an option (local: true) to compile the JS and other resources (downloaded from the internet URL, or whatever URL/file you tell it to use) into the firmware image that is written to the device, for the cases where internet access is undesirable (e..g closed network, self-contained, bitrot-prevention, etc).

[mortal river]

Aha so local: true supports essentially downloading/embedding js_url or js_include can be a URL as opposed to a local file? Suppose that either way, there will need to be separate bundles created since no internet means inability to dynamically load chunks, so, additional chunks would need to be embedded or not by choice.

[grand bone]

yes, I believe so. Haven't tested it, but the docs appear to say that. I imagine for v3, we could do something like local_graph: false which defaults to the same value as local: if not specified.

[mortal river]

This generally needs a bit more thought for sure. To start, we should probably go all in, but I'm keen on these sorts of optimizations and options absolutely.

[supple heart]

web_server:
  port: 80
  js_url: http://homeassistant.local:8123/local/www.js

is the way i load it locally from the HA "www" folder

[mortal river]

Ah yah, but that requires the devices to at minimum connected to wifi and for HA to be accessible. I think Rogan is talking about the offline access options local, js_include, and css_include

[supple heart]

ahh right i didnt read up enough 😉

[grand bone]

so I think that if you add local: true to that, whatever is there will be downloaded and built into the image, so that e.g. it is usable when the device is in AP mode, for example

although a lot of mobile devices will use GSM for internet access, even when WiFi is attached to a closed network. Doesn't help when your js_url points to something that is not internet-accessible!

etc

[mortal river]

it is an interesting prospect and definitely see why keeping the size down is important when you're already pressed for space

or even if you're not since you could be pressed for it in the future heh

[mortal river]

https://github.com/afarago/esphome-webserver/pull/4

• Pull request to the WIP branch by @proper pawn for consideration and eventual merge to https://github.com/esphome/esphome-webserver/pull/49
• Deployable builds for v1, v2, and new v3 should work like expected (plus vfallback option potentially related to https://github.com/esphome/esphome/pull/5853)
• v2 was restored to the original and the previous working state was duplicated over to v3 (e.g. https://oi.esphome.io/v3 once merged and deployed)
• Related to https://github.com/esphome/esphome/pull/6203

[wintry wyvern]

Awesome, I will try it out tonight

[mortal river]

Not certain if it just me, but when you interact with switches and such, it seems to be very latent. Are updates queued and flushed periodically or something?

[dawn basin]

since it is merged, how to add it now https://esphome.io/components/web_server?

currently I use this method ```web_server:
port: 80
ota: false
js_url: https://attilafarago.hu/smarthome/esphome_web_server/www.js

got it... it is awaiting merge

[mortal river]

I’m not certain what is hosted there currently, but I’m guessing the stuff I did likely isn’t too much different. What I was doing is mostly getting things to a place where it could be merged while leaving v2 as it was and making the new goodies available at an ESPHome hosted v3 endpoint. This is still pending in a couple ways, but you could host the latest locally on your machine/network

[wintry wyvern]

https://github.com/esphome/esphome/pull/6203

V2 is
https://oi.esphome.io/v2/www.js
So naturaly i assumed v3 will be
https://oi.esphome.io/v3/www.js

[mortal river]

Should be yup yup. Based on local testing, _static/v3/www.js and the other goodies are created

Next steps are for @proper pawn to consider accepting my pull request (https://github.com/afarago/esphome-webserver/pull/4) to his WIP branch and then he'd merge that in to his ha-styling branch (https://github.com/esphome/esphome-webserver/pull/49), then once that is accepted by the fine ESPHome folks, in theory the next build should generate and deploy v3 with v2 being just like it was before.

The v3 approach also has the benefit that we can do a little beta testing before updating the other documentation which recommends the v2 assets and then it is more of an opt-in from that point forward as opposed to forcing everyone over. Might also be good to buy some time to continue to iterate and improve (e.g. exploring chunking more) and then basically only peoples on this thread know about the new version.

[proper pawn]

The reason I have done but stopped at a point with the split and multi vite build is that I am not confident about that tool and build env. So my branch seems to be working but even I am not 100% sure.

Me reviewing and accepting your pull request is not adding too much value.

If you have more insights, it would be best that you directly submit a v1-v2-v3 split to the origin. Once it is there I can take over V3 if Jesse supports that.

An initial spotting - I was experimenting with this split with the fallback version in mind. It is not discussed/agreed, this should not be part of any PR posted to the origin repo.

What do you think? Does that sound cool to you?

[mortal river]

From what I could gather, there were a couple issues that prevented your branch from working appropriately. More specifically these paths: https://github.com/afarago/esphome-webserver/pull/4/commits/a25fd1cfa16c7dc5f0e22419d01096eb173c55b0#diff-09d021e5a5d4bcf75d0f5a6ac7d5e675b7a871e3c2cd2544d11d799ef1970866

Prior to making modifications based on your branch, I did attempt an alternate approach or two and the summary is that Vite is making it challenging to have/build more than one "app". v1 + v2 works because v1 is just copying files while v2 is the actual app, so, adding v3 is essentially another app that creates the challenge. I didn't look too much at the fallback and that seems fine to remove and potentially consider at a later time, but this approach did afford the ability to create more than one version build/app thingie.

So, I could try to spend more time trying again, but breaking things up where each verson is essentially its own vite app did seem like a reasonable approach. Bit of Vite issues, posts, and otherwise that indicate much the same issue with varying levels of hacks and things that I couldn't get working in totality. For example, two other approaches would dump index.html in _static/v2/v2/index.html while another approach would dump public assets in _static instead of _static/v2.

Ah, are you saying that you think your work to split the versions up in to packages should potentially be pull requested to the esphome repo separately and then you'll bring v3 in to the new arrangement? I sleepie now, will check back tomorrow morning.

[wintry wyvern]

I havent hat time to look at it yeaterday, but from what i can see on my phone its exacly what we need.
Beeing able to build and run a test server on each version 👍

We would also need some changes to the
Docs to let people know that there is this great v3.

[mortal river]

Yes indeedie. Also guessing there is some default set somewhere (e.g. prepare for first use and then viewing the device from ESPHome web). Maybe that was covered by your pull request?

[wintry wyvern]

Detault is still set to v2 in my PR

[mortal river]

Roger roger. Probably would be best to make it opt-in for some period.

[mortal river]

Pull request for just the workspaces/packages changes needed to facilitate building v1, v2, v3, and beyond.
https://github.com/esphome/esphome-webserver/pull/53

[wintry wyvern]

the problem seems to be on the js side.
this will fix it

  private _range(
    entity: entityConfig,
    action: string,
    opt: string,
    value: string,
    min: number | undefined,
    max: number | undefined,
    step: number | undefined
  ) {
    let valueString = step.toString();
    let numDecimalPlaces = 0  
    if (valueString.indexOf('.') !== -1) {
        numDecimalPlaces = valueString.split('.')[1].length;
    }
    console.log(numDecimalPlaces)
    return html`<div class="range">
      <label>${min || 0}</label>
      <input
        type="${entity.mode == 1 ? "number" : "range"}"
        name="${entity.unique_id}"
        id="${entity.unique_id}"
        step="${step || 1}"
        min="${min || Math.min(0, Number(value))}"
        max="${max || Math.max(10, Number(value))}"
        .value="${(Number(value).toFixed(numDecimalPlaces))}"
        @change="${(e: Event) => {
          const val = (<HTMLTextAreaElement>e.target)?.value;
          this.actioner?.restAction(entity, `${action}?${opt}=${val}`);
        }}"
      />
      <label>${max || 100}</label>
    </div>`;
  }

[wintry wyvern]

if you click fast on the controls the tab will expand.
I am not a web guy, but there should be a way to detect where you click and if it is a control item clicking them should not count as double clicking to expand the tab

[spark crown]

What do you mean the tab will expand?

[wintry wyvern]

double clicking on the sensor/control side will colaps the debug log and the sensor/control side will tke up the whole screen

double clicking the debug log will do the same but reverse

if i want to change some values with the arrow buttons and click to fast it will trigger this feature

[spark crown]

Oh, this is a feature of the v3?

I have not actually tried it yet

haha

[wintry wyvern]

yep 🙂

[mortal river]

If you'd like to give it a whirl:

web_server:
  port: 80
  js_url: https://deploy-preview-49--esphome-webserver.netlify.app/v2/www.js

Some areas also expand on single click it seems

[mortal river]

Had a look, summary is that double click expansion handling on all the things is in part due to web component encapsulation. I've demonstrated it is possible to restrict to the tab-header, but I'm trying to decide how to best go about suggesting changes to v3.

Ideally we'd merge packages/workspaces, rebase v3 on top of that, and then continue making improvements such as this. Is there an owner of esphome-webserver that might be able to help us make progress? If not, I'd be interested in helping as a maintainer.

[wintry wyvern]

I gave it a go, but it seems to to the same thing?

[mortal river]

Yes, that is the deployed endpoint from afarago’s pull request. I’d need to open a new pull request that duplicates his so that I can make changes

[wintry wyvern]

I totaly agree. We need someone responsible for esphome-webserver or we will never be able to get any chnages out

[mortal river]

(I can’t push to his personal repo)

[wintry wyvern]

I see, i thought this would be a build of your fork

[mortal river]

Nah just a way for Jesse or anyone else to easily test the current code

[wintry wyvern]

I tried out your version-packages and it seems to do what it is supposed to do.
beeing able to build v1 and v2 separately.
v3 is not in there on purpose i guess?

[wintry wyvern]

@spark crown it's seems that we would really need someone responsible for the esphome-webserver repo.
By looking at the history of the repo it looks like there is nobody besides you responsible for it and it seems you are already quite involved with the main repo. Would it be possible to grand @mortal river some permissions on the esphome-webserver repo so we could get somewhere with this?

[dawn basin]

@torn relic might be able to do this

[spark crown]

Merged

[mortal river]

:yayfrog: thanks so much!

I'll work on a fork / rebase of the actual work based on main

[spark crown]

👍

[mortal river]

QQ: CI/CD at play and I can now verify that I indeed did not break things for everyone loading those remote resources? These endpoints look good currently:

• https://oi.esphome.io/v2/index.html
• https://oi.esphome.io/v2/www.js
• https://oi.esphome.io/v1/webserver-v1.js
• https://oi.esphome.io/v1/webserver-v1.css

Small panic that the readme documented links (https://github.com/esphome/esphome-webserver?tab=readme-ov-file#build) maybe changed at some point https://esphome.io/_static/v2 / https://esphome.io/_static/v2/www.js

[spark crown]

Ah yep, we dont host the files on the docs site anymore

[mortal river]

Roger, I'll fix in the other pull request

[mortal river]

https://github.com/esphome/esphome-webserver/pull/54

web_server:
  port: 80
  js_url: https://deploy-preview-54--esphome-webserver.netlify.app/v3/www.js

npm run build from the root appears to create all 3 versions successfully, have a couple questions in the pull request for @proper pawn but otherwise looks like we're pretty close to being able to land this sweetness

Would be great if those on this thread familiar with the expectations of this change set could verify that all is well while using the above config that is representative of what would be deployed.

@wintry wyvern at what point do we require your pull request? https://github.com/esphome/esphome/pull/6203 (EDIT: ah, after #54)
Also seems like this is likely ready for liftoff to address a number of reported issues -- https://github.com/esphome/esphome-webserver/pull/50

[spark crown]

Conflict on #50

[mortal river]

Doh, right, conflict created by the workspaces moving things around. @wintry wyvern want to re-do that change based on the current main branch (instead of the root v2/esp-entity-table.ts file it is packages/v2/src/esp-entity-table.ts) or I can just include it as part of #54, just didn't want to steal your fix

[spark crown]

Managed to merge main into the branch locally and push, dont know why github wouldnt do it automatically as I didnt even have to manually choose fixes

[mortal river]

Lovely stuff! Yeah, an easier solve given access ability heh. #54 was a fun one to resolve conflicts on.

[mortal river]

@proper pawn if you might be able to have a look at the questions in https://github.com/esphome/esphome-webserver/pull/54 -- no worries if not. I'll probably undo those changes and do some testing in the next day or two so that we can proceed.

[dawn basin]

now we have use this ```web_server:
port: 80
js_url: https://deploy-preview-54--esphome-webserver.netlify.app/v3/www.js
version: 3

ended up with ``` Unknown value '3', valid options are '1', '2'.
version: 3

[wintry wyvern]

The Main pr for v3 on esphome-webserver didn't get merged yet.
Also the pr on esphome-esphome which will make version: 3 a valide option, same thing.

[mortal river]

Oops. In other words, the PR deployed endpoint should work if you omit version or make it 2. Maybe.

Guessing that normally just dictates which production hosted endpoint to use when not specifying js_url

[hazy lion]

I don't use version and it works for me

[spark crown]

The difference between 2 and 3 in the version field just sets the js_url AFAICT so it doesnt matter for now since you are specifying it yourself

[proper pawn]

@proper pawn I can look into it during the weekend. Thanks for all your progress and effort!

[mortal river]

Sweeeet, no problem and thank you for all the other important bits.

Makes sense on the version vs js_url -- I'll edit/update references appropriately.

@hazy lion @dawn basin just to make sure since you are likely familiar with the baseline expectations: all seems to look and work like you know and love?

[wintry wyvern]

@mortal river how hard would it be to update the page without reloading it after changing some components to internal = true and vice versa, so they are either displayed or not?

I would like to create a UI that displays inputs based on the seleced index on a select

[fleet cloak]

That requires a reboot of the device, so the web browser will get disconnected. When reconnected, it could get the updated content and update the display. I don't understand how that relates the second part though.

[wintry wyvern]

i dont think a reboot is needed after id(test_text).set_internal(true);
A simple reload of the page will fetch the new data and not display the test_text.
But i guess what i has hoping to do is not easily done since the components a instantiated once on event: state and there is no way to detect if a component got set to internal = true

[fleet cloak]

oh, you're hacking... 😛

[mortal river]

I'll have a looksee. We've also got the double click improvement pending and seeing about potentially leveraging dynamic imports to reduce memory overhead.

just guessing, but presumably the internal property is passed along and can be used as a render exemption

Unrelated, have contemplated adjusting the periodically pulsing heart to a simple green/red dot for node status (EDIT: or assume it is always online and only show "OFFLINE" or something when it isn't reachable)

Speaking of dynamic imports and potentially personal preference: should be a way for us to make the base goodies extensible

[hazy lion]

I tried compiling the latest js today and The Current valuie for sliders is still not shown.
I think the commits regarding changes have been left behind.

[mortal river]

Sorry about that, surely lost as part of conflict resolution when rebasing. Will try to find and restore those bits indeed.

[mortal river]

Possibly restored now with the only thing I was able to determine was potentially missing: https://github.com/esphome/esphome-webserver/pull/54/commits/c8803c1b8e0e21ca9b8cc74a9f84f7909eb603f5

Fixed a potentially broken CSS selector due to a missing closing } in the declaration above html * that looks like it could have a visual effect that may potentially restore transitions to all the things: https://github.com/esphome/esphome-webserver/pull/54/commits/2060c36eba39dac382fd3ab5f4154cf57752d560#diff-28a1bb373f2f8df807bfee1bd78d3a2a3c2352a49a5d95503003bfcc5dc3e4d6R80
Also possible that CSS engines still interpreted this correctly and that there will be no observable change, but this was uncorrect in v2 as well.

[proper pawn]

@mortal river - Thank you for your work, code seems to be OK, also seems to be working OK for all my devices.

[mortal river]

No problem at all and lovely stuff.

[grand bone]

Was the fan entity considered/included when developing this PR? Have a kids project to build with multiple hbridge fans, and the direction property doesn’t seem to be exposed on either classic web server or this pr

[mortal river]

@proper pawn removed potentially unused home.svg file but left the v2 version intact in case there are external use cases expecting that hosted file to be there. There was still this specific question regarding the removal of the gzip plugin: https://github.com/esphome/esphome-webserver/pull/54/files?w=1#r1514121741

[spark crown]

This is merged and available at https://oi.esphome.io/v3/www.js now

[spark crown]

I uncommented that, it adds www.js.gz, but not www.js.br

web_server v3 -- home assistant styling

[mortal river]

Yayay! It is strange that the br files went missing and while commenting out gzipping didn't make sense as an explanation, was only seemingly pertinent thing. I'll have a looksee.

Now I see. The plugin above what was previously commented out was creating br and that extension got changed to gz

[spark crown]

Well its easier to review/merge smaller PRs now 🙂

date has also been added to esphome including sending the state and requests for web_server

I am working on time entities too atm

[mortal river]

Nice nice nice. We'll see in a moment via preview if this is the .br solve https://github.com/esphome/esphome-webserver/pull/55

[spark crown]

That works, it downloads in my browser

[mortal river]

yup same

For those following along at home: you should probably change over to the official endpoint so that you can receive additional fixes and improvements.

web_server:
  port: 80
  js_url: https://oi.esphome.io/v3/www.js

Small issue dashboard to track fixes and feature requests: https://github.com/esphome/esphome-webserver/issues/56

[mortal river]

This fix is still pending, correct? Any others you can think of?

[grand bone]

Any chance of fan support now that this is merged? i.e. direction, speed, on/off?

congratulations, by the way, and thanks for pushing it through!

🎆

[mortal river]

I've added it to the to list. Possible to provide me with an example config that produces the missing bits?

[grand bone]

output:
  - platform: ledc
    id: globe_motor_forward_pin
    pin: GPIO12
  - platform: ledc
    id: globe_motor_reverse_pin
    pin: GPIO13

fan:
  - platform: hbridge
    id: globe_motor
    name: "Globe Motor"
    pin_a: globe_motor_forward_pin
    pin_b: globe_motor_reverse_pin
    # enable_pin: motor_enable
    decay_mode: slow   # slow decay mode (coasting) or fast decay (braking).

This fan should be capable of speeds at 1% resolution, allegedly, as well as forward and reverse.

in practice, the motor only starts spinning at around 20%, but that's more an implementation detail.

There is also an option to specify the number of steps available:

speed_count (Optional, int): Set the number of supported discrete speed levels. The value is used to calculate the percentages for each speed. E.g. 2 means that you have 50% and 100% while 100 will allow 1% increments in the output. Defaults to 100.

as well as a number of presets:

preset_modes (Optional): A list of preset modes for this fan. Preset modes can be used in automations (i.e. on_preset_set).

Docs from here: https://esphome.io/components/fan/hbridge.html

[mortal river]

Addressed by https://github.com/esphome/esphome-webserver/pull/57 with a couple other small associated improvements

@grand bone roger roger, will have a looksee. Brought over the seemingly related fix previously provided by rfdarter.

[wintry wyvern]

nice

[wintry wyvern]

we would definitly need the slider to show the current value somehow. otherwise the slide is useless

So what is needed to get #6203 merged?

[mortal river]

The lack of a slider value should be visible when I work on the fan issue? Guessing maybe just any slider such as a number template might also show this issue?

Jesse is aware of and did make moves on https://github.com/esphome/esphome/pull/6203 -- what appears to be needed is documentation which I assume means, at minimum, updating https://esphome.io/components/web_server.html

[spark crown]

correct

[mortal river]

I can take care of that if you like. Curious if we're feeling good about v3 as is to release it to the wild or if we should give folks on this thread some time to play with it? Suppose there has been a bit of time via previous pull requests and we can always keep making remote improvements since it doesn't ship in stone (unless embedded/offline)

Right, we've still got time and would target the docs update to the next version since documentation availability is dependent on an ESPHome release

[wintry wyvern]

feel free to take care of the docs

just tested with

web_server:
  port: 80
  js_url: https://oi.esphome.io/v3/www.js```

slider is not showing the current value

ha is showing a overlay on hover with the current value. Would loo nice, but how would we handle mobile devides?

[mortal river]

This is the same issue that shvm pointed out here? #1177062706340171807 message

[wintry wyvern]

yep

[mortal river]

Interesting. I pasted in every file from the pull request, perhaps it was in the other branch afarago was working on. Do you by chance have any other reference message, screen shot, or change set that shows how it was working?

[wintry wyvern]

I dont think the current value was ever shown in ha-styling

[mortal river]

Oh, that perhaps explains it then, though shvm indicated that maybe it was a change that was left behind. I'll add that to the list and work on it.

[spark crown]

I know this seems like something very minor, but to get 3 into the esphome release today, I need to put it into a beta which needs the docs to be updated as well...
I will be making the next beta in about an hour or so, then the final release a couple of hours after that...

[mild pond]

@proper pawn I recall some discussion about an RGB color picker, and seeing some mockups/trials. Looks like that didn't make it into the release. Is that still being planned?

[mild pond]

nevermind, found https://github.com/esphome/esphome-webserver/blob/bb1368203fed0448d1ceaee18b7b9ad4d8a2eb4f/packages/v3/src/esp-entity-table.ts#L455 which shows only RGB and RGBW are currently supported, not RGBWW or RGBCT. We'll probably have to set up a double-picker for those

[dawn basin]

OTA updates added to v3?

[rough bough]

Hi ! I've just tested webserver V3 and it's nice ! But, do you think it could be possible to add code to re-order components ? for example by giving a weight to each components in yaml or to give an order list with ids in webserver components ?

I've seen that @wintry wyvern is renaming entities with 1., 2., ... but, perhaps we could have a better solution...

[wintry wyvern]

I was thinking about how to do that for some time now.

The neatest solution would be adding a Index variable to the entity base.
But that is not fesable to add that overhead just for the web_server.

My next idea was to "transmit" the Index in the name like name: "[z=1]My Number" and [z=1] would be cut out on the webserver part.
Also not a good solution since on HA the name would remain [z=1]My Number

What i am thinking about right now is to add a config option to the webserver component like ```
webserver:

• id: my_number1
  index: 1
• id: my_select1
  index: 2
• id: my_number2
  Index: 3
  .
  ...

@mortal river if the webserver part on the esp would send a sorting index to the js side it would be easy to sort the enitiys right?

[rough bough]

i think that's the best solution, because after, we could add more options to configure each component

[wintry wyvern]

That way we could also add custom grouping

webserver: 
  -id: my_number
   group: "My custom Group"
   index:1

[rough bough]

yes !

instead of index, we could use the word "weight", default is 0, so you can add -10 to get it down or multiple with 10

don't know if you could understand me...

[wintry wyvern]

Makes sense

[hazy lion]

In the meantime, entities with Capital letters first are sorted separately (in an alphabetical order) from entities with small letters.

[grand bone]

Or simply provide a webserver: option to trim any leading digits from the name, AFTER sorting.

webserver:
  trim_sort_key: true

[wintry wyvern]

webserver: 
  - group:
    name: "My Group Nr. 1"
    weight: -100
  - group:
    id: my_group2
    name: "My Group Nr. 2"
    weight : -99
  - id: my_number1 
    group_id: my_group1
    weight: -10
  - id: my_number2
    group_id: my_group1
    weight: -9
  - id: my_number3
    group_id: my_group2
    weight: -10
  -id: my_number4
    group_id: my_group2
    weight: -9

[wintry wyvern]

Also a very good idea

[rough bough]

I think that Rogan is more easy to code but your solution is more intuitive and flexible...

[rough bough]

I would like to try to develop this feature... I've fork esphome and clone it locally, but now, i need to do the same for esphome-webserver respository ?

i don't understand how this repository is included and use from esphome...

Thanks for help 🙂

[rough bough]

Ok, i think that i've understand that a npm build on packages/v2 generate code in _static directory. But, after, how is it integrated in esphome/components/web_server/server_index.h INDEX_GZ[] PROGMEM variable ?

[dawn basin]

So you guys wants drag and drop one esphome webserver too

[wintry wyvern]

npm run build will build the www.js which you would need to include in the webserver component

Or for testing run npm run start which starts a local server for testing.

[inland relic]

If possible

[wintry wyvern]

That would be nice but alot harder to implement

[rough bough]

Ok, sorry. Everything is in the JS... i've not read index.html carefully

[spark crown]

Take a look how the mqtt component adds extra options to each entity

[rough bough]

@spark crown you think it's better to implements it on each component (entity) instead of configuring webserver: ?

[spark crown]

It probably doesnt matter too much, that was just my feedback for not bloating the EntityBase for webserver only because I know how its dont for mqtt 🙂

I dont use the webserver personally

[rough bough]

ok, thanks

[wintry wyvern]

Will do, thanks

[mortal river]

Interesting idea for sure and I'm down to provide support for adhering to a customized sort order. The only thing I do not know offhand and may be a consideration on the device implementation: are webserver properties exposed? Not familiar enough to know where the best place might be to make it available to the frontend.

Related concept that would be a nice addition is also allowing end-users to customize the sort order while retaining it in localStorage on the user's browser.

[fleet cloak]

The web server would provide it along with the other info when it sends the list of items.

[mortal river]

Lovely stuff!

[mortal river]

Just in case you've not figured this portion out yet: you can provide the js_url property under webserver which is the URL to the network hosted static www.js file. This isn't as straightforward currently as it could be and I'll look at improving the following.

• Start out in the latest version at ./packages/v3 and run PROXY_TARGET=http://device-name.local npm run build to generate the static bundles pointing at a particular device-name (or IP address) available on the network
• This will generate the www.js bundle at ../../_static/v3 which I believe you've already located (aka ./_static/v3)
• I've been using the serve global module, but any static file web server will work just as well https://www.npmjs.com/package/serve
• Main key is to serve static files from a path that you reflect in the js_url appropriately
• For example, cd ./_static/v3 && serve -p 8000 would make your js_url: http://192.168.1.123:8000/www.js while providing the IP address of your computer (ifconfig or ipconfig will output options)
• You can leave a window open serving the static files and in a new window run build again to make changes without having to restart the server

[rough bough]

Thank you very much ! it's working for me 🙂 I have not follow all you steps, i was just stucked to find where www.js was.

[mortal river]

No worries. Good development workflow / potential contribution thought exercise for me on something to document and improve.

[rough bough]

Are you the developer of web_server v3 ?

oh, yes, i've seen it on git, thanks for your good work !!

I have these categories :

  private static ENTITY_CATEGORIES = [
    "Sensor and Control",
    "Configuration",
    "Diagnostic",
  ];

What is going in Configuration and Diagnotic ?

[spark crown]

That depends on your device config and what you have in there

[rough bough]

Sure, but, do you have examples ?

[spark crown]

Uptime sensor is diagnostic by default

version text sensors, wifi signal sensors etc are all diagnostic

restart/shutdown/factory reset buttons are all configuration

[rough bough]

nice, thak you !

[spark crown]

the categories are all set by default, but can be overriden in yaml for any entity

[rough bough]

ok, tx

if we are doing something like that : https://tahazsh.com/blog/seamless-ui-with-js-drag-to-reorder-example, do you think it's possible to save the order somewhere in the filesystem ?

or is it forbidden with esphome ?

[grand bone]

The only possible mechanism that I can see being used for that would be to create an internal template number: named something like order_<entity_name> (convention), that refers to the numerical position of the relevant entity. Dragging and dropping the main entity could then update the associated number (and others which get shifted due to movement), which could be saved in EEPROM/FLASH using restore_value: true. Whether internal entities are exposed to the webserver: and hence the browser is an open question.

[grand bone]

I see that there is a include_internal: option for web_server: to control display of internal entities, but that doesn't necessarily mean that it is impossible to query internal entities if you know (or can guess) their names/identifiers, even if the attribute is false. That would allow you to define the entities as internal to not show them, but they could still be used to hold the position of the related entity.

[rough bough]

Ok, so, that is not a good solution IMO

[grand bone]

Sure, it's a hack 🙂

[spark crown]

Nice bug find, Ill fix that next release 😜

[grand bone]

😄 It's a guess that it is possible, but odds are fair that it is.

Solution is probably to make two lists of entities (internal/not internal), and only ever allow the web_server: or api: etc components to interact with the not-internal list.

Or a canonical list of all entities, and a "public" list that points to the relevant entry in the canonical list.

Of course, it would be simpler (less memory) to just check the internal flag in each "external" component (web_server:, api:, mqtt: etc), but there is the risk that that doesn't happen in all access paths.

[wintry wyvern]

The js side could simply contruct a data structure on any drag and drop Event and send it back to the webserver which will store it and send it to the client on future requests

[wintry wyvern]

Had a look. Doing it the mqtt way would mean creating some sort of webserver_entity which holds the nessasery data and add that to each components config if the web_server component is present.
Does that sound about right?

[rough bough]

Sorry, i can't find how YAML config is get from esp-app.ts (for example how to see if log: false)
I think that is here

const conf = document.querySelector("script#config");

But can't find this script in HTML

[wintry wyvern]

The js side has no connection to the yaml at all
The `web_server' sends Events to the clients.
If logging is off the webserver simply never sends any log events

[rough bough]

oh, yes, sorry for that question...

[mortal river]

Afarago was the main dev, I just helped land v3

Regarding persisting sort order to the device, it should probably be optional. I’m picturing two or more people arguing over the remote

[spark crown]

You might not need a class, but can just set the number and a reference to the entity directly on the web server

[rough bough]

Today, i'm trying again to sort components. I've many things to understand, but i move forward step by step 🙂
In the file esp-entity-table.ts, i have

    window.source.addEventListener("state", (e: Event) => {

Where is defined this "state" event ?

Tx

[fleet cloak]

defined?

[rough bough]

I mean, where this state is created ?

[fleet cloak]

I think it's an event that comes from the web server.

[wintry wyvern]

https://github.com/esphome/esphome/blob/dc0a7b1e205f5fa4e25fd1cadd507c27173636e1/esphome/components/web_server/web_server.cpp#L419

I got it working so that you will be able to set a weight and group directly on the component if the web_server component is set in the config and store it together with the hash of the id of the component in a list in the web_server.
I am currently trying to figure out what would be the best way to send it to the client.
Looping through that list and comparing the hash of the ids on every state update seems not very efficient.
But I have not yet found a way to link that list to the entity's on setup

Maybe doing it on DETAIL_ALL would be fine???

[fleet cloak]

Doesn't the web server send a list of all the entities at first?

[wintry wyvern]

https://github.com/esphome/esphome/blob/2345e7606a1ef2d1ec89e36d487666e9be8b2496/esphome/components/web_server/web_server.cpp#L132
Seems so.
And then send a json with DETAIL_ALL of every entity.

Do you think it would be a good practice to compare the the id's a that point?

https://github.com/esphome/esphome/blob/2345e7606a1ef2d1ec89e36d487666e9be8b2496/esphome/components/web_server/web_server.cpp#L442

So I would loop through the list of entitys to sort , compare the id's and on match send the weight and group?

[fleet cloak]

That would be the place to do it.

[wintry wyvern]

alright, seems to work. Can you work with that?

data: {"id":"number-anzahl_h_hner","name":"Anzahl Hühner","icon":"","entity_category":0,"weight":12,"group":"Test Gruppe","min_value":0,"max_value":100,"step":1,"mode":1,"value":20,"state":"20"}```

should we call it webserver_weight instead of weight in the config?

number:
  - platform: template
    name: Anzahl Hühner
    min_value: 0
    max_value: 100
    step: 1
    mode: box
    optimistic: True
    initial_value: 20
    weight: 12
    group: "Test Gruppe"
    on_value:
      then:
        lambda: id(chicken_in_coop_count).publish_state(x);

[fleet cloak]

I think it does need a better name to distinguish it. That's also a highly possible name for a component to use normally.

[wintry wyvern]

I thought so too, can you thinl of a one that would fit?

[fleet cloak]

not off-hand...

[wintry wyvern]

if someone wants to take a look

https://github.com/esphome/esphome/pull/6445

[rough bough]

@wintry wyvern I will take a look at this. Thanks for your work !

[rough bough]

Just to understand , why do you change SCHEMA in the file init.py of the number component ? Is the number component is the base class of all components ?

Even text components for example ?

[wintry wyvern]

No, i was thinking about doing it in the entity_base schema.
But we need a reference to the web_server and I am not sure if that would be a acceptable solution referencing to a component in the entity_base.
I would like some feedback from the guys

[rough bough]

So, do you think it will work on a text_sensor for example ?

[spark crown]

Left some comments

[rough bough]

I'm trying to test your PR. Sorry, it's the first time.
I've put that in my yaml :

external_components:
  # equivalent shorthand for GitHub pull request
  - source: github://pr#6445
    components: [ web_server, number  ]  

And i've the message "Component not found: web_server."

Sorry, it's the first time i'm testing PR in esphome...
Perhaps it's better to test it in another way...

[spark crown]

This can mean python issues in the web_server code. Any python errors above it?

[rough bough]

Oh, yes, you're right :
ImportError: cannot import name 'CONF_WEB_SERVER_SORTING_GROUP' from 'esphome.const' (/home/desktop/esphome-dev/esphome/esphome/const.py)

[spark crown]

Can't be used as an external component

[wintry wyvern]

thanks

[wintry wyvern]

did you manage to get a local copy of the pr and run it in a venv?

[rough bough]

No, just added your PR in my yaml file. By following this documentation : https://esphome.io/components/external_components

[wintry wyvern]

that will not work since i made some changes to /esphome/const.py which will not be updated using the external component feature

[rough bough]

i understand, i will get a copy...

[wintry wyvern]

got it working
https://github.com/esphome/esphome-webserver/pull/58

[wintry wyvern]

would that be an acceptable way off declaring groups?

web_server:
  groups:
    - name: "My Group 1"
      weight: 1
    - name: "My Group 2"
      weight: 2

if so, does someone see a possible way of validating the provided web_server_sorting_group name on the component with the one specified in the web_server?

number:
  - platform: template
    name: "My Number z"
    id: my_number_1
    min_value: 0
    max_value: 100
    step: 1
    mode: box
    optimistic: True
    initial_value: 2
    web_server_sorting_weight: 2
    web_server_sorting_group: "My Group 1"

[rough bough]

Perhaps it could be better to provide an id for groups ?

web_server:
  groups:
    - name: "My Group 1"
      weight: 1
      id: my_group_1
    - name: "My Group 2"
      weight: 2
      id: my_group_2

number:
  - platform: template
    name: "My Number z"
    id: my_number_1
    min_value: 0
    max_value: 100
    step: 1
    mode: box
    optimistic: True
    initial_value: 2
    web_server_sorting_weight: 2
    web_server_sorting_group: my_group_1

[grand bone]

Why would you need a weight in both places?

is that the weight within the group, while the web_server: groups: weight would be the weight of each group relative to each other?

[rough bough]

you have the weight of the group and the weight of each component...

[wintry wyvern]

Exacly, so you would even be able to sort the groups.

[wintry wyvern]

Thats a good idea! The problem is i havent found a way yet to validate that the group set on each entity is actually created on the web_server vomponent

[rough bough]

I've tried to test your PR's, but i get this :

I've copy your yaml file, checkout PR #6445 in esphome and checkout PR #58 in esphome-web

[rough bough]

Perhaps i'm wrong somewhere ?

[wintry wyvern]

So you started the proxy with npm run start and set the PROXY_TARGET env variable?

Or did you build it and include the build js file in the yaml?

[rough bough]

i include the js...

could you post a screenshot ?

but, i've this error when i compile firmware :

Traceback (most recent call last):
  File "/home/desktop/esphome-dev/esphome.orig/venv/lib/python3.11/site-packages/tornado/web.py", line 1790, in _execute
    result = await result
             ^^^^^^^^^^^^
  File "/home/desktop/esphome-dev/esphome.orig/esphome/dashboard/web_server.py", line 807, in get
    self.write(entry.storage.to_json())
               ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'to_json'

here is my conf of my webserver :

web_server:
  js_url: http://192.168.1.15:4173/www.js  

[wintry wyvern]

doesn't seem like a compilation error. Looks like a error on the dasboard.
Did you try uploading it directly from the cmd?
esphome run path/to/your/yaml

[wintry wyvern]

have you tried

web_server:
  js_include: "www.js"
  js_url: ""

web_server:
  js_url: https://deploy-preview-58--esphome-webserver.netlify.app/v3/www.js

should work too

[wintry wyvern]

Does someone see a solution for this? Or should be just dump the grouping for now?

[spark crown]

Lets keep it simple and drop it for now and it can be picked up again in the future, simplifies the PR reviews too to get basic ordering in

[ancient wedge]

ordering > grouping

[rough bough]

@wintry wyvern perhaps you could add comments to your PR's and describe what is working and what is missing...

[wintry wyvern]

https://github.com/esphome/esphome-webserver/pull/58

Works for All components.

And on
https://github.com/esphome/esphome/pull/6445
I stated in the decription that only the number component is implemented. 🙂
I might find some time tonight to add the other components.

Did you get the sorting working on your end?

[rough bough]

Yes, it works now for me 🙂 Sorry, i haven't told you...
good luck for tonight 🙂

[wintry wyvern]

All components should now be sort-able

[wintry wyvern]

slider current value work in progress

[supple heart]

eggcellent!

[wintry wyvern]

How should we handle cases like this, where we have different decimal places?
Should we let the width of the slider be dynamically adjusted or should we make the slider smaller to account for let's say 2 digest after the dot before we shrink the slider?

[grand bone]

If the number of decimals goes up, a slider is likely not the right interface. If it is important to be able to select 15.27, you're never going to do that with a slider

a text box becomes the only way

maaaybe being able to switch between a slider and a text box?

don't like to overcomplicate things

[mortal river]

Especially on mobile, sometimes it is really difficult to get a slider to the value that you actually want. Always having the option to input the exact value you'd like sounds like a sweet option and suppose an implementation could display the number's default with an option to switch to the inverse alternative?

Regarding slider width relative to available space vs values, this is mostly a CSS layout consideration. Couple options there, but I want to say keeping the slider a constant width would look best. If you'd like to propose your changes as is, I'll pull them down and try some things out.

[wintry wyvern]

I will do that later tonight, i am not at home at the moment

[wintry wyvern]

Maybe a long press on the value could let a input field popup.

[wintry wyvern]

https://github.com/esphome/esphome-webserver/pull/66

[wintry wyvern]

Works on mobile devices

[wintry wyvern]

is there a way to get the bot to post
https://deploy-preview-66--esphome-webserver.netlify.app/v2/www.js
and
https://deploy-preview-66--esphome-webserver.netlify.app/v3/www.js

istead of https://deploy-preview-66--esphome-webserver.netlify.app

[spark crown]

It sometimes posts a direct link if only 1 (deployed) file has changed, otherwise it posts the root url

[wintry wyvern]

event: state
data: {"id":"number-cell_voltage_4","name":"Cell Voltage 4","icon":"","entity_category":0,"min_value":0,"max_value":5,"step":0.100000001,"mode":2,"value":3.299999952,"state":"3.3"}

I always thought the rounding error would come from the js side.
But it seams like the web_server already sends the wrong values.
My method to fix it assumed we would get the right data and uses the step to set the decimal places, but since the step already contains the error it will not work.

[grand bone]

Sounds like the web_server: needs to convert the step to a string with the correct number of decimal places. I think that code is already there, just needs to be invoked accordingly. does something like multiply by 10^(decimal places), rounds to an integer, converts to string, then inserts the decimal in the right place. (I think)

[wintry wyvern]

the strange thing is I tested the slider with this and there was no issue at all.
Why would it sometimes get these errors and sometimes not?

https://github.com/esphome/esphome/pull/6507
seemes to fix it for good now. Can someone confirm that?

[spark crown]

Does the js side not care if it is a string or number already?

[wintry wyvern]

interface entityConfig {
  unique_id: string;
  domain: string;
  id: string;
  state: string;
  detail: string;
  value: string;
...

the js side assumes a string already, so no problem there, but I think you are right, js does not care at all

But the web_server sends *
"value":3.299999952
istead of
"value":3.3

[wintry wyvern]

the problem seems to exist the other way around too

the js clearly sends

http://bms-faker-master.local/number/total_voltage/set?value=42.9

and that is the log

[22:29:28][D][number:054]: 'Total Voltage' - Setting number value
[22:29:28][D][number:113]:   New number value: 42.900002
[22:29:28][D][number:012]: 'Total Voltage': Sending state 42.900002

[grand bone]

not surprising that the esphome code parses the string into a float, since the Number's internal representation is a float.

and floats are well known to have this problem

[wintry wyvern]

sure, but it could be parsed with a accuracy, but i dont thin kit is worth the troble atm, since those 0.000002 will not make a difference if you use the number for a calculation

[grand bone]

I think you don’t understand the cause of the problem. Floats just aren’t good for storing anything that needs an exact representation. It’s not about parsing more accurately, it’s simply what happens when you say ‘float a =3.3; printf(“%f”, a);’

[wintry wyvern]

I know, thats why we got the step

[grand bone]

Ok, I just got a bit confused when you talked about "parsed with a accuracy", since the problem is not in the parsing, it's the internal representation.

[wintry wyvern]

Ah ok. I used that, because thats what the helper function is called 🙂

[grand bone]

fair enough then! 😄

[mortal river]

JS can be loosey goosey when it comes to intermingling types, but what you showed here is a TypeScript interface which mostly just helps with enforcing expectations during development and compilation. What actually happens with a remotely provided value is not enforced by TS during runtime, so, usually need to add specific runtime checks and handling for potentially important bits like this.

Seems like a number is being received and we could String(num), num.toString(), or `${num}` to ensure it is always parsed as a string. Also, query parameters are always a key/value pair of strings (?value=42.9 ) [edited to include backticks for ${num}]

[toxic frost]

I am loving the new look and behaviour! Has anyone been looking at he design for Climate Control components? They could do with a bit of attention on mobile. I'd be willing to take a look if not

[lyric totem]

Are there plans to optimize/reduce the size of the JS for v3? I was doing some testing and noticed that it's roughly 6.5x (‼️😳) the size of v2, even gzipped

 33748 v2.js
219172 v3.js

219172-33748 = 185424
219172/33748 = 6.49



 11501 v2.js.gz
 75362 v3.js.gz

75362-11501 = 63861
75362/11501 = 6.55

I prefer to keep the assets local, but currently v3 will eat up a lot of additional space 😕

I see the code is already (at least somewhat) minified, but I'm not sure if things like removing unreachable code have also already been done.

[spark crown]

Something must be wrong there. The code was not that much larger

Ok nvm, it is way larger

[grand bone]

Most of that is likely the graphing library

[wintry wyvern]

Nope, i created an issue for that because it is basicly unsuable at the moment.
Go ahead and work on it 👍

[lyric totem]

Yeah…that definitely seems to be a lot of it. The www.js.gz is 75362 bytes with it and 23669 bytes without. That's still (almost exactly 🤔) 2x the v2 version though.

[wintry wyvern]

Doesnt v3 include Icons where v2 did not?

Or are they pulled from remote?

[lyric totem]

If you're referring to the icons along the left of the "Sensors and Controls" entities, those are pulled from remote (e.g. https://api.iconify.design/mdi.json?icons=water-percent) in this case. There are some embedded SVGs for things like the home icon, but those are in v2 as well.

[toxic frost]

This is my thoughts for the climate. To reflect what is seen in HA?
This includes current preset, current mode, current state, current temperature, and target temperature.
It's "read only" currently so you wouldn't be able to change the temperature targets, but it looks a lot cleaner. It could also have a graph to represent the current temperature?

[grand bone]

That looks good to me. Would be nice to be able to graph the current temperature like the other sensors.

I wonder how hard it would be to pull the actual HA html/javascript to use in the web server interface?

[wintry wyvern]

I see. So where does the doubling of the size come from?

[wintry wyvern]

Looks good so far.
What should be adjustable on the control side?
The target temp and humidity?

[toxic frost]

Yeah agreed on the graph - that seems to be easy enough.
The HA UI would be nice, but actually the only thing that needs to be set is the temperature target(s), so we could keep the overheads quite low by perhaps just making those input boxes

[toxic frost]

It's actually just temperature targets - depending on whether they have one or two set points. Humidity isn't controllable in any of the current climate components as far as I can see

[wintry wyvern]

Ok. I actually never used the Climate component so far.
I only saw two sliders on it while testing the sorting.
So i guess it should be possible to make the temps adjustable by a slider. It only needs to be positioned the right way and at a usable size.

In case you missed it. A long click on the current value of the slider will Pop up a input field so you can Typ in a precice value.

[toxic frost]

Do we even need a slider I suppose is my current thought process. You're generally only likely to change the temperature by small amounts so is an "up/down" better? Because when you have a high and low set point for a component that would mean two sliders as well

The other thing is you can change the Mode and Preset in the HA UI (drop-down) so should consider that too

[wintry wyvern]

I guess a + and - button to change the target would work as well

[wintry wyvern]

How did v2 handle all this? I am not at home atm, so i cant test it

[toxic frost]

Mode only, with radio buttons to select the desired mode. Presets are not displayed at all

[toxic frost]

I'll spin up a dev environment later and try getting the "read only" bit working first

[lyric totem]

There is generally more actual source code (packages/v2/src is 60K while packages/v3/src is 104K), and v3 includes the iconify-icon, which seems to use quite a lot of space considering it doesn't actually contain the icons. 🤨

60K iconify-icon.cjs
10K iconify-icon.d.ts
63K iconify-icon.js
22K iconify-icon.min.js
59K iconify-icon.mjs

I'm guessing/hoping only iconify-icon.min.js is actually bundled, but that still seems like an awful lot of space for essentially turning <iconify-icon icon="blah"/> into a request to https://api.iconify.design/mdi.json?icons=blah 🧐

[spark crown]

Please see #devs message

[toxic frost]

Managed to get the graph working for Climate

[toxic frost]

Need to resolve the width issue, I know this is an ongoing discussion about how best to use the screen space. Any suggestions?
Think I'd also like to sort the capitalisation and replace the underscore to match HA

[wintry wyvern]

I think you should get the controls in there as well before deciding on a final layout
Maybe an arrow down on the left to lower the requested temp and an arrow up on the right to increase the temperature.
I am not to familiar with the climate compoment. Are the number of modes fixed or can you define your own in the config?

[fleet cloak]

Different components have different numbers of modes I think.

[wintry wyvern]

on v2 the mode can be choosen via a select

[toxic frost]

Correct, and the Preset is the same. It's not changeable in V2 but it's just as valid as an option

[toxic frost]

I'm almost there with controls for climate, just need to make it look nice now. Issue I've got is any input components over the graph trigger the expand! I know someone flagged it - is it being looked at or is that something I should focus on first?

[lyric totem]

Let me know if https://github.com/esphome/esphome/pull/6563 needs any other changes or is good to merge

[wintry wyvern]

Do you mind sharing your work as a draft PR?

  _handleEntityRowClick(e: any) {
    if (e?.currentTarget?.domain === "sensor") {
      if (!e?.ctrlKey) e.stopPropagation();
      e?.currentTarget?.classList.toggle(
        "expanded",
        !e.ctrlKey ? undefined : true
      );
    }
  }
}

You mean a single click? Like on any Sensor?
Seems strange to me that it would also expand it on your control for the climate since it checks if its type sensor, but i guess it depends on how you got the graph implemented

[toxic frost]

Yeah I'll do that today. I've actually modified that function to add the climate to that if statement, so that I can show the graph in the same way. The problem is the propagation from controls within that div. I've managed to resolve it for the up and down buttons I've added, but the select components are more challenging, but I've got a couple ideas

[wintry wyvern]

@lyric totem did you get anywhere with modifying the flex to allow more space for the control and truncate long names?

[wintry wyvern]

I modified the double click behavior to only listen on the tab headers instead of the whole page.
What do you guys think, is this a good change?

https://github.com/esphome/esphome-webserver/pull/81

give it a try with

web_server:
  js_url: https://deploy-preview-81--esphome-webserver.netlify.app/v3/www.js

then we could expand the sensor graph with a double click instead of a single click

[lyric totem]

I took a stab at getting the basics to work in jsfiddle, but still need to test actually integrating it
https://jsfiddle.net/d24rcfyu/

Some of it's definitely still pretty broken, like extremely this narrow column

[toxic frost]

Draft PR created for the Climate changes I'm working on: https://github.com/esphome/esphome-webserver/pull/86

[toxic frost]

Sliders seem to be a real problem in general. Do you think we could get away with not using sliders and using up/down arrows for everything? Takes up a bit more vertical space but helps with the limited horizontal?

[lyric totem]

Eh I actually like sliders in general. Like if I want to change a light from 20% to 80% I don't want to have to wail on up/down arrows or type the value in

In this particular case I haven't actually done anything to adjust how they resize, just made the label collapse to give them max space. Definitely possible to improve with flex box, I just don't really know it well enough to do it yet without more research

[toxic frost]

Yeah that's a fair point on the lights front, I'd forgotten about those 🙈

[wintry wyvern]

hmm, i thought you wanted the controls to use more space if the name is short?
It seems like the controls are a fixed width and only the name shrinks.

[wintry wyvern]

the new sliders are actually pretty enjoyable especially since it shows he current value now and on a long click on the current value an input field appears where you can type in a precise value.

[lyric totem]

Right, still tbd, but at a high level I want them to use more (maybe not all) available space, but have the label shrink before the controls do

[wintry wyvern]

i will probably never use the climate component, but i think it gets annoying quickly if you want to change the temp by lets say 3 decrees and you would have to push a button 30 times.

[wintry wyvern]

https://github.com/esphome/esphome-webserver/pull/87
I had a go at it.
I tired doing it like this

+------------------------+
| Short     o==========o |
| Longer name here   o=o |
| Not so long o========o |
+------------------------|

but i seemed way to chaotic, so i sticked to the flex and truncated the name and set a min-width

[wintry wyvern]

Would still need a way to show the full name on hover, but only if the name is shortend i would prefer.
How could we handle mobile device in that regard?

[toxic frost]

I didn't put this in the PR but I've changed the step to be 0.5 in the climate config - as 0.1 steps don't really make huge sense in the climate world. You generally only adjust by a couple of degrees.
But you're right, I'll play with the sliders as the new look does improve them. Especially if we can get to a stage where the width improves like above

[toxic frost]

I can't think of an obvious answer for mobile. However a combination of what you've done and a smaller font might be a good idea?
Also perhaps considering how we could use another row for more advanced controls?
What about moving the log to the bottom (like on mobile) permanently for all screen sizes?

[wintry wyvern]

I think the font size is about right as it is.
Moving the log to the bottom might be an option, but I actually like the log on the side so see what it prints if i hit a control without scrolling.

Conrols do not have a fixed hight. You can design it as high as you like, or what do you mean with another row for advanced controls?

After locking at it today, i think we could actually get way with shortening the name some more and give the control side even more space

[toxic frost]

Font size I was thinking specifically on mobile. Feels quite sizable in comparison to the HA app for example.

[toxic frost]

Most controls are quite small and fit nicely next to the name, but there's a few that could benefit from being on a separate line in the row. Number for example could have the top line with name and current number, then the slider full width below?
Fan/Lock components would benefit similarly, with their current state being the top line (which is currently missing) and the controls on the second line?

[wintry wyvern]

Ok, that could be an option, to mske the name smaller and put it maybe in the top left corner and put the controls below.

Try it out and post some Screenshots 🙂

[dawn basin]

OTA not possible on it yet?

[acoustic edge]

is this done using device class?

I'm thinking this can be a way to somewhat have an order to the entities

to answer my own question it seems like there is only 2 options entity_category: "config" Anyway to make a custom category?

[spark crown]

categories and device classes are separate things.

No you cannot make a custom one

[acoustic edge]

how would I override the category?

[spark crown]

in yaml

you can set it to "", "diagnostic" or "config"

[acoustic edge]

Oh I misread you, so as I wrote

Why wasn't the sorting/ordering PR pushed?

https://github.com/esphome/esphome/pull/6445

[spark crown]

No, the docs are not done, and when looking at them I realised it needs a validation too because sorting weight is only valid for v3

[acoustic edge]

Gotcha.
If there are any other components that potentially may use the same sorting weight, it perhaps shouldn't haveweb_server in the name

[spark crown]

I doubt there are any

[wintry wyvern]

What you want would be custom grouping of the entitys. If we get sorting merged i would like to get back to grouping and work on that

[wintry wyvern]

should work the same as on v2.
What is not working?

[acoustic edge]

That would be awesome 👍👍

[dawn basin]

I mean webserver OTA option... Need it to update firmware remotely

this option

[wintry wyvern]

Is not there? Are you not able to choose the file? What is the problem?

[dawn basin]

in which version of v3?

[wintry wyvern]

Ota configuered in the config?
V3 has a Bug where ota is displayed even if not specifided in the config

[wintry wyvern]

The latest relase

[dawn basin]

can you share the code for v3 which one to use

[wintry wyvern]

ota:

web_server:
  version: 3 

Should work just fine

[dawn basin]

let me test it

with esp-idf too?

[spark crown]

No webserver ota with idf at this time

[dawn basin]

PR is waiting?

[acoustic edge]

@wintry wyvern what's the idea of this circle on the top right?

[fleet cloak]

Is that the replacement for the heartbeat indicator?

[acoustic edge]

Seems like it, what was that for?

[fleet cloak]

To indicate that you're actually still connected to a running device.

[acoustic edge]

Anyway to make it more subtle/March the design better?

It seems to only pulse for a second then it stops, not sure if that's by design

[rotund willow]

Agreed

[acoustic edge]

I'm noticing when the device isn't active the symbol changes. Can we just have that symbol and keep it blank when it alive?

[wintry wyvern]

We can have what ever we like 🙂
I was fine with the heart we have got bevor.+
Not sure who had the idea of changing it to the greed circle

[acoustic edge]

I vote remove unless we are offline. It otherwise looks very clean

[supple heart]

I think the heart is better because it also denotes what it is and its function

[rotund willow]

It's over-complicated with heart bumping and circles etc.
It should simply display mdi:close-network-outline when disconnected. That would be in sync with standard HA UI, which uses the same icon for the status binary sensor

it shouldn't display anything when connected, or mdi:check-network-outline.

[wintry wyvern]

The esp sends every 30 seconds a ping to let the Browser know if there is still a connection.
So i think we would need to start/reset a timer on a ping event. If that timer reaches 30+ seconds show the disconnected icon and remove it on a ping Event or replace it with the connected one.

Could you implement that and open a PR?

[mortal river]

I think, but am not sure, that I may have added the "Adjust beating heart to a green dot or only display an offline indicator" line item to the fixes and feature requests issue being used to track feedback and action items from this thread.

pzich kindly adjusted it to a green dot and I'll have a look at adjusting it to only appear when offline. Since there seems to be a sort of a split of preference here, would this be a good candidate for a configuration option of sorts?

[mortal river]

Working on improving the local development workflow and readme currently, curious which of these "Near future" checklist items may already be complete:

- [ ] Support for compressed files in flash for Standalone no internet nodes
- [ ] Add Climate
- [x] Add Select drop list
- [ ] Add Number editing
- [ ] Potentially use an optional card layout instead of a table

I want to say Climate and Number editing may be, but I could easily be wrong or missing others. I was going to migrate this list to issue #56 for easier editing and additions while also suggesting opening a separate Issue for a problem or feature request.

[inland relic]

I think valve support can also be added to the list

[mortal river]

Sorry, not familiar with that yet. Is that from the Sprinkler Controller component? https://esphome.io/components/sprinkler

[inland relic]

https://beta.esphome.io/index.html i think it is not in the normal release

[rotund willow]

Valve is just a new kind of Cover

Internally is mostly the same

[mortal river]

Ah OK, wonder if potentially covered by https://github.com/esphome/esphome-webserver/issues/61

[mortal river]

I've had the only display a disconnected icon change awhile ago, but been a bit lost in the weeds on trying to understand why it seems like once a device goes offline that it never comes back online. Anyone else observed the same? Will resume after sleepies.

[mortal river]

Think I figured out why and have a solve. Like HA, we should probably disable interactable elements when disconnected otherwise you might get the false impression that changing something might actually work.

[wintry wyvern]

Climate got something merged, not finished tho.
Number schould be finished, but i think we should modify the docs to let people know that a long click on the current value in slider Mode will let a input field Pop up to set a perice number.

[mortal river]

Is an online/offline icon necessary if interactable elements are disabled? That’s the HA approach as well?

[acoustic edge]

An indicator for offline can't hurt

Also a device can technically not have any shown entities

[mortal river]

Makes sense. Was also wondering if a grayed offline indicator may be too subtle and if it should possibly be red. Also, relatively random icons without context are often confusing for users, so perhaps will add a tooltip on click tap. I did add a "last seen" concept for "30 seconds ago" that I could adjust to say "Offline for 30 seconds" instead.

[spark crown]

The webui is useless when not connected right? Just blur the entire page and add a disconnected "dialog"

[wintry wyvern]

I vote for this!

[dawn basin]

what if using devices without the HA?

api will not be connected in that case

[spark crown]

It has nothing to do with api

It's just the ping between the browser and device

[dawn basin]

in that case this is good idea

[acoustic edge]

and please remove that green circle..

[wintry wyvern]

did we make some changes that could effect a switch recently?
Whatever the state of the swich is currently it always sends the rest action turn_on

[spark crown]

Im seeing this, its not always sending turn_on, but the opposite of the state of the switch when the page was loaded

v2 is working correctly, so something has gone wrong in v3

But light switches work correctly

[wintry wyvern]

It only works once. Then i breaks. Reloading the page will get it working again one time.

  toggle(ev: Event): void {
    console.log(this.state);
    const newState = this.isOn() ? this.stateOff : this.stateOn;
    let event = new CustomEvent("state", {
      detail: {
        state: newState,
        id: this.id,
      },
    });
    this.dispatchEvent(event);
  }

toggle is called fine, but the state is always the same, even the switch on the website is cleary changing its state

[spark crown]

I tried to take a wuick look at the webserver code this morning but I am way too unfamiliar with it

[wintry wyvern]

but I cant see any commit that could have affected it.
which browser did you use? did chrome get an update?

[wintry wyvern]

ok found it

PR #86 broke it

There is no historic value for a switch, so
let history = [...this.entities[idx].value_numeric_history];
fails and
Object.assign(this.entities[idx], data);
is never called to update the switch

        let history = [...this.entities[idx].value_numeric_history];
        if (typeof data.value === "number") {
          history.push(data.value);
        } else if (data.current_temperature) {
          history.push(Number(data.current_temperature));
        }
        this.entities[idx].value_numeric_history = history.splice(-50);

can we revert that PR?

or do i need to open a PR ot revert it?

[fleet cloak]

I think everything needs a PR.

[spark crown]

what pr added that?

I think that was just part of the v3 initial code, so its not exactly reverting it, but it needs to be fixed

[wintry wyvern]

https://github.com/esphome/esphome-webserver/pull/98

[wintry wyvern]

#86

[spark crown]

I don't think we should revert that entire pr.

[wintry wyvern]

I think we should. The climate entity wasn´t even finished and I dont want to fix his code

[lyric totem]

I think you could also just make that

let history = [...this.entities[idx]?.value_numeric_history ?? []];

so that an empty history array gets created if value_numeric_history doesn't exist

[toxic frost]

@wintry wyvern I'd also agree - I'd done that PR as a draft so others could review, I've yet to publish the changes we'd discussed (reverting to using the newly updated sliders), and I can fix this also

[spark crown]

🙈 I tested it out with the demo climates and it was all working so I just assumed it was left

[spark crown]

I can merge the revert if you are happy to and want to reopen a new PR for the climate stuff?

[toxic frost]

Yeah go with that and I'll try and get the climate stuff sorted this week

[spark crown]

@wintry wyvern your revert PR also reverts another PR?
Did you not just create the revert PR in github (It can be done with two clicks 😄)

[wintry wyvern]

I hope not. I did it in vs code. Still learning about git stuff.
Do you mind creat the revert PR if mine is not correct.

[spark crown]

I did already and released it 🙂

[mortal river]

Can anyone confirm that a device can go online/offline/online successfully?

• Target a device or otherwise load a device's page and wait for it show as online
• Remove power from the device and wait for it to go offline per the device page
• Re-add power to the device and ensure that it does (or does not) come back online per the device page

[wintry wyvern]

I will do it after work, but I think I saw that happening allready.
Online/loosing wifi Signal, offline/connecting again, online.

[mortal river]

Thanks for the early confirmation and much appreciate the sanity check. Must be something about the development workflow / proxy dealio. Wondering if a reconnection routine type improvement there might still be goods.

[wintry wyvern]

So it woks as expected.
Device is online indicated by the green circle after removing the power for about 35 seconds the green circle disappears. Adding power back to the device the green circle appears again

[mortal river]

Nice, happy to hear it. Figured this was a basic expectation that would've been called out by now. By chance setup for local development and can confirm that this issue is or is not present there? No worries if not.

[wintry wyvern]

I might find the time to test this tonight, but I expect the same behaveor since the connection status is somehow linked to the ping event, which should be forwoared by the proxy like all the other events.

[rough bough]

Hi ! Does V3 have documentation ? is it possible to see it ?

[fleet cloak]

What kind of documentation?

[rough bough]

There is nothing about v3 here : https://esphome.io/components/web_server or in the github (https://github.com/esphome/esphome-docs/blob/beta/components/web_server.rst). So is it existing somewhere ?

[wintry wyvern]

Strange, i thought we changed the docs to let the user know version: 3 is an option know.

[rough bough]

do you think it's lost ?

[wintry wyvern]

Ah is see i only changed it in my PR for entiy sorthing which is not merged yet.

Feel free to open a pr

[rough bough]

where is ou PR ? on your local repository ?

[wintry wyvern]

no,https://github.com/esphome/esphome-docs/pull/3741

[wintry wyvern]

webserver_sorting and the docs for it should be ready. I hope we can get it into the next beta and start working on grouping

[spark crown]

is that pr still open? 🙈

[wintry wyvern]

yep, i just saw that you requested some changes to the docs

[spark crown]

Both code and docs PRs are failing CI too

Probably why I have not come back to them...haha
My PR list filters out draft prs or PRs with failing CI runs 😅

[wintry wyvern]

hmm, doc is failing bc of the size of the image for v3, but v1 and 2 are also using bigger images

[wintry wyvern]

the code one seems to be failing on the valve, I guess you added that, right?

seems like merging dev broke it, but i cant see the issue

found it, i messed up the manual merge from dev

[lyric totem]

Any thoughts on using websockets (or some other type of bidirectional socket) for web_server I/O? I'm not sure how much overhead that adds, but I've noticed that while the POST requests for setting values are generally fast, they sometimes take an absurdly long amount of time.

I'm guessing this will only get worse / more frequent when building things that require higher frequency input/POSTs.

Right now a socket is already being kept open for the EventStream stuff, but it's solely for output. If this was replaced with a websocket, it could be used for both.

[fleet cloak]

That seems like a network issue of some kind. It's very unlikely that the ESP is taking that long to respond.

[lyric totem]

I believe it's other network requests in flight (since I think the async server can only handle ~4 at a time, and there's already one occupied persistently by each EventStream)

[fleet cloak]

Is something else connecting to the ESP?

I guess you would have to do some network sniffing to see where the issue is.

[mortal river]

WebSockets isn't a terrible idea to consider as we are indeed essentially doing bidirectional communication (Server-Sent Events for state updates and XHR requests to change state). One limitation of SSE is that it indeed shares the same pool of browser-limited concurrent connections which varies per-browser, but I agree that the latency you observed was probably not a browser request concurrency limit (e.g. EventStream, downloading an image, turning something off, and something else(s) all in parallel). The image you shared would have to have 4+ requests overlapping for it to potentially be a concurrency issue.

However, one potential problem with considering WebSockets currently is that the ESPHome web server itself would have to support WebSockets. If not already supported, that would mean that someone would have to add support for the server side equivalent. If we've got or could add server side support, I'd be happy to help replace SSE with WS on the client side.

[fleet cloak]

Exactly, that's the big issue right there.

Btw, this thread is now in the wrong section. 🤣 It's no longer "external".

[mortal river]

Fair point, but losing all the subscribers would be somewhat of a bummer. Would a new channel under the Development category be a good option to keep it topical? Suppose #device-builder nor #devices-website is the right place

[fleet cloak]

It's fine for now. I just thought it was kind of funny. But actually, since there's so much interest now, a new channel would be good.

What should it be called?

[mortal river]

Dashboard refers to the ESPHome devices dashboard for logs, installing, etc correct? I'm not sure what terminology HA uses for their device dashboards, but perhaps #devices-dashboard?

To be honest, I've found it a little confusing previously that the device page thingie is in the esphome-webserver repo since "web server" often refers to the thing serving web pages as opposed to the web page itself

but this is more a javascript bundle being served by the device?

[fleet cloak]

They are somewhat connected, but yes.

[mortal river]

*javascript bundle being loaded by the page that the device is serving?

optionally embedded and also being served by the device

OH right, esphome-webserver is in fact the repo for the actual ESPHome web server that is also serving the javascript bundles. It has just clicked.

[fleet cloak]

Actually, no. 🙂 It's only the front end.

A Lit Element web component frontend for the ESPHome web_server.

[mortal river]

Doh. But something in ESPHome's infrastructure is serving JS bundles resulting from compilation from this repo, suppose maybe just for local development it is also the web server.

[fleet cloak]

I think that's github with a CDN in front.

But the device web server can serve the bundle if set to local.

[mortal river]

Roger roger. Repo naming convention aside, not certain what may be best and surely someone else while chime in with a yay, nay, or other idea.

[fleet cloak]

I'll wait for a bit more discussion before creating the channel.

[spark crown]

The webserver assets are served by netlify with cloudflare in front

[spark crown]

What would be the topic?

[fleet cloak]

Basically what this channel has become. Discussions about the web interface for the device.

esphome/web-server 🙂

[spark crown]

web_server?

lol

device-webserver

[fleet cloak]

I was thinking that might as well be it. It could definitely include changes to the web server itself, like the websockets mentioned earlier.

[spark crown]

frontends:
  - home-assistant
  - mqtt
  - webserver

[fleet cloak]

How would you represent that as channels?

[spark crown]

frontends being the category

#device-webserver

[mortal river]

Yay! Separate threads will be useful for various webbie topics. Much appreciated.