2024.4: Organize all the things!

Anyone experiencing issues with JSON parsing via REST sensors after upgrade to 2024.4? Some of my sensors completely stopped to work, some have problems with parsing some of JSON nodes. No errors in log file, sensors return ‘unknown’ value.
Example of parsing weatherbit data directly from file:

rest:
  resource: http://192.168.52.53:8123/local/weatherbit.json
  sensor:
    - name: weather_code # working properly
      value_template: '{{ value_json.data[0].weather.code }}'

    - name: precip_0 # working properly
      value_template: "{{ value_json.data[0].precip | round(1) }}"
      unit_of_measurement: "mm"

    - name: precip_probability_0 # sensor have state unknown
      value_template: "{{ value_json.data[0].pop | int }}"
      unit_of_measurement: "%"

and here is corresponding part of JSON file:

{
    "city_name": "Zielonka",
    "country_code": "PL",
    "data": [
        {
            "app_max_temp": 13,
            "app_min_temp": 0.7,
            "clouds": 62,
            "clouds_hi": 36,
            "clouds_low": 40,
            "clouds_mid": 72,
            "datetime": "2024-04-04",
            "dewpt": 4.3,
            "high_temp": 13,
            "low_temp": 10.5,
            "max_dhi": null,
            "max_temp": 13,
            "min_temp": 1.7,
            "moon_phase": 0.148609,
            "moon_phase_lunation": 0.87,
            "moonrise_ts": 1712199069,
            "moonset_ts": 1712234119,
            "ozone": 388,
            "pop": 45,
            "precip": 1.5263672,
            "pres": 1001.2,
            "rh": 82,
            "slp": 1012.4,
            "snow": 0,
            "snow_depth": 0,
            "sunrise_ts": 1712203335,
            "sunset_ts": 1712251098,
            "temp": 7.2,
            "ts": 1712181660,
            "uv": 2.9,
            "valid_date": "2024-04-04",
            "vis": 23.336,
            "weather": {
                "description": "Light shower rain",
                "code": 520,
                "icon": "r04d"
            },
            "wind_cdir": "SSE",
            "wind_cdir_full": "south-southeast",
            "wind_dir": 150,
            "wind_gust_spd": 4.9,
            "wind_spd": 2.1
        },
.........
    ],
    "lat": 52.3112,
    "lon": 21.1612,
    "state_code": "78",
    "timezone": "Europe/Warsaw"
}

EDIT: removed part related to Synology sensors, there was internal NAS web server that caused json file not be available…

The id for your alarm remains the same when you rename it. Otherwise it wouldn’t stay attached to entities, devices and other things.

a yes, this is the ‘issue’ we ran into during beta… the id of the label/floor/area doesnt change when changing the name

immediately illustrates my point of how illogical/disfunctional that is, when using templates.

moreover, the id of the label is not ‘known’ to the user anymore after editing that (it’s not displayed like it is for areas/floors)

During beta I had not yet realized this was also happening on labels, otherwise I would have stressed it a bit more…

seems to me this cant hold, and needs to be taken care of

6 Likes

Clearly renaming the label simply renames the UI visual element - the Name

Here’s one I created with a typo - after renaming, the label_id still has the type

  {
    "color": "lime",
    "description": null,
    "icon": "mdi:gesture-tap-button",
    "label_id": "decive_control",
    "name": "Device-Control"
  },

I understand that altering the label_id might break any existing referenced to it… but I did opt in for …

image

I would like to be able to edit the label_id, just as I can with the entity_id (well the name part)

I don’t want this typo label_id in my automations and templates, I guess I’ll just have to …

  • create the correct version of the label
  • filter the entity list for the old label
  • assign the new label to all those entities
  • remove the label with the typo from the entities (painfully, one-by-one as I still see no bulk remove )

Most other linkage between objects in homeassistant is maintained by internal IDs (that we cannot edit), this enables us to have a Display Name, and a slugged_name_or_id that we can use in YAML

2 Likes

Hi,

I’ve got an issue with MQTT Add-On Mosquitto which affect Zigbee2MQTT. Is anyone got this problem ? A rollback from backup doesn’t work since this Add-On wasn’t backup.

Into the log of Mosquitto:

2024-04-04 11:07:06: New connection from 127.0.0.1:57766 on port 1883.
2024-04-04 11:07:06: Client <unknown> disconnected due to protocol error.
2024-04-04 11:07:06: New connection from 172.30.33.6:60134 on port 1883.
[11:07:06] INFO: Successfully send discovery information to Home Assistant.
2024-04-04 11:07:06: New client connected from 172.30.33.6:60134 as mqttjs_5ce1f065 (p5, c1, k60, u'addons').
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7f40e53da909]

