How to use a function to trigger upload？

Thx for the great package, I'm having some problems using it.
I want to submit this file as part of the form. When i setting instantUpload: false and allowProcess: false, I only found a method to cancel the upload in the document file.abortProcessing.
How to implement a method to continue uploading like  file.reProcess?

We require the issue template to be filled out on all new issues. The issue template helps us collect all the information we need to address your submission efficiently.
If your issue can be classified as an integration question or a question about specific features of FilePond we ask you kindly to submit it on Stack Overflow.
We will be able to more closely look at your issue once the issue template has been filled out. The issue will be closed until the above is addressed.
Please leave a comment after you've updated the issue.

:(  Deprecated this package...


[BCH] No input at index

by sending any BCH transaction, e.g. in Send

or in Swap screen

Error is gone after waiting some time. Send / swap works now without any issues . We will keep an eye on it...


wip: new: initial docsy porting

Co-Authored-By: Leonardo Di Donato<EMAIL_ADDRESS>Co-Authored-By: Rajakavitha Kodhandapani<EMAIL_ADDRESS>Signed-off-by: Lorenzo Fontana<EMAIL_ADDRESS>For the advent of 0.27.0, @leodido and I thought that it's time for Falco to have a better website to help our users navigating the content in an easier way.
Goals of this PR:

[x] to have everything in place, homepage, videos, etc
[x] To have search
[x] To have a more understandable typeface
[x] To let users provide feedback (this is only enabled in the production build, preview here doesn't show)
[x] To let users easily contribute/edit content
[x] To have versioned documentation, so that on release 0f 0.27.0, you can still browse 0.26.0
[x] To work on mobile browsers

Everyone is encouraged to help, this was brought up to discussion in the community call of November 25th, 2020.
Working group: The next meeting of the Falco website Working group is on December 11th, more details here
Important If you open the preview and you don't see anything, append /docs to the URL, we didn't style the home page yet.
What type of PR is this?
/kind cleanup
/kind design
/kind user-interface
Any specific area of the project related to this PR?
/area blog
/area documentation
/area videos
What this PR does / why we need it:
@leodido and I
Which issue(s) this PR fixes:
Fixes #12
Special notes for your reviewer:

@fntlnz: The label(s) area/videos cannot be applied, because the repository doesn't have them

In response to this:

Co-Authored-By: Leonardo Di Donato<EMAIL_ADDRESS>Signed-off-by: Lorenzo Fontana<EMAIL_ADDRESS>For the advent of 0.27.0, @leodido and I thought that it's time for Falco to have a better website to help our users navigating the content in an easier way.
Goals of this PR:

[x] To have search
[x] To have a more understandable typeface
[ ] To let users provide feedback
[ ] To let users easily contribute/edit content
[ ] To have versioned documentation, so that on release 0f 0.27.0, you can still browse 0.26.0
[x] To work on mobile browsers

Everyone is encouraged to help, this will be brought up to discussion in the community call of November 25th, 2020.
Important If you open the preview and you don't see anything, append /docs to the URL, we didn't style the home page yet.
What type of PR is this?
/kind cleanup
/kind design
/kind user-interface
Any specific area of the project related to this PR?
/area blog
/area documentation
/area videos
What this PR does / why we need it:
@leodido and I
Which issue(s) this PR fixes:
Fixes #12
Special notes for your reviewer:

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

First preview here: https://deploy-preview-324--falcosecurity.netlify.app/docs/

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

The broken logo is due to the minification library used by hugo
https://github.com/gohugoio/hugo/issues/6475
This is why it breaks in the netlify preview but not locally with make serve

It requires minify 2.7.3 to make hugo work with the svg logos while using --minify. They tried to update it but there are issues with it so I'll keep an eye. For now I'm removing minify at all.
https://github.com/gohugoio/hugo/issues/7792

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

2608a45 Merge branch 'update/falco-website-improvements' of https://github.com/falcosecurity/falco-website into update/falco-website-improvements
9974482 Merge branch 'update/falco-website-improvements' of https://github.com/falcosecurity/falco-website into update/falco-website-improvements

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

I'm rebasing this

I'm rebasing this

I just added the featured video playlist in home page and localized it in all our supported languages.

Can you take a look for Japanese in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ja/) @oke-py @TakaoShimizu @KeisukeYamashita
Can you take a look for Korean in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ko/) @bluefriday @futureCreator
Can you take a look for Chinese in the preview here (https://deploy-preview-324--falcosecurity.netlify.app/zh/ ) @nevermosby

Thanks everyone :)

I just added the featured video playlist in home page and localized it in all our supported languages.

Can you take a look for Japanese in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ja/) @oke-py @TakaoShimizu @KeisukeYamashita
Can you take a look for Korean in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ko/) @bluefriday @futureCreator
Can you take a look for Chinese in the preview here (https://deploy-preview-324--falcosecurity.netlify.app/zh/ ) @nevermosby

Thanks everyone :)

This is almost ready to go, we need to bring the logos to the home page

This is almost ready to go, we need to bring the logos to the home page

I just added the featured video playlist in home page and localized it in all our supported languages.

Can you take a look for Japanese in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ja/) @oke-py @TakaoShimizu @KeisukeYamashita
Can you take a look for Korean in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ko/) @bluefriday @futureCreator
Can you take a look for Chinese in the preview here (https://deploy-preview-324--falcosecurity.netlify.app/zh/ ) @nevermosby

Thanks everyone :)

It looks good in Chinese page. @fntlnz

I just added the featured video playlist in home page and localized it in all our supported languages.

