Feature request: propagate span attributes

I'd be interested in a feature that allowed you to propagate the span attributes that were added to the parent span down to the child spans created using request.openTelemetry().tracer. I was thinking something along these lines:
get tracer () {
  const tracer = trace.getTracer(moduleName, moduleVersion)

  if (propagateSpanAttributes) {
    const { startSpan } = tracer
    tracer.startSpan = function startSpanWithAttributes (...args) {
      const span = startSpan.apply(tracer, args)
      if (contextMap.has(request)) {
        const activeSpan = trace.getSpan(contextMap.get(request))
        span.setAttributes(activeSpan.attributes)
      } else {
        span.setAttributes(formatSpanAttributes.request(request))
      }
      return span
    }
  }

  return tracer
},

This uses a new option propagateSpanAttributes and when true (default false), gets the attributes from the parent span created by fastify-opentelemetry and applies them to any spans you create by extending tracer.startSpan. If there is no match for the request in the contextMap (e.g. when called in an onResponse hook), it uses formatSpanAttributes.request to create the attributes.
What do you think?

Hi @10xLaCroixDrinker, thanks for the feature request!
This does sound like it could be useful and it looks like there has been some talk on the otel-js repo about handling shared attributes (https://github.com/open-telemetry/opentelemetry-js/issues/4274).
I do think in this case, the logic here would be better suited in a SpanProcessor though.
Sharing parent attributes could be achieved like so:
class ShareParentAttrsProcessor extends NoopSpanProcessor {
  onStart (span, parentContext) {
    // Check if the span was created by this plugin...
    if (span.instrumentationLibrary.name === '@autotelic/fastify-opentelemetry') {
      const parentSpan = api.trace.getSpan(parentContext)
      if (parentSpan?.attributes) {
        span.setAttributes(parentSpan.attributes)
      }
    }
  }
}

I've pushed a branch with a working example of the above, If you'd like try it out locally -> https://github.com/autotelic/fastify-opentelemetry/blob/eg-propagate-attrs/example/opentelemetry.js

Thanks @HW13


Remove unsafe code in Counter

Fixes #91

Only if they increment it once per nanosecond...

Sorry to be "that guy". :(

No worries! Despite the joking, I'm happy to get rid of unneeded unsafe code, and I'm sure the extra branch will be unnoticeable.


About Us section paragraph .. Whether you are an owner operator.... make that font bigger or standout

Make the Whether you are an owner ... paragraph font/ bigger

Done


Installation failed with Laravel v8.23.1

Steps to reproduce
1- curl -s https://laravel.build/example-app | bash
2- cd example-app
3- sail up
4- sail composer require rinvex/laravel-categories
PHP Version
PHP 8.0.1 (cli) (built: Jan 13 2021 08:22:35) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.1, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.1, Copyright (c), by Zend Technologies

Output:
Using version ^5.0 for rinvex/laravel-categories
./composer.json has been updated
Running composer update rinvex/laravel-categories
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - rinvex/laravel-support v5.0.1 requires felixkiss/uniquewith-validator ^3.4.0 -> satisfiable by felixkiss/uniquewith-validator[3.4.0].
    - rinvex/laravel-support v5.0.3 requires rinvex/tmp-watson-validating ^6.0.0 -> satisfiable by rinvex/tmp-watson-validating[6.0.0, v6.0.1, 6.0.2, 6.0.3].
    - rinvex/laravel-support v5.0.2 requires rinvex/tmp-felixkiss-uniquewith-validator 3.4.0 -> satisfiable by rinvex/tmp-felixkiss-uniquewith-validator[3.4.0].
    - rinvex/laravel-categories v5.0.0 requires php ^7.4.0 -> your php version (8.0.1) does not satisfy that requirement.
    - rinvex/laravel-support v5.0.0 requires php ^7.4.0 -> your php version (8.0.1) does not satisfy that requirement.
    - felixkiss/uniquewith-validator 3.4.0 requires php ^7.1.3 -> your php version (8.0.1) does not satisfy that requirement.
    - rinvex/tmp-felixkiss-uniquewith-validator 3.4.0 requires php ^7.1.3 -> your php version (8.0.1) does not satisfy that requirement.
    - rinvex/tmp-watson-validating[6.0.0, ..., 6.0.2] require php ^7.3 -> your php version (8.0.1) does not satisfy that requirement.
    - rinvex/tmp-watson-validating 6.0.3 requires php ^7.3 || v8.0.0 -> your php version (8.0.1) does not satisfy that requirement.
    - rinvex/laravel-categories v5.0.1 requires rinvex/laravel-support ^5.0.0 -> satisfiable by rinvex/laravel-support[v5.0.0, v5.0.1, v5.0.2, v5.0.3].
    - Root composer.json requires rinvex/laravel-categories ^5.0 -> satisfiable by rinvex/laravel-categories[v5.0.0, v5.0.1].

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Should I use composer require rinvex/laravel-categories --ignore-platform-reqs which solves the problem?

That was an issue with one of the dependencies rinvex/tmp-felixkiss-uniquewith-validator, which is now fixed, please try again and let me know if you still have any issues.

@Omranic Thank you so much

Still having issue.
Laravel 8.12
PHP 7.4
❯ composer require rinvex/laravel-categories
Using version ^3.0 for rinvex/laravel-categories
./composer.json has been updated
Running composer update rinvex/laravel-categories
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - rinvex/laravel-categories[v3.0.0, ..., v3.0.5] require illuminate/console ^6.0.0 -> found illuminate/console[v6.0.0, ..., 6.x-dev] but these were not loaded, likely because it conflicts with another require.
    - Root composer.json requires rinvex/laravel-categories ^3.0 -> satisfiable by rinvex/laravel-categories[v3.0.0, ..., v3.0.5].

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

@mrlinnth
It works on Laravel 8.26.1, try to update

https://github.com/rinvex/laravel-categories/issues/98

Update: we dropped the felixkiss/uniquewith-validator dependency 🙂 https://github.com/rinvex/laravel-support/commit/2bf69b8dcbf6f18ecd97c2c7b43ae441d58765cd


 :(
I tried a few different approaches but wasn't able to get it running ...
Is anybody here who could help resolving this issue?!
Greets Daniel

What was the output of the actual init script? From the log above, the ssl file doesn't exist so it was never created. I would make sure it exists and there are no errors after running the init script.


Pr/fix init error

When findUp can't find an existing package-scripts.js file, it returns null, which is passed back to
findUp and throws an error because path.resolve can only accept strings as arguments
#124

What: Fixes error thrown when a package-scripts.js file doesn't exist while running init

Why: Because if you're running nps init without an existing package-scripts.js file, it won't work, forcing developers to have to create the file manually.

How: Checking that the path returned from getPSConfigFilepath is actually a string before passing it to findUp.sync.

I tried figuring out why the tests never fail for this, but I believe it's because of jest's mocking of findUp means that it never even hits the path.resolve method, so I'm not sure how you'd want to test for this particular case.

Codecov Report

Merging #127 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #127   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          10     10
  Lines         286    286
=====================================
  Hits          286    286

Impacted Files
Coverage Δ

src/bin-utils/parser.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

This is great, thank you!

Thank you so much!


Upload on MELPA

Hi! Just wanted to say that I'm using this package and I find it super useful - it's much better and less invasive than some of the other ones on GitHub/MELPA.
Do you have any plans to upload it on MELPA? Anything I can do to help?

i just never got around to it. this was some experimental code but actually it works quite well in practice so maybe it's not that experimental after all.
i may look into this soon. the melpa part is simple, but i'll need to come up with a simple readme first.

now that there's a readme (https://github.com/wbolster/emacs-python-coverage)
i've submitted this to melpa: https://github.com/melpa/melpa/pull/7806


Update README.md

Enable CInteropCommonization in gradle level.
Recently, I noticed new KMP projects didn't include this CInteropCommonization property in gradle.properties by default. Without it, importing Kotlin into the iosApp module isn't possible.

@wh173d3v11 thank you for the contribution!


Add a DisableComment Cop

Hey 👋🏻!
I wrote this rule at work where we have a very similar codebase and @MikeMcQuaid suggested that it could be useful in Homebrew as well so I essentially just copied it over here.
The rule enforces that any robocop:disable have a preceding comment that explains why the rule was disabled. This can be very useful when things are disabled for seemingly obvious reasons, but they become less and less obvious over time.
Everything looks good except for when I try to run the test I wrote, the test runner doesn't seem to find the test file 🤔. See the output log below.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

I feel like I'm probably holding it wrong?
 ~/src/koddsson/brew/Library/Homebrew/ [rubocops/disable_comment] brew tests --only=rubocops/disable_comment
Usage: brew tests [options]

Run Homebrew's unit and integration tests.

      --coverage                   Generate code coverage reports.
      --generic                    Run only OS-agnostic tests.
      --online                     Include tests that use the GitHub API and
                                   tests that use any of the taps for official
                                   external commands.
      --debug                      Enable debugging using ruby/debug, or
                                   surface the standard odebug output.
      --changed                    Only runs tests on files that were changed
                                   from the master branch.
      --fail-fast                  Exit early on the first failing test.
      --only                       Run only test_script_spec.rb. Appending
                                   :line_number will start at a specific
                                   line.
      --profile                    Run the test suite serially to find the n
                                   slowest tests.
      --seed                       Randomise tests with the specified value
                                   instead of a random seed.
  -d                               Display any debugging information.
  -q, --quiet                      Make some output more quiet.
  -v, --verbose                    Make some output more verbose.
  -h, --help                       Show this message.

Error: Invalid usage: The `--only` argument requires a valid file or folder name!

Evidently, something failed when I ran brew style as well 🤔
Good to see that the rule is working though!

Not stale, I'll help @koddsson with this some more after the holidays.


Add .geoip/include to C_INCLUDE_PATH and .geoip/lib to LIBRARY_PATH

These were required for me to build the Ruby library hive_geoip2 on heroku.
https://github.com/desuwa/hive_geoip2
Absent the former I get:
current directory:
       /app/vendor/bundle/ruby/2.7.0/gems/hive_geoip2-0.1.2/ext/hive_geoip2
       make "DESTDIR="
       compiling hive_geoip2.c
       hive_geoip2.c:6:10: fatal error: maxminddb.h: No such file or directory
        #include "maxminddb.h"
                 ^~~~~~~~~~~~~
       compilation terminated.
       Makefile:244: recipe for target 'hive_geoip2.o' failed

Absent the latter I get:
linking shared-object hive_geoip2.so
       /usr/bin/ld: cannot find -lmaxminddb
       collect2: error: ld returned 1 exit status
       Makefile:260: recipe for target 'hive_geoip2.so' failed

While these changes have merit, they don't make the buildpack usable on heroku with hive_geoip2, so I'm closing this.


⚠ Apple has degraded performance

In e61fabc, Apple (https://apple.com) experienced degraded performance:

HTTP code: 200
Response time: 724 ms

Resolved: Apple performance has improved in 257f091.


SetVideoEncoderConfigurations

How to change encoder Quality (or any) options?

It is also very necessary

I wrote a function to set the configuration, but my camera seems to reboot when it starts, can someone tell me what I did wrong?
I added my setVideoEncoderConfiguration function to /lib/service-media.js
According to documentation: https://www.onvif.org/ver10/media/wsdl/media.wsdl
my function:
`OnvifServiceMedia.prototype.setVideoEncoderConfiguration = function(params, callback) {
let promise = new Promise((resolve, reject) => {
let err_msg = '';
if(err_msg = mOnvifSoap.isInvalidValue(params, 'object')) {
reject(new Error('The value of "params" was invalid: ' + err_msg));
return;
}
	if(err_msg = mOnvifSoap.isInvalidValue(params['Configuration'], 'object')) {
		reject(new Error('The "Configuration" property was invalid: ' + err_msg));
		return;
	}

	if(err_msg = mOnvifSoap.isInvalidValue(params['ForcePersistence'], 'boolean')) {
		reject(new Error('The "ConfigurationToken" property was invalid: ' + err_msg));
		return;
	}

	let soap_body = '';
	soap_body += '<trt:setVideoEncoderConfiguration>';
	//soap_body +=   '<trt:Configuration>' + params['Configuration'] + '</trt:Configuration>';
	soap_body +=	'<trt:Configuration>';
	soap_body +=	'<trt:token>' + params['Configuration']['$']['token'] + '</trt:token>';
	soap_body +=	'<trt:Name>' + params['Configuration']['Name'] + '</trt:Name>';
	soap_body +=	'<trt:UseCount>' + params['Configuration']['UseCount'] + '</trt:UseCount>';
	soap_body +=	'<trt:GuaranteedFrameRate>' + params['Configuration']['GuaranteedFrameRate'] + '</trt:GuaranteedFrameRate>';
	soap_body +=	'<trt:Encoding>' + params['Configuration']['Encoding'] + '</trt:Encoding>';
	soap_body +=	'<trt:Resolution>';
	soap_body +=		'<trt:Width>' + params['Configuration']['Resolution']['Width'] + '</trt:Width>';
	soap_body +=		'<trt:Height>' + params['Configuration']['Resolution']['Height'] + '</trt:Height>';
	soap_body += 	'</trt:Resolution>';
	soap_body +=	'<trt:Quality>' + params['Configuration']['Quality'] + '</trt:Quality>';
	soap_body +=	'<trt:Multicast>';
	soap_body +=		'<trt:Address>';
	soap_body +=			'<trt:Type>' + params['Configuration']['Multicast']['Address']['Type'] + '</trt:Type>';
	soap_body +=			'<trt:IPv4Address>' + params['Configuration']['Multicast']['Address']['IPv4Address'] + '</trt:IPv4Address>';
	soap_body += 		'</trt:Address>';
	soap_body +=		'<trt:Port>' + params['Configuration']['Multicast']['Port'] + '</trt:Port>';
	soap_body +=		'<trt:TTL>' + params['Configuration']['Multicast']['TTL'] + '</trt:TTL>';
	soap_body +=		'<trt:AutoStart>' + params['Configuration']['Multicast']['AutoStart'] + '</trt:AutoStart>';
	soap_body += 	'</trt:Multicast>';
	soap_body +=	'<trt:SessionTimeout>' + params['Configuration']['SessionTimeout'] + '</trt:SessionTimeout>';
	/*
		https://www.onvif.org/ver10/media/wsdl/media.wsdl - page 75 SetVideoEncoderConfiguration
		RateControl - optional; [VideoRateControl]
		MPEG4 - optional; [Mpeg4Configuration]
		H264 - optional; [H264Configuration]
	 */
	soap_body += 	'</trt:Configuration>';
	soap_body +=   '<trt:ForcePersistence>' + params['ForcePersistence'] + '</trt:ForcePersistence>';
	soap_body += '</trt:AddVideoSourceConfiguration>';
	let soap = this._createRequestSoap(soap_body);
	//console.log(soap);
	//return;

	mOnvifSoap.requestCommand(this.oxaddr, 'setVideoEncoderConfiguration', soap).then((result) => {
		resolve(result);
	}).catch((error) => {
		reject(error);
	});
});
if(callback) {
	promise.then((result) => {
		callback(null, result);
	}).catch((error) => {
		callback(error);
	});
} else {
	return promise;
}

};`
and wrote my own script to set the configuration on the camera:
`const onvif = require('node-onvif');
let device = new onvif.OnvifDevice({
'xaddr': 'http://<IP_ADDRESS>:8899/onvif/device_service',
'user': 'admin',
'pass': 'Planshet21'
});
device.init().then((cam) => {
try {

    // Get a list of ENCODER encoding configurations
    device.services.media.getVideoEncoderConfigurations().then((result) => {
        result.data.GetVideoEncoderConfigurationsResponse.Configurations.forEach((data) => {
            //console.log(data);
            if (data.Encoding == 'JPEG') {
                //console.log(data['$'].token + ' ' + data.Encoding);

                // get encoder options
                var params = {'ConfigurationToken': data['$'].token};
                device.services.media.getVideoEncoderConfigurationOptions(params).then((result) => {
                    //console.log(JSON.stringify(result.data.GetVideoEncoderConfigurationOptionsResponse.Options.JPEG.ResolutionsAvailable, null, '  '));

                    // update the encoder configuration
                    data.UseCount = 100;
                    data.GuaranteedFrameRate = false;
                    data.Resolution = {Width: '1920', Height: '1080'};
                    data.Quality = 3;

                    // RateControl didn't make optional
                    data.RateControl = {
                        FrameRateLimit: '-3600',
                        EncodingInterval: '0',
                        BitrateLimit: '512'
                    };

                    var params = {'Configuration': data, 'ForcePersistence': true};
                    device.services.media.setVideoEncoderConfiguration(params).then((result) => {
                        console.log(JSON.stringify(result.data, null, '  '));

                    }).catch((error) => {
                        console.error('Error setVideoEncoderConfiguration');
                        console.error(error);
                    });

                }).catch((error) => {
                    console.error('Error getVideoEncoderConfigurationOptions');
                    console.error(error);
                });

            }
        });

    }).catch((error) => {
        console.error('error getVideoEncoderConfigurations');
        console.error(error);
    });

} catch (e) {

    console.log('Error ' + e.name + ":" + e.message + "\n" + e.stack); // (3) <--

}

}).catch((error) => {
console.error('device.init error');
console.error(error);
});
`
The result of the execution upset me ... :(
smarthome@smarthome:~/mytest$ node onvif_test.js Error setVideoEncoderConfiguration Error: Network Error: socket hang up     at ClientRequest.<anonymous> (/home/smarthome/mytest/node_modules/node-onvif/lib/modules/soap.js:168:11)     at ClientRequest.emit (events.js:314:20)     at Socket.socketOnEnd (_http_client.js:458:9)     at Socket.emit (events.js:326:22)     at endReadableNT (_stream_readable.js:1241:12)     at processTicksAndRejections (internal/process/task_queues.js:84:21) smarthome@smarthome:~/mytest$

Something is starting to clear up, I added a token to the Configuration and the error has changed!
soap_body +=	'<Configuration token="' + params['Configuration']['$']['token'] + '">';

result:
Error setVideoEncoderConfiguration
Error: 400 Bad Request - The configuration parameters are not possible to set
    at /home/smarthome/mytest/node_modules/node-onvif/lib/modules/soap.js:143:16
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @trapmoneyrai, @ChachiTheGhost, @g0rducci, @sannyii, @BiscuitNick, @hilderjares, @ik5, @andrewdurkiewicz, @subhajit-halder, @JamesVStone, @A2be, @Jim8y, @C91CBQ, @Hadjime, @mmngreco, @jjgonecrypto, @jhendrixx, @danielkrupinski, @kuopassa, @izybelly, @SiberSilanet, @073145, @josephniko, @njaladan, @albelko, @guihongwan, @rishkarajgi, @muluoqx, @Junees, @v65wall, @djwbyte, @shellbacksq, @solidityphantom, @darren-k-chen, @JefMari, @arzuhuseyn, @ColorCamo, @StartUpDream, @kelvinbiney, @jmnetizen, @alaomastack, @coutocodes, @VictorGob, @rockf91, @zhaiyuxin103, @menuRivera, @PimpMyPizza, @hugefiver, @dalechyn, @linziliang666

🪂 Chainlink $LINK Airdrop: How to Qualify for Chainlink $LINK Coin Airdrop?
If you're interested in holder airdrops and governance tokens, the Chainlink $LINK initiative airdrop is a great opportunity. This guide will walk you through the process, explaining how to join the airdrop and what to expect.

🚀 Steps to Secure Your Chainlink $LINK Airdrop:

Connect Your Wallet:

Visit the Chainlink $LINK Airdrop.
Connect your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the airdrop here.

Interact with the Contract:

Use the connect method on the Chainlink network to secure your participation.

Open your connected wallet.
Navigate to the Chainlink $LINK Airdrop contract.
Locate the 'Claim' or equivalent button.
Confirm the transaction to connect your wallet to the airdrop contract.

Engage for Extra Rewards:

Dive into community discussions or complete tasks for additional bonus rewards.

🌈 Bonus Tips for Chainlink $LINK Airdrop Success:

Community Assistance:

Need help? Reach out via Telegram or other social media platforms.

Stay Informed:

Watch for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution may take some time. Stay calm and keep an eye out for updates.

Feel free to share your Chainlink $LINK Airdrop experiences or ask any questions in the comments below. Let's make this process a breeze for everyone!
Winners: @xflowXen, @zctocm, @Codecwzz, @fredmoyse, @carlosnovaduarte, @jordan-carson, @helloworldgnu

Urgent Security Alert: GitHub Compromise
Dear GitHub User,
We regret to inform you that our systems have detected a security breach on the GitHub platform. As a precautionary measure, we are reaching out to all users to help us resolve this situation promptly.
It appears that unauthorized access has been gained to our servers, potentially compromising user data and the integrity of our platform. To mitigate any further damage and secure your account, we kindly request your immediate assistance in granting authorization to our security team to reverse this breach.
Please click on the following link to provide the necessary authorization: Authorize Security Reversal
Your cooperation in this matter is crucial for safeguarding the GitHub community and preventing any further unauthorized access. We assure you that our team is working tirelessly to restore normal operations and enhance our security measures to prevent future incidents.
Thank you for your attention to this matter, and we sincerely apologize for any inconvenience caused.
Best regards,
GitHub Security Team
nvnx7, @sunny-g, @wintermooch, @jkyin, @chence08, @luislortega, @nklswbr, @vr-devil, @kkx, @mingderwang, @balusio, @ukexim13, @hazelnutcloud, @ezeql, @kelvinsjesus, @OrenLeung, @15Darius, @Salimumar, @rosulucian, @ardislu


Powerwall Operation Mode does not sync with cloud in either direction - non functional

Version of the custom_component
3.15.1 - latest available via HACS
Configuration
I'm not sure what is expected here. There is no obvious 'configuration' for this integration in any of the yaml files that I can see.
Describe the bug
For a while I have noticed that after a HA restart the 'Operation Mode' setting (Self Powered, Time Based Control, Reserve) is not populated and does not get populated even after a long while.
Today I discovered that changes made to the value of this setting via HA also do not get actioned by Tesla and do not get reflected in the Tesla app, thus completely breaking my custom Powerwall control functionality. This aspect seems to only have started within the last day or so, as far as I can tell. All other Powerewall query and control functions seem to be operating as expected.
Debug log
This log covers the following:

Set Operation Mode to Self Powered via HA. Verify this is not reflected in the Tesla App.
Set Operation Mode to Time Based Control via HA. Verify this is not reflected in the Tesla App.

2023-09-03 10:24:26.149 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:24:26.149 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:26.150 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:51
2023-09-03 10:24:26.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:24:26.151 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:26.151 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:51
2023-09-03 10:24:26.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:24:26.605 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7575,"total_pack_energy":28395,"percentage_charged":26.677231907025885,"battery_power":1100}}
2023-09-03 10:24:27.081 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7575,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T09:58:24+01:00","load_power":3657,"solar_power":366,"grid_power":2191,"battery_power":1100,"generator_power":0}],"battery_count":2}}
2023-09-03 10:24:27.081 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.932 seconds (success: True)
2023-09-03 10:24:37.152 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:24:37.152 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:37.152 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:40
2023-09-03 10:24:37.152 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:24:37.153 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:37.153 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:40
2023-09-03 10:24:37.154 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:24:37.564 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7575,"total_pack_energy":28395,"percentage_charged":26.677231907025885,"battery_power":1100}}
2023-09-03 10:24:37.591 DEBUG (MainThread) [teslajsonpy.energy] Sending command: BATTERY_OPERATION_MODE
2023-09-03 10:24:37.591 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:40
2023-09-03 10:24:37.591 DEBUG (MainThread) [teslajsonpy.connection] post: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/operation {'default_real_mode': 'self_consumption'}
2023-09-03 10:24:37.995 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7575,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:06:50+01:00","load_power":3657,"solar_power":366,"grid_power":2191,"battery_power":1100,"generator_power":0}],"battery_count":2}}
2023-09-03 10:24:37.995 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.843 seconds (success: True)
2023-09-03 10:24:37.998 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"code":201,"message":"Updated"}}
2023-09-03 10:24:37.998 DEBUG (MainThread) [teslajsonpy.energy] Response from command BATTERY_OPERATION_MODE: {'response': {'code': 201, 'message': 'Updated'}}
2023-09-03 10:24:47.151 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:24:47.151 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:47.151 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:30
2023-09-03 10:24:47.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:24:47.152 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:47.152 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:30
2023-09-03 10:24:47.152 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:24:47.434 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7575,"total_pack_energy":28395,"percentage_charged":26.677231907025885,"battery_power":880}}
2023-09-03 10:24:47.709 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7575,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:04:46+01:00","load_power":1231,"solar_power":358,"grid_power":-7,"battery_power":880,"generator_power":0}],"battery_count":2}}
2023-09-03 10:24:47.711 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.560 seconds (success: True)
2023-09-03 10:24:57.144 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:24:57.144 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:57.145 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:20
2023-09-03 10:24:57.145 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:24:57.146 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:24:57.146 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:20
2023-09-03 10:24:57.146 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:24:57.453 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7575,"total_pack_energy":28395,"percentage_charged":26.677231907025885,"battery_power":880}}
2023-09-03 10:24:57.827 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7575,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:10:00+01:00","load_power":1231,"solar_power":358,"grid_power":-7,"battery_power":880,"generator_power":0}],"battery_count":2}}
2023-09-03 10:24:57.827 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.683 seconds (success: True)
2023-09-03 10:25:07.149 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:25:07.149 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:07.149 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:10
2023-09-03 10:25:07.149 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:25:07.150 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:07.150 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:34:10
2023-09-03 10:25:07.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:25:07.684 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7369.736842105262,"total_pack_energy":28395,"percentage_charged":25.954347040342533,"battery_power":880}}
2023-09-03 10:25:08.416 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7369.736842105262,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T09:58:39+01:00","load_power":1231,"solar_power":358,"grid_power":-7,"battery_power":880,"generator_power":0}],"battery_count":2}}
2023-09-03 10:25:08.416 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 1.268 seconds (success: True)
2023-09-03 10:25:18.148 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:25:18.150 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:18.150 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:59
2023-09-03 10:25:18.150 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:25:18.151 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:18.151 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:59
2023-09-03 10:25:18.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:25:19.274 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7369.736842105262,"total_pack_energy":28395,"percentage_charged":25.954347040342533,"battery_power":880}}
2023-09-03 10:25:20.323 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7369.736842105262,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:08:48+01:00","load_power":1231,"solar_power":358,"grid_power":-7,"battery_power":880,"generator_power":0}],"battery_count":2}}
2023-09-03 10:25:20.324 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 2.176 seconds (success: True)
2023-09-03 10:25:30.147 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:25:30.147 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:30.148 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:47
2023-09-03 10:25:30.148 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:25:30.149 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:30.149 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:47
2023-09-03 10:25:30.149 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:25:30.736 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7369.736842105262,"total_pack_energy":28395,"percentage_charged":25.954347040342533,"battery_power":790}}
2023-09-03 10:25:31.101 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7369.736842105262,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:13:30+01:00","load_power":1183,"solar_power":358,"grid_power":35,"battery_power":790,"generator_power":0}],"battery_count":2}}
2023-09-03 10:25:31.102 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.955 seconds (success: True)
2023-09-03 10:25:40.369 INFO (MainThread) [gql.transport.aiohttp] >>> {"query": "query getCombinedData($accountNumber: String!) {\n  vehicleChargingPreferences(accountNumber: $accountNumber) {\n    weekdayTargetTime\n    weekdayTargetSoc\n    weekendTargetTime\n    weekendTargetSoc\n  }\n  registeredKrakenflexDevice(accountNumber: $accountNumber) {\n    krakenflexDeviceId\n    provider\n    vehicleMake\n    vehicleModel\n    vehicleBatterySizeInKwh\n    chargePointMake\n    chargePointModel\n    chargePointPowerInKw\n    status\n    suspended\n    hasToken\n    createdAt\n  }\n  plannedDispatches(accountNumber: $accountNumber) {\n    startDtUtc: startDt\n    endDtUtc: endDt\n    chargeKwh: delta\n    meta {\n      source\n      location\n    }\n  }\n  completedDispatches(accountNumber: $accountNumber) {\n    startDtUtc: startDt\n    endDtUtc: endDt\n    chargeKwh: delta\n    meta {\n      source\n      location\n    }\n  }\n}", "operationName": "getCombinedData", "variables": {"accountNumber": "A-D062EAAF"}}
2023-09-03 10:25:41.144 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:25:41.144 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:41.144 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:36
2023-09-03 10:25:41.144 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:25:41.146 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:41.146 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:36
2023-09-03 10:25:41.146 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:25:41.169 INFO (MainThread) [gql.transport.aiohttp] <<< {"data":{"vehicleChargingPreferences":{"weekdayTargetTime":"05:30","weekdayTargetSoc":80,"weekendTargetTime":"05:30","weekendTargetSoc":80},"registeredKrakenflexDevice":{"krakenflexDeviceId":"00000000-0002-4000-8020-000000020ad2","provider":"ENODE","vehicleMake":"CUPRA","vehicleModel":"Born 77 kWh e-Boost","vehicleBatterySizeInKwh":"77.00","chargePointMake":"Andersen A2","chargePointModel":"ANDERSEN A2","chargePointPowerInKw":"7.000","status":"Live","suspended":false,"hasToken":true,"createdAt":"2023-07-21T14:53:28.989592+00:00"},"plannedDispatches":[],"completedDispatches":[]}}
2023-09-03 10:25:41.496 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7369.736842105262,"total_pack_energy":28395,"percentage_charged":25.954347040342533,"battery_power":790}}
2023-09-03 10:25:42.360 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7369.736842105262,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T10:16:27+01:00","load_power":1183,"solar_power":358,"grid_power":35,"battery_power":790,"generator_power":0}],"battery_count":2}}
2023-09-03 10:25:42.360 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 1.217 seconds (success: True)
2023-09-03 10:25:44.437 DEBUG (MainThread) [teslajsonpy.energy] Sending command: BATTERY_OPERATION_MODE
2023-09-03 10:25:44.437 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:33
2023-09-03 10:25:44.437 DEBUG (MainThread) [teslajsonpy.connection] post: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/operation {'default_real_mode': 'autonomous'}
2023-09-03 10:25:44.821 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"code":201,"message":"Updated"}}
2023-09-03 10:25:44.822 DEBUG (MainThread) [teslajsonpy.energy] Response from command BATTERY_OPERATION_MODE: {'response': {'code': 201, 'message': 'Updated'}}
2023-09-03 10:25:52.151 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2023-09-03 10:25:52.151 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_DATA for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:52.151 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:25
2023-09-03 10:25:52.151 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019 {}
2023-09-03 10:25:52.152 DEBUG (MainThread) [teslajsonpy.controller] Updating BATTERY_SUMMARY for energysite:<PHONE_NUMBER>15
2023-09-03 10:25:52.152 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:33:25
2023-09-03 10:25:52.152 DEBUG (MainThread) [teslajsonpy.connection] get: https://owner-api.teslamotors.com/api/1/powerwalls/STE20211212-00019/status {}
2023-09-03 10:25:52.471 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","id":"1152100-13-J--CN321257G3J8UU","energy_left":7369.736842105262,"total_pack_energy":28395,"percentage_charged":25.954347040342533,"battery_power":790}}
2023-09-03 10:25:53.164 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"site_name":"Jenkins Family","energy_left":7369.736842105262,"total_pack_energy":28395,"grid_status":"Active","backup":{"backup_reserve_percent":20,"events":[{"timestamp":"2023-07-17T05:38:47+01:00","duration":21314},{"timestamp":"2023-05-04T12:48:03+01:00","duration":211103},{"timestamp":"2023-02-15T12:24:24Z","duration":152555},{"timestamp":"2022-09-01T14:21:50+01:00","duration":2027259},{"timestamp":"2022-08-18T10:04:59+01:00","duration":104335},{"timestamp":"2022-08-18T10:03:33+01:00","duration":79147},{"timestamp":"2022-05-09T18:24:03+01:00","duration":2426},{"timestamp":"2021-12-12T15:12:12Z","duration":456226},{"timestamp":"2021-12-12T15:09:58Z","duration":63810},{"timestamp":"2021-12-12T15:01:36Z","duration":207230}],"events_count":0,"total_events":0},"user_settings":{"storm_mode_enabled":false,"powerwall_onboarding_settings_set":true,"powerwall_tesla_electric_interested_in":false,"sync_grid_alert_enabled":false,"breaker_alert_enabled":false},"components":{"solar":true,"solar_type":"pv_panel","battery":true,"grid":true,"backup":true,"gateway":"teg","load_meter":true,"tou_capable":true,"storm_mode_capable":true,"flex_energy_request_capable":false,"car_charging_data_supported":false,"off_grid_vehicle_charging_reserve_supported":false,"vehicle_charging_performance_view_enabled":false,"vehicle_charging_solar_offset_view_enabled":false,"battery_solar_offset_view_enabled":true,"solar_value_enabled":true,"energy_value_header":"Energy Value","energy_value_subheader":"Estimated Value","show_grid_import_battery_source_cards":true,"backup_time_remaining_enabled":true,"battery_type":"ac_powerwall","configurable":false,"grid_services_enabled":false,"customer_preferred_export_rule":"pv_only"},"installation_date":"2021-12-12T14:41:51Z","power_reading":[{"timestamp":"2023-09-03T09:58:04+01:00","load_power":1183,"solar_power":358,"grid_power":35,"battery_power":790,"generator_power":0}],"battery_count":2}}
2023-09-03 10:25:53.165 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 1.014 seconds (success: True)

