Segment size, batch size and VRAM; fp16

Can somebody please share train config and other parameters for training on LJ data (22kHz) on 1080 (8Gb mem) card?
I am trying to use default config as in current master and getting out-of-video-memory errors.
I have already lowered batch_size to 1 and tried to reduce segment_size, but that did not help.
Also, I do not see any train options to switch to fp16; although they are in inference script.

I have one 1080Ti (11 Gb memory), with batch size of 1, it barely fits the model with default configuration. If yours is 1080, I guess other than using batch size of 1, you have to reduce the model size as well. You probably want to reduce the "n_channels" in WN_config (512 -> 256), but you might see some performance degradation. It will be a trade-off.

Was able to fit it into 8Gb VRAM by lowering "n_layers": from 8 to 7. Of course, it will likely reduce model quality, but still.
So, on 8x 1080 I was able to get some quality after 20hours of trainig - It has severe artifacts, but I can understand whats said.

Try reducing the number of channels from 512 to 256.


Create UI options in app theme extension

As a developer,
I want to config TIKI SDK pre built UI options in the app theme editor,
So that administrators can easily configure the colors and fonts for the TIKI SDK's pre-built UI.
Description
We need to provide a way for administrators to customize the UI elements, such as colors and fonts, for the pre-built UI components. This customization should be done within the app theme extension editor in Shopify, allowing administrators to preview and apply the changes in realtime.
Acceptance Criteria

The app theme extension should provide the default Shopify interface for customizing the colors and the font used in pre built UI.
While in the theme editor, the user can check a preview checkbox that will trigger TikiSdk.present() and show the UI for preview. A default user id should be used to prevent the creation of test users.

Tasks

[x] Set up the app theme extension development environment in Shopify.
[x] Design and implement the UI options for the TIKI SDK customization within the app theme extension editor.
[x] Provide color customization options, allowing administrators to select and define colors for different UI elements.
[x] Implement font customization options, allowing administrators to specify the font family.
[x] Add the preview checkbox to see the result of the options in the screen (may be a button too).


Suggestion: Add project to jsdelivr

Here is a link to the website if you're not familiar with it. Great project by the way.
https://www.jsdelivr.com/

It is already added https://www.jsdelivr.com/projects/angular.file-upload

Great thank you!
I only searched by ng-file-upload, I'm new to jsDelivr so didn't realize it might have a different name.

Hi
This package doesn't have a default file set. You can set it via jsdelivr, browser, or main field in package.json
Thanks


Adds raw option for client get requests

Prevents parsing of response body into Kubeclient objects.  In large kubernetes cluster environments where it would saving off the raw json for later use can useful for memory tight scenarios.
Usage:
client = Kubeclient::Client.new(KUBECIENT_URL, 'v1')

client.get_endpoints                                        # normal
client.get_endpoints :raw => true                           # raw

client.get_endpoints "default_endpoint"                     # normal
client.get_endpoints "default_endpoint", nil, :raw => true  # raw

cc @ilackarms

straightforward patch :+1:
looks good to me. should we be checking to make sure we get 200 OK before returning non-error? Or we expect that to be taken care of by the http client?

Fixed cops, and added some more tests, specifically around error handling.
@ilackarms regarding your question, the handle_exception block that surrounds the request will create an exception in the same fashion as if :raw wasn't provided.  That said, I did a poor job of considering that myself when I did this originally, so good catch.  As mentioned above, added some tests to verify that this is in fact the case.

Looks good, only missing a README note and should be good to go.
@simon3z @abonas PTAL
The new interface would be beneficial in watch as well (but can be implemented if/when it is needed)

Woops, sorry for not consulting the other open issues before just shipping some code... I am a terrible opensource citizen... 😭

Looks good, only missing a README note and should be good to go.

Sounds good, I will add.

The new interface would be beneficial in watch as well (but can be implemented if/when it is needed)

Don't think this would be too hard for me to add in this PR as well, if you want me to put it together.

looks reasonable ... only alternative I could think of would be KubeClient.deserializer = -> {} setter or option and then users can do raw / json / OpenStruct / OJ etc ...

Code looks pretty good (did review test).
Let's see if we'd add couple other modes to "do less" that were on the table:

Currently we parse whole JSON, extract .items array, wrap each in RecursiveOpenStruct.
Could parse whole JSON, extract .items array, but skip structs.
#254: Read whole response(?), streaming parse JSON, yield .items one by one, wrap structs.

Also useful to have streaming mode without structs.

This PR: read whole response, return raw string.
Can be useful to return "chunk iterator" or something like that for streaming raw read.

That's a big matrix :-)  I'm trying to think if these can be more modular / composable, and then perhaps kubeclient wouldn't need all of them.  Example: if we had "chunk iterator" mode, users could implement streaming JSON parse themselves.  Example (forgetting compatibility): if we had only streaming interfaces, getting array is simple matter of .to_a.

To clarify, I'm less concerned with implementation (these can be done one in term of other), but with clean API.
E.g. #254 follows common ruby idiom — iterate if block given, return array if not — so does not increase API "weight" IMO.  I don't actually think forcing user to .to_a would be a win.

yeah ... need describe blocks for that ...
On Mon, Aug 21, 2017 at 10:51 AM, Nick LaMuro<EMAIL_ADDRESS>wrote:

@NickLaMuro commented on this pull request.
In test/test_kubeclient.rb
https://github.com/abonas/kubeclient/pull/262#discussion_r134291710:

@@ -191,6 +191,14 @@ def test_nonjson_exception

 assert(exception.message.include?('Not Found'))
 assert_equal(404, exception.error_code)

return the same with raw: true

Sure. Was just after a while, it seemed like I was not very DRY in the
tests, but ¯_(ツ)_/¯
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/abonas/kubeclient/pull/262#discussion_r134291710, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAsZ8C-pGSZQSgdc6aonCRnI4wcI38Sks5sacOTgaJpZM4O8fFe
.

@cben I would argue that one thing with https://github.com/abonas/kubeclient/pull/254 implementation that I don't like is it always includes a JSON streamer, even if the user is just going to take the full response anyway.  This means that all requests now go through the stream parser, regardless if they take advantage of any benefits of it.
I don't really want to spend too much time discussing #254 in this PR, so I will leave it at that.  Effectively, what I am trying to include is an option that allows the user to implement their own interface to the raw data, but take advantage of the connection handling and API negotiation that Kubeclient provides.
Also, in doing all that, I was trying to only use the minimal amount of resources required to do that, and enable the user to create any one of the described matrix results you described outside of kubeclient.  I think what you are describing is maybe a nice end goal, but probably something that requires a significant refactoring and most likely a major version number bump.

@moolitayer Added the :raw option for the watch_ requests as well.  Let me know if that is what you were thinking for that.

@NickLaMuro following @cben concerns on the API change we took the time to think on the future outputs we want to support and tried to come up with a plan in https://github.com/abonas/kubeclient/issues/263
We think it is a good way forward, take a look and let use know.

@NickLaMuro can you elaborate a little about how you plan to use this?

@NickLaMuro This PR is valuable as is. I ask that input parameter will be changed to accommodate additional values in the future. I think :as => :raw is the best name we have right now, you might have a better idea.

I think :as => :raw is the best name we have right now, you might have a better idea.

@moolitayer Nope, that works for me.  I can make the change.

@cben @grosser any chance for an explicit ack once we have a new version?

can do! using as: :raw also leaves the door open for more de-serializer choices later on :)

@cben can you officially approve if you don't need any other changes? @ilackarms please review.

@grosser Good suggestions, and thanks for looking over the README additions.  Wasn't sure how to put things, so I like your changes.

LGTM :+1:
cc @simon3z @ilackarms

@NickLaMuro can you restart Travis

@moolitayer Sorry for the delay.  Am on PTO today, but made a quick commit message update and re-pushed the last commit.  Hopefully that causes the tests to pass.

:tada: :cake:

@simon3z @abonas Is it possible to release a new version of the gem with this patch? It would be super useful for me, thank you!

@simon3z @abonas Is it possible to release a new version of the gem with this patch? It would be super useful for me, thank you!

@stefanmb let's continue on https://github.com/abonas/kubeclient/pull/271


glfw on headless machine

Hi, thanks for the great work! I am trying to run the code on a headless server but I get an error with glfw:
ends/_glfw.py", line 215, in _vispy_get_native_app
raise OSError('Could not init glfw:\n%r' % _glfw_errors)
OSError: Could not init glfw:
["Error 65544: b'X11: Failed to open display '"].
I did some research, and it seems that glfw does not support headless rendering. Have you ever tried it?

You can try to run the EGL headless examples from vispy here: https://github.com/vispy/vispy/tree/main/examples/offscreen
(I don't have sudo to install libgles2-mesa-dev on my server.)
If EGL backend works for your server, then you can modify inference_helper.py, and switch glfw to EGL.
Also something from vispy: https://vispy.org/faq.html#how-to-render-headless-off-screen-with-vispy


Catalogue Scenario C needs to be updated

The process for scenario C needs to be clarified and updated.
To request details for a seller-product or a customer_article an UUID is needed. Is this statement correct and agreed? i.e. papiNet always require a UUID to request information about an item. We have seen that other API implementations also use other identifiers, e.g. like papiNet otherIdentifier.
If the customer doesn't store the UUID in his business system, then a 2 step solution is needed to get the details, i.e. step 1 to get UUID using otherIdentifier and step 2 to get the details using UUID.
My proposal if the statement above is correct and agreed:

The description of Scenario C should state that the customer doesn't store the UUID and that a 2 step solution is needed to get the details of a seller-product or a customer-article using the otherIdentifier.

The descriptions of the steps in scenario C should also be updated to describe the 2 step solution.

We should also document our API design rules as have done for the papiNet XML standard.

"Step 3 of Scenario C" is the starting of the "2-step solution" described above.
We have started to document our API design rules with the papiNet-JSON-Style-Guide.md file.


equihash.so migrato from libsodium to use same blake2b function in modCrypto

This change will help clean up the unnecessary dependency in :
https://github.com/aionnetwork/aion/tree/dev/native/linux/sodium/sodium
by replace blake2b function from libsodium to libblake2b.

Done.


Chart Title

"Chart Title" shows up by default as the chart's title before my chart loads, is there anyway to stop this behaviour?

Yeah, set the default value to something else in your chartOptions

Is chartOptions in javascript or is it something I can apply on the  tag itself?

chartOptions is a scope object defined in the tag and implemented wherever you want (most likely in the controller):
<highchart config="chartConfig"></highchart>
maps to
$scope.chartConfig = {} in your controller
and
<highchart config="foobar"></highchart>
maps to
$scope.foobar = {} in your controller
Of course, if you wanted, you could map a textbox to chartConfig.title using ng-model and just type the title into the textbox.

Understood, thank you.


Please add a license file :)