Can you take a look for Japanese in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ja/) @oke-py @TakaoShimizu @KeisukeYamashita
Can you take a look for Korean in the preview here ( https://deploy-preview-324--falcosecurity.netlify.app/ko/) @bluefriday @futureCreator
Can you take a look for Chinese in the preview here (https://deploy-preview-324--falcosecurity.netlify.app/zh/ ) @nevermosby

Thanks everyone :)

It looks good in Chinese page. @fntlnz

LGTM label has been added.  Git tree hash: 2b97d5187e80619446d60e80836c9493733d49b4

LGTM label has been added.  Git tree hash: 2b97d5187e80619446d60e80836c9493733d49b4

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

I reviewed JP. I found some missing translation.
Falco, the cloud-native runtime security project, is the de facto Kubernetes threat detection engine
クラウドネイティブのランタイムセキュリティプロジェクトであるFalcoは、デファクトのKubernetes脅威検知エンジンです。
Falco was created by Sysdig in 2016 and is the first runtime security project to join CNCF as an incubation-level project. Falco detects unexpected application behavior and alerts on threats at runtime.
Falcoは2016年にSysdigによって作成され、CNCFにインキュベーションレベルのプロジェクトとして参加した初のランタイムセキュリティプロジェクトです。Falcoは、予期しないアプリケーションの動作を検出し、ランタイムで脅威を警告します。
Why Falco?
なぜFalco？
The flexible rules engine allows you to describe any type of host or container behavior or activity.
柔軟なルールエンジンにより、あらゆるタイプのホストやコンテナの動作やアクティビティを記述することができます。
End-Users
エンドユーザー
Vendors
ベンダー
Integrations
インテグレーション

I reviewed JP. I found some missing translation.
Falco, the cloud-native runtime security project, is the de facto Kubernetes threat detection engine
クラウドネイティブのランタイムセキュリティプロジェクトであるFalcoは、デファクトのKubernetes脅威検知エンジンです。
Falco was created by Sysdig in 2016 and is the first runtime security project to join CNCF as an incubation-level project. Falco detects unexpected application behavior and alerts on threats at runtime.
Falcoは2016年にSysdigによって作成され、CNCFにインキュベーションレベルのプロジェクトとして参加した初のランタイムセキュリティプロジェクトです。Falcoは、予期しないアプリケーションの動作を検出し、ランタイムで脅威を警告します。
Why Falco?
なぜFalco？
The flexible rules engine allows you to describe any type of host or container behavior or activity.
柔軟なルールエンジンにより、あらゆるタイプのホストやコンテナの動作やアクティビティを記述することができます。
End-Users
エンドユーザー
Vendors
ベンダー
Integrations
インテグレーション

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fntlnz: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

New changes are detected. LGTM label has been removed.

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Rebased and took care of the missing Japanese translation issues, thanks @TakaoShimizu !

Rebased and took care of the missing Japanese translation issues, thanks @TakaoShimizu !

LGTM label has been added.  Git tree hash: e169ff65ca6e827604b4ad0f4b3773af4f7d2de3

LGTM label has been added.  Git tree hash: e169ff65ca6e827604b4ad0f4b3773af4f7d2de3

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 9f172210fd7aa71343787d748f85222414a41d96

LGTM label has been added.  Git tree hash: 9f172210fd7aa71343787d748f85222414a41d96

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 529d6dbdfb915d26aa6879713224a09abb9ed96c

LGTM label has been added.  Git tree hash: 529d6dbdfb915d26aa6879713224a09abb9ed96c

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 844dd5598d2884ce70e1c905032aaf8310a244ca

LGTM label has been added.  Git tree hash: 844dd5598d2884ce70e1c905032aaf8310a244ca

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Storage API endpoint

@jcnelson commented on Wed Apr 13 2016
Add an API endpoint that will allow a client to upload their zonefile and profile information.  The endpoint should verify that the zonefile's hash is already present in the blockchain, and that the profile is signed by the key indicated in the zonefile.  This effectively makes the registrar a storage provider for the client.

This has been added in <IP_ADDRESS> and 0.14.0.  Blockstack-CLI 0.14.0 has driver support for this enabled by default.


Prevent restart when app is running

Hello I would like to consult about a issue. When I am clicking to the received notification from Android statusbar when my application is running on foreground or background. Application does not appear. it restart itself  instead of appear. I would like to just appear when my app is running. is there any way to achieve that? Thank you in advance.

I have the same problem

Thank you very much, I made this change and it worked.
 public class SplashActivity : Activity
 {
  protected override void OnCreate(Bundle savedInstanceState)
  {
   base.OnCreate(savedInstanceState);

   var mainIntent = new Intent(Application.Context, typeof(MainActivity));
   if (Intent.Extras != null)
   {
    mainIntent.PutExtras(Intent.Extras);
   }
   mainIntent.SetFlags(ActivityFlags.SingleTop | ActivityFlags.ClearTop);

   StartActivity(mainIntent);
  }
 }

Hi all, that is something I resolved with this code in SplashScreen if you have it,
protected override void OnCreate(Bundle savedInstanceState)
{
  base.OnCreate(savedInstanceState);
  var mainIntent = new Intent(Application.Context, typeof(MainActivity));
  if (Intent.Extras != null)
  {
     mainIntent.PutExtras(Intent.Extras);
  }
  if (someFlag)
  {
      // to avoid restart the app
      mainIntent.SetFlags(ActivityFlags.SingleTop);
  }
  else
  {
      // to restart the app
      mainIntent.SetFlags(ActivityFlags.ClearTop);
  }

StartActivity(mainIntent);

}
Regards

Thank you very much it is working for me too.


Cannot get HTTP Status code of request which errors

Overview of the issue:
I cannot seem to find any way to catch the HTTP Status code of a request which errors out (i.e. 4XX, 5XX codes). A Gist outlining the issue: https://gist.run/?id=7ef33f0d8f481e45417fa7544f4782fe
Motivation/Use Case:
When using the fetch client with an API, the server may reply with status codes which provide some context beyond "error", such as 401 indicating unauthorised, when we might need more of a specifc behaviour (check auth credentials are still valid) rather than just "Failed to fetch, sorry"

It appears as if it was previously working as evidenced by some code using response.status:

https://github.com/aurelia/fetch-client/issues/46

The httpstat.us service you're using to generate the 500 response appears to have an invalid SSL cert, so the browser is rejecting the request with a TypeError. If you visit the site using https in your browser and tell Chrome to accept the cert then the gist runs as expected.

Hi @bryanrsmith,
Thanks for replying to this issue. The same issue exists when you substitute for an API that returns a 500. I replaced the URL with our API that I know returns a 500 and I still cannot access the status key.

What output do you expect to see? Here's what I see, which is what I would expect from the code:

Hmm, okay. I've fixed up the cert and it is working but when I substitute my own API I still had the issues.
For now, I think the issue lies in that my API is not returning Access-Control-Allow-Origin: * on the header, thus it turns into a network request.
For future people who hit this issue - check your headers on the Response.
Thank you @bryanrsmith

No problem! For error responses you should see the status code in dev tools, and you should see a Response instance in the interceptor or continuation. If you see a TypeError or other JS error type there's probably another issue.
One other thing I noticed-- your requestError interceptor is returning the Response instead of throwing it. That will cause the Promise returned by HttpClient.prototype.fetch() to resolve successfully instead of rejecting. Unless your interceptor is recovering from the error you typically will want to rethrow the unsuccessful Response (or use return Promise.reject(response)).


Fix custom ops loading in diffusers

What does this PR do?
This PR has critical fix for custom ops loading in diffusers.
More information
As discussed in PR #1631, removing htcore import before model loading would break quantization support for OH diffusers; however, @skaulintel encountered issues with some workloads when htcore is imported before model is loaded.   The underlying issue happens to be due to how GaudiConfig is handled when custom ops precision lists are defined in the configuration (e.g. in Habana/stable-diffusion-2).
This PR fixes the underlying issue.

@dsocek Is this linked to #1657 ?

@dsocek Is this linked to #1657 ?

@regisss Yes, here's how:
#1657 is a temporary, less intrusive, and partial fix that can be implemented with minimal validation and testing, ensuring it doesn’t delay the release.
This PR, on the other hand, is the complete fix. However, @libinta recommended postponing it until after the release, as it requires extensive validation.


Investigate regression in graceful shutdown behaviour of the app container

Don't run npm: https://github.com/npm/npm/issues/4603


Should split out the iterative peak finder in ExtendedSource into imagetools

That way the iterative procedure could be run outside of a source, on PSF corrected ratemap for instance.

Actually no, it actually depends a hell of a lot on the particular source you're looking for, as well as region files etc.
As such I've decided the best compromise is to make the internal _find_peak function public, so it can be used for new ratemaps.

I also added a couple of extra options, so that the user can specify the peak finding method to use (currently 'simple' or 'hierarchical' - the default), and the max number of iterations (default 20).


Target charge not reached at set time

Describe the bug
Since upgrading to 0.119.x the target charge that I set does not get reached in time.
I notice that it only uses 3-phase charging when emergency charging, but not when getting charging as part of a plan. that's fine, but not if the target charge doesn't get reached at the set time.
just this morning I wanted the car to be charge from 50% (emergency minimum charge) to 70% (the charge I needed today) at 7am. it started charging at 5, but wasn't finished at 7. that's a real problem! to me it looks like it just starts charging too late. The maxcurrent of my charger is 32A and 3phase, but my VW has a max of 16A. it should be able to calculate when to start charging based on the fact that it knows it's max 16A 3phase, but it seems like that part is failing.
Steps to reproduce
1.set the target charge plan to anything more than 20% of the battery
2.wake up next morning and see that it's not charged in time
Configuration details
sponsortoken: xxxxxxxxxx
network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: http
  # host is the hostname or IP address
  # if the host name contains a `.local` suffix, the name will be announced on MDNS
  # docker: MDNS announcements don't work. host must be set to the docker host's name.
  host: evcc.local
  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

interval: 10s # control cycle interval

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true

# log settings
log: debug
levels:
  site: debug
  lp-1: debug
  lp-2: debug
  cache: error
  db: error

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:

- name: SMA
  type: template
  template: sma-inverter
  usage: pv
  host: <IP_ADDRESS> # IP-Adresse oder Hostname
  password: xxxxxxxx # Passwort für Benutzergruppe Benutzer (Optional)

- name: slimmelezer
  type: custom
  power:
    source: calc
    add:
    - source: http
      uri: http://<IP_ADDRESS>/sensor/power_consumed
      method: GET
      headers:
      - content-type: application/json
      jq: .value
      scale: 1000
      timeout: 15s
      cache: 5s
    - source: http
      uri: http://<IP_ADDRESS>/sensor/power_produced
      method: GET
      headers:
      - content-type: application/json
      jq: .value
      scale: -1000
      timeout: 15s
      cache: 5s
  energy:
    source: calc
    add:
    - source: http
      uri: http://<IP_ADDRESS>/sensor/energy_produced_tariff_1
      method: GET
      headers:
      - content-type: application/json
      jq: .value
      scale: 1
      timeout: 15s
      cache: 5s
    - source: http
      uri: http://<IP_ADDRESS>/sensor/energy_produced_tariff_2
      method: GET
      headers:
      - content-type: application/json
      jq: .value
      scale: 1
      timeout: 15s
      cache: 5s
  currents:
  - source: http
    uri: http://<IP_ADDRESS>/sensor/current_phase_1
    method: GET
    headers:
    - content-type: application/json
    jq: .value
    scale: 1
    timeout: 15s
    cache: 5s
  - source: http
    uri: http://<IP_ADDRESS>/sensor/current_phase_2
    method: GET
    headers:
    - content-type: application/json
    jq: .value
    scale: 1
    timeout: 15s
    cache: 5s
  - source: http
    uri: http://<IP_ADDRESS>/sensor/current_phase_3
    method: GET
    headers:
    - content-type: application/json
    jq: .value
    scale: 1
    timeout: 15s
    cache: 5s

# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for documentation see https://docs.evcc.io/docs/devices/chargers
chargers:
  - name: alfeneve
    type: template # Wallbe charger
    template: alfen
    # Modbus TCP
    modbus: tcpip
    id: 1
    host: <IP_ADDRESS> # Hostname
    port: 502 # Port

# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for documentation see https://docs.evcc.io/docs/devices/vehicles
vehicles:
  - name: GTX
    type: template
    template: id
    title: VW ID.4 GTX
    capacity: 77 # kWh
    user: xxxxxxxx # user
    password: xxxxxxx # password
    vin: xxxxx
#    onIdentify: # set defaults when vehicle is identified
    mode: pv # enable PV-charging when vehicle is identified
    minSoc: 65 # immediately charge to 0% regardless of mode unless "off" (disabled)
    targetSoc: 100 # limit charge to 90%
    minCurrent: 6 # minimum charge current (default 6A)
    maxCurrent: 16 # maximum charge current (default 16A)

# site describes the EVU connection, PV and home battery
site:
  title: VA35 # display name for UI
  meters:
    grid: slimmelezer # grid meter
    pv:
      - SMA # list of pv inverters/ meters
#    battery:
#      - battery # list of battery meters
#    aux:
#      - aux # list of auxiliary meters for adjusting grid operating point
  residualPower: 0 # additional household usage margin
  prioritySoc: 0 # give home battery priority up to this soc (empty to disable)
  bufferSoc: 0 # continue charging on battery above soc (0 to disable)
  bufferStartSoc: 0 # start charging on battery above soc (0 to disable)
  maxGridSupplyWhileBatteryCharging: 0 # ignore battery charging if AC consumption is above this value
  smartCostLimit: 0 # set cost limit for automatic charging in PV mode

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: Oprit # display name for UI
    charger: alfeneve # charger
    mode: pv # set default charge mode, use "off" to disable by default if charger is publicly available
    # vehicle: car1 # set default vehicle (disables vehicle detection)
    resetOnDisconnect: true # set defaults when vehicle disconnects
    phases: 0 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
    minCurrent: 1 # minimum charge current (default 6A)
    maxCurrent: 32 # maximum charge current (default 16A)

    # remaining settings are experts-only and best left at default values
    priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
    soc:
      # polling defines usage of the vehicle APIs
      # Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
      # or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
      poll:
        # poll mode defines under which condition the vehicle API is called:
        #   charging: update vehicle ONLY when charging (this is the recommended default)
        #   connected: update vehicle when connected (not only charging), interval defines how often
        #   always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
        mode: charging
        # poll interval defines how often the vehicle API may be polled if NOT charging
        interval: 60m
      estimate: true # set false to disable interpolating between api updates (not recommended)
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 3m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)

