Am I understanding correctly that there is no confirmed workaround to this?


Just a heads up: Wenn i try to login into the daikin dev are, i receive this message:
image

Further: I´ve registered a new user with different Email Adress. After Login, i got the same message. Seems there´s something broken @Daikin´s Dev area.


@ab-ip

See URL
This is under the Open Gateway Repo. This API provides both the static and dynamic routes; shared between telco finders of operators and aggregators.


@garciasolero

Agreed to drop this method as shown in `#9`. The signed request according to RFC9101 will be a better solution.

Are you referring to any of the following scenarios:
a) federated scenario, route to partner operator or
b) when the telco finder is unable to resolve the source Internet facing IP address?


Same as yesterday. Kicked out after around 12 hours.
Schermafbeelding 2024-03-19 om 08 26 25
Will wait for a couple of days till this issue with the Daikin server is solved; not in the mood the reinstall the integration every thelve hours.
Schermafbeelding 2024-03-19 om 08 30 37


Mine appears to be still working after 12 hours using my FQDN instead of local IP, however this is the second time I've tried it so there isn't any difference from the first time it failed. My assumption is this doesn't make a difference.

I assume Daikin must be doing something at their end manually in batches for it to work for certain people, until they get around to everyone.


I included the ip address but no change. Same issue with FQDN.


2024-03-18 23:01:54.607 DEBUG (MainThread) [custom_components.daikin_onecta.water_heater] Device 'Verwarming AD' hot water tank supports modes ['off', 'heat_pump']
2024-03-18 23:01:54.607 DEBUG (MainThread) [custom_components.daikin_onecta.water_heater] Device 'Verwarming AD' hot water tank current mode 'off'
2024-03-18 23:06:34.213 ERROR (MainThread) [homeassistant.components.shelly] Error fetching AD Verwarming Aan/uit data: Error fetching data: DeviceConnectionError()
2024-03-18 23:16:20.874 WARNING (MainThread) [dsmr_parser.clients.protocol] keep-alive check failed
2024-03-18 23:28:11.205 ERROR (MainThread) [homeassistant.components.shelly] Error fetching AD Verwarming Aan/uit data: Error fetching data: DeviceConnectionError()
2024-03-18 23:31:54.351 DEBUG (MainThread) [custom_components.daikin_onecta.coordinator] Daikin coordinator start _async_update_data.
2024-03-18 23:31:54.737 ERROR (MainThread) [homeassistant.helpers.config_entry_oauth2_flow] Token request for daikin_onecta_emu20gdjdiiuxi_hnfgz69dd failed (invalid_grant): The provided authorization code or refresh token is revoked.

Just some lines around the time the error started.


This all seems somewhat broken on v0.10 on Linux:
* `CALL load_aws_crendentials();` no longer works on `v0.10.0 20b1486d11` for me when `AWS_PROFILE` is set. This is regression from `v0.9.2 3c695d7ba9`. (Although even 0.9.2 is not reliable - see #10.)
* `CREATE SECRET` does not work for me when specifying the profile name - it returns `Success=true` from the call, but I then get a 403 error when the S3 `GET` request is made
* If I set the `AWS_PROFILE` env var and use `CREATE SECRET`, omitting the profile parameter, it fails in the same way (and also if you omit the `CHAIN` parameter too)

I can't make either `CALL load_aws_credentials()` or `CREATE SECRET` work on v0.10. If I run `aws configure export-credentials --profile foo` and manually set the legacy `s3_access_key_id`, `s3_secret_access_key` and `s3_session_token` config variables then everything works properly, so there's nothing wrong with the current SSO session, just the wiring here in DuckDB.


Is there anyone subscribed to this issue which has a Altherma with a hot water tank which doesn't provide a current temperature to HA. Someone reported an issue with such a hot water tank in the past and I added some support for it, but now looking for the integration json so that I can add it to the unit tests I am working on


If this helps? See below but it is clear that the disconnect occurs at the same time.
Schermafbeelding 2024-03-19 om 12 47 03


Update on the 2 instance norm failing tests. When I compile a model with dynamic shape, and then set the shapes at runtime, it works. But when we compile a model with dynamic shape AND set the size of these shapes by a compiler option, the compiler exit with an error. @chentong319 has a similar problem with another program, and he will test his solution (setting the output type to the same as the original type). Once Tong confirms that this work on his case, will do the same on these 2 cases of instance norm.


a) federated scenario, route to partner operator or
b) when the telco finder is unable to resolve the source Internet facing IP address?

I am referring to what the flow would be if an operator received a request from a SIM that does not belong to it, regardless of whether there is an aggregator in front of it or not.


I have a water tank, temperature is reported well. The ability to set the temperature, however, is not available. Hope this can be added so I can manage the heating depending on solar power.


Setting the tank temperature should be possible, can you do it from the onecta app? I can control it here, could be that you have some setting in the device itself preventing it?


I can set the temperature in the ONECTA app. In the HA integration it is not present as a control. Only set points I have are for the room temperature and the leaving water offset temperature.


@XanderNijhuis please open an issue with the integration diagnostics and a debug log so that I can check why it doesn’t work


An update, it's stlll up and running for more than 12 hours. I installed the latest release and did a new autothorisation at the Daikin site. I notice during the registration at Daikin it was adressing to my internal ip/port and not the external exposed interface on my router.
So two changes, but it is still working :-)


@chentong319 thanks for the suggested fix, it worked. PR #2763 implements the change for instance norm cases (added also group norm which needs the same pattern, even if it may not be tested at this time).


Thank you for your initiative, but it seems that there are already tools of this kind available now.


@garciasolero

Federated Architecture-Network Auth Service drawio

For the standalone Open Gateway, currently there is no route from the Internet to reach /authorize endpoint. Only the operator's SIM card can reach the internal /authorise endpoint. Blue dash path.

In the federated model, the Internet facing /authorize endpoint should only accept requests from partner / federated operators' CGNAT Internet IP address. A) We may assess this security posture of whitelisting partner CGNAT IP addresses and block the rest of the traffic. Pink dash path.

During the client onboarding process, the client will provide a redirect_uri.
B) If the /authorize endpoint observed source IP address (from a CGNAT) cannot be resolved in the operator's Telco Finder, the response will be the failure redirect_uri (with a newly defined error code), following OIDC Authorization Code Flow and OAuth 2.0 This is a graceful failure for the client.

What are your thoughts on this?