I found that your code uses  Boost Software License, Version 1.0.
but please add a license file to the repo too.
Thank you :)

Thanks, fixed that oversight.


It's no longer possible to scroll down the Explorer menu

It's no longer possible to scroll down the Explorer menu. This is problematic when an item in the Explorer menu has more children than can fit on the screen. The additional children are inaccessible!
The original issue is described in #2520 and fixed in #2525 (this commit). However, the fix changes the position of .explorer from absolute to fixed, which seems to be the problem.
A temporary solution is to add a new CSS file to the administration interface -- using the insert_global_admin_css hook -- that sets position: absolute;.

Thanks for the report! I've now reverted the fix from #2525, because inability to access menu items is a more severe bug than the original cosmetic issue. Reverted in 64132728d151803cbf739ea78aeff3ffd87f8a0e (master) and 1814579a77ef5db72e4ab7da03365c33580ebfef (1.5.x).


Update pipelines to use BuildTransportPackage.ps1

Refactor pipelines to use BuildTransportPackage.ps1. Currently the yml and the ps1 does exactly the same thing so it is important that we need to consolidate them. Much of the BuildTransportPackage.ps1 needed refactoring so that the pipeline can use it in steps. Running the BuildTransportPackage.ps1 in the innerloop will run all the steps by default.

Updated CI and BuildFoundation to use Powershell Script
Enable Helix Tests in BuildFoundation.yml if branch is develop
Move DevCheck to the root directory
Deleted much of the unused AzurePipelines yml templates or ones that are outdated by the script

/azp run

/azp run

/azp run

Does BuildTransportPackages.ps1 still work locally?

Does BuildTransportPackages.ps1 still work locally?

Yes

/azp run

/azp run


Elide uninteresting fields in object diffs.

What this PR does / why we need it:
Makes diffs on large objects much less verbose but not any less useful, by omitting these fields in the object which are not specified in the assertion and are at least moderately long when serialized.
This way, asserting on status.availableReplicas of a Deployment (which is missing if zero replicas are available) will still show the status.unavailableReplicas for example, but will omit spec completely unless the assertion also mentions it.
This saves hundreds to thousands of lines of logs to scroll when debugging failures of my operator tests. See the test for an example output. Before this change, the diff would contain the entirety of the "actual" resource from a cluster.

Fixes #497
Fixes #370

re-reading the PR desc... the first paragraph or sentence would make a perfect godoc for the prune func


Wallbox Dadapower Error Phase change PV Mode

Describe the bug
Hello there,
I use the EVCC addon in Home Assistant with a Dadapower wallbox. I've been getting the following error message for a few days now.
Garage: charger logic error: current
mismatch (got 16A measured,
expected 6A)
Nothing has actually changed, except the wallbox manufacturer updated the wallbox a few weeks ago, after which it worked again, although I needed a sponsor token shortly afterwards, which wasn't the case before. It does not recognize the excess correctly and always charges with 11kW when there is an excess, even if there is only a 2kW excess. Somehow he can't handle the phase change.
Does anyone have an idea why this is or how I can fix it?
Steps to reproduce

Start EVCC starten
Choose PV Mode and wait for PV surplus
Then the error occurs

Configuration details
network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: http
  # host is the hostname or IP address
  # if the host name contains a `.local` suffix, the name will be announced on MDNS
  # docker: MDNS announcements don't work. host must be set to the docker host's name.
  host: 192.168.xxx.xx:8123
  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

interval: 10s # control cycle interval

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

# sponsor token enables optional features (request at https://sponsor.evcc.io)
sponsortoken: xxx

# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true

# log settings
log: info
levels:
  site: debug
  lp-1: debug
  lp-2: debug
  cache: error
  db: error

# modbus proxy for allowing external programs to reuse the evcc modbus connection
# each entry will start a proxy instance at the given port speaking Modbus TCP and
# relaying to the given modbus downstream device (either TCP or RTU, RS485 or TCP)
modbusproxy:
  #  - port: 5200
  #    uri: solar-edge:502
  #    # rtu: true
  #    # readonly: true

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:
  - name: grid
    type: custom
    power:
      source: mqtt
      topic: pvdataevcc/sensor/sensor.strom_aktuell
      scale: 1
      timeout: 30s
    energy:
      source: mqtt
      topic: pvdataevcc/sensor/sensor.strom_netzbezug
      scale: 1
      timeout: 30s

  - name: pv
    type: custom
    power:
      source: mqtt
      topic: pvdataevcc/sensor/sensor.solar_power_current_power
      scale: 1
      timeout: 30s
    energy:
      source: mqtt
      topic: pvdataevcc/sensor/sensor.solar_power_energy_today
      scale: 1
      timeout: 30s

# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for documentation see https://docs.evcc.io/docs/devices/chargers

chargers:
  - name: my_charger
    type: template
    template: dadapower

    # Modbus TCP
    modbus: tcpip
    id: 1
    host: 192.168.xxx.xx # Hostname
    port: 502 # Port

# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for documentation see https://docs.evcc.io/docs/devices/vehicles
vehicles:
  - name: my_car
    type: template
    template: teslamate
    title: Model Y Domi # Wird in der Benutzeroberfläche angezeigt (optional)
    id: 1 # optional
    capacity: 77 # Akkukapazität in kWh (optional)

# site describes the EVU connection, PV and home battery
site:
  title: Home # display name for UI
  meters:
    grid: grid # grid meter
    pv: pv
      #- my_pv # list of pv inverters/ meters
  #  aux:
     # - aux # list of auxiliary meters for adjusting grid operating point
#   residualPower: 100 # additional household usage margin
 # smartCostLimit: 0 # set cost limit for automatic charging in PV mode

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: Garage # display name for UI
    charger: my_charger # charger
    mode: pv # "off" set default charge mode, use "off" to disable by default if charger is publicly available
    vehicle: my_car # set default vehicle (disables vehicle detection)
    # resetOnDisconnect: false # set defaults when vehicle disconnects
    # phases: 0 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
    # minCurrent: 6 # minimum charge current (default 6A)
    # maxCurrent: 16 # maximum charge current (default 16A)

    # remaining settings are experts-only and best left at default values
    priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
    soc:
      # polling defines usage of the vehicle APIs
      # Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
      # or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
      poll:
        # poll mode defines under which condition the vehicle API is called:
        #   charging: update vehicle ONLY when charging (this is the recommended default)
        #   connected: update vehicle when connected (not only charging), interval defines how often
        #   always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
        mode: charging
        # poll interval defines how often the vehicle API may be polled if NOT charging
        interval: 60m
      estimate: true # set false to disable interpolating between api updates (not recommended)
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 3m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)

# tariffs are the fixed or variable tariffs
tariffs:
  currency: EUR # three letter ISO-4217 currency code (default EUR)
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.2980 # EUR/kWh
    #zones:
     # - days: Mon-Fri
     #   hours: 2-5
     #   price: 0.2 # EUR/kWh
     # - days: Sat,Sun
     #   price: 0.15 # EUR/kWh

    # or variable tariffs
    # type: tibber
    # token: "476c477d8a039529478ebd690d35ddd80e3308ffc49b59c65b142321aee963a4" # access token
    # homeid: "cc83e83e-8cbf-4595-9bf7-c3cf192f7d9c" # optional if multiple homes associated to account

    # type: awattar
    # region: de # optional, choose at for Austria
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)

    # type: octopusenergy
    # tariff: AGILE-FLEX-22-11-25 # Tariff code
    # region: A # optional

    # type: elering # Nordpool
    # region: ee # or lt, lv, fi
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)

    # type: energinet # Energinet using the price in DKK
    # region: dk1 # or dk2
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.082 # EUR/kWh

    # type: octopusenergy
    # tariff: AGILE-FLEX-22-11-25 # Tariff code
    # region: A # optional
  co2:
    # co2 tariff provides co2 intensity forecast and is for co2-optimized target charging if no variable grid tariff is specified
    #type: grünstromindex # GrünStromIndex (Germany only)
    #zip: 35236

    # type: electricitymaps # https://app.electricitymaps.com/map
    # uri: <uri>
    # token: <token>
    # zone: DE

    # type: ngeso # National Grid Electricity System Operator data (United Kingdom only) https://carbonintensity.org.uk/
    # provides national data if both region and postcode are omitted - do not supply both at the same time!
    # region: 1 # optional, coarser than using a postcode - see https://api.carbonintensity.org.uk/ for full list
    # postcode: SW1A1AA # optional

# mqtt message broker
mqtt:
  broker: 192.168.xxx.xx:1883
  #topic:  # root topic for publishing, set empty to disable
  user: mqtt-user1
  password: xxx

# influx database
influx:
  # url: http://localhost:8086
  # database: evcc
  # user:
  # password:

# eebus credentials
eebus:
  # uri: # :4712
  # interfaces: # limit eebus to specific network interfaces
  # - en0
  # certificate: # local signed certificate, required, can be generated via `evcc eebus-cert`
  #   public: # public key
  #   private: # private key

# push messages
messaging:
  events:
    start: # charge start event
      title: Charge started
      msg: Started charging in "${mode}" mode
    stop: # charge stop event
      title: Charge finished
      msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
    connect: # vehicle connect event
      title: Car connected
      msg: "Car connected at ${pvPower:%.1fk}kW PV"
    disconnect: # vehicle connected event
      title: Car disconnected
      msg: Car disconnected after ${connectedDuration}
    soc: # vehicle soc update event
      title: Soc updated
      msg: Battery charged to ${vehicleSoc:%.0f}%
    guest: # vehicle could not be identified
      title: Unknown vehicle
      msg: Unknown vehicle, guest connected?
  services:
  # - type: pushover
  #   app: # app id
  #   recipients:
  #   - # list of recipient ids
  # - type: telegram
  #   token: # bot id
  #   chats:
  #   - # list of chat ids
  # - type: email
  #   uri: smtp://<user>:<password>@<host>:<port>/?fromAddress=<from>&toAddresses=<to>
  # - type: ntfy
  #   uri: https://<host>/<topics>
  #   priority: <priority>
  #   tags: <tags>

