Code quality test

Adds a separate CI test for MATLAB linting errors using checkcode.
It also separates it from the remaining of the test suite, although I'm not sure that's done in the best possible way.

@dstansby This should be ready, if you're happy to review it.
I've also added another workflow for code linting, separated from the other tests, which needs your approval before being run the first time.

@dstansby Can I ask for an advice?
Not sure what's the best way to handle the conflicts here: shall I just rebase this into the main, or is there a better way to fix diverging branches than rewriting the history?

Rebasing (and resolve the conflicts) is fine, and what I usually do (mainly out of habit, but also to keep a linear git history. The other option is to take the current main branch and merge it into your branch (and resolve the conflicts). That won't re-write any of your previous commits, but instead create a new commit on top of them. I'd say do whichever you're more comfortable doing, as the result is the same 😃

Just thinking about this again, I think the best thing to do would be revert changes to the .m files which are conflicting, then you should be able to do a clean merge of main into this branch (and then probably one more commit to fix any linting issues I've introduced since you opened this PR 😉 )

Going to close and open to see if the unit tests will run properley


Scrubber throttling isn't working properly

Addresses lag issue on animation controls.

See https://github.com/ioam/holoviews/issues/2571

Now fixed.


Asuswrt: Stops working after some minutes

Home Assistant release (hass --version): 0.65.4
Python release (python3 --version): 3.5.3
Component/platform: asuswrt
Description of problem: RT-AC86U in Router mode. Works after a restart but after a couple of minutes it stops and doesn't track any device anymore, seems to be happening for some HA versions now.
Tried using telnet and ssh using username/password.
Also tried changing the timeout to 60 seconds.
Expected:
Disconnected devices tracked by HA should have their state updated at the next interval after the change is reflected in the router itself.
Problem-relevant configuration.yaml entries and steps to reproduce:
  - platform: asuswrt
    host: !secret router_host
    username: !secret router_username
    password: !secret router_password
    protocol: ssh
    interval_seconds: 60

Traceback (if applicable):
2018-03-20 12:37:16 INFO (Thread-16) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-03-20 12:37:46 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:46 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:37:47 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:38:17 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: assoclist XX:XX:XX:XX:XX:XX
2018-03-20 12:38:17 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: assoclist XX:XX:XX:XX:XX:XX
2018-03-20 12:38:17 DEBUG (Thread-16) [homeassistant.components.device_tracker.asuswrt] Could not parse row: assoclist XX:XX:XX:XX:XX:XX
2018-03-20 12:42:21 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-03-20 12:42:21 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-03-20 12:42:21 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-03-20 12:42:21 WARNING (MainThread) [homeassistant.components.device_tracker] Updating device list from asuswrt took longer than the scheduled scan interval 0:01:00

Additional info:

@kennedyshead I've seen you've already fixed some stuff around this plugin, is it possible to take a look at this, please? Thanks

@MagnusKnutas No problem, thanks for your help!
`
arp -n
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:57:9b:18:c7:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:c7:bf:30:d4:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:22:0b:a0:80:xx [ether]  on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:b4:30:34:d1:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:74:2e:ef:e3:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0d:b8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:d5:9d:4d:f1:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:04:4b:47:be:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:28:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:27:eb:f3:1e:xx [ether]  on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:43:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:9a:a9:4f:f8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:95:a2:19:01:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:80:39:41:f8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0b:18:xx [ether]  on br0
? (<IP_ADDRESS>) at   on eth0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:a4:be:d0:0b:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:08:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:af:96:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:60:09:8e:f9:xx [ether]  on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:b4:29:aa:0e:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:ea:34:e4:85:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:cd:bd:03:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:30:71:b8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:30:79:70:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:27:eb:0e:85:xx [ether]  on br0
? (<IP_ADDRESS>) at   on br0
? (<IP_ADDRESS>) at xx:d5:9d:48:81:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:1d:ec:0a:64:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:a8:c2:xx [ether]  on br0
ip neigh
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:57:9b:18:c7:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:c7:bf:30:d4:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:22:0b:a0:80:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:30:34:d1:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:74:2e:ef:e3:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0d:b8:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:d5:9d:4d:f1:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:04:4b:47:be:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:28:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:27:eb:f3:1e:xx STALE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:43:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:95:a2:19:01:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:80:39:41:f8:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0b:18:xx STALE
<IP_ADDRESS> dev eth0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:a4:be:d0:0b:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:08:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:af:96:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:60:09:8e:f9:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:29:aa:0e:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:ea:34:e4:85:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:cd:bd:03:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:30:71:b8:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:b4:30:79:70:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:27:eb:0e:85:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:d5:9d:48:81:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:1d:ec:0a:64:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:a8:c2:xx STALE
2a00:23c4:c093:ad00:7975:ecaf:7248:94ff dev br0  FAILED
fe80::b2d5:9dff:fe4d:f163 dev br0 lladdr xx:d5:9d:4d:f1:xx STALE
fe80::5625:eaff:fe80:173 dev br0 lladdr xx:25:ea:80:01:xx STALE
fe80::418a:2c81:8ead:f780 dev br0 lladdr xx:56:dc:98:01:xx STALE
2a00:23c4:c093:ad00:1ab4:30ff:fe79:70f5 dev br0  FAILED
2a00:23c4:c093:ad00:cc61:84f3:fa1:830a dev br0  FAILED
fe80::1ab4:30ff:fe79:70f5 dev br0 lladdr xx:b4:30:79:70:xx STALE
fe80::2d:4601:a9e9:c812 dev br0 lladdr xx:85:90:38:f9:xx STALE
2a00:23c4:c093:ad00:9d39:40d6:a89c:a3ba dev br0 lladdr xx:25:ea:80:01:xx STALE
2a00:23c4:c093:ad00:1842:ce42:8c06:9d8c dev br0  router FAILED
2a00:23c4:c093:ad00:a19c:d5d4:46d0:8cd8 dev br0  FAILED
2a00:23c4:c093:ad00:3dc3:ba68:b0b2:3b0d dev br0  FAILED
2a00:23c4:c093:ad00:3dcd:f1d4:d2c7:70c6 dev br0  FAILED
2a00:23c4:c093:ad00:3d0f:9bb4:a2fa:e4af dev br0  FAILED
2a00:23c4:c093:ad00:7ce4:ca16:9ace:1a0 dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
fe80::7ce4:ca16:9ace:1a0 dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
2a00:23c4:c093:ad00:a559:685d:55eb:59e1 dev br0  FAILED
2a00:23c4:c093:ad00:2199:4cad:8639:16fd dev br0  FAILED
fe80::7a45:61ff:fef7:d678 dev br0 lladdr xx:45:61:f7:d6:xx STALE
2a00:23c4:c093:ad00:257f:3280:c28:ff1a dev br0 lladdr xx:22:0b:a0:80:xx STALE
fe80::1a74:2eff:feef:e384 dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:e9f8:be56:9b84:9a88 dev br0  FAILED
2a00:23c4:c093:ad00:6d9d:a63e:fa92:b2d dev br0  FAILED
2a00:23c4:c093:ad00:f555:e8df:4050:d37a dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:51fb:83da:9aab:adff dev br0 lladdr xx:e0:4c:68:01:xx STALE
2a00:23c4:c093:ad00:1ab4:30ff:fe71:b860 dev br0  FAILED
2a00:23c4:c093:ad00:617d:76d7:b23e:6a4e dev br0  FAILED
fe80::1ab4:30ff:fe71:b860 dev br0  FAILED
fe80::1ab4:30ff:fe34:d1cb dev br0 lladdr xx:b4:30:34:d1:xx STALE
2a00:23c4:c093:ad00:91fc:310b:85fa:b982 dev br0  FAILED
fe80::424e:36ff:fe21:2ce3 dev br0 lladdr xx:4e:36:21:2c:xx STALE
2a00:23c4:c093:ad00:1cad:8a0d:27c5:eefd dev br0  FAILED
2a00:23c4:c093:ad00:6c6c:10c1:833c:4a46 dev br0  FAILED
2a00:23c4:c093:ad00:f5b4:e8c9:77c9:5f64 dev br0  FAILED
2a00:23c4:c093:ad00:19e8:45c3:6215:a351 dev br0 lladdr xx:60:09:8e:f9:xx REACHABLE
fd29:3876:ca10:1:1ab4:30ff:fe79:70f5 dev br0 lladdr xx:b4:30:79:70:xx STALE
fe80::42b4:cdff:febd:304 dev br0 lladdr xx:b4:cd:bd:03:xx STALE
fe80::21d:ecff:fe0a:641c dev br0 lladdr xx:1d:ec:0a:64:xx STALE
2a00:23c4:c093:ad00:411e:97c2:ffa5:1ce8 dev br0  FAILED
fd29:3876:ca10:1:a169:9a9f:3200:3afb dev br0 lladdr xx:04:4b:47:be:xx STALE
2a00:23c4:c093:ad00:b042:3ac0:41d9:8020 dev br0  FAILED
2a00:23c4:c093:ad00:e56e:fa26:7c4:3602 dev br0 lladdr xx:56:dc:98:01:xx STALE
2a00:23c4:c093:ad00:7c0c:7aeb:97f6:adf7 dev br0  FAILED
fe80::8ee2:d9e7:aded:13e6 dev br0 lladdr xx:27:eb:f3:1e:xx STALE
2a00:23c4:c093:ad00:48be:d009:3251:d7dc dev br0  FAILED
2a00:23c4:c093:ad00:c5f8:190c:affd:93d6 dev br0 lladdr xx:27:eb:0e:85:xx STALE
fd09:b44:fa06:1:1ab4:30ff:fe71:b860 dev br0  FAILED
2a00:23c4:c093:ad00:f4a6:40ce:5001:a427 dev br0  FAILED
2a00:23c4:c093:ad00:35e8:420e:38a:c6cb dev br0  FAILED
2a00:23c4:c093:ad00:a44d:7466:2592:e8cf dev br0 lladdr xx:27:eb:f3:1e:xx STALE
fe80::cfe:4184:4c7f:4e1e dev br0  FAILED
2a00:23c4:c093:ad00:5df7:ac3b:8ba4:20ca dev br0  FAILED
fe80::ae22:bff:fea0:807a dev br0 lladdr xx:22:0b:a0:80:xx STALE
2a00:23c4:c093:ad00:6481:218a:7b5f:dbff dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:3014:58c6:1252:fc6b dev br0  router FAILED
2a00:23c4:c093:ad00:9157:20e9:2289:4b0e dev br0  FAILED
fe80::204:4bff:fe47:be6b dev br0 lladdr xx:04:4b:47:be:xx STALE
fe80::b26e:bfff:fe62:74f0 dev br0 lladdr xx:6e:bf:62:74:xx router STALE
2a00:23c4:c093:ad00:1497:c33f:c0b8:530f dev br0  FAILED
fe80::157d:5caf:af71:1bf4 dev br0 lladdr xx:27:eb:0e:85:xx STALE
2a00:23c4:c093:ad00:b2d5:9dff:fe48:81b2 dev br0 lladdr xx:d5:9d:48:81:xx STALE
fe80::b2d5:9dff:fe48:81b2 dev br0 lladdr xx:d5:9d:48:81:xx STALE
fe80::9665:2dff:fe71:591f dev br0 lladdr xx:65:2d:71:59:xx router STALE
fe80::5660:9ff:fe8e:f962 dev br0 lladdr xx:60:09:8e:f9:xx STALE
cat /var/lib/misc/dnsmasq.leases
83296 xx:a4:be:d0:0b:xx <IP_ADDRESS> * xx:10:a4:be:d0:0b:xx
28480 xx:d5:9d:4d:f1:xx <IP_ADDRESS>  xx:b0:d5:9d:4d:f1:xx
83469 xx:ea:34:e4:85:xx <IP_ADDRESS>  *
48992 xx:b4:29:aa:0e:xx <IP_ADDRESS>  *
49060 xx:b4:29:0e:28:xx <IP_ADDRESS>  *
83534 xx:57:9b:18:c7:xx <IP_ADDRESS>  xx:9b:18:c7:1c:00:01:00:01:1c:37:50:49:8c:57:9b:18:c7:xx
77422 xx:74:2e:ef:e3:xx <IP_ADDRESS>  *
49046 xx:b4:29:0e:08:xx <IP_ADDRESS>  *
49067 xx:b4:29:0e:43:xx <IP_ADDRESS>  *
49066 xx:b4:29:0b:18:xx <IP_ADDRESS>  *
76389 xx:b4:29:a8:c2:xx <IP_ADDRESS>  *
47669 xx:b4:30:71:b8:xx <IP_ADDRESS>  xx:18:b4:30:71:b8:xx
46989 xx:22:0b:a0:80:xx <IP_ADDRESS>  xx:ac:22:0b:a0:80:xx
45792 xx:b4:cd:bd:03:xx <IP_ADDRESS>  *
71125 xx:b4:29:af:96:xx <IP_ADDRESS>  *
49061 xx:b4:29:0d:b8:xx <IP_ADDRESS>  *
83552 xx:c7:bf:30:d4:xx <IP_ADDRESS>  xx:50:c7:bf:30:d4:xx
66785 xx:60:09:8e:f9:xx <IP_ADDRESS>  *
53332 xx:85:90:38:f9:xx <IP_ADDRESS>  xx:8c:85:90:38:f9:xx
61148 xx:b4:30:34:d1:xx <IP_ADDRESS> * *
48877 xx:65:2d:71:59:xx <IP_ADDRESS>  xx:94:65:2d:71:59:xx
49232 xx:b4:30:79:70:xx <IP_ADDRESS>  xx:18:b4:30:79:70:xx
15205 xx:80:39:41:f8:xx <IP_ADDRESS> * *
86400 xx:27:eb:f3:1e:xx <IP_ADDRESS>  xx:b8:27:eb:f3:1e:xx
60620 xx:25:ea:80:01:xx <IP_ADDRESS> * xx:54:25:ea:80:01:xx
48595 xx:4e:36:21:2c:xx <IP_ADDRESS> * xx:40:4e:36:21:2c:xx
55324 xx:9a:a9:4f:f8:xx <IP_ADDRESS>  xx:94:9a:a9:4f:f8:xx
60731 xx:27:eb:0e:85:xx <IP_ADDRESS> * xx:b8:27:eb:0e:85:xx
81937 xx:04:4b:47:be:xx <IP_ADDRESS>  xx:00:04:4b:47:be:xx
84191 xx:1d:ec:0a:64:xx <IP_ADDRESS>  xx:00:1d:ec:0a:64:xx
44061 xx:95:a2:19:01:xx <IP_ADDRESS> * *
48324 xx:45:61:f7:d6:xx <IP_ADDRESS> * xx:78:45:61:f7:d6:xx
27606 xx:56:dc:98:01:xx <IP_ADDRESS>  xx:2c:56:dc:98:01:xx
86166 xx:d5:9d:48:81:xx <IP_ADDRESS>  xx:b0:d5:9d:48:81:xx
duid xx:03:00:01:4e:75:b1:ba:3d:xx
`
Regards,

@MagnusKnutas No problem, thanks for your help!
**arp -n**
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:57:9b:18:c7:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:c7:bf:30:d4:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:22:0b:a0:80:xx [ether]  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:b4:30:34:d1:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:74:2e:ef:e3:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0d:b8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:d5:9d:4d:f1:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:04:4b:47:be:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:28:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:27:eb:f3:1e:xx [ether]  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:43:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:9a:a9:4f:f8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:95:a2:19:01:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:80:39:41:f8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0b:18:xx [ether]  on br0
? (<IP_ADDRESS>) at <incomplete>  on eth0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:a4:be:d0:0b:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:0e:08:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:af:96:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:60:09:8e:f9:xx [ether]  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:b4:29:aa:0e:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:ea:34:e4:85:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:cd:bd:03:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:30:71:b8:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:30:79:70:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:27:eb:0e:85:xx [ether]  on br0
? (<IP_ADDRESS>) at <incomplete>  on br0
? (<IP_ADDRESS>) at xx:d5:9d:48:81:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:1d:ec:0a:64:xx [ether]  on br0
? (<IP_ADDRESS>) at xx:b4:29:a8:c2:xx [ether]  on br0

**ip neigh**
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:57:9b:18:c7:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:c7:bf:30:d4:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:22:0b:a0:80:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:30:34:d1:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:74:2e:ef:e3:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0d:b8:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:d5:9d:4d:f1:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:04:4b:47:be:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:28:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:27:eb:f3:1e:xx STALE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:43:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:95:a2:19:01:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:80:39:41:f8:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0b:18:xx STALE
<IP_ADDRESS> dev eth0  FAILED
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:a4:be:d0:0b:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:0e:08:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:af:96:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:60:09:8e:f9:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:b4:29:aa:0e:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:ea:34:e4:85:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:cd:bd:03:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:30:71:b8:xx STALE
<IP_ADDRESS> dev br0 lladdr xx:b4:30:79:70:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:27:eb:0e:85:xx REACHABLE
<IP_ADDRESS> dev br0  FAILED
<IP_ADDRESS> dev br0 lladdr xx:d5:9d:48:81:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:1d:ec:0a:64:xx REACHABLE
<IP_ADDRESS> dev br0 lladdr xx:b4:29:a8:c2:xx STALE
2a00:23c4:c093:ad00:7975:ecaf:7248:94ff dev br0  FAILED
fe80::b2d5:9dff:fe4d:f163 dev br0 lladdr xx:d5:9d:4d:f1:xx STALE
fe80::5625:eaff:fe80:173 dev br0 lladdr xx:25:ea:80:01:xx STALE
fe80::418a:2c81:8ead:f780 dev br0 lladdr xx:56:dc:98:01:xx STALE
2a00:23c4:c093:ad00:1ab4:30ff:fe79:70f5 dev br0  FAILED
2a00:23c4:c093:ad00:cc61:84f3:fa1:830a dev br0  FAILED
fe80::1ab4:30ff:fe79:70f5 dev br0 lladdr xx:b4:30:79:70:xx STALE
fe80::2d:4601:a9e9:c812 dev br0 lladdr xx:85:90:38:f9:xx STALE
2a00:23c4:c093:ad00:9d39:40d6:a89c:a3ba dev br0 lladdr xx:25:ea:80:01:xx STALE
2a00:23c4:c093:ad00:1842:ce42:8c06:9d8c dev br0  router FAILED
2a00:23c4:c093:ad00:a19c:d5d4:46d0:8cd8 dev br0  FAILED
2a00:23c4:c093:ad00:3dc3:ba68:b0b2:3b0d dev br0  FAILED
2a00:23c4:c093:ad00:3dcd:f1d4:d2c7:70c6 dev br0  FAILED
2a00:23c4:c093:ad00:3d0f:9bb4:a2fa:e4af dev br0  FAILED
2a00:23c4:c093:ad00:7ce4:ca16:9ace:1a0 dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
fe80::7ce4:ca16:9ace:1a0 dev br0 lladdr xx:9a:a9:4f:f8:xx STALE
2a00:23c4:c093:ad00:a559:685d:55eb:59e1 dev br0  FAILED
2a00:23c4:c093:ad00:2199:4cad:8639:16fd dev br0  FAILED
fe80::7a45:61ff:fef7:d678 dev br0 lladdr xx:45:61:f7:d6:xx STALE
2a00:23c4:c093:ad00:257f:3280:c28:ff1a dev br0 lladdr xx:22:0b:a0:80:xx STALE
fe80::1a74:2eff:feef:e384 dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:e9f8:be56:9b84:9a88 dev br0  FAILED
2a00:23c4:c093:ad00:6d9d:a63e:fa92:b2d dev br0  FAILED
2a00:23c4:c093:ad00:f555:e8df:4050:d37a dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:51fb:83da:9aab:adff dev br0 lladdr xx:e0:4c:68:01:xx STALE
2a00:23c4:c093:ad00:1ab4:30ff:fe71:b860 dev br0  FAILED
2a00:23c4:c093:ad00:617d:76d7:b23e:6a4e dev br0  FAILED
fe80::1ab4:30ff:fe71:b860 dev br0  FAILED
fe80::1ab4:30ff:fe34:d1cb dev br0 lladdr xx:b4:30:34:d1:xx STALE
2a00:23c4:c093:ad00:91fc:310b:85fa:b982 dev br0  FAILED
fe80::424e:36ff:fe21:2ce3 dev br0 lladdr xx:4e:36:21:2c:xx STALE
2a00:23c4:c093:ad00:1cad:8a0d:27c5:eefd dev br0  FAILED
2a00:23c4:c093:ad00:6c6c:10c1:833c:4a46 dev br0  FAILED
2a00:23c4:c093:ad00:f5b4:e8c9:77c9:5f64 dev br0  FAILED
2a00:23c4:c093:ad00:19e8:45c3:6215:a351 dev br0 lladdr xx:60:09:8e:f9:xx REACHABLE
fd29:3876:ca10:1:1ab4:30ff:fe79:70f5 dev br0 lladdr xx:b4:30:79:70:xx STALE
fe80::42b4:cdff:febd:304 dev br0 lladdr xx:b4:cd:bd:03:xx STALE
fe80::21d:ecff:fe0a:641c dev br0 lladdr xx:1d:ec:0a:64:xx STALE
2a00:23c4:c093:ad00:411e:97c2:ffa5:1ce8 dev br0  FAILED
fd29:3876:ca10:1:a169:9a9f:3200:3afb dev br0 lladdr xx:04:4b:47:be:xx STALE
2a00:23c4:c093:ad00:b042:3ac0:41d9:8020 dev br0  FAILED
2a00:23c4:c093:ad00:e56e:fa26:7c4:3602 dev br0 lladdr xx:56:dc:98:01:xx STALE
2a00:23c4:c093:ad00:7c0c:7aeb:97f6:adf7 dev br0  FAILED
fe80::8ee2:d9e7:aded:13e6 dev br0 lladdr xx:27:eb:f3:1e:xx STALE
2a00:23c4:c093:ad00:48be:d009:3251:d7dc dev br0  FAILED
2a00:23c4:c093:ad00:c5f8:190c:affd:93d6 dev br0 lladdr xx:27:eb:0e:85:xx STALE
fd09:b44:fa06:1:1ab4:30ff:fe71:b860 dev br0  FAILED
2a00:23c4:c093:ad00:f4a6:40ce:5001:a427 dev br0  FAILED
2a00:23c4:c093:ad00:35e8:420e:38a:c6cb dev br0  FAILED
2a00:23c4:c093:ad00:a44d:7466:2592:e8cf dev br0 lladdr xx:27:eb:f3:1e:xx STALE
fe80::cfe:4184:4c7f:4e1e dev br0  FAILED
2a00:23c4:c093:ad00:5df7:ac3b:8ba4:20ca dev br0  FAILED
fe80::ae22:bff:fea0:807a dev br0 lladdr xx:22:0b:a0:80:xx STALE
2a00:23c4:c093:ad00:6481:218a:7b5f:dbff dev br0 lladdr xx:74:2e:ef:e3:xx STALE
2a00:23c4:c093:ad00:3014:58c6:1252:fc6b dev br0  router FAILED
2a00:23c4:c093:ad00:9157:20e9:2289:4b0e dev br0  FAILED
fe80::204:4bff:fe47:be6b dev br0 lladdr xx:04:4b:47:be:xx STALE
fe80::b26e:bfff:fe62:74f0 dev br0 lladdr xx:6e:bf:62:74:xx router STALE
2a00:23c4:c093:ad00:1497:c33f:c0b8:530f dev br0  FAILED
fe80::157d:5caf:af71:1bf4 dev br0 lladdr xx:27:eb:0e:85:xx STALE
2a00:23c4:c093:ad00:b2d5:9dff:fe48:81b2 dev br0 lladdr xx:d5:9d:48:81:xx STALE
fe80::b2d5:9dff:fe48:81b2 dev br0 lladdr xx:d5:9d:48:81:xx STALE
fe80::9665:2dff:fe71:591f dev br0 lladdr xx:65:2d:71:59:xx router STALE
fe80::5660:9ff:fe8e:f962 dev br0 lladdr xx:60:09:8e:f9:xx STALE

**cat /var/lib/misc/dnsmasq.leases**
83296 xx:a4:be:d0:0b:xx <IP_ADDRESS> * xx:10:a4:be:d0:0b:xx
28480 xx:d5:9d:4d:f1:xx <IP_ADDRESS> <name> xx:b0:d5:9d:4d:f1:xx
83469 xx:ea:34:e4:85:xx <IP_ADDRESS> <name> *
48992 xx:b4:29:aa:0e:xx <IP_ADDRESS> <name> *
49060 xx:b4:29:0e:28:xx <IP_ADDRESS> <name> *
83534 xx:57:9b:18:c7:xx <IP_ADDRESS> <name> xx:9b:18:c7:1c:00:01:00:01:1c:37:50:49:8c:57:9b:18:c7:xx
77422 xx:74:2e:ef:e3:xx <IP_ADDRESS> <name> *
49046 xx:b4:29:0e:08:xx <IP_ADDRESS> <name> *
49067 xx:b4:29:0e:43:xx <IP_ADDRESS> <name> *
49066 xx:b4:29:0b:18:xx <IP_ADDRESS> <name> *
76389 xx:b4:29:a8:c2:xx <IP_ADDRESS> <name> *
47669 xx:b4:30:71:b8:xx <IP_ADDRESS> <name> xx:18:b4:30:71:b8:xx
46989 xx:22:0b:a0:80:xx <IP_ADDRESS> <name> xx:ac:22:0b:a0:80:xx
45792 xx:b4:cd:bd:03:xx <IP_ADDRESS> <name> *
71125 xx:b4:29:af:96:xx <IP_ADDRESS> <name> *
49061 xx:b4:29:0d:b8:xx <IP_ADDRESS> <name> *
83552 xx:c7:bf:30:d4:xx <IP_ADDRESS> <name> xx:50:c7:bf:30:d4:xx
66785 xx:60:09:8e:f9:xx <IP_ADDRESS> <name> *
53332 xx:85:90:38:f9:xx <IP_ADDRESS> <name> xx:8c:85:90:38:f9:xx
61148 xx:b4:30:34:d1:xx <IP_ADDRESS> * *
48877 xx:65:2d:71:59:xx <IP_ADDRESS> <name> xx:94:65:2d:71:59:xx
49232 xx:b4:30:79:70:xx <IP_ADDRESS> <name> xx:18:b4:30:79:70:xx
15205 xx:80:39:41:f8:xx <IP_ADDRESS> * *
86400 xx:27:eb:f3:1e:xx <IP_ADDRESS> <name> xx:b8:27:eb:f3:1e:xx
60620 xx:25:ea:80:01:xx <IP_ADDRESS> * xx:54:25:ea:80:01:xx
48595 xx:4e:36:21:2c:xx <IP_ADDRESS> * xx:40:4e:36:21:2c:xx
55324 xx:9a:a9:4f:f8:xx <IP_ADDRESS> <name> xx:94:9a:a9:4f:f8:xx
60731 xx:27:eb:0e:85:xx <IP_ADDRESS> * xx:b8:27:eb:0e:85:xx
81937 xx:04:4b:47:be:xx <IP_ADDRESS> <name> xx:00:04:4b:47:be:xx
84191 xx:1d:ec:0a:64:xx <IP_ADDRESS> <name> xx:00:1d:ec:0a:64:xx
44061 xx:95:a2:19:01:xx <IP_ADDRESS> * *
48324 xx:45:61:f7:d6:xx <IP_ADDRESS> * xx:78:45:61:f7:d6:xx
27606 xx:56:dc:98:01:xx <IP_ADDRESS> <name> xx:2c:56:dc:98:01:xx
86166 xx:d5:9d:48:81:xx <IP_ADDRESS> <name> xx:b0:d5:9d:48:81:xx
duid xx:03:00:01:4e:75:b1:ba:3d:xx

Regards,

Ok... all the "Could not parse row ***" is actually nothing to worry about, there is an atampt to parse the command sent to router (not great but it does not break anything). This is where the fault is I think: "Could not parse row: assoclist XX:XX:XX:XX:XX:XX"
Problem is that in the commandlogs you sent me there is no lines with this, did it actually not work when you ran the commands?

Oh! I missed one command that you have to run on the router:
for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done

Seems fine, gives me a list of the "assoclist "
From the list of errors, it seems the component loops through all those commands and that's when it goes nuts?
Shouldn't the component wait for a response before going to another command? Does it need to repeat them that much in less than 12 seconds?
2018-04-09 15:20:56 INFO (Thread-13) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-04-09 15:21:09 WARNING (MainThread) [homeassistant.components.device_tracker] Updating device list from asuswrt took longer than the scheduled scan interval 0:00:12
2018-04-09 15:21:22 WARNING (MainThread) [homeassistant.components.device_tracker] Updating device list from asuswrt took longer than the scheduled scan interval 0:00:12
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: arp -n
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ip neigh
2018-04-09 15:21:26 DEBUG (Thread-13) [homeassistant.components.device_tracker.asuswrt] Could not parse row: cat /var/lib/misc/dnsmasq.leases
2018-04-09 15:21:35 WARNING (MainThread) [homeassistant.components.device_tracker] Updating device list from asuswrt took longer than the scheduled scan interval 0:00:12

Oh... well it should parse the assoc row but the loop is worse yes.
I dont get what's wrong, it queues a lot of jobs at once it should anly run the commands one time everytime _update_info is called???

When it's working I get this:
2018-04-09 16:00:13 INFO (Thread-9) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on eth0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-09 16:00:13 DEBUG (Thread-9) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0

And after ~3 hours it stops again and I start getting the weird loops.

Another weird thing I've noticed is that when I restart it to make it work again it does authenticate 2 times in a row:
Apr 11 14:40:29 dropbear[7690]: Pubkey auth succeeded for 'xxxxxxxx' with key sha1!! xx:aa:88:1b:5e:ef:xx:80:xx:59:xx:66:xx:08:xx:d8:xx:76:xx:82 from 192.168.1.xx:58944
Other thing is that when it's working it's always giving this errors:
2018-04-11 14:41:22 INFO (Thread-17) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on eth0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on eth0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0
2018-04-11 14:41:23 DEBUG (Thread-17) [homeassistant.components.device_tracker.asuswrt] Could not parse row: ? (<IP_ADDRESS>) at <incomplete>  on br0

Looking at the error it prints the actual command and it should be printing the line:
    for line in lines:
        match = regex.search(line)
        if not match:
            _LOGGER.debug("Could not parse row: %s", line)

So it's printing the command instead the line.
I think there's a bug in line 286:
lines = self._ssh.before.split(b'\n')[1:-1]
I don't know python, can anyone help please?

I am pretty sure its not related, this  would be an optimisation and not fix the bug.

Looking at my router logs, HA re-connected 2 times in the last 10 hours after I've added that patch, it's not ideal but it seems to be working.
Any idea how can I debug the ssh connection when it happens?
Thanks

Hm… I think I might be able to solve it then.
Ill look in to this after work ;)

On 18 Apr 2018, at 11:28, joaoasilva<EMAIL_ADDRESS>wrote:
Looking at my router logs, HA re-connected 2 times in the last 10 hours after I've added that patch, it's not ideal but it seems to be working.
Any idea how can I debug the ssh connection when it happens?
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/13351#issuecomment-382324725, or mute the thread https://github.com/notifications/unsubscribe-auth/AELD0-CB9shVqgX9syuHOKUr8BAxcWmPks5tpwdEgaJpZM4Sx8Zl.

Problem still exists in 0.68.  Also, seems to be the same issue as one I opened (13723)

Can confirm problem still exists in 0.71.0

I've created a patch that's been working fine for me for this couple of months. It just reconnects when it gets those weird errors: https://gist.github.com/joaoasilva/45f0c82c3f7ac33d670f49c86f9b102c.
This isn't a permanent fix as it can cause loop reconnections and I'm not a python dev so this is just a dirty fix that I got until someone that knows what he's doing creates a proper fix for the root problem.

I think the problem is that it opens multiple connections (not 100% sure)... I actually had this problem myself after I upgraded my router with new firmware after a router reset it went away.
Im on vacation for 5 weeks now :) and will look into this problem

