[wip] fix: make scratchpad scrollable

📝 Summary

Fixes #3073 . Each individual part can be scrolled (code editor, output area, console output) and the whole scratchpad can be scrolled too. I think it maintains the feel of scratchpad while handling long inputs / outputs.
I'm not sure if it breaks anything else, so plan to test it locally a while.

🔍 Description of Changes

📋 Checklist

[X] I have read the contributor guidelines.
[ ] For large changes, or changes that affect the public API: this change was discussed or approved through an issue, on Discord, or the community discussions (Please provide a link if applicable).
[ ] I have added tests for the changes made.
[X] I have run the code and verified that it works as expected.

📜 Reviewers

@akshayka OR @mscolnick

@Light2Dark - just played around with it, i think the only change needed is this at the bottom:
      <div className="flex-1 divide-y relative overflow-hidden flex flex-col">
        {renderBody()}
        {renderHistory()}
      </div>

hey, sorry about that, that's a much better fix. Thanks :)

hey @Light2Dark, yea i thought it always was (that was my intention initially). but I think that is fine to keep it like that


Update 05-Amal-Velu's slide

First commit made to the caption of the slide @Amal-Velu.

Reviewed and approved


Reference errors when using multiple token sets

I'm trying to generate my Flutter assets using your library and the token set my designer gave me has 2 sets of data. It seems that that is currently not supported? I'm getting a lot of "Reference doesn't exist" on the second token set.

Input tokens.json
{
"source": {
  "0": {
    "value": "0",
    "type": "letterSpacing"
  },
  "brand": {
    "50": {
      "value": "#f0faff",
      "type": "color"
    },
    "100": {
      "value": "#e0f5fe",
      "type": "color"
    },
    "200": {
      "value": "#bae8fd",
      "type": "color"
    },
    "300": {
      "value": "#7dd5fc",
      "type": "color"
    },
    "400": {
      "value": "#38bcf8",
      "type": "color"
    },
    "500": {
      "value": "#0ea5e9",
      "type": "color"
    },
    "600": {
      "value": "#028ac7",
      "type": "color"
    },
    "700": {
      "value": "#0370a1",
      "type": "color"
    },
    "800": {
      "value": "#075e85",
      "type": "color"
    },
    "900": {
      "value": "#0c506e",
      "type": "color"
    }
  },
  "gray": {
    "50": {
      "value": "#f9fafb",
      "type": "color"
    },
    "100": {
      "value": "#f3f4f6",
      "type": "color"
    },
    "200": {
      "value": "#e5e7eb",
      "type": "color"
    },
    "300": {
      "value": "#d1d5db",
      "type": "color"
    },
    "400": {
      "value": "#9ca3af",
      "type": "color"
    },
    "500": {
      "value": "#6b7280",
      "type": "color"
    },
    "600": {
      "value": "#4b5563",
      "type": "color"
    },
    "700": {
      "value": "#374151",
      "type": "color"
    },
    "800": {
      "value": "#1f2937",
      "type": "color"
    },
    "900": {
      "value": "#111827",
      "type": "color"
    }
  },
  "red": {
    "50": {
      "value": "#fef2f2",
      "type": "color"
    },
    "100": {
      "value": "#fee2e2",
      "type": "color"
    },
    "200": {
      "value": "#fecaca",
      "type": "color"
    },
    "300": {
      "value": "#fca5a5",
      "type": "color"
    },
    "400": {
      "value": "#f87171",
      "type": "color"
    },
    "500": {
      "value": "#ef4444",
      "type": "color"
    },
    "600": {
      "value": "#dc2626",
      "type": "color"
    },
    "700": {
      "value": "#b91c1c",
      "type": "color"
    },
    "800": {
      "value": "#991b1b",
      "type": "color"
    },
    "900": {
      "value": "#7f1d1d",
      "type": "color"
    }
  },
  "yellow": {
    "50": {
      "value": "#fefce8",
      "type": "color"
    },
    "100": {
      "value": "#fef9c3",
      "type": "color"
    },
    "200": {
      "value": "#fef08a",
      "type": "color"
    },
    "300": {
      "value": "#fde047",
      "type": "color"
    },
    "400": {
      "value": "#facc15",
      "type": "color"
    },
    "500": {
      "value": "#eab308",
      "type": "color"
    },
    "600": {
      "value": "#ca8a04",
      "type": "color"
    },
    "700": {
      "value": "#a16207",
      "type": "color"
    },
    "800": {
      "value": "#854d0e",
      "type": "color"
    },
    "900": {
      "value": "#713f12",
      "type": "color"
    }
  },
  "green": {
    "50": {
      "value": "#f0fdf4",
      "type": "color"
    },
    "100": {
      "value": "#dcfce7",
      "type": "color"
    },
    "200": {
      "value": "#bbf7d0",
      "type": "color"
    },
    "300": {
      "value": "#86efac",
      "type": "color"
    },
    "400": {
      "value": "#4ade80",
      "type": "color"
    },
    "500": {
      "value": "#22c55e",
      "type": "color"
    },
    "600": {
      "value": "#16a34a",
      "type": "color"
    },
    "700": {
      "value": "#15803d",
      "type": "color"
    },
    "800": {
      "value": "#166534",
      "type": "color"
    },
    "900": {
      "value": "#14532d",
      "type": "color"
    }
  },
  "white": {
    "value": "#ffffff",
    "type": "color"
  },
  "black": {
    "value": "#000000",
    "type": "color"
  },
  "transparent": {
    "value": "rgba(255,255,255,0)",
    "type": "color"
  },
  "General Sans": {
    "value": "General Sans",
    "type": "fontFamilies"
  },
  "Default": {
    "value": "140%",
    "type": "lineHeights"
  },
  "Footnote": {
    "value": "13",
    "type": "fontSizes"
  },
  "Subheadline": {
    "value": "15",
    "type": "fontSizes"
  },
  "Body": {
    "value": "17",
    "type": "fontSizes"
  },
  "Title": {
    "value": "20",
    "type": "fontSizes"
  },
  "LargeTitle": {
    "value": "34",
    "type": "fontSizes"
  },
  "Regular": {
    "value": "Regular",
    "type": "fontWeights"
  },
  "Medium": {
    "value": "Medium",
    "type": "fontWeights"
  },
  "Bold": {
    "value": "Bold",
    "type": "fontWeights"
  }
},
"semantic": {
  "button": {
    "background": {
      "primary": {
        "default": {
          "value": "{brand.500}",
          "type": "color"
        },
        "pressed": {
          "value": "{brand.600}",
          "type": "color"
        }
      },
      "secondary": {
        "default": {
          "value": "{gray.800}",
          "type": "color"
        },
        "pressed": {
          "value": "{gray.900}",
          "type": "color"
        }
      },
      "disabled": {
        "default": {
          "value": "{gray.100}",
          "type": "color"
        }
      },
      "success": {
        "default": {
          "value": "{green.500}",
          "type": "color"
        },
        "pressed": {
          "value": "{green.600}",
          "type": "color"
        }
      },
      "destructive": {
        "default": {
          "value": "{red.500}",
          "type": "color"
        },
        "pressed": {
          "value": "{red.600}",
          "type": "color"
        }
      },
      "transparent": {
        "default": {
          "value": "{transparent}",
          "type": "color"
        }
      }
    },
    "foreground": {
      "default": {
        "value": "{white}",
        "type": "color"
      },
      "disabled": {
        "value": "{gray.200}",
        "type": "color"
      },
      "success": {
        "value": "{green.500}",
        "type": "color"
      },
      "destructive": {
        "value": "{red.500}",
        "type": "color"
      },
      "onTransparent": {
        "default": {
          "value": "{gray.900}",
          "type": "color"
        },
        "pressed": {
          "value": "{gray.800}",
          "type": "color"
        }
      }
    }
  },
  "background": {
    "default": {
      "value": "{gray.100}",
      "type": "color"
    },
    "neutral": {
      "value": "{white}",
      "type": "color"
    }
  },
  "default": {
    "footnote": {
      "regular": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Regular}",
          "lineHeight": "{Default}",
          "fontSize": "{Footnote}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "medium": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Medium}",
          "lineHeight": "{Default}",
          "fontSize": "{Footnote}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "bold": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Bold}",
          "lineHeight": "{Default}",
          "fontSize": "{Footnote}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      }
    },
    "subheadline": {
      "regular": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Regular}",
          "lineHeight": "{Default}",
          "fontSize": "{Subheadline}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "medium": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Medium}",
          "lineHeight": "{Default}",
          "fontSize": "{Subheadline}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "bold": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Bold}",
          "lineHeight": "{Default}",
          "fontSize": "{Subheadline}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      }
    },
    "body": {
      "regular": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Regular}",
          "lineHeight": "{Default}",
          "fontSize": "{Body}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "medium": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Medium}",
          "lineHeight": "{Default}",
          "fontSize": "{Body}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "bold": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Bold}",
          "lineHeight": "{Default}",
          "fontSize": "{Body}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      }
    },
    "title": {
      "regular": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Regular}",
          "lineHeight": "{Default}",
          "fontSize": "{Title}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "medium": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Medium}",
          "lineHeight": "{Default}",
          "fontSize": "{Title}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "bold": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Bold}",
          "lineHeight": "{Default}",
          "fontSize": "{Title}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      }
    },
    "largetitle": {
      "regular": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Regular}",
          "lineHeight": "{Default}",
          "fontSize": "{LargeTitle}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "medium": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Medium}",
          "lineHeight": "{Default}",
          "fontSize": "{LargeTitle}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      },
      "bold": {
        "value": {
          "fontFamily": "{General Sans}",
          "fontWeight": "{Bold}",
          "lineHeight": "{Default}",
          "fontSize": "{LargeTitle}",
          "letterSpacing": "{0}"
        },
        "type": "typography"
      }
    }
  }
},
"$themes": [],
"$metadata": {
  "tokenSetOrder": [
    "source",
    "semantic"
  ]
}
}

