Z-wave nodes does not load in 0.87

Home Assistant release with the issue:

0.87
Last working Home Assistant release (if known):
0.79.3
Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io on Docker on Ubuntu on Intel NUC
Component/platform:

https://www.home-assistant.io/docs/z-wave/installation/
Description of problem:
After upgrade to 0.87 (from 79.3) almost all Z-wave nodes disappeared (I have 5 working out of around 50). Log says:

Z-Wave entity Unknown Node 18 Unknown (node_id: 18) not ready after 30 seconds, continuing anyway

When I downgrade to 0.79.3 again, it work as expected.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
zwave:
  usb_path: /dev/serial/by-id/usb-0658_0200-if00 (have tried regular /dev/ttyACM0 too)

Traceback (if applicable):
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 1 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 4 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 7 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 8 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 9 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 12 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 13 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 17 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 18 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 19 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 20 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 21 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 22 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 23 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 24 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 25 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 26 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 27 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 28 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 29 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 30 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 33 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 34 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 35 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 36 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 37 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 38 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 41 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 42 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 43 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 44 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 45 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 46 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 47 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 48 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 49 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 50 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 51 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave node 52 not ready after 30 seconds, continuing anyway
2019-02-09 17:57:06 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 4 Level (node_id: 4) not ready after 30 seconds, continuing anyway
2019-02-09 17:57:08 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 7 Level (node_id: 7) not ready after 30 seconds, continuing anyway
2019-02-09 17:57:09 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.speedtest_upload is taking over 10 seconds
2019-02-09 17:57:10 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.netatmo_utesensor_battery is taking over 10 seconds
2019-02-09 17:57:12 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:12 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 8 Level (node_id: 8) not ready after 30 seconds, continuing anyway
2019-02-09 17:57:13 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:57:16 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.xxs_iphone_battery_level is taking over 10 seconds
2019-02-09 17:57:17 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:20 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 12 Level (node_id: 12) not ready after 30 seconds, continuing anyway
2019-02-09 17:57:23 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:24 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:57:29 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:30 WARNING (MainThread) [homeassistant.components.sensor] Updating speedtest sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:57:31 WARNING (MainThread) [homeassistant.components.sensor] Updating netatmo sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:57:35 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:57:35 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:37 WARNING (MainThread) [homeassistant.components.sensor] Updating ios sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:57:39 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.cpu_temperature is taking over 10 seconds
2019-02-09 17:57:41 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:43 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 21 Level (node_id: 21) not ready after 30 seconds, continuing anyway
2019-02-09 17:57:46 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:57:47 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:53 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:57:57 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:57:59 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:01 WARNING (MainThread) [homeassistant.components.sensor] Updating speedtest sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:02 WARNING (MainThread) [homeassistant.components.sensor] Updating netatmo sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:05 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:05 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 25 Level (node_id: 25) not ready after 30 seconds, continuing anyway
2019-02-09 17:58:08 WARNING (MainThread) [homeassistant.components.sensor] Updating ios sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:08 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:58:11 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:17 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:19 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:58:23 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:29 WARNING (MainThread) [homeassistant.components.sensor] Updating command_line sensor took longer than the scheduled update interval 0:01:00
2019-02-09 17:58:29 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:30 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:58:32 WARNING (MainThread) [homeassistant.components.sensor] Updating speedtest sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:33 WARNING (MainThread) [homeassistant.components.sensor] Updating netatmo sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:34 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 38 Switch (node_id: 38) not ready after 30 seconds, continuing anyway
2019-02-09 17:58:34 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 41 Switch (node_id: 41) not ready after 30 seconds, continuing anyway
2019-02-09 17:58:35 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:39 WARNING (MainThread) [homeassistant.components.sensor] Updating ios sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:58:41 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:58:41 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:47 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:53 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:58:58 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:59:00 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.hue_dimmer_garderobe is taking over 10 seconds
2019-02-09 17:59:02 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.stue is taking over 10 seconds
2019-02-09 17:59:02 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.gang is taking over 10 seconds
2019-02-09 17:59:03 WARNING (MainThread) [homeassistant.components.sensor] Updating speedtest sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:59:03 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:59:04 WARNING (MainThread) [homeassistant.components.sensor] Updating netatmo sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:59:04 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:59:08 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.speedtest_download is taking over 10 seconds
2019-02-09 17:59:08 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.netatmo_regn_sum_rain_24 is taking over 10 seconds
2019-02-09 17:59:08 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.xxxs_iphone_battery_state is taking over 10 seconds
2019-02-09 17:59:10 WARNING (MainThread) [homeassistant.components.sensor] Updating ios sensor took longer than the scheduled update interval 0:00:30
2019-02-09 17:59:10 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:59:14 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 17:59:16 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 33 Unknown (node_id: 33) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 33 Alarm Type (node_id: 33) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 33 Alarm Level (node_id: 33) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 35 Unknown (node_id: 35) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 35 Alarm Type (node_id: 35) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:38 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 35 Alarm Level (node_id: 35) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:54 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 38 Unknown (node_id: 38) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:54 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 38 Alarm Type (node_id: 38) not ready after 30 seconds, continuing anyway
2019-02-09 17:59:54 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 38 Alarm Level (node_id: 38) not ready after 30 seconds, continuing anyway
2019-02-09 18:00:04 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:00:10 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:00:14 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.hue_dimmer_garderobe is taking over 10 seconds
2019-02-09 18:00:15 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.speedtest_download is taking over 10 seconds
2019-02-09 18:00:15 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.netatmo_innesensor_wifi is taking over 10 seconds
2019-02-09 18:00:16 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:00:19 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.gang is taking over 10 seconds
2019-02-09 18:00:19 WARNING (MainThread) [homeassistant.helpers.entity] Update of media_player.stue is taking over 10 seconds
2019-02-09 18:00:20 WARNING (MainThread) [homeassistant.components.media_player] Updating sonos media_player took longer than the scheduled update interval 0:00:10
2019-02-09 18:00:22 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:00:22 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.xxxs_iphone_battery_level is taking over 10 seconds
2019-02-09 18:00:28 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:00:34 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 38 Power (node_id: 38) not ready after 30 seconds, continuing anyway
2019-02-09 18:00:36 WARNING (MainThread) [homeassistant.components.sensor] Updating speedtest sensor took longer than the scheduled update interval 0:00:30
2019-02-09 18:00:36 WARNING (MainThread) [homeassistant.components.sensor] Updating netatmo sensor took longer than the scheduled update interval 0:00:30
2019-02-09 18:00:40 WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:05
2019-02-09 18:01:36 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave not ready after 300 seconds, continuing anyway
2019-02-09 18:01:40 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave entity Unknown Node 18 Unknown (node_id: 18) not ready after 30 seconds, continuing anyway

Additional information:

There have been a few breaking changes between .79 and .87.