Issues #13723 , #13351, and #10568 all seem to be related to the same problem.   I can confirm it still happens in 0.72.1 ... It's driving me crazy as my automations stop triggering and I need to delete my known_devices in order to get it working again.
Also, as this component has been broken for almost half a year, maybe a note on the documentation page that it doesn't work will help others from spending too much time troubleshooting this.

Guys, I have the issue as well. I believe it's related to ssh and how pxssh.pxssh() (in asuswrt.py) handles it. In my case even if I restart homeassistant the problem persists. As soon as I restart the ac86u router everything works for the next couple of minutes. Try to set the ssh session timeout on the router to 0 (Administration-System, idle timeout).


StatusBarHandler should not be in Lib

Errors that happen during Lib operations should propagate up, and the UI should handle them and add them to the statusbar.

Turns out this was fixed some time ago. . . oops.


Correction for raw affiliation Behavior and Welfare Group, Division of Farm Animal Health, Department of Population Health Sciences, Faculty of Veterinary Medicine, Utrecht University, Utrecht, Netherlands; Study Program Animal Health and Management, Aeres University of Applied Sciences, Dronten, Netherlands

Correction needed for raw affiliation Behavior and Welfare Group, Division of Farm Animal Health, Department of Population Health Sciences, Faculty of Veterinary Medicine, Utrecht University, Utrecht, Netherlands; Study Program Animal Health and Management, Aeres University of Applied Sciences, Dronten, Netherlands
raw_affiliation_name: Behavior and Welfare Group, Division of Farm Animal Health, Department of Population Health Sciences, Faculty of Veterinary Medicine, Utrecht University, Utrecht, Netherlands; Study Program Animal Health and Management, Aeres University of Applied Sciences, Dronten, Netherlands
new_rors: 04pp8hn57;03jnx2c74
previous_rors: 04pp8hn57;015d5s513
works_examples: W2911447385
contact: bec25c7d9fd7f639939c157bb3ba885b:64822a02216fa116369f @ hotmail.com

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


