Use .note.GNU-stack section in ASM.

Motivation:
Well-formed Linux assembly code declares a .note.GNU-stack section in
order to help out the linker. When absent, the linker makes some
suboptimal linking decisions that can cause pain in running programs.
Modifications:

Amend the vendoring script to add the .note.GNU-stack section to all
assembly files on Linux.
Updated BoringSSL

Results:
Better linker behaviour.

@swift-nio-bot test this please


removed second ingress key, fixed ingress class bug

This moves all ingress related values to .Values.deployment.ingress (from .Values.ingress)

Do you mind if we delay merging this a bit? I prefer to merge https://github.com/Ontotext-AD/graphdb-helm/pull/7 first, push a version to our helm registry and than merge this one as it changes the values.yaml file

No fine for me.
I'll be using it from our repo in the meantime.
Thanks

closing this one in favor of https://github.com/Ontotext-AD/graphdb-helm/pull/11


Finish porting warehouse/static/js/main.js to ES6

In #1059 we laid out the framework for using ES6 modules and webpack to handle our Javascript, but we still need to port everything in warehouse/static/js/main.js over to this as well, ideally without using jQuery if possible.

Are there any UI tests that can be run to make sure the porting is correct?

Nope :( We have the start of some UI tests, but the original JS was not written with tests.

We probably don't need this to actually launch do we? The downside to not having this is basically that we have extra JS being downloaded that we don't really need (some duplication between the old and new) but other than that it should work yea?

Also to mention is that warehouse/static/js/main.js doesn't need to be entirely ported in one go (in fact, it'd be easier both to implement and review if it were done feature by feature instead of all at once).
These things aren't massive bits of JS, but porting each would ideally involve figuring out if there's a native alternative to whatever is being used (possibly will a polyfill if needed for our Browser Support Policy or else wise pulling in small modern libraries where needed. Ideally each port will also include with it some front end tests to ensure that the JS continues to work in the future.

@wismer is working on the rest of this issue.

@dstufft since all of main.js has been ported, I suppose this issue could be closed, then?


feat: Tool for grabbing bootstrap icons, update to Bootstrap icons 1.10.3

Based on the tool to get the fontawsome icons from their API, this PR adds a tool that gets the https://icons.getbootstrap.com website and crawls the icon list from it.
The result is used to update bootstrap icons to 1.10.3

Just merged, thanks for your contribution


[SPARK-27008][SQL][FOLLOWUP] Support java.time.LocalDate as an external type of DateType

What changes were proposed in this pull request?
This fixes a typo in the SQL config value: DATETIME_JAVA8API_EANBLED -> DATETIME_JAVA8API_ENABLED.
How was this patch tested?
This was tested by RowEncoderSuite and LiteralExpressionSuite.

Test build #4658 has started for PR 24194 at commit 02b0e12.

Can one of the admins verify this patch?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9239/
Test PASSed.

Test build #103874 has started for PR 24194 at commit 02b0e12.

Test build #103874 has finished for PR 24194 at commit 02b0e12.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/103874/
Test PASSed.


Github User for Authentication Compliance Review Chapter 12

Describe the issue
In Platform Service Community Meetup, there was a demo regarding Chapter 12 that demonstrate the
suitability of using github user for authentication is sufficient.
Chapter 12 is core government policy that covers Information Management and Information Technology Management specifically and now has language speaking to the use of GitHub as an authentication provider.
Additional context

https://www2.gov.bc.ca/gov/content/governments/policies-for-government/core-policy/policies/im-it-management

Definition of done

Get a copy of the screenshot from Julian
Look up online and scan through the latest Chapter 12 and find the new section relating to GitHub (see link Additional Context above), read that section
Bring it back to the team for a 15 minute update meeting
Update the Policy slide deck to have a better introduction to what is Chapter 12, and a slide about GitHub authentication (ask PO for which copy to edit)
QA the proposed deck changes with PO

Wrote to Corey, Dir, IMB and he said he would need to do  a bit of digging to confirm use of github authentication.

Loop in Nick Corcorant for discussion


Can I print out .text section of a binary from ghidra using headless or ghidrascript?? if so, how would i do it?

Can I print out .text section of a binary from ghidra using headless or ghidrascript?? if so, how would i do it?

Duplicate of #3041

Yes. You can use getMemoryBlock('.text') to get the memory block. What you do from there is up to you. The real question is why would you want to do this?


uv pip install should support reasonable variations on pythonw.exe e.g. .pythonw.exe

When generating GUI script executables on Windows, uv will take python_executable and try to replace the filename with a constant "pythonw.exe".
Whereas pip is slightly more subtle in this regard. It would take the filename and replace the python component with pythonw. This allows for the executable name to be renamed (within reason) e.g. .python.exe and .pythonw.exe respectively.
Our use case here is that we generate relocatable virtual environments, and we deliberately rename the interpreter executable so as to avoid shadowing existing Python interpreters on the $PATH.
Happy to raise a PR, although I am new to Rust so you might have to bear with me futzing around a bit :-)

It seems like a reasonable change to me. For stuff like this, pip is effectively a spec. Feel free to give it a try, thanks.

Raised #5259 :-)


Locking exe/dll files creates interesting circular problem

We have several .net apps and postgres database running in tye. Also we use Entity Framework migrations.
The way EF migrations work is you run this:
dotnet ef database update

and it compiles the stuff and run migrations on the database.
So if I'm running tye, it fails to compile as files are locked.
If I'm not running tye, it has no access to database :)
I could workaround this in several ways, but would prefer having it working without workarounds, so wondering what are your thoughts.

So you need your database running, and then after run dotnet ef database update.
Would a precommand or post command for this after the database starts work for you?
I think this is effectively a duplicate of https://github.com/dotnet/tye/issues/627, adding an init command.


1.3.x

It is only merged in master, so no.

OK.  I pushed an updated branch with the reboot hardening bits removed.


The generated commonjs *_pb.js files don't work in Node.js environment

This bug is a rebirth of protocolbuffers/protobuf#9152, which has already been fixed in v3.19.1. It seems the fix hasn't been delivered to the latest version.
What version of protobuf and what language are you using?
Version: v3.20.1
Language: Javascript
What operating system (Linux, Windows, ...) and version?
macOs Monterey v12.3.1
What runtime / compiler are you using (e.g., python version or gcc version)
Node.js v16.13.0
What did you do?

Run protoc --js_out=import_style=commonjs,binary:path/to/out/dir --proto_path=. *.proto
Try to import and use the generated *_pb.js files.

What did you expect to see
Import and use without errors (just as in 3.19.1 - 3.19.4).
What did you see instead?
ReferenceError: window is not defined

   14 | var jspb = require('google-protobuf');
   15 | var goog = jspb;
 > 16 | var global = (function() { return this || window || global || self || Function('return this')(); }).call(null);

FYI, this was fixed in 3.19.x by PR #9156, but regressed to the old behavior. I've verified that this works with protoc version 3.19.4, but fails with 3.20.1.

Any progress on this issue, running into the same problems. I'am not be able to compile an old version of libprotoc on apple silicon m2 arm64. brew install --build-from-source protobuf-3.19.4 -> Error: protobuf-3.19.4 did not build
Error using *_pb.js
var global = (function() { return this || window || global || self || Function('return this')(); }).call(null);
Thanks

3.19.4 predates the split off of protobuf-javascript from the main protobuf repo. Do you still have a problem with protobuf v21+   (there was a numbering scheme change ~3.21) and the current published google-protobuf npm package/3.21 of protobuf-javascript? The main difference is you need to start specifying a --plugin flag to protoc to point it to protoc-gen-js.

libprotoc 3.21.5
cd lib/server && protoc \
		--plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts \
		--plugin=protoc-gen-grpc=./node_modules/.bin/grpc_tools_node_protoc_plugin \
		--js_out=import_style=commonjs,binary:./src/proto \
		--ts_out=service=grpc-node,mode=grpc-js:./src/proto \
		--grpc_out=grpc_js:./src/proto \
		-I ../../protos ../../protos/xxx.proto
protoc-gen-js: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--js_out: protoc-gen-js: Plugin failed with status code 1.
make: *** [gen-server] Error 1

Error mentioned in https://github.com/protocolbuffers/protobuf-javascript/issues/127
--plugin flag already in use as you recommended
Any other ideas i could get the last working version of libprotoc 3.19.4 running on arm64?

The surface level issue appears to be that it can't find protoc-gen-js on your PATH. However, I'm not familiar with either protoc-gen-ts or protoc-gen-grpc, so you may have better luck asking one of those projects how they depend on protoc-gen-js.

We are forced to use 3.20.3 (where this bug is still present) because of https://github.com/protocolbuffers/protobuf-javascript/issues/127,
but were able to workaround this via
// @ts-ignore
globalThis.window = null;
// @ts-ignore
globalThis.self = null;

at the start of our index.ts.

I'm seeing this same issue - can we re-open this issue?

@tbarlow12 Can you please describe your setup and any reproduction instructions?

We are also experiencing this issue when converting es module -> cjs via esbuild. It gets exposed by use strict being enabled. Seems like return this || window || global || self || Function('return this')(); implies that window can be undefined, but the way in which it is checked is not strict mode compatible.


chore: set trim_tailing_whitespace

Codecov Report

Merging #22 (e0dcb9f) into master (9d94af9) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #22   +/-   ##
=========================================
  Coverage     76.84%   76.84%
  Complexity       31       31
=========================================
  Files             7        7
  Lines            95       95
  Branches          1        1
=========================================
  Hits             73       73
  Misses           22       22

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


FiberError/NoMemoryError error related to csv gem occurs when upgrading from ruby 3.1 to 3.3

When upgrading from ruby 3.1.4 to 3.3.5, FiberError/NoMemoryError error related to csv occurred in our system. In addition, when loading csv file, CPU load also increases compared to before.

FiberError: can't alloc machine stack to fiber (1 x 659456 bytes): Cannot allocate memory error
NoMemoryError: failed to allocate memory

After investigation we found the cause. It was caused by csv gem. When upgrading ruby version, csv version is also updated (from 3.2.5 to 3.2.8)
Even if we try to keep ruby 3.1.4 and only update csv gem to 3.2.8, the FiberError/NoMemoryError error will still occur
We have upgraded ruby 3.3.5 and kept the csv gem version 3.2.5 (same as ruby version 3.1.4) and FiberError/NoMemoryError didn't occur and CPU load also didn't increase
It seems that some changes from csv 3.2.5 to 3.2.8 caused the error. This commit of csv gem is very suspicious

