check_zpool_scrub: Illegal number:      0B repaired, 45.26% done, 0 days 01:07:10 to go

Hey there,
I recently upgraded to Debian Buster.
Now I get the following error while scrubbing
/usr/lib/nagios/plugins/check_zpool_scrub
/usr/lib/nagios/plugins/check_zpool_scrub: 494: /usr/lib/nagios/plugins/check_zpool_scrub: Illegal number:      0B repaired, 45.26% done, 0 days 01:07:10 to go
OK: The last scrub on zpool 'zfsdata' was performed on 2019-08-03.10:21:02. | warning=2678400 critical=5356800 zfsdata_last_ago=3333 zfsdata_progress=100 zfsdata_speed=133 9 zfsdata_time=

The output of zpool status is:
  pool: zfsdata
 state: ONLINE
  scan: scrub in progress since Sat Aug  3 10:21:02 2019
        461G scanned at 120M/s, 258G issued at 67.2M/s, 496G total
        0B repaired, 52.05% done, 0 days 01:00:21 to go
config:

        NAME                                       STATE     READ WRITE CKSUM
        zfsdata                                    ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-SanDisk_SDSSD            ONLINE       0     0     0  (trimming)
            ata-SanDisk_SDSSD            ONLINE       0     0     0  (trimming)

errors: No known data errors

It looks like that there is a new field "days" which confuses the monitoring.

Thank you for reporting. Would you be so kind an test  eaae2f8

This issue is not solved I think, I'm getting the same error. It's probably not the progress functions that fail, but the time functions, in particular this regex:
https://github.com/Josef-Friedrich/check_zpool_scrub/blob/60a260efab2eab80915cf9177754da2b19c81704/check_zpool_scrub#L487

@taam Thank you for your report. Could you please specify the output of zpool status that causes your described problem.

Sure, but it's very similar to the one above:
  pool: xxx
 state: ONLINE
  scan: scrub in progress since Thu May 20 00:18:06 2021
        287G scanned at 962M/s, 31,3G issued at 105M/s, 2,70T total
        0B repaired, 1,13% done, 0 days 07:25:04 to go
config:

        NAME                                          STATE     READ WRITE CKSUM
        xxx                                           ONLINE       0     0     0
          mirror-0                                    ONLINE       0     0     0
            ata-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  ONLINE       0     0     0
            ata-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  ONLINE       0     0     0

errors: No known data errors

@taam could you please test 6e23e5ca54384cff75fcc0133081735f914e5208. Hopefully the problem is solved now.

Work for me (but comment regarding indentation applies: https://github.com/Josef-Friedrich/check_zpool_scrub/issues/12#issuecomment-850795202).
However, seems OpenZFS 2.0 changes the output again (with https://github.com/openzfs/zfs/commit/9a49d3f3d3bfa26df4e5e54d574cb490f0ee284b), the current string can be without "x days" as mentioned, see:
https://github.com/openzfs/zfs/blob/a1ca39655ba446c98a2f44b2b1d45d1059738885/cmd/zpool/zpool_main.c#L7400-L7408


add claim implementation

I have had to use some tricks to avoid stack too deep.
Notably, block scoping and the use of a new struct ClaimArgs to reduce the number of variables on the stack.

I am sure there are plans for this, but I didn't see any testing for the claim implementation.

Yep #3709


MLT: Confirm MLT is working with set_transaction_tracer

The existing method_level_telemetry branch is thought to be delivering MLT metrics for all manual calls to set_transaction_tracer. This should be confirmed and unit tests that verify this should be added.

Done


Heightcoding: please forward complaint to management

               LOGONCE(warn3) << "2D polygon heightcoding not implemented. "
                    "You may complain to the management.";

Either that or I will try to implement this soon :)  Also for exact lines matching on terrain it will probably be necessary to insert vertices at the intersection with surface mesh edges.

Wait, heighcoding is related to vector data, not raster data.

yes I'm aware of that - my goal is to have OSM vector features tightly mapped onto the terrain

I've implemented this previously with cgal on a custom tile-builder backend, but unfortunately lost the code due to a company shutdown

OK, however we never implemented polygon, didn't need it. I'm affraid there are no resource at our side to implement it now.
(FYI, the "you may complain ti the management" is a inner joke -- our manager implemented the heightcoding functionality and skipped stuff not needed at that time.)

yea ok - I see :) please close this issue

OK, closing as requested.


heartbeat?

we havent see anything being done for the last 10 months....

A new version is planned to be released very soon.

I can't give you an exact date. There are still some minor bugs left that need fixing. The release will happen once they are fixed.

can tease some expected changes?

We have been testing since March the new release (or was it February?). We changed a ton of code based on all the projects that are using this now. We still waiting for one unit test to finish ... it will cover a cross-platform software rasterizer.
If you had asked me during the time since February when we are going to release my response would have been ... probably in the next 2 - 4 weeks ... so this is also my response today.
Generally, we work on currently 10 customer projects with The Forge. The good thing is we can integrate a lot of changes learned from that experience. The bad thing is, that our customer projects have priority. This is why the release cycle gets a bit longer ... also the big amount of changes needs more manual testing. Our hardware testing of all platforms is not enough.

@wolfgangfengel The good thing is we can integrate a lot of changes learned from that experience. The bad thing is, that our customer projects have priority.
Here's something to really (re?)consider: if you push out WIP stuff early in the repo (or much more often), no matter how patchy or flaky, you'll get plenty more problems-surfaced that "10 customer projects" might just not-yet show, plus perhaps even fixes/patches/PRs for them...

It's been a long time

Last commit 26 months ago indeed! I mean let's not even talk about "releases" here, but in this space (foss, linuxable 3D realtime) plenty devs are happy to get their hands dirty (and at times even your fixes prepped) from the raw codebase..

Fixed with the latest release. We plan to release more frequently from here on


subscribe to both the Market and the Order messages on the same stream

hello,
Can you please double check , I keep getting a confusing error about unique_id when I add both markets and orders to the same stream .
WARNING:betfairlightweight.streaming.listener:Unwanted data received from uniqueId: 1, expecting: 3
Any help would be much appreciated .

betfairlightweight doesn't handle having both market and order streams through the same socket.

Thank you very much for your answer.
I had to run two different streams on two different threads indeed but on the same socket (APICLIENT class)
Thanks

No problem, join the slack group for instant replies
https://betfairlightweight.herokuapp.com/


StyleSheet not supported in native-base 2.0.5

<Icon name="person" style={{fontSize: 30}} />

works as expected.
<Icon name="person" style={styles.icon} />
...
const styles = StyleSheet.create({
  icon: {
    fontSize: 30
  }
});

doesn't work and returns the following warning:
Invalid prop 'style' of type `number` supplied to `Styled(Icon)`, expected `object`.

From docs:
If you have overwritten the styles of NativeBase components in your project using StyleSheet.create(), modify them to plain JavaScript objects. StyleSheet.create() is redundant as it's been called in the source of NativeBase components itself.
http://nativebase.io/docs/v2.0.0/migration

Thanks for your feedback.
The replacement of StyleSheet.create() to plain JavaScript objects works but we loose intellisense support.


Using ABCs from 'collections' will stop working in Python 3.8

We get the following deprecation warning on Python 3:
/Users/maiera/virtualenvs/pywbem37/lib/python3.7/site-packages/testfixtures/comparison.py:1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
    from collections import Iterable

The fix should be to change the quoted line to:
    from collections.abc import Iterable

I just checked the testfixtures version we are using, and it was 5.4.0. This issue was already fixed in 6.7.1. Closing this issue.


Question: Warnings about not having a strong name

RepoDB 1.12.7
RepoDB.SqlServer 1.1.3
...added using Nuget Package Manager in Visual Studio 2019 16.9.4.
<ItemGroup>
    <PackageReference Include="RepoDb" Version="1.12.7" />
    <PackageReference Include="RepoDb.SqlServer" Version="1.1.3" />
 </ItemGroup>

I use a strong name for my project (web api), and so I get warnings in the Error List window about your assemblies not having a strong name. It's not a problem, but wanted to let you know.

Thanks for this information.


fix: TUI shows developer name as author of agama-pw project

Author should be Gluufederation as shown on the Agama Lab, explore section listing.

Please check with latest release v1.0.2 .

Yes, this is fixed. Can you please link the relevant PR and close this issue?

@ossdhaval, no PR, Just login to GluuFederation/agama-pw and make a new release from agama lab. I'm closing this issue.


extra javac opts should override default ones

Description

Fixes https://github.com/bazelbuild/rules_scala/issues/1550
Currently the default javac flags will be appended last, overriding the manual ones.

Motivation

@thomasbao12 could you add a test to prevent regressions?

@liucijus I added a test and verified it fails on master https://github.com/bazelbuild/rules_scala/pull/1615.
I tried to follow the pattern established in other javac tests.
One issue though is I assume the default java toolchain sets a -target flag.
3 potential options:
0. merge as is

I could rename the test to clarify that I actually am only testing that I want to be able to override the java target version.  This is actually the behavior I want to fix.
I could try a more elaborate unit-test that verifies that two javac flags exist, one from the default toolchain and one from javacopts and that the javacopt one is ordered after the default toolchain.

I'm okay with 0 & 1.  I worry 2 is not worth doing and overly specific.

3 potential options:
0. merge as is

1. I could rename the test to clarify that I actually am only testing that I want to be able to override the java target version.  This is actually the behavior I want to fix.

2. I could try a more elaborate unit-test that verifies that two javac flags exist, one from the default toolchain and one from javacopts and that the javacopt one is ordered after the default toolchain.

@thomasbao12 if I haven't missed anything, option 0 seems the best to me - it communicates  your need plus the name implies generic expectation

@liucijus Can you merge?


