Add ability to declare an intermediate class as acting like a leaf class

The purpose of this mixin is to allow declaring an intermediate class (or more accurately a leaf class' parent) as acting like a leaf class, so that when querying it, it will ignore STI subclasses in the type conditions.  Where this is specifically useful is in provider subclassing.  Right now if we want to create a provider that is a subclass of another provider, we can't do that because querying the records will bring back both the parent provider type as well as the child.
Code Layout
Presently, we resort to creating mixins in those providers which is unnatural.  So when we need to "subclass" a provider, all of the code must be moved into mixins, then the base parent provider type and child provider types are implemented as direct leaf classes that each have to mix in the shared code.
Current layout:
ExtManagementSystem
- ManageIQ::Providers::ContainerManager
  - ManageIQ::Providers::Kubernetes::ContainerManager (empty) + ManageIQ::Providers::Kubernetes::ContainerManagerMixin
  - ManageIQ::Providers::OpenShift::ContainerManager (empty) + ManageIQ::Providers::Kubernetes::ContainerManagerMixin

New layout that's possible:
ExtManagementSystem
- ManageIQ::Providers::ContainerManager
  - ManageIQ::Providers::Kubernetes::ContainerManager + ActsAsStiLeafClass
    - ManageIQ::Providers::OpenShift::ContainerManager

Querying
This works by changing the definition of the type condition for the class from [self] + descendants to just [self].  This can be seen in the following query demonstration.
Without ActsAsStiLeafClass (see PR https://github.com/ManageIQ/manageiq-providers-amazon/pull/667 showing what an a hypothetical amazon subclass provider might be like when not using mixins)
[1] pry(main)> ManageIQ::Providers::Kubernetes::ContainerManager.all.to_sql
=> "SELECT \"ext_management_systems\".* FROM \"ext_management_systems\" WHERE "
   "\"ext_management_systems\".\"type\" IN ('ManageIQ::Providers::Kubernetes::ContainerManager', 'ManageIQ::Providers::Amazon::ContainerManager')"
[2] pry(main)> ManageIQ::Providers::Amazon::ContainerManager.all.to_sql
=> "SELECT \"ext_management_systems\".* FROM \"ext_management_systems\" WHERE "
   "\"ext_management_systems\".\"type\" IN ('ManageIQ::Providers::Amazon::ContainerManager')"

Now with ActsAsStiLeafClass (add in ~~https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/408~~ ManageIQ/manageiq-providers-kubernetes#410 - better PoC with actual inheritance)
[1] pry(main)> ManageIQ::Providers::Kubernetes::ContainerManager.all.to_sql
=> "SELECT \"ext_management_systems\".* FROM \"ext_management_systems\" WHERE "
   "\"ext_management_systems\".\"type\" = 'ManageIQ::Providers::Kubernetes::ContainerManager'"
[2] pry(main)> ManageIQ::Providers::Amazon::ContainerManager.all.to_sql
=> "SELECT \"ext_management_systems\".* FROM \"ext_management_systems\" WHERE "
   "\"ext_management_systems\".\"type\" = 'ManageIQ::Providers::Amazon::ContainerManager'"

@agrare Please review.
My only 2 concerns at the moment are:

People making changes to the parent provider type to add some new object and forgetting to add in include ActsAsStiLeafClass.  I'm not sure if there's a way to detect that or write some general spec pattern that would detect that.
Technically children inherit this method meaning all children will be considered as leaf classes as well.  From the point of view of our provider objects, this is probably fine, since any child provider type is also a leaf class anyway.  However, from a generic ActsAsStiLeafClass naming point of view that may be unexpected.  Not sure how to fix this...maybe we only apply the type check on the included class directly, but I'm not sure how?

Part of #20741

@agrare I un-WIP'ed this, as I think we can move forward with it.  I'm looking into trying to figure out how to "undo" the change in child classes, but I don't think it's a show stopper right now.

@cross-repo-tests /all including https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/410, https://github.com/ManageIQ/manageiq-providers-openshift/pull/197, https://github.com/ManageIQ/manageiq-providers-kubevirt/pull/178

@miq-bot cross-repo-tests /all including ManageIQ/manageiq-providers-kubernetes#410, ManageIQ/manageiq-providers-openshift#197, ManageIQ/manageiq-providers-kubevirt#178

@miq-bot cross-repo-tests /all, ManageIQ/manageiq-providers-kubernetes#410, ManageIQ/manageiq-providers-openshift#197, ManageIQ/manageiq-providers-kubevirt#178 , https://github.com/ManageIQ/manageiq/pull/20756 including ManageIQ/manageiq-providers-kubernetes#410, ManageIQ/manageiq-providers-openshift#197, ManageIQ/manageiq-providers-kubevirt#178

Not related to this PR but for the bot's cross-repo-tests command I think we should use any includeing [PRs] in the list of test repos so the user doesn't have to do: @miq-bot /all PR#1 PR#2 including PR#1 PR#2

@Fryguy manageiq-api looks like a failure from this PR, the rest of the failures look unrelated

@agrare I agree...I can't think of cases where the user doesn't want to run the specs on their associated manageiq PRs as well.  We do have to make sure they are runnable, however.  For example, if you override an external gem, can we run gem's specs...
@miq-bot /all including PR#1, ManageIQ/more_core_extensions#1234
Should that run the more core specs?

Discussed with @agrare, and while @kbrock's concerns are justified, we think the benefits of this approach outweigh the negatives and are going to push forward.
However, to avoid leaking too much, I'm going to look at trying to better isolate the "acts as" features to the target class.

@Fryguy were you able to get the class variable (which are not inherited) working?
What do we need to move forward with this.
ASIDE: While there are things I don't like about this approach, it does solve a problem we have. So lets find out what we need to do to get this in.

What do we need to move forward with this.

@agrare has a number of PRs reorganizing the Kubernetes-based providers that demonstrate this working...once those are all green, we can move forward with merging.

@Fryguy actually all of the provider PRs are green it is the api repo that is failing https://travis-ci.com/github/ManageIQ/manageiq-cross_repo-tests/jobs/435710901#L2435-L2463

@miq-bot cross-repo-tests /all, ManageIQ/manageiq-providers-kubernetes#410, ManageIQ/manageiq-providers-openshift#197, ManageIQ/manageiq-providers-kubevirt#178 , #20756 including ManageIQ/manageiq-providers-kubernetes#410, ManageIQ/manageiq-providers-openshift#197, ManageIQ/manageiq-providers-kubevirt#178

Kicking cross-repo tests

Kicking cross-repo tests

@Fryguy @agrare any updates on this one?  This is the basis for adding providers that are similar to each other and allows for code reuse.

@Fryguy @agrare any updates on this one?  This is the basis for adding providers that are similar to each other and allows for code reuse.

The API is failing due to the provider controller expecting that ManageIQ::Providers::Openshift::ContainerManager.superclass == ManageIQ::Providers::ContainerManager.

The API is failing due to the provider controller expecting that ManageIQ::Providers::Openshift::ContainerManager.superclass == ManageIQ::Providers::ContainerManager.

Alright cross-repo tests are green (ui-service always fails)

Alright cross-repo tests are green (ui-service always fails)

@chessbyte, since both myself and @agrare are invovled in this one, can you be the reviewer+merger?

[ ] This PR: https://github.com/ManageIQ/manageiq/pull/20756

[ ] Kubernetes: https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/410

[ ] Openshift: https://github.com/ManageIQ/manageiq-providers-openshift/pull/197
[ ] Kubevirt: https://github.com/ManageIQ/manageiq-providers-kubevirt/pull/178

@chessbyte, since both myself and @agrare are invovled in this one, can you be the reviewer+merger?

[ ] This PR: https://github.com/ManageIQ/manageiq/pull/20756

[ ] Kubernetes: https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/410

[ ] Openshift: https://github.com/ManageIQ/manageiq-providers-openshift/pull/197
[ ] Kubevirt: https://github.com/ManageIQ/manageiq-providers-kubevirt/pull/178

https://github.com/ManageIQ/manageiq-cross_repo-tests/pull/239 is NOT green.  Is that the right cross-repo test?

https://github.com/ManageIQ/manageiq-cross_repo-tests/pull/239 is NOT green.  Is that the right cross-repo test?

manageiq-ui-service always fails cross-repo tests because it doesn't use bundle exec rake to run its tests, it does yarn run test

manageiq-ui-service always fails cross-repo tests because it doesn't use bundle exec rake to run its tests, it does yarn run test

Yeah I shouldn't have included ui-service in the cross repo test, but I autogenerated the list and wasn't paying attention :)

Yeah I shouldn't have included ui-service in the cross repo test, but I autogenerated the list and wasn't paying attention :)

Yeah it is in the /all group

Yeah it is in the /all group

Oh, @agrare was the one who did it...I blame him 🏃 💨  😆

Oh, @agrare was the one who did it...I blame him 🏃 💨  😆


Act as a toggle with same payload

Description:
If payload_on and payload_off are the same value, then it will act as a toggle.  This comes in handy when using a remote control/fob.  Otherwise, it doesn't change functionality.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for configuration.yaml (if applicable):
binary_sensor:
  -platform: mqtt
  state_topic: [topic]
  name: [name]
  payload_on: [value]
  payload_off: [value same as on]

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

Hi @MattyBoy4444,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

We shouldn't merge this as it is confusing and unexpected behavior for users. This can already be achieved using a value_template and inverting the current state.

Not sure how this is confusing.  I also put in the documentation.  This would ONLY change behavior if both payloads where set to the same value.  Nobody would have that configuration now.  It doesn't do anything.  Also, relying on value_templates is a support nightmare.  How many more question do you want in github and home assistant forums.  Do you really think most people using HA know how to write value_templates?  Please reconsider.  I could ask other rf users to comment??

@MattyBoy4444 Isn't the force_update option of MQTT binary_sensor better suited to what you want to do? This is used by Sonoff Tasmota for example to trigger a new event each time a button is pressed, this event can then be used in automations to toggle other devices.


Move send_email module to modules directory.

I tried to commit the __init__.py file in the modules directory. I added it with git add, but it didn't show  up in my staged changes, or when I did the commit. Not sure what is going on.

hi @2Max4, will try to do the rebase, that is one part of the git workflow I still haven't figured out.

Hey @Rho-n
I always do it this way:
do my work on my dev branch
pull master (make sure it is up to date)
then checkout in dev
then in dev : git rebase master
Works for me! Greetings


Move ComponentSelector from dispatch API to common API

What's needed?
The message currently known as ComponentSelector should be moved to this repository.
Proposed solution
No response
Use cases
No response
Alternatives and workarounds
No response
Additional context
No response

@tiyash-basu-frequenz just discussed this with @stefan-brus-frequenz and we don't feel this need moving right now as no other API uses that.


Add a function dump general characteristics of the device for logging.

When a user of the classes has a problem, it would be great to be able to dump some general characteristics.  Add a function that logs those to the console.

We now have a function called GeneralUtils#dumpInfo() that when called logs details to the console.  For example:
D (353) GeneralUtils: --- dumpInfo ---
D (356) GeneralUtils: Free heap: 192180
D (360) GeneralUtils: Chip Info: Model: 0, cores: 2, revision: 1
D (366) GeneralUtils: ESP-IDF version: v3.0-dev-1411-g7e3ac347
D (372) GeneralUtils: ---


Add Stats Module - WIP

This PR is opened for the benefit of discussing the proposed solution to #293 . It will have tests added after the approach is agreed upon

deleting this as i need to rethink the implementation from scratch

reopening this  until ill create new PR

@wojtek0806 I mostly like this implementation.   SDK architecture is that every path element of a URI needs to be it's own class that inherits from PathElement so I think this class should not be a mixin, it should be a class in resource.py.

closing PR as new one is opened


setup walk tool change

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Karthik seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


The developers portal quick-start page shows a 404 error

What is the URL you're trying to access?

https://developers.rsk.co/quick-start/ 404's and it should - that page doesn't exist, and we don't have any links to it.
https://developers.rsk.co/quick-start/step1-install-rsk-local-node/ works, as do the other quick start steps as those are what we link to

Closing this for now, LMK if there's still an issue so we can investigate further.

@bguiz, to reproduce: click the "read more" button under "getting started".

@bguiz, to reproduce: click the "read more" button under "getting started".

Thanks @emiliorizzo - I've pushed a fix here: https://github.com/rsksmart/rsksmart.github.io/pull/87


Add a page covering organisations focussed on inequalities & data

eg.
Organisation websites
Useful social media accounts

https://www.datascienceforhealthequity.com/


Galran/adding projected paraxial lenses

added the HeadEye module inside the ParaxialAnalysis module to support the creation of Paraxial MLAs based on projection onto a Plane, Cylinder or Sphere.
This is a draft version - comments and exports will be added after initial integration to better support the tools and interfaces we will need.

Codecov Report

Merging #258 (78d69a2) into BrianGun/issue242 (44e731c) will decrease coverage by 1.77%.
The diff coverage is 0.88%.

@@                  Coverage Diff                  @@
##           BrianGun/issue242     #258      +/-   ##
=====================================================
- Coverage              54.97%   53.20%   -1.78%
=====================================================
  Files                     72       76       +4
  Lines                   6708     6930     +222
=====================================================
- Hits                    3688     3687       -1
- Misses                  3020     3243     +223

Impacted Files
Coverage Δ

...tical/ParaxialAnalysis/HeadEyeModel/Arrangement.jl
0.00% <0.00%> (ø)

...al/ParaxialAnalysis/HeadEyeModel/HeadEyeClasses.jl
0.00% <0.00%> (ø)

src/Optical/ParaxialAnalysis/HeadEyeModel/Misc.jl
0.00% <0.00%> (ø)

src/Vis/HeadEyeModel.jl
0.00% <0.00%> (ø)

src/Geometry/Primitives/NonCSG/ConvexPolygon.jl
61.29% <50.00%> (-0.62%)
:arrow_down:

Continue to review full report at Codecov.

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


Push delays

Just an idea right now, will have to inpect apis etc.

This issue is related to the Tequila API and we have the issue #116 for that, this should be part of that.


Specified the latest versions of tf/tfp/tfb-nightly

This PR solves this "Installation fails" issue, https://github.com/pymc-devs/pymc4/issues/23, by specifying the latest versions of tf/tfp/tfb-nightly packages.

Pull Request Test Coverage Report for Build 68

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.615%

Totals

Change from base Build 67:
0.0%

Covered Lines:
198

Relevant Lines:
234

💛  - Coveralls

umm this does not specify the 'latest version'.


Mattermost plugin does not work

Hello Seansackowitz,
I have downloaded the plugin for Mattermost server running on Ubuntu 18.4 bionic. When i try to up i get the following error.
Mar 27 18:43:47 lab-mmost1 platform[1032]: {"level":"error","ts":1553712227.977395,"caller":"app/plugin.go:97","msg":"Unable to activate plugin","plugin_id":"jitsi","error":"unable to copy webapp bundle directory: jitsi: stat /opt/mattermost/client/plugins/jitsi/webapp: no such file or directory","errorVerbose":"stat /opt/mattermost/client/plugins/jitsi/webapp: no such file or directory\nunable to copy webapp bundle directory: jitsi\ngithub.com/mattermost/mattermost-server/plugin.(*Environment).Activate\n\t/go/src/github.com/mattermost/mattermost-server/plugin/environment.go:189\ngithub.com/mattermost/mattermost-server/app.(*App).SyncPluginsActiveState\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:95\ngithub.com/mattermost/mattermost-server/app.(*App).InitPlugins\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:182\ngithub.com/mattermost/mattermost-server/app.(*Server).RunOldAppInitalization\n\t/go/src/github.com/mattermost/mattermost-server/app/server_app_adapters.go:139\ngithub.com/mattermost/mattermost-server/app.NewServer\n\t/go/src/github.com/mattermost/mattermost-server/app/server.go:177\ngithub.com/mattermost/mattermost-server/cmd/mattermost/commands.runServer\n\t/go/src/github.com/mattermost/mattermost-server/cmd/mattermost/commands/server.go:64\ngithub.com/mattermost/mattermost-server/cmd/mattermost/commands.serverCmdF\n\t/go/src/github.com/mattermost/mattermost-server/cmd/mattermost/commands/server.go:50\ngithub.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra.(*Command).execute\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra/command.go:762\ngithub.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra.(*Command).ExecuteC\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra/command.go:852\ngithub.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra.(*Command).Execute\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/spf13/cobra/command.go:800\ngithub.com/mattermost/mattermost-server/cmd/mattermost/commands.Run\n\t/go/src/github.com/mattermost/mattermost-server/cmd/mattermost/commands/root.go:14\nmain.main\n\t/go/src/github.com/mattermost/mattermost-server/cmd/mattermost/main.go:30\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:201\nruntime.goexit\n\t/usr/local/go/src/run
Then i manually copied the plugin the tar file and then untar it to plugins directory and restarted the server i still see the same error.
I have also local jitsi-meet server which is working if i go to url of jitsi. But intergration of Jitsi with mattermost does not seem to work at all.
Can you kind suggest and help me where am i going wrong with this.
Kind regards
Mohammad

@desertanwar This should be resolved now, but I would appreciate if you could test it. I apologize for the delay in resolving this issue.


[Style] Add dark mode to Contact page

What's the style idea?
We need to improve
Description
The Contact page currently does not support dark mode, which impacts user experience for those who prefer a dark interface or are using the website in low-light environments. Adding dark mode will improve accessibility and align with modern UI standards.
Expected Outcome

A toggle option to switch between light and dark modes on the Contact page.
Proper color adjustments for:

Background.
Text content.

Ensure all elements remain readable and visually appealing in dark mode.

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a KWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

@Rakesh9100, could you kindly assign these issues to me individually?

@Rakesh9100 Kindly assign this issue to me under KWOC


Add slang support based on ruoso++'s Grammar::EBNF work

This only does slang for BNF, not the ABNF in the other PR yet.

Can we get some tests for that? Mostly as an example of how to use it and when is it useful :)

Will followup with more docs


ingress: add nodepool edge node taints tolerations

When nginx ingress controller is orchestrated to the related nodepools by YurtIngress,
it can not be orchestrated successfully to the nodepool edge nodes with taints for the
related deployment didn't add the related tolerations. As a system component, we keep
it tranparent to users and set it to tolerate all taints for the nodepool nodes.
Signed-off-by: zhenggu1<EMAIL_ADDRESS>
What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage
/sig storage

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

/assign @kadisi @rambohe-ch

/lgtm
/approve


Dashboard-IE11-sidebar-no space between left arrow and service name

Dashboard-IE11-sidebar-no space between left arrow and service name

Refactor SidebarNavWidget.js into styled-components

blocked by #580


Add Travis CI Support

Problem
We have no way of running automated tests for the repo.
Solution
Add a test task in the task runner and add configuration to have Travis CI run this task.
Howto Test

[x] Ensure Travis CI ran for this branch (See Job #3)
[ ] Ensure Travis CI runs our noop test task for this pull request ([See Job #4)[ci_#4])

References

@mkinsey I will follow up with setup test runners for Angular and Integration tests.
Closes #127

I am not seeing build 4 in (the list)[https://travis-ci.org/orbitable/bridge/builds]


x/build: consider opting-in to longtest builders by default for cmd/go changes, if/when they're under 15 min

(I have a feeling @bcmills may have already filed an issue for this, but I couldn't find it. Maybe it was a comment instead.)
With the progress made on https://github.com/golang/go/issues/37439#issuecomment-723413000 recently, it seems we can speed up longtest SlowBots to run in under 15 minutes or so. If that can be done, what is your preference on enabling longtest builders by default for changes that touch the go command? CC @bcmills, @jayconrod, @matloob.
In either case, we need to wait for #37439 to be completed first, and give it a little time to see if that on its own is sufficient. But I wanted to create a tracking issue to start gathering feedback eagerly.
I'm also looking for feedback on:

If this is something we want to do, would you prefer that "cmd/go" changes are determined by the commit subject having the "cmd/go" path present (which is up to the author), or by looking whether any files in src/cmd/go directory are modified?

Also CC @golang/release.

(I have a feeling @bcmills may have already filed an issue for this, but I couldn't find it. Maybe it was a comment instead.)

I think it was previously an implicit subtext of #37439. Thanks for filing it as a proper issue!

If the longtest builders can be made to run at roughly the same latency as other TryBots, I think we would prefer to have it trigger by default (in much the same way that the x/tools 'bot triggers automatically).
I think we should use the same mechanism that we currently use to trigger x/tools, whatever that is. (I can't find it at the moment...)

This would be great! It would save me from accidentally submitting bugs in many cases...

This would be great! It would save me from accidentally submitting bugs in many cases...

We should also run longtest builders by default any time there are changes in src/vendor or src/cmd/vendor. We've had too many build breaks lately due to stray edits.

Which of these features is still desirable? This has become pretty easy to do with LUCI and I already sent out a CL to add run linux-amd64-staticlockranking when a CL modifies runtime files so the context is all fresh.

I agree with the non-cmd/go-related suggestion in https://github.com/golang/go/issues/42661#issuecomment-1116274332. That is, I suggest opting into longtest on at least linux/amd64 when any of these files are modified:

src/{,cmd/}go.mod
src/{,cmd/}vendor/*
src/*_bundle.go

I defer to @bcmills for cmd/go details. Thanks @mknyszek!

I sent out a CL for what you listed @dmitshur.
@bcmills That CL only seems to cover vendoring. Are there any other Go command related file paths that should enable the longtest builder? Thanks.


Unable to scrape data: hass variable not set on template

Since 2025.08.00b I have been getting an error on most of my multiscrape sensors, all of which worked fine before.
Version of the custom_component
7.0.2
Configuration
---
- name: Hue Sync Box Rest
  resource: https://<IP_ADDRESS>/api/v1/execution
  verify_ssl: false
  log_response: true
  timeout: 60
  headers:
    User-Agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36"
    Authorization: !secret hue_sync_box_token_bearer
  sensor:
    - unique_id: Hue Sync Box
      name: Hue Sync Box
      value_template: "foo"
      icon: mdi:devices
      attributes:
        - name: syncActive
          value_template: >
            {{ value.syncActive }}
        - name: video
          value_template: >
            {{ value.video }}
        - name: game
          value_template: >
            {{ value.game }}
        - name: music
          value_template: >
            {{ value.music }}
        - name: hdmiSource
          value_template: >
            {{ value.hdmiSource }}

      # state_class: measurement

Describe the bug
2024-08-02 19:22:02.537 ERROR (MainThread) [custom_components.multiscrape.sensor] Hue Sync Box Rest # Hue Sync Box # Unable to scrape data: hass variable not set on template

Debug log

2024-08-02 19:22:01.466 DEBUG (MainThread) [custom_components.multiscrape] # Start processing config from configuration.yaml

2024-08-02 19:22:01.467 DEBUG (MainThread) [custom_components.multiscrape] Hue Sync Box Rest # Setting up multiscrape with config:
 {'name': 'Hue Sync Box Rest', 'resource': 'https://<IP_ADDRESS>/api/v1/execution', 'verify_ssl': False, 'log_response': True, 'timeout': 60, 'headers': {'User-Agent': Template<template=(Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36) renders=0>, 'Authorization': Template<template=(Bearer xxxxxxxx=xxxxx=) renders=0>}, 'sensor': [{'unique_id': 'Hue Sync Box', 'name': 'Hue Sync Box', 'value_template': Template<template=({{ value.syncActive }}) renders=0>, 'icon': Template<template=(mdi:devices) renders=0>, 'force_update': False}], 'method': 'GET', 'list_separator': ',', 'parser': 'lxml'}
2024-08-02 19:22:01.467 DEBUG (MainThread) [custom_components.multiscrape] Hue Sync Box Rest # Log responses enabled, creating logging folder: /config/multiscrape/hue_sync_box_rest/
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # Initializing http wrapper
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hue Sync Box Rest # Creating scraper
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hue Sync Box Rest # Initializing scraper
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # Creating ContentRequestManager
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # Creating coordinator
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # Scan interval is 0:01:00
2024-08-02 19:22:01.666 DEBUG (MainThread) [custom_components.multiscrape.service] Hue Sync Box Rest # Setting up multiscrape configuration level services

2024-08-02 19:22:01.761 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # New run: start (re)loading data from resource
2024-08-02 19:22:01.761 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # Deleting logging files from previous run
2024-08-02 19:22:01.776 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # Executing page-request with a GET to url: https://<IP_ADDRESS>/api/v1/execution with headers: {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36', 'Authorization': 'Bearer xxxxxxxx=xxxxx='}.
2024-08-02 19:22:01.781 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # request_headers written to file: page_request_headers.txt
2024-08-02 19:22:01.787 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.026 seconds (success: True)
2024-08-02 19:22:01.787 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.028 seconds (success: True)
2024-08-02 19:22:01.791 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # request_body written to file: page_request_body.txt
2024-08-02 19:22:01.805 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.043 seconds (success: True)
2024-08-02 19:22:01.863 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.101 seconds (success: True)
2024-08-02 19:22:02.429 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # Response status code received: 200
2024-08-02 19:22:02.430 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # response_headers written to file: page_response_headers.txt
2024-08-02 19:22:02.431 DEBUG (MainThread) [custom_components.multiscrape.http] Hue Sync Box Rest # response_body written to file: page_response_body.txt
2024-08-02 19:22:02.431 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hue Sync Box Rest # Response seems to be json. Skip parsing with BeautifulSoup.
2024-08-02 19:22:02.431 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hue Sync Box Rest # Data successfully refreshed. Sensors will now start scraping to update.
2024-08-02 19:22:02.431 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.671 seconds (success: True)
2024-08-02 19:22:02.532 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.771 seconds (success: True)
2024-08-02 19:22:02.533 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-02 19:22:02.536 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.sensor] Hue Sync Box Rest # Hue Sync Box # Setting up sensor
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.sensor] Hue Sync Box Rest # Hue Sync Box # Start scraping to update sensor
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hue Sync Box Rest # Hue Sync Box # Applying value_template only.
2024-08-02 19:22:02.537 ERROR (MainThread) [custom_components.multiscrape.sensor] Hue Sync Box Rest # Hue Sync Box # Unable to scrape data: hass variable not set on template
Consider using debug logging and log_response for further investigation.
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.sensor] Hue Sync Box Rest # Hue Sync Box # On-error, set value to None
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.entity] Hue Sync Box Rest # Hue Sync Box # Icon template rendered and set to: mdi:devices
2024-08-02 19:22:02.537 DEBUG (MainThread) [custom_components.multiscrape.entity] Hue Sync Box Rest # Hue Sync Box # Updated sensor and attributes, now adding to HA
2024-08-02 19:22:02.546 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-02 19:22:02.549 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
Consider using debug logging and log_response for further investigation.
2024-08-02 19:22:02.558 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
Consider using debug logging and log_response for further investigation.
2024-08-02 19:22:02.563 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
Consider using debug logging and log_response for further investigation.
2024-08-02 19:22:02.567 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-02 19:22:02.568 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up multiscrape platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/config/custom_components/multiscrape/sensor.py", line 68, in async_setup_platform
    sensor_selector = Selector(hass, conf)
                      ^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/multiscrape/selector.py", line 33, in __init__
    raise ValueError(
ValueError: Selector error: either select, select_list or a value_template should be provided.

So, FWIW I tried the example straight from your readme and got the same error
- name: HA scraper
    resource: https://www.home-assistant.io
    scan_interval: 3600
    sensor:
      - unique_id: ha_latest_version
        name: Latest version
        select: ".release-date"
        value_template: "{{ value | trim }}"
      - unique_id: ha_release_date
        icon: >-
          {% if is_state('binary_sensor.ha_version_check', 'on') %}
            mdi:alarm-light
          {% else %}
            mdi:bat
          {% endif %}
        name: Release date
        select: ".release-date"
        attribute: "title"
        value_template: "{{ (value.split('released')[1]) }}"
    binary_sensor:
      - unique_id: ha_version_check
        name: Latest version == 2021.7.0
        select: ".release-date"
        value_template: '{{ value | trim == "2021.7.0" }}'
        attributes:
          - name: Release notes link
            select: ".release-date"
            attribute: href

2024-08-03 11:03:49.720 DEBUG (MainThread) [custom_components.multiscrape] # Start processing config from configuration.yaml
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape] HA scraper # Setting up multiscrape with config:
 {'name': 'HA scraper', 'resource': 'https://www.home-assistant.io', 'scan_interval': datetime.timedelta(seconds=3600), 'sensor': [{'unique_id': 'ha_latest_version', 'name': 'Latest version', 'select': Template<template=(.release-date) renders=0>, 'value_template': Template<template=({{ value | trim }}) renders=0>, 'force_update': False}, {'unique_id': 'ha_release_date', 'icon': Template<template=({% if is_state('binary_sensor.ha_version_check', 'on') %}
  mdi:alarm-light
{% else %}
  mdi:bat
{% endif %}) renders=0>, 'name': 'Release date', 'select': Template<template=(.release-date) renders=0>, 'attribute': 'title', 'value_template': Template<template=({{ (value.split('released')[1]) }}) renders=0>, 'force_update': False}], 'binary_sensor': [{'unique_id': 'ha_version_check', 'name': 'Latest version == 2021.7.0', 'select': Template<template=(.release-date) renders=0>, 'value_template': Template<template=({{ value | trim == "2021.7.0" }}) renders=0>, 'attributes': [{'name': 'Release notes link', 'select': Template<template=(.release-date) renders=0>, 'attribute': 'href'}], 'force_update': False}], 'method': 'GET', 'timeout': 10, 'verify_ssl': True, 'list_separator': ',', 'parser': 'lxml', 'log_response': False}
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.http] HA scraper # Initializing http wrapper
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Creating scraper
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Initializing scraper
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.coordinator] HA scraper # Creating ContentRequestManager
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.coordinator] HA scraper # Creating coordinator
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.coordinator] HA scraper # Scan interval is 1:00:00
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape.service] HA scraper # Setting up multiscrape configuration level services
2024-08-03 11:03:49.721 DEBUG (MainThread) [custom_components.multiscrape] Hass Main config multiscape # Setting up multiscrape with config:
 {'name': 'Hass Main config multiscape', 'resource': 'http://<IP_ADDRESS>:8123/api/config', 'verify_ssl': False, 'log_response': True, 'timeout': 60, 'headers': {'User-Agent': Template<template=(Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36) renders=0>, 'Authorization': Template<template=(Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJiODRjNDRmZWUxN2Y0NmY3OTY1NWE3NzdlOGNlMjA3YSIsImlhdCI6MTYwODY2ODY2OCwiZXhwIjoxOTI0MDI4NjY4fQ.wr_uPBSYSOO7KCb_32o3uwlf34dYkFnBE7NzEoQ8h3g) renders=0>}, 'sensor': [{'unique_id': 'hass_main_config', 'name': 'Hass Main config', 'icon': Template<template=(mdi:devices) renders=0>, 'attributes': [{'name': 'components', 'value_template': Template<template=({{ value_json.components | default }}) renders=0>}, {'name': 'unit_system', 'value_template': Template<template=({{ value_json.unit_system | default }}) renders=0>}, {'name': 'config_dir', 'value_template': Template<template=({{ value_json.config_dir | default }}) renders=0>}, {'name': 'version', 'value_template': Template<template=({{ value_json.version | default }}) renders=0>}], 'force_update': False}], 'method': 'GET', 'list_separator': ',', 'parser': 'lxml'}
2024-08-03 11:03:49.722 DEBUG (MainThread) [custom_components.multiscrape] Hass Main config multiscape # Log responses enabled, creating logging folder: /config/multiscrape/hass_main_config_multiscape/
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # Initializing http wrapper
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hass Main config multiscape # Creating scraper
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hass Main config multiscape # Initializing scraper
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # Creating ContentRequestManager
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # Creating coordinator
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # Scan interval is 0:01:00
2024-08-03 11:03:49.728 DEBUG (MainThread) [custom_components.multiscrape.service] Hass Main config multiscape # Setting up multiscrape configuration level services
2024-08-03 11:03:49.730 DEBUG (MainThread) [custom_components.multiscrape.coordinator] HA scraper # New run: start (re)loading data from resource
2024-08-03 11:03:49.730 DEBUG (MainThread) [custom_components.multiscrape.http] HA scraper # Executing page-request with a GET to url: https://www.home-assistant.io with headers: {}.
2024-08-03 11:03:49.731 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # New run: start (re)loading data from resource
2024-08-03 11:03:49.731 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # Deleting logging files from previous run
2024-08-03 11:03:50.211 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # Executing page-request with a GET to url: http://<IP_ADDRESS>:8123/api/config with headers: {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36', 'Authorization': 'Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJiODRjNDRmZWUxN2Y0NmY3OTY1NWE3NzdlOGNlMjA3YSIsImlhdCI6MTYwODY2ODY2OCwiZXhwIjoxOTI0MDI4NjY4fQ.wr_uPBSYSOO7KCb_32o3uwlf34dYkFnBE7NzEoQ8h3g'}.
2024-08-03 11:03:50.230 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # request_headers written to file: page_request_headers.txt
2024-08-03 11:03:50.232 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # request_body written to file: page_request_body.txt
2024-08-03 11:03:50.237 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # Response status code received: 200
2024-08-03 11:03:50.239 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # response_headers written to file: page_response_headers.txt
2024-08-03 11:03:50.240 DEBUG (MainThread) [custom_components.multiscrape.http] Hass Main config multiscape # response_body written to file: page_response_body.txt
2024-08-03 11:03:50.240 DEBUG (MainThread) [custom_components.multiscrape.scraper] Hass Main config multiscape # Response seems to be json. Skip parsing with BeautifulSoup.
2024-08-03 11:03:50.240 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Hass Main config multiscape # Data successfully refreshed. Sensors will now start scraping to update.
2024-08-03 11:03:50.240 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.509 seconds (success: True)
2024-08-03 11:03:50.267 DEBUG (MainThread) [custom_components.multiscrape.http] HA scraper # Response status code received: 200
2024-08-03 11:03:50.267 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Loading the content in BeautifulSoup.
2024-08-03 11:03:50.282 DEBUG (MainThread) [custom_components.multiscrape.coordinator] HA scraper # Data successfully refreshed. Sensors will now start scraping to update.
2024-08-03 11:03:50.282 DEBUG (MainThread) [custom_components.multiscrape.coordinator] Finished fetching multiscrape data in 0.552 seconds (success: True)
2024-08-03 11:03:50.283 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-03 11:03:50.283 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Latest version # Setting up sensor
2024-08-03 11:03:50.283 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Latest version # Start scraping to update sensor
2024-08-03 11:03:50.284 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version # Tag selected:
2024.7.4

2024-08-03 11:03:50.284 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version # Selector result:
2024.7.4

2024-08-03 11:03:50.284 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version # Applying value_template on selector result
2024-08-03 11:03:50.284 ERROR (MainThread) [custom_components.multiscrape.sensor] HA scraper # Latest version # Unable to scrape data: hass variable not set on template
Consider using debug logging and log_response for further investigation.
2024-08-03 11:03:50.284 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Latest version # On-error, set value to None
2024-08-03 11:03:50.284 DEBUG (MainThread) [custom_components.multiscrape.entity] HA scraper # Latest version # Updated sensor and attributes, now adding to HA
2024-08-03 11:03:50.285 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-03 11:03:50.285 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Release date # Setting up sensor
2024-08-03 11:03:50.286 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Release date # Start scraping to update sensor
2024-08-03 11:03:50.286 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Release date # Tag selected:
2024.7.4

2024-08-03 11:03:50.286 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Release date # Try to find attribute: title
2024-08-03 11:03:50.286 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Release date # Selector result: Latest version 2024.7.4 released July 30, 2024
2024-08-03 11:03:50.286 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Release date # Applying value_template on selector result
2024-08-03 11:03:50.286 ERROR (MainThread) [custom_components.multiscrape.sensor] HA scraper # Release date # Unable to scrape data: hass variable not set on template
Consider using debug logging and log_response for further investigation.
2024-08-03 11:03:50.287 DEBUG (MainThread) [custom_components.multiscrape.sensor] HA scraper # Release date # On-error, set value to None
2024-08-03 11:03:50.287 DEBUG (MainThread) [custom_components.multiscrape.entity] HA scraper # Release date # Icon template rendered and set to: mdi:bat
2024-08-03 11:03:50.287 DEBUG (MainThread) [custom_components.multiscrape.entity] HA scraper # Release date # Updated sensor and attributes, now adding to HA
2024-08-03 11:03:50.287 DEBUG (MainThread) [custom_components.multiscrape.binary_sensor] HA scraper # Latest version == 2021.7.0 # Setting up binary sensor
2024-08-03 11:03:50.288 DEBUG (MainThread) [custom_components.multiscrape.binary_sensor] HA scraper # Latest version == 2021.7.0 # Start scraping to update sensor
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0 # Tag selected:
2024.7.4

2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0 # Selector result:
2024.7.4

2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0 # Applying value_template on selector result
2024-08-03 11:03:50.289 ERROR (MainThread) [custom_components.multiscrape.binary_sensor] HA scraper # Latest version == 2021.7.0 # Unable to scrape data: hass variable not set on template.
Consider using debug logging and log_response for further investigation.
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.binary_sensor] HA scraper # Latest version == 2021.7.0 # On-error, set value to None
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.entity] HA scraper # Latest version == 2021.7.0 # Start scraping attributes
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0# release_notes_link # Tag selected:
2024.7.4

2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0# release_notes_link # Try to find attribute: href
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0# release_notes_link # Selector result: /blog/2024/07/03/release-20247/
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.scraper] HA scraper # Latest version == 2021.7.0# release_notes_link # Final selector value: /blog/2024/07/03/release-20247/ of type <class 'str'>
2024-08-03 11:03:50.289 DEBUG (MainThread) [custom_components.multiscrape.entity] HA scraper # Latest version == 2021.7.0 # Updated sensor and attributes, now adding to HA
2024-08-03 11:03:50.292 INFO (MainThread) [homeassistant.components.sensor] Setting up multiscrape.sensor
2024-08-03 11:03:50.292 DEBUG (MainThread) [custom_components.multiscrape.sensor] Hass Main config multiscape # Hass Main config # Setting up sensor
2024-08-03 11:03:50.292 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up multiscrape platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/config/custom_components/multiscrape/sensor.py", line 68, in async_setup_platform
    sensor_selector = Selector(hass, conf)
                      ^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/multiscrape/selector.py", line 33, in __init__
    raise ValueError(
ValueError: Selector error: either select, select_list or a value_template should be provided.
2024-08-03 11:03:53.367 WARNING (MainThread) [pyweatherflow_forecast.wffcst_lib] Weather Station either is offline or no recent observations.
2024-08-03 11:03:53.416 WARNING (MainThread) [custom_components.weatherflow_forecast] Weather Station either is offline or no recent observations from station. Remove Sensors to avoid this warning.

Thanks for reporting! I will have a look as soon as possible or maybe @jeremicmilan is able to take a look as it involves his PR?
Note that it is a pre-release, so please downgrade to the latest official release for the quickest solution.

I'll take a look tonight. I don't have hue, but hopefully the logs will be enough to figure out what's going on.

Here is the response incase its needed
{"mode":"video","syncActive":true,"hdmiActive":true,"hdmiSource":"input1","hueTarget":"xxxx-xxx-xxxx-xxxx-xxxx9ac","brightness":200,"lastSyncMode":"video","video":{"intensity":"intense","backgroundLighting":true},"game":{"intensity":"intense","backgroundLighting":false},"music":{"intensity":"intense","palette":"melancholicEnergetic"},"preset":null}

So one thing I found troubleshooting other errors is that the Alexa Media player app is throwing a similiar error re: the hass variable...
2024-08-03 13:38:48.505 ERROR (MainThread) [custom_components.monitor_docker] Failed Docker connect: tcp://<IP_ADDRESS>:2375/version
2024-08-03 13:38:48.506 ERROR (MainThread) [custom_components.monitor_docker] Retry in 60 seconds
2024-08-03 13:38:51.286 ERROR (MainThread) [homeassistant] Error doing job: Unclosed client session (None)
2024-08-03 13:38:51.387 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry<EMAIL_ADDRESS>- amazon.com for alexa_media
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 604, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/alexa_media/__init__.py", line 360, in async_setup_entry
    if await test_login_status(hass, config_entry, login):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/alexa_media/__init__.py", line 1396, in test_login_status
    async_create_persistent_notification(
TypeError: async_create() missing 1 required positional argument: 'hass'

I'm not reproducing this issue on the latest stable version of HA: 2024.7.4. I'm not updating my production server to check this. @danieldotnl, do you know how to change HA version in the dev environment (since 2024.7.4 is being initialized there as well)?
Also, since it is happening with other integrations, I would say that this is an issue with hass core. Examining the shared traces and the code hints at hass core as well.
Can you please downgrade to the stable version of multi-scrape and see if the issue happens again?

Seeing this on my 2024.0.8b1 as well, on 2024.7 it all works fine.
I have 2 multiscrape URLs setup: one is based on only html selectors (and works completely fine), the other is based on JSON parsing (with a template) and is broken. Not sure where we need to throw in the hass argument though.

You do not need to specify anything. This seems like a regression in Hass core. The bug needs to filled there. I'm AFK at the moment and cannot check if a bug already exists for this in hass core.

@jeremicmilan: Apologies for involving you. I read variables and I thought it must be your PR since I just merged that. However, this is already happening in v7.0.2.

What I know so far:
The error is correct, the hass variable isn't set. This is caused by a change in HA core as of release 2024.08.0b0. Somehow the hass variable is having a different value than before, already in the async_setup_platform function.
So this is either a bug in HA core, or something changed there which requires a change in custom components using the hass variable in some way or at some place.
I'll keep investigating.

@danieldotnl, do you know how to change HA version in the dev environment (since 2024.7.4 is being initialized there as well)?

Normally I'm relying on pytest-homeassistant-custom-component for the HA version. They usually create a new version automatically after each HA release, and this results in a PR on Multiscrape side. However, for some reason they didn't for the 204.08 pre-releases.
For now I removed pytest-homeassistant-custom-component from requirements.txt and added homeassistant==2024.08.0b0. Then run ./scripts/setup.

I have raised this in the #beta discord, but Did not get many replies there

Yeah, I read that earlier tonight.

Bumped conversation again just to make sure its not lost in the daily shuffle of that channel
https://discord.com/channels/330944238910963714/427516175237382144/1269765596006842429

So I currently think it's an issue in core:
https://discord.com/channels/330944238910963714/427516175237382144/1269948432672620545

I have no idea what causes the issue (since 2024.8), but I have a quick and dirty fix prepared, which I'll release before Wednesday in case there's is no more clarity.

Released: https://github.com/danieldotnl/ha-multiscrape/releases/tag/v7.0.3

Fixed. Tx!

For others; it's a regression in HA 2024.8: https://github.com/home-assistant/core/issues/123251#issuecomment-2275833529
2024.8.1 should have the fix, when it gets released (prob later today, Frenck started the release about 40mins ago)


Tweak glossary entry for ServiceAccount

Tweak https://kubernetes.io/docs/reference/glossary/?all=true#term-service-account (preview)
Use API resource name for clarity (no space).

/retitle [WIP] Tweak glossary entry for ServiceAccount

/retitle Tweak glossary entry for ServiceAccount

@sftim, @tengqm  Status of this PR?

I think this is ready for another review

/lgtm

/retitle [WIP] Tweak glossary entry for ServiceAccount

@sftim Nit: when you're finished with feedback, please squash your commits to prep for merge. Thanks in advance!

/retitle Tweak glossary entry for ServiceAccount

/lgtm
/approve


Supporting custom cultures that are not pre-defined in options.SupportedCultures

From @chaim770 on Wednesday, April 13, 2016 2:18:44 AM
Following this StackOverflow question:
http://stackoverflow.com/questions/36590969/enabling-client-based-culture-in-asp-net-core
It's currently impossible to let the CultureInfo be determined automatically from what the client specify in the Accept-Language header (as it used to be using <system.web.globalization enableClientBasedCulture> in Web.config).
The way it is now, I have to pre-register all the cultures I'm planning to support, which renders  AcceptLanguageHeaderRequestCultureProvider quite useless.
The following is the culprit:
https://github.com/aspnet/Localization/blob/b52e33caa7927093dc3ec540fd3282f4f69ae169/src/Microsoft.Extensions.Globalization.CultureInfoCache/CultureInfoCache.cs#L34
Copied from original issue: aspnet/Localization#237

Thanks for contacting us. We're closing this issue as there was no community involvement here for quite a while now.


Allow custom actions on save inventory collections

An idea for allowing extensibility of save inventory
I would still like new_records to be automatically handled in save_inventory, so I'm unsure if putting this into the block will cause errors.
/cc @bzwei @Fryguy

no real change. fixed rubocops

I tried this out. It works. For new_records I don't need to add them to parent at the custom block. So it seems the adding new items step is not needed even in the original code.

@bzwei it is not needed if you call save on the parent object after this method is called.
If the parent object is saved before this is called, then that push(new_records) is necessary.
Typing that last sentence makes me feel like there is a bug there, but the current refresh depends upon that code and fails without it.
I think I would like to add the new records before calling this block. new_records will be more of a fyi.
# Add the new items
parent.send(type).push(new_records)

if block_given?
  yield new_records, deletes
else
  # Delete the items no longer found
  unless deletes.blank?
    $log.info("MIQ(#{name}.save_#{type}_inventory) Deleting #{log_format_deletes(deletes)}")
    parent.send(type).delete(deletes)
  end
end

@Fryguy any thoughts?

Can you show an example of calling usage, and how this improves things?  It's hard to tell what will happen when I can't see how it's used.

@Fryguy Here is the example. For deleted stacks I am setting the ems_id to nil in order to disconnect the orphaned stack from its original provider.
deletes = ems.orchestration_stacks.dup
stacks = save_inventory_multi(:orchestration_stacks,
                              ems,
                              hashes,
                              deletes,
                              :ems_ref,
                              [:parameters, :outputs, :resources],
                              [:parent, :orchestration_template]) do |new_recs, del_recs|
  del_recs.each do |rec|
    rec.update_attributes(:ems_id => nil)
  end
end

This was more of an example than actual request for code. But I guess I don't see why not. removing the WIP.
@Fryguy did you discuss with @bzwei - do we like? If not, then just close

Yes I discussed with him and the feature this was going to be used for will not be done anymore so closing for now.


Cannot Build CentOS 7: 3.10.0-1160.80.1.el7.x86_64

Describe the bug
It looks like CentOS 7 got a new kernel ~Nov. 10 - at least, that's when mirrors picked it up. Our build pipelines internally have been failing for ALL falco libs versions, pointing to the problem being something else. Trying to manually build it gives an error.
Command:
 _output/bin/driverkit docker --output-module test.ko --kernelrelease 3.10.0-1160.80.1.el7.x86_64 --kernelversion 1 --driverversion 3.0.0+driver --target centos --moduledevicename scwx-falco --moduledrivername scwx-falco --kernelurls https://mirrors.edge.kernel.org/centos/7/updates/x86_64/Packages/kernel-devel-3.10.0-1160.80.1.el7.x86_64.rpm -l debug

Error:
DEBU !  CC [M]  /tmp/driver/tp_table.o
DEBU #  LD [M]  /tmp/driver/scwx-falco.o
DEBU ld: Q/tmp/driver/tp_table.o: invalid string offset<PHONE_NUMBER> >= 21 for section `mtab'
DEBU /tmp/driver/tp_table.o3: error adding symbols: File format not recognized
DEBU Lmake[2]: *** [scripts/Makefile.build:470: /tmp/driver/scwx-falco.o] Error 1
DEBU )make[1]: Leaving directory '/tmp/kernel'
DEBU :make[1]: *** [Makefile:1316: _module_/tmp/driver] Error 2
DEBU $make: *** [Makefile:7: all] Error 2
DEBU log pipe close                                error=EOF

It looks like it's an issue with the linker..?
Either way to get around this problem, I tried creating a custom builder image using CentOS 7 as the base:
FROM centos:7

RUN yum install -y make which binutils gcc && ln -s $(which gcc) /usr/bin/gcc-4.9

And using --builderimage with this image works just fine 🙂
NOTE: GCC in that above image is actually gcc-4.8.5, NOT gcc-4.9 - I just symlink the /usr/bin/gcc to /usr/bin/gcc-4.9 to trick the driverkit GCC selector into using my 4.8.5 - and that works! It gets more interesting... If I change the driverkit GCC selector to force gcc-4.8 for CentOS 3.10 kernels, that also fails... It seems that specifically for this NEW CentOS kernel, it requires gcc-4.8.5?
That, or something else in the build container is mismatched...
What's even MORE interesting is that the other CentOS 7 kernel releases build just fine with the default driverkit container. So something upstream in how CentOS is compiling the new kernel release isn't working...

How to reproduce it
Using the current master branch of driverkit, make build, and try to run the following:
 _output/bin/driverkit docker --output-module test.ko --kernelrelease 3.10.0-1160.80.1.el7.x86_64 --kernelversion 1 --driverversion 3.0.0+driver --target centos --moduledevicename scwx-falco --moduledrivername scwx-falco --kernelurls https://mirrors.edge.kernel.org/centos/7/updates/x86_64/Packages/kernel-devel-3.10.0-1160.80.1.el7.x86_64.rpm -l debug

Expected behaviour
It should build correctly just like the other CentOS 7 kernel releases without the need for --builderimage.

@FedeDP - wanted to ping you in case you immediately knew what to do here since you worked with the multi-gcc PR.

The buster-based builder uses a more recent binutils than CentOS 7 does, interestingly:
buster-based Builder
root@018e00199b39:/# ld --version
GNU ld (GNU Binutils for Debian) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
root@018e00199b39:/#

centos:7
[root@69c6b754624d /]# ld --version
GNU ld version 2.27-44.base.el7_9.1
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
[root@69c6b754624d /]#

I hope we haven't encountered another issue like this... It's clear that these problems will continue; we may want to consider moving to per-distro builder containers.

NOTE: GCC in that above image is actually gcc-4.8.5, NOT gcc-4.9 - I just symlink the /usr/bin/gcc to /usr/bin/gcc-4.9 to trick the driverkit GCC selector into using my 4.8.5 - and that works! It gets more interesting... If I change the driverkit GCC selector to force gcc-4.8 for CentOS 3.10 kernels, that also fails... It seems that specifically for this NEW CentOS kernel, it requires gcc-4.8.5?

fwiw, I'm able to build this driver in the following environments:
CentOS 7: gcc: 4.8.5, binutils: 2.27-44.base.el7
RHEL 8: gcc: 8.5.0, binutils: 2.30-117.el8
RHEL 9: gcc: 11.3.1, binutils: 2.35.2-24.el8
So, I don't think there's anything special about gcc 4.8.5 that's missing in gcc 4.9 that's causing this.
Interestingly, Ubuntu-based containers don't seem to be working. Using Ubuntu 18, with gcc 7.5.0-3ubuntu1~18.04 and ld 2.3.0:
DEBU Jarch/x86/Makefile:96: stack-protector enabled but compiler support broken
DEBU warch/x86/Makefile:169: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended..  Stop.

I'm sure the gcc in this container has stack-protector and retpoline support, though:
strings /usr/bin/gcc-4.9 |grep -i "\-mindirect\-branch"
mindirect-branch-register
-mindirect-branch=

strings /usr/bin/gcc-4.9 |grep -i "\-stack-protector"
-Wstack-protector
-fstack-protector
-fstack-protector-all
-fstack-protector-explicit
-fstack-protector-strong
-mstack-protector-guard=

Hi! As always, this is very weird...
I agree that, at some point, we might want to add different builders for each distro and distro version (like: centos7 builder, centos8 builder, ubuntu20.04 builder); fact is it's not easy to understand in which distro version a kernelrelease was present (let aside the added complexity of managing 15+ docker images).
Perhaps it would be enough to let's say add builders for distro type, like rpm builders, deb builders (we already have them), and arch builders and whatever we need still.
Again, i am not fond of adding that complexity to build let's say 5% more drivers, ie: i don't think the effort is worth the gain!

I was trying to leverage #244 to create a new builder image to fix this, but i still end up with:
DEBU 3+ make CC=/usr/bin/gcc-4.8.5 KERNELDIR=/tmp/kernel
DEBU *make -C /tmp/kernel M=/tmp/driver modules
DEBU Jarch/x86/Makefile:96: stack-protector enabled but compiler support broken
DEBU *make[1]: Entering directory `/tmp/kernel'
DEBU )make[1]: Leaving directory `/tmp/kernel'
DEBU warch/x86/Makefile:169: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended..  Stop.

COLLECT_GCC=gcc-4.5.8
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

Any hint?

RUN ln -s /usr/bin/gcc /usr/bin/gcc-4.5.8

Spot the issue :stuck_out_tongue_closed_eyes:
Why i am so bad!! ahahah
It should be:
RUN ln -s /usr/bin/gcc /usr/bin/gcc-4.8.5

!!
It is now fixed.

@FedeDP: Closing this issue.

In response to this:

#244 fixed this issue ;)
./_output/bin/driverkit docker --output-module test.ko --kernelrelease 3.10.0-1160.80.1.el7.x86_64 --kernelversion 1 --driverversion 3.0.0+driver --target centos --moduledevicename scwx-falco --moduledrivername scwx-falco --kernelurls https://mirrors.edge.kernel.org/centos/7/updates/x86_64/Packages/kernel-devel-3.10.0-1160.80.1.el7.x86_64.rpm --builderimage auto:master
INFO driver building, it will take a few seconds   processor=docker
INFO kernel module available                       path=test.ko

/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Create aatg

By the way, I'm pretty you need the .text extension. You might want to submit another commit to fix that so it can be merged whenever that happens.


AssertionError:  \c_ops\libaster.so not found

I have executed cp command in build.sh separately, but could not find libaster.so file

libaster.so in c_ops folder, so you can check it.

Me too, have you solved this problem？

@KongfuKitty  you need to check it in c_ops folder, if it have, you need to add path to python

@KongfuKitty you need to check it in c_ops folder, if it have, you need to add path to python

but my c_ops floder don't have libaster.so,what should i do?

@KongfuKitty you need to check it in c_ops folder, if it have, you need to add path to python

but my c_ops floder don't have libaster.so,what should i do?

That means you built fail. So check CMake Files and be sure that you build it right as the author said.


Using directly TLS

Hi, maybe I'm missing something, but is there a way to connect using TLS directly instead of starting without encryption and then upgrading with STARTTLS?

Hi @tsmanuelanton. Currently no, it's only STARTTLS. Is there a particular reason you want/need TLS only? I'm not 100% sure if this is even possible via the smtpd module I use, so I'd need to look into that first.

Thank you for your fast reply, @axllent  💯. I am using this server for integration tests and wanted to ensure that my code is compatible with TLS from the beginning. However, I will assume that if it works with STARTTLS, the same would happen with TLS.

I cannot see why it wouldn't work. TLS requires encryption from beginning to end, where STARTTLS does not initially require it for the handshake. The thing to note is that if you are using authentication, TLS is required and your client must upgrade to TLS (unless you specifically disabled that in the Mailpit with --smtp-auth-allow-insecure).
So the short answer is, TLS is definitely used for sending using authentication (unless disabled in Mailpit), even when using STARTTLS.

Maybe it does in fact require TSL (I've never tested that). Leave this with me and I'll look into how/if it's possible to add an option to Mailpit to use TSL instead of STARTTSL. I'm not too sure when I'll get a chance to look into it, bit I hope in the next couple of days.

Thank you very much, I really appreciate your help. Please, don't feel the need to rush for me 😄.

You are absolutely correct - I have been doing a bit of testing and you cannot connect to STARTTLS directly using TLS in a client. The good news it I can add this feature (it is supported) - I just need to figure out a way to add it so that it makes sense to the user.
Currently there are the following logic in Mailpit:

When you add SMTP certificates the SMTP server automatically allows STARTTLS, but it does not require/enforce STARTTLS (ie: you can send unencrypted although most clients automatically upgrade). Basically the client connects and can decide whether to send plain or encrypted (the connection is then upgraded to TLS after the client connects).
If the SMTP server is using authentication,  then STARTTLS is required (although you can override this with --smtp-auth-allow-insecure to allow auth over an unencrypted connection - just like before TLS was "a thing" in the good old days).
There is also an option to enforce STARTTLS (--smtp-tls-required) even without authentication, meaning that a client connecting must use STARTTLS to send the email. This option does not imply TLS-only (what you are after), but rather that a client must upgrade to encryption after it connects. This logic aligns with the TLSRequired flag in the smtpd package I use, and from what I understand aligns with the evolution of SMTP encryption in general.

Now I want to add the option for actual TLS (only) which means that the entire connection must run only over TLS only. This aligns with the TLSListener flag, and is different to STARTTLS because the TCP handshake is encrypted too (and why the two are not compatible even though they both use TLS).
As you can probably see, there will be probably confusion for Mailpit users because of the existing --smtp-tls-required flag in Mailpit.
I think I may have to deprecate the --smtp-tls-required and replace it with two new flags to either:

require STARTTLS, or
enforce & require TLS/SSL

I am thinking maybe --smtp-require-starttls and --smtp-require-tls (they cannot both be used at the same time). I really do not like deprecating flags, but I feel this may be the only way as it will help prevent confusion moving forward when I add "actual TLS" into the mix.
I'm going to slap on this decision as I may have a fresh idea in the morning, but I'd appreciate your comments if you have any. Sorry for the long post!

Apologies for the extra workload 😉. Although I'm not very familiar with this topic, you might consider keeping the --smtp-tls-required flag and detecting whether the client is already using TLS, ensuring the conversion is transparent for the client. I would be happy to assist you in any way I can.

Unfortunately that's not how it works, TLS is TLS and doesn't support upgrading from an unencrypted connection (it doesn't allow an unencrypted connection at all). STARTTLS on the other hand does, which is why it is the more common (though slightly less secure) protocol as it is more backwards compatible. This is why email providers who support both protocols run these on different ports.
Ultimately I predict everything will eventually move to pure TSL in the future (a bit like HTTPS), but that's not for a long time.
In the meantime I will add the option soon to use TSL (instead of STARTTSL) for those like yourself wanting to explicitly test SSL/TSL rather than STARTTSL. I just need to implement it and do the changes I mentioned earlier. I'll also need to write up some documentation as this is a somewhat confusing topic to most.
Also don't apologise for the time/work to implement this. This investigation has allowed me to investigate and better understand the SMTP protocols and their differences, and I see the benefits of adding this feature 👍

@tsmanuelanton I have just released a new version of Mailpit (v1.15.0) which includes TLS support for SMTP :partying_face: You can read the documentation on the website.
Please confirm this works for you?

I've just tried and still not working for me. Keeps giving same error when calling  tls.Dial("tcp", srv.ServerName(), tlsconfig). Do I have to use/open any new port?

 Yeah, now it works fine. Much thank you!

Excellent, thanks for the feedback!

excellent jobs,but i want more,can we support pop3 tls(pop3s) as smtps?

POP3 already supports TLS @yoke88 (see docs). Is this not what you mean?

thanks, I think it was pop3 with starttls. I use this soft to test multiple email protocols ,so i  need pop3,pop3 with starttls,pop3 etc. so it support pop3s and pop currently, but lack pop3 with starttls?

Sorry, STARTTLS for the POP3 server is currently not supported.


(PUP-11061) Override Sensitive equality/hash

Previously, instances of Sensitive with the same @value were not equal.
This patch overrides ==, eql? and hash to fix that.
  a = Puppet::Pops::Types::PSensitiveType::Sensitive.new('secret')
  b = Puppet::Pops::Types::PSensitiveType::Sensitive.new('secret')
  a == b
  # true
  h = { a => 1 }
  h[b] = 2
  h
  # {#<Sensitive [value redacted]>=>2}

Hi @jpartlow can you rebase and retarget the PR to 6.x? As this is a bugfix we'd like to also have it in the LTS stream.
Thanks!

:+1: Rebased and switched to 6.x.

I pinged Henrik about this and left his response in a comment on the JIRA ticket. I'm not sure what's the best course of action here, maybe @joshcooper can also weigh in when he gets back.

Updated to to rely on a hash test rather than any calls to unwrap. I think that bypasses the security leak on error concern.


[Bug]: Text to Voice Converter is not responsive

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
It is not responsive for smaller screens.
Expected behavior
Text input space, button, and background overflow when the screen gets smaller.
Add ScreenShots

On which device are you experiencing this bug?
No response
Record

[X] I have read the Contributing Guidelines
[ ] I'm a GSSOC'24 contributor
[X] I'm a SSOC'24 contributor
[X] I have starred the repository

Hello @anuragverma108 @apu52 @heysagnik
Please assign this under ssoc and the difficulty level, too.

@jeevan10017 u are assigned.


fix(burn): Debug minimal-slp-wallet

PR related to this trello task --> https://trello.com/c/dFhe06ov

This is no longer a Work in Progress, is ready for @christroutner to review

:tada: This PR is included in version 3.3.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Buienradar component warning 0.97.0

Home Assistant release with the issue:
0.97.0
Last working Home Assistant release (if known):
0.96.5
Operating environment (Hass.io/Docker/Windows/etc.):
HassOS 3.4 on RaspBerry PI 3B+
Component/platform:
buienradar.sensor
https://www.home-assistant.io/components/sensor.buienradar/
Description of problem:
The sensor I want to monitor works as expected, but there are warnings shown in the log. Are they caused by the new json buienradar-api? Warning occurs every time Buienradar tries to retrieve data.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: buienradar
  latitude: !secret location_latitude
  longitude: !secret location_longitude
  monitored_conditions:
    - irradiance

Traceback (if applicable):
2019-08-08 07:19:11 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfc' not loaded from br data!
2019-08-08 07:19:11 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcname' not loaded from br data!
2019-08-08 07:19:11 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcnamenl' not loaded from br data!
2019-08-08 07:19:11 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='pressure' not loaded from br data!

Rverm
These warnings are indeed caused by the buienradar component; when an update is requested the library will retrieve the json data from the closest station (either the location configured in home assistant or the location configured in the component). In your case, you seem to have configured the buienradar component with a specific location.
The warning you see here is that some data elements are missing from the retrieved data. We support a data element called pressure (the others depend on pressure). As it seems, your selected station does not have a (air)pressure data-element in its json, thus causing the warning.
it seems there are several stations that do not have it:

Arcen (6391), Berkhout (6249), Cadzand (6308), Ell (6377), Groenlo-Hupsel (6283)
Hansweert (6315), Heino (6278), Houtribdijk (6258), Huibertgat (6285)
IJmond (6209), IJmuiden (6225), Lauwersoog (6277), Marknesse (6273)
Nieuw Beerta (6286), Oosterschelde (6312), Rotterdam Geulhaven (6343)
Schaar (6316), Stavenisse (6324), Stavoren (6267), Texelhors (6229), Tholen (6331)
Vlakte aan de Raan (6313), Wijdenes (6248), Wijk aan Zee (6257)

Questions:

Do you see this warning all the time (day and night), or only specific times?
Is the weather station selected in the above list (you can see the selected station in the sensor details); or can you share your configured location? that would allow me to verify it is indeed missing the airpressure data...

If you are just interested in not seeing this warning anymore:

set the home assistant loglevel to error, or
set the loglevel for buienradar to error level.
The snipplet below should do the trick:

logger:
  default: warning
  logs:
    buienradar.buienradar: error
    buienradar.buienradar_json: error

Hi mjj4791
The location i'm using is in your list: "Ell (6377)". The warning looks continous to me, I can't see a pattern in time / day / night.
I've added the logger configuration to hide the warning. It's no longer displayed "home-assistant.log", but still on the "Developers Tools" page, tab "Info". Is this behavior expected?

Same problem here, using Stationname "Nieuw Beerta (6286)"
Also interested in how the logger works, only affects the .log file itself and indeed not the dev tools output.
Data element with key='visibility' not loaded from br data!
9:13 AM components/buienradar/sensor.py (WARNING) - message first occured at August 9, 2019, 5:47 PM and shows up 93 times
Data element with key='pressure' not loaded from br data!
9:13 AM components/buienradar/sensor.py (WARNING) - message first occured at August 9, 2019, 5:47 PM and shows up 93 times
Data element with key='barometerfcnamenl' not loaded from br data!
9:13 AM components/buienradar/sensor.py (WARNING) - message first occured at August 9, 2019, 5:47 PM and shows up 93 times
Data element with key='barometerfcname' not loaded from br data!
9:13 AM components/buienradar/sensor.py (WARNING) - message first occured at August 9, 2019, 5:47 PM and shows up 93 times
Data element with key='barometerfc' not loaded from br data!
9:13 AM components/buienradar/sensor.py (WARNING) - message first occured at August 9, 2019, 5:47 PM and shows up 93 times

So; the warning is correct; the data does not contain a airpressure element.
If you don't want the warning to show up, i would modify the logger config (for now).
Seeing that several stations do not have all elements (including airpressure, but others as well), i might change the buienradar library sometime to not output this as a warning, since this seems far more common than I anticipated....
I always understood that the dev tools also look at the logging in the logfile, so I also expected the warning to be gne after you reconfigure the logger and restart HA. If it doe snot, not sure how this works....
Did you try clicking on clear? do they remain even after that?

Doesn't work that way I noticed...
Already set this in my configuration.yaml:
logger:
default: critical
...but that results in only a 0KB home-assistant.log, not affecting the dev tools output
Thanks tho!

Few more warnings occured in the last days, nothing changed in the configuration except HA is now version 0.97.2.
Data element with key='rainlast24hour' not loaded from br data!
Data element with key='rainlasthour' not loaded from br data!
Data element with key='precipitation' not loaded from br data!

2019-08-29 14:41:43 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='visibility' not loaded from br data!

2019-08-29 14:41:43 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='visibility' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfc' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcname' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcnamenl' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='pressure' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfc' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcname' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcnamenl' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='pressure' not loaded from br data!

This does not appear to be consistently happening for that station. When this occurs, can you check whether the data is available on KNMI.nl on their observations page?
Dat is sometimes not reported by stations (for example: Houtribdijk and Ijmuiden are not reporting a temperature right now).

Marc, Ties
I am also seeing this behavior.
It seems that sometimes data elements are randomly missing from the json we
get from the buienradar API; even though they are usually there for that
station.
My station usually shows all elements i used for home assistant, but i
captured one occurrence in my HA logs with this warning and when i checked
the json, the element was actually not there....
What I will do is create an updated version of the buienradar library, to
remove the warning (will make it a debug message) and then provide an
update to the buienradar component to use the new library;
the missing dataelement will still not be updated (until it is back again
in the json), but at least there will not be a warning anymore....
On Thu, Aug 29, 2019 at 7:19 PM Ties de Kock<EMAIL_ADDRESS>wrote:

2019-08-29 14:41:43 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='visibility' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfc' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcname' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcnamenl' not loaded from br data!
2019-08-29 15:43:13 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='pressure' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfc' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcname' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='barometerfcnamenl' not loaded from br data!
2019-08-29 15:43:14 WARNING (MainThread) [buienradar.buienradar_json] Data element with key='pressure' not loaded from br data!
This does not appear to be consistently happening for that station. When
this occurs, can you check whether the data is available on KNMI.nl on
their observations page https://knmi.nl/nederland-nu/weer/waarnemingen?
Dat is sometimes not reported by stations (for example: Houtribdijk and
Ijmuiden are not reporting a temperature right now).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/25767?email_source=notifications&email_token=AF36HR2ZZ6GSKV5VCKZBETLQHAAI5A5CNFSM4IKGPRQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5PGO7Y#issuecomment-526280575,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF36HRZPUYTUCXT7DIC5YDDQHAAI5ANCNFSM4IKGPRQQ
.

Please keep open, I see this still on 102.1:
Data element with key='irradiance' not loaded from br data!

I havent set irradiance as a monitored condition because of the error since way back, and still the system errors out on this.
  - platform: buienradar
    monitored_conditions:
      - barometerfc
      - barometerfcname
      - condition
      - conditioncode
      - conditiondetailed
      - conditionexact
      - feeltemperature
      - humidity
#      - irradiance
      - pressure
      - groundtemperature
      - precipitation
      - precipitation_forecast_average
      - precipitation_forecast_total
      - stationname
      - symbol
      - temperature
      - visibility
      - windspeed
      - windforce
      - winddirection
      - windazimuth
      - windgust

Still happening in 102.3. I use station 'IJmuiden' (see above), which has limited data in the data stream, which causes the log entries. For conditions not reported by IJmuiden I use Schiphol.

105.5: I also have a lot of warnings about conditions not being monitored. Here is my config:
  - platform: buienradar
    timeframe: 20
    monitored_conditions:
      - symbol
      - conditiondetailed
      - precipitation_forecast_average
      - precipitation_forecast_total
      - temperature_1d
      - irradiance

Here is a part of a long list of warnings:
Data element with key='windazimuth' not loaded from br data!
Data element with key='winddirection' not loaded from br data!
Data element with key='windgust' not loaded from br data!

Same problem here. Using Ell weatherstation. Missing pressure and barometer values.
Hass version 0.106.4


404 link on evm-basics page

Issue:
https://github.com/huff-language/huff-docs/tree/main/src/tutorial/evm-basics
README.md Resources hyperlink returns 404
https://github.com/huff-language/huff-docs/blob/main/src/tutorial/evm-basics/resources/overview
Potential fix:
Change the Resources hyperlink from
https://github.com/huff-language/huff-docs/blob/main/src/tutorial/evm-basics/resources/overview
to
https://docs.huff.sh/resources/overview/

Nice catch! Pushing a fix now. Thanks!


Searching by indexes

When I'm trying to find documents by indexed field, query returns not all documents, matching search criteria.
After removing indexes, it was fixed. Fortunately, It seems it didn't affect queries performance (in my case).
Example:
Collection:
collection = db.addCollection('name', {indicies: ['left', 'right']}) //Query returns only 1 entry
collection = db.addCollection('name') //Query returns 2 entries
Collection entries:
{'code': 'code1', 'left': 1, 'right': 4}
{'code': 'code2', 'left': 2, 'right': 3}
Query:
collection.find({'left': {'$lt': 3}})

so are you saying that when specifying indexes the query results are inaccurate? that would be a major bug. Will investigate asap, thanks for reporting!

Think I found the problem, thanks!  I will try to fix tonight and add this as test case.  Our calcseg utility function only seems to work when the target value ('3') is in the middle of total all possible values in the data.  If you added another record with left = 5 (just for diagnostic purposes) it would have worked.  I'll add a check for 'all values are in range' and handle correctly.

wow, such a quick feedback. thanks guys:)

thank @obeliskos really - i'm submerged in work ATM, he's like a saviour.
On Mon, Jun 22, 2015 at 9:49 PM, Alex<EMAIL_ADDRESS>wrote:

wow, such a quick feedback. thanks guys:)
—
Reply to this email directly or view it on GitHub
https://github.com/techfort/LokiJS/issues/174#issuecomment-114258273.

Thank you for finding that, i guess there was a gap in unit test coverage.
The release i just checked in should fix it, and I added units tests and rebuilt the minified version.  You should be able to get it from this github repo if you want to test it.
Let me know if you still have issues


Only call app entry on websocket reconnect

Summary
NOT TO BE MERGED
Here is the PR where I was toying with moving the whole logic of app entry to the websocket.
The only thing to figure out still is the navigation of notifications, which is a bit chaotic.
Opening the PR to see if we want to rescue any ideas from here, but not planning to merge it.
Ticket Link
NONE
Release Note
NONE

@enahum @avinashlng1080 in case you are curious.

Alright, this looks a bit much for me to check it out at the moment.
I would like to spend tomorrow morning to go through this and then in the afternoon we can meet and talk about it.
cool?

After looking at this PR I'm definitely not convinced this is the way to go.. the way is done today is "proven", we just need to avoid making the entry calls more than once.. Why don't we just add a condition that tracks if entry is being executed and skip the other calls to entry? I think that in combination with #7067 should be more than OK, but I would love to hear your thoughts @larkox and @avinashlng1080 as this is only my point of view and perception.

The problem is that app entry is spread on many places.

Server switch
Go to call channel, when the channel is in a different server
Websocket reconnect
CRT Toggled
Deep link handling
On logout (while relaunching the app)
Entry

Normal entry
Upgrade entry
Login entry
Notification

What I mean with this... it is a chaos, and trying to set the conditions and make them work is not going to be easy, but it is going to get worse to maintain and make sure any change in the future in any of these moving pieces is setting the condition correctly.
I can give it a go to get this done with a condition (I have a few ideas already) but my main worry is how hard will be later to maintain. (Maybe I start working on it and suddenly is way easier than I anticipated)

True, it happens in many places, but as I said before, in reality each of those places should have their own logic, as the should require things to be done in a different order. We settle with the same logic as it wasn't too damaging.
But having it when the websocket connects seems:

Too late
Depends on the WebSocket being able to connect while normal request would succeed even if the WS fails for whatever reason.

As of today, the only thing I can identify for this being a problem is when the WS reconnects while there is a server switch that occurs by any of the means, being selecting a new server, switching to a channel in another server when tapping on a notification, or a deeplink, etc..

@enahum @avinashlng1080 I made the changes we talked about. I haven't been able to properly test all scenarios (specially notification), so not sure if this PR is ready to be merged. If any of you have bandwidth to take a run at this to test more scenarios and get it through the finish line, I would appreciate it. If not, I will get into it when I get back.

@devinbinnie Adding you to the review just as "knowledge share". So feel free to take your time and ask as many questions as you need, and do not worry about blocking the PR or anything.


[0.5pt] Find external API - group task

Find an API to base the development of the webapp around it. The API should allow you to

Get a list of items with a unique item id (or generate the unique id).
For a given item, get detailed information about it.
choose an APIs that doesn't need authentication. if you select an API that requires authentication, you should implement it on your own. Also, if you select an API that provides image resources your webapp will be more visual.

Hi @MarcoAurelioAntonio,
I have gone through different APIs we could use for the project, and after doing some research, I found the Meals API a good API to consume for our project.
The details of the API are as below:

Link to the API documentation: ==> MealDB API

The API and site will always remain free.

No authentication is required to consume the API.

[ ] API Methods we will be using:

Search meal by name: ==>  www.themealdb.com/api/json/v1/1/search.php?s=Arrabiata

List all meal categories: ==> www.themealdb.com/api/json/v1/1/categories.php

Hi @iAmWaris97 , this is a great job searching for everything we need before starting. I'm giving to conclude the task so we can be moving forward.
Happy coding!!


[✨] Qwik is great! Please make more videos tutorial for 2.0 or something.

Is your feature request related to a problem?
too few tutorials online.
Describe the solution you'd like
maybe can do 2.0 tutorial after 2.0 comes out or before it's officially out.
Describe alternatives you've considered
too few video tutorials online
Additional context
No response

Thanks for the feedback. We are looking for content creators that help us to produce videos and tutorials. We are centralising this kind of discussions in our Discord server
so I close this issue here and I'm looking forward to continue the discussion there. Thanks


⬆ switch to pnpm v8

pnpm released v8 on march 28. We are currently locked to v7 due to multiple issues with v8. v7 will be supported for "a few months" and recieve security updates for "at least a year".
I was unable to run v8 locally with multiple node versions that are supposed to be compatible so I think this needs a few daysat least to stew to fix some kinks before we try again.
Once v8 is up and running we need to regenerate new lock files and remove @"<8.0.0" again from the setup.yml workflow files, and then make sure there are no other breaking changes

Update sucess!


MRTK BoundsControl destroys Box Collider or NearInteractionGrabbable

Describe the bug
When the OnDisable() function is called on BoundsControl The NearInteractionGrabbalble is removed when the BoundsControl has an Bounds Override assigne to it. Otherwise it removes the Box Collider attached to the same gameobject.
To reproduce

Create a game object with a BoundsControl, Box Collider and NearInteractionGrabbable
Disable BoundsControl or disable gameobject
The NearInteractionGrabbable or the Box Collider gets removed from the game object.

Expected behavior
The BoundsControl is deactivated while the other compents are still on the gameobject.
Your setup (please complete the following information)

Unity Version 2020.3.17f1
MRTK Version v2.7.2

Target platform (please complete the following information)

HoloLens 2

Additional context
I'm trying to disable game objects from script. However, I do not want to add new components everytime I disable gameobjects with a BoundsControl attached to it.

Hey @iweinbau, when you re-enable bounds control does the NearInteractionGrabbable get re-added?

No, once the nearinteractiongrabbable component is removed it remains removed even after activating the boundscontrol


[Feature]: how to use ssr or ss proxy with golang

Does the upstream have similar features?
playwright-go is just a community-driven client for playwright. For feature requests, please refer to other officially supported clients first. Nodejs / Java / .Net / Python
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Additional context
Add any other context or screenshots about the feature request here.

Just specify the http or socks5 proxy address in browser.NewContext(playwright.BrowserNewContextOptions{ Proxy: "http://[ip]:[port]")


swagger 2.0 support?

exist?

#28

Added possibility to use collection query string
https://github.com/zfcampus/zf-apigility-documentation/issues/61


fix: Unable to use Toast UI via npm import (fix #61)

Please check if the PR fulfills these requirements

[ ] It's submitted to right branch according to our branching model
[ ] It's right issue type on title
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has description for the breaking change

Description
When Toast UI is included in the codebase via npm,
import ImageEditor from 'npm:tui-image-editor';
import CodeSnippet from 'npm:tui-code-snippet';
import ColorPicket from 'npm:tui-color-picker';

it gave me _fabric2.default.util is undefined error. This was due to how fabric library was being imported into the tui image editor.
This PR correctly imports fabric into tui-image-editor so that the clients using tui-image-editor can reliably use the library via npm.

Can one of the admins verify this patch?

Is there any progress on this? The workaround for fabric is a definite pain point.

I was able to get ToastUI Image Editor working including styles and icons using npm. In a couple of steps here is how I did it within an Angular app using npm, typescript, scss, etc.
https://gist.github.com/coderfin/103d75152f12dad8b0bda3df73189ca9

It seems to have been fixed since version 3.7.0. Close this pr.