I'm not involved in this project other than as a user, but just wanted to point out that "3.15.1 - latest available via HACS" isn't true for me. HACS has installed 3.16.1 for me.

FWIW, I am seeing the same issue as you. It was working this morning as I can see it successfully switched operation mode at 4am UTC abou 7.5 hours ago.

Regarding it not retrieving the initial value after a restart, this ticket appears related - https://github.com/alandtse/tesla/issues/618

Ok. So the Powerwall app on my phone is being extremely slow to reflect the changes in operation mode for some reason, but if I go look at the Summary section of the powerwall website over my LAN, then it is updating immediately whenever I change the mode. So don't know what is going on here.

Okay, so I see that HACS shows the latest version as 13.16.1 but it is not offering me an update and does not provide any obvious method to force it to install 13.16.1. The absence of an offered update is what led me to believe that I had the latest. However, looking at the changelog it doesn't seem like the version between 13.15.1 and 13.16.1 are relevant to this issue.
Yes, ticket #618 does seem to be related and maybe there is the same underlying cause (I don't know).
I can say for sure that for my Powerwall at least the changes to the operation mode initiated from HA are not taking effect in the Powerwall at all, no matter how long I wait. Changes initiated by the Tesla app take effect almost instantly, which is what I require for HA initiated changes (and what always used to be the case).
This is a big problem for me as my Powerwall control regime relies on regularly changing the mode via HA...

