Unable to start the vault service

VAULT CONFIGURATION SCRIPT
local-vault-1     | (./infrastructure/local/./vault/scripts/init.sh):
local-vault-1     | ===================================
local-postgres-1  | 2023-11-17 03:51:49.176 UTC [1] LOG:  starting PostgreSQL 14.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924, 64-bit
local-postgres-1  | 2023-11-17 03:51:49.176 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
local-postgres-1  | 2023-11-17 03:51:49.176 UTC [1] LOG:  listening on IPv6 address "::", port 5432
local-postgres-1  | 2023-11-17 03:51:49.272 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
local-vault-1     | ==> Vault server configuration:
local-vault-1     |
local-vault-1     |              Api Address: http://<IP_ADDRESS>:8200
local-vault-1     |                      Cgo: disabled
local-vault-1     |          Cluster Address: https://<IP_ADDRESS>:8201
local-vault-1     |    Environment Variables: GODEBUG, HOME, HOSTNAME, PATH, PWD, SHLVL, VAULT_ADDR, VAULT_ADDRESS, VAULT_API_ADDR
local-vault-1     |               Go Version: go1.20.3
local-vault-1     |               Listener 1: tcp (addr: "<IP_ADDRESS>:8200", cluster address: "<IP_ADDRESS>:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
local-vault-1     |                Log Level:
local-vault-1     |                    Mlock: supported: true, enabled: true
local-vault-1     |            Recovery Mode: false
local-vault-1     |                  Storage: file
local-vault-1     |                  Version: Vault v1.13.2, built 2023-04-25T13:02:50Z
local-vault-1     |              Version Sha: b9b773f1628260423e6cc9745531fd903cae853f
local-vault-1     |
local-vault-1     | ==> Vault server started! Log data will stream in below:
local-vault-1     |
local-vault-1     | 2023-11-17T03:51:49.267Z [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
local-vault-1     | 2023-11-17T03:51:49.321Z [INFO]  core: Initializing version history cache for core
local-postgres-1  | 2023-11-17 03:51:49.364 UTC [22] LOG:  database system was shut down at 2023-11-17 03:51:11 UTC
local-postgres-1  | 2023-11-17 03:51:49.405 UTC [1] LOG:  database system is ready to accept connections
local-vault-1     |
local-vault-1     | ===== Unseal the Vault =====
local-vault-1     | Unseal Key (will be hidden):
local-vault-1     | An error occurred attempting to ask for an unseal key. The raw error message
local-vault-1     | is shown below, but usually this is because you attempted to pipe a value
local-vault-1     | into the unseal command or you are executing outside of a terminal (tty). You
local-vault-1     | should run the unseal command from a terminal for maximum security. If this
local-vault-1     | is not an option, the unseal key can be provided as the first argument to the
local-vault-1     | unseal command. The raw error was:  file descriptor 0 is not a terminal
local-vault-1     | Unseal Key (will be hidden):
local-vault-1     | An error occurred attempting to ask for an unseal key. The raw error message
local-vault-1     | is shown below, but usually this is because you attempted to pipe a value
local-vault-1     | into the unseal command or you are executing outside of a terminal (tty). You
local-vault-1     | should run the unseal command from a terminal for maximum security. If this
local-vault-1     | is not an option, the unseal key can be provided as the first argument to the
local-vault-1     | unseal command. The raw error was:  file descriptor 0 is not a terminal
local-vault-1     | Unseal Key (will be hidden):
local-vault-1     | An error occurred attempting to ask for an unseal key. The raw error message
local-vault-1     | is shown below, but usually this is because you attempted to pipe a value
local-vault-1     | into the unseal command or you are executing outside of a terminal (tty). You
local-vault-1     | should run the unseal command from a terminal for maximum security. If this
local-vault-1     | is not an option, the unseal key can be provided as the first argument to the
local-vault-1     | unseal command. The raw error was:  file descriptor 0 is not a terminal
local-vault-1     | Token (will be hidden):
local-vault-1     | Error authenticating: An error occurred attempting to ask for a token. The raw error message is shown below, but usually this is because you attempted to pipe a value into the command or you are executing outside of a terminal (tty). If you want to pipe the value, pass "-" as the argument to read from stdin. The raw error was: file descriptor 0 is not a terminal
local-vault-1     | Error enabling: Error making API request.
local-vault-1     |
local-vault-1     | URL: POST http://<IP_ADDRESS>:8200/v1/sys/mounts/secret
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     |
local-vault-1     | ===== ENABLED KV secrets =====
local-vault-1     | Error registering plugin vault-plugin-secrets-iden3: Error making API request.
local-vault-1     |
local-vault-1     | URL: PUT http://<IP_ADDRESS>:8200/v1/sys/plugins/catalog/vault-plugin-secrets-iden3
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | Error enabling: Error making API request.
local-vault-1     |
local-vault-1     | URL: POST http://<IP_ADDRESS>:8200/v1/sys/mounts/iden3
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | Error enabling: Error making API request.
local-vault-1     |
local-vault-1     | URL: POST http://<IP_ADDRESS>:8200/v1/sys/mounts/kv
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | ===== ENABLED IDEN3 =====
local-vault-1     | ===== CREATE POLICIES =====
local-vault-1     | Error uploading policy: Error making API request.
local-vault-1     |
local-vault-1     | URL: PUT http://<IP_ADDRESS>:8200/v1/sys/policies/acl/issuernode
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | ===== CREATE USERS =====
local-vault-1     | Error enabling userpass auth: Error making API request.
local-vault-1     |
local-vault-1     | URL: POST http://<IP_ADDRESS>:8200/v1/sys/auth/userpass
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | Error writing data to auth/userpass/users/issuernode: Error making API request.
local-vault-1     |
local-vault-1     | URL: PUT http://<IP_ADDRESS>:8200/v1/auth/userpass/users/issuernode
local-vault-1     | Code: 503. Errors:
local-vault-1     |
local-vault-1     | * Vault is sealed
local-vault-1     | token:

the command make new_password=*** change-vault-password  is commented in Makefile, Since the command requires the issuer-vault to be up...I think its a chicken and egg situation.
yash@yash-Lenovo-G50-80:~/go/src/P.O.C/polygonid_issuer_node/issuer-node$ make new_password=*** change-vault-password
docker exec issuer-vault-1
vault write auth/userpass/users/issuernode password=***
Error response from daemon: No such container: issuer-vault-1
make: *** [Makefile:216: change-vault-password] Error 1
yash@yash-Lenovo-G50-80:~/go/src/P.O.C/polygonid_issuer_node/issuer-node$

Hi @yash-block8, That command should not be used right now. We have removed it because it doesn't work indeed.
We will push a new version of the init vault script to allow password change.

Is this issue still open? I’m encountering the same issue now. The error I’m receiving on running make generate-issuer-did might be due to the sealing of the vault (I’m not sure).


As user I want to use multiple synonyms of a command word (example 'list', 'find', 'search') to execute a command the application so that I can find the application more intuitive.

Closed with #13


Integrate LiteLLM

High-level explanation of the problem
DSPy currently supports many LLM providers, including OpenAI, Anthropic, and (~) Huggingface, to name a few.  Each of the LLM providers has its own wrapper script, such as module/anthropic for the Anthropic provider. This helped us in handling the custom API interface that LLM providers had. What this means:

Each LLM provider wrapper must be manually updated when an LLM API interface changes. This may change due to the introduction of new parameters, API refactoring, and significant feature upgrades.
Supporting a New LLM provider requires creating a new wrapper script and writing many redundant code.
Since API interfaces differ across API providers, standardization is lacking.

Suggested Solution
Integrate LiteLLM, which helps manage, standardize, and scale LLM providers. Here is a short summary of what LiteLLM can help us with:

Supporting New LLM providers
Maintaining Existing LLM Providers (new features from providers are easy to integrate!)
Standardization Across LLM providers (To a certain satisfactory degree)

Changes Necessary (only included significant ones)

We will create a new centralized LLM provider wrapper that implements LiteLLM. The wrapper will be the entry point for all the LLM usage.
We will start deprecating individual LLM provider wrappers such as module/anthropic. NOTE: This will not break existing code when users upgrade to the latest version, but they may miss out on new features.

Thank you @lawliet19189 ! This is the right path indeed. There's ongoing work on this, by @hmoazam and in the "rc" branch. Maybe coordinating with Hanna makes sense? She has a more detailed plan.


Update the Collateral and Loan sections to highlight the value backing bnUSD

Maybe an entire page about bnUSD, maybe just a section, but after UST collapse, stablecoin backing and details are valued by users.
Some ideas:

Total $$ value backing it
breakdown of assets backing it (Stability fund + collateral)

Let's update the Loan section to be called Balanced Dollars, and give the Collateral section a dropdown menu:

The Collateral section should display a different set of values depending on which option is active:

(all new collateral types will use the details used in this variation)

Notes:

Have used ICX as the ticker for the ICON collateral type as people are more familiar with it, but happy to be challenged on this. Whichever one we choose, the ticker used for the Collateral section in the app should be consistent with this one.

If ICX, use ICX price as the middle value
If sICX, use sICX / ICX price

Ignore the horizontal line on the Collateral charts

We'll need to update the Y axis on the Collateral chart to use $ values, rather than number of tokens:

Don't think this is possible yet, but it'd be awesome if we could update the info on the Balanced Dollars chart based on which collateral type is currently active.

Here's the icon for the Stability Fund. Will get the All icon for you soon.
stability-fund.svg.zip

Let us know if you have any questions.


Remove TableAvailable

For #4250.

Codecov Report

Merging #4254 into master will increase coverage by <.01%.
The diff coverage is 69.23%.

@@             Coverage Diff              @@
##             master    #4254      +/-   ##
============================================
+ Coverage     60.92%   60.93%   +<.01%
  Complexity      352      352
============================================
  Files          1011     1011
  Lines         16995    16993       -2
  Branches       3005     3003       -2
============================================
  Hits          10355    10355
  Misses         5987     5987
+ Partials        653      651       -2

Impacted Files
Coverage Δ
Complexity Δ

...e/sql/parser/sql/segment/generic/TableSegment.java
20% <ø> (ø)
0 <0> (ø)
:arrow_down:

...lidator/impl/ShardingInsertStatementValidator.java
100% <100%> (ø)
0 <0> (ø)
:arrow_down:

...l/parser/sql/segment/dml/column/ColumnSegment.java
50% <100%> (ø)
0 <0> (ø)
:arrow_down:

...ct/projection/engine/ProjectionsContextEngine.java
67.77% <25%> (ø)
0 <0> (ø)
:arrow_down:

...ent/select/projection/engine/ProjectionEngine.java
97.91% <50%> (ø)
1 <0> (ø)
:arrow_down:

...rite/token/generator/impl/TableTokenGenerator.java
80.64% <66.66%> (ø)
1 <0> (ø)
:arrow_down:

...ere/sharding/route/engine/keygen/GeneratedKey.java
88.88% <75%> (ø)
0 <0> (ø)
:arrow_down:

...l/parser/relation/segment/table/TablesContext.java
89.65% <87.5%> (+2.98%)
0 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 9464

23 of 26 (88.46%)  changed or added relevant lines in 7 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.004%) to 64.827%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

shardingsphere-sql-parser/shardingsphere-sql-parser-relation/src/main/java/org/apache/shardingsphere/sql/parser/relation/segment/select/projection/engine/ProjectionsContextEngine.java
1
4
25.0%

Totals

Change from base Build 9463:
-0.004%

Covered Lines:
11016

Relevant Lines:
16993

💛  - Coveralls


exec multiplex stream

hi.
@clue i want to write some string to execStartStream returned stream but it's not writable stream .
how can i write to this stream?

Yes, I agree and would love to see support for this! If this is something you need for a commercial project and you want to help sponsor or develop this feature, please reach out!
Closing this as a duplicate of #33


Func code for the smart-contracts

Add a link or a folder for all the func code.
https://github.com/toncenter/tonweb/search?q=oneFromBoc

Don't get it. Do you mean something like that? https://github.com/toncenter/tonweb/blob/9a10ecb1b5c703a3115c1d65f708c3ff68f2188d/src/contract/wallet/WalletSources.md

Yeah exactly func/fift for that. I was specifically looking at NFT contracts.


chore: retire AREnableSubmitMyCollectionArtworkInSubmitFlow feature flag

This PR resolves ONYX-1125
Description
This PR retires AREnableSubmitMyCollectionArtworkInSubmitFlow feature flag

PR Checklist

[x] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

retire AREnableSubmitMyCollectionArtworkInSubmitFlow feature flag

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Dev changes (retire AREnableSubmitMyCollectionArtworkInSubmitFlow feature flag)

  Generated by :no_entry_sign: dangerJS against 428f1379eea227906997f01d38a0055ca28bd09b


No robots listed when schema verification fails on non-required fields

Issue
Running the latest commit (34b5941), I am unable to list any robots because the response verification fails.
Steps to recreate
Running
account = pybotvac.Account(pybotvac.PasswordSession(email=<email>, password=<password>))
for robot in list(account.robots):
  ...

on my account prints the following
Bad response from robots endpoint: expected str for dictionary value @ data['timezone']. Got: {'serial': 'OPSblabla', ... 'timezone': None, ...}

and the for loop returns.
Explanation
The reason for this appears to be that self._robots.add(robot_object) is being skipped if response verification throws in refresh_robots() in account.py, regardless of whether the exception is due to a required or non-required field missmatch:
    def refresh_robots(self):
        """
        Get information about robots connected to account.

        :return:
        """

        resp = self._session.get("users/me/robots")

        for robot in resp.json():
            _LOGGER.debug("Create Robot: %s", robot)
            try:
                ROBOT_SCHEMA(robot)
                robot_object = Robot(
                    name=robot["name"],
                    vendor=self._session.vendor,
                    serial=robot["serial"],
                    secret=robot["secret_key"],
                    traits=robot["traits"],
                    endpoint=robot["nucleo_url"],
                )
                self._robots.add(robot_object)
            except MultipleInvalid as ex:
                # Robot was not described accordingly by neato
                _LOGGER.warning(
                    "Bad response from robots endpoint: %s. Got: %s", ex, robot
                )
                continue
...

Proposed fixes

ROBOT_SCHEMA should allow None as timezone entry
Verification of a non-required field should create a log entry, but the rest of the code should execute as normal. If this is not possible, non-required fields should not be verified.

@Santobert Do you agreed with proposed fixes?

@Santobert Do you agreed with proposed fixes?

Yea this may be correct. Since timezone is not documented at all we shouldn't be too restrictive here. Let's use the following ROBOT_SCHEMA

ROBOT_SCHEMA = Schema(
    {
        Required("serial"): str,
        "prefix": Any(str, None),
        Required("name"): str,
        "model": str,
        Required("secret_key"): str,
        "purchased_at": Any(str, None),
        "linked_at": Any(str, None),
        Required("traits"): list,
        # Everything below this line is not documented, but still present
        "firmware": Any(str, None),
        "timezone": Any(str, None),
        Required("nucleo_url"): Url,
        "mac_address": Any(str, None),
        "created_at": Any(str, None),
    },
    extra=ALLOW_EXTRA,
)

I am not 100% sure how to achieve this. Voluptuous checks if the Required() fields are present at all and then if the field has the expected typing. So we can't distinguish between critical and less critical errors this way. Let's stay binary here. Either we can work with the given response or not.

Yea this may be correct. Since timezone is not documented at all we shouldn't be too restrictive here. Let's use the following ROBOT_SCHEMA

ROBOT_SCHEMA = Schema(
    {
        Required("serial"): str,
        "prefix": Any(str, None),
        Required("name"): str,
        "model": str,
        Required("secret_key"): str,
        "purchased_at": Any(str, None),
        "linked_at": Any(str, None),
        Required("traits"): list,
        # Everything below this line is not documented, but still present
        "firmware": Any(str, None),
        "timezone": Any(str, None),
        Required("nucleo_url"): Url,
        "mac_address": Any(str, None),
        "created_at": Any(str, None),
    },
    extra=ALLOW_EXTRA,
)

I am not 100% sure how to achieve this. Voluptuous checks if the Required() fields are present at all and then if the field has the expected typing. So we can't distinguish between critical and less critical errors this way. Let's stay binary here. Either we can work with the given response or not.


Hdds 3772. Add LOG to S3ErrorTable for easier problem locating.

https://issues.apache.org/jira/browse/HDDS-3772

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1054   +/-   ##
=========================================
  Coverage          ?   69.43%
  Complexity        ?     9113
=========================================
  Files             ?      961
  Lines             ?    48150
  Branches          ?     4679
=========================================
  Hits              ?    33435
  Misses            ?    12499
  Partials          ?     2216

Continue to review full report at Codecov.

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

Thank You @ChenSammi for the contribution and @xiaoyuyao for the review.


Right Click of mouse should paste the magnet link

What version of WebTorrent Desktop? (See the 'About WebTorrent' menu)
0.12.0
What operating system and version?
Every OS
What did you do?
Right click on the main screen of webtorrent
What did you expect to happen?
I always expect to be right click option of paste the magnet link
What actually happened?
*Nothing
I was thinking what is missing in the main screen  . Now I found out it is the right click menu to paste new torrent file or magnet link .
I always used (Ctrl + v ) to paste the magnet links.

Ctrl+V works for you, right? I think that's fine. You can also drag-and-drop torrent files.

Just to confirm, you're asking for a Paste Magnet Link... option in the right-click menu

yes I'm asking to put a paste button ,Drag and drop and ctrl+v are working

Reopening as this was never resolved.


Make social buttons extendable

Right now we are hard-coding our social buttons here:
https://github.com/pandas-dev/pydata-sphinx-theme/blob/cc2551f97db509102c99421e758bffd2c527b305/pydata_sphinx_theme/docs-navbar.html#L38
It means that we need to manually add support for a new kind of button each time somebody wants one. We could instead make this a configurable list like so:
pydata_social_buttons = [
    {"classes": "fab fa-github", "url": "https://github.com/pandas-dev/pydata-sphinx-theme"},
    {"classes": "fab fa-twitter-square", "url": "https://twitter.com/pandas-dev"},
]

and so on.
Then the template code for adding the buttons would be:
{% if social_buttons %}

  {% for button in social_buttons %}

  {% endfor %}

{% endif %}

and this could live in _tempalates/social-buttons.html. In the future we could then insert it into the sidebar/navbar/etc as users wish via other configuration values

That sounds good to me!
There might be value in keeping the current github/twitter short-cut (eg if social_buttons are not defined, but github_url is defined, automatically add a github entry to the social_buttons), that is easier for this use case (don't need to know the fab classes).
Should we give it a more generic name (eg "icon links" or so)? It's not necessarily only "social" links

yeah that makes sense 👍

If this gets overhauled: it's likely worth adding some human-readable content to render in a tooltip/screen-reader discoverable way:
pydata_social_buttons = {
    {"title": "GitHub", "classes": "fab fa-github", "url": "https://github.com/pandas-dev/pydata-sphinx-theme"},
    {"title": "Twitter", "classes": "fab fa-twitter-square", "url": "https://twitter.com/pandas-dev"},
}

{% if social_buttons %}

  {% for button in social_buttons %}

        {{ button['title'] }}

  {% endfor %}

{% endif %}

#270 is doing what it says on the tin, but in thinking about deprecation cycles and testing: could we combine external_links and the proposed icon links? It would keep the same data model (e.g. name instead of label or title), but have some flag (maybe just the presence of icon) that would push it to the "short links" toolbar.
    "external_links": [
        {
            "url": "https://pandas.pydata.org/pandas-docs/stable/",
            "name": "Pandas Docs"
        },
        {
            "url": "https://pypi.org/project/pydata-sphinx-theme",
            "name": "PyPI",
            "icon": "fab fa-python",
        }
    ],


typo in WebDriverIO.md

Thanks for PR
This documentation is generated from docblocks of the corresponding JS file: helpers/WebDriverIO.js
Please fix the issue there

@gosua I hope you don't mind, I created a PR #941 fixing the typo in the correct source file. I just thought it would be good as an example.


Inconcistent layout WP twenty twent

Information:

Prism version: [ latest from the download page]
Plugins: [line highlight, line numbers]
Environment: [Mobile Browser]

Description
Everything worked well before since I switched to wordpress twenty twenty theme. Things are breaking. On desktop things are okay but on mobile I am getting the data-line are placed wrong. Even on desktop I'm am getting wrongs tabs.

Example
To reproduce the bug I can only point out to my blog link

That's because the code element is indented. It has to be <pre ...><code ...> without any spaces or line breaks in between.


fix: trimming variable path

fixes #936
Description
Fixes a bug where when having spaces in the left or right of a variable inside the {{ }} syntax bruno would not find the variable:
before the fix:

after the fix:

I would happily add tests for this if it is needed, but I need some help :>)

Hey @giuliano-macedo
Sorry for being late to the PR review
Thanks for taking time to work on this PR. For now, we'd like to keep the interpolation logic strict.
We may consider this in the future, if there is a wider interest from the community or a strong reason on why the variable must be trimmed.


Add Dimensions 'changed' event listener, expose size classes on iOS

Test plan (required)
Example screenshot of iPhone 6S (which has a regular vertical size class)

Added support for dimension change events. However, the UIExplorer example will not demonstrate this, as the demo component is unmounted and remounted on screen changes. Past simple confirmation that the event works (with console.log), I'm not sure what is the best way to test this, or if it's too trivial to test.

By analyzing the blame information on this pull request, we identified @ericvicenti and @javache to be potential reviewers.

@jacobp100 updated the pull request - view changes

Can the dimensions change only only on screen rotation or in other cases too?
cc @andreicoman11 who wanted to look into screen rotation on Android
cc @javache

Both platforms have some sort of split screen support.

Both platforms have some sort of split screen support.

👍

@jacobp100 updated the pull request - view changes

Good timing, @andreicoman11 is just adding this event on Android.

Good timing, @andreicoman11 is just adding this event on Android.

Nice!

Friendly ping to @andreicoman11 or @javache

Sorry, I somehow missed all the comments. Added the suggestions, but I wasn’t sure what the standard way to do event emitters in RN is.

Hey, are you still working on this pull request? In terms of feedback, it seems pretty risky to add this functionality without any tests that cover it. Could you arrange so that this dimension behavior is tested? We also would need to document it.

Sorry, I didn’t get a notification for the change requests. I’m not too sure how we do tests, but for the size classes, there is an example in UIExplorer that will at least form a screenshot-based test.

@hramos Did you see my previous comment?

So it looks like the event emitter part was added to master at some point, which makes this PR just about the size classes now! I've just updated to master and tested everything.
Is there any more I need to do? I believe the only issues were in Dimensions.js, which is now the master version.

Friendly ping to @lacker or @hramos

@jacobp100 Thank you so much for your effort!
I believe we should not introduce size class concept (and merge this) because:

This is pretty specific iOS functionality and I can not imagine how it can be used in RN;
size class is actually view/view controller property, not just screen/device property, so this implementation is not quite correct/useful.

Please, feel free to reopen this to continue the discussion if you are disagree.

Makes sense. Definitely valid points!


Fix link to roadmap in README.md

The current link is incorrect, so this updates the link to the correct value.

/lgtm


Avoid running format checks twice on PRs

Currently, the formatting checks (black and clang-format) are setup to run on all pull requests and all pushes, this means that any commits that get pushed to a PR branch have the formatting checks run on them twice (e.g here)
This PR fixes this by specifying that all PRs but only pushes to the master branch should have the formatting check run on them, which means that the checks will be run once on PRs and then again on the new master branch once a PR is merged.
I also noticed that the unit testing action is only setup to run on PRs targeting the master branch, is this on-purpose or should we also enable that action for all PRs?

Currently, the formatting checks (black and clang-format) are setup to run on all pull requests and all pushes, this means that any commits that get pushed to a PR branch have the formatting checks run on them twice (e.g here)
This PR fixes this by specifying that all PRs but only pushes to the master branch should have the formatting check run on them, which means that the checks will be run once on PRs and then again on the new master branch once a PR is merged.
I also noticed that the unit testing action is only setup to run on PRs targeting the master branch, is this on-purpose or should we also enable that action for all PRs?

I think this PR makes sense.
On the second point, I think running the unit tests on the master branch only makes sense. I'd like to preserve the ability for users to work on development branches that may be broken depending on what feature they are trying to add. When those feature branches are ready for release/review, then the developer can submit a PR at which point the unit tests must pass.


Add test for suggest values for @calendar to schematron

Suggested values are gregorian and julian.

Not concerned this may be too western-centric?

@tcatapano Leave it out.

Commented out the relevant rule. Closing.


[QUESTION] Is v3 maintained anymore? Or we wait for v4?

I wanted to touch base regarding the current status of v3. It seems like there's been a bit of a hiccup lately with the maintenance and functionality. It's been quite some time since v3 has been working smoothly for anyone. I've personally been eagerly awaiting an update for over a month now, especially since the encryption key seems to be causing issues and hasn't been maintained.
I'm finding it impossible to stream anything using mov-cli anymore; every provider I try gives me padding errors and other issues.
So, I was wondering, are we still waiting on a fix for v3? Or perhaps considering moving on to v4 instead?
What's the uppdate? ^^

The current plan is to maintain v3 until v4 is ready,i understand how frustrating this has been. I will focus on fixing it today.
Thank you.

I apologise, im not frustrated tho, but more motivated, id relly like to be of help and help maintain to eliviate workload etc.  , and i relly would love to help out, and be part of maintnance... the thing is, i dont know the code base to well and its structure, I do know a little bit of python, but not versatile an making advansed structure and statements of the get go, only eventualy, but i was thinking if u like, you could teach me what to do and eventualy i cold help maintaine the project (v3) untill v4.
If you tho dont have any ideas as of what component i could be assigned to maintain etc, then u could teach me about the encryption/decryption keys and its system or setup, and I could be of help or be one to be on the the spot to maintain it if the keys stops working or the padding stuff, teach me about it, then structure or the mekanics of the stuff , factors, and ill be on it as soon as it needs to be maintained
i have alot of free time now and be more then happy to

If you're unsure about which component I could handle, perhaps you could teach me about encryption/decryption keys and their system or setup. I could then be on standby to maintain them if they malfunction or if there are issues with padding.

Well the decryption keys are just a hit or miss. I kinda got it to work but i still don't know anything about the decryption. >:(

If you're desperate: https://github.com/mov-cli/mov-cli/issues/188#issuecomment-1981831492


argyllcms: 2.2.1 -> 2.3.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/argyllcms/versions.
meta.description for argyllcms is: "Color management system (compatible with ICC)"
meta.homepage for argyllcms is: "http://www.argyllcms.com"
meta.changelog for argyllcms is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/viewgam passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/iccdump had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/spec2cie passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/extractttag passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/mppcheck passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/tiffgamut passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/chartread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/collink passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/extracticc passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/ls2ti3 passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/dispcal passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/refine passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/icclu had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/cb2ti3 passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/oeminst passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/mpplu passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/fakeCMY passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/colprof passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/greytiff had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/scanin passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/printtarg passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/invprofcheck passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/kodak2ti3 passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/cctiff had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/dispread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/targen passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/colverify passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/illumread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/splitti3 passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/txt2ti3 passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/fakeread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/timage passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/synthread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/printcal passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/cxf2ti3 had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/xicclu passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/average passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/applycal passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/spotread passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/iccgamut passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/ccxxmake passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/revfix passed the binary check.
Warning: no invocation of /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/iccvcgt had a zero exit code or showed the expected version
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/profcheck passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/specplot passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/synthcal passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/dispwin passed the binary check.
/nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin/mppprof passed the binary check.
2 of 48 passed binary check by having a zero exit code.
42 of 48 passed binary check by having the new version present in output.
found 2.3.0 with grep in /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0
found 2.3.0 in filename of file in /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0

Rebuild report (if merged into master) (click to expand)

89 total rebuild path(s)

86 package rebuild(s)

86 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
adapta-gtk-theme
argyllcms
chrome-gnome-shell
cinnamon.cinnamon-common
cinnamon.cinnamon-control-center
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cinnamon-settings-daemon
colord
colord-gtk
darktable
diffoscope
displaycal
docbookrx
eolie
fwupd
gnome-firmware-updater
gnome.gnome-color-manager
gnome.gnome-control-center
gnome.gnome-disk-utility
gnome.gnome-session
gnome.gnome-settings-daemon
gnome.gnome-settings-daemon338
gnome.gnome-shell
gnome.gnome-software
gnome.gnome-terminal
gnome.gnome-tweak-tool
gnome.gnome-tweaks
gnome.gnome_control_center
gnome.gnome_session
gnome.gnome_settings_daemon
gnome.gnome_shell
gnome.gnome_terminal
gnome.gpaste
gnome.mutter
gnome.mutter338
gnome.simple-scan
gnomeExtensions.easyScreenCast
gnomeExtensions.gsconnect
gnomeExtensions.night-theme-switcher
gnomeExtensions.system-monitor
libsForQt5.discover
libsForQt512.discover
libsForQt514.discover
libsForQt515.discover
monitor
pantheon.elementary-greeter
pantheon.elementary-gsettings-schemas
pantheon.elementary-session-settings

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A argyllcms https://github.com/r-ryantm/nixpkgs/archive/b7fd1344446f7c400b1adde41d04c85bcf0947d6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0
ls -la /nix/store/ga9ivk6fpx8av5h0v7snga0vd23daam6-argyllcms-2.3.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages marked as broken and skipped:

libsForQt512.discover
libsForQt514.discover

71 packages built:

adapta-gtk-theme
argyllcms
chrome-gnome-shell
cinnamon.cinnamon-common
cinnamon.cinnamon-control-center
cinnamon.cinnamon-gsettings-overrides
cinnamon.cinnamon-screensaver
cinnamon.cinnamon-session
cinnamon.cinnamon-settings-daemon
colord
colord-gtk
darktable
diffoscope
eolie
fwupd
gnome-firmware-updater
gnome.gnome-color-manager
gnome.gnome-control-center
gnome.gnome-disk-utility
gnome.gnome-session
gnome.gnome-settings-daemon
gnome.gnome-settings-daemon338
gnome.gnome-shell
gnome.gnome-software
gnome.gnome-terminal
gnome.gnome-tweaks
gnome.gpaste
gnome.mutter
gnome.mutter338
gnome.simple-scan
gnomeExtensions.easyScreenCast
gnomeExtensions.gsconnect
gnomeExtensions.night-theme-switcher
gnomeExtensions.system-monitor
libsForQt5.discover
monitor
pantheon.elementary-greeter
pantheon.elementary-gsettings-schemas
pantheon.elementary-session-settings
pantheon.gala
pantheon.switchboard-plug-a11y
pantheon.switchboard-plug-about
pantheon.switchboard-plug-bluetooth
pantheon.switchboard-plug-keyboard
pantheon.switchboard-plug-mouse-touchpad
pantheon.switchboard-plug-pantheon-shell
pantheon.switchboard-plug-power
pantheon.switchboard-plug-security-privacy
pantheon.switchboard-with-plugs
pantheon.wingpanel
pantheon.wingpanel-applications-menu
pantheon.wingpanel-indicator-a11y
pantheon.wingpanel-indicator-bluetooth
pantheon.wingpanel-indicator-datetime
pantheon.wingpanel-indicator-keyboard
pantheon.wingpanel-indicator-network
pantheon.wingpanel-indicator-nightlight
pantheon.wingpanel-indicator-notifications
pantheon.wingpanel-indicator-power
pantheon.wingpanel-indicator-session
pantheon.wingpanel-indicator-sound
pantheon.wingpanel-with-indicators
phoc
phosh
vimix-gtk-themes
weston
westonLite
whitesur-gtk-theme
wingpanel-indicator-ayatana
xdg-desktop-portal-gtk
xiccd

Maintainer pings

Builds, nixos x86_64 & aarch64.

Builds, nixos x86_64 & aarch64.

I don't know how to test this but I found the default of USE_CMFM was changed in 2.3.0 and maybe we should reflect the change here?


How to use other components in the ULP core (IDFGH-13625)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
My idf version is v5.4-dev-2620-g6673376297-dirty
I would like to try to read the data of the sths34pf80 in the ULP core, but the sths34pf80 will have a lot of extra operations to read/write some registers, and it will take a lot of time if the components are not used.
My main/lp_core has the following directory tree

where main/lp_core/lpsths34pf80/CMakeLists.txt has the following contents
set(EXTRA_COMPONENT_DIRS /Users/tinyu/esp/master/esp-idf/components/ulp)
set(EXTRA_COMPONENT_DIRS /Users/tinyu/esp/master/esp-idf/components/esp_timer)

idf_component_register(SRCS
                        "sths34pf80.c"
                        "sths34pf80-pid/sths34pf80_reg.c"
                    INCLUDE_DIRS
                        "include"
                        "sths34pf80-pid"
                        "/Users/tinyu/esp/master/esp-idf/components/ulp/lp_core/lp_core/include"
						"/Users/tinyu/esp/master/esp-idf/components/esp_timer"
                    REQUIRES
                        esp_timer
                        ulp)

The contents of main/CMakeLists.txt are
file(GLOB BMI_SRCS BMI270-Sensor-API/*.c)

file(GLOB BMP_SRCS "${CMAKE_SOURCE_DIR}/components/esp-idf-bmx280/*.c")

file(GLOB ESP32ENCODER_SRCS "${CMAKE_SOURCE_DIR}/components/ESP32Encoder/*.c")

set(CMAKE_VERBOSE_MAKEFILE ON)

idf_component_register(
                    SRCS
                        "main.cpp"
                        "i2c_bus.c"
                        "ir_nec_encoder.c"
                        "ir_test.c"
                        "mesh_stick_pink.c"
                        "mesh_stick_green.c"
                        ${BMI_SRCS}
                        ${BMP_SRCS}
                        ${ESP32ENCODER_SRCS}
                    INCLUDE_DIRS
                        ""
                        "BMI270-Sensor-API"
                        "lp_core/lpsths34pf80/include"
                        "lp_core/lpsths34pf80/sths34pf80-pid"
                        "${CMAKE_SOURCE_DIR}/components/ESP32Encoder"
                        "${CMAKE_SOURCE_DIR}/components/esp-idf-bmx280"
						"$ENV{IDF_PATH}/components/driver/i2c/include/driver"
                    REQUIRES
                        ulp spi_flash esp_timer esp_wifi nvs_flash ra01s ESP32Encoder esp-idf-bmx280 esp_driver_i2c driver
                    WHOLE_ARCHIVE esp_timer)

#
# ULP support additions to component CMakeLists.txt.
#
# 1. The LP Core app name must be unique (if multiple components use LP Core).
set(ulp_app_name lp_core_${COMPONENT_NAME})
#
# 2. Specify all C files.
#    Files should be placed into a separate directory (in this case, lp_core/),
#    which should not be added to COMPONENT_SRCS.
set(ulp_lp_core_sources "lp_core/main.c" "lp_core/lpsths34pf80/sths34pf80.c" "lp_core/lpsths34pf80/sths34pf80-pid/lpsths34pf80_reg.c")

#
# 3. List all the component source files which include automatically
#    generated LP Core export file, ${ulp_app_name}.h:
set(ulp_exp_dep_srcs "lp_i2c_main.c")

#
# 4. Call function to build ULP binary and embed in project using the argument
#    values above.
ulp_embed_binary(${ulp_app_name} "${ulp_lp_core_sources}" "${ulp_exp_dep_srcs}")

# ulp_add_project("ulp_build_system_example" "${CMAKE_SOURCE_DIR}/main/lp_core/")

Why do I still get a lot of errors when executing esp_timer even though I've requisitioned it in CMakeLists.txt of sth32pf80, and why do I get a lot of errors when executing it?
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: CMakeFiles/lp_core_main.dir/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c.obj: in function `delay_ms':
/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:153:(.text.delay_ms+0x10): undefined reference to `esp_timer_get_time'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: /Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:164:(.text.delay_ms+0x30): undefined reference to `esp_timer_get_time'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: /Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:159:(.text.delay_ms+0x50): undefined reference to `esp_timer_get_time'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: CMakeFiles/lp_core_main.dir/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c.obj: in function `sths34pf80_set_odr':
/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:128:(.text.sths34pf80_set_odr+0x8): undefined reference to `esp_log_timestamp'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: /Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:129:(.text.sths34pf80_set_odr+0x28): undefined reference to `esp_log_write'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: CMakeFiles/lp_core_main.dir/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c.obj: in function `sths34pf80_init':
/Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:80:(.text.sths34pf80_init+0x54): undefined reference to `esp_log_timestamp'
/Users/tinyu/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/13.2.0/../../../../riscv32-esp-elf/bin/ld: /Users/tinyu/Developer/Develop/OneBtn/OneBtn_IDF/main/lp_core/lpsths34pf80/sths34pf80.c:81:(.text.sths34pf80_init+0x74): undefined reference to `esp_log_write'
collect2: error: ld returned 1 exit status

Is it like the ulp core where you can't use the normal i2c driver but have to use lp_i2c using esp_log, esp_timer....?

I solved the problem with ulp_lp_core_delay_us alternative esp_timer_get_time and lp_core_printf substitution ESP_LOGX, but where should I find support for ULP cores in the official ESP components, I don't see it in the documentation.

Hi @Tinyu-Zhao,
you can find all the information concerning the API under "API Reference" > "System API". Then depending on your target you will Have a dedicated ULP section:

"ULP Coprocesseur Programming" e.g., on esp32
"ULP LP-Core Coprocesseur programming" e.g., on esp32c6

At the end of the section you will find the subsection "API Reference" like on esp32c6 for example, where all the API functions are described.

Hi @Tinyu-Zhao, you can find all the information concerning the API under "API Reference" > "System API". Then depending on your target you will Have a dedicated ULP section:

"ULP Coprocesseur Programming" e.g., on esp32
"ULP LP-Core Coprocesseur programming" e.g., on esp32c6

At the end of the section you will find the subsection "API Reference" like on esp32c6 for example, where all the API functions are described.
There you should find all supported features on the ULP core.您应该可以在此处找到 ULP 内核上支持的所有功能。

Thank you for your reply.


Object areEqual datetime fix

when comparing objects, if the both objects had a property with the same name that was a date it was incorrectly saying they where equal if the date values where not the same.
added test and fix.

:shipit:


No arm64-v8a .so file

android phone cpu 64 will crash.

it's an issue of openCV library try to update it.

Generated native library files for all architectures.


Handling 180/-180 overlap

Hi!
We've found out that you ClusterManager removes all the markers from the map when camera bounds include 180'th meridian, coz this situation is not properly handled. You can reproduce it by adding points around 180/-180 to your MapActivity::onMapReady
        clusterItems.add(new SampleClusterItem(new LatLng(1, 179)));
        clusterItems.add(new SampleClusterItem(new LatLng(2, -179)));

I've added naive WO.

Thanks for your contribution, I will check this when I have time.

I'm going to close this PR, since I implemented a fix in the other commit: 64d274daa934cd89deb567495e27a6f73242df21. Anyway, thanks a lot for your help.


Return h.continue instead of response

Returning a response object here halt execution of other plugins that may listen to the onPreResponse event.
There is no reason i18n should prevent other plugins from logging 404 or other errors.
I ran into this problem when updating a project from HAPI v16. I worked around it by loading the plugin which listens to 404 errors before hapi-i18n but this PR should fix such problems.

Hi David,
Thanks for your contribution.. Is it possible to add a test case that reproduces that issue? I will merge to master and update the npm module then.
Cheers, Kay

I added test and published new release :+1:


Publish on Google Play Store

Installing apps from the Google Play Store currently provides the most robust chain of trust on stock Android systems as well as GrapheneOS. Installing AppVerifier from there would be more secure and convenient than the currently recommended options for basically all platforms of interest.
Accrescent is currently recommended as the most secure way to install AppVerifier. However, the process of verifying one's Accrescent installation in the first place is basically equivalent to the one outlined for AppVerifier anyway. I believe the recommendation should be the other way around: Install AppVerifier securely (from Google Play Store or manually), then use it to verify Accrescent and your other apps.

I don't think I want to make AppVerifier available on the Google Play Store mostly because of the Play App signing requirement for new apps. This means that the AppVerifier on the Google Play Store would NOT be signed by me and instead be signed by Google.

I'd do that but the registration is too annoying

Are there specific concerns you have with the Play App Signing requirements? From a user's perspective, I can only think of a couple:

The same app being available with different signatures can cause conflicts.

Solution: Use a different app ID for the Play Store variant.

Google has the power to push a malicious update to people or an individual.

This is not a realistic concern for basically anybody. Perhaps a disclaimer could be placed in the app description for those who might be impacted by this.

I think the benefits of obtaining AppVerifier from the Play Store are significant, and outweigh the downsides of Play App Signing.

If Play App signing was optional, I would be fine. My issue is that it is not optional so I must use it. They let you use your own signing key before.

Right, I'm aware of that. I struggle to see what's undesirable about that compared to the significant benefit. AppVerifier in particular when installed from the Play Store would extend that robust chain of trust to all apps, including Accrescent. No apk would need to be manually verified on a separate PC with apksigner again.


Proposal: use "enhanced enums" in the repo for reduced boilerplate

There are a few situations where the same enum logic is implemented over and over again.

A good example would be distinguishing an AnimationStatus between forward/complete and reverse/dismissed.
 15 style guide violations (click to collapse)
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/material/backdrop_demo.dart#L281
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/shrine/backdrop.dart#L235
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/shrine/expanding_bottom_sheet.dart#L236
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/gallery/backdrop.dart#L260
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/pages/splash.dart#L71-L72
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/reply/adaptive_nav.dart#L525-L526
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/app.dart#L122-L123
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/backdrop.dart#L214-L215
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/expanding_bottom_sheet.dart#L343-L344
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/navigation_bar.dart#L1309-L1310
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/navigation_drawer.dart#L691
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/scaffold.dart#L610-L611
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/scaffold.dart#L3206-L3207
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/widgets/animated_cross_fade.dart#L320-L321
https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/widgets/routes.dart#L1939-L1940

Rather than refactoring all of these into switch expressions, I think it'd be best to take advantage of enhanced enum features and improve AnimationStatus directly.

You showed that currently have something like this:
enum AnimationStatus {
  /// The animation is stopped at the beginning.
  dismissed,

  /// The animation is running from beginning to end.
  forward,

  /// The animation is running backwards, from end to beginning.
  reverse,

  /// The animation is stopped at the end.
  completed,
}

final AnimationStatus status = _controller.status;

final bool returnValue = status == AnimationStatus.completed || status == AnimationStatus.forward;

Would you mind to show the proposed cleaner, simpler and more performant preferred new way that reduces the boilerplate?

@FusoraTech I forgot to link to this issue in the pull request I made, my bad!
I was going to wait to refactor until that PR is approved, but I'd be happy to share some ideas now 🙂

animated_cross_fade.dart
before
bool get _isTransitioning => _controller.status == AnimationStatus.forward || _controller.status == AnimationStatus.reverse;

Widget build(BuildContext context) {
  final bool transitioningForwards = _controller.status == AnimationStatus.completed ||
                                     _controller.status == AnimationStatus.forward;

  if (transitioningForwards) {
    // ...
  }
}

transitioningForwards is instantiated only to be used once
style guide violations:

Avoid using == with enum values
Prefer a maximum line length of 80 characters

after
bool get _isTransitioning => _controller.moving;

Widget build(BuildContext context) {
  if (_controller.aimedForward) {
    // ...
  }
}

I understand. The idea is to make specialized getters right inside those "smart enums", replacing complex reusable ifs with switches when possible, and reducing the boilerplate replacing those long ifs spread everywhere by those new concise getters.

Just to be clear, my worry was about exchanging performance in one place by complexity in another place, and performance penalty adding an extra call layer, just to satisfy a code clarity guidance.


Possible error in ch14_part2.ipynb of GitHub

There is a code  'get_smile = lambda attr: attr[18]' in In[6] cell.
It should be 'get_smile = lambda attr: attr[31]' according to the  'list_attr_celeba' text document in the celeba file.

Wow, big oversight! I have a "correct" smile classifier here (https://github.com/rasbt/deeplearning-models/blob/master/pytorch_ipynb/cnn/cnn-vgg16-celeba.ipynb) and am not sure how that happened. Will fix that. Thanks a lot for pointing that out!

Just updated it via #63. Thanks again!


Error compiling for board esp8266

hi @cotestatnt
I have updated lib to 1.2.4
an error appears when I compile the esp8266 board
D:\Documents\Arduino\libraries\esp-fs-webserver-master\src\esp-fs-webserver.cpp: In member function 'bool FSWebServer::begin(const char*)':
D:\Documents\Arduino\libraries\esp-fs-webserver-master\src\esp-fs-webserver.cpp:125:16: error: 'using WebServerClass = using ESP8266WebServer = class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>' {aka 'class esp8266webserver::ESP8266WebServerTemplate<WiFiServer>'} has no member named 'enableDelay'
  125 |     webserver->enableDelay(false);
      |                ^~~~~~~~~~~

.
.
.
exit status 1
Error compiling for board LOLIN(WEMOS) D1 R2 & mini.

I have also updated the board manager for esp8266, but the error still appears
is there any solution?

The method is defined in the ESP32 WebServer, so the call should be moved inside
#ifdef ESP32
...
#ednif
The default value is true and I don't know why it had to be set to false.
In the default case it just add a delay(1) in the handleClient() method if there is no connected client.

Sorry, i've added the instruction at the wrong line.
New release contains the fix.


Pagination for "show all"

currently client app downloads entire database records and display. Probably needs pagination at somepoint.

Would you like me to create an end-point with pagination parameters...? (implementation for #10)
I could then add a  "load more" button or page numbers to the UI. (implementation for this issue.)

@alexbooker I think keep hitting load more (twitter style) would be nice :)

@kosamari Good morning.
I'll get on this now.

@alexbooker thanks for PR ! just merged the serverside code :)

Awesome :smile:.
I'll get on the front-end part shortly.

Closed by #24 and #32.


Mojo::UserAgent >= 9.07 breaks empty POST and PUT requests

From the Mojo changelog:
9.07  2021-03-11
  - Improved Mojo::UserAgent performance slightly by not including unnecessary "Content-Length: 0" request headers.

This breaks most functions relying on POST or PUT without a payload like start_typing() or create_reaction() because the discord cloudflare endpoint does not like a missing Content-Length:
$VAR1 = '<!DOCTYPE html>
[...]
<title>Error 411 (Length Required)!!1</title>
[...]

411. That's an error.

POST requests require a Content-length header.  Thatâs all we know.
[...]

The Content-Length: 0 header needs to be added back explicitly in Mojo-Discord for empty POST/PUT requests.

Adding the header explicitly doesn't fix the issue :( Seems like Mojo::UserAgent is stripping it out regardless.
On the plus side, sending a single character in the body to get a Content-Length of 1 works and Discord accepts it.
I think the ultimate fix here is for Discord to only require Content-Length when it is >= 1

Not sure if Discord can change the requirement of Content-Length, it is probably a Cloudflare thing. Removing it when explicitly setting it does not sound good either, I'll open a Mojo issue then.

Fixed in https://github.com/mojolicious/mojo/issues/1738 so probably no action needed here, leaving the issue open until a new Mojo release is out and I can confirm that it works again,

Great news. Thanks for doing that!

Fixed (and confirmed) in Mojo::UserAgent 9.12, so the workaround is needed for Mojo::UserAgent versions < 9.12 && >= 9.07. Maybe add a condition to enable the workaround if any of the affected version is used, giving there is an easy way to check the mojo version.

77b97a1ad145cf45599c36ec756c30cb45614fc0 Could be made conditional with something like:
use version;
require Mojolicious;
my $mojobroken;
$mojobroken = 1 if ( $Mojolicious::VERSION >= version->parse( 9.07 ) && $Mojolicious::VERSION < version->parse( 9.11 ) );

I'll probably just put it in the cpanfile to be incompatible with those versions.

I'm going to just leave the workaround in place. Sending a single character doesn't (currently) break Mojo::UserAgent. I can always revisit this if that changes.


Feature request: integrate fakegato-history module

First of all - HUGE thank you for this plugin!!! I successfully connected my dumb aircon wi-fi controller and Oregon BLE weather station to HomeKit using simple bash scripts
This issue is to ask you to please consider integrating support for fakegato-history to be used with temperature/humidity sensors
This module saves a log with temp/humidity values and exposes it to Eve app. The app draws very nice graphs so you can see historical values
https://www.npmjs.com/package/fakegato-history
Thank you again!

Interesting,
I will have a look but cannot promise anything.  My only concern is that
it means my plugin requires another, but if I can figure out how to only
use the fakegato if it is installed, I will try.  If I close this request,
it is not because.I will not do it, it is just to show that there are no
outstanding issues.  This is more of a feature.
ttfn,
John Talbot
On Tue, Mar 19, 2019 at 6:26 AM TimofeyK<EMAIL_ADDRESS>wrote:

First of all - HUGE thank you for this plugin!!! I successfully connected
my dumb aircon wi-fi controller and Oregon BLE weather station to HomeKit
using simple bash scripts
This issue is to ask you to please consider integrating support for
fakegato-history to be used with temperature/humidity sensors
This module saves a log with temp/humidity values and exposes it to Eve
app. The app draws very nice graphs so you can see historical values
https://www.npmjs.com/package/fakegato-history
Thank you again!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AGQRXyBOsQK9bcbtlCIMrJCgmLMthhcPks5vYLthgaJpZM4b7xbQ
.

Thanks John!
Fakegato-history doesn’t not require manual install, it’s installed as a dependency to the Homebridge plugin
I used it as a part of https://github.com/hannseman/homebridge-mi-hygrothermograph and I did not need installing it separately

Thanks for the clarification.  I will see what I can do.  I'm working on my
CNC at the moment and it is so close to be fully calibrated.  This document
is not complete but the video is cool.
http://benicegames.com/CNC/MyCNCBook.pdf
http://www.benicegames.com/CNC/CNCDrawing.mp4
BeNiceGames is my web site for my free IOS apps, I also use it as a place
to put files, instead of attaching them.
ttfn,
John Talbot
On Thu, Mar 21, 2019 at 12:43 AM TimofeyK<EMAIL_ADDRESS>wrote:

Thanks John!
Fakegato-history doesn’t not require manual install, it’s installed as a
dependency to the Homebridge plugin
I used it as a part of
https://github.com/hannseman/homebridge-mi-hygrothermograph and I did not
need installing it separately
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-475111755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX2PMSf-6jipsL8it3bHbXcZSCGREks5vYw3hgaJpZM4b7xbQ
.

I started coding this.  I do not know when it will be done. The API is okay, but incomplete for many devices, I will see what I can do with what is available.
The only thing I do. not like is the note that when using GoogleDrive to store the history on, you can potentially corrupt the data with multiple writes at the same time. This is a red flag in that they do not know how to handle concurrency.
Homebridge-cmd4 handles concurrency for state information by having each devices status placed into a different file.  See files in Cmd4States directory.
So I am working on it.  I will close this but as I previously mentioned, it is not forgotten.  I will also update the logs of this issue as time goes on.
P.S.  I just got some new parts for my CNC, so I will probably start again tomorrow on this.
ttfn,
John Talbot

Just to let you know that I made significant progress on this feature. Everything is coded and testing of a fake thermostat works. FakeGato is not by default part of Homebridge like you mentioned. It is part of Eve. I was able to include it as an option defined in your config.json file if storage of fs is defined for the accessory.
All this still needs to be documented in my ReadMe.  You might have it all in a week.
TTFN,
John

What I meant is that fakegato-history is an npm module that will be automatically installed as a dependency when installing your plugin. Sorry, I did not word it clearly enough!

Hi Tim,
You are right and thank you ever so much for the clarification!  I was

not seeing it this way because I was adding in the functionality and not
installing it as npm would.. I can rip out the part where I check for the
availability of  the fakegatoHistory module and let npm handle it.  This
makes things cleaner and easier for the user to understand.
ttfn,
John Talbot
On Mon, Mar 25, 2019 at 1:03 AM TimofeyK<EMAIL_ADDRESS>wrote:

What I meant is that fakegato-history is an npm module that will be
automatically installed as a dependency when installing your plugin. Sorry,
I did not word it clearly enough!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-476055875,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX9wU-xwgx15nWi-_OG-BWLYdX7vjks5vaFiQgaJpZM4b7xbQ
.

Hi Tim,,
I  just checked everything into GitHub for this feature request you asked for.  I have not made an npm module of it yet. If you could give it a go by copying the index.js to the /usr/local/lib/node_modules/homebridge-cmd4 directory, make the appropriate config.json changes as detailed in the README.md or in the config.json file I include in Extras; It would be much appreciated.
Any feedback you give will be very helpful..
ttfn,
John Talbot

Hi John,
It works partially so far
I loaded the new index.js (had to install fakegato-history and moment npm modules manually) and made changes to config as described
I have 3 temp, 3 humidity, thermostat and fan devices created via cmd4
I've found persist.json flies created for all sensors + thermostat and surprisingly for fan as well
So far Eve app recognised services for temperature/ humidity sensors + thermostat but values for thermostat sensor are all 50deg, for temp/humidity are all null and not changing
Below is the content of persist files
Homebridge_T0_persist.json
{"firstEntry":0,"lastEntry":2,"usedMemory":2,"refTime":575268616,"initialTime":1553575816,"history":["noValue",{"time":1553575816,"setRefTime":1},{"temp":null,"humidity":null,"ppm":null,"time":1553575816}]}
Homebridge_Aircon_persist.json
{"firstEntry":0,"lastEntry":29,"usedMemory":29,"refTime":575268095,"initialTime":1553575295,"history":["noValue",{"time":1553575295,"setRefTime":1},{"time":1553575295,"currentTemp":50,"setTemp":25,"valvePosition":0},{"time":1553575295,"currentTemp":50,"setTemp":25,"valvePosition":0},

I think I know why "null" in temp/humidity sensors log:
     case  "TemperatureSensor":
     {
        this.loggingService.addEntry({time: moment().unix(), temp:**this.temperature**, humidity:**this.humidity**, ppm:this.ppm});
        break;
     }

These characteristics called "currentTemperature" and "currentRelativeHumidity". Thermostat log has "currentTemperature" and shows default value of 50 deg
But both this. currentTemperature  and this. currentRelativeHumidity  aren't set to the actual HK values in the code

Hi Tim,
Thanks so much for trying it out.  You did well debugging to get it
going and I'll look into why it is not changing.
John Talbot
On Tue, Mar 26, 2019 at 7:43 AM TimofeyK<EMAIL_ADDRESS>wrote:

I think I know why "null" in temp/humidity sensors log:
 case  "TemperatureSensor":
 {
    this.loggingService.addEntry({time: moment().unix(), temp:**this.temperature**, humidity:**this.humidity**, ppm:this.ppm});
    break;
 }

These characteristics called "currentTemperature" and
"currentRelativeHumidity". Thermostat log has "currentTemperature" and
shows default value of 50 deg
But both this. currentTemperature and this. currentRelativeHumidity aren't
set to the actual HK values in the code
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-476589936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX4Q29p32jygoLc12hzsQDXHSrCXUks5vagf6gaJpZM4b7xbQ
.

Hi Tim,
homebridge-cmd4 never stored internally the accessories current state. It just returned to the app what was retrieved. fakegato would just write the log of the initial value in the config.json file. This is what you were seeing.
I made the change to Homebridge-cmd4 to update the variables of the state retrieved so that they are correctly written to the fakegato log.
I changed index.js.   I also changed config.json to not poll everything by default.
Let me know what you think when you get time.
John Talbot

Nearly there!

Thermostat sensor started logging temp correctly
Temperature and Humidity logs still had 'null' values. Then I noticed in the code that it still has wrong variable names in the addEntry method, must be a copy-past issue
this.loggingService.addEntry({time: moment().unix(), temp:this.temperature, humidity:this.humidity, ppm:this.ppm});
I changed them to currentTemperature and currentRelativeHumidity and the logging to files started working correctly BUT...
Eve app shows the same values for all 3 different Temperature sensors and same values for all Humidity sensors. I have 3 of each and they are named T0, T1 and T2 + H0, H1 and H2. Eve app shows T0 and H0 for all sensors. Also if I delete stored measurements in the app for one sensor it deletes them for all sensors. Somehow the app shows the same log for all sensors

Correction to the N3 above: Eve app shows measurements for the same sensor for all 3 sensors of the type but it’s not always T0. At some point it started showing values from another sensor

Tim,
Thank again for your great debug work.  I jut got it logging data and
did not investigate further. You have done more than I. Fantastic wok on
your side.
Ill see what else i can find.  I certainly have never tried it with
multiple device of the same type.
TTFN,
John
On Wed, Mar 27, 2019 at 5:41 AM TimofeyK<EMAIL_ADDRESS>wrote:

Correction to the N3 above: Eve app shows measurements for the same sensor
for all 3 sensors of the type but it’s not always T0. At some point it
started showing values from another sensor
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-477064463,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX6aWWBE_ZAfrz57oGAlfIKz0yJIkks5vazzdgaJpZM4b7xbQ
.

Hi Tim,
Fakegato accessory attributes do not map very well. I did the best I could all considering.
I did test multiple accessories with the same type and could not find an issue. The latest changes made just have those you requested, plus some other mapping fixes and documentation.
Let me know if all goes well.
ttfn,
John Talbot

I just remembered something I wanted to tell you.  It is best that you do not put spaces in the accessory names because that can throw off command line parsing.  I do not know if you do this, but just in case.
TTFN,
John

Hi John,
Thanks a lot for all your efforts! Still the same result, unfortunately. I can see that all persist.json files have correct values logged but Eve app still shows the same set of values for all accessories of the same type. Maybe this is fakegato's own issue or even Eve app's bug. And this is, after all, a hack to feed fake data to an official Eve app!
Device names in my config are T0, T1, T2, H0 etc so no spaces
For now I removed fakegato-history from the Platform level and only added for one Temperature and one Humidity sensor. In this config it works correctly
BTW, is there a way to configure CMD4 for a single device with multiple characteristic? All my sensors measure both temperature and humidity but I had to configure them as separate devices

Hey Tim.
So fakegato Thermo has both temperature and humidity, so if you configure
it as a thermostat, you will get both.  FakeGato does not map well to the
Hap spec.
I see as you see the stuff being logged correctly.  I will see what IOS
does with multiple accessories of the same type.  Right now I think it is a
FakeGato thing though.
TTFN,
John
On Wed, Mar 27, 2019 at 9:28 PM TimofeyK<EMAIL_ADDRESS>wrote:

Hi John,
Thanks a lot for all your efforts! Still the same result, unfortunately. I
can see that all persist.json files have correct values logged but Eve app
still shows the same set of values for all accessories of the same type.
Maybe this is fakegato's own issue or even Eve app's bug. And this is,
after all, a hack to feed fake data to an official Eve app!
Device names in my config are T0, T1, T2, H0 etc so no spaces
For now I removed fakegato-history from the Platform level and only added
for one Temperature and one Humidity sensor. In this config it works
correctly
BTW, is there a way to configure CMD4 for a single device with multiple
characteristic? All my sensors measure both temperature and humidity but I
had to configure them as separate devices
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-477408284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX7LGpCFjptxoU961N9JbVgC0g2g1ks5vbBrWgaJpZM4b7xbQ
.

A thermostat does not poll for humidity,but i can change that.
John
On Wed, Mar 27, 2019 at 9:41 PM John Talbot<EMAIL_ADDRESS>wrote:

Hey Tim.
So fakegato Thermo has both temperature and humidity, so if you
configure it as a thermostat, you will get both.  FakeGato does not map
well to the Hap spec.
I see as you see the stuff being logged correctly.  I will see what IOS
does with multiple accessories of the same type.  Right now I think it is a
FakeGato thing though.
TTFN,
John
On Wed, Mar 27, 2019 at 9:28 PM TimofeyK<EMAIL_ADDRESS>wrote:

Hi John,
Thanks a lot for all your efforts! Still the same result, unfortunately.
I can see that all persist.json files have correct values logged but Eve
app still shows the same set of values for all accessories of the same
type. Maybe this is fakegato's own issue or even Eve app's bug. And this
is, after all, a hack to feed fake data to an official Eve app!
Device names in my config are T0, T1, T2, H0 etc so no spaces
For now I removed fakegato-history from the Platform level and only added
for one Temperature and one Humidity sensor. In this config it works
correctly
BTW, is there a way to configure CMD4 for a single device with multiple
characteristic? All my sensors measure both temperature and humidity but I
had to configure them as separate devices
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-477408284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX7LGpCFjptxoU961N9JbVgC0g2g1ks5vbBrWgaJpZM4b7xbQ
.

Sorry, I again didn't explain in full. I have 3 temperature/humidity sensors which I had to configure as 6 separate accessories. This does not make sense to expose them as Thermostats because I will get all CoolingHeating modes etc and mandatory characteristics
What I meant is that native HomeKit devices and also some other Homebridge plugins expose a single device with multiple services such Temperature, Humidity etc.
Example: https://github.com/hannseman/homebridge-mi-hygrothermograph/blob/master/lib/accessory.js - this one exposes one accessory with Temperature, Humidity, Battery and Fakegato-History services
I guess in CMD4 this isn't possible because of its architecture and the fact that you support all kind of devices based on HAP spec

Hi Tim,
This is true if you create custom accessories that have custom
characteristics.  Essentially you can add any characteristic to an
accessory, but Homebridge-cmd4 follows the hap spec which defines only
certain characteristics for each accessory.
I would have to think on how to handle that.  It may not be as easy as a
custom plugin.
TTFN,
John
On Wed, Mar 27, 2019 at 11:04 PM TimofeyK<EMAIL_ADDRESS>wrote:

Sorry, I again didn't explain in full. I have 3 temperature/humidity
sensors which I had to configure as 6 separate accessories. This does not
make sense to expose them as Thermostats because I will get all
CoolingHeating modes etc and mandatory characteristics
What I meant is that native HomeKit devices and also some other Homebridge
plugins expose a single device with multiple services such Temperature,
Humidity etc.
Example:
https://github.com/hannseman/homebridge-mi-hygrothermograph/blob/master/lib/accessory.js

this one exposes one accessory with Temperature, Humidity, Battery and
Fakegato-History services

I guess in CMD4 this isn't possible because of its architecture and the
fact that you support all kind of devices based on HAP spec
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-477428263,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRXwugJY2cf7Uhbkx1IMfSuYzB7Fe5ks5vbDE0gaJpZM4b7xbQ
.

Eureka!
I think I found how to resolve the Eve app mixing up measurements!
I came across this issue which mentions requirement of a unique serial number for devices of the same type: https://github.com/simont77/fakegato-history/issues/60
That makes sense, all my sensor had the same Serial number constructed by the CMD4 code
I changed one line to add accessory name to the serial number to make it unique (and also dropped the space, just in case)
.setCharacteristic(Characteristic.SerialNumber, "Cmd4" + this.config.type + this.config.name);
Configured all 6 sensors again and... it works now! :-)

Hey Tim,
This is great news!  I will implement this.
My fake sensors were running all night and I had measurements in the history logs in Eve this morning.  I had made some other changes and if I do not  need to implement them, that would be good. Are you getting history measurements?   They do not appear immediately and that was one of my concerns. It must be a fakegato thing.
Let me know if yours has history measurements.
ttfn,
John

Hey Tim,
From the code, I guess we could have also added a unique serial number to the config.json file instead.  I don't know if the SerialNumber gets parsed anyway, but I will add it too.
ttfn,
John

no I got that wrong. ignore last message

Everything works beautifully since I changed serial numbers
I had a problem when Eve app would read only one measurement after I reset history files and reinstalled the app but that was likely app’s problem because it started working after I rebooted the phone
I don’t think there is a real need to have a configurable serial number
Initial measurements  appear with a delay, that’s true. I think it takes up to 20 min to start receiving measurements for the first time. Also they don’t update if you’re not on wi-fi I think
For Cmd4 I think it’s good for release as is with only serial number change
Thank you!

Thanks Tim,
I agree with your findings.   I was testing the install process as
dependencies are added with fakegato and moment.  It all checks out so I
will be submitting everything shortly.  Under changes of 2.30 I will be
giving you credit as your help was extremely valuable.
ttfn,
John Talbot
On Fri, Mar 29, 2019 at 5:09 PM TimofeyK<EMAIL_ADDRESS>wrote:

Everything works beautifully since I changed serial numbers
I had a problem when Eve app would read only one measurement after I reset
history files and reinstalled the app but that was likely app’s problem
because it started working after I rebooted the phone
I don’t think there is a real need to have a configurable serial number
Initial measurements appear with a delay, that’s true. I think it takes up
to 20 min to start receiving measurements for the first time. Also they
don’t update if you’re not on wi-fi I think
For Cmd4 I think it’s good for release as is with only serial number change
Thank you!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19#issuecomment-478150526,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQRX1xciWMr9TuocK8k8OVyUS5zvMUVks5vboD_gaJpZM4b7xbQ
.

Hi Tim,
The final changes were checked in and a new npm package released.  Thanks for all your help.
John

Hi Tim,
In branch b_v2.0_dev I've rewritten mostly everything, except the get/set methods so everything in that regard is the same.
I remembered that you had a device with two types of characteristics.  This branch supports the ability to add any characteristic to an accessory.  You may wish to try this on your Homebridge setup.  fakegato is also improved, as is polling and adding in TV ....
Let me know what you think.  I will be away for a few days so I am only able to put it in a branch, though everything looks good.

Thank you John!
I am away myself so will install 2.0 when I am back in 2 weeks

Hi John,
Sorry it took me very long time to finally update to 2.x, I had a new arrival in the family and didn't have time to touch my setup
After updating to the latest build and re-configuring Fakegato I am having a new issue with the history "stuck" on the same value for long period of time then update to the actual value, then stay on that value for long time again
I am sure that values passed to the plugin were correct and changed over time because they stay in a sqlite table from where the plugin reads them
Also I can see actual current values when I open Home app
It looks as if polling wasn't working properly and feed a stale value to fakegato (or fakegato fudging values because nothing returned from the plugin) and values only update when I open Home app and a new value is explicitly read by the plugin
My config for sensors is:
                {                    "type": "TemperatureSensor",
                  "name": "TH0",                   "currentTemperature": 0,
                   "currentRelativeHumidity": 0,                    "polling": [
                       {                            "currentTemperature": 0,
                           "currentRelativeHumidity": 0,                            "interval": 300,
                           "timeout": 3000                        }
                   ],                    "fakegato": {
                       "eve": "room",                        "temp": "currentTemperature",
                       "humidity": "currentRelativeHumidity",                        "storage": "fs"
                   },                    "stateChangeResponseTime": 1,
                   "state_cmd": "bash /home/pi/Cmd4Scripts/oregon.sh"                },
Similarly configured polling works for a thermostat though I don't use fakegato with it
Is there anything wrong in the config above?

Hi Tim,
I'll have a peek later.  I'm sure your config is correct. It looks that
way.
There was tons of redundant code in the first version that we worked on
together, spelling mistakes too.  Now everything is in a table that has
7000+ test cases against it.
I assume that you checked the stored FakeGato history data to see that it
is changing.  I'll look at FakeGato to see if anything they did caused your
issue.
TTFN,
John
On Mon, Jul 15, 2019 at 1:25 AM TimofeyK<EMAIL_ADDRESS>wrote:

Hi John,
Sorry it took me very long time to finally update to 2.x, I had a new
arrival in the family and didn't have time to touch my setup
After updating to the latest build and re-configuring Fakegato I am having
a new issue with the history "stuck" on the same value for long period of
time then update to the actual value, then stay on that value for long time
again
I am sure that values passed to the plugin were correct and changed over
time because they stay in a sqlite table from where the plugin reads them
Also I can see actual current values when I open Home app
It looks as if polling wasn't working properly and feed a stale value to
fakegato (or fakegato fudging values because nothing returned from the
plugin) and values only update when I open Home app and a new value is
explicitly read by the plugin
My config for sensors is:
{ "type": "TemperatureSensor",
"name": "TH0", "currentTemperature": 0,
"currentRelativeHumidity": 0, "polling": [
{ "currentTemperature": 0,
"currentRelativeHumidity": 0, "interval": 300,
"timeout": 3000 }
], "fakegato": {
"eve": "room", "temp": "currentTemperature",
"humidity": "currentRelativeHumidity", "storage": "fs"
}, "stateChangeResponseTime": 1,
"state_cmd": "bash /home/pi/Cmd4Scripts/oregon.sh" },
Similarly configured polling works for a thermostat though I don't use
fakegato with it
Is there anything wrong in the config above?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX2EGLQPGNKYUXBXAVTP7QC3VA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4XULY#issuecomment-511277615,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCXZ7QYULTKUK327IGILP7QC3VANCNFSM4G7PC3IA
.

is  "storagePath":  ".homebridge/FakegatoStorage",
missing from your config.json file?  does HomeBridge-cmd4 say its missing?
ttfn,
John
On Mon, Jul 15, 2019 at 8:09 PM John Talbot<EMAIL_ADDRESS>wrote:

Hi Tim,
I'll have a peek later.  I'm sure your config is correct. It looks that
way.
There was tons of redundant code in the first version that we worked on
together, spelling mistakes too.  Now everything is in a table that has
7000+ test cases against it.
I assume that you checked the stored FakeGato history data to see that
it is changing.  I'll look at FakeGato to see if anything they did caused
your issue.
TTFN,
John
On Mon, Jul 15, 2019 at 1:25 AM TimofeyK<EMAIL_ADDRESS>wrote:

Hi John,
Sorry it took me very long time to finally update to 2.x, I had a new
arrival in the family and didn't have time to touch my setup
After updating to the latest build and re-configuring Fakegato I am
having a new issue with the history "stuck" on the same value for long
period of time then update to the actual value, then stay on that value for
long time again
I am sure that values passed to the plugin were correct and changed over
time because they stay in a sqlite table from where the plugin reads them
Also I can see actual current values when I open Home app
It looks as if polling wasn't working properly and feed a stale value to
fakegato (or fakegato fudging values because nothing returned from the
plugin) and values only update when I open Home app and a new value is
explicitly read by the plugin
My config for sensors is:
{ "type": "TemperatureSensor",
"name": "TH0", "currentTemperature": 0,
"currentRelativeHumidity": 0, "polling": [
{ "currentTemperature": 0,
"currentRelativeHumidity": 0, "interval": 300,
"timeout": 3000 }
], "fakegato": {
"eve": "room", "temp": "currentTemperature",
"humidity": "currentRelativeHumidity", "storage": "fs"
}, "stateChangeResponseTime": 1,
"state_cmd": "bash /home/pi/Cmd4Scripts/oregon.sh" },
Similarly configured polling works for a thermostat though I don't use
fakegato with it
Is there anything wrong in the config above?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX2EGLQPGNKYUXBXAVTP7QC3VA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4XULY#issuecomment-511277615,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCXZ7QYULTKUK327IGILP7QC3VANCNFSM4G7PC3IA
.

storagePath is optional for Fakegato spec, by default .homebridge is used
I found the issue after running debug mode for a while: polling is only called for currentRelativeHumidity so currentTemperature logged with the last known value. Was hard to notice that humidity logged actual values as it’s not changing as noticeable as temperature
Once I removed humidity from configured polling the temperature started getting polled (“Doing poll of index:38 characteristic:CurrentTemperature...” started showing in the log)

Looks like polling only works for only one characteristic

Aaah, my bad! I looked at the example of polling config in the readme and realised I did it wrong! I put both characteristics in the same brackets section
After fixing the config both characteristics showing in the debug log

Hi Tim,
You are correct about the path being optional and the data written to
.homebridge.  I just found that out myself.
I'll check on polling for the one characteristic.  This should not be.
TTFN,
John
On Mon, Jul 15, 2019 at 8:41 PM TimofeyK<EMAIL_ADDRESS>wrote:

Looks like polling only works for only one characteristic
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX7IVJGTLUKRS5MF7K3P7UKKDA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7LF5I#issuecomment-511619829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCX63IOK34JIQADMI6IDP7UKKDANCNFSM4G7PC3IA
.

Hi Tim,
I'm glad you figured it out.
I think one of the other things you used to worry about was that you had
two sensors and the serialNumber had to be unique.  I believe I allowed you
to specify your own Unique serialNumber in your config.json file. If you
don't, I still make it unique the old way.
TTFN,
John
On Mon, Jul 15, 2019 at 8:56 PM John Talbot<EMAIL_ADDRESS>wrote:

Hi Tim,
You are correct about the path being optional and the data written to
.homebridge.  I just found that out myself.
I'll check on polling for the one characteristic.  This should not be.
TTFN,
John
On Mon, Jul 15, 2019 at 8:41 PM TimofeyK<EMAIL_ADDRESS>wrote:

Looks like polling only works for only one characteristic
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX7IVJGTLUKRS5MF7K3P7UKKDA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7LF5I#issuecomment-511619829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCX63IOK34JIQADMI6IDP7UKKDANCNFSM4G7PC3IA
.

hi Tim,
I looked at the code for polling.  it kind of accepts what you did, but
would then only poll the second one defined.  I can either put a warning,
or fix it to accept what you did.  I prefer the warning, what would you
like?
John
On Mon, Jul 15, 2019 at 9:01 PM John Talbot<EMAIL_ADDRESS>wrote:

Hi Tim,
I'm glad you figured it out.
I think one of the other things you used to worry about was that you had
two sensors and the serialNumber had to be unique.  I believe I allowed you
to specify your own Unique serialNumber in your config.json file. If you
don't, I still make it unique the old way.
TTFN,
John
On Mon, Jul 15, 2019 at 8:56 PM John Talbot<EMAIL_ADDRESS>wrote:

Hi Tim,
You are correct about the path being optional and the data written to
.homebridge.  I just found that out myself.
I'll check on polling for the one characteristic.  This should not be.
TTFN,
John
On Mon, Jul 15, 2019 at 8:41 PM TimofeyK<EMAIL_ADDRESS>wrote:

Looks like polling only works for only one characteristic
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX7IVJGTLUKRS5MF7K3P7UKKDA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7LF5I#issuecomment-511619829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCX63IOK34JIQADMI6IDP7UKKDANCNFSM4G7PC3IA
.

Warning should be fine, you can’t possibly cover all potential config errors anyway
Btw, I configured humidity as an extra characteristic of the temperature sensor. This must be weird from HAP point of view I guess and your log says that :) I think the expected configuration is an accessory with two services each having its own characteristics
Anyway, it works fine and even better - humidity is not showing as a separate device but still visible in Eve if I need it
Thank you again!

Hi Tim,
I pushed out 2.2.2 that makes defining two characteristics for each
characteristic polling item an error.  I prefer it as an error, because
most do not look at the logs and I have been enforcing any configuration
problem to be an error so that people know right away there is a problem
and I get less issue reports.
P.S. You will notice that when you restart home bridge, it will tell you
that there is a later version available.  A nice change since last time.
I'm glad you enjoy.
ttfn,
John Talbot
On Mon, Jul 15, 2019 at 9:44 PM TimofeyK<EMAIL_ADDRESS>wrote:

Warning should be fine, you can’t possibly cover all potential config
errors anyway
Btw, I configured humidity as an extra characteristic of the temperature
sensor. This must be weird from HAP point of view I guess and your log says
that :) I think the expected configuration is an accessory with two
services each having its own characteristics
Anyway, it works fine and even better - humidity is not showing as a
separate device but still visible in Eve if I need it
Thank you again!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ztalbot2000/homebridge-cmd4/issues/19?email_source=notifications&email_token=ABSBCX3E3HJSFKT7YUCECFTP7URZPA5CNFSM4G7PC3IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7OAZA#issuecomment-511631460,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABSBCXZDI25NG63JTDZSM3LP7URZPANCNFSM4G7PC3IA
.


GitConfigHelper setGitConfig overwrite existing bug

Q
A

Fixed Tickets
#369

License
MIT

@tmilos I merged your commit on this PR in #377 giving you credit for it. It let me do the 2nd merge on gush as well. About the update on the tests we will do them in a new PR cc @sstok I am trying but not sure if i will have enough time or succeed. If you are good in health and time please be my guess I am on skype now.


‘CV_P3P, CV_EPNP not declared in this  scope'

Hello,
When trying to compile, I get the following errors:
/home/trina2/PoseCNN/lib/synthesize/synthesize.cpp:1340:94: error: ‘CV_EPNP’ was not declared in this
 scope
 cv::solvePnP(points3D, points2D, camMat, cv::Mat(), hyp.pose.first, hyp.pose.second, true, CV_EPNP);

and
e2D(const int*, const float*, const float*, int, int, int, float, float, float, float, float*)’:
/home/trina2/PoseCNN/lib/synthesize/synthesize.cpp:1575:19: error: ‘CV_P3P’ was not declared in this
scope
   int pnpMethod = CV_P3P;

The offending lines are here:

has anyone had similar issues?

It seems the info at this link has solved the problem. In short, replace the variables names with the following:
CV_ITERATIVE = 0,
CV_EPNP = 1,
CV_P3P = 2,
CV_DLS = 3