Log details
[main  ] INFO 2024/09/27 12:16:11 evcc 0.130.12
[main  ] INFO 2024/09/27 12:16:11 using config file: /config/evcc.yaml
[db    ] INFO 2024/09/27 12:16:11 using sqlite database: /data/evcc.db
[mqtt  ] INFO 2024/09/27 12:16:11 connecting evcc-325769715 at tcp://192.168.xxx.xx:1883
[mqtt  ] DEBUG 2024/09/27 12:16:11 tcp://192.168.xxx.xx:1883 connected
[main  ] INFO 2024/09/27 12:16:11 listening at :7070
[lp-1  ] DEBUG 2024/09/27 12:16:11 charge total import: 3176.614kWh
[site  ] INFO 2024/09/27 12:16:13 site config:
[site  ] INFO 2024/09/27 12:16:13   meters:      grid ✓ pv ✓ battery ✗
[site  ] INFO 2024/09/27 12:16:13     grid:      power ✓ energy ✓ currents ✗
[site  ] INFO 2024/09/27 12:16:13     pv 1:      power ✓ energy ✓ currents ✗
[site  ] INFO 2024/09/27 12:16:13   vehicles:
[site  ] INFO 2024/09/27 12:16:13     vehicle 1: range ✓ finish ✗ status ✓ climate ✗ wakeup ✗
[lp-1  ] INFO 2024/09/27 12:16:13 loadpoint 1:
[lp-1  ] INFO 2024/09/27 12:16:13   mode:        pv
[lp-1  ] INFO 2024/09/27 12:16:13   charger:     power ✓ energy ✓ currents ✓ phases ✓ wakeup ✗
[lp-1  ] INFO 2024/09/27 12:16:13   meters:      charge ✓
[lp-1  ] INFO 2024/09/27 12:16:13     charge:    power ✓ energy ✓ currents ✓
[lp-1  ] DEBUG 2024/09/27 12:16:13 phase timer inactive
[lp-1  ] DEBUG 2024/09/27 12:16:13 pv timer inactive
[lp-1  ] INFO 2024/09/27 12:16:13 vehicle updated: unknown -> Model Y Domi
[lp-1  ] DEBUG 2024/09/27 12:16:13 max charge current: 6A
[site  ] WARN 2024/09/27 12:16:13 interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
[site  ] DEBUG 2024/09/27 12:16:13 ----
[lp-1  ] DEBUG 2024/09/27 12:16:13 charge power: 11246W
[lp-1  ] DEBUG 2024/09/27 12:16:13 charge currents: [15.9 15.9 16]A
[site  ] DEBUG 2024/09/27 12:16:15 pv power: 1750W
[site  ] DEBUG 2024/09/27 12:16:15 grid meter: 9993W
[site  ] DEBUG 2024/09/27 12:16:15 site power: 9993W
[lp-1  ] DEBUG 2024/09/27 12:16:15 vehicle odometer: 14190km
[lp-1  ] DEBUG 2024/09/27 12:16:15 charge total import: 3176.629kWh
[lp-1  ] DEBUG 2024/09/27 12:16:15 charger status: C
[lp-1  ] INFO 2024/09/27 12:16:15 car connected
[lp-1  ] DEBUG 2024/09/27 12:16:15 pv timer elapse
[lp-1  ] DEBUG 2024/09/27 12:16:15 pv timer inactive
[lp-1  ] DEBUG 2024/09/27 12:16:15 charge total import: 3176.629kWh
[lp-1  ] INFO 2024/09/27 12:16:15 start charging ->
[lp-1  ] DEBUG 2024/09/27 12:16:15 wake-up timer: stop
[lp-1  ] DEBUG 2024/09/27 12:16:15 charger vehicle id: N-04ab1d50700000-Mod
[lp-1  ] DEBUG 2024/09/27 12:16:15 vehicle status: B
[lp-1  ] DEBUG 2024/09/27 12:16:15 vehicle soc: 51%
[lp-1  ] DEBUG 2024/09/27 12:16:15 vehicle range: 261km
[lp-1  ] WARN 2024/09/27 12:16:15 charger logic error: current mismatch (got 16A measured, expected 6A)
[lp-1  ] DEBUG 2024/09/27 12:16:15 available power 1253W < 4140W min 3p threshold
[lp-1  ] DEBUG 2024/09/27 12:16:15 start phase scale1p timer
[lp-1  ] DEBUG 2024/09/27 12:16:15 phase scale1p in 3m0s
[lp-1  ] DEBUG 2024/09/27 12:16:15 pv charge current: 1.55A = 16A + -14.5A (9993W @ 3p)
[lp-1  ] DEBUG 2024/09/27 12:16:15 projected site power 7233W >= 0W disable threshold
[lp-1  ] DEBUG 2024/09/27 12:16:15 pv disable in 0s
[lp-1  ] DEBUG 2024/09/27 12:16:15 pv disable timer elapsed
[lp-1  ] DEBUG 2024/09/27 12:16:15 charger disable
[lp-1  ] DEBUG 2024/09/27 12:16:15 wake-up timer: stop
[site  ] DEBUG 2024/09/27 12:16:23 ----
[lp-1  ] DEBUG 2024/09/27 12:16:23 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:16:23 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:16:23 pv power: 1712W
[site  ] DEBUG 2024/09/27 12:16:23 grid meter: 9961W
[site  ] DEBUG 2024/09/27 12:16:23 site power: 9961W
[lp-1  ] DEBUG 2024/09/27 12:16:23 vehicle odometer: 14190km
[lp-1  ] DEBUG 2024/09/27 12:16:23 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:16:23 charger status: B
[lp-1  ] INFO 2024/09/27 12:16:23 stop charging <-
[lp-1  ] DEBUG 2024/09/27 12:16:23 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:16:23 soc estimated: 51.02% (vehicle: 51.00%)
[lp-1  ] DEBUG 2024/09/27 12:16:23 vehicle soc: 51%
[lp-1  ] DEBUG 2024/09/27 12:16:23 vehicle range: 261km
[lp-1  ] DEBUG 2024/09/27 12:16:23 available power -9961W < 4140W min 3p threshold
[lp-1  ] DEBUG 2024/09/27 12:16:23 phase scale1p in 0s
[lp-1  ] DEBUG 2024/09/27 12:16:23 switched phases: 1p
[lp-1  ] DEBUG 2024/09/27 12:16:23 phase timer inactive
[lp-1  ] DEBUG 2024/09/27 12:16:23 pv charge current: 0A = 0A + -43.3A (9961W @ 1p)
[lp-1  ] DEBUG 2024/09/27 12:16:23 pv enable timer reset
[lp-1  ] DEBUG 2024/09/27 12:16:23 pv timer inactive
[site  ] DEBUG 2024/09/27 12:16:33 ----
[lp-1  ] DEBUG 2024/09/27 12:16:33 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:16:33 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:16:33 pv power: 1712W
[site  ] DEBUG 2024/09/27 12:16:33 grid meter: -1277W
[site  ] DEBUG 2024/09/27 12:16:33 site power: -1277W
[lp-1  ] DEBUG 2024/09/27 12:16:33 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:16:33 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:16:33 pv charge current: 5.55A = 0A + 5.55A (-1277W @ 1p)
[site  ] DEBUG 2024/09/27 12:16:43 ----
[lp-1  ] DEBUG 2024/09/27 12:16:43 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:16:43 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:16:43 pv power: 1712W
[site  ] DEBUG 2024/09/27 12:16:43 grid meter: -1239W
[site  ] DEBUG 2024/09/27 12:16:43 site power: -1239W
[lp-1  ] DEBUG 2024/09/27 12:16:43 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:16:43 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:16:43 pv charge current: 5.39A = 0A + 5.39A (-1239W @ 1p)
[site  ] DEBUG 2024/09/27 12:16:53 ----
[lp-1  ] DEBUG 2024/09/27 12:16:53 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:16:53 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:16:53 pv power: 1616W
[site  ] DEBUG 2024/09/27 12:16:53 grid meter: -1190W
[site  ] DEBUG 2024/09/27 12:16:53 site power: -1190W
[lp-1  ] DEBUG 2024/09/27 12:16:53 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:16:53 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:16:53 pv charge current: 5.17A = 0A + 5.17A (-1190W @ 1p)
[site  ] DEBUG 2024/09/27 12:17:03 ----
[lp-1  ] DEBUG 2024/09/27 12:17:03 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:17:03 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:17:03 pv power: 1616W
[site  ] DEBUG 2024/09/27 12:17:03 grid meter: -1155W
[site  ] DEBUG 2024/09/27 12:17:03 site power: -1155W
[lp-1  ] DEBUG 2024/09/27 12:17:03 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:17:03 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:17:03 pv charge current: 5.02A = 0A + 5.02A (-1155W @ 1p)
[site  ] DEBUG 2024/09/27 12:17:13 ----
[lp-1  ] DEBUG 2024/09/27 12:17:13 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:17:13 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:17:13 pv power: 1524W
[site  ] DEBUG 2024/09/27 12:17:13 grid meter: -1118W
[site  ] DEBUG 2024/09/27 12:17:13 site power: -1118W
[lp-1  ] DEBUG 2024/09/27 12:17:13 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:17:13 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:17:13 pv charge current: 4.86A = 0A + 4.86A (-1118W @ 1p)
[site  ] DEBUG 2024/09/27 12:17:23 ----
[lp-1  ] DEBUG 2024/09/27 12:17:23 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:17:23 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:17:23 pv power: 1524W
[site  ] DEBUG 2024/09/27 12:17:23 grid meter: -1101W
[site  ] DEBUG 2024/09/27 12:17:23 site power: -1101W
[lp-1  ] DEBUG 2024/09/27 12:17:23 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:17:23 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:17:23 pv charge current: 4.79A = 0A + 4.79A (-1101W @ 1p)
[site  ] DEBUG 2024/09/27 12:17:33 ----
[lp-1  ] DEBUG 2024/09/27 12:17:33 charge power: 0W
[lp-1  ] DEBUG 2024/09/27 12:17:33 charge currents: [0 0 0]A
[site  ] DEBUG 2024/09/27 12:17:33 pv power: 1472W
[site  ] DEBUG 2024/09/27 12:17:33 grid meter: -1072W
[site  ] DEBUG 2024/09/27 12:17:33 site power: -1072W
[lp-1  ] DEBUG 2024/09/27 12:17:33 charge total import: 3176.631kWh
[lp-1  ] DEBUG 2024/09/27 12:17:33 charger status: B
[lp-1  ] DEBUG 2024/09/27 12:17:33 pv charge current: 4.66A = 0A + 4.66A (-1072W @ 1p)