Errors while running generator
Property Reference Errors:
Reference doesn't exist: semantic.button.background.primary.default.value tries to reference brand.500, which is not defined
Reference doesn't exist: semantic.button.background.primary.pressed.value tries to reference brand.600, which is not defined
Reference doesn't exist: semantic.button.background.secondary.default.value tries to reference gray.800, which is not defined
Reference doesn't exist: semantic.button.background.secondary.pressed.value tries to reference gray.900, which is not defined
Reference doesn't exist: semantic.button.background.disabled.default.value tries to reference gray.100, which is not defined
Reference doesn't exist: semantic.button.background.success.default.value tries to reference green.500, which is not defined
Reference doesn't exist: semantic.button.background.success.pressed.value tries to reference green.600, which is not defined
Reference doesn't exist: semantic.button.background.destructive.default.value tries to reference red.500, which is not defined
Reference doesn't exist: semantic.button.background.destructive.pressed.value tries to reference red.600, which is not defined
Reference doesn't exist: semantic.button.background.transparent.default.value tries to reference transparent, which is not defined
Reference doesn't exist: semantic.button.foreground.default.value tries to reference white, which is not defined
Reference doesn't exist: semantic.button.foreground.disabled.value tries to reference gray.200, which is not defined
Reference doesn't exist: semantic.button.foreground.success.value tries to reference green.500, which is not defined
Reference doesn't exist: semantic.button.foreground.destructive.value tries to reference red.500, which is not defined
Reference doesn't exist: semantic.button.foreground.onTransparent.default.value tries to reference gray.900, which is not defined
Reference doesn't exist: semantic.button.foreground.onTransparent.pressed.value tries to reference gray.800, which is not defined
Reference doesn't exist: semantic.background.default.value tries to reference gray.100, which is not defined
Reference doesn't exist: semantic.background.neutral.value tries to reference white, which is not defined
Reference doesn't exist: semantic.default.footnote.regular.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.footnote.regular.value.fontWeight tries to reference Regular, which is not defined
Reference doesn't exist: semantic.default.footnote.regular.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.footnote.regular.value.fontSize tries to reference Footnote, which is not defined
Reference doesn't exist: semantic.default.footnote.regular.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.footnote.medium.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.footnote.medium.value.fontWeight tries to reference Medium, which is not defined
Reference doesn't exist: semantic.default.footnote.medium.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.footnote.medium.value.fontSize tries to reference Footnote, which is not defined
Reference doesn't exist: semantic.default.footnote.medium.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.footnote.bold.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.footnote.bold.value.fontWeight tries to reference Bold, which is not defined
Reference doesn't exist: semantic.default.footnote.bold.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.footnote.bold.value.fontSize tries to reference Footnote, which is not defined
Reference doesn't exist: semantic.default.footnote.bold.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.subheadline.regular.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.subheadline.regular.value.fontWeight tries to reference Regular, which is not defined
Reference doesn't exist: semantic.default.subheadline.regular.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.subheadline.regular.value.fontSize tries to reference Subheadline, which is not defined
Reference doesn't exist: semantic.default.subheadline.regular.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.subheadline.medium.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.subheadline.medium.value.fontWeight tries to reference Medium, which is not defined
Reference doesn't exist: semantic.default.subheadline.medium.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.subheadline.medium.value.fontSize tries to reference Subheadline, which is not defined
Reference doesn't exist: semantic.default.subheadline.medium.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.subheadline.bold.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.subheadline.bold.value.fontWeight tries to reference Bold, which is not defined
Reference doesn't exist: semantic.default.subheadline.bold.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.subheadline.bold.value.fontSize tries to reference Subheadline, which is not defined
Reference doesn't exist: semantic.default.subheadline.bold.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.body.regular.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.body.regular.value.fontWeight tries to reference Regular, which is not defined
Reference doesn't exist: semantic.default.body.regular.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.body.regular.value.fontSize tries to reference Body, which is not defined
Reference doesn't exist: semantic.default.body.regular.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.body.medium.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.body.medium.value.fontWeight tries to reference Medium, which is not defined
Reference doesn't exist: semantic.default.body.medium.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.body.medium.value.fontSize tries to reference Body, which is not defined
Reference doesn't exist: semantic.default.body.medium.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.body.bold.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.body.bold.value.fontWeight tries to reference Bold, which is not defined
Reference doesn't exist: semantic.default.body.bold.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.body.bold.value.fontSize tries to reference Body, which is not defined
Reference doesn't exist: semantic.default.body.bold.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.title.regular.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.title.regular.value.fontWeight tries to reference Regular, which is not defined
Reference doesn't exist: semantic.default.title.regular.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.title.regular.value.fontSize tries to reference Title, which is not defined
Reference doesn't exist: semantic.default.title.regular.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.title.medium.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.title.medium.value.fontWeight tries to reference Medium, which is not defined
Reference doesn't exist: semantic.default.title.medium.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.title.medium.value.fontSize tries to reference Title, which is not defined
Reference doesn't exist: semantic.default.title.medium.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.title.bold.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.title.bold.value.fontWeight tries to reference Bold, which is not defined
Reference doesn't exist: semantic.default.title.bold.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.title.bold.value.fontSize tries to reference Title, which is not defined
Reference doesn't exist: semantic.default.title.bold.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.largetitle.regular.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.largetitle.regular.value.fontWeight tries to reference Regular, which is not defined
Reference doesn't exist: semantic.default.largetitle.regular.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.largetitle.regular.value.fontSize tries to reference LargeTitle, which is not defined
Reference doesn't exist: semantic.default.largetitle.regular.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.largetitle.medium.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.largetitle.medium.value.fontWeight tries to reference Medium, which is not defined
Reference doesn't exist: semantic.default.largetitle.medium.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.largetitle.medium.value.fontSize tries to reference LargeTitle, which is not defined
Reference doesn't exist: semantic.default.largetitle.medium.value.letterSpacing tries to reference 0, which is not defined
Reference doesn't exist: semantic.default.largetitle.bold.value.fontFamily tries to reference General Sans, which is not defined
Reference doesn't exist: semantic.default.largetitle.bold.value.fontWeight tries to reference Bold, which is not defined
Reference doesn't exist: semantic.default.largetitle.bold.value.lineHeight tries to reference Default, which is not defined
Reference doesn't exist: semantic.default.largetitle.bold.value.fontSize tries to reference LargeTitle, which is not defined
Reference doesn't exist: semantic.default.largetitle.bold.value.letterSpacing tries to reference 0, which is not defined

/Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/node_modules/style-dictionary/lib/exportPlatform.js:125
  throw new Error('Problems were found when trying to resolve property references');
  ^

Error: Problems were found when trying to resolve property references
  at Object.exportPlatform (/Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/node_modules/style-dictionary/lib/exportPlatform.js:125:11)
  at Object.buildPlatform (/Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/node_modules/style-dictionary/lib/buildPlatform.js:56:21)
  at /Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/node_modules/style-dictionary/lib/buildAllPlatforms.js:31:10
  at Array.forEach (<anonymous>)
  at Object.buildAllPlatforms (/Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/node_modules/style-dictionary/lib/buildAllPlatforms.js:30:39)
  at Object.<anonymous> (/Users/markmooibroek/.nvm/versions/node/v16.19.1/lib/node_modules/style-dictionary-figma-flutter/build.js:33:25)
  at Module._compile (node:internal/modules/cjs/loader:1191:14)
  at Object.Module._extensions..js (node:internal/modules/cjs/loader:1245:10)
  at Module.load (node:internal/modules/cjs/loader:1069:32)
  at Function.Module._load (node:internal/modules/cjs/loader:904:12)

Can you perhaps tell me if this is indeed not supported or maybe how I can fix this?

Went a different route and created a parser myself, specifically designed for targetting Flutter. https://pub.dev/packages/figma2flutter


Point out problematic names in documentation

Documentation might want to also point out issues with the '-' character in test names. For whatever reason, XRay will not find a perfect match in a test case that has dashes, possibly to do with the way the the plugin is looking for the test case ID in the test string. The result is creating a new duplicate test issue on each run.

Originally posted by @barnes in https://github.com/Qytera-Gmbh/cypress-xray-plugin/issues/47#issuecomment-1544319620

As far as I can see, this really seems to be an issue on Xray's side. I will try to reach out to their product support.

Here's their response for now:

We´re currently testing this issue, and we managed to replicate it. We´ll continue investigating to figure out the issue source and possibly a workaround. I'll let you know as soon as we have some more details.

Here's their corresponding issue: https://jira.getxray.app/browse/XRAYCLOUD-6031. I have added a remark here.


Correct ABCD format