goroutine 23 [running]:
runtime.throw(0x7f40e5ae3b7a, 0x5)
	/usr/lib/go-1.15/src/runtime/panic.go:1116 +0x74 fp=0xc000067d00 sp=0xc000067cd0 pc=0x7f40e4fd5cb4
runtime.sigpanic()
	/usr/lib/go-1.15/src/runtime/signal_unix.go:749 +0x405 fp=0xc000067d30 sp=0xc000067d00 pc=0x7f40e4febc65
net/http.newTransferWriter(0x7f40e5eef3a0, 0xc0000b8600, 0x7f40e5aee965, 0x10, 0xc000067e58)
	/usr/lib/go-1.15/src/net/http/transfer.go:76 +0x9 fp=0xc000067d38 sp=0xc000067d30 pc=0x7f40e53da909
net/http.(*Request).write(0xc0000b8600, 0x7f40e5f3b8a0, 0xc000130000, 0x0, 0xc000110120, 0x0, 0x0, 0x0)
	/usr/lib/go-1.15/src/net/http/request.go:628 +0x4d1 fp=0xc000067e98 sp=0xc000067d38 pc=0x7f40e53ce771
net/http.(*persistConn).writeLoop(0xc00012a000)
	/usr/lib/go-1.15/src/net/http/transport.go:2349 +0x1c5 fp=0xc000067fd8 sp=0xc000067e98 pc=0x7f40e53ec225
runtime.goexit()
	/usr/lib/go-1.15/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc000067fe0 sp=0xc000067fd8 pc=0x7f40e500c6e1
created by net/http.(*Transport).dialConn
	/usr/lib/go-1.15/src/net/http/transport.go:1716 +0xcdc

goroutine 6 [chan receive]:
github.com/iegomez/mosquitto-go-auth/backends/files.(*Checker).watchSignals(0xc000321ea0)
	/usr/src/mosquitto-go-auth/backends/files/files.go:107 +0x9e
created by github.com/iegomez/mosquitto-go-auth/backends/files.NewChecker
	/usr/src/mosquitto-go-auth/backends/files/files.go:97 +0x285

goroutine 17 [select, locked to thread]:
net/http.(*persistConn).roundTrip(0xc00012a000, 0xc000215040, 0x0, 0x0, 0x0)
	/usr/lib/go-1.15/src/net/http/transport.go:2573 +0x7a5
net/http.(*Transport).roundTrip(0xc000235680, 0xc0000b8500, 0x7f40e5ef4e00, 0x7f40e3ee4b01, 0xc0000b8500)
	/usr/lib/go-1.15/src/net/http/transport.go:582 +0xab8
net/http.(*Transport).RoundTrip(0xc000235680, 0xc0000b8500, 0xc000235680, 0xc17bb94fdac5d183, 0x141c7db1f)
	/usr/lib/go-1.15/src/net/http/roundtrip.go:17 +0x37
net/http.send(0xc0000b8400, 0x7f40e5f3d320, 0xc000235680, 0xc17bb94fdac5d183, 0x141c7db1f, 0x7f40e6508fe0, 0xc000010a20, 0xc17bb94fdac5d183, 0x1, 0x0)
	/usr/lib/go-1.15/src/net/http/client.go:252 +0x453
net/http.(*Client).send(0xc000319590, 0xc0000b8400, 0xc17bb94fdac5d183, 0x141c7db1f, 0x7f40e6508fe0, 0xc000010a20, 0x0, 0x1, 0x6)
	/usr/lib/go-1.15/src/net/http/client.go:176 +0xff
net/http.(*Client).do(0xc000319590, 0xc0000b8400, 0x0, 0x0, 0x0)
	/usr/lib/go-1.15/src/net/http/client.go:718 +0x45f
net/http.(*Client).Do(...)
	/usr/lib/go-1.15/src/net/http/client.go:586
github.com/iegomez/mosquitto-go-auth/backends.HTTP.httpRequest(0x557825c87270, 0xf, 0x557825c881c0, 0xa, 0x557825c846e0, 0x4, 0xc00037c750, 0x10, 0x557825c85e00, 0x9, ...)
	/usr/src/mosquitto-go-auth/backends/http.go:235 +0x673
github.com/iegomez/mosquitto-go-auth/backends.HTTP.GetSuperuser(0x557825c87270, 0xf, 0x557825c881c0, 0xa, 0x557825c846e0, 0x4, 0xc00037c750, 0x10, 0x557825c85e00, 0x9, ...)
	/usr/src/mosquitto-go-auth/backends/http.go:167 +0x278