Token request for daikin_onecta_XXXXXX failed (invalid_grant): The provided authorization code or refresh token is revoked.
400, message='Bad Request', url=URL(' URL

Same here :-(

it is really cheeky of @Daikin-Europe to unleash something like this on the users and simply switch off the old interface.
I paid so much money for my system and nothing works anymore!
The support from Daikin is also just bad, this will definitely be my last system from Daikin.


What old interface? There was no official API util now...
Or do you mean the local-API of the old devices? (and even that was no official AFAIK)


Then just the ability to send HTTP commands to the cloud.

Daikin simply threw a new API onto the market, touted it as great news, allowed far too few requests, made all previously available integrations unusable and now nothing works at all.

And then their support doesn't even work, a disgrace.


So I tried.

Remote URL and incognito.
Local IP.

All breaks after 12h


After the first few days of breaking after 12 hours, mine appears to be finally stable now with 2+ days going strong.
Only thing I did was change it to my FQDN name opposed to the local IP, did not use Incognito mode.

I believe it is something Daikin are fixing on their end in batches, nothing we can do on ourside until then.


I have the same experience. 3 days with 12h bug. Now the connection is stable for more than 36 hours. No special settings, no incognito mode, local IP. For others, the only option is to wait for Daikin to fix users accounts on their end.

Btw: Daikin products have a very good reputation, but this is a big fail. Decision to stop the previous API and not release a functional replacement. I don't understand.


Around the 12 hours bug, I found building an automation that a service called: ´Daikin Onecta: Reload' is available
According to the text provided the action performed by this service is:
 Retrieve new access TokenSet by logging in again to Daikin Cloud.

When is supposed to be used this service? Is it a way to solve the "12 hours" revoked token situation?


"zdaratom" is no longer needed as it has been updated via URL


@thebeline

As I can see on:
Lunarity XL Turbo
This brand new model has a hash.


@jlbutler coming back to the creation of 2 images on ECR when pushing a multiplatform one.

I think there is indeed a bug on ECR, not for the lifecycle as mentioned in the linked comments but rather due to mutability (or lack thereof) of the tags.

In my case, our repositories have `immutable` tags, so when trying to push a multiplatform image to ECR it fails with a `failed commit on ref unexpected status from put ...`. Checking the dockerd debug log I found out that the 2 ` ` images are the culprit as both have the "same tag" so ECR rejects pushing it twice.


probably related to URL even though the linked PR over there says that the issue has been solved. In my case I am using `containerd` for building the multiplatform images not buildx with `docker-container`.


I think it's okay to close this now.

I figured it was still in a broken state because URL had fixed it, but was reverted in URL causing it to be an issue again. URL was intended to reimplement URL and solve the issue again. However, URL which was the origin of this bug was reverted in URL fixing this issue. 😵💫

I still have the PR for adding the `defaultFontSizes` option in URL which I would still appreciate some reviews on 🙂 But I will be closing this issue now.


Adding support as well. Definitely wish there were a way to have the panel and side bar auto close when exiting the data wrangler editor.


hi @PriyadharshiniP

thanks for the repro we can see the issue will be implementing a fix for this in the upcoming preview.


Thanks for looking into this.

1. Additionally, it appears that the following modifications to the `SQLServerPreparedStatement` : by resetting the `batchParam` value to fetch the metadata of first row(0) instead of the last row seems to prevent duplicates from happening in this case.
But not entirely sure of the consequences.
Please have a look as it may help you fix this issue :
image

2. I'm also not clear why, when we re-use the same connection from the pool, a `Could not find prepared statement with handle exception is thrown`. I would really appreciate any clarifications to assist me better comprehend statement pooling.


I just want to state that after maybe the 10th time of re-adding the integration, it is now running for 24 hours. I did not do any incognito window tricks.


Same here. After I reinstalled yesterday, now still up and running. Must have been an Daikin fault.


I believe this is happening cos the cache is messed up. If I clear the preparedStatementHandleCache in resetPooledConnection() then this works. I'm just doing some testing now.


I appreciate you committing the fix.
It appears to prevent duplicates from happening by creating a new prepared statement handler for every usage of same connection from the connection pool. But I don't fully understand this fix.
I am aware that this statement pooling is per-connection and not server-wide.
But the prepared statement handler should be retained for re-using the connection having the same user name and password from pool : SQLServerPooledConnection , is it not ?
If statement caching was implemented and a connection pool was in use, it seems to be a waste in both client and server side and no real performance improvements with statement cache?
Please clarify.


Mine failed again after 12 hours, so I was trying to connect the Faikin ESP32 module with local API, but it seems my Emura 3 has a different S21 connector than the one indicated on the Faikin main page

The connector on my Emura 3 board is clearly smaller with probably 1.5 or 2mm pitch, still 5 way though.

247945450-99f36b85-2d08-4d3e-a90a-7216cb1714fb

Maybe this is not the right thread for it, but I am sure many other users are as desperate as myself trying to get a local API working.


Just jumping in here to get updates. Currently also seeing the 12hr breakage with a 400 Bad Request error. I scanned through the hundreds of comments, but can't see any definitive workaround or solution, but will keep my eye out.
<img width="1061" alt="Screenshot 2024-03-21 at 12 15 48" src=" URL


Maybe a kind of workaround:
I am still using the old integration without any problems (Daikin Residential Controller including Altherma). After one time a 400 error, reinstall the old integration, created an account on the Daikin Developer Portal, and activated the connection there. Since then no problem anymore so far.


Daikin drives me nuts :) Can you help to see if I'm wrong? I'm using the credentials from this page: URL

Or is there a way to generate a more permanent set of credentials?

API Credentials

To access the ONECTA Cloud API and ensure secure authorization, you'll need to create an application through this developer portal. While the functionality to request credentials for your application is not yet available, we are actively working on enhancing our developer portal to accommodate this feature of self-service in the near future. Self-service will allow you to create an application with a name, description and redirect URI you can specify yourself.

To provide you with a temporary solution, you can utilize the following credentials for authorization:

clientId: "xx"
clientSecret: "xxx"

Copy
These credentials require the use of onectaintegration://callback/ as redirect URI in the authorization flow.

⚠Please Note: These temporary credentials will have a limited lifespan and are expected to be deprecated by Spring 2024. The deprecation will occur once we introduce the creation of applications through the developer portal, allowing every developer to register their own application and obtain their own credentials. A specific date for revocation of the temporary credentials will be shared later.


I removed the integration as I did several times before. But now I can't add it anymore.

I have the screen to enter the Daikin API codes all going good. But when I link it to my account I have only this screen.

Schermafbeelding 2024-03-22 120123

Normally that should be the screen where I can see my Daikin units and add them to the correct room. But now it's empty.

Tried it again but always the same.
I removed the integration completely but no change. Also I do not get the screen anymore where I need to add the API codes, it's goes straight to the Daikin SSO site.


@Marcel030nl We have to wait on Daikin

@Tazmanian79 Have you removed the old credentials, see for how to see which credentials you have, you can remove them from there


@Marcel030nl that's what we all use. After 12 hours, it expires, delete the integration and re-add. Repeat until it suddenly goes longer than 12 hours.


Thank you so much for the quick replies. And I'm on your team then @Gollam, the every 12h delete and re-add the integration.. :D :D


@jwillemsen yes that did the trick. Thanks for you help and i'm good again for 12h :-)


Although ESPALtherma can do much better (this is the other HP):

Schermafbeelding 2024-03-22 om 14 19 26


Update. Mine now just works. Didn't do anything new, Just readded it. Now it didn't break. Added it yesterday evening. It's on 16+ hours atm.


Still working here for some days now. The only thing I changed was after the sw update to specify the external HA port which should be accessable by Daikin. I'm reading that some people are using the internal IP address but this is causing the issues (I think)


Statement pooling is per connection, yes, but sp_reset_connection (resetPooledConnection) clears any prepared statements in the session on the server (among many other cleanup tasks). That's why you see the _Could not find prepared statement with handle_ error. Clearing the cache would keep the driver from re-using invalid prepared statement handles. But I'd be worried that the driver is executing some of the batch or consuming/flushing results on the wrong side of the pool use boundary. ExecuteBatch() should be executing and consuming all the results from the server immediately and I wonder if it's leaving some hanging until the next statement execution (which is happening after the connection goes back into and then comes out of the pool again).


Expired here 2 times already, no improvement.

I have written an email to Daikin, no reply, really unbelievable.


The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity, `lifecycle/stale` is applied
- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed

You can:
- Mark this issue as fresh with `/remove-lifecycle stale`
- Close this issue with `/close`
- Offer to help out with [Issue Triage][1]

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[1]: URL


I don't know, but mine configuration/setup is still woking. Ones I notices it was at the Daikin site refering to an internal link (home network) and I changed that to the external network (via https), it is running for many days.


Must have to do with the id and secret being shared as temp fix; there may be a limit the number of requests from different IP addresses that the server can handle. Mine is up and running voor 50 hours now after several reinstalls.


I was not so lucky, had to remove and add it again to get it working. I'm almost at the point to automate it.. Do we have a contact at Daikin which we can reach out to?


Of course they are. They got us locked in, they got our data. That was the goal. If they cared, a local api would have been made available. Fucking cloud shit. It's MY data, MY electricity, MY control. So why do I need THEIR servers


Eh? They always had the data. It got sent to their cloud regardless of the local API being available.

This isn't nefarious, it's just incompetence.


Thank you for submitting your proposal to the 2024 QGIS Grant Programme. The 2 week discussion period starts today. At the end of the discussion, the proposal author has to provide a 3-line pitch of their proposal for the voter information material. (For an example from last year check URL


old [Daikin Residential for Altherma 3] started working again, and this one new [Daikin Onecta] gets rejected on every 12h. If you reload, it will work for another 12hours.
daikin temporary enabled old api, while this new one are not stable?


This shouldn't even be a discussion. If you enabled -Werror you are asking for early fatal breakage. And that's what you get. We should not entertain the idea that -Werror need to be considered when deprecating. The whole point is to warn people for upcoming changes. If you run with -Werror you get the warning as fatal error early. Not a bit later when it fatally breaks. Deprecations allow you to also get some more context as to why. And you can often specifically opt out of a specific warning at the module level if you so need to.


I totally agree, raising an issue is still hard for non english and non tech users.
Being able to push issues from QGIS, and being able to keep the context is interesting too.

I've done this in a corporate environnement, where users could just push a simple issue descriptions, and we kept a screenshot and all technical context under the hood.

However, I feel like this can be something not totally sustainable. Here is why :

- In my organization, this tool was not used much, even with a lot of training and human proximity. I'm not sure users afraid by Github are real contributors (speaking population wide)
- We create a hard dependency on Github API, which we don't manage. If it changes, QGIS feature will stop working.
- Users have to create a token, but they expire at least yearly. How to help them renew them?
- We will have more issues, which is good, but maybe harder to triage and manage. And we will have more non english issues, reducing the pool of possible triagers.
- We don't educate users to go themselves learn GitHub, so the load of adaptating to Github's changes will be on our shoulders.
- Our **current limiting factor is our ability to triage them**. Increasing the input flow as we havent' adressed the **growing 4K opened issues ** problem, might be some bad gift to our already overwhelmed triager's team.
- We currently have 500K QGIS opening's a day. Polling he API for answers, similar issues etc, will probably lead to 5 - 30 API call per day. Everything with the same QGIS user agent. I'm afraid GitHub will start to at least identify us, and maybe block us. Which would lead to a broken core feature without any way to fix. That can be dealt by discussion with them.

I feel like the really issue is that Github is non-english unfriendly. In beta version, translation of comments is on its way. UI not yet
 URL

It is already possible to auto translate interface, but it is ugly :
 URL

I'm don't think we can solve this by making a proxy of github on our side, this is too big to maintain in the long run.

And last point, when rewriting QGIS' website, PSC decided to **not** translate it. The workload for translator teams is too high and we bet that AI translation tools are solving the issue for us.
I know this will be an issue in France, but this has a massive cost, and we are at a point of history of having partial translations deserve the project.

However, pivoting this proposal to a generic plugin that organizations could parameterize to their internal git forge would be excellent, I dream of it. Then the GIS admin can extract its critical issues to QGIS upstream (and hopefully fund fixes) .


😂😂

Unbelievable, what an indictment and then not even communicated.


Same issue still happening today

Logger: homeassistant.helpers.config_entry_oauth2_flow
Source: helpers/config_entry_oauth2_flow.py:211
First occurred: 6:09:36 PM (3 occurrences)
Last logged: 6:09:49 PM

Token request for daikin_onecta_emu20 failed (invalid_grant): The provided authorization code or refresh token is revoked.

It's also not clear how to force regenerate the token, the UI doesn't provide any way to delete / recreate it.
I am using version 4.0.21 (updated today) using all latest HA (no new update for today).

Core 2024.3.3
Supervisor 2024.03.0
Operating System 12.1
Frontend 20240307.0


known problem, just wait while daikin will make its own homework


To force regenerate, you have to remove the integration, including the access credentials, then re-add everything.


It's great to see such a successful and confidence-inspiring launch of the new APIs and developer portal from Daikin. Good job guys! 🤦♂


I also have concerns about this leading to more non-English bug reports.

I just don't think we have the people power available to manage these effectively and ensure that the relevant information is accessible to developers with the ability to actually fix the bugs.

I don't know if it's just an idea in the mockup, but I'm also strongly against collecting the social handles of the users (ie the linked in / twitter details). I can't see any reason we'd want this or in which it would be valuable for us. (More broadly, I'm extremely against **any** sign of "official" QGIS endorsement/support to Twitter in any way, given the disgusting cesspool of intolerance and extremism that it's become under Musk's guidance).

Lastly, if the user has to sign up to Github and then go through the hassle of creating a token themselves, that seems to me to be much more complex then just signing up to Github and filing the issue directly :laughing: . I realise it alleviates non-English use of Github, but creating a token is a scary/complex process for anyone completely new to Github regardless of how nicely we wrap it up in a wizard on QGIS' side... Maybe there's ways to avoid the user requiring their own key, eg through some custom service hosted on QGIS infrastructure which handles the actual GitHub API portion and issue filing using an internal hidden QGIS token?


Same here. Through reverse proxy and my WAN domain name. About 12hours up then it is a broken token. I'm not exposing my internal port for Daikin like someone says here to fix. NO WAY.
Never EVER i buy a DAIKIN thing in my house again. This is the 3rd time for my Daikin changing control over the AC. From local IP control to residential to this. I have a other Chinese Tuya connected AC. Only 1 time it needed a hard reset in 4 years and i can local connect it if i want.
Interesting note i saw in HA logs was that my token was all lower case when i got an error. Can it be something that HA/daikin_onecta changing upper case to lower case?


I think what sparked this thread is that these types of discussions are constantly coming up. So the question is if we as a CLC should encode common singular principles we all agree on in a document, so that contributors know what they're getting into and we can just link to the document whenever it comes up again.

Such a document wouldn't really be set in stone and could as well be discarded by a future CLC.

But I believe it makes things a bit easier.

This is far less ambitious than coming up with a "stability policy". I see this really about avoiding repetitive discussions.


Thanks for clarifying that the statement pooling is per connection and cannot be shared even when the connection is used , goes back and is re-used from pool.
It appears that the un prepare call is not being initiated explicitly, and presumably, there can still be a performance improvement if statement pooling and pooling are enabled.

With the fix under this issue, it seems to have fixed the corrupt client side prepared statement cache by clearing it when the connection gets re-used from the pool.
But I am still not sure, if there can be some duplicates or entries from a batch mistakenly inserted due to any other scenarios where there is a corrupt prepared statement cache or no server prepared handle with a retry. I cannot replicate such a scenario yet with 8179 and 586 exceptions. However it is in the exception handling, I think it may be possible.
The row in batchParam ought to have also been reset to the index of numBatchesPrepared rather than the last row if the retryBasedOnFailedReuseOfCachedHandle method returns true, right? I'm saying that there may still be instances where this exception stack trace occurs, and that the batch should be correctly retried.
Please advise.
image


Maybe someone where the token renew fails and who has some python experience can patch helpers/config_entry_oauth2_flow.py:211 locally and add some logging of the access and refresh token before and after just to validate that HA doesn't change the token. All oauth2 support is generic HA support, nothing special in the daikin_onecta integration


Seems not to be fixed recently - I get the same errors randomly after some time since switching from 12.4.2.jre8 to 12.6.1.jre8

com.microsoft.sqlserver.jdbc.SQLServerException: Could not find prepared statement with handle 1.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:261)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1752)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:675)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:594)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7739)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:4384)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:293)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:263)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(SQLServerPreparedStatement.java:509)