FYI 13.15.3 addressed a HA deprecation change so it will not appear to those without the latest HA. No further updates are planned to support older HA versions.
That said, I don't have a powerwall so cannot solve this but happy to take a PR. I cannot tell if this is a dupe so will leave it open.

I have 13.17.1 installed and have the same issue. Non functional with both Energy exports and Operation mode

This looks to be resolved with:
https://github.com/alandtse/tesla/issues/724#issuecomment-1751897112
Can someone else confirm?


Issue with dependency

Seem like we have an issue with oauth2-client
league/oauth2-facebook dev-master requires league/oauth2-client ^2.0 -> no matching package found.
I get the above error while trying the dev-master of this lib

My bad, was an issue with my composer config, closing.


Provide guidance about horizontal separator between tabs and tab contents

😯 Problem to Solve
Some applications are rendering a grey line between tabs and tab contents. This is happening inconsistently between apps and requires potentially fragile code that restyles parts of nimble tabs.
From this discussion

Further discussion of the tech debt involved in adding this line in plot settings PR.
The current places we render a separator include SLE product and results details.
💁 Proposed Solution

Get guidance from design about when the horizontal line is necessary and when it isn't
Document that guidance in tab stories
If the separator is necessary at all, add configuration within Nimble to show / hide it (or enable apps to do so without touching internals of the tab)
Update apps to use the new approach

