New thread is spawned for every I/O request

When trying to run a sequential I/O with async-std, it seems that new thread is spawned for every I/O request.
Here's strace log for a test workload, which shows that a thread is spawned for every request.
79669 00:41:46.567723 clone( <unfinished ...>
79669 00:41:46.567776 <... clone resumed> child_stack=0x7f2e6d980b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6d9819d0, tls=0x7f2e6d981700, child_tidptr=0x7f2e6d9819d0) = 79670
79669 00:41:46.567800 read(4,  <unfinished ...>
79670 00:41:46.568086 getrandom("\xa5\x37\x5a\x6e\x17\x92\xc9\xfe\xe4\x95\x04\x86\x48\xf0\xc3\x2a\x76\xaa\x6f\x41\x6d\x78\xbb\x13\x30\xdd\x10\x16\x33\x4f\x48\x2f", 32, GRND_NONBLOCK) = 32
79669 00:41:46.569861 <... read resumed> "AndroidManifest.xml\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4194304) = 4194304
79669 00:41:46.570068 exit(0)           = ?
79670 00:41:46.571880 clone(child_stack=0x7f2e6e382b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6e3839d0, tls=0x7f2e6e383700, child_tidptr=0x7f2e6e3839d0) = 79671
79670 00:41:46.571938 read(4,  <unfinished ...>
79671 00:41:46.572264 getrandom("\xbe\xbb\x85\xd2\x92\x95\xa5\xe0\x5e\x4a\xc4\xf7\xb0\x9a\xb0\x87\xa0\x5b\xfe\x4c\xc9\x47\x94\xb9\x25\xb0\x2c\x48\xc2\x87\x3b\x66", 32, GRND_NONBLOCK) = 32
79670 00:41:46.573016 <... read resumed> "\6\20\0u555'\252\25210\0u---#\242\"U\20\4\204\226\256\r\226(P\0\201"..., 4194304) = 4194304
79670 00:41:46.573279 exit(0)           = ?
79671 00:41:46.574703 clone(child_stack=0x7f2e6d980b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6d9819d0, tls=0x7f2e6d981700, child_tidptr=0x7f2e6d9819d0) = 79672
79671 00:41:46.574773 read(4,  <unfinished ...>
79672 00:41:46.575185 getrandom("\xcf\x3b\x90\x37\x9e\x51\x44\xe8\xa4\x87\xe1\x69\x6f\x21\xb3\xb5\xf9\x13\x2a\xfa\xaa\x9a\xdd\x7c\x3d\x52\x6d\xda\xb7\x35\x21\xff", 32, GRND_NONBLOCK) = 32
79671 00:41:46.575597 <... read resumed> "\213d\272\\\346\272\257\247\346i\241\272\241\314\356J\234O\375\355\316\350<%X\327\316\316\275k77"..., 4194304) = 4194304
79671 00:41:46.575822 exit(0)           = ?
79672 00:41:46.577128 clone(child_stack=0x7f2e6e382b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6e3839d0, tls=0x7f2e6e383700, child_tidptr=0x7f2e6e3839d0) = 79673
79672 00:41:46.577190 read(4,  <unfinished ...>
79673 00:41:46.577577 getrandom("\xf5\x32\xc3\x91\xd2\x5d\x82\xee\xe0\x70\x90\x62\xf7\x55\xdf\x06\x52\x9a\x87\x3b\x84\x92\xeb\x12\xbc\x49\x92\x8c\x8b\xba\x4e\x11", 32, GRND_NONBLOCK) = 32
79672 00:41:46.578301 <... read resumed> "\267\377\7\6\307\34\4\271\2+\233\222\1\0*\226\253\0\10<\4\22\34$S\3#\312\t}\263\4"..., 4194304) = 4194304
79672 00:41:46.578501 exit(0)           = ?
79673 00:41:46.579951 clone(child_stack=0x7f2e6d980b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6d9819d0, tls=0x7f2e6d981700, child_tidptr=0x7f2e6d9819d0) = 79674
79673 00:41:46.580029 read(4,  <unfinished ...>
79674 00:41:46.580354 getrandom("\x26\xda\xb7\xd8\xd6\xa8\x94\x81\x7e\xd5\xf2\xba\xa8\x0c\xfe\x97\xd0\x9b\xec\x99\x82\x28\x49\x69\x98\xd4\x3a\x05\x82\xa4\xaf\x92", 32, GRND_NONBLOCK) = 32
79673 00:41:46.580667 <... read resumed> "&\17(\0\377\311\262\t 6Mcx\214\237\257\276\273\305\30Z\262\270\275\301\315\0\10\365\10\1\23"..., 4194304) = 4194304
79673 00:41:46.580907 exit(0)           = ?
79674 00:41:46.582260 clone(child_stack=0x7f2e6e382b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6e3839d0, tls=0x7f2e6e383700, child_tidptr=0x7f2e6e3839d0) = 79675
79674 00:41:46.582322 read(4,  <unfinished ...>
79675 00:41:46.582647 getrandom("\xf5\x1e\xc5\xca\xab\x11\x8c\x8a\x4a\x90\x3f\x93\x11\xbc\x28\x93\xd0\xbb\x29\xa1\x97\x08\xba\xe6\xa9\x9f\xd3\x4e\x2d\xcb\x00\x6a", 32, GRND_NONBLOCK) = 32
79674 00:41:46.583319 <... read resumed> "_\233\5_\233\25\363b\377\0\0\0\0\0\0\0_\233\5_\233\25\363b\377\0\0\0\0\0\0\0"..., 4194304) = 4194304
79674 00:41:46.583526 exit(0)           = ?
79675 00:41:46.584923 clone(child_stack=0x7f2e6d980b70, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2e6d9819d0, tls=0x7f2e6d981700, child_tidptr=0x7f2e6d9819d0) = 79676
79675 00:41:46.584994 read(4,  <unfinished ...>
79676 00:41:46.585351 getrandom("\x07\x26\xde\x5d\x98\xf7\x6d\xec\xa9\xb1\x58\xc9\x9d\xc5\x9a\x05\xc4\xaa\x71\x88\xeb\x8c\xcb\x13\x81\x8d\xf0\xce\x05\x91\x09\xa6", 32, GRND_NONBLOCK) = 32
79675 00:41:46.586010 <... read resumed> "\331\331\241\"\214\316\10\214\340\340\250\2\0\0\0\0\340\340\250\2\0\0\0\0\340\340\250\2\0\0\0\0"..., 4194304) = 4194304
79675 00:41:46.586205 exit(0)           = ?

The workload is recorded with
strace -o strace.log -ftt ./target/release/run

and filtered with
grep -vP '(futex|sched|map|sig|prote|prctl|robust_|madvise|exited)' strace.log

Thanks for report.
Can you teach us used async-std version and wrote code?
@yjh0502

@k-nasa Here's a sample code to reproduce the problem
use async_std::prelude::*;

fn main() {
    async_std::task::block_on(async {
        let mut f1 = async_std::fs::File::open("/dev/zero")
            .await
            .expect("File::open");
        let mut f2 = async_std::fs::File::create("/dev/null")
            .await
            .expect("File::create");

        let mut buf = [0u8; 1];
        for _ in 0..10000 {
            f1.read(&mut buf).await.expect("read");
            f2.write(&buf).await.expect("write");
        }
        ()
    });
}

I'm using latest async-std, 1.5.0, and here's strace stats.
$ strace -cf ./target/debug/async-std-test 2>&1 | grep -v '^strace: Process'
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.80    2.085741          28     72686      3836 futex
 10.52    0.393280           6     57470           sigaltstack
  6.68    0.249663          13     19159           munmap
  5.64    0.210648          10     19154           madvise
  4.18    0.156334           8     19188           mmap
  3.75    0.140303           7     19157           sched_getaffinity
  3.45    0.128948           6     19156           prctl
  3.14    0.117421           6     19156           clone
  2.52    0.094104           4     19157           set_robust_list
  1.63    0.060762           6     10008           read
  1.55    0.057823           5     10000           write
  1.14    0.042570           7      5466           sched_yield
  0.00    0.000039           2        17           mprotect
  0.00    0.000000           0         8           close
  0.00    0.000000           0         6           fstat
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         8           pread64
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           fcntl
  0.00    0.000000           0         2         1 arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         8           openat
  0.00    0.000000           0         2           prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00    3.737636                289821      3838 total
19692
$ strace -cf ./target/release/async-std-test 2>&1 | grep -v '^strace: Process'
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 55.74    2.518723          34     72651       622 futex
 10.04    0.453825           7     58040           sigaltstack
  7.11    0.321096          16     19345           madvise
  6.23    0.281487          14     19352           munmap
  4.68    0.211388          10     19384           mmap
  3.36    0.151727           7     19346           clone
  3.26    0.147177           7     19347           sched_getaffinity
  2.89    0.130757           6     19346           prctl
  2.72    0.122969           6     19347           set_robust_list
  1.51    0.068417           6     10008           read
  1.42    0.064351           6     10000           write
  1.04    0.046779           6      7577           sched_yield
  0.00    0.000083           3        23           mprotect
  0.00    0.000012           1         8           close
  0.00    0.000000           0         6           fstat
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         8           pread64
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           fcntl
  0.00    0.000000           0         2         1 arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         8           openat
  0.00    0.000000           0         2           prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00    4.518791                293813       624 total

It read/write about 10k times (as expected), and around 19k threads are created/destroyed during the process.

Here's what I think is happening:

open and create both are implimented via spawn_blocking(), which is intended to use a thread pool.

The internal thread pool impl keeps at least one sleeping thread running at all times.

when a thread-pool thread is started, it blocks waiting for work on a queue

if the blocking times out (it does every second), it checks if we're the last sleeping thread

if we're the last sleeping thread, we continue running.
if there are other sleeping threads, the thread is terminated

after obtaining a task, the thread checks if there are any sleeping
threads (ie: it is no longer sleeping because it has a task, so it checks
that there's another).

if there are no other sleeping threads then a new one is spawned

task is then run

another check for sleeping threads occurs: if there are others, than the thread running the task exits.

Putting this together with the code sample:

on each of open and create:

the 1 sleeping thread is used for computation
another thread is spawned so that there is at least 1 sleeping thread
after computation, the computing thread exits because the sleeping thread it created exists.

so we see approximately 2x iterations in thread creation/destruction (1
thread spawned + destroyed for each of open and create)

I'm not sure what the best way to resolve this is. Plausible that some
different approach to the thread pool could be taken. It's not really operating
as a pool right now (zero thread re-use with the code given).

I don't know how the internals are working, but shouldn't there be a policy that allows to spawn a predefined number of threads say N, which are waiting for tasks to be available. Then when the tasks are available, schedule those M tasks across the N available threads?

I've looked back at the code again and noticed that it performs 1 open and 1 create (not many). This means that the explanation I posted previously is probably wrong (I added a note at the start about that error).

I don't know how the internals are working, but shouldn't there be a policy that allows to spawn a predefined number of threads say N, which are waiting for tasks to be available. Then when the tasks are available, schedule those M tasks across the N available threads?

For the particular spawn_blocking::POOL, there are no limits. Note that spawn_blocking is intended for use with blocking tasks (openandcreate` are syscalls that block and don't offer a non-blocking interface).
Note that this shouldn't apply to read/write: these have non-blocking interfaces.

Ok, so I've dug a bit further:
It appears that we're hitting the spawn_blocking() call within write(). Here's a partial call stack:
#0  async_std::task::spawn_blocking::spawn_blocking (f=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/task/spawn_blocking.rs:45
#1  0x00005555555a770b in async_std::fs::file::LockGuard<async_std::fs::file::State>::poll_drain (self=..., cx=0x7fffffffd1c0)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:815
#2  0x00005555555a6c9f in async_std::fs::file::LockGuard<async_std::fs::file::State>::poll_write (self=...,
    cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:796
#3  0x00005555555a4895 in <&async_std::fs::file::File as futures_io::if_std::AsyncWrite>::poll_write (self=...,
    cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:374
#4  0x00005555555a46e9 in <async_std::fs::file::File as futures_io::if_std::AsyncWrite>::poll_write (self=...,
    cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:355
#5  0x0000555555573bbd in <async_std::io::write::write::WriteFuture<T> as core::future::future::Future>::poll (self=...,
    cx=0x7fffffffd1c0) at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/io/write/write.rs:19

There's also one in read() (again, partial backtrace):
#0  async_std::task::spawn_blocking::spawn_blocking (f=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/task/spawn_blocking.rs:45
#1  0x00005555555a5d8d in async_std::fs::file::LockGuard<async_std::fs::file::State>::poll_read (self=..., cx=0x7fffffffd1c0,
    buf=...) at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:703
#2  0x00005555555a4625 in <&async_std::fs::file::File as futures_io::if_std::AsyncRead>::poll_read (self=...,
    cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:345
#3  0x00005555555a44f9 in <async_std::fs::file::File as futures_io::if_std::AsyncRead>::poll_read (self=...,
    cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/fs/file.rs:334
#4  0x0000555555570e6f in <&mut T as futures_io::if_std::AsyncRead>::poll_read (self=..., cx=0x7fffffffd1c0, buf=...)
    at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-io-0.3.4/src/lib.rs:326
#5  0x000055555556ab6d in <async_std::io::read::read::ReadFuture<T> as core::future::future::Future>::poll (self=...,
    cx=0x7fffffffd1c0) at /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.5.0/src/io/read/read.rs:19

So my previous incorrect comment is still somewhat informative here.

s@jmesmon

Edit: file-io is basically blocking on linux even if using NONBLOCK flags.

Correct me if I am wrong, but this should hold true for regular files on all *nix systems, since it is assumed that a local file is always accessible and disk reads/writes are not slow enough to block. But the same should not be true for "special" character special devices such as /dev/zero and /dev/null. There is no reason for kernel to block reads and writes to these files, even on linux.
On side note since you guys are using mio, my guess would be it is using epoll internally on linux, in which case it is important to note that epoll doesn't work on regular files. I also highly doubt that it would work on files like /dev/zero, which always has something to read.

@adityashah1212 sure, that sounds right. Internally, async-std flows all File io the same way: calling read() (or write())within a spawn_blocking(), in effect spawning a thread for each of the reads/writes of normal files that occur in a user's program.
As far as I can tell, there is no special casing for non-normal files.

@jmesmon then wouldn't it better to have two sets of API's in two different modules, one performing blocking and other performing non-blocking File IO operations. Let the developer choose which ones s/he wants to use?

Yes, there are non-normal-file use cases where one would want to wait on the fd instead of spawning a separate thread for each operation. I don't know what async-std's thoughts on where those should live are.
As far as blocking operations, I believe one would just use the std::file stuff at that point instead of async_std::file.


Unregistered documents are never cleaned up, which causes TernProvider list of documents to forever grow

https://github.com/MiguelCastillo/Brackets-Ternific/commit/23e4abd7ad8aa703a800fb14d800d5750f1e1ed1


⚠ Bofrost.es has degraded performance

In d3fb3e7, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1772 ms

Resolved: Bofrost.es performance has improved in a484528 after 15 minutes.


Add support for .xz / lzma

Signed-off-by: Vadim Markovtsev<EMAIL_ADDRESS>

@piskvorky CI passed, README updated, py2.7 handled. PTAL

Thanks for the swift resolution!
@mpenkov WDYT?


feat: add dimension tokens in the demo app

Waiting for Figma answers about WithIcon and WithArrow tokens.


Infobar for "make terminal the default" doesn't remember it was dismissed upon new OS flight

Windows Terminal version (or Windows build number)
22496
Other Software
No response
Steps to reproduce
launch terminal, get the infobar about making Terminal de default console.
Close it, don't make it the default
get a new OS flight
launch terminal - same infobar shows up again
Expected Behavior
setting gets persisted
Actual Behavior
terminal insists

@asklar can you share a copy of state.json from %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState?
Closing the infobar should make us record that it was dismissed. This is not tracked per OS version or stored anywhere that the OS would clear on upgrade.

(This assumes that you are using Terminal Stable and not switching back and forth between Stable and Preview, and that you are not using Unpackaged terminal -- since you did not include a Terminal version, I must assume the formermost.)

Using Preview, version 1.11.2921.0
{
	"dismissedMessages" :
	[
		"setAsDefault"
	],
	"generatedProfiles" :
	[
		"{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
		"{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
		"{574e775e-4f2a-5b96-ac1e-a2962a402336}",
		"{b453ae62-4e3d-5e58-b989-0a998ec441b8}"
	]
}

This is after dismissing the message. I guess I should check the content of this file after the next flight?
or maybe app updates/installs are clearing the localstate folder?

or maybe app updates/installs are clearing the localstate folder?

That would definitely be worth checking! That's where we keep our settings, as well. Have you noticed Terminal deleting all your settings across OS upgrades? Would you mind capturing a snapshot of that directory next time you flight?

(I'll reopen this for another 7 days)

just hit this again, and this is the content now:
{
        "generatedProfiles" :
        [
                "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
                "{63e31163-583f-5850-9c1e-24e227dd2da9}",
                "{b453ae62-4e3d-5e58-b989-0a998ec441b8}"
        ]
}

It is deeply concerning that your state is getting destroyed but your settings are not... or.. are they? Do you tend to change settings.json at all?

I haven't changed the state in a while... the only change I remember making in the last few months is adding -nologo to pwsh since I don't want to be reminded of the "build du jour" every time

An OS update shouldn't be clearing out things from %LOCALAPPDATA%, right? Yea of course not, the settings file doesn't get deleted. There's also no code that's shipped yet for blowing away the elevated version of that file, so it's not like I'm accidentally doing that...
Maybe this is the thing where we can't find the settings file, or find that it's empty, and then re-create the state. Trick is, why do we think we can't find it? (and why isn't anyone else on the team seeing this?)

haven't seen this recently


Add ability to edit URL.

Add ability to edit URL before opening. It would help to clear referrer and to copy to clipboard.

It might be worth while considering maybe making these buttons configurable in the future?


[Feature Request]: Create ODH UX Team Group & Add them to the PR Template

Feature description
Currently in our PR Template we ask you to tag the UX team. How will anyone open source know who is on the UX team?
Using https://github.com/opendatahub-io/org-management, we should create a group (@LaVLaS is setting it up). Then we should update our template to reference this group name.
Describe alternatives you've considered
No response
Anything else?
No response

We're still working on the PR template but just submit the PR to org-management to create the groups

Migrated to:  https://issues.redhat.com/browse/RHOAIENG-2524


Entities with Composite Keys behave weirdly when referenced by OneToMany relationships

Describe the bug
If an Entity containing a OneToMany relationship toward another Entity with composite keys is present in the cache, Mikro-ORM will behave strangely depending on how many times you will flush related entities. The first time you flush (one or more entities) it works, then it fires an update query with a non-existing id (0) which leads to a rollback.
I'm unsure about what exactly is happening because I'm not super familiar with the innings of UnitOfWork, a repro is pending.
Stack trace
[query] insert into "new_user" default values returning "id" [took 1 ms]
[query] commit
[query] begin
[query] insert into "new_user" default values returning "id" [took 1 ms]
[query] commit
[query] begin
[query] insert into "new_chat" ("owner_id", "recipient_id") values (1, 3) [took 3 ms]
[query] commit
[query] begin
[query] insert into "new_chat" ("owner_id", "recipient_id") values (3, 1) [took 1 ms]
[query] update "new_chat" set "owner_id" = 039m [took 2 ms]
[query] rollback
(node:108262) UnhandledPromiseRejectionWarning: error: update "new_chat" set "owner_id" = $1 - insert or update on table "new_chat" violates foreign key constraint "new_chat_owner_id_foreign"
    at Parser.parseErrorMessage (/home/niko/WebstormProjects/beach/server/node_modules/pg-protocol/src/parser.ts:325:11)
    at Parser.handlePacket (/home/niko/WebstormProjects/beach/server/node_modules/pg-protocol/src/parser.ts:154:21)
    at Parser.parse (/home/niko/WebstormProjects/beach/server/node_modules/pg-protocol/src/parser.ts:106:30)
    at Socket.<anonymous> (/home/niko/WebstormProjects/beach/server/node_modules/pg-protocol/src/index.ts:7:48)
    at Socket.emit (events.js:315:20)
    at Socket.EventEmitter.emit (domain.js:485:12)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:273:9)
    at Socket.Readable.push (_stream_readable.js:214:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:186:23)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:108262) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:108262) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

To Reproduce
A PR with a failing test is available: https://github.com/mikro-orm/mikro-orm/pull/590
Expected behavior
Should work despite the order and/or what's already loaded into the cache.
Additional context
The same works if I use IDs instead of composite keys.
Versions

Dependency
Version

node
13.14.0

typescript
3.9.3

mikro-orm
3.6.14

pg
8.2.1

Closing as fixed in dev branch.


Updated the login page to make it more consistent with the current theme.

I have added a login and signup form with animation and added "geet-logo" with the same color pallete as the main page to make it look more professional and consistent with the mainweb-page.
Earlier

Now

and

Thankyou for merging😊


[locale] es: Fix es locale serialization #4585

Fixes this issue: https://github.com/moment/moment/issues/4585

Coverage remained the same at 94.691% when pulling 062eaed0dded82603aff48d2ba3bd3084a6846c5 on suprMax:develop into aba77ec8196bab4067474c407f871f7612a5f421 on moment:develop.

Coverage remained the same at 94.691% when pulling 062eaed0dded82603aff48d2ba3bd3084a6846c5 on suprMax:develop into aba77ec8196bab4067474c407f871f7612a5f421 on moment:develop.


Updates style to new bootstrap 3 pagination

If you want to centralize the pagination, just add a

 before the
 tag.

Thank you @patrickemuller! This helped me right now. :+1:


Error message: 'couldn't be opened because you don't have permission to view it'.

Running any assertSnapshot() on Xcode 13 fails giving this error message:
'failed - The File ______.txt could not be opened because you don't have permission to view it.'
Has anyone else experienced this? All permissions that could be required are setup, and I can actually see the files and open the files it refers to, and all others at my work are running these tests fine.
A workaround I currently have is deleting the file it says it says I don't have access to, and remaking it with isTesting = true on. After doing this it then works. But would like to not have to do this each time.

I got a similar error.

my environment is here

Xcode 13.1
iMac Pro(2017) Intel
test with iOS 15 Simulator
running the test by Xcode

deleting snapshot folder and rerunning test fix the problem for me as well 🥲.

Is there any update, it still present in last version of library


Fixes autoUpdate being enabled when applying a DynaKube in v1beta1 with autoUpdate set to false.

cherrypick to release 1.2 for #3235

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 58.79%. Comparing base (fe22f6a) to head (6051b68).
Report is 1 commits behind head on release-1.2.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff               @@
##           release-1.2    #3251      +/-   ##
===============================================
- Coverage        58.80%   58.79%   -0.01%
===============================================
  Files              326      326
  Lines            18145    18153       +8
===============================================
+ Hits             10670    10673       +3
- Misses            6279     6283       +4
- Partials          1196     1197       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Tint color are too dark

You can't tint with bright color. They too dark and you didn't see labels at it.
Colors for backgrounds are inlined and tangled with code, they need to be in settings window at my opinion.

 Wrong repo. Sorry >__<


fix(graphql-model-transformer): @model conflict resolution

Description of changes

implementation for graphql transformer V2 datastore resolvers

Description of how you validated changes

added new tests
ran yarn test
manual testing by creating an app using "useexperimentalpipelinedtransformer": true,

Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #8035 (7b5de7b) into master (b40faa7) will increase coverage by 0.00%.
The diff coverage is 0.00%.

:exclamation: Current head 7b5de7b differs from pull request most recent head 26f87ff. Consider uploading reports for the commit 26f87ff to get more accurate results

@@           Coverage Diff           @@
##           master    #8035   +/-   ##
=======================================
  Coverage   54.13%   54.14%
=======================================
  Files         657      657
  Lines       37488    37484    -4
  Branches     7698     7696    -2
=======================================
  Hits        20295    20295
+ Misses      16353    16349    -4
  Partials      840      840

Impacted Files
Coverage Δ

...tils/awscloudformation/secrets/ssmClientWrapper.ts
11.42% <ø> (+0.31%)
:arrow_up:

...der-awscloudformation/src/system-config-manager.ts
46.04% <0.00%> (+0.63%)
: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 b40faa7...26f87ff. Read the comment docs.


fixed process start to call with spaces in command/arguments

close log file before start of callback function

Signed-off-by: Slava<EMAIL_ADDRESS>

I will make these two changes, but a little differently.
Thanks.

I made equivalent changes in a previous commit. If it isn't working properly, please create a new issue.
Thanks!


Escape more symbols in path handling.

Add escapes for "#" and "," because buck build tool use them to differentiate target patterns in its generated compile_commands.json: source.
I considered covering the other cases from the standard, but decided against it because of the potential of extra string allocations if I add too many cases.

Having additional allocations here is probably fine since it is not a very hot code path.


Context menu not displaying antivirus for file or folder scanning

Description
The context menu is not showing the installed antivirus for quick scanning of files and folders. Normally in file explorer if you have Bitdefender or another antivirus installed, there will be an item in the context menu so that you can right-click and scan a file or folder easily.
Steps To Reproduce
Right click any file or folder.
You will see that there is no menu item for scanning with installed antivirus.
Requirements
This should be recognized automatically or for now address how we can incorporate this functionality manually by ourselves.
Files Version
<IP_ADDRESS>
Windows Version
Windows 11 Pro 23H2 Windows Feature Experience Pack 1000.22677.1000.0
Log File
debug.log

Thanks for the report. Last known it was an issue with bit defender and how it add shell options as said here https://github.com/files-community/Files/issues/10866#issuecomment-1485743785


'+' model selector with dbt test looks for incorrect models

Describe the bug
Using the '+' model selector with a tag for both run and test:
$ dbt run -m +tag:external and then  $ dbt test -m +tag:external
I get a number of missing model errors. The missing models were (correctly) not built by the run, so it seems like an issue they were expected by the test.
Digging around, it looks like test is trying to test models not included in the run DAG, but that have a relationship: test against a models that are included.
Steps To Reproduce

Tag model_a with 'external'
Write a test against model_b checking a relationship against model_a
Remove any existing model_b relations in the db
Run $ dbt run -m +tag:external
Run $ dbt test -m +tag:external : expect an error for no model_b
Remove the relationship test for model_b against model_a
Run $ dbt test -m +tag:external : expect everything is happy again.

  - name: model_b
    columns:
    - name: model_b_id
      tests:
        - not_null
        - unique
    - name: model_a_id
      tests:
        - not_null
        - relationships:
            to: ref('model_a')
            field: model_a_id

Expected behavior
Using the same model selectors would result in the same models in the DAG for both run and test. And if a model isn't built, its relationships to other models shouldn't be tested.
Screenshots and log output

System information
Which database are you using dbt with?
postgres
The output of dbt --version:
installed version: 0.15.0
latest version: 0.15.2

The operating system you're using:
macOS Mojave (10.14.6)
The output of python --version:
Python 3.7.3
Additional context
This went unnoticed until I cleared out all old models before the run & test, since finding old copies of the models from a full run would satisfy the tests.

@jmace006 thanks for opening this issue! I missed this initially, and we ended up also opening #1827 which addresses the same issue!
Our fix here is going to be to change test selection to only include tests which have all of their requirements satisfied by the specified selector. In the case you've shown above, you'd need to run:
dbt test -m +tag:external model_a

in order to run the relationships test specified on model_b.
Let us know what you think over in #1827, and thanks again for raising this one!!

@jmace006 thanks for opening this issue! I missed this initially, and we ended up also opening #1827 which addresses the same issue!
Our fix here is going to be to change test selection to only include tests which have all of their requirements satisfied by the specified selector. In the case you've shown above, you'd need to run:
dbt test -m +tag:external model_a

in order to run the relationships test specified on model_b.
Let us know what you think over in #1827, and thanks again for raising this one!!

hey @drewbanin is there an issue being tracked for this change you mention?
Our fix here is going to be to change test selection to only include tests which have all of their requirements satisfied by the specified selector.

@ags2121 Just opened: https://github.com/fishtown-analytics/dbt/issues/2891


Pull request for libcups2-dev

For travis-ci/travis-ci#4374.
Ran tests and found no setuid bits.
See https://travis-ci.org/travis-ci/apt-whitelist-checker/builds/71975804

This is identical to #71.


Updated snapshot examples files

Description

Ran the update-examples-snapshot.sh and updated all our example files.
Includes new LA sample files.

Issue
1355
Note: You may remove items that are not applicable

I may need to back track some of the other example files changes. It looks like only ID's were updated in some examples. The main purpose of this PR was to upload the example/LA files

I may need to back track some of the other example files changes. It looks like only ID's were updated in some examples. The main purpose of this PR was to upload the example/LA files

@saquino0827  It looks good to me. The IDs for the FHIR resources will always change when updating the files because they are randomly generated when RS creates the FHIR message. Unless you are referring to other IDs

I opened a PR for the wrong branch. Closing this PR for now.


Use types from @types/chrome where avialable

Use types from the @types/chrome package where available.

See https://github.com/lachlanmcdonald/mock-storagearea/issues/4.


Modbus connection randomly disconnects

Describe the bug
I am experiencing random disconnects of the modbus connection. So about 1-2 times per day the reporting of values stops w/o an error message. I then need to manually reload the adapter in order to get the connection restarted. Also with other adapters connections sometimes break either due to network issues, or cloud service problems or whatever, but all other adapters I am using do an automatic reconnect in such a case.
Expected behavior
Please add an automatic reconnect service in case the modbus connection gets lost.
  A reboot of HA brings it back online but only for a short time (maybe 15 minutes).
I have this error in my log:
Log Details (ERROR)
This error originated from a custom integration.
Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:319
Integration: SolarEdge Modbus Multi (documentation, issues)
First occurred: 15:32:50 (1 occurrences)
Last logged: 15:32:50
Timeout fetching SolarEdge Coordinator data

I can confirm that since rolling back to 2.4.9, the Modbus connection is now stable once more.
For info, here is the historical graph showing the disconnects since updating to 2.4.10 last night:

Please try Release v2.4.11-pre.2

Thanks. I'll install now and see how it goes tonight

Can you release it as a beta?  I cannot seem to install it via HACS...

Thank you. I have got it installed now.
Will leave it overnight and report back tomorrow.
Thanks for the speedy release. Let's hope it fixes the issue.

I'm afraid it didn't fix it.
It lasted about 25 mins and has then disconnected again.

Here's the log error:

Release v2.4.11-pre.3 removes the current limit entity and the matching modbus read.

If pre.3 doesn't change anything then next I'll try removing polling reads for the commit/restore functions.

OK, installing now.
I'll report back in the next hour if it stops working, otherwise I'll report back that it is working in about 13 hours.

I went ahead and made Release v2.4.11-pre.4 so you can try it immediately if needed.

Pre4 installed.
Will keep you posted.

Pre4 has also done the same thing.

Release v2.4.11-pre.5 removes the power reduce entity and associated read.

Thanks.
Installed and testing

Upload your diagnostic file too.

config_entry-solaredge_modbus_multi-c62b22ee6af38c36522d4c8dca9025ea.json

@mtbsteve

Please add an automatic reconnect service in case the modbus connection gets lost.

FYI this should already be addressed specifically for timeouts in Release v2.4.11-pre.1.
The real issue is the long delays when communicating with the inverter. If you look at the Registers received requested : X Y there are 3 seconds between them, which is not normal, but also I don't know why that is happening or what I can do about it.
Also try turning off the "Keep Modbus Open" option as someone on the HA forums reported disabling this helped their similar issue.

I just just turned off 'keep modbus connection open".
Will see how it looks tomorrow

You have a 5 second polling interval, the integration currently forces that option for less than 10 seconds. I will need to make another pre-release to remove that condition.

Release v2.4.11-pre.6 removes internal requirement for keep modbus open if polling interval is less than 10 seconds.

thanks! I am still on Pre4 which runs stable for the last couple of hours. I have Keep Modbus Open set and the polling interval set for 30sec. Will get back tomorrow morning. Am 15.02.2024 um 22:45 schrieb Seth @.***>:
@mtbsteve
Please add an automatic reconnect service in case the modbus connection gets lost.
FYI this should already be addressed specifically for timeouts in Release v2.4.11-pre.1.
The real issue is the long delays when communicating with the inverter. If you look at the Registers received requested : X Y there are 3 seconds between them, which is not normal, but also I don't know why that is happening or what I can do about it.
Also try turning off the "Keep Modbus Open" option as someone on the HA forums reported disabling this helped their similar issue.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I do not recommend using keep open unless there is a specific problem it solves.

Pre6 with "keep modbus open" disabled and Pilling at 5s has worked perfectly overnight.

It looks like my issue was the "keep modbus open" then.
Thank you for the fix. Is it possible to remove the requirement to keep modbus open under 10s polling in your next release, but with all the other changes you were planning?

I do not recommend using keep open unless there is a specific problem it solves.

Thanks. I disabled Keep Open and with Pre4 the connection kept stable overnight. Keeping my fingers crossed :-)

I don't think this is a modbus issue since I've been experiencing the same issue for the whole of last year.
When I lose connection to the Modbus it's because the Inverter/Battery resets according to Solaredge which happens twice a day. This can also be seen in the SE monitoring portal as you see only power being drawn from the grid while both Solar and battery goes idle for 1 minute, before restablishing comms again.

Release 2.4.11-pre.7 goes back to pre.1, but the keep modbus open requirement for polling intervals under 10 seconds removed so it will now always follow the option setting for any polling interval.

Thanks.
I have installed pre7 and left my polling interval at 5s, with the keep alive unticked.  Has been working ok for 30 mins so will leave it overnight.
Incidentally, Pre6 was perfect all day. Not a single drop. I did see some errors in the log though...

The errors are still happening with pre7, but no drops observed....

@WillCodeForCats after 36 hours with Pre4, there are no more errors or disconnects in my setup.
Thanks a lot for your speedy resolution!

For another datapoint: I was having the same original issue. After reading this thread I installed pre7 and unticked keep alive. Polling interval = 10s. I've experienced no permanent drop-outs overnight. So it looks fixed?
I did see this in the logs:
Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:345
Integration: SolarEdge Modbus Multi (documentation, issues)
First occurred: 05:11:00 (1 occurrences)
Last logged: 05:11:00
Error fetching SolarEdge Coordinator data: Modbus/TCP connect to <IP_ADDRESS>:1502 failed.
But it's not a problem as it came back 10 seconds later.
As mtbsteve said, thanks for your speedy resolution, WillCodeForCats.

It is.

Can someone please explain to me how to install pre-releases? Do I have to enable someting in HA to see beta/pre-release versions in updates?

The connection errors are something I can't fix, unfortunately. I can only try to work around them. If the inverter doesn't accept a connection, it doesn't. The integration can detect that and will run through some retry attempts before it gives up. It's currently set to retry up to 5 times.
From the feedback it sounds like it's safe to take this into a final release so I'll do that shortly.

Can someone please explain to me how to install pre-releases? Do I have to enable someting in HA to see beta/pre-release versions in updates?

In HACS you have to navigate into the integration card, then go to the menu and choose "Redownload". The you have to turn on the show beta versions switch.

Hi - I am still experiencing repeated disconnects since 2.4.10. I tried the various pre-releases in this thread and updated to 2.4.11.

I have to re-load the integration manually, at which point things go OK for a short while but invariably gets lost again. Once the above error message fires and the entities become unavailable, additional errors show in logs as follows:

Upload your diagnostic file.

@addinsella Upload your diagnostic file.

Sorry - here is the diagnostic file - config_entry-solaredge_modbus_multi-1b85b484d42a0c2df324517598ee7358 (1).json

I am running 2.4.11 and I have experienced 2 more drops that required a reboot to restart data collection:

Same problem here still with 2.4.11. Need to reload integration many times per day.

The last idea I have is clearing the pymodbus object on timeouts.
But if this doesn't help then someone who has this issue is going to have to try to analyze it and suggest a fix or submit a PR to me. Maybe it's related to the network, or how HA is installed, or the hardware, or inverter firmware, or a bug in the pymodbus library. In any case I don't see this problem personally so I can't duplicate it.

If you want to try different versions of the pymodbus library you will need to edit the file custom_components/solaredge_modbus_multi/manifest.json and change the folowing line:
  "requirements": ["pymodbus>=3.5.4"],

Change pymodbus>=3.5.4 to something like pymodbus==3.5.4 to fix the version rather than use the current version HA ships with (I believe HA 2024.2.2 has pymodbus 3.6.3). The latest version is pymodbus==3.6.4 which will probably be in HA 2024.3.
After changing this reboot Home Assistant to reload requirements since these are only loaded at startup.
You can try other versions listed here: https://github.com/pymodbus-dev/pymodbus/releases

Release v2.4.12-pre.1 will clear the pymodbus object on timeouts.

Thank you.  I will install and try that version now.
I'm afraid I cannot help with a fix / PR as I have next to no coding skills.  I am very happy to continue to test and to submit logs etc to assist anyone who can suggest a fix.

Same problem here still with 2.4.11. Need to reload integration many times per day.

just curious - are you using the Tibber integration in parallel?

@WillCodeForCats now I am having the first disconnect since I installed Pre4 on Feb 15. In the logs I observed exactly 4 drops in connection over the past days prior to the final disconnect this morning. Could it be that the 5 times-retry-counter is not reset once the interface establishes a reconnect?
Also, why are you limiting it to 5 retries? Other integrations, such as eg the Shelly adapter are retrying indefinitely once a connection breaks.

There is no actual limit, it's 5 times with an escalating multiplier before the data is considered stale due to failure to refresh it and signals that to HA (unavailable state). Other integrations may prefer to keep showing stale data which appears on the graphs as an unchanging flat line.
You can change that value in const.py and adjust the settings under class RetrySettings
You can turn on debug to observe if the counter is reset. THe message Timeout count X limit Y logs the values before it gets reset to zero. The message Refresh timeout X limit {RetrySettings.Limit} shows the values as it increments.

I would recommend trying your own values based on observations, I can't provide any guidance on what would be appropriate since I can't duplicate this issue.
Making the internal retry very long will hide the connection errors and give you flat line graphs if you prefer that. But you can also end up with stale or bad data without any warning.

Did this resolve your issues?
--
Markus Westerberg
Den tis 20 feb. 2024 kl 17:33 skrev mtbsteve @.***>:

Example of fixed 5 seconds between attempts for up to 720 times (1 hour of
retries between attempts, which does not include timeouts during the
polling cycles, so longer in reality):
class RetrySettings(IntEnum):
"""Retry settings when opening a connection to the inverter fails."""
Time = 5000  # first attempt in milliseconds
Ratio = 1  # time multiplier between each attempt
Limit = 720  # number of attempts before failing

You can try this and try changing the pymodbus library versions.
Otherwise at the moment I'm out of ideas on this one.
Thanks I configured the settings accordingly 👍
—
Reply to this email directly, view it on GitHub
https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/535#issuecomment-1954600430,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCOLLL6SVAJGZHRH7U2KFADYUTF6PAVCNFSM6AAAAABDKEU3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUGYYDANBTGA
.
You are receiving this because you commented.Message ID:
@.***>

I am running 2.4.12.pre-1 and the connection has been solid for a week now. Thanks @WillCodeForCats

Another data point here:  I have been running .12Pre2 since it was released and I have not had any drops since.

Unfortunatelly for me this is still an issue...

Do you want me to enable debuging and send logs?

There may be something common about the people that have this problem compared to those that don't (like me). I don't know what could be though. Hopefully someone will be able to duplicate this problem and suggest a fix.
Feel free to upload logs if you like, but I for now don't have any new ideas other than what I've already suggested to try. Sorry.

There was a Solaredge Server outage between 9:20am and 10:40am CET this morning. Access through the Solaredge Monitoring App, Modbus and Web API was not possible.
The modbus multi integration automatically restored the connection right after the SE monitoring platform was accessible again.
I am using the retrySettings in const.py as suggested by @WillCodeForCats  above. Seems that this works.
If others are still experiencing problems it would be helpful to list also the other HA adapters in use.
I am suspicious if there is a correlation with the Tibber access since I observed some coincidence with crashes of the HA Tibber link adapter.

I am using the retrySettings in const.py as suggested by @WillCodeForCats above. Seems that this works.

I am investigating if it's possible to use a YAML config to set overrides for those so they can persist across updates, since altering the file will not. I don't really want those to be able to be changed through the UI options.

There was a Solaredge Server outage between 9:20am and 10:40am CET this morning. Access through the Solaredge Monitoring App, Modbus and Web API was not possible. The modbus multi integration automatically restored the connection right after the SE monitoring platform was accessible again. I am using the retrySettings in const.py as suggested by @WillCodeForCats above. Seems that this works.
If others are still experiencing problems it would be helpful to list also the other HA adapters in use. I am suspicious if there is a correlation with the Tibber access since I observed some coincidence with crashes of the HA Tibber link adapter.

Although mine seems to be working nicely now, I wanted to just confirm that I do not, and never have, run the Tibber addin.  (never heard of Tibber).
The only possible lead is that I did update my SolarEdge inverter's firmware just before this all started to go wrong.  Perhaps that is the missing link....

There was a Solaredge Server outage between 9:20am and 10:40am CET this morning. Access through the Solaredge Monitoring App, Modbus and Web API was not possible. The modbus multi integration automatically restored the connection right after the SE monitoring platform was accessible again. I am using the retrySettings in const.py as suggested by @WillCodeForCats above. Seems that this works.
If others are still experiencing problems it would be helpful to list also the other HA adapters in use. I am suspicious if there is a correlation with the Tibber access since I observed some coincidence with crashes of the HA Tibber link adapter.

It is not related directly to SE server disconnects. I have completely block internet connection of the inverter to SE servers and I have random disconnects since many versions ago. Before they were even more often.
When my modbus disconnects with the SE, I stop being able to control the storedge features as the inverter stops responding even I can keep the receiving readings after it reconnects the modbus between HA and inverter.
Full modbus reconnection and storedge responds only the morning after, when the inverter kind of “restores” when it starts producing energy.
I have also noticed that storedge values of maximum discharge and charge value set to 5400W after the disconnect happens

I'm getting the same issue since about 21/02/2024. Restarting HA does help. Prior to that, the connection was rock-solid.

I've read this thread in details and about to upgrade to the latest beta.

Also check if your inverter firmware changed with sensor sensor.solaredge_i1_version
The version of the pymodbus library can also change with various HA releases. The next release 2024.3 will have pymodbus version 3.6.4.

Updating to pre12-2 seems to have resolved all my issues.
--
Markus Westerberg
Den tors 29 feb. 2024 kl 22:38 skrev Seth @.***>:

Also check if your inverter firmware changed with sensor
sensor.solaredge_i1_version
The version of the pymodbus library can also change with various HA
releases. The next release 2024.3 will have pymodbus version 3.6.4.
—
Reply to this email directly, view it on GitHub
https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/535#issuecomment-1972006432,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCOLLLZL6VE4VWIGYPKZSXDYV6PXBAVCNFSM6AAAAABDKEU3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSGAYDMNBTGI
.
You are receiving this because you commented.Message ID:
@.***>

Also check if your inverter firmware changed with sensor sensor.solaredge_i1_version
The version of the pymodbus library can also change with various HA releases. The next release 2024.3 will have pymodbus version 3.6.4.

The more I think about this issue, the more I am convinced that the inverter firmware has a LOT to do with it.
@WillCodeForCats Have you connected to your inverter with SetApp recently?  As you are unable to replicate the issues, I wonder if your inverter is on a slightly older build....

So I'm on integration version 2.4.12-pre.4, and the issue happened again just now.
The inverter firmware is 0003.2725.
I've started to collect the logs, will see what I can do.

My inverters are running  0004.0014.0229

Mine are SE5000, which are not SetApp-enabled. Hence, I don't believe the firmware is going to be of the same version.

Mine are SE5000H, which are not SetApp-enabled. Hence, I don't believe the firmware is going to be of the same version. They look something like this:

Advanced YAML config options from PR #553 will be in the next pre-release.

Advanced YAML config is now available in Release v2.4.13-pre.2
Documentation has been added in the wiki at:
https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Configuration#advanced-configuration-with-yaml

@WillCodeForCats I just updated to the latest prerelease 2.4.13pre3. Connection is completely broken now.
TypeError: Cannot read properties of null (reading 'removeEventListener')
renderHeading (src/components/ha-dialog.ts:53:24)
apply (src/scoped-custom-element-registry.js:262:44)
mainWindow.history.pushState (src/dialogs/make-dialog-manager.ts:129:7)
2024-03-09 10:44:53.443 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] solaredge_modbus_multi configuration: number_of_inverters=2, start_device_id=1, detect_meters=True, detect_batteries=True, detect_extras=True, keep_modbus_open=False, adv_storage_control=True, adv_site_limit_control=False, allow_battery_energy_reset=False, sleep_after_write=0, battery_rating_adjust=0,
2024-03-09 10:44:53.444 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Retry limit=5 time=800 ratio=3
2024-03-09 10:44:53.444 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] New client object for <IP_ADDRESS>:1502
2024-03-09 10:44:53.444 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] reconnect_delay=0 reconnect_delay_max=3 retry_on_empty=Falsetimeout=3
2024-03-09 10:44:53.523 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 31.2
2024-03-09 10:44:53.523 WARNING (MainThread) [custom_components.solaredge_modbus_multi.hub] Power Control Options: Storage Control is enabled. Use at your own risk!
2024-03-09 10:44:53.580 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 69 69
2024-03-09 10:44:53.580 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_ID 0x53756e53<class 'int'>
2024-03-09 10:44:53.581 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_DID 0x1<class 'int'>
2024-03-09 10:44:53.581 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_Length 0x41<class 'int'>
2024-03-09 10:44:53.581 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Manufacturer SolarEdge<class 'str'>
2024-03-09 10:44:53.581 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Model SE10K-RWB48BFN4<class 'str'>
2024-03-09 10:44:53.582 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Option <class 'str'>
2024-03-09 10:44:53.582 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Version 0004.0019.0039<class 'str'>
2024-03-09 10:44:53.582 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SerialNumber 7B072907<class 'str'>
2024-03-09 10:44:53.582 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Device_address 0x1<class 'int'>
2024-03-09 10:44:53.623 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 9 9
2024-03-09 10:44:53.623 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_DID 0x1 <class 'int'>
2024-03-09 10:44:53.623 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_Length 0x41 <class 'int'>
2024-03-09 10:44:53.624 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_Units 0x0 <class 'int'>
2024-03-09 10:44:53.624 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 is NOT Multiple MPPT
2024-03-09 10:44:53.675 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 67 67
2024-03-09 10:44:53.676 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SunSpec_DID 0x1 <class 'int'>
2024-03-09 10:44:53.676 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SunSpec_Length 0x41 <class 'int'>
2024-03-09 10:44:53.677 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Manufacturer SolarEdge <class 'str'>
2024-03-09 10:44:53.677 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Model MTR-240-3PC1-D-A-MW <class 'str'>
2024-03-09 10:44:53.677 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Option Export+Import <class 'str'>
2024-03-09 10:44:53.677 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Version 1.0.15 <class 'str'>
2024-03-09 10:44:53.678 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SerialNumber 6325eb15 <class 'str'>
2024-03-09 10:44:53.678 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Device_address 0x2 <class 'int'>
2024-03-09 10:44:53.678 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Found I1M1
2024-03-09 10:44:53.745 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 67 67
2024-03-09 10:44:53.745 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_SunSpec_DID 0x2bd <class 'int'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_SunSpec_Length 0x99 <class 'int'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_Manufacturer 4c	7 <class 'str'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_Model z <class 'str'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_Option  <class 'str'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_Version 	7 <class 'str'>
2024-03-09 10:44:53.746 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_SerialNumber  <class 'str'>
2024-03-09 10:44:53.747 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: C_Device_address 0x8000 <class 'int'>
2024-03-09 10:44:53.747 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M2: Meter 2 ident incorrect or not installed.
2024-03-09 10:44:53.781 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 67 67
2024-03-09 10:44:53.782 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_SunSpec_DID 0xffff <class 'int'>
2024-03-09 10:44:53.782 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_SunSpec_Length 0x0 <class 'int'>
2024-03-09 10:44:53.782 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_Manufacturer  <class 'str'>
2024-03-09 10:44:53.782 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_Model  <class 'str'>
2024-03-09 10:44:53.782 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_Option  <class 'str'>
2024-03-09 10:44:53.783 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_Version  <class 'str'>
2024-03-09 10:44:53.783 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_SerialNumber A <class 'str'>
2024-03-09 10:44:53.783 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: C_Device_address 0xffff <class 'int'>
2024-03-09 10:44:53.783 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M3: Meter 3 ident incorrect or not installed.
2024-03-09 10:44:53.898 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 68 68
2024-03-09 10:44:53.899 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_Manufacturer SolarEdge <class 'str'>
2024-03-09 10:44:53.899 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_Model SolarEdge Home Battery 9.2kWh <class 'str'>
2024-03-09 10:44:53.900 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_Version 48V DCDC 3.2.9 <class 'str'>
2024-03-09 10:44:53.900 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_SerialNumber 7B072907 <class 'str'>
2024-03-09 10:44:53.900 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_Device_Address 0x70 <class 'int'>
2024-03-09 10:44:53.900 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B1: B_RatedEnergy 0x460fc000 <class 'float'>
2024-03-09 10:44:53.900 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Found I1B1
2024-03-09 10:44:53.966 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 68 68
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_Manufacturer SolarEdge <class 'str'>
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_Model SolarEdge Home Battery 9.2kWh <class 'str'>
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_Version  <class 'str'>
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_SerialNumber  <class 'str'>
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_Device_Address 0xff <class 'int'>
2024-03-09 10:44:53.967 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: B_RatedEnergy 0xff7fffff <class 'float'>
2024-03-09 10:44:53.968 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B2: Battery 2 not usable (rating <=0)
2024-03-09 10:44:54.020 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 68 68
2024-03-09 10:44:54.021 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_Manufacturer SolarEdge <class 'str'>
2024-03-09 10:44:54.021 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_Model SolarEdge Home Battery 9.2kWh <class 'str'>
2024-03-09 10:44:54.021 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_Version  <class 'str'>
2024-03-09 10:44:54.022 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_SerialNumber  <class 'str'>
2024-03-09 10:44:54.022 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_Device_Address 0xff <class 'int'>
2024-03-09 10:44:54.022 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: B_RatedEnergy 0xff7fffff <class 'float'>
2024-03-09 10:44:54.022 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1B3: Battery 3 not usable (rating <=0)
2024-03-09 10:45:06.028 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 12.584 seconds (success: False)

I have the same as @mtbsteve
2024-03-09 20:46:16.874 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:46:16.962 ERROR (MainThread) [homeassistant.components.homekit] HomeKit Front Door cannot startup: entity not available: {'include_domains': [], 'exclude_domains': [], 'include_entities': ['lock.doorlock_10'], 'exclude_entities': [], 'include_entity_globs': [], 'exclude_entity_globs': []}
2024-03-09 20:46:30.450 WARNING (MainThread) [pymodbus.logging] Failed to connect
2024-03-09 20:46:33.435 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 625, in async_add_entities
    await add_func(coros, entities, timeout)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 573, in _async_add_entities
    async with self.hass.timeout.async_timeout(timeout, self.domain):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/timeout.py", line 469, in async_timeout
    current_task: asyncio.Task[Any] | None = asyncio.current_task()
                                             ^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: no running event loop
2024-03-09 20:46:33.448 WARNING (MainThread) [py.warnings] /usr/local/lib/python3.12/asyncio/tasks.py:670: RuntimeWarning: coroutine 'EntityPlatform._async_add_entity' was never awaited
  def ensure_future(coro_or_future, *, loop=None):

2024-03-09 20:46:33.449 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 625, in async_add_entities
    await add_func(coros, entities, timeout)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 573, in _async_add_entities
    async with self.hass.timeout.async_timeout(timeout, self.domain):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/timeout.py", line 469, in async_timeout
    current_task: asyncio.Task[Any] | None = asyncio.current_task()
                                             ^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: no running event loop
2024-03-09 20:49:05.388 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:49:18.648 WARNING (MainThread) [pymodbus.logging] Failed to connect
2024-03-09 20:49:29.984 ERROR (MainThread) [frontend.js.latest.202403060] Uncaught error from Chrome WebView 121.0.6167.144 on Android 12
TypeError: Cannot read properties of null (reading 'removeEventListener')
renderHeading (src/components/ha-dialog.ts:53:24)
apply (src/scoped-custom-element-registry.js:262:44)
mainWindow.history.pushState (src/dialogs/make-dialog-manager.ts:129:7)
2024-03-09 20:49:40.794 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:50:28.939 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:50:41.363 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:51:04.651 WARNING (MainThread) [pymodbus.logging] Failed to connect
2024-03-09 20:51:44.834 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:58:23.239 ERROR (MainThread) [frontend.js.latest.202403060] Uncaught error from Chrome WebView 121.0.6167.144 on Android 12
TypeError: Cannot read properties of null (reading 'removeEventListener')
renderHeading (src/components/ha-dialog.ts:53:24)
apply (src/scoped-custom-element-registry.js:262:44)
mainWindow.history.pushState (src/dialogs/make-dialog-manager.ts:129:7)
2024-03-09 20:58:30.275 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('<IP_ADDRESS>', 1502)
2024-03-09 20:58:43.268 WARNING (MainThread) [homeassistant.helpers.entity] Update of switch.chuangmi_212a01_0e98_switch is taking over 10 seconds
2024-03-09 20:58:43.882 WARNING (SyncWorker_28) [custom_components.xiaomi_miot.core.xiaomi_cloud] Request xiaomi api: v2/user/statistics {'did': '552382854', 'key': 'prop.5.1', 'data_type': 'stat_day_v3', 'time_start':<PHONE_NUMBER>, 'time_end':<PHONE_NUMBER>, 'limit': 31} failed, response: None
2024-03-09 20:58:43.898 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'result' is undefined when rendering '{%- set dat = namespace(today=0,month=0) %}{%- set tim = now() %}{%- set stm = tim - timedelta(minutes=tim.minute,seconds=tim.second) %}{%- set tod = stm - timedelta(hours=tim.hour) %}{%- set stm = tod - timedelta(days=tim.day-1) %}{%- set tod = tod | as_timestamp | int(0) %}{%- set stm = stm | as_timestamp | int(0) %}{%- for d in (result or []) %}{%-   set t = d.time | default(0) | int(0) %}{%-   if t >= stm %}{%-     set v = (d.value | default('[]') | string | from_json) or [] %}{%-     set n = v[0] | default(0) %}{%-     if t >= tod %}{%-       set dat.today = n %}{%-     endif %}{%-     set dat.month = dat.month + n %}{%-   endif %}{%- endfor %}{{ {'power_cost_today': dat.today | round(3),'power_cost_month': dat.month | round(3),} }}'
2024-03-09 20:58:44.796 ERROR (MainThread) [frontend.js.latest.202403060] Uncaught error from Chrome WebView 121.0.6167.144 on Android 12
TypeError: Cannot read properties of null (reading 'removeEventListener')
renderHeading (src/components/ha-dialog.ts:53:24)
apply (src/scoped-custom-element-registry.js:262:44)
mainWindow.history.pushState (src/dialogs/make-dialog-manager.ts:129:7)
2024-03-09 20:59:19.477 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] solaredge_modbus_multi configuration: number_of_inverters=1, start_device_id=1, detect_meters=True, detect_batteries=False, detect_extras=True, keep_modbus_open=True, adv_storage_control=False, adv_site_limit_control=False, allow_battery_energy_reset=False, sleep_after_write=0, battery_rating_adjust=0,
2024-03-09 20:59:19.477 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] New client object for <IP_ADDRESS>:1502
2024-03-09 20:59:21.538 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 21.6
2024-03-09 20:59:25.091 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 69 69
2024-03-09 20:59:25.091 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_ID 0x53756e53<class 'int'>
2024-03-09 20:59:25.091 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_DID 0x1<class 'int'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SunSpec_Length 0x41<class 'int'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Manufacturer SolarEdge<class 'str'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Model SE10000H-AUSNBBX14<class 'str'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Option <class 'str'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Version 0004.0016.0023<class 'str'>
2024-03-09 20:59:25.092 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_SerialNumber 74075935<class 'str'>
2024-03-09 20:59:25.093 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1: C_Device_address 0x1<class 'int'>
2024-03-09 20:59:28.723 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 9 9
2024-03-09 20:59:28.724 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_DID 0x1 <class 'int'>
2024-03-09 20:59:28.724 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_Length 0x41 <class 'int'>
2024-03-09 20:59:28.724 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 MMPPT: mmppt_Units 0x0 <class 'int'>
2024-03-09 20:59:28.724 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1 is NOT Multiple MPPT
2024-03-09 20:59:40.302 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 67 67
2024-03-09 20:59:40.303 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SunSpec_DID 0x1 <class 'int'>
2024-03-09 20:59:40.303 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SunSpec_Length 0x41 <class 'int'>
2024-03-09 20:59:40.303 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Manufacturer SolarEdge <class 'str'>
2024-03-09 20:59:40.303 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Model SE-MTR-3Y-400V-B <class 'str'>
2024-03-09 20:59:40.303 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Option Export+Import <class 'str'>
2024-03-09 20:59:40.304 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Version 77 <class 'str'>
2024-03-09 20:59:40.304 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_SerialNumber 606950035 <class 'str'>
2024-03-09 20:59:40.304 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] I1M1: C_Device_address 0x1 <class 'int'>
2024-03-09 20:59:40.305 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Found I1M1
2024-03-09 20:59:43.139 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 23.662 seconds (success: False)
2024-03-09 20:59:48.234 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] solaredge_modbus_multi configuration: number_of_inverters=1, start_device_id=1, detect_meters=True, detect_batteries=False, detect_extras=True, keep_modbus_open=True, adv_storage_control=False, adv_site_limit_control=False, allow_battery_energy_reset=False, sleep_after_write=0, battery_rating_adjust=0,
2024-03-09 20:59:48.234 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] New client object for <IP_ADDRESS>:1502
2024-03-09 20:59:51.237 WARNING (MainThread) [pymodbus.logging] Failed to connect
2024-03-09 20:59:51.237 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 21.6
2024-03-09 20:59:51.238 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 3.004 seconds (success: False)

Weird, I didn't change code.

Try editing the file manifest.json and look for the line that says:
"requirements": ["pymodbus>=3.6.4"],
Change it to:
"requirements": ["pymodbus>=3.6.5"],
Or also try:
"requirements": ["pymodbus>=3.6.6"],
Reboot is required when changing requirements.

A hard reset (powercycle of the HA yellow) solved it. Interestingly, a restart of HA from the Developer Options menu was apparently not sufficient after I installed the latest version.
2.4.13 pre3 is running now uninterrupted for 2 days now. What is the difference between all those pymodbus versions?

The differences are listed on the pymodbus release page:
https://github.com/pymodbus-dev/pymodbus/releases

Has anyone tried the YAML advanced options? If there aren't any problems with them I will take them to a full release.

Has anyone tried the YAML advanced options? If there aren't any problems with them I will take them to a full release.

Nope.
My install has stabilised in recent weeks so I'm not gonna mess with it.

Mine too. Not sure why but I'm not messing with something that is working :D
--
Markus Westerberg
Den sön 17 mars 2024 kl 09:20 skrev Siggy101 @.***>:

Has anyone tried the YAML advanced options? If there aren't any problems
with them I will take them to a full release.
Nope.
My install has stabilised in recent weeks so I'm not gonna mess with it.
—
Reply to this email directly, view it on GitHub
https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/535#issuecomment-2002358509,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCOLLL2SPGDJY2NJJPZDDP3YYVG4RAVCNFSM6AAAAABDKEU3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGM2TQNJQHE
.
You are receiving this because you commented.Message ID:
@.***>

For your information, in case it helps: I have noticed this issue on my Home Assistant (Core 2024.3.1 / Supervisor 2024.03.0) on both SolarEdge inverter releases 4.19.39 and 4.20.32 (see https://www.solaredge.com/en/support/setapp-inverters-firmware). A few days ago, as suggested in https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/562, I manualy set the version for pymodbus (https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/562#issuecomment-2002415007) and everything was fine until yesterday when I had the same problem even though no obvious changes had happened. I tried manually changing the pymodbus to multiple versions, including 3.6.6, followed by a reboot, but with no success. I didn't try to update the timeout settings. What seems to have fix it is a restart of the leader inverter (I have two, running the same versions). The pymodbus is still set to 3.6.6 and I do not want to change it to check if something else works until I have this issue again or there is another release of any of the related projects.

My install never had this issue, but it's now disconnecting every day or two since upgrading to
v2.4.13-pre.3. I then have to reload the integration to reconnect manually.

There are no changes in v2.4.13-pre.3 so that would mean the problem is with HA core or the pymodbus version included with HA core.

The pymodbus library has been updated several times since this issue was opened; closing issue.


minor fix to capitalization

Traces doesn't need to be capitalized everywhere.

@codeboten While you're at it, can you replace this line:
- Sign up for one of our monthly interview/feedback sessions

with this:
- [Sign up for one of our monthly interview/feedback sessions](https://opentelemetry.io/community/end-user/interviews-feedback/)

I tried to do an in-line suggestion, but for some reason, it wouldn't let me? 🤷♀

@avillela done!


broken out of the box?

Is there something im doing wrong? the component wont render
import React from 'react';
import ReactDOM from 'react-dom';
import ReactSlider from 'react-slider';
const DepthMeterInput = React.createClass({
render() {
return (

blahahh

);
}
})
export default DepthMeterInput

i dont know why but it doesnt show my render

    <ReactSlider defaultValue={50} />
    blahahh

@foodaka For now react slider is a non-es6 module, so you should use CommonJS require call or import this with * like this:
import React from 'react';
import ReactDOM from 'react-dom';
import * as`ReactSlider  from 'react-slider';

const DepthMeterInput = React.createClass({
  render() {

      <ReactSlider defaultValue={50} />
      blahahh

  }
})

export default DepthMeterInput;

@foodaka it seems that it doesn't work even with your workaround?

@foodaka @istrel this issue is still present, workaround doesn't word, should be reopened!

@VanDavv DId you try to use CommonJS require? It should work with webpack:
import React from 'react';
import ReactDOM from 'react-dom';
const ReactSlider = require('react-slider');

const DepthMeterInput = React.createClass({
  render() {

      <ReactSlider defaultValue={50} />
      blahahh

  }
})

export default DepthMeterInput;

Yes, and I still didn't manage to see the slider. Sorry, but i ended up using rc-slider

im unable to see the slider too

The slider is hidden by default. The divs are there with the right classes, but without CSS rules they are empty. Hopefully it's just a matter of adding the CSS you want.


Startup crash - integer overflow?

The code and data are out of sync. git pull, and run ./data/grab_seed_data.sh again (or rebuild the maps yourself). I'll add some error handling here to explain what's happening more clearly

I'm getting the same error.  Grab the latest data and performed a git pull on the current local repo.  No luck.  Tried also a completely new clone and performed the same steps but still no luck.  Maybe it's a windows thing, I'll try on mac later today.

It works fine on mac.  I was able to compile and run the game.
On Windows, I tried also using the Windows Subsystem for Linux(WSL) feature with Ubuntu.  Compiling and running the game within Ubuntu using this feature, the game still crashed at startup with the following error:

The WSL issue seems like an issue with https://github.com/rust-windowing/winit. Since you compiled on Ubuntu, winit found bindings to wayland (your display server), but when you run on Windows, wayland doesn't exist.
The very first error is a serde deserialization error. Every time I've seen it, it means the file I'm reading was serialized with older code. I've never seen a difference between platforms matter.
What I'll work on:

better errors when running the game if map data is missing or out-of-date
a script to download a much smaller set of files to run from source (you won't be able to rebuild maps from scratch, but you'll be able to work on the simulation and GUI layers)
figuring out what the deserialization issue is here

First two problems fixed. I don't have a Windows env and so can't easily help debug. Seems like using WSL doesn't work (kind of by design), so if you try again normally and still get the "invalid value" deserialization error, check the md5sum of the montlake.bin file. It should match data/MANIFEST.txt's entry.

Closing old bugs. If you're still having issues, please reopen. Thanks!


iOS Categories - Titanium iOS

https://www.pushwoosh.com/programming-push-notification/features-guides/ios-8-interactive-push/
this new module already has the iOS Categories working?

Yes!


[#105] Fact Clustering with TD-IDF and K-Means++

Fact Clustering with TD-IDF and K-Means++

I am able to run KMeansWrapper("text_bk/",100,10) in local, but seems like Travis is complaining ModuleNotFoundError: No module named 'feature_extraction'


Update smartsynchronize to v3.4.3

Thank you for the contribution. It was merged directly as 465138cad29deef7912506e4e16264f7610ec0e4 to keep commit history cleaner. Your contribution is still credited to you.


Text and icons disappeared with 1.69.2 (Ubuntu ARM 64-bit)

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.69.2 arm64
OS Version: Ubuntu 20.04 ARM 64-bit

Steps to Reproduce:

sudo apt purge code
sudo rm -r ~/.config/Code
sudo rm -r ~/.vscode
sudo dpkg -i code_1.69.2-1658161440_arm64.deb
code --disable-extensions

Text and icons disappeared

Are you referring to the fact that your Activity Bar is blank apart from the gearwheel?

Can you provide the output of code --verbose

Text and icons disappeared

Are you referring to the fact that your Activity Bar is blank apart from the gearwheel?

A lot of the text has disappeared everywhere.
Here is an example of opening a workspace (with the "Trust" prompt)

Here is an example of an open file with the open directory on the left

Can you provide the output of code --verbose

output.txt

Thanks for the log, I see a lot of shader errors. Can you see if the problem happens when you start with --disable-gpu ?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

Sorry about the delay, I did not get to test for a long while !
FYI, the issue is still present in 1.71, but running it with --disable-gpu solves the problem !
I guess there should be an error somewhere in the middleware or even in QEMU settings or implementation, but it's still weird that ONLY 1.69.2 and onward trigger the problem.
I will try to change GPU settings in QEMU, but let me know if I can collect more data to investigate the problem itself.

Here are the GPU modes I've tested in QEMU display mode :

virtio-ramfb-gl (GPU supported) : problem exists
virtio-ramfb : no problem (although the graphics are somewhat unresponsive)
As far as I know, other modes don't allow the system to boot at all, or result in a completely unresponsive system.

So it's certainly an interaction with the GPU implemented by QEMU on M1 accelerated hardware, but again only this app has the problem (specifically, browsers and all desktop apps work just fine).

Thanks for checking, this usually indicates an issue in the runtime and I would expect this to get addressed in future runtime updates. I recommend running with gpu acceleration disabled using the following steps

Open Command Palette inside VSCode and search for "Configure Runtime Arguments"
Set disable-hardware-acceleration: true
Restart


Disable logging for MockWebServer

Feature request: A way to disable the MockWebServer logging
I'm currently using MockWebServer for my tests, and it's spamming the test output with its log. As far as I can tell, there's no way to disable the logging of MockWebServer. This is an important missing feature for me since it's tough to find the information I want when the log is full of hundreds of lines like this:
INFO: MockWebServer[51602] received request: GET /api/v2/berry/34/ HTTP/1.1 and responded: HTTP/1.1 200 OK
Jun 15, 2016 9:20:52 PM okhttp3.mockwebserver.MockWebServer$4 processOneRequest

You can use the java.util.logging APIs to mute logging for any class, including MockWebServer.

Here a concrete way to make MockWebServer a little less noisy ;)
Basically, you can use this anywhere
Logger.getLogger(MockWebServer::class.java.name).level = Level.WARNING
For example like this
import okhttp3.mockwebserver.MockWebServer
import java.util.logging.Level
import java.util.logging.Logger

/**
 * Avoids noise in the test output
 * by setting the logging level of [MockWebServer] to [Level.WARNING]
 * and then calling [MockWebServer.start]
 */
fun MockWebServer.startSilently() {
    Logger.getLogger(this::class.java.name).level = Level.WARNING
    start()
}

// That extension can be used like this
val mockWebServer = MockWebServer()
mockWebServer.startSilently()

For those who want a copy-paste snippet for Java:
Logger.getLogger(MockWebServer.class.getName()).setLevel(Level.WARNING);
// or totally silent
Logger.getLogger(MockWebServer.class.getName()).setLevel(Level.OFF);


Rake Arguments

Hi,
I'm trying to send an argument to rake using square brackets(as mentioned here: https://robots.thoughtbot.com/how-to-use-arguments-in-a-rake-task).
Whenever seems to ignore the task when there are brackets
For example
rake 'tweets:send'  - written to crontab
rake 'tweets:send[cpytel]' - not written to crontab.
Any workaround?
Thanks!

The above commit verifies the absence of this bug. If you can reproduce this on the master branch, please provide more details (schedule.rb, whenever output, etc) to demonstrate it.


TypedDecoder: Add Union Type for GitHub.Repository.Rule*

A recent update of the spec introduced repository rules, which are communicated in a large union type. A special case of the typed decoder is necessary to handle this correctly.

Resolved by aad1ca8c61ad9893f8b502637b76b9dd97d13957


Minor re-work of Criteria-Catalog for 2021

e.g. open government add accessibility
https://www.access-for-all.ch/ch/projekte/publikationen/574-schweizer-accessibility-studie-onlineshops.html

Resolving for 2021 - please feel free to re-open / adjust for 2022.


I merged from upstream accidentally

AAAA I can't believe I did this on the first day
So sorry for the notifications
For the future I will use a fork
What happened was I wanted to look at the differences between this and atom...master, so I clicked the top right button (wrong) and then my hand moved automatically to the green (!!):

I'm currently getting help from the python, programming, and ts discord servers in order to revert this "as if this never happened", which means that this repo should be some commits behind

Current notes:
Can't rebase last n commits, merge pr commit chronologically is interspersed with non-pr commits
In addition, when I merged that pr, it seems like a bunch of atom prs were created to match:

I think this because I'm pretty sure the actual last pr was aminya's upstream
This implies (as said above) that the latest non-pr commit happens After the first pr commit:
5 yrs ago

https://github.com/atom-community/atom/pull/309 was on aug 16, 2021 and is definitely non-pr

Fixed by undoing the undo merge and the accidental merge then force push
git reset HEAD^^
git reset HEAD^^
git push -f


Add PolicyTypes to allow-all egress policy

PolicyTypes default to ["Egress", "Ingress"],
it doesn't make sense for egress-only policy to have Ingress as PolicyType.

/assign @chenopis

/assign
/approve


PPO2 with MlpLstmPolicy crashes GPU

Describe the bug
While training using PPO2 with MlpLstmPolicy on custom env, my computer intermittently freezes yet continues training. When I attempt to monitor GPU's with watch -n0.5 nvidia-smi it loads first gpu data then seems to hang for a while until I see that my second GPU has an error. Even after training, anything that uses a gpu glitches requiring me to reset the computer even to run another model. I've run the same training on the same env using just MlpPolicy and it trains just fine (although my problem needs a recurrent network so I always get bad results) and I can monitor everything without GPU glitches. I thought it might be memory overload but I don't get anywhere near using all the ram or GPU memory.
Code example
import gym
import money_maker
import os

from stable_baselines.common.policies import MlpLstmPolicy, LstmPolicy
from stable_baselines.common.vec_env import SubprocVecEnv
from stable_baselines import PPO2

# multiprocess environment
n_cpu = 128
env = SubprocVecEnv([lambda: gym.make('maker-v0') for i in range(n_cpu)])

model = PPO2(MlpLstmPolicy, env, verbose=1, nminibatches=32,
             tensorboard_log="./ppo2_lstm_21_jan_morn_tensorboard/")

model.learn(total_timesteps=10000000)
model.save("ppo2_maker_lstm")
del model
env.close()

System Info
Describe the characteristic of your environment:

installed using PIP according to docs
2- gtx-1080ti GPU's, driver:410.93,
python version 3.6.5 in conda environment
Tensorflow version: 1.12.0

Additional context

Awesome!!! No more crashing and logs are about 100x smaller. Good job guys!

Closed by #185


Add CI

[ ] Build, lint and clippy on commit
[ ] Automate release publication
[ ] Automate building Windows binaries

We're planning to combine rgbds-obj with rgbobj and rsgbds in one repo for the 1.0.0 release, so having a polished CI setup here would not be worthwhile.


refactor: Upload file streaming endpoint

Description:
Add an UploadFileV2 endpoint to APIC that uses GRPC streaming. For now the 4MB limits remains, it will be lifted once all endpoints are migrated to streaming.
Is this change user facing?
NO

References (if applicable):

Discussed offline. Makes sense to update the one we currently have for upload_file. However, as noted in the description, this PR does not raise the max file size of 4MB so adding the test in this PR doesn't make sense. I'll merge and add the test as a FLUP in the final PR that raises the file size limit.


[AMBARI-22712] Update install Wizard layout. Fourth patch.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/385/
Test FAILed.
Test FAILured.

Jenkins Build failed due to Ambari Agent:
[INFO] Ambari Agent ....................................... FAILURE [ 49.304 s]
And patch consists only of UI style and template changes


Add skopeo and umoci to CI image

Adds skopeo and umoci binaries to the CI's check-payload image.
xref: https://redhat-internal.slack.com/archives/C05U13J3LLS/p1716476010936559?thread_ts=1715954957.336589&cid=C05U13J3LLS

/cc @mrunalp


fixes issue #499 Fixing the routes

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes:  #499

Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[ ] I have made this from my own
[ ] I have taken help from some online resourses and mentioned in PR
[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

this fixes links only not images.

Uploading Amazing-CSS-Effects - Google Chrome 2022-04-05 16-38-07.mp4…
@VidhiBhatt01

maura-dev  did these changes should i close this pr?

@wre9-tesh i am closing it for now if problem remains u can work on it