[WIP] malonso/modules + custom build commands + durable object support

[x] remove linter and add custom build options as part of JS TargetType

JS projects with current config options will continue to work the same.
if a [builder-config] section is added, a custom build command can be configured. Wrangler will handle watching for changes and running the build command for the user.

[x] support uploading in module format

when the script-format field in [builder-config] is set to modules, we should upload using the new modules format, uploading each file in builder-config.output_dir as a module.
The main_module is determined by looking at the module field in package.json. this should point to the bundled module in the output directory.
for service-worker builds, the behavior is the same as always: the main field in package.json is what will be uploaded, so this should be the output of your build tool.

[x] support creating/implementing durable object namespaces
[x] support binding/using durable object namespaces

This PR closes a lot of tickets with the same general theme (I hit xyz build edge case and I need a new feature to fix it/I want to use newer webpack version/I don't want to use webpack) that all come down to the limitations of wrangler's current build setup. Custom builds will allow users to setup their own build step, which wrangler will upload the results of unmodified to the API.
closes #206
closes #820
closes #954
partially addresses #1102
partially addresses #1397
closes #1550
might address #1557? need to test
closes #1558

Is there a design doc somewhere? I don't know this codebase well enough to review the code but I'm interested to understand how this will end up looking from the user's perspective.

Is there a design doc somewhere? I don't know this codebase well enough to review the code but I'm interested to understand how this will end up looking from the user's perspective.

And may I request an example of how to use a simple example like the Counter in the folder structure of a Worker Site?

@kentonv the only design doc was that google doc linked from our meeting on dec 9.
I believe Matt's plan was to share an example wrangler template, which should hopefully make things clearer.  It'll be at least a couple weeks before there's more progress on this PR though.

@koeninger would you mind sharing the document? i'd like to take a look too

Me too.
On Tue, Dec 29, 2020 at 4:41 PM Sven Sauleau<EMAIL_ADDRESS>wrote:

@koeninger https://github.com/koeninger would you mind sharing the
document? i'd like to take a look too
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#issuecomment-752265948,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWSCDNYRI5244SSCSO5D4DSXJLLNANCNFSM4UXDVOQA
.

Does it make sense to support a modules project without a build step? If I had a modules project with one source file at ./index.mjs:

I would need to configure my src_dir and build_dir to be './'.
Wrangler would then try to upload all files in './' as modules, and fail on something like .gitignore because it can't parse the extension.
I would move index.mjs to a new src directory and update src_dir and build_dir.

I think we can solve this by moving upload_format from builder_config to top-level configuration. So we don't tie module support to having a build step with source and build directories.
I'll make a line comment about the .gitignore failure.

Does it make sense to support a modules project without a build step? If I had a modules project with one source file at ./index.mjs:

I would need to configure my src_dir and build_dir to be './'.
Wrangler would then try to upload all files in './' as modules, and fail on something like .gitignore because it can't parse the extension.
I would move index.mjs to a new src directory and update src_dir and build_dir.

I think we can solve this by moving upload_format from builder_config to top-level configuration. So we don't tie module support to having a build step with source and build directories.
I'll make a line comment about the .gitignore failure.

I think we can solve this by moving upload_format from builder_config to top-level configuration. So we don't tie module support to having a build step with source and build directories.

We still need to know where to look for files to upload, right?  Having to specify a subdirectory seems about as inconvenient / confusing as having to specify ignore patterns.  I guess we could special case single file modules using the filename from package.json module, but that seems hacky

I think we can solve this by moving upload_format from builder_config to top-level configuration. So we don't tie module support to having a build step with source and build directories.

We still need to know where to look for files to upload, right?  Having to specify a subdirectory seems about as inconvenient / confusing as having to specify ignore patterns.  I guess we could special case single file modules using the filename from package.json module, but that seems hacky

I've done some light testing of this locally. Going to setup some example projects (service_worker project + webpack custom build, durable object module project + rollup custom build) and make sure there's no surprises.

I've done some light testing of this locally. Going to setup some example projects (service_worker project + webpack custom build, durable object module project + rollup custom build) and make sure there's no surprises.

https://github.com/xortive/durable-objects-template is a template using rollup + durable objects + modules.
To try this out, clone my branch and run cargo install --path . --debug in the root of the wrangler repo, which will install my branch's wrangler on your machine.

https://github.com/xortive/durable-objects-template is a template using rollup + durable objects + modules.
To try this out, clone my branch and run cargo install --path . --debug in the root of the wrangler repo, which will install my branch's wrangler on your machine.

https://github.com/xortive/service-worker-template service worker demo project. this one works with wrangler dev even!

https://github.com/xortive/service-worker-template service worker demo project. this one works with wrangler dev even!

Hey @xortive, still digesting this. Could you please squash and rebase so that the PR only has your own commits in it? Since there are multiple logical parts to this I would like to look at the modules commits separately.

Hey @xortive, still digesting this. Could you please squash and rebase so that the PR only has your own commits in it? Since there are multiple logical parts to this I would like to look at the modules commits separately.

Hey @xortive, still digesting this. Could you please squash and rebase so that the PR only has your own commits in it? Since there are multiple logical parts to this I would like to look at the modules commits separately.

done :)

Hey @xortive, still digesting this. Could you please squash and rebase so that the PR only has your own commits in it? Since there are multiple logical parts to this I would like to look at the modules commits separately.

done :)

https://github.com/xortive/service-worker-template service worker demo project. this one works with wrangler dev even!

Can we add a note to that repo's readme about how to get started? Just to remind people to npm install before trying to build the project.

https://github.com/xortive/service-worker-template service worker demo project. this one works with wrangler dev even!

Can we add a note to that repo's readme about how to get started? Just to remind people to npm install before trying to build the project.

There's already a PR to just run npm install as part of the build,
https://github.com/xortive/service-worker-template/pull/1
On Tue, Jan 19, 2021 at 11:00 AM Andrew Sharp<EMAIL_ADDRESS>wrote:

https://github.com/xortive/service-worker-template service worker demo
project. this one works with wrangler dev even!
Can we add a note to that repo's readme about how to get started? Just to
remind people to npm install before trying to build the project.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#issuecomment-762979901,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAB3H2Q3XHZB2XQLWUJ3S2W3ETANCNFSM4UXDVOQA
.

There's already a PR to just run npm install as part of the build,
https://github.com/xortive/service-worker-template/pull/1
On Tue, Jan 19, 2021 at 11:00 AM Andrew Sharp<EMAIL_ADDRESS>wrote:

https://github.com/xortive/service-worker-template service worker demo
project. this one works with wrangler dev even!
Can we add a note to that repo's readme about how to get started? Just to
remind people to npm install before trying to build the project.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#issuecomment-762979901,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAB3H2Q3XHZB2XQLWUJ3S2W3ETANCNFSM4UXDVOQA
.

sorry for the history churn, needed to rearrange the build_dir -> package_dir rename to before the custom build squash commit

sorry for the history churn, needed to rearrange the build_dir -> package_dir rename to before the custom build squash commit

I've added a good bit more logging and bails for failure cases (like trying to use wrangler preview with modules. I'm still testing locally to find other problems, I'll update this list below:

[ ] Don't allow uploading service-worker scripts that attempt to implement a durable object namespace, provide a nice error instead
[ ]

I've added a good bit more logging and bails for failure cases (like trying to use wrangler preview with modules. I'm still testing locally to find other problems, I'll update this list below:

[ ] Don't allow uploading service-worker scripts that attempt to implement a durable object namespace, provide a nice error instead
[ ]

squashed fixups and rebased onto master

squashed fixups and rebased onto master

My main concern is making sure durable objects users can try it out.  If
we're doing an RC anyway, I don't see how doing 2 separate RCs is going to
make things easier to roll back than doing 1 RC.  From my perspective we
can keep it in RC until durable objects GA if we have to, as long as
external users have an easy way to get a binary.  I don't think we have the
bandwidth to do any major wrangler refactors that would conflict with it in
the meantime.
On Thu, Jan 28, 2021 at 10:33 AM Natalie Davidson<EMAIL_ADDRESS>wrote:

@nataliescottdavidson commented on this pull request.
This looks good to me. My main concern is how we are going to release it
without breaking anything. Wrangler has minimal test coverage. It looks
like you've done a lot of good manual testing @xortive
https://github.com/xortive, but I can't help worrying that some edge
case is going to break. I'm in favor of doing an RC and asking internal
users to test things out before we go to a full release.
I think that the modules and DO changes should be separate. This will make
things easier in case we have to roll back. I remember that @koeninger
https://github.com/koeninger had thoughts on this from the last
wrangler contributors meeting.
Thanks for the great work on this @xortive https://github.com/xortive.
I'll approve once we have a release plan in place, you and I can sheriff it
early next week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#pullrequestreview-578520476,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAB2JRZF773L2CUC23ITS4GGWHANCNFSM4UXDVOQA
.

My main concern is making sure durable objects users can try it out.  If
we're doing an RC anyway, I don't see how doing 2 separate RCs is going to
make things easier to roll back than doing 1 RC.  From my perspective we
can keep it in RC until durable objects GA if we have to, as long as
external users have an easy way to get a binary.  I don't think we have the
bandwidth to do any major wrangler refactors that would conflict with it in
the meantime.
On Thu, Jan 28, 2021 at 10:33 AM Natalie Davidson<EMAIL_ADDRESS>wrote:

@nataliescottdavidson commented on this pull request.
This looks good to me. My main concern is how we are going to release it
without breaking anything. Wrangler has minimal test coverage. It looks
like you've done a lot of good manual testing @xortive
https://github.com/xortive, but I can't help worrying that some edge
case is going to break. I'm in favor of doing an RC and asking internal
users to test things out before we go to a full release.
I think that the modules and DO changes should be separate. This will make
things easier in case we have to roll back. I remember that @koeninger
https://github.com/koeninger had thoughts on this from the last
wrangler contributors meeting.
Thanks for the great work on this @xortive https://github.com/xortive.
I'll approve once we have a release plan in place, you and I can sheriff it
early next week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#pullrequestreview-578520476,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAB2JRZF773L2CUC23ITS4GGWHANCNFSM4UXDVOQA
.