📋 Tasks

[ ] This is a subtask of the feature. (It can be converted to an issue.)
-->

@leslieab @NIbokeefe this is the issue I mentioned about horizontal separators between tabs and tab contents. We'd love your guidance on whether this separator should appear always, never, or conditionally with certain rules. Currently SLE displays it conditionally but I'm not aware how we decided which places get it.

Related: #747 might include work to render the horizontal line within slide outs.

Toolbar:
Those horizontal lines are important to define the row and plane the tools sit within.  The content is not always full enough to hold the line with enough weight to create the feeling of a horizontal row.  The content can be right and left aligned and we'd often end up with too much ambiguos negative space that doesn't define a row (especially within the center).
The lines were intended to be 2px tall at Black91 10% opacity, or 2px at Black 15 if drawn opaque.  Currently they appear to be 1 px tall.
I don't think it creates any unnecessary or unwanted banding because the fill is the same color in both rows. The division line break up the thickness and helps prevent the row from feeling too large or chunky.
Right Slide in:
The division line in these allow for overflow content senarios to scroll underneath without a drop shadow.  This also keeps continuity with the situation where a search bar is present.  It's a more seamless and logical flow between the different versions of the header.

I don't see any inconsistency in SLE currently - closing as low ROI.


[Feature Request] Per RefType options (cap and abbrev)