https://github.com/nexB/scancode-toolkit/blob/develop/thirdparty/prod/lxml-3.6.4.ABOUT
From to the doc (https://docs.google.com/document/d/1Le0bahKIUxWfFD2j8uvbyNjTjD8Up4vPyfMLML9OEGo), "Top level known objects are ALWAYS plural".
Should the 'component' becomes 'components', 'package' becomes 'packages', 'license' becomes 'licenses'
Example from the doc:
    packages:
      - download_url: http://pypi.python.org/packages/source/b/bitarray/bitarray-0.8.1.tar.gz
        sha1:<PHONE_NUMBER>29abcdef342
    license_expression: psf
    licenses:
      - source: scancode.com
        key: psf
        text_file: PSF.LICENSE

Should we update the ABOUT to the following instead?
    packages:
      - checksum: md5:6dd7314233029d9dab0156e7b1c7830b
        download_url: https://pypi.python.org/packages/4f/3f/cf6daac551fc36cddafa1a71ed48ea5fd642e5feabd3a0d83b8c3dfd0cb4/lxml-3.6.4.tar.gz

    copyright: Copyright (c) 2004 Infrae. All rights reserved.
    licenses:
      - text_file: lxml.LICENSE
        expression: bsd-new and (mit and gpl-2.0-plus and zope-2.0 and zlib)
        text_file: lxml.LICENSE
        notice_file: lxml.NOTICE

    vcs:
      - tool: git
        branch: lxml-3.3
        repository: https://github.com/lxml/lxml.git

See #283


docs(open-payments): Add readme docs

Changes proposed in this pull request

Adds initial README to open-payments
Adds some TSDoc comments for explaining the arguments in the client

Context

Progress towards #970

Checklist

[ ] Related issues linked using fixes #number
[ ] Tests added/updated
[ ] Documentation added
[ ] Make sure that all checks pass

@wilsonianb I agree, what about just "Online Marketplace"?

@wilsonianb I agree, what about just "Online Marketplace"?

:+1:


Managing eye with upstart

I've got eye set up for managing my Rails and Sidekiq processes, however I wanted to manage eye via Upstart to start eye on boot and monitor eye incase it dies unexpectedly.
I've tried with all three variations on the expect stanza:

no expect stanza (0 forks)
expect fork (1 fork)
expect daemon (2 forks)

And each time, Upstart ends up tracking a different PID than what eye is running on.
Following Upstarts documentation for getting the fork count (http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count), the strace log returns a value of 17, which seems excessively high.
Here's the Upstart config I'm using for reference:
description 'Eye'

start on runlevel [2]
stop on runlevel [016]

expect daemon

exec su -l -c 'eye load /home/deploy/sample.eye' deploy

respawn

Process forking is a bit new to me in Ruby, so I'm hoping someone else can shed some light on this for me.
Once it's solved, I'll gladly work up a wiki page to help document this for future users.
Thanks in advance!

I try use your upstart script , its work fine for start, but stop and restart dont work.
I use upstart  1.12.1-0ubuntu4.2 in ubuntu 14.04

Yup, struggling with the same issue as @stufently, will post if I manage to find a solution. Or did you (@stufently) managed to sort this out?

there is in wiki https://github.com/kostya/eye/wiki/Manage-with-upstart, may be it works?

Maybe  my upstart script help you
/etc/init/eye.conf                                                                                341/341               100%
description 'Eye'
start on (local-filesystems and runlevel [2345])
stop on runlevel [016]
setuid deploy
setgid deploy
respawn
expect fork
console log
env EYE_HOME=/home/deploy
script
export HOME=/home/deploy
exec eye load /home/deploy/sites/asgapi/shared/asgapi.eye
end script
post-stop script
eye quit --stop_all
end script

@kostya saw this one, but also had no luck with it.
@stufently thanks, I actually had a similar one and as long as staring worked, stop did not for me.
In both those cases stop was the thing not working for me, as PID for service spawned by Upstart differ from the actual PID of running eye daemon. Which is expected here I guess ;).
For now I ended up with different solution which I grabbed from some "unicorn in Upstart" tutorial:
description 'Eye'

start on (net-device-up
          and local-filesystems
          and runlevel [2345])
stop on runlevel [!2345]
kill timeout 60

setuid ubuntu
setgid ubuntu

# log stdout and stderr to /var/log/upstart/eye
console log

script
  # Eye runs from $HOME, upstart with setuid wont set $HOME
  export HOME=/home/ubuntu
  eye load /var/www/app/current/config/eye/app.eye
  # After above point we/Upstart lose control of eye daemon here due to PID mismatching
  while true; do
    # Sleep forever. The backgrounding (&) + wait is so that "trap" can
    # interrupt at any time. A plain "sleep infinity" wouldn't allow this.
    sleep infinity & BLOCKING_PID=$!
    # When interrupted by a trap, wait dies with exit code 128; ignore this, keep going.
    wait "$BLOCKING_PID" || true
  done
end script

post-stop script
  export HOME=/home/ubuntu #Here needed as well. See coment above.
  eye quit -s # Stop all eye services, and quit eye
end script

Not the prettiest solution, but hopefully temporary won't become permanent ;)

you can run eye without daemonization,
there is internal loader_eye process
loader_eye --help
Usage: loader_eye [options]
    -h, --help                       Display this screen
    -c, --config CONFIG              load with config
    -s, --socket SOCKET              start listen on socket
    -l, --logger LOGGER              custom logger
    -d, --dir DIR                    Dir for local runner
    -a, --stop_all                   Stop all on exit
    -g, --debug                      debug info to logger

example:
bundle exec loader_eye -c config_dir/ -l /tmp/eye.log -a

And the Duh! goes to me ;), will check this out, thanks!
Though the more I relay on a setup like Upstart-> eye-> app stuff, the less I find it convenient. I'd rather drop either Upstart or eye here. I need to give it more thoughts and testing.

i don't know why you need upstart at all, we using only crontab to run eye after server reboot, and eye works without restart for years


fix: Update gates report commit

Description
Problem*
Resolves this comment https://github.com/noir-lang/noir/pull/4719#issuecomment-2040362061. We want to test going back to handling the reference content the same way.
Summary*
Additional Context
Documentation*
Check one:

[ ] No documentation needed.
[ ] Documentation included in this PR.
[ ] [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

[ ] I have tested the changes locally.
[ ] I have formatted the changes with Prettier and/or cargo fmt on default settings.

This now uses the main branch of noir-gates-diff


Displaying images in gui

I have poked around a little in the views.py. I worked out how to add a new tab that allows users to select which browswer they would like the tests to run in. I couldn't figure out how to get an image to display in the gui, however. If you could point me in the right direction, i would appreciate it. Btw, i'm not sure if this is the right place to post this because this isn't a bug.

@hujosh Hey! Have you tried following this?
http://effbot.org/tkinterbook/photoimage.htm
Also, it looks like Tkinter requires for you to hold a reference to the image. Here's a detailed and example to help:
http://effbot.org/pyfaq/why-do-my-tkinter-images-not-appear.htm

It's not clear to me exactly why this requires an image view - or why another tab is required. If you're looking to configure the browser to use so it can be passed in as an option, I would have thought a menu option would be all you need. What's the role of the image?

I only mentioned the browser thing so that you knew i was somewhat familiar with the views.py code. Maybe i used the wrong terminology to describe it: i meant that i put another "drown down menu' among the set that comes with cricket by default -- the set {File ,Test, BeeWare, Help}.
I have now worked out how to do images. I just put a "view screenshot" button in the details frame that is "DISABLED" until a testcase has been run. I don't display the image in the Cricket GUI. Instead i use
    image.show(),

which opens the paint program on windows 10 with the image i want to be showed showed.


feat: Updated shutdowns schedule

Hi!
Is there any point in converting Unicode Escaped characters to Unicode plain text?
Or is there software that can't work properly with this format?

Hi!
No, there's no special need to converting Unicode Escaped to plain text.
I have made changes to keep JSON files is in a unified format.

@szheliab Thanks!
But if this transformation is necessary, no problem. I was just curious.


Bulleting Appearance not available

Hello !
Is not available in the master branch :/
Thank you

If you are using Carthage
Make sure to use this in your Cartfile:
github "alexaubry/BulletinBoard" "master"

And then run carthage update to build the latest version.
If you are using CocoaPods
Make sure you are using this in your Podfile:
pod 'BulletinBoard', :git => 'https://github.com/alexaubry/BulletinBoard.git', :branch => 'master'

And then run pod install and pod update to make sure you get the latest version.
Tell me if you need more help 😃

It appears to be working with the two snippets I provided. Feel free to reopen the issue if it still does not work.

im getting the same issue there's no appearance available for the PageBulletinItem. I'm on the latest version 1.3.0, and still not working. already pulled directly from master but still. help please.

+1

@Capossito @yusuftor Could you try using the 2.0.0 beta and let me know if the appearance is available with this version?

Will do, can I do this through Cocoapods?

Sure, try using the v2 branch in your Podfile:
pod 'BulletinBoard', :git => 'https://github.com/alexaubry/BulletinBoard.git', :branch => 'v2'

Ok just tried and it doesn't work with that either. It works in the sample swift app though...

Hi, just tried this again today. The master branch does work with appearance. I think it was an issue with Cocoapods so I've been cleaning my project and closing and reopening it. Finally it works! Thank you.


Highlighting should print an info when linenumber style is explicitly set to table

If a Sphinx configuration explicitly sets html_codeblock_linenos_style to table, we should print a message that this theme uses the inline version and that to get rid of this message, remove this configuration from the code.

I actually have no idea if this is possible, since Sphinx sets it by default to table. The option html_codeblock_linenos_style is added by the HTML builder. The config-inited event returns table regardless whether it is specified by the user or not. I couldn't find any way to get default values, or to distinguish user-provided from program-provided content.
I guess, I would have to modify the read method of the config file and emit some sort of event. I'll probably not do that.


[FR] support for packaging sources for debugging

We may be able to support source debugging of distributed binaries if we package the sources (and possibly separate debug info files, depending on the platform) alongside the binaries in a predictable manner.

If feasible, I'd suggest making it possible to have a separate aar-sources AAR so that the user doesn't have to download it to build.


chore: Regenerate generated files

Commit changes generated by:

npm run test:prep
npm run build

@naugtur needs to approve this since it's blocked on his disapproval

I see you've backed out of generating on the fly.
I'll unblock first and ask questions later


Carbon cache: no module named carbon.util

Exactly the same issue as #276 .
Debian 8 x64, installed
carbon-0.9.15
graphite-web-0.9.15
to default locations using pip.
When I trying to run:
python /usr/local/bin/carbon-cache.py start
I got:
Traceback (most recent call last):
File "/usr/local/bin/carbon-cache.py", line 28, in
from carbon.util import run_twistd_plugin
ImportError: No module named carbon.util

+1
I have installed into a virtualenv at /opt/graphite/venv, after activating with source /opt/graphite/venv/bin/activate in the python shell I can import whisper no problem, but import carbon throws an ImportError

import twisted and import zope also work.

I changed the virtualenv to the installation folder as recommended in the docs.  This is the output I get below when trying to import carbon, hopefully it will help diagnose the problem.  Box is a fresh install of ubuntu14.04 with python 2.7
vagrant@carbon:~$ cd /opt/graphite/
vagrant@carbon:/opt/graphite$ source bin/activate
(graphite)vagrant@carbon:/opt/graphite$ pip freeze
carbon==0.9.15
graphite-web==0.9.15
Twisted==15.5.0
txAMQP==0.6.2
wheel==0.24.0
whisper==0.9.15
zope.interface==4.1.3
(graphite)vagrant@carbon:/opt/graphite$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import carbon
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named carbon

Exactly the same issue here. I rollbacked to 0.9.12 from Ubuntu 14.04 repo and had to manually remove twisted from pip, otherwise even 0.9.12 did not work.

My colleague tried to make a container for 0.9.15 and locked the version of twisted to 11.1.0 and then it worked well. Here is the container.

This is a mess; I found the util stuck in /opt/graphite/lib/python/site-packages/opt/graphite/lib/
There's also some twisted plugins in there as well.

+1
Using virtualenv seems to be the problem. I'm seeing the carbon.util module ending up in /opt/graphite/lib/python2.7/site-packages/opt/graphite/lib.
Not using virtual env works fine as then the util module ends up in /opt/graphite/lib/carbon/util.py (as expected by carbon-cache.py, in terms of relative path to itself at least)
(CentOS 7)

Looks like this is graphite's default prefix (/opt/graphite) screwing things up again. Unsure what changed to break this - perhaps it never worked in the first place.
You should be able to pass in --install-lib to point to the virtualenv's site-packages dir as in the 'custom install' section of the docs:
http://graphite.readthedocs.org/en/latest/install-pip.html?highlight=pip#installing-carbon-in-a-custom-location
Unfortunately there doesn't appear to be a reliable way to get this directory programmatically on the commandline (see http://stackoverflow.com/questions/122327/how-do-i-find-the-location-of-my-python-site-packages-directory) though if you're installing with a virtual env at /opt/graphite/ this should work:
source /opt/graphite/bin/activate
pip install carbon --install-option="install-lib=/opt/graphite/lib"

@cahlbin I'm not sure that /opt/graphite/lib/carbon/util.py is the right location without virtualenv
carbon should be installed into the python site-packages? that's what seems right to me.  I suspect it would fail either way
This was introduced in https://github.com/graphite-project/carbon/issues/219

@cahlbin is right, by default it's installing in /opt/graphite and not in python site-packages

right and it should be installed into the site-packages; regardless of virtualenv or not.
As virtualenv is just an isolated python install? (i guess that's a good phrase) it has roughly the same directory layout as the distro's install.

damm commented on 27 Feb
This is a mess; I found the util stuck in /opt/graphite/lib/python/site-packages/opt/graphite/lib/
There's also some twisted plugins in there as well.

mv  /opt/graphite/lib/python/site-packages/opt/graphite/lib/carbon   /opt/graphite/lib/python/site-packages/
mv  /opt/graphite/lib/python/site-packages/opt/graphite/lib/twisted/plugins/carbon_*  /opt/graphite/lib/python/site-packages/twisted/plugins/carbon_*

exactly @qiangyao

cp -rv /usr/local/lib/python2.7/dist-packages/opt/graphite/lib/carbon /usr/local/bin/ && cp -rv /usr/local/lib/python2.7/dist-packages/opt/graphite/lib/twisted /usr/local/bin/
This fixed the issue for me
ubuntu 16 // python 2.7 // Twisted (11.1.0) // carbon (0.9.15)

qiangyao commented on Sep 19, 2016

damm commented on 27 Feb

This is a mess; I found the util stuck in /opt/graphite/lib/python/site-packages/opt/graphite/lib/
There's also some twisted plugins in there as well.

mv /opt/graphite/lib/python/site-packages/opt/graphite/lib/carbon /opt/graphite/lib/python/site-packages/
mv /opt/graphite/lib/python/site-packages/opt/graphite/lib/twisted/plugins/carbon_* /opt/graphite/lib/python/site-packages/twisted/plugins/carbon_*

That will work for installations located in /opt/graphite. For virtualenv installations, cd to your virtualenv and run:
$ mv lib/python2.7/site-packages/opt/graphite/lib/carbon lib/python2.7/site-packages/
$ mv lib/python2.7/site-packages/opt/graphite/lib/twisted/plugins/* lib/python2.7/site-packages/twisted/plugins/
$ rmdir -p lib/python2.7/site-packages/opt/graphite/lib/twisted/plugins/

And carbon will work.


[fastlane_core] Version bump

repare for fastlane plugins (#4770)
Removed Sentry (#4756)
Shell escape keychain paths in CertChecker
Replaced remaining .red and raise blocks (#4709)

👍 💎


Replace space with percent encoding

Whenever Jenkins posts a Terraform message in Slack, the link in broken due to the spaces in the job name. This PR replaces spaces with the percent encoding

The "Approve Terraform plan" stage  - https://github.com/nationalarchives/tdr-terraform-environments/blob/95a8781fec654aff4ba0c99aaf603af692f79091/Jenkinsfile#L57

I just checked, and the /input URL is correct: it's a temporary URL that you can visit when the job is paused for input, in this case so that you can approve or cancel the Terraform changes.

Cool. Thanks!


[backlog]Vmware Storage Plugin: Logging and Error handling

/kind bug
What happened:
We need to have logging in Storage Adapters.
More error handling is required in Plugin/adapter code.

Closing issue as this is addressed through https://github.com/opensds/nbp/pull/298


fish: fix and enable fishConfig test

nix-build -A fish.tests.fishConfig will now test that the
fish_config tool would start up properly. Previously, this test was
effectively disabled due to withTests being stubbed out.
I don't think this test ever truly worked, because the generated
temporary file would be cleaned up automatically (or maybe this
"automatically" changed between versions). The solution to this is to
add delete=False to the NamedTemporaryFile function call, to keep
the temporary file around in order to grep its contents for the expected
output.

Motivation for this change
The test had been effectively disabled for a long time.
Things done

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

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

[x] 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"
[ ] 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.

Is there any way to avoid having the derivation for fish itself be let-bound? It certainly makes it easier for the fishConfig test to refer to paths inside the derivation, but I wonder if there's a better way.

Is there any way to avoid having the derivation for fish itself be let-bound? It certainly makes it easier for the fishConfig test to refer to paths inside the derivation, but I wonder if there's a better way.

Putting it in a let is perfectly fine.


Not much information why postage stamp buying fails

Context
Bee 1.8.1
Summary
I was trying to buy a postage stamp and it failed. I tried to find out what is the problem and neither the error messages neither the logs are helpful.
The error I get from the endpoint is: Error: Internal Server Error: cannot create batch, status 500.
In the logs I only found this logline (with INFO verbosity):
"time"="2022-09-21 16:42:36.763231" "level"="error" "logger"="node/api" "msg"="create batch: create failed"

With DEBUG verbosity an additional line is printed:
"time"="2022-09-21 16:42:36.763211" "level"="debug" "logger"="node/api" "msg"="create batch: create failed" "error"="create batch: depth 17 bucketDepth 16 immutable false: transaction reverted"

The problem seems to be that the gas limit is too low for the transaction, but that can be deduced only by looking at the transactions (in blockscout).
Expected behavior
It would be good if either the error message or at least the logs would give some information to why there was an error.

Related #3240


Service lifetime for PSQL DbContext

After some digging I did not find a way to define the DbContext Service Lifetime. I believe that by default, the DbContext is being registered as a singleton because of Context Pooling.
Is that for any specific reason? Can it be changed somehow?
This because I want to inject some scoped services on my dbcontext and I'm unable to do so. Getting an error:
Cannot resolve scoped service 'CalGest.Shared.Common.Interfaces.ICurrentUser' from root provider.
Thanks in advance!

Db contexts are pooled by default. You can change this setting:
https://learn.microsoft.com/en-us/dotnet/aspire/database/postgresql-entity-framework-component?tabs=dotnet-cli#use-configuration-providers
@eerhardt is there a blessed way via the Aspire component's signature to get at lifetime scope for the dbcontext?

This should be resolved when #1403 is addressed. The EF Aspire components will no longer register the DbContext, but instead the app will register it using EF APIs.

Closing as dupe of #1403

Thanks everyone! I ended up by making the DbContext not pooled and worked for me. However, I'll keep an eye on https://github.com/dotnet/aspire/issues/1403
Thanks once again 😄


Bash completion of strings containing colons is incorrect

Expected Behavior
Click should be able to perform tab completion over a set of strings containing colons.
To reproduce this problem, apply the following diff to the click repo, and run the bashcompletion example following the instructions in examples/bashcompletion/README.md. Here's a session that goes wrong
$ bashcompletion group subcmd bob<TAB>
bob:1  bob:2  bob:3  # OK
$ bashcompletion group subcmd bob:<TAB>
bob:1  bob:2  bob:3
$ bashcompletion group subcmd bob:bob:  # <-- Oh no!

diff --git a/examples/bashcompletion/bashcompletion.py b/examples/bashcompletion/bashcompletion.py
index 0502dbc..42f4915 100644
--- a/examples/bashcompletion/bashcompletion.py
+++ b/examples/bashcompletion/bashcompletion.py
@@ -30,7 +30,7 @@ def group():
 def list_users(ctx, args, incomplete):
     # You can generate completions with descriptions by returning
     # tuples in the form (completion, description).
-    users = [("bob", "butcher"), ("alice", "baker"), ("jerry", "candlestick maker")]
+    users = [("bob:1", "butcher"), ("bob:2", "baker"), ("bob:3", "candlestick maker")]
     # Ths will allow completion matches based on matches within the
     # description string too!
     return [user for user in users if incomplete in user[0] or incomplete in user[1]]

Actual Behavior
Completion over a set of strings containing a colon character is correct until the partial user input contains a colon. At that point, something happens that is wrong, but a bit hard to describe. It seems to involve incorrectly duplicating the user input so far.
(This means that, for example, click cannot correctly complete python nose test names.)
Environment

Python version: 3.8.1
Click version: current master at the time of writing: c3eac6b887ecc2012b28356c229c443a50523f7f

It looks like this might be solved by something along the lines of https://stackoverflow.com/a/12495480/583763

Still an issue in the new autocomplete system (https://github.com/pallets/click/pull/1622).
With colons:

Without colons:

Occurs in both bash and zsh.
The hope for the new autocomplete system is to drop support for bash versions older than 4.4, which hopefully should make it easier to fix.

elif return ~/ .

This doesn't happen for me in Zsh or Fish, only Bash. @dandavison would you be able to make a pull request with your suggested changes?

@davidism the change I investigated is here: https://github.com/pallets/click/compare/master...dandavison:fix-colon-completion
However, this didn't quite fix it, so I didn't open a PR. Copying the comment from https://github.com/dandavison/click/commit/0f33bebdb542c7adc509ef086bcbbd6de947498d, here's the evidence that it is still not quite right with that change:
$ bashcompletion group subcmd bob<TAB>
bob:1  bob:2  bob:3
$ bashcompletion group subcmd bob:<TAB>
1  2  3

You are welcome to use 0f33bebdb542c7adc509ef086bcbbd6de947498d, with attribution or not. I can of course open the PR but I don't have time to work on it more at the moment.

It seems that _get_comp_words_by_ref is provided by the bash-completion package, not built-in to Bash. Despite the name, the bash-completion package is not required for Bash completion, and is not always installed. Using it in Click would make that package required.
I'm going to call this an issue with Bash's completion system in general, although there do seem to be legitimate reasons for it too. I don't think this is something Click can solve, although if a Bash expert comes along later with a PR and an explanation, I won't object. The nice thing about the new completion system is that if a project is ok with making it a requirement, they can apply this fix to their own completion script fairly easily now.


feat: add pagination

Closes #
✅ Checklist

[x] I have followed every step in the contributing guide (updated 2022-10-06).
[x] The PR title follows the convention we established conventional-commit
[x] I performed a functional test on my final commit

Changelog
add pagination for docs

How about on hover we just add underline, no color changes

we're currently doing both underline and color change in both left and right sidebar. imo unless we change those it's good the way it is

Run pnpm format too

@nexxeln Done 👍🏼


/areachairs tool should show emails too

Area Chairs may need to chase down reviewers individually. Unless there is another way to do so, the tool exposed through the web summary should also show emails or a way to contact the reviewers directly.

What is the timeline for this? (when do you expect that the area chairs will need this?) I ask because it turns out that the public profiles that we would use to get the email addresses only reveal users' partial addresses, for security reasons.
If they need this information very soon, I can generate a list of IDs-->emails

Probably Dec 2 since it's when some reviewers may need to be chased (that's the first deadline for reviewing).

sounds good, thanks!

Let me know when this is done so I can ask the AC who requested it to test it : )

done - you can go ahead and have your AC test it out.


Bluetooth stack issues (was: No updates in HA despite network connection / MQTT reconnect loop)

This morning I noticed a peculiar phenomenon while I was leaving for work: The lock state in HA did not change, yet the ESP web interface was reachable by Wifi and told me it was connected to MQTT (and the lock) just fine. When I came home and wanted to check more deeply, I noticed the state updating was working again.
Here are my restart settings:

The last time the lock entity in HA worked was Saturday 18:34 (unlock/lock event pair). (There was a lock event recorded by HA on Sunday 22:11, but that was just because I restarted HA at that time.)
According to Mosquitto, the last login by the ESP user yesterday was 20:14, replacing a still existing connection. Today at 08:21, the client closed the connection and opened a new one, and again at 08:24, and yet again at 08:40, and at 08:45. (Interestingly, there was a 3 second delay between closing and opening the new connection this time.)
Again at 08:47, also with the 3 second delay, and yet again 09:07 (no delay). Another fast reconnect at 09:12, at 09:23, 09:28, 09:43, 09:48, 09:50, and then finally at 10:20. No reconnects since then, and HA has recorded the lock/unlock events correctly after that.
I am not sure what was going there, but it sure looks weird. I've looked at the logs of the AP the ESP was connected to and there only three events in the relevant time frame:
Sun Aug  7 20:14:27 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> IEEE 802.11: authenticated
Sun Aug  7 20:14:28 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> IEEE 802.11: associated (aid 7)
Sun Aug  7 20:14:28 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> RADIUS: starting accounting session <session1>
Sun Aug  7 20:14:28 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> WPA: pairwise key handshake completed (RSN)
...
Mon Aug  8 06:47:42 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> WPA: group key handshake completed (RSN)
...
Mon Aug  8 12:25:23 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> IEEE 802.11: authenticated
Mon Aug  8 12:25:24 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> IEEE 802.11: associated (aid 7)
Mon Aug  8 12:25:24 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> RADIUS: starting accounting session <session2>
Mon Aug  8 12:25:24 2022 daemon.info hostapd: if-iot: STA <nuki_hub_mac> WPA: pairwise key handshake completed (RSN)

So the MQTT reconnect on Sunday 20:14 was related to a WiFi reconnect, probably after a reboot due to network timeouts (I fiddled with some settings at that time). The numerous reconnects today don't seem to have anything to do with the network itself.

Sorry I'm not really sure what to do about this, and the ticket is open for a long time. Is this kind of behavior still happening? A new Arduino Core for ESP32 was just released (v2.0.5), which includes fixes from Espressif. This may or may not help.

I have not noticed it again, but I've since changed my restart settings:

I've updated the core to 2.0.5, could you give the attached binary a try?
For fixes in 2.0.5 see here:
https://github.com/espressif/arduino-esp32/releases/tag/2.0.5
nuki_hub_core_2.0.5.zip

I can try the binary, but I'm not sure if I can really test anything (except wait and see if the behavior comes back).

Since updating the firmware, my Mosquitto log has quite a lot of malformed packet errors (unfortunately, I don't have a log from before, but I never noticed them before, certainly not in such a large number).
2022-09-17 22:55:11: Client <nukihost> disconnected due to malformed packet.
2022-09-17 22:55:11: New connection from <ip>:52751 on port <port>.
2022-09-17 22:55:11: New client connected from <ip>:52751 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-17 23:00:38: Saving in-memory database to /data//mosquitto.db.
2022-09-17 23:30:39: Saving in-memory database to /data//mosquitto.db.
2022-09-18 00:00:40: Saving in-memory database to /data//mosquitto.db.
2022-09-18 00:14:08: Client <nukihost> disconnected due to malformed packet.
2022-09-18 00:14:08: New connection from <ip>:52752 on port <port>.
2022-09-18 00:14:08: New client connected from <ip>:52752 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 00:14:11: Client <nukihost> disconnected due to malformed packet.
2022-09-18 00:14:11: New connection from <ip>:52753 on port <port>.
2022-09-18 00:14:11: New client connected from <ip>:52753 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 00:19:38: Client <nukihost> disconnected due to malformed packet.
2022-09-18 00:19:38: New connection from <ip>:52754 on port <port>.
2022-09-18 00:19:38: New client connected from <ip>:52754 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 00:30:41: Saving in-memory database to /data//mosquitto.db.
2022-09-18 01:00:42: Saving in-memory database to /data//mosquitto.db.
2022-09-18 01:08:02: Bad client <nukihost> sending multiple CONNECT messages.
2022-09-18 01:08:02: Client <nukihost> disconnected due to protocol error.
2022-09-18 01:08:02: New connection from <ip>:52755 on port <port>.
2022-09-18 01:08:02: New client connected from <ip>:52755 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 01:30:43: Saving in-memory database to /data//mosquitto.db.
2022-09-18 01:56:59: Client <nukihost> disconnected due to protocol error.
2022-09-18 01:56:59: New connection from <ip>:52756 on port <port>.
2022-09-18 01:56:59: New client connected from <ip>:52756 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 01:58:02: Client <nukihost> disconnected due to malformed packet.
2022-09-18 01:58:02: New connection from <ip>:52757 on port <port>.
2022-09-18 01:58:02: New client connected from <ip>:52757 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 02:00:44: Saving in-memory database to /data//mosquitto.db.
2022-09-18 02:27:14: Client <nukihost> disconnected due to malformed packet.
2022-09-18 02:27:14: New connection from <ip>:52758 on port <port>.
2022-09-18 02:27:14: New client connected from <ip>:52758 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 02:30:45: Saving in-memory database to /data//mosquitto.db.
2022-09-18 03:00:46: Saving in-memory database to /data//mosquitto.db.
2022-09-18 03:11:20: Client <nukihost> disconnected due to protocol error.
2022-09-18 03:11:21: New connection from <ip>:52759 on port <port>.
2022-09-18 03:11:21: New client connected from <ip>:52759 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 03:24:20: Client <nukihost> disconnected due to malformed packet.
2022-09-18 03:24:21: New connection from <ip>:52760 on port <port>.
2022-09-18 03:24:21: New client connected from <ip>:52760 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 03:29:26: Client <nukihost> disconnected due to malformed packet.
2022-09-18 03:29:27: New connection from <ip>:52761 on port <port>.
2022-09-18 03:29:27: New client connected from <ip>:52761 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 03:30:47: Saving in-memory database to /data//mosquitto.db.
2022-09-18 03:56:29: Client <nukihost> disconnected due to malformed packet.
2022-09-18 03:56:29: New connection from <ip>:52762 on port <port>.
2022-09-18 03:56:29: New client connected from <ip>:52762 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 04:00:48: Saving in-memory database to /data//mosquitto.db.
2022-09-18 04:12:29: Client <nukihost> disconnected due to malformed packet.
2022-09-18 04:12:29: New connection from <ip>:52763 on port <port>.
2022-09-18 04:12:29: New client connected from <ip>:52763 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 04:30:49: Saving in-memory database to /data//mosquitto.db.
2022-09-18 04:45:32: Client <nukihost> disconnected due to protocol error.
2022-09-18 04:45:32: New connection from <ip>:52764 on port <port>.
2022-09-18 04:45:32: New client connected from <ip>:52764 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 05:00:50: Saving in-memory database to /data//mosquitto.db.
2022-09-18 05:30:51: Saving in-memory database to /data//mosquitto.db.
2022-09-18 06:00:52: Saving in-memory database to /data//mosquitto.db.
2022-09-18 06:29:08: Client <nukihost> disconnected due to malformed packet.
2022-09-18 06:29:09: New connection from <ip>:52765 on port <port>.
2022-09-18 06:29:09: New client connected from <ip>:52765 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 06:30:53: Saving in-memory database to /data//mosquitto.db.
2022-09-18 07:00:54: Saving in-memory database to /data//mosquitto.db.
2022-09-18 07:08:35: Client <nukihost> disconnected due to malformed packet.
2022-09-18 07:08:36: New connection from <ip>:52766 on port <port>.
2022-09-18 07:08:36: New client connected from <ip>:52766 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 07:30:55: Saving in-memory database to /data//mosquitto.db.
2022-09-18 08:00:56: Saving in-memory database to /data//mosquitto.db.
2022-09-18 08:27:41: Client <nukihost> disconnected due to malformed packet.
2022-09-18 08:27:42: New connection from <ip>:52767 on port <port>.
2022-09-18 08:27:42: New client connected from <ip>:52767 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 08:29:51: Client <nukihost> disconnected due to malformed packet.
2022-09-18 08:29:51: New connection from <ip>:52768 on port <port>.
2022-09-18 08:29:51: New client connected from <ip>:52768 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 08:30:57: Saving in-memory database to /data//mosquitto.db.
2022-09-18 08:39:51: Warning: Received PUBREC from <nukihost> for an unknown packet identifier 12356.
2022-09-18 08:39:51: Bad socket read/write on client <nukihost>: Invalid function arguments provided.
2022-09-18 08:39:51: New connection from <ip>:52769 on port <port>.
2022-09-18 08:39:51: New client connected from <ip>:52769 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 09:00:58: Saving in-memory database to /data//mosquitto.db.
2022-09-18 09:27:33: Client <nukihost> disconnected due to malformed packet.
2022-09-18 09:27:33: New connection from <ip>:52770 on port <port>.
2022-09-18 09:27:33: New client connected from <ip>:52770 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-18 09:30:59: Saving in-memory database to /data//mosquitto.db.
2022-09-18 09:44:42: Client <nukihost> disconnected due to malformed packet.

(No functional problem, yet. I've no set the restart timeout to -1 again, so let's see what's happening in the next few days.)

Thanks. Just to be sure, could you get a log with the released firmware? If this does indeed happen with with the new core, I'd postpone updating.

Sure. Is it possible that there are underlying problems that always existed but only with the new core manifest as explicit errors?

Just to make sure: Should this test release have different version number or just 5.15? (If it should show a different name, I've probably been on stock all along.)

It's still 5.15, but I added -core-v2.0.5.

OK, so the errors were from stock 5.15. I'll try flashing the new binary again.

Huh, so I have hard time doing an OTA. Somehow, it appears the network stack is wonky (or my ESP32 has decided it is a good time to die). Ping veers into several seconds every few packets, and sometimes even times out even when in the same room as the router. I've skipped several version (roughl 5.9 to 5.14 IIRC, but I'm not completely sure which was the earliest). Before 5.15 OTA worked fine (after you cleared up the initial issues with credentials).
Anyway, how can I install the test version via esptool.py, can I just use the other .bin files from the normal release?

Yes, the other files didn't change. Just replace nuki_hub.bin and that's it.

P.S.: Do you also have network problems with the "official" 5.15 ?

P.S.: Do you also have network problems with the "official" 5.15 ?

Everything above was with the official release, before updating to the new core. Since the update, the Mosquitto log still looks the same (e.g. frequent protocol errors), but the integration seems to work fine. Bluetooth and WiFi RSSI seem to be much more consistent than before. I'll do a ping test and post the logs later.

Much better ping after flashing 5.15#core_2.0.5 (still dropping a packet here and there, but about 10 times less and ping is mostly und 100 ms instead of 2 to 5 seconds).
Here's the current Mosquitto log:
2022-09-19 03:53:01: New connection from <ip>:58404 on port <port>.
2022-09-19 03:53:01: New client connected from <ip>:58404 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 04:01:36: Saving in-memory database to /data//mosquitto.db.
2022-09-19 04:04:15: Client <nukihost> disconnected due to malformed packet.
2022-09-19 04:04:16: New connection from <ip>:58405 on port <port>.
2022-09-19 04:04:16: New client connected from <ip>:58405 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 04:26:07: Client <nukihost> disconnected due to malformed packet.
2022-09-19 04:26:07: New connection from <ip>:58406 on port <port>.
2022-09-19 04:26:07: New client connected from <ip>:58406 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 04:31:37: Saving in-memory database to /data//mosquitto.db.
2022-09-19 05:01:38: Saving in-memory database to /data//mosquitto.db.
2022-09-19 05:31:39: Saving in-memory database to /data//mosquitto.db.
2022-09-19 06:01:40: Saving in-memory database to /data//mosquitto.db.
2022-09-19 06:31:41: Saving in-memory database to /data//mosquitto.db.
2022-09-19 06:58:22: Client <nukihost> disconnected due to malformed packet.
2022-09-19 06:58:22: New connection from <ip>:58407 on port <port>.
2022-09-19 06:58:22: New client connected from <ip>:58407 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 06:59:13: Client <nukihost> disconnected due to protocol error.
2022-09-19 06:59:13: New connection from <ip>:58408 on port <port>.
2022-09-19 06:59:13: New client connected from <ip>:58408 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 07:01:42: Saving in-memory database to /data//mosquitto.db.
2022-09-19 07:04:31: Client <nukihost> disconnected due to malformed packet.
2022-09-19 07:04:31: New connection from <ip>:58409 on port <port>.
2022-09-19 07:04:31: New client connected from <ip>:58409 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 07:31:43: Saving in-memory database to /data//mosquitto.db.
2022-09-19 08:01:44: Saving in-memory database to /data//mosquitto.db.
2022-09-19 08:24:58: Invalid QoS in PUBLISH from <nukihost>, disconnecting.
2022-09-19 08:24:58: Client <nukihost> disconnected due to malformed packet.
2022-09-19 08:24:58: New connection from <ip>:58410 on port <port>.
2022-09-19 08:24:58: New client connected from <ip>:58410 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 08:31:45: Saving in-memory database to /data//mosquitto.db.
2022-09-19 09:01:46: Saving in-memory database to /data//mosquitto.db.
2022-09-19 09:26:43: Client <nukihost> disconnected due to malformed packet.
2022-09-19 09:26:43: New connection from <ip>:58411 on port <port>.
2022-09-19 09:26:43: New client connected from <ip>:58411 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 09:31:47: Saving in-memory database to /data//mosquitto.db.
2022-09-19 10:01:48: Saving in-memory database to /data//mosquitto.db.
2022-09-19 10:31:49: Saving in-memory database to /data//mosquitto.db.
2022-09-19 10:34:34: Client <nukihost> disconnected due to malformed packet.
2022-09-19 10:34:34: New connection from <ip>:58412 on port <port>.
2022-09-19 10:34:34: New client connected from <ip>:58412 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 10:37:34: Client <nukihost> disconnected due to malformed packet.
2022-09-19 10:37:34: New connection from <ip>:58413 on port <port>.
2022-09-19 10:37:34: New client connected from <ip>:58413 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 11:01:50: Saving in-memory database to /data//mosquitto.db.
2022-09-19 11:24:46: Client <nukihost> disconnected due to protocol error.
2022-09-19 11:24:46: New connection from <ip>:58414 on port <port>.
2022-09-19 11:24:46: New client connected from <ip>:58414 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 11:31:51: Saving in-memory database to /data//mosquitto.db.
2022-09-19 11:40:13: Client <nukihost> disconnected due to malformed packet.
2022-09-19 11:40:13: New connection from <ip>:58415 on port <port>.
2022-09-19 11:40:13: New client connected from <ip>:58415 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 11:56:01: Client <nukihost> disconnected due to malformed packet.
2022-09-19 11:56:01: New connection from <ip>:58416 on port <port>.
2022-09-19 11:56:01: New client connected from <ip>:58416 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 11:56:04: Client <nukihost> disconnected due to malformed packet.
2022-09-19 11:56:04: New connection from <ip>:58417 on port <port>.
2022-09-19 11:56:04: New client connected from <ip>:58417 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 12:01:52: Saving in-memory database to /data//mosquitto.db.
2022-09-19 12:31:53: Saving in-memory database to /data//mosquitto.db.
2022-09-19 13:01:54: Saving in-memory database to /data//mosquitto.db.
2022-09-19 13:31:55: Saving in-memory database to /data//mosquitto.db.
2022-09-19 13:34:19: Client <nukihost> disconnected due to malformed packet.
2022-09-19 13:34:19: New connection from <ip>:58418 on port <port>.
2022-09-19 13:34:19: New client connected from <ip>:58418 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 13:56:08: Client <nukihost> disconnected due to malformed packet.
2022-09-19 13:56:08: New connection from <ip>:58419 on port <port>.
2022-09-19 13:56:08: New client connected from <ip>:58419 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 14:01:56: Saving in-memory database to /data//mosquitto.db.
2022-09-19 14:06:39: Client <nukihost> disconnected due to malformed packet.
2022-09-19 14:06:39: New connection from <ip>:58420 on port <port>.
2022-09-19 14:06:39: New client connected from <ip>:58420 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 14:31:57: Saving in-memory database to /data//mosquitto.db.
2022-09-19 14:39:15: Client <nukihost> disconnected due to malformed packet.
2022-09-19 14:39:15: New connection from <ip>:58421 on port <port>.
2022-09-19 14:39:15: New client connected from <ip>:58421 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 15:01:58: Saving in-memory database to /data//mosquitto.db.
2022-09-19 15:03:01: Client <nukihost> disconnected due to malformed packet.
2022-09-19 15:03:01: New connection from <ip>:58422 on port <port>.
2022-09-19 15:03:01: New client connected from <ip>:58422 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 15:31:59: Saving in-memory database to /data//mosquitto.db.
2022-09-19 15:39:13: Client <nukihost> disconnected due to malformed packet.
2022-09-19 15:39:13: New connection from <ip>:58423 on port <port>.
2022-09-19 15:39:13: New client connected from <ip>:58423 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 16:02:00: Saving in-memory database to /data//mosquitto.db.
2022-09-19 16:32:01: Saving in-memory database to /data//mosquitto.db.
2022-09-19 17:02:02: Saving in-memory database to /data//mosquitto.db.
2022-09-19 17:02:34: Client <nukihost> disconnected due to malformed packet.
2022-09-19 17:02:34: New connection from <ip>:58424 on port <port>.
2022-09-19 17:02:34: New client connected from <ip>:58424 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 17:05:58: Client <nukihost> disconnected due to malformed packet.
2022-09-19 17:05:58: New connection from <ip>:58425 on port <port>.
2022-09-19 17:05:58: New client connected from <ip>:58425 as <nukihost> (p2, c1, k15, u'<user>').
2022-09-19 17:22:34: Client <nukihost> disconnected due to malformed packet.

No real change here. I am assuming the default log level of the Mosquitto container changed during a recent update, so that might explain why those malformed packets weren't there when I checked the log with earlier versions.

So this is the Bluetooth signal of the opener from yesterday till now. The huge drop in the middle is when I took the ESP32 elsewhere for flashing.

Not sure about the small drop this afternoon. It coincides when a member of the household arrived home, but I don't have an explanation for the change.

Thanks, I'll prepare a new Release with core 2.0.5. Interesting there's still that much to fix about Wifi, considering it's one of the main features of the chip.

I think I've found the reason for the unresponsive device and it has nothing to do with either WiFi connectivity or MQTT. This diagram shows the Bluetooth RSSI for both the Lock and the Opener:

The horizontal line between roughly 6:42 and 9:55 is the same for both devices - there were no new measurements coming in via MQTT, but in this diagram, adding WiFi RSSI you can see that device was always online.

Apparently, the BT stack got into a weird state and stopped reporting anything until some kind of reset fixed things. (Probably a reboot of the ESP32, it's hard to tell from the graph, but there is a one minute flatline on the WiFi just before BT reporting resumes.)

Very strange. Is this the old or the new core?
As a workaround I could reset the ESP when no beacons are received and thus the bluetooth RSSI isn't updated, but I don't really like such workarounds.

P.S.: Might be worth trying to update the ble lib:
https://github.com/h2zero/NimBLE-Arduino
There's a new release from end of june

Very strange. Is this the old or the new core?
As a workaround I could reset the ESP when no beacons are received and thus the bluetooth RSSI isn't updated, but I don't really like such workarounds.

The graph is from the new core, but I'm by now 100 % certain that that's what happened before. I found a similar episode in the old logs from a few weeks ago and it happened again today.
Updating the BLE library certainly sounds like a good idea, but so does a failsafe trigger similar the network timers. I agree that finding the root cause would be better, but that may not be possible without some extensive long-time logging (which is difficult in operating conditions - though it might be possible if you could implement a wireless way to access the logs).

Hi,
sorry I was rather busy the last few days. I'll look into it, let's first try updating the bluetooth library.

The attached binary is compiled with

core 2.05
nimble 1.40

Could you give it another try? If this doesn't fix it, I'll add another restart option ... and yes remote logging would help indeed.
nuki_hub_nimble-1.40.zip

I've updated the ESP using the new binary (had some issues with it - seems the OTA is not as smooth at was before for me, feels a bit like before the issue with credentials was fixed. (There's a chance it correlates with the device switching to a "bad" access point and sticking to it between reboots, and it's not since updating to the original 5.15).
I will monitor the issue, but it will take at least three days to have some confidence it's not occurring anymore. I've added an automation to HA to trigger a restart via MQTT if the RSSI value for both Lock and Opener does not change for over 60 seconds. (The automation also logs an error and sends me a notification.)

ok, thanks for testing. I'd like to release since it seems to improve WiFi issues, let's just make sure it doesn't make things worse.
Yes an automatic restart from HA is possible of course, it should work in the meantime. It would still be better to have the firmware do it, it can probably detect it a bit faster and more reliable, and makes the feature independent from the frontend used.

Unfortunately, I can already tell you that the new library does not help (and that my automation also has some kind of error because it did not trigger). Had a BT dropout during the night.

Since I don't really have an explanation, let's try the automatic reboot. The attached binary restarts when no beacons have been received for ~2 minutes. Can you check if it improves things? If yes, I'd make the timeout configurable.
nuki_hub_ble_reboot.zip

Thanks. What's the version string supposed to be on that one (to make sure the flashing took)?

I think I didn't change it. I'll just use incremental numbers for this from now on to make it easier.
I've recompiled with an updated version string:
5.15_core-2.05_nimble-1.40#01
nuki_hub#01.zip

Well, weirdly enough the drop out last night was NOT the same as the previous BT dropouts. Instead, there apparently where no MQTT changes transmitted to HA (i.e. the WiFi RSSI also dropped out). I don't see anything in the router logs to suggest that WiFi actually dropped out (there are two reconnections at the beginning and the end of the four hour drop out period, and a DHCP request in the middle, so the network must have been up). Unfortunately, the Mosquitto logs have already rolled over.
Weirdly, I
Anyway, I'll monitor this version during the next week, let's see if there are any more (non-WiFi/MQTT) drop-outs.

I'm logging Bluetooth RSSI too now, so far no issues. I've nevertheless released Version 6.0 with the libs.

I'm logging now and I don't any drops in bluetooth. I'm a using LAN module, so maybe this is some interaction between bluetooth and Wifi? They use the same antenna afterall.

It has not happened for me either since thw update of the BLE library, so I'm thinking this might have fixed the issue.

I'm logging now and I don't any drops in bluetooth. I'm a using LAN module, so maybe this is some interaction between bluetooth and Wifi? They use the same antenna afterall.

I was too hasty. There was a dropout again yesterday for about 15 minutes.

So if it dropped the automatic restart doesn't work either?

Is the automatic restart also in 6.0? I switched to that version after it was released.

ok I see. No only in the previous 5.15 for testing

ok I see. No only in the previous 5.15 for testing

So as an update, I've fixed my automation (a stray " in the trigger template) which now works very nicely. I've set the timeout to 1 minute, which is about twice the longest "natural" time between RSSI updates I've seen in my logs.

Just to confirm, you reset after not receiving any bluetooth RSSI updates?

Just to confirm, you reset after not receiving any bluetooth RSSI updates?

Yes, I reset after not receiving BT RSSI updates for either the opener or the lock (though one would suffice) for longer than 60 seconds. This is my automation:
trigger:
  - platform: template
    value_template: >-
      {{ as_timestamp( now() ) - as_timestamp(
      states.sensor.nukilock_bluetooth_signal_strength.last_changed )  > 60 }}
  - platform: template
    value_template: >-
      {{ as_timestamp( now() ) - as_timestamp(
      states.sensor.nukiopener_bluetooth_signal_strength.last_changed ) > 60 }}
condition: []
action:
  - service: system_log.write
    data:
      logger: nukihub
      message: No BLE beacons detected for over a minute. Restarting.
  - service: mqtt.publish
    data:
      topic: nuki/maintenance/reset
      payload: "1"
      qos: "2"
  - service: notify.mobile_app_myphone
    data:
      message: NukiHub neu gestartet.
mode: single

I'll add it to the firmware then.

I am also having the exact same issue described here, I'm going to try the above automation for now to see if it helps 👍

Hi ... any updates on this? Have you tried the new firmware with updated libraries?

If that's directed at me, I am still waiting for the automatic restart feature to be added to the firmware (as of https://github.com/technyon/nuki_hub/issues/28#issuecomment-1272515996). I am currently on version 6.3, but the automation is still needed to restart the device every few days at least (sometimes more often).

Sorry I completely lost track of that. I'll look into it.

Pleases check release 6.4, you can set the timeout under NUKI configuration.

Thx, I've updated and set the timeout. Will monitor the ESPs behavior for the next week or so.

I use the presence topic in HA and I monitor the updates of the presence topic in HA like this:
mqtt:
  device_tracker:
    - name: "Beacon Julien"
      state_topic: "nuki_entree/presence/devices"
      value_template: "{{ 'home' if 'xx:xx:xx:xx:xx:xx' in value else 'not_home' }}"

alias: ESP32 Presence not updating
trigger:
  - platform: template
    value_template: >-
      {{ (now() - states.device_tracker.beacon_julien.last_changed).seconds >
      120}}
condition: []
action:
  - service: notify.mobile_app_telephone_julien
    data:
      message: ESP32 Presence is not updating
mode: single

Usually, there's at least an update every 5 seconds but sometimes, it just stops.
Despite having the new option "Restart if bluetooth beacons not received" set to 30 seconds, I still get notified every few hours that the presence topic was not updated for more than 120 seconds. However, the updates come back few seconds later. I'm going to increase my notification period to 180 seconds.

Pleases check release 6.4, you can set the timeout under NUKI configuration.

Some results from the field test (I've set a BT timeout of 40 seconds on the ESP and my HA automation timeout to 120 seconds to prevent "double firing"):

The HA automation hasn't been triggered except once (and that was when my Opener stopped responding to BT again).
When a device stops responding to the BT API (confirmed to happen with the official app as well), the ESP will basically enter into a boot loop.
To allow for reconfiguration, in such cases, the boot loop should be detected and further reboots be prevented.
It would be good if some diagnostic topic could be set (allowing me to send a notification that e.g. the Opener needs to be reset by removing its batteries) if the ESP is unable to read the device state several times in a row.

In my case, I have "Restart if bluetooth beacons not received" set to 30 seconds and notification + MQTT reset (thanks to your code @mundschenk-at) is there's no update of Presence sensor for 60 seconds.
I get notifications every few hours (between 2 and 6 I would say). The ESP seems more resilient when adding with MQTT reset triggered from HA. Before that, I needed to unplug and plug it again (was it stuck in what you call "boot loop"?).
Since I get the notification after 60 seconds without updates, it means the ESP was not rebooted after 30 seconds. I think the internal check of nuki_hub for BT issues may not working as expected.

Right now, I have two unresponsive devices. I published on the maintenance/reset topic but I can see remotely that the presence or RSSI does not update at all. Is it in "boot loop"? I don't know what's causing this.
@mundschenk-at : In your case, do you mean at some point, and for unknown reasons, the Nuki device will stop reporting over BT to the ESP, and this is this behavior that is causing the ESP to "crash"?

@Mincka There are two issues I think, namely that sometimes the ESP BT stack gives up and can only be recovered by a reboot. The other appears to be a firmware bug in the latest Opener FW that makes the device lock up (coincidentally also needing a reboot, which can only be triggered by removing the batteries). The ESP BT stack issue can be mitigated using the new BT watchdog setting, but a boot loop prevention should be added to the Nuki_Hub firmware to make it more tolerant of missing devices.

I don't think this issue is only related to the Opener. I don't have the Opener but my ESPs become unresponsive after few hours and they cannot recover with Restart on disconnect + Restart timer + Restart when no beacon update.
Actually, I came back from home and I just confirmed that I cannot connect to the devices over Wi-Fi. I need to unplug them. Either there are in a boot loop or maybe they just cannot reconnect to the Wi-Fi. I will try to disable Wi-Fi for a few minutes to see if that's causing this. I will also try to monitor the serial output.

I don't think this issue is only related to the Opener. I don't have the Opener but my ESPs become unresponsive after few hours and they cannot recover with Restart on disconnect + Restart timer + Restart when no beacon update.

You are right, the issue with the ESP BT stack is not related to the Opener. I didn't intend to imply that it is, sorry if I was not clear about this.
What I meant is that the mitigation via "restart if no BT packets are received in X second" can currently trigger a boot loop if a paired device does not respond.

I just full reinstall one the ESP and during the setup I had an issue with the ESP falling back to the Wi-Fi Manager because it did not manage to join the already configured Wi-Fi for some reason. I realize this could also be something silly like this in my case. The ESP would not be in a boot loop but maybe stuck on the Wi-Fi Manager page... Next time, I will check if the ESP Access Point SSID is up.

If WifiManager can't connect to the Wifi, it will reopen the ESP access point so you can reconfigure your Wifi. There's a timeout for the Wifi config portal, but it's several minutes, so there's plenty of time to fix the wifi

The boot loop should be fixed in the latest release.

I'm on 6.10 with serial attached. The ESP stopped updating presence at some point yesterday. It was unresponsive, status not updated, did not respond to commands.

I had a look at the logs on the console, only the "usual" error messages:

The only thing I did was closing the serial console and connect again in the browser. It seemed to trigger a reboot of the ESP since I got logs and few seconds after, Presence started updated again.

My options:

It seems that the ESP crashed 27 minutes after its setup.

Since the WiFi RSSI stopped updating as well, this looks more like a network/MQTT issue than a bluetooth dropout. With a BT dropout, the WiFi connection is still there (see the second diagram in https://github.com/technyon/nuki_hub/issues/28#issuecomment-1252786140 for an example).

Indeed, you're right. I can even see in the HA log that the lacking BT updates automation was triggered at that time and the maintenance/reset topic was published on both locks but only my second lock was able to restart, not the affected one.  My automation is currently basic and dumb, if lock 1 is not updated, it publishes maintenance/reset on both locks.

Ok, so this means I should not pollute your thread. I'll try to find another related issue or maybe create a new one.

Oh, you might get both, eventually. I've been able to prevent WiFi connection issues by using both the network timeout setting and an automatic reboot once per day.

Not sure that I saw another topic describing my issue so I guess I'll create another issue. :(
I still lose the ESP despite the following options (aggressive Restart timer every 30 minutes):

This time, the ESP crashed 12 minutes after the boot. There is no suspicious message on the serial console other than things shown in https://github.com/technyon/nuki_hub/issues/28#issuecomment-1382700361
I really don't know how to diagnose this. The ESP seems just crashed without warnings in logs in an unrecoverable state. It happens on my two ESPs (M5 Atom). No sign of Wi-Fi dropout or other things in HA logs at that time. I will try to test with another ESP model but @alexdelprete also have them and does not seem to have this issue.

Anything on the routers logs?

ESP model but @alexdelprete also have them and does not seem to have this issue.

No, I don't have this issue with the M5 Atom:

Is your router configured to automatically change Wifi channel by any chance. I have a hunch that could trigger Wifi dropouts.

Yes my APs (I have a mesh network) manage channels automatically...but I didn't experience any issues, and I have a lot of ESP devices around the house (40-45 more or less, can't remember exactly).

Anything on the routers logs?
Nothing special (using OpenWRT) and no other device has this kind of issue. I have around 50 devices on Wi-Fi and other ESP-based devices (Shelly first and second generation) and no issues with them.

Is your router configured to automatically change Wifi channel by any chance. I have a hunch that could trigger Wifi dropouts.
I use fixed channels per AP for 2.4 Ghz with minimum overlap of channels and also a dedicated channel for Zigbee that is far from Wi-Fi channels. No mesh, only 3 APs connected with cables.

If the issue was "only" related to network, the ESP should restart because of connection loss OR restart at some point with the Restart timer set to 30 minutes. But nothing happens for hours . I also checked if the ESP was in AP mode but no trace of its Wi-Fi SSID.

I think I've found the culprit for my crashing ESPs. I was using the USB output of a Surface Pro for one and for the other, it was on a power strip with USB ports. I plugged both ESPs on Samsung mobile chargers (at least 1 A) and from now, no more crash. Still, the ESPs are often rebooting (Restart timer is disabled) but they always manage to reconnect. Since I don't see restart reason in the logs, I guess

mqtt:
  sensor:
    - name: "Nuki Entrée Log"
      state_topic: "nuki_entree/maintenance/log"
    - name: "Nuki Cuisine Log"
      state_topic: "nuki_cuisine/maintenance/log"
    - name: "Nuki Entrée Uptime"
      state_topic: "nuki_entree/maintenance/uptime"
      device_class: duration
      unit_of_measurement: min
    - name: "Nuki Cuisine Uptime"
      state_topic: "nuki_cuisine/maintenance/uptime"
      device_class: duration
      unit_of_measurement: min

That's why I want to include all topics in discovery. ;)

I didn't even know we had those measurements. :)
Yes, we definitely need to improve autodiscovery. ;)
What do we need to do? If I can help let me know...

I added the uptime to my Mushroom template card:

While I was editing, I noticed it rebooted (after 800+ minutes) because it started from 1. I will monitor restarts by watching the uptime sensor and send a notification.
It would be good to have a topic under maintenance with the date of last boot.

I think we fixed the problems mentioned here, I'll close for now.

Yeah, it seems unlikely we will ever definitely find the underlying cause and the new watchdog works very well.


Panic when using forall in ensures of function containing return

This might be related to #215. The following code causes a panic. If return true; is replaced with true or if we use an ensures without a quantifier, it verifies without issues.
#[allow(unused_imports)]
use builtin::*;
mod pervasive;

#[spec]
fn f(a: nat) -> bool {
    true
}

fn g() -> bool {
    ensures(|res: bool| forall(|i: nat| f(i)));
    return true;
}

fn main() {
}

results in
fhs m: source 1 ν ./tools/rust-verify.sh /st/verus/test.rs
note: verifying root module

thread 'rustc' panicked at 'assertion failed: trigs.len() == 0', vir/src/ast_to_sst.rs:227:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
verification results:: verified: 0 errors: 0

Currently, expression-return and return statements are handled in different places, the first in func_to_air and the second in ast_to_sst. The result is there are a few differences in the way they're handled.
At one point I attempted to consolidate them into place to resolve the inconsistencies,  but I never followed through as it turned out to be kind of tricky and there were a few things i didn't know how to handle. It's probably time to revisit it, though.

fixed by #312


Bulk label association

Fixes #368.

Here is what it looks like till now

Bulk association is also complete. Here is what it looks like:

Wow, great contribution, thanks a lot! Only a few, minor, UI-related change requests

[ ] In the "single-add" case, can you make either select and the button a bit more subtle, or potentially only appear after clicking a very subtle, gray "+" icon or so? With many labels and many projects, it looks a bit too cluttered with an additional select box and additional big green button each time. Or, alternatively, at least make the button a bit smaller (e.g. only a "+") and both elements (select and button) a little bit more offset to the right from the actual labels.
[ ] In the multi-select, could you make the options appear dark gray instead of white when they loose focus?

Here is the new UI.

Thank you! :+1:

@muety Could you release the docker image on ghcr as well?

Wanna wait for a few more changes / fixes to accumulate before next release, if you don't mind.

This is awesome, thank you!


List is generated dynamically

I have an ajax process where I download the hierarchy and the items first. Then I populate my list dynamically. But the collapse and expand doesn't seem to work.

What do you populate dynamically? I don't understand why? List has been changed. Its state is actual. Also which part of expading/collapsing does not work? Opener buttons or automatic expanding while dragging?

Did you try to initialize the populated list again after ajax request?

Yes I did. The reason I am doing this is because my data may contain over 400 nodes. I don't want the page to take a long time to load, so I thought of loading the page and then load the data using Ajax. I am loading the data using 2 Ajax call, where one loads up the hierarchy, and the other loads up the item information.
My code is more or less like this.
<script>
var odata;
var ohierarchy;
$(document).ready(function(){
		var a1 = $.ajax({
			url : base_url + 'aj_get_data',
			dataType: 'text',
			method : 'post'
		});

		var a2 = $.ajax({
			url : base_url + 'aj_get_hierarchy',
			dataType: 'text',
			method : 'post'
		});

		$.when(a1, a2).done(function(d1, d2){
			odata = JSON.parse(d1[0]);
			ohierarchy = JSON.parse(d2[0]);
			console.log( odata );
			console.log( ohierarchy );

			var ohtml = $.Deferred();
			var obj = {};

			ohtml.promise(obj);
			ohtml.resolve( build_hierarchy(ohierarchy) );
			// build_hierarchy() is a recursive function to generate ul-li HTML

			obj.done(function(html){
				console.log(html);
				$('#sortable-list').html( html );
				var options = {
					ignoreClass: 'clickable',
					hintClass: 'hintClass',
					placeholderClass: 'placeholderClass',
				};
				$('#sortable-list').sortableLists(options);
			});

		});
});
</script>

The sortable list is working & I can drag things around but

it does not generate the caret icon for expand and collapsing items with children
I cannot click on my custom buttons, the one that I the 'clickable' class.

Ok I understand. It is little weird if everithing works but open/close buttons not. For sure, do you have  opener section in options object?

Oh man, I missed that. It is working now.
Previously I see that the span was generated on object drop. I just used CSS to style the span.

Ok.