text:
Iterative_timeout after a certain amount of requests

I am trying to run the ZDNS tool on alexa1m using the iterative mode
cat top-1m.csv |./zdns A -iterative -alexa
At the start of the list, I get the expected results:
{"alexa_rank":3567,"data":{"answers":[{"answer":"47.119.172.75","class":"IN","name":"ylsw.com","ttl":600,"type":"A"}],"protocol":"udp","resolver":"106.11.141.114:53"},"name":"ylsw.com","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}
{"alexa_rank":3349,"data":{"answers":[{"answer":"213.16.167.115","class":"IN","name":"sport-fm.gr","ttl":600,"type":"A"}],"protocol":"udp","resolver":"208.78.70.14:53"},"name":"sport-fm.gr","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}
{"alexa_rank":4833,"data":{"answers":[{"answer":"52.2.4.21","class":"IN","name":"topcashback.com","ttl":60,"type":"A"},{"answer":"34.202.70.123","class":"IN","name":"topcashback.com","ttl":60,"type":"A"},{"answer":"54.237.74.19","class":"IN","name":"topcashback.com","ttl":60,"type":"A"},{"answer":"23.20.184.113","class":"IN","name":"topcashback.com","ttl":60,"type":"A"}],"protocol":"udp","resolver":"205.251.194.157:53"},"name":"topcashback.com","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}
{"alexa_rank":4807,"data":{"answers":[{"answer":"23.6.118.43","class":"IN","name":"massimodutti.com","ttl":20,"type":"A"},{"answer":"23.6.118.73","class":"IN","name":"massimodutti.com","ttl":20,"type":"A"}],"protocol":"udp","resolver":"72.246.46.65:53"},"name":"massimodutti.com","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}
{"alexa_rank":4404,"data":{"answers":[{"answer":"192.230.74.118","class":"IN","name":"tcgplayer.com","ttl":300,"type":"A"},{"answer":"192.230.66.118","class":"IN","name":"tcgplayer.com","ttl":300,"type":"A"}],"protocol":"udp","resolver":"205.251.194.207:53"},"name":"tcgplayer.com","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}
{"alexa_rank":4566,"data":{"answers":[{"answer":"104.20.135.21","class":"IN","name":"e-hentai.org","ttl":300,"type":"A"},{"answer":"172.67.0.127","class":"IN","name":"e-hentai.org","ttl":300,"type":"A"},{"answer":"104.20.134.21","class":"IN","name":"e-hentai.org","ttl":300,"type":"A"}],"protocol":"udp","resolver":"172.64.32.145:53"},"name":"e-hentai.org","status":"NOERROR","timestamp":"2021-06-17T04:26:32-04:00"}

After a certain amount of time ~15-20sec, I only receive ITERATIVE_TIMEOUT with no results. For almost every other domain after that point, I never get a result.
{"alexa_rank":13888,"data":{"protocol":"","resolver":""},"name":"zp.cc","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":14086,"data":{"protocol":"","resolver":""},"name":"mrw.es","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":14083,"data":{"protocol":"","resolver":""},"name":"micap.es","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":11326,"data":{"protocol":"","resolver":""},"name":"pmkisan.gov.in","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":14410,"data":{"protocol":"","resolver":""},"name":"diggbt.ws","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":14311,"data":{"protocol":"","resolver":""},"name":"mygovid.ie","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}
{"alexa_rank":14579,"data":{"protocol":"","resolver":""},"name":"uniqlo.cn","status":"ITERATIVE_TIMEOUT","timestamp":"2021-06-17T04:27:49-04:00"}

I have already tried to change the number of go threads, the iterative-timeout, the timeout, and the cache size, it only changes the initial records that are being resolved and the same issue occurs again but at a later point.
I suspected that I might run out of ports and I have also monitor the number of open ports and it seems that is equal to the number of threads as expected.
Any advice? Am I doing something wrong or is there anything that I am missing?

Hey @ParisConstantinides, sorry about just getting around to this.
So I'm unable to reproduce this, ran zdns on the Alexa1m file for about 300k entries and only saw around 2k timeouts:
~/zdns on  main! ⌚ 19:11:18
$ cat top-1m.jsonl | wc -l
329152

~/zdns on  main! ⌚ 19:11:28
$ cat top-1m.jsonl | grep "TIMEOUT" | wc -l
9928

We've made a couple performance improvements in the past couple months. If anyone sees this crop up again, please re-open!

authors: ParisConstantinides phillip-stephens

repo: zmap/zdns


text:
All the planets are gone?

I've upgraded from version 1.0.8 to version 1.0.11 and have noticed that there arent any planets to choose in the selection screen.  Even the moon is gone.  I havent been anywhere in space yet as I've been building up resources, etc. and have always been able to see other planets.  Currently, the only one that shows up in the rocket or the planet selector machine is Earth (moons: 0).
Any suggestions?  I can provide whatever you need.  Currently the server is running on Forge version 2239.

FYI, creating a fresh single-player world shows planets in each solar system.
I've also looked at my Satellite Terminal's and each of them show 'No Link'.  They still have the Satellite ID chips in them.

There was a bug introduced in 1.0.11 that broke the planets, I released a fix for 1.7.10 and thought I released the 1.10.2 update but i apparently forgot, I'll have a build up in a minute

Should be up on curse now, just waiting approval.

Thank you!  I'll keep an eye out.

It works!  Thanks again for your prompt response and fix!

source: gharchive/issue

license: mit

license_type: permissive

license_source: bigquery


text:
feat: 完成题目数据解析功能

完成题库数据解析功能
完成题库上传功能
补充相关UI界面

@JessieChan0730 感谢贡献，非常棒的实现。不过我注意到还有几个小问题可能需要修改
1、添加多个选项后换行的选项外边距可能过窄需要调整一下（如下图）

2、高级配置未实现的话可以删除或者注释掉

3、通过账号体系的 token 应该是可以直接提交数据的（如果后端接口有问题可以让我看看），能否实现不需要创建应用直接使用账号 token 进行提交

4、点击清空数据按钮会直接跳转结果页面，而非清空数据重新提交

感谢你的贡献，期待修复后的提交，有问题随时联系我

LGTM

source: gharchive/pull-request

license: MIT

license_source: github-api


text:
Bad behaviour when I want past an url in the search field.

For search purpose ( ctrl+f or ctrl+maj+f )
I need to be able to paste an url in the search box but when I paste the url, the editor capture the action and the url text is paste on the opened md document...
Thanks you for this good job !

Just to note that this is still happening in 1.2.3- I'd love to know if anyone finds a workaround other than turning the plugin off, as, so far as I can see, it makes it impossible to search for URLs in a vault.

This is still happening, and is quite a problematic issue. It feels like a keyboard problem, because you're looking at the search field, and typing the Paste short-cut - and nothing goes in to the search field.
So you paste a few more times - then give up...
And only then notice that you've messed your note by pasting in a load of unwanted text.
@zolrath Thank you for the very useful plugin - Could you give any pointers as to where to look, for how to fix this please, in case anyone has time to work on a PR?

I've updated the minimum Obsidian version to 12.17 as it gives us access to the "editor-paste" event. Now that we only intercept pastes in the editor this issue should no longer occur!

authors: EKliptus claremacrae zolrath

repo: zolrath/obsidian-auto-link-title


text:
go.mod: fix module path

When I try to use this module instead of go-llsqlite, I get this:
go: github.com/zombiezen/go-sqlite@v1.4.0: parsing go.mod:
	module declares its path as: zombiezen.com/go/sqlite
	        but was required as: github.com/zombiezen/go-sqlite

I know that this eventually to be fixed in go with redirects, but today it is not usable for me without forking it.
Could you please adjust this?

The correct import path for this module is zombiezen.com/go/sqlite. See the README for install instructions.

thanks! I missed that note

authors: nikkicoon zombiezen

repo: zombiezen/go-sqlite

license: ISC


text:
:apple:  ws链接握手认证

这是一套ws连接时握手认证的功能逻辑，可以根据请求头中的token进行鉴权或者请求uri的参数进行鉴权，这一套逻辑在我项目要当中是适用的。

是的 所以几个类都是新增的 可以说提供下鉴权思路

好的多谢啦，大家也可以根据示例代码看看思路，然后来提交完整pe，这个就先不通过咯

repo: zongzibinbin/MallChat


text:
add apple privacy manifest & usage descriptions for UserDefaults

Summary
#830
Starting May 1, Apple will enforce 3rd party SDK's to sign & provide privacy manifests for specific API's being accessed by the code. This change adds a privacy manifest and reason for using the data. Apple Documentation
I have added a declaration for use of UserDefualts via NSPrivacyAccessedAPICategoryUserDefaults and from reading the code have stated the reason
CA92.1
Declare this reason to access user defaults to read and write information that is only accessible to the app itself.

This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps.

Test Plan
What's required for testing (prerequisites)?
Build and run the example app
What are the steps to test it (after prerequisites)?
Upon building the IPA you can inspect the IPA and find RNPermissions_PrivacyInfo.bundle and within that find PrivacyInfo.xcprivacy
Compatibility

OS
Implemented

iOS
✅

Android
❌

Checklist

[x] I have tested this on a device and a simulator
[ ] I added the documentation in README.md
[ ] I added a sample use of the API in the example project (example/App.tsx)

Notes

iOS Only
No changes required to documentation
No additions required for the example project

@johnhatvani Thanks! I merge that in a separate branch as it's still need a bit of work (ideally, we want to add the manifest only if the concerned permission is used: FaceID)
Then I will do a release.

@zoontek Thanks! I'm not sure that the manifests are conditional like that, unless you have seen something different?

@johnhatvani I updated the setup script to conditionally comment / uncomment the line: https://github.com/zoontek/react-native-permissions/blob/master/scripts/setup.rb

nice change! was wondering how you would achieve that 🙏🏼

authors: johnhatvani zoontek

repo: zoontek/react-native-permissions


text:
🛑 AI Portal is down

In e66361c, AI Portal (https://aiportal.army.mil/aiportal/Account/ConsentToMonitor) was down:

HTTP code: 0
Response time: 0 ms

Resolved: AI Portal is back up in 1f6c077.

repo: zootsewt/aistatus


text:
Dev Prep: E2E Simple Infra

[ ] simple cypris e2e test scripts
[ ]  marker package to share between ui-components and cypris tests
[ ] documentation (a few words about approach and links to resources )

Link with integration https://github.com/zorko-io/zorko-mono/tree/master/packages/e2e-test-suite

repo: zorko-io/zorko-platform


text:
looks good -- minor suggestion

You could import Base: push!, pushfirst! and name your corresponding routines with the trailing !, which, by convention indicates alter-in-place or replace-with-altered.

Thanks!
The structure is supposed to be immutable, so that it's safe to reuse parts. I suppose I could make a mutable version as well...

I changed push() and pushfirst() to use same the argument order as push!() and pushfirst!()

that is a good call

authors: JeffreySarnoff zot


text:
Directx11

add option to for d3dx11 internal and a d3dx11 external overlay.

good issue, consider adding support for dx11 in the future

authors: movrax zouxianyu

repo: zouxianyu/evil-cat


text:
Issue with docs.zowe.org/stable/user-guide/ze-ftp/

Doc enhancement request:
See: https://docs.zowe.org/stable/user-guide/ze-ftp
In the sections:

List of Supported Data Set Functionalities
List of Supported USS Functionalities
List of Supported Jobs Functionalities

List unsupported functionalities.  I'm sure that the lists will be shorter and be of more value to the reader.
Engage the Zowe Explorer FTP Extension team for the content.

The team agreed to leave the content as-is.  Rather than describe what is not supported, document what is supported to demonstrate the progression of the FTP extension.
Closing issue:  no action required.

repo: zowe/docs-site


text:
Document the steps that an API ML extender needs to take to achieve SSO within Zowe

This the documentation of what an API ML extender needs to take to achieve SSO within Zowe.
It has been reviewed by @janan07 as a part of #937.
Resolves zowe/api-layer#438
Note to reviewers: Do not review or modify unrelated documentation in this PR, please open a new PRs for unrelated changes.
Is there a related issue for this PR?
Issue number: zowe/api-layer#438
Developer's Certificate of Origin (DCO)
Signed-off-by: Petr Plavjanik plavjanik@gmail.com

@janan07 I think it can be merged. But the build fails (PDF could not be generated). Who can help with it?

@janan07 @plavjanik Merging this PR. The PDF failure is might be a Jenkins issue. Looking into that.

authors: nannanli plavjanik


text:
--depth flag behaviour

Possible Awareness for Community
Just wondering if gents/ladies need to be made aware of this slight behaviour change
To Reproduce
With v7.2.0 use --depth flag on a project that had a secret on another branch's commit history. In my case value passed to flag was 2.
Expected behavior
Was initially expecting the secret to be found just like normally occurs in v6.2.0 but alas, that was not the case. This led me to #460. There I realized that the --depth option was being passed directly to the git clone command as such after reading the docs I realized when using the --depth flag on git clone the behaviour is slightly different from what used to occur before.
This new behaviour is not a problem at all since I know it is just a difference in how git walks down the tree in collecting parent information.
Just wanted to bring this difference to the attention of folks and the powers that be.
Good day!
Basic Info (please complete the following information):

OS: macOS Catalina 10.15.7
Gitleaks Version: 7.2.0

cc @zricethezav

you can pass git log -p option into gitleaks with the --log-opts flag. So to set a depth you can pass --log-opts -1 which execute git log -p -1 under the hood

authors: bhornsby zricethezav

repo: zricethezav/gitleaks


text:
Fully Integration with Breadcrumb

Breadcrumb introduced some nice featured to avoid writing metadata in every single files, see Alternative Hierarchies
Let's says I have a /MyFolder/Index.md one that I use very often is Folder Note:
---
BC-folder-note: children
BC-folder-note-up: parent
---

or
BC-folder-note:: children
BC-folder-note-up:: parent

When I place this in the front-matter or as a DV field then all the notes within /MyFolder/ result as children of the Index note.
This avoids to write in every single note within that folder the metadata parent:: [[Index]]
Is there a way to achieve this in excalibrain or to fully integrate the BC Alternative Hierarchies?
Thanks

Originally ExcaliBrain was built on top of BC. Unfortunately, Breadcrumbs (at the time, maybe still) did not differentiate between the same filename but in different folders. As a result, I moved ExcaliBrain to be based on DataView. Whatever format Dataview supports, ExcaliBrain should also support it.
I don't use frontmatter for defining the hierarchy because those fields don't get updated when I rename or move files. Instead of the frontmatter, I recommend adding dataview fields in the body of the document. You can always hide them by placing the section in markdown comments:
%%
parents:: [[parent doc]]
%%

I don't use frontmatter for defining the hierarchy because those fields don't get updated when I rename or move files.

This should't be a problem anymore thanks to the introduction of properties, see my comment here.
Now that this is not a problem anymore would still consider the integration of the two plugins?

would like this feature for BC-regex-note as well, or is there another way to do that?

authors: LeonardoGentile d1n6 zsviczian

repo: zsviczian/excalibrain


text:
Bot

How config a botM please record for me i pay for help

email me on vanakgame@gmail.com

repo: ztizzlegaming/CSGOWinBig


text:
context path问题

当设置了java web contextpath之后，异步加载js path不对了。请问如何解决？

demo是正常的，不知道你改了什么配置，也不知道你是用的什么版本

authors: Itdotaer zuiidea

repo: zuiidea/antd-admin


text:
Add support for login via web

We have a few login mechanisms that we're unlikely to want to build into the app natively (both corporate SSO type things like Apache REMOTE_USER and things like GitHub auth).
To support these more unusual login flows, I think maybe we should support "login via web", where basically the app logs into the Zulip website using a web authentication flow, but then rather than loading the website, it instead could just grab a credential and pass it back to the app.
It will likely require some server changes to support this (mainly either just supporting the redirect-at-the-end piece to get an API key), so probably best for whoever works on this to have a working Zulip development server and familiarity with our backend.

Do we need to do this?
As we are moving towards React Native app so What do you suggest ??

Yeah I think this is a sufficiently marginal feature that we should just skip it.  We just implemented this feature in the RN app.

authors: meghalagrawal timabbott

repo: zulip/zulip-android


text:
Previews when composing a message

This is a useful feature in web:
https://zulip.com/help/preview-your-message-before-sending
and it would be useful in mobile too.
(It's not as common to want it in mobile, I think, because one tends to stick to shorter messages with simpler formatting. But that's far from absolute.)

We had a user request for this the other day:
https://chat.zulip.org/#narrow/channel/48-mobile/topic/iOS.20feedback.20for.20Julia.20community.20member/near/1961857
https://chat.zulip.org/#narrow/channel/48-mobile/topic/iOS.20feedback.20for.20Julia.20community.20member/near/1963803
They raised code blocks and LaTeX as particularly useful situations for a preview.

hey,
I am working on this issue

Please correct me If i am doing something wrong
So, I checked the website of zulip and checked how this view button works
I started working on this issue and I have showed the message in the dialogbox so this is how it looks like .

So, the model this is right or should i do same like what is done in the web

Let's put the preview in the compose box, replacing the content input, just like in Zulip web.
And the text styling should be sure to be the same as it is in the message list — after all, the point of the preview is to see how your message will look if you send it. In the screenshot above, it looks like the text is smaller.

https://github.com/user-attachments/assets/27fa956f-2f7d-4c4d-8409-4b124a025351
i have done this to the text can you please check is it correct

Please post a screenshot where the message uses some Zulip Markdown features, like:
*italic*

**bold**

```
code block
```

```spoiler
testing
```

[image2.jpg](/user_uploads/2/5b/4T9c_99X3W2IYB62fKnIzyvk/image2.jpg)

This feature will be complex to implement. It will require some work toward #488, at least to address the fact that the image-preview widget currently depends on a Message object (for the lightbox), and we don't have a Message object in this context.

I have done the bold and the italic thing but right now i am working on the ``` and the image preview
https://github.com/user-attachments/assets/592d207d-324f-4d56-9bc1-c7f2ed959f6d

@whodivyanshu It doesn't sound like you're approaching this in a way that's going to work. A successful approach to this issue isn't going to involve re-implementing Zulip's message content features one by one.
If you want to share more details of what you're doing, please start a PR thread or a chat thread in #mobile-dev-help. Let's keep this issue thread clear so it's readable for discussion of the issue itself.

Oh hey, it turns out we already had an issue for this:

#178

I'll close this thread in favor of that one, and consolidate to there the useful bits of information from this thread.

authors: chrisbobbe gnprice whodivyanshu

repo: zulip/zulip-flutter


text:
deps: Upgrade Flutter to latest main, 3.16.0-23.0.pre.38

And update Flutter's supporting libraries to match.

Thanks! Looks good; merging.

@sirpengi FYI re the first commit; see also https://github.com/zulip/zulip-flutter#upgrading-dependencies .

authors: chrisbobbe gnprice


text:
responsive view, mobile: message actions menu overlays the message and can block interaction

Just noticed this on my phone (Pixel 3 XL, Chrome):

There's an open issue and pr for this.
-Tim Abbott (mobile)
On Thu, Feb 13, 2020, 08:21 Chris Heald notifications@github.com wrote:

Just noticed this on my phone (Pixel 3 XL, Chrome):
[image: Screenshot_20200213-091834]
https://user-images.githubusercontent.com/9830/74455187-30196480-4e42-11ea-9cd6-bc469789948d.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/zulip/zulip/issues/13900?email_source=notifications&email_token=AAU6NWVTC2255WISRG4W5HTRCVXQ3A5CNFSM4KUWCKHKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INKEK4A,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAU6NWQLSM5XYJCNESZEOWLRCVXQ3ANCNFSM4KUWCKHA
.

@zulipbot claim

i would like to work on this issue

Closing as a duplicate of https://github.com/zulip/zulip/issues/13642

authors: cheald prajwal2100 timabbott

repo: zulip/zulip


text:
requirements: Upgrade pathlib2 to latest version

Upgrading pathlib2 (requirements/ipython.txt.txt) directly to the latest version should break the code. So you may have to make some changes in the codebase or add some extra dependencies for upgrading.

@timabbott @hackerkid I think pathlib2 is already at its latest version == 2.2.1

@sinwar Yeah! I accidentally included it in the list. Thanks. :)

we can use https://requires.io/ for this purpose

authors: hackerkid sinwar


text:
compose: Update the New topic button to say New stream message when in PMs.

If a user is narrowed by is:private, pm-with, or group-pm-with, this PR changes the New topic button to say New stream message instead for added clarity.
Fixes #9072.
Testing Plan:
This PR adds two new tests to the narrow Casper tests and updates the Node tests.
GIFs or Screenshots:
When in a public stream (or "All messages" and other non-private narrows):

When in a PM:

This looks good.  Fixed a double-period in the commit message and merged, thanks @skunkmb!
One good follow-up thing to tackle: I believe these buttons don't work well in the mobile webapp views (they're in total too wide for some sizes).  We should either replace some of them with icons or something to make that look good.

authors: skunkmb timabbott


text:
user_list: Distinguish between full and new members.

Previously, in the admin user list,user roles were listed as just "member"
so it's difficult to distinguish between full members and new members.
Now, the user's roles were listed as  "Full Member" or "New Member"
in admin user list rather than just "Member".
Also in this commit changes were made to distinguish between
full member and new member in other places like
user profile , user info popover etc.

fixes #16040
Testing Plan:
Tested using automated node testes and manually tested in the browser
GIFs or Screenshots:

@timabbott ready for another review


text:
django3: Save language preference in a cookie rather than the session.

Support for saving it in the session is dropped in django3, the cookie
is the mechanism that needs to be used. The relevant i18n code doesn't
have access to the response objects and thus needs to delegate setting
the cookie to LocaleMiddleware.
Fixes the LocaleMiddleware point of #16030.
Tested manually (language is preserved like before, to portico pages and when logged out)

@mateuszmandera can you link to the Django docs around this change?  I want to understand the motivation around Django's changes here.
@andersk can you help review this?

@timabbott commit https://github.com/django/django/commit/a8e2a9bac6e548d6ab2e13af6171d2fdd3b8055b django ticket - https://code.djangoproject.com/ticket/15902 main docs - see the differenve between 3.0 and 2.2 in the scheme described in LocaleMiddleware tries to determine the user’s language preference by following this algorithm: https://docs.djangoproject.com/en/3.0/topics/i18n/translation/#how-django-discovers-language-preference (the step of trying to take the session from the language is gone in 3.0)

OK, makes sense.  Merged, thanks @mateuszmandera!

OK, makes sense.  Merged, thanks @mateuszmandera!

authors: mateuszmandera timabbott


text:
added documentation  for saml with authentik

Url to authentik documentation regarding zulip integration is waiting to be merged. It should be available soon at the url I provided. (https://goauthentik.io/integrations/services/zulip/)
I haven't tested signed saml request. I might be able to add that part later.

@xpufx I did an editing pass on this and pushed, can you take a look if it looks good?

@mateuszmandera Yes. It's good.

@xpufx No, let's leave this open, Tim can review and merge from here.

I will add missing config params that need to be changed to this pr.
the first name and the last name with the "first_name", "last_name" attribute names.
"attr_user_permanent_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"attr_first_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"attr_last_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"attr_username": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
#"attr_email": "email",
"attr_email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",

Merged, thanks @xpufx and @mateuszmandera!

great work already! helped me setting up the primary flow.
What would be a great addition: auto provisioning users howto. Currently, I can follow the auth flow, but invite links don't survive that and I have no clue how to connect the last piece of mapping the auth to users. Experimenting atm, but any hints would fit in there greatly. Cheers.

@erdnuesse can you make a thread in https://chat.zulip.org/#narrow/stream/31-production-help? That's a better place for debugging a config. And are you using multi-use invite links? Those can be used for signing up through the SAML authentication flow. The regular email invites can't.
If you want auto-provisioning, we have SCIM (https://zulip.readthedocs.io/en/latest/production/scim.html), but that sounds like an independent thing from your immediate issue.

It might also be simply that authentication is not working correctly because the server doesn't find what it expects in the SAMLResponse from the IdP due to some misconfiguration. So posting your recent /var/log/zulip/auth.log entries might be helpful.

@erdnuesse can you make a thread in https://chat.zulip.org/#narrow/stream/31-production-help?

I have found (one of the few) my issue(s) over the weekend, and some of it was DNS related; I have had the correct entries, but proxied vs non-proxied entries made a HUGE difference with (dyn-) DNS CNAMEs via cloudflare.

And are you using multi-use invite links?

Yes. For testing, single use would make me go crazy.

So posting your recent /var/log/zulip/auth.log entries might be helpful.

I'll look into that going forward, thank you.

When you say " I can follow the auth flow", do you mean that you are able to successfully fully login to your own account via SAML?

Sorry, for making it not clear enough.
My setup is:
DynDNS, split-DNS, ACME-DNS wildcard certs through *.extra.example.domain.
Cloudflare (proxied DNS for ACME, DNS only (unproxied) for clean DNS of services ->
traefik ->
Authentik, auth.extra.example.domain ->
zulip, zulip.extra.example.domain
This had multiple challenges in one with docker labels, traefik, and SSO, was pretty solid with DNS, but not DynDNS.
I Don't think I'll follow the path of new issue yet, as I am unsure where to put any of my findings. It seems that I was running in an edge case, which was not 100% related to the xmlsoap, but an addition to that, so sorry for the extra dust.
set erdnuesse=out;

authors: erdnuesse mateuszmandera timabbott xpufx


text:
help center: Document message actions.

I considered adding this to https://zulip.com/help/messaging-tips, but that page is about composing messages, not reading them. So I opted for a new page.

@laurynmm  What do you think?

Looks good to me! The logic for having it's own page makes sense. Do we want to link back to this page from any of those linked (or other) articles? Maybe the user cards article?

Looks good to me! The logic for having it's own page makes sense. Do we want to link back to this page from any of those linked (or other) articles? Maybe the user cards article?

Sure, added a link there.

@timabbott This PR has been reviewed by @laurynmm . Please take a look!

Merged, thanks @alya!

authors: alya laurynmm timabbott


text:
Indicate when DM reply is not allowed in interleaved views.

The PR implements a functioning where we disable the compose reply button for DMs in case the user is not allowed to send a DM. Previously, we do this for DM view only but this PR implements it for all the view including DM feed view, Combined feed view, Mentions view, Reactions view, Starred messages view and Search view,

 Video description for all the views

NOTE:
Desdemona is the only one who can authorize or initiate a DM. This is required for the differentiation.
Before column contains same video in all the tables, as all the view share the same behavior.

DM Feed

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/50e4eba8-155a-428b-b7e6-0e8e9cfad076

Combined Feed

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/d574fd25-83f7-4053-b42e-6729255bdb75

Mentions

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/21c2953c-1f5b-4423-be2e-03ed8b834d44

Reactions

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/86dd9bf5-6386-4d24-a5d4-385207533232

Starred Messages

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/5919f2b3-8e49-4841-9912-09d146a2bf3c

Search View

Before

After

https://github.com/user-attachments/assets/4f73ed15-9728-4435-bc0f-26f76ffd7b43

https://github.com/user-attachments/assets/f2a17ef0-85cb-422e-affb-d4c1c64c9f97

Fixes: #32597 .

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Hey @alya, could you please take a look at this one?

Hey @alya @amanagr , could you please take a look at this one?

Thanks! @amanagr tagging you for a review.

@amanagr , ready for next review.

@whilstsomebody maybe you should revisit this code later but close this PR now since I don't think contributor is ready to make an effective contribution right now in this code area.

authors: alya amanagr whilstsomebody


text:
Fix #3644: Fixed scrollbar overflow issue.

Fixes #3644.

Automated message from Dropbox CLA bot
@souravbadami, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

Automated message from Dropbox CLA bot
@souravbadami, thanks for signing the CLA!

Awesome, thanks for fixing this @souravbadami!  I merged this as
c511f576fbbbd773f7cd492108000d25102974b3, after cleaning up the commit message.
Check out the Zulip commit message guidelines for more details: https://zulip.readthedocs.io/en/latest/version-control.html#commit-messages
Thanks @souravbadami!

authors: smarx souravbadami timabbott


text:
Updated bug reports doc #7388

Please review this update on issue #7388 and clarify the modifications regarding Contribution.md
@rishig

Thanks for working on this @sroy8091!
I think this issue is going to take a lot more work; I've removed the "good first issue" label to reflect that.
I'd recommend starting with a coding issue, since that's an easier way to become familiar with the project.
Closing for now, thanks again for picking this up!


text:
Replace Text Fields with Dropdowns for Enum Parameters in API Sandbox UI

This PR introduces dropdowns and multi-selects in the Zudoku sandbox UI for parameters with constrained values, using the enum metadata from the OpenAPI spec. Instead of displaying text fields for these parameters, the updated UI now automatically populates dropdowns or multi-selects, streamlining the experience for users exploring the API.
This enhancement addresses issue ZUP-3767.
🎥 Watch the Demo

added a custom MultiSelect.tsx component ( as Radix react select does not support multi-select primitive in existing dropdown )

Awesome. Thanks for making quick work of this issue.

Thanks for your contribution @arian0zen! Looks great so far 🙏  Can you provide the changes you made to the OpenAPI schema so we can test it?
(and sorry for the merging all the time, the CI doesn't work properly with forks yet)

Thanks for your contribution @arian0zen! Looks great so far 🙏 Can you provide the changes you made to the OpenAPI schema so we can test it?
(and sorry for the merging all the time, the CI doesn't work properly with forks yet)

for testing you can :
a. set a few enum for type string in query param schema (line 131)
b. also you can set type array and set enum for its items (line 156-159)

openapi.json
🫱🏽🫲🏾 I am very much open to any suggestions, let me know if any changes are required!

@dan-lee these are very solid suggestions. Working on it🙌

Hi,
Thanks for putting this code together.
I just wanted to check back in on the status and when it might be mergable. We could really use this for some APIs we are working on.
Let me know if there is anything I can do to help.
Thanks!

authors: arian0zen dan-lee vengroff

repo: zuplo/zudoku


text:
Issue running git clone to download the framework.

How can we reproduce this bug?
foundation new --framework emails

What did you expect to happen?
Initialise the project
What happened instead?
Downloading the project template...There was an issue running git clone to download the framework Foundation for emails and template unspecified.
Make sure your computer's Git is configured properly and then try again.

Additional Information
node v6.9.2
nom v3.10.9
Try several suggested solutions both on Zurb forum and github issues. Doesn't seem to work at all. And the weird part is it work just last week.
Solutions tried

Install xcode select
Make sure command line is correct
Make sure permissions of folder is correct
Use standard git clone instead

I've tried removing all dependencies except for babel just for testing and it runs fine. Doesn't seem to have cloning issues.

Thanks for the report! This is the only report we've seen and it seems to work now. Maybe a temporary glitch? We'll close for now,  open a new issue if you can reproduce still.

Just had the same issue.
Turns out it was a high sierra issue and I had to reinstall xcode
xcode-select --install
It was related to this

Had this issue too on High Sierra. A git status told me to run sudo xcodebuild -license to agree to the new Xcode license. That did the trick.

I'm receiving this issue with Windows.
Node 8.11.3
NPM 6.2.0

Hi, I'm just posting this to help Windows users who will receive the error message.
You have to launch Command Prompt as an administrator. Use the "win + x" keyboard shortcut to open "Command Prompt (Admin)" from the menu.

authors: Wirelesstaco icreatesolutions katlis nickngqs rafibomb zmarmara

repo: zurb/foundation-emails


text:
Gem doesn't install due to its dependencies' versions

Using the bundler, I get the following error when installing Foundation using rails 3.2.0 and jquery-rails 2.0.0
Bundler could not find compatible versions for gem "jquery-rails":
    In Gemfile:
        zurb-foundation (>= 0) ruby depends on
            jquery-rails (~> 1.0) ruby
Bundler could not find compatible versions for gem "rails":
    In Gemfile:
        zurb-foundation (>= 0) ruby depends on
            rails (~> 3.1.0) ruby

The gemspec has this:
s.add_runtime_dependency "rails", "~> 3.1"
s.add_runtime_dependency "jquery-rails", "~> 1.0"

Shouldn't it be this?
s.add_runtime_dependency "rails", ">= 3.1"
s.add_runtime_dependency "jquery-rails", ">= 1.0"

Thanks for pointing this out!  In this case it looks like only the jquery-rails dependency needs to be updated since the rails dependency should not cause any issues up until rails 4.
Here's the commit that fixes this issue:
7ce904d1a1fe978beb942072b6922d2aeac0b234
I also pushed out an updated gem (version 2.1.5.1) that supports Rails 3.2.  Go ahead and run bundle install and you should be all set :)

authors: mhayes vitorussui

repo: zurb/foundation-rails


text:
Sass Error when changing breakpoints.

I get a compilation error when changing breakpoints using the example code.
$breakpoints: (
small: rem-calc(0),
medium: rem-calc(640),
large: rem-calc(1024),
xlarge: rem-calc(1200),
xxlarge: rem-calc(1440)
);
Libsass 3.4.1
--
bower_components/foundation-sites/scss/util/_unit.scss
Error: argument $number of unit($number) must be a number
   Backtrace:
   	bower_components/foundation-sites/scss/util/_unit.scss:49, in function `unit`
   	bower_components/foundation-sites/scss/util/_unit.scss:49, in function `-zf-bp-to-em`
   	bower_components/foundation-sites/scss/util/_breakpoint.scss:146, in function `-zf-bp-serialize`
   	bower_components/foundation-sites/scss/foundation.scss:52
    on line 49 of bower_components/foundation-sites/scss/util/_unit.scss

@if unit($value) == 'px' or unit($value) == '' {
------^

Hey @christianmagill - i got the same error when i tried to create my own breakpoints. All you have to do is to add one breakpoint more into your $breakpoints and don't add it to the $breakpoint-classes.
In your example just add something like xxxlarge:rem-calc(9999) and compile again. Or just remove the xxlarge from your $breakpoint-classes.
I will check the Code later, becuase I don't know if it is a bug or a feature. ;)

Try using pixel values instead and see if that fixes it. (They still get converted to em for the media queries.)
$breakpoints: (
  small: 0,
  medium: 640px,
  large: 1024px,
  xlarge: 1200px,
  xxlarge: 1440px,
);

Wondering if the pixel value helped in this situation?

Looking at this closer, I realize it's happening because rem-calc() is not defined in your Sass code yet, so the breakpoint converter is trying to convert the value rem-calc(640) instead of, say, 40rem. Verify that _settings.scss has @import 'util/util' at the top; this is what will load rem-calc() into your Sass.
If that doesn't work, if you revert to pixel values, the error will go away. Any value you put in there is converted to ems at the end.
Related: #7021

I don't have custom breakpoints declared and I'm running into this error.
{ [Error: node_modules/foundation-sites/scss/util/_unit.scss
Error: argument $number of unit($number) must be a number
   Backtrace:
   	node_modules/foundation-sites/scss/util/_unit.scss:57, in function `unit`
   	node_modules/foundation-sites/scss/util/_unit.scss:57, in function `-zf-bp-to-em`
   	node_modules/foundation-sites/scss/components/_visibility.scss:9, in mixin `show-for`
   	resources/assets/sass/_frame.scss:9
    on line 57 of node_modules/foundation-sites/scss/util/_unit.scss
>>   @if unit($value) == 'px' or unitless($value) {

_frame.scss:9 is @include show-for(medium up);. I'm not sure what's wrong. I have just upgraded from Foundation 5 but my other project (Foundation 6 fresh start) doesn't have this problem.

authors: christianmagill cietho gakimball tyteen4a03 zurbrandon

repo: zurb/foundation-sites


text:
Can grid be configured to use margins rather than padding for gutters

Feature request.

Can't see really how. box-sizing: border-box; or any other property wont include margins.

Can maybe use calc to adjust widths to remove margins from computed width

I don't think that could be reliably done.
This would also add the problem that you could not change margins on the fly - as you can right now with the paddings.
Actually i really can't see any real world use case for that right now. Is there actually?

We considered a margin/calc grid, but decided to keep our padding based grid. The math is way easier, and it also makes it easier to keep the width of the column and the size of its gutters separate. This is important because we plan to introduce a responsive gutter feature in 6.1.
The main downside is that you can't combine columns with other components for less markup, but we don't consider this a huge deal. On the contrary, keeping layout elements and other components separate makes more sense to us.

authors: Renkas alexmorris gakimball


text:
Foundation 5.3.3 - Reveal modal doesn't work with jquery 2.2.0

Hi there,
As mentioned here : http://foundation.zurb.com/forum/posts/37579-reveal-stopped-working
Reveal modal doesn't work anymore with the jquery update (2.2.0)
Firebug in firefox shows this message :
TypeError: g.on(...).trigger is not a function
it works if you downgrade to jquery 2.1.4

Confirmed. Same issue for me as well.

Merged #7859 which resolves this.

Why this issue is closed? The issue is not fixed!
There is no foundation 5.3.4 or something else, installing version 5.* via bower is still broken!

Agreed. Though, you can fix it by manually applying the patch as described in https://github.com/sjhewitt/foundation/commit/2e33179ad78b7d677610c50656f51f4b703034d5

@timaschew The fix is in the codebase, so we close the issue. We'll try to get a patch out for Foundation 5 soon.

This is NOT fixed in 5.5.3,
please release 5.5.4 legacy version that fixes that,
5.5.3 still needs downgrade of jQuery to 2.1.4

authors: gakimball mpasternak roundge timaschew wneessen


text:
[Magellan] links don't work in Firefox

Click a magellan link in the docs. They do not work in Firefox:
http://foundation.zurb.com/sites/docs/magellan.html

I have the exact same problem. The Magellan links do not work in Firefox. Any suggestions how to fix this?
Just try the example page: http://foundation.zurb.com/sites/docs/magellan.html
Setup
Sticky Navigation
JavaScript Reference

see #8056

Perfect, thanks!

authors: michaelvolz phifa


text:
Opera don't work all foundation 5 js?

Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.16
example http://foundation.zurb.com/docs/components/orbit.html
(I removed an item from the top bar)

In the inspector(f12), such an error js - Uncaught exception: Error: Syntax error, unrecognized expression: [data-"DejaVu Serif"-abide]

Thanks @xa0c - that solved a problem I was having with a site not running under Opera using Foundation 5

authors: gordonbanderson slava-viktorov

repo: zurb/foundation


text:
Angular 7 Compatibility?

I have been trying to ng update @angular/core  and getting these errors:
          ```
Package "angular-contents" has an incompatible peer dependency to "@angular/common" (requires "^5.0.0" (extended), would install "7.2.9").
              Package "angular-contents" has an incompatible peer dependency to "@angular/core" (requires "^5.0.0" (extended), would install "7.2.9").
              Package "angular-contents" has an incompatible peer dependency to "rxjs" (requires "^5.5.2", would install "6.4.0").

Hi Icborn4,
It shows as a warning to me in a brand new Angular project (Angular CLI 7.3.5):
 > npm i angular-contents
npm WARN angular-contents@2.1.0 requires a peer of @angular/common@^5.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN angular-contents@2.1.0 requires a peer of @angular/core@^5.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN angular-contents@2.1.0 requires a peer of rxjs@^5.5.2 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.7 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+ angular-contents@2.1.0
added 1 package from 1 contributor and audited 42610 packages in 10.853s
found 0 vulnerabilities

Either way I commited v7 to support Angular 7 specifically as well as the RxJS 6 (otherwise rxjs-compat was needed). Please, let me know if you encounter any more issues.

repo: zurfyx/angular-contents


text:
🛑 Avatar API Endpoint is down

In 1b12249, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) was down:

HTTP code: 429
Response time: 680 ms

Resolved: Avatar API Endpoint is back up in fb00ac3 after 9 minutes.

Resolved: Avatar API Endpoint is back up in e593d2a after 9 minutes.


text:
🛑 Account Settings API is down

In a436872, Account Settings API (https://accountsettings.roblox.com) was down:

HTTP code: 404
Response time: 194 ms

Resolved: Account Settings API is back up in 79211a7 after 23 minutes.


text:
Issues with Leviton Decora Smart Z-Wave 600W Dimmer (DZ6HD)

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
YES, BUT a Home Assistant developer has told me to come here
Is your problem within ZWaveJS2MQTT?
NO, my problem is NOT within ZWaveJS2MQTT
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
The Light state appears in home assistant, but it always shows as "off".
What do you observe?
When I try toggle the switch on (physically), the home assistant device still shows as "off".
When I try toggle the switch on (via home assistant), the state goes to "on" briefly, then back to "off". Meanwhile the actual light itself never illuminates.
What did you expect to happen?
I expect the home assistant device state to reflect the actual state of the light
I expect the light to illuminate when I turn the device on from the app.
Everything worked fine on the old ZWAVE addon.  The problem began after upgrading to ZWaveJS.
I have re-interviewed the device and rebooted the system.  No effect.
Steps to reproduce the behavior:

Try to toggle the light on from the app, or vice versa.

Device information
Manufacturer:  Leviton
Model name: Decora Smart Z-Wave 600W Dimmer (DZ6HD)
Node ID in your network: 14
Z-Wave Info
Device ID: 14
Device Status: Alive
Device Ready: Yes
Highest Security: None
Z-Wave Plus: Version 1
How are you using node-zwave-js?

[ ] zwavejs2mqtt Docker image (latest)
[ ] zwavejs2mqtt Docker image (dev)
[ ] zwavejs2mqtt Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[X] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
Driver Version: 8.11.9
Server Version: 1.15.0
Home ID: 4282397224
Devices ready: 11 / 12
Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Yes (please describe)
If yes, where did it work?
I upgraded from the ZWAVE addon to the ZWaveJS Addon.
Everything was working perfectly before.
I see others are having similar issues.  See below post:
https://community.home-assistant.io/t/leviton-dz6hd-polling-not-working-under-z-wave-js/356753/9
Attach Driver Logfile
zwave_js (2).log

This is what I can gather from your current log:
Node tells zwave-js to re-query its status:
2022-04-13T03:04:52.081Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[HailCC]
zwave-js does so:
2022-04-13T03:04:52.087Z DRIVER » [Node 014] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      41
                                  └─[MultilevelSwitchCCGet]
...
but the device doesn't know its current status:
2022-04-13T03:04:52.122Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: undefined

5 seconds later, the same happens multiple times and each time the node answers with a different value, which looks like it is dimming down (roughly 10% every half second):
2022-04-13T03:04:57.298Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 87
                                      target value:  87
                                      duration:      1s
2022-04-13T03:04:57.865Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 74
                                      target value:  74
                                      duration:      1s
2022-04-13T03:04:58.449Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 61
                                      target value:  61
                                      duration:      0s
2022-04-13T03:04:58.882Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 48
                                      target value:  48
                                      duration:      1s
... etc, down to 0:
2022-04-13T03:05:01.449Z DRIVER « [Node 014] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 0
                                      target value:  0
                                      duration:      0s

Without knowing what should have happened instead, this doesn't look wrong to me.
I will need some additional, commented logs where you describe what you're doing when, e.g. like this:
Turn on the light physically:
... logs here ...

Turn on the light via HA:
... logs here ...

I have no idea why, but its working now....

Well, sometime since April, maybe after one of the upgrades (not sure which one), but it seems to be broken again.
Similar issue as before.  Its seems that home assistant can communicate with the light, but it fails to process the light's response and update the state of the light.
Here is a breakdown of what I am seeing:
---------------STATUS------------------
Actual State of Light Itself: Off
light.in_wall_600w_dimmer: "Off"
---------------Action Performed--------
Press Light Button in home assistant.
Expected behaviour: Actual light turns on, and "light.in_wall_600w_dimmer" changes to "Off"
---------------Start of ZWAVE Log-----------
Subscribed to Z-Wave JS Log Messages…
2022-07-16T20:31:38.083Z SERIAL » 0x010b001312042601ffff252bd8                                        (13 bytes)
2022-07-16T20:31:38.085Z DRIVER » [Node 018] [REQ] [SendData]
│ transmit options: 0x25
│ callback id:      43
└─[MultilevelSwitchCCSet]
target value: 255
duration:     default
2022-07-16T20:31:38.087Z SERIAL « [ACK]                                                                   (0x06)
2022-07-16T20:31:38.091Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-07-16T20:31:38.092Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.092Z DRIVER « [RES] [SendData]
was sent: true
2022-07-16T20:31:38.106Z SERIAL « 0x010500132b00c2                                                     (7 bytes)
2022-07-16T20:31:38.107Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.108Z DRIVER « [REQ] [SendData]
callback id:     43
transmit status: OK
2022-07-16T20:31:38.117Z SERIAL « 0x01080004001202820160                                              (10 bytes)
2022-07-16T20:31:38.118Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.118Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
└─[HailCC]
2022-07-16T20:31:38.120Z CNTRLR   [Node 018] Hail received from node, refreshing actuator and sensor values...
2022-07-16T20:31:38.121Z CNTRLR » [Node 018] requesting current switch state...
2022-07-16T20:31:38.127Z SERIAL » 0x0109001312022602252cd8                                            (11 bytes)
2022-07-16T20:31:38.128Z DRIVER » [Node 018] [REQ] [SendData]
│ transmit options: 0x25
│ callback id:      44
└─[MultilevelSwitchCCGet]
2022-07-16T20:31:38.131Z SERIAL « [ACK]                                                                   (0x06)
2022-07-16T20:31:38.134Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-07-16T20:31:38.135Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.135Z DRIVER « [RES] [SendData]
was sent: true
2022-07-16T20:31:38.149Z SERIAL « 0x010500132c00c5                                                     (7 bytes)
2022-07-16T20:31:38.150Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.151Z DRIVER « [REQ] [SendData]
callback id:     44
transmit status: OK
2022-07-16T20:31:38.160Z SERIAL « 0x010b00040012052603646402c0                                        (13 bytes)
2022-07-16T20:31:38.161Z CNTRLR   [Node 018] [~] [Multilevel Switch] duration: {"value":1,"unit":"s [Endpoint 0]
econds"} => {"value":2,"unit":"seconds"}
2022-07-16T20:31:38.162Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:38.164Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: undefined
2022-07-16T20:31:43.118Z SERIAL » 0x0109001312022602252dd9                                            (11 bytes)
2022-07-16T20:31:43.119Z DRIVER » [Node 018] [REQ] [SendData]
│ transmit options: 0x25
│ callback id:      45
└─[MultilevelSwitchCCGet]
2022-07-16T20:31:43.121Z SERIAL « [ACK]                                                                   (0x06)
2022-07-16T20:31:43.125Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-07-16T20:31:43.126Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:43.127Z DRIVER « [RES] [SendData]
was sent: true
2022-07-16T20:31:43.140Z SERIAL « 0x010500132d00c4                                                     (7 bytes)
2022-07-16T20:31:43.141Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:43.144Z DRIVER « [REQ] [SendData]
callback id:     45
transmit status: OK
2022-07-16T20:31:43.151Z SERIAL « 0x010b00040012052603646400c2                                        (13 bytes)
2022-07-16T20:31:43.153Z CNTRLR   [Node 018] [~] [Multilevel Switch] duration: {"value":2,"unit":"s [Endpoint 0]
econds"} => {"value":0,"unit":"seconds"}
2022-07-16T20:31:43.153Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T20:31:43.154Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: undefined
---------------END OF ZWAVE Log-----------
---------------STATUS------------------
Actual State of Light Itself: On
light.in_wall_600w_dimmer: "Off"

Since home assistant always thinks the light is off, there is no way to turn it off using the home assistant dashboard.
However, if I call the service manually (), the light will turn off.
Subscribed to Z-Wave JS Log Messages… 2022-07-16T20:45:54.948Z SERIAL » 0x010b00131204260100ff252e22                                        (13 bytes) 2022-07-16T20:45:54.949Z DRIVER » [Node 018] [REQ] [SendData]                                   │ transmit options: 0x25                                   │ callback id:      46                                   └─[MultilevelSwitchCCSet]                                       target value: 0                                       duration:     default 2022-07-16T20:45:54.952Z SERIAL « [ACK]                                                                   (0x06) 2022-07-16T20:45:54.955Z SERIAL « 0x0104011301e8                                                       (6 bytes) 2022-07-16T20:45:54.957Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:54.958Z DRIVER « [RES] [SendData]                                     was sent: true 2022-07-16T20:45:54.971Z SERIAL « 0x010500132e00c7                                                     (7 bytes) 2022-07-16T20:45:54.972Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:54.973Z DRIVER « [REQ] [SendData]                                     callback id:     46                                     transmit status: OK 2022-07-16T20:45:54.978Z CNTRLR   [Node 018] [~] [Multilevel Switch] currentValue: 0 => 0           [Endpoint 0] 2022-07-16T20:45:54.981Z SERIAL « 0x01080004001202820160                                              (10 bytes) 2022-07-16T20:45:54.982Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:54.983Z DRIVER « [Node 018] [REQ] [ApplicationCommand]                                   └─[HailCC] 2022-07-16T20:45:54.985Z CNTRLR   [Node 018] Hail received from node, refreshing actuator and sensor values... 2022-07-16T20:45:54.986Z CNTRLR » [Node 018] requesting current switch state... 2022-07-16T20:45:54.994Z SERIAL » 0x0109001312022602252fdb                                            (11 bytes) 2022-07-16T20:45:54.995Z DRIVER » [Node 018] [REQ] [SendData]                                   │ transmit options: 0x25                                   │ callback id:      47                                   └─[MultilevelSwitchCCGet] 2022-07-16T20:45:54.997Z SERIAL « [ACK]                                                                   (0x06) 2022-07-16T20:45:55.000Z SERIAL « 0x0104011301e8                                                       (6 bytes) 2022-07-16T20:45:55.001Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:55.002Z DRIVER « [RES] [SendData]                                     was sent: true 2022-07-16T20:45:55.016Z SERIAL « 0x010500132f00c6                                                     (7 bytes) 2022-07-16T20:45:55.016Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:55.017Z DRIVER « [REQ] [SendData]                                     callback id:     47                                     transmit status: OK 2022-07-16T20:45:55.027Z SERIAL « 0x010b00040012052603000001c3                                        (13 bytes) 2022-07-16T20:45:55.028Z CNTRLR   [Node 018] [~] [Multilevel Switch] targetValue: 0 => 0            [Endpoint 0] 2022-07-16T20:45:55.029Z CNTRLR   [Node 018] [~] [Multilevel Switch] duration: {"value":0,"unit":"s [Endpoint 0]                                   econds"} => {"value":1,"unit":"seconds"} 2022-07-16T20:45:55.030Z CNTRLR   [Node 018] [~] [Multilevel Switch] currentValue: 0 => 0           [Endpoint 0] 2022-07-16T20:45:55.031Z CNTRLR   [Node 018] Scheduled poll canceled because expected value was received 2022-07-16T20:45:55.031Z SERIAL » [ACK]                                                                   (0x06) 2022-07-16T20:45:55.032Z DRIVER « [Node 018] [REQ] [ApplicationCommand]                                   └─[MultilevelSwitchCCReport]                                       current value: 0                                       target value:  0                                       duration:      1s

Not being an expert on this library, my eyes tend to gravitate to this:
After the light is turned off, the device sends this message with the current state of the light, and it is processed correctly.
2022-07-16T20:45:55.032Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 0
                                      target value:  0
                                      duration:      1s

But when the light is turned on, the device sends this message with the current state of the light, and it is "undefined", and processed incorrectly.
2022-07-16T20:31:43.154Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: undefined

Its also worth mentioning, the device is currently on the following firmware:
Firmware: 1.17
Device ID: 18
Device Status: Alive
Device Ready: Yes
Highest Security: None
Z-Wave Plus: Version 1

So I ran the firmware update to v1.22 from post 4101  and hopefully Im not speaking too soon, but it seems to have resolve the issue..
Here is the response after turning the light on:
Subscribed to Z-Wave JS Log Messages…
2022-07-16T21:18:02.049Z SERIAL » 0x010b001312042601ffff2544b7                                        (13 bytes)
2022-07-16T21:18:02.050Z DRIVER » [Node 018] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      68
                                  └─[MultilevelSwitchCCSet]
                                      target value: 255
                                      duration:     default
2022-07-16T21:18:02.052Z SERIAL « [ACK]                                                                   (0x06)
2022-07-16T21:18:02.056Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-07-16T21:18:02.057Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.058Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-07-16T21:18:02.071Z SERIAL « 0x010500134400ad                                                     (7 bytes)
2022-07-16T21:18:02.072Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.073Z DRIVER « [REQ] [SendData]
                                    callback id:     68
                                    transmit status: OK
2022-07-16T21:18:02.082Z SERIAL « 0x01080004001202820160                                              (10 bytes)
2022-07-16T21:18:02.083Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.084Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
                                  └─[HailCC]
2022-07-16T21:18:02.086Z CNTRLR   [Node 018] Hail received from node, refreshing actuator and sensor values...
2022-07-16T21:18:02.087Z CNTRLR » [Node 018] requesting current switch state...
2022-07-16T21:18:02.092Z SERIAL » 0x01090013120226022545b1                                            (11 bytes)
2022-07-16T21:18:02.093Z DRIVER » [Node 018] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      69
                                  └─[MultilevelSwitchCCGet]
2022-07-16T21:18:02.095Z SERIAL « [ACK]                                                                   (0x06)
2022-07-16T21:18:02.099Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-07-16T21:18:02.100Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.101Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-07-16T21:18:02.114Z SERIAL « 0x010500134500ac                                                     (7 bytes)
2022-07-16T21:18:02.115Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.116Z DRIVER « [REQ] [SendData]
                                    callback id:     69
                                    transmit status: OK
2022-07-16T21:18:02.125Z SERIAL « 0x010b00040012052603636302c0                                        (13 bytes)
2022-07-16T21:18:02.126Z CNTRLR   [Node 018] [~] [Multilevel Switch] targetValue: 255 => 99         [Endpoint 0]
2022-07-16T21:18:02.127Z CNTRLR   [Node 018] [~] [Multilevel Switch] duration: {"value":0,"unit":"s [Endpoint 0]
                                  econds"} => {"value":2,"unit":"seconds"}
2022-07-16T21:18:02.128Z CNTRLR   [Node 018] [~] [Multilevel Switch] currentValue: 0 => 99          [Endpoint 0]
2022-07-16T21:18:02.129Z CNTRLR   [Node 018] Scheduled poll canceled because expected value was received
2022-07-16T21:18:02.130Z SERIAL » [ACK]                                                                   (0x06)
2022-07-16T21:18:02.131Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 99
                                      target value:  99
                                      duration:      2s

The final message is no longer "undefined", but is actually showing values correctly now:
2022-07-16T21:18:02.131Z DRIVER « [Node 018] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 99
                                      target value:  99
                                      duration:      2s

repo: zwave-js/node-zwave-js


text:
General Level of Inconsistency in Z-Wave Command Functionality.

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within ZWaveJS2MQTT?
NO, my problem is NOT within ZWaveJS2MQTT
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
I'm noticing a general inconsistency with commands succeeding.  It's not any one device, or area of the house and it's quite random. I have an 84 Node Z-Wave Network, comprising of many powered devices in a 2 level 1200 sq ft house. So considering the size of my house and the number of powered z-wave devices (both 500 and 700 series) I should have a very strong mesh.

Latest FW for Controller.
Controller on a 3' Ext. Cable
Connected to a USB2 Powered Hub
Controller is almost centered in the middle of the house

I'm coming from HomeSeer (Z-NET) (~7 Years) so that is my comparative. While that setup's inclusion and exclusion system was extremely temperamental, the system seemed more stable. I would get the occasional failed command, but it was a once or twice a months thing, not an every other day thing.
Not sure if this is a normal failure rate?

Device information
The controller is a Zooz ZST 10 700
How are you using node-zwave-js?

[X] zwavejs2mqtt Docker image (latest)
[ ] zwavejs2mqtt Docker image (dev)
[ ] zwavejs2mqtt Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[ ] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
version:
Server Version: 1.17.0
zwavejs2mqtt: 6.11.0
zwave-js: 9.3.0
Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Don't know, this is a new device
If yes, where did it work?
No response
Attach Driver Logfile
zwavejs.zip

While I can't say exactly what is going on, I have a pretty good idea:

You have a few nodes with bad connectivity, which take extraordinarily long to reach. There are several instances in the log where the controller gives up after 10-20 seconds.
In some instances the controller tries really hard to reach a device that it was just sending to sleep. This is dumb and I've opened https://github.com/zwave-js/node-zwave-js/issues/4693 to improve on this.

You have lots of nodes that report a lot of power meter data. There are a few stretches where the controller is getting reports roughly every 20-50ms. With this amount of traffic on the network, sending commands will absolutely take longer and be less reliable.
While individual nodes seem to have a reporting frequency of several minutes, they send data in bursts and the mass of devices adds up. There are several factors that make this worse:
a) Some devices repeat themselves, e.g.:

2022-06-06T15:15:42.959Z SERIAL « 0x011700a80001620e320221640000000900780000000900c4e4                (25 bytes)
2022-06-06T15:15:42.960Z CNTRLR   [Node 098] [~] [Meter] value[65537]: 0.009 => 0.009               [Endpoint 0]
2022-06-06T15:15:42.961Z SERIAL » [ACK]                                                                   (0x06)
2022-06-06T15:15:42.962Z DRIVER « [Node 098] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -60 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       0.009
                                      time delta:  120 seconds
                                      prev. value: 0.009
2022-06-06T15:15:43.125Z SERIAL « 0x011700a80001620e320221640000000900780000000900c3e3                (25 bytes)
2022-06-06T15:15:43.126Z CNTRLR   [Node 098] [~] [Meter] value[65537]: 0.009 => 0.009               [Endpoint 0]
2022-06-06T15:15:43.126Z SERIAL » [ACK]                                                                   (0x06)
2022-06-06T15:15:43.127Z DRIVER « [Node 098] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -61 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       0.009
                                      time delta:  120 seconds
                                      prev. value: 0.009
2022-06-06T15:15:43.746Z SERIAL « 0x011700a80001620e320221640000000900780000000900c4e4                (25 bytes)
2022-06-06T15:15:43.747Z CNTRLR   [Node 098] [~] [Meter] value[65537]: 0.009 => 0.009               [Endpoint 0]
2022-06-06T15:15:43.748Z SERIAL » [ACK]                                                                   (0x06)
2022-06-06T15:15:43.748Z DRIVER « [Node 098] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -60 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       0.009
                                      time delta:  120 seconds
                                      prev. value: 0.009
2022-06-06T15:15:43.766Z SERIAL « 0x011700a80001620e320221640000000900780000000900c3e3                (25 bytes)
2022-06-06T15:15:43.766Z CNTRLR   [Node 098] [~] [Meter] value[65537]: 0.009 => 0.009               [Endpoint 0]
2022-06-06T15:15:43.767Z SERIAL » [ACK]                                                                   (0x06)
2022-06-06T15:15:43.767Z DRIVER « [Node 098] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -61 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       0.009
                                      time delta:  120 seconds
                                      prev. value: 0.009

This might be an indication of a lost acknowledgement, so the devices re-transmit to make sure the reports reach their target. This might also be a side effect of the high traffic, unfortunately making it worse.
b) Some devices report on a fixed schedule, even if the changes are insignificant (0.003 kWh):
2022-06-06T15:15:47.177Z DRIVER « [Node 101] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -91 dBm
                                  └─[MeterCCReport]
                                      type:        Electric
                                      scale:       kWh
                                      rate type:   Consumed
                                      value:       335.327
                                      time delta:  60 seconds
                                      prev. value: 335.324

If you can configure them to report only on significant changes, like 0.1 kWh or more, I strongly recommend to do that.
c) Some devices send the reports with Supervision encapsulation, requiring an answer to the report, even if the reports are useless because nothing changed (0W -> 0W):
2022-06-06T15:16:16.270Z DRIVER « [Node 118] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -62 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 57
                                    └─[SupervisionCCGet]
                                      │ session id:      35
                                      │ request updates: false
                                      └─[MeterCCReport]
                                          type:        Electric
                                          scale:       W
                                          rate type:   Consumed
                                          value:       0
                                          time delta:  1 seconds
                                          prev. value: 0

While this isn't a problem per se, this adds to the traffic and these devices tend to get nervous and repeat the supervised commands if they don't get a response within a short timeframe. Remember that there are stretches where the controller cannot reply for 10-20 seconds because it is busy.

Not sure if this is a normal failure rate?

The failures are mainly dropped (identically) repeated commands from nodes. What you should worry about are the almost 20k incoming reports.
Your first course of action should be configuring all devices to report way less. Where possible, prefer reporting on significant (!) changes over timed reports. If you need timed reports e.g. as a backup, reduce the frequency significantly (to sth. like once per hour).
Check which reports you really need. E.g. do you need to know the Voltage or is W/kWh enough? For multisensors, check if you need UV levels or if temperature/humidity is enough, etc.

Thank You for taking a look at this, I will go through, see if I can make the suggested changes and report back.

After turning off ALL automatic reporting and raising the threshold to a point of almost uselessness for all energy reporting devices the problem persists.
zwavejs_After_Adjustments.zip

Ok, it does look a bit better though. At least I am getting a clearer picture of whats going on.
The long delays when sending nodes to sleep are still a problem https://github.com/zwave-js/node-zwave-js/issues/4693.
Node 006 is spamming a lot, I count 38 reports during the time it took to send an S2 nonce to node 128, about a third are the same illuminance report
2022-06-12T10:24:25.960Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:25.961Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 0 => 1            [Endpoint 0]
2022-06-12T10:24:25.962Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:25.962Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -59 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:25.986Z SERIAL « 0x010f00a8000106063105030a000100c4a1                                (17 bytes)
2022-06-12T10:24:25.987Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:25.988Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:25.989Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:25.990Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -60 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:26.161Z SERIAL « 0x010f00a8000106063105030a000100c3a6                                (17 bytes)
2022-06-12T10:24:26.162Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:26.162Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:26.162Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:26.163Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -61 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:26.339Z SERIAL « 0x010f00a8000106063105030a000100d0b5                                (17 bytes)
2022-06-12T10:24:26.339Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:26.340Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:26.341Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:26.341Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -48 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:26.401Z SERIAL « 0x010f00a8000106063105030a000100c5a0                                (17 bytes)
2022-06-12T10:24:26.401Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:26.402Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:26.403Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:26.403Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -59 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:26.429Z SERIAL « 0x010f00a8000106063105030a000100cfaa                                (17 bytes)
2022-06-12T10:24:26.429Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:26.430Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:26.430Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:26.431Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -49 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
2022-06-12T10:24:26.436Z SERIAL « 0x010f00a8000106063105030a000100c5a0                                (17 bytes)
2022-06-12T10:24:26.436Z CNTRLR   [Node 006] [Multilevel Sensor] Illuminance: metadata updated      [Endpoint 0]
2022-06-12T10:24:26.437Z CNTRLR   [Node 006] [~] [Multilevel Sensor] Illuminance: 1 => 1            [Endpoint 0]
2022-06-12T10:24:26.437Z SERIAL » [ACK]                                                                   (0x06)
2022-06-12T10:24:26.438Z DRIVER « [Node 006] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -59 dBm
                                  └─[MultilevelSensorCCReport]
                                      type:  Illuminance
                                      scale: Lux
                                      value: 1
...etc...

This is most likely a connectivity issue of Node 6, but has a negative influence on all communication.
The remaining problematic nodes seem to be 128 (mainly this one), 118, 117. They still (partially) report with Supervision encapsulation, but this is not the main problem. The core of the issue is still a connectivity.
A typical faulty communication pattern seems to be this:
# incoming commands (node to controller) are marked with <
# outgoing commands (controller to node) are marked with >

< Report (supervised, with S2)
> Supervision confirmation (with S2) [1]

... a few seconds later ...

< Report (supervised, with S2)
> Supervision confirmation (with S2) [2]
< Node does not get the confirmation, re-requests it
  Z-Wave JS cannot decode because the message was sent and the shared S2 state has advanced to the next.
  Queues S2 nonce in an attempt to restore the shared state.
< Re-transmit a previous command, either the confirmed report or the command we cannot decode (zwave-js ignores)
> S2 nonce - The node should now re-transmit its command with Sender EI extension (2nd half of the nonce pair)

... nothing ...
... several seconds later ...

< S2 nonce (not sure what to do with that)

IMO the main problem is a combination of connectivity issues and the node not re-transmitting the command that was not understood. Here's an example of the bad link:
Transmit report of [1]
transmit status:        OK, took 830 ms
repeater node IDs:      3, 94, 13
routing attempts:       1
protocol & route speed: Z-Wave, 9.6 kbit/s
ACK RSSI:               -63 dBm
ACK RSSI on repeaters:  -87 dBm, N/A, N/A
ACK channel no.:        2
TX channel no.:         1

9.6 kbps is the lowest speed the protocol can drop to, so this already looks like a hail mary.
The transmit report of [2] comes after the node has already re-transmitted its message twice and this looks even worse (took almost 20s without success):
transmit status:        NoAck, took 18560 ms
routing attempts:       21
protocol & route speed: Z-Wave, 40 kbit/s
TX channel no.:         1
route failed here:      4 -> 128
TX power:               0 dBm
measured noise floor:   0 dBm

TL;DR: Your next steps should be using zwavejs2mqtt to do health checks on every node, working outwards from the controller. If there are delays or routing issues or low signal strength, check if you need to move the node or add repeaters in between to improve the link strength.

Sorry, some how I missed your reply. :-(
I just can't image that I need more repeaters for a 2 level 1200 sq ft house.  My house measures exactly 20' x 30' (Townhouse) and as you can see has a ton of powered nodes.  I truly would have no place to add them.
What is further puzzling is I didn't have these problems with HomeSeer and a Z-NET (Albeit on a 500 controller).
Something must be causing these signal issues, and perhaps the 700 controller has something to do with this.
I will work through the suggestions and report back.
Thank you again for taking a look at this, it really is MUCH appreciated.

Interesting, Node 006 is in a closed door closet (storage underneath step) which rarely gets opened. I shut off the automatic reporting on that node to see if it helps.
Another note: Node 128 makes perfect sense as it's inside a refrigerator, but can one low signal battery node bring down a network?
I can't seem to do any more with nodes 118, 117 to try and turn off report with Supervision encapsulation.
Nodes 006, 118 and 117 are 10' from the controller. (117 and 118 in the same room) and 006 in the closet next to controller (2 walls).

Node 128 makes perfect sense as it's inside a refrigerator, but can one low signal battery node bring down a network?

The stick can only send messages to one node at a time and there is a cycle of steps involved that needs to complete before the next message can be sent. If sending commands to one node can take 10-20 seconds and frequently fail altogether, this definitely has an influence on the entire network. Especially in situations like yours where:

the problematic node is included with S2 and the frequent errors cause the node and controller to go out of sync, requiring further communication to restore the shared state
the problematic node uses Supervision, requiring a response from the controller quickly, essentially making 1. much worse
other nodes use Supervision aswell and get impatient when they don't get the confirmation ASAP

So yes, one battery powered node with bad reception can bring down a network when it forces the controller to try and send to it frequently.

As for the other problematic nodes, definitely use the health check tool to try and figure out which nodes have a bad connection to the controller. The built-in algorithm for selecting routes doesn't seem to be particularly sophisticated, so a bad repeater connectivity may increase your problems aswell.

authors: AlCalzone RJ-Make


text:
fix(config): zooz: use templates wherever possible

As promised in #4496 I have reworked the entire Zooz config subfolder to make use of templates wherever possible.
I recognize that this is a massive changeset, so it will take some time to review. Any help appreciated. Many changes follow simple patterns so once you get the hang of it it should become straightforward. I found having a mental model of how the base_ templates work helps to speed up the review. E.g. base_enable_disable is 0 = Disable and 1 = Enable with a defaultValue of 0 (Disable).
It is also largely untested as I do not own most of the devices touched by these changes. Any guidance on how to best test this is appreciated. I'm willing to spend the effort on testing.
Happy to incorporate any feedback. E.g. you may want me to shuffle stuff around in the master_template.json or zooz_template.json. Especially the latter is getting a bit crowded by now that I was thinking maybe alphabetically sorting stuff would make sense. Zooz devices do have quite an overlap (and often not entirely consistent) it turns out.
Also Zooz documentation is of varying quality, especially the older the device is. I would have fixed it for them if their Knowledge base had been a Wiki.
I have cross referenced the documentation for each device many times to ensure that what I'm swapping out for a template is actually accurately represented by that template.
However, especially historic documentation is often unavailable and the change logs often merely allude to what parameters were changed and in which ways. So I've done my best to keep that information intact.
I have further removed description fields that were overly obvious.

Wow, this is great! I'll try to get to this soon, unless @blhoward2 beats me to it. Currently I'm caught up in my own massive undertaking over at https://github.com/zwave-js/node-zwave-js/pull/4614

Just a little side rant: Zooz published OTA firmware updates for the ZEN72/77 dimmers and because after version 1.01 there was 10.0 the new version is now - you guessed it - 2.0 🤦🏼♂

Thanks for the review!
This is ready for re-review. Feel free to resolve/reject the newest changes.

authors: AlCalzone kaechele


text:
Using Homeassistant to change the state of a z-wave wall Plug causes crash in zwavejsui

Checklist

[X]  I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.

Deploy method
Manually built (git clone - yarn build - yarn install
Z-Wave JS UI version
8.6.2
ZwaveJS version
10.3.1
Describe the bug
Using Homeassistant to change the state of a z-wave wall Plug causes crash in zwavejsui.
ERROR Z-WAVE-SERVER: Unexpected error label.toString(...).toLowerCase(...).replaceAll is not a function
TypeError: label.toString(...).toLowerCase(...).replaceAll is not a function
at zwaveLabel (/snapshot/zwave-js-ui/node_modules/@kvaster/zwavejs-prom/index.js:50:10)
at ZwavejsProm.onValueChanged (/snapshot/zwave-js-ui/node_modules/@kvaster/zwavejs-prom/index.js:161:34)
at ZwaveClient.emit (events.js:400:28)
at ZwaveClient.emit (domain.js:475:12)
at ZwaveClient.emitValueChanged (/snapshot/zwave-js-ui/server/lib/ZwaveClient.js:908:14)
at ZwaveClient._updateValue (/snapshot/zwave-js-ui/server/lib/ZwaveClient.js:3017:26)
at ZwaveClient._onNodeValueUpdated (/snapshot/zwave-js-ui/server/lib/ZwaveClient.js:2504:14)
at ZWaveNode.emit (events.js:412:35)
at ZWaveNode.emit (domain.js:475:12)
at ZWaveNode.translateValueEvent (/snapshot/zwave-js-ui/node_modules/zwave-js/src/lib/node/Node.ts:466:8)
To Reproduce
Setup as lxc container on a Proxmox host:
https://tteck.github.io/Proxmox/
https://github.com/tteck/Proxmox/raw/main/ct/zwave-js-ui-v5.sh
Using Homeassistant to change the state of a z-wave wall Plug.
Expected behavior
It shouldn't crash.
Additional context
No response

Thank you but most of my devices are zwave, so ha is not really usable with the plugin deactivated ;-)
PS, i switched new from the old zwavejs to zwavejsui implementation.
Also values are not updating anymore in ha, so automations don't work.
I hope that's all the same error.

No, i don't use Prometheus. only zwavejsui + homeassistant.
an example is a heater build from a switch and a multisensor:
climate:
  - platform: generic_thermostat
    name: Heizung Schlafzimmer
    unique_id: thermo.schlafzimmer
    heater: switch.switch_schlafzimmer
    target_sensor: sensor.sensor_schlafzimmer_air_temperature
    min_temp: 0
    max_temp: 30
    target_temp: 18
    hot_tolerance: 1
    cold_tolerance: 0.3
    initial_hvac_mode: "heat"
    precision: 0.1
    cold_tolerance: 1

But since the switch to zwaveuijs, the multisensor values are not updated anymore in ha.
in The ui of zwavejs the values are changing correct.

Disabled Prometheus, thank you.

@robertsLando You're still building the 64-bit linux/win packages with node 14. zany_face

@kpine I know that, it's because there were some problems with pkg, I need to try to set it to nodejs 18 to see if it still works

repo: zwave-js/zwave-js-ui


text:
[question] Zwave not working after config files update

Hello,
after I ran an update of the config files using the web control panel and then later rebooting the server it seems something is not working anymore.
It says: Driver: Failed to initialize the driver: Timeout while waiting for an ACK from the controller
The list of zwave equipments is empty.
When I checked the zwave configuration it shows the following details which are different of the menu I was seeing before.

The version is:
zwavejs2mqtt: 5.6.0.47c26b0
zwave-js: 8.3.1
home id: undefined
home hex: undefined
installed with snap
It looks like something went wrong with the configuration file, how can I fix it ?
Edit: I tried to look at the files using the "Store" feature, it keeps saying "Network Error" when clicking on a file, if I try to download a file using it for example settings.json the downloaded file is empty whereas when checking the files from CLI they contains data.
Thanks

I dunno what's the default folder for snap users. @jmgiaever ?

After a few reboots it now shows a different error:

2021-10-04 19:51:58.215 INFO ZWAVE: Zwavejs usage statistics ENABLED
2021-10-04 19:51:58.218 INFO ZWAVE: Controller status: Driver: Error Resource temporarily unavailable Cannot lock port
2021-10-04 19:51:58.218 WARN ZWAVE: Retry connection in 3 seconds...

Hi sorry my delayed reply. I've been away for the weekend and just returned. Have you tried to do a reboot?

I tried a few reboot of the ESXI VM without success also tried to reboot the whole host, no success at this time.

That is strange.
Can you try

Stop zwavejs2mqtt with sudo snap stop zwavejs2mqtt,
delete the .ext-config folder in /var/snap/current/ (can be different if your OS is not debian based), with rm -rf /var/snap/zwavejs2mqtt/current/.ext-config/
and do a full power cycle?

Before getting your last message, I solved it by unplugging the USB dongle for a couple of minutes.
It already happened once that the dongle became unresponsive, it is an Aeotec Z-Stick gen 5, is there anything I could do to avoid this problem in the future ?
Thanks

Ah, I swapped that plug out a year ago. I had so many issues with it. And I guess the built-in battery might be causing it to «keep alive» even when unplugged. But I'm happy that you solved it! :)

authors: jmgiaever robertsLando rvb89


text:
[建议] 二维码生成器 去掉生成按钮，改为监听输入框自动生成

完全没必要手工点【生成】按钮，多加几个事件，实现自动生成即可。

那你这样每敲一个字母都生成一次，浏览器可能都要炸了 :joy:

有道理，不过可以加上离开焦点时生成😁

也是一个解决方案耶 👍
只不过离开焦点应该都是为了点生成了吧 😂

那你这样每敲一个字母都生成一次，浏览器可能都要炸了 😂

You got it!

那你这样每敲一个字母都生成一次，浏览器可能都要炸了 😂

You got it!

加上离开焦点事件吧，点空白处直接生成，不用非得点按钮

authors: SmallOyster tianyiw2013 zxlie

repo: zxlie/FeHelper


text:
召唤石选择界面 UI位置不对

在选择友召界面时，如果选择比较上方的石头，选择队伍界面会正确出现在顶部，选择比较下面的石头时，选择队伍界面会如图所示出现在比较下方，主角LB界面也出现过同样情况，确认时候的UI会直接出现在底部

更新一下版本试试？


text:
Convert doctests to django unittests and add travis-ci support

Hi! To make a project more comfortable for contributing I've made the following changes:

Add support of Travis-ci and Coveralls
Convert all doctests to django unitests
Add new test runner
Drop unneeded django-testproject using
Fix a few bugs and python3 issues of incompatibility.

NOTE
To complete adding support of travis-ci and coveralls @zyga should authorize and enable repo in settings.
Please, review PR. Thanks!

Wow, fantastic effort! It is my pleasure to merge this!

Thank you very much!
BTW, would you mind closing fixed issues -- #16,  #30, #32, #33?

Done, thanks again @atugushev :)

Awesome, thanks! :+1:

authors: Gagaro atugushev zyga

repo: zyga/django-pagination


text:
super mario brothers original

super mario brothers original

歌曲信息

专辑：《super mario brothers original》
作词：未知
作曲：未知
编曲：未知
歌手：近藤浩治

谱
33 3 135(5)
1(53 67#66) (5)3564 5312(7)
1(53 67#66) (5)3564 5312(7)
5#44 2#2 3(56) 1(6)12
5#44 2#2 3[111]
5#44 2#2 3(56) 1(6)12 #221
5#44 2#2 3(56) 1(6)12
5#44 2#2 3[111]
5#44 2#2 3(56) 1(6)12 #221

111 12 31(65) 111 123
111 12 31(65) 333 135(5)
1(53 67#66) (5)3564 5312(7)
1(53 67#66) (5)3564 5312(7)

31(5#5 6)44(6) (7)66 654 31(65)
31(5#5 6)44(6) (7)44 432 1(5) ((5)31)
31(5#5 6)44(6) (7)66 654 31(65)
31(5#5 6)44(6) (7)44 432 1(5) ((5)31)

111 12 31(65) 111 123
111 12 31(65) 333 135(5)
31(5#5 6)44(6) (7)66 654 31(65)
31(5#5 6)44(6) (7)44 432 1(5) ((5)31)

1(53 67#66) (5)3564 5312(7)
1(53 67#66) (5)3564 5312(7)

5#44 2#2 3(56) 1(6)12
5#44 2#2 3[111]
5#44 2#2 3(56) 1(6)12 #221
5#44 2#2 3(56) 1(6)12
5#44 2#2 3[111]
5#44 2#2 3(56) 1(6)12 #221

111 12 31(65) 111 123
111 12 31(65) 333 135(5)
1(53 67#66) (5)3564 5312(7)
1(53 67#66) (5)3564 5312(7)
31(5#5 6)44(6) (7)66 654 31(65)
31(5#5 6)44(6) (7)44 432 1(5) ((5)31)
31(5#5 6)44(6) (7)66 654 31(65) 渐弱

记谱：超级玛丽(マリオ)

超级玛丽(マリオ)


text:
内存泄露

1.存在严重的内存泄露。ChartView 滑动时存在线性的内存增长。
ZYWCandleChartView.m
CGMutablePathRef redRef = CGPathCreateMutable();
CGMutablePathRef greenRef = CGPathCreateMutable();
这个需要手动释放。
// add
CGPathRelease(redRef);
CGPathRelease(greenRef);
2.浏览了代码，思路是在scrollview上放置ChartView。
这样做是有问题的，数据不断增长，ChartView的宽度可以无限变大。
3.可以只绘制当前界面需要显示的K线，减少不必要的开销。

@249109296
根据 屏幕大小、单个蜡烛的宽度， 计算当前屏幕能容纳的条数，再动态绘制。
我写了一个简单的demo 没有这些问题
https://github.com/stonelay/OpenGLDemo/tree/master/OpenGLDemo/OpenGLDemo/Class/KLineDemo

请问如何做到只绘制当前界面需要显示的k线?

可以做一个类似轮播似的, 三个界面轮训绘制k线数据。这样的话 不会无限创建出view了

请问如何做到只绘制当前界面需要显示的k线?
我写了一个demo,借鉴了Cocoa-Charts的实现方式
https://github.com/stonelay/ZLKLineDemo
CoreAnimation实现，不会影响主线程，目前看起来效率不错。


text:
CI/CD

Сборка провалилась, нужно будет запушить новые изменения и прогнать заново.


text:
add solidly v3 helper

Codecov Report
Attention: 46 lines in your changes are missing coverage. Please review.

Files
Coverage Δ

contracts/SolidlyV3Helper.sol
0.00% <0.00%> (ø)

:loudspeaker: Thoughts on this report? Let us know!.

authors: codecov-commenter ilyapt


text:
chore: upgrades dependancies

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


text:
Finetune model

Had to write some custom code for an early stopping condition since the sentence transformers lib doesn't seem to support training till we see no improvement in test loss


text:
Merge master into main

Looks good 👍🏼


text:
docs: Fill contents into README.md

수고하셨습니다!!!

authors: ddoyun hwanky


text:
API: download dataset

Resolved by #56

repo: ABI-CTT-Group/digital-twin-platform


text:
Addnewlogo

Page with new logo loaded.
Did not see where pipelinelogo is used. Only saw pipelinelogo2 being used.
logged in and got Hi message
had to delete code/dev-data.db in my folder due to error

authors: LSMachuca Sarahnsweet