Daikin is aware of reports regarding refresh token expiration after 12 hours, impacting 3rd party integrations. Some users may encounter a "400 Bad Request" response when refreshing their access token. We're actively investigating with our IT department for a solution. Stay updated on URL

We appreciate your patience as we work to ensure the ONECTA API meets user expectations. Thank you for your understanding.


I suspect that at least in some cases the 12 hour bug is related to the rate limit. Currently I have it working without stop for 4 days.
 I did two things:
Reduce the high rate polling to 20 minute Reduce the low rate to 60 minutes
Include in the dashboard the sensor: "sensor.your_device_name_ratelimit_remaing_day"

I obtained from HA above sensor graphic :
call remaining

You may see that during the day, every day the "remaining call available is decreasing" with the 20 minutes set up ¡3 CALLS PER HOUR! during the night I recover remaining calls expending just 1 call per hour.

I realized that on top of this is neccesary to add the daily calls for each request to start and stop the units. (6 calls per day in theory).

My needs for "call requests" are limited and repetitive currently for testing purposes. I only have an automated start and stop per day for two units.

The graphic above does not show fully repetitive pattern for every day despite I do the same things everyday. It seems that something beyond 24 hours is part of the calculation. I tried to understand better how is supposed to work and I found in the DAIKIN ONECTA Cloud API documentation> "GENERAL API GUIDELINES" (available in the DAIKIN developper cloud repository). A reference to the rules used as referenced in:
 URL
These rules talk about "Dynamic limits and throttling the rates" which I am afraid Daikin is using and makes difficult to predict how this simple rule of "200 calls per day" is going to behave in each particular case.

Btw I suspect that simply opening ONECTA with the phone adds also 1 call.

It will be helpful to have more information from DAIKIN on how this seemingly simple rule is actually applied.


Regression from:
* URL

Unsure if this *caused* it or just exposed an existing issue that didn't fire without this

CC @ajreckof @KoBeWi


nice, maybe you found out what rate limit are on old api? (which can't be changeable)
strange why daikin not mention this in docs, and, instead, register this as a issue


The polling rate may be managed if you "open" in HA the DAIKIN integration and once is opened "click" on "configuration"


@Daikin-Europe the rate limit is really terrible and far too small.

I have 3 devices and can't even begin to get by with the permitted calls!
I don't understand why they only allow such a small limit, it simply can't be true!


@bugac
I suspect that the old api did not have a rate limit, but I do not have solid information about it


I have the 400 Bad request issue as well.
Any fixes in the meantime besides removing and adding again? Because I have 6 devices and integrated in a multitude of locations and automations - I'd rather avoid having to configure everything again and again.


At a glance I suspect the issue is that the change in timing means the scene editor adds a preview environment or similar incorrectly and then doesn't restore it, could be related to incorrectly not checking ownership as well


You don't need to play the project. Just save the instance scene and go back to the parent scene. This causes reloading the scene (to update the instance) and leads to the mentioned bug.

After enough repeats, I got the editor to freeze while spamming `Object was deleted while awaiting a callback.` in the console.


To add to that, the rate limit is insensible from a business standpoint.

Why offer an API, when people can't use it in a sensible way that in turn generated valuable data?

If @Daikin-Europe wanted to learn from the API access patterns how their devices are used, then they need to allow the users to use the API in the way they want. In short: The business goals of providing a free API are severely undermined by the incredibly low rate limit.

As it is right now, no real benefit is created. @Daikin-Europe has an API that costs them money to run but they do not get valuable user data back because the rate limit is was to low to expose interesting patterns.

I do not understand what the motive is here or it the rate limit was a misinformed decision to reduce power usage in which case this whole API makes absolutely zero sense.

Imho, the rate limit should at least enable getting sensor information of all devices every minute (24*60 = 1440 calls/day) and some more requests for changing settings on the devices. That would make sense, would make everybody happy and not significantly increase costs majorly. After all, how many people will actively integrate the API themselves and not access their DAIKIN Devices through the app? The costs generated by external API accesses even with significantly higher rate limits should not influence operating costs that significantly.

---

I do not endorse data collection through the API but that is the only sensible business motive I can come up with. So that's what I base my thoughts on.


100%

@Daikin-Europe do your job and finally open the api for more requests, at the moment it is useless


I suspect it's an attempt by Daikin to reduce their server overheads, and to avoid any risk of DDoS. However, it seems like they've just picked an arbitrary number, without considering a) whether that's even useful to end-users, b) whether it should be per device/serial number and c) whether it should be counted separately from their own application software limits.

My hunch (and hope) is that some people in Daikin are sitting in a room with their software dev team right now, and hopefully reconsidering their course of action. A much more sensible approach would be:

- Rate-limit per period (e.g., no more than 10 calls per second, to avoid DDoS
- Rate-limit per device serial number (so that people who've bought multiple devices can use the API for all of them without needing register each against a different account
- Rate-limit their own app (over which they have control) to a separate limit
- Provide useful diagnostics from the API call - e.g., a 'Too Many requests' response with data on when more requests will be allowed, instead of this poor 400 Bad Request.


In my own project (not the MRP) it duplicates several nodes as seen here (check the Time label is the only one without @ in the name but it was also duplicated).
image


Well the crash seems specific to your scene. The bug is that nodes get duplicated, but depending on nodes, the end result might be different.


It's due to an incorrect deletion sequence in the PR, writing a fix right now:
 URL


Indeed, this should go from last to first.

But this approach feels hacky in the first place, maybe we could add a bool to `replace_by` to not copy child nodes?


No stupid people work at Daikin, they understand everything.
By the way, as you have probably read, it was written that in the future it will be possible to create as many APIs as needed. So each of your devices will have its own API and its own limits.
Now it just takes time for daikin to find the optimal solution. And that can take time.
it's just weird to me, is to release a temporary API that can't work normally, temp solutions must work to its limits, without limits, to test it properly. it's just homework not done. This is not a serious step for a company like Daikin


You cannot create multiple APIs because that is per-definition not possible. You may however, and that is what I think you are referring to, create multiple applications that access that API with distinct rate limits.

However, that is not the solution to the issue because **one application is meant for one service (like HA)** accessing all devices. That is how their architecture is laid out (and what is the industry standard for the described application system). For example, the `/gateway-devices` endpoint would make absolutelty no sense if each device had a single application assigned to it because then it would always return just one device.

You would have multiple applications if completely different services, for example HomeAssistant and your own custom script, access the Daikin servers. Then however I presume, one device may only be connected to one application (this is speculative) because otherwise dodging the rate limits would be super easy.


Yeah, what I was referring to was that you'd have to have something to distinguish each device - it could be any of:
- pass the device ID/serial in the payload
- prefix all the API endpoints with the device identifier
- create a separate secret for each device, so that each request is seen as a different source/dest
- something else.

Anyway, I'm not worried about all this - I'm sure Daikin engineers have considered all these use-cases and haven't structured their API in such a way that calls for one device can't be distinguished from those associated with another. I have no concerns about that, or Daikin prematurely publishing an API that's so unfit-for-purpose that they need to revoke it and reinstate the old one, because somebody elsewhere in the thread confirmed that no stupid people work at Daikin. ;)


Exactly.

I checked across our systems where we deployed 0.24.0 without a WinSW wrapper to test it, and we haven't seen these issues with the service failing to start anymore. Thus this issue is resolved for me, thanks.


Yep, I reproduced with 0.25.1 as well. Here's a copy-paste repro without chocolatey, just using onboard windows stuff:

powershell
# Download windows_exporter 0.25.1
curl.exe -LO " URL

# Install it
cmd.exe /D /C start "" /wait /b msiexec.exe /i "windows_exporter-0.25.1-amd64.msi" /qn

# Confirm windows_exporter service exists
sc.exe queryex windows_exporter

# Remove windows_exporter service
sc.exe stop windows_exporter
sc.exe delete windows_exporter

# Reinstall windows_exporter to repair
cmd.exe /D /C start "" /wait /b msiexec.exe /i "windows_exporter-0.25.1-amd64.msi" /qn

# Confirm windows_exporter service exists
sc.exe queryex windows_exporter

# IT'S NOT THERE

Only way to bring the service back is to completely uninstall windows_exporter, and then reinstall.


hi @smesh

this looks like it might be related to #2356 could you please tell us what your connection string is?


Having the same issue with Kubeflow Pipelines 0.2.5 - if pods created by workflow are deleted, logs cannot be accessed from MinIO artifact store, even if they are archived there. Has anyone actually found a way to make this work ?


Hi @lilgreenbird ,
Connection url is: jdbc:sqlserver:// ;authentication=SqlPassword;DatabaseName= ;trustServerCertificate=true;SelectMethod=cursor


This is still working for me since March 17th, I haven't done any changes since

image


I agree, and mind you I'm addicted to `-Werror -Wall -Wcompat` stuff.


we have another issue relating to this that we are working on, we think it's related to the cache not being cleared. Can you pls try to disable prepared statement handle caching and see if that resolves your issue? if so, that's a temporary workaround for the issue for now.

i.e. add `disableStatementPooling=false;statementPoolingCacheSize=0` to your connection string


About API limits.
yesterday, i moved all limit sliders to the right side (max allowed) and today, after about 12hours, onecta app not responding anymore. Old one still working.
You guys sure about API usage limits?


Wonderful new API, worked for 12h and now everything is broken since 24h.
I know why I installed a heat and power meter on the heatpump to fetch my own data by second!
Why oh why can't we get a local API in addition? For us strange'lingy wanting to poll more often and fast?

PS: If I want to change the token I have to remove and add the integration? Was that serious or some joke?


I am so tired of this shitstorm, so I bought the Faikin ESP32 module, but then had to wait for the EKRS21 cable.
Cable finally arrived today, connected it and... nothing.

I start discussing with the Faikin developer on another thread and it seemed the problem is with my Emura :
- Faikin works perfectly fine if I feed with 5V over USB
- there is simply no voltage between Pin 5 (ground) and Pin 4 of the S21 board, where there should be anything between 12V and 15V
- then I checked in detail the behaviour of my Emura and it does indeed do weird things. It is e.g. not possible to choose anything but Auto Fan mode in Heating mode. In other modes it works.

So I suspect something is broken on my Emura 3 unit and now comes the fun...

Daikin Support refuses to replace the board under warranty (unit was installed 2 months ago) because I opened it up to connect my "own device" on the S21 port. 2 arguments that is BS
1) the problems with the fan modes already occurred when the unit was just installed, but I didn't flag it because I thought it was a Onecta app issue (we never use the remote)
2) if Daikin wouldn't have broken the Cloud API, I would never had to seek my resort to a Faikin... they called this upon themselves.

I am really upset about this total cynism of the Daikin support team. Premium prices, but they refuse to take any responsability whatsoever and try to blame everything on the customer.
It seems they forgot we are actually doing them a favour being the alfa/beta tester of their s***.


I would not put it on Daikin Devs, but probabl on "good'old" product management.
I like the idea that the same API which is hosted in the cloud for dah'lazy people if also available locally. So I am thinking about getting a BRP069A61/2.


@mixphix Don't feel targeted if you're not guilty of this. This sort of principle also applies to submitters and third-party reviewers on the proposals.


OK, so things cooled a bit down here. I still don't have any voltage on Pin 4 of my S21 connector (Emura 3), but I took the 5V from Pin 1 and fed that into the Pin 4 of the Faikin.

Everything seems to work fine and most importantly ALL LOCAL !!! Yippee
- on/off
- changing mode : auto/cool/heat/fan/dry
- changing temp
- changing fan (even silent mode), but still a small bug there, see URL
- lot of settings that the cloud API does not offer are available :
 - Eco
 - Boost
 - Comfort mode (yep !)
 - Streamer (another yep!)
 - Quiet outdoor
 - Sensor mode (no idea what that is)

It's funny to see that any change with this Local Faikin integration is instantaneous and the Onecta app only following like 30-60 seconds later...

Still a bit worried about not having voltage on Pin 4 of the S21. Do I have a defective board or did Daikin somehow change that ? I have to admit it was one of the first Emura 3 delivered...


@BjornHoorelbeke :

But then you did remove it all and installed it again to be able to do so in Incognito mode?
Didn't you loose all your devices and entities and thus all your configuration?


I think I found the root cause of the problem. It is likely that the schema for Argo Workflow status has changed, as the Argo Workflow fields that are retrieved by URL are not anymore where the ts code expects it. The code expects a workflow status with S3 info under the node's output artifacts, but Argo Workflow may have changed since when that code was written and those properties are now under:

status:
 artifactRepositoryRef:
 artifactRepository:
 archiveLogs: true
 s3:


On my side I found out I could control my Daikin with my eMylo device which works with local tuya, it can use infrared to control the indoor unit. Just I wouldn't have the consumption, but anyway I could use another shelly device on my electric board to monitor locally too.

So if Daikin don't open source or make it stable I think I will look into this alternative ( already did it for my old Toshiba AC units), anyway there is no guarantee Daikin will provide the cloud service forever or for the life time of the AC unit.


I also have the same error.
(And know suddenly the old custom integration starts working again)

Is there a possibility to make some kind of repair function? I renamed some entities, so I don't like to keep doing this when reinstalling the integration


@djfanatix I don't have had this issue at all, so I can't test this, but maybe you can try URL I have done some searching and there is some reauth support in HA, but not sure if this is the right way because I can't test it. The access tokens are normally valid for a year so this is a use case other integrations probably ignore.


Just released v4.0.23 which should trigger the reauth config flow again on the access token refresh error. I did a quick hack locally to raise this exception always and at that moment I can reauthorize daikin again, let me know whether this works when you have this 400 error on your system.


Installed latest version. The API was revoked already.
After re-authentication it start working again (without the need of removing and setup the integration again)


Great, that at least simplifies the re-authentication, learned again more from HA than I wanted to learn ;-)


So what I'm hearing you say here is that you're now *the* Home Assistant integration development expert that we can all turn to with our many and varied questions? :) Thanks for all the hard work on sorting this it's really appreciated.


This is my experience too. I just had this 1 minute ago.

Thank you @jwillemsen for all the hard work and patience.


Do you see the original exception also a part of the log? Just curious what HA logs at this moment, just for reference for others


Thanks for your interest and for taking time to write here @haubourg and @nyalldawson.

I think there is some confusion here. To create the issue, no call to the Github API is necessary. It's just a URL with query parameters corresponding to the issue form. Click me to have an issue with prefilled fields.

About adherence to a platform (and a proprietary one!), the risk is not important here:

- issues are so intensively and widely used that Github is unlikely to break things suddenly
- if it happens (probability still > 0), the feedback form won't be the first concern I guess
- similar mechanisms exist in other forges (even in Gitea) so the change would be quite affordable

On the other hand, I find it more questionable that QGIS embeds a hard-coded dependency on the fonts.google.com service (in the fonts downloader), which is certainly handy but also serves as a tracker for the world's leading advertiser.

Is educating users to raise their Github skills a goal or even a mission for the QGIS project? I don't think so. Why not educate developers to learn using QGIS on Windows 11 for a mapping work expected for the next week? Just kidding obviously but in my opinion, this comment is emblematic of a developer's posture and how much the project can be more developer's centric, and we can look at things from another angle: why should a QGIS user learn to use a software forge, which is the developers' software?

Sorry for that, I was in a hurry and wanted to give a graphical view of the idea and, as the dialog's title reveals it, I just quickly modify a form used in QTribu (Geotribu's plugin) where social accounts are used in the publication workflow. So, yes it's definitely just an idea. No worries and sorry for that.


This is getting a bit more tricky since we introduced bundle limit in URL because the `max_extrinsic` weight needs to be smaller than the max bundle weight limit while the bundle limit is calculated from the domain config which is a param of the `instantiate_domain` call and is not a constant value. So different domain instances may need different `max_extrinsic` values, as a result, we may need to store the bundle limit in the domain state either via genesis state (like domain id) or inherent extrinsic (like XDM channel allow list).

Also, in gemini-3h, the bundle limit of domain 0 is now `DomainBundleLimit { max_bundle_size: 357469, max_bundle_weight: Weight { ref_time: 136363636363, proof_size: 1257732550480196701 } }`, meaning the `max_extrinsic` is ~136ms compare to previous 1500ms with domain block weight limit. cc @dariolina


yes we agree there may be other issues there we will take a closer look into this when we can, thanks


I also confirm it works for me with 4.0.23 , lets hope it stay stable like it used to be :)


There's also #2365. Can we have bundle limit in domain config instead of block limit? Especially since domain block limit is not enforced.
So in domain config we would have `target_bundles_per_slot` (1 or less, or more) and `max_bundle_weight`. Then the average domain block weight would be `target_bundles_per_slot * max_bundle_weight/SLOT_PROBABILITY` and each domain should have hardware requirements to be able to achieve that.


Since the last version I'm now over the 12h it's running .. so fingers crossed it keeps on working.


Mine is actually working since the last update. It just popped up once (yesterday morning) to say that my credentials expired, but the new version automatically sent me to the Daikin SSO pag and after going through the acceptation, it just ran fine ever since.

So I am happy although it's a bit (too) late because I just got my Faikin local control working, so I'm using local now.


To make this a concrete proposal:
1. we will add a section in README.md entitled "Seal of Approval" with a brief statement explaining that this is a list of packages which are built using data.table, and what functionality they provide.
2. the approval process is the same as for anything. If you want to list your package under Seal of Approval, submit a PR that changes README.md (add your package to the list). Make sure the change has a link to your package web page, and also a brief description of how data.table is used, and what new/interesting/unique functionality your package provides.
3. The data.table maintainers will judge submissions based on relevance -- does this package provide a new/interesting/unique functionality beyond what is provided by data.table? Also I believe Seal of Approval packages should be outside of data.table scope. A data.table maintainer will merge the PR if there is consensus, just like for any other PR.