Could you provide a script that reproduces this?

@kou
The code in my application like this
catch(:max_lines) do
  File.open(file.path, "rt").each_line.with_index do |line, i|
    # handle line with gsub...
    csv_parse = CSV.parse(line.gsub(/\r\n?/, "\n"))
    # ...
    csv_parse.each do |row|
      # ...
      @file_content << row
    end
  end
end

In csv 3.2.8, FiberError/NoMemoryError will occur if we upload large csv file multiple times
In csv 3.2.5, No problem if we upload large csv file multiple times

Thanks.
Could you also provide sample data that reproduce this problem? (You don't need to use a real data.  I just want to reproduce this on local.)

BTW, CSV.parse(...) do |row| will be better than csv_parse = CSV.parse(...); csv_parse.each do |row|.

We only use csv files with normal data, sample data

or

I just want to reproduce this on local

Because the local memory is so large, we cannot reproduce it on local but can only reproduce it on the test environment (stagging, RAM: 9.6GB)

Hmm. I can't debug this without reproducible data...

Can you provide compose.yaml (for docker compose) that can limit available memory?


Return better error message when POST request value too large

Not sure about all the other endpoints. But need to catch when a POST request value is too large and let the user know.
In this example case I was gunning for it just to see what happens.
  Quaerat beatae dolore perferendis pariatur reiciendis temporibus? Maxime, aperiam perferendis, modi, reiciendis qui expedita repellat ea adipisci omnis laboriosam in! Reprehenderit, modi?
Impedit, quidem earum ducimus, sequi reprehenderit voluptate magni omnis, mollitia harum excepturi nesciunt nobis amet doloribus voluptatum? Dignissimos facere, voluptatum excepturi id, ipsam dolore asperiores, quibusdam ducimus doloribus magnam aliquid?"
}'

This error message is too generic. What if you have 65 instead of 64?
{
  "message": "System Error",
  "incidentIdentifier": "-8721545769261696166",
  "details": {}
}

There are at least two ways this could be addressed.

maxLength can be validated in the DTO validate() methods
We can look for "value too large for column" and return a more specific exception

#2 would probably be the "best" option overall, and certainly works in this case. But given @DanielTOsborne 's update to #849 I don't think it's going to work in every case (though it should)
So I think we're looking at a combination of 1 and 2. Should give us the bulk of things.
However, we did rename some columns so they make more sense. Probably don't need to address that complexity immediately but it's going to come up.


Extend to allow creation of virtual devices with multiple capabilities

The PR is in reference to: https://github.com/biocomp/hubitat_ci/issues/45
Changes

Updated to gradle 8.5
DeviceInputValueFactory can now generate from multiple capabilities at once.  (For example, a dimmer with both the Switch and the SwitchLevel capabilities.)
The capabilities parameter is now strongly typed.  An array of capability classes.
GeneratedDeviceInputBase also supports multiple capabilities at once now.
Updated existing tests to be strongly typed on capabilities.
Added unit test for "Multiple capability input generates object with all proper fields and methods”

Example of Usage
Because I needed to exercise these changes in another project, I published my version of the package to my own Maven repo:  https://github.com/joelwetzel/hubitat_ci/packages/2028932
Here is an example project where I made use of all this:  https://github.com/joelwetzel/Hubitat-Dimmer-Minimums

I added unit tests for everything the app does.
I added a Github Actions workflow to run the tests/gradle and archive results if tests fail.

Thanks for the feedback!  I'll take a look and respond.

Okay, I have pushed up a 5th commit with the updates.  Thanks!

It looks like the Azure pipeline is trying to use an image that has been deprecated.  Since that is determined in the yaml file, I will try to push a commit to see if I can fix it.

Ok, looks like that worked and this is ready for you to merge.  Thanks!

Thanks, @joelwetzel! I guess I might need to publish the updated package, will do this a bit later, when I recall how )


dockle: 0.3.10 -> 0.3.11

Motivation for this change
Bump dockle to 0.3.11
Set buildFlagsArray in bash
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 114841 run on x86_64-linux 1

1 package built:

dockle


Need multiple animation view demo

Any updates on this?

That should work, I use multiple animation in my other react project by react-lottie

Awesome! I'll take a look on that and see how achievable it is to translate the logic to angular. If I start working on it, I hope I can have your help too :)

Sure, I'm more than happy to collaborate with you :)


Collection summaries including Asset-only fields

The collection spec states:

Collections are strongly recommended to provide summaries of the values of fields that they can expect from the properties of STAC Items contained in this Collection.