I was hoping to avoid this rabbithole, but I realize now we may need to support ignoring of files in the upload directory... rollup for example will not allow you to output sourcemaps to a different directory than the bundle (I tried the sourcemapFile option to change where it's outputted, but it doesn't seem to work?)
To be clear, the issue here is not that it won't work, it's that unneeded files in the upload directory would still count against the worker size limit.
I'm content to just hardcode ignoring *.map, but the file walker for the upload directory already supports ignore globs, we just need to pass them in and provide a convenient default, so leaning towards making it configurable.

I was hoping to avoid this rabbithole, but I realize now we may need to support ignoring of files in the upload directory... rollup for example will not allow you to output sourcemaps to a different directory than the bundle (I tried the sourcemapFile option to change where it's outputted, but it doesn't seem to work?)
To be clear, the issue here is not that it won't work, it's that unneeded files in the upload directory would still count against the worker size limit.
I'm content to just hardcode ignoring *.map, but the file walker for the upload directory already supports ignore globs, we just need to pass them in and provide a convenient default, so leaning towards making it configurable.

I'd just hardcode *.map for now and make it configurable in another PR.

I thought you could configure rollup to not output sourcemaps.
Worst case scenario people can script mv commands to copy only the files
they care about into the upload directory.
If you're going down the route of configurable ignore, I definitely
wouldn't hardcode any defaults.
On Mon, Feb 1, 2021 at 12:56 PM Matt<EMAIL_ADDRESS>wrote:

I was hoping to avoid this rabbithole, but I realize now we may need to
support ignoring of files in the upload directory... rollup for example
will not allow you to output sourcemaps to a different directory than the
bundle (I tried the sourcemapFile option to change where it's outputted,
but it doesn't seem to work?)
To be clear, the issue here is not that it won't work, it's that unneeded
files in the upload directory would still count against the worker size
limit.
I'm content to just hardcode ignoring *.map, but the file walker for the
upload directory already supports ignore globs, we just need to pass them
in and provide a convenient default, so leaning towards making it
configurable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/wrangler/pull/1677#issuecomment-771079718,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYABZVU2K6HLORRWGHKY3S432NXANCNFSM4UXDVOQA
.

pushed up a fix so workers site projects can access durable object namespaces using the namespace name (which requires running some pre-upload tasks)

Is there an example toml file on how to use durable objects?

Is there an example toml file on how to use durable objects?

We'll be releasing this PR as part of a release candidate soon, and we'll publish some templates + docs for it as well then.

Some testers ran into a bug where the verify_config step fails when the upload directory has not been created yet. Will push a fix to push verifying the upload directory to after the build, instead of before.

going to open a new PR with just the durable object changes. will be merging the modules + toml-edit changes into a release branch for the rc


Restrict URL escaping to object names only

Hi Marius,
I've changed the way how the escaping works.
It first recognizes the object names inside the brackets and quotes then doubles the quotes afterwards.
@tombrzy will do some more testing, and we will let you know the results.
Cheers,
Adam

@ducklingasa and @tombrzy
Thanks guys! Will merge in the changes and add a few test cases to it.


MSG100 cloud mode support

Thanks for the project. Would love support for the msg100.

@sdast9
Please try the latest beta of homebridge-meross plugin. If you’re still using homebridge-meross-cloud then you’ll need to switch over.

Progress... but it had my garage as "open" in homekit when it was not. When I tried opening it within homekit, I got the following error:
[7/27/2021, 9:55:01 AM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 9:55:01 AM] [Meross] ✓ Setup complete.
[7/27/2021, 9:55:28 AM] [homebridge-meross] This plugin threw an error from the characteristic 'Target Door State': Unhandled error thrown inside write handler for characteristic: this.internalCloudTargetUpdate is not a function. See https://git.io/JtMGR for more info.

@sdast9 please try beta.9 just pushed!

More progress... again, it doesn't identify the state of the door correctly (i.e. open or closed). However, I was able to get the door to open and close within homekit! Upon opening and closing, homekit stays in a constant opening/closing state with the swirling star in the upper righthand corner of the icon for the device. It never gets to a point that shows the door as closed or open. In addition, if the state of the garage door is changed outside of homekit, there is no acknowledgement of that within homekit. Getting there!

Sounds like the issue is with the polling.
Do you have any warnings (yellow text) in the logs from the garage device polling in the background?
Have you configured a custom cloud polling rate or using the default?
Also for good measure, use the plugin ui to configure a “garage door open time” for your device if you haven’t already

I was using default settings. This was when my wife opened and closed the garage door within the meross app, not homekit.
[7/27/2021, 11:05:22 AM] [Meross] [Sarah’s Garage Door Opener] real-time garage cloud updates not supported.
[7/27/2021, 11:05:22 AM] [Meross] [Sarah’s Garage Door Opener] please post the below message in a github issue.
[7/27/2021, 11:05:22 AM] [Meross] [Sarah’s Garage Door Opener] {"state":[{"open":1,"lmTime":1627398322,"channel":0}]}.
[7/27/2021, 11:06:22 AM] [Meross] [Sarah’s Garage Door Opener] real-time garage cloud updates not supported.
[7/27/2021, 11:06:22 AM] [Meross] [Sarah’s Garage Door Opener] please post the below message in a github issue.
[7/27/2021, 11:06:22 AM] [Meross] [Sarah’s Garage Door Opener] {"state":[{"open":0,"lmTime":1627398381,"channel":0}]}.

@sdast9
Actually I think the issue here is because for cloud devices the default polling is every 5 minutes. Hadn’t thought of this. It would seem extreme to reduce this to a much lower value just to check for status, when in real life it probably opens/closes a small number of times a day.
This is a good opportunity for me to implement the real-time status updates for garages.
I’ll get back to you with another beta

@sdast9 can you try beta 10?

Even closer now... No yellow status updates, so I guess that is good. Homekit initially was out of phase with the garage door (i.e. it said it was open when it was closed). I had to tell it to close and then open for them to be in sync. Once I did, i opened the garage door in homekit and the state read "open" immediately instead of "opening". The close phase worked flawlessly. It said it was closing and updated to closed when the door shut. The second time I did it, the door opened but the icon hung on say "opening" with the swirling star again. Closing worked flawlessly again. When I open the door without homekit, homekit says it is closing and hangs there. If I tap on the icon in homekit, it changes to correctly say "open" and does nothing. If I hit it again, it starts the closing sequence flawlessly. Hope the helps. Let me know if you want me to test any other situations.

It would help to see a full cycle of logs, I mean:
With the garage door closed, with plugin debug ON so I can see the initial polling data, restart the plugin, then open the door, and close it once opened (both by homekit). Then open the door again via meross app and close again via meross app.
If this is possible?  They already think that. Ok, I did everything (I think), but I cannot find the location of the log file. Any suggestions?

The logic I wrote for the previous version needs to be optimized, but I don't think it's possible to reflect the real status of the door (especially for opening or closing statuses), because the only thing we are sure is the closed status.
We can guess it's open if it isn't closed for more than the garage door open/close time , but it's really hard to guess if it's opening or closing if we interrupt the opener in the middle.

Agreed. I looks like the meross app just switches the status fron opening to open after a specific time.

Agreed. It looks like the meross app just switches the status fron opening to open after a specific time.

Yes, that's a setting in the Meross app, and I added the same setting in the plugin to estimate the open status better.

LOL. They already think that. Ok, I did everything (I think), but I cannot find the location of the log file. Any suggestions?

You can copy and paste from the homebridge UI?
On a default setup, log file is at /var/lib/homebridge/homebridge.log

Sorry. Power outage... bad timing.

Judging the status when closing is easier because the plugin in effect can wait for the 'closed' notification from meross.
Judging the status when opening is harder because as was mentioned before, the two states that meross offer are 'closed' and 'not closed'.
So the custom operation time is more useful in this case, to update the status from 'opening' to 'open' after the operation time has elapsed.
In the case that a door is manually stopped when opening or closing, I'm not sure if the plugin gets a real-time notification from meross (cloud control only). This would be useful to know for reference.

In the case that a door is manually stopped when opening or closing, I'm not sure if the plugin gets a real-time notification from meross (cloud control only). This would be useful to know for reference.

Even for Meross, they can't know the status, they can only guess, since we only have one sensor to detect it's closed or not.
I think we could do it better than Meross by adding 2 new settings, that was really my planning to optimize the logic, but I don't really have the time:

If we interrupt the door while closing, what's the expected behaviour? (In my house, it changes to opening right away)
If we interrupt the door while opening, what's the expected behaviour? (In my house, it stops in the middle, then if I trigger the opener again, it changes to closing)

Power is back but computers are rebooting. I was able to confirm that it is a timing thing for opening in meross. I opened within meross and then manually stopped it halfway. The meross app continued to say "opening" and then switched to "open" after some time. Also, it I manually open the door, the app immediately switched to "open". It does not say "opening".

I guess I was expecting something different than what was already
[7/27/2021, 12:40:20 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 12:40:20 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 12:40:20 PM] [Meross] ✓ Setup complete.
[7/27/2021, 12:40:21 PM] [Homebridge UI] Starting terminal session
[7/27/2021, 12:40:36 PM] [Homebridge UI] Terminal session ended.
[7/27/2021, 12:40:58 PM] [Meross] [Steve’s Garage Door Opener] current target [open].
[7/27/2021, 12:41:39 PM] [Meross] [Steve’s Garage Door Opener] current target [closed].
[7/27/2021, 12:41:54 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].
[7/27/2021, 12:42:05 PM] [Meross] [Steve’s Garage Door Opener] current state [open].
[7/27/2021, 12:42:41 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].
[7/27/2021, 12:42:54 PM] [Homebridge UI] Starting terminal session
[7/27/2021, 12:47:29 PM] [Homebridge UI] Terminal session ended.
[7/27/2021, 12:48:34 PM] [Homebridge UI] Starting terminal session

the latter was from before the power outage (opening and closing in homekit and then opening and closing in meross).

I don't think you have plugin debug mode on. In the plugin settings in the 'optional settings' part there is a debug setting

I see. I was putting homebridge in debug mode, didn't realize I needed to do it for the plugin. Here is the output. Note: I first opened and closed with meross and then with homkit.
[7/27/2021, 1:21:54 PM] [Meross] [Sarah’s Garage Door Opener] has been added to Homebridge.
[7/27/2021, 1:21:54 PM] [Homebridge UI] Starting terminal session
[7/27/2021, 1:21:54 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 1:21:54 PM] [Meross] [Steve’s Garage Door Opener] has been added to Homebridge.
[7/27/2021, 1:21:54 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 1:21:54 PM] [Meross] ✓ Setup complete.
[7/27/2021, 1:21:54 PM] [Meross] [Sarah’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 1:21:54 PM] [Meross] [Steve’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 1:21:54 PM] [Meross] [Sarah’s Garage Door Opener] incoming poll: {"header":{"messageId":"94a366a53d7b0ff7fbda594649562a6e","namespace":"Appliance.GarageDoor.State","method":"GETACK","payloadVersion":1,"from":"/appliance/2009115750695736100748e1e9330662/publish","timestamp":1627406514,"timestampMs":550,"sign":"bfe3a515ae6f7d6b94e44da18f99bd06"},"payload":{"state":{"channel":0,"open":0,"lmTime":1627400625}}}.
[7/27/2021, 1:21:54 PM] [Meross] [Steve’s Garage Door Opener] incoming poll: {"header":{"messageId":"36dd6313367054fe116dd0d38561605f","namespace":"Appliance.GarageDoor.State","method":"GETACK","payloadVersion":1,"from":"/appliance/2009112225282836100748e1e9330c79/publish","timestamp":1627406514,"timestampMs":847,"sign":"c84de2bd8104601e7e9f93a61ef99014"},"payload":{"state":{"channel":0,"open":0,"lmTime":1627405706}}}.
[7/27/2021, 1:23:47 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"triggerSrc":"iOS","timestampMs":989,"timestamp":1627406627,"sign":"21e5890b05cc6357c84437f06ebd03ea","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"0351d8f52ce5cb4587cd2a516ed21fe9","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":1,"lmTime":1627406627,"channel":0}]}}.
[7/27/2021, 1:24:30 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"triggerSrc":"iOS","timestampMs":75,"timestamp":1627406670,"sign":"8bac4cb1d22cead9fab7bb0e7f81b476","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"bfc40d770f81566b7f64631692f777d3","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":0,"lmTime":1627406669,"channel":0}]}}.
[7/27/2021, 1:24:30 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].
[7/27/2021, 1:24:49 PM] [Meross] [Steve’s Garage Door Opener] current target [open].
[7/27/2021, 1:24:51 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":224,"timestamp":1627406690,"sign":"38b81920694ab4d5afe8d9ac6808ab1b","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"7f40f06a0ba2e23a5bdb029de3ac56e1","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":1,"lmTime":1627406690,"channel":0}]}}.
[7/27/2021, 1:24:51 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":224,"timestamp":1627406690,"sign":"38b81920694ab4d5afe8d9ac6808ab1b","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"7f40f06a0ba2e23a5bdb029de3ac56e1","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":1,"lmTime":1627406690,"channel":0}]}}.
[7/27/2021, 1:25:18 PM] [Meross] [Steve’s Garage Door Opener] current target [closed].
[7/27/2021, 1:25:33 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":212,"timestamp":1627406732,"sign":"d3bd2e7c0ab623096eecd4e133ea15cd","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"c10e03d88936b4526fc4c4aa887c92fb","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":0,"lmTime":1627406732,"channel":0}]}}.
[7/27/2021, 1:25:33 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].
[7/27/2021, 1:25:33 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":212,"timestamp":1627406732,"sign":"d3bd2e7c0ab623096eecd4e133ea15cd","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"c10e03d88936b4526fc4c4aa887c92fb","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":0,"lmTime":1627406732,"channel":0}]}}.

