flash completed but device does not show up

I successfully flashed 1 aubess smartswitch bk7213N, I have 6. It was by no means easy. In the meantime, I have been busy flashing the others for a few days, but after completing the routine. The device does not show up in  my the network. The script  has changed the firmware but afterwards the device does not appear in my network. I don't have any special characters in my wifi ssid or password and have put -s 'myssid' 'mypass' between the characters. I dont have ip or mac filtering in my router.
After i flash i even tried to connect with the smart app to direct it to my network.  This step wont complete of course hens the tact that Its cut off from the tuya cloud with succes. If i take this step (reconnecting with the smartapp) the device is on my network and pingable but cant be used in homeassistant.
Also, I tried to direct the AP to the cloudcutterflash using the smartapp but remains too short in the air to complete that. Is there a method to get it up longer and earlier? What am I doing wrong? Attached is the verbose output
two runs.txt

Are you cutting or flashing?  The logs provided are only for cutting, and they completed successfully.  If the device doesn't join your network, that is an issue you must figure out how to resolve outside of CloudCutter, as all we're doing is passing the ssid and password into the same fields Tuya uses to connect to a network.

The script has changed the firmware but afterwards the device does not appear in my network.

Again, are you cutting or flashing?  If flashing, what are you flashing?  If it is ESPHome, are you changing the device name so there is no conflict?  If OpenBeken, a device doesn't join your network, it starts an AP instead.  The -s flag does not work with flashing, it is only for cutting.  If you are just cutting, you need to examine your network to find out why the device isn't joining.  There is no other way CloudCutter can pass credentials to join a network.

After i flash i even tried to connect with the smart app to direct it to my network.

If you are flashing 3rd party firmware, I am not sure what smart app you are referring to, Smart Life would no longer be applicable.  If you are cutting, Smart Life will no longer work as the device never finishes communicating with Smart Life because it has been cut.  The only way to change network credentials (again, only if cut, not if flashed with 3rd party firmware) is by running CloudCutter again and providing different credentials.

This step wont complete of course hens the tact that Its cut off from the tuya cloud with succes. If i take this step (reconnecting with the smartapp) the device is on my network and pingable but cant be used in homeassistant.

This is because it resets deviceids when you try to join with Smart Life, and it will fail.  Once cut, you should stop using the Smart Life app with that device.  Smart Life when it sets network details attempts to re-activate the device (which will fail), and because it fails, will continue trying to re-activate itself (which will keep failing).

Also, I tried to direct the AP to the cloudcutterflash using the smartapp but remains too short in the air to complete that. Is there a method to get it up longer and earlier? What am I doing wrong? Attached is the verbose output

I'm not sure what you're even trying to do here.  You should not be doing anything with the Smart Life app at this point.  The CloudCutter script does the network join portion on its own independent of the Smart Life app.
You should not need to use the Smart Life app for any portion of cutting or flashing using Tuya-CloudCutter.

Okay sorry for my bad English. i will try to explain.
i try to cut the mini switch off.

sudo ./tuya cloudcutter.sh -r -w wlan0 -s   -v
put mini switch in AP mode (slow blinking)
script ->  finds the AP  and setting up wlan0 -> Running initial exploit toolchain
device freezes and have to wait till its free to set it in AP mode again
It finds device and configure device for connecting to cloudcutterflash ( i can see cloucutterflash become availeable)
script gives message:  Wait for up to 10-120 seconds for the device to connect to 'cloudcutterflash'. This script will then show the activation requests sent by the device, and tell you whether local activation was successful.
my question is, during this last step should the device blink? because at this point the device switch is functional.

it ends with succes and the device should be visible or pingable in my network. but it is not.
while it isn't working after several times trying and restart the above procedure
i switched to my android and started the smartlive app.  just for testing purpose. I know its cut off so it cant fullfill its adding procedure anymore.

add device  with loged in to my network wifi settings.
putting device in AP mode fast blinking
smartlife app connects to device
device stops blinking
device is visible in router on local ip <IP_ADDRESS>
device is pingable

as mentioned above step with smartlife app should not be done but is more a test cause i'm out of cluess here.
if i restart tuay-cloudcutter.sh again i get the same results as the first try. device is not visible in router , not pingable.
so what am i doing wrong or where can i get some pointers how to check if tuya-cloudcutter.sh is actually writing the wifi credentials and use these.