One interpretation of this is that summaries should only include properties of STAC Items, which would exclude properties that might only exist on the Asset objects of the Item. However, it would be useful to include Asset-only properties in the summaries - for example, in the file extension, there is a file:values property that contains useful information about the classification values of a raster (though this will likely move to another extension). Having a summary at the Collection level for this asset-only property would be useful to allow users to know the classmap without having to dig into an Item.
Should asset-only properties be allowed in Collection summaries? If so, should they be treated the same as Item properties - with the property existing as a top level property in summaries (e.g. "summaries": { "file:values": [ ... ] }? What about if multiple assets have the same property value; should there be something which differentiates between the assets whose properties are being summarized?
I'd vote for treating Asset-only properties the same as Item properties; if there are multiple Assets that implement a property, then both could be summarized without differentiating, and the summary would remain valid IMO.

Summaries of asset properties (and possible link properties) would be useful for us in the Radiant MLHub API.
We have heard from a few users that it would be nice to have a collection-level summary of the file formats of the source imagery so that users could search for collections based on formats that fit into their existing workflows. We utilize the Label Extension and typically have separate source imagery and label collections. In the source imagery collection, we would probably want to summarize the Asset media type (type property) of any data assets in the collection. One problem we might run into here is distinguishing between Item- and Asset-level properties of the same name (e.g. type). There is obviously no reason to summarize the Item-level type property (since it will always be "Feature"), but we may still want a mechanism to make it clear in these kinds of cases.

What about if multiple assets have the same property value; should there be something which differentiates between the assets whose properties are being summarized?

Not sure if this is the same issue, but in our case we would only be summarizing the media type for "data" assets (i.e. not thumbnails and other assets), so it might be good to indicate this somehow in the summaries. I'm not sure what the best/clearest way is to do this, though.
This probably goes beyond the scope of what this issue is discussing, but ideally we would have a way of summarizing the Asset media type (type property) associated with the assets listed in the label:assets property of Links with "rel": "source" as defined in the Label Extension "Links: source imagery" section. This is a bit tricky since it would requires getting the label:assets property from links in a label collection and then summarizing the media type of the assets associated with the Items that those Links point to (which could be in a totally different collection).

Isn't this partially what the Item Asset Definition Extension is about?
https://github.com/stac-extensions/item-assets

One problem we might run into here is distinguishing between Item- and Asset-level properties of the same name (e.g. type). There is obviously no reason to summarize the Item-level type property (since it will always be "Feature"), but we may still want a mechanism to make it clear in these kinds of cases.

Yes I think this mechanism is necessary, for example the Common Metadata notes that created and updated can be used against both Items and Assets, and there may be a need to summarise both. Raised via https://github.com/radiantearth/stac-spec/discussions/1156.

We are thinking of progressing this in our custom stac extensions, but just wanted to check if we are doing something that would align to future stac core changes as much as possible. Can I get some feedback on this way of summarising asset metadata?
Asset created and updated summary could look like this in the collection.json.
   "summaries": {
    "assets": {
      "created": {
        "minimum": "1901-01-01T00:00:00Z",
        "maximum": "1920-01-01T00:00:00Z"
      },
      "updated": {
        "minimum": "1901-01-02T00:00:00Z",
        "maximum": "1920-01-02T00:00:00Z"
      }
    }
  }

And with some other item properties it would look like this.
   "summaries": {
    "assets": {
      "created": {
        "minimum": "1901-01-01T00:00:00Z",
        "maximum": "1920-01-01T00:00:00Z"
      },
      "updated": {
        "minimum": "1901-01-02T00:00:00Z",
        "maximum": "1920-01-02T00:00:00Z"
      }
    },
    "platform": ["Fixed-wing Aircraft"],
    "instruments": ["EAGLE IV"],
    "created": {
      "minimum": "1999-01-01T00:00:00Z",
      "maximum": "2010-01-01T00:00:00Z"
    },
    "updated": {
      "minimum": "1999-01-02T00:00:00Z",
      "maximum": "2010-01-02T00:00:00Z"
    }
  },

So, I think the assets key with summaries one level below would "break" a lot of tooling that would expect JSON Schema in there. It would certainly not work well in STAC Browser at least and I think implementations would have a hard time differentiating between the new extension and what is allowed right now. I'd recommend putting the asset summaries into a new field. Maybe it would better fit with the Item Asset definition extension? @matthewhanson In the extension you can only set a specific value and not summarize, but maybe it would be worth extending that instead of mangling with the summaries that were meant for item properties?
The item properties as you show them are already supported, that's no problem.

Thanks @m-mohr. How would this work as a new field? Happy to suggest it as a pull request on the Item Asset extension if that will help?
  "asset_summaries": {
      "created": {
        "minimum": "1901-01-01T00:00:00Z",
        "maximum": "1920-01-01T00:00:00Z"
      },
      "updated": {
        "minimum": "1901-01-02T00:00:00Z",
        "maximum": "1920-01-02T00:00:00Z"
      }
    },
    "summaries": {
      "platform": ["Fixed-wing Aircraft"],
      "instruments": ["EAGLE IV"],
      "created": {
        "minimum": "1999-01-01T00:00:00Z",
        "maximum": "2010-01-01T00:00:00Z"
      },
      "updated": {
        "minimum": "1999-01-02T00:00:00Z",
        "maximum": "2010-01-02T00:00:00Z"
      }
    },

We'd likely need a larger discussion whether it makes sense to have it in the Item Asset Definition Extension, e.g. on one of the Monday calls. Feel free to join, if you can although I guess TZ differences make it hard for you. I can put that on the agenda and discuss it for you, if you can't join.
Otherwise, you could likely come up with a new extension that looks similar to what you've shown above.

If I can make it, I will. I think my email address is public if you want to send an invite there? Otherwise, if I'm not there, please put it on the agenda for me. Thanks.

Okay, @matthewhanson can you invite @billgeo, please?

Participation in the call was low this week so we postponed it to the next meeting, but in general people agreed on one of the approaches mentioned above. We identified that having it as part of the Item Asset Definition extension could lead to validation issues in JSON Schema.


Recent MSS110 Firmware Update Broke meross_lan

Version of the custom_component
5.2.1
Configuration

Configured using UI with cloud login.

Describe the bug
I have a number of mss110 devices. Some are hardware version 4.0.0, some are 7.0.0. Recently, a firmware update for hardware 7.0.0 was rolled out. The firmware notes said something like "improve security of local control". After updating, meross_lan can no longer control these devices at all. My hardware version 4.0.0 devices (firmware 4.2.14) are still working.
Debug log

2024-06-08 20:50:12.858 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################1] Polling begin
2024-06-08 20:50:12.858 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################1] TX(http) SET Appliance.Control.Multiple (messageId:16f92586dde44e63bb5fc070ff490771)
2024-06-08 20:50:12.908 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################1] RX(http) SETACK Appliance.Control.Multiple (messageId:16f92586dde44e63bb5fc070ff490771)
2024-06-08 20:50:12.908 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################1] Appliance.Control.Multiple requests=2 (responses=2) expected size=930 (actual=982)
2024-06-08 20:50:12.908 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################1] Polling end
2024-06-08 20:50:14.981 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] Polling begin
2024-06-08 20:50:14.981 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] TX(http) GET Appliance.System.All (messageId:7df7f3f0106f4cddb0e530fac65c2ea3)
2024-06-08 20:50:15.081 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] RX(http) GETACK Appliance.System.All (messageId:7df7f3f0106f4cddb0e530fac65c2ea3)
2024-06-08 20:50:15.081 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] Polling end
2024-06-08 20:50:15.081 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] TX(http) GET Appliance.System.Debug (messageId:1462cbbda37e4577ad69837e4d1a9bef)
2024-06-08 20:50:15.138 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################0] HTTP ERROR GET Appliance.System.Debug (messageId:1462cbbda37e4577ad69837e4d1a9bef ServerDisconnectedError:Server disconnected)
2024-06-08 20:50:15.327 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] Polling begin
2024-06-08 20:50:15.328 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] TX(http) GET Appliance.System.All (messageId:43480e9a7dde4a649222269109652371)
2024-06-08 20:50:15.426 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] RX(http) GETACK Appliance.System.All (messageId:43480e9a7dde4a649222269109652371)
2024-06-08 20:50:15.426 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] Polling end
2024-06-08 20:50:15.426 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] TX(http) GET Appliance.System.Debug (messageId:bfc110b44b8346379e0f6dda312df42a)
2024-06-08 20:50:15.486 DEBUG (MainThread) [custom_components.meross_lan.mss110_###############################4] HTTP ERROR GET Appliance.System.Debug (messageId:bfc110b44b8346379e0f6dda312df42a ServerDisconnectedError:Server disconnected)

Enabling diagnostic entities on this firmware populates three new sensors:
Name: Suite_ds
Value: [null]
—
Name: Suite_ka
Value: ecdhe256
—
Name: Suite_se
Value: mrskey
—
Judging by ecdhe256 above and the patch notes, it looks like they may have started encrypting local connections, if they weren't already.

I'm still able to issue some commands to the /config endpoint. For example these still work:

Appliance.System.All
Appliance.System.Ability

But these result in an immediate socket hangup (I've validated that these same commands still work on the older firmware):

Appliance.Control.ToggleX
Appliance.System.Debug

This could explain a similar issue as in https://github.com/krahabb/meross_lan/issues/430#issuecomment-2131930662.
I think it would need some reverse engineering on the app <-> device communication in order to extract the eventual 'key' needed for correctly setting up those failing requests/responses.
I could guess the header would need some extra field carrying an added signature or the standard signature algorithm has been updated to a new version.
Or, there's an extra 'encapsulation' of the whole payload which is no more sent as a plain json

Yup, looks like the same exact behavior.
I tried sniffing traffic last night but couldn’t get my Mac to pick up the eapol packets for some reason. I’ll try running tcpdump on my UniFi router and/or access point to see if I can grab the traffic that way.
There are also two new capabilities for encryption listed; one to return the encryption suite, and the other presumably for initial key exchange.

Not looking good, seems like the payload and header are both completely encrypted now. Here's what the traffic looks like between my app and the plug when toggling power:
Host: <IP_ADDRESS>
Content-Type: text/plain
Connection: keep-alive
Accept: */*
User-Agent: intellect_socket/3.26.0 (iPhone; iOS 17.5.1; Scale/3.00)
Accept-Language: en-US;q=1
Content-Length: 472
Accept-Encoding: gzip, deflate

YmN73xCvPUw/BHOupPbpPjpMSxiEShfVguENAx/zy/Z8xX1FnoKzroF890DXonAErMliiwpwW6K8h61u8VG+tx6El2AtYP3muv3TK/pg3/zcsaTcTSPE+D4wl8paVwdXSujOmcbvzwcIxkZGzGpqBiteeK8qTh0KxNnbDc80Q89i29AjlVsrC9oZJXSFOUkgAUTX+6GjmZiJb0YoDefIU8YHR5l881Z3PzZ+IW7fIP8ZlPUsXxKTV+cpKyx/HcT+ZX5uFiA5KnvUmNM3NxfKlTc37IAsA02L4jTF4p86Q3g1j4VQPtIFb8iVLTOWnZdupfsjkgJS58QYoDSeYg3k/ETzdfoBxsyb++q6NoPcw5GlImf3kaz0QESBFo9kcBRIcIYpG9YjEjlQ4eYBOB8xQs660AnZupQQgvII5ntaAnevgNLTk6y9K5K7TE7l7RcXx9p6o+E+3i+0A7Oq/DLYxA==

I'm going to request that Meross roll back my firmware to the previous version on these plugs.
But my other question is: why isn't cloud connectivity working? The meross_cloud HA integration seems to work OK via cloud. I guess they use different mechanisms, but I thought they were both using the Meross  MQTT broker to send/receive messages.

Hello @brianschrameck ,
Today I've checked the merossiot repo which is the foundation of that other component and it looks like it is supporting encryption...so the solution for meross_lan would be to 'copy' that implementation along.
@albertogeniola is always doing a damn good job with Meross...I (we) surely owe him some coffee or beer ;)

Hi @krahabb ,
Didn't notice this thread. You are right, the newest firmware do add encryption capabilities for local lan communication. Feel free to get inspiration 🙂

Hello @brianschrameck,
I've ported the support for encryption from https://github.com/albertogeniola/MerossIot and it is now implemented in the dev branch. I could sooner or later release an alpha but I guess you'd have no problems directly downloading the branch (tell me, I can anyway quickly 'pre-release' during the day).
Or, take inspiration if you want to try 'manually' encode/decode payloads and see if everything fits.
It looks as even if ECDHE256 is mentioned as 'ka' (key algorithm ?) encryption is basically an AES CBC with a 'parameterized' key and a fixed iv. Meross uses this techninque here and there to compute secrets based off some unique/intrinsic device properties (uuid/mac) and the device/account key (signature key).
The fix itself is pretty simple and you'll easily check the diff in #2920018 (mainly in httpclient.py)

That was fast! I pulled the dev branch and things look to be working well. 👍 Thanks!

Awesome ;)

Do you have an ETA on when you will make a release with this? Asking so I can make sure I check back and update :) Thanks!

Hello @rxin.
The 'pre-release' channel already has an update with the feature which has already been tested in the field and looks promising.
You can enable 'beta releases' in HACS for the repo so to get access to the download.
Else I think I could release an official version in the next weekend

Sadly Alpha 2 is still not working for me and I think the Sensors changed. I can see the current state bug can't switch it in HA. Hope that helps :)

How do i enable the beta? I am having this issue?

This is puzzling me a bit. By the look of it the issue is strictly connected to this incoming new fw for v7 hw which is introducing (mandatory?) encryption for HTTP traffic which is the default meross_lan uses.
Some queries though are still supported in clear and that's why some state from the device gets refreshed (typically the switch state) but obviously the commands are not (and many other queries: this explains @stefmde dashboard view)
What I don't understand is why the patch (5.3.0-alpha.2) worked for @brianschrameck and is not working for others exposing the same kind of issue/behavior. If I could get a 'Download diagnostic' (with 5.3.0-alpha.2) from any of these devices I could try better figure out.
In the meantime, you could try re-configure the device (no need to remove and re-add the device).
Just enter CONFIGURE from meross_lan integration UI and without any change hit the SUBMIT button so that the component tries/checks the device configuration (do this for any device still exposing the issue on alpha.2). This might be needed since the device abilities are only read once when the device is configured and the integration needs to know if, among those abilities, encryption is supported or not.

FWIW I had completely removed and reinstalled the integration, so that would seem to make sense for the need to reconfigure.

This is the raw data from one of the devices that is not working in Alpha 2
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2024.6.4",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.12.2",
"docker": true,
"arch": "aarch64",
"timezone": "America/St_Johns",
"os_name": "Linux",
"os_version": "6.6.33-haos",
"supervisor": "2024.06.2",
"host_os": "Home Assistant OS 12.4",
"docker_version": "26.1.4",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"pyscript": {
"documentation": "https://github.com/custom-components/pyscript",
"version": "1.5.0",
"requirements": [
"croniter==1.3.8",
"watchdog==2.3.1"
]
},
"meross_lan": {
"documentation": "https://github.com/krahabb/meross_lan",
"version": "5.3.0-alpha.2",
"requirements": []
},
"hacs": {
"documentation": "https://hacs.xyz/docs/configuration/start",
"version": "1.34.0",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"meross_cloud": {
"documentation": "https://www.home-assistant.io/components/meross_cloud",
"version": "1.3.2",
"requirements": [
"meross_iot==<IP_ADDRESS>b3"
]
},
"sinope": {
"documentation": "https://github.com/claudegel/sinope-gt125",
"version": "1.6.8",
"requirements": [
"crc8==0.1.0"
]
},
"neviweb": {
"documentation": "https://github.com/claudegel/sinope-1",
"version": "2.2.1",
"requirements": []
}
},
"integration_manifest": {
"domain": "meross_lan",
"name": "Meross LAN",
"after_dependencies": [
"mqtt",
"dhcp",
"recorder",
"persistent_notification"
],
"codeowners": [
"krahabb"
],
"config_flow": true,
"dhcp": [
{
"hostname": "",
"macaddress": "48E1E9"
},
{
"hostname": "",
"macaddress": "C4E7AE"
},
{
"hostname": "",
"macaddress": "34298F1"
},
{
"registered_devices": true
}
],
"documentation": "https://github.com/krahabb/meross_lan",
"integration_type": "hub",
"iot_class": "local_polling",
"issue_tracker": "https://github.com/krahabb/meross_lan/issues",
"loggers": [
"custom_components.meross_lan"
],
"mqtt": [
"/appliance/+/publish"
],
"requirements": [],
"version": "5.3.0-alpha.2",
"is_built_in": false
},
"setup_times": {
"null": {
"setup": 9.595799929229543e-05
},
"5facaa17d15da6786588cda63012676d": {
"wait_import_platforms": -0.00013970799773233011,
"config_entry_setup": 0.13238459500280442
},
"5487551d6e2301668a0c658a8454544f": {
"wait_import_platforms": -0.0002295419981237501,
"wait_base_component": -17.50815853200038,
"config_entry_setup": 18.160321740004292
},
"43c8fa579c1f9fba9ebd9837bf3434dd": {
"wait_import_platforms": -0.0002450009997119196,
"wait_base_component": -17.471636823000154,
"config_entry_setup": 18.158324693002214
},
"b23b90b3aa40466c909c880789b37998": {
"wait_import_platforms": -0.0003590420019463636,
"wait_base_component": -17.43496782299917,
"config_entry_setup": 18.20350163099647
},
"369679a0ec61f2b4123e4066137e5123": {
"wait_base_component": -17.458617377000337,
"config_entry_setup": 18.15588868800114
},
"d00445cae8a6103543a229f958e5b76c": {
"wait_base_component": -17.44835447800142,
"config_entry_setup": 18.154161433994886
},
"88ad65f5238005719418ec45af88a23f": {
"wait_base_component": -17.440699376995326,
"config_entry_setup": 18.20782997400238
},
"a03666194118864e8ba54050794c6b13": {
"wait_base_component": -17.439782084002218,
"config_entry_setup": 18.20374575599999
},
"be26019096d2700a7de0c43684092920": {
"wait_base_component": -17.37868506799714,
"config_entry_setup": 18.203088045993354
},
"55aa7176d15601398a2090c0651d62d8": {
"wait_base_component": -17.353665261005517,
"config_entry_setup": 18.204670924998936
},
"57c03035bd9b46b570f5f7a6c3dfdbe4": {
"wait_base_component": -17.3253067379992,
"config_entry_setup": 18.207901433001098
},
"ebabf095514c6a0c40913719a106e5ce": {
"wait_base_component": -17.304023480995966,
"config_entry_setup": 18.206789304997073
},
"ff3fc9be763a3ccf76badc0e526a2e32": {
"wait_base_component": -17.285623645999294,
"config_entry_setup": 18.206181469999137
},
"3d251a541f7e229c5bca76d488ff8687": {
"wait_base_component": -17.282749557001807,
"config_entry_setup": 18.2056305110018
},
"f933e3b0f0d03b6e46b52f114281d3a5": {
"wait_base_component": -17.278159588000563,
"config_entry_setup": 18.205279050998797
}
},
"data": {
"host": "########0",
"payload": {
"all": {
"system": {
"hardware": {
"type": "mss110",
"subType": "un",
"version": "7.0.0",
"chipType": "rtl8710cm",
"uuid": "##############################13",
"macAddress": "################0"
},
"firmware": {
"version": "7.3.37",
"homekitVersion": "6.3",
"compileTime": "2024/04/12-19:13:08",
"encrypt": 1,
"wifiMac": "################0",
"innerIp": "########0",
"server": "###################0",
"port": "@0",
"userId": "@0"
},
"time": {
"timestamp":<PHONE_NUMBER>,
"timezone": "America/St_Johns",
"timeRule": [
[
1647149400,
-9000,
1
],
[
1667709000,
-12600,
0
],
[
1678599000,
-9000,
1
],
[
1699158600,
-12600,
0
],
[
1710048600,
-9000,
1
],
[
1730608200,
-12600,
0
],
[
1741498200,
-9000,
1
],
[
1762057800,
-12600,
0
],
[
1772947800,
-9000,
1
],
[
1793507400,
-12600,
0
],
[
1805002200,
-9000,
1
],
[
1825561800,
-12600,
0
],
[
1836451800,
-9000,
1
],
[
1857011400,
-12600,
0
],
[
1867901400,
-9000,
1
],
[
1888461000,
-12600,
0
],
[
1899351000,
-9000,
1
],
[
1919910600,
-12600,
0
],
[
1930800600,
-9000,
1
],
[
1951360200,
-12600,
0
]
]
},
"online": {
"status": 1,
"bindId": "YKL1WiEdsQl2htET",
"who": 1
}
},
"digest": {
"togglex": [
{
"channel": 0,
"onoff": 1,
"lmTime":<PHONE_NUMBER>
}
],
"triggerx": [],
"timerx": []
}
},
"payloadVersion": 1,
"ability": {
"Appliance.Config.Key": {},
"Appliance.Config.WifiList": {},
"Appliance.Config.Wifi": {},
"Appliance.Config.WifiX": {},
"Appliance.Config.Trace": {},
"Appliance.Config.Info": {},
"Appliance.Config.OverTemp": {},
"Appliance.Config.NtpSite": {},
"Appliance.Encrypt.Suite": {},
"Appliance.Encrypt.ECDHE": {},
"Appliance.System.All": {},
"Appliance.System.Hardware": {},
"Appliance.System.Firmware": {},
"Appliance.System.Debug": {},
"Appliance.System.Online": {},
"Appliance.System.Time": {},
"Appliance.System.Clock": {},
"Appliance.System.Ability": {},
"Appliance.System.Runtime": {},
"Appliance.System.Report": {},
"Appliance.System.Position": {},
"Appliance.System.DNDMode": {},
"Appliance.Control.Multiple": {
"maxCmdNum": 3
},
"Appliance.Control.Bind": {},
"Appliance.Control.Unbind": {},
"Appliance.Control.Upgrade": {},
"Appliance.Control.OverTemp": {},
"Appliance.Control.ToggleX": {},
"Appliance.Control.TimerX": {
"sunOffsetSupport": 1
},
"Appliance.Digest.TimerX": {},
"Appliance.Control.TriggerX": {},
"Appliance.Digest.TriggerX": {}
}
},
"key": "###############################0",
"device_id": "##############################13",
"device": {
"class": "MerossDevice",
"conf_protocol": "auto",
"pref_protocol": "http",
"curr_protocol": "http",
"polling_period": 30,
"device_response_size_min": 1450,
"device_response_size_max": 5000,
"MQTT": {
"cloud_profile": true,
"locally_active": false,
"mqtt_connection": true,
"mqtt_connected": true,
"mqtt_publish": true,
"mqtt_active": true
},
"HTTP": {
"http": true,
"http_active": true
},
"namespace_handlers": {
"Appliance.System.All": {
"lastrequest":<PHONE_NUMBER>.139646,
"lastresponse":<PHONE_NUMBER>.6335526,
"polling_strategy": "async_poll_all"
},
"Appliance.Control.ToggleX": {
"lastrequest": 0.0,
"lastresponse":<PHONE_NUMBER>.9870756,
"polling_strategy": null
},
"Appliance.Config.OverTemp": {
"lastrequest":<PHONE_NUMBER>.4392803,
"lastresponse":<PHONE_NUMBER>.5916905,
"polling_strategy": "async_poll_lazy"
},
"Appliance.System.DNDMode": {
"lastrequest":<PHONE_NUMBER>.4392803,
"lastresponse":<PHONE_NUMBER>.5916905,
"polling_strategy": "async_poll_lazy"
},
"Appliance.System.Runtime": {
"lastrequest":<PHONE_NUMBER>.4392803,
"lastresponse":<PHONE_NUMBER>.5916905,
"polling_strategy": "async_poll_lazy"
},
"Appliance.System.Debug": {
"lastrequest": 0.0,
"lastresponse":<PHONE_NUMBER>.947002,
"polling_strategy": null
}
},
"namespace_pushes": {
"Appliance.Control.ToggleX": {
"togglex": [
{
"lmTime":<PHONE_NUMBER>,
"channel": 0,
"onoff": 1
}
]
}
},
"device_info": {
"uuid": "##############################13",
"onlineStatus": 1,
"devName": "August Connect Front",
"devIconId": "device001",
"bindTime":<PHONE_NUMBER>,
"deviceType": "mss110",
"subType": "us",
"channels": [
{}
],
"region": "us",
"fmwareVersion": "7.3.37",
"hdwareVersion": "7.0.0",
"userDevIcon": "",
"iconType": 1,
"domain": "###################0",
"reservedDomain": "###################0",
"hardwareCapabilities": []
}
},
"trace": [
[
"time",
"rxtx",
"protocol",
"method",
"namespace",
"data"
],
[
"2024/06/28 - 11:45:47",
"",
"auto",
"GETACK",
"Appliance.System.All",
{
"system": {
"hardware": {
"type": "mss110",
"subType": "un",
"version": "7.0.0",
"chipType": "rtl8710cm",
"uuid": "##############################13",
"macAddress": "################0"
},
"firmware": {
"version": "7.3.37",
"homekitVersion": "6.3",
"compileTime": "2024/04/12-19:13:08",
"encrypt": 1,
"wifiMac": "################0",
"innerIp": "########0",
"server": "###################0",
"port": "@0",
"userId": "@0"
},
"time": {
"timestamp":<PHONE_NUMBER>,
"timezone": "America/St_Johns",
"timeRule": [
[
1647149400,
-9000,
1
],
[
1667709000,
-12600,
0
],
[
1678599000,
-9000,
1
],
[
1699158600,
-12600,
0
],
[
1710048600,
-9000,
1
],
[
1730608200,
-12600,
0
],
[
1741498200,
-9000,
1
],
[
1762057800,
-12600,
0
],
[
1772947800,
-9000,
1
],
[
1793507400,
-12600,
0
],
[
1805002200,
-9000,
1
],
[
1825561800,
-12600,
0
],
[
1836451800,
-9000,
1
],
[
1857011400,
-12600,
0
],
[
1867901400,
-9000,
1
],
[
1888461000,
-12600,
0
],
[
1899351000,
-9000,
1
],
[
1919910600,
-12600,
0
],
[
1930800600,
-9000,
1
],
[
1951360200,
-12600,
0
]
]
},
"online": {
"status": 1,
"bindId": "YKL1WiEdsQl2htET",
"who": 1
}
},
"digest": {
"togglex": [
{
"channel": 0,
"onoff": 1,
"lmTime":<PHONE_NUMBER>
}
],
"triggerx": [],
"timerx": []
}
}
],
[
"2024/06/28 - 11:45:47",
"",
"auto",
"GETACK",
"Appliance.System.Ability",
{
"Appliance.Config.Key": {},
"Appliance.Config.WifiList": {},
"Appliance.Config.Wifi": {},
"Appliance.Config.WifiX": {},
"Appliance.Config.Trace": {},
"Appliance.Config.Info": {},
"Appliance.Config.OverTemp": {},
"Appliance.Config.NtpSite": {},
"Appliance.Encrypt.Suite": {},
"Appliance.Encrypt.ECDHE": {},
"Appliance.System.All": {},
"Appliance.System.Hardware": {},
"Appliance.System.Firmware": {},
"Appliance.System.Debug": {},
"Appliance.System.Online": {},
"Appliance.System.Time": {},
"Appliance.System.Clock": {},
"Appliance.System.Ability": {},
"Appliance.System.Runtime": {},
"Appliance.System.Report": {},
"Appliance.System.Position": {},
"Appliance.System.DNDMode": {},
"Appliance.Control.Multiple": {
"maxCmdNum": 3
},
"Appliance.Control.Bind": {},
"Appliance.Control.Unbind": {},
"Appliance.Control.Upgrade": {},
"Appliance.Control.OverTemp": {},
"Appliance.Control.ToggleX": {},
"Appliance.Control.TimerX": {
"sunOffsetSupport": 1
},
"Appliance.Digest.TimerX": {},
"Appliance.Control.TriggerX": {},
"Appliance.Digest.TriggerX": {}
}
],
[
"2024/06/28 - 11:45:47",
"TX",
"http",
"GET",
"Appliance.Config.Info",
{
"info": {}
}
],
[
"2024/06/28 - 11:45:47",
"RX",
"http",
"GETACK",
"Appliance.Config.Info",
{
"info": {
"homekit": {
"model": "MSS110",
"sn": "##############0",
"category": 7,
"setupId": "###0",
"setupCode": "#########0",
"uuid": "##################################14",
"token": "###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################0"
}
}
}
],
[
"2024/06/28 - 11:45:47",
"TX",
"http",
"GET",
"Appliance.Config.OverTemp",
{
"overTemp": {}
}
],
[
"2024/06/28 - 11:45:47",
"RX",
"http",
"GETACK",
"Appliance.Config.OverTemp",
{
"overTemp": {
"enable": 1,
"type": -1
}
}
],
[
"2024/06/28 - 11:45:47",
"TX",
"http",
"GET",
"Appliance.Config.NtpSite",
{
"ntpSite": {}
}
],
[
"2024/06/28 - 11:45:47",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Config.NtpSite (messageId:53c020437d2a41b393f80edc390a9f41 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 11:45:47",
"TX",
"http",
"PUSH",
"Appliance.Config.NtpSite",
{}
],
[
"2024/06/28 - 11:45:47",
"RX",
"http",
"SET",
"Appliance.Config.NtpSite",
{}
],
[
"2024/06/28 - 11:45:47",
"",
"auto",
"LOG",
"debug",
"Handler undefined for method:SET namespace:Appliance.Config.NtpSite payload:{}"
],
[
"2024/06/28 - 11:45:47",
"TX",
"http",
"GET",
"Appliance.Encrypt.Suite",
{
"suite": {}
}
],
[
"2024/06/28 - 11:45:48",
"RX",
"http",
"GETACK",
"Appliance.Encrypt.Suite",
{
"suite": {
"ka": "ecdhe256",
"se": "mrskey",
"ds": ""
}
}
],
[
"2024/06/28 - 11:45:48",
"",
"auto",
"LOG",
"debug",
"Handler undefined for method:GETACK namespace:Appliance.Encrypt.Suite payload:{'suite': {'ka': 'ecdhe256', 'se': 'mrskey', 'ds': ''}}"
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"GET",
"Appliance.Encrypt.ECDHE",
{
"eCDHE": {}
}
],
[
"2024/06/28 - 11:45:48",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Encrypt.ECDHE (messageId:82bef6b6c23f487698d1581c5b3607f2 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"PUSH",
"Appliance.Encrypt.ECDHE",
{}
],
[
"2024/06/28 - 11:45:48",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Encrypt.ECDHE (messageId:1b49af4fd6644fae943c6dc868155fdd ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"GET",
"Appliance.System.Debug",
{
"debug": {}
}
],
[
"2024/06/28 - 11:45:48",
"RX",
"http",
"GETACK",
"Appliance.System.Debug",
{
"debug": {
"system": {
"version": "7.3.37",
"homekitVersion": "6.3",
"sysUpTime": "17h43m18s",
"UTC":<PHONE_NUMBER>,
"localTimeOffset": -9000,
"localTime": "Fri Jun 28 11:45:47 2024",
"suncalc": "5:5;21:2",
"memTotal": 3611680,
"memFree": 3320864,
"memMini": 3312192
},
"network": {
"linkStatus": "connected",
"snr": 36,
"channel": 4,
"signal": 100,
"rssi": -33,
"ssid": "########0",
"gatewayMac": "################0",
"innerIp": "########0",
"wifiDisconnectCount": 0,
"wifiDisconnectDetail": {
"totalCount": 0,
"detials": []
}
},
"cloud": {
"linkStatus": "connected",
"activeServer": "###################0",
"mainServer": "###################0",
"mainPort": "@0",
"secondServer": "###################1",
"secondPort": "@0",
"userId": "@0",
"sysConnectTime": "Thu Jun 27 20:32:40 2024",
"sysOnlineTime": "17h43m7s",
"sysDisconnectCount": 0,
"iotDisconnectDetail": {
"totalCount": 0,
"detials": []
}
}
}
}
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"GET",
"Appliance.System.Runtime",
{
"runtime": {}
}
],
[
"2024/06/28 - 11:45:48",
"RX",
"http",
"GETACK",
"Appliance.System.Runtime",
{
"runtime": {
"signal": 100,
"ssid": "########0"
}
}
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"GET",
"Appliance.Control.OverTemp",
{
"overTemp": {}
}
],
[
"2024/06/28 - 11:45:48",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Control.OverTemp (messageId:aa526945917f44b0a636307941fbefc6 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"PUSH",
"Appliance.Control.OverTemp",
{}
],
[
"2024/06/28 - 11:45:48",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Control.OverTemp (messageId:638274d41c9743c3a812f141254b1627 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 11:45:48",
"TX",
"http",
"GET",
"Appliance.Control.ToggleX",
{
"togglex": []
}
],
[
"2024/06/28 - 11:45:48",
"RX",
"http",
"GETACK",
"Appliance.Control.ToggleX",
{
"channel":<PHONE_NUMBER>,
"togglex": [
{
"channel": 0,
"onoff": 1,
"lmTime":<PHONE_NUMBER>
}
]
}
]
]
}
}

By the way I tried uninstalling the HACS intergration and rebooting and re-adding. No change.
I did break down and install the Merros Cloud integration and that works as a backup while I am waiting for this issue to be resolved.
https://github.com/albertogeniola/meross-homeassistant

First I had an old Version (don't know the Version) manually installed. After that I had HACS. So I removed the old version manually and installed the beta 2 via HACS and restarted HA. Now I noticed that there comes a additional popup wenn I hit the "Configure?" button on the device. I clicked the "Configure?" button in the first popup and the second popup is the same then as in the old version I had. I then submitted as you sayed without changing something. Doesn't work. I checked all the Connectiontypes. MQTT can't be submitted. Auto/Http made no difference.

@JosephRDawson:
Your diagnostic seems promising as everything (except some new/unknown messages which are irrelevant for the general behavior) looks like working good. If I'm not wrong you previously posted/opened an issue (#467 - now closed) with some logs where almost 99% of the HTTP connections were failing while now the queries are working ok.
So, the alpha.2 looks like working 'in general' in order to address the encrypted protocol support. The issue you have now might be different, or related but at a different level.

Hi ... I closed 467 because it was a duplicate to this issue and I wanted to respect the bug tracking.  I didn't close it because it was resolved.
The log data may look better but the end result is the same... Not working. :)
Is their any additional captures or anything i could do to give you more data.

Do I need to open an own issue? Thought it was the same as here ^^
Unfortunately I don't know where I can find logs or something to provide mir insights.

Ok... I turned on debug  and flicked it on and off a few times and downloaded the diagnostics.
If their is something more useful i can do please let me know.
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2024.6.4",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.12.2",
"docker": true,
"arch": "aarch64",
"timezone": "America/St_Johns",
"os_name": "Linux",
"os_version": "6.6.33-haos",
"supervisor": "2024.06.2",
"host_os": "Home Assistant OS 12.4",
"docker_version": "26.1.4",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"pyscript": {
"documentation": "https://github.com/custom-components/pyscript",
"version": "1.5.0",
"requirements": [
"croniter==1.3.8",
"watchdog==2.3.1"
]
},
"meross_lan": {
"documentation": "https://github.com/krahabb/meross_lan",
"version": "5.2.2",
"requirements": []
},
"hacs": {
"documentation": "https://hacs.xyz/docs/configuration/start",
"version": "1.34.0",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"meross_cloud": {
"documentation": "https://www.home-assistant.io/components/meross_cloud",
"version": "1.3.2",
"requirements": [
"meross_iot==<IP_ADDRESS>b3"
]
},
"sinope": {
"documentation": "https://github.com/claudegel/sinope-gt125",
"version": "1.6.8",
"requirements": [
"crc8==0.1.0"
]
},
"neviweb": {
"documentation": "https://github.com/claudegel/sinope-1",
"version": "2.2.1",
"requirements": []
}
},
"integration_manifest": {
"domain": "meross_lan",
"name": "Meross LAN",
"after_dependencies": [
"mqtt",
"dhcp",
"recorder",
"persistent_notification"
],
"codeowners": [
"krahabb"
],
"config_flow": true,
"dhcp": [
{
"hostname": "",
"macaddress": "48E1E9"
},
{
"hostname": "",
"macaddress": "C4E7AE"
},
{
"hostname": "",
"macaddress": "34298F1"
},
{
"registered_devices": true
}
],
"documentation": "https://github.com/krahabb/meross_lan",
"integration_type": "hub",
"iot_class": "local_polling",
"issue_tracker": "https://github.com/krahabb/meross_lan/issues",
"loggers": [
"custom_components.meross_lan"
],
"mqtt": [
"/appliance/+/publish"
],
"requirements": [],
"version": "5.2.2",
"is_built_in": false
},
"setup_times": {
"null": {
"setup": 0.00010062500001595254
},
"5facaa17d15da6786588cda63012676d": {
"wait_import_platforms": -0.00015020900002582493,
"config_entry_setup": 0.13967065000002776
},
"5487551d6e2301668a0c658a8454544f": {
"wait_import_platforms": -0.00022458400002278722,
"wait_base_component": -15.021828568999979,
"config_entry_setup": 15.688359437000031
},
"43c8fa579c1f9fba9ebd9837bf3434dd": {
"wait_import_platforms": -0.00022370900001078553,
"wait_base_component": -15.018911891000016,
"config_entry_setup": 15.688577312999996
},
"b23b90b3aa40466c909c880789b37998": {
"wait_import_platforms": -0.00032900200000085533,
"wait_base_component": -14.991269665000004,
"config_entry_setup": 15.733747026999993
},
"369679a0ec61f2b4123e4066137e5123": {
"wait_base_component": -15.008456478000028,
"config_entry_setup": 15.688269311999989
},
"d00445cae8a6103543a229f958e5b76c": {
"wait_base_component": -14.998731984000017,
"config_entry_setup": 15.685461135000025
},
"88ad65f5238005719418ec45af88a23f": {
"wait_base_component": -14.998177231999989,
"config_entry_setup": 15.735422655999969
},
"a03666194118864e8ba54050794c6b13": {
"wait_base_component": -14.995308096999963,
"config_entry_setup": 15.732610104000003
},
"be26019096d2700a7de0c43684092920": {
"wait_base_component": -14.967768535000005,
"config_entry_setup": 15.733833069000013
},
"55aa7176d15601398a2090c0651d62d8": {
"wait_base_component": -14.970194628000002,
"config_entry_setup": 15.740974262999998
},
"57c03035bd9b46b570f5f7a6c3dfdbe4": {
"wait_base_component": -14.962858601999983,
"config_entry_setup": 15.742457102999992
},
"ebabf095514c6a0c40913719a106e5ce": {
"wait_base_component": -14.960336257999984,
"config_entry_setup": 15.745732824000015
},
"ff3fc9be763a3ccf76badc0e526a2e32": {
"wait_base_component": -14.956675537000024,
"config_entry_setup": 15.747446664000051
},
"3d251a541f7e229c5bca76d488ff8687": {
"wait_base_component": -14.95347856699999,
"config_entry_setup": 15.744509569999991
},
"f933e3b0f0d03b6e46b52f114281d3a5": {
"wait_base_component": -14.950121180000053,
"config_entry_setup": 15.744561778000048
}
},
"data": {
"host": "#########0",
"payload": {
"all": {
"system": {
"hardware": {
"type": "mss110",
"subType": "un",
"version": "7.0.0",
"chipType": "rtl8710cm",
"uuid": "##############################11",
"macAddress": "################0"
},
"firmware": {
"version": "7.3.37",
"homekitVersion": "6.3",
"compileTime": "2024/04/12-19:13:08",
"encrypt": 1,
"wifiMac": "################0",
"innerIp": "#########0",
"server": "###################0",
"port": "@0",
"userId": "@0"
},
"time": {
"timestamp":<PHONE_NUMBER>,
"timezone": "America/St_Johns",
"timeRule": [
[
1647149400,
-9000,
1
],
[
1667709000,
-12600,
0
],
[
1678599000,
-9000,
1
],
[
1699158600,
-12600,
0
],
[
1710048600,
-9000,
1
],
[
1730608200,
-12600,
0
],
[
1741498200,
-9000,
1
],
[
1762057800,
-12600,
0
],
[
1772947800,
-9000,
1
],
[
1793507400,
-12600,
0
],
[
1805002200,
-9000,
1
],
[
1825561800,
-12600,
0
],
[
1836451800,
-9000,
1
],
[
1857011400,
-12600,
0
],
[
1867901400,
-9000,
1
],
[
1888461000,
-12600,
0
],
[
1899351000,
-9000,
1
],
[
1919910600,
-12600,
0
],
[
1930800600,
-9000,
1
],
[
1951360200,
-12600,
0
]
]
},
"online": {
"status": 1,
"bindId": "XpqA1zpbqHU0wxZe",
"who": 1
}
},
"digest": {
"togglex": [
{
"channel": 0,
"onoff": 0,
"lmTime":<PHONE_NUMBER>
}
],
"triggerx": [],
"timerx": []
}
},
"payloadVersion": 1,
"ability": {
"Appliance.Config.Key": {},
"Appliance.Config.WifiList": {},
"Appliance.Config.Wifi": {},
"Appliance.Config.WifiX": {},
"Appliance.Config.Trace": {},
"Appliance.Config.Info": {},
"Appliance.Config.OverTemp": {},
"Appliance.Config.NtpSite": {},
"Appliance.Encrypt.Suite": {},
"Appliance.Encrypt.ECDHE": {},
"Appliance.System.All": {},
"Appliance.System.Hardware": {},
"Appliance.System.Firmware": {},
"Appliance.System.Debug": {},
"Appliance.System.Online": {},
"Appliance.System.Time": {},
"Appliance.System.Clock": {},
"Appliance.System.Ability": {},
"Appliance.System.Runtime": {},
"Appliance.System.Report": {},
"Appliance.System.Position": {},
"Appliance.System.DNDMode": {},
"Appliance.Control.Multiple": {
"maxCmdNum": 3
},
"Appliance.Control.Bind": {},
"Appliance.Control.Unbind": {},
"Appliance.Control.Upgrade": {},
"Appliance.Control.OverTemp": {},
"Appliance.Control.ToggleX": {},
"Appliance.Control.TimerX": {
"sunOffsetSupport": 1
},
"Appliance.Digest.TimerX": {},
"Appliance.Control.TriggerX": {},
"Appliance.Digest.TriggerX": {}
}
},
"key": "###############################0",
"device_id": "##############################11",
"timestamp":<PHONE_NUMBER>.4211953,
"device": {
"class": "MerossDevice",
"conf_protocol": "auto",
"pref_protocol": "http",
"curr_protocol": "http",
"polling_period": 30,
"device_response_size_min": 1449,
"device_response_size_max": 1449,
"MQTT": {
"cloud_profile": true,
"locally_active": false,
"mqtt_connection": true,
"mqtt_connected": true,
"mqtt_publish": true,
"mqtt_active": true
},
"HTTP": {
"http": true,
"http_active": true
},
"namespace_handlers": {
"Appliance.System.All": {
"lastrequest":<PHONE_NUMBER>.758611,
"lastresponse":<PHONE_NUMBER>.0832298,
"polling_strategy": "async_poll_all"
},
"Appliance.Control.ToggleX": {
"lastrequest": 0.0,
"lastresponse":<PHONE_NUMBER>.177938,
"polling_strategy": null
},
"Appliance.Config.OverTemp": {
"lastrequest":<PHONE_NUMBER>.095082,
"lastresponse":<PHONE_NUMBER>.4489262,
"polling_strategy": "async_poll_lazy"
},
"Appliance.System.DNDMode": {
"lastrequest":<PHONE_NUMBER>.095082,
"lastresponse":<PHONE_NUMBER>.4489262,
"polling_strategy": "async_poll_lazy"
},
"Appliance.System.Runtime": {
"lastrequest":<PHONE_NUMBER>.095082,
"lastresponse":<PHONE_NUMBER>.4489262,
"polling_strategy": "async_poll_lazy"
},
"Appliance.Encrypt.Suite": {
"lastrequest": 0.0,
"lastresponse":<PHONE_NUMBER>.9674473,
"polling_strategy": null
}
},
"namespace_pushes": {
"Appliance.Control.ToggleX": {
"togglex": [
{
"onoff": 0,
"lmTime":<PHONE_NUMBER>,
"channel": 0
}
]
}
},
"device_info": {
"uuid": "##############################11",
"onlineStatus": 1,
"devName": "Fan",
"devIconId": "device001",
"bindTime":<PHONE_NUMBER>,
"deviceType": "mss110",
"subType": "us",
"channels": [
{}
],
"region": "us",
"fmwareVersion": "7.3.37",
"hdwareVersion": "7.0.0",
"userDevIcon": "",
"iconType": 1,
"domain": "###################0",
"reservedDomain": "###################0",
"hardwareCapabilities": []
}
},
"trace": [
[
"time",
"rxtx",
"protocol",
"method",
"namespace",
"data"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"GETACK",
"Appliance.System.All",
{
"system": {
"hardware": {
"type": "mss110",
"subType": "un",
"version": "7.0.0",
"chipType": "rtl8710cm",
"uuid": "##############################11",
"macAddress": "################0"
},
"firmware": {
"version": "7.3.37",
"homekitVersion": "6.3",
"compileTime": "2024/04/12-19:13:08",
"encrypt": 1,
"wifiMac": "################0",
"innerIp": "#########0",
"server": "###################0",
"port": "@0",
"userId": "@0"
},
"time": {
"timestamp":<PHONE_NUMBER>,
"timezone": "America/St_Johns",
"timeRule": [
[
1647149400,
-9000,
1
],
[
1667709000,
-12600,
0
],
[
1678599000,
-9000,
1
],
[
1699158600,
-12600,
0
],
[
1710048600,
-9000,
1
],
[
1730608200,
-12600,
0
],
[
1741498200,
-9000,
1
],
[
1762057800,
-12600,
0
],
[
1772947800,
-9000,
1
],
[
1793507400,
-12600,
0
],
[
1805002200,
-9000,
1
],
[
1825561800,
-12600,
0
],
[
1836451800,
-9000,
1
],
[
1857011400,
-12600,
0
],
[
1867901400,
-9000,
1
],
[
1888461000,
-12600,
0
],
[
1899351000,
-9000,
1
],
[
1919910600,
-12600,
0
],
[
1930800600,
-9000,
1
],
[
1951360200,
-12600,
0
]
]
},
"online": {
"status": 1,
"bindId": "XpqA1zpbqHU0wxZe",
"who": 1
}
},
"digest": {
"togglex": [
{
"channel": 0,
"onoff": 0,
"lmTime":<PHONE_NUMBER>
}
],
"triggerx": [],
"timerx": []
}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"GETACK",
"Appliance.System.Ability",
{
"Appliance.Config.Key": {},
"Appliance.Config.WifiList": {},
"Appliance.Config.Wifi": {},
"Appliance.Config.WifiX": {},
"Appliance.Config.Trace": {},
"Appliance.Config.Info": {},
"Appliance.Config.OverTemp": {},
"Appliance.Config.NtpSite": {},
"Appliance.Encrypt.Suite": {},
"Appliance.Encrypt.ECDHE": {},
"Appliance.System.All": {},
"Appliance.System.Hardware": {},
"Appliance.System.Firmware": {},
"Appliance.System.Debug": {},
"Appliance.System.Online": {},
"Appliance.System.Time": {},
"Appliance.System.Clock": {},
"Appliance.System.Ability": {},
"Appliance.System.Runtime": {},
"Appliance.System.Report": {},
"Appliance.System.Position": {},
"Appliance.System.DNDMode": {},
"Appliance.Control.Multiple": {
"maxCmdNum": 3
},
"Appliance.Control.Bind": {},
"Appliance.Control.Unbind": {},
"Appliance.Control.Upgrade": {},
"Appliance.Control.OverTemp": {},
"Appliance.Control.ToggleX": {},
"Appliance.Control.TimerX": {
"sunOffsetSupport": 1
},
"Appliance.Digest.TimerX": {},
"Appliance.Control.TriggerX": {},
"Appliance.Digest.TriggerX": {}
}
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Config.Info",
{
"info": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Config.Info (messageId:cd29461b3f60482fbea7404390a936e6)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Config.Info (messageId:cd29461b3f60482fbea7404390a936e6 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.Config.Info",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.Config.Info (messageId:11bfdf84876b4739bd98f4b19d97ff25)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Config.Info (messageId:11bfdf84876b4739bd98f4b19d97ff25 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Config.OverTemp",
{
"overTemp": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Config.OverTemp (messageId:8dc951a0a3a94825870d70977a97b18f)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Config.OverTemp (messageId:8dc951a0a3a94825870d70977a97b18f ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Config.NtpSite",
{
"ntpSite": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Config.NtpSite (messageId:2345c6da652d4067a6aaa21bb7dca0d9)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Config.NtpSite (messageId:2345c6da652d4067a6aaa21bb7dca0d9 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.Config.NtpSite",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.Config.NtpSite (messageId:6ee605eb0ce3485f99a1a7aa868f89d4)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Config.NtpSite (messageId:6ee605eb0ce3485f99a1a7aa868f89d4 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Encrypt.Suite",
{
"suite": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Encrypt.Suite (messageId:9740d6f9df744c5d94c25f7614e318d8)"
],
[
"2024/06/28 - 13:01:24",
"RX",
"http",
"GETACK",
"Appliance.Encrypt.Suite",
{
"suite": {
"ka": "ecdhe256",
"se": "mrskey",
"ds": ""
}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"RX(http) GETACK Appliance.Encrypt.Suite (messageId:9740d6f9df744c5d94c25f7614e318d8)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"Handler undefined for method:GETACK namespace:Appliance.Encrypt.Suite payload:{'suite': {'ka': 'ecdhe256', 'se': 'mrskey', 'ds': ''}}"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Encrypt.ECDHE",
{
"eCDHE": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Encrypt.ECDHE (messageId:1cf3b5ed87b943dc94b216d2ca47c146)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Encrypt.ECDHE (messageId:1cf3b5ed87b943dc94b216d2ca47c146 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.Encrypt.ECDHE",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.Encrypt.ECDHE (messageId:2064bcc681c140cf9cdac775eb70ece6)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Encrypt.ECDHE (messageId:2064bcc681c140cf9cdac775eb70ece6 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.System.Debug",
{
"debug": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.System.Debug (messageId:19363a67ce144dcda3aa9a4c8b75473f)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.System.Debug (messageId:19363a67ce144dcda3aa9a4c8b75473f ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.System.Debug",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.System.Debug (messageId:2a4272fe52204ebeb1ac4279064f0b82)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.System.Debug (messageId:2a4272fe52204ebeb1ac4279064f0b82 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.System.Runtime",
{
"runtime": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.System.Runtime (messageId:c36985427cf640bfa8b2919849ab4bfe)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.System.Runtime (messageId:c36985427cf640bfa8b2919849ab4bfe ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Control.OverTemp",
{
"overTemp": {}
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Control.OverTemp (messageId:0f134d00811b4138bb5777c92be6fff6)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Control.OverTemp (messageId:0f134d00811b4138bb5777c92be6fff6 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.Control.OverTemp",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.Control.OverTemp (messageId:7f644a78ea2c4c578ddc78aaea055684)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Control.OverTemp (messageId:7f644a78ea2c4c578ddc78aaea055684 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"GET",
"Appliance.Control.ToggleX",
{
"togglex": []
}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) GET Appliance.Control.ToggleX (messageId:0c7ecccee0a246f3a636cd1a2b2f38a7)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR GET Appliance.Control.ToggleX (messageId:0c7ecccee0a246f3a636cd1a2b2f38a7 ServerDisconnectedError:Server disconnected)"
],
[
"2024/06/28 - 13:01:24",
"TX",
"http",
"PUSH",
"Appliance.Control.ToggleX",
{}
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"TX(http) PUSH Appliance.Control.ToggleX (messageId:e2cbdd4968184554ad967bd3c9727e57)"
],
[
"2024/06/28 - 13:01:24",
"",
"auto",
"LOG",
"debug",
"HTTP ERROR PUSH Appliance.Control.ToggleX (messageId:e2cbdd4968184554ad967bd3c9727e57 ServerDisconnectedError:Server disconnected)"
]
]
}
}

Oh you get the debug logs when you turn debug off! Ok I have them.
home-assistant_switch_as_x_2024-06-28T15-48-30.325Z.log
home-assistant_meross_lan_2024-06-28T15-49-19.821Z.log

I question if this item should be flagged as "fixed" ;)

@JosephRDawson,
Yeah..this issue is still ongoing of course even if flagged as fixed ;)
At any rate, there's some 'confusion' in your logs since:

here you've posted a diagnostic with 5.3.0-alpha.2 version and that diagnostic looks like working in general (this diagnostic was grabbed at around "2024/06/28 - 11:45:47"
here the 'same' diagnostic states that the component version is 5.2.2 (clearly not supporting encryption and so not working 'by design') and was grabbed at around "2024/06/28 - 13:01:24"

So it looks like after installing 5.3.0-alpha.2 somehow you reverted to 5.2.2 which is obviously not working

Do I need to open an own issue? Thought it was the same as here ^^ Unfortunately I don't know where I can find logs or something to provide mir insights.

Hello @stefmde,
I think your issue could be the same since your device dashboard shows the state for the switch while nothing else and this is 'typical' when the issue is about encryption.
Since your mss210 is on fw 7.3.5 it is hard to say if your device works the same as those mss110 with fw 7.3.37 but we'll try detect the issue in the same way:
First of all, ensure you have 5.3.0-alpha.2 installed (see my previous post ). After that, try to get a 'diagnostic' for the device i.e. from your device dashboard (DOWNLOAD MEROSS_LAN DIAGNOSTICS) and post a link (try to not copy/paste here the full diagnostic since it would clutter the thread ;)

LOL good catch!
Ok after I did the uninstall and reinstall I didn't know beta was turned off.
Ok so new logs and debug info from alpha2.
Still not working...
home-assistant_meross_lan_2024-06-28T21-46-28.428Z.log
meross_lan-d00445cae8a6103543a229f958e5b76c-August Connect Front-62fa7daf6730043e0a4f3463430feb19(1).json

Hello @JosephRDawson,
Something has changed since it looks you've tried toggling your mss110 (marked with the obfuscated id "##############################13") and those messages are working so it looks like your device should actually toggling when you use HA to switch it. Also, both the log and the diagnostic trace show the device is being queried correctly. What is the specific issue with this  particular device ? (you have many mss in your log so it's hard to say which one is behaving how).
In 5.2.2 it was not working at all (replies disconnection) while, on 5.3.0-alpha.2 it looks like behaving correctly (protocol-wise)
In the log you've posted, there are many connections errors about other mss110 devices but these errors look different ("Connect call failed") than the typical error due to wrong encryption ("Server disconnected"). Also, these other devices are not replying on MQTT too so it looks like they're internally 'stalling' not being able to reply to any query from any protocol.
Either, their IP is not correct (and so HTTP fails since it cannot find a device at the provided address) but this doesn't explain why they're not reachable via MQTT. In my experience inferred from similar issues in the past, this happens and is usually fixed with some 'old style reboot' of the device so that any internal bugged state gets reset.

Hi @krahabb,
I power cycled a plug that is not working just to be sure and no change.  Let me give you more information.  The plug I tested just then was August Connect Front and it's Entity ID ends with eab_outlet when you look at the logs.
In the log data I am providing you now using your integration I turned on and off the plug in HA 5 times.  And it says it is working but the device is NOT changing state.  Then I also turn it on and off five times locally via HomeKit.  And you could see your integration was capturing the change and showing it going on and off.  So your integration even when I was using 5.2.2 was always seeing state changes in the plugs without issue.  It just hasn't been able to change the sate since the new firmware.
The device is working in HA using the the https://github.com/albertogeniola/meross-homeassistant/issues integration that works via the cloud.  (But obviously as a HA user I want it done locally.)
I hope this additional information is helpful.
Here are the new logs.
meross_lan-d00445cae8a6103543a229f958e5b76c-August Connect Front-62fa7daf6730043e0a4f3463430feb19.json
home-assistant_meross_lan_2024-06-29T12-29-33.049Z.log
In the log data I am sending you now I turned on Debug and I tu

So your integration even when I was using 5.2.2 was always seeing state changes in the plugs without issue.
Yes, this is explained by the fact that MQTT traffic is not being encrypted in new fw so it is correctly decoded even in 5.2.2.
Your config has a 'Meross cloud profile' configured so in most cases your devices are being reached over MQTT when HTTP fails for any reason. In general, when you see 'instant' updates to the switch state, that's because meross_lan is configured to receive MQTT traffic (through Meross cloud) and as stated aboce, MQTT traffic is not encrypted anyway.

Regarding encryption, at the moment it is only being enforced over HTTP, and, by the look of your traces it seems working...just the commands are not executed at the device so maybe there's an another issue..I'll further investigate those toggle commands being accepted by the device but not sorting any effect..

@krahabb  Ok sir... Just giving you all the info i know for now.
If their is anything additional i can provide don't hesitate to ask.
All the best,
Joe

Hello @JosephRDawson,
I really can't figure out where the issue lies. We can try a different approach to further investigate it:
Since you have the Meross cloud profile setup, we could try force the protocol to (cloud) MQTT in order to see if the issue is in the HTTP transport or somewhere else:

ensure your Meross cloud profile has "Allow cloud MQTT publish" set
enter your "August Connect Front" device config in HA/meross_lan and set the "Connection protocol" to MQTT

When configured this way you might incur throttling in 'message rate' (maximum 6 messages over a 1 minute span) but, unless you're repeatedtly 'fast switching' your plug this shouldn't occur very often ;)

Hi @krahabb ...
I assume your talking about this set of options in the cloud version.

All three methods work equally as well.

Ok I just installed 5.3.0-beta.0
Still not working but I assume you have more logging information.
It is now faster to notice that it is NOT working and the LOGBOOK next to each device when you flick it is not showing success.  So Meross LAN now knows it is NOT working.
I made a short video so you could see it.  To the right is my Home Kit so you can see HomeKit the device is not moving and at the end i turn off and on in HomeKit and Meross LAN shows it working.
https://www.youtube.com/watch?v=KRDaTtKV63g
home-assistant_meross_lan_2024-07-01T12-23-52.212Z.log
meross_lan-d00445cae8a6103543a229f958e5b76c-August Connect Front-62fa7daf6730043e0a4f3463430feb19.json

@krahabb  ... Ok I thought you wanted to know if making that change in their integration broke their system.
Sorry.
Turning on and off the MQTT configuration in  5.3.0-beta.0 has no change that i can see.

Thank you @JosephRDawson,
The video is awesome :) good job!
At any rate, I've tried gambling with this fix but I wasn't really confident...my old mss310 accept both the previous version and this new one but in general, and the @albertogeniola integration does that too, the 'supposed correct way' was the previous one. Now, this is no more an issue about encryption since it looks very stable overall..just this 'toggle command' which is not working.
This looks anyway similar to the issue @stefmde  is having on its mss210.
Right now we should consider the 5.3.0-beta.0 as surely buggy (with this new implementation) so I'll revert that fix rightaway.
At the moment I'm like 'bumbing my head into the wall' (not sure if this is the correct way to say that...)
What I would do, with the device available, is to try manually issuing some commands using the HA services interface UI (Developer tools -> SERVICES) so I'll ask you to do so if you like:
In the HA 'SERVICES' UI select the meross_lan.request service call and fill it like this:

Device identifier: provide the 32 alphanumerics identifying the device (in the trace it is obscurated but you'll have it)
alternatively use the correct Host address (I would prefer the first but they're somewhat equal methods)
Protocol: set as HTTP
Method: set as SET
Namespace: select 'Appliance.Control.ToggleX'
Payload: enter {"togglex":{"channel":0, "onoff": 1}}

The payload is the one which usually worked (swapping "onoff" -> 0/1 for toggling) and is the one used in 5.3.0-alpha.2 or any previous version. The device should reply with a SETACK and an empty payload (this too is the usual reply when the command works).
Beside trying issuing that command for toggling (I'm expecting it gets replied with SETACK meaning success - but the device doesn't really toggle...) what I would test now is to try this payload:
{"togglex":{"channel":4294967295, "onoff": 1}} and see what's the outcome. This is because in the logs/diagnostics you've uploaded, the ToggleX message carries this 'strange' channel value for the channel in an unusual place and I might suspect it could have some meaning.
Also, since you're there, try issuing those messages by setting the Protocol to MQTT for the service call (don't use AUTO else we would not know if and where the message worked since the code would decide the transport on its own).

I am showing you the HTTP tries but the MQTT results are the same no effect but here is the data.
You should pick up a plug so you can try yourself they are dirt cheap.  What country are you in and do you have Amazon Prime?

You should pick up a plug so you can try yourself they are dirt cheap. What country are you in and do you have Amazon Prime?

Sure that's no issue..
But since I wont use them anyway that would be a bit of a waste. I hoped we could get around this by simple tries but it looks very enigmatic so far.
At any rate, even having the plugs I would be at lost since these commands are the only reasonable ones and they used to work before....
Also, the other component (meross_cloud) is working right and it uses the same commands so I really don't understand

@krahabb The Meross cloud system is always sending to Meross cloud.  So I guess they are using a dedicated system with extra authentication to Meross. And now you need that... perhaps they are using the users password with the local authentication now and maybe that has changed and is causing it to be broken.
I just hate to think this integration will get dropped once they update the firmware on all devices. You put so much work into it... it will be sad to see it go.
Also is this normal? To have it show no devices here?

Also is this normal? To have it show no devices here?

The 'no devices' is ok since that config entry is just a kind of 'connector' to the Meross api in order to query devices config and broker addresses.

@krahabb The Meross cloud system is always sending to Meross cloud. So I guess they are using a dedicated system with extra authentication to Meross. And now you need that... perhaps they are using the users password with the local authentication now and maybe that has changed and is causing it to be broken.

I don't think so. Everything else is working, just the issued commands which are somehow ignored (even though the device accepts it with the SETACK confirmation). We'll further investigate

@krahabb I guess I will revert for now to the stable release until you have something you would like me to test.

I see you made another 5.3.0-beta.1... :)  No change.. I will keep trying as long as you have things you want me to try.

Yep..the beta.1 is just reverting the toggle command to what it was before...since the implementation in beta.0 was just a 'drastic' attempt.

Any progress?

Hello @JosephRDawson,
I'm a bit busy lately and didn't go any further on the topic. I'll try come up with a trick for the matter...
Anyway I'm just curious and would like to have a confirmation from @brianschrameck since in the initial fix, he confirmed it was working flawlessly. If that's true the issue you're having would likely be not related to encryption but something else.

I see a new update for it was released a few hours ago.  No change in it not working...

Hello @JosephRDawson,
As previously confirmed I have really no idea where this issue lies. The fact the issue might not be related to encryption would also be confirmed by the fact @phhoef in #470 verified the beta (which is still not toggling your mss(s)) has correctly fixed its somewhat related issue.
So, at the moment I strongly guess your issue might be different (and so better open a new thread) but still out of ideas about how to fix :(


new to Flame

Hello, i have been fooling around with Flame and Tiled for a few days and i have read the docs, but i cant figure out how to get tile data from the TiledComponent.
import 'package:flame/components.dart';
import 'package:flame/effects.dart';
import 'package:flame/flame.dart';
import 'package:flame/game.dart';
import 'package:flame_tiled/flame_tiled.dart';
import 'package:flutter/widgets.dart' hide Animation, Image;

import 'package:flame/input.dart';
import 'package:flame/events.dart';

// Main
void main() {
  runApp(GameWidget(game: TiledGame()));
}

// Tile and map
Size tile = const Size(128, 64);
Size map = const Size(30, 30);

//  TiledGame
class TiledGame extends FlameGame with PanDetector, TapDetector {
  late TiledComponent mapComponent;

  TiledGame() : super(
    camera: CameraComponent.withFixedResolution(
      width: map.width * tile.width,
      height: map.height * tile.height,
    ),
  );

  @override
  Future<void> onLoad() async {
    debugMode = true;
    mapComponent = await TiledComponent.load(
        'test.tmx',
        Vector2(128, 64),
        prefix: 'assets/maps/'
    );
    world.add(mapComponent);
    camera.viewfinder.anchor = Anchor.center;
    camera.moveTo(
        Vector2(
            (map.width * tile.width) * 0.5,
            (map.height * tile.height) * 0.5
        )
    );
  }

  @override
  void onTapDown(TapDownInfo info) {
    // int x = ??
    // int y = ??
    // print(mapComponent.tileMap.getTileData(layerId: 0, x: x, y: y));
  }

  @override
  void onPanUpdate(DragUpdateInfo info) {
    double offset = 3.3;
    Vector2 pos = Vector2((info.delta.global.x*offset)*-1, (info.delta.global.y*offset)*-1);
    camera.moveBy(pos);
  }
}

Hi @Mythar. 🙂 GitHub issues should ideally be used for requesting new features, reporting bugs or suggesting improvements. That is the reason why following options are presented when you are creating a new issues

Such "how-to" questions should ideally be posted under the "Discussions" table on GitHub or on the discord server.

ok, id did so :)

Here is the SO thread that was created from this:
https://stackoverflow.com/questions/77536446/new-to-flame-and-tile


[feat] Right-click to add to AI chat + Hotkey for adding to chat

Right-click to add selected element(s) to chat. Remember that a user may be holding SHIFT down and selecting multiple elements.

Hotkey (CMD+SHIFT+L) that adds the selected element code chunk to the existing chat
Hotkey (CMD+L) that starts a new AI chat with the selected element code chunk.

Also fits in the family of Right Click actions #683 #206 #520

This is for the chat functionality which is only available in beta. Standby.

This is now ready to be picked up now that AI is in main. Should just be a simple tab switch.

Hey @drfarrell @Kitenite, Can I take up this task?

@RaghavGanesh7 go for it!