[Bug] SOCI snapshotter not working insecure container registry

Description
When using SOCI with an insecure container registry, SOCI fails to pull the container image. SOCI error logs are below:
{"error":"skipping mounting layer sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9 as FUSE mount: no ztoc for layer","key":"default/33/extract-128831236-kfhG sha256:781d5934416a582cf712c35212a8f92940c0223da02c1360d9ebb834d0f2c873","level":"warning","msg":"failed to prepare remote snapshot","parent":"sha256:9bb22d850b6e163c76b5cee00494067210e96c4cf585e2cd9d68898e31f43f69","remote-snapshot-prepared":"false","time":"2024-06-13T14:49:30.132049905Z"}
...
...
{"error":"cannot unpack the layer: cannot fetch layer: unable to fetch descriptor (sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9) from remote store: Get \"https://localhost:5000/v2/python/blobs/sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9\": context canceled","key":"default/33/extract-128831236-kfhG sha256:781d5934416a582cf712c35212a8f92940c0223da02c1360d9ebb834d0f2c873","level":"warning","msg":"failed to prepare snapshot; deferring to container runtime","parent":"sha256:9bb22d850b6e163c76b5cee00494067210e96c4cf585e2cd9d68898e31f43f69","time":"2024-06-13T14:49:30.363771421Z"}
...
...
{"error":"cannot unpack the layer: cannot fetch layer: unable to fetch descriptor (sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9) from remote store: Get \"https://localhost:5000/v2/python/blobs/sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9\": unknown \"unknown\": giving up request after 9 attempt(s): Get \"https://localhost:5000/v2/python/blobs/sha256:a99509a323905a80628005e4f3bc26ac15ebaf3ffdb08a9646a7f2d110ab38f9\": http: server gave HTTP response to HTTPS client","key":"default/34/extract-776892714-Ki3b sha256:781d5934416a582cf712c35212a8f92940c0223da02c1360d9ebb834d0f2c873","level":"warning","msg":"failed to prepare snapshot; deferring to container runtime","parent":"sha256:9bb22d850b6e163c76b5cee00494067210e96c4cf585e2cd9d68898e31f43f69","time":"2024-06-13T14:49:44.089475833Z"}