7. my question is, during this last step should the device blink? because at this point the device switch is functional.

Not all devices are the same, but no, it should stop blinking once it connects to the cloudcutterflash AP.  Your log shows it goes through the complete motion and finishes successfully.  If the device won't reliably stay on your network, cutting may not be the most viable option (some devices just have poor connectivity code from Tuya).  You may be better off flashing a 3rd party firmware, especially for something as simple as a relay/switch.

it ends with succes and the device should be visible or pingable in my network. but it is not.

It can't get the the success message without doing all the things that would allow it to join your network.  If it doesn't, then there is either a flaw in your network, or a flaw in the firmware on the device.  It only makes it to the success message if it received a good response to the network join command.
I don't think you're doing anything wrong, but either something is incompatible with your network, or the firmware on the device is flawed in an unusual way.  It wouldn't be the first time, there have been a couple other devices that have failed to join after being sent all data correctly.  My general recommendation at this point would to look into the possibility of a 3rd party firmware.  See https://github.com/tuya-cloudcutter/tuya-cloudcutter/blob/main/INSTRUCTIONS.md#custom-firmware-options for potential 3rd party firmware options.
I'm closing this issue, as there is nothing different Tuya-CloudCutter can do, as unfortunate as that might be.


Connecting an organisation that was not present when first using amplify

** Please describe which feature you have a question about? **
I want to connect a new github repository, which is under a specific github organisation.
I currently have 6 other projects running, which are either under my personal account, or another organisation that I am a member of.
I believe the issue is that when I first used amplify-console from the AWS UI, this second github organisation did not yet exist, and so it never detects projects which are under that org.
Is there a way I can re-authenticate/ get those projects to show up? Pushing new commits to them does not help.
** Provide additional details**

Ok solved - the solution was to revoke from Github AWS Amplify access, and then to re-authorise.


chore: rel urls, remove txindex display

change to relative urls, remove transaction index, and change owner to creator/artist per discussions

also made some changes to move the JS out of the index.html page. Will need to do the same for the css elements as well so we can apply those elements across all pages.


Translation for Hindi

**Need a translation for Hindi  [ Hindi - INDIA (IN) (hi_IN)] **
Locale Support needed :  Hindi - INDIA (IN) (hi_IN)
Number of Native Hindi Speakers in India
Percentage of Hindi understood :  57%  , 691 Million
reference: wiki reference

We have Hindi translation (~56% translated), you can help us adding more translations so it shows up in the dropdown as well (it needs to ~85% translated) https://crowdin.com/translate/excalidraw/10/en-hi?filter=basic&value=0


Compatibility with Python 3.7

Testing with the new Python 3.7, I am getting these errors:
$ python -m wheelhouse_uploader upload --local-folder ${TRAVIS_BUILD_DIR}/wheelhouse/ $UPLOAD_ARGS $CONTAINER
Traceback (most recent call last):
  File "/Users/travis/build/MacPython/cython-wheels/venv/lib/python3.7/site-packages/libcloud/utils/files.py", line 86, in read_in_chunks
    raise StopIteration
StopIteration
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/Users/travis/build/MacPython/cython-wheels/venv/lib/python3.7/site-packages/wheelhouse_uploader/upload.py", line 45, in upload
    return self._try_upload_once(local_folder, container)
  File "/Users/travis/build/MacPython/cython-wheels/venv/lib/python3.7/site-packages/wheelhouse_uploader/upload.py", line 74, in _try_upload_once
    recently_uploaded=recently_uploaded)
  File "/Users/travis/build/MacPython/cython-wheels/venv/lib/python3.7/site-packages/wheelhouse_uploader/upload.py", line 95, in _update_metadata_file
    for bytes_ in metadata_obj.as_stream():
RuntimeError: generator raised StopIteration
Traceback (most recent call last):
  File "/Users/travis/build/MacPython/cython-wheels/venv/lib/python3.7/site-packages/libcloud/utils/files.py", line 86, in read_in_chunks
    raise StopIteration
StopIteration

https://travis-ci.org/MacPython/cython-wheels/jobs/398198700#L198
Is wheelhouse-uploader compatible with Python 3.7?