# tariffs are the fixed or variable tariffs
tariffs:
  currency: EUR # three letter ISO-4217 currency code (default EUR)
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.207 # EUR/kWh
 #   zones:
  #    - days: Mo-Fr
  #      hours: 2-5
  #      price: 0.2 # EUR/kWh
  #    - days: Sa,So
  #      price: 0.15 # EUR/kWh

    # or variable tariffs
    # type: tibber
    # token: "476c477d8a039529478ebd690d35ddd80e3308ffc49b59c65b142321aee963a4" # access token
    # homeid: "cc83e83e-8cbf-4595-9bf7-c3cf192f7d9c" # optional if multiple homes associated to account

    # type: awattar
    # region: de # optional, choose at for Austria
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)

    # type: elering # Nordpool
    # region: ee # or lt, lv, fi
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.1126 # EUR/kWh
  co2:
    # co2 tariff provides co2 intensity forecast and is for co2-optimized target charging if no variable grid tariff is specified
    # type: grünstromindex # GrünStromIndex (Germany only)
    # zip: <zip>

Log details
larsdecraene@Mackak Downloads % evcc -c evcc.yaml --log debug
[main  ] INFO 2023/08/27 08:31:02 evcc 0.119.0
[main  ] INFO 2023/08/27 08:31:02 using config file: evcc.yaml
[main  ] INFO 2023/08/27 08:31:02 starting ui and api at :7070
[alfen ] DEBUG 2023/08/27 08:31:03 detected 3p alfen
[site  ] INFO 2023/08/27 08:31:06 site config:
[site  ] INFO 2023/08/27 08:31:06   meters:      grid ✓ pv ✓ battery ✗
[site  ] INFO 2023/08/27 08:31:06     grid:      power ✓ energy ✓ currents ✓
[site  ] INFO 2023/08/27 08:31:06     pv 1:      power ✓ energy ✓ currents ✓
[site  ] INFO 2023/08/27 08:31:06   vehicles:
[site  ] INFO 2023/08/27 08:31:06     vehicle 1: range ✓ finish ✓ status ✓ climate ✓ wakeup ✓
[lp-1  ] INFO 2023/08/27 08:31:06 loadpoint 1:
[lp-1  ] INFO 2023/08/27 08:31:06   mode:        pv
[lp-1  ] INFO 2023/08/27 08:31:06   charger:     power ✓ energy ✓ currents ✓ phases ✓ wakeup ✗
[lp-1  ] INFO 2023/08/27 08:31:06   meters:      charge ✓
[lp-1  ] INFO 2023/08/27 08:31:06     charge:    power ✓ energy ✓ currents ✓
[lp-1  ] DEBUG 2023/08/27 08:31:06 phase timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:06 pv timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:06 guard timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:06 max charge current: 1A
[site  ] WARN 2023/08/27 08:31:06 interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
[site  ] DEBUG 2023/08/27 08:31:06 ----
[lp-1  ] DEBUG 2023/08/27 08:31:06 charge power: 7093W
[site  ] DEBUG 2023/08/27 08:31:06 pv power: 1286W
[main  ] INFO 2023/08/27 08:31:06 new version available: 0.119.1
[site  ] DEBUG 2023/08/27 08:31:06 grid power: 6117W
[site  ] DEBUG 2023/08/27 08:31:06 grid currents: [30.1 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:31:06 site power: 6117W
[lp-1  ] DEBUG 2023/08/27 08:31:06 charge currents: [31.5 0.018 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:06 charge total import: 584.088kWh
[lp-1  ] DEBUG 2023/08/27 08:31:07 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:31:07 charge start energy: 584kWh
[lp-1  ] INFO 2023/08/27 08:31:07 car connected
[lp-1  ] DEBUG 2023/08/27 08:31:07 vehicle api refresh
[lp-1  ] DEBUG 2023/08/27 08:31:07 pv timer elapse
[lp-1  ] DEBUG 2023/08/27 08:31:07 pv timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:07 charger: guard elapse
[lp-1  ] DEBUG 2023/08/27 08:31:07 guard timer inactive
[influx] ERROR 2023/08/27 08:31:07 write failed (attempts 1): Post "http://a0d7b954-influxdb:8086/api/v2/write?bucket=evcc&org=&precision=s": dial tcp: lookup a0d7b954-influxdb: no such host
[lp-1  ] DEBUG 2023/08/27 08:31:07 charge total import: 584.088kWh
[main  ] DEBUG 2023/08/27 08:31:07 vehicle status: C (VW ID.4 GTX)
[lp-1  ] INFO 2023/08/27 08:31:07 vehicle updated: unknown -> VW ID.4 GTX
[lp-1  ] DEBUG 2023/08/27 08:31:07 set charge mode: pv
[lp-1  ] DEBUG 2023/08/27 08:31:07 set min current: 6
[lp-1  ] DEBUG 2023/08/27 08:31:07 set max current: 16
[lp-1  ] DEBUG 2023/08/27 08:31:07 vehicle status: C
[lp-1  ] DEBUG 2023/08/27 08:31:07 vehicle soc: 64%
[lp-1  ] DEBUG 2023/08/27 08:31:07 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/08/27 08:31:07 vehicle range: 259km
[lp-1  ] DEBUG 2023/08/27 08:31:07 available power 976W < 4140W min 3p threshold
[lp-1  ] DEBUG 2023/08/27 08:31:07 start phase scale1p timer
[lp-1  ] DEBUG 2023/08/27 08:31:07 phase scale1p in 3m0s
[lp-1  ] DEBUG 2023/08/27 08:31:07 pv charge current: 0A = 0A + -8.87A (6117W @ 3p)
[lp-1  ] DEBUG 2023/08/27 08:31:07 pv disable timer reset
[lp-1  ] DEBUG 2023/08/27 08:31:07 pv timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:08 max charge current: 6A
[site  ] DEBUG 2023/08/27 08:31:16 ----
[lp-1  ] DEBUG 2023/08/27 08:31:16 charge power: 42W
[site  ] DEBUG 2023/08/27 08:31:16 pv power: 1282W
[site  ] DEBUG 2023/08/27 08:31:16 grid power: -1048W
[site  ] DEBUG 2023/08/27 08:31:16 grid currents: [1.65 1.58 1.55]A
[site  ] DEBUG 2023/08/27 08:31:16 site power: -1048W
[lp-1  ] DEBUG 2023/08/27 08:31:16 vehicle odometer: 2795km
[lp-1  ] DEBUG 2023/08/27 08:31:16 charge currents: [6.02 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:17 charge total import: 584.090kWh
[influx] ERROR 2023/08/27 08:31:17 write failed (attempts 2): Post "http://a0d7b954-influxdb:8086/api/v2/write?bucket=evcc&org=&precision=s": dial tcp: lookup a0d7b954-influxdb: no such host
[lp-1  ] DEBUG 2023/08/27 08:31:17 charger status: C
[lp-1  ] DEBUG 2023/08/27 08:31:17 charge start energy: 584kWh
[lp-1  ] INFO 2023/08/27 08:31:17 start charging ->
[lp-1  ] DEBUG 2023/08/27 08:31:17 wake-up timer: stop
[lp-1  ] DEBUG 2023/08/27 08:31:17 soc estimated: 64.00% (vehicle: 64.00%)
[lp-1  ] DEBUG 2023/08/27 08:31:17 vehicle soc: 64%
[lp-1  ] DEBUG 2023/08/27 08:31:17 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/08/27 08:31:17 vehicle range: 259km
[lp-1  ] DEBUG 2023/08/27 08:31:17 phase timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:17 pv charge current: 7.52A = 6A + 1.52A (-1048W @ 3p)
[lp-1  ] DEBUG 2023/08/27 08:31:17 max charge current: 7.52A
[site  ] DEBUG 2023/08/27 08:31:26 ----
[lp-1  ] DEBUG 2023/08/27 08:31:26 charge power: 1683W
[site  ] DEBUG 2023/08/27 08:31:26 pv power: 1284W
[site  ] DEBUG 2023/08/27 08:31:26 grid power: 632W
[site  ] DEBUG 2023/08/27 08:31:26 grid currents: [5.89 1.58 1.54]A
[site  ] DEBUG 2023/08/27 08:31:26 site power: 632W
[lp-1  ] DEBUG 2023/08/27 08:31:26 charge currents: [7.22 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:26 detected active phases: 1p
[lp-1  ] DEBUG 2023/08/27 08:31:27 charge total import: 584.094kWh
[lp-1  ] DEBUG 2023/08/27 08:31:27 charger status: C
[lp-1  ] DEBUG 2023/08/27 08:31:27 soc estimated: 64.00% (vehicle: 64.00%)
[lp-1  ] DEBUG 2023/08/27 08:31:27 vehicle soc: 64%
[lp-1  ] DEBUG 2023/08/27 08:31:27 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/08/27 08:31:27 vehicle range: 259km
[lp-1  ] DEBUG 2023/08/27 08:31:27 pv charge current: 4.77A = 7.52A + -2.75A (632W @ 1p)
[lp-1  ] DEBUG 2023/08/27 08:31:27 site power 632W >= 0W disable threshold
[lp-1  ] DEBUG 2023/08/27 08:31:27 pv disable timer start: 3m0s
[lp-1  ] DEBUG 2023/08/27 08:31:27 pv disable in 3m0s
[lp-1  ] DEBUG 2023/08/27 08:31:27 max charge current: 6A
[site  ] DEBUG 2023/08/27 08:31:36 ----
[lp-1  ] DEBUG 2023/08/27 08:31:36 charge power: 0W
[site  ] DEBUG 2023/08/27 08:31:36 pv power: 1287W
[site  ] DEBUG 2023/08/27 08:31:36 grid power: -1064W
[site  ] DEBUG 2023/08/27 08:31:36 grid currents: [1.49 1.58 1.55]A
[site  ] DEBUG 2023/08/27 08:31:36 site power: -1064W
[lp-1  ] DEBUG 2023/08/27 08:31:36 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:37 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:31:37 charger status: B
[influx] ERROR 2023/08/27 08:31:37 write failed (attempts 3): Post "http://a0d7b954-influxdb:8086/api/v2/write?bucket=evcc&org=&precision=s": dial tcp: lookup a0d7b954-influxdb: no such host
[lp-1  ] DEBUG 2023/08/27 08:31:37 final charge energy: 0.006kWh
[lp-1  ] INFO 2023/08/27 08:31:37 stop charging <-
[lp-1  ] DEBUG 2023/08/27 08:31:37 wake-up timer: start
[lp-1  ] DEBUG 2023/08/27 08:31:37 pv timer reset
[lp-1  ] DEBUG 2023/08/27 08:31:37 pv timer inactive
[lp-1  ] DEBUG 2023/08/27 08:31:37 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:31:38 soc estimated: 64.01% (vehicle: 64.00%)
[lp-1  ] DEBUG 2023/08/27 08:31:38 vehicle soc: 64%
[lp-1  ] DEBUG 2023/08/27 08:31:38 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/08/27 08:31:38 vehicle range: 259km
[lp-1  ] WARN 2023/08/27 08:31:38 charger out of sync: expected enabled, got disabled
[lp-1  ] DEBUG 2023/08/27 08:31:38 pv charge current: 4.63A = 0A + 4.63A (-1064W @ 1p)
[site  ] DEBUG 2023/08/27 08:31:46 ----
[lp-1  ] DEBUG 2023/08/27 08:31:46 charge power: 0W
[site  ] DEBUG 2023/08/27 08:31:46 pv power: 1283W
[site  ] DEBUG 2023/08/27 08:31:46 grid power: -1068W
[site  ] DEBUG 2023/08/27 08:31:46 grid currents: [1.5 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:31:46 site power: -1068W
[lp-1  ] DEBUG 2023/08/27 08:31:46 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:46 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:31:47 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:31:47 pv charge current: 4.64A = 0A + 4.64A (-1068W @ 1p)
[lp-1  ] DEBUG 2023/08/27 08:31:48 set target soc: 70
[site  ] DEBUG 2023/08/27 08:31:48 ----
[lp-1  ] DEBUG 2023/08/27 08:31:48 charge power: 0W
[site  ] DEBUG 2023/08/27 08:31:48 pv power: 1283W
[site  ] DEBUG 2023/08/27 08:31:48 grid power: -1068W
[site  ] DEBUG 2023/08/27 08:31:48 grid currents: [1.5 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:31:48 site power: -1068W
[lp-1  ] DEBUG 2023/08/27 08:31:48 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:48 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:31:48 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:31:48 pv charge current: 4.64A = 0A + 4.64A (-1068W @ 1p)
[site  ] DEBUG 2023/08/27 08:31:56 ----
[lp-1  ] DEBUG 2023/08/27 08:31:56 charge power: 0W
[site  ] DEBUG 2023/08/27 08:31:56 pv power: 1291W
[site  ] DEBUG 2023/08/27 08:31:56 grid power: -1052W
[site  ] DEBUG 2023/08/27 08:31:56 grid currents: [1.48 1.56 1.53]A
[site  ] DEBUG 2023/08/27 08:31:56 site power: -1052W
[lp-1  ] DEBUG 2023/08/27 08:31:56 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:31:56 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:31:57 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:31:57 pv charge current: 4.57A = 0A + 4.57A (-1052W @ 1p)
[site  ] DEBUG 2023/08/27 08:32:06 ----
[lp-1  ] DEBUG 2023/08/27 08:32:06 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:06 pv power: 1291W
[site  ] DEBUG 2023/08/27 08:32:06 grid power: -1067W
[site  ] DEBUG 2023/08/27 08:32:06 grid currents: [1.5 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:32:06 site power: -1067W
[lp-1  ] DEBUG 2023/08/27 08:32:06 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:06 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:07 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:07 pv charge current: 4.64A = 0A + 4.64A (-1067W @ 1p)
[site  ] DEBUG 2023/08/27 08:32:16 ----
[lp-1  ] DEBUG 2023/08/27 08:32:16 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:16 pv power: 1278W
[site  ] DEBUG 2023/08/27 08:32:16 grid power: -1066W
[site  ] DEBUG 2023/08/27 08:32:16 grid currents: [1.49 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:32:16 site power: -1066W
[lp-1  ] DEBUG 2023/08/27 08:32:16 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:16 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:17 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:17 planned 27m52s until 2023-08-27 10:00:00 +0200 CEST at 11040W: total plan duration: 27m52s, avg cost: 0.207
[lp-1  ] DEBUG 2023/08/27 08:32:17 pv charge current: 4.63A = 0A + 4.63A (-1066W @ 1p)
[influx] ERROR 2023/08/27 08:32:17 write failed (attempts 1): Post "http://a0d7b954-influxdb:8086/api/v2/write?bucket=evcc&org=&precision=s": dial tcp: lookup a0d7b954-influxdb: no such host
[lp-1  ] DEBUG 2023/08/27 08:32:17 set target soc: 80
[site  ] DEBUG 2023/08/27 08:32:17 ----
[lp-1  ] DEBUG 2023/08/27 08:32:17 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:17 pv power: 1278W
[site  ] DEBUG 2023/08/27 08:32:17 grid power: -1066W
[site  ] DEBUG 2023/08/27 08:32:17 grid currents: [1.49 1.58 1.56]A
[site  ] DEBUG 2023/08/27 08:32:17 site power: -1066W
[lp-1  ] DEBUG 2023/08/27 08:32:18 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:18 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:18 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:18 planned 1h14m22s until 2023-08-27 10:00:00 +0200 CEST at 11040W: total plan duration: 1h14m22s, avg cost: 0.207
[lp-1  ] DEBUG 2023/08/27 08:32:18 pv charge current: 4.63A = 0A + 4.63A (-1066W @ 1p)
[site  ] DEBUG 2023/08/27 08:32:26 ----
[lp-1  ] DEBUG 2023/08/27 08:32:26 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:26 pv power: 1138W
[site  ] DEBUG 2023/08/27 08:32:26 grid power: -1040W
[site  ] DEBUG 2023/08/27 08:32:26 grid currents: [1.46 1.54 1.53]A
[site  ] DEBUG 2023/08/27 08:32:26 site power: -1040W
[lp-1  ] DEBUG 2023/08/27 08:32:26 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:26 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:27 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:27 planned 1h14m22s until 2023-08-27 10:00:00 +0200 CEST at 11040W: total plan duration: 1h14m22s, avg cost: 0.207
[lp-1  ] DEBUG 2023/08/27 08:32:27 pv charge current: 4.52A = 0A + 4.52A (-1040W @ 1p)
[site  ] DEBUG 2023/08/27 08:32:36 ----
[lp-1  ] DEBUG 2023/08/27 08:32:36 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:36 pv power: 1288W
[site  ] DEBUG 2023/08/27 08:32:36 grid power: -1063W
[site  ] DEBUG 2023/08/27 08:32:36 grid currents: [1.49 1.57 1.56]A
[site  ] DEBUG 2023/08/27 08:32:36 site power: -1063W
[lp-1  ] DEBUG 2023/08/27 08:32:36 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:36 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:37 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:37 planned 1h14m22s until 2023-08-27 10:00:00 +0200 CEST at 11040W: total plan duration: 1h14m22s, avg cost: 0.207
[lp-1  ] DEBUG 2023/08/27 08:32:37 pv charge current: 4.62A = 0A + 4.62A (-1063W @ 1p)
[site  ] DEBUG 2023/08/27 08:32:46 ----
[lp-1  ] DEBUG 2023/08/27 08:32:46 charge power: 0W
[site  ] DEBUG 2023/08/27 08:32:46 pv power: 1302W
[site  ] DEBUG 2023/08/27 08:32:46 grid power: -1085W
[site  ] DEBUG 2023/08/27 08:32:46 grid currents: [1.51 1.62 1.57]A
[site  ] DEBUG 2023/08/27 08:32:46 site power: -1085W
[lp-1  ] DEBUG 2023/08/27 08:32:46 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/08/27 08:32:46 charge total import: 584.096kWh
[lp-1  ] DEBUG 2023/08/27 08:32:47 charger status: B
[lp-1  ] DEBUG 2023/08/27 08:32:47 planned 1h14m22s until 2023-08-27 10:00:00 +0200 CEST at 11040W: total plan duration: 1h14m22s, avg cost: 0.207
[lp-1  ] DEBUG 2023/08/27 08:32:47 pv charge current: 4.72A = 0A + 4.72A (-1085W @ 1p)
^C[lp-1  ] DEBUG 2023/08/27 08:32:51 charge total import: 584.096kWh

What type of operating system are you running?
HomeAssistant Add-on
Version
0.119.1

Hey,That doesn’t seem to have fixed it I’m afraid. But when I charge use the ‘fast’ setting 3 phases are used again. This did not work on 0.119.1, but is fixed in .2Thanks!LOn 28 Aug 2023, at 12:14, andig @.***> wrote:
Could you please try 0.119.2 in a few minutes?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

I experienced a similar issue just a few days ago. Could it be that the charging mode is no longer set to 'Fast' in case of planned target SoCs and that it just keeps the current charging mode? In my case it was still set to PV even though the target charge was planned in the early morning when the sun still was down.

But if it has the whole night to reach the charging goal, why should it use ‘fast’? I try to avoid this mode as much as possible for the capacity tariff. I would rather it charges the whole night at the lowest possible power.Thanks!LOn 30 Aug 2023, at 10:11, Carsten Schlipf @.***> wrote:
I experienced a similar issue just a few days ago. Could it be that the charging mode is no longer set to 'Fast' in case of planned target SoCs and that it just keeps the current charging mode? In my case it was still set to PV even though the target charge was planned in the early morning when the sun still was down.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

That‘s just how it works.

@bolisaf are you able to compile evcc? I've looked hard but cannot find a problem.
Could you kindly change the following in loadpoint.go:
// scalePhasesIfAvailable scales if api.PhaseSwitcher is available
func (lp *Loadpoint) scalePhasesIfAvailable(phases int) error {
	want := phases
	if lp.ConfiguredPhases != 0 {
		phases = lp.ConfiguredPhases
	}

	if _, ok := lp.charger.(api.PhaseSwitcher); ok {
		lp.log.DEBUG.Printf("!! scalePhasesIfAvailable: %dp -> %dp", want, phases)
		return lp.scalePhases(phases)
	}

	return nil
}

// scalePhases adjusts the number of active phases and returns the appropriate charging current.
// Returns api.ErrNotAvailable if api.PhaseSwitcher is not available.
func (lp *Loadpoint) scalePhases(phases int) error {
	cp, ok := lp.charger.(api.PhaseSwitcher)
	if !ok {
		panic("charger does not implement api.PhaseSwitcher")
	}

	lp.log.DEBUG.Printf("!! scalePhases: GetPhases %dp <> phases %dp", lp.GetPhases(), phases)
	if lp.GetPhases() != phases {
		// switch phases
		if err := cp.Phases1p3p(phases); err != nil {
			return fmt.Errorf("switch phases: %w", err)
		}

		// prevent premature measurement of active phases
		lp.phasesSwitched = lp.clock.Now()

		// update setting and reset timer
		lp.setPhases(phases)
	}

	return nil
}

If not I'll add this to the nightly build.

Please try new nightly version tomorrow plus change above- I've also improved planner logging.

Please retry 0.119.3.

Hey,It didn’t work with 0.119.3 I’m afraid. Would it help you if I ran it in debug the whole night and provided you the logs? It would be a pretty lengthy file thoughThanks!LOn 31 Aug 2023, at 19:53, andig @.***> wrote:
Closed #9550 as completed.

It looks like it did charge it in time this time around. The others times it just wasn’t charged at the target time. Let me do that again tomorrow night.

—
Reply to this email directly, view it on GitHub https://github.com/evcc-io/evcc/issues/9550#issuecomment-1704069579, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXHBOMA4NNYEKCG4G3ZTQLXYRFSLANCNFSM6AAAAAA4ADJFBY.
You are receiving this because you were mentioned.

Hey @andig i ran another debug this night. i asked evcc to charge the car to 70% by 7AM, but in the morning it was only charged to about 56%
at line 75 the car soc is 51%
[lp-1  ] DEBUG 2023/09/07 23:18:25 vehicle soc: 51%
at line 134 i set the plan:
[lp-1  ] DEBUG 2023/09/07 23:18:52 plan: charge 1h28m21s starting at 2023-09-08 05:31:39 +0200 CEST until  2023-09-08 07:00:00 +0200 CEST (power: 11040W, avg cost: 0.207)
at line 24756 the charging starts at the planned time:
[lp-1  ] DEBUG 2023/09/08 05:31:41 charge power: 0W
[site  ] DEBUG 2023/09/08 05:31:41 pv power: 0W
[site  ] DEBUG 2023/09/08 05:31:41 grid power: 293W
[site  ] DEBUG 2023/09/08 05:31:41 grid currents: [0.76 0.74 0.66]A
[site  ] DEBUG 2023/09/08 05:31:41 site power: 293W
[lp-1  ] DEBUG 2023/09/08 05:31:41 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2023/09/08 05:31:42 charge total import: 784.906kWh
[lp-1  ] DEBUG 2023/09/08 05:31:42 charger status: B
[lp-1  ] DEBUG 2023/09/08 05:31:42 plan: charge 1h28m18s (required: 1h28m19s) starting at 2023-09-08 05:31:42 +0200 CEST until 2023-09-08 07:00:00 +0200 CEST (power: 11040W, avg cost: 0.207)
[lp-1  ] DEBUG 2023/09/08 05:31:42 max charge current: 16A
[lp-1  ] DEBUG 2023/09/08 05:31:42 charger enable
[lp-1  ] DEBUG 2023/09/08 05:31:42 wake-up timer: start
[lp-1  ] DEBUG 2023/09/08 05:31:42 pv timer elapse
[lp-1  ] DEBUG 2023/09/08 05:31:42 pv timer inactive
[lp-1  ] DEBUG 2023/09/08 05:31:42 charger: guard elapse
[lp-1  ] DEBUG 2023/09/08 05:31:42 guard timer inactive
[lp-1  ] DEBUG 2023/09/08 05:31:42 wake-up vehicle
[site  ] DEBUG 2023/09/08 05:31:51 ----
[lp-1  ] DEBUG 2023/09/08 05:31:51 charge power: 1839W
[site  ] DEBUG 2023/09/08 05:31:51 pv power: 0W
[site  ] DEBUG 2023/09/08 05:31:51 grid power: 2143W
[site  ] DEBUG 2023/09/08 05:31:51 grid currents: [8.42 0.75 0.67]A
[site  ] DEBUG 2023/09/08 05:31:51 site power: 2143W
[lp-1  ] DEBUG 2023/09/08 05:31:51 charge currents: [7.94 0 0]A
[lp-1  ] DEBUG 2023/09/08 05:31:51 charge total import: 784.909kWh
[lp-1  ] DEBUG 2023/09/08 05:31:52 charger status: C
[lp-1  ] DEBUG 2023/09/08 05:31:52 charge start energy: 785kWh
[lp-1  ] INFO 2023/09/08 05:31:52 start charging ->
[lp-1  ] DEBUG 2023/09/08 05:31:52 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/08 05:31:53 soc estimated: 51.01% (vehicle: 51.00%)
[lp-1  ] DEBUG 2023/09/08 05:31:53 vehicle soc: 51%
[lp-1  ] DEBUG 2023/09/08 05:31:53 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/09/08 05:31:53 vehicle range: 205km
[lp-1  ] DEBUG 2023/09/08 05:31:53 plan: charge 1h28m7s (required: 1h28m19s) starting at 2023-09-08 05:31:53 +0200 CEST until 2023-09-08 07:00:00 +0200 CEST (power: 11040W, avg cost: 0.207)

at line 32748 at 7am the charging is only 56% instead of the 70% i asked for
[lp-1  ] DEBUG 2023/09/08 07:00:01 charge power: 3581W
[site  ] DEBUG 2023/09/08 07:00:01 pv power: 0W
[site  ] DEBUG 2023/09/08 07:00:01 grid power: 3984W
[site  ] DEBUG 2023/09/08 07:00:01 grid currents: [16.2 0.93 0.68]A
[site  ] DEBUG 2023/09/08 07:00:01 site power: 3984W
[lp-1  ] DEBUG 2023/09/08 07:00:01 charge currents: [15.7 0 0]A
[lp-1  ] DEBUG 2023/09/08 07:00:01 detected active phases: 1p
[lp-1  ] DEBUG 2023/09/08 07:00:02 charge total import: 790.152kWh
[lp-1  ] DEBUG 2023/09/08 07:00:02 charger status: C
[lp-1  ] DEBUG 2023/09/08 07:00:02 soc estimated: 55.86% (vehicle: 55.00%)
[lp-1  ] DEBUG 2023/09/08 07:00:02 vehicle soc: 56%
[lp-1  ] DEBUG 2023/09/08 07:00:02 vehicle soc limit: 100%
[lp-1  ] DEBUG 2023/09/08 07:00:02 vehicle range: 222km
[lp-1  ] DEBUG 2023/09/08 07:00:02 plan: charge 0s (required: 3h17m15s) starting at 0001-01-01 01:00:00 +0100 CET until 2023-09-08 07:00:00 +0200 CEST (power: 3680W, avg cost: NaN)
[lp-1  ] DEBUG 2023/09/08 07:00:02 plan: continuing after target time

all the time it says charge x amount of time but the requried time is higher than the planned time, for example:
plan: charge 1m48s (required: 3h19m3s)
here's the full file:
debug.txt

It's charging 1p only:
charge currents: [15.6 0 0]A

We'll need to find out why.

It's charging 1p only:
charge currents: [15.6 0 0]A

We'll need to find out why.

isn't it supposed to use 1p, so the power is kept to a minimum and spread throughout the night like you said earlier in this thread?

isn't it supposed to use 1p, so the power is kept to a minimum and spread throughout the night like you said earlier in this thread?

This does not make sense... While charging your car has a constant self-consumption. So if you charge from the Grid anyway you should charge as fast as possible. Except you want to limit charging from your home battery.

Here in BE we have a capacity tariff, we get punished for drawing too much power from the grid. So it makes a lot of sense to spread the charging as much as possible. Also the car has a minimum charging current, which is set taking the self-consumption of the car into account. As long as the power is equal or larger than that minimum, you’re fine.Thanks!LOn 8 Sep 2023, at 09:35, Carsten Schlipf @.***> wrote:
isn't it supposed to use 1p, so the power is kept to a minimum and spread throughout the night like you said earlier in this thread?
This does not make sense... While charging your car has a constant self-consumption. So if you charge from the Grid anyway you should charge as fast as possible. Except you want to limit charging from your home battery.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Thanks @bolisaf - didn't know that something like this exists. Learned something new.

@bolisaf we're still missing the switch to 3p. You're charging at 1p and we're failing (or not executing) to switch. Seems you did not add the additional logging requested?

I've added the additional logging to the nightly release as of tomorrow- it would be great if you could provide another logfile with that version.

I just did a —log debug with the latest version..Anyhow, I’ll run it again with the nightly.But again, I’d really prefer it didn’t switch to 3p but just started earlier, for reasons I mentioned earlier.Thanks!LOn 9 Sep 2023, at 09:59, andig @.***> wrote:
I've added the additional logging to the nightly release as of tomorrow- it would be great if you could provide another logfile with that version.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

But again, I’d really prefer it didn’t switch to 3p but just started earlier, for reasons I mentioned earlier.

Fair, but that is a completely different topic.
For sake of completeness: is it possible that you've set the charger to 1p intentionally (ui settings)? I'd need to double-check, but that might explain why it didn't switch to 3p but the planner still used 3p for calculation. I'll need to verify that.
Anyway please share the new log.

Here’s a screen from my UI:It switches to 3p fine when I select ‘fast’ charging. I can do that as well as part of the debug.Do I create an enhancement request for the 1p low power charging?Thanks!LOn 9 Sep 2023, at 19:21, andig @.***> wrote:
But again, I’d really prefer it didn’t switch to 3p but just started earlier, for reasons I mentioned earlier.
Fair, but that is a completely different topic.
For sake of completeness: is it possible that you've set the charger to 1p intentionally (ui settings)? I'd need to double-check, but that might explain why it didn't switch to 3p but the planner still used 3p for calculation. I'll need to verify that.
Anyway please share the new log.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I've added the additional logging to the nightly release as of tomorrow- it would be great if you could provide another logfile with that version.

hey andig, sory for the stupid question, where can i download the nightly build? is it compiled as exe? can i just run it as i did before?

You cannot for HA but latest release should contain the logging.

Here’s a screen from my UI

No screenshot.

I'll need to verify that.

Lets reopen when we have a new log.

heuy @andig here's the new log
debug.txt
take a look at line 21402, it says 'active phases detected: 1p' but doesn't change to 3p
[site  ] DEBUG 2023/09/16 05:32:47 ---- [lp-1  ] DEBUG 2023/09/16 05:32:47 charge power: 3566W [site  ] DEBUG 2023/09/16 05:32:47 pv power: 0W [site  ] DEBUG 2023/09/16 05:32:47 grid power: 3824W [site  ] DEBUG 2023/09/16 05:32:47 grid currents: [15.9 0.72 0.41]A [site  ] DEBUG 2023/09/16 05:32:47 site power: 3824W [lp-1  ] DEBUG 2023/09/16 05:32:47 charge currents: [15.5 0 0]A [lp-1  ] DEBUG 2023/09/16 05:32:47 charge total import: 933.988kWh [lp-1  ] DEBUG 2023/09/16 05:32:48 charger status: C [lp-1  ] DEBUG 2023/09/16 05:32:48 soc estimated: 51.06% (vehicle: 51.00%) [lp-1  ] DEBUG 2023/09/16 05:32:48 vehicle soc: 51% [lp-1  ] DEBUG 2023/09/16 05:32:48 vehicle soc limit: 100% [lp-1  ] DEBUG 2023/09/16 05:32:48 vehicle range: 230km [lp-1  ] DEBUG 2023/09/16 05:32:48 plan: charge 1h27m12s (required: 1h28m4s) starting at 2023-09-16 05:32:48 +0200 CEST until 2023-09-16 07:00:00 +0200 CEST (power: 11040W, avg cost: 0.207) [site  ] DEBUG 2023/09/16 05:32:57 ---- [lp-1  ] DEBUG 2023/09/16 05:32:57 charge power: 3567W [site  ] DEBUG 2023/09/16 05:32:57 pv power: 0W [site  ] DEBUG 2023/09/16 05:32:57 grid power: 3827W [site  ] DEBUG 2023/09/16 05:32:57 grid currents: [15.9 0.72 0.43]A [site  ] DEBUG 2023/09/16 05:32:57 site power: 3827W [lp-1  ] DEBUG 2023/09/16 05:32:57 charge currents: [15.5 0 0]A [lp-1  ] DEBUG 2023/09/16 05:32:57 detected active phases: 1p [lp-1  ] DEBUG 2023/09/16 05:32:57 charge total import: 933.997kWh [lp-1  ] DEBUG 2023/09/16 05:32:58 charger status: C [lp-1  ] DEBUG 2023/09/16 05:32:58 soc estimated: 51.07% (vehicle: 51.00%) [lp-1  ] DEBUG 2023/09/16 05:32:58 vehicle soc: 51% [lp-1  ] DEBUG 2023/09/16 05:32:58 vehicle soc limit: 100% [lp-1  ] DEBUG 2023/09/16 05:32:58 vehicle range: 230km [lp-1  ] DEBUG 2023/09/16 05:32:58 plan: charge 1h27m2s (required: 4h24m2s) starting at 2023-09-16 05:32:58 +0200 CEST until 2023-09-16 07:00:00 +0200 CEST (power: 3680W, avg cost: 0.207)

here's the screenshot from the UI again to show it's set to auto switch phases:

me:

But if it has the whole night to reach the charging goal, why should it use ‘fast’? I try to avoid this mode as much as possible for the capacity tariff. I would rather it charges the whole night at the lowest possible power.Thanks!L
@andig:
That‘s just how it works.
me:
But again, I’d really prefer it didn’t switch to 3p but just started earlier, for reasons I mentioned earlier.
@andig
Fair, but that is a completely different topic.

am i reading this wrong or are these contradictory statements? if it doesn't spread out the charging as much as possible, I'll create an enhancement request, i just want to be sure

Thats just how it works. Plan charging tages as much PV as possible and covers the remainder at full speed.

@andig
i did some more testing. i logged the successful phase switch when i set the mode from 'pv' to 'fast'.
evcc debug:
phaseswitch_evcc_debug.txt
alfeneve debug:
phaseswitch_alfeneve_debug.txt
don't forget about the 2hour time difference :)

I'm really sorry. The additional logging is only in the nightly. I'll release .6 now and we'll need to do this again :(

first start planned charge at 09:38 => only 1 phase
start fast charging after plan => also only 1p!
disconnect car and reconnect => switch to 3p worksµ
switch back to pv mode => switch to 1p works
switch back to fast mode => switch to 3p works
switch back to pv mode => switch to 1p works
reactivate plan => switych to 3p doesn't work
disconnect car and reconnect => now the switch to 3p does work as part of the plan !
cancel plan => switch to 1p works
switch to fast => switch to 3P doesnt work anymore

here's the logs. testing (more or less in the order that i state above) starts at 09h38 and ends at 10h31
evcc_debug.txt
alfeneve_debug.txt

That is really helpful, lets take a look:
We start in PV mode and successfully switch to 1p:
[lp-1  ] DEBUG 2023/09/18 09:17:23 set charge mode: pv
[lp-1  ] DEBUG 2023/09/18 09:20:32 phase scale1p timer elapsed
[lp-1  ] DEBUG 2023/09/18 09:20:32 !! scalePhases: GetPhases 0p <> phases 1p
[lp-1  ] DEBUG 2023/09/18 09:20:32 phase timer inactive
[lp-1  ] DEBUG 2023/09/18 09:20:32 switched phases: 1p @ 4W

We switch to Now mode and successfully switch to 3p:
[lp-1  ] DEBUG 2023/09/18 09:20:47 set charge mode: now
[lp-1  ] DEBUG 2023/09/18 09:20:48 charger status: B
[lp-1  ] DEBUG 2023/09/18 09:20:48 !! scalePhasesIfAvailable: 3p -> 3p
[lp-1  ] DEBUG 2023/09/18 09:20:48 !! scalePhases: GetPhases 1p <> phases 3p
[lp-1  ] DEBUG 2023/09/18 09:20:48 charger enable
[lp-1  ] DEBUG 2023/09/18 09:20:48 wake-up timer: start
[lp-1  ] DEBUG 2023/09/18 09:20:52 charger status: C
[lp-1  ] INFO 2023/09/18 09:20:52 start charging ->
[lp-1  ] DEBUG 2023/09/18 09:20:52 wake-up timer: stop
[lp-1  ] DEBUG 2023/09/18 09:20:52 !! scalePhasesIfAvailable: 3p -> 3p
[lp-1  ] DEBUG 2023/09/18 09:20:52 !! scalePhases: GetPhases 3p <> phases 3p
[site  ] DEBUG 2023/09/18 09:21:01 grid currents: [15.6 15.5 15.8]A

Note: we do not see the phase switch in the log (bad- seems only PV mode is actually logging this) but we can see 3p charging.
We switch back to PV mode and successfully switch to 1p:
[lp-1  ] DEBUG 2023/09/18 09:22:56 set charge mode: pv
[lp-1  ] DEBUG 2023/09/18 09:26:01 charge power: 4159W
[site  ] DEBUG 2023/09/18 09:26:01 grid power: 3936W
[lp-1  ] DEBUG 2023/09/18 09:26:01 detected active phases: 3p
[lp-1  ] DEBUG 2023/09/18 09:26:02 charger status: C
[lp-1  ] DEBUG 2023/09/18 09:26:02 available power 223W < 4140W min 3p threshold
[lp-1  ] DEBUG 2023/09/18 09:26:02 phase scale1p in 0s
[lp-1  ] DEBUG 2023/09/18 09:26:02 phase scale1p timer elapsed
[lp-1  ] DEBUG 2023/09/18 09:26:02 !! scalePhases: GetPhases 3p <> phases 1p
[lp-1  ] DEBUG 2023/09/18 09:26:02 phase timer inactive
[lp-1  ] DEBUG 2023/09/18 09:26:02 switched phases: 1p @ 223W

Sofar, so good. Now the plan starts, we're in PV mode:
[lp-1  ] DEBUG 2023/09/18 09:39:02 plan: charge 45m58s (required: 46m7s) starting at 2023-09-18 09:39:02 +0200 CEST until 2023-09-18 10:25:00 +0200 CEST (power: 11040W, avg cost: 0.207)
[lp-1  ] DEBUG 2023/09/18 09:39:02 !! scalePhasesIfAvailable: 3p -> 3p
[lp-1  ] DEBUG 2023/09/18 09:39:02 !! scalePhases: GetPhases 1p <> phases 3p
[lp-1  ] DEBUG 2023/09/18 09:39:02 max charge current: 16A
[lp-1  ] DEBUG 2023/09/18 09:39:02 charger: guard elapse
[lp-1  ] DEBUG 2023/09/18 09:39:02 guard timer inactive
[lp-1  ] DEBUG 2023/09/18 09:39:02 charger enable
[lp-1  ] DEBUG 2023/09/18 09:39:02 pv timer elapse
[lp-1  ] DEBUG 2023/09/18 09:39:02 pv timer inactive
[lp-1  ] DEBUG 2023/09/18 09:39:02 charger: guard elapse
[lp-1  ] DEBUG 2023/09/18 09:39:02 guard timer inactive
[lp-1  ] DEBUG 2023/09/18 09:39:11 charge currents: [8.14 0 0]A
[lp-1  ] DEBUG 2023/09/18 09:39:11 charger status: C
[lp-1  ] INFO 2023/09/18 09:39:12 start charging ->

Again we see that we've apparently trying to switch phases but we don't. Similar to Now mode we don't see if any switching actually happened (bad).
/cc @GrimmiMeloni hast Du eine Idee, was hier los ist? In jedem Fall ein hässlicher Bug.

@bolisaf I've improved logging in master branch. Could you please confirm if the Alfen log shows phase switching at 09:20:32, 09:20:48, 09:26:02 und most importantly at 09:39:02?
Once done please upgrade to master and also set alfen: trace.

Here is the phases setting from the Alfen log:
2023-09-18T07:20:29 #phases is 1 by: Modbus
2023-09-18T07:20:45 #phases is 3
2023-09-18T07:25:59 #phases is 1 by: Modbus
2023-09-18T07:38:59 #phases is 3 <- start of plan
2023-09-18T07:46:59 #phases is 1 by: Modbus
2023-09-18T07:47:19 #phases is 3
2023-09-18T07:50:59 #phases is 1 by: Modbus
2023-09-18T07:59:59 #phases is 3
2023-09-18T08:08:49 #phases is 1 by: Modbus
2023-09-18T08:09:05 #phases is 3
2023-09-18T08:13:19 #phases is 1 by: Modbus
2023-09-18T08:17:49 #phases is 3
2023-09-18T08:23:09 #phases is 1 by: Modbus
2023-09-18T08:26:47 #phases is 3
2023-09-18T08:38:01 #phases is 1 by: Modbus

It confirms that with plan start we're switching to 3p. It seems as if this is not working since vehicle continues charging at 1p. Its unclear to me why this happens.
Its also a bit unclear why the phases=1 is shown as by: Modbus while phases=3 is not, but that seems to be a firmware logging issue.
ATM I would say that evcc works exactly as planned- only the charger does not seem to perform the switch. I'd suggest to contact Alfen with these findings.

I had a look, @andig.
The Alfen Log looks spurious to me. I have no first hand experience with modBus, so maybe I am misreading.
That said - searching for #phases in said log reveals
2023-09-18T07:38:59.308Z:INFO:taskMain.c:6910:Socket #1: #phases is 3
However, 30 seconds later the charge is running on 1p only:
2023-09-18T07:39:31.292Z:USER:taskMaster.c:6077:Socket #1: I1=15.6A I2=0.0A I3=0.0A P=3.6kW Idc=0.0mA
In between these lines quite a few things happen - most importantly charging is stopped and started in less than 2s
2023-09-18T07:38:59.484Z:INFO:taskMaster.c:4307:Socket #1: state main  : CHARGING_POWER_OFF
2023-09-18T07:39:01.234Z:INFO:taskMaster.c:4307:Socket #1: state main  : CHARGING_POWER_ON

Wild guess: Does the Alfen by any chance reset phases when cycling through charge off/on ?

It confirms that with plan start we're switching to 3p. It seems as if this is not working since vehicle continues charging at 1p. Its unclear to me why this happens.

@bolisaf seems we're ready to close at this point. evcc log looks as expected, Alfen log is unclear. If you disagree please provide more inside- though I wouldn't see which at this point :(

If you disagree please provide more inside- though I wouldn't see which at this point :(

Actually: since you're saying that 0.119 introduced the problem I could suggest to have a simple scenario and retest on 118 plus 120. Set alfen: trace in both cases and lets see if there is a difference that might make the box so behave differently.

as soon as I updated the alfen eve to firmware 6.5.0-4217 phase switching was no longer an issue.


DNM Helm may be broken on inspection

This is a test of the automated gates.  It was reported that
the CRD separate step was not in the e2e test cases.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: sdake
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: nmittler
If they are not already assigned, you can assign the PR to them by writing /assign @nmittler in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

I don't see any code for this PR @sdake ?


test git backup workflow

ensure that I can work on the project both in the lab and @ home

lab -> home works great!
going to test with @MocapMike home -> lab


chore: bdd-spring-1574983137 to 0.0.1

chore: Promote bdd-spring-1574983137 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


OAuth2 filter POST request with expired token

I am using OAuth2 filter to protect my backend. I faced with following unpleasant issue.

User opens my site
User authorizes and gets JWT token for 5 minutes.
User works on site for 5 minutes.
Token is expired and user sends POST http method instead of GET method(any save operation on my site)
Because the token is expired, Envoy redirects user to IDP, user gets new JWT token, and after that instead of HTTP POST method my backend is recieved HTTP GET method, but initially my site had sent HTTP POST method.

Is there a best way to resolve such behaviour?

cc @snowp

I think when we recieved callback from IDP, we need to send source request further without redirect to browser.

Could you add the tag "help wanted" please

Could you add the tag "help wanted" please?

Why this is closed given that linked PR is still open?


Limit validate steps + test

This change is

Codecov Report

Merging #1026 (cbc476c) into main (61c9719) will increase coverage by 0.23%.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1026      +/-   ##
==========================================
+ Coverage   67.48%   67.72%   +0.23%
==========================================
  Files          51       51
  Lines        6228     6243      +15
  Branches     6228     6243      +15
==========================================
+ Hits         4203     4228      +25
+ Misses       1644     1634      -10
  Partials      381      381

Files
Coverage Δ

crates/blockifier/src/execution/entry_point.rs
94.84% <100.00%> (+0.16%)
:arrow_up:

... and 6 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Added EMPD2 samples contributed by Hallsdottir

Hi! I'm your friendly automated EMPD-admin bot!
Thank you very much for your data submission! I will now run some tests on your data.
In the meantime: please review your test data on the EMPD viewer using
this link: https://EMPD2.github.io/?repo=EMPD2/EMPD-data&branch=Hallsdottir&meta=Hallsdottir.tsv
This bot is helping you merging your data. I am checking for common issues and I can fix your climate, country or elevation data.
Type @EMPD-admin help in a new comment in this PR for usage information.
Make sure, that all the commands for the @EMPD-admin are on one single line and nothing else. Only
@EMPD-admin help
will work, not something like
<other words> @EMPD-admin help
or
@EMPD-admin help <other words>
Note that you can also run these tests on your local machine with
pytest.

Hi! I'm your friendly automated EMPD-admin bot!
This is just to inform you that I tested your data submission in your PR (Hallsdottir.tsv) and found it in an excellent condition!

@EMPD-admin finish --commit

Hi! I'm your friendly automated EMPD-admin bot!
I processed your command and hope that I can help you!

finish --commit

Finished the PR!
You may want to have a final look into the viewer (https://EMPD2.github.io/?repo=EMPD2/EMPD-data&branch=Hallsdottir) and then merge it.


Adjust mongodb connection string

Adjust mongodb connection string

Codecov Report

Merging #18 (3c947a5) into main (3f7741f) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #18   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           79        79
  Lines          851       851
  Branches        69        69
=========================================
  Hits           851       851

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


Webview breaks command-H shortcut even when closed

Issue Type: Bug
Open any webview (e.g. Git Graph or Hex Editor) and close it. From then on, while that workspace is open, pressing command-H on the Mac will no longer hide the VS Code app.
Similar to #71800, but as of a recent release, it stays broken even after you close the webview. Even using Developer > Reload Window doesn't help; you need to close and re-open the workspace.
VS Code version: Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:32.912Z)
OS version: Darwin x64 18.7.0
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz (8 x 2300)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 3, 2

Memory (System)
16.00GB (1.21GB free)

Process Argv
--crash-reporter-id ee98133f-4180-44b0-86f2-150582a5f918

Screen Reader
no

VM
0%

OK -- but if it's being considered a duplicate of #71800, that was reported about the issue only happening when the webview is open; this recent bug made it start happening even when you close the webview.


Updates OmniSharp package version

Updates OmniSharp package version and makes explicit reference to the desired System.Reactive version.
Once more validation is complete will merge this PR.

Why do we need to update OmniSharp.Extensions.LanguageServer at all? It's only used by Web Tools in VS.

@DustinCampbell , WebTools no longer uses OmniSharp (they absolutely did before), and no longer references it in any way.  The goal here is to have the same System.Reactive used in multiple places as one of our partners needed to update the System.Reactive version which they have, and are changing the one VS loads via binding redirect.  This change is to get us up-to-date with that.  The alternative fix would be to pin System.Reactive to the new version, and leave the OmniSharp unchanged.

I hadn't realized that WebTools got the work done to remove their dependency on the OmniSharp LSP dependency (which is different from "OmniSharp" BTW). That's great news. We should remove our reference to OmniSharp.Extensions.LanguageServer, so long as everyone in VS is on CLaSP. WRT System.Reactive, are there partners using that dependency implicitly because we're inserting in VS? We should get rid of that dependency. I don't think we want to be in the business of shipping things for other parties that we don't use ourselves.

Surely the other alternative fix, if WebTools isn't using it, is to not ship OmniSharp, and by extension System.Reactive, at all?
It seems very odd that we would bump the version of OmniSharp, so that we can bump the version of System.Reactive, and justify it as being safe by saying "nobody uses them". Why do they exist then? Seems like shipping a DLL we don't need, and causing problems for an unrelated team, is the definition of breaking into jail.

maybe the CI failure can be ignored, I see integration build failure


126 influence analysis

Closes #126
This includes:

Changes in requirements.txt
A summary of the method and how to implement it here
ai_genomics/analysis/influence/openalex_influence_analysis.py, the script that implements the analysis above (you can also use it as a rough tutorial for the topic modelling utilities below).
ai_genomics/utils/text_modeling.py, a script for text processing and fast topic modelling.
Changes in ai_genomics/getters/openalex.py to fetch the influence results from S3.

Checklist:

[x] I have refactored my code out from notebooks/
[x] I have checked the code runs
[x] I have tested the code
[x] I have run pre-commit and addressed any issues not automatically fixed
[x] I have merged any new changes from dev
[x] I have documented the code

[ ] Major functions have docstrings
[ ] Appropriate information has been added to READMEs

[x] I have explained the feature in this PR or (better) in output/reports/
[x] I have requested a code review

Thank you for your comments! I have...

put spacy in environment.yaml and removed it from requirements.txt
brought back get_openalex_entities

I explain above why I haven't implemented an ids getter (other than laziness :-D) but the idea is good and might come up down the line.

great! thanks for addressing those comments - feel free to merge.


Update README*.md files

This fixes the reference to git website in all README files. The current link is returning 404 status code.

Thanks @deniscapeto :+1:


How to know fetcher used my proxy or not?

Hello,
I wrote a script using my proxy to scrape a website as shown in below image:
How to know pyspider fetcher is using the proxy? I didn't find in the "active tasks" function.
Many thanks for your help,

self.crawl("http://httpbin.org/get")


zero balance neo after synchronization neogaz after synchronization appeared

That's my problem.
Theoretically NEO is on the purse. If you write the purse address in Neotraker, it shows them, but the purse does not display them. The transaction that was made from the wallet to the stock exchange is not in the block, but the transaction in the wallet is not confirmed, and this is not confirmed. Is there a way to cancel the transaction and return the coins to the wallet?
The instruction on this address did not bring the result https://steemit.com/cryptocurrency/@guppyken/neo-antshares-wallet-does-not-show-your-balance-this-may-help
address wallet Neotraker https://neotracker.io/address/ATQWSYvaRgb4gM8nNxZyFfimJb4spZhLCq
please, help! if you know how to help send detailed instructions with pictures

Its full sync? Then try rebuild the index on neo-gui. Wallet-> Rebuild index,
If not, open you wallet on neotracker and claim gas and sync your neo-gui


JBEHAVE-1477 Add ability to get ExamplesTable column values

In master https://github.com/jbehave/jbehave-core/commit/390e2a2bd3abcbe21dc082bc1128af3711b17fd2


Normalized environment variable

Define naming convention to distinguish settable by user variable and variable set by the system

Proposed convention: uppercase text surrounded with <>:
<REPLACE_ME>

I propose the following :

all variable should be lower camel case: myVariable
variable set by the user should start by a letter: userSettableVariable
variable set by the system should start by an underscore: _systemSettableVariable

applied to existing :
url => url
version => version
username => username
password => password
secret_token => secretToken
clientId => clientId
clientSecret => clientSecret
redirectUrl => redirectUrl
init_access_token => initAccessToken
site => site
key => to remove : seems to not be used
env => to remove : seems to not be used
orgId => _orgId
userId => _userId
endpoint => _endpoint
access_token => _accessToken
refresh_token => _ refreshToken

Sounds good, let's try to separate two concepts in docs: variables and placeholders.
Here's what I propose as definitions:

Variables are set in the Postman Environment dialog. This doesn't modify the requests. Syntax: we use the convention that you defined.
Placeholders are request parts that needs to be replaced with a value. This modifies the requests. Syntax: uppercase text with underscores surrounded with <>

Wonderfull !
I think we don't need to add placeholder in the template environment, they will be added when we set them in the code.
This way we expose the variable in the environment template and we let the scripts add the system one it requires :
url => url
version => version
username => username
password => password
secret_token => secretToken
clientId => clientId
clientSecret => clientSecret
redirectUrl => redirectUrl
init_access_token => initAccessToken
site => site
key => to remove : seems to not be used
env => to remove : seems to not be used
orgId => <ORG_ID> removed from template
userId => <USER_ID> removed from template
endpoint =>  removed from template
access_token => <ACCESS_TOKEN> removed from template
refresh_token => <REFRESH_TOKEN> removed from template
other set variable like jobId and batchId should be removed


Cleanup for GA launch of ReadChangeStream

This includes a series of small changes to release the connector:

Remove option for users to override heartbeat duration
Add option to skip creating metadata table and standalone utility to create metadata table
Add hard timeout to mutateRow requests as workaround for hanging requests
Remove excessive RCSP logging for debugging during preview
Increase read rows timeout to better accomodate large tables
Remove side effects from InitializeDoFn
Lower ReadChangeStream deadline to closer align with checkpoint duration
Add release note to CHANGES.md

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @pabloem

Run Java PreCommit

strange. I'll just reopen...

Run Spotless PreCommit

Run Java_Examples_Dataflow_Java11 PreCommit

reopening to trigger all tests

Run Java PreCommit

retest this please

fixes #27183

Tests all passed @pabloem @tonytanger let's get this in before release cut (tomorrow)

LGTM


No polling

[x] server changes
[ ] client changes

fixes #231

Let's close this PR. Once anyone starts trying to make a similar change they'll be able to see this closed PR linked from #231.