update to OPTEE 3.13.0

Hi @mssun,
I have upgraded the sdk to OPTEE 3.13.0. The changes are:

Upgrade optee submodules to 3.13.0 (optee_client, optee_os, build in optee/)
Modify Makefile in sdk
All the examples has been tested on OPTEE 3.13.0's Qemu emulator.

Best regards,
Rong Fan

Thanks. I believe the tests/screenlog.0 file is not needed.

Can you also update the getting started doc (docs/getting-started-with-optee-for-qemu-armv8.md)?

OK, these two files has been updated.

Do you know why the CI failed?

Sorry, it's my fault. I didn't pack qemu-system-aarch64 into optee-qemuv8-3.13.0.tar.gz. I repackaged the optee-qemuv8-3.13.0.tar.gz and trouble you to upload again.


Bump http-client version (actions#221)

Description:
Bump http-client version to 1.0.11 to fix proxy auth error
Related issue:
https://github.com/actions/setup-java/issues/221
Check list:

[ ] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.

Hello @pavelkrulec-ext96968. Thank you for your pull request. Could you please run the npm update @actions/http-client command with node 12 npm 6.* to regenerate package-lock.json and after that run the npm run build command to regenerate dist. Besides, you need to update licenses for http-client, you can see how it can be done in licensed.yml. If you need any help feel free to ping me.

Hello @dmitry-shibanov and thank you for your feedback! I've checked the license for http-client, updated version and licensed status now exits successfully.
I've also run the npm update @actions/http-client command with npm 6.14.15 (Node v12.22.6), however, it looks like this version of npm downgrades the version of package-lock.json from v2 to v1, see the new commit's diff. Is this desirable?
$ npm update @actions/http-client                                                                                
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+<EMAIL_ADDRESS>added 587 packages from 465 contributors and audited 593 packages in 12.971s

24 packages are looking for funding
  run `npm fund` for details

found 280 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details

Output of npm version 7.x looks much better.

Hello @pavelkrulec-ext96968. Thank you for your response. We'd prefer to stick with npm 6.x for now.
Thank you for your contribution.


APK

hi I was wondering i you still got the APK, or could share how/if you defeated the packager.
i'm trying to get some more details about its inner-workings and comms with the dongle, so i can (hopefully) use physical buttons to control the ui, basically like you use my own frontend to communicate with the dongle.
seems the APK i have is packaged with QiHOO, and my attemts to unpack it have failed so far.
cheers,

@VincentGijsen might I reproduce your actions on linux host to try to unpack APK?

hi @iDoka , I basically i used JDAX, but as the file is protected by an unpacker, you will get a very minimal sdk, and most stuff is encoded in a binary... lots of hassle,
I ended up searching for a pirated version of the dongle on the aliexpress sites... as all those vendors use their own link to a copy of the firmware on (as it seems) home-adsl connection, or something. Luckily for us those sellers of the pirated box didn't bother to add any form of protection, other than normal obfuscation by packing a APK.
As my intention is to use the official box, but with my own interface, to combine with another project.
I found on the usual chinese shopping sites an apk by the name of 'PhoneMirrorBox'

Yes, I used JADX on macOS, but the APK that came with my dongle wasn't protected in any obvious way. I included the link that was provided with my dongle in the "download assets" shell script here: https://github.com/electric-monk/pycarplay/blob/master/downloadassets.sh#L2


DROP SOURCE <name> CASCADE does not work

Describe the bug
The following statements are executed in order

trying to drop source

dev=> DROP SOURCE drivers;
ERROR:  QueryError: Permission denied: PermissionDenied: Fail to delete source `drivers` because 1 other relation(s) depend on it

trying to drop source using CASCADE mode, and the result shows no problem

dev=> DROP SOURCE drivers CASCADE;
DROP_SOURCE

show sources, seems the source still exists.

dev=> SHOW SOURCES;
  Name
---------
 drivers
 rides
(2 rows)

no jobs in progress

dev=> SHOW JOBS;
 Id | Statement | Progress
----+-----------+----------
(0 rows)

trying to drop the source again, got the same error, indicating the source still exists

dev=> DROP SOURCE drivers;
ERROR:  QueryError: Permission denied: PermissionDenied: Fail to delete source `drivers` because 1 other relation(s) depend on it

drop the mview depending on the source, and then run drop source again. The source is finally dropped

dev=> DROP MATERIALIZED VIEW driver_status;
DROP_MATERIALIZED_VIEW

dev=> DROP SOURCE drivers;
DROP_SOURCE

dev=> SHOW SOURCES;
 Name
-------
 rides
(1 row)

Error message/log
No response
To Reproduce
No response
Expected behavior
No response
How did you deploy RisingWave?
docker-compose
The version of RisingWave
dev=> SELECT version();
                                  version
----------------------------------------------------------------------------
 PostgreSQL 9.5-RisingWave-1.3.0 (c4c31bdc5e8763ae65ec23293e8c07bdfd4ab4df)
(1 row)

Additional context
No response

Could you please provide your concrete sqls, since I can't reproduce it. Recently we have a fix https://github.com/risingwavelabs/risingwave/pull/12745. But your version seems to have this fix.

Ping @mikechesterwang ?

Already fixed by https://github.com/risingwavelabs/risingwave/pull/12731


Missing GLES support

Strategically, this is a step towards supporting WebAssembly via Emscripten and creating 3D viewers in modern browsers.
PS: If I'm wrong about something, then correct me.

No, you are definitely right. Besides implementing the EGL support for Wayland this is another important issue that needs to be done to keep Coin alive and kicking :)

We have a showstopper here.

I have experience to port OpenGL ES 3.0 Programming Guide Sample Code to Emscripten. It uses both EGL and GLES API. But I don't have enough free time and knowledge of Coin architecture to apply this experience.

Unfortunately my OpenGL knowledge is very basic. I've had a look into the Coin wgl stuff but could not derive a proper schedule what needs to be done to implement egl bindings. That's why I marked this as help wanted. Sorry.

Anyone know of someone that could tackle this? If not, how to we proceed?

CC @wmayer @yorikvanhavre @realthunder @kkremitzki

@epuzanov has been kindly working on this and provided PR #470 for this. I have tested this and just merged with master.

I built FreeCAD (as a flatpak) with coin3d from master (commit 28ac68d3de1970b32fd9524ad1ba6d0a502b78f2), passing -DCOIN_BUILD_EGL=YES. On x86_64, no problem.
But on aarch64 (it's built with a Qt5 that only has GLES, and it's running on a RaspberryPi 4 64-bits), when I open a model I get this errors:
Coin warning in cc_glglue_instance(): Error when setting up the GL context. This can happen if there is no current context, or if the context has been set up incorrectly.
Coin warning in SoGLPolygonOffsetElement::updategl(): OpenGL driver doesn't support z-buffer offsetting

And then the display looks like this:

The GLES is not an EGL. The Coin3d library used an OpenGL API, some part of it must be rewritten to be compatible with OpenGL ES API. The EGL support is needed for compatibility with Wayland, because Wayland doesn't support GLX API.
Summary:
GLX (X11) -> EGL (Wayland)
OpenGL -> OpenGL ES (GLES)