What is your username and discriminator?
Metal Fan#1786
Why did you join Discord Linux?
I'm new to UNIX/Linux.
Where did you hear about Discord Linux?
Search engine
What is the passphrase that was assigned to you by the bot?
amorosapew.md

From simonizor#0420 :
That is not your passphrase. Please read the contents of the link to find your passphrase.


OS#17172584: Add handling of more OOM scenarios in ICU

Also throws in some of the fix for OS#17175014

[cc @Microsoft/target-dev ]


Update dependencies

Follow up to https://github.com/cfpb/design-system/pull/471 but updates mostly dependencies in root folder to align with /docs/ folder.
Testing

Pull branch, run yarn, and yarn start. It should work.

@contolini I'm going to merge this as there're a lot of moving parts and this should be up-to-date with the earlier update deps PR. I'll fix it if it breaks something.


Fixing the alignment of the landing page

Hello Sir,
I found that the landing page is not centered whenever the user lands on it.
Please assign me this issue to work on under GSSOC 2024.

@mdrehan369 This has been already addressed in issue number #6 . Try contributing in some other issues and if you find some other issues, raise them and get assigned.

@mdrehan369 Can you please assign this issue to me..?

Hey @ashutoshgithubs can you please assign this issue to me I would like to work on it.

Hey everyone, thanks for exploring the project. But this issue has addressed already in #6 . Please find some features enhancement/bugs/issue and raise them in issue section.


Allow including icon and license within package

Original Spec
Icons:

Icon_dialog.png (32x32)
Icon_list.png (50x50)
Icon_details.png (100x100)

License:
License.txt
Related Issue: Automatically resize images

I think we should consider this for the Hershey release.

@anglicangeek did you ever start this? I was thinking of doing this. :)

I started working on the icons, not the licenses. I have the icon image file storage plumbing mostly done and uploading a single image icon that gets used in all the places; let me wrap that up and commit it and you can take it from there (adding different sizes and also embedding license).

Sweet!

We have a new gallery design and infrastructure that addresses this.


Debug node counter

I've added a debug node counter; it demonstrates a memory leak of the nodes.
I'll investigate the leak and absolve it when found.

Very odd; testing the last commit with 10_000 continuations on my MacBook Pro 2016 gives the same memory leak I was having originally as opposed to when I was testing on my Ryzen 5 Windows 10 which was giving leaks in the range of 2+/-2

Fixed the leak; tested on Windows and Mac Os.
Documentation and styling to follow. Pull can be completed whenever though since this is a pretty big bug.


Exposed RenewLock so you can choose the renew and extend the peek loc…

…k on the message that's on the queue

Lager ny PR


Comparing masses with approx

This seems not to work properly yet:
julia> filter(p->p.mass ≈ Particle(2212).mass, particles())  # using \approx
ERROR: MethodError: no method matching isapprox(::Corpuscles.MeasuredValue{𝐋^2 𝐌 𝐓^-2}, ::Corpuscles.MeasuredValue{𝐋^2 𝐌 𝐓^-2})
Closest candidates are:
  isapprox(::Missing, ::Any; kwargs...) at missing.jl:90
  isapprox(::Unitful.Quantity, ::Corpuscles.MeasuredValue) at /home/tgal/Dev/Corpuscles.jl/src/Corpuscles.jl:74
  isapprox(::Corpuscles.MeasuredValue, ::Unitful.Quantity) at /home/tgal/Dev/Corpuscles.jl/src/Corpuscles.jl:78
  ...
Stacktrace:
 [1] (::var"#55#56")(::Particle) at ./REPL[64]:1
 [2] filter(::var"#55#56", ::Array{Particle,1}) at ./array.jl:2347
 [3] top-level scope at REPL[64]:1