What type of operating system are you running?
HomeAssistant Add-on
Nightly build

[X] I have verified that the issue is reproducible with the latest nightly build

Version
v0.130.12

Nothing has actually changed, except the wallbox manufacturer updated the wallbox a few weeks ago, after which it worked again,

So it's not an evcc issue if that wasn't updated!

although I needed a sponsor token shortly afterwards, which wasn't the case before.

Vendor has stopped sponsoring us, sorry for the inconvenience.

It does not recognize the excess correctly and always charges with 11kW when there is an excess, even if there is only a 2kW excess. Somehow he can't handle the phase change.

You can test that standalone (without evcc running) using
evcc meter

Nothing has actually changed, except the wallbox manufacturer updated the wallbox a few weeks ago, after which it worked again

Which firmware version is now working at your dadapower?
Do you have a Single- or Dual-Wallbox?

It is the single wallbox with software version 1.2.22.
Is it maybe necessary to adapt the configuration for example the power limits?

Hello,
there is a bug in version 1.2.22. Please install version 1.2.23.

Great support, thank you 👍🏻

Thank you I will check it and if the error happen again I will repost it.


[BUG] pygwalker bug report

Error Message
Failed to load model class 'BoxModel' from module '@jupyter-widgets/controls'
ChunkLoadError: Loading chunk 345 failed.
Difficult to decode such an error message.

refer it: https://github.com/Kanaries/pygwalker/issues/487
update jupyterlab or ipywidgets.


Incrementing the minor version, after the mismatches-after-variant change

Fixes #75

This change is

Coverage remained the same at 88.88% when pulling e355e544155d2646433a02317c71e20167c514dd on increment-version into 4b82673d1833772e66f80422e34d689932c764fa on master.

Looks like Travis needs the newer isovar to get onto PyPI:
https://www.dropbox.com/s/itho2ik6wyx414q/Screenshot 2017-01-17 20.30.56.png?dl=1


Add/update schemas, and reference them in response object

This PR:

Addresses RAC-4622, to update/correct schema.
Reference them in responses.
The original issue was seen while generating client libraries in GO/JAVA, where return types are all list,
and the user has to manually parse the returned data. This addresses that.
Fix few responses return type, array of object VS just objects.

@RackHD/corecommitters @jasl8r

+1


Simplify LWRP Deprecations Proposal 1

Our logic for creating the deprecation class was too complicated and had
a lot of edge cases. Simplifying here to only deprecate when
:treat_deprecation_warnings_as_errors is set. This means that warnings
will no longer be printed, however this is a lot less risky.
Loading the lwrp multiple times causes problems when comparing classes
due to the their dynamic nature. It worked fine when we were overriding
the things that checked.
I've left the tests mostly as is, other than the fact that the test
lwrp is loaded only once. The tests should still hold true, even
with the new implementation.

:+1:

I like pink :+1:

closes #3621


git-lfs not available in lint job containers (provider-ci)

We need to either install git-lfs, remove the use of git-lfs from those jobs (as I believe linting not configured on larger providers) or change how we run the linting job, which I would recommend, there is an action or we can install golanci with curl.  See sample failure here: https://github.com/pulumi/pulumi-mongodbatlas/actions/runs/3015667700/jobs/4847380853

Actually we are able to remove the use of git-lfs now, so I will close this issue.


GameStop false positive

Description
The button component in the DOM we are scraping has the "Add to Cart" text as well as "Not Available"
[11:25:28 AM] info :: ℹ selected stores: gamestop
[11:25:28 AM] info :: ℹ selected series: 3070, 3080, 3090
[11:25:29 AM] debug :: [
    {
        "brand": "test:brand",
        "model": "test:model",
        "series": "test:series",
        "url": "https://www.gamestop.com/video-games/pc/components/graphics-cards/products/tuf-gaming-geforce-rtx-3080-graphics-card/11109446.html"
    },
    {
        "brand": "asus",
        "model": "tuf oc",
        "series": "3080",
        "url": "https://www.gamestop.com/video-games/pc/components/graphics-cards/products/tuf-gaming-geforce-rtx-3080-graphics-card/11109446.html"
    }
]
[11:25:37 AM] debug :: [gamestop] Starting lookup...
[11:25:41 AM] debug :: <button class="add-to-cart btn btn-primary " data-pid="11109446" data-gtmdata="{"productInfo":{"sku":"226285","productID":"11109446","name":"TUF Gaming GeForce RTX 3080 Graphics Card","category":"Video Games/PC/Components/Graphics Cards","brand":"TUF","subGenre":"","platform":"PC","condition":"New","variant":"New","genre":"","availability":"Not Available","productType":"regular","zoneSource":"PDP"},"price":{"sellingPrice":"749.99","basePrice":"749.99","currency":"USD"}}" data-buttontext="Add to Cart" disabled="disabled">Not Available</button>

Possible solution
Perhaps look into ensuring that there is only an in stock label? Not 100%.

Can confirm.  As soon as I added gamestop to my .env, it started popping off false positives.

stores.ts defines an outOfStock label,
export type Labels = {
bannedSeller?: LabelQuery;
captcha?: LabelQuery;
container?: string;
inStock?: LabelQuery;
outOfStock?: LabelQuery;
};
In lookupCardInStock it check for it, it the outOfStock label is present, it immediately returns false.
async function lookupCardInStock(store: Store, page: Page, link: Link) {
const baseOptions: Selector = {
requireVisible: false,
selector: store.labels.container ?? 'body',
type: 'textContent'
};
if (store.labels.inStock) {
	const options = {...baseOptions, requireVisible: true, type: 'outerHTML' as const};

	if (!await pageIncludesLabels(page, store.labels.inStock, options)) {
		Logger.info(Print.outOfStock(link, store, true));
		return false;
	}
}

**if (store.labels.outOfStock) {
	if (await pageIncludesLabels(page, store.labels.outOfStock, baseOptions)) {
		Logger.info(Print.outOfStock(link, store, true));
		return false;
	}
}**

if (store.labels.bannedSeller) {
	if (await pageIncludesLabels(page, store.labels.bannedSeller, baseOptions)) {
		Logger.warn(Print.bannedSeller(link, store, true));
		return false;
	}
}

if (store.labels.captcha) {
	if (await pageIncludesLabels(page, store.labels.captcha, baseOptions)) {
		Logger.warn(Print.captcha(link, store, true));
		await delay(getSleepTime());
		return false;
	}
}

return true;

}
So if we just add the Not Available displayed to the  outOfStock labels of the gamestop model, then that should do it, wouldn't it?

That seems to have worked.
I modefied that labels for gamestop.ts to include the outOfStock label,
labels: { 		inStock: { 			container: '.add-to-cart', 			text: ['add to cart'] 		}, 		outOfStock: { 			container: '.add-to-cart', 			text: ['not available'] 		}

@adolfox That's exactly it! Nice job. I totally forgot we had label.outOfStock... Lol. Thanks for fixing this.

@jef you're welcome.  Thank you for this great project!


Replacing run.search and descendant/ancestors/get.related.table/wrapper functions to use the get.relatives and new recursive functions

I see that commits 299284a533d0e76def9e210cb17ee9704003c2dd, b57a4d95aead28f32ed3bf3b737e1b4491d63adb and 0615defb9d82a8c40e2fdd102bf9780172c3933b have brought back some functions that were deleted in commit 2737a1f7c580d1ea64705ce0523fd561ab989b53. They were not deleted by mistake but because they have been replaced by get.relatives, which uses the recursive functions get.descendants and get.ancestors instead of the combo wrapper/get.related.table/ancestors/descendants.
This was explained a bit in more detail in the pull requestion here, explaining also some of the positive side effect of these new function:
https://github.com/BIADwiki/BIADwiki/pull/12
But the pull request did not  deleted these old functions, this was done quickly in 2737a1f7c580d1ea64705ce0523fd561ab989b53.  We probably should have documented than more clearly...
Basically, these functions (run.searcher,wrapper,...) should not be used anymore and we should have or rename get.relatives to run.searcher or deleted all uses of run.searcher.  I guess what happened is that run.searcher was still declared/used somewhere but failed as the other functions were deleted.
Regarding the problem of sanitizing string, that I see @AdrianTimpson you probably spotted too and tried to fix here: e2fdcfa282a24f8bb0aedf3deaf170d62bfa2a4b ; this was something I also spotted in my shiny app here:  https://github.com/simoncarrignon/BIADtools/issues/5 but I think this should be treated/dealed with within the function query.database, making sure the string are sanitized using something like DBI::dbQuoteString. This will be a bit cleaner, work forany call to query.database and will help dealing and solve some of the errors I wanted to take care of in #14

I agree with all of that, apologies for my confusion!


Permit join defaults to on

The permit join defaults to on, allowing any device to join the network at any time.  This should default to off, and only turned on when the user allows permit join, and only for a limited period of time.

Good point, do you have suggestion how we should expose this in API?

There is the existing method sendPermitJoinRequest but it is not called from anything in zigbee4java.  The firmware already supports the join timeout also.
I'm thinking of adding wrappers for this method in ZigBeeApi like public void permitJoin(short timeout) and public void permitJoin(short timeout, ZToolAddress16 address).  This would allow all devices to join or just one device specified by address.  The user application would call this method when joining is desired.
Also another change would be to call sendPermitJoinRequest to turn off join, on every startup, because the dongle defaults to on.

Sounds like a good plan. We could maybe add constructor parameter to API for configuring whether permit join should be disabled on startup? At least in lab environment it might be nice to have devices joining automatically.
Lets make the method signature use int instead of short and define the unit. This is pretty normal convention:
public void permitJoin(int timeoutMillis)
public void permitJoin(int timeoutMillis, ZToolAddress16 address)
Would you like to implement this change?

Maybe use a System.getProperty for the permit join override, this way it can easily be set on the command line.
The firmware API for ZDO_MGMT_PERMIT_JOIN_REQ specifies the timeout in seconds as follows: Specifies the duration to permit joining. 0 = join disabled. 0xff = join enabled.  0x01-0xfe = number of seconds to permit joining.  So on the one hand I see using milliseconds as other methods use this unit,  on the other hand the firmware does not support it so precision is implicitly lost if the permitJoin method does the timeoutMillis / 1000.  I do agree with the naming convention.
Yes I'd be happy to do this change.  For these smaller changes would you like me to create a branch and let you merge it into master?

Hi
System properties are configuration mechanism for  programs and as such could be used for console but I would prefer optional command line argument. On API level it is good style to use programmatic non JVM wide way to set this kind of options. If there are security concerns that weight against API level option, I would consider leaving the option out all together rather than implementing environment variable.
As constructor parameter count is increasing for ZigBeeApi class we could:

create ZigBeeApiConfiguration class,
add another constructor with optional arguments,
or create setter for this option which could be invoked before startup.

In my opinion this kind of change can implemented in master as long as there is agreement regarding API level changes.

Hi Tommi
Personally I prefer a parameter parser that creates a static class of
options. Keeps it simple, removes specific dependencies and supports an
unknown amount of parameters increase.
Kind regards,
Danny Watson
On 23 Mar 2015 20:22, "Tommi S.E. Laukkanen"<EMAIL_ADDRESS>wrote:

Hi
System properties are configuration mechanism for programs and as such
could be used for console but I would prefer optional command line
argument. On API level it is good style to use programmatic non JVM wide
way to set this kind of options. If there are security concerns that weight
against API level option, I would consider leaving the option out all
together rather than implementing environment variable.
As constructor parameter count is increasing for ZigBeeApi class we could:

create ZigBeeApiConfiguration class,
add another constructor with optional arguments,
or create setter for this option which could be invoked before startup.

In my opinion this kind of change can implemented in master as long as
there is agreement regarding API level changes.
—
Reply to this email directly or view it on GitHub
https://github.com/tlaukkan/zigbee4java/issues/17#issuecomment-85177169.

@tlaukkan How about something like 3) but it could be invoked after startup if desired.  On startup the join will be disabled, but it is always possible to re-set the join to always enabled with no timeout.  This way the API is simple and all that is needed is to do something like permitJoin(true) after startup to set it back enabled indefinitely.  The firmware supports this with the 0xff value.
The implementation in the console app could be done a number of ways.  I think at least adding another  console command to change the join setting would be good.  I don't have a strong opinion about this.