Which I is I thought I had understood, but https://github.com/coin3d/coin/issues/449#issuecomment-1007506992 threw me off thinking it would work.
At least it no longer crashes, but that could be a different reason.
(yes the RaspberryPi still doesn't use Wayland/Weston)

@hfiguiere So it seems to be my fault. I thought it is something conntected to the EGL work. Sorry for the noise.

Any progress on this?

bump


chore(CHANGELOG): Add info about a backward incompatible change to Ec…

…to.Schema.Metadata.
@josevalim Let me know if you want to change any of the wording.

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


BugFix: Fix & enhance DAISY sampling from convoluted cubes collection.

This PR address:

Align numeric and performance indicators to original DAISY descriptor implementation.

(1) BugFix: Fix descriptor sampling in interpolated mode over convoluted collection of cubes. Sampling should be done properly over the convoluted cubes.
(2) Enhancement: Original, and actual compute_histograms() was ment to convert (h,y,x) to (y,x,h) for the descriptor sampler part. The (h,y,x) data order was used to perform inplace stacked convolutions (first one time) but then the (y,x,h) order is useful to do fast &memory aligned .ptr<float>(y,x,0)[h] like sampling for final descriptor (at any time).
All my apologies for letting this latent issue so long, now DAISY should be at full and original quality.

PR should include: https://github.com/Itseez/opencv_extra/pull/285 regression data.

:+1:


Some videos are unavailable

Hello~ Thanks for your great job~ But I found some videos are unavailable, can you provide them?  I think missing those files may lead to unfair comparsion. (209 videos have been sucessfully downloaded.)

YouTube videos might be removed by the uploader. In that case, we evaluate performance without them. (This is the conventional way of field.)
Also, I would like to share the dataset, but due to copyright issues, I cannot.


TLS error after Google automated update causes downtime

Bug Description
On 2 MySQL 5.7 instances in separate projects we had an "Update" operation automatically performed at 7am EST today. This aligned with an error we started receiving at the same time:
Reading data from project:region:db-name had error: remote error: tls: bad certificate

Restarting our Pods resolved the issue, I understand adding Kubernetes Probes to reboot the container would likely have minimized this issue to under a minute and am implementing them currently.
However, I'm curious if there's any way to avoid this altogether
Example code (or command)
# none

Stacktrace
Reading data from project:region:db-name had error: remote error: tls: bad certificate

How to reproduce

Google Automated Upgrade

Environment

OS type and version: debian
Cloud SQL Proxy version (./cloud_sql_proxy -version): 1.27 (Docker image latest)

Related: https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/400.

Also https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/980.

Out of curiosity are you using client-side connection pooling or similar to reconnect bad connections? We merged https://github.com/GoogleCloudPlatform/cloudsql-proxy/pull/817 thinking it would fix this problem.

@enocom I'm not 100% sure how to know that but judging off the managing connections documentation, I think we aren't.
We're using ruby (rails) and have the following setup:
production:
  adapter:  <%= ENV["DB_ADAPTER"] || 'mysql2' %>
  encoding: utf8
  host:     <%= ENV['MYSQL_HOST'] %>
  username: <%= ENV['MYSQL_USERNAME'] %>
  password: <%= ENV['MYSQL_PASSWORD'] %>
  database: <%= ENV['MYSQL_DATABASE'] %>
  port:     <%= ENV['MYSQL_PORT'] %>
  collation: utf8_general_ci
  pool: 10

Which doesn't have the socket setting set. The pool setting is also 2x higher then in the documentation, I'm not sure why someone set it to 10, all I can see in our git history is that it was bumped from 2

It's been awhile since I've worked with ActiveRecord and Rails, but it looks like other people have had similar problems. See https://github.com/rails/rails/issues/38324 for example and a proposed workaround which goes hand-in-hand with Kubernetes probes.
I suspect what's happening here is the connection pool (size 10) all go stale during the update operation. Rails doesn't reset any of the connections and continues trying to use bad connections. I imagine you're seeing the "bad certificate" error repeatedly in the proxy logs. Is that correct?
Since this appears to be an issue with how Rails handles connection pooling, I recommend adding a liveness healthcheck as a workaround as you suggest. In the meantime, I'm going to downgrade this to a P2 and investigate further.

Here's what I tried:

Started a simple Rails <IP_ADDRESS> app with a Cloud SQL MySQL database with RAILS_ENV set to production
Confirmed that my database connection worked with the proxy running locally
Stopped my database and confirmed the database connection was broken
Started the database and confirmed I could connect with the mysql CLI and also the app without restarting the proxy.

In addition to stopping and starting the database, I also tried rotating the server CA cert and triggering a failover. In all cases, the app and the CLI managed to get a new connection without error. So it seems that Rails isn't holding on to stale connections. Likewise, at least in these cases, the proxy recovers without issue.
In https://github.com/GoogleCloudPlatform/cloudsql-proxy/pull/995, I added support for a liveness probe that checks the validity of all cached connections. If the probe fails, Kubernetes will restart the pod. Without steps to reproduce, I think it's best to add a liveness probe to cover this case and close this issue for now.
If you are able to reproduce this, please re-open this and I'll dig in further.

On second thought I’m a little disturbed that this error has popped up in the latest version. I’m going to re-open this.

I just saw this happen today as well, running gcr.io/cloudsql-docker/gce-proxy:1.26.0-buster@sha256:9c9ad91f5a353d71d0815cf9206ee320af7227919005972090f59a07405d2566.
Our application is written in Go.
The database (mysql) upgraded.
We saw the same errors in one of our ~60 pods and they lasted 7 hours before recovering on their own.

We suspect this issue will be resolved as part of the v2 release. I'm going to leave this open in case anyone else has additional reports.

Hi @vikstrous2 and @fbongiovanni29 - are you folks still seeing this issue? If so, can you try to provide some logs of when the proxy does this?
Our understanding is that the proxy should be performing a new refresh and the dial should work after that. You shouldn't been seeing any prolonged instances of this error in recent versions.

Just got hit by this. After a maintenance event, it was not possible to connect to the instance using any Cloud SQL Auth proxy on any machine that previously connected to it. Is it possible that it maintains some kind of cache?
First there were some certificate errors and then:
SQL error logs showed: "Got an error reading communication packets"
From service side: "Connection lost: The server closed the connection."
On the other hand, our services written in Java that use JDBC driver (no Google SQL Auth proxy) continued to work fine.
This continued to happen for two days and Google Cloud support hasn't been of any help.
Then magically, when I connected to a different instance, and back to the problematic instance, it worked again.
What the heck??

...Also I am interested how best to fix this in the future? (I am not an MySQL expert). Thanks!

Scratch that, the problem is with -enable_iam_login flag. Not sure what changed, but suddenly if this flag is passed it is not possible to connect to MySQL 5.7 instances.

Now that v2 is in preview, I'll test to see if we can close this out.

This is what I tried with both the v1 and the v2 proxies:

Start up the proxy pointing at my Postgres instance
Connect an app that reads the time from the database using database/sql (a connection pooled interface)
Curl the app's endpoint every 1s
Reset the instance's SSL configuration (docs).

This is what I saw in both versions:

The proxy loses a connection to the instance with a connection reset by peer error
The app loses the connection
The app's connection pool creates a new connection
The proxy connects successfully with a valid SSL configuration.

So, this seems consistent with my earlier comment. So I'm going to close this and assume the issue has been fixed. Note: the v2 proxy is still in public preview (with a GA launch planned early next year), but it's worth trying out as it's a more stable version of the v1 proxy.


ActiveRecord Magic and ?? operator

What steps will reproduce the problem?
class Item extends yii\db\ActiveRecord {
    public function getList()
    {
        return [1, 2, 3 / 0]; // division by zero!
    }
}

$list = $item->list ?? [];
var_dump($list); // array(0) {}  where is exception?
$list = $item->getList() ?? []; // exception - ok

What is the expected result?
$list = $item->list ?? []; // Exception division by zero

What do you get instead?
$list = $item->list ?? []; // array(0) {}

Additional info
Reason in:
https://github.com/yiisoft/yii2/blob/master/framework/db/BaseActiveRecord.php#L336-L342
?? - operator first make isset(), so it calls __isset(), which suppresses errors.
The problem is that it is very difficult to detect an error, because they are suppressed.

Q
A

Yii version
all

PHP version
7.0

Operating system
all

Any proposal on how to possibly fix that?

@samdark how about this?

I agree with the fact that this is not desirable behavior, but changing it is a big break in backwards compatibility.

I agree that changing behavior is dangerous, and can reveal some problems in existing projects. But complete suppression without logging is also bad.

I agree, logging is fine and doesn't change behavior. Or direct your PR at 3.0 and fix the behavior :-D


Update docs for pinot support

I have pushed pinotdb 0.2.2 to Pypi and with that the trunk version of superset can talk to Pinot now too.

Codecov Report

Merging #6865 into master will increase coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6865      +/-   ##
==========================================
+ Coverage   56.22%   56.31%   +0.09%
==========================================
  Files         527      527
  Lines       23529    23529
  Branches     2782     2782
==========================================
+ Hits        13229    13251      +22
+ Misses       9888     9866      -22
  Partials      412      412

Impacted Files
Coverage Δ

superset/views/core.py
75.01% <0%> (+0.28%)
:arrow_up:

superset/models/core.py
83.56% <0%> (+0.62%)
:arrow_up:

superset/db_engine_specs.py
53.82% <0%> (+1.84%)
:arrow_up:

Continue to review full report at Codecov.

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

cc: @betodealmeida @mistercrunch, I swear this is totally safe to accept :-)

+1


[IMPROVEMENT] Migrate PodSecurityPolicy to support K8s 1.25

Is your improvement request related to a feature? Please describe
PodSecurityPolicy will be deprecated from K8s 1.25, so we need to find an alternative way to resolve the need for PSP in Longhorn to support 1.25.
Describe the solution you'd like
Deprecate PSP if it's not needed. Otherwise, we need an alternative solution like https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/.
Describe alternatives you've considered
N/A
Additional context
https://www.kubernetes.dev/resources/release/#timeline