I already stumbled upon that, but I did not implement it so far, because I was not sure about the right behaviour when comparing two MeasuredValue types. When I look at it now, I think  isapprox` should yield true, if both ranges overlap?!

I think this is reasonable. At least, this is what I would use it for 😉 If one really wants to do some floating point approximation comparisons, the .value field can be used anyways...


Update pagination to compute current page based off total_count

Also fixes pagination for a few Access Resources
Description
In terraform, if you try to use the Access Application Resource in a datasource it will fail to find the app because the List function will only check the first page.
Has your change been tested?
Unit tests and a local reproduction of the original issue that is now resolved.
Types of changes
What sort of change does your code introduce/modify?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] This change is using publicly documented in cloudflare/api-schemas
and relies on stable APIs.

@jacobbednarz tbh I'm a little hesitant on the new commit about changing total_count in all the tests. That was why the tests were failing.
I think its the correct fix, since count should always equal total_count if there are less than 1 page worth of results. Since most tests only have 1 item this should make the tests match real behavior. I couldn't decide if should try to handle that differently though in pagination.go?

iirc, the test data came from the old API docs which didn't have real validation so it may have been incorrect the entire time. I think fixing the tests here is the right move if we've uncovered issues.

it's worth noting, we also don't have thorough impossible logic checks for pagination which we could firm that up but I suspect there are some services that have a misunderstanding of all the result info fields so it may be better to fix to be more clear instead.
(the second part is already something we are speaking about internally too)

Codecov Report

Merging #1372 (5b8eed4) into master (b9ac804) will increase coverage by 0.00%.
Report is 191 commits behind head on master.
The diff coverage is 49.62%.

@@           Coverage Diff            @@
##           master    #1372    +/-   ##
========================================
  Coverage   48.33%   48.34%
========================================
  Files         133      139     +6
  Lines       13023    13749   +726
========================================
+ Hits         6295     6647   +352
- Misses       5201     5453   +252
- Partials     1527     1649   +122

Files Changed
Coverage Δ

access_audit_log.go
79.31% <ø> (ø)

access_bookmark.go
72.44% <ø> (ø)

access_keys.go
71.42% <ø> (ø)

access_organization.go
53.84% <ø> (ø)

access_service_tokens.go
51.85% <ø> (ø)

account_members.go
65.54% <ø> (ø)

account_roles.go
53.84% <ø> (ø)

accounts.go
50.81% <ø> (ø)

addressing_address_map.go
39.04% <ø> (ø)

addressing_ip_prefix.go
45.45% <ø> (ø)

... and 121 more

... and 1 file with indirect coverage changes

thanks for this!


[Task]: Git Repo Page UI Inconsistencies

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
If a user reaches 3 repo limit on Git, then we show them a the modal to either upgrade or delete an existing repo. The UI for this is not the same as the design.

This is the expected UI

Is there an API that returns for a given app the number of users that the app has been shared with?
Also, if we can figure out the number of users that an app is shared with in backend, BE can just return that number in response for limited git repo api.

@AnaghHegde ^


PMin not in models

1547-2018 specifies PMin as the minimum active power output of the DER. It's used in active power-reactive power, voltage-active power, and freq-droop. I cannot find it in the DER models.
According to Greg Kern, our power architect, there are multiple use cases where setting Pmin to -1.0 or 0.0 or some other number are needed. The requested range is -1.00 pu to 1.00 pu.
From Greg:

Most PV inverters will likely hardcode the number internally.  For stacking I might want to be able to set Pmin to -1.0, our default will be 0.0.  People who build microgrids would want to be able to program Pmin to -1.0 to help stabilize micro grid frequency.  How they do that is through the communication interface.

PMin is not specified as an adjustable setting in 1547-2018 and I am not sure it addresses PMin < 0 in the 1547 spec. Is there a specification that describes what is means for PMin < 0? When PMin < 0, is that addressing the charging capabilities and does PMin = -1.0 reflect the maximum charge rating? I am not opposed to supporting it, but would like to be able to understand and describe what it means.

SunSpec must support not only the minimum requirements of 1547-2018 but also the ability for equipment to use SunSpec to pass certification testing specified in 1547.1-2020.
section <IP_ADDRESS> step r) of 1547.1-2020 reads as follows
"For EUTs that can absorb power, rerun Characteristic 1 allowing the unit to absorb power by
programming a negative Pmin."
If SunSpec refuses to support programming a negative Pmin, then SunSpec is not a viable communication means for ESS.

No, this is for Freq-Droop, in the case when grid frequency goes high, DERs with the ability to absorb power can and in some cases will be configured to pull power in from the grid to the DER to help pull grid frequency back down.  More typically, an inverter with a battery (a type of ESS) connected to a micro grid where the micro grid controllers want to help stabilize the microgrid by configuring the ESS for full charge or discharge on FreqDroop.  but in order to make this happen we have to be able to communicate the Pmin parameter.

Would 702:WDisChaRteMaxRtg work to change Pmin from 0 to -1 pu?
I would think this would provide the necessary behavior to evaluate the 1547.1-2020 Freq-Droop for battery-based DER, as this sets a negative Pmin since this point is defined as the "Maximum active power discharge rate in watts."

702:WChaRteMax is an independent setting that would need to be set to allow the unit to charge while freq-drooping, but there still needs to be an independant Pmin setting within the freq-droop function.  Not all utilities require absorption of power during freq-droop.  Some would argue that encroaches on Load Dispatch.  CA Rule 21 curves on freq droop go down to zero then stop, and do not go negative, implying a Pmin default setting of 0 for ESS.  What harm is there in providing an optional Pmin setting under freq-droop for those of us who have ESS and need to be able to execute the 1547.1-2020 test procedure?
1547-2018 eratta defines Pmin as follows
pmin   is the minimum active power output due to DER prime mover constraints, in p.u. of the DER active power
rating in kW
and 1547.1-2020 CLEARLY indicates Pmin is a programmed parameter.
r) For EUTs that can absorb power, rerun Characteristic 1 allowing the unit to absorb power by
programming a negative Pmin.

ps. setting Pmin to zero for freq-droop is also needed in CA to be able to comply with Tariffs that only allow batteries to be charged from solar and NOT the grid in order to qualify for net metering.

I see your point Greg. This would create a Freq-Droop cut off line at the bottom of the curve, and it's defined as a parameter in IEEE 1547-2018. I agree that it should be adjustable based on the IEEE 1547.1 test procedure. Play around with the curve in the attached sheet if you like.
Freq-droop.xlsx

At this point, we are just trying to specify what PMin is and how to use it. Ideally that would all be in 1547 but it seems incomplete for a full understanding. The errata definition seems to be oriented to generation. It indicates that PMin is expressed as output and in terms of the DER active power rating. It seems like many systems may have a different limit for absorbing active power and generation. For example, if the generation rating is 10KW and the charge rating is 5KW, what value does -1.0 represent, -5KW or -10KW? And does this matter?

yes, Pmin is positive for active power output (or generation or injection) and negative for active power consumption (charging or absorption).
Yes, some systems will have limits on how much active power absorption (charging) they can do, but this doesn't change the basis.
Use the same basis for generation and charging.   In your example, -1.0 Pmin would represent -10kW, however the unit would never operate at that point and would be limited by other limits to -5kW.  and if the battery is full, charging would be limited even further.
imagine how confusing programming would be if we decided that positive numbers basis should be  two's complement but negative numbers basis should be ten's complement.  it is an apt analogy.
Pmin is clearly a per unit parameter since the freq-droop equation is in per unit.
I would argue that in the absence of clear guidance, only one basis should be used, positive active power rating.  The standard does not state or even imply that we should use two separate basses.
I would strongly argue against trying to define a positive and negative basis (dont overcomplicate this) for such a per unit parameter, because that would effectively change the slope of the response, an unintended consequence, and possible impact on system stability.  The basis for Pmin should be exactly what is written in 1547-2018, the 'p. u. of the active power rating'.
Here is another place where 1547-2018 DOES NOT define a separate positive and negative basis, Reactive Power.  Table 7 of 1547-2018 defines the minimum reactive power injection and absorption capabilities of Cat A and B DERs, in that case the basis is Apparent Power Rating, Cat A injection capability is 0.44 pu (44%) and for absorption 0.25 pu (25%).  We DID NOT try to define a different basis for positive and negative reactive powers.  If anything, in the future, to eliminate this question, 1547-2018 should set the basis for all power ratings (apparent, active and reactive) as rated Apparent Power.  now of course there is no such thing as a negative apparent power rating.

FYI
be aware that Pmin does not have the same meaning throughout IEEE 1547.1-2020.  It's meaning may vary from test to test.
for example, in section 5.14.2 states
Pmin – minimum active power (W)
P’min – for EUTs that can sink power, minimum active power while sinking power (W)

and in some of those cases Pmin does not represent a communicated parameter but rather a power level as part of a test procedure.

The following changes were proposed to multiple manufacturers and stakeholders today in the weekly FIGII meeting and there were no objections:
PMin be added to SunSpec Modbus model 711 (Freq-Droop) for each set of settings.
PMin is a signed 16-bit value representing a percentage from -100 to 100. The label is Minimum Active Power. The description is: The minimum active power output due to DER prime mover constraints, in percent of the DER active power rating. The valid range is -100 to 100. Support of PMin is optional and not required for 1547-2018 conformance.
We will review at the next Modbus workgroup meeting and proceed if there are no issues.


Avoid processing VT Render Trace strings when no one is listening

Summary of the Pull Request

If no one is listening to the ETW provider for the VT Renderer for diagnostic purposes, do not spend time allocating/deleting/formatting strings for presentation in TraceLogging messages.

PR Checklist

[x] Closes something I noticed while working on the renderer.
[x] I work here.
[x] Existing tests should pass
[x] No doc
[x] Am core contributor.

Validation Steps Performed
WPR/WPA
Before: 321/3016 samples on hot path (10.64%)

After: 0/1266 samples on the same path (0%)

@msftbot merge this in 1 minute


Echonet Lite disconnecting sporadically until restart

Good morning
I have been having this issue with my Mistsubishi Electric MSZ AP25/70 Aircon units since March and have tried numerous things to solve the problem.
After restarting home assistant, the aircons connect successfully and will maintain a connection anywhere from a few hours to several days before they become unavailable in home assistant and will not reconnect until the home assistant system is restarted. They still remain connected through the Mitsubishi App as well as through Google Home. They were running without issue for about 18 months before this issue began. I had not updated or changed anything on my homeassistant OS in about 6 months. Since then, I have updated to the latest version of echonet as well as updated the homeassistant core and homeassistant OS.
I have ensured that my router keeps these aircons on a static IP so that should not be the issue. I have enabled the debug log and posted the results below. You can see it is working normally before it seemingly begins timing out and will not reconnect. I'm not sure if this is an issue with the integration or my own personal setup. I have tried deleting and re-adding the devices since updating to the latest version of echonet. Any help would be greatly appreciated as I love the integration and use it everyday.
Please let me know if you need any more info. The debug log was 40mb as I enabled it immediately after restarting and it took three days before the latest disconnection issue so have included just the snippet below.
Cheers
Nick
2024-04-30 11:54:42.140 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.office_aircon is taking over 10 seconds
2024-04-30 11:54:42.151 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.kitchen_aircon is taking over 10 seconds
2024-04-30 11:54:42.151 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.rumpus_aircon is taking over 10 seconds
2024-04-30 11:54:42.179 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.bedroom_aircon is taking over 10 seconds
2024-04-30 11:55:02.494 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status 0x80(128): off
 - Air flow rate setting 0xa0(160): auto
 - Automatic control of air flow direction setting 0xa1(161): non-auto
 - Automatic swing of air flow setting 0xa3(163): not-used
 - Air flow direction (vertical) setting 0xa4(164): upper
 - Air flow direction (horizontal) setting 0xa5(165): right
 - Operation mode setting 0xb0(176): cool
 - Set temperature value 0xb3(179): 23
 - Measured value of room temperature 0xbb(187): 26
 - Measured outdoor air temperature 0xbe(190): 126

2024-04-30 11:55:02.495 DEBUG (MainThread) [custom_components.echonetlite.climate] Called async_update_callback on Office Aircon.
Changed: True
Update data: {128: 'off', 160: 'auto', 161: 'non-auto', 163: 'not-used', 164: 'upper', 165: 'right', 176: 'cool', 179: 23, 187: 26, 190: 126}
Old data: {128: 'off', 160: 'auto', 161: 'non-auto', 163: 'not-used', 164: 'upper', 165: 'right', 176: 'cool', 179: 23, 187: 26, 190: 126}
2024-04-30 11:55:02.505 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status 0x80(128): off
 - Air flow rate setting 0xa0(160): auto
 - Automatic control of air flow direction setting 0xa1(161): non-auto
 - Automatic swing of air flow setting 0xa3(163): not-used
 - Air flow direction (vertical) setting 0xa4(164): upper
 - Air flow direction (horizontal) setting 0xa5(165): left
 - Operation mode setting 0xb0(176): cool
 - Set temperature value 0xb3(179): 20
 - Measured value of room temperature 0xbb(187): 23
 - Measured outdoor air temperature 0xbe(190): 126

2024-04-30 11:55:02.506 DEBUG (MainThread) [custom_components.echonetlite.climate] Called async_update_callback on Kitchen Aircon.
Changed: True
Update data: {128: 'off', 160: 'auto', 161: 'non-auto', 163: 'not-used', 164: 'upper', 165: 'left', 176: 'cool', 179: 20, 187: 23, 190: 126}
Old data: {128: 'off', 160: 'auto', 161: 'non-auto', 163: 'not-used', 164: 'upper', 165: 'left', 176: 'cool', 179: 20, 187: 23, 190: 126}
2024-04-30 11:55:02.611 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status 0x80(128): off
 - Automatic control of air flow direction setting 0xa1(161): non-auto
 - Air flow rate setting 0xa0(160): auto
 - Automatic swing of air flow setting 0xa3(163): not-used
 - Air flow direction (vertical) setting 0xa4(164): upper
 - Air flow direction (horizontal) setting 0xa5(165): right
 - Measured cumulative power consumption 0x85(133): 913700
 - Operation mode setting 0xb0(176): cool
 - Set temperature value 0xb3(179): 21
 - Measured value of room temperature 0xbb(187): 25
 - Measured outdoor air temperature 0xbe(190): 126

2024-04-30 11:55:02.612 DEBUG (MainThread) [custom_components.echonetlite.climate] Called async_update_callback on Rumpus Aircon.
Changed: True
Update data: {128: 'off', 161: 'non-auto', 160: 'auto', 163: 'not-used', 164: 'upper', 165: 'right', 133: 913700, 176: 'cool', 179: 21, 187: 25, 190: 126}
Old data: {128: 'off', 161: 'non-auto', 160: 'auto', 163: 'not-used', 164: 'upper', 165: 'right', 133: 913700, 176: 'cool', 179: 21, 187: 25, 190: 126}
2024-04-30 11:55:02.638 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status 0x80(128): off
 - Automatic control of air flow direction setting 0xa1(161): non-auto
 - Air flow rate setting 0xa0(160): auto
 - Automatic swing of air flow setting 0xa3(163): not-used
 - Air flow direction (vertical) setting 0xa4(164): lower
 - Air flow direction (horizontal) setting 0xa5(165): right
 - Measured cumulative power consumption 0x85(133): 321000
 - Operation mode setting 0xb0(176): cool
 - Set temperature value 0xb3(179): 18
 - Measured value of room temperature 0xbb(187): 23
 - Measured outdoor air temperature 0xbe(190): 126

2024-04-30 11:55:02.639 DEBUG (MainThread) [custom_components.echonetlite.climate] Called async_update_callback on Bedroom Aircon.
Changed: True
Update data: {128: 'off', 161: 'non-auto', 160: 'auto', 163: 'not-used', 164: 'lower', 165: 'right', 133: 321000, 176: 'cool', 179: 18, 187: 23, 190: 126}
Old data: {128: 'off', 161: 'non-auto', 160: 'auto', 163: 'not-used', 164: 'lower', 165: 'right', 133: 321000, 176: 'cool', 179: 18, 187: 23, 190: 126}
2024-04-30 11:55:12.796 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.office_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:55:12.800 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.kitchen_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:55:12.849 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.rumpus_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:55:12.867 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.bedroom_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:55:32.796 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 11:55:32.798 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 11:55:32.850 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 11:55:32.867 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 11:55:42.142 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.office_aircon is taking over 10 seconds
2024-04-30 11:55:42.154 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.kitchen_aircon is taking over 10 seconds
2024-04-30 11:55:42.154 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.rumpus_aircon is taking over 10 seconds
2024-04-30 11:55:42.182 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.bedroom_aircon is taking over 10 seconds`
2024-04-30 11:56:12.797 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.office_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:56:12.800 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.kitchen_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:56:12.857 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.rumpus_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 11:56:12.868 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.bedroom_aircon_automatic_control_of_air_flow_direction_setting is taking over 10 seconds