This is the configuration I'm using for the containerd client.
# /etc/containerd/config.toml

version = 2
[plugins."io.containerd.grpc.v1.cri".containerd]
    disable_snapshot_annotations = false
[proxy_plugins]
    [proxy_plugins.soci]
        type = "snapshot"
        address = "/run/soci-snapshotter-grpc/soci-snapshotter-grpc.sock"

Steps to reproduce the bug

nerdctl run -d -p 5000:5000 --restart=always --name registry registry:2.7
nerdctl pull registry.hub.docker.com/library/python:3.9
nerdctl image tag registry.hub.docker.com/library/python:3.9  localhost:5000/python:3.9
nerdctl --insecure-registry push --snapshotter soci localhost:5000/python:3.9
nerdctl rmi localhost:5000/python:3.9
nerdctl --insecure-registry pull --snapshotter soci localhost:5000/python:3.9
journalctl -u soci-snapshotter

Describe the results you expected
I expect the SOCI to work with the insecure registry like other snapshotters (eg: stargz).
Host information

OS: Ubuntu 20.04.3 LTS
Snapshotter Version: v0.6.1
Containerd Version: v1.7.16

Any additional context or information about the bug
No response

Related to #276.
This should allow plain http for localhost, but it doesn't seem to be working.
https://github.com/awslabs/soci-snapshotter/blob/145a4382bad97921bb72b08a8376d6276b58afbc/fs/fs.go#L211