Hi
Good points and viable plan. We can either  allow permit join timeout value -1 equaling infinite timeout  or separate method with boolean parameter?
From my perspective this feature is go for direct master implementation. 👍
Best regards,
Tommi

Hi Danny
Do you refer to console parameter parsing? Console has room for improvement as it started off as an example and has been evolving since to become a development tool.
Or how to parametrize ZigBeeApi programmatically?
Br,
Tommi

To enhancing the functionality of command-line parsing at launch, I would recommend looking at Apache Commons CLI, which I've worked with in the past and provides a great framework to avoid reinventing the wheel.  https://commons.apache.org/proper/commons-cli/
For the console itself; that's a conversation to be had... I would just mention that I am currently refactoring code between zigbee-console-common and zigbee-console-javase in preparation for implementation of zigbee-console-android.
Summary of the changes is:

Console is constructed with generic InputStream / OutputStream.
Console runs on it's own Thread.
Neither of these changes should affect the current behaviour.

Hi,
The CLI and using a common library that is understood is a great idea.
On the command parser we are all of the agreement that it's upto the
application to decide what parameters to use so the parser can be issued as
an example.
I personally don't like the idea of a never ending list of parameters in
the constructor as it will never end.
Can i ask a question, why is there a need to change the permit joining from
default in the api? Can we not just leave it upto the application developer
to change this after startup?
Kind regards,
Danny Watson
On 24 Mar 2015 04:59, "Chris Hatton"<EMAIL_ADDRESS>wrote:

To enhancing the functionality of command-line parsing at launch, I would
recommend looking at Apache Commons CLI, which I've worked with in the past
and provides a great framework to avoid reinventing the wheel.
https://commons.apache.org/proper/commons-cli/
For the console itself; that's a conversation to be had... I would just
mention that I am currently refactoring code between
zigbee-console-common and zigbee-console-javase in preparation for
implementation of zigbee-console-android.
Summary of the changes is:

Console is constructed with generic InputStream / OutputStream.
Console runs on it's own Thread. Neither of these changes should
affect the current behaviour.

—
Reply to this email directly or view it on GitHub
https://github.com/tlaukkan/zigbee4java/issues/17#issuecomment-85338468.

@d1g2w3 With permit join on, it's possible for someone malicious to compromise the security.  Once joined they are on the network; they can sniff data and control devices.  The default should err on the side of more security.
This is why the window of time for joining should be limited, and even the allowed device address can be specified.
Ryan

Hi Ryan,
Hmm, ok, they can sniff data as long as they have the HA key and see the
transport key but understand regards to controlling devices.
Kind regards,
Danny Watson
On 24 Mar 2015 12:50, "presslab-us"<EMAIL_ADDRESS>wrote:

@d1g2w3 https://github.com/d1g2w3 With permit join on, it's possible
for someone malicious to compromise the security. Once joined they are on
the network; they can sniff data and control devices. The default should
err on the side of more security.
This is why the window of time for joining should be limited, and even the
allowed device address can be specified.
Ryan
—
Reply to this email directly or view it on GitHub
https://github.com/tlaukkan/zigbee4java/issues/17#issuecomment-85483302.

@d1g2w3 The network key is only exposed when a device joins.  Otherwise it is a secret that all devices use for the cypher.
Ryan

@presslab-us Accidently said transport key instead of network key.
If you have the transport key and you are sniffing the channel you can see
the network key being passed hence you can sniff the network
On 24 Mar 2015 13:05, "presslab-us"<EMAIL_ADDRESS>wrote:

@d1g2w3 https://github.com/d1g2w3 The network key is only exposed when
a device joins. Otherwise it is a secret that all devices use for the
cypher.
Ryan
—
Reply to this email directly or view it on GitHub
https://github.com/tlaukkan/zigbee4java/issues/17#issuecomment-85486390.

I've pushed my changes to master.  For the console app I've just made it have the previous functionality (permit join always enabled).  I know @chris-hatton is refactoring it right now so I didn't want to change too much.
I think the console app should eventually have some way to re-enable permit join from the command line (otherwise leaving it disabled), and a dedicated console command to enable/disable permit join and set the timeout duration.

Nice! :+1:


Added greeting trigger, PM trigger, link title lookup trigger

Additions:
-Greeting trigger AKA Doormat functionality: When a person enters a groupchat, he is greeted with "Hello Name".
-Link title lookup trigger: Posted links are responded to with the page title.
-PM trigger: Basically ChatReplyTrigger, but responds via private message to reduce spam.
Take my code with a grain of salt, I'm an amateur. Which is probably why I needed the PM Trigger and some additions in chatBot and baseTrigger. Maybe you can think of a better way to implement that.
That's also the reason I messed up the loop, apparently. (According to codacy) :I But you get the idea.
Thank you for your hard work guys, this bot is amazepants.
p.S.: Hope I "reopened" this correctly. Thank you for the quick response!

Once I fix the merge issues I'll merge this. It'll go into development, then when we know it doesn't break anything, we can merge to master.

Awesome, thanks!

So the reason there are merge conflicts (I think) is because you forked an old(er) version. What probably happened is that you forked it, made your changes, and opened this request. But by that time, we already updated the repo with more stuff.
My recommendations:

Move the files you changed to their own folder on your computer
Delete your fork
Refork it
Run `git pull git://github.com/efreak/node-steam-chat-bot.git' in command line (wherever you want your repo to be
Add your files back
`git push https://github.com/divinux/node-steam-chat-bot.git
Repoen the pull request

Sorry for the trouble.

Allright, I'll try after breakfast. I'll close this until then. No trouble at all.

Merge can be done manually (by editing the code at commit time), but it would be appreciated if you would deal with this by rebasing instead (I've never had to rebase, and I don't know anything about it).
You can avoid having to rebase/manual merge by keeping your local repo up to date with the main repo's code. I personally push almost all my changes immediately after I make them (so there shouldn't be any issues with me pushing earlier changes after you make your own changes), but I can't say for @dragonbanshee.
Also, squashing most of your changes into a single commit would be useful for viewing the commit history, even if I'm too lazy to do it myself (I don't expect you to do it, but for patches that don't get merged automatically it owuld be nice)


Use push_back() instead of emplace_back()

@baldersheim : please review
@havardpe : FYI

why is the stringref conversion operator on string better than the string constructor on stringref?

my bad, I thought you could create (construct) a stringref from a string.


Support for multiple master links ?

In the event where there are two different types of uplink to a drone ( eg 900mhz , 2.4ghz , 4G(lte), 433mhz, GPS uplink etc ) , any two of these, or alternately two of of the same link type ( eg dual 900Mhz telem links), etc, then there should be some sort of failover, or redundancy, or support for using both link/s concurrently.   Mavproxy handles these sorts of scenario, aparently, but is clearly not as fast as mavlink-router.

do you mean a failover link that's only used when the first fails?

There are a number of redundancy scenarios, such as a master/slave failover, which is the minimum viable solution,  but a more generic solution would be one that allowed comms packets to arrive through either link, and would be aware of the active/inactive state for each link, and would send outgoing packets based on some smarts, e.g. send out whichever link was most recently received on, or assign a priority to the more capable link if more than one are online at the same time.

Just to explain a little bit what mavlink-router does: mavlink-router works by routing packets using pairs of (sysid, compid) and adding them to an endpoint. By doing that we don't care about much of the content of the message, only a few fields from the header. That's partially the reason why it's faster than mavproxy, since we don't care about parsing the entire message (mavproxy has a reason to do it that way).  And endpoint has no knowledge what's a "master". GCS, flight stack and a sensor over mavlink are all viewed as an endpoint.
So... we know if a (sysid, compid) is in more than one endpoint. Right now we just send the message to both channels (if the originator of the message is not the same link). In a flight stack it's the flight stack responsibility to respond on the right channel (if the message requires a response) or filter the message out since it already arrived on the other channel. Broadcast messages screw all this up, so there's a little bit more going on for this type of messages.
Is that filtering on the flight stack end not working for you or what? I think it should just work... How do I reproduce what you're doing?

What you've described "no knowledge of what is a master" seems to disagree with the README.md which says "There's one 'master' endpoint that should be the flight stack..."  Id like some clarity there, perhasps if the readme is incorrect, it needs more details there?  Now in our particular issue at present is that we have two (usb/ftdi) com ports, and the data can arrive basically through either of them, so we need to connect to more than one com port, and it doesn't appear to me from the readme that you can do that..?