I'm getting a similar issue. I've been trying to isolate the issue and found this issue. All of my heat pumps have the same issue, like the orig poster, the Mitsubishi app still works fine.
2024-04-30 02:14:28.705 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.may_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:14:28.706 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.sw2_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:14:28.889 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.main_bedroom_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:14:48.705 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:14:48.706 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:14:48.889 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:14:58.706 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.may_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:14:58.890 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.sw2_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:14:58.891 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.main_bedroom_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:15:18.706 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:18.890 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:18.891 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.may_heatpump is taking over 10 seconds
2024-04-30 02:15:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.sw2_heatpump is taking over 10 seconds
2024-04-30 02:15:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.main_bedroom_heatpump is taking over 10 seconds
2024-04-30 02:15:28.706 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.may_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:15:28.707 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.sw2_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:15:28.890 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.main_bedroom_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:15:48.706 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:48.707 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:48.890 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:15:58.708 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.may_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:15:58.890 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.sw2_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:15:58.892 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.main_bedroom_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:16:18.707 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:18.891 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:18.893 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.may_heatpump is taking over 10 seconds
2024-04-30 02:16:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.sw2_heatpump is taking over 10 seconds
2024-04-30 02:16:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.main_bedroom_heatpump is taking over 10 seconds
2024-04-30 02:16:28.707 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.may_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:16:28.709 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.sw2_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:16:28.892 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.main_bedroom_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:16:48.707 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:48.708 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:48.892 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:16:58.708 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.may_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:16:58.892 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.sw2_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:16:58.894 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.main_bedroom_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:17:18.709 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:18.892 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:18.894 WARNING (MainThread) [homeassistant.components.select] Updating echonetlite select took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.may_heatpump is taking over 10 seconds
2024-04-30 02:17:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.sw2_heatpump is taking over 10 seconds
2024-04-30 02:17:23.016 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.main_bedroom_heatpump is taking over 10 seconds
2024-04-30 02:17:28.709 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.may_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:17:28.709 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.sw2_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:17:28.893 WARNING (MainThread) [homeassistant.helpers.entity] Update of sensor.main_bedroom_heatpump_measured_cumulative_power_consumption is taking over 10 seconds
2024-04-30 02:17:48.709 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:48.710 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:48.894 WARNING (MainThread) [homeassistant.components.sensor] Updating echonetlite sensor took longer than the scheduled update interval 0:00:30
2024-04-30 02:17:58.710 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.may_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:17:58.894 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.sw2_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds
2024-04-30 02:17:58.895 WARNING (MainThread) [homeassistant.helpers.entity] Update of select.main_bedroom_heatpump_automatic_control_of_air_flow_direction_setting is taking over 10 seconds

This integration may be the cause, but we were unable to determine the problem from the log file.
Please try the following measures to rule out any influence from the network environment.

Restart the LAN hub
Restart the network router
Power cycle the air conditioner

Continue to observe after taking the above measures.

I've had to rollback as I can't have my home as a test environment overnight sorry. I can say that I'm a network engineer and it wasn't a network issue cause such significant delays observed over days. I also have 3 Mistsubishi heatpumps (2 x AP25 and 1 AP35) and they all had the issue at the same time, so I think that eliminates the heat pump being the issue.
I notice the orig poster has the same model heatpumps.
I'll try and roll forward during the day but not sure if it will be long enough to trigger it.
Are there some manual debug commands I can run to figure out what is causing the issue when it happens?

@16thompn So if I understand this correctly - this issue started in March, but at the time you had not performed any sort of update of either home assistant or this component, having not updated in 6 months? Has anything else in your environment possibly changed?
Do you add the devices manually using their IP address, or do you use the auto discover function (which relies heavily on multicast?) Perhaps try enabling the force polling option too to see if that helps?

I would be adding the devices manually using their IP address rather then auto discover if that is what is being used at this point. It could possibly be some issue with IGMP snooping killing off multicast queries after a certain period of time? I have had no end of dramas with IGMP snooping for similar integrations which rely on multicast?

@jacobw as you are a network engineer,  fire up Wireshark on a spare laptop and monitor the traffic over a period of time to see if you can identify what is going on?

Does the autodiscover process not just get the ip and save it?

@16thompn So if I understand this correctly - this issue started in March, but at the time you had not performed any sort of update of either home assistant or this component, having not updated in 6 months? Has anything else in your environment possibly changed?
Do you add the devices manually using their IP address, or do you use the auto discover function (which relies heavily on multicast?) Perhaps try enabling the force polling option too to see if that helps?

Apologies for the delay in getting back!
That's correct. The HomeAssistant version had not been touched for over 6 months (including not updating) and I also had not installed any new software or integrations or even added any new devices. Everything was working so didn't touch it! We have not changed routers or anything to do with the internet set up.
I manually locked the IP address of my HVAC systems in my router settings and then manually added the IP addresses to the EchoNet integration. This worked rather flawlessly for about 18 months.
Since this I have tried restarting the router and lan hub, HA, power cycles the aircons and readd them again. It works for several days but still disconnects shortly after.
I have actually added a restart HA button to my interface as a temporary measure and this works a treat as they will always be reconnected when the system reboots

Let me know if I can provide any more information or if there are any other debugging logs that I could access to shed more light on the issue.
Cheers
Nick

@16thompn To be frank it is difficult for me to attribute your issues to any fault in the custom component. As you said - you hadn't updated anything, it worked flawlessly for 6 months and then you started encountering issues. Your issue cannot have been caused by some issue with the custom component since it was working for 6 months. 6 months of issue free performance is hardly indicative of any undetected defect in the code. If you had said you updated to version X of either Home assistant and/or the custom component, and then the issues started there would be a clear causality and we could look at what changed in the code or not.  But in your case we cannot.  How exactly are you running Home Assistant? Unfortunately I do not have the time available to work on this.

I am running HA on a Raspberry Pi 4. The integration has now been working without issue for 72 hours since the last restart. I appreciate your feedback and if I continue to have it drop out I will try rolling back. It does make sense that something else might be going wrong given that it worked without issue for so long. I just can't work out what that might be given the lack of any changes to the system!  I will update if I find any more useful info.
My only thought is that if the request is timing out, is there a way to increase this? Can I do this manually anywhere?
Thanks again

I thought mine was dropping randomly too but turns out it wasn't random - it was the microwave! Interestingly all of my other 2.4ghz devices stay online and the Mitsubishi app shows it online but anything done in the app doesn't control the AC. I'm using a MAC-588IF, maybe they don't handle interference very well. I haven't tried changing 2.4ghz channel yet.

I thought mine was dropping randomly too but turns out it wasn't random - it was the microwave! Interestingly all of my other 2.4ghz devices stay online and the Mitsubishi app shows it online but anything done in the app doesn't control the AC. I'm using a MAC-588IF, maybe they don't handle interference very well. I haven't tried changing 2.4ghz channel yet.

Oh that's an interesting thought. We use our microwave very frequently so will have to do some testing to see if that's what is causing it. It could explain why it only began recently when we got a new microwave. Not sure if they are correlated as I can't remember exact dates. I'm away for a couple of weeks now but will see when I get back if this causes the issue! Thanks for your input :)

FYI - I've switched from channel 11 to channel 1 on my 2.4ghz network and so far so good for me.

Thanks so much for the info again. I am home next week so will switch everything over and report back. Hopefully this is the issue 😊

Hi,
I have the same problem with it dropping out and a HA restart fixing the problem and then it seems to last a few days to a week. I can still use the mitsubishi app so the actual physical device is still connected and working. I'll try changing the channel too and see what happens

Hi,
I have the same problem with it dropping out and a HA restart fixing the problem and then it seems to last a few days to a week. I can still use the mitsubishi app so the actual physical device is still connected and working. I'll try changing the channel too and see what happens

I went to go change the channel on my router but am using a Deco mesh wifi and they don't let you adjust your routers channel number. I have noted as well that it does not disconnect from the Mitsubishi wifi app despite being disconnected from HA.

When an issue occurs, does an integrated device reload resolve the issue rather than an HA restart?
If a device reload resolves it, you can use automation to fix it.

I tried to do a device reload but it doesn’t connect. I can ping the device
so the IP hasn’t changed and the Mitsubishi app still works.
It seems like the full HA restart is required. Is there something more
hardcore than a device reload but less hardcore than a HA restart?
On Sun, 15 Sep 2024 at 18:30, Naoki Sawada @.***> wrote:

When an issue occurs, does an integrated device reload resolve the issue
rather than an HA restart?
If a device reload resolves it, you can use automation to fix it.
—
Reply to this email directly, view it on GitHub
https://github.com/scottyphillips/echonetlite_homeassistant/issues/181#issuecomment-2351463386,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHJQ7EF5MV2ES2V4GMMGWB3ZWVASPAVCNFSM6AAAAABHBDHHEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGQ3DGMZYGY
.
You are receiving this because you commented.Message ID:
@.***
com>

It is likely that the pychonet UDP server is experiencing some communication problems, but I have not experienced any problems in either my production or test environments, so I am still unable to speculate on what to do about it.

I've been seeing this recently as well.
I have changed a fair bit on my end so I'm debugging bits as I go along and I am currently looking at pychonet to track down the behavior in pychonet currently so will open up an issue there to see if we can get to the bottom of it
https://github.com/scottyphillips/pychonet/issues/75

Thanks so much for checking this out Josh.
This same problem has been frustrating for months. I'm a JS dev but haven't touched python before and haven't looked at the insides of HA before and didn't really know how to start troubleshooting it

After debugging for a week or so to try get to the bottom of this, I think I found my issue though I'm not 100% certain of the cause yet.
Setup:
MSZ-AP20VGD - mitsi heat pump
MAC-568-IF-E - wifi interface to heat pump
Wifi provided by unifi access points
Pfsense as the router/firewall with VLANS for certain networks
My IOT devices live on a seperate VLAN, the home assistant server also is on another different VLAN
IOT VLAN - No internet access, 2.4ghz, custom settings
LAN_VLAN - Normal internet access, 2.4ghz/5gz, settings on auto in unifi management
MAC-568-IF-E - wifi interface lives on IOT_VLAN
Running tcpdump on the access point that the wifi interface was connected to I could see ocasionally the first packet leaving the Unifi access point though not getting a reply from the echonet device.
This would happen with ping in the same randomness
It would happen either from my desktop or server
I did a reset on the MAC-568-IF-E wifi interface and made it connect to LAN_VLAN so it had access to the internet and set it up again and that so far (12 hours) has not had any errors/warning from home assistant and it appears to be back to solidly reliable
I'm not sure what the exact cause is as the IOT wifi network does have some custom settings and is blocked from internet access compared to the LAN_VLAN network
At this stage it appears the network setup or the reset has solved the issue. I will give it a week and attempt to put it back on the IOT network and see what happens.

I tried to do a device reload but it doesn’t connect. I can ping the device so the IP hasn’t changed and the Mitsubishi app still works.

@IsaacInsoll do you happen to see any ocasional packet loss when pinging, mine was happening on the first ping and it would randomly be dropped

I've just done a ping from local machine and it seems like there is no dropouts at the moment.
It seems like everything is working at the moment. My HA container has been up for 36 days but I often restart from within HA when the AC drops (which presumably doesn't reset docker container uptime) out so I can't tell what my actual uptime is.
A few notes on my setup if it helps at all

Statically assigned IP (from PiHole) and the whole network is just one basic LAN/WIFI network (IE: no different vlans/subnets or anything)
MAC-568IF-E installed into my AC unit, and I don't have any other wifi or network connectivity issues I'm aware of even though I have heaps of devices on the network.

I'm super happy to do any other troubleshooting that can help either now (while it's working) or if you want to give me some testing procedures to isolate the issue next time it dies.
Thanks again!

Also another thing to try, this script will use the underlying library to poll you aircon machine for its on/off status
Might be an idea to get it working when home assistant is working and when home assistant breaks then try it and see if there is any output
Only tested on linux, windows was going on about not being able to create a non blocking socket I think
python -m venv venv
source venv/bin/activate
pip install pychonet

python aircon_test.py "<IP_ADDRESS>"

aircon_test.zip

I'm running this in Container Manager on synology and can't see a way to do a docker inspect. Here's the compose file which I presume answers the question?
version: "3"
services:
  homeassistant:
   container_name: homeassistant
   image: homeassistant/home-assistant:latest
   network_mode: "host"
   environment:
     WHEELS_LINKS: https://wheels.home-assistant.io/musllinux/
     TZ: 'Australia/Brisbane'
   volumes:
     - './homeassistant/config:/config'
   restart: unless-stopped

I'll test out that script on WSL2 tonight and see if I can get it working (while aircon is in running state so we have a baseline). I've got linux boxes at work but not at home