I have tried to bump up the dependency on apache libcloud but then I run into:
https://issues.apache.org/jira/browse/LIBCLOUD-935
I will try to find a work around.

@matthew-brett I pushed release 0.10.0 that includes support for Python 3.7 (while still supporting python 2.7) and recent versions of apache libcloud.

Excellent - thanks a lot for doing that.  Now to try and pull out all those
uses of --no-ssl-check :)
On Tue, Jul 3, 2018 at 1:17 PM, Olivier Grisel<EMAIL_ADDRESS>wrote:

@matthew-brett https://github.com/matthew-brett I pushed release 0.10.0
that includes support for Python 3.7 (while still supporting python 2.7)
and recent versions of apache libcloud.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ogrisel/wheelhouse-uploader/issues/27#issuecomment-402135117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEIHALTEBloyPJZbATfYFCNzatn8VRvks5uC2DQgaJpZM4U9ThZ
.

It's causing another bug:
https://github.com/ogrisel/wheelhouse-uploader/issues/29
Will probably do a stopgap release that pins the libcloud dependency to 2.2.1.
I am also trying to reset my apache password to report the bug upstream.


New

Risk Level 3 - /home/runner/work/sample-project-maven/sample-project-maven/src/main/java/org/web3j/sample/Application.java

The Infura token is hardcoded in the code, which is a security risk. API keys and secrets should not be stored in plain text in the code. Consider using environment variables or a configuration file to store sensitive information.
The password for the wallet file is hardcoded in the code, which is also a security risk. Consider using a more secure method to handle passwords, such as a password manager or encryption.
The code could be improved by separating the Ethereum client endpoint, wallet file path, and other configurable values into a separate configuration file or class. This would make it easier to change these values without modifying the code.
The code could benefit from better error handling and exception handling. Currently, exceptions are not caught or handled, which could lead to unexpected behavior or crashes.
The code could be refactored to follow SOLID principles, such as separating the Ethereum client connection logic into a separate class or module.
The code could be made more readable by adding comments and documentation to explain the purpose and functionality of each section of code.
The code could be optimized for performance by using asynchronous calls and parallel processing where applicable. This could improve the overall efficiency and responsiveness of the application.
Consider using a logging framework, such as Log4j or SLF4J, to handle logging instead of using System.out.println(). This would provide more flexibility and control over logging levels and output destinations.
Consider using a dependency injection framework, such as Spring or Guice, to manage dependencies and improve the overall maintainability and testability of the code.
Consider using a code formatter, such as Google Java Format or Checkstyle, to ensure consistent code style and formatting throughout the project.
Consider using unit tests to verify the correctness and functionality of the code. This would help catch bugs and issues early on and improve the overall quality of the code.
Consider using version control best practices, such as branching and merging, to manage code changes and collaborate with other developers effectively.
Consider using code review tools or plugins, such as SonarQube or Crucible, to automate and streamline the code review process. This would help identify potential issues and improve code quality and maintainability.

🔒 Security risks: hardcoded sensitive information, password handling
🔧 Code improvements: separate configuration, error handling, SOLID principles
📚 Readability and optimization: comments, documentation, performance enhancements
💼 Best practices: logging framework, dependency injection, code formatting, unit tests, version control, code review tools

Powered by Code Review GPT


Fedora 36, please.

Could someone generate MAVSDK for Fedora 36, please.
Thanks

FWIW, I was able to install mavsdk-devel-1.4.3-1.fc35-x86_64.rpm on F36 with #dnf install ./mavsdk*.


Graceful Failure

When a cloud provider fails to provision a machine, InstaScale should be able to gracefully handle: either by removing the failed machine and re-trying, or by scaling down the whole request if incomplete (or both, with a configurable timeout).

@Maxusmusti I have been trying to trigger a failure phase in a machine but I have not been able to come across a way to do this. Even trying to scale machines which are not available to our org didn't work.
Have you any idea on how to trigger this scenario? Also how often would a failure like this occur?

@Bobbins228 did you ever figure this out?

I thought I had made a comment here but yeah if I remember correctly you have to create a machineSet template with an incorrect subnet attached to it which will cause a Node to enter that failed phase when machines are scaled up. That way you can replicate this behaviour.