For example I have been developing URL which provides named capture regex functionality, using and outputting data.tables, and I would like that package for inclusion under Seal of Approval.

Another example would be the mlr3 packages which are built using data.table.

I see the Seal of Approval as a way of building community, by increasing awareness about how widely-used data.table is among other R packages.


GHC's new stability principles explicitly say that they will not keep warnings stable: URL

(Obviously the CLC can do something different to GHC, but it's a reference point)


I think this will ultimately be a pretty low lift while allowing more public connections to the community.


Referencing a past issue URL

I believe it can be implemented simply as ` URL with a selector in the navbar.


Same issue with me. Just updated to 4.0.23 ...fingers crossed


I'm really excited to hear this news! Should I fork this repository and start translating? Or do you have any better suggestions? I'm eager to start contributing. Perhaps, once Hyprland is more stable, you could consider releasing these documents. @fufexan


I have the same problem. Do we have an update on publishing to a GitHub Folder? ... without having to create a new repo or manually merge a pull request?


glad to see some positive feedback to my proposal.
also would be cool to have some logo with a sea lion giving a thumbs up, does anybody have graphics/art skills? @Maradestefanis ?
My vision is that the README.md should have a one-line mention of the package, with a link to a blog post on URL which gives further details. So that would entail a little extra work for the package author: writing that blog post. (But no extra work for data.table devs, who just review the PR with a change to README.md)


We should check in with Vaxry first, as he was against the previous translation attempt.


I think to enable this I would probably need to do 2 things:

1. Enable saving posts in a subfolder, meaning that rather than saving an entry as `posts/my-entry.md` I would save it as `posts/my-entry/index.md`.
2. For new content, force the user to save the entry before uploading any asset.

The issue with the first point is that this will likely require a lot more work as to retrieve all the entries in a collection I'll need to run an individual query to the GitHub API for each entry as I don't think I can recursively fetch files with the GitHub GraphQL API. To make it manageable, I'll likely need to aggressively cache entries. That's probably more of a 1.0.0 version to be honest.


Light strips dimming can be disabled in FW 6.0.0 which is currently available for _alpha_ testing.
 URL

Michele Moramarco
Prusa Research


Did not work for me. Single HVAC with standard pulling settings. Bind to my WAN url through reverse proxy. Got a HA alert that i need to re authorize (it was new) and it up again (for the next 12 hour...).


@Illauriel and I confirmed a bisect of #89447
Another MRP: node-dupe-bug.zip

Steps to reproduce:
1. Open node3d.tscn.
2. Open the nested scene.
3. Save the nested scene
4. Return to the original node3d.tscn. it will contain duplicate nodes.

I also had a suspicion that an internal node somewhere could cause an issue: I recall from debugging a different issue that the core function `Node::replace_by` may be buggy in the presence of internal nodes (off-by-n error), since it does not properly check indexing, so seeing `replace_by` in the regression PR is setting off that alarm bell as well.

From my notes about replace_by:

All nodes have to be added and moved to the same index, one by one. This might make files with thousands of nodes slow.
Calling replace_by on an internal node will malfunction because it does not preserve the internal_node in the add_child call
I do think there's a core bug in that replace_by is incorrect for internal nodes

I should try and repro + file the bug about replace_by, since it's probably a separate issue, but wanted to bring it up anyway just in case.


I'm having the same issue with auto time adjustment, but I do have the official app installed, what steps do I take to make sure it works properly?


- First make sure the official app is not running. You can shut it down
from the the Android settings -> Applications.

- Test that time settings work manually. Set action "set time" and trigger
it by short-pressing the lower-right button. If that works, the automatic
time setting should work. There is no difference to the app how time
setting was triggered.

- Also, the app should be running when auto time sync takes place. It can
be in the background, but still running. Sometimes, Android will swap it
out of memory. What this means is that if you started the app within a few
hours of auto sync, this should work.

Hope this helps, and let me know if it works for you.

Ivo

On Mon, Apr 1, 2024, 10:21 AM ppsasho ***@***.***> wrote:


I think there should be at least 6 hours from last time set (manually or
automatic) for the automatic action to trigger.

On Mon, Apr 1, 2024, 10:40 AM ppsasho ***@***.***> wrote:


I'm not syncing it on purpose to see if it auto syncs, I'm on a POCO X3 PRO - version MIUI 13. I gave the app all necessary permissions to run in the background, removed it from battery restrictions and also used: IMG_20240401_112331.jpg

 the app lock feature on MIUI that doesn't let it get closed. Also noticed when trying to change the minutes when it will sync it always goes back to 5 minutes when I Re-connect.


So, just to understand, is the auto time adjustment triggered and gets an error, or not triggered at all? If it is triggered, there is something else interfering with the connection, like the official app.

About settings the minutes, there maybe a small input bug, which I'll fix in the next release. After entering the number, touch the field again, to stop the blinking cursor. Then send to watch.


I actually checked my apps and forgot I deleted the official app so I hope interference is not the issue, But in the past when It tried to auto sync I would see the watch trying to pair with the phone, failing and leaving an error on the display for a moment. I'm waiting for the auto time to adjust and see if I get an error this time without the app.


Ok, seems like there is a problem setting the time to adjust value. It worked for me during testing, but not working at the moment. I'll have to investigate further. I plan to have another release around apr. 20th.


I just got a notification, it connected flawlessly, I'm so glad it worked 😁


👍

On Mon, Apr 1, 2024, 12:12 PM ppsasho ***@***.***> wrote:


That doesn't look right according to REST definition of resource.

 URL

A schema is an implementation detail. The "concept" (say "authors") can move schemas and it'll still be the same. Having the schema on the path results in brittle URLs.

This way will also give us the flexibility of doing cross-schema resource embedding if the need arises. Using paths for schemas will overcomplicate the syntax `/schema1/projects?select=schema2/projects`?

---

Besides that `Prefer` is just an improvement over the existing Accept/Content-Profile headers so not a new feature. I don't see why not improve things.

It's the only header we can use without inventing an `X-Something`, which is much more likely to give trouble. If you have an alternative header, I'm all ears..


Hey everyone, thanks for reporting. I will try to set up some SSO config in our CI testing environment to properly test the SSO login method and fix any issues.

Just for clarity here, @herebebeasties Did you also try the create secret syntax as described by @mehd-io?


Is there something new on this issue? It would be really good if this is implemented in next releases.


This still isn't working for me, have deleted and reinstalled but still no joy. Hopefully a fix or work around soon


But others are still having issue with it? or it is just me :(


Check you really are running the latest version. 4.0.23 didn't come up as an automatic update that I was prompted to install. In the end I had to do this to get the latest:

1. HACS
2. Search for Onecta
3. Click 3-dots on the right hand side
4. Choose 'Redownload'
5. Then I was prompted for 4.0.23
6. Redownloaded
7. Restarted HA
8. Got an error on the Onecta integration about auth
9. Re-did the OAuth flow
10. Been working now for 5 days.


Hi

Yes upgraded and it worked for 12 hours or so.

Will try again when home tonight.

Kind regards

Dan Scate

Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: vevs ***@***.***>
Date: 02/04/2024 16:59 (GMT+00:00)
To: jwillemsen/daikin_onecta ***@***.***>
Cc: Majikmonke ***@***.***>, Comment ***@***.***>
Subject: Re: [jwillemsen/daikin_onecta] The provided authorization code or refresh token is revoked. (Issue #41)

still working fine for almost a week. latest version FTW 😅👍

But others are still having issue with it? or it is just me :(

so, did you upgraded?

—
Reply to this email directly, view it on GitHub


Just deleted it all and tried again and we have a connection. Let's hope its still working tomorrow.

Kind regards

Dan Scate

Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: vevs ***@***.***>
Date: 02/04/2024 16:59 (GMT+00:00)
To: jwillemsen/daikin_onecta ***@***.***>
Cc: Majikmonke ***@***.***>, Comment ***@***.***>
Subject: Re: [jwillemsen/daikin_onecta] The provided authorization code or refresh token is revoked. (Issue #41)

still working fine for almost a week. latest version FTW 😅👍

But others are still having issue with it? or it is just me :(

so, did you upgraded?

—
Reply to this email directly, view it on GitHub


Still working for me as well, 1 week now. Does anyone managed to update the devices to 1.30 to see has problem? Trying to update my devices but it fails.


Hey @tdhock I'm stepping in and I can give the logo a shot. It would be great to have it in high definition, if possible. Can you provide that? Also, is there anything else you need from me for the blog?


Hi Mara the existing logo graphics files are in URL is that high enough definition?


From a conceptual point of view (the REST one), those `items` you refer to should be different concepts. The correct db design for that is to have only one parent table `items` then use table inheritance for childs `items_x` and `items_y`. Those would be different endpoints then.

IMO at the relation level. Databases and schemas are boxes of relations. If you rename the table/view then it is a different relation thus a different concept.

Hm, I don't see why. IME besides the different headers that has been working just fine. Simple in interface, implementation and maintenance.

---

We had another discussion about the `Host` header pointing to different databases. Following your URL argument here, should we now use `/db/schema/table`? (Like prest does?) Typing that.. looks inconvenient for users.

Maybe that's the real win we have with the header approach. We're able to provide default schemas/databases for our endpoints and keep them simpler.


I get the idea, although I don't think this would be respected in practice. Name collisions could also happen in homographs too.

---

Since I was working on bulding the OpenAPI spec, I noticed that it's quite difficult to work with the `Accept-Profile` header, since the response, filters and permissions may change when that header is present and the endpoint is the same. Separating it into a different endpoint instead of a header helps a lot in simplifying this. Of course, we shouldn't build our API around OpenAPI, but I think it's good to know that the issue is there.


OpenAPI is a valid point. So in general is harder to provide a static spec with the header approach.

In that case I guess we should also ditch the `Host` idea for mapping an endpoint to another database relation.


Let's move forward with the schema in URL then. Will open a new issue for that.


You must follow the readme and use URL it's only for the first auth.
Regarding cloudflare follow this thread: URL


Failed again after around 12 hours. Error authentication expired


logs that I can see

Logger: homeassistant.helpers.config_entry_oauth2_flow
Source: helpers/config_entry_oauth2_flow.py:211
First occurred: 06:35:44 (1 occurrences)
Last logged: 06:35:44

Token request for daikin_onecta_emu20gdjdiiuxi_hnfgz69dd failed (invalid_grant): The provided authorization code or refresh token is revoked.

This error originated from a custom integration.

Logger: custom_components.daikin_onecta.coordinator
Source: helpers/update_coordinator.py:371
integration: Daikin Onecta (documentation, issues)
First occurred: 06:35:44 (1 occurrences)
Last logged: 06:35:44

Authentication failed while fetching daikin_onecta data: Problem refreshing token: 400, message='Bad Request', url=URL(' URL

Regards

Dan Scate

________________________________
From: vevs ***@***.***>
Sent: 03 April 2024 10:15
To: jwillemsen/daikin_onecta ***@***.***>
Cc: Majikmonke ***@***.***>; Comment ***@***.***>
Subject: Re: [jwillemsen/daikin_onecta] The provided authorization code or refresh token is revoked. (Issue #41)

Failed again after around 12 hours. Error authentication expired

thats new, never seen this error message

—
Reply to this email directly, view it on GitHub


Yes, awesome! I've been trying it out these days

Mara Destefanis
Lic. Comunicación Social. Máster Ciencia de Datos
Tel: (+598) 99041531
Ln: URL
web: URL

El mar, 2 abr 2024 a las 18:01, Toby Dylan Hocking ( ) escribió:


Moving a `GDScript` from one folder to another also reproduced this bug for me.


@zilinfg How is this going? By the conversations it seems like you've done a lot on this. If you don't have time to finish it, please consider pushing what you've got and I could find someone to start from there. It's getting to the point where things are coming together. Thanks.


Hi I just saw pointGroup was done and I'll be making progress on it. I do have time for this and will get it done asap.


It seems that it will appear as long as you save the sub-scene and switch to the main scene.

Nodes will be duplicated only when the nodes meet the following conditions:
1. Is a direct non-internal child node of the main scene root;
2. The node index is an even number.


How would the one maintain the dependencies?
How would you import a module from foo.rs?


Provided a diagram for review NumberVerification issues 93

@garciasolero @jpengar


Could you clarify what you mean by "maintain dependencies"? In general, we expect tooling to manage embedded manifests like regular ones.

As for importing a `foo.rs`, that is broken right now when dependencies are used due to a hack we use to get dependencies working. You would `mod foo;` just like from a `main.rs`. However, that would be discouraged as the point of these is to be single file. If you need to `mod` something, why not have a full package?


"maintain dependencies"
Can I do:

toml
once_cell = { workspace = true, default-features = false }

Can I use `cargo update`?

I would disagree on the limitation of not having the ability to use a module, to be able to externalize some code and import that module makes it much cleaner.


`cargo update` should already work.

`workspace = true` does not work yet because workspace support is out of scope for the initial release.

`cargo add` will be supported on release. Support is waiting on the syntax RFC being approved.

As for `mod`, I did not say it wouldn't be supported. I said it would be discouraged. Its still not clear why you'd use an embedded manifest over `Cargo.toml` if you are using external files. A large point of these is to be single file for easy sharing and there are features we are explicitly not supporting, like `build.rs`.


Given this only affect 6.0 and 7.0 there is limited ROI. Additionally URL covers testing to ensure the tags are consistent. Consider closing as won't fix.


I see almost no discussion around release/optimized mode (except "This is under discussion in the RFC" (above) and merged commit adding "option to generate release mode profile") which I find pretty important, so I want to express my view on this subject:

While manually setting all parameters in the `[profile.dev]` section to be the same as in release mode or just using the "option to generate release mode profile" kinda does that, I don't think this is an optimal solution.

Adding `--release` and `-r` flags looks to me like a much more solid solution to the problem. Or perhaps maybe even add support for arbitrary profiles (using `--profile`), same as for the usual `cargo run`, for maximum flexibility.

This allows users to iterate much faster when developing or experimenting with a script, while not compromising performance when the script is done, and all of this is just by simply adding or removing the `--release` flag to the shebang, unlike the current solution, where you have to manually edit all of the desired flags in "`Cargo.toml` part" of the script.


Afaict the workflow described by @mehd-io works. I will PR this to the docs.

Since `load_aws_credentials` is now deprecated, I did not test that and will not fix that if its broken

I will leave this open until this is properly tested in the aws extension ci


lets move any discussion here to the aws repo and close this one. Check out the reply here: URL for a working workflow with secrets


Yes. It did not work for me - see the bullet points in my above message. What I've put in my above message is accurate.


@herebebeasties

Could you provide a reproducible example for the `CREATE SECRET` flow, describing the exact steps you've taken and the contents of your ~/.aws/config file? otherwise its a bit hard for me to reproduce this


Rather than dividing the conversation, I'd recommend focusing it at URL


I'm not really sure what a "reproducible example" would look like here beyond what I've already described, other than scripting up the creation of a whole AWS environment, S3 bucket, AWS policy, role, policy mapping, Microsoft Azure AD domain creation, SSO setup, etc. which would be pretty complex and time-consuming. Do you have something smaller and more specific in mind?

I'll try to find some time to have a stab at debugging why this is failing in gdb, as tbh it's probably easier to do that than the above.


Well, for example, I ran:

`aws configure sso`

now my `~/.aws/config` looks like

[default]
region=eu-west-1

[profile duckdb-sso-test]
sso_session = ...
sso_account_id = ...
sso_role_name = ...
region = eu-west-1

[sso-session duckdb-sso-test]
sso_start_url = ...
sso_region =...
sso_registration_scopes = ...

Then to login I run:

aws sso login --profile=duckdb-sso-test

Now I get a pop up in my browser to login, which I do.

Then in DuckDB i run:

SQL
CREATE SECRET (
 TYPE s3,
 PROVIDER credential_chain,
 CHAIN 'sso',
 PROFILE 'duckdb-sso-test'
);

And now my auth works fine, and when I query `SELECT secret_string FROM duckdb_secrets()` I get:

name=sso;type=s3;provider=credential_chain;serializable=true;scope=s3://,s3n://,s3a://;endpoint=s3.amazonaws.com;key_id=redacted;region=eu-west-1;secret=redacted;session_token=redacted

Alternatively, If you would give a stab at debugging this, that would be super useful for sure.


That's exactly the same skeleton as my set-up and yet it doesn't work for me. I'll have a look in a debugger.


[Triage] Will use URL to track integrating this logic into the release CLI.


Thanks! Be aware of the fact that I had to rerun the `aws sso login --profile=duckdb-sso-test` after some time. Also, DuckDB stores the raw temporary credentials in the secret, so when the session token expires, the secret is not automatically updated and needs to be manually re-created


Hi @sudomain , I am working on full re-implementation of virtual keys. The new layout follows the same style as Termux. (There are some differences as the use case is different for AVNC).
- 2-row layout similar to Termux
- Meta keys are automatically released on next key press. Long-press to lock meta keys, as described in this particular issue.
- There are three swipable "pages":
 - First two pages contain keys
 - Similar to Termux, third page contains an editbox. It allows you to have full-fledged Android editing experience in a session. When finished, you can send the whole text to server in one go.

First page:
Screenshot_2024-04-04-21-51-23-702_com gaurav avnc debug-edit

Edit box:
Screenshot_2024-04-04-21-52-25-104_com gaurav avnc debug-edit

---

While there are still some rough edges, I would appreciate if you guys can test it.
Test APK: URL

cc @dp-alvarez


Once branch `storage-buffer` is merged, this type of problems (internal SPIRVCross compiler errors) will produce a proper error message. Interestingly I cannot reproduce the problem anymore with your shader though (I just did some small changes for the new separate texture/sampler stuff). Maybe updating the Khronos dependencies helped. Closing this ticket, even though the fix (better error message) isn't in master yet.


I just implemented a fix to communicate the SPIRVCross error message instead of just crashing in branch `storage-buffer`. In case of your example shader the error message isn't very helpful, but better than nothing I guess:

/Users/floh/projects/sokol-tools/test/issue_86.glsl:0:0: error: SPIRVCross exception: Access chains that result in an array can not be flattened

Unfortunately I don't get line information back from SPIRVCross, only an error message. Closing this ticket (even though the fix isn't in the master branch yet).


That was already on my mind, but then the current implementation got slightly more complex. So I decided to get this working for now, and put custom configuration on hold. Maybe someday it will be implemented, but I don't have any immediate plans for it.

That said, is there any key missing from current layout?


@ddfridley Quick question, Is this component responsible for rendering the step footer? Look at other steps I am assuming it doesn't.


The `aud` claim requirements for authorization servers in the FAPI profile are: issuer, token endpoint, or the endpoint URL (as I suggested above). I'm not sure why the client requirements section restricts sending only the issuer (and as a string, not in an array) when authorization servers are expected to accept the other values. In my opinion, I would include the requirements for the authorization server.


The section on clients is a "should", so clients can still use the other allowed values in FAPI 2.0 security.

The current text in #121 is this:

This document defines that for OIDC CIBA the audience MUST be the Backchannel Authentication Endpoint.

In other words, the aud is always the url the request is sent too. Which seems to be a simple rule, which is somewhat more secure than additionally allowing the "issuer" as well.

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | any other endpoint|
| ------------------------------- | ------- |-----------------|------------------------|--------------------|
| /token | Reject | Accept | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject |

Please suggest "better" text if you think that is needed.


Suggested text aligned with what the CIBA standard and the FAPI profile state:

_To facilitate interoperability, the Authorization Server MUST accept its issuer identifier, the token endpoint URL, or the URL of the endpoint at which the assertion was received as values of the audience claim._


Correct. Thanks.

Get BlueMail for Android

On Apr 4, 2024, 10:55 PM, at 10:55 PM, zilinfg ***@***.***> wrote:


@ddfridley Hi, I am a little confused on how to achieve this selected effect.

<img width="527" alt="Screenshot 2024-04-05 at 9 29 39 PM" src=" URL

I am assuming the user can freely select and unselect the points and click create group to proceed with the selected points.

And you mentioned to use pointGroup to render every point in this component. But for the default state in PointGroup, I cannot select and unselect the PointGroup.


You are right. The expedient thing to do here is to use the Point component. The props are a little different, but the result will be the same UI.


Since yesterday i have the same issues. Log says:

Token request for daikin_onecta_emu20gdjdiiuxi_hnfgz69dd failed (invalid_grant): The provided authorization code or refresh token is revoked.

Also the login at Daikin isn't working for me, maybe they are working on something?

 URL does not work, page has errors and doesn't show up correctly

Best,
Jens


@jwillemsen I’m also receiving this error. In the issue in the other repo from where you linked to this one, a user wrote:

‘’’
ONECTA Cloud API: Refresh tokens expire after approximately 12 hours
Investigating
Daikin is aware of reports regarding refresh token expiration after 12 hours, impacting 3rd party integrations. Some users may encounter a "400 Bad Request" response when refreshing their access token. We're actively investigating with our IT department for a solution.

We appreciate your patience as we work to ensure the ONECTA API meets user expectations. Thank you for your understanding.
Posted 7 days ago. Mar 25, 2024 - 10:23 CET
‘’’

Does this mean there’s nothing we can do while waiting for Daikin to resolve the issue?


Sorry for not replying, we could not try workaround in the production.


@AxelNennker @garciasolero

The current text in URL is this:

In other words, the aud is always the url the request is sent too. Which seems to be a simple rule, which is somewhat more secure than additionally allowing the "issuer" as well.

| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | authorize endpoint | any other endpoint | mulitple endpoints |
|--------|--------|--------|--------|--------|--------|--------|
| /token | Reject | Accept | Reject | Reject | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject | Reject | Reject |
| /authorize | Reject | Reject | Reject | Accept | Reject | Reject |

Agree with Axel's statement above. The
aud
 claim should not be an array.

The signed Object Request RFC 9101 is a signed JWT and it is communicated in the public domain over the Internet when performing the Auth Code flow.

The signed JWT maybe used to invoke the /token /bc-authorized endpoints by a bad actor, as mentioned in Cross-JWT Confusion.

The above proposal is leaving the API Consumer to secure the Operator's endpoint. As an Operator, we should secure our endpoints with restrictions.

Another approach is to issue different
client_id
 for the same backend application when performing auth code flow and CIBA flow.

Bank XYZ will use client_id A for auth code flow, client_id B for CIBA flow. client_id A will not be accepted for CIBA flow, client_Id B will not be accepted for auth code flow.


1)
Regarding the following two sections:

@mhfoo Please do not add even more options to the mix.

2) Not sure why write about 9101. Yes, that is also a signed JWT, and there also can be a mixup-attack.
Does your text after "The signed Object Request..." help with the solution if you assume that we assume that more concrete aud values are more secure?

# To summarize this issue's discussion:
Specifying single, specific values for aud depending on the use-case and end point improves security.
Doing that might possibly be bad for interoperability. Even though I am one of the editors of the CIBA standard I do not agree with the interoperability argument. Specifying the correct aud string is simple and I believe that clients are not overburdened with this task. While at the same time, we prevent mixup attacks.

You might challenge the "simple"-argument, but I think the other proposals (key management) are too complicated and implementing the aud-requirement discussed here is indeed simple.

# Some examples for aud value in various implementations:
The example seem to use the endpoint url which agrees existing text.

- URL

- URL

- URL

- URL

- URL


I see there's no quick fix. You are right that the selected vState needs to be implemented in the PointGroup component. Please go ahead and do that as part of this issue, please also add a story to point-group.stories for the new state.


So many years and no change - we are still struggling with this. mklement0 was pretty spot on from the beginning, and it is hard to grasp the perspectives that has been put onto this, attempting to justify inconsistent behavior with user vs developer perspectives. We're not developing to match everyones expectation, but to produce consistent outcomes and predictable behavior.

Imho - whether you are looking at this from a user perspective, or developer perspective, either one wants consistent behavior, independent of the source of the function thei're invoking. By having a requirement for detailed knowledge of the call stack from start to end, to be able to predict the outcome of preferences, does exactly complicate it for users and developers alike, and especially -WhatIf is a problematic preference variable/common parameter, since it can incur devastating consequences, which ultimately can't be predicted in the current state of affairs, if implemented in an advanced module function.

Keep in mind that in module development, we often call other functions in the module, to deal with specific tasks a greater function needs to accomplish, but at the same time the user/another developer may have the option to call those functions directly.

Users and developers alike would expect e.g. -WhatIf to perform as intended, regardless of how deep the function call is in the call stack. It could be catastrophic if we forgot to import preference variables from the callers scope, and even if we do remember it, the inheritance may have been severed by a module function somewhere else in the call stack that didn't do it - which btw. is completely out of our control, and not fixable by an opt-in change. This leaves the WhatIf parameter risky, and thereby imo useless in a module advanced function, as you cannot guarantee its propagation from parent scopes.

Propagating preference variables to descendent scopes should always have been the way, but the proposed option of adding a CmdletBindingAttribute for opting in to this, is however a truly elegant solution, that would solve part of the problem, and it won't even introduce breaking changes. You may even add more attributes, for more granular control - so one may wonder what is wrong with at least giving us this?


**Current decision**: JSpecify-compliant tools must be able to recognize when a method that returns a nullable type overrides a method that returns a non-null type (contravariant return) or one that accepts a non-null parameter overrides one that accepts a nullable parameter (contravariant parameters). Tools are free to report those to users at whatever severity they wish, suppressibly or not. When a compliant tool analyzes calls to such methods, the nullability of the method associated with the static type of the receiver should be applied. This approach preserves the ability of compliant tools to be strict or lenient.

**Argument for changing**: Such overriding methods are incorrect, and like Java, JSpecify should consider them invalid and require tools to report them as such.

However, the current decision preserves the ability of tools to report such overriding methods as strictly incorrect, but it does not prevent tools from interpreting such methods in any case.

**Timing**: This must be decided before version 1.0 of the spec.

**Proposal for 1.0: Finalize the current decision.** If you agree, please add a thumbs-up emoji (👍) to this comment. If you disagree, please add a thumbs-down emoji (👎) to this comment and briefly explain your disagreement. Please only add a thumbs-down if you feel you can make a strong case why this decision will be materially worse for users or tool providers than an alternative.


Got just my first token refresh failed error, but using the Onecta app which I am using for more than 2 years now. The HA integration still runs stable on my systems.


@abelsiqueira Is there a way we can have this generate with code? That way we can put it in the docs without screenshotting it and keep it updated in the future (maybe add it to our PR checklist?)


Thinking like an engineer @clizbe ;-)

We could explore using `Mermaid.js`. It's supported by GitHub. You can experiment @ URL


| Invoking Endpoint \ Audience | issuer | token endpoint | bc-authorize endpoint | authorize endpoint | any other endpoint | mulitple endpoints |
|--------|--------|--------|--------|--------|--------|--------|
| /token | Reject | Accept | Reject | Reject | Reject | Reject |
| /bc-authorize | Reject | Reject | Accept | Reject | Reject | Reject |
| /authorize | Reject | Reject | Reject | Accept | Reject | Reject |

@garciasolero can TEF live with this table? As I said, I thing that using the endpoint url is not obstacle for client developers and provides better security.


Hello!

Your file has items that are not UTF-8 encoded. What is your local character encoding? If Windows is able to read it, that means the file is using your system encoding.


UTF-16.
And the file's title, artist, ... tag are UTF-16 LE encoded.


Hm. It's unfortunate that RIFF doesn't specify a text encoding. We would be able to *somewhat* reliably detect UTF-16 LE, but there's no BOM either. The only way for us to know ahead of time how to decode the text would be using GetACP() from Windows. Don't know how I feel about having platform-specific code in Lofty, though.


In my modules I have found that you can parse the command that called your module load so you can take action on that....
`[System.Management.Automation.Language.Parser]::ParseInput($MyInvocation.Statement, [ref]$ParsedTokens, [ref]$ParsedErrors)`
This will let you parse the import-module command and the parameters. Since you are using your own invocation statement you do not have to validate the module that is loading is yours.

This is a quick sample of how to do it, incase you are like me and need to see code to understand what these words mean. Drop the following code into a module and when you load it use Verbose switch on the import, it should let you know... you can play with it as you see fit. But I was thinking that it should be able to actually implement this in the import command somehow. I wonder if a proxy command would work... you could do it and throw the parameters that you want into a set order for the 'args' array.... or even modify the bound parameters I guess to do it... thats an idea I haven't thought about... I'll go have some fun with that idea this weekend. Anyways, the code:

`[System.Management.Automation.Language.Token[]]$local:ParsedTokens = @()
[System.Management.Automation.Language.ParseError[]]$local:ParsedErrors = @()
[System.Management.Automation.Language.ScriptBlockAst]$local:LastStatementAst = [System.Management.Automation.Language.Parser]::ParseInput($MyInvocation.Statement, [ref]$ParsedTokens, [ref]$ParsedErrors) # statement should only contain the import-module command
[System.Management.Automation.Language.CommandAst]$local:LastImportCommand = @($local:LastStatementAst.Find({$args[0] -is [System.Management.Automation.Language.CommandAst] -and ([System.Management.Automation.Language.CommandAst]$args[0]).GetCommandName() -eq 'Import-Module'}, $false))[0]
[System.Collections.ObjectModel.ReadOnlyCollection[System.Management.Automation.Language.CommandParameterAst]]$local:LastImportParameters = $local:LastImportCommand.CommandElements | Where-Object {$_ -is [System.Management.Automation.Language.CommandParameterAst]}
[System.Management.Automation.Language.ParameterAst]$local:CalledVerboseAst = @($local:LastImportParameters | Where-Object {$_ -is [System.Management.Automation.Language.ParameterAst] -and $_.ParameterName -eq 'Verbose'})[0]
[bool]$Script:IsVerbose = $false # default state
# update the IsVerbose variable based on the value of the 'Verbose' parameter
if (-not $null -eq $local:CalledVerboseAst.Argument) { # means 'Verbose:[Variable | Value]' was used
 try {
 $script:IsVerbose = $local:CalledVerboseAst.Argument.SafeGetValue($true)
 } catch [System.InvalidOperationException] { # the extent is unsafe
 try { # fallback to extract value from string but compare it to a known valid value to determine the state
 $script:IsVerbose = $local:CalledVerboseAst.Argument.Extent.Text.Replace('$','').ToUpper() -eq 'TRUE'
 } catch { # ya, that extent is really unsafe
 $script:IsVerbose = $false # no hope so we just say false
 }
 }
} else { # else only the switch is present, which means true for the value
 $script:IsVerbose = $true
}

Write-Host "Verbose was $(($Script:IsVerbose ? "used with a resolved value of $IsVerbose" : "not used"))"
`
I just wish I could make it cleaner and more compact that it would be not so distracting at the top of a module.


Maybe we can simply set the way to decode text when read riff info. Obviously it is not a good way to fix it though.


@AxelNennker

As I mentioned earlier, we should clearly separate the audiences for these endpoints because they have their own requirements: `token` and `bc-authorize` endpoints deals with client assertions for authentication, while the `authorize` endpoint deals with request objects.

In relation to the audience claim within a client assertion, we suggest what CIBA standard or FAPI profile define: to accept the issuer, the token endpoint and the endpoint URL as valid audiences to ensure interoperability.

CIBA:

FAPI:

Of course, you can simplify the possible values and, for example, accept only the endpoint URL. However, this would affect already deployed solutions that follow the CIBA standard. Therefore, we suggest that the profile should allow authorization servers to accept these three values and recommend using the endpoint URL to clients.

---
Regarding what would happen if we support RFC9101 by passing request objects by value, the standard already specifies what the value of the audience should be:

In relation to your concern about the use of a JWT issued for a request object in authorize flow as a client authentication JWT, the RFC9101 already suggests a way to mitigate this by avoiding the `client_id` as `sub` value within the request object:


@AxelNennker

Does your text after "The signed Object Request..." help with the solution if you assume that we assume that more concrete aud values are more secure?

Regarding the above question, it is related to #128.

The following is the proposed text for PR #121 under OIDC Authorization Code Flow section.

The OIDC Authorization Code Flow is defined in OpenID Connect, incorporating RFC 9101, Passing a Request Object by Value.


@ab-ip

Please consider +1 this Android feature request, which would allow client's mobile applications to get the operator's openid configuration
 URL


tried the solution mentioned by the @pralor-bot and it actually fixes a part of the problem: the PiHole UI is displayed in the iframe now (inside the home assistand GUI).

However loggin in does not work - the login-screen will be displayed over and over again.

Does anyone has a suggestion ?


Toby, Iam working on this graphics a sea lion giving a thumbs up, for now
it is regular and not really nice the result. I will try again and send you
the result in a few days.

I´ll keep pushing forward

Mara Destefanis
Lic. Comunicación Social. Máster Ciencia de Datos
Tel: (+598) 99041531
Ln: URL
web: URL

El mié, 3 abr 2024 a las 6:51, Mara Destefanis ***@***.***>)
escribió:


Your video doesn't work, and please specify what version you are on specifically


Also sounds like:
* URL

From just the description, without the video


I don't know why the video won't play, it's just a simple mp4 video, but it can be played after downloading


Then this problem is solved in the latest version, try building the latest version

If you're still having problems please comment and we can investigate if further


@jdx Shouldn't be possible to use scopes via version suffix as well or was this only intended for configuration files?


This looks inconsistent indeed, will need to dig into this since it works for some and not for others. In the meantime i would have suggested to use the workaround using a `prefix:` scope but it looks that is also not working as expected with #1888.


I am not sure why that check is there. I think maybe I expect that the version was resolved at that point or something so if it was ToolVersionRequest::Prefix in the past it should at this point be resolved to ToolVersionRequest::Version. I would try adding ToolVersionRequest::Prefix and seeing if everything works, if so we can add that to the assertion


Other core plugins like `go`, `node`, `python` don't have this assertion. Adding Prefix to the assertion works, question is if other scopes also would need to be supported and removal of the assertion would make more sense.


Behaviour is consistent in the sense that it uses the "exact" match if found, otherwise falls back to newest available version (fuzzy) matching the provided version. The `@17` version is a shorthand for `openjdk` which behaves a bit differently as you have pointed out.

17 --> openjdk-17.0.2
openjdk-17 --> openjdk-17
sapmachine-17 --> sapmachine-17
liberica-17 --> liberica-17.0.10+13 (no liberica-17 version, so newest 17.x is installed)
oracle-17 --> oracle-17


@AxelNennker +1 vote from my side.
This feature (API) is fine and useful, but unfortunately it won't solve Web use cases (but only App) and coverage issue will stay as well.
Having(knowing) OIDC Auth Endpoints does not mean that user can reach endpoint and be identified at the specific moment.
When we talk about Seamless Auth the crucial part (for Service Providers/App Devs) is to know that it is possible to handle (resolve/identify) specific user.
In order to determinate this possibility it is required to know that user is on Cellular(Mobile) Connection of specific (supported) Carrier. The best and easiest way to do this is definitely by IP address resolution.
You can check how IPification do it for last 4 years with many partners (including 60+ Carriers and 100+ Service Providers)


Thanks for the +1.

I agree that the proposed API does not solve all problems but if Android provides then others might follow.
For the web case we go for universal links and assetlinks.
 URL
 URL
Which enable app-clips and instant apps, and also app-web-credential-sharing.
To get rid of ip2msisdn we have operatorTokens (best thing since sliced bread) defined in GSMA TS.43
 URL

No solution for everything or use case but we are getting there if MNO work together and build an ecosystem for all of us


That would also work. Gonna have to think about this one. For now I'd just recommend changing the encoding of your files to UTF-8, that's what most libraries (outside of TagLib) will exclusively support.


We are not making progress with this issue.

I changed the text regarding `client authentication and the aud values` to RECOMMEND instead of MUST.

The AZ still MUST ensure that it is the intended audience. The document, as always following the principle of no repeating the obvious, does not mention that fact because the standards are clear and no clarification is needed.

## Client Authentication

This CAMARA document allows **one** client authentication method, `private_key_jwt`, as defined in OIDC
OIDC Client Authentication

This document RECOMMENDS that for OIDC Authorization Code Flow and OAuth2 Client Credentials Grant the audience SHOULD be the URL of the Authorization Server's Token Endpoint.
This document RECOMMENDS that for OIDC CIBA the audience SHOULD be the Backchannel Authentication Endpoint.


@AxelNennker The following is the proposed text for PR URL under OIDC Authorization Code Flow section.

----------------------

The OIDC Authorization Code Flow is defined in OpenID Connect and incorporates RFC 9101, Passing a Request Object by Value.


Not on the NixOS side; we'd have to fix it upstream I imagine.


Great! Let's use that. It'll probably take some work for the first version but updating after that shouldn't be bad.


@ItsArsalanAziz
Is there any difference between this issue and the other one you reported ?
Can you provide screenshots of the current behavior ?
Check this similar issue which was fixed and see if it helps in your case or not.


@darshankawar

Yes these both issues are totally different from each other, I have added images here for that issue.

The issue you mentioned, not worked in my case. I have tried all the solutions posted there.

Below you can see the behavior for this issue that when I pick from the list, the image have the bottle on RHS but when it appears on screen using Image Widget, the bottle shifted to LHS.


@alanwilter I have re-opened the issue so we can discuss there- thanks


Also closing this issue since we dont have the repro anymore but please create another issue / follow up on #22018 about symlinks so we can discuss any ongoing problems


Thanks for the update @ItsArsalanAziz
I tried with image_picker plugin example running on iOS physical device OS 15.3.1 with which I didn't see the reported behavior.

<img width="342" alt="Screenshot 2024-04-16 at 11 22 31 AM" src=" URL

Can you try the same at your end using plugin example and check if using it, you still get reported behavior or not ?
If not, please provide us runnable complete but minimal reproducible code sample (ex: main.dart) that we can directly use to verify the issue further. Also, provide iOS device you are using which shows the issue.


I suggest to move this issue or it resolution to the next version because I think incorporating this now would open up a longer discussion and I would like to get PR #121 soon.


import 'dart:io';
import 'package:flutter/material.dart';
import 'package:image_picker/image_picker.dart';

void main() {
 runApp(const MyApp());
}

class MyApp extends StatelessWidget {
 const MyApp({super.key});

 @override
 Widget build(BuildContext context) {
 return const MaterialApp(
 title: "Test",
 home: MainApp(),
 );
 }
}

class MainApp extends StatelessWidget {
 const MainApp({super.key});

 _pickImage(BuildContext context, src) {
 ImagePicker().pickImage(source: src).then((value) async {
 if (value != null) {
 showDialog(
 context: context,
 builder: (context) {
 return Center(
 child: Image.file(
 File(value.path),
 height: 300.0,
 width: 300.0,
 fit: BoxFit.cover,
 ),
 );
 },
 );
 }
 }).onError((err, stackTrace) {
 debugPrint(err.toString());
 });
 }

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 body: Center(
 child: Column(
 mainAxisAlignment: MainAxisAlignment.center,
 children: [
 GestureDetector(
 onTap: () => _pickImage(context, ImageSource.gallery),
 behavior: HitTestBehavior.opaque,
 child: const Text(
 'Pick from Gallery',
 textAlign: TextAlign.center,
 style: TextStyle(
 fontFamily: 'Roboto',
 color: Colors.blue,
 fontSize: 16,
 ),
 ),
 ),
 const SizedBox(height: 30),
 GestureDetector(
 onTap: () => _pickImage(context, ImageSource.camera),
 behavior: HitTestBehavior.opaque,
 child: const Text(
 'Capture from Camera',
 textAlign: TextAlign.center,
 style: TextStyle(
 fontFamily: 'Roboto',
 color: Colors.blue,
 fontSize: 16,
 ),
 ),
 ),
 ],
 ),
 ),
 );
 }
}

Above is the simplest code, by running it with the below image you can see the rotation issue. Kindly check it on latest IOS device and use only the front camera, as I have already , mentioned that this issue occurs on front camera. For your kind information, I am using iPhone 13 pro max and this issue is also occurs in other latest IOS devices too.


Weird that this is the latest version of Ferdi I see on the Releases page `6.7.3-nightly.9` that was released 3 days ago but I have this `6.7.3-nightly.11` instead.

Ferdium-linux-Portable-6.7.3-nightly.9-x86_64.AppImage