This needs to consider to backport.

This was released in Longhorn v1.2.5-rc1 release but not in Longhorn v1.2.5 release. Is there an ETA for an official release?

This was released in Longhorn v1.2.5-rc1 release but not in Longhorn v1.2.5 release. Is there an ETA for an official release?

It was wrongly mentioned in the rc release note. It is planned for 1.4.0 instead, the end of this year.

dont' forget CronJobs #4490 (comment)

Thanks :+1: , all deprecated resources will be taken care of together.

I managed to upgrade to kubernetes 1.25 on several nodes before I noticed the issue, so I'm hoping a release comes out that will handle that version as rolling back isn't an option.

@skandragon I have exactly the same problem too. However, I cannot wait until the end of the year and unfortunately have to set up the cluster again.

It was wrongly mentioned in the rc release note. It is planned for 1.4.0 instead, the end of this year.

Are you sure about this scheduling, by the end of the year 1.26 (Tuesday 6th December 2022) will be out?

Knowing people are eager for this, but for now, the plan is still the same, because Longhorn has its release scope and cadence.
Please keep following up on the update here, and we will work on this soon or later.

@innobead what is required to do beyond just changing the API calls?  I know that means version 1.3 would be locked to 1.25 or higher; the better option is likely to try to use the proper API calls depending on what version was in use, I suppose?
I know I was able to just change the betav1 magic to v1 and it just worked as far as I could tell.
A bigger issue for me with longhorn is unrelated, and that's that it won't run under Talos.  :/

Just want to mention that the wording of the issue is misleading.

PodSecurityPolicy will be deprecated from K8s 1.25 [...]

PodSecurityPolicy has been deprecated since K8s 1.21 and will be removed in 1.25.

That's really unfortunate, Longhorn will be unusable by the most recent Kubernetes release for the next two months.
I encourage you to reconsider this release plan.

I just hit this issue on k3s (latest channel) and needed to revert to 1.24 (where other coredns bug is present)
This should happen ASAP because 1.25 is on the way and any service based on longhorn will fail :(

Why we need PSP before?
If the cluster admin enables PSP admission controller, the default behavior was to block any pod that doesn't have a PSP associated with them. That was the reason Longhorn ship the longhorn-psp
So, now that PSP is removed, we can just remove the PSP template. Similar to how Calico did https://github.com/projectcalico/calico/pull/6270
Kubernetes provide a new mechanism, Pod Security Admission. Does Longhorn need to do anything?

The way that Pod Security Admission works is by having users to annotate the target namespace with annotations to specify the blocking criteria, example. By default, it doesn't block pods in a namespace, link
If the users change the default behavior to block privileged pods, it is the responsibility of the users to add the correct annotation to the namespace that is running Longhorn pods to allow Longhorn pods to start (because Longhorn pods require privileged access to manage storage). Longhorn doesn't manage namespace resources so Longhorn doesn't need to take action here.
In conclusion, Longhorn doesn't need to take action here other than document that If user enabled Pod Security Admission and users change the default behavior to block privileged pods, the users to add the correct annotation to the namespace that is running Longhorn pods to allow Longhorn pods to start (because Longhorn pods require privileged access to manage storage)

Test plan:
Case 1: in Kubernetes 1.24 with PSP admission controller enabled

Remove longhorn-psp and deploy Longhorn, Longhorn pods should fail to come up
Add longhorn-psp back, Longhorn pods should fail to come up

Case 2: in Kubernetes 1.25 with Pod Security Admission enabled

Remove longhorn-psp template
Deploy Longhorn, Longhorn pods should come up

Case 3: in Kubernetes 1.25 with Pod Security Admission enabled

Remove longhorn-psp template
Change the default behavior of Pod Security Admission to block privileged pods
Deploy Longhorn, Longhorn pods should fail to come up

Case 4: in Kubernetes 1.25 with Pod Security Admission enabled

Remove longhorn-psp template
Change the default behavior of Pod Security Admission to block privileged pods
Annotate longhorn-system namespace with correct permission
Deploy Longhorn, Longhorn pods should fail to come up

I need this ASAP as well :)

Why this can not be backported to 1.3 or 1.2?
Basically, it's because CronJob and PSP v1 are only available since 1.21, but batch/v1beta1 and policy/v1beta1 have been removed from 1.25. So, if backport this fix, that means we need to update the K8s min version for existing release branches 1.3 and 1.2 from 1.18 to 1.21; However, this will not conform to our release branch policy w/ the same K8s version range for the following patch releases of already released branches.
@PhanLe1010 Please correct me if anything is missing or incorrect.

Something along the lines of
if kubernetes.version >= 1.25 {
imPDBs = make(map[string]*policyv1.PodDisruptionBudget)
} else {
imPDBs = make(map[string]*policyv1beta1.PodDisruptionBudget)
}

@warrenrees I wish it was that simple. However, we have controllers with listers/informers that notify and cache the objects into the local caches. For example, for the cronjob it is https://github.com/longhorn/longhorn-manager/blob/15f850c6937a1eedb5667dfc775c1b7037b45b9c/datastore/datastore.go#L70-L71. I am not sure how to easily/cleanly solve this dynamic multi-typed problem.

Yeah I see the conundrum... short of adding another entry into the DataStore struct (cjListerV1   batchlisters_v1.CronJobLister) and some logic in the NewDataStore function, it gets complicated fairly quickly.
Sorry just trying to brainstorm how to fix this without having to wait 2 months.  I have 2 of 5 nodes down in my K8s cluster and I don't particularly want to rebuild it :)
Thank you guys for all your hard work, I love longhorn it's a great storage solution!

Are there any updates? I read enough to start with Longhorn, and then that disappointing moment came, I cannot use it with 1.25 K8s.

Is it for testing or production use @MohammedNoureldin ?
This one will take sometime until we release Longhorn v1.4.0. But if you are just testing, you can use master-head kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

Thanks for the almost immediate reply, @PhanLe1010!
Is there any nightly built Helm chart to be installed?

Here is it https://github.com/longhorn/longhorn/tree/master/chart
This chart will track master-head which is the latest and unstable version.

(subjected to change any time)

I know that you mean to an earlier date ;)
Maybe not really relevant question, but adding a GitHub repo and installing this chart is not really something that works out of the box, and no link online helped so far. Could you summarize that in 2 lines of bash commands?

The bash command would be like
git clone https://github.com/longhorn/longhorn.git && cd longhorn && helm install longhorn ./chart --namespace longhorn-system --create-namespace
Another alternative is kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

Oh, thanks! I thought it is possible to install it using Helm from a GitHub repo on the fly, but it turned out that I need to clone it. I will try it now. Thanks a lot!

I just want to confirm that the helm chart @ master works excellently on Kubernetes 1.25.3 with the default settings. I am now waiting for the release 1.4.0

Case 1: within a Kubernetes version

[ ] Test basic recurring snapshot/backup jobs are working correctly

Kubernetes Version
Pipeline Link
Verify Result

v1.25.3+k3s1
Verified on local environment
:heavy_check_mark:

v1.24.7+k3s1
https://ci.longhorn.io/job/private/job/longhorn-tests-regression/2239/
In Progress

v1.23.1+k3s2
https://ci.longhorn.io/job/public/job/master/job/sles/job/amd64/job/longhorn-tests-sles-amd64/292/testReport/tests/test_recurring_job/
:heavy_check_mark:

v1.22.15+k3s1
https://ci.longhorn.io/job/private/job/longhorn-tests-regression/2238/
In Progress

v1.21.10+k3s1
https://ci.longhorn.io/job/private/job/longhorn-tests-regression/2237/
In Progress

[x] Test generating support bundle generation. Make sure that the above jobs are in /yamls/kubernetes/cronjobs folder

Kubernetes Version
Verify Result

v1.25.3+k3s1
:heavy_check_mark:

v1.24.7+k3s1
:heavy_check_mark:

v1.23.13+k3s1
:heavy_check_mark:

v1.22.15+k3s1
:heavy_check_mark:

v1.21.10+k3s1
:heavy_check_mark:

[ ] Test upgrade Longhorn from 1.3.2 or v1.2.5 to master

Test basic functionalities (workload, upgrade engine image, replica rebuilding)

Kubernetes Version
Upgrade from v1.3.2
Upgrade from v1.2.5

v1.25.3+k3s1
NA
NA

v1.24.7+k3s1
:heavy_check_mark:
:heavy_check_mark:

v1.23.13+k3s1
:heavy_check_mark:
:heavy_check_mark:

v1.22.15+k3s1
:heavy_check_mark:
:heavy_check_mark:

v1.21.10+k3s1
:heavy_check_mark:
:heavy_check_mark:

Verify CSI snapshot upgrade

Kubernetes Version
Verify Result

v1.25.3+k3s1
NA

v1.24.7+k3s1

v1.23.13+k3s1

v1.22.15+k3s1

v1.21.10+k3s1

[x] Test zone and topology,

Kubernetes Version
Verify Result

v1.25.3+k3s1
:heavy_check_mark:

v1.24.7+k3s1
:heavy_check_mark:

v1.23.13+k3s1
:heavy_check_mark:

v1.22.15+k3s1
:heavy_check_mark:

v1.21.10+k3s1
:heavy_check_mark:

[x] Test uninstallation

Kubernetes Version
Verify Result

v1.25.3+k3s1
:heavy_check_mark:

v1.24.7+k3s1
:heavy_check_mark:

v1.23.13+k3s1
:heavy_check_mark:

v1.22.15+k3s1
:heavy_check_mark:

v1.21.10+k3s1
:heavy_check_mark:

Case 2: Test a Kubernetes version upgrade

[x] Update from v1.24.7+k3s1 to v1.25.3+k3s1 and workload still working properly

Install Longhorn master in Kubernetes v1.24 cluster
Create some workload, Longhorn volumes, cronjobs, etc...
Upgrade Kubernetes to v.125
Verify that Longhorn is running ok. Basic functionality is working ok

@chriscchien Could you just test one more scenario, deploying Longhorn on a hardened cluster?

Head Chart installs perfectly and everything looks fine

and some how installing longhorn crashed treafik in my k3s cluster

Hi @khushboo-rancher ,
I tried deploy Longhorn master on hardened cluster but the deploy not scuccessed.
Deployment longhorn-driver-deployer raised error and most Longhorn component pod not deployed
[FailedCreate] pods "longhorn-driver-deployer-f9546bd9b-" is forbidden: PodSecurityPolicy: unable to admit pod: [spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden spec.containers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden]

Hi @khushboo-rancher ,
I tried deploy Longhorn master on hardened cluster but the deploy not scuccessed. Deployment longhorn-driver-deployer raised error and most Longhorn component pod not deployed
[FailedCreate] pods "longhorn-driver-deployer-f9546bd9b-" is forbidden: PodSecurityPolicy: unable to admit pod: [spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden spec.containers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden]

@chriscchien Would you mind to share the test steps here?

Probably need to enable the PSP on this hardened cluster. Switch this field to true https://github.com/longhorn/longhorn/blob/23d264196f6bfdc4928b333e49b30b6c29ad417e/chart/values.yaml#L253-L255

Using helm to install Longhorn master head by command helm install longhorn ./chart -n longhorn-system which enablePSP set to true can deploy/uninstall Longhorn and workload worked well on the hardened cluster
But there is no PSP field exist in master-head's longhorn.yaml, does this mean currently we can not use kubectl to deploy Longhorn on hardened cluster? thank you
cc @khushboo-rancher,  @yangchiu

longhorn.yaml is generated by running helm template . The default Helm value enablePSP is false so it Helm template does not generate PSP yaml into longhorn.yaml. This behavior is expected because we are moving away from PSP. However, it is a bit incovinent for the user using old hardened cluster with PSP enable, therefore we have 2 options:

Document and pointing the user to PSP yaml
Put the PSP yaml under comment section into the longhorn.yaml. This method would require us to modify the generate-longhorn-yaml.sh

For use kubectl to deploy Longhorn, I tried add below section into longhon.yaml to deploy but still have problem in longhorn-driver-deployer

You also need to add PSP into longhorn-service-account. AKA, you need to put this whole section into longhorn.yaml

Thank you @PhanLe1010 ,
Deploy Longhorn on hardened cluster by kubectl and helm all worked well( including steps install, create/scale workload, and uninstall).

longhorn.yaml is generated by running helm template . The default Helm value enablePSP is false so Helm template does not generate PSP yaml into longhorn.yaml. This behavior is expected because we are moving away from PSP. However, it is a bit inconvenient for the user using old hardened clusters with PSP enabled, therefore we have 2 options:

Document and pointing the user to PSP yaml
Put the PSP yaml under the comment section into the longhorn.yaml. This method would require us to modify the generate-longhorn-yaml.sh

cc @innobead Which option would you suggest from PM perspective?

I think we need to do both for users who use kubectl to apply the manifest directly. If in the future, it becomes complicated, we can use kustomize instead, but right now it's enough to have a separate manifest for < 1.25.
@PhanLe1010 Could you help with this? Thanks.

In addition, tested upgrade Longhorn from old release to v1.40-rc1 then upgrade Kubernetes version to v1.25
Below scenario were all passed
In v1.24.7+k3s1

[ ] Upgrade Longhorn from v1.2.6 to v1.4.0-rc1 then upgrade kubernetes to  v1.25.4+k3s1
[ ] Upgrade Longhorn from v1.3.2 to v1.4.0-rc1 then upgrade kubernetes to v1.25.4+k3s1

In v1.23.11+k3s1

[ ] Upgrade Longhorn from v1.2.6 to v1.4.0-rc1 then upgrade kubernetes to v1.25.4+k3s1
[ ] Upgrade Longhorn from v1.3.2 to v1.4.0-rc1 then upgrade kubernetes to v1.25.4+k3s1


use const instead of var for nodejs

(just driving by) The *.baseline files also have to be updated. An easy way to do that is to run the unit tests locally, and failing baselines will be spit out in /tmp/com.google.api.codegen_testdata/. Copy over the new baselines from there into their appropriate location in /usr/local/google/home/andrealin/Documents/git/veneer/toolkit/src/test/java/com/google/api/codegen/testdata/...

Codecov Report

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

@@            Coverage Diff            @@
##             master    #2267   +/-   ##
=========================================
  Coverage          ?   86.75%
  Complexity        ?     5134
=========================================
  Files             ?      452
  Lines             ?    20392
  Branches          ?     2190
=========================================
  Hits              ?    17691
  Misses            ?     1930
  Partials          ?      771

Continue to review full report at Codecov.

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


An Azure AD attached resource does not auto display broken after removing its associated account

Storage Explorer Version: 1.19.1
Build Number: 20210417.6
Branch: hotfix/1.19.1
Platform/OS: Windows 10/ Linux Ubuntu 16.04/ MacOS Catalina
Architecture: ia32/x64
Regression From: Previous release (1.18.1)
Steps to Reproduce

Select one queue -> Give a RBAC role to it then assign to one account.
Sign in with the account -> Attach the queue via Azure AD.
Go to 'ACCOUNT MANAGEMENT' panel -> Remove the account.
Click 'Open Explorer' -> Check whether the Azure AD attached queue shows broken.

Expected Experience
The queue shows broken.
Actual Experience

The queue does not show broken.
The queue shows broken after manually refreshing.

Additional Context

This issue also reproduces for Azure AD attached blob containers.
The broken Azure AD attached resources do not auto fix after sign-in back the removed account.

The "Blob Containers" and "Queues" nodes under "Attached Containers" should now refresh after leaving the account panel (every time).


New command: remove external connection

Usage
m365 external connection remove [options]
Description
Removes external connection
Options

Option
Description

-i, --id <id>
The ID of the external connection to remove

-f, --force
Don't prompt for confirmation

Examples
Removes the external connection with the specified ID. Will prompt for confirmation
m365 external connection remove --id contoso

Removes the external connection with the specified ID without prompting for confirmation
m365 external connection remove --id contoso --force

Default properties
No response
Additional Info
Uses the following endpoint: https://learn.microsoft.com/en-us/graph/api/externalconnectors-externalconnection-delete?view=graph-rest-1.0&tabs=http

@pnp/cli-for-microsoft-365-maintainers any feedback before we open it up?

We've got this already


Add Language on Navigate & Views

Do you want to request a feature or report a bug?
Feature
Can you assign to me, I want to make tihs feature
What's the current behavior?
Interfaces gives static string,

export interface Navigate {
    PREVIOUS: 'PREV';
    NEXT: 'NEXT';
    TODAY: 'TODAY';
    DATE: 'DATE';
}
export interface Views {
    MONTH: 'month';
    WEEK: 'week';
    WORK_WEEK: 'work_week';
    DAY: 'day';
    AGENDA: 'agenda';
}

What's the expected behavior?
Adding Language props on HOC to change Navigation and Views
<Calendar language='tr / en / es' String />

bar