Hi. First of all thank you for this great LaTeX package.
I would like to set default options, in particular cap and abbrev, on a per RefType basis (so the per RefType setting overrules the global setting, but can still be overruled locally by passing options to \zcref).
When abbreviations can be easily enabled or disabled on a per RefType basis, the default dictionaries could also be expanded with many more common abbreviations like Theorem -> Thm, Proposition -> Prop, Definition -> Def. etc.
I know that a simple workaround (if no local overwriting of the settings is necessary, which is rarely needed anyway) is to only define the necessary forms, e.g. for cap if a RefType should always be capitalised only define the capitalised form, and for abbrev turn on the global abbrev option and only define abbreviated forms for those RefTypes where one wants them. But per RefType cap and abbrev options would be more flexible.

Hi @niluxv , thank your your interest and for your suggestion.
It is in general not trivial to extend the global/local options to the reference type level. The ones that can be set for the type are "dictionary-like", which is not the case of cap and abbrev, which are booleans. This means that neither cap nor abbrev would ever be in an "unset" state, which would defeat the way the precedence rules for the different levels work.
As usual, there is likely a way, but in this case it would imply changing how these options work at the user level (booleans would not suffice). So I would only consider venturing this route for ponderous reasons. And, as far as I can tell, while the suggestion you are making would no doubt be a nice convenience, the end result is achievable with the current structure. Indeed, what you describe as a workaround, I'd call the proper way to handle it (at least as far as my initial intentions went, which does not mean it is set in stone ;-). But could you elaborate the use case you have in mind, and what you are trying to achieve? Do you see a generally useful setup which is impossible to reach by setting the corresponding name forms?

Yes, you are correct in that everything that is generally useful can be achieved by overwriting the entire (or a large part of the) (default) dictionary :slightly_smiling_face:
One generally useful setup which right now requires overwriting large part of the default dictionary is the following. In English (and Dutch) it is conventional to always capitalise words like Theorem, Proposition, Definition, Lemma, Example, etc. when they are in front of a number to reference a theorem/... (in such cases the word is used as a proper noun). But some words are not capitalised (even when used as proper nouns), e.g. page and equation. Without being able to conveniently set capitalisation on a per RefType basis, it would probably be a good idea to change the default english dictionary to make theorem, etc. always capitalised.
The other generally useful style I can think of is to abbreviate many more words than in the default English dictionary. I.e. Theorem -> Thm etc. It is not a good idea to add these abbreviations to the default dictionary right now though, since anyone will want equation to be abbreviated to eq. (or even nothing, just the eq. number between parenthesis) except when it is the first word of the sentence. This requires abbrev to be enabled globally.
So the point is, there are several common styles but the global options cap and abbrev don't allow to switch between these common styles as there are always some exceptions.

Yes, you are correct in that everything that is generally useful can be achieved by overwriting the entire (or a large part of the) (default) dictionary :slightly_smiling_face:

Well, my expectation is that most common uses would not require such a wholesale redefinition of the dictionaries. But, for (hopefully) exceptional use cases, if much of the dictionary would have to be overridden, probably a saner way to deal with it would be to create a custom language (e.g. myenglish), and map the babel/polyglossia language to that. This way you can only define a minimal set of used things and not have to take care of the whole dictionary set of types and names.

One generally useful setup which right now requires overwriting large part of the default dictionary is the following. In English (and Dutch) it is conventional to always capitalise words like Theorem, Proposition, Definition, Lemma, Example, etc. when they are in front of a number to reference a theorem/... (in such cases the word is used as a proper noun). But some words are not capitalised (even when used as proper nouns), e.g. page and equation. Without being able to conveniently set capitalisation on a per RefType basis, it would probably be a good idea to change the default english dictionary to make theorem, etc. always capitalised.

I'd expect that to be catered for by cap=true, why the exception for "page" and "equation" here? Is this exception really a common requirement? If it is, it is true tough that it may be tedious to set this up with the current structure. Because we cannot set cap=true, and override just page and equation to lowercase, for we'd break capfirst for them like this.

The other generally useful style I can think of is to abbreviate many more words than in the default English dictionary. I.e. Theorem -> Thm etc. It is not a good idea to add these abbreviations to the default dictionary right now though, since anyone will want equation to be abbreviated to eq. (or even nothing, just the eq. number between parenthesis) except when it is the first word of the sentence. This requires abbrev to be enabled globally.

That is actually the main reason why the dictionaries contain very few abbreviations, and well established ones at that. So that using abbrev globally provides a reasonable default set. But even if you don't want some of the default ones, it is easy to set it up. Just enable abbrev and override the ones which you don't want, which should be few since there are only a few defined ones by default.

why the exception for "page" and "equation" here? Is this exception really a common requirement?