Sorry for the insane delay on responding to this.
I've noticed the dropouts have still been happening and as previously discussed a HA reboot fixes it for a few days.
I've noticed that if I turn on the AC with the physical remote I'll sometimes see the AC appear as online in HA for a minute (i can't interact with it, and it goes back online) but I thought that might be a useful hint.
I finally ran the task you provided and this is the output
░▒▓      ~/Downloads  python aircon_test.py "<IP_ADDRESS>"                                                                                 ✔  thebos    at 12:19:23   ▓▒░

2024-12-02 12:20:46.194012 Attempting discover of <IP_ADDRESS>
2024-12-02 12:21:16.251665 Finshed discover
Traceback (most recent call last):
  File "/home/isaac/Downloads/aircon_test.py", line 36, in <module>
    asyncio.run(main(sys.argv))
  File "/usr/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/isaac/Downloads/aircon_test.py", line 27, in main
    aircon = HomeAirConditioner(target, server)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/isaac/thebos/venv/lib/python3.12/site-packages/pychonet/HomeAirConditioner.py", line 287, in __init__
    EchonetInstance.__init__(
  File "/home/isaac/thebos/venv/lib/python3.12/site-packages/pychonet/EchonetInstance.py", line 56, in __init__
    self._epc_data = self._api._state[self._host]["instances"][self._eojgc][
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
KeyError: 1

I ran that from my work PC while VPN'd into the home network :)

The Air Con is currently in "unavailable" state for the last few days. I haven't done a HA restart yet to fix it, but here's something that might help with troubleshooting the issue:
Whenever we use the physical remote to change settings: HA picks it up immediately and the device is temporarily online for a minute before reverting to unavailable state.
As previously discussed: it's still controllable from the factory Mitsubishi app as well.
I'm not sure what else I can to do help test it but please let me know if there is something I can do.

Host mode so is directly on the nas network interface so udp will work

network_mode: "host"

Looking at the timing here that's 30 seconds and it fails to discover hence the error thrown below it

2024-12-02 12:26:40.000921 Attempting discover of <IP_ADDRESS>
2024-12-02 12:27:10.074914 Finshed discover

I'm leaning towards something wrong in your network, like what was causing my issue.
You might need to break out wireshark and monitor the traffic to see whats happening

Thanks for your help so far. I was running this in WSL2 on Windows 11 which can do some weird stuff with docker networking so I thought I'd run the same steps via SSH to my NAS  which is literally the machine running home assistant.
I'm a python noob and not sure how I've messed this up
Isaac@NAS:/volumeUSB1/usbshare$ cd test
Isaac@NAS:/volumeUSB1/usbshare/test$ python -m venv venv
Isaac@NAS:/volumeUSB1/usbshare/test$ source venv/bin/activate
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ pip install pychonet
WARNING: The directory<EMAIL_ADDRESS>or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Collecting pychonet
  Downloading pychonet-2.6.13-py3-none-any.whl (83 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 83.1/83.1 KB 2.8 MB/s eta 0:00:00
Collecting deprecated
  Downloading Deprecated-1.2.15-py2.py3-none-any.whl (9.9 kB)
Collecting wrapt<2,>=1.10
  Downloading wrapt-1.17.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (85 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 85.6/85.6 KB 69.2 MB/s eta 0:00:00
Installing collected packages: wrapt, deprecated, pychonet
Successfully installed deprecated-1.2.15 pychonet-2.6.13 wrapt-1.17.0
WARNING: You are using pip version 22.0.4; however, version 24.3.1 is available.
You should consider upgrading via the '/volumeUSB1/usbshare/test/venv/bin/python -m pip install --upgrade pip' command.
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ python aircon_test.py "<IP_ADDRESS>"
Traceback (most recent call last):
  File "aircon_test.py", line 5, in <module>
    from pychonet.lib.udpserver import UDPServer
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/__init__.py", line 1, in <module>
    from pychonet.echonetapiclient import ECHONETAPIClient  # noqa
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/echonetapiclient.py", line 25, in <module>
    from pychonet.lib.epc_functions import EPC_SUPER_FUNCTIONS
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/lib/epc_functions.py", line 89, in <module>
    def _call_int(data: bytes | list):
TypeError: unsupported operand type(s) for |: 'type' and 'type'

Thanks for your help so far. I was running this in WSL2 on Windows 11 which can do some weird stuff with docker networking so I thought I'd run the same steps via SSH to my NAS which is literally the machine running home assistant.
I'm a python noob and not sure how I've messed this up
Isaac@NAS:/volumeUSB1/usbshare$ cd test
Isaac@NAS:/volumeUSB1/usbshare/test$ python -m venv venv
Isaac@NAS:/volumeUSB1/usbshare/test$ source venv/bin/activate
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ pip install pychonet
WARNING: The directory<EMAIL_ADDRESS>or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Collecting pychonet
  Downloading pychonet-2.6.13-py3-none-any.whl (83 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 83.1/83.1 KB 2.8 MB/s eta 0:00:00
Collecting deprecated
  Downloading Deprecated-1.2.15-py2.py3-none-any.whl (9.9 kB)
Collecting wrapt<2,>=1.10
  Downloading wrapt-1.17.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (85 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 85.6/85.6 KB 69.2 MB/s eta 0:00:00
Installing collected packages: wrapt, deprecated, pychonet
Successfully installed deprecated-1.2.15 pychonet-2.6.13 wrapt-1.17.0
WARNING: You are using pip version 22.0.4; however, version 24.3.1 is available.
You should consider upgrading via the '/volumeUSB1/usbshare/test/venv/bin/python -m pip install --upgrade pip' command.
(venv) Isaac@NAS:/volumeUSB1/usbshare/test$ python aircon_test.py "<IP_ADDRESS>"
Traceback (most recent call last):
  File "aircon_test.py", line 5, in <module>
    from pychonet.lib.udpserver import UDPServer
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/__init__.py", line 1, in <module>
    from pychonet.echonetapiclient import ECHONETAPIClient  # noqa
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/echonetapiclient.py", line 25, in <module>
    from pychonet.lib.epc_functions import EPC_SUPER_FUNCTIONS
  File "/volumeUSB1/usbshare/test/venv/lib/python3.8/site-packages/pychonet/lib/epc_functions.py", line 89, in <module>
    def _call_int(data: bytes | list):
TypeError: unsupported operand type(s) for |: 'type' and 'type'

I wouldnt run it on WSL as I'm sure it will have the same issue as docker and udp packets not being able to be routed correctly
It's throwing errors as your python version on the nas does not support the union operator |. Needs to be above 3.10
You will want to test on a newer distro, download something easy like ubuntu or linux mint, in windows download the LTS iso and use rufus to burn it to a usb stick and run it live from usb on your pc/laptop

Thanks heaps, will test it out and get back to you :)


FR: Use OpenAI API to generate tryAgainMessages[]

It would add a lot more variety than having a random set of hard-coded local responses.

Supported by commit #27 - added one-off prompt support.


feat: init ApisixPluginConfig crd  (#638)

Please answer these questions before submitting a pull request

Why submit this pull request?

[ ] Bugfix

[x] New feature provided

[ ] Improve performance

[ ] Backport patches

Related issues
#638

Bugfix

Description

How to fix?

New feature or improvement

Describe the details and related test reports.

Backport patches

Why need to backport?

Source branch

Related commits and pull requests

Target branch

@tao12345666333
ci run failed due to clientset need ApisixPluginConfigList, but i had deleted it before.

@neverCase  you should re-run make codegen and push it.

@neverCase you should re-run make codegen and push it.
make codegen
git add pkg/*
git commit -m 're-run codegen'
git push

should i add ApisixPluginConfigList first.
There some errors in the pkg/kube/apisix/client/clientset/versioned/typed/config/v2beta1/apisixpluginconfig.go
// List takes label and field selectors, and returns the list of ApisixPluginConfigs that match those selectors.
func (c *apisixPluginConfigs) List(ctx context.Context, opts v1.ListOptions) (result *v2beta1.ApisixPluginConfigList, err error) {
	var timeout time.Duration
	if opts.TimeoutSeconds != nil {
		timeout = time.Duration(*opts.TimeoutSeconds) * time.Second
	}
	result = &v2beta1.ApisixPluginConfigList{}
	err = c.client.Get().
		Namespace(c.ns).
		Resource("apisixpluginconfigs").
		VersionedParams(&opts, scheme.ParameterCodec).
		Timeout(timeout).
		Do(ctx).
		Into(result)
	return
}

The structure ApisixPluginConfigList maybe be required.

@neverCase  yes. you should add it.

Codecov Report

Merging #689 (49be139) into master (3e9bdbf) will decrease coverage by 1.32%.
The diff coverage is 0.95%.

:exclamation: Current head 49be139 differs from pull request most recent head 475c742. Consider uploading reports for the commit 475c742 to get more accurate results

@@            Coverage Diff             @@
##           master     #689      +/-   ##
==========================================
- Coverage   35.37%   34.04%   -1.33%
==========================================
  Files          60       61       +1
  Lines        5967     6144     +177
==========================================
- Hits         2111     2092      -19
- Misses       3612     3801     +189
- Partials      244      251       +7

Impacted Files
Coverage Δ

pkg/ingress/compare.go
0.00% <0.00%> (ø)

pkg/ingress/controller.go
1.06% <0.00%> (-0.01%)
:arrow_down:

pkg/ingress/secret.go
0.00% <0.00%> (ø)

pkg/kube/translation/apisix_ssl.go
0.00% <0.00%> (ø)

pkg/kube/translation/translator.go
47.00% <ø> (ø)

pkg/ingress/pod.go
32.46% <100.00%> (+0.88%)
:arrow_up:

pkg/apisix/plugin.go
80.00% <0.00%> (-20.00%)
:arrow_down:

pkg/apisix/cluster.go
27.25% <0.00%> (-3.50%)
:arrow_down:

pkg/apisix/route.go
35.66% <0.00%> (-2.10%)
:arrow_down:

Continue to review full report at Codecov.

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

IMO this CRD is simple, we could use kubebuilder markers to generate schema.
This is a reference use case: https://github.com/apache/apisix-ingress-controller/blob/master/pkg/kube/apisix/apis/config/v1/types.go#L272-L328
After defining markers, run the following command in project root (assuming your are using linux) to regen the schema yaml:
controller-gen schemapatch:manifests=./samples/deploy/crd/v1beta1  output:dir=./samples/deploy/crd/v1beta1 paths=./pkg/kube/apisix/...

This command will raise some errors because not all CRD definitions works well with controller-gen. So you should rollback all changed files except fo ApisixPluginConfig one.

ApisixPluginConfig is a new resource.
According to the management method of the Kubernetes API1, we should start with the v1alpha1 version.
This means that you should create a pkg/kube/apisix/apis/config/v1alpha1 directory and move your current content to it.

The structure of ApisixPluginConfigSpec can be as follows, it only needs to include the following two fields. (you can add some comments)
type ApisixPluginConfigSpec struct {
	Desc   string                   `json:"desc,omitempty" yaml:"desc,omitempty"`
	Plugins []ApisixRouteHTTPPluginConfig `json:"plugins" yaml:"plugins"`
}

The structure of ApisixPluginConfigSpec can be as follows, it only needs to include the following two fields. (you can add some comments)
type ApisixPluginConfigSpec struct {
	Desc   string                   `json:"desc,omitempty" yaml:"desc,omitempty"`
	Plugins []ApisixRouteHTTPPluginConfig `json:"plugins" yaml:"plugins"`
}

but the ApisixRouteHTTPPluginConfig and ApisixStatus don't exist in the new created file pkg/kube/apisix/apis/config/v1alpha1/types.go,
so should i import them from the pkg/kube/apisix/apis/config/v2alpha1/types.go

@neverCase  yep, you should import them

like this:
https://github.com/apache/apisix-ingress-controller/blob/957c31522e1b1e5f8ef9cab7eb244473a4e0f675/pkg/kube/apisix/apis/config/v1/types.go#L23

i find some problem when generating zz_generated.deepcopy.go
cause the previous deepcopy files's head was:
// +build !ignore_autogenerated

// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
...

but when i generated on my mac, it would add an another line before:
//go:build !ignore_autogenerated
// +build !ignore_autogenerated

// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
....

i don't know the reason why the difference //go:build !ignore_autogenerated to occur.

you can push you change first (before run make codegen)

Submit complete changes and code to make it easier to let us know what happened.

We can use https://github.com/apache/apisix-ingress-controller/pull/694 instead, I will close this.


Demo doesn't work

I wanted to try your plugin with your demo inside the repository. But when I tried to tns run ios --emulator after installation of npm dependencies, I got an error like that:
objc[56909]: Class PLBuildVersion is implemented in both /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/AssetsLibraryServices.framework/AssetsLibraryServices (0x11a8e2cc0) and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/PhotoLibraryServices.framework/PhotoLibraryServices (0x11a6f96f0). One of the two will be used. Which one is undefined.
1   0x10274aa6b NativeScript::FFICallback<NativeScript::ObjCMethodCallback>::ffiClosureCallback(ffi_cif*, void*, void**, void*)
2   0x102eca90e ffi_closure_unix64_inner
3   0x102ecb2c2 ffi_closure_unix64
4   0x103c4245a -[UIViewController view]
5   0x103b0a98a -[UIWindow addRootViewControllerViewIfPossible]
6   0x103b0b070 -[UIWindow _setHidden:forced:]
7   0x103b1debe -[UIWindow makeKeyAndVisible]
8   0x102ecb11d ffi_call_unix64
9   0x11f637d90
file:///app/tns_modules/tns-core-modules/ui/builder/builder.js:167:56: JS ERROR Error: Building UI from XML. @file:///app/Views/main-page.xml:9:7
	 ↳Module '/Users/murat.corlu/Library/Developer/CoreSimulator/Devices/F842400A-D653-42B1-935C-4C5F9E5A5DB7/data/Containers/Bundle/Application/ED0E3711-5A7C-4C23-9DAF-D5EFCAB2C27B/demo.app/app/carousel-view/carousel-view' not found for element 'carousel-view/carousel-view:CarouselView'.
	   ↳Could not find module '/Users/murat.corlu/Library/Developer/CoreSimulator/Devices/F842400A-D653-42B1-935C-4C5F9E5A5DB7/data/Containers/Bundle/Application/ED0E3711-5A7C-4C23-9DAF-D5EFCAB2C27B/demo.app/app/carousel-view/carousel-view'. Computed path '/Users/murat.corlu/Library/Developer/CoreSimulator/Devices/F842400A-D653-42B1-935C-4C5F9E5A5DB7/data/Containers/Bundle/Application/ED0E3711-5A7C-4C23-9DAF-D5EFCAB2C27B/demo.app/app/carousel-view/carousel-view'.Jul  5 14:19:32 Murats-MBP com.apple.CoreSimulator.SimDevice.F842400A-D653-42B1-935C-4C5F9E5A5DB7.launchd_sim[56218] (UIKitApplication:org.nativescript.demo[0x2eb5][56240][56909]): Service exited due to Segmentation fault: 11

To be fare, the plugin has been abandonware for a while. I have focused on some other stuff. I will try to go back to this as soon as i can. Thanks


Difference in price of the video and price to be paid

The Issue
There is a different price on the video and when you want to download it and buy it. Not sure if it affects multiple videos, it probably does but I couldn't check due to my balance. It is probably some kind of a rounding issue.
Steps to reproduce

Open a video with price 0.58 LBC
When you try to pay for it, the price will be reported as 0.57

Expected behaviour
Prices should be always the same.
Actual behaviour
Prices are different.
System Configuration

LBRY Daemon version: 0.18.0
LBRY App version: 0.18.0
LBRY Installation ID: 7tYN144rHXrspzJG9xLP28fi1JztXnbpKro6DBJEQyzBmXTyDgqRLfYsUvHYFVmMe2
Operating system: Win 10

Screenshots

After clearing the cache, both prices are 0.57.

@tzarebczan do you think this is an issue with updating prices? i.e. if you make the price .58 but then lower it to .57 it doesn't update? has anyone had issues with that?

@liamcardenas I'm pretty much 100% sure I know the cause of this issue. The cost_info reducer caches costs separately from the claims reducer, and refreshing a claim does not update the cost.
Both the claim and the cost info should be hard-refreshed at least when rendering a <FilePage>, and likely more frequently (consider a <FilePage> left open).

Issue moved to lbryio/lbry #1429 via ZenHub


dd: implement iseek + oseek flags

These are the first half of changes needed to pass the dd/bytes.sh tests:

Add iseek and oseek options (additive with skip and seek options)
Implement tests for the new flags, matching those from dd/bytes.sh

--iseek and --oseek are fairly new dd features, added in coreutils commit 4439ef3ec4 this February.

I'm a bit confused by the failing GnuTests CI run- tests/misc/seq-long-double test passes both in a local build, and in GitHub CI in my fork. Is it possible the failure is an intermittent issue?

yeah, likely not your fault :)

I'm a bit confused by the failing GnuTests CI run- tests/misc/seq-long-double test passes both in a local build, and in GitHub CI in my fork. Is it possible the failure is an intermittent issue?

Yes, it is an intermittent issue https://github.com/uutils/coreutils/issues/2924

Hi! I'm doing a refactor of the argument handling of dd and ran into something I didn't quite understand. In this PR, you added tests to check that iseek and oseek are added on skip and seek, but I cannot reproduce that behaviour. Could you explain in what case they should be added?
This is with dd from GNU coreutils 9.1 and the current main branch:
❯ echo "0123456789abcdefghijklm" | dd iseek=4 skip=4 iflag=skip_bytes bs=2
456789abcdefghijklm
10+0 records in
10+0 records out
20 bytes copied, 0,000209508 s, 95,5 kB/s
❯ echo "0123456789abcdefghijklm" | cargo run --quiet -- dd iseek=4 skip=4 iflag=skip_bytes bs=2
89abcdefghijklm
8+0 records in
8+0 records out
16 bytes copied, 0.0 s, 16.0 KB/s

I likewise haven't been able to reproduce the additive behavior- I probably misinterpreted the results of my tests. I've checked out the pull request, and the behavior looks to be correct now.


Deprecate Project.getConvention()

Nag for deprecation of access to conventions: Convention, HasConvention and Project.getConvention().
Registering conventions doesn't nag yet. Mostly because of KGP still registering conventions for backwards compatibility reasons.
See https://youtrack.jetbrains.com/issue/KT-52976
This is not about "convention mapping".

@bot-gradle test RFM

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

I've triggered the following builds for you:

PullRequestFeedback build

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle AFT, AST

Sorry I don't understand what you said.
Currently, the following commands are supported:
@bot-gradle test <BuildTrigger1> <BuildTrigger2> ... <BuildTriggerN>

A trigger is a special build for this PR on TeamCity, common triggers are:

SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/PullRequestFeedback/ReadyForNightly/ReadyForRelease
Shortcuts: SC/CA/QFL/QF/PRF/RFN/RFR
Specific builds:

BD: BuildDistributions/BuildDocs so that you can preview the generated docs/distribution.
PT: PerformanceTest, all performance tests for Ready For Nightly stage.
APT: AllPerformanceTest, all performance tests, including slow performance tests.
AST: AllSmokeTestsPullRequestFeedback
AFT: AllFunctionalTestsPullRequestFeedback
ASB: AllSpecificBuildsPullRequestFeedback
ACC: AllConfigCacheTestsPullRequestFeedback
ACT: AllCrossVersionTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle test and merge

queues this PR for testing and merges if all tests pass by:

Creating a merge commit from your PR branch HEAD and the target branch
Running a ReadyForNightly build against the merge commit
When it passes, fast-forward the target branch to this merge commit (i.e. merge the PR)

The merge commit is called a pre-tested commit, which means that it fully tests the integration
of your branch HEAD and latest master, instead of only testing your branch HEAD.
@bot-gradle cherrypick to <branch>

Cherrypicks the current PR to another branch.
A new PR will be created and a build will triggered automatically if there is no conflict.

@bot-gradle cancel

cancel a running pre-tested commit build or remove it from queue

@bot-gradle clean

clear the conversation history

@bot-gradle help

display this message

To run a command, simply submit a comment.  For detailed instructions see here.

@bot-gradle test AFT, AST

I've triggered the following builds for you:

AllFunctionalTestsPullRequestFeedback build
AllSmokeTestsPullRequestFeedback build

@bot-gradle test AFT, AST

I've triggered the following builds for you:

AllFunctionalTestsPullRequestFeedback build
AllSmokeTestsPullRequestFeedback build

@bot-gradle test AFT, AST

I've triggered the following builds for you:

AllFunctionalTestsPullRequestFeedback build
AllSmokeTestsPullRequestFeedback build

@bot-gradle test AFT, AST, APT

I've triggered the following builds for you:

AllFunctionalTestsPullRequestFeedback build
AllSmokeTestsPullRequestFeedback build
AllPerformanceTestsReadyForRelease build

@bot-gradle test AFT, AST, APT

I've triggered the following builds for you:

AllFunctionalTestsPullRequestFeedback build
AllSmokeTestsPullRequestFeedback build
AllPerformanceTestsReadyForRelease build

Superseded by https://github.com/gradle/gradle/pull/24231


18.3.1

Should we bump https://github.com/preactjs/preact/blob/main/compat/src/index.js#L38 as well or should we trust that folks don't check this and only do it for the package managers?
Resolves https://github.com/preactjs/preact/issues/4441

Any reason not to land this? People do tend to see the NPM errors and assume they're doing something incorrect, rather than adding the --legacy-peer-deps flag and moving on.


Extend explanation of identifying Option in builder 06

Closes #12.

Hello @dtolnay,
Should the previous tests pass if the current_dir is made optional?


fix nonhydrostatic pressure drag

Purpose

Fix the buoyancy term in nonhydrostatic pressure drag and set the tendency to true. Also change the entrainment coefficient.
Closes #2232
To-do

Content

[ ] I have read and checked the items on the review checklist.

bors r+


Don't build JSON using string operations

Building JSON literals using string operations is dangerous. Database.getIndexDefinition() is the first place I spotted this but there may be other examples in this codebase. GSON is a better choice.

Thanks for pointing this instance out. There are some inconsistencies in this library in this respect, but we do use GSON in most places. We will try and get this and any other remaining string uses fixed up.

Attempting to build valid JSON using string operations instead of a library is dangerous in principle but it is actually the cause of several defects. This line of code:
database.findByIndex("\"selector\"asdfasdf", Subscription.class);

or this block of code:
FindByIndexOptions findByIndexOptions = new FindByIndexOptions();
findByIndexOptions.fields("\"");
database.findByIndex("{\"type\":\"subscription\"}", Subscription.class, findByIndexOptions);

both bypass the input sanitisation in Database.getFindByIndexBody() and cause it to construct invalid JSON, which is then passed to the Cloudant backend, resulting in:
{"error":"bad_request","reason":"invalid UTF-8 JSON"}

I see at line 1108 you're actually using GSON to parse the selector JSON, but then just discarding the result. It would be better to just use GSON to assemble the object you need directly.

Sorry if I wasn't clear - I completely agree that this is a bad way of doing things! I've added it to a milestone to make sure we get it fixed soon.

@emlaver I noticed there are some instances of building arrays using strings in Search.java that should also be corrected.


Added Int32 and Float32 to JSON::Type

Added Int32 and Float32 types to JSON::Type.
I am working on implementing JSON type field for crystal-mysql and faced a problem that type checking fails then it gets Int32 or Float32 values even if normal to_json works perfectly fine.

JSON::Any is more used for parsing JSON in a generic way. There won't be much use of Int32/Float32 in those cases: parsing {"a":1} is a Int32 or Int64? The use will need to deal with the union all the time an Int is expected.
crystal-mysql should use Int64/Float64 when building a JSON in a straight way.
On a given schema, a JSON.mapping could be supported though and there a lot of flexibility can be achieved.

Note: I am eager to see that JSON addition in mysql :-), so big 👍  there.

I don't know if I implement it correctly as I am just newbie with Crystal but it works for me. https://github.com/crystal-lang/crystal-mysql/pull/24

I actually have my doubts about automatically parsing a JSON field from a database. crystal-pg does that too, but I think we should just return a String. Since you are probably in control of the database you know what you put in that column typed as JSON, and the best thing to do is to use JSON.mapping with that. If you get the result already parsed there's no way to use JSON.mapping. So I would drop that from all drivers and return String instead.

Thats also a good point. I started by extending only string with native json type it was working but I went bit further and added json parsing and generation as it is json type...

Since the JSON can be a type interpreted by the database (as parameters also, not just query results). I wouldn't mind for the drivers to support them. But I would also expect that if the schema is fixed a JSON.mapping or other strict parsing technique will be used.
Probably there is no performance difference between a native json representation of the driver and just the json-to-io done by crystal, so is more an api discussion than a discussion about what happens under the hood.
But sometimes json is used to store not fixed schema data. JSON.mapping might be a bit annoying here. So I am not totally sure JSON should be discarded as a first class citizen in the db family.

I'll close this. We can continue the discussion of json & db at https://github.com/crystal-lang/crystal-mysql/pull/24 or maybe even at crystal-db since most of the drivers supports json nowadays.

Yeah, ok 👍


how can I disable an indicator?

I want to disable the empty prompt indicator but I wasn't able to with set -g @mode_indicator_empty_prompt ''

solved with an empty space with set -g @mode_indicator_empty_prompt ' '

You can also use zero-width-space https://unicode-table.com/en/200B/
set -g @mode_indicator_empty_prompt ''


[OTEL-2043] Pin otel collector version when checking otel module version

What does this PR do?
Pin otel collector version in inv check-otel-module-versions to the current version in use in Agent, rather than pulling from the latest mainline head.
Motivation
Prevent accidental breakage caused by upstream OTel change, e.g. #incident-29728.

/merge


Device Request - Smart Wall Switch - _TZE200_r731zlxk / TS0601

Device Name: Smart Wall Switch
Device Model: TS0601
Device Description: Smart Wall Seitch 6 Gang
Link to device image: https://pt.aliexpress.com/item/1005004084521839.html?spm=a2g0o.order_list.order_list_main.195.d01dcaa4UIA3V5&gatewayAdapt=glo2bra

Device Interview
"ids": {
"modelId": "TS0601",
"manufacturerName": "_TZE200_r731zlxk"
},
"endpoints": {
"ieeeAddress": "a4:c1:38:e3:dc:27:65:07",
"networkAddress": 54355,
"modelId": "TS0601",
"manufacturerName": "_TZE200_r731zlxk",
"endpointDescriptors": [
{
"status": "SUCCESS",
"nwkAddrOfInterest": 54355,
"_reserved": 20,
"endpointId": 1,
"applicationProfileId": 260,
"applicationDeviceId": 81,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
4,
5,
61184,
0
],
"outputClusters": [
25,
10
]
},
{
"status": "SUCCESS",
"nwkAddrOfInterest": 54355,
"_reserved": 10,
"endpointId": 242,
"applicationProfileId": 41440,
"applicationDeviceId": 97,
"applicationDeviceVersion": 0,
"_reserved1": 0,
"inputClusters": [],
"outputClusters": [
33
]
}
],
"deviceType": "router",
"receiveWhenIdle": true,
"capabilities": {
"alternatePANCoordinator": false,
"deviceType": true,
"powerSourceMains": true,
"receiveWhenIdle": true,
"security": false,
"allocateAddress": true
},
"extendedEndpointDescriptors": {
"1": {
"clusters": {
"groups": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"name": "nameSupport",
"value": {
"type": "Buffer",
"data": [
0
]
},
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"name": "clusterRevision",
"value": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"scenes": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 1,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 3,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 4,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"name": "clusterRevision",
"value": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"basic": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"name": "zclVersion",
"value": 3
},
{
"acl": [
"readable",
"reportable"
],
"id": 1,
"name": "appVersion",
"value": 70
},
{
"acl": [
"readable",
"reportable"
],
"id": 2,
"name": "stackVersion",
"value": 0
},
{
"acl": [
"readable",
"reportable"
],
"id": 3,
"name": "hwVersion",
"value": 1
},
{
"acl": [
"readable",
"reportable"
],
"id": 4,
"name": "manufacturerName",
"value": "_TZE200_r731zlxk"
},
{
"acl": [
"readable",
"reportable"
],
"id": 5,
"name": "modelId",
"value": "TS0601"
},
{
"acl": [
"readable",
"reportable"
],
"id": 6,
"name": "dateCode",
"value": ""
},
{
"acl": [
"readable",
"reportable"
],
"id": 7,
"name": "powerSource",
"value": "mains"
},
{
"acl": [
"readable",
"writable",
"reportable"
],
"id": 65502
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"name": "clusterRevision",
"value": 2
},
{
"acl": [
"readable",
"reportable"
],
"id": 65534,
"name": "attributeReportingStatus",
"value": "PENDING"
},
{
"acl": [
"readable",
"reportable"
],
"id": 65506
},
{
"acl": [
"readable",
"reportable"
],
"id": 65507
}
]
}
},
"bindings": {
"ota": {},
"time": {}
}
},
"242": {
"clusters": {},
"bindings": {}
}
}
}

@MarceloSilvaLeite Now in test version.

Hi @JohanBendz, I have app version 0.2.60 installed on my Homei Pro. I have tested the 6 Gang Wall Switch device and I am having problems when I press the device's keys. They have a delay in the response times of the on and off status, especially key 6 which I have no response to.
Diagnostics Report
4f4d8ee9-5f5a-4c28-b034-da8a547115ad

Hi @MarceloSilvaLeite
The diagnostic report show no errors but there are no button 5 and 6 activity.
I can see you pressed button 1, 3, 2, 4 in that order.
Can you restart the app, and press the buttons in the order below.

Button Position | Action | Expected Result | Status
-- | -- | -- | --
Button 1 (Top Left) | Press On | Homey shows Button 1 is ON |
Button 1 (Top Left) | Press Off | Homey shows Button 1 is OFF |
Button 2 (Top Center) | Press On | Homey shows Button 2 is ON |
Button 2 (Top Center) | Press Off | Homey shows Button 2 is OFF |
Button 3 (Top Right) | Press On | Homey shows Button 3 is ON |
Button 3 (Top Right) | Press Off | Homey shows Button 3 is OFF |
Button 4 (Bottom Left) | Press On | Homey shows Button 4 is ON |
Button 4 (Bottom Left) | Press Off | Homey shows Button 4 is OFF |
Button 5 (Bottom Center) | Press On | Homey shows Button 5 is ON |
Button 5 (Bottom Center) | Press Off | Homey shows Button 5 is OFF |
Button 6 (Bottom Right) | Press On | Homey shows Button 6 is ON |
Button 6 (Bottom Right) | Press Off | Homey shows Button 6 is OFF |

Hi @JohanBendz.
I performed tests on the 6 Gang Wall Switch device, but the sequence you asked me to perform does not match the outputs described on the device. I performed the tests according to the sequence of the device. First pressing keys 1, 2, 3, 4, 5 and 6. I did not obtain the status of key 6.
Below are images of the device and position of the keys.
Diagnostics Report:
f7b6294f-ef45-41e5-9cf2-b26eb3ddb6e8

@MarceloSilvaLeite Found a typo, an update will come later today.

Hi @JohanBendz , I tested the device after the update and everything seems to be working correctly. Congratulations on the great work.
I hope the other devices will be added soon.

Hi @JohanBendz , after testing the 6 Gang Wall Switch and 4 Gang Wall Switch devices for a few days, I noticed that when my Homey pro Hub is updated or even when I restart it, they don't work as they should. I have to delete and then add them again to get them working properly again.

Hmm, interesting @MarceloSilvaLeite... not expected. I'll look into it.

@MarceloSilvaLeite A fix in the upcoming Test version. Let me know if there are any issues.

Hi @JohanBendz, I have run some tests and everything seems to be working correctly.


Tell reviewdog not to filter any output

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

Comparison is base (4b0dc06) 79.52% compared to head (6205582) 80.21%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #622      +/-   ##
==========================================
+ Coverage   79.52%   80.21%   +0.68%
==========================================
  Files          70       70
  Lines        5989     5989
==========================================
+ Hits         4763     4804      +41
+ Misses       1000      958      -42
- Partials      226      227       +1

Flag
Coverage Δ

integration-test
69.98% <ø> (+0.76%)
:arrow_up:

unittests
44.50% <ø> (-0.16%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

Closing as this PR was to demonstrate some behavior.


allow move-only types to conform to Sendable

Part of the reason why we do not want to
permit conformance to protocols for
move-only types is that they're
fundamentally wrong: all existing protocols
assume the type is copyable, so we'd be
allowing people to write conformances to
things that are not actually true.
The other aspect of it is that we may
need to change the runtime representation
for conformance descriptors of move-only
types. So we can't have these conformances
leaving residue at runtime. Luckily, that
means marker protocols would be OK,
since they leave no residue at runtime.
So for, now we're going to specifically
permit move-only types to conform to the
marker protocol Sendable since it's needed
for move-only types to work with concurrency.
All of the existing rules about mixing
move-only types with generics still apply.
That means you still can't turn it into the
existential any Sendable in any way at all,
despite it conforming. The purpose of the
conformance is purely to allow the concrete
instances to cross actor isolation boundaries
if it is actually Sendable.
resolves rdar://104987062

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


Add github workflow pipeline

Issue #, if available:
#15
Description of changes:
Adding a github workflow pipeline to replace travis, since it's free now
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for the issue and contribution! Execution on your fork looks good: https://github.com/JDeuce/circuitgen/runs/6482973234?check_suite_focus=true
Could you also commit the .travis.yml removal?


Why is resuming training is uncomment？

I try to train a model by my own dataset. But it is interrupt.
How can I resume trainging
It will return a error when using resume training：

RuntimeError: Caught RuntimeError in replica 0 on device 0.

You can try to uncomment this line to resume the training which is interrupted.
https://github.com/Yaoyi-Li/GCA-Matting/blob/5a999be4b00bb482658fa7013a74a2b8acddc78e/config/gca-dist.toml#L21

hi,dear
when you resume training with your dataset how to set the config file ?
could you please show me the file ?
thx
https://github.com/Yaoyi-Li/GCA-Matting/issues/25


Corrupt icon on Monterey?

I just tried updating my vscode icon to use this and it seems to work fine except in the Info screen (at the very top of that screen) it seems to be corrupt.  Is that a known issue?  The icon works fine otherwise (i.e. in the Applications folder and the dock it looks great).

me too