messages= {
    allDay:"",
    previous:"",
    next: "",
    today: "",
    month:"",
    week: "",
    day: "",
    agenda: "",
    date: "",,
    time:"",
    event:"",
    showMore: (total) => `+ ${total}
}

Solved 👍

Tanks!
Have to close this issue!

Is there a way to modify language of shown month, too?
(January, February, March, .....)

Is there a way to modify language of shown month, too?
(January, February, March, .....)

You can use culture props.
        <Calendar
          localizer={localizer}
          events={events}
          culture="pt"
          startAccessor="start"
          endAccessor="end"
          style={{ height: 500 }}
        />

Is there a way to modify language of shown month, too?
(January, February, March, .....)

You can use culture props.
        <Calendar
          localizer={localizer}
          events={events}
          culture="pt"
          startAccessor="start"
          endAccessor="end"
          style={{ height: 500 }}
        />

Thank you, but, unfortunately, nothing change! The names of months and days keep english.


refactor: periphery contracts refactor/cleanup

Configure and run forge fmt
Check formatting in CI
Use named imports
Remove extra balanceOf check in UniswapWithdrawHook.tokensWithdrawn()

@apbendi re forge fmt changes, are you on the latest forge version? Given the CI passes and it uses the most recent version I suspect yours may be outdated (unless forge fmt changed since CI was ran)


Remove AdditionalProperties from model structs as it is not used by Cockroach Cloud API

Removed AdditionalProperties field from all the model struct generated by Go SDK

LGTM!


Fix for callback flow to fix #86

This PR fixes issue with the callback flow of client.capture* functions where it now gets called after the transporter has finished sending the logs to server.
Case in point:
The following code does not work since process.exit() kills all ongoing transports.
client.captureError(err, {}, function () {
    process.exit(1);
});

This PR fixes this.

Hey @shamasis, this is actually an intentional decision and documented on how to handle it with events: https://github.com/getsentry/raven-node#events
There's an explicit reason why it's being done the way it is.
Is there some reason that the events can't cover your use case?

I would appreciate to know the reason for this code flow. As far as I see, using the events would result in using a very convoluted code flow.

captureError
on callback of capture error set a flag that an error has been captured
wait for logged or error to happen once on client
on those event of previous point, exit process.

It would be super tedious to carry around the client across all modules and our internal middlewares.

We needed to return back an event id. This is similar to how the client works in other languages. We can return back an event id before the error is actually transmitted. The event id is calculated by the client.
Unfortunately, in node, the calculation of this event id requires reading files from disk, which need to be done in an asynchronous manner, which means, we need to leverage a callback instead of simply returning.
Ideally, the API would look like:
var eventId = client.captureError(...);

But that doesn't work. So I opted to make the event id be the callback. And the source of the error being actually transmitted or not, be dictated by the events being broadcast.
It's much less common for a developer to care when the event was actually transmitted successfully or not.
Typically, this is relevant for inside of an HTTP request and being used as a middleware, so exiting the process is not desirable. In the case where we do want to exit, say, in patchGlobal, the patchGlobal callback actually does trigger after the error has been transmitted, as documented here: https://github.com/getsentry/raven-node#catching-global-errors
You can also see how patchGlobal is implemented to produce the same thing on your end using normal captureError, etc: https://github.com/getsentry/raven-node/blob/master/lib/client.js#L163-L204

Appreciate the explanation. In other words, the eventId first approach is to better suit a more dominant use-case of raven. Understandable. This makes it do a lot of rewrites, like I mentioned. (Our use case is not similar to patchGlobal and is very specific to our code.)
Why did you not choose to resolve two async (transport + file read) and execute the callback with both? And does the code changes suggested by me break any future plans (I will not ask "what") :smile: ?

In other words, the eventId first approach is to better suit a more dominant use-case of raven.

Correct.

Why did you not choose to resolve two async (transport + file read) and execute the callback with both?

Because we don't like to tie resolving an event id to the actual network transfer. Typically, this event id is utilized to render onto a page or something like that, and we don't want the sentry server to impact any flow. If the sentry server was unreachable, or network unstable and say, it took 5 seconds to send, I wouldn't want the client to delay 5 seconds just to render a 500 error page.
This could be encapsulated in some sort of promise though, but that'd probably require a bit more work. :)
Does this all make sense?

Sure. Having the promises would be exciting.
Keep up the great work. :smile:

I don't understand this quote:
Unfortunately, in node, the calculation of this event id requires reading files from disk
Looking at the source, event_id is generated from a uuid, then set as ident.id, and in getIdent function it just returns ident.id?
kwargs.event_id = uuid().replace(/-/g, '');
...
var ident = {
    'id': kwargs.event_id
  };
...
proto.getIdent =
  proto.get_ident = function getIdent(result) {
    return result.id;
  };

The only thing that seems to prevent a synchronous return of the event id is that parsing is done before event id generation, something that probably is switchable.

Yeah, sorry, I misspoke. The problem is order of operations as you pointed out. We parse the stacktrace which requires reading files from disk first, before assigning the event id.

But is that really necessary? The most important thing to return when capturing errors is as I've understood, it, the event ID. The other stuff seems kind of redundant, and mostly for internal use.

Likely not. This code is also super old, so it'd require looking into since I made an explicit decision here long ago, but maybe these constraints aren't required anymore as things have changed over the years.


Created and implemented animations for StunTower and FireTower.

Created the StunTower and FireTower in TowerFactory. Also implemented the relevant components and animations for the added towers.

Looks good, no obvious issues


Add severity column to vulnerability list

Issue: #2255

LGTM

This adds more width to our page :/ Should we evaluate removing some other columns first?

e.g. fix available, and versions probably isn't that useful.

Hey @ZhangChen199102 , thanks for implementing this feature! After discussing with the team, we have some thoughts on this change:

Instead of adding a new column for the severity score, we can just move it into the "Fix Available" column and making it more of an "Attributes" column. This can reduce the number of columns and allow us to easily add other tags in the future.
the current severity tag colour makes the text a bit hard to see. Maybe we can just use a white tag with black text, displaying the information like "Severity - 5.4 (MEDIUM)"?
the "Affected versions" listed here aren't adding much information and make the page looks a bit crowded. We can remove this column entirely from https://osv.dev/list (this can be done in a separate PR, and it would also automatically resolve https://github.com/google/osv.dev/issues/2286)

Looks really good! Can you also try keeping the color, but for the darker colors have the text color switch from black to white to make it easier to read? I'm not sure if we'll go with that, but I think it would be nice to compare.

With the current colors, switching the text color to white instead of black actually fails the contrast ratio for accessibility (checked using this tool).
I’ve attached a sample output for reference, showing how the text looks with white colors on these backgrounds. Additionally, I’ve attached a photo demonstrating the appearance with black text on these colors.
As another alternative, I’ve used red-themed colors for high and critical severities to maintain the contrast.
Sample output with white text on colors( fails accessibility checks )

Black and white text on colors ( passes accessibility checks )

Red-themed colors for medium high and critical severities

I personally prefer the middle option, though can you try switching the orange (High) text color to white instead of black?

I personally prefer the middle option, though can you try switching the orange (High) text color to white instead of black?

+1, I also think the middle one looks better. The third one has a pink colour, which is the same as our "no fix available" tag.

I personally prefer the middle option, though can you try switching the orange (High) text color to white instead of black?

@another-rex, unfortunately, using white on orange fails the accessibility contrast checks. the result is in demonstrated on pic1 in my previous comment.

Here is the updated colours:


Timed out waiting for response from TWCManager script

Hello, I'm still a freshman in programming. Have the TWCManager installed according to the instructions. When I go to the website, I get the following error: "If the script is running, make sure the $ twcScriptDir parameter in the source of this web page points to the directory containing the TWCManager script.". I checked the parameter and am of the opinion that everything is correct. What can I do to solve the problem?

do you see the script running when you type "screen -r" on the rpi?

Hello,
I do not see a script when I enter "screen -r". I get the answer "There is no screen to be resumed." Did the installation as in your description again. I checked the file in the folder home / pi / TWC / index.php, is that correct? Does it make a difference if I set the country code to DE UTF -8?
Von: flodorn<EMAIL_ADDRESS>Gesendet: Mittwoch, 10. April 2019 22:17
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
do you see the script running when you type "screen -r" on the rpi?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-481845706 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVqdqr-JAJMgCWmHByPNNY5LloSOLks5vfkbSgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

This means the script isn't running on the rpi and you have to set it up properly first. It is not an issue of changing the country code.
Try running the script manually by typing "python3 TWC/TWCManager.py". If this works, you probably didn't setup the autostart bit properly.

ok, the program says that the TWC is set as the master. The rotary switch is at F.
pi@TWCManager:~ $ python3 TWC/TWCManager.py
TWC Manager starting as fake Master with id 7777 and sign 77
09:28:02: Send master linkready1
09:28:02 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
09:28:02: Send master linkready1
09:28:02 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
09:28:02: Send master linkready1
09:28:02 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
09:28:02: Send master linkready1
09:28:02 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
09:28:02: Send master linkready1
09:28:03 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
09:28:03: Send master linkready2
09:28:03: 32.00 amp slave TWC 02BB is ready to link.  Sign: 2D
09:28:03: Set slave TWC 02BB protocolVersion to 1, minAmpsTWCSupports to 5.
09:28:03: Send master linkready2
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:03: Send master linkready2
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:03: Send master linkready2
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:03: Send master linkready2
09:28:03: SHB 02BB: 02 00.00/00.00A 0000  M: 05 00.00/00.00A 0000
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:03: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:04: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:05: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:05: SHB 02BB: 00 00.00/00.00A 0000  M: 05 00.00/00.00A 0000
09:28:06: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:07: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:08: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:09: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:10: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:11: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:12: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:13: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:14: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:15: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:16: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:17: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:18: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:19: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:20: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:21: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:23: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:24: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:25: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:26: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:27: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:28: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:29: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:30: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:31: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:32: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:33: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:34: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:35: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:36: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:37: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:38: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:40: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:41: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:42: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:43: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:44: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:45: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:46: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:47: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:48: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:49: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:50: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:51: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 05 00 00 00 00 00 00 00 00 90
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
09:28:52: WARNING: We haven't heard from slave 02BB for over 26 seconds.  Stop sending them heartbeat messages.
09:29:03 ERROR: Can't determine current solar generation from:
Von: flodorn<EMAIL_ADDRESS>Gesendet: Donnerstag, 11. April 2019 08:53
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
This means the script isn't running on the rpi and you have to set it up properly first. It is not an issue of changing the country code.
Try running the script manually by typing "python3 TWC/TWCManager.py". If this works, you probably didn't setup the autostart bit properly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-481989579 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVuOpOMyocKeKJgPf2M2aDCmOSb0nks5vftvEgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

It looks like your wall connecter is set to master, not slave. You should disconnect the power and check that the rotary switch and dip switch are set correctly, see installation manual: https://www.tesla.com/sites/default/files/pdfs/wall-connector-eu/20161208/tesla-32a-wall-connector-installation-manual-en-EU-v2.pdf?201612081439

The connector is set to slave.
Von: flodorn<EMAIL_ADDRESS>Gesendet: Donnerstag, 11. April 2019 09:55
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
It looks like your wall connecter is set to master, not slave. You should disconnect the power and check that the rotary switch and dip switch are set correctly, see installation manual: https://www.tesla.com/sites/default/files/pdfs/wall-connector-eu/20161208/tesla-32a-wall-connector-installation-manual-en-EU-v2.pdf?201612081439
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-482008744 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVm0lst62_zJa12-9AA5BGVyoa0W6ks5vfuphgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

Could be an issue with the wall connector. I'd set debugLevel to 11 in TWCManager.py and try different rotary switch positions on the wall connector to see which messages you get. Don't forget to power off the wall connector before making changes on the rotary switch.
Tx@ is for messages you send to your wall connector
Rx@ is for messages you receive
You could also try to run TWCManager as slave to see if this works.

I also set the debug level to 11. Enclosed the protocol
pi@TWCManager:~ $ python3 TWC/TWCManager.py
TWC Manager starting as fake Master with id 7777 and sign 77
10:48:38: Send master linkready1
Tx@10:48:38: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0
Rx@10:48:38: () FC E1 77 77 77 00 00 00 00 00 00 00 00 46
10:48:38 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
10:48:38: Send master linkready1
Tx@10:48:38: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0
Rx@10:48:38: () FC E1 77 77 77 00 00 00 00 00 00 00 00 46
10:48:38 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
10:48:38: Send master linkready1
Tx@10:48:38: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0
Rx@10:48:38: () FC E1 77 77 77 00 00 00 00 00 00 00 00 46
10:48:38 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
10:48:38: Send master linkready1
Tx@10:48:38: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0
Rx@10:48:38: () FC E1 77 77 77 00 00 00 00 00 00 00 00 46
10:48:38 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
10:48:38: Send master linkready1
Tx@10:48:38: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0
Rx@10:48:39: () FC E1 77 77 77 00 00 00 00 00 00 00 00 46
10:48:39 ERROR: TWC is set to Master mode so it can't be controlled by TWCManager.  Search installation instruction PDF for 'rotary switch' and set switch so its arrow points to F on the dial.
10:48:39: Send master linkready2
Tx@10:48:39: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0
Rx@10:48:39: () FB E2 77 77 77 00 00 00 00 00 00 00 00 47
10:48:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
10:48:39: Send master linkready2
Tx@10:48:39: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0
Rx@10:48:39: () FB E2 77 77 77 00 00 00 00 00 00 00 00 47
10:48:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
10:48:39: Send master linkready2
Tx@10:48:39: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0
Rx@10:48:39: () FD E2 02 BB 97 0C 80 00 00 00 00 00 00 C2
10:48:39: 32.00 amp slave TWC 02BB is ready to link.  Sign: 97
10:48:39: Set slave TWC 02BB protocolVersion to 1, minAmpsTWCSupports to 5.
Tx@10:48:39: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
10:48:39: Send master linkready2
Tx@10:48:39: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0
Ignoring byte 02 between messages.
Ignoring byte 00 between messages.
Rx@10:48:39: (02 00) FD E2 02 BB 97 0C 80 00 00 00 00 00 00 C2
10:48:39: 32.00 amp slave TWC 02BB is ready to link.  Sign: 97
Tx@10:48:39: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
10:48:39: Send master linkready2
Tx@10:48:39: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0
Ignoring byte 1C between messages.
Ignoring byte DC between messages.
Ignoring byte 3F between messages.
Ignoring byte BC between messages.
Ignoring byte D7 between messages.
Ignoring byte D7 between messages.
Ignoring byte 17 between messages.
Ignoring byte 20 between messages.
Ignoring byte 20 between messages.
Ignoring byte 40 between messages.
Ignoring byte 40 between messages.
Ignoring byte 80 between messages.
Ignoring byte 80 between messages.
Ignoring byte 00 between messages.
Ignoring byte 00 between messages.
Ignoring byte 47 between messages.
Found end of message before full-length message received.  Discard and wait for new message.
Rx@10:48:39: (1C DC 3F BC D7 D7 17 20 20 40 40 80 80 00 00 47) FD E2 02 BB 97 0C 80 00 00 20 B8 3F 78 D7 97 A0 37 40 40 80 80 00 00 00 00 00 8B
10:48:39: ERROR: Ignoring message of unexpected length 27: FD E2 02 BB 97 0C 80 00 00 20 B8 3F 78 D7 97 A0 37 40 40 80 80 00 00 00 00 00 8B
Rx@10:48:39: () FB E2 77 77 77 00 00 00 00 00 00 00 00 47
10:48:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Rx@10:48:39: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Rx@10:48:39: () FB E2 77 77 77 00 00 00 00 00 00 00 00 47
10:48:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E2 77 77 77 00 00 00 00 00 00 00 00 47
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:40: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:40: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:40: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Ignoring byte 40 between messages.
Ignoring byte E1 between messages.
Ignoring byte E0 between messages.
Ignoring byte FE between messages.
Rx@10:48:41: (40 E1 E0 FE) FD E2 02 BB 97 0C 80 00 00 00 00 00 00 C2
10:48:41: 32.00 amp slave TWC 02BB is ready to link.  Sign: 97
Tx@10:48:41: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Ignoring byte FE between messages.
Rx@10:48:41: (FE) FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:41: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:42: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:42: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:42: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:43: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:43: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:43: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:44: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:44: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:44: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:45: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:45: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:45: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:46: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:46: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:46: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:47: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:47: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:47: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:48:48: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:48:48: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:48:48: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
10:50:27: WARNING: We haven't heard from slave 02BB for over 26 seconds.
Rx@10:50:29: () FD E2 02 BB 97 0C 80 00 00 00 00 00 00 C2
10:50:29: 32.00 amp slave TWC 02BB is ready to link.  Sign: 97
10:50:29: Set slave TWC 02BB protocolVersion to 1, minAmpsTWCSupports to 5.
Tx@10:50:29: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Ignoring byte FC between messages.
Rx@10:50:29: (FC) FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:29: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:30: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:30: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:30: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:31: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:31: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:31: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:32: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:32: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:32: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:33: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:33: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:33: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:34: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:34: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:34: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:35: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:35: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:35: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:36: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:36: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:36: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:37: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:37: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:37: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:38: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:38: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:38: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:39: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:39: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:39: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:40: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:40: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:40: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:41: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:41: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:41: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:42: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:42: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:42: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:43: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:43: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:43: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:44: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:44: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:44: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:45: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:45: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:45: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:46: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:46: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:46: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:47: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:47: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:47: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:48: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:48: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:48: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:49: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:49: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:49: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:50: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:50: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:50: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:51: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:51: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:51: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:52: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:52: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:52: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:53: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:53: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:53: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
Tx@10:50:54: C0 FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B C0
Rx@10:50:54: () FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
10:50:54: *** UNKNOWN MESSAGE FROM SLAVE:FB E0 77 77 02 BB 00 00 00 00 00 00 00 00 00 8B
Please private message user CDragon at http://teslamotorsclub.com with a copy of this error.
10:50:55: WARNING: We haven't heard from slave 02BB for over 26 seconds.
Von: flodorn<EMAIL_ADDRESS>Gesendet: Donnerstag, 11. April 2019 10:38
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
Could be an issue with the wall connector. I'd set debugLevel to 11 in TWCManager.py and try different rotary switch positions on the wall connector to see which messages you get. Don't forget to power off the wall connector before making changes on the rotary switch.
Tx@ is for messages you send to your wall connector
Rx@ is for messages you receive
You could also try to run TWCManager as slave to see if this works.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-482022722 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVg85igPr25BWhX1HCP1U7kh0OPOuks5vfvRWgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

Because of the autostart, a picture of the parameters. Is it correct that way?
Von: flodorn<EMAIL_ADDRESS>Gesendet: Donnerstag, 11. April 2019 10:38
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
Could be an issue with the wall connector. I'd set debugLevel to 11 in TWCManager.py and try different rotary switch positions on the wall connector to see which messages you get. Don't forget to power off the wall connector before making changes on the rotary switch.
Tx@ is for messages you send to your wall connector
Rx@ is for messages you receive
You could also try to run TWCManager as slave to see if this works.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-482022722 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVg85igPr25BWhX1HCP1U7kh0OPOuks5vfvRWgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

I don't see a picture.
Your serial port gets the excact same repsonse as the message you send during linkready1, this is strange. It casues the TWCManager script to think that the wall connector is sending it and is a master, but it's just a repeated signal on the serial port, or even the same signal as the source. Could be an issue with the serial adapter or the wiring.
How did you connect the serial wires?
I'd also try resetting the wall connector by pressing the reset button for >10sec

I have connected from the interface D- (RX) to D- in TWC and D + (TX) to D + in TWC. This is my interface [4.988866] usb 1-1.1.2: FTDI USB Serial Device Converter now attached to ttyUSB0. Picture is attached to the email. When I execute the command "python3 TWC / TWCManager.py" to the PI, the script runs. The command screen -r but nothing appears to me.
Von: flodorn<EMAIL_ADDRESS>Gesendet: Donnerstag, 11. April 2019 12:11
An: cdragon/TWCManager
Cc: chran28; Author
Betreff: Re: [cdragon/TWCManager] Timed out waiting for response from TWCManager script (#6)
I don't see a picture.
Your serial port gets the excact same repsonse as the message you send during linkready1, this is strange. It casues the TWCManager script to think that the wall connector is sending it and is a master, but it's just a repeated signal on the serial port, or even the same signal as the source. Could be an issue with the serial adapter or the wiring.
How did you connect the serial wires?
I'd also try resetting the wall connector by pressing the reset button for >10sec
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cdragon/TWCManager/issues/6#issuecomment-482054597 , or mute the thread https://github.com/notifications/unsubscribe-auth/AvJuVkggZcgUYEqJPKtpIoD_URTtvLZjks5vfwojgaJpZM4cmSBg .Das Bild wurde vom Absender entfernt.

There is no image file attached to the email.
As mentioned before, I'd try different settings on the rotary switch, change the serial cable from IN to OUT on the wall connector and run TWCManager as slave.
As for the autostart, if you followed the instructions of CDragon regarding the rc.local file it should work. I personally also had to change chmod of the TWC folder to 777 to make autostart work.
If the script has an error it also won't start. But you ruled that out by running it direclty with the python3 command.

Good Evening,
I am having a similar issue, I have been setting this up as a POC until my PW arrive and was going to see if I could write an API to interact with my SolarEdge inverter for now but upon reboot the script just does not seem to run
Below is an example of the start up script, I have checked for any potential errors by copying from the PDF and ensuring this went in as plain text like below

I also tried to modify the script to try and run the following su - pi -c "screen -dm -S TWCManager ~/TWC/TWCManager.py" and still no luck, I also tried to also see if it was a permissions issue by amending the folder using chmod 777 but again it still would not start
I have tried the command manually and get the following

If I run the Python the script runs as expect

Whilst this is running it works as expected, Is there a simple step I have missed?

@neoof86
The only difference I notice is that I added the startup bit su - pi -c "screen -dm -S TWCscript ~/TWC/TWCManager.py" in rc.local directly above the exit 0 line

I have set up the script as systemd service and is working properly (starting at boot). To do so, I did follow the guideline in Systemd (method4).
create the file TWCManager.service in /etc/systemd/system/
the content should be:
`[Unit]
Description=Autostart TWCManager, logs to be found in journalctl -U TWCManager.system
[Service]
User=pi
Type=idle
ExecStart=/usr/bin/python3 /home/pi/TWC/TWCManager.py
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
then give the proper rights, enable, start and reboot:sudo chmod 644 /lib/systemd/system/TWCManager.service
sudo systemctl daemon-reload
sudo systemctl enable TWCManager.service
sudo reboot`
If you want to check the status of the process, just write
sudo systemctl status TWCManager.service
you can "stop" it "restart" it or many other stuff to debug things.
The logs are to be found using journalctl
Maybe worth a try ?

Thanks,
That is the proper way to have it work. Not sure why local.rc was used?
Maybe a Raspian thing. I think it would be possible to add a cron job that
ran every so often to check it's running, if not, then start it. I
currently have the as suggested method and it occasionally stops! I'm
hoping to get back on track with this project to see if I can have all 3
HPTWC fighting over 80A!! and include an OpenEVSE just to make sure I'm
insane!!
Simon
On Thu, Apr 23, 2020 at 4:29 PM juamiso<EMAIL_ADDRESS>wrote:

I have set up the script as systemd service and is working properly
(starting at boot). To do so, I did follow the guideline in Systemd
https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/
(method4).
create the file TWCManager.service in /etc/systemd/system/
the content should be:
`[Unit]
Description=Autostart TWCManager, logs to be found in journalctl -U
TWCManager.system
[Service]
User=pi
Type=idle
ExecStart=/usr/bin/python3 /home/pi/TWC/TWCManager.py
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
then give the proper rights, enable, start and reboot:sudo chmod 644
/lib/systemd/system/TWCManager.service
sudo systemctl daemon-reload
sudo systemctl enable TWCManager.service
sudo reboot`
If you want to check the status of the process, just write
sudo systemctl status TWCManager.service
you can "stop" it "restart" it or many other stuff to debug things.
The logs are to be found using journalctl
Maybe worth a try ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dracoventions/TWCManager/issues/6#issuecomment-618682145,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYGU7E5D2GTOHBON7NWTY3ROCXL7ANCNFSM4HEZEBQA
.

--
This email, and any attachment to it, may contain information that is
proprietary, privileged or confidential or that may be otherwise legally
exempt from disclosure and is intended only for the individual(s) or entity
to which it is addressed.   If you are not the named recipient, or the
employee or agent responsible for delivering it to the intended recipient,
you are not authorized to read, print, retain, copy, disclose or distribute
this email or any part of it.
If you have received this email in error, please return it immediately to
the sender, delete it and all copies from your system, and destroy any hard
copies of this communication.


Update utils.py

Adding support for FreeBSD (running IoT Inspector from within a FreeNAS jail)

Thank you! We are preparing a major release now, and will merge your PR in a few weeks.


General Feedback from JOSS reviews

Start with atleast a 0.1.* versioning. 0.0.* means every change is breaking
Caret specifiers are not needed
CUDA Support:

Add CUDA tests. buildkite might be hard for repos in personal accounts, but since the cuda code in the ext involves custom kernels, I would expect tests at the bare minimum.

https://github.com/mrazomej/AutoEncoderToolkit.jl/blob/49653858a1e0bb70eb08bd27a18875c59a7c4491/src/layers.jl#L192. Flux now prefers @layer
Coverage for the project seems extremely low, even excluding the cuda tests it is roughly 60%.

Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Can a section for this be added?
7. Pattern like https://github.com/mrazomej/AutoEncoderToolkit.jl/blob/49653858a1e0bb70eb08bd27a18875c59a7c4491/src/decoders.jl#L452-L456 makes your entire code type-unstable, which might be okay for large networks, but best to avoid that pattern.

@avik-pal, thank you so much for taking the time to carefully review the paper and the software. I agree with all comments and suggestions and will promptly implement the necessary changes.
I would like to follow up with some questions and clarifications:

Caret specifiers are not needed

How would you rewrite this example from the Project.toml file without the caret specifiers?
[compat]
CUDA = "^5.3.3"
ChainRulesCore = "^1.23.0"

CUDA Support:
Add CUDA tests. buildkite might be hard for repos in personal accounts, but since the cuda code in the ext involves custom kernels, I would expect tests at the bare minimum.

Would it suffice to have a test file that runs locally on my CUDA-available machine?

Pattern like

AutoEncoderToolkit.jl/src/decoders.jl
Lines 452 to 456 in 4965385

 struct JointGaussianLogDecoder <: AbstractGaussianLogDecoder
     decoder::Flux.Chain
     µ::Flux.Dense
     logσ::Flux.Dense
 end

makes your entire code type-unstable, which might be okay for large networks, but best to avoid that pattern.

Would rewriting the struct as
struct JointGaussianLogDecoder{D<:Flux.Chain,L<:Flux.Dense} <: AbstractGaussianLogDecoder
    decoder::D
    µ::L
    logσ::L
end

fix the type instability?
Thanks again for your help!

[compat]
CUDA = "5.3.3"
ChainRulesCore = "1.23.0"

is same as specifying ^....

Would it suffice to have a test file that runs locally on my CUDA-available machine?

Yes, you can commit that. Add a explicit check for CUDA.functional() and run those test files if  cuda is functional (which would be false for github actions)

fix the type instability?

Yes. You can also use https://github.com/jonniedie/ConcreteStructs.jl which makes it easier to write these things.

Thank you both!

@avik-pal and @fabian-s
I implemented the requested changes and released the v0.1.0 version. The coverage reported does not reflect in the codecov tag does not reflect the real coverage of the package. There were a lot of "experimental" files that I accidentally kept in the main branch, but those have been removed. Basically, every function in the available models has been fully tested.
Thanks again, @avik-pal, for the incredibly insightful comments. Your suggestions truly improve the quality of the package.
Please let me know if there is anything else you would like me to implement. If not, we can close this issue.

The CI isn't running correctly right? It proceeds on error https://github.com/mrazomej/AutoEncoderToolkit.jl/blob/8b80d925ef9a50f928fe746b3195e914730e91ca/.github/workflows/CI.yml#L50 https://github.com/mrazomej/AutoEncoderToolkit.jl/actions/runs/9846125121/job/27183232171#step:7:281

The CI isn't running correctly right? It proceeds on error
https://github.com/mrazomej/AutoEncoderToolkit.jl/blob/8b80d925ef9a50f928fe746b3195e914730e91ca/.github/workflows/CI.yml#L50
https://github.com/mrazomej/AutoEncoderToolkit.jl/actions/runs/9846125121/job/27183232171#step:7:281

@avik-pal , you are absolutely right, and I apologize for that. I made an error in determining whether or not to test the CUDA- related functions on GitHub, but now that is fixed. I changed that continue-on-error to false.
However, I'm running into an issue I don't really understand. Locally, all tests pass whether CUDA is available or not.
Test Summary:         | Pass  Total     Time
AutoEncoderToolkit.jl | 1387   1387  1m44.3s

But on GitHub, there seems to be a recurrent issue when taking gradients with Zygote (see example below from here). This causes all functions where a gradient is taken to fail.
Test Summary:                               | Pass  Error  Total     Time
AutoEncoderToolkit.jl                       | 1344     30   1374  2m54.0s

That was the original reason I had set continue-on-error: true. I am not sure how to fix this issue.
 Regardless you should do a merge of 2 NamedTuples, Dicts generally have unnecessary overheads.

@avik-pal , that was it! Replacing all Dict with NamedTuple solved the issue. Thank you so much for your help; now all tests pass on GitHub.
All tests passed!

Test Summary:         | Pass  Total     Time
AutoEncoderToolkit.jl | 1387   1387  8m08.4s
     Testing AutoEncoderToolkit tests passed

I released and registered v0.1.1 with all these changes. Thanks again for your help!
Please let me know if you would like me to implement anything else.

Things look great now.


Handle empty job list for a workflow

Starting from a project page

I click on "List jobs", in the workflow list.
This leads to an empty page:

I think it'd be better to show one of:

An empty table
A message saying something like "There is no job associated to the current project".

The empty page was a bug. It should display an empty table. Fixed with d44d681036edaa800c22f3e8532e112dee813060.

I confirm (from the admin-jobs branch):


chore(ci): add CICD

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cleanup of user facing verbiage of Bitcoin -> Zcoin

Changed Bitcoin -> Zcoin verbiage in help texts, and error/info messages.
Omni message should be Exodus.
Renamed bitcoinaddressvalidator files to zcoinaddressvalidator in code and fs.

Going to flatten the PR


java.net.SocketTimeoutException when using multiple metadata sources

I use 7 metadata sources for my Komga library. Recently, when I try to identify series using the userscript I get java.net.SocketTimeoutException in logs:
komf  | java.net.SocketTimeoutException: timeout
komf  |         at okhttp3.internal.http2.Http2Stream$StreamTimeout.newTimeoutException(Http2Stream.kt:675)
komf  |         at okhttp3.internal.http2.Http2Stream$StreamTimeout.exitAndThrowIfTimedOut(Http2Stream.kt:684)
komf  |         at okhttp3.internal.http2.Http2Stream.takeHeaders(Http2Stream.kt:143)
komf  |         at okhttp3.internal.http2.Http2ExchangeCodec.readResponseHeaders(Http2ExchangeCodec.kt:97)
komf  |         at okhttp3.internal.connection.Exchange.readResponseHeaders(Exchange.kt:110)
komf  |         at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.kt:93)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:34)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at org.snd.common.http.UserAgentInterceptor.intercept(UserAgentInterceptor.kt:10)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.kt:221)
komf  |         at org.snd.common.http.LoggingInterceptor.intercept(LoggingInterceptor.kt:20)
komf  |         at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
komf  |         at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
komf  |         at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
komf  |         at org.snd.common.http.HttpClient$execute$1.invoke(HttpClient.kt:27)
komf  |         at org.snd.common.http.HttpClient$execute$1.invoke(HttpClient.kt:26)
komf  |         at org.snd.common.http.HttpClient.rateLimited$lambda$0(HttpClient.kt:54)
komf  |         at io.github.resilience4j.ratelimiter.RateLimiter.lambda$decorateCheckedSupplier$3(RateLimiter.java:219)
komf  |         at io.github.resilience4j.retry.Retry.lambda$decorateCheckedSupplier$1(Retry.java:135)
komf  |         at org.snd.common.http.HttpClient.rateLimited(HttpClient.kt:56)
komf  |         at org.snd.common.http.HttpClient.execute(HttpClient.kt:26)
komf  |         at org.snd.metadata.providers.mangaupdates.MangaUpdatesClient.searchSeries(MangaUpdatesClient.kt:44)
komf  |         at org.snd.metadata.providers.mangaupdates.MangaUpdatesMetadataProvider.searchSeries(MangaUpdatesMetadataProvider.kt:64)
komf  |         at org.snd.metadata.MetadataProvider$DefaultImpls.searchSeries$default(MetadataProvider.kt:18)
komf  |         at org.snd.mediaserver.MetadataService.searchSeriesMetadata_7R2r78w$lambda$1$lambda$0(MetadataService.kt:48)
komf  |         at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(Unknown Source)
komf  |         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
komf  |         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
komf  |         at java.base/java.lang.Thread.run(Unknown Source)

Is there a way to increase the timeout limit value?

It might have been a temporary issue with mangaupdates. Timeout is set to 10 seconds and request is retried 3 times, usually that's enough
Do you still have this issue?

No, I don't have any issues today. The problem has been there for the last few days, but now it is fine. I guess it was a temporary issue with some provider. Still, it is strange because I experimented with 3 providers and each one worked fine when it was the only one enabled. When I enabled all of them - the issue was present.
I think the issue can be closed now. I'll report back if the problem ever comes back so we can investigate it further.