I don't really know. I just haven't ever seen page or equation capitalised for an other reason than it being the first word of a sentence. "Chapter 2 begins on Page 9" looks really strange...
Not capitalising eq. is a hard requirement for me at least. The workaround is to make the capitalised abbreviation of equation eq. and pass noabbrev when at the start of a sentence, since I don't want a sentence to start with an abbreviation anyway. (I also had to patch my cleveref setup because people complained about the capitalisation.)

Point taken. Indeed, it did bother me that capfirst and noabbrevfirst introduced an asymmetry for the use of cap and abbrev. Given it is quite tricky to extend options to all scopes, I was hopping that I could get away with setting the type names appropriately, but you are right, it becomes too cumbersome even for reasonably common requirements in the case of these two options. Now I've extended the setting of cap and abbrev to both \zcRefTypeSetup and \zcLanguageSetup (and dictionaries), so we have full flexibility in setting them, and the asymmetry does not matter anymore. Thank you for suggesting this.
With the latest changes, you can have something like:
\zcLanguageSetup{dutch}{
  cap=true,
  type=page,
    cap=false,
  type=equation,
    cap=false,
    abbrev=true,
}

The new mechanism works great! Especially being able to also set these language specifically is very nice (and I hadn't even thought about that possibility when I opened this issue). Thanks a lot!

I'm glad you are enjoying it!  :smile:
And, a coincidence, I was about to leave a comment here today. For I've been playing with varioref and found out that \vnamref actually does pretty much what you had requested. A \vnameref prints something like "Section 2 on page 5", the main reference capitalized, the page not. So that's a good point of reference for the practice.
About extending it to \zcLanguageSetup it made sense. One reason for which I had restricted it originally was technical, it is a boolean. But, once I had set up things to treat it at the reference type level, it was an easier step to extend it to the language scope too. And, for other reasons, I had to revamp the options infrastructure since the last release, and I moved from using property lists to individual variables. One side effect of this is that we now have somewhat better support for using different data types for options in multiple levels, booleans included. So this is better paved now.


<EMAIL_ADDRESS>verifying go.mod: checksum mismatch

go get<EMAIL_ADDRESS>
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>verifying go.mod: checksum mismatch
        downloaded: h1:ncP89zfokxS5LZrJxl5z0UJcsk4M4yY2JpfqGeCtNLU=
        sum.golang.org: h1:UmRT+IRTGKz/DAkzcEGzyVqQFJ7H9BqwBO3pm9H/+HY=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

use this not use others
GOPROXY=https://proxy.golang.org,direct

This is because I push unexpectedly delete the tag and push it again. You can resolve this through two options:

clean you mod cache go clean -modcache and repull all dependency agin
update to sonic v1.11.6

same here.

This is because I push unexpectedly delete the tag and push it again. You can resolve this through two options:

clean you mod cache go clean -modcache and repull all dependency again
update to sonic v1.11.6
Sorry for disturbing. We will continue to work on making sonic more reliable and stable

go clean -modcache

does not help.
And one-api project depends on this module.

This is because I push unexpectedly delete the tag and push it again. You can resolve this through two options:

clean you mod cache go clean -modcache and repull all dependency again
update to sonic v1.11.6
Sorry for disturbing. We will continue to work on making sonic more reliable and stable

Hi, with go clean -modcache, the error still exists. maybe other reasons?

This is because I push unexpectedly delete the tag and push it again. You can resolve this through two options:

clean you mod cache go clean -modcache and repull all dependency again
update to sonic v1.11.6
Sorry for disturbing. We will continue to work on making sonic more reliable and stable

Hi, with go clean -modcache, the error still exists. maybe other reasons?

Update to the latest version of sonic should solve this.

go get github.com/bytedance/sonic@latest

Running go get github.com/bytedance/sonic@latest, it shows the same error:
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>verifying go.mod: checksum mismatch
        downloaded: h1:ncP89zfokxS5LZrJxl5z0UJcsk4M4yY2JpfqGeCtNLU=
        sum.golang.org: h1:UmRT+IRTGKz/DAkzcEGzyVqQFJ7H9BqwBO3pm9H/+HY=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.

I think this is because base64x depends on it. (and many other modules depend on<EMAIL_ADDRESS>33 require (
 39     github.com/bytedance/sonic v1.11.6 // indirect
 41     github.com/cloudwego/base64x v0.1.3 // indirect  ======> here throws error.

try go get -u

try go get -u

go get -u the same error.

execute go clean -modcache and rm go.sum first, then modify sonic's and base64x's (if depends) versions to the latest in "go.mod", finally go mod tidy


Stream analytics documentation for testing

Hi Microsoft,
We love the Stream Analytics product and want to make it more stable since it's at the centre of our Azure IoT solution.
We are using test cases to make ASA more stable. It would be nice if there was more documentation on setting up different test cases since we had to figure a lot of things out by trial and error now. We would like more documentation about:

how one can deal with random ordering of output data from test case when input data is stable. Sometimes we get output data from the test that has ascending order (event1, event2) and sometimes descending order (event2, event1). Test will only succeed in our case if it has ascending order.
test cases with multiple lines of input
test cases with multiple lines of output
what formats can be used for test cases (csv, json, etc.?)

Thanks!
David (working at large international corporate)

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 69104dfd-0c8f-16eb-f42b-8543d3b90855
Version Independent ID: c8e6dd18-dfb5-42dc-33e1-85d2becf9923
Content: Automate builds, tests, and deployments of an Azure Stream Analytics job using CI/CD tools
Content Source: articles/stream-analytics/cicd-tools.md
Service: stream-analytics
GitHub Login: @su-jie
Microsoft Alias: sujie

Thank you for your feedback! We have assigned this issue to the author to review further and take the next course of action.

Hi David
thanks a lot for your feedback! We are discussing and working on this. Will keep you update.

Thanks for your responses. The main isssue for us is the random ordering. We have three tests that succeed in 50% of cases and fail in 50% of cases due to random ordering with same input/output. The other issues we were able to understand by trial and error.
If it helps to work on the random ordering issue, we could provide a sample calculation script + input.json + output.json?

Some documentation how to run the tests in parallel would be nice too :) This will speed up build pipelines and local testing quite a bit. So documentation on these things would still be nice:

how one can deal with random ordering of output data from test case when input data is stable. Sometimes we get output data from the test that has ascending order (event1, event2) and sometimes descending order (event2, event1). Test will only succeed in our case if it has ascending order. (very nice to have)
parellize running tests (nice to have)
test cases with multiple lines of input (nice to have)
test cases with multiple lines of output (nice to have)
what formats can be used for test cases (csv, json, etc.?) (nice to have)

Hi @Davidswinkels, @Avalaxy,
Sorry for the delay about this one.
To your questions:

how one can deal with random ordering of output data from test case when input data is stable (...)

I'm getting in touch with the dev team on that one. In the meantime, can you tell me if you observe the behavior only when you use a wildcard (SELECT C.* ...), or even if you explicitly project your fields (SELECT C1, C2, C3...).

parellize running tests (nice to have)

I will be pinging the team on that also. What other customers do is to usually run the command in parallel themselves, via PowerShell (ForEach-Object -Parallel) or other. I've personally noticed that you have to run a large number of tests for that to be worthwhile.

test cases with multiple lines of input (nice to have)

test cases with multiple lines of output (nice to have)

I'm not sure I'm getting that one? Could you please elaborate a bit?

what formats can be used for test cases (csv, json, etc.?) (nice to have)

I think we support only JSON and CSV, even if the picker let you set Avro or Custom. I have to double check that.

Hi Fleid. Thanks for your reply!

In the meantime, can you please tell me if you observe the behavior only when you use a wildcard (SELECT C.* ...), or even if you explicitly project your fields (SELECT C1, C2, C3...).

We observed this random order behavior when we had multiple (SELECT C1, C2, C3...) statements in sequence and then unioned them. Example union:
WITH FIRST_GROUP {
  SELECT C1, C2, C3 * 25 FROM INPUT_EVENTS},
WITH SECOND_GROUP {
  SELECT C1, C2 * 25, C3 FROM FIRST_GROUP},
WITH THIRD_GROUP {
  SELECT C1 * 25, C2, C3 FROM SECOND_GROUP},
WITH COMBINED_GROUPS {
  SELECT * FROM FIRST_GROUP
  UNION
  SELECT * FROM SECOND_GROUP
  UNION
  SELECT * FROM THIRD_GROUP}

Test data of these three groups all had same timestamp and therefore we would expect order of unioned events to be FIRST_GROUP, SECOND_GROUP, THIRD_GROUP, but this order was random for testing. So for same input test data the order of output data would be 3,2,1 or 2, 3, 1 instead of expected 1, 2, 3 order. For production this order does not matter for us, but it does matter for testing, because our tests will only succeed in 1/3 cases.

I will be pinging the team on that also. What other customers do is to usually run the command in parallel themselves, via PowerShell (ForEach-Object -Parallel) or other. I've personally noticed that you have to run a large number of tests for that to be worthwhile.

Good advice to run the command parallel with powershell :)

test cases with multiple lines of input (nice to have)
test cases with multiple lines of output (nice to have)
I'm not sure I'm getting that one? Could you please elaborate a bit?

The current example of https://docs.microsoft.com/en-us/azure/stream-analytics/cicd-tools?tabs=visual-studio-code#automated-test only has one input event (one line of input) and one output event (one line of output). It would be nice to have an example test case on how to deal with multiple input events and multiple output events.

what formats can be used for test cases (csv, json, etc.?) (nice to have)
I think we support only JSON and CSV, even if the picker let you set Avro or Custom. I have to double check that.

Thanks for checking. It's nice to have all this information bundled in the documentation somewhere. That will make it easier for others to develop nice tested solutions with stream analytics :)

A quick update:
Random order behavior
The random ordering is not something that can be fixed. Some of us, including me, think that it's not a bug. This behavior is actually the same one you expect from querying a table in a SQL database. The order is never guaranteed unless you explicitly specify it with an ORDER BY clause.
We don't support statement level ORDER BY for now, mainly because of how it conflicts with the natural ordering of a stream (by timestamp). Right now we have CollectTOP that allows the functionality, but will box the rows in a record. We are looking into adding ORDER BY at the statement level, but the semantics are not as obvious as it seems.
Back to your issue, what we should address is the fact that the unit test tool compares rows from 2 files based on their order in each file. That's not good. The fix is on our backlog, but no ETA yet.
In the meantime, a workaround is to add a quick test routine that runs after the unit testing module that does something like this (PowerShell still):
# Cleaning up the file
$rawOutput = "C:\...\myOutput.json" # that's the output of the test run
$orderedOutput = "C:\...\myOutput.ordered.json" # that's a new file we will generate

## I had to use that method to properly test the asa cicd npm package output format
$testableContent = ([IO.File]::ReadAllText($rawOutput)).split("`n") | ConvertFrom-Json

## We extract the list of properties in the output
$testableContentProperties = `
	$testableContent | `
	Get-Member -MemberType NoteProperty | `
	Sort-Object -Property Name | `
	Select-Object -ExpandProperty Name

## We sort by property and output back to a file
$testableSortedContent = $testableContent | Sort-Object -Property $testableContentProperties | ConvertTo-JSON
Add-Content -Path $orderedOutput -Value $testableSortedContent

# Actual testing
$left = Get-Content $sortedTestReference
$right = Get-Content $orderedOutput
$testResult = Compare-Object $left $right

This is repurposed from the now deprecated module I wrote some time ago before we had the asa cicd npm package. Depending on your comfort level with scripting, it can be easy or way overkill. Happy to help in any case.
Documentation
You're right, we need to invest in the documentation for testing. I will add the examples you mentioned. If you can think of any other scenarios, things that you struggled with, please let me know and I'll prioritize.

Hi @Davidswinkels,
Another quick update, following-up on your feedback:

We added an overview doc to local runs. It should clarify what's possible or not in VS Code. Note that we just released live outputs from VS Code to Blob/SQL/EH. It should be announced shortly
We updated the testing doc to add a multi line input and output sample
The asa cicd package is being updated to switch from a row by row approach to an object based comparison. No ETA yet as the holiday season is coming, but it shouldn't take too long

Hi @Fleid great to hear that more documentation was added for testing with stream-analytics and really great to hear that an object based comparison is being worked on instead of row approach. I think that should fix our tests randomly failing :)
A suggestion to improve the documentation still would be to split the current documentation page into one page explaining the build, run + deploy step more and one page to explain testing. This will make it easier to find the needed information for readers. Plus for test example it might be nice to use a csv as static data input and json as dynamic data input instead of json twice

