text:
format in JSON Schema

It is not quite clear whether JSON Schema allows format for other types than string. At least several JSON Schema validatiors don't fully support it. We use format extensively in our process parameter and return value schemas to allow better validation. Unfortunately, this is not so easy any longer if validators don't support it so we may need to think about alternatives. To clarify, I asked in the JSON Schema Slack:

Is format meant to be only for strings or could I also use format for integer or an arrays? For example:
{
  type: 'integer',
  format: 'epsg-code'
}

I'm asking, because in https://json-schema.org/understanding-json-schema/reference/string.html it is just defined for strings. In contrast, https://json-schema.org/latest/json-schema-validation.html#format doesn't mention this restriction and explicitly mentions for individual types that they apply for strings ('These attributes apply to string instances.'), which would not be required if format is only defined for strings anyway. Also, OpenAPI (see https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#data-types - I know their schema is not JSON Schema) allows formats for integers and numbers. I personally have a use case where I need format for arrays, objects and integers, but ajv only implements format for strings and numbers for example.

It seems the JSON Schema guys want to work on format in draft 09 anyway, so we should get that sorted beforehand and vote to allow format for other data types than strings if required.

More information from the Gitter Slack:
@handrews wrote:

Technically you could do all sorts of things with format, and yes, technically implementations that only support format with strings have a bug. (bearbeitet)
BUT, format is problematic because it was an early, somewhat half-assed attempt at extensibility for complex semantic concepts.  It's not consistently supported (or, as you noted, always correctly supported), and there is a tremendous amount of debate over what is really required for proper support.
Now we have the concept of annotation keywords, which can signify arbitrarily complex concepts to applications without dealing with format's problems.

It seems they think about deprecating format in favor of custom keywords.
So we may replace format in the next version with a custom keyword.

repo: Open-EO/openeo-processes


text:
mpi_cmd

MPI execution now controlled by MPI_PREP_CMD and MPI_CMD.
MPI_PREP_CMD: command necessary to prepare for running MPI (loading of environment variables or somesuch)
MPI_CMD : command to execute MPI

per discussion on other pull request and in standup meeting, merging into ml_structure_s13

source: gharchive/pull-request

repo: Open-Network-Insight/oni-ml

license_type: permissive

license_source: bigquery


text:
Explore HuggingFace PRO spaces (https://huggingface.co/spaces) or Inference Endpoints (https://huggingface.co/inference-endpoints).

Feature request
We want to know what are the trade-offs of the two hosted solutions offered by HuggingFace.
Motivation
We want to run models in HuggingFace when we can't run them offline due to computational constraints.

https://huggingface.co/blog/inference-update Explores both inference endpoints and spaces.
The two factors that I think are the most crucial are: Hardware Availability and Pricing. Here's the inference endpoint pricing:

(from https://huggingface.co/pricing#endpoints)
and here is pricing for spaces:

(from https://huggingface.co/docs/hub/spaces-gpus)

To be honest, HF Spaces are more web demo oriented, the way I see us using Spaces for a model that we computationally cannot afford to run locally is: opening up a new tab with the model link, prompting with whatever UI options we have for it and generating the output (in this case, Action Events) and then grabbing those from the tab followed by a tab close.

https://huggingface.co/blog/inference-endpoints-llm

source: gharchive/issue

authors: FFFiend abrichr

repo: OpenAdaptAI/OpenAdapt

license: MIT

license_source: github-api


text:
[Docs] Add Jupyter Notebook illustrating entityTraits

Add a notebook illustrating the usage of entityTraits, as specified in OpenAssetIO/OpenAssetIO#31
WIP notes
The notebook will not (yet) run.  It makes assumptions of future work that has not yet happened. In particular, see

OpenAssetIO/OpenAssetIO#31
OpenAssetIO/OpenAssetIO#1209
Unsubmitted feature requests to BAL

The idea in the first instance is to provoke discussion and provide a reference as the feature is further refined.
An ideal outcome is that this document continues to be iterated as the feature(s) is developed, incorporating changes in design as well as new corner cases that need defining.
Eventually this should lead to an executable specification of the feature, which also serves as example documentation.

Btw - a nice thing here is by the time the work is done and this is passing we should have some usefull specifcations from #22

Update on this rather long-running notebook.
It's updated to use the changes in https://github.com/OpenAssetIO/OpenAssetIO-Manager-BAL/issues/90
CI still targets PyPI releases for dependencies however, so either we need to retarget it, or wait til the next release, before this PR can be merged.

authors: feltech foundrytom

repo: OpenAssetIO/OpenAssetIO-MediaCreation


text:
Update country codes

This adds the United States Minor Outlying Islands, and updates the names of Eswatini and Việt Nam.
It should be merged in conjunction with the matching server update.
https://github.com/OpenBazaar/openbazaar-go/pull/1175

The server code related to this PR has been merged.

The server code related to this PR has been merged.

I'll start working through the PR reviews later today.

authors: jjeffryes rmisio

repo: OpenBazaar/openbazaar-desktop


text:
De-duplicate active currencies.

Minor tweak to de-duplicate active currencies in the crypto currency selector.
This doesn't remove the need for the server to fix the bug that allows duplicate copies of currencies to be saved, but I think it's beneficial if the control makes sure it's own data is correct regardless of where it comes from.

👍


text:
Purchase Call gets stuck in Pending

One user on Slack is reporting behavior that appears to be caused by the purchase call getting stuck in a pending state without timing out or failing.
They click the pay button in the client, and get a spinner that never ends.

I've managed to replicate this issue, but I haven't figured out what triggers it.
Once in this state, any purchase calls to the same vendor also go into a pending state indefinitely.
I didn't have a 2nd selling node handy to test if new purchase calls become stuck for all vendors, or just the original stuck vendor. I'll check that if this happens again.
I did notice that once the node is in this state, I was not able to use control-C to close the node. The terminal appeared to not accept any input at all.

I have reproduced this in the master branch of 2.3.1

I saw some errors in that node that seem unrelated, but might be relevant.
One:
15:21:50.990 [ERROR] [retriever/handleMessage] Error processing message /ipfs/QmdB8xfuz9fCZMb2JPX7rgNCSXEtCTgJYsevzfXr2QAMV9. Type ORDER_COMPLETION: exhausted maximum attempts for request
and a bunch of:
16:28:36.098 [INFO] [pool/executeRequest] error executing wallet client request: error broadcasting tx: status not ok: 400 Bad Request
and two:
16:28:36.098 [ERROR] [WalletService/func1] broadcasting unconfirmed utxo: exhausted maximum attempts for request

I haven't reproduced this since almost a year ago, I think it's safe to close it.

repo: OpenBazaar/openbazaar-go

license: mit


text:
服务端镜像启动报错

在离线环境下运行服务端镜像，报错如下：
init logger, level: INFO, format: json
all_in_one-csghub_server-1  | {"time":"2024-04-27T06:49:16.456842199Z","level":"INFO","msg":"FIFOScheduler run started"}
all_in_one-csghub_server-1  | {"time":"2024-04-27T06:49:16.457924209Z","level":"ERROR","msg":"refresh status all failed","error":"Get "http://localhost:8082/status-all\": dial tcp [::1]:8082: connect: connection refused"}
all_in_one-csghub_server-1  | Error: failed to init router: error creating dataset viewer handler:failed to create parquet reader,cause:failed to setup s3 for duckdb, cause:IO Error: Failed to download extension "httpfs" at URL "http://extensions.duckdb.org/v0.9.2/linux_amd64/httpfs.duckdb_extension.gz"

能否解决上述问题后，更新下镜像，谢谢！

@mdllly 感谢使用，我们今天会跟进处理，尽快修复

all_in_one-csghub_server-1 | Error: failed to init router: error creating dataset viewer handler:failed to create parquet reader,cause:failed to setup s3 for duckdb, cause:IO Error: Failed to download extension "httpfs" at URL "http://extensions.duckdb.org/v0.9.2/linux_amd64/httpfs.duckdb_extension.gz"

这个错误是因为在离线环境下无法下载 duckdb 的一个扩展包，可以通过手动下载到宿主机，然后 mount 到容器中。请参考以下步骤：

宿主机创建文件夹： ~/.duckdb/extensions
点击错误信息中的链接（http://extensions.duckdb.org/v0.9.2/linux_amd64/httpfs.duckdb_extension.gz）下载扩展包，并解压到步骤1创建的文件夹中
修改docker-compose 配置文件中 csghub_server 的配置，将步骤1中的文件夹 mount 到容器中。修改的配置文件如下：

  csghub_server:
    image: opencsg/csghub-server:latest
    ...
    networks:
      - opencsg
    volumes:
      - ~/.duckdb/extensions:/root/.duckdb/extensions

fixed in v0.7

authors: Rader hiveer mdllly

repo: OpenCSGs/csghub-server


text:
chore: add take action for contributors to self-assign

This workflow should enable contributors to self-assign issues.
This pull request closes #6

okay, I'm lost. Why is prettier failing for this @JoshuaKGoldberg

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@43da7d5). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 5d051ea differs from pull request most recent head 885e98a. Consider uploading reports for the commit 885e98a to get more accurate results

@@          Coverage Diff           @@
##             main      #7   +/-   ##
======================================
  Coverage        ?   0.00%
======================================
  Files           ?       3
  Lines           ?     144
  Branches        ?       0
======================================
  Hits            ?       0
  Misses          ?     144
  Partials        ?       0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: blackgirlbytes codecov-commenter


text:
Cyphal/UDP transfer <-> address/port conversion

For #98 the specification in pycyphal does not specify conversion between transfer to address and port.
It would be great to integrate this documentation with this part in the first text part of the specification.
Maybe something like this:

Transfer kind
Address
Port

Message
Multicast base + subnet id + subject id
SUBJECT_PORT = 16383

Service
Target address
SERVICE_BASE_PORT = 16384; TARGET_PORT =  SERVICE_BASE_PORT + service_id * 2 + responce_not_request

Superseded by https://github.com/OpenCyphal/specification/issues/98

authors: ASMfreaK pavel-kirienko

repo: OpenCyphal/specification


text:
Trouble merging branches

We have a few troubles:

Protege seems to change the order of attributes in the omn file when working on the ontology.
Thus it marks changes when comparing versions where there are none.

It seems that Protege sorts classes alphabetically. If persons work on different branches and in different places, then changes with similar alphabetic beginnings end up in the same place when trying to merge with git  - thus seemingly creating conflicts (where there should actually be none)

We have created the branch feature/geo  off feature/resources and have trouble merging back into feature/resources due to the above mentioned issues. We are not sure how to resolve this.  Do you have an advice on how to deal with this?
Suggestion: Potentially add this to the agenda for the next ontology meeting.
@l-emele
@wingechr

The first issue should be solved in newer versions of Protégé (resp. of the OWL API, which is used by Protégé). See https://github.com/owlcs/owlapi/issues/273

The second problem is caused by the fact that for program code, if at one place there are two insertions, then their order matters. So git better generates a conflict, and you are forced to choose one particular order. See also https://softwareengineering.stackexchange.com/questions/194788/why-doesnt-git-merge-adjacent-lines-without-conflict
For ontologies, generally the order of insertions does not matter, so git's behaviour is unwanted here.

In the case of such conflicts, git merge --strategy-option=patience seems to produce better results (the conflict is easier to resolve).

Thanks. Unfortunately this did not work. We will now, as discussed in Magedburg, separate the geo branch into a separate ontology, and may thus have an unexpected workaround.

yes, this is not just a workaround, but conceptually the better strategy. Still, I would be interested what exxactly did not work with conflict resolution, because such conflicts can happen again.

authors: han-f tillmo

repo: OpenEnergyPlatform/ontology


text:
How to learn OpenFast ,if there are some advice for beginners

I am a beginner ,a postgraduate student in china,now I have learnt how to run OpenFast and get some results ,but I have trouble in learning it in advance,could you please give me some advice or guide ,because I need to learn deeper to do some academic research,thank you very much

Dear @fpxno1,
Similar questions have been asked and answered here: https://github.com/OpenFAST/openfast/issues/626 and our on forum: https://forums.nrel.gov/.
The presentations, sample models, and video recordings from our most recent OpenFAST workshop are available here: https://drive.google.com/drive/folders/1Z6hqCxGP57nZTgyTIMi6AkYd83rJuZmh?usp=sharing.
Best regards,

Dear @jjonkman ,
There is a problem opening the above ”https://drive.google.com/drive/folders/1Z6hqCxGP57nZTgyTIMi6AkYd83rJuZmh?usp=sharing“.Do you know why？Thank you very much.

Dear @largeluck,
The link above works for me.  Here is a second try; does this one work?:
https://drive.google.com/drive/folders/1Z6hqCxGP57nZTgyTIMi6AkYd83rJuZmh?usp=share_link
Best regards,

Dear @jjonkman,
Well,this is OK.Thank you very much.
Best regards,

authors: fpxno1 jjonkman largeluck

repo: OpenFAST/openfast


text:
Update to latest HDF5

The wget command does not work for version 1.8.19.
The version on the web is 1.8.20.
The script has been updated to do this.

Hey Ganesh,
Yes, I agree.
I have always had the same issue with hdf5, there is no clean way of
getting the source code (like git clone).
If that link you are suggesting works, then go ahead and change it to that.
The scripts in share are very good, and they should be the go-to for
compilation.
On Tue, May 1, 2018 at 12:58 PM, Ganesh Vijayakumar <
notifications@github.com> wrote:

@gantech commented on this pull request.
Thanks for doing this @tonyinme https://github.com/tonyinme. This
change seems harmless and ok. However, we have to make a decision on if we
continue to change files in share/ at all. I think they're meant to be an
example and not really production/compile ready. If we do want to to keep
changing files in share/, I suggest we move to a more stable version 1.10.2
as here https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.10/
hdf5-1.10.2/src/. Does that seem ok?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenFAST/openfast/pull/111#pullrequestreview-116665157,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKixAdxg2u8vT09nnNUItEPAe2MW1BWwks5tuLBogaJpZM4TuKQ_
.

@gantech It would be good if you set the same version for OpenFAST as Trilinos/Nalu so that there are no conflicts when we attempt to link to Nalu.

@gantech is this pull request good to go or do you need to address @sayerhs suggestion above?

As soon as @tonyinme accepts this pull request https://github.com/tonyinme/openfast/pull/1, this will be ready to go.

Looks good!

authors: gantech rafmudaf sayerhs tonyinme


text:
给作者个建议

有很多地方用到的都是比例。按比例更能适配屏幕的大小。
在加几个方法和扩展方法，
.widthPercent(0.2)  0.2.wp   20%的屏幕宽度大小。
.heightPercent(0.2)  0.2.hp 20%的屏幕高度大小
.appWidthPercent(0.2)  0.2.awp app所占设备宽度的20%大小
.appHeightPercent(0.2)  0.2.ahp app所占设备高度（除去状态栏和底部虚拟导航栏 所占高度）20%的高度大小

了解

辛苦了。老哥。


text:
trim front option to allow more than 30bp

Hello! I am very thankful for this tool as I use it all the time!
However, I am running into some issues as I need to cut the first 50 bp of my reads but the program does not allow me
ERROR: trim_front1 (--trim_front1) should be 0 ~ 30, suggest 0 ~ 4
I see that this issue was brought up before here but the issue was closed despite having some demand for this implementation.
Is there a way to allow this in the program? Or what alternatives do you recommend?

I agree this should be changed to a warning instead of an error, there are plenty of cases where you may want to trim more than the ranges allowed here.

repo: OpenGene/fastp


text:
meson: add an option to disable building the unit tests

The option is enabled by default, but allows to disable building the unit tests
in case of linker issues on broken build systems.
Fixes #259.

lgtm!

repo: OpenHMD/OpenHMD


text:
Add min-height to collapsed v2 timeslider

This is pretty minor but I think also easy to fix.
currently when I collapse the timeslider there's a slight different in height between the collapse button and the date readout:

Adding a min-height:40px; seems to fix this issue:

Tested in FF, Chrome, and Safari

Done.

authors: danrademacher gregallensworth

repo: OpenHistoricalMap/issues


text:
ustring::string() returns empty string when using the new C++11 ABI

I noticed that when using GCC 5.1 with the new libstdc++ ABI enabled, oslc foo.osl (from OpenShadingLanguage) would choose .oso as the output filename instead of foo.oso.
oslc uses shader_decl()->shadername().string() + ".oso" as the default output filename if one is not provided via the -o option. Further testing indicates that OpenImageIO's ustring::string() method is broken and returns an empty string on the new C++11 ABI.
Bellow is an example test program and GDB backtrace that show the issue.
#include <OpenImageIO/ustring.h>

int main(void) {
    auto a = OpenImageIO::v1_4::ustring("123");
    std::string b = "123";

    std::cout << "a = " << a.string() << std::endl << "b = " << b << std::endl;
    return 0;
}

Breakpoint 1, main () at test.cc:8
8		std::cout << "a = " << a.string() << std::endl << "b = " << b << std::endl;

(gdb) p a
$1 = {static npos = 18446744073709551615, m_chars = 0x61d870 "123",
  static empty_std_string = <optimized out>}

(gdb) p a.string
$2 = {const std::__cxx11::string &(const OpenImageIO::v1_4::ustring * const)} 0x4010e6 <OpenImageIO::v1_4::ustring::string[abi:cxx11]() const>

(gdb) p &a.string()
$3 = (const std::__cxx11::string *) 0x61d838

(gdb) p a.string()
$4 = ""

(gdb) c
Continuing.
a =
b = 123

Can you test this workaround? https://github.com/OpenImageIO/oiio/pull/1176

Seems to work, thanks!
Please note that most (if not all) Linux distros configure GCC 5.1 to use the old ABI (using --with-default-libstdcxx-abi=c++98). The issue won't manifest in such configurations, though building OIIO and its dependencies with -D_GLIBCXX_USE_CXX11_ABI=1 should be enough to reproduce it.

authors: foutrelis lgritz

repo: OpenImageIO/oiio


text:
support single channel 8-bit bmp

Description
Support single channel, 8-bit grayscale bmp files.
Tests
I did not add a test.
Checklist:

[x] I have read the contribution guidelines.
[x] If this is more extensive than a small change to existing code, I
have previously submitted a Contributor License Agreement
(individual, and if there is any way my
employers might think my programming belongs to them, then also
corporate).

This is a small bug fix that should not need a CLA, updated documentation or tests. The code, except for the color_table_is_all_gray method, is copy/paste from an email exchange with Lary Gritz or from Larry's own lg-bmp branch where he cleaned up memory allocations when reading bmp files.

[ ] I have updated the documentation, if applicable.
[ ] I have ensured that the change is tested somewhere in the testsuite
(adding new test cases if necessary).
[ ] My code follows the prevailing code style of this project.

This seems to be on top of my PR for reducing allocations (#2934). Can I assume that means that you have tried it and are happy with it?
If that's the case, then I'd like to suggest that I go ahead and merge that PR, and then you should rebase on top of it (and re-push this branch with --force). That will update this PR and make it so the diffs are only your new part, will make it a bit easier to review than having my changes mixed in.

Yes, my PR is on top of (#2934). And, yes, I have tried it and am happy with the reduced allocation changes you made for bmp files. (I tested using ImageInput and see that no allocations are made when reading into an external buffer - thank you!)

OK, I merged the other PR. I suggest that you rebased this one on top of it.

Is there anything else you want me to do to this PR?

No, it looks great. I will merge after the CI tests on the latest push are finished.

Thanks!
I have another PR I can submit if you are interested. It is for to_OpenCV line 313 and following.  Instead of cv::Mat mat(roi.height(), roi.width(), dstFormat); with dst = std::move(mat); at the end, you can eliminate mat altogether and use dst.create(roi.height(), roi.width(), dstFormat); since the opencv Mat create method does the same thing as the constructor if the arguments are for something different than the instance is already for. But, it does no change if the instance already matches the spec. Eliminating this object avoids another unnecessary memory allocation for me where I am using opencv for the processing but oiio for image reading (and soon to be writing). Of course I will submit a PR if this sounds reasonable (or even if you are midly interested). But I will not bother if this is not a change that you think you would want.

I do not think my last commit had anything to do with the test failure:
99% tests passed, 1 tests failed out of 139

Total Test time (real) = 490.77 sec

The following tests FAILED:
	100 - openexr-chroma (Failed)

No, I'm seeing a few intermittent failures on Windows, and it's definitely not related to this PR.

Are you building out of master, or do you need this backported to the release branch?

I have been using a release build, but I can use master or a tagged commit on master, unless you think there is a reason not to. I do not have any thing forcing me to a release branch other than the desire for stability. (My platform is currently windows VS2019, but I also use Ubuntu 18, and any commit you point me to will be fine.) So I am fine with leading edge but not bleeding edge. Master works okay for me, but I would to a release-2.3.x-dev tag when it is available.

This is the kind of change to existing behavior that I prefer not to backport to existing releases unless somebody makes the specific request for a good reason. So if you are not desperate to have this in 2.2.x, then I recommend you work from master now (and whatever commit you want to lock down on) and then can peg to the next dev tag I make.
My studio does production work from master (or close to it), so I'm not worried about stability or robustness. The most important difference between master and release branches is simply that release branches promise not to break backward ABI and API compatibility.

Okay, sounds great! I would prefer to stay closer to the leading than the trailing edge. And backward compatibility, and particularly, ABI compatibility is not important to me.
By the way, did you get anyone to take you up on your request to take on the vcpkg build of oiio? I do not think I can take that on myself, but I might be able to lend a hand. There are still many things about vcpkg I do not understand, but I am able to use it. In fact for these two PRs, I used my vcpkg build (on windows) of the oiio dependencies (but without the vcpkg build of openimageio itself). And then I was able to build the oiio master branch using the vcpkg toolchain file. (I had to first remove the find modules for ffmpeg, libraw, and opencv from src/cmake/modules as is done in the openimageio port. ) There are still a couple of kinks with the build of the debug configuration, so it would be much better if I could build the head of the master branch (or something much newer than what is on vcpkg), but the current patch files in the vcpkg port make that difficult (at least for me).


text:
Big List - Reporting Resources

Capturing screenshots of websites.
There are a variety of libraries for doing this. We should add this under remote recon or reporting.
https://github.com/ChrisTruncer/EyeWitness
https://www.trustwave.com/Resources/SpiderLabs-Blog/Using-Nmap-to-Screenshot-Web-Services/
https://github.com/SpiderLabs/Nmap-Tools/blob/master/NSE/http-screenshot.nse
https://github.com/segmentio/nightmare
Python mechanize
https://github.com/breenmachine/httpscreenshot

When handling a large-scale intrusion, incident responders often struggle with obtaining and organizing the intelligence related to the actions taken by the intruder and the targeted organization. Examining all aspects of the event and communicating with internal and external constituents is quite a challenge in such strenuous circumstances.
The following template for a Threat Intelligence and Incident Response Report aims to ease this burden. It provides a framework for capturing the key details and documenting them in a comprehensive, well-structured manner.

https://zeltser.com/cyber-threat-intel-and-ir-report-template/

Enjoyed this talk about the importance of writing when doing threat intelligence. I believe there are lessons to be transferred to risk assessment components of the reporting for SAFETAG. Pen-To-Paper and The Finished Report: The Key To Generating Threat Intelligence - CTI SUMMIT 2017

authors: elationfoundation seamustuohy

repo: OpenInternet/SAFETAG


text:
Dev mode to support arquillian

Arquillian requires to start its server but dev mode start one. Suggest to have <allowConnectingToRunningServer>true</allowConnectingToRunningServer> property. It allows Arquillian to connect the running server started by dev mode.
See Option 2 in https://github.com/OpenLiberty/guide-arquillian-managed/pull/68:

Add the <allowConnectingToRunningServer>true</allowConnectingToRunningServer> property to the pom.xml
On a command prompt, run mvn liberty:dev
On another command prompt, run mvn liberty:configure-arquillian
On the dev mode prompt, press enter to run the tests

or https://github.com/OpenLiberty/guide-arquillian-managed/issues/69

Currently, if using arquillian, users have to run as following:
mvn clean package
mvn liberty:create liberty:install-feature liberty:deploy
mvn liberty:configure-arquillian
mvn failsafe:integration-test

Currently, if using dev mode by following the instruction in the description, tests will fail as
[ERROR] it.io.openliberty.guides.inventory.InventoryArquillianIT  Time elapsed: 0 s  <<< ERROR!
java.lang.RuntimeException: Arquillian initialization has already been attempted, but failed. See previous exceptions for cause
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Connecting to an already running server is not allowed

Suggest to have a better design/experience so that no need to do mvn liberty:configure-arquillian

Summary of current situation based on the above: Currently dev mode does not work with Arquillian tests - Arquillian cannot start its own server while dev mode is running, and it cannot connect to dev mode's Liberty server (perhaps unless some manual steps are performed).
This issue is to support a scenario where user is developing Open Liberty and/or Arquillian test cases, and wants to run their Arquillian tests on dev mode's Liberty server.

Document that dev mode does not currently work with Arquillian tests.

Document that dev mode does not currently work with Arquillian tests.

authors: ericglau gkwan-ibm


text:
Detailing the local example to match its jupyter sibling

Where?
Where are you looking to add documentation? Which file? Which feature?
https://github.com/OpenMined/PipelineDP/blob/main/examples/restaraunt_visits/run_without_frameworks.py
Who?
Who is your audience for this documentation issue?
Newcomers wanting to run the example locally.
What?
Describe what you would like this documentation to accomplish.
Add details to the local example file to match its jupyter sibling (https://github.com/OpenMined/PipelineDP/blob/main/examples/restaurant_visits.ipynb) allowing newcomers to read/run either example with similar content - but strictly for a local example dataset.
Additional Context
Add any other context about the problem here.

I (github.com/ will be working on this issue.

Thanks @parikhanupk! Go ahead!

authors: dvadym parikhanupk

repo: OpenMined/PipelineDP


text:
Add documentation about env variables (ONE_XMLRPC, etc...) to the cli guide

Author Name: Jaime Melis (@jmelis)
Original Redmine Issue: 2730, https://dev.opennebula.org/issues/2730
Original Date: 2014-02-14

ONE_XMLRPC and other env variables are explained in http://docs.opennebula.org/4.4/administration/users_and_groups/manage_users.html, however it would be interesting to add them to the CLI guide as well (or add a link) http://docs.opennebula.org/4.4/user/references/cli.html
Also, it would be interesting to recommend adding them to .bash_profile (as it gets called once) and not to .bashrc (as it gets called once per bash instance)

http://docs.opennebula.org/5.8/operation/users_groups_management/manage_users.html?highlight=one_auth#shell-environment

authors: OpenNebulaProject rsmontero

repo: OpenNebula/one


text:
DRS-like functionality for vCenter clusters

Author Name: Ruben S. Montero (@rsmontero)
Original Redmine Issue: 3308, https://dev.opennebula.org/issues/3308
Original Date: 2014-11-06

OpenNebula can issue re-allocation plans to optimize cluster usage and migrate VMs accordingly. Also OpenNebula can offer suggestions for initial VM placement

Original Redmine Comment
Author Name: Miguel Ángel Álvarez Cabrerizo (Miguel Ángel Álvarez Cabrerizo)
Original Date: 2017-04-13T09:27:11Z

Similar proposal in #4789

Original Redmine Comment
Author Name: OpenNebula Systems Support Team (OpenNebula Systems Support Team)
Original Date: 2017-06-08T10:44:57Z

This needs a dynamic scheduler.


text:
Fix Pokemon Storage Count to include eggs

This will make the pokemon storage reflect the true number of pokemon.

👍

👍
Will close old PR.

authors: ajurna tehp wchill

repo: OpenPoGo/OpenPoGoBot


text:
Support of different PDLs in IPP Everywhere and Generic IPP Everywhere drivers

Is there a way how can IPP printer specify, which PDL should be generated when I add it to CUPS? For example if I have a printer, that only supports PCL XL PDL, is there a way how to make the IPP driver (either IPP Everywhere driver, or the Generic IPP Everywhere driver) to generate print job with such PDL? I thought that if the printer returns some specific attributes in the Get-Printer-Attributes operation, it can be achieved, but I tried all three document-format-default, document-format-preferred, document-format-supported attributes and I played with different values (e.g. application/vnd.hp-PCLXL for PCL XL), and with no success. The IPP Everywhere driver generates PDF, the Generic IPP Everywhere driver generates some PWGRaster. Any suggestions?
Btw I know it is possible to specify different drivers and it should be probably possible to add IPP Printer and as a driver choose some PCL XL driver, but I want to avoid this, use the generic driver and let the printer specify this.
CUPS version: 2.3.3

IPP Everywhere model is designed for document formats which are present in driverless printing - image/pwg-raster, image/urf, application/pdf - not for any existing PDL.

authors: stavikpetr zdohnal

repo: OpenPrinting/cups


text:
Increasing to 10 second sleep because of Travis

In Travis these tests are occasionally failing https://travis-ci.org/OpenRefine/OpenRefine/jobs/3896227 which is probably due to the CPU demand spike placed with createProcess.

@wetneb However not sure what to do about the occasional Wikibaseapi issues.

@thadguidry I will remove some of them so that it reduces these bugs a bit

authors: thadguidry wetneb

repo: OpenRefine/OpenRefine


text:
code to update the book + update

write code to download latest versions of the main.md files, update m…odule 1 and 5, rebuild the book.
also deleted figures from this repo.

videos now showing up, needed to update the bookdown, rmarkdown packages and now it is working !

repo: OpenScienceMOOC/book


text:
Assess OpenJDK variants.

adopt openjdk, open j9 vs. hotspot

compat with Solr 7.x

Generally Hotspot is required -- given sizable heap requirements at launch, ~ 1GB.
OpenJ9 JVM (from AdoptOpenJDK) fails to run Xponents libraries in Eclipse debugger.
Hotspot works fine.

.... stay away from OpenJ9 for now.

repo: OpenSextant/Xponents


text:
Display vote weight totals

If vote weight is activated vote weight totals should be calculated and displayed next to "total heads", e. g. admins need to see vote weights present when filtering by "is present".

I consider this an important issue.

meh. The projectors PollData entries are strings instead of numbers.

authors: jwinzer tsiegleauq

repo: OpenSlides/OpenSlides


text:
Fix motion 'default change reco mode' setting

Closes #3105

That's because, until a change recommendation is actually made, the "changed version" is the same as the original version. Also changing the code so that changed mode, if it is set as default, is triggered under all circumstances, even those that don't include a recommendation, would, with the current way that mode is implemented, cause the view to break a bit (i.e. no possibility to create change recommendations and no way to switch modes).
Similar reasoning for the final version. That one needs at least one of "change recommendations" or "accepted amendments" to be present for the motion. Else it doesn't work.
If the requirements for the views are there, they will be displayed in the correct format however.
Does this really need fixing (and if yes: to what extend?), or is this alright as is?

ping @MSoeb

authors: jsangmeister luisa-beerboom

repo: OpenSlides/openslides-client


text:
No auto generation when adding new events or services on component type

When I add events or services to a component type Trait, there is no auto generation in the component implementation.
Use case to reproduce on a new Pharo 11 - 64 bit image :
1 - Load Molecule on Pharo image
Metacello new
   baseline: 'Molecule';
   repository: 'github://OpenSmock/Molecule:main/src';
   load.

2 - Create a MolGeneratorBugTest type
Trait named: #MolGeneratorBugTest
	uses: MolComponentType
	instanceVariableNames: ''
	package: 'Molecule-Examples-test'

3 - Create an event MolGeneratorBugTestEvents
Trait named: #MolGeneratorBugTestEvents
	uses: MolComponentEvents
	instanceVariableNames: ''
	package: 'Molecule-Examples-test'

4- Create an implementation MolGeneratorBugTestImpl for MolGeneratorBugTest
MolAbstractComponentImpl subclass: #MolGeneratorBugTestImpl
	uses: MolGeneratorBugTest
	instanceVariableNames: ''
	classVariableNames: ''
	package: 'Molecule-Examples-test'

5 - Add the event MolGeneratorBugTestEvents into MolGeneratorBugTest  type
producedComponentEvents
	<componentContract>
	^ {MolGeneratorBugTestEvents}

-> The event notifier is not generated into the implementation

Thanks @LouisePla!

@LouisePla, this is a bug.
Normaly you should have the notifier corresponding to your produced events interface, even if your events interface is empty.
Do you have some methods in your Events interface in this example (I suppose no) ?

authors: LouisePla labordep

repo: OpenSmock/Molecule


text:
Add more architectural documentation?

I think you guys have done an excellent job with this software, and the instructions right now are fairly easy to follow if you're the developer type and already know quite a bit about Solo. However for a new user just getting into Solo (or just getting into Open Solo, anyway) I think it would be helpful to have some explanation about what exactly Open Solo is going to change when they install it. Something similar to the "architectural overview" diagram on the old 3DR dev guide, except maybe a little higher level. Just to introduce the users to the concepts of all the different individual devices involved in this, and make sure they understand what they're getting into.
I've got a copy of MS Visio I could use to make some nice looking diagrams, and I understand the general idea of how the Solo's parts fit together, but some more information on the network communication would be very helpful. What ports does the controller use to talk to the Solo? What ports does the app use? If someone can explain that a little for me I will try and put together a couple diagrams this week.
Thanks again for your hard work on this! This is a big step for Solo owners.

If you draw-up some diagrams that will be helpful to the community, we're happy to accept them as  PR to the repo.

repo: OpenSolo/documentation


text:
zlib not found configure failed for lal

I everyone, Im new here and  I have a issue I need help with the following.
I am following the instructions here https://gnome.pages.gitlab.rlp.net/gdas/installation.html
to get gdas going for a summer research project I (and team) are doing for gravitational wave analysis at California State University.
I made it to this step: ./configure --enable-swig-python --prefix=/where/to/install
After I execute this is the error I get. I searched online, tried many solutions but non worked for me.
configure: error: could not find the zlib library
configure: error: ./configure failed for lal
Running: MacBook Air 12.3 Monterey M1
Python 3.10
installed zlib via brew, pip, and nothing.
if I  run whereis zlib I get nothing.
pls help, how to fix this?

----------------------
Running config.status.
----------------------
This file was extended by LALSuite config.status 7.5.1, which was
generated by GNU Autoconf 2.71.  Invocation command line was
CONFIG_FILES    =
CONFIG_HEADERS  =
CONFIG_LINKS    =
CONFIG_COMMANDS =
$ ./config.status
on Marlons-MacBook-Air.local
config.status:780: creating Makefile
config.status:780: creating wheel/Makefile
config.status:780: creating wheel/setup.py
configure:5446: === configuring in lal (/opt/lalsuite/lal)
configure:5507: running /bin/sh ./configure --disable-option-checking '--prefix=/opt'  '--enable-swig-python' --cache-file=/dev/null --srcdir=.
configure:5512: error: ./configure failed for lal

checking for pthread.h... yes
checking for pkg-config... no
checking for ZLIB... no
checking for library containing compress... no
configure: error: could not find the zlib library
configure: error: ./configure failed for lal

repo: OpenSourceHelpCommunity/Questions


text:
filterToFourWayMode shares statics with core and DDI, probably doesn't play well with combination modes

Noticed this while looking at https://github.com/OpenStickCommunity/GP2040-CE/issues/532 --- since filterToFourWayMode declares static variables for tracking axis states, we get a history of sorts for free, but the method is used by both core gamepad and DDI, which means there's probably something squirrely if you...

have DDI enabled,
have 4-way enabled (core gamepad, or DDI, or both?), and
activate both core dpad and DDI directionals in a way that would trigger 4-way mode logic

This is probably an edge case, but I think it would do something weird. The fix might just be, sadly, to duplicate the static declarations for core gamepad and DDI.

Note that if #533 merges --- and at this point I think it should, this issue can be closed.

Closing as per above, but also noting that #559 may be a different form of this problem.


text:
Revert app theme to white

As per feedback after the second trial, we are reverting the theme of our app to be white. This has updated the general background to white as well as applying darker tinges to some other colours for better visibility on the graph. There were also some inconsistencies of different colours being used for the same logical components and these were removed. Lastly, unused colours were also disposed of.
Close #59

The relevant issue will be resolved with adjusting the stroke width. Closing this for now, barring some other refactorings in a separate change

repo: OpenVentPk/ventilator-app


text:
Trying to build on Fedora 34

Found quite a few missing deps (perl and others).
However Build fails with:
`/home/brianr/Data/brianr/OVOS/OpenVoiceOS/buildroot/output/build/qt5base-5.15.2/src/corelib/text/qbytearraymatcher.h:103:38: error: ‘numeric_limits’ is not a member of ‘std’
103 |         const auto uchar_max = (std::numeric_limits::max)();
|                                      ^~~~~~~~~~~~~~
/home/brianr/Data/brianr/OVOS/OpenVoiceOS/buildroot/output/build/qt5base-5.15.2/src/corelib/text/qbytearraymatcher.h:103:58: error: expected primary-expression before ‘>’ token
103 |         const auto uchar_max = (std::numeric_limits::max)();
|                                                          ^
/home/brianr/Data/brianr/OVOS/OpenVoiceOS/buildroot/output/build/qt5base-5.15.2/src/corelib/text/qbytearraymatcher.h:103:61: error: ‘::max’ has not been declared; did you mean ‘std::max’?
103 |         const auto uchar_max = (std::numeric_limits::max)();
|                                                             ^~~
|                                                             std::max
Any ideas?

Okidokie, am at the same error as we speak.
Had to go for a fresh QT compile run because of the virtual keyboard work. Threw away all QT5 related build packages and re-compiling them and it errored out with that exact error.
So in short; Looking into it.

Should be fixed now.

Thanks, I am now on Fedora 35, and will have a go when I get time.

Hang on for a little bit longer. Going through a fresh compile showed some other quircks here and there that i also addressing when they pop up.

repo: OpenVoiceOS/OpenVoiceOS


text:
[bug] not detecting all of lock manual state changes

Version
Build/Run method

[X] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 3.0.0 (same on 2.2.0)
Openzwave Version: 1.6
Describe the bug
Locks in Z2M are not reporting certain manual state changes.

Keypad lock on BE469 Schlage is being sent and IS detected by Z2M
Manual internal lock turn (lock or unlock) is not being picked up by Z2M

Locks include BE469, Kwikset Z-wave lock
To Reproduce
Steps to reproduce the behavior:

Turn internal lock mechanism
notice no change to state

Expected behavior
The internal lock mechanism used to be picked up by Z2M
Additional context
Debug logs do NOT show internal mechanism state change

@Fishwaldo any reason why the lock would be sending some commands to Z2M but not all.
(I guess a better way to ask would be, what could be the reason Z2M / OZW would be missing some commands from the lock?)

turning the BE469 internal lock handle I can see the following in Z2M:
zwave/front_lock/113/1/260 = 0
zwave/front_lock/113/1/6 = "Manual Lock Operation"
zwave/front_lock/113/1/6 = "Clear"

but notice there is no update to the actual lock state.... weird?

I suggest you to enable logs on zwave settings and post the OZW_logs.txt

On 3 Mar 2020, at 20:37, jaburges notifications@github.com wrote:

turning the BE469 internal lock handle I can see the following in Z2M:
zwave/front_lock/113/1/260 = 0
zwave/front_lock/113/1/6 = "Manual Lock Operation"
zwave/front_lock/113/1/6 = "Clear"
but notice there is no update to the actual lock state.... weird?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

is there anything specific to look for, the log.txt is pretty big.
Also what is "Current Record Number" with locks - i'm seeing Invalid Record for Log Record

ok update, i had created a new manual value for the lock under Gateway in the Settings tab.
There are 2 values in 1.6 so created both
Locked 98-1-0
Locked (Advanced)98-1-1
polling time = 1
verify value = true
and now (apart from my MQTT being flooded with values, the lock is reporting the correct state).
So Z2M is able to pull the value from the lock, but it was my understanding that the lock would send the command to the controller (and used to) - not sure what has changed?

Did you check the Association groups on the lock? Controller should be in there.

@jaburges Check if the lock lifeline group has controller :)

I noticed what I think is the same issue after a recent update to Z2M. The manual states are no longer reporting as LOCKED, but when I send a LOCK command, it will report back as LOCKED.
There was an old issue with Schlage locks not correctly updating the status (can't find a reference to it right now), wondering if some change may have regressed?

There was an old issue with Schlage BE469 locks not correctly updating the status because they only update the alarm control, not the lock status

joys of non-compliant devices!
you could try adding something this to the AlarmCC Block in a config file (adjust values to suit):
    <TriggerRefreshValue Genre="user" Index="0" Instance="1">
      <RefreshClassValue CommandClass="51" Index="255" Instance="1" RequestFlags="0"/>
    </TriggerRefreshValue>

see here for a example.

its already there with some commentary on the previous edit:
    <!-- These Door Locks don't send a DoorLockReport when the
		Lock Status is Changed, but instead send a Alarm Message -
		So we trigger a Refresh of the DoorLock Command Class when
		we recieve a Alarm Message Instead -->
    <TriggerRefreshValue Genre="user" Index="0" Instance="1">
      <RefreshClassValue CommandClass="98" Index="1" Instance="1" RequestFlags="0"/>
    </TriggerRefreshValue>

Ahhh. Ok. It’s possible that broke with some core changes we made recently. I’ll confirm it’s still working.

cool, thank you :) appreciate the help

Please change
<TriggerRefreshValue Genre="user" Index="0" Instance="1">

to
<TriggerRefreshValue Genre="user" Index="6" Instance="1">

and either RefreshNodeInfo or delete ozwcache

deleted ozwcache (and amended BE469.xml)
but weirdly ended up with 2 entries that dont match the change:
				<TriggerRefreshValue Genre="user" Instance="1" Index="0">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>
				<TriggerRefreshValue Genre="user" Instance="1" Index="0">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>

assuming i should amend this to the above, and only need one of them?

i'm seeing this a little more wide spread to more than just the BE469 lock. Also the Kwikset lock, and garage door opener. All are securely added.
Interesting in the logs I see a similar issue as you commented on here:
https://github.com/OpenZWave/open-zwave/issues/1949#issuecomment-539053738
2020-03-04 21:16:54.467 Info, Node084, Encrypted Flag is 1
2020-03-04 21:16:54.467 Info, Node084, Sending (Poll) message (Callback ID=0xd2, Expected Reply=0x04) - DoorLockCmd_Get (Node=84): 0x01, 0x09, 0x00, 0x13, 0x54, 0x02, 0x62, 0x02, 0x25, 0xd2, 0x24
2020-03-04 21:16:54.476 Detail, Node084,   Received: 0x01, 0x04, 0x01, 0x13, 0x00, 0xe9
2020-03-04 21:16:54.476 Error, Node084, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2020-03-04 21:16:54.571 Detail, Node084,   Received: 0x01, 0x10, 0x00, 0x04, 0x10, 0x54, 0x0a, 0x98, 0x80, 0x33, 0xce, 0x97, 0x82, 0xaf, 0xa4, 0x91, 0x88, 0x47
2020-03-04 21:16:54.571 Info, Node084, Received SecurityCmd_NonceReport from node 84

is from my Kwikset lock - so the issue isnt isolated to the BE469.

as per the issue #1949 above where i dont believe there was a known solution. I excluded and re-added 2 of the locks - they now seems to have solved the issue.
To me observing this as a non-zwave person, it seems the issue is contained to the securely added devices, and seemed like they lost trust with the controller (assuming there is some kind of handshake using the network key). FYI The network key hasnt changed

So what ?  I have also another user expecting some strange crash :(

note - i dont see the BE469 manual lock turn appear in the OZW logs - just the kwikset.
I do now see the following for the Kwikset in MQTT - but NOT for Locked or Locked (Advanced)
turned to lock:
zwave/back_lock/113/1/512 = 21
zwave/back_lock/113/1/513 = 1
turned to unlock:
zwave/back_lock/113/1/512 = 22
zwave/back_lock/113/1/513 = 1
The Kwikset lock is reporting as Touchpad Electronic Deadbolt (Kwikset (Spectrum Brands))
seems like Alarm is not being passed to DoorLock?

@Fishwaldo

in more testing (as locks are important and I need my house to be secure)
If I use the Z2M console it will lock and unlock the lock using the toggle Locked (NodeID-98-1-0)
this produces:
zwave/back_lock/113/1/512
locked = 24
unlocked = 25
However i'm unable to send a command via MQTT to the lock
zwave/back_lock/98/1/0 or zwave/back_lock/98/1/0/set
HA therefore is not able to send lock/unlock - but is listening to the 98/1/0 topic so is reporting the state correctly when sent from Z2M.
Any more thoughts on this?

Try to check in your broker if on startup z2m subscribes to the topic you wrote with “/set” at the end, than also when you publish something you should see a log on z2m if he receives the message
Daniel

On 7 Mar 2020, at 05:52, jaburges notifications@github.com wrote:

in more testing (as locks are important and I need my house to be secure)
If I use the Z2M console it will lock and unlock the lock using the toggle Locked (NodeID-98-1-0)
this produces:
zwave/back_lock/113/1/512
locked = 24
unlocked = 25
However i'm unable to send a command via MQTT to the lock
zwave/back_lock/98/1/0 or zwave/back_lock/98/1/0/set
HA therefore is not able to send lock/unlock - but is listening to the 98/1/0 topic so is reporting the state correctly when sent from Z2M.
Any more thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Yes ‘/set’ does now work. It was a different issue preventing the node from receiving messages. Z2M still has the old node ID number so I was sending to 93/98/1/0 and the node was still thinking it was 36/98/1/0.
I’ve fixed that, but the initial bug still remains.
No locks are responding to manual turns.
My current work around is to listen to
113/5/12 (in node-red via an MQTT in node, but could also be done via an automation) and send the 98/1/0/set ‘true’ or ‘false’ appropriately to ensure the state is updated.
This temporary workaround however does NOT work for the BE469 as I’m not seeing anything in the logs or MQTT for this lock.

Very timely find this thread is. I'm also having this issue.
Kwikset ZWave 914 Deadbolt Lock: https://github.com/OpenZWave/open-zwave/blob/master/config/kwikset/914c.xml#L65-L73
Latest ZWave MQTT code and such. OZW 1.6.
It looks like the same lock, or similar situation as @jaburges . The lock doesn't update the locked true/false on its own, so when Command Class 113 is reported, we need to poll for 98-1-0(Locked Status).
It sounds like the ZWave MQTT app is ignoring the TriggerRefreshValue directive in the XML for that node.

It sounds like the ZWave MQTT app is ignoring the TriggerRefreshValue directive in the XML for that node

Zwave2Mqtt uses openzwave-shared to use OZW. And I think that once the configuration of a device is loaded it should work as the configuration tells, I should not handle that. I think that this is something on OZW side not something wrong with Z2M
@jaburges

2020-03-04 22:43:07.240 Detail, Node093, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 512
2020-03-04 22:43:07.240 Detail, Node093, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 513

Notification: ValueChanged I am subscribed to those changes, if you receive all others updates you should get that too
https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/ZwaveClient.js#L67
https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/ZwaveClient.js#L69
https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/ZwaveClient.js#L447
The only reason why you could not get the updates is if the node is not ready
That event is coming from here: https://github.com/OpenZWave/node-openzwave-shared/blob/master/src/callbacks.cc#L212

@robertsLando i'm not sure i understand your comments?
i am getting updates to MQTT on /113/1/512 & 113/1/513 but NOT /98/1/0 (which is the "Locked" state) for a manual lock turn.
I can still lock/unlock when I send true or false to 98/1/0/set - which then the lock confirms its new state at /98/1/0 .
As above it seems like there were some edits made to the devices to grab/poll the state of the lock at the time the alarm level is triggered (as that wasn't happening normally). Beyond this point anything I add is likely to complicate things (as i'm not a zwave specialist).

@jaburges My comment was mainly for @Fishwaldo to show him how things are from my side, I really think it is something on OZW side and I have no power with that

Has anyone actually tried my suggestion to change the config?
These devices are not compliant with the specifications. The Config change works around that.

@Fishwaldo yep about 5 days ago after your comment. Sadly didn’t resolve the issue :-(

Logs please. After removing ozwcache

removed ozwcache last restart. Here is the log: https://1drv.ms/u/s!At3XmrQSJ2NJs5EsTxjIauM3WPa0JQ?e=3AnSwi
Let me know if you want me to restart and just lock/unlock the locks.
Node 92 & 93 are Kwikset Locks
Node 78 is the BE469

@Fishwaldo let me know if you need any more info and what thoughts you have on resolving this.

2020-03-06 21:20:40.681 Info, Node078, Value Refresh triggered by CommandClass: COMMAND_CLASS_NOTIFICATION, Genre: 1, Instance: 1, Index: 0 for:
2020-03-06 21:20:40.681 Info, Node078,     CommandClass: COMMAND_CLASS_DOOR_LOCK, RequestFlags: 0, Instance: 1, Index: 1

Node 78 Does not have the changes I recommended above (change Index to 6). Hence:
2020-03-07 14:16:29.828 Info, Node078, Got a AlarmCmd_Report Message....
2020-03-07 14:16:29.828 Info, Node078, Received Notification report (>v1): Type: Access Control (6) Event: Manual Unlock Operation (2) Status: true, Param Length: 0
2020-03-07 14:16:29.828 Detail, Node078, Initial read of value
2020-03-07 14:16:29.828 Info, Node078, Automatically Clearing Alarm in 5000ms
2020-03-07 14:16:29.828 Info, Timer: adding event in 5000 ms
2020-03-07 14:16:29.828 Detail, Timer: waiting with timeout 5000 ms
2020-03-07 14:16:29.828 Detail, Node078, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 6

Does not trigger OZW to refresh the DoorLock Status
Node92:
2020-03-06 21:20:40.716 Info, Node092, Value Refresh triggered by CommandClass: COMMAND_CLASS_NOTIFICATION, Genre: 1, Instance: 1, Index: 0 for:
2020-03-06 21:20:40.716 Info, Node092,     CommandClass: COMMAND_CLASS_DOOR_LOCK, RequestFlags: 0, Instance: 1, Index: 1

Also does not have the changes (index 6)
but it does not seem to expose a Access Control (index 6) Alarm Message type:
2020-03-06 21:20:40.870 Detail, Node092, Notification: ValueAdded CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 512
2020-03-06 21:20:40.870 Detail, Node092, Notification: ValueAdded CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 513
2020-03-06 21:20:40.871 Detail, Node092, Notification: ValueAdded CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 514

hence we get:
2020-03-06 23:00:53.820 Info, Node092, Got a AlarmCmd_Report Message....
2020-03-06 23:00:53.820 Info, Node092, Received Alarm report: type=24, level=1
2020-03-06 23:00:53.820 Detail, Node092, Initial read of value
2020-03-06 23:00:53.820 Detail, Node092, Initial read of value
2020-03-06 23:00:53.820 Detail, Node092, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 512
2020-03-06 23:00:53.820 Detail, Node092, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 513

So you probably have to change index from 0 to 512 or 513 for the Kwikset locks
Also, There is one bug that I've fixed (but nothing todo with reporting) and I also see Node078 is really acting strange, occasionally flooding the Network With Nonce_Get Messages very very quickly (see 21:01:09:643 - Resolved at at 21:01:24:38 and at 15:57:14:886 we get into another Nonce Flood, Finally resolved at 15:58:47:478)
If you fix the RefreshValue blocks for each device, hopefully it will refresh the door lock status when opened/closed locally. (from the logs, it works when you do it remotely)
Hate to say it (I may already have said it) but both these locks are not compliant with the Z-Wave specifications. They would not pass certification today. I do recall that some Locks were bundled with a alarm.com package (or something similar) and it appears that interoperability was not a concern to them.
In Particular, Node78 is probably causing other issues with its flooding of the Network, sometimes in excess of 1 minute - which means any other reports are probably not getting through...

Thanks for the response, I’ll take another look and make sure the changes stick.
Can’t understand why it would happen in an update though. I’ve had these locks for 4 years and have been working fine. I understand they may not be compliant but that shouldn’t suddenly stop them working - unless there was a change made that aligns to Compliance and these then don’t fall in line?

I suspect its a case of transition from OZW 1.4 to OZW 1.6 - The Alarm (now called Notification) CC was rewritten to support Version 11 (it previously supported version 4?). With that re-write, the index numbers changed - hence why the config file was pointing at the wrong index's
I can't possibly test all the devices (I own a LOT but not everything!) hence, why a lot of config files are maintained by the "Community"
And yes - we did a lot of work on OZW 1.6 to be more compliant... but that wasn't the source of your problem... the RefreshValue config option was created for "non-compliant" devices even in 1.4 days

Cool, I’ll do my best to test these and report back today :-)

every step forward is another 2 backward.
So removed ozwcache and it rebuilt the Kwikset locks correctly, now responding to manual commands.
However, now the door sensors are reporting as dead.
and I removed node on the BE469 and its still showing :-/
is there a limit to how many nodes you can have, as I feel like there seems to be some kind of limit on the zwave network before issues occur. Its been solid until this lock issue, and excluding and re-adding them (with the edit) is the only fix that has worked.

@robertsLando dead nodes or excluded nodes arent removing from the list and show up as:
Unknown: type=0000, id=0000 (Unknown: id=0000)

Even after restart

dead nodes or excluded nodes arent removing from the list and show up as:

This is not handled by Z2M

Is there some DB that Z2M is using that stores this information

I only store nodes name and locations in a file in store named nodes.json but that doesn't do anything against OZW. I only take those info if nodes are coming from OZW events notifications

There is definitely something off, as I excluded the BE469 lock. I then reset the lock (full factory reset, no working codes etc etc).
On re-adding the lock, it was assigned its previous node (node 78) - every other device is assigned a new node.

i've now repaired 99% of my zwave network except for a strips back door sensor (WIP).
However the Kwikset locks are not reporting their state from a manual lock turn as originally raised.
CONFIRMED for both Kwikset locks:
			<CommandClass id="113" name="COMMAND_CLASS_NOTIFICATION">
				<Compatibility />
				<State>
					<CCVersion>1</CCVersion>
					<Encrypted>true</Encrypted>
					<StaticRequests>2</StaticRequests>
				</State>
				<Instance index="1" />
				<Value type="byte" genre="user" instance="1" index="512" label="Alarm Type" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="22">
					<Help>Alarm Type Received</Help>
				</Value>
				<Value type="byte" genre="user" instance="1" index="513" label="Alarm Level" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1">
					<Help>Alarm Level Received</Help>
				</Value>
				<Value type="int" genre="config" instance="1" index="514" label="Automatically Clear Events" units="ms" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="5000">
					<Help>Automatically Clear Events sent by a device after a number of Milliseconds</Help>
				</Value>
				<TriggerRefreshValue Genre="user" Instance="1" Index="6">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>
				<TriggerRefreshValue Genre="user" Instance="1" Index="6">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>
			</CommandClass>

HOWEVER - 1 lock works (eventually) node 92 but there is a LOT of traffic and issues in the logs before it registers the change.
Node 93 the other Kwikset lock shows nothing in the logs here
This is getting really tiresome chasing these gremlins, especially as there seems to be no consistency to the issues. Could really do with some direction as now i have excluded and re-included (after a factory reset).

Unfortunately the TriggerRefreshValue Block isn't correct. Maybe let me explain so you can understand what its doing:
				<TriggerRefreshValue Genre="user" Instance="1" Index="6">

This says - if we see a ValueID, whois Genre is user, its instance is 1, and the Index is 6, then we are going to refresh a ValueID in another class:
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />

So this is the ValueID we are going to refresh - In this case CommandClass 98 (doorlock), RequestFlags is advanced and can be left at 0, Instance 1, Index 1 - which corresponds to the DoorLock Status ValueID
Now technically, you look at the DoorLock CC - there are two ValueID's that relevant, (Lock - Index 0 and Lock_Mode - Index 1) but we only need to refresh one of them, and the other will update, hence we don't need to have two RefreshClassValue blocks as refreshing one will automatically refresh the other)
So in the dump you posted above, we will only Refresh the DoorLock if we get a change on a Notification CC with Index 6 (Access Control), but in your case, the device doesn't expose a "Access Control" Notification type. Only Alarm Type (index 512) and Alarm Level (index 513). So you need to pick one (either one is fine) and update your TriggerRefreshValue index with 512 or 513 (I did post that above).
Other Devices, like your BE469 did expose Index 6 (Access Control) so that block probably would work for it.

This is getting really tiresome chasing these gremlins, especially as there seems to be no consistency to the issues.

Your working with some pretty old devices here, welcome to my world!

There is definitely something off, as I excluded the BE469 lock. I then reset the lock (full factory reset, no working codes etc etc).
On re-adding the lock, it was assigned its previous node (node 78) - every other device is assigned a new node.

Sounds like the Exclusion didn't "stick" on the Controller. I assume you did a "RemoveNode" then did whatever button dance on the lock to actually trigger the Node Removal?

btw, when you get it finally "refreshing" there is a fix to the Lock_Mode value. @robertsLando needs to pull the latest version to get it... but we can continue to diagnose instead of having to wait for him.

is there a limit to how many nodes you can have, as I feel like there seems to be some kind of limit on the zwave network before issues occur. Its been solid until this lock issue, and excluding and re-adding them (with the edit) is the only fix that has worked.

I can't see from your logs (as we had ozwcache present) details about your Network, so this is just generic advice...

Pre ZWave+ devices operate at 40K bandwidth... Z-Wave+ devices operate at 100K bandwidth... so if you have lots of traffic, obviously old devices are going to limit your available bandwidth

On a large network, its good to have a decent amount of Mains powered devices. These are the only type of devices that "particpate" in creating a mesh. Battery devices will not "strengthen" your mesh.

I saw a LOT of motion events in your log files. I'm assuming these are battery powered. This is really chatty. If you have a lot of pre-zwave+ devices this is consuming your bandwidth, introducing latency. You may want to evaluate the "retrigger time" (if available) for the motion sensors here - its a trade off - Frequent updates, versus latency. you need to decide if the latency is worth it.
Also - the Network Graph/Neighbors only displays around 1/4 of the actual routing table a device has. Honestly, its pretty much next to useless, as what you see are basically the "last resort" as far as how a mesh is setup/configured.
When Adding/Removing or Physically moving a mains powered node (not battery) you should run HealNetwork - It will run in the background and could take anywhere from minutes to hours. Unfortunately there is no feedback from the stick when it completes :( Also - During that time, pretty much 100% of bandwidth is consumed, so any testing etc during that time is going to be affected
Heal Network is most beneficial to Non-ZWave+ devices. (as they dont have a feature called Explorer Frames that auto discover the Network paths etc). If you have all + devices, then its pretty much redundant.
Finally - There are some really crappy devices out there (especially older devices prior to the Z-Wave Alliance improving the certification process). A lot of code in OZW is to deal with these crappy implementations. Unfortunately your dealing with 2 models that are in that category, hence there is some trial and error needed to get them functional. I'm pretty sure if you had models that were very recently released (and certified) then you wouldn't be facing these issues.

thanks for the informative reply! super useful.
i'll explore what options there are to replace the locks - little frustrating as they weren't cheap.
I wonder what recourse there is for scenarios like this from the manufacturer.
I have a lot of powered devices (all my light switches are permanently wired creating a pretty solid mesh throughout the house) - although most of these are GE and not z-wave plus.
The motion sensors are Dome and certified z-wave plus.
The thing I can't get my head around is WHY this suddenly happened, and why excluding and re-adding the device has fixed things.
I'm also seeing a lot of the NONCES to the garage door opener (so basically the 4 devices out of all of them having issues - mostly different manufacturers and not all locks) were the ones securely added.
Is it possible that during an update, or a recent change the security/trust broke leaving these devices as only partly communicating with the controller?

There is no reason to wait for me to build a new release just for “testing”. Instead there are 2 options to this (that are lot recommended): first one is to git clone this project compile it and start it hsing nodejs, the second one would be to follow Zwave2Mqtt-docker repo readme and compile a custom docker image (it’s just one command).

On 15 Mar 2020, at 07:33, jaburges notifications@github.com wrote:

thanks for the informative reply! super useful.
i'll explore what options there are to replace the locks - little frustrating as they weren't cheap.
I wonder what recourse there is for scenarios like this from the manufacturer.
I have a lot of powered devices (all my light switches are permanently wired creating a pretty solid mesh throughout the house) - although most of these are GE and not z-wave plus.
The motion sensors are Dome and certified z-wave plus.
The thing I can't get my head around is WHY this suddenly happened, and why excluding and re-adding the device has fixed things.
I'm also seeing a lot of the NONCES to the garage door opener (so basically the 4 devices out of all of them having issues - mostly different manufacturers and not all locks) were the ones securely added.
Is it possible that during an update, or a recent change the security/trust broke leaving these devices as only partly communicating with the controller?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

i'll explore what options there are to replace the locks - little frustrating as they weren't cheap.
I wonder what recourse there is for scenarios like this from the manufacturer.

Well if we get this TriggerRefreshValue right - then I think you will be able to use them....

Is it possible that during an update, or a recent change the security/trust broke leaving these devices as only partly communicating with the controller?

In general, it either works or doesn't work. Not often you will get a partially works, and if you do, its more than likely a RF/Mesh issue than a security issue.

ok update. I have pulled the latest docker of Zwave2MQTT which includes the latest OZW build (1.6.1061 (latest from master)
Removed ozwcache (and nodes.json from Z2M) - renamed and ensured all devices are 'Alive' and talking to the controller.
BE469 and Kwikset locks STILL dont report their manual state to the controller.
Issue 1: BE469 isn't reporting the correct device type (not sure how to force it).
Refresh Node Info doesnt help.
Issue 2: (Related to issue 1 is the ozwcache entry for that node does NOT include the changes
mentioned by @Fishwaldo as that requires it to recognize the device type)
Issue 3: Again supplemental to issue 1 as the device does not contain the Lifeline association to the
controller.
Kwikset DOES have the additions made above, and the LifeLine association to the controller but is currently NOT reporting manual state/lock changes, although is reporting 512 & 513
Here is the Kwikset Node logs:
2020-03-17 19:41:49.238 Detail, Node093,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x5d, 0x02, 0x98, 0x40, 0x74
2020-03-17 19:41:49.238 Info, Node093, Received SecurityCmd_NonceGet from node 93
2020-03-17 19:41:49.238 Info, NONCES: 0xeb, 0x56, 0xa1, 0x29, 0xac, 0x3d, 0xfb, 0x6c
2020-03-17 19:41:49.238 Info, NONCES: 0x63, 0x73, 0x8a, 0x5b, 0xb0, 0x01, 0x6c, 0x81
2020-03-17 19:41:49.239 Info, NONCES: 0x61, 0x51, 0xf3, 0xa4, 0x46, 0x94, 0x90, 0x9b
2020-03-17 19:41:49.239 Info, NONCES: 0xdb, 0xeb, 0x5a, 0x5b, 0xfd, 0xb6, 0xd9, 0x95
2020-03-17 19:41:49.239 Info, NONCES: 0xef, 0xf8, 0xa4, 0xad, 0xa4, 0x4b, 0xea, 0x6f
2020-03-17 19:41:49.239 Info, NONCES: 0x4a, 0x41, 0x8f, 0x3c, 0xa4, 0x96, 0x66, 0x91
2020-03-17 19:41:49.239 Info, NONCES: 0xab, 0x80, 0x09, 0x98, 0x28, 0x91, 0x10, 0xe8
2020-03-17 19:41:49.239 Info, NONCES: 0xea, 0x91, 0xef, 0x93, 0x21, 0xf0, 0xf9, 0xe1
2020-03-17 19:41:49.239 Info, Node093, Sending (Send) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x5d, 0x0a, 0x98, 0x80, 0xea, 0x91, 0xef, 0x93, 0x21, 0xf0, 0xf9, 0xe1, 0x05, 0x01, 0x78:
2020-03-17 19:41:49.253 Detail,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-03-17 19:41:49.253 Detail,   ZW_SEND_DATA delivered to Z-Wave stack
2020-03-17 19:41:49.359 Detail,   Received: 0x01, 0x07, 0x00, 0x13, 0x01, 0x00, 0x00, 0x0b, 0xe1
2020-03-17 19:41:49.359 Detail,   ZW_SEND_DATA Request with callback ID 0x01 received (expected 0x01)
2020-03-17 19:41:49.426 Detail, Node093,   Received: 0x01, 0x1e, 0x00, 0x04, 0x00, 0x5d, 0x18, 0x98, 0x81, 0x29, 0x54, 0xb6, 0x06, 0x01, 0x7c, 0x08, 0xda, 0x7f, 0xc0, 0x8e, 0xa2, 0xc3, 0xea, 0x5d, 0x0d, 0xd2, 0xc0, 0xe7, 0x6b, 0x22, 0x36, 0xbb
2020-03-17 19:41:49.426 Info, Raw: 0x98, 0x81, 0x29, 0x54, 0xb6, 0x06, 0x01, 0x7c, 0x08, 0xda, 0x7f, 0xc0, 0x8e, 0xa2, 0xc3, 0xea, 0x5d, 0x0d, 0xd2, 0xc0, 0xe7, 0x6b, 0x22, 0x36, 0xbb
2020-03-17 19:41:49.426 Detail, Node093, Decrypted Packet: 0x00, 0x71, 0x05, 0x16, 0x01
2020-03-17 19:41:49.426 Detail,
2020-03-17 19:41:49.426 Info, Node093, Got a AlarmCmd_Report Message....
2020-03-17 19:41:49.426 Info, Node093, Received Alarm report: type=22, level=1
2020-03-17 19:41:49.426 Detail, Node093, Refreshed Value: old value=21, new value=22, type=byte
2020-03-17 19:41:49.426 Detail, Node093, Changes to this value are not verified
2020-03-17 19:41:49.426 Detail, Node093, Refreshed Value: old value=1, new value=1, type=byte
2020-03-17 19:41:49.426 Detail, Node093, Changes to this value are not verified
2020-03-17 19:41:49.426 Detail, Node093, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 512
2020-03-17 19:41:49.427 Detail, Node093, Notification: ValueChanged CC: COMMAND_CLASS_NOTIFICATION Instance: 1 Index: 513
  z2m:Zwave zwave node 93: changed: 113-1-512:Alarm Type:21 -> 22 +514ms
  z2m:Zwave zwave node 93: changed: 113-1-513:Alarm Level:1 -> 1 +0ms

In the spirit of being thorough I excluded the BE469 and then paired it. This time a new node number was issued, however still the wrong device is being reported.
Log of the inclusion is here:
https://pastebin.com/kgs9QRrt

This issue (on searching the web goes back as far as 2018 so doesnt seem like a new thing).
Also the BE469 is in fact z-wave alliance certified:
https://products.z-wavealliance.org/products/1051
so not sure I understand the part about it being non-compliant.
My model is specifically BE469NX

so the solution was to replace the BE469 with a BE469ZP (zwave Plus) - oddly there was an error on first inclusion but the new lock does not have the issue.
NOTE - despite being securely added, it is showing in the UI as NOT securely added, and whilst i can lock/unlock the user codes are not configurable.
Now the Kwikset continues to have the same issue.
I have used Node-Red to solve this temporarily listening to 512 and 513 and submitting the correct state to 98.

@robertsLando but mostly @Fishwaldo i thought I was losing my mind (turns out i'm not)
As above the Brand NEW BE469ZP was securely added (showed in the UI as secure).
Then for some reason changed to not secure?! weird thought I may have done something wrong.
Excluded the lock, and then re-added it securely. next morning the lock is no longer showing as Secure. And validated by the fact I no longer see the user code parameters in the UI. I guess Z2M is working correctly.
Why an earth is a device losing its secure connection?

@jaburges don’t trust that flag. If you added it securely it is secure. There is an open issue for that
Sent with GitHawk

Normally I’d agree, however the user code
Parameters (the ability to enter and store user codes in the UI) disappears once the secure flag changes to ‘No’

@jaburges That's must be a bug with the device so :confused:  I never seen such things @Fishwaldo what do you think?

I actually think it could be RF interference, that randomly causes dropped z-wave commands. In a 24 hour period seemingly if a certain command is dropped (not sure which) the lock stops communicating securely (and Z2M actually behaves correctly, as updates the Secure flag = No, and removes secure functionality).

@jaburges That's really weird

The weirdest thing is the interference is potentially from 2.4GHz !?

@Fishwaldo

everything is stable without the possible interference. I'm going to regret doing this, but i'm going to test if that is the case, and replace the possible interference and see if the issue returns - update to follow

@jaburges Ok thanks!

Ok tested and moved the RF interference back.
I’ll close this issue, but my concern is we never got to the bottom of it. The locks just stopped working (and I ended up getting a newer Zwave plus lock)
For completeness:
The new BE469ZP has issues when dropping commands, however after a few days I guess when the zwave network may have stablized? I removed and re-added this lock and it works, reports manual state AND remains securely added.
The Kwikset locks needed the fix above from fishwaldo, but now also report manual lock state changes correctly.
No idea what caused the issue, but hope it holds as is.
Thanks for your help!

I have a Kwikset 916 door lock and notice it doesn't refresh on manual lock / unlock.  What file do I need to change?

I suggest to open this device related question in openzwave repo, unfortunately I cannot help with this kind of issues

Daniel

On 14 Jul 2020, at 22:09, Devin Buhl notifications@github.com wrote:

I have a Kwikset 916 door lock and notice it doesn't refresh on manual lock / unlock. What file do I need to change?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

authors: Fishwaldo brgaulin jaburges onedr0p robertsLando shbatm


text:
ERC721 pausable token

Fixes #1115
🚀 Description

ERC721PausableToken: ERC721BasicToken modified with pausable transfers.

[x] 📘 I've reviewed the OpenZeppelin Contributor Guidelines
[x] ✅ I've added tests where applicable to test my new functionality.
[x] 📖 I've made sure that my contracts are well-documented.
[x] 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

Hello @nventuro, thank you for feedback!
I've made changes to pull request according to your comments.
Also, I've add checks for views, as their behavior shouldn't be changed while pause. Is it a good idea (in terms of #1148) to extract somthing like shouldBehaveLikeERC721BasicTokenViews and share it between ERC721 Basic & ERC721 Pausable test suites?

Is there something that blocks merge?

Sorry @urvalla - this PR must've slipped by! Thanks for letting me know. I'll review ASAP and get back to you :)

Thank you, @nventuro!
I've left shouldBehaveLikeERC721BasicToken(owner, ...otherAccounts) call, but not shouldBehaveLikeERC721BasicToken(owner, [...otherAccounts]) due to its interface. I'll fix it in a separate pull request.

Awesome, thanks for keeping the PRs clean and concise :) Looking forward to that PR!

Great work @urvalla, thank you very much for your contribution! We haven't seen many flavors of ERC721 come up, this is a nice addition.

authors: nventuro urvalla

repo: OpenZeppelin/openzeppelin-solidity


text:
Network files missing storage layout when overrides are used

The Hardhat Upgrades plugin normally enables storage layout automatically in Solidity compilation settings, so that detailed storage layout can be saved in the network files.
However, when a project's hardhat config has overrides for Solidity compiler settings (e.g. https://github.com/Idle-Labs/idle-tranches/blob/master/hardhat.config.js#L62), storage layout is not enabled for these overrides.  This causes the network file (such as https://github.com/Idle-Labs/idle-tranches/blob/master/.openzeppelin/unknown-1101.json#L496-L810) to be missing detailed storage layout such as slot and offset fields.  This causes storage layout checks to fail from storage gap resizing, even if the storage gap is being used properly.
--
Originally reported in https://forum.openzeppelin.com/t/bad-storage-gap-resize-when-adding-variables-and-reducing-gap/37196

This should be fixed in:
https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/d1513992c58106b44967e42cb9f8cb2621d5a300/packages/plugin-hardhat/src/index.ts#L109-L118

authors: ericglau frangio

repo: OpenZeppelin/openzeppelin-upgrades


text:
Can't launch after installation, error messages, missing files

I'm greeted with this after running the Path of Building installer: https://i.gyazo.com/f19dbfd06c2279a51752cb3d8c450a42.png
The full text:
`Please wait while we complete installation...
Saving C:\ProgramData\Path of Building\Launch.cfg
Engine shutdown complete.
--- SCRIPT ERROR ---
Runtime error in 'C:\ProgramData\Path of Building\Launch.lua':
UpdateCheck.lua:9: module 'xml' not found:
no field package.preload['xml']
no file 'C:\Program Files (x86)\LuaRocks\lua\xml.lua'
no file 'C:\Program Files (x86)\LuaRocks\lua\xml\init.lua'
no file 'C:\Program Files(x86)\LuaRocks\lua\5.3\share\lua\5.3\xml.lua'
no file 'C:\Program Files(x86)\lua\5.3\share\lua\5.3\xml\init.lua'
no file 'C:\Program Files (x86)\lua\5.3\lib\lua\5.3\xml.dll'
stack traceback:
[C]: in function 'require'
UpdateCheck.lua:9: in main chunk
[C]: in function 'LoadModule'
C:\ProgramData\Path of Building\Launch.lua:30: in function <C:\ProgramData\Path of Building\Launch.lua:15>
`
Seems like it's looking for files that aren't part of the standard luarocks installation? I've already tried downloading and doing a force installation of the latest version of luarocks, which does succeed, but it doesn't include the files listed by this error in POB.
Any tips are welcome; I'm hardly familiar with luarocks and only installed it years ago just to try it out, but I never did anything with it.

Hilariously, I've just solved this since I posted.
Despite setting my %PATH% and environment variables exactly according to what the luarocks installer suggested, I thought maybe POB was unhappy with them. I removed LUA_PATH and LUA_CPATH from both my system variables and user variables and now Path of Building launches correctly.

same issue here. would be nice if the installed program would be self-contained and ignore system lua settings.

Can confirm system Lua installation interferes with POB. In my case lua was installed through scoop. Removing LUA_PATH and LUA_CPATH as mentioned above is a workaround.

authors: Sykaas grapereader jjYBdx4IL

repo: Openarl/PathOfBuilding


text:
Adding new Watcher's Eye variants

I copied these from the wiki, and for some reason the diff is showing the addition and removal of almost all of them.
I also added a checkbox to differentiate between a jewel from Uber Elder and one from just regular Elder.  I wasn't able to figure out how to hide the checkbox for other uniques without my code removing all of the variant section or leaving a blank, so I just disabled it to get this in.  I can remove that commit or at least the checkbox after this weekend if you'd rather wait on that piece until later.

I copied these from the wiki, and for some reason the diff is showing the addition and removal of almost all of them.
I also added a checkbox to differentiate between a jewel from Uber Elder and one from just regular Elder. I wasn't able to figure out how to hide the checkbox for other uniques without my code removing all of the variant section or leaving a blank, so I just disabled it to get this in. I can remove that commit or at least the checkbox after this weekend if you'd rather wait on that piece until later.

Greetings. But why checkbox? Why not just third select box for third "while affected by" row? If all select boxes are same -> only one row for watcher's eye - it is working now. Or (and?) make first "None" option as alternative to make this process less frustrating.

is there an idea on when this pull request will be merged?

@Openarl I know you're super busy with the Blight release at the moment, but I wanted to put this back on your radar. From my perspective this is a fairly low-risk and high-value change that many users would really appreciate.
Is there more to be done here or does it just need a keen review from a core maintainer? Anything I can do to help?


text:
Add eagle image and fix typo in Alexis section

Following along with clinic demonstration. Please check out my eagles.

Thanks! Because this is the template repo I'm going to close this without merging :)

About-face! I'm reopening so you can merge if you like, and see your changes in the live site (https://openscapes.github.io/quarto-clinic). We can revert/tweak things later for the next teaching session 😄

authors: alexishunzinger ateucher

repo: Openscapes/quarto-clinic


text:
Canceling a protocol outside the app

A few months ago, we had a pipette crash into the tip box following our protocol cancellation using a try/catch loop. It seemed like this occurred because of the interpreter, which would stop the current step, run a recover and reset block, and then finish the step it was on before, probably without certain variables such as labware calibration, etc, resulting in our crash.
Has this issue been resolved? And if not, is there any way we can have our code get around it (since the app allows cancellation, is there some code that allows this to be done safely)? We would ideally like to be able to cancel protocols, because right now if we make any error in the setup, we have to wait an hour before we can use that robot again.

Hi @caroline-wyzer,
The app uses this function via react-query to cancel a protocol run.
The readme in api-client says that npm install can install api-client as a package, but we haven't published it as a package so the readme doesn't work. (sorry for the inconvenience to you).
If you plan to use js/ts, you will need to clone this repo and build api-client and install it as a package with npm/yarn. Our repo is using yarn so I highly recommend you use yarn.
If you plan to use python, probably this new python wrapper will be good.
The support team may be able to provide further guidance on this. support@opentrons.com. When you reach out to the team, please provide your environment info(app version and robot-server version) with them. Then they can response to you quickly.

Hey @caroline-wyzer, I'm going to close this in favor of the original ticket #11360. There have been no changes to SSH based execution, but I'm going to sound off in that thread with an alternative solution

authors: caroline-wyzer koji mcous

repo: Opentrons/opentrons


text:
PD Research spike: How do we track whether a form has been edited since its last save (1 of 4)

Link to research question

I've thrown my analysis into the google doc in this ticket!

authors: howisthisnamenottakenyet shlokamin


text:
Labware definition file refactor

Problem
Labware definitions are currently stored in a single large json file, and duplicated with some transformations in a sqlite database.
Specific problems:

There is currently no mechanism for keeping these two databases in sync with each other
The human-readable datastore (the json file) is not the source of truth at run time
The labware definitions themselves have some problems in either file, such as the fact that the wells are not given any strict order or organization into or within rows and columns, which has caused unpredictable behavior in user protocols
The migration process (creating the sqlite database from the json file if it does not previously exist) is slow and unnecessary
The current state of the server keeps all of both the json datastore and the sqlite database in memory, which nullifies any gains made from keeping the data in a structured database
It is difficult to incorporate and share user labware definitions
The "container-offsets" field in the labware definition is confusing (and unnecessary, because the labware itself is never targeted for movements apart from targeting a well within the labware)

Proposal

Remove the sqlite database from the server
Break the single large json file into a directory containing one json file per labware (example schema below)
Remove "container-offsets" and fold these values into the x/y/z of each well
For each definition, add an array of arrays as an explicit ordering of wells into rows and columns, where each inner array is a column (e.g.: A1 to H1 on a 96-well plate), and row N would be obtained by selecting the Nth element from each column.
Keep standard labware definitions in one directory in the Docker container, and keep user labware definitions in a corresponding directory in persistent storage (when loading a labware, check user directory first, then standard directory)
Add/modify create method that will accept new data format and save to the user definition directory
When calibrating labware, instead of modifying existing definitions, create an "offsets" record representing the delta from the base definition for that labware, in a directory in persistent storage (when loading a labware, check for an offset and apply it if it exists) (example schema below)
Only load a definition into memory when that specific labware is requested, which will reduce the run time memory footprint

Definition schema example:
{
  "metadata": { "name": "4-well-plate" },
  "ordering": [
    [ "A1", "A2" ],
    [ "B1", "B2" ]
  ],
  "wells": {
    "A1": {
      "depth": 26,
      "diameter": 10,
      "total-liquid-volume": 78.6,
      "x": 40,
      "y": 40,
      "z": 30},
    "A2": {
      "depth": 26,
      "diameter": 10,
      "total-liquid-volume": 78.6,
      "x": 40,
      "y": 80,
      "z": 30
    },
    "B1": {
      "depth": 26,
      "diameter": 10,
      "total-liquid-volume": 78.6,
      "x": 40,
      "y": 80,
      "z": 30
    },
    "B2": {
      "depth": 26,
      "diameter": 10,
      "total-liquid-volume": 78.6,
      "x": 80,
      "y": 80,
      "z": 30
    }
  }
}

Offset schema example:
{ "name": "4-well-plate", "x": 10, "y": -10, "z": 100}

Upon load, the x/y/z coordinates of each well would have the corresponding value from the offset file added. In the example above, the A1 well would be at (50, 30, 130) after having the offset applied.

Not sure if this belongs under this issue, but also making sure that labware definitions are actually correct + naming conventions for each labware include either manufacturing company name and/or model number

Sounds good!!!
Also, we talked about moving labware to the repo root as its own labware/ project, and adding a barebones package.json so JS projects can import it -- if that's done as a secondary follow-up PR after the initial big refactor labware PR(s), that's OK with me!
@Laura-Danielle maybe model number & manufacturer would go under the metadata field?
Something else we talked about was not treating "stackable" modules (like temperature deck) as a normal labware, since it doesn't have any wells. (But it does have an offset that it applied to its child/children, and js world would probably benefit from being able to read that offset...)
@btmorr Did we also talk about being able to create any container that you could make with JSON using containers.create? Or is that a separate thing outside this RFC?

@IanLondon I actually think @Laura-Danielle 's idea about having separate named definitions per manufacturer is smart, to avoid confusion between one plate and another, but that doesn't change the overall plan at all
I do think that containers.create should work with the json schema

Also, happy to put the definitions into a repo-level directory with a package.json file. Might as well do it right from the start.

authors: IanLondon Laura-Danielle btmorr


text:
fix(api): Make BCRobot fw_version sync again

This is a regression report and a fix.
#3637 made a lot of hardware control API elements async, including fw_version. Unfortunately, the update server imports the wheel and tries to check fw_version and send it back on requests to /server/update/health, and those requests then 500 because coroutines are not json serializable.
Luckily, the update server is doing this through opentrons.robot, which is a BCRobot, and already has an override for fw_version; so we can just change that to be synchronous. Also luckily the app now prefers /health (from the api server) for information like the smoothie version.

Successfully solved the issue on sanni-t bot


text:
Initial commit for Anroid_page

This branch is the initial android place. It's just the scaffolding for developing the android help page once we get someone to provide further information.
Addresses #119

Could you make it so this page is accessible via the url /getting-started/android?
I'd also like to get this page a little more fleshed out. This should probably be in the CONTRIBUTING.md but all changes that go into master should be OK to go into production.
Can you rally a few people to get some resources for this page?
I think initially we can just have a few sections with 1 or 2 links under them.
I'd like:

a brief summary of the language. Something like what you can do with android development and a really high level overview.
a getting started section with some links on things like how to get your environment setup
a resources section with links to beginner oriented docs. Things like hello worlds, books, blogs, videos etc.

@rickr Sure, I can take a look into all of that. Is getting-started going to be a landing pages for all of the areas? Also, are we going to create a getting-started controller and view container to house these?

I'm not completely sure yet but I know it definitely makes sense to namespace these out so we have the option and things are logically grouped.

Hey Josh - going to close this PR since there's a bit more work to be done. Feel free to open a new one once you've addressed the stuff above.
I've assigned you to #119. She's all yours!

repo: OperationCode/operationcode


text:
Out of memory error with large file profiling

The following line fails for large datasets due to memory constraints.
https://github.com/OpertusMundi/BigDataVoyant/blob/ac9b158d92c064cbfa287019c2e78fdf880b8ffb/bigdatavoyant/profiler.py#L150
The stack trace while running the profiler with a 220MB file is the following:

profile_1  | 2021-01-30 21:38:36,399 - geoprofile.app - ERROR - Exception on /profile/file/vector [POST]
profile_1  | Traceback (most recent call last):
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 2447, in wsgi_app
profile_1  |     response = self.full_dispatch_request()
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1952, in full_dispatch_request
profile_1  |     rv = self.handle_user_exception(e)
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask_cors/extension.py", line 165, in wrapped_function
profile_1  |     return cors_after_request(app.make_response(f(*args, **kwargs)))
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1821, in handle_user_exception
profile_1  |     reraise(exc_type, exc_value, tb)
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/_compat.py", line 39, in reraise
profile_1  |     raise value
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1950, in full_dispatch_request
profile_1  |     rv = self.dispatch_request()
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/flask/app.py", line 1936, in dispatch_request
profile_1  |     return self.view_functionsrule.endpoint
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/geoprofile-0.1.0-py3.8.egg/geoprofile/app.py", line 579, in profile_file_vector
profile_1  |     report = get_resized_report(ds, form, 'vector')
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/geoprofile-0.1.0-py3.8.egg/geoprofile/utils.py", line 108, in get_resized_report
profile_1  |     report = gdf.profiler.report(basemap_provider=form.basemap_provider.data, basemap_name=form.basemap_name.data,
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/bigdatavoyant/profiler.py", line 414, in report
profile_1  |     'distribution': self.distribution().to_dict(),
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/bigdatavoyant/profiler.py", line 168, in distribution
profile_1  |     attributes = self.categorical() if attributes is None else attributes
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/bigdatavoyant/profiler.py", line 150, in categorical
profile_1  |     nunique = df[col].nunique()
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/vaex/expression.py", line 678, in nunique
profile_1  |     return len(self.unique(dropna=dropna, dropnan=dropnan, dropmissing=dropmissing, selection=selection, delay=delay))
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/vaex/expression.py", line 669, in unique
profile_1  |     return self.ds.unique(self.expression, dropna=dropna, dropnan=dropnan, dropmissing=dropmissing, selection=selection, delay=delay)
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/vaex/dataframe.py", line 487, in unique
profile_1  |     keys = np.asarray(keys)
profile_1  |   File "/usr/local/lib/python3.8/dist-packages/numpy/core/_asarray.py", line 85, in asarray
profile_1  |     return array(a, dtype, copy=False, order=order)
profile_1  | MemoryError: Unable to allocate 948. GiB for an array with shape (99990,) and data type <U2545264

Not relevant anymore after the latest update

repo: OpertusMundi/BigDataVoyant


text:
Rolling restart logic is broken

After configuring my cluster CR (by adding a wrong plugin name), the operator updates the sts with the wrong plugin name and restarts one the pods (rolling restart) but the pod is stuck in CLB. When I correct the the plugin name in the CR, the sts is updated with the right name but the pods are not restarted. This is likely due to multiple checks that we have before performing a rolling restart of the pods.
Before doing a rolling restart:

We check if all the data nodes pods are ready or not. This would not be the case on the second try(when the plugin name is corrected) since one of the pod is in CLB

Even after this check, we again check if the sts is healthy i.e. replicas == readyReplicas. Again this would not be the case as one of the pods is stuck in CLB.

While this can easily be fixed by deleting the pod manually, the operator should be handling this case rather the user having to do anything.
Cluster CR -
apiVersion: opensearch.opster.io/v1
kind: OpenSearchCluster
metadata:
  name: vz-os-cluster
  namespace: default
spec:
  security:
    tls:
      transport:
        generate: true
      http:
        generate: true
  general:
    httpPort: 9200
    serviceName: vz-os-cluster
    version: 2.3.0
    drainDataNodes: false
  dashboards:
    tls:
      enable: true
      generate: true
    version: 2.3.0
    enable: true
    replicas: 1
    resources:
      requests:
         memory: "512Mi"
         cpu: "200m"
      limits:
         memory: "512Mi"
         cpu: "200m"
  nodePools:
    - component: masters
      replicas: 3
      resources:
         requests:
            memory: "1Gi"
      roles:
        - "data"
        - "cluster_manager"
      persistence:
        emptyDir: { }

After all the pods are ready, add a wrong plugin to the pluginsList and the pod goes to CLB. Correct the plugin name but the pods are restarted anymore.

Misconfiguring the plugin name is just one example. If for any reason, one of the pods is stuck on a rolling restart, then it seems any further updates to the CR won't have any effect as it will keep on waiting for sts to be healthy before attempting another restart.

Should be fixed with PR #614

authors: saketmht swoehrl-mw


text:
When trying to preview contents of very large files the tool can crash

When previewing contents of very large files the tool crashes.

Added a limit to how many lines of a file is read and displayed for the preview

repo: OpusMag/lds