Yeah, what's on the README may not have the best wording. Have you tried it and it failed?

Have I tried what and failed?  warning, sarcasm ahead. Are you suggesting I should randomly try every possible incantation that involves describing two comports, on the off chance I manage to stumble over an undocumented feature that might just possibly exist, but there is no evidence for?

I understood it was a bug report about something that should work that is not working.

This is an issue, that I had, and that I'm discussing.    At this stage it might be any of these, I don't know :

that the author/s never expected multiple masters to work, and it's considered out of scope.
that the author/s have not actively considered this scenario to this point, but think adding support for it is a good idea.
that this authors intend that the feature should already work, but it's not documented.

I don't know which if those is true, but it might be that if it's the second point, then this issue is a feature-request, or it may be that in the case of the third point, then this is a  documenation issue, which might be considered a bug report by some ( a documentation bug ).

As I mentioned above, it's the third: it should work. It needs testing though. I think this exactly what Emlid's Edge is doing adding multiple endpoints to their config file. If you want to take a look yourself, examples/config.sample is a good place. I can take a look on it later, but no ETA

Starting the flight stack:
$ ./build/sitl/bin/arducopter -M x

Starting mavlink-router:
./mavlink-routerd -c /tmp/main.conf

Mavproxy (or any other GCS supporting dual link):
$ mavproxy.py  --master udp:<IP_ADDRESS>:14550 --master udp:<IP_ADDRESS>:14551

The configuration file:
[General]
TcpServerPort = 11000

[UDPEndpoint bla-link1]
Address = <IP_ADDRESS>
Mode = Normal

[UDPEndpoint bla-link2]
Address = <IP_ADDRESS>
Mode = Normal

[TCPEndpoint sitl]
Port = 5760
Address = <IP_ADDRESS>
Mode = Normal

For a stm32-based flight controller (rather than a linux/sitl) you will need to adapt the endpoints to use UARTEndpoint rather than TCPEndpoint

I have reviewed https://github.com/intel/mavlink-router/blob/master/examples/config.sample and it contains only one uart, two udp, and one tcp connection, so it's not quite doing what you suggested.

yeah... It's just one example, not doing exactly what you wanted.
Did you have a chance to test?

@lucasdemarchi
I have the same need that @davidbuzz was describing a year ago...
We have 900 and 4g coming from the drone simultaneously and need to receive both on the ground then choose which one to forward on to the GCS.
Did you determine if this is possible?

As I said above it should work. If it doesn't please post the logs.

The way it works is a little different from what you say. We send the message to both/multiple links and let the gcs/flightstack decide on what to drop based on msg id, sender, etc.

Thanks for getting back with me!
A lot of GCSs don't have the capability of choosing so we are wanting to
build a base station that does that internally as well as provid a wireless
internet connection to the tablet or computer running the GCS.
How hard do you think it would be to implement a feature that would choose
between a primary and secondary incoming Mavlink connection to pass on to
the GCS?
Thanks,
Shane
On Fri, Aug 23, 2019, 2:44 PM Lucas De Marchi<EMAIL_ADDRESS>wrote:

The way it works is a little different from what you say. We send the
message to both/multiple links and let the gcs/flightstack decide on what
to drop based on msg id, sender, etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/intel/mavlink-router/issues/139?email_source=notifications&email_token=AG24OWW5NN3HAWXH2TS3NBTQGAVY5A5CNFSM4FUCYQS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BAWEQ#issuecomment-524421906,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG24OWVDN2ZFJAD6HY2SHP3QGAVY5ANCNFSM4FUCYQSQ
.

All we want to do is use the LTE link if available otherwise use RFD 900 so
we're not worried about any logic beyond that.
Would that make it any easier?
-Shane
On Tue, Aug 27, 2019 at 11:22 AM Lucas De Marchi<EMAIL_ADDRESS>wrote:

The problem is how to define when or in what case to switch? It seems you
want to choose one link, the one with fewer packet lost, to forward to a
GCS. When implemented in a GCS it actually uses boths links. It may get one
packet from one link and one from another. Then use the seq numbers to
reconstruct the original ordering.
It's possible to do any of these in mavlink-router, but not very trivial.
PRs implementing it are welcome.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/intel/mavlink-router/issues/139?email_source=notifications&email_token=AG24OWXXI34IFXPCDS465XTQGVBELA5CNFSM4FUCYQS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5IDYVI#issuecomment-525352021,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG24OWSMY6LZBE5AJRPK3R3QGVBELANCNFSM4FUCYQSQ
.

So it seems more like supporting device hotplug than having any priority or adapt to multi-link. That sounds simpler at the surface but has some integration work to get it done. Right now we expect all endpoints to be created at startup rather than waiting for hotplug.
Supporting hotplug would be great as it means we don't have to order the startup of mavlink-router after devices are available in the system, making it better on supporting e.g. USB device that tend to show up later in the boot.

The "priority" in the config would just avoid sending multiple heart beats
or redundant messages to the flight controller from the GCS even when you
have two or more active telemetry connections.  Basically the GCS endpoint
would only ever experience one Mavlink connection at a time as long as all
the other endpoints had a "priority" in the config file.
I wasn't aware whether you could "hot swap" or not but it does seem like a
feature that would make the overall system more robust.
-Shane
On Mon, Sep 2, 2019, 3:42 PM Lucas De Marchi<EMAIL_ADDRESS>wrote:

So it seems more like supporting device hotplug than having any priority
or adapt to multi-link. That sounds simpler at the surface but has some
integration work to get it done. Right now we expect all endpoints to be
created at startup rather than waiting for hotplug.
Supporting hotplug would be great as it means we don't have to order the
startup of mavlink-router after devices are available in the system, making
it better on supporting e.g. USB device that tend to show up later in the
boot.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/intel/mavlink-router/issues/139?email_source=notifications&email_token=AG24OWVIVEMM7FNIUY5FQZTQHVUDDA5CNFSM4FUCYQS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WOXMQ#issuecomment-527231922,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG24OWWV3LHX5UAF7A2YJZDQHVUDDANCNFSM4FUCYQSQ
.

I just realized you probably haven't gotten the direct email I sent yet.
I gave a detailed explanation of how this might be implemented and sent it
from my hybridproject email.
Hopefully that will make things more clear.
-Shane
On Mon, Sep 2, 2019, 3:50 PM Shane Roberts<EMAIL_ADDRESS>wrote:

The "priority" in the config would just avoid sending multiple heart beats
or redundant messages to the flight controller from the GCS even when you
have two or more active telemetry connections.  Basically the GCS endpoint
would only ever experience one Mavlink connection at a time as long as all
the other endpoints had a "priority" in the config file.
I wasn't aware whether you could "hot swap" or not but it does seem like a
feature that would make the overall system more robust.
-Shane
On Mon, Sep 2, 2019, 3:42 PM Lucas De Marchi<EMAIL_ADDRESS>wrote:

So it seems more like supporting device hotplug than having any priority
or adapt to multi-link. That sounds simpler at the surface but has some
integration work to get it done. Right now we expect all endpoints to be
created at startup rather than waiting for hotplug.
Supporting hotplug would be great as it means we don't have to order the
startup of mavlink-router after devices are available in the system, making
it better on supporting e.g. USB device that tend to show up later in the
boot.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/intel/mavlink-router/issues/139?email_source=notifications&email_token=AG24OWVIVEMM7FNIUY5FQZTQHVUDDA5CNFSM4FUCYQS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WOXMQ#issuecomment-527231922,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG24OWWV3LHX5UAF7A2YJZDQHVUDDANCNFSM4FUCYQSQ
.

Just as a follow up on this topic. Lucas is right, that at least QGroundControl (the only GCS I know) is fully capable of having multiple telemetry links and doing some failover between those.
A quite generic solution to your problem might be to have message de-duplication and endpoint groups in mavlink-router as proposed in #240. This would mean, that you can have multiple wireless links, which receive data from the drone, but only one instance of each packet will be forwarded to the GCS endpoint. In the other direction, all messages from the GCS to the drone will be sent via both wireless links.
De-duplication is not easy, but a time based failover can also be quite error-prone, if badly configured. But we need the features mentioned for a mesh network solution, so I would rather implement that. Do you think, this can solve your problem? Because then I would like to close this in favor of the other feature request.

Anything is better than nothing :)
On Tue, Feb 2, 2021 at 10:27 AM Jannik Beyerstedt<EMAIL_ADDRESS>wrote:

Just as a follow up on this topic. Lucas is right, that at least
QGroundControl (the only GCS I know) is fully capable of having multiple
telemetry links and doing some failover between those.
A quite generic solution to your problem might be to have message
de-duplication and endpoint groups in mavlink-router as proposed in #240
https://github.com/mavlink-router/mavlink-router/issues/240. This would
mean, that you can have multiple wireless links, which receive data from
the drone, but only one instance of each packet will be forwarded to the
GCS endpoint. In the other direction, all messages from the GCS to the
drone will be sent via both wireless links.
De-duplication is not easy, but a time based failover can also be quite
error-prone, if badly configured. But we need the features mentioned for a
mesh network solution, so I would rather implement that. Do you think, this
can solve your problem? Because then I would like to close this in favor of
the other feature request.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mavlink-router/mavlink-router/issues/139#issuecomment-771714250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG24OWX5HUCYC5JSISO7NGTS5AKVDANCNFSM4FUCYQSQ
.

I guess in all cases that's not true...
On Tue, Feb 2, 2021 at 11:49 AM Shane Roberts<EMAIL_ADDRESS>wrote:

Anything is better than nothing :)
On Tue, Feb 2, 2021 at 10:27 AM Jannik Beyerstedt <
<EMAIL_ADDRESS>wrote:

Just as a follow up on this topic. Lucas is right, that at least
QGroundControl (the only GCS I know) is fully capable of having multiple
telemetry links and doing some failover between those.
A quite generic solution to your problem might be to have message
de-duplication and endpoint groups in mavlink-router as proposed in #240
https://github.com/mavlink-router/mavlink-router/issues/240. This
would mean, that you can have multiple wireless links, which receive data
from the drone, but only one instance of each packet will be forwarded to
the GCS endpoint. In the other direction, all messages from the GCS to the
drone will be sent via both wireless links.
De-duplication is not easy, but a time based failover can also be quite
error-prone, if badly configured. But we need the features mentioned for a
mesh network solution, so I would rather implement that. Do you think, this
can solve your problem? Because then I would like to close this in favor of
the other feature request.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mavlink-router/mavlink-router/issues/139#issuecomment-771714250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG24OWX5HUCYC5JSISO7NGTS5AKVDANCNFSM4FUCYQSQ
.