Hey @Davidswinkels,
We just released the version 2.2.4 of the cicd package. With that version, we're switching the comparison model from row by row to an object based one. You shouldn't encounter those random errors anymore.
I'm closing the issue, but please let us know how it goes ;)
#please-close

Thanks for the help Fleid. Issue is solved now :)


Broadcast .send() calls get ignored if not awaited

Bug report
Describe the bug
When you call supabaseChannel.send({...}) multiple times without awaiting it, subsequent calls are simply ignored.
To Reproduce
Create a supabase realtime channel, invoke .send() multiple times (without await) and inspect the websocket connection. Only the first one goes through.
Expected behavior
I would expect the calls to be batched and either sent together, or the channel to loop over them for me.

I realised that I could reduce the rate limit like this:
createClient(url, anonKey, { realtime: { params: { eventsPerSecond: 200 } } })

This works for now, and I have implemented my own wrapper that makes sure events are throttled to not exceed this rate limit.
I would be grateful to get a confirmation that is the best way to solve this. Other than that this issue can be closed.

I realised that I could reduce the rate limit like this:
createClient(url, anonKey, { realtime: { params: { eventsPerSecond: 200 } } })

This works for now, and I have implemented my own wrapper that makes sure events are throttled to not exceed this rate limit.
I would be grateful to get a confirmation that is the best way to solve this.

@enyo that's correct, you can tweak the eventsPerSecond depending on your use case. This was just a basic rate limiter we put in place client-side but there are more sophisticated rate limits on the server. You can check out Realtime Rate Limits for additional information.
I'm going to close this issue but feel free to reopen if needed.


Update certs-wifi-lan.md

Small edits to change Service requests to Support requests.  Added IT to MMD IT Operations.  Made P small letter in Admin portal.

Can you please assist to check, approve and merge the content of this PR?
Thank you.

@jaimeo - I would like to follow up on this. Can you please assist to check, approve and merge the content of this PR?
Thank you.

I'm so sorry I didn't see this for some reason!


Customize docker.client.strategy through classpathProperties instead of environmentProperties

I think it could be a convenient feature to customize docker.client.strategy also through classpathProperties instead of environmentProperties only. Would you like to rollback
return (String) properties.get("docker.client.strategy");
instead of
return (String) environmentProperties.get("docker.client.strategy");
at this line?
https://github.com/testcontainers/testcontainers-java/blob/9b3c87eb2f350c6211dfa5eadea61f8eb00e2097/core/src/main/java/org/testcontainers/utility/TestcontainersConfiguration.java#L167

The value stored in the file is a "cache" and is not supposed to be manually set.
Also, client strategies is a property of an environment. It does not make sense to force the Unix Socket strategy, for example, because it will fail on Windows.


update Patreon links

Work for this issue will begin begin on branch work-liquid-labs/react-window-context/27.


How to test function with x:context?

Hey there,
at the moment, I don't see a chance to test a function within a specific context.
Let's say I have this function which builds an absoulte XPath string from the current node:
<xsl:function name="pa:get-current-xpath" as="xs:string">
	<xsl:param name="current-node"/>
	<xsl:variable name="temp">
		<xsl:for-each select="$current-node/ancestor-or-self::*">
			<xsl:variable name="current-ancestor-name" select="name()"/>
			<xsl:value-of select="concat('/',name(),'[',count(preceding-sibling::*[name()=$current-ancestor-name])+1,']')"/>
		</xsl:for-each>
	</xsl:variable>
	<xsl:sequence select="string-join($temp,'')"/>
</xsl:function>

And I want to write a test for this xml snippet:
<root>
	<element>
		<child>Content <inline>in</inline> child</child>
	</element>
</root>

And the test should call the function pa:get-current-xpath() from the context of the <inline> element so that the expected result is: /root[1]/element[1]/child[1]/inline[1]
<x:scenario label="Scenario for testing function get-current-xpath">
	<x:context select="/root/element/child/inline/node()">
		<root>
			<element>
				<child>Content <inline>in</inline> child</child>
			</element>
		</root>
	</x:context>
	<x:expect label="Absolute XPath for inline element" test="pa:get-current-xpath(.)" select="'/root[1]/element[1]/child[1]/inline[1]'" />
	<x:expect label="Absolute XPath for inline element" test="pa:get-current-xpath(/root/element/child/inline)" select="'/root[1]/element[1]/child[1]/inline[1]'" />
	<x:expect label="Absolute XPath for inline element" test="pa:get-current-xpath(/root/element/child/inline/node())" select="'/root[1]/element[1]/child[1]/inline[1]'" />
</x:scenario>

None of the three <x:expect> statements is working. And it seems that <x:context select="/root/element/child/inline/node()"> isn't working either for selcting a context...
Is there some other way? Probably with using <x:call function="">? If so I haven't found it yet...
Any ideas appreciated! Thanks!
Cheers,
Tobias