github.com/iegomez/mosquitto-go-auth/backends.(*Backends).checkAcl(0xc000321e30, 0x557825cb6a00, 0x6, 0x557825cb57f0, 0x1c, 0x557825cb6ea0, 0xf, 0x2, 0xc0000c8f20, 0xc0001c1bf0, ...)
	/usr/src/mosquitto-go-auth/backends/backends.go:473 +0x53e
github.com/iegomez/mosquitto-go-auth/backends.(*Backends).AuthAclCheck(0xc000321e30, 0x557825cb6ea0, 0xf, 0x557825cb6a00, 0x6, 0x557825cb57f0, 0x1c, 0x2, 0xf, 0x2, ...)
	/usr/src/mosquitto-go-auth/backends/backends.go:417 +0xa99
main.authAclCheck(0x557825cb6ea0, 0xf, 0x557825cb6a00, 0x6, 0x557825cb57f0, 0x1c, 0x2, 0xf, 0x1, 0xc0001c1e80)
	/usr/src/mosquitto-go-auth/go-auth.go:370 +0xb1
main.AuthAclCheck(0x557825cb6ea0, 0xf, 0x557825cb6a00, 0x6, 0x557825cb57f0, 0x1c, 0x2, 0x38)
	/usr/src/mosquitto-go-auth/go-auth.go:338 +0xae
main._cgoexpwrap_6c877fb7ed5a_AuthAclCheck(0x557825cb6ea0, 0xf, 0x557825cb6a00, 0x6, 0x557825cb57f0, 0x1c, 0x2, 0x7c0000006e)
	_cgo_gotypes.go:71 +0x6c

goroutine 7 [select]:
github.com/patrickmn/go-cache.(*janitor).Run(0xc00023f200, 0xc000214fc0)
	/root/go/pkg/mod/github.com/patrickmn/[email protected]+incompatible/cache.go:1079 +0xda
created by github.com/patrickmn/go-cache.runJanitor
	/root/go/pkg/mod/github.com/patrickmn/[email protected]+incompatible/cache.go:1099 +0xab

goroutine 20 [syscall]:
os/signal.signal_recv(0x0)
	/usr/lib/go-1.15/src/runtime/sigqueue.go:147 +0x9e
os/signal.loop()
	/usr/lib/go-1.15/src/os/signal/signal_unix.go:23 +0x25
created by os/signal.Notify.func1.1
	/usr/lib/go-1.15/src/os/signal/signal.go:150 +0x46

goroutine 22 [IO wait]:
internal/poll.runtime_pollWait(0x7f40e024beb8, 0x72, 0x7f40e5f3eb00)
	/usr/lib/go-1.15/src/runtime/netpoll.go:222 +0x65
internal/poll.(*pollDesc).wait(0xc000118118, 0x72, 0x7f40e5f3eb00, 0x7f40e64af168, 0x0)
	/usr/lib/go-1.15/src/internal/poll/fd_poll_runtime.go:87 +0x47