Great! Thank you @Kern--!


Specify client-side service discovery on repository objects

There is currently a proposal on the table for adding a Link rel=”service” header, linking to a service discovery resource that enumerates, describes, and links to services exposed on a particular object.   The services on this list would be dynamically generated from registered extensions that match a given object based on provided selection criteria
SSWAP provides a mechanism by which clients can discover services/resources by submitting a resource query graph
For RDFSource resources, it may be possible/desirable to link to service URIs in the resource body, akin to adding “server managed triples” to its representation.

This is described in Service Discovery and Binding


Depth color JET range only shows dark/light blue

The color JET range in test.py is only showing dark/light blue.
The range needs to be changed for the JET display to show yellow, red, and green.

/cc @Luxonis-Brandon

I assume COLORMAP_HOT has a similar issue. I get pretty much just solid red for everything.

Thanks.  So I'm guessing there must be some range setting to calling this conversion that should help.  Looking now.

OK, yes, it's just a range thing.  So changing this line here to 4 * 65535 instaed of 65535 makes a fairly appropriate range for the BW1097 (the Pi Compute Module Edition, which has 9cm camera spacing).
Note that I've done some bending/etc. to my board (accidentally) so the calibration isn't as good as it could be.  But you can still see this is a bit more of an appropriate range for the 1097.  This probably is a terrible actual solution... but it gives a quantification of about how far off the current range is.

https://photos.app.goo.gl/4DKXoYhs3fVKbCQ16
https://photos.app.goo.gl/uuwubN95LKsRzZG27

Thoughts?

Interesting, thanks @Luxonis-Brandon . I had looked at that line a few times but convinced myself it was correct given the uint16 input. If I change that line to 2,3 or 4 * 65535 I do get more colorized depth info. However, it quickly drops to 2fps (but reports it as 46 fps) and fills the console with "data queue full errors". I'll play with that line to see if I can find a quicker way to convert the frame.

Got it.  So we recently added a functionality to make this not happen.  The reason it happens is the host gets overwhelmed and can't keep up with the frame output from the Myriad X.
So to solve that we implemented the capability to specify on the host side what the Myriad X should output in terms of FPS.  I don't know if this is in Master yet, however.  Let me look.

Not clear to me yet @chris-piekarski .  So here's the code I'm looking at:
https://github.com/luxonis/depthai-python-extras/blob/1703b69a736e4932d0dd2872648a4828f41cb3cd/test.py
# Make sure to put 'left' always first. Workaround for an issue to be investigated configs = {     'streams': [         'meta_d2h',         {'name': 'left', "max_fps": 5.0},         {'name': 'right', "max_fps": 5.0},         {'name': 'depth_sipp', "max_fps": 10.0},         'metaout',         {'name': 'previewout', "max_fps": 10.0},         # 'depth_color_h',     ],

And here's the commit:
https://github.com/luxonis/depthai-python-extras/pull/38/commits/1703b69a736e4932d0dd2872648a4828f41cb3cd
Need to run now but will look more into this soon.

Ah, yes, @GergelySzabolcs pointed out that this is in PR #38 https://github.com/luxonis/depthai-python-extras/pull/38
(Sorry I'm still a Git n00b, working to get better!)

Nice. I will try that PR now.

@chris-piekarski - test.py is hanging for me with the metaout/previewout streams, so I wouldn't be surprised if you run into issues. We're working those and will likely loop back here.

could only get the previewout stream to work for me on that PR @itsderek23. The depth stream options never show up and throw a != null assertion exception when I force close it. Same issue if I go back to the commit Brandon called out. I'll just wait until you say its stable :-)

Ah sorry Chris ... we'll loop back as we get #38 sorted out.
On Tue, Mar 3, 2020 at 3:07 PM Christopher Piekarski <
<EMAIL_ADDRESS>wrote:

could only get the previewout stream to work for me on that PR @itsderek23
https://github.com/itsderek23. The depth stream options never show up
and throw a != null assertion exception when I force close it. Same issue
if I go back to the commit Brandon called out. I'll just wait until you say
its stable :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/luxonis/depthai-python-extras/issues/39?email_source=notifications&email_token=AAAB5SB4GADHAC3GUDJ3BRLRFV5Q7A5CNFSM4LAL527KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENVLHJA#issuecomment-594195364,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAB5SCR7WEQK2E5WJVJ3JLRFV5Q7ANCNFSM4LAL527A
.

So the depth stream not working turned out to be a loose flex cable on the right camera @itsderek23.

Ah ... I ran into this one with a bad connection as well. Remind me again what model you are using @chris-piekarski?
PS - Added an issue to create a troubleshooting entry for this.

Yes, thanks @chris-piekarski - that's the main hardware issue we're seeing so far.  We're wondering if we need to stake the camera connection down on future units.  What happened to us is we would accidentally grab the board by that location, which would push the flex down and pop out the connector.  I caught myself doing it once.
And @itsderek23 I happen to know, @chris-piekarski has the BW1097 (RPi Compute Module Edition).

And @itsderek23 I happen to know, @chris-piekarski has the BW1097 (RPi Compute Module Edition).

Great. Noted in https://github.com/luxonis/depthai-docs-website/issues/29#issuecomment-595515886.

So as an update on this, using JET on disparity (instead of actual depth data) produces an better visualization.
So this can now be done using python3 test.py -s depth_color_h, which then uses the host to colorize the disparity.
The why of doing it this was is if the Myriad X colorizes the depth (it can, easily!) the data is sent as RGB so 3 bytes (24 bits) per pixel, so 2.7MB/frame or 82.9MB/s for 30FPS - which is QUITE a lot for say a Pi to visualize and is, more importantly, too much data for USB2 to handle (typically USB2 maxes out at ~30MB/s).
So with this depth_color_h option, disparity is sent directly, which is just a single byte, so 0.9MB/frame or 27MB/s for 30FPS, which is a LOT more manageable to say a Raspberry Pi to deal with.
Since the Pi still does struggle even w/ 27MB/s over USB, we added the capability to limit the framerate, which helps to prevent the Pi from getting overwhelmed.  Using 10FPS usually helps:
python3 test.py -s depth_color_h,10


Document the development and production workflows

How does one actually include FOAM in a project?
Why are the "releases" on NPM or Bower just dumps of the repo, not a handful of minified files a la Angular releases?
Building for production with foam.build.BuildApp, including documenting its various options and output.

I think we should still have built releases which make it easy to test / experiment with FOAM.  Just so long as we make it clear that for production they should use a BuildApp version, and that we provide instructions on how to do so.

Do you mean a release of a handful of minified files? Or a release in the sense that we have now, that this particular version of the whole repo is known to work well?


Add FadeInSmall classes

We already have classes like FadeInLeft and FadeInLeftBig but the shift is often too big.
Consider add some "Small" classes to just move the shift the item like 50px for a more subtle feel.

hmmm good idea... let me work on that ;) @mathisjay

#1009 could fix this too.

Let's keep the discussion on #1009 .


Add State Param in Configuration

Hi, I am migrating from react-oidc-context v3 to react-oidc v5.
The default value of state is undefined in v5 but our authentication service using Ory Hydra requires an valid state value.
I have tried adding state in extras prop but it is not working.
Could we get an option to set our own state value in the configuration provided to OidcProvider?