I would like to close this issue as:

Two (or even more) parallel links work when endpoint grouping is enabled (otherwise the "ground" side would reflect messages from one link back through the other one). And with de-duplication enabled as well, you would only see each message once.
This has the lowest possible failover latency as each message is transmitted through both links, but your flight stack might respond to commands twice, if no mavlink-router is used on the UAV side to de-duplicate.
I don't think, that a true master-slave failover (only using one at a time) will be in scope of mavlink-router in the near future.

There are no questions in all of your four messages from 2021-02-02, just comments. If the proposal to have hot-swappable endpoints is still a thing, it should rather have its own issue/ feature request as this thread is already quite long. (Auterion started to implement some control interface to add new endpoints during runtime in their fork.)


allow gtdbtk to run on pqhm1

Where is gtdbtk_database defined?

On 3 destinations and one tool. This is how scheduling tags work. Because the tag is on these 3 destinations, a tool that requires it can only go to these 3 destinations.


Fix: syntax highlighting and formatting update

Adds proper JSON syntax highlighting and updates formatting form 4 width tabs to 2 spaces.
fixes #22

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

GitHub release
1.0.0

Your semantic-release bot :package::rocket:


UnicodeEncodeError: 'charmap' codec can't encode characters in position 74-78: character maps to

using laion2b-en-aesthetics65.parquet entry #3
"San Pedro: One Of Mother Nature's Most Powerful Psychedelics | Ayahuasca  アヤワスカ | Scoop.it"
Error:
Traceback (most recent call last):
  File "%USERPROFILE%\miniconda3\envs\controlnet\Lib\site-packages\img2dataset\downloader.py", line 328, in download_shard
    sample_writer.write(
  File "%USERPROFILE%\miniconda3\envs\controlnet\Lib\site-packages\img2dataset\writer.py", line 280, in write
    f.write(str(caption))
  File "%USERPROFILE%\miniconda3\envs\controlnet\Lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeEncodeError: 'charmap' codec can't encode characters in position 74-78: character maps to <undefined>
Sample 3 failed to download: 'charmap' codec can't encode characters in position 74-78: character maps to <undefined>

Result:
jpg was downloaded
empty: 000000003.txt
missing: 000000003.json
Using Windows 10 with Miniconda
similar issue: https://github.com/rom1504/img2dataset/issues/219

In my case it worked after specifying the encoding in writer.py:
def write(self, img_str, key, caption, meta):
  ...
  with self.fs.open(caption_filename, "w", encoding="utf-8") as f:
  ...
  with self.fs.open(meta_filename, "w", encoding="utf-8") as f:
  ...


Unplayable, Literally

Upon launching the game with the mod enabled, the player will fall as normal, but everything is blacked out. Upon hitting the ground will not move until the menu is opened and closed, and the UI will be bugged with enlarged overlapping numbers under the geo count and the health bar full of masks. Everything will still be blacked out until the player either moves to the secret corner to the left, with the geo rock, or to the right at the first blockage. Both the geo rock and path blockade will be indestructible, and cutting grass will remove it, but leave the slash marks suspended on the screen indefinitely. Also, when near the geo rock to the left, Mr. Mushroom's muttering can be heard, but he is not present. There are more discrepancies that are present visually in the images provided.

So sorry for the late response, I must've missed the notification of your response. The only other mods enabled are Custom Knight and it's requirements, listed here:

And the logs.
ModLog.txt


[WW-5136] Makes class attribute deprecated - cherry-pick

Refs WW-5136

Coverage remained the same at 49.914% when pulling da21273d427f318ed5f052c9471f404a240ad3d0 on WW-5136-class-deprecated into ae85f5195ffd82a29243e63f0a459fb5eceb35f9 on master.

thanks! LGTM :+1:


fix(ssl-handshake): update list of supported cipher suites

Update the list of supported cipher suites to use with openssl to
include those supported by lnd, which are defined as:
tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
See https://github.com/lightningnetwork/lnd/blob/master/lnd.go#L80-L85
Fix #324

Thanks, looks good. Could you add a comment something like this one, for reference:
// Default is ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
// https://github.com/grpc/grpc/blob/master/doc/environment_variables.md
// Current LND cipher suites here:
// https://github.com/lightningnetwork/lnd/blob/master/lnd.go#L80

And I'm unsure whether we should include the default suites, given they aren't accepted by LND. I guess they're harmless given they'll be excluded during negotiation. Thoughts? /cc @jackmallers

@Empact  I have updated the code to include the comment. Regarding wether the defaults should be included or not - I did test without and it works ok with the most recent version of lnd. The reason I opted to include them however was that I figured that they may be needed in order to continue to support older version of lnd.

Fair enough - another question came to mind: should we sort the suites in an order to indicate our preference for stronger suites? Until recently LND led with the 384 bit ciphers:
https://github.com/lightningnetwork/lnd/commit/f7eeea71e206a514ee649060e903f72c9d4a8c46

FWIW, I don't see why we would maintain compatibility with < LND 0.4.0.

Ok, so as we don't want to support older versions of lnd I have removed the default suites -which I think makes sense, although could make the upgrade process more involved for some users.
With regards to the ordering, I'm not sure TBH. The way it is now matches what they are doing in lnd.

Fair enough on ordering, I don't have a strong sense of the relative strength so leaving as is is fine.
That brings to mind that we should defer to the existing environment variable, if set, so that users can override / set their own ordering if desired.

Good call. Have updated to honour existing values of the env var.

@mrfelton nice!
I agree that I don't see the need to support LND < 0.4. We certainly won't be releasing anything with LND < 0.4, I think having 0.4+ support only makes sense.
Looks good to me though, just wondering if ECDHE-ECDSA-CHACHA20-POLY1305 is needed? I can test locally in a bit. Can anyone confirm it's necessary?

yeah looks like lightning-app doesn't support ECDHE-ECDSA-CHACHA20-POLY1305 as well: https://github.com/lightninglabs/lightning-app/blob/v2/public/grpc-client.js#L9

@JimmyMow any idea why ECDHE-ECDSA-CHACHA20-POLY1305 is included in lnd?

Roasbeef's answer from the LND Slack:
¯\_(ツ)_/¯

doesn't really matter
just needs to have a non empty intersection

https://lightningcommunity.slack.com/archives/C6BDA6DGE/p1521492965000083

Ok, then IMO we should keep our list of supported suites inline with those supported by lnd.

SSL Labs likes them in this order:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-CBC-SHA256
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

When pretty much agrees with Mozilla's list from 2016::

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

Based on the above, how about ordering them like so:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-CBC-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305

Nice find @Empact - have updated the PR to reflect.


ws2812 num is always 10, no matter what num i defined in the firmware

I use cc2530 and 5 led ws2812 led-strip, the question is that no matter what led count i defined , the zigbee2mqtt always recognize 10, and the strip is light 10 leds.
Can you help me solve this.

Are you using the premium version?


The music list not showing

First Problem : it just show the control (backward,forward,pause,duration and title)
There no music list like in your picture (awesome music 1, awesome music 2) based in my code, this should add "Another One Bities Of Dust","Be Starters","Gee,"Crazy Frogs" etc to the music list and show it right?
Second Problem: the music is played properly, but when i keep forward the audio, it just play till "Feel This Moment" 6 more audio are not added to the playlist, but in code , i added it, why?
My apk : https://ufile.io/0ycnh sorry if i upload here
code :
player = (JcPlayerView)findViewById(R.id.musicplayer);
ArrayList musicList = new ArrayList();
musicList.add(JcAudio.createFromURL("Another One Bities Of Dust","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1zqcwflJjFT.mp3"));
musicList.add(JcAudio.createFromURL("Be Starters","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1KMVtNBwtGW.mp3"));
musicList.add(JcAudio.createFromURL("Crazy Frogs","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1IN5m15oEcu.mp3"));
musicList.add(JcAudio.createFromURL("Dance Of The Knights","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1UtUmVB1Tl2.mp3"));
musicList.add(JcAudio.createFromURL("Dumags","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1CcypsYOiS7.mp3"));
musicList.add(JcAudio.createFromURL("Feel This Moment","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1AfxoRr8dk3.mp3"));
musicList.add(JcAudio.createFromURL("Flight Of The Bumblebee","https://s1.vocaroo.com/media/download_temp/Vocaroo_s15cjibddJl2.mp3"));
musicList.add(JcAudio.createFromURL("Game of Thrones","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1srPoxtfSeA.mp3"));
musicList.add(JcAudio.createFromURL("Gee","https://s1.vocaroo.com/media/download_temp/Vocaroo_s14Lx19MsFxa.mp3"));
musicList.add(JcAudio.createFromURL("Growtopia Menu","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1RU8xv4uosK.mp3"));
musicList.add(JcAudio.createFromURL("Here With You","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1R52lycmdAp.mp3"));
musicList.add(JcAudio.createFromURL("Hey There Darlin","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1qZzHc11Ybl.mp3"));
musicList.add(JcAudio.createFromURL("I Need Your Love","https://s1.vocaroo.com/media/download_temp/Vocaroo_s1AJ93YXmOnN.mp3"));
player.initWithTitlePlaylist(musicList,"Growtopia Music");

Is that solved?

solve


Split modules to facilitate custom builds

mixpanel-browser is the largest dependency we have in our web application. We aren't using all of the functionality, notably notifications. Although that feature can be turned off, the code is still included in the bundle. There may be other users that have custom features sets, like those not using the people functionality.
I've seen discussions about potentially making this library more modular. This PR is to help facilitate this through a series of refactors. These are simple mechanical splitting out of mixpanel-core.js into smaller modules, so I've left the commits unsquashed so it's easier to see the refactors one-at-a-time.
The last commit introduces a custom bundle that excludes notifications, saving 44 KB. Our application bundle can use a Webpack alias to swap in that custom bundle.

Awesome, thanks so much for doing this! It looks very close to the direction we were planning to take the library already. I can't give a timeline ATM for when we can get to it, but I definitely want to get this patch merged.

@tdumitrescu: any update? I've just rebased these changes on master, which required porting changes over to the split files. The longer this sits dormant, the harder it is to keep in sync, so it might be best to merge ASAP so that future changes can go to the split-out modules.

Right now we have a couple changesets for new features in development/testing, which have pretty big conflicts with this branch. Once those go out in the coming weeks, I'll make this patch top priority for this lib. Thanks for your patience!

Sorry this never got pushed through. We've now deleted both the notifications module and the autotrack module entirely, so there aren't really any optional modules left in the SDK to worry about.


Failed to download

Steps to reproduce
download manga
Expected behavior
Works as intended.
Actual behavior

Where all directory are empty.
Crash logs
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: Failed to createFile
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: java.lang.IllegalStateException: Failed to mkdir /storage/emulated/0/Download/mihon/downloads (5)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.os.Parcel.createException(Parcel.java:2086)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.os.Parcel.readException(Parcel.java:2046)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:188)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:140)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.content.ContentProviderProxy.call(ContentProviderNative.java:658)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.content.ContentResolver.call(ContentResolver.java:2080)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at android.provider.DocumentsContract.createDocument(DocumentsContract.java:1327)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at coil.util.-Collections.createFile(Unknown Source:4)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at com.hippo.unifile.TreeDocumentFile.createDirectory(Unknown Source:28)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at tachiyomi.domain.storage.service.StorageManager.getDownloadsDirectory(Unknown Source:6)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at eu.kanade.tachiyomi.data.download.DownloadProvider.findSourceDir(Unknown Source:7)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at eu.kanade.tachiyomi.source.AndroidSourceManager$registerStubSource$1.invokeSuspend(Unknown Source:107)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(Unknown Source:8)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlinx.coroutines.DispatchedTask.run(Unknown Source:106)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(Unknown Source:3)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlinx.coroutines.scheduling.TaskImpl.run(Unknown Source:2)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(Unknown Source:0)
12-12 11:41:23.492 21388 21453 E DocumentsContractApi21: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(Unknown Source:57)

