!QhvgabMQzwEQeWehhZ:lossy.network

NixOS Home Automation

511 Members
Declarative Home Automation and other Sidequests | https://wiki.nixos.org/wiki/Home_Assistant133 Servers

Load older messages


SenderMessageTime
1 Dec 2024
@freewalkr:fwkrr.rufreewalkr joined the room.15:30:21
@freewalkr:fwkrr.rufreewalkr hi everyone!
to = "on"; in my nix automation trigger config gets converted into to: on yaml config
home assistant interprets this as to: true and throws an error expected str for dictionary value @ data['to']
is this a known issue? has anyone solved it?
15:33:09
@freewalkr:fwkrr.rufreewalkr i see the same line in example config given in wiki page
should it even work?
15:35:05
@k900:0upti.meK900This is a YAML 1.2 thing I think?15:40:34
@k900:0upti.meK900 @hexa did that ever get fixed 15:40:38
@hexa:lossy.network@hexa:lossy.networkI rolled that back to 1.1 a while ago15:41:54
@hexa:lossy.network@hexa:lossy.networkzigbee2mqtt 2.0 is going to hit early january 2025 with breaking changes17:40:41
@hexa:lossy.network@hexa:lossy.networkhttps://github.com/Koenkk/zigbee2mqtt/discussions/2419817:40:43
@hexa:lossy.network@hexa:lossy.networkthere's stuff you can do to prepare today to not get hit hard 😄 17:40:52
@k900:0upti.meK900Honestly I still don't get how we ended up with MQTT as de facto standard RPC protocol for embedded things 17:45:54
@k900:0upti.meK900It's not even good at any of those things17:46:05
@hexa:lossy.network@hexa:lossy.networkeverything is a string 🥳17:48:10
@hexa:lossy.network@hexa:lossy.networkit is what was popular in early home automation tinkering setups17:48:40
@k900:0upti.meK900And everything is a queue 17:48:45
@k900:0upti.meK900Even though very few things actually are 17:48:55
@hexa:lossy.network@hexa:lossy.networkWhat would be the better alternative?17:49:17
@hexa:lossy.network@hexa:lossy.networke.g. CoAP is maybe 10 years old now17:49:49
@k900:0upti.meK900Some reasonable-ish RPC protocol, probably17:49:52
@k900:0upti.meK900I don't think there's anything out there that would be a good fit for all the use cases 17:50:14
@k900:0upti.meK900Which probably means there should be more than one protocol 17:50:35
@hexa:lossy.network@hexa:lossy.networkah cool, they start using pnpm with z2m 2.017:55:03
@freewalkr:fwkrr.rufreewalkr
In reply to @hexa:lossy.network
I rolled that back to 1.1 a while ago
i updated to latest nixpkgs-unstable and now it converts to yaml to: 'on'. thanks!
20:25:23
@freewalkr:fwkrr.rufreewalkr

one more problem, more general this time
maybe someone knows
i pass a usb device to hass via a symlink generated by udev rule:

services.udev.extraRules = ''ACTION=="add", KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="16d6", ATTRS{idProduct}=="0008", MODE="0600", OWNER="hass", GROUP="hass", SYMLINK+="jablotron"'';

then i allow it in systemd unit:

systemd.services.home-assistant.serviceConfig.DeviceAllow = "/dev/jablotron";

and everything works fine
but the device can randomly disconnect and connect back every once in a while
it is available on the symlink /dev/jablotron again (i checked with sudo -u hass cat /dev/jablotron - no access errors)
but home assistant won't have access to it: there are a lot of log lines:

2024-12-01 23:18:33.036 ERROR (ThreadPoolExecutor-2_1) [custom_components.jablotron100] Write error: [Errno 1] Operation not permitted: '/dev/jablotron'

restarting hass service helps, it works fine again until the next reconnect

is it an issue with an integration or it can be solved with systemd tuning?

20:33:07
@hexa:lossy.network@hexa:lossy.networkwhat are the permissions when it reconnects?20:34:17
@hexa:lossy.network@hexa:lossy.networkis it still owned by hass:hass?20:34:25
@freewalkr:fwkrr.rufreewalkr600 hass:hass20:34:27
@hexa:lossy.network@hexa:lossy.network what I would do is create a static group users.groups.jablotron = { } and add SupplementaryGroup = [ "jablotron " ] to the home-assistant unit 20:35:39
@hexa:lossy.network@hexa:lossy.networkbut that just shifts things around, not sure it would meaningfully change anything20:35:57
@freewalkr:fwkrr.rufreewalkrwell the symlink is 777 of course, but the device it points to is 600 hass:hass20:36:07
@hexa:lossy.network@hexa:lossy.networkthe hass user/group are statically allocated, so I wouldn't expect anything weird to happen20:38:23

Show newer messages


Back to Room ListRoom Version: 6