We first hit the route (http://localhost:3000) of our component wrapped in withOidcSecure
WrappedComponent:

Route:

As the user is not authenticated, it makes an auth request to our hydra auth server
v3 Auth Request:
https://spe-ms-hydra.apps.ocpsit.uat.dbs.com/oauth2/auth?client_id=1b39cecf-9d50-4ec0-8c8b-02ba58a4bc1f&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauthentication%2Fcallback&response_type=code&scope=openid offline_access http%3A%2F%2Flocalhost%3A8082 DRTS_SG_TRADER DRTS_SG_ENQUIRY DRTS_SGD_ACS_TRADER DRTS_SGD_SGMM_TRADER&state=f7fac9dd7bbd4f0dbf726ce4a3c6b488&code_challenge=pRv0Wr-0Zx_Zz71X8lw5lwoB9Ldt_h_tL76xUJ7LIrk&code_challenge_method=S256&response_mode=query

v5 Auth Request:
https://spe-ms-hydra.apps.ocpsit.uat.dbs.com/oauth2/auth?redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauthentication%2Fcallback&client_id=1b39cecf-9d50-4ec0-8c8b-02ba58a4bc1f&response_type=code&state=%2F&scope=openid offline_access http%3A%2F%2Flocalhost%3A8082 DRTS_SG_TRADER DRTS_SG_ENQUIRY DRTS_SGD_ACS_TRADER DRTS_SGD_SGMM_TRADER&code_challenge=G6W9zkezTft7QrxFJ55JakSNTH8syfscAYEBckaVGg0&code_challenge_method=S256

As the auth request does not meet the state value requirement of 8 characters length, it throws back an invalid_state error

We can work around the state value by passing a callback path param in withOidcSecure but it's not elegant as we will need to change the routing of our components

Thank you @zhien95 , i will try to make you à pull request on monday. I will add state value to paramaters that you will be able to set.

Thank you kind Sir @guillaume-chervet

I think the version 5.7.8 I just published may fix your issue.

Thanks @guillaume-chervet, it fits our use case.


Remove unnecessary exceptions

From @sohkai on September 27, 2016 10:21
Haven't double checked all of them, but a large number of the exceptions could be removed since they're BDB-specific.
Copied from original issue: bigchaindb/bigchaindb-common#23

From @sbellem on September 27, 2016 11:57
:+1:


[DNM] Toolchain testing

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.


Add Wheel of Robots

Could go into fastbin_dup_into_stack as well
Challenge is not available on Insomnihack github yet.

Thanks!


Minor updates

@vasily-kirichenko I added some logging to Generate references for FSI. Please try on your big solutions, we might find a clue why the feature doesn't work on certain solutions.

I will try to reproduce the bug with generating references on my solution tomorrow.

@vasily-kirichenko Have you got a relevant log for this?

I forget about this :( Will try to reproduce right now.

I reproduced it. I added a new reference to a project. Then build it. The output as follows:
[VFPT][Information 01:53:16 PM] Checking projects after build done...
[VFPT][Information 01:53:16 PM] Checking F# project 'p1'...
[VFPT][Information 01:53:16 PM] Checking F# project 'p2'...
[VFPT][Information 01:53:16 PM] Checking F# project 'p3'...
[VFPT][Information 01:53:16 PM] Checking F# project 'p4'...
[VFPT][Information 01:53:16 PM] Checking F# project 'p5'...
[VFPT][Information 01:53:16 PM] Checking F# project 'p6'...

Where p1..p6 are projects on which the project I'm building has references. Even if change a code in the project I build, VFPT does not check it.

Wait. Actually it checks completely unrelated projects. I mean only p1 is in refs of the project I build. Why does it check them?..

Build output is as follows:
========== Build: 0 succeeded, 0 failed, 3 up-to-date, 0 skipped ==========
So VS checked only 3 projects, VFPT - 6.

VFPT should check all F# projects in the solution, it doesn't know which projects have been built yet.
So do you mean that your current project is NOT a project from p1 to p6? That is weird.

Yes, it does not appear as checked.


Sen bot message with PHP

Does anyone know or have an example of sending a bot message with php to the groupme group?

I have one. As soon as I get home, I'll try and post it.

Thank you
Sent from my iPhone

On Mar 8, 2017, at 4:38 PM, Lenny Shirley<EMAIL_ADDRESS>wrote:
I have one. As soon as I get home, I'll try and post it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

$gm = new GroupMePHP\groupme();
$gm->bots->post(array(
    "bot_id" => "Bot ID from https://dev.groupme.com/bots/",
    "text" => "A test bot message"
));

It's a bit longer then necessary for consistency with the other endpoints. If you want your bot to have an avatar... It's the same thing but with a groupme image service url. So any url on the i.groupme.com host.
Example with avatar:
$gm = new GroupMePHP\groupme();
$gm->bots->post(array(
    "bot_id" => "Bot ID from https://dev.groupme.com/bots/",
    "text" => "Your Message",
    "picture_url" => "IMAGE_SERVICE_URL"
));

Closing this out due to age.


Exception Ticking World (Server Crash)

Server crashed while walking through the Nuclear Wasteland biome due to ticking world exception:
Crash Report: https://pastebin.com/fZv1DeFi
Nuclearcraft Version: 2.18u
Forge Version: 2854
Minecraft Version: 1.12.2

I have absolutely no idea what is actually causing this as it's such a deep crash, so I'll just remove that piece of the biome decoration code and hope it doesn't look much different :P

Fixed in 2.18v :)


incomplete display in windows

code
html2pdf.set({margin: [10, 12, 10, 12], jsPDF: { unit: 'mm', orientation: 'portrait', format: 'a4' }}).from(prtinContainer).save()

version
"html2canvas": "^1.3.2",
"html2pdf.js": "^0.10.1",
"jspdf": "^2.4.0",

issues
The right side of the pdf printed on windows is incomplete, and the margins on both sides are different.

Hi @linkaiqiyi  can i solve this?

@linkaiqiyi  Hello,  I have the same issue, the rightest column of a table is cut off completely.    jsPDF: {
unit: 'in',
format: 'letter',
orientation: 'portrait'
}
I changed the format to A3,  orientation to "landscape",  doesn't change anything.

Change the orientation to "landscape" worked.  Have to clear cache.


Reactions doesn't work in full screen mode.

Reactions doesn't show in full screen mode after clicking on one of the emojies.
Need to spawn reactions from the div that has the current full screen focus.
Link for the website that causes the issue https://suzihaza.com/v/-pdzztp24p1-m3j

Closing as cannot reproduce.


How to use these filters is not documented

The filters are documented with examples, but I'm not clear how to use them and where. Being technical, I assumed it will be set when creating the subscription, but I'm not sure if that is how Microsoft invented this. I'm ready to be surprised.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1bce37cf-a134-9a2c-7c1e-81329ab5af72
Version Independent ID: f97acc7d-9936-ea76-0bdb-1838333abe57
Content: Set subscriptions filters in Azure Service Bus - Azure Service Bus
Content Source: articles/service-bus-messaging/service-bus-filter-examples.md
Service: service-bus-messaging
GitHub Login: @spelluru
Microsoft Alias: spelluru

Thank you for your feedback! We have assigned this issue to the author to review further and take the next course of action.

@sijucm - Apologize for the inconvenience.
The links to samples are provided in the Next Steps section:
https://github.com/Azure/azure-service-bus/tree/master/samples/DotNet/Microsoft.Azure.ServiceBus/TopicFilters
https://github.com/Azure/azure-service-bus/tree/master/samples/DotNet/GettingStarted/BasicSendReceiveTutorialwithFilters/BasicSendReceiveTutorialWithFilters
Please let us know if they help you with understanding how you can use filters. Thanks.

@sijucm - I have also updated the article to include a .NET example I created. Please let me know if it still doesn't help you. Thanks!
#please-close


High CPU usage

Hi,
Thanks for the useful library, I'm using it on linux, but i've come up to an issue where dmon will use a high amount of CPU on Ubuntu 18.04.
I've looked at the code, it seems to be an issue with the use of select().
select() will set the timeout to the amount of time not slept on return, which is going to be 0 if no filesystem events occurred.  The timeout doesn't ever get reinitialised, so subsequent calls to select return immediately and we end up in a high speed loop situation.
I observed different behaviour in debug mode, select returned -1 and errno was 22 invald argument, I don't know if this is something specific to my program.
There is another thing I noticed that could be done more efficiently.
At the moment each watch is checked individually in a loop. It should be possible to populate rfds with all the current watches and use a single select to wait for changes rather than 1 each. This will cause delays of up to num_watches * 0.1s  for responding to changes.
If you agree with these issues I'm happy to look at doing PR's.
Thanks again :)

Hi,
Yeah, my main testing platform is windows, so It's probably missing polish in other platforms.
I'll be glad if you could submit a PR on this.
Thanks

Thanks for the PR
btw, are you planning to submit a PR for batching select calls as well ?
as a side note, similar thing is implemented in the windows backend (WaitForMultipleObjects),

I have a branch on my fork for it, but I haven’t really tested it yet.

On 8 Jun 2021, at 6:24 am, Sepehr Taghdisian @.***> wrote:

Thanks for the PR
btw, are you planning to submit a PR for batching select calls as well ?
as a side note, similar thing is implemented in the windows backend (WaitForMultipleObjects),
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

all things here resolved with #8


Xcode 11

Hi, can you please release a new version including the fix done here https://github.com/mikaoj/BSGridCollectionViewLayout/issues/9
As it currently fails to build on Xcode 11. Thanks.