internal/poll.(*pollDesc).waitRead(...)
	/usr/lib/go-1.15/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Read(0xc000118100, 0xc00012e000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	/usr/lib/go-1.15/src/internal/poll/fd_unix.go:159 +0x1a5
net.(*netFD).Read(0xc000118100, 0xc00012e000, 0x1000, 0x1000, 0x5, 0x7f40e5068a9d, 0x557825c842d0)
	/usr/lib/go-1.15/src/net/fd_posix.go:55 +0x51
net.(*conn).Read(0xc000126008, 0xc00012e000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	/usr/lib/go-1.15/src/net/net.go:182 +0x90
net/http.(*persistConn).Read(0xc00012a000, 0xc00012e000, 0x1000, 0x1000, 0x7f40e4fa51d0, 0x60, 0x0)
	/usr/lib/go-1.15/src/net/http/transport.go:1894 +0x77
bufio.(*Reader).fill(0xc00010e4e0)
	/usr/lib/go-1.15/src/bufio/bufio.go:101 +0x105
bufio.(*Reader).Peek(0xc00010e4e0, 0x1, 0xc00008a900, 0x0, 0x0, 0xc000057530, 0x7f40e4fad2b0)
	/usr/lib/go-1.15/src/bufio/bufio.go:139 +0x51
net/http.(*persistConn).readLoop(0xc00012a000)
	/usr/lib/go-1.15/src/net/http/transport.go:2047 +0x1aa
created by net/http.(*Transport).dialConn
	/usr/lib/go-1.15/src/net/http/transport.go:1715 +0xcb7
[11:07:06] INFO: Successfully send service information to the Supervisor.
[09:07:06] INFO: Service restart after closing

In the log of Zigbee2MQTT:

Zigbee2MQTT:error 2024-04-04 11:16:25: MQTT error: connect ECONNREFUSED 172.30.33.0:1883

Note : Solved after remove and reinstall the Mosquito Add-On.

1 Like

Too much labels already?


Trying to set labels for automations, I cannot reach the first ones, it’s like I cannot scroll the labels list, it’s fixed and not all labels fits.

If I need a bigger smartphone just tell me, will do! :sweat_smile:

Update: I created an issue and it’s already fixed; Cannot scroll labels panel when adding them to automations · Issue #20413 · home-assistant/frontend · GitHub

2 Likes

Great work, already looks so much better with the categories and labels and makes finding things significantly easier. Hopefully a future release adds collapsable categories in the automation editor!

1 Like

Hi all,

In case someone is using downloader setup on configuration.yaml, and most probably are having a hard time trying to set the downloader integration in the UI, always getting back the “unknown error” message:

Just take note of the dir you are currently using in the yaml file, delete those lines pertaining to downloader, save, restart, and now you’ll be able to setup the same dir in the UI without any issues.

At least it worked for me.

2 Likes

Dear friends, with netatmo station weather I loss all main sensors after reboot or restart h.a.: Main temperature, Main CO2, Main preassure, Main noise and main humidity. The external sensor and the secondary sensors works fine. Only main sensor problem, ( 5 not available sensors ) .

2 Likes

The sensors have appeared again after waiting 5 minutes after starting up. Indeed, first all the secondary sensors and the external one appear and around 5 minutes later the 5 main sensors appear

2 Likes

Hyper excited for the release. Great work from the team, it’s amazing and I’d love 2024 to be “Year of the UX”, as it’s going sooo great so far.

I’ve started playing around with labels a bit and I’m really curious how others are approaching it. Especially I have detected a potential conflict with “label all the things” philosophy.

Since labels are great to use as targets, they make a ton of sense to be used on Entities.

However, if you use the same labels as a categorization tool on devices, helpers, automations and scripts, what will happen when using the label as target? It will prob make everything run, which is rarely desired.

Which brings me to the conclusion to either use separate types of labels for each type of element (which would bring us back to labels being named [Auto] Lights, [Script] Lights, etc) or alternatively (and I think better) just stick to labels for Entities, and use exclusively Categories for everything else.

What do you guys think?

3 Likes

It seems that only Homematic climate devices are missing.

1 Like

Labels:

  1. Manage labels in UI: add/remove/change.
  2. Assign labels to entities (do not know about other objects) in UI.
  3. Use labels to select entities in templates.
  4. Use labels to select entities in UI tables.

In some limited extent this functionality was (and still is) available before 2024.4:

  1. Add attributes like “label: xmas” to an entity (YAML):
    – either explicitly - for template (binary_)sensors;
    – or via “customize”.
  2. Filter list of entities in “Dev tools → State” by this “label: xmas”.
  3. Select entities in templates by “selectattr('attributes.label','defined') | selectattr('attributes.label','eq','xmas')”.

(also, these string labels occupied space in “attributes_id” DB table).

1 Like

I was hoping that Labels would provide a shortcut to be able to easily bring up “all things of the same type” in a History graph.

For example, I’ve given all my Sensor batteries the same label, and if I go into the History view and just select that label, I get nothing displayed. So I suppose it’s acting just as a filter, rather than a source ? That’s a little bit unclear from the UI at least.

1 Like

It looks like its fixed in 2024.4.1

Thank you for the info.

I just switched to the custom_homematic integration.
It makes a lot of things easier.

1 Like

On the other hand, If one look at it “the other way around”
You “mark/group” i.e devices/automations etc. with “A Label” The label can be Area/Zone/ & now “Label”, which make “Label” kind of versatile , because you can use it for what ever purpose you find suitable, to Group Devices etc. "

Labels is an organizational structure that is completely up to you.

I can come up with dozen of “Labels” which in fact are Location/Grouping
Ceiling ( Individual rooms, or All ), Door locks/sensors(widely spread, thou grouped ), Left / Right. Etc.

It’s not an issue. All things users can name act like this. Devices (device_id), Areas (area_id), Entity (entity_id), and now Labels (label_id). I’m not sure why this is now a problem for you. Without an ID in the background, it can’t be linked to other items. Otherwise if you change the name, the link would break. Then you’d be here saying “I labeled everything, changed the name, and how I have to relabel everything!”.

Heck, there’s a long standing Feature Requests and Month of "What the heck?!" about renaming entity_id’s auto updating in automations. You want this to also be a problem with labels too?

There’s a bug in the current version with floors & labels in the history tab. Expected fix is for 2024.4.1.

1 Like