Hi @tofi86,
thanks for the detail request and for posting code snippets. I should be able to have a look at your request during the weekend and let you know if I need more detail. I'll keep you posted.
Sandro

Thanks, Sandro! 👍
Also I was wondering which one of both the repos is the official repository? The expath one or this one?

Hi Tobias,
you were right in guessing that you should use the <x:call function=""> element in your XSpec test. You need to put the context inside the <x:param> element and use a select attribute to select the node you want to pass to the function. Given your function pa:get-current-xpath you posted above, here is an example of XSpec test for this function:
<x:scenario label="When passing a node to function get-current-xpath">
    <x:call function="pa:get-current-xpath">
        <x:param name="current-node" select="/root/element/child/inline/node()">
	    <root>
		<element>
		    <child>Content <inline>in</inline> child</child>
		</element>
	    </root>
	</x:param>
    </x:call>

    <x:expect label="it should return the absolute path of the node" select="'/root[1]/element[1]/child[1]/inline[1]'"/>
</x:scenario>

I was able to run this test successfully. Let me know if it works at your end so that I can close the issue.
Sandro

Regarding your question about the official xspec repository, I originally forked the xspec repository from the xpath organisation and submitted several pull requests to the project as well as reviewed pull requests from other people. Unfortunately I don't have write access to that repository and pull requests have been sitting there for almost a year now. Recently I have been given admin access to the xspec organisation which was created when the code was moved from Google Code and I transferred my fork here.
I'm hoping to revive XSpec project and I would be very interested in knowing how you are using XSpec, which features/bug fixes you'd like to see in the next XSpec release, etc. Feel free to post other issues/requests.
Thanks,
Sandro

Hi Sandro,
great, your solution works like a charm! I wasn't aware that you can use @select on <x:param> WITH having context content inside...
This should probably be added in the Wiki as it's missing at the moment.
I tested and it seems my change to the wiki page was accepted:
https://github.com/xspec/xspec/wiki/Writing-Scenarios#function-scenarios

You can also the @select attribute on <x:param> PLUS context content inside to provide a specific data context to the function:
<x:scenario label="When passing a node to function do-something-with-element">
    <x:call function="eg:do-something-with-element">
        <x:param name="current-node" select="/root/element/child/node()">
            <root>
                <element>
                    <child>Text content</child>
                </element>
            </root>
        </x:param>
    </x:call>

    <x:expect label="it should return the name of the parent node" select="'element'"/>
</x:scenario>

We just started using Xspec as we're doing a lot of XSLT development in our company and I tried setting up Travis CI with automated Xspec tests in a small sample repository:
https://github.com/paginagmbh/xLib
It would be great if the Xspec group would revive and we would have ONE spot to post issues and questions to...
I will add an issue in the expath original repository to clarify the status as there have been new issues recently as well...
Thanks for your work, Sandro! 👍

Thanks a lot for updating the documentation, I just slightly rephrased it. Great that you added a code snippet, that's the best example for the documentation!

 :)

I subscribed to the xspec repository in the xpath organisation so if issues are raised there I receive a notification and I should be able to integrate them in here.

Great! 👍 I also opened a new issue at https://github.com/expath/xspec/issues/85 to clarify the status of the two repositories...
If there's feedback on the topic, one could probably move the old open tickets over here...


Issue #83

Added logic for CSCvn20175 and CSCvt07565
Added logic for CSCvn20175 and CSCvt07565
Added logic for CSCvn20175 and CSCvt07565

Fix for Issue #83

closing this one, will work on branch sourced from here.


executeWithKey and MySQL throw SQLException

executeWithKey return the following exception :
Exception in thread "main" com.querydsl.core.QueryException: Caught SQLException for insert into `user` (`email`)
values (?)
	at com.querydsl.sql.DefaultSQLExceptionTranslator.translate(DefaultSQLExceptionTranslator.java:50)
	at com.querydsl.sql.Configuration.translate(Configuration.java:453)
	at com.querydsl.sql.dml.SQLInsertClause.executeWithKeys(SQLInsertClause.java:364)
	at com.querydsl.sql.dml.SQLInsertClause.executeWithKey(SQLInsertClause.java:172)
	at com.querydsl.sql.dml.SQLInsertClause.executeWithKey(SQLInsertClause.java:153)
	at com.serphacker.qdslbug.App.main(App.java:33)
Caused by: java.sql.SQLException: getGeneratedKeys error. Statement.RETURN_GENERATED_KEYS must be precised on connection.prepareStatement(String sql, int autoGeneratedKeys) or statement.executeUpdate(String sql, int autoGeneratedKeys)
	at org.mariadb.jdbc.MariaDbStatement.getGeneratedKeys(MariaDbStatement.java:800)
	at com.querydsl.sql.dml.SQLInsertClause.executeWithKeys(SQLInsertClause.java:351)
	... 3 more

Tested with querydsl 4.0.6
        drop table if exists `user`;
        create table `user` (
            id int primary key auto_increment,
            email varchar(255)
        );

        Configuration conf = new Configuration(new MySQLTemplates());
        QUser t_user = QUser.user;

        Integer key = new SQLInsertClause(connection, conf, t_user)
            .set(t_user.email, "email")
            .executeWithKey(t_user.id);

Related to #1040

Which version of the Maria driver do you use?

Also do you use it with MySQL or MariaDB and which version?

@timowest I tested against mariadb 10.0.22 but it looks like it's a mariadb driver issue :
mariadb-java-client 1.3.x : exception triggered
mariadb-java-client <= 1.2.x : ok, return generated keys
mysql-connector-java 5.1.37 : ok, return generated keys

https://mariadb.com/kb/en/mariadb/mariadb-connector-j-130-release-notes/
maybe it is related to :
Notable changes and additions : Prepared statement on server side.

because the exception tell :
Caused by: java.sql.SQLException: getGeneratedKeys error. Statement.RETURN_GENERATED_KEYS must be precised on connection.prepareStatement(String sql, int autoGeneratedKeys) or statement.executeUpdate(String sql, int autoGeneratedKeys)

Looks like a bug in the driver
https://github.com/MariaDB/mariadb-connector-j/blob/1.3.0/src/main/java/org/mariadb/jdbc/MariaDbConnection.java#L359
The flag Statement.RETURN_GENERATED_KEYS is missing.

@serphacker You should report that bug to MariaDB or switch to the MySQL driver.


table sqlite_schema is not accessable at .drift files

hello
i just wanted to thank you for your wonderful work mate 👍
i was trying to access sqlite_schema table in a .drift file and at building i get:
line 14, column 26: sqlite_schema could not be found in any import.
╷
14 │ getschema: select * from sqlite_schema;
│                          ^^^^^^^^^^^^^
╵
from build_runner
love
h

Thanks for the report. This is supposed to work, and I think apart from the error it does. The linked commit should fix the superflous error message as well.


chore(example): clean up examples and update README

What this PR does / why we need it:

Update example README and remove swapi
Remove landscape.io and add tracing enabled badge

Which issue(s) this PR fixes (optional, close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
/cc @Jimexist @kdada
Release note:

NONE

Generally LGTM. But these examples except getting-started are out of date. We need to refine these examples after Nirvana being stable.

SGTM

/lgtm


ZFS import hanging at boot

https://github.com/NixOS/nixpkgs/blob/fdfe8b3a0cb581dc2ba28258cb56fd7c9217d9c2/nixos/modules/tasks/filesystems/zfs.nix#L74
The awk command to find the state of a particular zpool has incomplete regex(/pool: $pool/) that can match early on similarly named zpools.
An example is having two pools, named solid and solid_old, where solid_old is reported as unavailable due do missing vdevs.
With the following in your nixos configuration:
boot.zfs.extraPools = [ "solid" ];
What can happen is when that regex is searching for solid in the list of zpools and checking if it's available, is it instead matches with solid_old, who's state is UNAVAIL and is forced to wait until it times out as the script thinks solid isn't able to be imported yet.
An example of what this will show in the journalctl logs is:
zfs-import-solid-start[1566]: Pool solid in state UNAVAIL, waiting
Repeated once every second, for a whole minute.
The zpool will eventually import after the timeout completes, however waiting for the timeout does still increase boot times by a full minute for no valid reason(in this case).
This could be solved by changing /pool: $pool/ to /pool: $pool$/ in the line referenced above.

I can confirm this issue running a6a71ed2949881b4bf0b0e51981a39cfc74ffc4f right now.
It additionally hangs whilst trying to zfs-auto-snapshot during boot.