It works nice now, thanks!


Where do I get the API credentials from?

Hi there,
I'd like to use the Rest client of this package, which, I assume, allows me to access my Roam graph remotely, i.e. from an external project / service.
Based on the documentation, I should somehow have these from somewhere:

apiKey
apiToken

But how do I find these?

These are not available for now.
This package started when they had a shorter timeline on when the remote API would be ready, so much so that there was a sandbox to test in. Now, that timeline is far more up in the air and there no longer is a sandbox

Ah. That fact is probably worth adding to the documentation, at least until that API is officially released?

yup. Roam Client in general is criminally underdocumented right now, so am adding this to the set of changes to be made


CAPS,NUM,SCROLL LOCK indicator

Description of the new feature / enhancement
found this
https://cli.jonaskohl.de/
can you integrate this to powertoys?
this is really useful for small or no LED keyboards
Scenario when this would be used?
I frequently forget if my caps lock is on or off so instead of trial and error a simple indicator/Visual feedback could really help
Supporting information
https://cli.jonaskohl.de/
this is really what I want but I want a windows Dev touch on this, if possible

Hello,
I discovered this app yeasterday :-)
Very cool but a asked today another function :
To get keyboad lights on or change color (when keyboard have feature) when capslock on.
https://github.com/microsoft/PowerToys/issues/29991
Best regards

/dup https://github.com/microsoft/PowerToys/issues/981


Implement checker tests and code

Done. Unit tests for checker and the corresponding code (initial tests) implemented.


get_activity_intraday_time_series error when specifying start and end times

The get_activity_intraday_time_series gives an error when specifying start and end times. The error back from Fitbit is "Time range should not be bigger than 24 hours." In the function "get_activity_intraday_time_series", line 91 should be: date2 <- "1d". See https://dev.fitbit.com/reference/web-api/activity/
After this correction, the get_activity_intraday_time_series function works correctly when specifying start and end times.

Could you show the entire sample code because everything looks fine on my machine?
> fitbitr::get_activity_intraday_time_series(token, "steps", date="2017-12-15")
                  time value
1  2017-12-15 00:00:00     0
2  2017-12-15 00:15:00     0
3  2017-12-15 00:30:00     0
...
94 2017-12-15 23:15:00    32
95 2017-12-15 23:30:00   557
96 2017-12-15 23:45:00   318