Mihon version
0.17.1
Android version
Android 10
Device
SCM-W09
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have gone through the FAQ and troubleshooting guide.
[X] I have updated the app to version 0.17.1.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Come to the Mihon Discord support channel for help, since you decided to put Mihon's storage location into your device's System folders.


NioServer: retain links by address string to minimize resource leak

Every time a client connects, the NioServer will retain the link against
the InetSocketAddress object. If the same agent/client reconnects, it
will grow older links over time and in case of denial of service attack
or a client/script/monitoring-service reconnecting aggressively against
port 8250 will cause the _links weak hashmap to grow over time and
very quickly.
The fix will ensure that only one Link gets weakly retained for an
incoming client based on its address string.
This is what is seen when only one kvm/agent connects to the management server:

When I restart the cloudstack-agent couple of times, I see the _links grow:

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-189

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-230)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 26166 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3525-t230-kvm-centos7.zip
Smoke tests completed. 77 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Caveat: for multiple-mgmt servers behind an LB, it will end up creating only one weak entry in the weak hash map. I'm not sure if it could cause any issues.

@rhtyd sounds intresting. LGTM. I think when anybody use a lb maybe the transparent mode can help?

Caveat: for multiple-mgmt servers behind an LB, it will end up creating only one weak entry in the weak hash map. I'm not sure if it could cause any issues.

Do you mean that the two servers would share that hashmap, @rhtyd ? that seem strange to me. And if you mean on the agent side, that would only be a problem if the MSses are natted behind the same address, would it?

In case of mgmt servers behind an LB, this will likely create a single entry in the weak hashmap. I'll revisit this towards 4.14 or 4.13.1; it's also possible to add a garbage collector to remove old/unreachable links from the heap.

Sorry, reverting this PR because I remembered why it was put On-Hold, as the change would cause a single Link to be added to a Map when the mgmt server is behind a LB. So the changes are not optimal for all cases.


Adding ability to authenticate and run epicli from a pod.

@sk4zuzu what would be a use case for that issue?

@mkyc so the previous idea for autoscaling was to reuse existing k8s automation we have already, but without any kind of cloud provider software deployed. Also we were supposed to reuse existing epicli/ansible code. We would introduce a long running process inside k8s that would control the size of the cluster by running epicli commands. I don't think that this is needed anymore.

Yeah, I agree. Closing it for now.


Uncaught ReferenceError: process is not defined

I'm using

"vite": "^3.1.8",
"vite-plugin-environment": "^1.1.3"

with React and switched from "create-react-app".
In my config I added EnvironmentPlugin("all", { prefix: "REACT_APP_" }),.
If I add an REACT_APP_something to my .env file everything works, but if my .env file is empty, I get the Uncaught ReferenceError: process is not defined.
In my code I have a check like if (process.env.REACT_APP_PREVIEW === "true") but the env variable is optional.
I expected, that even with no prefixed variable the process variable is available.
As workaround I added EnvironmentPlugin("all", { prefix: "NODE_" }), because this is always defined, so process is defined too.

@[pitgrap Replacement is performed using define:

Because it's implemented as straightforward text replacements without any syntax analysis, we recommend using define for CONSTANTS only.

That means that process.env won't be injected as a constant with values. Instead, process.env.MY_VAR will be replaced statically with the provided value.
If you want to fail if a particular variable is missing, or provide a default so that you can omit it, use the object format this plugin allows (instead of all).


Fixed handling of IN (subquery) expressions.

Turns out after all, the problem was simpler than we initially thought. Closes #391.

Damn, merged into master instead of first merging into release/elm. Will make a new PR for Elm.


Support for xml/html code highlighting

The Angular template parser seems to try to parse the written code e.g.
<test>

and give an error message that the markdown-to-html tag has been closed already.
And with the following code angular states that "test" is not a known element and suggests to insert the NO_ERRORS_SCHEMA into the module.
<test></test>

Comment tags such as <!-- test --> seem to be ignored as well.

Workaround:
Include the xml/html code via the [source] tag.

Hi @informaterian,
Markdown can contains HTML and you are right that Angular will definitely try to parse the template. I haven't found any built-in solution yet for this not to happen (any suggestion would be welcome).
Like you said, the best workaround is to use the [src] input binding so this way the template won't be parse by Angular template parser
<markdown-to-html [src]="'path/to/file.html'"></markdown-to-html>

I am closing this issue as there is a workaround.


Add necessary permissions for packaged applications (fixes #365)

I didn't do extensive testing, and not sure about any possible regressions caused by switching from Option 2 to Option 1, but from a quick test, adding explicit permissions for "All Application Packages", "All Restricted Application Packages" makes Debugview++ work with UWP apps.
Fixes #365.

I looked at how Sysinternals DebugView does that. It does the following:
ConvertStringSecurityDescriptorToSecurityDescriptorA(
  "D:(A;;GRGWGX;;;WD)(A;;GA;;;SY)(A;;GA;;;BA)(A;;GRGWGX;;;AN)(A;;GRGWGX;;;RC)(A;;GRGWGX;;;S-1-15-2-1)S:(ML;;NW;;;LW)",
  SDDL_REVISION_1,
  ...
)

Since DebugView is the de facto standard tool for debug logging, you might want to align DebugView++ to use the exact same security descriptor.

Thank you!! That is very interesting, is there any more you can tell me about what this does, and what it is doing? I am not familiar with this at all.

Here are a couple of references:

https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/
https://devblogs.microsoft.com/oldnewthing/20220502-00/?p=106550

A process within an AppContainer runs with an Integrity Level of low, which effectively means it has no access to almost everything, as the default integrity level of objects (such as files) is Medium.

My change, and DebugView's method (S-1-15-2-1 representing "All Application Packages") set permissions such that the relevant objects are accessible to AppContainer processes.


Make the error returned by the BytesDecode/BytesEncode trait customizable

This PR is an attempt at getting rid of the BoxedError type we currently use everywhere.
That allows us to use a « real » type when an error arises in the BytesEncode or BytesDecode traits.
The new traits
/// A trait that represents an encoding structure.
pub trait BytesEncode<'a> {
    type EItem: ?Sized + 'a;
    type Err;

    fn bytes_encode(item: &'a Self::EItem) -> Result<Cow<'a, [u8]>, Self::Err>;
}

/// A trait that represents a decoding structure.
pub trait BytesDecode<'a> {
    type DItem: 'a;
    type Err;

    fn bytes_decode(bytes: &'a [u8]) -> Result<Self::DItem, Self::Err>;
}

I called the type Err to do something similar to the FromStr trait from the stdlib.
The new Error enum
/// An error that encapsulates all possible errors in this crate.
#[derive(Debug)]
pub enum Error<E, D> {
    Io(io::Error),
    Mdb(MdbError),
    Encoding(E),
    Decoding(D),
    InvalidDatabaseTyping,
    DatabaseClosing,
    BadOpenOptions {
        /// The options that were used to originaly open this env.
        options: EnvOpenOptions,
        /// The env opened with the original options.
        env: Env,
    },
}

I had to make the Error enum generic over the decoding and encoding error.
For most functions, that do not add any complexity because we use our Result type;
/// Either a success or an [`Error`].
pub type Result<T, E = Infallible, D = Infallible> = result::Result<T, Error<E, D>>;

That set E and D to Infallible by default.
My issue
For some methods like the following one, we can return an error while encoding the key OR the value + while decoding the key OR the value:
    pub fn get_lower_than<'a, 'txn, KC, DC>(
        &self,
        txn: &'txn RoTxn,
        key: &'a KC::EItem,
    ) -> Result<Option<(KC::DItem, DC::DItem)>, KC::Err, DC::Err>
    where
        KC: BytesEncode<'a> + BytesDecode<'txn>,
        DC: BytesDecode<'txn>,
    {
        assert_eq_env_db_txn!(self, txn);

        let mut cursor = RoCursor::new(txn, self.dbi)?;
        let key_bytes: Cow<[u8]> = KC::bytes_encode(&key).map_err(Error::Encoding)?;
        cursor.move_on_key_greater_than_or_equal_to(&key_bytes)?;

        match cursor.move_on_prev() {
            Ok(Some((key, data))) => match (KC::bytes_decode(key), DC::bytes_decode(data)) {
                (Ok(key), Ok(data)) => Ok(Some((key, data))),
                (Err(e), _) | (_, Err(e)) => Err(Error::Decoding(e)),
            },
            Ok(None) => Ok(None),
            Err(e) => Err(e),
        }
    }

One solution could be adding two other variants to the Error enum.

I tried to introduce more variants to the Error enum to represent the key encoding/decoding and data encoding/decoding possible errors.
Unfortunately, it's not that easy to convert the generic Error types between them. Some functions return a Result<Infallible, Infallible, Infallible, Infallible> and it is not easy to convert that into a Result<KC, KD, DC, DD>.