Could you do me another favour, and put the device into local mode by changing 'connection' to local in the plugin settings and supplying the device IP? And do the same open and close procedure whilst it's in local mode?

The payloads between cloud and local mode normally match for devices. However the payloads you have posted for the garage in cloud mode do not match how the plugin checks for local payloads. If that makes sense. I would like to see the logging for local mode to see the difference (if exists) between the payloads for cloud mode and for local mode.

Sorry- in a meeting. Will test this in a bit.

Not sure I got everything that you needed. I did one open and close through homekit and one through meross. Local seems to work flawlessly for what that is worth to you.
homebridgelog.txt

@sdast9 could you now update to 6.0.0-beta.16, go back to using cloud connection for one of the garages, and get me the data for the initial poll that happens when the device initialises?
You are helping me out a lot here so thank you, sorry if it feels like we are going in circles

initial poll will look something like this:
[27/07/2021, 21:02:48] [Meross] [Device] initialised with id [200911549315412%%%%] [local].
[27/07/2021, 21:02:48] [Meross] ✓ Setup complete.
[27/07/2021, 21:02:48] [Meross] [Device] incoming poll: {"header":{"messageId":"64%%%%","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/20091154931%%%/publish","timestamp":1627%%,"timestampMs":173,"sign":"05867%%%%762ab8641"},"payload":{"all":{"system":{"hardware":{"type":"mss310","subType":"un","version":"2.0.0","chipType":"mt7682","uuid":"20091154931541%%%%","macAddress":"48:e1:e%%%0"},"firmware":{"version":"2.1.16","compileTime":"2020/09/28 15:51:07 GMT +08:00","wifiMac":"18:90:8&%%%6","innerIp":"192.%%%","server":"mqtt-eu.meross.com","port":443,"userId":1472097},"time":{"timestamp":162%%7,"timezone":"Europe/London","timeRule":[[1616893200,3600,1],[1635642000,0,0],[1648342800,3600,1],[1667091600,0,0],[1679792400,3600,1],[1698541200,0,0],[1711846800,3600,1],[1729990800,0,0],[1743296400,3600,1],[1761440400,0,0],[1774746000,3600,1],[1792890000,0,0],[1806195600,3600,1],[1824944400,0,0],[1837645200,3600,1],[1856394000,0,0],[1869094800,3600,1],[1887843600,0,0],[1901149200,3600,1],[1919293200,0,0]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":1627385500}],"triggerx":[],"timerx":[]}}}}.

[7/27/2021, 4:52:12 PM] [Meross] [steve's local] has been removed from Homebridge.
[7/27/2021, 4:52:12 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 4:52:12 PM] [Meross] [Steve’s Garage Door Opener] has been added to Homebridge.
[7/27/2021, 4:52:12 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 4:52:12 PM] [Meross] ✓ Setup complete.
[7/27/2021, 4:52:12 PM] [Meross] [Sarah’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 4:52:12 PM] [Meross] [Steve’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 4:52:13 PM] [Meross] [Sarah’s Garage Door Opener] incoming poll: {"header":{"messageId":"cd3b67e112cadc8123002641ae93074c","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009115750695736100748e1e9330662/publish","timestamp":1627419133,"timestampMs":263,"sign":"c4f37e822863da306e26ef0b13db2eb8"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009115750695736100748e1e9330662","macAddress":"48:e1:e9:33:06:62"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627419133,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627410077}]}}}}.
[7/27/2021, 4:52:13 PM] [Meross] [Steve’s Garage Door Opener] incoming poll: {"header":{"messageId":"bd0950e2a141a1932550b3f14b344442","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009112225282836100748e1e9330c79/publish","timestamp":1627419132,"timestampMs":622,"sign":"09606074b75b79b25b5ebb1a35f026f1"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009112225282836100748e1e9330c79","macAddress":"48:e1:e9:33:0c:79"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627419132,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627415148}]}}}}.
[7/27/2021, 4:52:13 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].

@sdast9 could you now update to 6.0.0-beta.16, go back to using cloud connection for one of the garages, and get me the data for the initial poll that happens when the device initialises?
You are helping me out a lot here so thank you, sorry if it feels like we are going in circles

No worries. Happy to help. I appreciate you doing all of the troubleshooting and coding.

Can anyone try beta 17 with the garage?
Cloud or local, shouldn't matter which protocol.

on cloud, we took a step backwards from a functionality standpoint.
7/27/2021, 6:33:52 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 6:33:52 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 6:33:52 PM] [Meross] ✓ Setup complete.
[7/27/2021, 6:33:53 PM] [Meross] [Sarah’s Garage Door Opener] failed to refresh status as Cannot read property 'sendMQTT' of undefined at connectionMQTT.publishMessage (/usr/local/lib/node_modules/homebridge-meross/lib/connection/mqtt.js:173:53).
[7/27/2021, 6:33:53 PM] [Meross] [Steve’s Garage Door Opener] failed to refresh status as Cannot read property 'sendMQTT' of undefined at connectionMQTT.publishMessage (/usr/local/lib/node_modules/homebridge-meross/lib/connection/mqtt.js:173:53).
[7/27/2021, 6:33:53 PM] [Meross] [Steve’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 6:33:53 PM] [Meross] [Sarah’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 6:34:38 PM] [Meross] [Steve’s Garage Door Opener] sending update failed as Cannot read property 'sendMQTT' of undefined at connectionMQTT.publishMessage (/usr/local/lib/node_modules/homebridge-meross/lib/connection/mqtt.js:173:53).
[7/27/2021, 6:34:38 PM] [homebridge-meross] This plugin generated a warning from the characteristic 'Target Position': Characteristic not in required or optional characteristic section for service GarageDoorOpener. Adding anyway.. See https://git.io/JtMGR for more info.
[7/27/2021, 6:34:57 PM] [Meross] [Steve’s Garage Door Opener] sending update failed as Cannot read property 'sendMQTT' of undefined at connectionMQTT.publishMessage (/usr/local/lib/node_modules/homebridge-meross/lib/connection/mqtt.js:173:53).

homekit fails to open the door and almost immediately goes form a state of opening to closing and hangs. No movement from the door and never says closed.

6.0.0-beta.19 any better? two steps forward and one step back!

So close!!! opening was great. it changed from opening to open appropriately.  Closing closed the door but homekit never changed from closing to closed like it was doing nicely before.
[7/27/2021, 6:48:15 PM] [Meross] Meross Key: 17c20aca593425175794eabac1384242
[7/27/2021, 6:48:15 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 6:48:15 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 6:48:15 PM] [Meross] ✓ Setup complete.
[7/27/2021, 6:48:15 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"1faedd2762a670de230a9e47538ad29b","method":"GET","namespace":"Appliance.System.All","payloadVersion":1,"sign":"e8f668852f04cee2ab1eaf601bcc1092","timestamp":1627426096},"payload":{}}.
[7/27/2021, 6:48:15 PM] [Meross] [Sarah’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-ab09802aa746f0a1a9e8f24dcea208bd/subscribe","messageId":"13bf86f69e1c33b3b8cf617357a142d6","method":"GET","namespace":"Appliance.System.All","payloadVersion":1,"sign":"773e65b52175df1899f23d9f64fab347","timestamp":1627426096},"payload":{}}.
[7/27/2021, 6:48:15 PM] [Meross] [Steve’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 6:48:15 PM] [Meross] [Sarah’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 6:48:16 PM] [Meross] [Steve’s Garage Door Opener] incoming poll: {"header":{"messageId":"1faedd2762a670de230a9e47538ad29b","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009112225282836100748e1e9330c79/publish","timestamp":1627426095,"timestampMs":879,"sign":"499182eee35a6ecdf2d71924b236b110"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009112225282836100748e1e9330c79","macAddress":"48:e1:e9:33:0c:79"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627426095,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627419511}]}}}}.
[7/27/2021, 6:48:16 PM] [Meross] [Steve’s Garage Door Opener] target state [closed].
[7/27/2021, 6:48:16 PM] [Meross] [Steve’s Garage Door Opener] current state [closed].
[7/27/2021, 6:48:16 PM] [Meross] [Sarah’s Garage Door Opener] incoming poll: {"header":{"messageId":"13bf86f69e1c33b3b8cf617357a142d6","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009115750695736100748e1e9330662/publish","timestamp":1627426095,"timestampMs":514,"sign":"253d3683297afe893ce712a085150c24"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009115750695736100748e1e9330662","macAddress":"48:e1:e9:33:06:62"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627426095,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627410077}]}}}}.
[7/27/2021, 6:48:44 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"47a77817e6b210f5c137a918697929c2","method":"SET","namespace":"Appliance.GarageDoor.State","payloadVersion":1,"sign":"02dc8ddcee1c8212707d0b725a1f3b0a","timestamp":1627426125},"payload":{"state":{"channel":0,"open":1,"uuid":"2009112225282836100748e1e9330c79"}}}.
[7/27/2021, 6:48:44 PM] [Meross] [open] current target [%s].
[7/27/2021, 6:48:44 PM] [Meross] [Steve’s Garage Door Opener] current state [opening].
[7/27/2021, 6:48:46 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":687,"timestamp":1627426126,"sign":"d5bbbe104669c5ef98a6475a08586081","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"ea41a895d68231c4407b5f1327c64f29","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":1,"lmTime":1627426126,"channel":0}]}}.
[7/27/2021, 6:48:46 PM] [Meross] [Steve’s Garage Door Opener] failed to refresh status as Cannot read property 'digest' of undefined at deviceGarage.externalUpdate (/usr/local/lib/node_modules/homebridge-meross/lib/device/garage.js:381:33).
[7/27/2021, 6:49:04 PM] [Meross] [Steve’s Garage Door Opener] current state [open].
[7/27/2021, 6:49:11 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"f12cbbaa3161f2ff4241b42bbf961ba4","method":"SET","namespace":"Appliance.GarageDoor.State","payloadVersion":1,"sign":"df9e5114309ab087859ea43176b0fe5b","timestamp":1627426151},"payload":{"state":{"channel":0,"open":0,"uuid":"2009112225282836100748e1e9330c79"}}}.
[7/27/2021, 6:49:11 PM] [Meross] [closed] current target [%s].
[7/27/2021, 6:49:11 PM] [Meross] [Steve’s Garage Door Opener] current state [closing].
[7/27/2021, 6:49:25 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":816,"timestamp":1627426165,"sign":"312b10f839096744db7eac3b4149e3e5","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"431ce1f81c7f354da4f24d0a936fafcd","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":0,"lmTime":1627426165,"channel":0}]}}.
[7/27/2021, 6:49:25 PM] [Meross] [Steve’s Garage Door Opener] failed to refresh status as Cannot read property 'digest' of undefined at deviceGarage.externalUpdate (/usr/local/lib/node_modules/homebridge-meross/lib/device/garage.js:381:33).

Lol! It eventually did change to closed after I tried opening/closing again. Again, opening worked perfectly, but when closing it had the wrong state (open) for the longest time and then switched to close after about 10 minutes or so. The door responded immediately though.

And better with 6.0.0-beta.20?

Will test in 20 minutes

homekit still doesn't switched to closed. Door goes down but state remains on closing with spinning star. Note that my door finished closed put the log has the state as open at the end.
[7/27/2021, 7:16:31 PM] [Meross] [Sarah’s Garage Door Opener] initialised with id [2009115750695736100748e1e9330662] [cloud].
[7/27/2021, 7:16:31 PM] [Meross] [Steve’s Garage Door Opener] initialised with id [2009112225282836100748e1e9330c79] [cloud].
[7/27/2021, 7:16:31 PM] [Meross] ✓ Setup complete.
[7/27/2021, 7:16:31 PM] [Meross] [Sarah’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-ab09802aa746f0a1a9e8f24dcea208bd/subscribe","messageId":"ead2451a661f70038d4310d78c89b5df","method":"GET","namespace":"Appliance.System.All","payloadVersion":1,"sign":"8757852f118a027d187c9531a9ee627c","timestamp":1627427792},"payload":{}}.
[7/27/2021, 7:16:31 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"81c593ebd216945031607b95e10b60c2","method":"GET","namespace":"Appliance.System.All","payloadVersion":1,"sign":"f0897f03cca722a6a41632e15494acf0","timestamp":1627427792},"payload":{}}.
[7/27/2021, 7:16:31 PM] [Meross] [Steve’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 7:16:31 PM] [Meross] [Sarah’s Garage Door Opener] mqtt subscribe complete.
[7/27/2021, 7:16:31 PM] [Meross] [Steve’s Garage Door Opener] incoming poll: {"header":{"messageId":"81c593ebd216945031607b95e10b60c2","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009112225282836100748e1e9330c79/publish","timestamp":1627427791,"timestampMs":509,"sign":"437ce68390747a9e0615b3a10e26bc90"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009112225282836100748e1e9330c79","macAddress":"48:e1:e9:33:0c:79"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627427791,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627426404}]}}}}.
[7/27/2021, 7:16:31 PM] [Meross] [Sarah’s Garage Door Opener] incoming poll: {"header":{"messageId":"ead2451a661f70038d4310d78c89b5df","namespace":"Appliance.System.All","method":"GETACK","payloadVersion":1,"from":"/appliance/2009115750695736100748e1e9330662/publish","timestamp":1627427791,"timestampMs":125,"sign":"cad44d2cd29270b2a520891d29249b50"},"payload":{"all":{"system":{"hardware":{"type":"msg100","subType":"us","version":"3.5.0","chipType":"mt7682","uuid":"2009115750695736100748e1e9330662","macAddress":"48:e1:e9:33:06:62"},"firmware":{"version":"3.2.3","compileTime":"2021/06/16 15:35:05 GMT +08:00","encrypt":1,"wifiMac":"18:90:88:77:cf:66","innerIp":"<IP_ADDRESS>","server":"mqtt-us.meross.com","port":443,"userId":1052832},"time":{"timestamp":1627427791,"timezone":"America/New_York","timeRule":[[1604210400,-18000,0],[1615705200,-14400,1],[1636264800,-18000,0],[1647154800,-14400,1],[1667714400,-18000,0],[1678604400,-14400,1],[1699164000,-18000,0],[1710054000,-14400,1],[1730613600,-18000,0],[1741503600,-14400,1],[1762063200,-18000,0],[1772953200,-14400,1],[1793512800,-18000,0],[1805007600,-14400,1],[1825567200,-18000,0],[1836457200,-14400,1],[1857016800,-18000,0],[1867906800,-14400,1],[1888466400,-18000,0],[1899356400,-14400,1]]},"online":{"status":1}},"digest":{"togglex":[{"channel":0,"onoff":1,"lmTime":0}],"triggerx":[{"channel":0,"id":"1111111111111111","count":1}],"timerx":[],"garageDoor":[{"channel":0,"open":0,"lmTime":1627410077}]}}}}.
[7/27/2021, 7:16:57 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"aa4a0b351146081bb67af00ed9db74f7","method":"SET","namespace":"Appliance.GarageDoor.State","payloadVersion":1,"sign":"9769ca16f88d8b7be9e9456fe41b0350","timestamp":1627427817},"payload":{"state":{"channel":0,"open":1,"uuid":"2009112225282836100748e1e9330c79"}}}.
[7/27/2021, 7:16:57 PM] [Meross] [Steve’s Garage Door Opener] current target [open].
[7/27/2021, 7:16:57 PM] [Meross] [Steve’s Garage Door Opener] current state [opening].
[7/27/2021, 7:16:59 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":815,"timestamp":1627427818,"sign":"81690b14138f2f5e7375afdf85dcb8e3","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"a243578497cd402fb456398c2f2df9dd","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":1,"lmTime":1627427818,"channel":0}]}}.
[7/27/2021, 7:17:17 PM] [Meross] [Steve’s Garage Door Opener] current state [open].
[7/27/2021, 7:17:25 PM] [Meross] [Steve’s Garage Door Opener] sending mqtt: {"header":{"from":"/app/1052832-85495f44ae2e22540d168ce3407b5231/subscribe","messageId":"7c685a328ce540dc52b8c128ca39bf39","method":"SET","namespace":"Appliance.GarageDoor.State","payloadVersion":1,"sign":"23eb12d0d5dde513c810c0bdce5de050","timestamp":1627427845},"payload":{"state":{"channel":0,"open":0,"uuid":"2009112225282836100748e1e9330c79"}}}.
[7/27/2021, 7:17:25 PM] [Meross] [Steve’s Garage Door Opener] current target [closed].
[7/27/2021, 7:17:25 PM] [Meross] [Steve’s Garage Door Opener] current state [closing].
[7/27/2021, 7:17:40 PM] [Meross] [Steve’s Garage Door Opener] incoming mqtt [Appliance.GarageDoor.State]: {"header":{"timestampMs":963,"timestamp":1627427860,"sign":"498b26d2ed93f633b661421f65b59563","payloadVersion":1,"namespace":"Appliance.GarageDoor.State","method":"PUSH","messageId":"fef4031fd0780f8479d7cbae8ee04a4e","from":"/appliance/2009112225282836100748e1e9330c79/publish"},"payload":{"state":[{"open":0,"lmTime":1627427860,"channel":0}]}}.
[7/27/2021, 7:17:40 PM] [Meross] [Steve’s Garage Door Opener] current state [open].

In my old implementation, while it's closing, I will call the status every one second to get the status update.

@sdast9 i had released beta22 since!

The 22nd time was the charm!!! Congrats. I will continue to test, but it passed all of my earlier tests. Nice work!

@CocoaBob thevway i have rewritten it for now:
when opened from homekit, if after the operation time the state is still opening then it will be updated to open
when closed from homekit, the plugin will mark as closing then wait for a “closed” notification before marking as closed. if after the operation time plus an extra 15 seconds the garage is still “closing” then the garage will then be marked as open again.
the cloud control statuses are in real time, and local polling is every 5 seconds, the garage should mark as closed when it, or just after, it has physically closed

After updating to v6.0.0, my old MSG100 works (in Local mode), thanks. But the status updating is slow (no matter from which status to which status), I think it's due to the 5s updating interval? Or due to some heavy traffic?
And interestingly, the official HomeKit version of MSG100 (the newer model) doesn't work very well now, it's always showing Obstructed status in HomeKit 😓 Maybe I should move it to Homebridge too...😂

But the status updating is slow (no matter from which status to which status), I think it's due to the 5s updating interval? Or due to some heavy traffic?

Be sure to also test the timings from the Homebridge UI accessories page. This will give a better measure on what the plugin is doing. Sometimes there can be delays between homebridge and home app updating, sometimes the home app won't reflect new status if the accessory is already open on your screen (simply switching room or reopening the home app can refresh this). The Homebridge UI accessories page will update straight away when the plugin updates the state of an accessory.

Obstructed issue is solved by increasing the operation time in Meross app.

The plugin accessory should never be marked as obstruction detected now, as I do not use this characteristic.

Oh, just noticed one issue, the status in HomeKit was no response (I don't know why)

The plugin only will mark the accessory as no response for a couple of seconds if sending an update command to it fails for any reason. Best place to check for error messages in the logs.
The home app may mark an accessory as no response if there is a communication failure between home app and homebridge (for example a home hub not working, or local wifi issues). In this case nothing will appear in the logs since it is out of the plugin scope.
Hope this helps, to anyone, to help debug any problems that may crop up!

Just to be sure: this works on the latest FW of the msg100? I downgraded the msg100 and am using version 3.5 of this plugin

Just to be sure: this works on the latest FW of the msg100? I downgraded the msg100 and am using version 3.5 of this plugin

@Frankdoc Yes, I didn't downgrade mine, it works  now, but still keep in mind that they may break it at any time in the future.

I believe it was using the static messageId, timestamp and sign that was causing it to not work. Now these are generated by the plugin from the user key, I assume this is how the Meross app does it too. Seems to work on the latest firmware of MSG100 (and 200)

Would like to reopen the discussion to the "opening" and "closing" issue. Latest Version "homebridge-meross v6.9.2" and when I open the garage door through a regular switch the state keeps on "opening" instead of "open".

Would like to reopen the discussion to the "opening" and "closing" issue. Latest Version "homebridge-meross v6.9.2" and when I open the garage door through a regular switch the state keeps on "opening" instead of "open".
Edit: Same for closing obviously

Hi, which garage device model do you have? When you say through a regular switch do you mean using the home app to control the device?

I think he was talking about a physical opener remote.

I think he was talking about a physical opener remote.

This is what i want to figure out, as there is actually nowhere at all in the code that updates the status to “opening/closing”.
when controlled externally, the plugin directly updates to open/closed

Would like to reopen the discussion to the "opening" and "closing" issue. Latest Version "homebridge-meross v6.9.2" and when I open the garage door through a regular switch the state keeps on "opening" instead of "open".
Edit: Same for closing obviously

Hi, which garage device model do you have? When you say through a regular switch do you mean using the home app to control the device?

MSG100 non native HomeKit version.

I think he was talking about a physical opener remote.

Yes 👍 it is physically mounted to my wall - yeah thats a thing 😄

@christiantschoerner please can you put the plugin into debug mode and obtain the logs that appear when you use the wall switch to open or close the garage?

Sorry, maybe a totally superfluous question but unfortunately I can't find anything about it.
I have an MSG100 and would like to install the plugin. It only asks for the Meross Cloud username and password during installation. It also wants to know the name and the UUID under "Garage Devices".
This is exactly my question: Where do I get the UUID?

Sorry, maybe a totally superfluous question but unfortunately I can't find anything about it.
I have an MSG100 and would like to install the plugin. It only asks for the Meross Cloud username and password during installation. It also wants to know the name and the UUID under "Garage Devices".
This is exactly my question: Where do I get the UUID?

The uuid is only needed in the configuration when you want to customise any options related to this device. It can be found in the homebridge ui on the “my devices” tab, and also in the homebridge log when the plugin initialises.

@Eron4711 You can also get it in HTTP Catcher from Meross app's login response and when Decrypt HTTPS Traffic is turned on (it's a paid feature).


Restreamer Settings "Check for updates" not aligned with documentation

Check the image, in the Restreamer UI Setting "Check for updates" there is a link to documentation that says "automatic updates".
It's not clear if this setting is just to show if there are new versions or to auto update like the documentation specifies.
I think it's just to check, as it didn't update automatically. So would be nice to fix the documentation.

Thanks for the hint. This has been fixed in the documentation: https://docs.datarhei.com/restreamer/installing/update


Update catalan messages.po

Another batch, take a look please @jordimas @darccio @surfdude29 @rortan134

Thank you very much @surfdude29


BSAPI-24: Developed working code for comment feature

Very simple feature to implement, basically the same as the Rating entity.


Smart quotes change 1.55 to 1.57 breaks Deliverfile

I just updated fastlane from 1.55 to 1.57 and now I get this error I have never seen before:
[11:25:56]: ---------------------
[11:25:56]: --- Step: deliver ---
[11:25:56]: ---------------------
[11:25:56]: Your Deliverfile has had smart quotes sanitised. To avoid issues in the future, you should not use TextEdit for editing it. If you are not using TextEdit, you should turn off smart quotes in your editor of choice.

Sanitizing these quotes out completely breaks my Deliverfile because I have smart quotes inside my app descriptions to do stuff like:
description( "en-US" => "“Best app ever!” - A. Customer")

“Best app ever!” - A. Customer

I wasn't getting this behavior earlier this week but that quote sanitizer code in fast_file.rb seems to be pretty old (Sept '15?) - any ideas what could be causing this now? I don't think smart quotes should be scrubbed out. I'll try rolling back versions as soon as I figure out how to do that :)

Interesting! I'd recommend not storing the actual metadata (e.g. description) in your Deliverfile, instead put it into the metadata folder which is created by deliver for you :+1:

We generate a Deliverfile "on-the-fly" during our build process. It's more of a build artifact for us. We used to write our data out to all the various metadata files but maintaining all those little files was bothersome. I guess I'll revert to that if I must - but I'll look around a bit more first. Thanks!

I have "fixed" this by using Ruby alternate quotes in our tool that creates the Deliverfile like this:
description( "en-US" => %q^“Best app ever!” - A. Customer^)
This ends up with standard quotes in our description rather than the original smart quotes - but it works. After working on this - I really think that fastlane should not be "helping me" by modifying any input / Deliverfile with smart quotes. However, since that's an opinion and not a Pull Request - I'll move on for now :smiley:  Thanks!

Awesome, thanks @RocketPop :+1:


Change engine version to >16

Hello,
This PR address the issue #64 and also updates some dependencies
Changes:

Remove @types/change-case dep, not necessary anymore
Update async and ejs due to vulnerabilities (npm audit fix)
Update TypeScript minor version

Thank you @HeavenVolkoff


Easy rule creation from recent downloads

Hi!
There's a feature I'd love to see in RegExp Download Organizer.
Currently, adding a new rule takes a bit of trial and error, and it's not accessible to everyone. That's why I'd like rule creation from recent downloads to be integrated to this extension. This feature could make adding a rule as simple as clicking three buttons!
Here is what it could look like in practice.

We could add a new tab called "Recent downloads" on the right, next to "Help", "Changelog" and "About". This tab would be the leftmost and the default tab.
In this tab, there would be a list of the (for example) 15 most recent downloads.
Next to each filename, there would be the name of the rule that it triggers, and if there's none, a "+" button.
Clicking the "+" button (First click!) would open a dialog to add a new rule based on the file. There would be several options like "match files downloaded from the same host (drive.google.com)", "match files downloaded from the same base domain (google.com)", "match files with the same extension", and "match files with the same filetype (image/jpeg)".
Then, after selecting one or multiple options (Second click!), one could click the "Confirm" button (Third click!)
And then it's done! In case the user wants to make adjustments, it's probably best to make the newly added rule focused and open.

Implementing this feature will probably be quite a bit of work, but I really hope someone considers implementing it!
Remark: an alternative to using a dialog would be to create a new empty rule, then prefill everything with informations about the file and its download URLs. Then the user can just remove whatever they don't need.

Please like this issue if you would like this feature to be implemented! Who knows, this might just be the encouragement a roving coder needs to get their hands dirty 😉


fix: remove scarf redirect from containers images

closes #1431

scarf is still present is the currently released KLT 0.2.3 helm chart (which is released with KLT 0.7.1), so maybe we should do a new release soon?


Is it possible to flip schematics upside down?

I've tried for like 20 mins and I can't get it to flip upside down. any ideas

You should just need to make sure that the text next to "flip" is set to "up", and then click "fip".

nope, when I click flip while it's set to "up", nothing happens

Does the button become red after you click it? You have to hold shift to force a flip operation, by default it only allows a safe flip operation.


Unit test for multi-node processing

We should have a unit test comparing the result of 1- and N-node processing.

mentioned & moved issue into #82


[release-4.12][manual] tests: minimize deps on k8s.io/kubernetes

almost all the dependencies can be fulfilled by
supported library packages, so let's use them.
The last missing bits is about taints, which will
be addressed with a later PR.

manual cherry-pick of #732

/retest


Update [ChangeNow changenow.io] #exchange #memo-required GDBIXG…NO2PNY

Address: GDBIXGZ3EKI3M4DBM65ADLHVNYIOG7JXGOHW5DHUZQAXPORY3QNO2PNY
Tags: exchange memo-required
Title: ChangeNow  Domain: changenow.io
Requested by @zhidilin05

Confirmed ChangeNow exchange custodial account

We will try to verify this soon. Sometimes they are slow to respond or don't give straight forward answers.


Unable to Access Cubic Function in SimpleCrystals.jl

I was following the user defined crystal structures tutorial, and it looks like I'm unable to create the NaCl crystal structure. I'm working in VSCode using a notebook extension. Here's my attempt:
using SimpleCrystals
#import SimpleCrystals.CrystalStructures

function NaCl1(a, N::SVector{3})
    lattice = BravaisLattice(Cubic(a), Primitive())
    basis = [Atom(:Na, SVector(zero(a), zero(a), zero(a)), charge = 1.0u"q"),
             Atom(:Na, SVector(0.5*a,zero(a),0.5*a), charge = 1.0u"q"),
             Atom(:Na, SVector(zero(a), 0.5*a, 0.5*a), charge = 1.0u"q"),
             Atom(:Na, SVector(0.5*a,0.5*a,zero(a)), charge = 1.0u"q"),
             Atom(:Cl, SVector(0.5*a, zero(a), zero(a)), charge = -1.0u"q"),
             Atom(:Cl, SVector(zero(a), 0.5*a, zero(a)), charge = -1.0u"q"),
             Atom(:Cl, SVector(zero(a),zero(a),0.5*a), charge = -1.0u"q"),
             Atom(:Cl, SVector(0.5*a, 0.5*a, 0.5*a), charge = -1.0u"q")]
    return Crystal(lattice,basis,N)
end

NaCl1(0.54u"nm", SVector(3, 3, 3))

Here's the error:
UndefVarError: Cubic not defined
Stacktrace:
[1] NaCl1(a::Quantity{Float64, 𝐋, Unitful.FreeUnits{(nm,), 𝐋, nothing}}, N::SVector{3, Int64})
@ Main c:\Users\User\Desktop\tratar_dados\tutorial_julia\Tutorial crystal\jl_notebook_cell_df34fa98e69747e1a8f8a730347b8e2f_W0sZmlsZQ==.jl:5
[2] top-level scope
@ c:\Users\User\Desktop\tratar_dados\tutorial_julia\Tutorial crystal\jl_notebook_cell_df34fa98e69747e1a8f8a730347b8e2f_W0sZmlsZQ==.jl:1
Environment Details:
Julia Version: 1.9.2
SimpleCrystals.jl Version: v0.2.0
OS: Windows 11

Oh, I think I just forgot to update the example, it should be CubicLattice instead of Cubic. Let me know if that still doesn't work!

Thank you very much, it worked perfectly.
Hmm, I see. I was using the following link
https://docs.juliahub.com/General/SimpleCrystals/stable/
Indeed it's different from the other link
https://github.com/ejmeitz/SimpleCrystals.jl
I did a pretty naive research, I just googled "how to draw crystal lattices in Julia" , which lead me to the first link

If it's okay, I have one more question, but I'm not sure if I should either open a new issue or continue with this one. How do you manage to plot the unit cells on your GitHub? I'm working on my master thesis and I'm trying to display these cells also

Ah, ok. I just updated the docs too hopefully, they should match the ReadMe once those changes go live.
I rendered the images in the ReadMe inside of OVITO. The free version should let you use the OpenGL renderer. I was working on integrating this into a Julia package but for now you'll have to save the SimpleCrystals structure as an xyz file and then move it into OVITO and render the image.

Got it.
Understood, I will. Thank you once again for this great package.


sbom cannot be query directly from api.adoptium.net

Expected behaviour:
when using api.adoptium.net to query for sbom, should get correct return from swagger and using curl/wget
Observed behaviour:
on /binary endpoint
curl -iL https://api.adoptium.net/v3/binary/latest/17/ea/linux/x64/sbom/hotspot/normal/eclipse?project=jdk
HTTP/1.1 404 Not Found

on /assets endpoint
https://api.adoptium.net/v3/assets/latest/17/hotspot?architecture=x64&image_type=sbom&os=linux&vendor=eclipse
server response []
client response with all other binary_type(e.g jdk jre debugimage testimage etc) but not "sbom"
Any other comments:
The root cause probably is not in the api.adoptium.net but the metadata it uses to map from /api/v3/assets or /api/v3/binary is missing.
Suspect this is caused when we made the change from old sbom file format from tar.gz to json, which broke the function
so in the case of sbom file (e.g OpenJDK17U-sbom_x64_linux_hotspot_2022-06-10-09-44.jsons) it wont generate a metadata json file

now we have two json files generated

now release binary git repo has two json files.

issue has been resolved, finally updated pushed to production api server and everything works fine.


What about the ZendX library for php 7.3?

Hi,
Not really a bug but what about the ZendX library that contains some extras. Is there a plan
to propose a php 7.3 compatibility? Or may be nothing incompatible?
https://github.com/zendframework/zf1-extras
Thanks!

It might be ok as it is, I've never used zf1-extras. What functionality does it have that you need?
I looked and it isn't here but this might help you with other libraries https://github.com/zf1s

Thanks, i use some JQuery helpers in some old ZF projects. From some months/years i try to find a solution for an old and big project that i cannot migrate or redevelop easily. Your fork can be a good solution for the next one or two years. It give me a little more time...
Yes, i use ZendX, JQuery helpers part only:

$view->jQuery()->enable()->setLocalPath(...
$this->view->ajaxLink(...

I didn't check the code if it is 7.3 compatible or not. Was just a question to you because is a extra part of ZF and didn't know if is panned or not to include it.

https://github.com/Shardj/zf1-extras-future
If you run into any issues just drop an issue on there and I'll fix it


Cannot use Statiq.Feeds with Kontent

Describe the bug
Statiq.Feeds depends on AngleSharp >= 0.9.10 but that version is incompatible with the current version 0.14.0.
The Delivery SDK requires AngleSharep >= 0.14.0.
To Reproduce
Add a pipeline that uses the GenerateFeeds module to a project using Kontent.Statiq.
Expected behavior
The feed generates without issues.
Actual behavior
An exception occurs:
Error while executing module GenerateFeeds in Feeds/Process: Could not load type 'AngleSharp.Parser.Html.HtmlParser' from assembly 'AngleSharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea'.
Environment(please complete the following information):

OS: Windows
.NET Core version: 3.1
Package version or git commit hash: https://github.com/alanta/Kontent.Statiq/commit/3495dfbee1b7722d241682bb36262cd8db23225b

Additional context
This popped up in pre-release testing.

Works in beta7


Add port setting from settings_dict to connection_params

This resolves issue #9

Thanks for the patch. I'll double check that no other settings suffer from the same issue before merging it.


Intermittent Segmentation faults

SerialPort Version: v5.0.0-beta3

NodeJS Version: v7.10.0

Operating System and Hardware Platform: Debian Sid, kernel 4.9.25, ftdi_sio ttyUSB0: FTDI USB Serial Device

Have you checked the right version of the api docs?: yes

Are you having trouble installing and you checked the Installation Special Cases docs? no

Are you using Electron and have you checked the Electron Docs?: no

Summary of Problem
I'm seeing the occasional segmentation fault.
[Sat May 20 10:54:33 2017] usb 6-2: new full-speed USB device number 25 using ohci-pci
[Sat May 20 10:54:33 2017] usb 6-2: New USB device found, idVendor=0403, idProduct=6001
[Sat May 20 10:54:33 2017] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat May 20 10:54:33 2017] usb 6-2: Product: FT232R USB UART
[Sat May 20 10:54:33 2017] usb 6-2: Manufacturer: FTDI
[Sat May 20 10:54:33 2017] usb 6-2: SerialNumber: A9CBJ19X
[Sat May 20 10:54:33 2017] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
[Sat May 20 10:54:33 2017] usb 6-2: Detected FT232RL
[Sat May 20 10:54:33 2017] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0
[Sat May 20 10:54:39 2017] usb usb6-port2: disabled by hub (EMI?), re-enabling...
[Sat May 20 10:54:39 2017] usb 6-2: USB disconnect, device number 25
[Sat May 20 10:54:39 2017] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[Sat May 20 10:54:39 2017] ftdi_sio 6-2:1.0: device disconnected
[Sat May 20 10:54:39 2017] usb 6-2: new full-speed USB device number 26 using ohci-pci
[Sat May 20 10:54:40 2017] usb 6-2: New USB device found, idVendor=0403, idProduct=6001
[Sat May 20 10:54:40 2017] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat May 20 10:54:40 2017] usb 6-2: Product: FT232R USB UART
[Sat May 20 10:54:40 2017] usb 6-2: Manufacturer: FTDI
[Sat May 20 10:54:40 2017] usb 6-2: SerialNumber: A9CBJ19X
[Sat May 20 10:54:40 2017] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
[Sat May 20 10:54:40 2017] usb 6-2: Detected FT232RL
[Sat May 20 10:54:40 2017] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0
[Sat May 20 11:41:19 2017] node[17960]: segfault at 1810 ip 00007f948caeb5a1 sp 00007ffda3e334b0 error 4 in serialport.node[7f948cae0000+d000]
[Sat May 20 12:01:22 2017] node[20745]: segfault at e70 ip 00007fa2f4e395a1 sp 00007ffc3435bd20 error 4 in serialport.node[7fa2f4e2e000+d000]
[Sat May 20 12:10:40 2017] node[22869]: segfault at e70 ip 00007f8f079f25a1 sp 00007ffe150d7630 error 4 in serialport.node[7f8f079e7000+d000]
[Sat May 20 12:37:28 2017] node[23454]: segfault at 1810 ip 00007fab063185a1 sp 00007ffc6cbf6560 error 4 in serialport.node[7fab0630d000+d000]

Steps and Code to Reproduce the Issue
const port = new SerialPort('/dev/ttyUSB0', {
	baudRate: 9600
	, dataBits: 7
	, parity: 'even'
	, stopBits: 1
})

const parser = port.pipe(new SerialPort.parsers.ByteLength({
	length: APEX_MESSAGE.length.head
		+ APEX_MESSAGE.length.received
		+ APEX_MESSAGE.length.tail
}))

port.on('error', error => logger.error(error))

// I'm leaving this bit here for completeness but it's probably safe to ignore.
parser.on('data', message => {
	state.copy(oldState)
	messageToState(message)
	const stateDiff = getStateDiff()

	Object.keys(stateDiff).forEach(i => {
		Object.keys(APEX_MESSAGE.status[`byte${i}`]).forEach(j => {
			const bitDiff = stateDiff[i] & APEX_MESSAGE.status[`byte${i}`][j]
			if (bitDiff) {
				if (bitDiff & state[i]) {
					this.emit(j, true)
					return
				}
				this.emit(j, false)
			}
		})
	})
})

port.on('open', () => {
        // Here I have to write the port every 200ms - not sure if that's the cause.
	setInterval(() => {
		// Message needs to be re-created each time to alternate the acks
		const message = commandToMessage({
			data: [
				0x7f
				, APEX_MESSAGE.command.byte1.escrow
				, 0
			]
			, type: 'sent'
		})

		port.write(message, err => {
			if (err) {
				console.log('Error on write: ', err.message)
			}
		})
	}, 200)
	port.read()
})

This could be a cleanup problem so I've just added:
port.on('open', () => {
	process.once('SIGUSR2', () => {
		port.close(() => process.kill(process.pid, 'SIGUSR2'))
	})
...

I'll test it out and report back.

It didn't help; just saw another segfault. Hopefully this will help.
PID 11939 received SIGSEGV for address: 0x1810
/home/rich/Projects/bitcoin-barber-btm/backend/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1a4b)[0x7f29924dea4b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f2994e9e0c0]
/home/rich/Projects/bitcoin-barber-btm/backend/node_modules/serialport/build/Release/serialport.node(_ZN10ReadPoller6_closeEv+0x21)[0x7f299209c5a1]
node(+0x135f090)[0x55978c1dc090]
node(uv_run+0x14c)[0x55978c1cbf0c]
node(_ZN4node5StartEP9uv_loop_siPKPKciS5_+0x6f7)[0x55978bf20e37]
node(_ZN4node5StartEiPPc+0x10d)[0x55978bf1f9ad]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f2994b0f2b1]
node(_start+0x2a)[0x55978b40241a]


ValueError from firestore_fn.on_document_created (Emulator)

There's a bug when the @firestore_fn.on_document_created() gets executed in the emulator.
I started with this example.
# The Cloud Functions for Firebase SDK to create Cloud Functions and set up triggers.
from firebase_functions import firestore_fn, https_fn

# The Firebase Admin SDK to access Cloud Firestore.
from firebase_admin import initialize_app, firestore
import google.cloud.firestore

app = initialize_app()

@https_fn.on_request()
def addmessage(req: https_fn.Request) -> https_fn.Response:
    """Take the text parameter passed to this HTTP endpoint and insert it into
    a new document in the messages collection."""
    # Grab the text parameter.
    original = req.args.get("text")
    if original is None:
        return https_fn.Response("No text parameter provided", status=400)

    firestore_client: google.cloud.firestore.Client = firestore.client()

    # Push the new message into Cloud Firestore using the Firebase Admin SDK.
    _, doc_ref = firestore_client.collection("messages").add(
        {"original": original}
    )

    # Send back a message that we've successfully written the message
    return https_fn.Response(f"Message with ID {doc_ref.id} added.")

@firestore_fn.on_document_created(document="messages/{pushId}")
def makeuppercase(
    event: firestore_fn.Event[firestore_fn.DocumentSnapshot | None],
) -> None:
    """Listens for new documents to be added to /messages. If the document has
    an "original" field, creates an "uppercase" field containg the contents of
    "original" in upper case."""

    # Get the value of "original" if it exists.
    if event.data is None:
        return
    try:
        original = event.data.get("original")
    except KeyError:
        # No "original" field, so do nothing.
        return

    # Set the "uppercase" field.
    print(f"Uppercasing {event.params['pushId']}: {original}")
    upper = original.upper()
    event.data.reference.update({"uppercase": upper})

When I now open the url http://localhost:5001/MY_PROJECT/us-central1/addMessage?text=uppercaseme
I get the following error in the console:
i  functions: Beginning execution of "us-central1-addmessage"
i  functions: Finished "us-central1-addmessage" in 48.166834ms
i  functions: Beginning execution of "us-central1-makeuppercase"
>  [2023-10-14 14:04:37,923] ERROR in app: Exception on /functions/projects/ [POST]
>  Traceback (most recent call last):
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/flask/app.py", line 2190, in wsgi_app
>      response = self.full_dispatch_request()
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/flask/app.py", line 1486, in full_dispatch_request
>      rv = self.handle_user_exception(e)
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/flask/app.py", line 1484, in full_dispatch_request
>      rv = self.dispatch_request()
>           ^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/flask/app.py", line 1469, in dispatch_request
>      return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/functions_framework/__init__.py", line 174, in view_func
>      function(event)
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/firebase_functions/firestore_fn.py", line 308, in on_document_created_wrapped
>      return _firestore_endpoint_handler(
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/firebase_functions/firestore_fn.py", line 115, in _firestore_endpoint_handler
>      is_nanoseconds = _util.is_precision_timestamp(time)
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    File "/Users/XXX/Firebase/functions/venv/lib/python3.11/site-packages/firebase_functions/private/util.py", line 332, in is_precision_timestamp
>      _, s_fraction = time.split(".")
>      ^^^^^^^^^^^^^
>  ValueError: not enough values to unpack (expected 2, got 1)
i  functions: Finished "us-central1-makeuppercase" in 5.738042ms

Didn't changed anything in the requirements.txt file:
firebase_functions~=0.1.0

Same

Is fixed there, https://github.com/firebase/firebase-functions-python/pull/149
They are making a 0.2.0 release very soon now, the version num was already changed in main and all the code is in.

Looking forward to the new release 👍 , any scheduled date?

Any day now I guess, perhaps Google has some process it's going through still, dunno.
BTW I got the version number wrong, it's 0.1.2 in main now, https://github.com/firebase/firebase-functions-python/commit/8926c714e0dd453459971a0e39b8b6232ac1f36c

Hey. Since this issue is fixed in https://github.com/firebase/firebase-functions-python/pull/149, I'll close this issue. 0.1.2 will be released soon with this fix. Thanks for your patience


Waypoint: Comment your JavaScript Code, 2nd test bug

Challenge http://www.freecodecamp.com/challenges/waypoint-comment-your-javascript-code has an issue. Second test doesnt account for multi line comments. Becouse of that, this, valid comment:
/*
This is mutiline comment
*/
Doesnt pass the test.

I can't reproduce that error. Maybe this was fixed since this issue was made. I'm running on Chrome on a Windows machine, if that makes any difference.

Thanks for looking into this @erictleung. I confirm the same thing as well. Must have been fixed since this bug was filed!


Project of Polkadot-Dart by Michael So

Grant Application Checklist

[x] The application-template.md has been copied, renamed ( "project_name.md") and updated.
[x] A BTC address for the payment of the milestones is provided inside the application.
[x] The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
[x] The total funding amount of the project is below CHF 30k at the time of submission.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

We could not finish the CLA signing. So we are going to resubmit.


Experiment Code release

Hi,
Are there any plans to release the code of the paper soon?

Hi,
Thank you for your interest in our work. Our code will be released after the peer-review period for our paper submission is over.


2023 Roadmap for rn-emoji-keyboard

It's been quite a while since TheWidlarzGroup released the first version of the library 🚀 And an exciting journey developing it. Seeing it being used in countless applications has been very rewarding.
Thanks to the community and our dev team effort we have planned the following months.
🟢 Update rn-emoji-keyboard - to the latest version of React Native and Fabric compatibility - July - August 2023
Self-explanatory
🟢 Enhanced Search Functionality August - November 2023
Involves augmenting the search functionality by integrating a library or similar mechanism to search emojis using alternative keywords or associated terms. This would enable users to find emojis based on a broader range of terms related to the desired emoji, such as synonyms, related concepts, or commonly used expressions associated with the emoji.
🟢 Support for Older Android Versions  September - ?? 2023
Involves implementing comprehensive support for older Android versions, ensuring that emojis are displayed correctly across all devices and Android versions. This can be achieved by integrating appropriate emoji libraries or leveraging compatibility frameworks that handle emoji rendering and compatibility across different Android versions.
🟢 Additional feature and improvements ideas

The transition from Animated API to Reanimated
Enhanced Pop-up Hiding Behavior
Automated Snacks in Pull Requests (PRs) for Enhanced Testing
Compatibility with React Native Web
Migration of Examples to Expo for Easier Testing and Compatibility with React Native Web
Slack-like Custom Emojis
Support for GIFs Keyboard
Vertical Layout Categories

Our organization commits to maintaining and developing this library, although the presented plan is tentative and may change over time. Things might be delivered slower or... faster, if we get some help. As an open-source project, this library relies on the collaborative efforts of developers like you to continue to improve, innovate, and maintain our project. Our goal is to constantly enhance this emoji picker to meet ever-evolving user needs, maintain compatibility with the latest technologies, and expand our emoji range as they are released.
In order to make our project sustainable and keep providing value to our users, we are welcoming sponsorships. Your sponsorship will help us to cover development costs and maintain the high quality of the library.
By sponsoring our library, you will gain several benefits:

Priority Development: We will prioritize the development of features and fixes that matter the most to you.
Customization: We will help you to customize the emoji picker to better fit your project needs.
Recognition: Depending on the level of sponsorship, we can add your logo to our README file and/or our project's homepage.
To become a sponsor reach out to me directly<EMAIL_ADDRESS>If you have any questions or need any further details, don't hesitate to get in touch.

Also, if we get hired as React Native agency thanks to this library we commit to delivering the feature chosen by you within 4 weeks 🥇

Thanks for your ideas, bug reports, fixes, and improvements. If you feel this roadmap might get better just let me know @jakex7 @mateki0 @xts-bit @ShmilyXI @ginsueddy @oferRounds @liellevibob @yefim @crumb1e  @wojtus7 @hankduan @gaishimo @WrathChaos @tudormarze @kacper-mikolajczak @KIMINJOONG @rikkyarisendi @sebdott @itispx @minhchienwikipedia @pchalupa @SectionTN @WrathChaos @Hamfer @StianVaage @tudormarze @whaddafish @hankduan @saul-atomrigs @arunim2405 and you that I haven't mentioned!

It would be great to get this fix in and release it! https://github.com/TheWidlarzGroup/rn-emoji-keyboard/pull/145

Thanks for the work on this lib!
What's the progress on the search functionality improvements?

Hey, how is the roadmap going so far? Great work with the library by the way 🚀 . I might try to do the transition from Animated API to Reanimated (and I guess react-native-gesture-handler as well) if You are interested 😄

Hey @AnMiZa,
First off, massive thanks for your contributions.🌟
We're all in on the idea to switch things up with Reanimated and react-native-gesture-handler. We have it on our roadmap and it’s exactly the kind of upgrade we’ve been looking to explore.
Your initiative is super appreciated. Feel free to reach out anytime if you have questions or need a hand with anything.


[CosmosDB coordinate data to Java model issue]

Query/Question
“I am trying to build a Spring Boot project with some RESTFul apis to retrieve document from Azure CosmosDB (via SQL API v3).
Here are the sample data:
1.	 vessel {
2.	  "mmsi": 368102360,
3.	  "location": {
4.	         "type": "Point",
5.	         "coordinates": [
6.	             -90.255,
7.	             38.5383333333
8.	         ]
9.	     },
10.	 }

The mapped Java model:
1.	 @Data
2.	 public class Vessel {
3.	     @Id
4.	     private String id;
5.	     private String mmsi;
6.	     private Location location;
7.	 }
8.
9.	 @Data
10.	 public class Location {
11.	     private String type;
12.	     private ArrayList <Coordinate> coordinates;
13.	 }
14.
15.	 @Data
16.	 public class Coordinate {
17.	     Double latitude;
18.	     Double longitude;
19.	 }

I am hitting the error:
com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of .model.Coordinate (although at least one Creator exists): no double/Double-argument constructor/factory method to deserialize from Number value (-90.255)
at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: .model.Vessel["location"]->.model.Location["coordinates"]->java.util.ArrayList[0])
at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63) ~[jackson-databind-2.11.2.jar:2.11.2]

What would be the proper mapping for the dataset?
note it works for the following def:

private ArrayList coordinates;

But it would be nice to define a Coordinate object to better object traversal and interpretation.”
Why is this not a Bug or a feature Request?
A clear explanation of why is this not a bug or a feature request?
Setup (please complete the following information if applicable):

OS: [e.g. iOS]
IDE : [e.g. IntelliJ]
Version of the Library used

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[ ] Query Added
[ ] Setup information Added

@kirankumarkolli @mbhaskar The issue came on our Q&A platform - here are the details - =====================================================================
Issue: [https://docs.microsoft.com/en-us/answers/questions/242939/index.html]
You can track and update accordingly the Workitem for this escalation here: [https://msazure.visualstudio.com/One/_workitems/edit/9203723]

@kirankumarkolli @mbhaskar The issue came on our Q&A platform - here are the details - =====================================================================
Issue: [https://docs.microsoft.com/en-us/answers/questions/242939/index.html]
You can track and update accordingly the Workitem for this escalation here: [https://msazure.visualstudio.com/One/_workitems/edit/9203723]

@kirankumarkolli @mbhaskar Here is the Q&A issue - https://docs.microsoft.com/en-us/answers/questions/242939/index.html that we raised issue in reference too.

@kirankumarkolli @mbhaskar Here is the Q&A issue - https://docs.microsoft.com/en-us/answers/questions/242939/index.html that we raised issue in reference too.

Not sure about this, but seems like coordinates is an array of double values, instead of an array of Coordinate objects.

@mbhaskar Can you confirm the same.

@kirankumarkolli @mbhaskar Can you please confirm here.

"coordinates": [
-90.255,
38.5383333333
]
This json represents an array of numbers, so the deserialization type would be a Array/List.
An alternative could be just to read the data into a JsonNode object instead and then try custom deserialization in the way you need in your application.


Travis-CI integration

This is a squashed version of Travis-CI integration. Also I've pulled out the changes to the unit tests, since unit tests aren't being run yet - only CalDAVTester. I'll commit those separately.
(I'm shamelessly deleting the rest of the PR boilerplate because I'm not only a pull request client, I'm also a president!)

Andre,
I see that you are the one who created the github project for ccs-calendarserver, and you call yourself "president". Does that mean you are the tech lead for this project? I'm curious because I'd like to acknowledge the Apple team in a Kickstarter campaign I'm doing for a company I'm launching soon. I'd love to acknowledge the team, or at least you as lead if that's OK.

On Feb 23, 2017, at 3:06 PM, Rob Archibald<EMAIL_ADDRESS>wrote:
Andre,
I see that you are the one who created the github project for ccs-calendarserver, and you call yourself "president"

The "president" remark was absolutely a (strained) reference to an old Hair Club For Men television commercial. Sorry :) I'm not the president of anything.

. Does that mean you are the tech lead for this project?

No. My role on this project is sort of hard to succinctly describe, but generally includes dealing with 'deployment' issues, i.e. most any problem that doesn't exist completely inside the core server code, and also care & feeding of surrounding development infrastructure (buildbots, etc). Also I take the lead on the community support for the open source side. Every once in a while I actually commit something to the repo.

I'm curious because I'd like to acknowledge the Apple team in a Kickstarter campaign I'm doing for a company I'm launching soon. I'd love to acknowledge the team, or at least you as lead if that's OK

Thanks for asking. As CalendarServer is an open source project, everything that has transpired here is in the public record, so feel free to acknowledge any of that. In terms of the codebase itself, my contributions pale in comparison to those of the top contributors https://github.com/apple/ccs-calendarserver/graphs/contributors.
-dre


[T6A3][T14-C1] Oh Han Gyeol

ready for review

@Leook0209
Some comments added. Please ack & close the PR after reading comments.


test_twine fails with existing /usr/bin/twine

I could patch setupmeta.which to return False for run_setup_py(["twine", "--egg=all"], "twine is not installed"), but later invocations should also use the mocked (copied) version then.

E             Running: /tmp/tox…/Vcs/setupmeta/py37/bin/python setup.py bdist_egg
E             Uploading to PyPi via twine...
E             Running: <target>/mocked-twine upload <target>/dist/sample-0.0.0.dirty-py3.7.egg
E             Deleting <target>/build...
E           assert None

…/Vcs/setupmeta/tests/test_commands.py:24: AssertionError
----------------------------------- Captured stdout setup -----------------------------------
Running: git init
Running: git add sample.py .gitignore requirements.txt setup.py setup.cfg
Running: git commit -m "Initial commit"
Running: git tag -a v0.1.0 -m "Version 2.4.2"
===================================== warnings summary ======================================
tests/test_commands.py::test_twine
  …/Vcs/setupmeta/tests/test_commands.py:24: PytestAssertRewriteWarning: asserting the value None, please use "assert is None"
    assert m, "'%s' not present in output of '%s': %s" % (line, " ".join(args), output)

-- Docs: https://docs.pytest.org/en/latest/warnings.html
======================= 1 failed, 54 deselected, 1 warnings in 1.09s ========================
ERROR: InvocationError for command /tmp/tox…/Vcs/setupmeta/py37/bin/pytest -k test_twine -vv (exited with code 1)
__________________________________________ summary __________________________________________
ERROR:   py37: commands failed

(using tox -e py37 -- -k test_twine -vv)

Ah, so from your output, looks like the mocked-twine is now working as expected, however you seem to get this:
Running: .../mocked-twine .../sample-0.0.0...

Instead of the expected:
Running: .../mocked-twine .../sample-0.1.0...

Ie: in your case, it got the version wrong.
The test should basically create a temp folder, with a few sample files in it, and assign a tag v0.1.0. Somehow, you get a different tag.
The sample git repo is created by sample_project() in conftest.py, and the tagging should be happening line 50 of conftest.py. Something in your setup is changing that apparently. Only debugger can tell us what I think.

Going to close this one as can't reproduce.
I just added an explicit git config call in test setup: https://github.com/zsimic/setupmeta/commit/04cc94db33436e3567a04f17f079b779ae36d79d
It's possible that you have a version of git that I didn't have, just realized today some git setups complain about missing name/email, it could be what was making your test run fail before.