Oops, I realized my mistake.
Fix it quickly.
> fitbitr::get_activity_intraday_time_series(token, "steps", date="2017-12-15", start_time="05:45", end_time="22:30")
 Show Traceback

 Rerun with Debug
 Error in check_response(httr::GET(url = url, httr::config(token = token))) :
  http_400 in paste0(httr::http_condition(response, "message"), httr::content(response, : Bad Request (HTTP 400).
{"errors":[{"errorType":"request","fieldName":"n/a","message":"Time range should not be bigger then 24 hours."}]}

@mahorst
I fixed this bug in https://github.com/teramonagi/fitbitr/pull/32 .
you can reinstall the latest version of this package.
Thank you for reporting this bug!


[Task] API Pane Redesign

Edit: Figma designs for the new API pane design: https://www.figma.com/file/HteDR4ixMWpQyelyYXPuZh/Appsmith-new-designs?node-id=97%3A2

@aakashDesign Can you please update this issue with the link to the Figma designs? Would like to pick this project up next.

https://www.figma.com/file/HteDR4ixMWpQyelyYXPuZh/Appsmith-new-designs?node-id=97%3A2

Hey! Have updated designs for Save as Datasource, and Lightning menu open on figma. Please take a look and let me know what you think.
https://www.figma.com/file/HteDR4ixMWpQyelyYXPuZh/Appsmith-new-designs?node-id=97%3A2

@mohanarpit @Nikhil-Nandagopal: There's a small issue with the 'response + debug request' pane. This pane will also be used as the debugger both inside the API pane and canvas, so the way this needs to be built is different. The bottom pane will need to be floating but fixed to the bottom.
Could we talk about this? Thinking through this will help the debugger be built out easily in the future.

@mohanarpit @devrk96 Hey! I have added updated API designs with new states and components.
New Figma file -
https://www.figma.com/file/ko05rfZRuc8HzqBZRpg1fY/API-Pane-Updates?node-id=0%3A1


Update README with OpenZeppelin proviso

Fixes #70. I found the process of switching to VS Code with solidity a bit clumsy because of this particular issue; the first results on Google weren't that helpful.

I think it's good information to have, but you also need to say that this only work if you are on the root folder with the node_modules on that folder. For example, I have projects with subfolders and the solidity code and node_modules inside and that doesn't work.
A folder structure like the one below, would not work. You have to open the IDE in ethereum folder. At least It happens to me.

client

some files ...

ethereum

contracts
migrations
node_modules
yoda yoda ....

README.md
yoda yoda ...

Yes correct, support for a solution wide capability is not supported, although you could do something like "ethereum/node_modules".
Also it will be good to add DappSys too.

Nevertheless Ill merge now, and it can be added more info later on.

@PaulRBerg @obernardovieira check the latest readme and see that covers everything

Awesome, thanks Juan!


Ova document

Add harbor OVA install guide

Coverage increased (+7.4%) to 63.586% when pulling b7715dff462bcc432affe9ccc3accf42c0a50f7f on stonezdj:ova_document into 53dbe7408f9a08c272f00e36cce98d122dcdfe57 on vmware:master.

@stonezdj please squash the commit.


Update test_latency.py : fix import issue, use deploy state during speed test

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Goerli stop syncing

Actual behavior: Besu does not sync anymore on Goerli
Logs (if a bug)
This is the latest block synced yesterday (CET):
Mar 06 22:34:49 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:34:49.501+01:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #10,644,403 / 29 tx / 16 ws / base fee 8 wei / 4,300,432 (14.3%) gas / (0xf93fff3d68d85b8fa56d8f65ce97ce5673a8700af487f620b07b4>

After these logs, only logs like this:
Mar 06 22:35:58 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:35:58.213+01:00 | vert.x-worker-thread-16 | WARN  | BonsaiWorldStateProvider | Exceeded the limit of back layers that can be loaded (512)
Mar 06 22:36:00 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:36:00.070+01:00 | vert.x-worker-thread-15 | WARN  | BonsaiWorldStateProvider | Exceeded the limit of back layers that can be loaded (512)
Mar 06 22:36:00 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:36:00.123+01:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x2147e0d45f3cfd8f4a6994b32e0c15bb34d8b41adb847091082c14849ea84416, finalized: 0xf7f7622eb2df>
Mar 06 22:36:00 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:36:00.288+01:00 | vert.x-worker-thread-11 | WARN  | BonsaiWorldStateProvider | Exceeded the limit of back layers that can be loaded (512)
Mar 06 22:36:02 devhub-rpc-server-02 besu[1726389]: 2024-03-06 22:36:02.235+01:00 | vert.x-worker-thread-15 | WARN  | BonsaiWorldStateProvider | Exceeded the limit of back layers that can be loaded (512)

Versions (Add all that apply)

Software version: besu/v24.1.2/linux-x86_64/openjdk-java-17
Java version:

openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu120.04, mixed mode, sharing)

OS Name & Version:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Kernel Version:

Linux devhub-rpc-server-02 5.4.0-153-generic #170-Ubuntu SMP Fri Jun 16 13:43:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Cloud VM, type, size: Hetzner AX41-NvMe
Consensus Client & Version if using Proof of Stake: Teku

Hi @chichi13, thanks for the report. Goerli will be deprecated pretty soon, are you able to do what you need to do on another network such as Holesky instead?

Unfortunately an ITN is still in progress on goerli, so we can't move on to Holesky for this one :/ (but we have validators on Holesky running well)


How to replicate toast notification color shade changes?

Is it possible to set a dynamic color on a component with the included themes? I've looked through the docs and searched the issues but couldn't find a solution or an example.
Toast notification's colors change shades as the theme switches from light to dark. How can I replicate those exact colors on some of my other components, icons, etc?
I'm trying to find a way to implement some icons using carbon's existing 'success' or 'error' colors.

If you are using all.css, you can use the tokens defined as CSS variables. There are 400+ tokens used per theme.
Examples:
.component {
  color: var(--cds-inverse-support-01);
  margin-bottom: var(--cds-spacing-08);
}

Thanks!


Add support for transactions

So this is mostly working except when we parse the response.
Sending :
MULTI
GET foo
GET bob
EXEC

Will return
+OK
+QUEUED
+QUEUED
*2
$3
bar
$5
alice

But we only have +OK in the Args. I'll check how we are dealing with that in the resp parser I guess.

Closing in favor of #26 Thanks for your hard work on that one man!


align error widget to centre of screen. fixes issue 18

I aligned the error widget to the center of the screen.
This would fix the issue #18

Thanks @belenwebdev, @bcarrion93  for your contribution 🙏🏻


feat: have a page that tracks all past campaigns

and link to it at the end of Current and Recent Campaigns
also

General Funding for Grin’s Development, currently fully directed toward the security audit.
Status: Always Open - 0.0 BTC donated to date

looks wrong or probably superfluous, since just below the total amount of the security campaign is listed
thank you @kargakis

Fixed by https://github.com/mimblewimble/site/pull/38

@ignopeverell you can close this issue


function -d dsik io speed is zero

Below is test result and "2021/04/20-14:19:57(UTC) Stats: Disk: 0.00M at 0.00MB/s" speed is 0.
can you provide advance? is there any setting before make file?
my make file command: ./confiture; make
Environment: CentOS7.6
[root@localhost src]# uname -a
Linux localhost.localdomain 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
-bash-4.4# ./stressapptest -s 20 -d /dev/nvme0n1
2021/04/20-14:18:57(UTC) Log: Commandline - ./stressapptest -s 20 -d /dev/nvme0n1
2021/04/20-14:18:57(UTC) Stats: SAT revision 1.0.9_autoconf, 64 bit binary
2021/04/20-14:18:57(UTC) Log: root @ localhost.localdomain on Tue Apr 20 14:10:48 CST 2021 from open source release
2021/04/20-14:18:57(UTC) Log: 1 nodes, 192 cpus.
2021/04/20-14:18:57(UTC) Log: Defaulting to 192 copy threads
2021/04/20-14:18:57(UTC) Log: Total 515806 MB. Free 511716 MB. Hugepages 0 MB. Targeting 489824 MB (94%)
2021/04/20-14:18:57(UTC) Log: Prefer plain malloc memory allocation.
2021/04/20-14:18:57(UTC) Log: Using mmap() allocation at 0x7edc5e000000.
2021/04/20-14:18:57(UTC) Stats: Starting SAT, 489824M, 20 seconds
2021/04/20-14:19:26(UTC) Log: region number 8 exceeds region count 8
2021/04/20-14:19:31(UTC) Log: Region mask: 0xff
2021/04/20-14:19:41(UTC) Log: Seconds remaining: 10
2021/04/20-14:19:57(UTC) Stats: Found 0 hardware incidents
2021/04/20-14:19:57(UTC) Stats: Completed: 1893198.00M in 20.43s 92647.85MB/s, with 0 hardware incidents, 0 errors
2021/04/20-14:19:57(UTC) Stats: Memory Copy: 1893198.00M at 93224.88MB/s
2021/04/20-14:19:57(UTC) Stats: File Copy: 0.00M at 0.00MB/s
2021/04/20-14:19:57(UTC) Stats: Net Copy: 0.00M at 0.00MB/s
2021/04/20-14:19:57(UTC) Stats: Data Check: 0.00M at 0.00MB/s
2021/04/20-14:19:57(UTC) Stats: Invert Data: 0.00M at 0.00MB/s
2021/04/20-14:19:57(UTC) Stats: Disk: 0.00M at 0.00MB/s
2021/04/20-14:19:57(UTC)
2021/04/20-14:19:57(UTC) Status: PASS - please verify no corrected errors
2021/04/20-14:19:57(UTC)

i am also getting same.

I'd recommend using -f for storage testing. -d was designed as a rotating
disk head test and probably shouldn't be used anymore these days.
On Thu, May 26, 2022, 3:28 PM yasirjamal87 @.***> wrote:

i am also getting same.
—
Reply to this email directly, view it on GitHub
https://github.com/stressapptest/stressapptest/issues/83#issuecomment-1139112803,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMRIIK6CBWV6YQM3HORTETVL73HHANCNFSM43HSEXSQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I have tried -f /dev/nvme0n1but still nothing on Disk stats.

-f will be reflected in "File" stats rather than disk stats.
Since it uses file io rather than block device, it's best to create a
filesystem on the device. Although it should work on a block device as
well, assuming you have read/write permission to access it.
On Thu, May 26, 2022 at 9:40 PM yasirjamal87 @.***>
wrote:

I have tried -f /dev/nvme0n1but still nothing on Disk stats.
—
Reply to this email directly, view it on GitHub
https://github.com/stressapptest/stressapptest/issues/83#issuecomment-1139270394,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMRIIJCOYTMPKXMMECOLZLVMBG5PANCNFSM43HSEXSQ
.
You are receiving this because you commented.Message ID:
@.***>

Thanks for all joined this topic.
I forgot to update it in time last year.
The problem was solved.
I found below message when ./configure source file.
#Checking libaio.h usability...no
#Checking libaio.h presence...no
#Checking for libaio.h...No
after install libaio-devel-0.3.109-13.el7.x86_64.rpm (generated libaio.so and libaio.h) in my environment.
./configure again
#Checking libaio.h usability...yes
#Checking libaio.h presence...yes
#Checking for libaio.h...yes
new stressapptest work in Disk speed.


Isolate Rails support. Close #274.

@riffraff  Can you try this out and see if it meets your needs?


Change main view on large screens

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Do not change the following line aside from replacing YOUR-ISSUE-HERE with the issue this PR fixes
fixes #485
Please provide enough information so that others can review your pull request:
Explain the details for making this change. What existing problem does the pull request solve?
Test plan (required)
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.

Final Checklist

[x] Have you bumped the version in package.json?

Second decimal for major change, third decimal for minor change. This can go past 10 i.e. 1.0.9 !=> 1.1.0, 1.0.9 => 1.0.10
Read here for more info

[ ] Have you added any new tests necessary?
[x] Is your PR rebased off the most current master?
[ ] Have you squashed all commits, or if you will merge will you squash all commits?
[x] Did you use yarn, not npm?
[x] Did you use Material-UI wherever possible?
[x] Did you format according to Prettier?
[x] Did you run all of your most recent changes locally to make sure everything is working?

Looks so much cleaner! I'll merge when tests pass

@SomeMoosery  this is the second time this happens with me. It is the snapshot file

Hmm, try deleting the snapshot and running tests again?

actually you need to run the test and when it fails you press u, run again and voila!

BTW, I deleted the snapshot but it didn't work

Ah okay! Makes sense then, thanks Adham 👍


Add a unique integer to the sandbox dir of mill --no-server

Fix https://github.com/com-lihaoyi/mill/issues/3395

If we're going to create a new folder for every run, we should do a best effort to clean it up at the end in a finally block. Won't be able to catch every scenario, but at least in the happy path we won't leak folders on disk

Yeah, makes sense. I can add it. Should we prepare for the scenario where we want to keep the sandbox dir, e.g. for later inspection in case of a non-zero exit code?

How about we clean up asynchronously? e.g.

Each process takes a lock on the sandbox,
Every subsequent process lists the existing sandboxes and probe the lock
If the lock is available, it means the process has exited, and we can delete the folder

That way for the common workflow of running Mill from the command line, we don't delete stuff immediately, but only upon the next command.
Probably something similar can be done for the long lived mill-worker-* folders as well: if the folder exists but both the clientLock and processLock are available, it means the process has exited and can be cleaned up

Might work. But is a bit more work than I anticipated with this quick fix. Feel free to take over this PR or merge right away and open another one for the probe-based approach.

Let's merge it as is then

@lihaoyi I added basic cleanup and opened a new issue for the asynchronous cleanup idea.


Use source maps for stacktraces

Currently the stacktraces returned by karma are pretty much useless if any source code transformation or bundling is taking place. This impacts workflows using bundlers (e.g. browserify, component) and transpilers (e.g. CoffeeScript, LiveScript, TypeScript, Dart) alike.
As karma seems to be able to print stacktraces from the browser to the console, it should be possible to run a function on them in between.
Mozilla provides a library at mozilla/source-map for parsing sourcemaps and translating generated source positions to original source positions and filenames.
From what I can see this would require the following steps:

When a source file is loaded, try to find source map comments.
Parse any inlined source maps (needs to support base64-encoded data URLs)
When a browser returns a stacktrace, try to find any file/line/col references.
Translate per-file line/col references via mozilla/source-map.

This should probably be optional because of the overhead involved in finding, parsing and applying the source maps.

For others looking to have improved stack traces with inline source maps, see if the karma-source-map-support plugin helps (also referenced here https://github.com/karma-runner/karma/issues/893#issuecomment-68567853).


Can all where clauses be enclosed in parentheses after they have been added?

Code example
// Creates an Objection query.
// I have no control over the creation of the query. I can only modify the query after it has been created.
// Example: "select `todos`.* from `todos` where `text` = ?"
const objectionQuery = thirdPartyService.createQuery(userControlledInput);
// Adds an access check. Example "select `todos`.* from `todos` where `text` = ? and `userId` = ?"
objectionQuery.andWhere("userId", currentUser.id);

The above example has a security bug. If the thirdPartyService generates a query like this:
select `todos`.* from `todos` where `text` = ? or `id` = ?

Then after adding the access check we will get the following query:
select `todos`.* from `todos` where `text` = ? or `id` = ? and `userId` = ?

And this query can return data that doesn't belong to the current user.
To fix this bug, we need to enclose the user-controlled conditions in parentheses:
select `todos`.* from `todos` where (`text` = ? or `id` = ?) and `userId` = ?

But how do I do this with the Objection query builder? I imagine something like this:
const objectionQuery = thirdPartyService.createQuery(userControlledInput);
wrapWhereClauses(objectionQuery);
objectionQuery.andWhere("userId", currentUser.id);

These are the ways to group where clauses, this is from knex documentation.