I might have narrowed it down to the upgrade of python_openzwave package to 0.4.10(#17323) which happened in 0.81? Or is it the z wave config entry support, which happened in same  version? (#17119)
I cant make zwave work on versions from 0.81-0.87.
In 0.81.6 all nodes appear, but 90% of them are unknown and do not work. In later versions, only a few appear (around 5 of 50).

There have been a few breaking changes between .79 and .87.

I suggest you dont thumb this down before we have found the issue. I see others also have issues with zwave on Docker in versions after 0.79, so I am not alone.
Of course I have checked the breaking changes, and none of those explains why I am only getting 5 out of my 50 devices which all function 100% in 0.79.3.

Try updating in order. Go to .80 and see what happens.

Ok, will try that. Letting you know if it works!

Having similar issues, some nodes working fine but others are missing. Haven't had a chance to investigate much, but will update if I find anything.

i'm having the same issue with 5 monoprice door sensors and a first alert smoke/carbon detector. same exact steps to setup all 5 sensors... only 3 of them work. factory reset everything, then 4 work. factory reset again, 2 work.

I noticed that there are no nodes listed in the Z-Wave management panel except for the Aeotec Z-stick itself, but looking at the OZW logs I see that it is still receiving updates from all the nodes as expected.
Oddly enough, one of my Z-Wave binary sensors does work properly and the value in the frontend gets updated, but the corresponding node is not there in the Z-Wave control panel. The rest of them also show up in the OZW log file, but the associated sensors don't appear in the frontend nor do their corresponding nodes show up.

Same here after upgrading from 0.86 to 0.88.1. The OZW_Log.txt shows regular updates from the nodes. I did stop hass and run ozwcp where all 15 nodes appears as ready after some time.
In hass all nodes a reported as not ready, although they are reachable according to OZW_Log.txt.

I played with it some more and I've noticed that it's intermittent.
Sometimes devices show up, sometimes the don't. It's not consistent which
devices appear.

Ok, upgraded stepwise from 0.79.3 and this is the results:
0.79.3 -> 0.80.3: No problems. All works nice.
0.80.3 -> 0.81.6: No problems. All works nice.
0.81.6 -> 0.82.1: No problems. All works nice.
0.82.1 -> 0.83.3: Started seeing problems. Z-wave devices are found in Hass, but still initializing.
So there must be something between 0.82.1 and 0.83.3 which makes the trouble. I'm guessing change #18160 in 0.83.3:
Update python-openzwave to 0.4.11 (@rafale77 - #18160) (zwave docs)

Update, Z-wave devices suddenly got out of the initializing state now, and all work as expected. It is just loading a bit more slowly than I am used to in this version than before. Will try to debug 0.83.3 version a bit, to see if it is stable or not.

Update on 0.88.1: although after a long time most Z-wave devices did appear but they are not responding to commands. A single wall plug seems to work most time. The other wall plugs are not responding (while they did before upgrading). All nodes are directly reachable by the Z-wave root.

What z-wave adapter is everybody using? It sounds like we're on our own for fixing this, so we need to narrow it down some more.

Aeotec Z-Wave USB Hub (FT090-C)

Aeotec Z-Stick Gen5
if you need more specific details let me know. I don't have access to the physical stick at the moment, but I can query the CLI if you let me know what command you'd like to see the output from

Are you still experiencing this issue after updating to 0.90 there were some changes fixes made in 0.90

The issue still exists with 0.90.1 :-(

This is also occurring to me in 0.90.1. It's only impacting my battery powered sensors (switches and everything connected to mains voltage works fine) My Door/Window and multisensors are all not showing up. I was able to get one of my multi-sensors to pop in by forcing an update by pressing a button on it- I'm wondering if they are asleep when HA/Z-Wave starts- can be related? Never have had this issue before- things are showing up fine in the OZW logs (I can see the battery powered nodes waking up and receiving data. Let me know what everyone needs to troubleshoot this further... I need my door sensors working for many of my automations. Thanks!

Having this issue for the last few weeks as well. Using a ZOOZ Zwave USB (basically a Aeotec Z-Stick Gen5).
Either no devices load (, or just the ZOOZ USB loads, or the devices stop working randomly.
Errors:
Z-Wave node 1 not ready after 30 seconds, continuing anyway
Error in manager callback Traceback (most recent call last): KeyError: 8
WARNING [openzwave] Z-Wave Notification ValueChanged

I do have exactly the same issue.
Updated regulary and now on the most recent rel 91.3.
Runnung hassio in a docker on a NUC (coming from RPi).
My zwave network is secured with a key.
Lost all my nodes except the USB Stick itself.
according to the OZW Log the zwave network is running:
example:
2019-04-14 20:17:33.632 Info, contrlr,     Node 006 - New
2019-04-14 20:17:33.632 Detail, Node006, AdvanceQueries queryPending=0 queryRetries=0 queryStage=None live=1
2019-04-14 20:17:33.632 Detail, Node006, QueryStage_ProtocolInfo
2019-04-14 20:17:33.632 Detail, Node006, Queuing (Query) Get Node Protocol Info (Node=6): 0x01, 0x04, 0x00, 0x41, 0x06, 0xbc
2019-04-14 20:17:33.632 Detail, Node006, Queuing (Query) Query Stage Complete (ProtocolInfo)
2019-04-14 20:17:33.632 Info, Node006, Initializing Node. New Node: false (false)
2019-04-14 20:17:33.812 Info, Node006, Sending (Query) message (Callback ID=0x00, Expected Reply=0x41) - Get Node Protocol Info (Node=6): 0x01, 0x04, 0x00, 0x41, 0x06, 0xbc
2019-04-14 20:17:33.814 Detail, Node006,   Received: 0x01, 0x09, 0x01, 0x41, 0x53, 0x9c, 0x01, 0x04, 0x07, 0x01, 0x7a
2019-04-14 20:17:33.814 Detail,
2019-04-14 20:17:33.814 Info, Node006, Received reply to FUNC_ID_ZW_GET_NODE_PROTOCOL_INFO
2019-04-14 20:17:33.814 Info, Node006,   Protocol Info for Node 6:
2019-04-14 20:17:33.814 Info, Node006,     Listening     = false
2019-04-14 20:17:33.814 Info, Node006,     Frequent      = false
2019-04-14 20:17:33.814 Info, Node006,     Beaming       = true
2019-04-14 20:17:33.814 Info, Node006,     Routing       = true
2019-04-14 20:17:33.814 Info, Node006,     Max Baud Rate = 40000
2019-04-14 20:17:33.814 Info, Node006,     Version       = 4
2019-04-14 20:17:33.814 Info, Node006,     Security      = false
2019-04-14 20:17:33.814 Info, Node006,   Basic device class    (0x04) - Routing Slave
2019-04-14 20:17:33.814 Info, Node006,   Generic device Class  (0x07) - Notification Sensor
2019-04-14 20:17:33.814 Info, Node006,   Specific device class (0x01) - Notification Sensor
2019-04-14 20:17:33.814 Info, Node006,     COMMAND_CLASS_BASIC is not mapped
2019-04-14 20:17:33.814 Info, Node006,   Mandatory Command Classes for Node 6:
2019-04-14 20:17:33.814 Info, Node006,     COMMAND_CLASS_BASIC
2019-04-14 20:17:33.814 Info, Node006,     COMMAND_CLASS_WAKE_UP
2019-04-14 20:17:33.814 Info, Node006,   Mandatory Command Classes controlled by Node 6:
2019-04-14 20:17:33.814 Info, Node006,     None
2019-04-14 20:17:33.814 Detail, Node156,   Expected reply was received
2019-04-14 20:17:33.814 Detail, Node156,   Message transaction complete
2019-04-14 20:17:33.814 Detail,
2019-04-14 20:17:33.814 Detail, Node006, Removing current message
2019-04-14 20:17:33.814 Detail, Node006, Notification: NodeProtocolInfo
2019-04-14 20:17:33.816 Detail, Node006, Notification: ValueAdded
2019-04-14 20:17:33.817 Detail, Node006, Notification: ValueAdded
2019-04-14 20:17:33.819 Detail, Node006, Query Stage Complete (ProtocolInfo)
2019-04-14 20:17:33.819 Detail, Node006, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Probe live=1
2019-04-14 20:17:33.819 Detail, Node006, QueryStage_Probe
2019-04-14 20:17:33.819 Info, Node006, NoOperation::Set - Routing=true
2019-04-14 20:17:33.819 Detail, Node006, Queuing (NoOp) NoOperation_Set (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x00, 0x00, 0x25, 0x0d, 0xc9
2019-04-14 20:17:33.819 Detail, Node006, Queuing (Query) Query Stage Complete (Probe)
2019-04-14 20:17:33.819 Detail,
2019-04-14 20:17:33.819 Info, Node006, Sending (NoOp) message (Callback ID=0x0d, Expected Reply=0x13) - NoOperation_Set (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 0x02, 0x00, 0x00, 0x25, 0x0d, 0xc9
2019-04-14 20:17:33.826 Detail, Node006,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-04-14 20:17:33.826 Detail, Node006,   ZW_SEND_DATA delivered to Z-Wave stack
2019-04-14 20:17:41.612 Detail, Node006,   Received: 0x01, 0x07, 0x00, 0x13, 0x0d, 0x01, 0x03, 0x0b, 0xef
2019-04-14 20:17:41.612 Detail, Node006,   ZW_SEND_DATA Request with callback ID 0x0d received (expected 0x0d)
2019-04-14 20:17:41.612 Info, Node006, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.
2019-04-14 20:17:41.612 Info, Node006,   Node 6 has been marked as asleep
2019-04-14 20:17:41.612 Info, Node006, Node not responding - moving QueryStageComplete command to Wake-Up queue
2019-04-14 20:17:41.612 Detail, Node006, Notification: Notification - NoOperation
2019-04-14 20:17:41.614 Detail, Node006, Notification: Notification - Node Asleep
2019-04-14 20:17:41.620 Detail,
not battery powered device (power plug):
2019-04-14 20:17:51.329 Info, Node020, Sending (Query) message (Callback ID=0x00, Expected Reply=0x41) - Get Node Protocol Info (Node=20): 0x01, 0x04, 0x00, 0x41, 0x14, 0xae
2019-04-14 20:17:51.330 Detail, Node020,   Received: 0x01, 0x09, 0x01, 0x41, 0xd3, 0x9c, 0x01, 0x04, 0x10, 0x01, 0xed
2019-04-14 20:17:51.331 Detail,
2019-04-14 20:17:51.331 Info, Node020, Received reply to FUNC_ID_ZW_GET_NODE_PROTOCOL_INFO
2019-04-14 20:17:51.331 Info, Node020,   Protocol Info for Node 20:
2019-04-14 20:17:51.331 Info, Node020,     Listening     = true
2019-04-14 20:17:51.331 Info, Node020,     Beaming       = true
2019-04-14 20:17:51.331 Info, Node020,     Routing       = true
2019-04-14 20:17:51.331 Info, Node020,     Max Baud Rate = 40000
2019-04-14 20:17:51.331 Info, Node020,     Version       = 4
2019-04-14 20:17:51.331 Info, Node020,     Security      = false
2019-04-14 20:17:51.331 Info, Node020,   Basic device class    (0x04) - Routing Slave
2019-04-14 20:17:51.331 Info, Node020,   Generic device Class  (0x10) - Binary Switch
2019-04-14 20:17:51.331 Info, Node020,   Specific device class (0x01) - Binary Power Switch
2019-04-14 20:17:51.331 Info, Node020,     COMMAND_CLASS_BASIC will be mapped to COMMAND_CLASS_SWITCH_BINARY
2019-04-14 20:17:51.331 Info, Node020,   Mandatory Command Classes for Node 20:
2019-04-14 20:17:51.331 Info, Node020,     COMMAND_CLASS_BASIC
2019-04-14 20:17:51.331 Info, Node020,     COMMAND_CLASS_SWITCH_BINARY
2019-04-14 20:17:51.331 Info, Node020,     COMMAND_CLASS_SWITCH_ALL
2019-04-14 20:17:51.331 Info, Node020,   Mandatory Command Classes controlled by Node 20:
2019-04-14 20:17:51.331 Info, Node020,     None
2019-04-14 20:17:51.331 Detail, Node156,   Expected reply was received
2019-04-14 20:17:51.331 Detail, Node156,   Message transaction complete
2019-04-14 20:17:51.331 Detail,
2019-04-14 20:17:51.331 Detail, Node020, Removing current message
2019-04-14 20:17:51.331 Detail, Node020, Notification: NodeProtocolInfo
2019-04-14 20:17:51.333 Detail, Node020, Notification: ValueAdded
2019-04-14 20:17:51.342 Detail, Node020, Notification: ValueAdded
2019-04-14 20:17:51.350 Detail, Node020, Query Stage Complete (ProtocolInfo)
2019-04-14 20:17:51.350 Detail, Node020, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Probe live=1
2019-04-14 20:17:51.350 Detail, Node020, QueryStage_Probe
2019-04-14 20:17:51.350 Info, Node020, NoOperation::Set - Routing=true
2019-04-14 20:17:51.350 Detail, Node020, Queuing (NoOp) NoOperation_Set (Node=20): 0x01, 0x09, 0x00, 0x13, 0x14, 0x02, 0x00, 0x00, 0x25, 0x1b, 0xcd
2019-04-14 20:17:51.350 Detail, Node020, Queuing (Query) Query Stage Complete (Probe)
2019-04-14 20:17:51.350 Detail,
2019-04-14 20:17:51.350 Info, Node020, Sending (NoOp) message (Callback ID=0x1b, Expected Reply=0x13) - NoOperation_Set (Node=20): 0x01, 0x09, 0x00, 0x13, 0x14, 0x02, 0x00, 0x00, 0x25, 0x1b, 0xcd
2019-04-14 20:17:51.358 Detail, Node020,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-04-14 20:17:51.358 Detail, Node020,   ZW_SEND_DATA delivered to Z-Wave stack
2019-04-14 20:17:51.374 Detail, Node020,   Received: 0x01, 0x07, 0x00, 0x13, 0x1b, 0x00, 0x00, 0x02, 0xf2
2019-04-14 20:17:51.374 Detail, Node020,   ZW_SEND_DATA Request with callback ID 0x1b received (expected 0x1b)
2019-04-14 20:17:51.375 Info, Node020, Request RTT 24 Average Request RTT 24
2019-04-14 20:17:51.375 Detail,   Expected callbackId was received
2019-04-14 20:17:51.375 Detail,   Expected reply was received
2019-04-14 20:17:51.375 Detail,   Message transaction complete
2019-04-14 20:17:51.375 Detail,
2019-04-14 20:17:51.375 Detail, Node020, Removing current message
2019-04-14 20:17:51.375 Detail, Node020, Notification: Notification - NoOperation
2019-04-14 20:17:51.376 Detail,
2019-04-14 20:17:51.376 Info, Node021, Sending (Query) message (Callback ID=0x00, Expected Reply=0x41) - Get Node Protocol Info (Node=21): 0x01, 0x04, 0x00, 0x41, 0x15, 0xaf
2019-04-14 20:17:51.378 Detail, Node021,   Received: 0x01, 0x09, 0x01, 0x41, 0xd3, 0x9c, 0x01, 0x04, 0x10, 0x01, 0xed
so from my point of view all looks good.
But the frontend does not get any zwave data (all nodes with yellow background; can*t read data).
If I restore the zwcfgxxxx.xml from an old backup and reboot the system the nodes are back but just for a limted time. There are 100% lost at the next boot.
It is a nightmare.
Any hint for a solution is highly appreciated.
thanks

@fregattegit What type of USB Z-wave dongle are you using? Hass seems to be brocken for Z-wave since 0.87 :-1:

@liske
I am using also the Aeotec Z-Stick Gen5.
I restored to 0.88.2 and at least I now have my nodes back and the NUC is running since 12 hours now. Also hass can be restarted without loosing my nodes (up to now).
Will not touch any upgrade and will not add any further zwave items up to now to monitor the situation.
Thinking also about "rolling back" to RPi for now as the issue seems to be related to the NUC/Docker.

So everybody(?) using (rebranded) Aeotec Z-Sticks are affected - but it might also be biased due to a high number of users.
On 0.91.3 all nodes did disappear over time except the root node. Downgrading to 0.80.3 did recover all nodes for me.
@fregattegit it would nice to if your nodes are still available after some days. I've reviewed the comments and collected all reports (for multiple days) about (non-)working hass releases and would not expect that Z-wave on 0.88 ist stable for a longer time:

0.80 python_openzwave==0.4.9 :+1: @liske
0.81 python_openzwave==0.4.10 :-1: @anaxyd
0.82 homeassistant-pyozw==0.1.1
0.83 homeassistant-pyozw==0.1.1
0.84 homeassistant-pyozw==0.1.1
0.85 homeassistant-pyozw==0.1.2
0.86 homeassistant-pyozw==0.1.2
0.87 homeassistant-pyozw==0.1.2 :-1: @anaxyd
0.88 homeassistant-pyozw==0.1.2
0.89 homeassistant-pyozw==0.1.2
0.90 homeassistant-pyozw==0.1.2 :-1: @liske :-1: @brent20
0.91 homeassistant-pyozw==0.1.3 :-1: @fregattegit
dev: homeassistant-pyozw==0.1.4

I have got the feeling (but I am not 100% sure) that the "drama" begun when I added new nodes and startet to rename these in "Configuration / Entity Registry" (seems to be in the most recent release the only recommended way).
At the moment I am also faced with a couple of orphaned nodes and it seems to be impossible to get rid of these.

Don't know if it helps, but got a Aeotec USB Z-Stick too and have not had any issues with z-wave. Some big changes did happen in between with the versions. At some point i just removed my devices from HA and let it rediscover all my zwave devices. Since i named them it wasn't too much work. (and i have at least 50+ devices)

@riemers;
thanks for the info; are you running HA also in a NUC/docker environment (this seems to "trigger" the issue)?
Regarding the "rediscovery"; did you just delete core.device_registry and core.entity_registry and let HA read the entities stored in the z-wave stick through the next boot?

Yes, i deleted the entries and let HA read the stick again. I actually went from hassbian (on a nuc) to hassio (also on the nuc)
In regards to your orphaned nodes, i have had that in the past too. These are a real pain. If you don't have those devices laying around anymore (adding/removing them) then your in for some pain. Since removing them from zwcfg or from HA just makes them come back on restart of HA since the data is stored in the stick. I was lucky enough i could still power the orphaned devices to remove them.

That is interesting that you do not have any issues on your NUC/docker. Die you update HA regulary and have you been on the most recent release without problems?
Ok, thanks for the info on the deleting; may be I have to go this route as well; I will wait for 0.92 and than update again; according to rumors there will be a improvement on the z-wave side in 0.92.
Concerning the orphaned nodes unpairing did not work for me. I had to restore to 0.88 and all new nodes I added between 0.88 and 0.91 are not in the HA "database" but are on the Z-Wave stick. That's why there is some inconsstency between HA and the stick.
I thought about trying the aerotec z-wave tool and deleting the nodes in the stick.
In regards of stability of 0.88 at the moment my z-wave network is stable. No issues so far.

I did update HA pretty regular without any issues.
Don't forget that if you have dead nodes. It can screw up your setup alot. In my case i had 1 dead node and it took a whoping 30 minutes before it had a working network (which was responding quickly)
So you can always turn it on, wait for a day or so. If all seems to be working then without to much hassle then it is a problem with your dead nodes.
Actually made a post about my findings: https://community.home-assistant.io/t/z-wave-dropping-command-slow-startup-long-hickups-troubleshooting/50112

thanks for the follow up and for the link and your findings; very educational. So far my Z-Wave network is quite responsive (with aboutish 40 nodes) so nor urgent need to optimize everything but on a rainy weekend I might consider this (including renaiming the nodes within the Z-Wave UI).
Thanks again!!

Do note, renaming is not something you should do anymore. Since you can use the registry for that. Do hope that if you do it again or something similar the issues will be resolved for people.

I made today a first try to (re)generate my nodes new  through deleting the zwcfgXXX.xml file.
After a new start of HA the zwcfgxxxx.xml file gets (at least in my case) populated with just very few entities.
This is kind of logical as a big part of the devices and entities is also stored in the .storage folder.
It seems to be that the files core.device_registry and core.entity_registry also need to be deleted.
But if you do that, you really are starting from scratch and this is a lot of work (depending on the quantity of your entities) as all your entities (not just the zwave ones) are lost.
So I did not go this route and restored from a last snapshot.
Rebuilding the zwave entities with one of the more recent HA releases seems to be even more complicated as the entity information is stored in several files. This design in general seems to be quite fragile.

The moment i had that issue, was still before the whole lovelace was introduced. Back then i had all those things in config files which you don't have anymore (i did stop updating my configs pretty quickly once i found the configure ui part)
But if you only want to delete your z-wave devices and since you are on hassio you could try this
hhass-cli entity list|grep ^zwave | while read id rest; do hass-cli entity delete $id; done
This should delete only your z-wave devices.

Thanks for the command line script; will go that route once my zwave network gets again messed up; at the moment I try to keep it as it is (never touch a running system); as I do have minimum 15 Z-Wave units behind wall switches the repairing will be a huge effort; but I have to go this route once it needs to be done. Hopefully at this moment the Z-wave UI will be improved (also in terms of renaiming of sub nodes if the main node gets renaimed).

If you start fresh and rename them in the gui it will remember that for you. Don't use any tools outside HA anymore. Do keep in mind, there is a bug in the current version which does not allow for renaming directly (only via settings) so thats a pain if you start from scratch. Wait for the next version with the fix ;)
Only thing that still bothers me, if i change the main node, i have to rename all the other nodes too. For some TL;DR https://community.home-assistant.io/t/what-is-the-preferred-way-to-rename-z-wave-entities/64329/158

just to give a brief follow up; updated to 0.92.2 aboutisch 1 week ago; running so far fine; apart that after a HA restart I need sometimes to re-restart and maybe re re restart to get the z-wave entities up and running. But up to now I was getting the z-wave network up without restoring a snapshot. Not sure if the nuc / docker is too fast for HA or what the issue is.

Also perhaps look into the hassio addon zwave2mqtt. Then you never restart the zwave stack with a restart of HA. Still playing with it too, but time is an issue for me atm.

@riemers,
thanks for the info; I also do not have that much time and HA can be quite time consuming; but will keep this recommondation in mind; there is also the possibility to keep HA on the nuc and have the z-wave stick on a RPI so that the z-wave network keeps running even on restarts; but never tried this.

New observation from me:
Suddenly after a restart of hass, all my z-wave nodes disappeared again, only a few were appearing. This were on 0.83.4, which I have had running fine for several months now. Tried restarting, restoring, even tried deleting failed z-wave nodes with 3rd party program, same issue. At last tried installing latest hass version 0.91.3, and then everything worked as it should. Weird!
Now I am finally running latest version of hass on my NUC without problems so far (knock on wood).

I'm on HA 97.2 with an AEON labs zw090 z stick gen 5 US and just started having this issue as presented by OP.


Menu not positioned correctly inside scrollview

When this menu is inside a scrollview, it works fine on the initial load, but once tapped after you've scrolled within its container, it does not position correctly.
Example:

Hi danleveille,
My solution is put  outside the
<MenuContext>
  <ScrollView>
   ... your stuff here
     <Menu>
      ... your menu trigger and options
      </Menu>
  </ScrollView>
</MenuContext>

after scrolled, the menu still appear near your menu trigger.

in MenuContext give lazy render={200} , what ever you give the allignment it's fixed


prezto-grunt-cache.501.zsh:37: command not found: compdef

Description
Each time I start a new session with ZSH this error comes up.
Expected behavior
No error upon new ZSH session at all.
Actual behavior
This:
└─( 3 ) ❱❱❱ zsh                                                                                130 ⏎  +541 11:36 ❰─┘
/var/folders/g0/jzp533fj51n7987tgt94zn_w0000gn/T//prezto-grunt-cache.501.zsh:37: command not found: compdef

Steps to Reproduce

Git pull latest from prezto
Type zsh
Booom! Above error gets printed.

Versions

Prezto commit:

commit 0e6429da97876c7ce0868966e8a812c29bcba0b3 (HEAD -> master, origin/master, origin/HEAD)
Author: Diego Rabatone Oliveira<EMAIL_ADDRESS>Date:   Mon Dec 17 16:22:33 2018 -0200

    Remove duplicated information from git module README (#1657)

ZSH version:

└─( 4 ) ❱❱❱ zsh --version                                                                                130 ⏎  +544 12:13 ❰─┘
zsh 5.6.2 (x86_64-apple-darwin17.7.0)

OS information:

macOS High Sierra
Version 10.13.6

In my case, loading the node module after the completion did the trick! ☺


Remove gameservices workarounds from CI scripts

Some of our CI scripts build against "latest version in vcpkg", or "latest release". These versions still have the gameservices code, burt the quickstart is gone.  We need to remove the workarounds after the outside world catches up.

This is fixed. Partly because we removed some builds as part of the migration out of Kokoro.  Partly because we are long past the point where the workarounds would be needed.


color of label different color to ui-text.

Current Behavior
The label of the LED has a different color then the label of the ui-text.

Expected Behavior
The label of the LED and the label of a ui-text shall have the same color.
Steps To Reproduce
No response
Environment

Node-RED Dashboard 2.0 version: 1.6.1
Node-RED version: 4.0.0-beta1
Node.js version:
Platform/OS: RasperrypiOs
Browser: Firefox

Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

This is fixed by https://github.com/FlowFuse/node-red-dashboard-2-ui-led/pull/7

Closed by https://github.com/FlowFuse/node-red-dashboard-2-ui-led/pull/7


Deploy failed since latest update

Hi I have used your great github-wiki-action since a while and was working great but today I go fail
Initialized empty Git repository in /github/workspace/temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae/.git/
From https://github.com/luc-github/ESP3D.wiki
 * branch            HEAD       -> FETCH_HEAD
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

....
sent 20,126,623 bytes  received 2,376 bytes  40,257,998.00 bytes/sec
total size is 20,113,421  speedup is 1.00
rm: can't remove 'temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae/a': No such file or directory
rm: can't remove 'temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae/b.md': No such file or directory
Pushing to Wiki
fatal: unsafe repository ('/github/workspace/temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace/temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae
fatal: unsafe repository ('/github/workspace/temp_wiki_ac3a8d28ad5db91287796de8b84dc1f9448a4bae' is owned by someone else)
To add an exception for this directory, call:

I feel it is linked to https://github.com/Andrew-Chen-Wang/github-wiki-action/commit/194d37ff03f5220e1baf7eb9d7c7ad7f3e1db30c but I do not understand how to solve the issue reading the log neither reading the change log:
Add global config option to make our clone directory "safe" what is and where should I put this global option
Sorry to bother you

Ok my mistake I missed the
uses: Andrew-Chen-Wang/github-wiki-action@v3
I was still using the v2
updating to v3 solved the issue - thank you for your great tool


An exception occured while trying to issue the HTTP call ??

Even with the simple example (bellow) I alway receive the error An exception occured while trying to issue the HTTP call
How can I debug this issue?
        public static async Task<string> MyInfo()
        {
            try
            {
                Log.Info($"Connecting to OVH...");
                Client client = new Client();
                Log.Info($"Connected");
                PartialMe me = await client.GetAsync<PartialMe>("/me");
                Log.Info($"Hello {me.firstname}!");
                return me.firstname;
            }
            catch (Exception ex)
            {
                Log.Warn(ex.Message);
                return null;
            }
        }

I have a .ovh.conf file

The problem was TLS.  by default Visual Studio is not using TLS12 as the first option.
Please change the constructor in Client.cs to:
        public Client(string endpoint = null, string applicationKey = null,
            string applicationSecret = null, string consumerKey = null,
            TimeSpan? defaultTimeout = null, char parameterSeparator = ',',
            HttpClient httpClient = null, string confFileName = ".ovh.conf") : this()
        {
            LoadConfiguration(endpoint, applicationKey, applicationSecret, consumerKey, parameterSeparator, confFileName);
            _defaultTimeout = defaultTimeout ?? _defaultTimeout;

            //specify to use TLS 1.2 as default connection
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

            _httpClient = httpClient ?? _httpClient ?? new HttpClient(handler);
        }

Quick fix solution for the current version
        /// <summary>
        /// Customise our client.
        /// </summary>
        /// <returns></returns>
        internal static Client NoProxyClient()
        {
            //specify to use TLS 1.2 as default connection, otherwise it will not work...
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

            //Remove Proxy, In my case we have a proxy in the LAN
            HttpClientHandler handler = new HttpClientHandler
            {
                UseProxy = false
            };

            var httpClient = new HttpClient(handler);
            return new Client(null,null,null,null,null,',',httpClient);
        }

        public static async Task<string> MyInfo()
        {

            Client client = NoProxyClient();

            string me = await client.GetAsync("/me");
            return me;

        }

Hello,
Thanks for opening an issue, and for your investigation!
I could not reproduce on my side, using a .NET Core 3.1 console application running on Windows 10 20H2. Looking at the documentation, starting with .NET Framework 4.7, it seems this configuration depends on the system:

Are you using an older framework?
Are you using a Windows version that don't have it enabled?

In any case, ServicePointManager.SecurityProtocol alters the whole process, therefore we should not manipulate it from inside the library as per Microsoft recommendations. However, you can apply that change in your own code if this is an acceptable solution for you.

I had the problem while debuging using Visual Studio  2017 in a windows 10 on a WebProject with for NetFramework 4.6.2.
The fault is probably because of the IIS Express used by VS in debug.
Just want to add that the code is clean and well comented, well done.

The problem is VS in debug mode using the IIS Express.


Refactor Editor Container

Changes
This PR makes a number of changes to the EditorContainer component.

Addresses the issues outline in #630.
Migrates away from class based to functional React syntax as outlined in the contributing docs.

Testing
Component functionality has been tested in standalone and storybook.

I noticed the use of React.cloneElement. The React Docs strong urge against using it. I'm looking into the other ways they give. Are there any prefernces? @GerardasB.

I noticed the use of React.cloneElement. The React Docs strongly urge against using it. I'm looking into the other ways they give. Are there any prefernces?

Not sure if we can do much w/o breaking existing editors. I'd leave it as a separate task for later.

Ok sweet! I can make a separate issue


[excel] (Workbook, Table, PivotTable) New slicer and add table/PivotTable samples

Docs Build status updates of commit a5ce8da:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/docs-ref-autogen/excel/excelscript/excelscript.slicer.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.workbook.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.worksheet.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/sample-scripts/excel-scripts.yaml
:white_check_mark:Succeeded

generate-docs/json/excel/snippets.yaml
:white_check_mark:Succeeded

generate-docs/package-lock.json
:white_check_mark:Succeeded

generate-docs/scripts/package-lock.json
:white_check_mark:Succeeded

generate-docs/tools/API Coverage Report.csv
:white_check_mark:Succeeded

generate-docs/tools/package-lock.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Footer Test

Adding Test for Footer.
Changes

Added 'test/browser_tests/page_components/footer.js'  to add footer component.
Added 'test/browser_tests/spec_suites/shared/shared_footer.js' to add footer tests.

Test

Run 'grunt build && protractor ./test/browser_tests/conf.js'

Notes

@anselmbradford had to disable the max-nested-callbacks rule.

Review
@jimmynotjim
@anselmbradford
@KimberlyMunoz
@imuchnik

:+1:

:+1:

:+1:


word2html don't work

when I run word2html 1.docx I get an error
RuntimeError: Invalid input format! Got "docx" but expected one of these: docbook, haddock, html, json, latex, markdown, markdown_github, markdown_mmd, markdown_phpextra, markdown_strict, mediawiki, native, opml, rst, textile

Hi, thanks for opening the Issue. Can you answer the following?

What version of pandoc do you have installed? (run pandoc -v)
Check the supported versions of pypandoc: python -c "import pypandoc; print(pypandoc.get_pandoc_formats()[0])". If you don't see docx in that list, then for some reason your version of pandoc doesn't know how to read Word documents.
Just for completeness, what version of python and which operating system are you using?

This project (word2html) is just a convenient wrapper around pypandoc, which is a python wrapper around pandoc. If either of those aren't working, then this project won't work either. Hopefully the above can help me troubleshoot this with you.

Hi

pandoc <IP_ADDRESS>
$ python -c "import pypandoc; print(pypandoc.get_pandoc_formats()[0])"
[u'docbook', u'haddock', u'html', u'json', u'latex', u'markdown', u'markdown_github', u'markdown_mmd', u'markdown_phpextra', u'markdown_strict', u'mediawiki', u'native', u'opml', u'rst', u'textile']
Python 2.7.5, CentOS Linux release 7.3.1611

Well, your version of pandoc is a little old (the current is 1.19.2.x), and it definitely doesn't support reading .docx files. (otherwise you'd see that in the list ouput in step 2).
I'm not 100% sure how to fix this. Any chance you could try upgrading pandoc to see if that works?

Since I think this is a problem with the pandoc, and not word2html directly, I'm closing this issue. Feel free to reopen if this doesn't work with a pandoc version that supports .docx files.


electron cannot open display when running orca --help (Ubuntu)

Hi, am running Ubuntu 18.04 and am trying to install orca. It is installed, but I can't get it to work. I have followed the instructions and also looked at previous issues, but it hasn't helped.
I have installed these in ubuntu:
sudo apt-get install nodejs-dev node-gyp libssl1.0-dev
apt install npm
npm install -g<EMAIL_ADDRESS>orca
sudo apt-get install xvfb

Looking at the location:
root@cmcapvm01:~# which orca
/usr/local/bin/orca
root@cmcapvm01:~# orca --help

(electron:7505): Gtk-WARNING **: 00:58:35.738: cannot open display: :0

And testing the export: https://plotly.com/r/static-image-export/
library(plotly)

if (!require("processx")) install.packages("processx")
fig <- plot_ly(z = ~volcano) %>% add_surface()
orca(fig, "surface-plot.svg")

Error: The orca command-line utility is required for this functionality.

Please follow the installation instructions here -- https://github.com/plotly/orca#installation

I have also tried the headless server configuration:
$ sudo apt-get install xvfb

#!/bin/bash
xvfb-run -a /path/to/orca-X.Y.Z-x86_64.AppImage "$@"

But it still doesn't run.

Hi @williamlai2, any solution to it? I am having the same issue

No, I haven't found a solution to it yet.


Rebuild PyTorch and ONNX Serve Docker Images

For #129 this fix, we should update the docker images in the Docker Hub
Fixed CUDA Version
We should also fix the CUDA version in those two docker images. Currently our benchmarking uses CUDA version 10.0.130 in TensorFlow/Serving and TensorRT Server, the ONNX and PyTorch serve Docker images should keep the same.
You can FROM a base 10.0-cudnn7-tensorrt7-devel-ubuntu16.04 (cuda 10.0.130, nccl 2.6.4, cudnn <IP_ADDRESS> tensorrt <IP_ADDRESS>) image to build the image.

Updated new docker images for PyTorch Serving and ONNX Serving:
Pull docker images with CUDA version 10.0 by:
PyTorch:
docker pull mlmodelci/pytorch-serving:10.0

ONNX:
docker pull mlmodelci/pytorch-serving:10.0

You can check if the new builds work for your benchmarking @huangyz0918


Small renamings

The namings between QSolver, SolverOption (referred externally as solver) and AdaptiveSolver was a bit confusing, we now have three objects:

QSolver: implements a quantum solver.
AdaptiveODESolver: class which has nothing to do with a QSolver used by the adaptive ODE QSolver.
SolverOption: internal name for QSolver options, external exposed name is still solver (in sesolve and mesolve APIS and for imports).

There we go 🤓 Now, what do you think about renaming QSolver to simply Solver? (@abocquet and @gautierronan) We always refer to a QSolver object as the solver in the comment and in the doc, and I don't think it's necessary to precise it's a quantum solver (if this even has a meaning), as long as we give a clear name to the other kind of solvers (ode_solver for ODE solvers for instance).

Haha are you making proposals incrementally so we are more likely to agree? :D
In any case I'm fine with this renaming, it doesn't really matter for end users anyway !

Haha are you making proposals incrementally so we are more likely to agree? :D

Hahaha no it's just that I think about them too late 😅


a.without(1) vs a.without('1')

a.set(1, 2)
a.without(1) does not work, but '1' works.

This is because JavaScript objects only use strings for keys, not numbers.

But a[1] and a['1'] both work, how do you explain?

JavaScript treats a[1] as the same as a["1"] when a is an object.


Tutorial 3 - Adding a new Command,tutorial-adding-command

Tutorial 3 - Adding a new Command, tutorial-adding-command

Codecov Report

Merging #20 (40d9cad) into master (fa7d9fc) will increase coverage by 0.93%.
The diff coverage is 94.91%.

@@             Coverage Diff              @@
##             master      #20      +/-   ##
============================================
+ Coverage     72.15%   73.09%   +0.93%
- Complexity      399      420      +21
============================================
  Files            70       73       +3
  Lines          1232     1286      +54
  Branches        125      131       +6
============================================
+ Hits            889      940      +51
- Misses          311      313       +2
- Partials         32       33       +1

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/seedu/address/ui/PersonCard.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...c/main/java/seedu/address/model/person/Remark.java
75.00% <75.00%> (ø)
4.00 <4.00> (?)

...java/seedu/address/logic/commands/EditCommand.java
97.05% <100.00%> (+0.04%)
12.00 <0.00> (ø)

...va/seedu/address/logic/commands/RemarkCommand.java
100.00% <100.00%> (ø)
11.00 <11.00> (?)

...a/seedu/address/logic/parser/AddCommandParser.java
100.00% <100.00%> (ø)
5.00 <0.00> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
100.00% <100.00%> (ø)
13.00 <0.00> (+1.00)

...ain/java/seedu/address/logic/parser/CliSyntax.java
85.71% <100.00%> (+2.38%)
1.00 <0.00> (ø)

...eedu/address/logic/parser/RemarkCommandParser.java
100.00% <100.00%> (ø)
2.00 <2.00> (?)

...c/main/java/seedu/address/model/person/Person.java
97.72% <100.00%> (+0.10%)
21.00 <1.00> (+1.00)

.../java/seedu/address/model/util/SampleDataUtil.java
25.00% <100.00%> (+5.00%)
2.00 <1.00> (+1.00)

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa7d9fc...40d9cad. Read the comment docs.


Convert modules.py to tinygrad

Hi,
Great that you're working on the modules.py! Are you leaving the dependencies as they are for now? For example, the utils? If so, I can try to start working on that!

That sounds great! Thanks!


banglejs2: altimeter broken after extended use

Affected hardware version
Bangle 2
Your firmware version
2v19
The bug
After extensive use, altimeter locked up. Unfortunately, neither reboot nor complete draining of battery fixed the issue. After some more experiments, google revealed following snippet:
{
  // Show the menu
  E.showMenu({
    "" : { "title" : "Barometer reset" },
    "Reset" : () => {
      if (Bangle.barometerRd(0x0D) == 16) {
        Bangle.barometerWr(0x0c, 9);
        E.reboot();
      }
      back();
    },
  });
}

Which indeed fixed the issue. I believe we should be reseting barometer at each boot, working with persistent issues is not fun.
Installed apps
No response

Yes - I believe this is a duplicate of #3086 and I guess you found the code from the forum post? I'll close this as a duplicate but feel free to reopen or comment on the other issue if you see problems after the changes listed there


when applying  the model.fuse(), the processing of torchscript export fail.  (how to accelerate the model inference ？)

Maybe you can raise this issue in the yolov5 python repo, thanks


vkquake: 1.04.1 -> 1.05.0

Motivation for this change
Removed patch. cc @peterhoeg
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@peterhoeg @FRidh Thanks!

Result of nixpkgs-review pr 102331 run on x86_64-linux 1

1 package failed to build:

vkquake

Result of nixpkgs-review pr 102331 1

1 package built:

vkquake

Not sure why my build failed.


Throw an error when EMAIL_HOST_USER is specified but not email_password

As a convenience (from someone who was misreading zulip/zulip-secrets.conf as zulip/secrets.conf), it would be nice to see an error message when EMAIL_HOST_USER is specified but the password is missing in the secrets file.

@zulipbot claim.

This seems useful and likely easy.  I think perhaps we'd want to change this function to add an additional check after the loop?  Not sure.  @mateuszmandera FYI.
def check_config() -> None:
    for (setting_name, default) in settings.REQUIRED_SETTINGS:
        # if required setting is the same as default OR is not found in settings,
        # throw error to add/set that setting in config
        try:
            if settings.__getattr__(setting_name) != default:
                continue
        except AttributeError:
            pass

        raise CommandError(f"Error: You must set {setting_name} in /etc/zulip/settings.py.")

@timabbott Hmm, though this only gets called in manage.py checkconfig (and for some reason in register_server) - so I'm not sure how many admins actually utilize that command, especially since we don't particularly advertize it (on in management-commands.md). Also called in initialize-database, but that runs only once, during installation, so it's not useful for this issue either.
I'm wondering if it wouldn't make sense to add some kind of check_config() function that's called in zproject/settings.py after the setting imports, that could be generally used for putting all sorts of assertions in it for validating that settings make sense?:
from .configured_settings import *  # noqa: F401,F403 isort: skip
from .computed_settings import *  # noqa: F401,F403 isort: skip

check_config()
# Do not add any code after these wildcard imports!  Add it to
# computed_settings instead.

Checks like this are a little complicated because they can fire when the server process starts up.  If we add anything like this, we need to make sure that we start running check_config in restart_server so that we can abort with a clear admin-visible error message before the restart, so they aren't left wondering and having to log-dive for why uwsgi isn't coming up cleanly.

@alexmv Would logging.error in the hypothetical check_config function solve this concern? (as opposed to hard AssertionErrors)

That pushes it back into "is this visible enough" since it's only going to show up if folks check their logs.  If you're running the check at startup, that also means it's going to show up in the logs at random intervals when uwsgi processes get (re)started.
We might be better off doing this sort of check, with a logging.error, when we're trying to send an email -- rather than trying to do it at "start time," which is not well-defined and not always an interactive process.

Logging an error on email send makes sense to me.
-Tim Abbott (mobile)
On Tue, Feb 1, 2022, 14:21 Alex Vandiver @.***> wrote:

That pushes it back into "is this visible enough" since it's only going to
show up if folks check their logs. If you're running the check at startup,
that also means it's going to show up in the logs at random intervals when
uwsgi processes get (re)started.
We might be better off doing this sort of check, with a logging.error,
when we're trying to send an email -- rather than trying to do it at "start
time," which is not well-defined and not always an interactive process.
—
Reply to this email directly, view it on GitHub
https://github.com/zulip/zulip/issues/20132#issuecomment-1027345167, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAU6NWQ2KKAALE65FXCSFF3UZBMHFANCNFSM5HFHVLCQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


No tests found on Windows with Jenkins

Is this a bug report?
Yes
Did you try recovering your dependencies?
Yes
Which terms did you search for in User Guide?
test
Environment
From npx create-react-app --info:
(node:2604) UnhandledPromiseRejectionWarning: Error: The system cannot find the path specified.
System:
OS: Microsoft Windows Version 10.0.14393
CPU: x64 Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
Binaries:
Node: 10.13.0
npm: 6.4.1
npmPackages:
"@coreui/coreui": "^2.1.1",
    "@coreui/icons": "0.3.0",
    "@coreui/react": "^2.1.0",
    "bootstrap": "^4.1.3",
    "classnames": "^2.2.6",
    "flag-icon-css": "^3.2.1",
    "font-awesome": "^4.7.0",
    "node-sass": "^4.10.0",
    "prop-types": "^15.6.2",
    "react": "^16.6.1",
    "react-dom": "^16.6.1",
    "react-helmet": "5.2.0",
    "react-loadable": "^5.5.0",
    "react-redux": "^5.1.0",
    "react-router-bootstrap": "^0.24.4",
    "react-router-dom": "^4.3.1",
    "react-router-redux": "^5.0.0-alpha.8",
    "react-scripts": "2.1.1",
    "reactstrap": "^6.5.0",
    "redux": "^4.0.1",
    "redux-immutable": "4.0.0",
    "redux-thunk": "^2.3.0",
    "rimraf": "^2.6.2",
    "simple-line-icons": "^2.4.1"

Steps to Reproduce

Write test file and save it in src folder as App.test.js
npm run react-scripts test --env=jsdom --no-watchman
or
npm react-scripts test --env=jsdom --coverage

Reproduction repository: https://github.com/Saibamen/react_test
Expected Behavior
Tests should be executed
Actual Behavior
No tests found
react-scripts test --env=jsdom --no-watchman
00:02:06.736
00:02:11.011 No tests found
00:02:11.011 In C:\Program Files (x86)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp
00:02:11.011   50 files checked.
00:02:11.011   testMatch: C:\Program Files \(x86\)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp\src\**\__tests__\**\*.{js,jsx,ts,tsx},C:\Program Files \(x86\)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp\src\**\?(*.)(spec|test).{js,jsx,ts,tsx} - 0 matches
00:02:11.011   testPathIgnorePatterns: \\node_modules\\ - 50 matches
00:02:11.011 Pattern:  - 0 matches
00:02:11.045 npm ERR! code ELIFECYCLE
00:02:11.046 npm ERR! errno 1
00:02:11.048 npm ERR<EMAIL_ADDRESS>test:ci: `react-scripts test --env=jsdom --no-watchman`
00:02:11.049 npm ERR! Exit status 1
00:02:11.049 npm ERR!
00:02:11.049 npm ERR! Failed at the<EMAIL_ADDRESS>test:ci script.
00:02:11.050 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
00:02:11.086
00:02:11.087 npm ERR!      C:\Users\jenkins\AppData\Roaming\npm-cache\_logs\2018-11-30T12_24_24_901Z-debug.log
00:02:11.109 Build step 'Execute Windows batch command' marked build as failure

Reproduction repository: https://github.com/Saibamen/react_test

Same.

activity mode on :P

Same happens to me with 2.1.8

Also running into the same issue.

still happens...

Install yarn globally in your stages work for me,
stages {
stage('Prepare') {
steps {
sh "npm install -g yarn"
}
}
}

has there been a fix for this?

Ran into the same issue on Windows Jenkins today. Any fix or update for this?

This works for me: https://stackoverflow.com/questions/60604572/react-jest-no-tests-found-exiting-with-code-0
I used yarn test --watchAll=false --testMatch **/src/**/*.test.js on Windows Jenkins, and it works!


dart2wasm: Failed null check at ClosureRepresentation.fieldIndexForSignature on a statically typed constructor tearoff expression

I get a compilation error when compiling to wasm with flutter build web --wasm --release (that I don't get with other compilation targets.) (I use a flutter command but the error happens in the dart2wasm library, so I'm posting the issue here.)
The error is:
Target dart2wasm failed: ProcessException: Process exited abnormally with exit code 64:
*NOTE*: Compilation to WasmGC is experimental.
The support may change, or be removed, with no advance notice.

Exception in ConstantExpression at [...]:70:21

Unhandled exception:
Null check operator used on a null value

Stack trace:

#0      ClosureRepresentation.fieldIndexForSignature (package:dart2wasm/closures.dart:112)
#1      ConstantCreator.visitInstantiationConstant.<anonymous closure>.fillVtableEntry (package:dart2wasm/constants.dart:725)
#2      ConstantCreator.visitInstantiationConstant.<anonymous closure>.makeVtable (package:dart2wasm/constants.dart:749)
#3      ConstantCreator.visitInstantiationConstant.<anonymous closure> (package:dart2wasm/constants.dart:765)
#4      ConstantCreator.createConstant (package:dart2wasm/constants.dart:285)
#5      ConstantCreator.visitInstantiationConstant (package:dart2wasm/constants.dart:698)
#6      InstantiationConstant.accept (package:kernel/ast.dart:14209)
#7      ConstantCreator.ensureConstant (package:dart2wasm/constants.dart:252)
#8      ConstantInstantiator.defaultConstant (package:dart2wasm/constants.dart:137)
#9      ConstantVisitorDefaultMixin.visitStaticTearOffConstant (package:kernel/visitor.dart:944)
#10     InstantiationConstant.accept (package:kernel/ast.dart:14209)
#11     ConstantInstantiator.instantiate (package:dart2wasm/constants.dart:121)
#12     Constants.instantiateConstant (package:dart2wasm/constants.dart:103)
#13     CodeGenerator.visitConstantExpression (package:dart2wasm/code_generator.dart:2841)
#14     ConstantExpression.accept1 (package:kernel/ast.dart:8707)
#15     CodeGenerator.wrap (package:dart2wasm/code_generator.dart:852)
#16     CodeGenerator.visitRecordLiteral (package:dart2wasm/code_generator.dart:3086)
#17     RecordLiteral.accept1 (package:kernel/ast.dart:8490)
#18     CodeGenerator.wrap (package:dart2wasm/code_generator.dart:852)
#19     CodeGenerator.visitLet (package:dart2wasm/code_generator.dart:1669)
#20     Let.accept1 (package:kernel/ast.dart:8775)
#21     CodeGenerator.wrap (package:dart2wasm/code_generator.dart:852)
#22     CodeGenerator.visitLet (package:dart2wasm/code_generator.dart:1669)
#23     Let.accept1 (package:kernel/ast.dart:8775)
#24     CodeGenerator.wrap (package:dart2wasm/code_generator.dart:852)
#25     CodeGenerator.visitMapLiteral.<anonymous closure> (package:dart2wasm/code_generator.dart:2956)
#26     Translator.makeArray (package:dart2wasm/translator.dart:1025)
#27     CodeGenerator.makeArray (package:dart2wasm/code_generator.dart:2921)
#28     CodeGenerator.visitMapLiteral (package:dart2wasm/code_generator.dart:2949)
#29     MapLiteral.accept1 (package:kernel/ast.dart:8341)
#30     CodeGenerator.wrap (package:dart2wasm/code_generator.dart:852)
#31     CodeGenerator.visitVariableDeclaration (package:dart2wasm/code_generator.dart:1020)
#32     VariableDeclaration.accept (package:kernel/ast.dart:10791)
#33     CodeGenerator.visitStatement (package:dart2wasm/code_generator.dart:863)
#34     CodeGenerator.visitBlock (package:dart2wasm/code_generator.dart:983)
#35     Block.accept (package:kernel/ast.dart:9247)
#36     CodeGenerator.visitStatement (package:dart2wasm/code_generator.dart:863)
#37     CodeGenerator.generateBody (package:dart2wasm/code_generator.dart:557)
#38     CodeGenerator.generate (package:dart2wasm/code_generator.dart:236)
#39     Translator.translate (package:dart2wasm/translator.dart:374)
#40     compileToModule (package:dart2wasm/compile.dart:188)
<asynchronous suspension>
#41     generateWasm (package:dart2wasm/generate_wasm.dart:24)
<asynchronous suspension>
#42     main (file:///C:/b/s/w/ir/x/w/sdk/pkg/dart2wasm/bin/dart2wasm.dart:10)
<asynchronous suspension>

I've tried to write a minimal reproducible example from scratch, but I haven't succeeded, so I'll show my actual code.
The culprit of this exception, as pointed out by the error, seems to be this tearoff expression:
final Map<Type, _TypeConfig> typesConfig = {
      // [...]
      Habit: (
        enabled: isSubtype<Habit, C>(),
        typeInfo: CommitmentTypeInfo(
          name: "Habit",
          icon: Habit.icon_,
          orderKey: DiscreteHabit.commitmentTypeInfo.orderKey,
          fromMapFactory: (map) => throw UnimplementedError(),
        ),
        editScreen: EditHabit.blank   // ERROR: this is the constant expression that causes the error
      ),
     // [...]
    };

I have the following typedefs:
typedef _EditPageBuilder<C extends Commitment> = Widget Function({
  CompositeCommitment<C>? parentCommitment,
  Function(C)? onEdited,
});

typedef _TypeConfig<C extends Commitment> = ({
  bool enabled,
  CommitmentTypeInfo typeInfo,
  _EditPageBuilder<C> editScreen,
});

The problem disappears when I set:
typedef _EditPageBuilder<C extends Commitment> = dynamic;

Related code (definition of EditHabit.blank):

class EditHabit<H extends Habit> extends EditCommitment<H> {
  // [...]

  EditHabit.blank({
    super.key,
    super.parentCommitment,
    super.onEdited,
  }) : super.blank(
          commitmentTypeInfo: DiscreteHabit.commitmentTypeInfo,
          titleHintText: titleHint,
        );

  // [...]
}

abstract class EditCommitment<C extends Commitment> extends Edit<C> {
  // [...]

  /// For creating a new commitment.
  const EditCommitment.blank({
    super.key,
    required CommitmentTypeInfo commitmentTypeInfo,
    required super.titleHintText,
    this.parentCommitment,
    super.onEdited,
  })  : _commitmentTypeInfo = commitmentTypeInfo,
        super.blank();

  // Should be CompositeCommitment<C> but Dart forces the type parameter to be
  // covariant, which is not desirable here.
  final CompositeCommitment? parentCommitment;

  // [...]
}

abstract class Edit<O extends CommitmentStoreObjectSnapshot>
    extends ConsumerStatefulWidget {
  // [...]

  const Edit.blank({
    super.key,
    required this.titleHintText,
    this.onEdited,
  }) : object = null;

  /// Called after the edit/creation has been successfully executed.
  final Function(O)? onEdited;

  // [...]
}

Surprisingly, I have other elements in the map above for which this error does not occur, in particular for EditTask.blank:

class EditTask extends EditCommitment<Task> {
  // [...]

  const EditTask.blank({
    super.parentCommitment,
    super.key,
    super.onEdited,
  }) : super.blank(
          commitmentTypeInfo: Task.commitmentTypeInfo,
          titleHintText: titleHint,
        );

  // [...]
}

I thought the difference might be in the const, but I haven't managed to make a minimal reproducible example. Maybe someone experienced with dart2wasm will be able to do so.

Dart version and tooling diagnostic info (dart info)

#### General info

- Dart 3.4.4 (stable) (Wed Jun 12 15:54:31 2024 +0000) on "windows_x64"
- on windows / "Windows 10 Home" 10.0 (Build 22631)
- locale is en-GB

#### Project info

- sdk constraint: '^3.4.0'
- dependencies: built_collection, cloud_firestore, collection, cupertino_icons, easy_debounce, equatable, firebase_auth, firebase_core, firebase_ui_auth, firebase_ui_oauth_google, flut
ter, flutter_fancy_tree_view, flutter_local_notifications, flutter_localizations, flutter_riverpod, flutter_speed_dial, flutter_timezone, google_sign_in, intersperse, intl, meta, modal_bottom_sheet, package_info_plus, quiver, rrule_generator, skeletonizer, sliver_tools, stream_transform, timezone, url_launcher
- dev_dependencies: custom_lint, flutter_launcher_icons, flutter_lints, flutter_test, riverpod_lint, test
- elided dependencies: 2

#### Process info

| Memory | CPU | Elapsed time | Command line |
| -----: | --: | -----------: | ------------ |
| 274 MB |  -- |              | dart.exe     |
|  30 MB |  -- |              | dart.exe     |
|   3 MB |  -- |              | dart.exe     |
| 476 MB |  -- |              | dart.exe     |
| 485 MB |  -- |              | dart.exe     |
|  94 MB |  -- |              | dart.exe     |
| 100 MB |  -- |              | dart.exe     |

Whether you are using Windows, macOS, or Linux (if applicable)
Windows

Whether you are using Chrome, Safari, Firefox, Edge (if applicable)
Chrome

I'm unable to reproduce the issue from the snippets. Is it possible to share the whole project with commands to run to get the error?

It's a private repo, maybe I can add you as a collaborator temporarily so you can access it?

@plammens Could you try to verify that this problem still happens when you're on flutter master channel?

The problem disappears when I set:
typedef _EditPageBuilder<C extends Commitment> = dynamic;

This is an indication that the issue is due to a partial instantiation of a tear-off constant, i.e. EditHabit is generic and will get its type argument filled in when EditHabit.blank is used in a context where one doesn't expect a generic function but one without type arguments, the language type inference.

I thought the difference might be in the const, but I haven't managed to make a minimal reproducible example. Maybe someone experienced with dart2wasm will be able to do so

The issue has to do with closure representations. Dart2wasm will try to make a good calling convention for closures. To do that it will look at a) all function definitions b) all function call sites. It then partitions them together into groups that have to be together (all possible definitions for a given callsite, all callsites for a definition) and based on those groups makes optimized vtables for fast closure calls.
If this issue still persists on flutter master channel, then we'll need a minimal reproduction we can look at (I've spent the entire morning looking through the relevant code and trying to construct cases that could trigger this, but failed to come up with an example where this would trigger).
What we need for a minimal reproduction is the code that creates those closures (class hierarchy, constructors and how the constructor tear-offs are used) and the code that invokes those closures. @plammens Could you try to make a minimal flutter app that reproduces this?

@plammens Could you try to verify that this problem still happens when you're on flutter master channel?

I can confirm that the issue is still there on master, flutter/flutter@e66ce1591f17e5e1c2b3310cf0a64c8a28b3fff5 .

```text
Flutter 3.24.0-1.0.pre.517 • channel master • https://github.com/flutter/flutter.git
Framework • revision e66ce1591f (16 minutes ago) • 2024-08-08 14:25:19 -0400
Engine • revision 387f6f3c5f
Tools • Dart 3.6.0 (build 3.6.0-129.0.dev) • DevTools 2.38.0
```

What we need for a minimal reproduction is the code that creates those closures (class hierarchy, constructors and how the constructor tear-offs are used) and the code that invokes those closures. @plammens Could you try to make a minimal flutter app that reproduces this?

I'll try again making a reproducible example, this time I'll try to work my way down from my actual code to a more minimal version instead of trying to build my way up.

I've used a script to put all my code in a single file to try to whittle it down to a minimal example, but it seems this is going to take forever because  many times I delete some code that seems completely unrelated and the error goes away. Plus I have to wait 60 seconds between each iteration due to having to run the command.
Currently gone from 10k lines of code to 7.5k. Is there any chance I can just send you the file privately and slap an open-source license on it? It's a personal project anyway.

I've used a script to put all my code in a single file to try to whittle it down to a minimal example, but it seems this is going to take forever because many times I delete some code that seems completely unrelated and the error goes away. Plus I have to wait 60 seconds between each iteration due to having to run the command.

We really appreciate the effort, @plammens !

Currently gone from 10k lines of code to 7.5k. Is there any chance I can just send you the file privately and slap an open-source license on it? It's a personal project anyway.

If it's under an open source license we can take a look - irrespective of how it's shared. You're welcome to share via email.

If it's under an open source license we can take a look - irrespective of how it's shared. You're welcome to share via email.

Okay, I've added a GPL license to the file. What email address should I send it to?
By the way, don't try to make too much sense of the code as it is now in a heavily mutilated state :)

Okay, I've added a GPL license to the file. What email address should I send it to? I'll also send the pubspec in case you need it.

You can send it to<EMAIL_ADDRESS>

You can send it to<EMAIL_ADDRESS>
Done, thanks!

@plammens Thank you very much for the reproduction!
The following test case reproduces the issue
void main() {
  final funs = <String Function({Object? shared})>[
    foo,
    bar,
  ];

  final one = int.parse('1');
  final barS = funs[one] as String Function({Object? barSpecific});
  if (barS(barSpecific: 1) != 'bar(null, 1)') {
    throw 'failed: ${barS(barSpecific: 1)}';
  }
}

String foo<T>({Object? shared, Object? fooSpecific}) =>
    'foo<$T>($shared, $fooSpecific)';

String bar({Object? shared, Object? barSpecific}) =>
    'bar($shared, $barSpecific)';

Fixed with f7fc4d037466a099000962f3f0eb20e01048e37c.

@plammens The fix should have rolled up all the way to flutter/flutter now.


[ISSUE #4182] optimization global plugin sort.

GLOBAL order set -1
PluginDTO sort add @Min(0)

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

@iwangjie pls check ci & resolve conflict

@iwangjie pls check ci & resolve conflict

ok.

Codecov Report

Merging #4429 (d2562ef) into master (0a777ec) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #4429      +/-   ##
============================================
+ Coverage     68.33%   68.38%   +0.04%
- Complexity     7607     7611       +4
============================================
  Files          1029     1029
  Lines         29403    29403
  Branches       2659     2659
============================================
+ Hits          20092    20106      +14
+ Misses         7720     7703      -17
- Partials       1591     1594       +3

Impacted Files
Coverage Δ

...a/org/apache/shenyu/admin/model/dto/PluginDTO.java
62.16% <ø> (ø)

...ava/org/apache/shenyu/common/enums/PluginEnum.java
100.00% <100.00%> (ø)

... and 5 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[WFLY-3471] JMSContext injection

fix JMSContext injection to use the correct CDI scope (request or
transaction) depending on the presence of a transaction.
Inject @RequestScoped and @TransactionScoped beans to let CDI handle
the bean lifecycle.
move injection code in the
org.wildfly.extension.messaging.activemq.deployment.injection package
add test asserting that a @RequestScoped injected JMSContext is
properly cleaned up at the end of the request

JIRA: https://issues.jboss.org/browse/WFLY-3471

retest this please

retest this please

@jmesnil Please advise ASAP if this should be for 10.1.

@bstansberry this is ok for 10.x


Suggestion: add option to retain blank lines

Since I love prettier so much, I have integrated it into my text editor (bbedit by barebones) as a text filter. This allows me to run it in context with a command key. I don't even try to maintain format while coding. I just hit prettier every fifteen minutes.
However, I use blank lines a lot to help me keep things organized visually. Since prettier does not retain blank lines, I have wrapped it in regular expressions to make blanks lines into comments that I later replace. With that, I get excellent prettier formatting and keep my blank lines.
It would be cooler if prettier had a switch like --retain-blank-lines
Of course, this might not be possible. If so, I have my regular expressions so I can continue to love prettier.

prettier should retain blank lines between lines (not at the top and bottom) and compresses blank lines to at most one. If you see cases where that's not the case, please let me know and we'll fix it :)
https://jlongster.github.io/prettier/#{"content"%3A"1\n\n2\n\n3\n\nfunction f() {\n  a\n  \n  b\n  \n  c\n  \n  d\n}"%2C"options"%3A{"printWidth"%3A80%2C"tabWidth"%3A2%2C"singleQuote"%3Afalse%2C"trailingComma"%3Afalse%2C"bracketSpacing"%3Atrue%2C"doc"%3Afalse}}

You describe the behavior I see but not what I am hoping for.
I often, while coding, set off the chunk I am working on with several blank lines before and after so I can easily see it when scrolling. Since my normal usage is to use prettier constantly, that multiple line grouping goes away. I suggest a switch so that I can keep them.
Maybe the use of blank lines for navigation is peculiar to me. As I say, I can work around it but thought it might be a common use case.
(ps, I also do have a key command that collapses the multiple lines when I am done. I'd have made a good VIM guy in another life. ;-) )

Can you set off the chunk you're working on with several lines of empty // comments instead? At least in my Vim setup, Vim automatically adds // to the next line when pressing Enter in a comment.

It seems for objects, prettier actually removes blank lines between properties. Is this intentional? (See https://jlongster.github.io/prettier/#{"content"%3A"const Blah %3D React.createClass({\n  propTypes%3A {\n    \n  }%2C\n\n  componentWillMount() {\n    \n  }\n})%22%2C%22options%22%3A%7B%22printWidth%22%3A80%2C%22tabWidth%22%3A2%2C%22singleQuote%22%3Atrue%2C%22trailingComma%22%3Atrue%2C%22bracketSpacing%22%3Atrue%2C%22doc%22%3Afalse%7D%7D)

@joefiorini I implemented preserving lines for arrays ( https://github.com/jlongster/prettier/pull/448 ) and @jlongster mentioned that we may not want to do it there. All the code I've tested prettier on is using es6 classes where new lines are preserved.
class C {
  propTypes() {

  }

  componentWillMount() {

  }
}

https://jlongster.github.io/prettier/#{"content"%3A"class C {\n  propTypes() {\n    \n  }\n\n  componentWillMount() {\n    \n  }\n}"%2C"options"%3A{"printWidth"%3A80%2C"tabWidth"%3A2%2C"singleQuote"%3Atrue%2C"trailingComma"%3Atrue%2C"bracketSpacing"%3Atrue%2C"doc"%3Afalse}}
I think that createClass is a good argument for preserving them for objects as well.

and compresses blank lines to at most one.

I used to think that way too, but users kept requesting more flexibility.  I originally had an option named preserve that took boolean values, which meant preserve 1 empty line when true or 0 when false.  Now the option takes numbers and the boolean values are converted to 1 and 0 respectively.  I found that various users used empty lines to separate sections of code with large separations for greater visual division of code sections.  This was a very minor enhancement to go from boolean to number values and it made my users happy without really sacrificing anything.

Hello, I was wondering if it possible to turn off empty lines with prettier when you use it in HTML ?

@linocatucci right now HTML is not very well supported with prettier. But the plan is to use the same rules as JSX there: at most one empty line is going to be preserved between children. Not before the first child and after the last one.

@vjeux thanks for the quick response.

I'm not sure what was decided here, but I have the same question / request as the OP. @prettydiff described the behavior I would love to see: have an option to allow prettier to preserve 'x' number of blank lines. However, unless I'm missing something, I don't think this is implemented and (imho) it should be...
In my time with prettier (which I love), it seems the whole point is making files more readable ("prettier"), so being able to preserve multiple blank lines, if desired, falls in line with its purpose and really should be supported. Especially when you have larger files, being able to highlight or separate sections with multiple lines of whitespace is extremely helpful in making the file "prettier" and more readable. And if it's a configurable option, you're not sacrificing or losing anything to get there.
Again, love prettier, thank you!

@thezimme It was decided to stick with the current "at most one blank line in a row" rule, and that's not going to change. Sorry!

it seems the whole point is making files more readable

No. I don't think a non-machine-learning program can beat humans when it comes to making readable code (but it does beat humans who don't care). Prettier is all about taking code formatting out of developers' minds. Auto-format instead of manually typing everything. Keep code consistent in teams. Avoid code style discussions. The cost? Slightly worse formatting in a few cases. Worth it? Absolutely! Disagree? Well, then Prettier might not be for you…

The cost? Slightly worse formatting in a few cases. Worth it? Absolutely! Disagree? Well, then Prettier might not be for you…

@lydell I don't disagree. To the contrary, this is what I really love about prettier. Consistency, no debates, plus it's simple to use and has wide support. It took some getting used to some of the ways it formats things into multiple lines, but even that I have come to love. I personally think it could be argued that breaking into multiple, narrow lines makes things more readable. But of course everything with code formatting is subjective, and the purpose of prettier is to take out any subjectivity. So please don't get me wrong, I agree with and love that philosophy.
What I'm not understanding is why such an emphatic "no" on blank lines / whitespace when other "stylistic"/whitespace rules -- such as semicolons, quotes, tabs/spaces, and even the width of each line -- are configurable. Making the number of blank lines configurable does seem to take away from your above stated goals of prettier. At all. Nor does it sacrifice anything for current users. All it does is add value to users. In fact I think there is more lost by not adding it. However, obviously I haven't worked on the prettier project, so my perspective is limited. So here are my questions to you and any other creators/contributors:

What were the reason(s) decided to emphatically stick with "at most one blank line in a row"?
Why are other stylistic rules configurable but this one isn't/"never will be"? What makes the configurable rules different from this one?
What is lost by adding this feature? Is there a cost or technical challenge to doing this that makes it not worthwhile?
What is lost by not adding this feature?

I appreciate any insights you or anyone else involved in these decisions might give.

Ideally, Prettier would have no options at all. But the JS community is too opinionated for that to work, so the double-vs-single quote option exists, for example. After a lot of requests, --no-semi was added. Recently, --arrow-parens was added after a lot of discussions and huge demand. In other words, it takes a lot to get a new option into Prettier.
Problems with options are:

Maintenance. Implementation, tests, docs, fixing bugs, fixing problems when used in combination with other options. The more options, the more combinations.
Burden on the user. More choices to make. Bikeshedding in teams. "Which code style should we use?" is swapped for "Which Prettier options should we use?"

Regarding a configurable amount of allowed blank lines in a row. Let's say you set it to 3. Then in code reviews you'll get comments like "Please remove excessive blank lines here" or "There should be 2 not 1 blank lines after such-and-such". The option is opening the doors for exactly the discussions Prettier is trying to do away with.
Finally, it is not true that this option will never be added. It could be. If there's a lot of demand for it, which there isn't for the time being.
Remember, when a new option is suggested, I'd say it will be rejected 99 times out of 100. After a couple of months of :+1:s, a few miles of GitHub comments and a bunch of duplicate issues, then it might be added. I'm not saying this because I get to decide these things, but from my experience from contributing to this project for about a year.
Thanks for your feedback! But I think that you have to let your blank lines go. Or start some expensive lobbying campaign ;) You can also experiment with using comments, functions and more files instead of blank lines.

In the meantime, I integrated prettier into my code editor (bbedit). It calls a Nodejs script and keeps the blank lines. Enjoy...
#!/usr/local/bin/node
const prettier = require("prettier");
let inString = "";

const customPreprocess = inString => {
	let outString = inString;
	outString = inString.replace(/^[\s]$/gm, "/*linebreak*/");
	return outString;
};

const customPostprocess = inString => {
	let outString = inString;
	outString = outString.replace(/\/\*linebreak\*\//gm, "");
//	outString = outString.replace(new RegExp(" " + " ", "g"), "\t");
	return outString;
};

const writeStuff = function() {
	let outString = "";
	outString = customPreprocess(inString);
	outString = prettier.format(outString, {
		singleQuote: true,
		useTabs:true
	});
	outString = customPostprocess(outString);
	process.stdout.write(outString);
};

//the rest ========================================================
process.stdin.resume();
process.stdin.setEncoding("utf8");
process.stdin.on("data", function(data) {
	inString += data;
});
process.stdin.on("end", writeStuff);

Let's say you set it to 3. Then in code reviews you'll get comments like "Please remove excessive blank lines here" or "There should be 2 not 1 blank lines after such-and-such". The option is opening the doors for exactly the discussions Prettier is trying to do away with.

Ummm... try communicating? and share the same prettier config file? 😄 But I get the overarching point you are making, and agree it's wise to be choosy about the number of options and which options you make configurable. I just wish this was one of them (gosh, I'd take this one over half the other configurable options!). 😉

I think that you have to let your blank lines go. Or start some expensive lobbying campaign ;)

Since I don't have the means, I'm afraid you're right (sad face). 😃 Thank you for answering my questions! Much appreciated!
@tqwhite Thank you for posting, I use sublime text with the sublime prettier extension. I'm sure I can integrate this somehow, I'll have to play with it when I have a chance. Thanks again!

Just want to add my voice to this as I would love the option to have more than 1 blank - I've avoided using prettier to date because of this, as being able to give my code my own visual hierarchy using spacing is really important to me, and it seems I'm not alone.
Also, I notice that blank lines are removed completely from the start and end of objects, but not between object properties. Not sure if this is intentional or not, but it seems inconsistent with the rest of the behaviour.

Also, I notice that blank lines are removed completely from the start and end of objects, but not between object properties. Not sure if this is intentional or not, but it seems inconsistent with the rest of the behaviour.

@abimpson Yes it is intended. See https://prettier.io/docs/en/rationale.html#empty-lines

I use Prettier a hundred times a day. I type a bunch of code without worrying about format then I hit the Prettier button in my editor (bbedit, see my example above) and Voila!, it's effortlessly formatted correctly.
However, when working on preexisting code, I often insert a bunch of lines around the place I am adding code so I can easily see it when scrolling. These get removed when I'm done but it's a great convenience that, without my workaround, is ruined. And it slows down my work because I have to either spend time typing format or paying attention to line numbers after I reformat with Prettier.
Yet another reason it's a mistake to refuse to parameterize the blank lines.

@tqwhite You never answered my question about that: https://github.com/prettier/prettier/issues/554#issuecomment-276885340

@lydell, my apologies. Somehow I missed your question.
I use a program called bbedit and it does not automatically extend comments.

We do keep multiple blank lines inside of multiline comments.
Prettier 1.14.2
Playground link
--parser babylon

Input:
/*

*/

Output:
/*

*/

@primalanomaly, Prettier is too good to allow such things to prevent your enjoying it. Scroll up to see a bit of Node I added to my development kit that retains blank lines but still retains the other Prettier goodness.