Update nrf-serialization

This works with my one patch to the kernel PR. I tested on hail.

#174 subsumes this.


Add upper version bound on vector

After spending a couple of hours trying to figure out why cardano-crypto-class was not compiling in certain repos.

Comment explaining why this helps, or do we not know?

Like, did vector do something weird in this version?

Well, nothing weird other than a breaking change (justifying the 0.12.x.y -> <IP_ADDRESS> transition). To be honest I don't understand the problem very well. The error is
src/Cardano/Crypto/KES/Simple.hs:195:10: error:
Error:     • Could not deduce (NoThunks (Vector (SignKeyDSIGN d)))
        arising from a use of ‘NoThunks.Class.$dmwNoThunks’
      from the context: DSIGNAlgorithm d
        bound by the instance declaration
        at src/Cardano/Crypto/KES/Simple.hs:195:10-66
    • In the expression:
        NoThunks.Class.$dmwNoThunks @(SignKeyKES (SimpleKES d t))
      In an equation for ‘NoThunks.Class.wNoThunks’:
          NoThunks.Class.wNoThunks
            = NoThunks.Class.$dmwNoThunks @(SignKeyKES (SimpleKES d t))
      In the instance declaration for
        ‘NoThunks (SignKeyKES (SimpleKES d t))’
    |
195 | instance DSIGNAlgorithm d => NoThunks (SignKeyKES (SimpleKES d t))
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The changelog mentions a change in the role signatures but I am not sure how that could lead to the problem.

Hmm, so maybe it's a nothunks issue we should raise that the vector instances don't seem to work with vector- 0.13

Yes, the issue should be fixed. Adding an upper bound is simply masking a problem and delaying someone finding a solution. That is exactly why adding restrictive upper bounds proactively is a bad thing. The weird part is that nothunks already has an upper bound on vector (vector >=0.12 && <0.13), so I have no idea how vector-0.13 was used in the first place.
In any case roles indeed have changed in latest vector and it does prevent instance deriving (for good reasons) and I guess affects default implementation using generics as well.
I've opened a ticket to solve this issue properly: #327

I want the developers to fix the problem of supporting newer versions of vector.
I don’t want the users to fix the problem of why cardano-crypto-class doesn’t compile anymore.

The weird part is that nothunks already has an upper bound on vector (vector >=0.12 && <0.13), so I have no idea how vector-0.13 was used in the first place.

This is confusing indeed. I’ll have another look.

Adding an upper bound is simply masking a problem and delaying someone finding a solution.

In this case I disagree: adding an upper bound here means that the developers of cardano-crypto-class (i.e. us) have noticed there is a problem and can pursue a fix; but it prevents any users of cardano-crypto-class from re-discovering the same problem repeatedly until we fix it. If we know a dependency doesn't work, then it's just true to add the upper bound. But I agree that we should mainly try and fix the problem.

Adding an upper bound is simply masking a problem and delaying someone finding a solution.

@michaelpj and @andreabedini My apologies, looks like I worded it poorly and I can now see how unclear was the point that I was trying to make. I was trying to say that we would have not discovered this issue if the upper bound was there in the first place. Moreover, I was reading comments on this PR in my email and did no realize the the comment I was addressing was not even in this thread: https://github.com/input-output-hk/cardano-base/pull/318#issuecomment-1290158102 So, the culprit was not the lack of upper bound, but the fact that cardano-crypto-class was not compatible with vector-0.13
In other words the proper fix should be making the library compatible. That beeing said, I do agree that in such a situation if a fix is not feasible due to some reasons like complexity of a fix or lack of resources for the task, then adding an upper bound is a totally sensible thing to do and I would always encourage it. So I am definitely not against the interim fix of adding an upper bound, as was done in this PR.


Fix52

Should fix the issue #23 when using the api or the website.

Oops, I just fixed this. Sorry!


Question: Is there a standard format for using @returns when returning an async function?

Example code:
Given the following example, the fetchSomething instance method returns an async function.  Is there a proper way for describing that the return value is a function AND that it is async?
class ExampleClass {
  constructor() { }

  /**
  * @description An async method which fetches some data asynchronously.
  * @async
  * @static
  * @returns {promise<object>}
  */
  static asyncFetchSomething(/* args */) {
    // Do some async operation here;

    return Promise.resolve({});
  }

