| 1 Dec 2024 |
 K900 | And everything is a queue | 17:48:45 |
| K900 | Even though very few things actually are | 17:48:55 |
 hexa | What would be the better alternative? | 17:49:17 |
| hexa | e.g. CoAP is maybe 10 years old now | 17:49:49 |
| K900 | Some reasonable-ish RPC protocol, probably | 17:49:52 |
| K900 | I don't think there's anything out there that would be a good fit for all the use cases | 17:50:14 |
| K900 | Which probably means there should be more than one protocol | 17:50:35 |
| hexa | ah cool, they start using pnpm with z2m 2.0 | 17:55:03 |
 freewalkr | 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 | 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 | what are the permissions when it reconnects? | 20:34:17 |
| hexa | is it still owned by hass:hass? | 20:34:25 |
| freewalkr | 600 hass:hass | 20:34:27 |
| hexa | 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 | but that just shifts things around, not sure it would meaningfully change anything | 20:35:57 |
| freewalkr | well the symlink is 777 of course, but the device it points to is 600 hass:hass | 20:36:07 |
| hexa | the hass user/group are statically allocated, so I wouldn't expect anything weird to happen | 20:38:23 |
| freewalkr | should i use group jablotron as udev group? | 20:38:52 |
| freewalkr | * should i use group jablotron as udev rule group? | 20:39:03 |
| freewalkr | * should i use group jablotron as udev rule GROUP? | 20:39:13 |
| hexa | that is what I would do | 20:39:13 |
| hexa | root/jablotron | 20:39:19 |
| hexa | then 660 | 20:39:23 |
| hexa | and group membership delegates access to the device | 20:39:37 |
| freewalkr | well it didn't fix the problem
i guess it maybe something like integration keeps reading from dead file descriptor or something | 20:49:36 |
| freewalkr | * well it didn't fix the problem
i guess it may be something like integration keeps reading from dead file descriptor or something | 20:49:46 |
| hexa | yeah, plausible | 20:49:47 |
| hexa | best to talk to the componentn maintainer | 20:50:08 |
| hexa | on permission error, try to reopen the device | 20:50:42 |
| freewalkr | retard move (at least it works for now)
services.udev.extraRules =
''ACTION=="add", KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ''
+ ''ATTRS{idVendor}=="16d6", ATTRS{idProduct}=="0008", ''
+ ''MODE="0660", OWNER="hass", GROUP="hass", SYMLINK+="jablotron", ''
+ ''RUN+="/bin/sh -c 'systemctl restart home-assistant.service'"''
| 21:32:56 |