  /**
  * @description Returns an async method to fetch some data asynchronously.
  * @instance
  * @returns {function}
  */
  get fetchSomething() {
    return this.constructor.asyncFetchSomething;
  }
}

Probably duplicate of #509 ?


lazy:true doesn't work correctly

Environment

Operating System: Linux
Node Version:     v18.18.0
Nuxt Version:     3.11.2
CLI Version:      3.11.1
Nitro Version:    2.9.6
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools, modules, i18n
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Reproduction
https://stackblitz.com/edit/nuxt-starter-cro1om?file=locales%2Fen.json,locales%2Fru.json,nuxt.config.ts,app.vue,pages%2Findex.vue,components%2Fmenu.vue
Describe the bug
I expect json with ru text will be loading only when i click ru locale. But instead, both files are downloaded at the same time

Additional context
No response
Logs
No response

Thank you for your reporting!
Unfortunately, I could not reproduce this issue in my enviroment. 😞
Your nuxt.config.ts has defaultLocale: 'en'.
When you access the root of the page only en.json is loaded.
If you switch to ru once and reload, both en.json and ru.json will be loaded. This behavior is correct. This behavior is correct, because the defaultLocale: 'en' and the switched ru are required.


Create eleventy-plugin-responsive-images.json

Adding eleventy-plugin-responsive-images plugin to the list

Thank you!


BOPIS (Buy Online, Pick Up In-Store)

@amansinghbais I see some of the items are taken care of. Should I created a seperate ticket for the items left, or just close this out because everything is already done.

@Dhiraj1405 sir, Almost all of the issues mentioned in this ticket are resolved. The one's left are due to a single reason that notifications don't come after refreshing the app.
We can close this ticket and raise a different for that refreshing issue.

Closing this issue, we will create a new issue.


merge master into gearpump-runner

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[x] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[x] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[x] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

R: @kennknowles @dhalperi

Can you merge apache:master into apache:gearpump-runner and then rebase manuzhang:gearpump-runner, to clear out the excess commits?

@kennknowles this's a merge PR now.


prerender can now bind to a specific interface using NODE_HOSTNAME

As proposed in #164 this could be useful for security/obfuscation reasons, without needing to use a firewall setting.

I would very much like to see this merged.

Sorry about the delay! I'll try to get this merged tonight or tomorrow.

Thanks @mrgamer! @svenstaro this has been merged. Let me know if you see any issues when using it.


Cargo rebuild isn't triggered when restarting a test with modified code

OS: Arch Linux
VSCode version:  1.82.1
CodeLLDB version: 1.9.2
Compiler: rust 1.72
Debuggee: Rust w/ Dwarf

Hitting "restart" in the debugger pane doesn't rebuild the binary if I make changes to the source. This applies to both when launched through IntelliSense or through a launch config.
x86_64-pc-linux-gnu
Steps to Reproduce:
Set a breakpoint at some line of code.
Use Intellisense to launch a normal rust test by hitting the "Debug" inlay hint.
Modify some code and save
Hit "restart" in the debug panel
Expected:
The new modified code is being tested
Actual:
Code is not rebuilt and instead the previously run library is used.
The same issue exists when using a formal lldb cargo profile in launch.json & hitting restart then.
This is a bit of departure of my expectation from what normally happens when you initially start the debugging session where it will trigger a rebuild as I find myself frequently trying to "debug -> edit (e.g. adding a printf, fixing what I think is the bug)-> restart the test running the new code to verify change".
If this is a controversial suggestion, it would be nice to at least have this be a toggleable preference (or even use file watching to determine if any files changed since last run for peak optimal behavior).

Rebuilding (or not) code on debug is a VSCode behavior, so you should raise this issue with them.  (The "Debug" inlay hint is not even a Codelldb feature, but rather that of the Rust Analyzer).

I did before I filed it here because that's what I figured: https://github.com/microsoft/vscode/issues/193039
The VSCode team closed it out and said it's an LLDB issue.


Create LICENSE

Thank you for this very interesting and exciting work and for releasing your code and models! Would you consider adding a permissive license like this one?

Yes, sure, thanks!