[FLINK-13632] Port EnumSerializer upgrade test to TypeSerializerUpgradeTestBase

What is the purpose of the change
Port EnumSerializer upgrade test to TypeSerializerUpgradeTestBase
Verifying this change
This change is already covered by existing tests, such as (please describe tests).
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: ( no)

Documentation

Does this pull request introduce a new feature? ( no)
If yes, how is the feature documented? (not applicable)

verified with the data generated on release-1.9


apktool.bat b xx.apk failed

Information

Apktool Version (apktool -version) -2.4.0
Operating System (Mac, Linux, Windows) -Windows
APK From? (Playstore, ROM, Other) -Playstore

Stacktrace/Logcat

Include stacktrace here

### Steps to Reproduce
1. `apktool `

### Frameworks
If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files
(`.apks` that live in `/system/framework` or `/system/priv-app`)

### APK
If this APK can be freely shared, please upload/attach a link to it.

### Questions to ask before submission
1. Have you tried `apktool d`, `apktool b` without changing anything?
2. If you are trying to install a modified apk, did you resign it?
3. Are you using the latest apktool version?

In the future, please don't use images. The stacktrace cannot be searched and its difficult to read images vs text. This is a duplicate of #1427


Is this repository still supported?

There are multiple issues related to getting this package working with NextJs 13+ App Router.
NextJS 13+ has been released for a very long time
Its the most popular frontend framework
10s of pages in your docs link to it.
It simply does not work

We wasted a lot of time trying to get this working. Please at least state this does not support NextJS 13+ for browser

Please refer to newrelic-node-examples/nextjs-app-router repository for App Based router sample integration

moved to nextjs/nextjs-app-router


Serve front-end in PrivateServer mode

This adds a new option --frontend-dist which accepts a path to serve as part of the PrivateServer mode. All API routes have been moved to /api, and the front-end baseURL has been adjusted accordingly.

See #119 for packaging


export new file assessmentForm

I forgot to export this file in the previous PR.

Related Issues

https://github.com/transcend-io/privacy-types/commit/11a28af6ac54608b725ec0097a319278f97e2464

Looks fine, but what "last PR"? Did I miss a PR for assessment forms?

I linked it in the PR description. You haven't missed anything. I just shipped the statuses 😄


chore: import fixes to fix e2e tests

Both the server and client e2e tests run fine in the CI, but in some local scenarios the "deep imports" we used were causing issues with module resolution.
I've updated the e2e test to always import from the "top level" instead of the /src sub-directory in the test suite.

@jamescarr I'm not 100% sure this will fix your issue locally (I wasn't able to reproduce it) but it might.


How generate pages in flat structure?

I have few pages like:
pages
  |- index.vue
  |- page1.vue
  |- page2.vue

and after generate I'll get
dist
  |- index.html
  |- page1
  |   |- index.html
  |- page2
      |- index.html

but I need to
dist
  |- index.html
  |- page1.html
  |- page2.html

Extended routes can solve your problem
https://nuxtjs.org/api/configuration-router#extendroutes

What if I want to have page like images.html and also have folder images in static folder?

Hi, this option is not available.
A PR is more than welcome to add this option to nuxt generate.
I'm closing this issue because it's not really one, but feel free to comment it if you have more ideas about this feature.

@rzcoder It's now possible using the subFoldersproperty: https://nuxtjs.org/api/configuration-generate#subfolders


php-debug: Rebuild for gd update

php-debug: Rebuild for gd update

:beers: @BrewTestBot has triggered a merge.


Inventory Grid in While in Bank/Seed Vault

With the New Inventory grid option it'd be nice to see it implemented while you're in your bank/seed vault aswell

I was thinking of taking a look into this but how would you like the plugin to be configured?
3 separate plugins for each grid or one larger encompassing plugin?

@EVOuser94 are you looking to have the grid system in your bank or do you want the inventory grid to appear while in the bank?

I want the inventory grid to appear while in bank, not the bank itself, tho that also sounds pretty useful to me too.

Not sure if the seed vault feature is doable. Items in the invy are not draggable.


Which version I must install?

Hi to all and a very big tank to Syssi and all other for tis great work!
I have this inverter

I use a Wemos D1 Mini, not original wifi stick, but exactly wich version I must install?
I've connected wemos to inverter USB port and installed esp8266-display-wifi-version-limiter-example.yaml
All works but not limiter connected directly to inverter
I have also connected inverter rs485 to wemos throught adapter (rs485 to serial ttl) but it does not work :/
Can anyone help to configure correctly wemos?
Thank you very much

You are on the right track. Could you make a photo of your wiring and provide your YAML configuration? I would like to make sure the RS485 converter is connected to the configured GPIOs etc.

Tank you syssi!

Sorry for "fast draw"
The schema is:
inverter USB port to wemos GPIO4 and 5 ...and ground
inverter RS485 to converter
tis is the code:
substitutions:
  name: "gestione-inverter-notte"
  device_description: "Monitor and control the Soyosource GTN (WiFi version) via the display port and control the power output on demand via RS485"
  external_components_source: github://syssi/esphome-soyosource-gtn-virtual-meter@main
  # The display port should be connected to these GPIOs using a USB connector (VCC, RX, TX, GND)
  # A optocoupler / optical isolator (f.e. ADUM1201) between the display port and the ESP is recommended if the ESP isn't powered by the display port!
  tx_pin_ttl_wifi: GPIO4
  rx_pin_ttl_wifi: GPIO5
  tx_pin_rs485: GPIO12
  rx_pin_rs485: GPIO14

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "syssi.esphome-soyosource-gtn-virtual-meter"
    version: 2.1.0

esp8266:
  board: d1_mini

external_components:
  - source: ${external_components_source}
    refresh: 0s

logger:
  level: INFO

# If you use Home Assistant please remove this `mqtt` section and uncomment the `api` component!
# The native API has many advantages over MQTT: https://esphome.io/components/api.html#advantages-over-mqtt
mqtt:
  broker: xxxx
  username: xxxxx
  password: xxxxx
  #id: mqtt_client

api:
  encryption:
    key: "xxxx"

ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "xxxxx"
    password: "xxxxx"

uart:
  - id: uart_0
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi}
    rx_pin: ${rx_pin_ttl_wifi}

  - id: uart_1
    baud_rate: 4800
    tx_pin: ${tx_pin_rs485}
    rx_pin: ${rx_pin_rs485}

soyosource_modbus:
  - id: modbus0
    uart_id: uart_1
    # flow_control_pin: GPIO12

    # Optional settings
    #
    # The name is used as prefix for some log messages and should
    # help to distinguish between different instances/devices
    name: inverter_notte

soyosource_virtual_meter:
  - id: virtualmeter0
    soyosource_modbus_id: modbus0

    # The state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter0

    # Optional settings
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # Split/distribute the power demand if you have multiple inverters attached to the same RS485 bus
    power_demand_divider: 1
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    operation_status_id: operation_status_id0

    # The update interval is important and defaults to 3 seconds. If the demand is sent too frequently
    # or rarely the interverter stops. TODO: Identify and validate the lower and upper update limit
    update_interval: 3s

soyosource_display:
  - id: display0
    uart_id: uart_0
    protocol_version: SOYOSOURCE_WIFI_VERSION
    update_interval: 5s

binary_sensor:
  - platform: soyosource_display
    fan_running:
      name: "${name} fan running"
    limiter_connected:
      name: "${name} limiter connected"

button:
  - platform: soyosource_display
    restart:
      name: "${name} restart"

number:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    buffer:
      name: "${name} buffer"
      initial_value: 10
      restore_value: true
    manual_power_demand:
      name: "${name} manual power demand"
      max_value: 900
    max_power_demand:
      name: "${name} max power demand"
      initial_value: 200
      max_value: 900
      restore_value: true
    power_demand_divider:
      name: "${name} power demand divider"
      initial_value: 1
      restore_value: true

  - platform: soyosource_display
    start_voltage:
      name: "${name} start voltage"
    shutdown_voltage:
      name: "${name} shutdown voltage"
    # Maximum output power in limiter mode / Output power in constant power mode
    output_power_limit:
      name: "${name} output power limit"
    start_delay:
      name: "${name} start delay"

select:
  - platform: soyosource_display
    operation_mode:
      name: "${name} operation mode"
      optionsmap:
        1: "PV"
        2: "Battery Constant Power"
        17: "PV Limit"
        18: "Battery Limit"

sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    power_demand:
      name: "${name} power demand"

  - platform: soyosource_display
    error_bitmask:
      name: "${name} error bitmask"
    operation_mode_id:
      name: "${name} operation mode id"
    operation_status_id:
      name: "${name} operation status id"
      id: operation_status_id0
    battery_voltage:
      name: "${name} battery voltage"
    battery_current:
      name: "${name} battery current"
    battery_power:
      name: "${name} battery power"
    ac_voltage:
      name: "${name} ac voltage"
    ac_frequency:
      name: "${name} ac frequency"
    temperature:
      name: "${name} temperature"
    output_power:
      name: "${name} output power"

  # mqtt subscribe example
#  - id: powermeter0
#    internal: true
#    platform: mqtt_subscribe
#    name: "${name} instantaneous power consumption"
#    topic: "smartmeter/sensor/smartmeter/obis/1-0:16.7.0/255/value"
#    accuracy_decimals: 2
#    unit_of_measurement: W
#    device_class: power
#    filters:
#      - throttle_average: 15s

#   # import smartmeter reading from homeassistant
#   # requires the "api" component see above
  - platform: homeassistant
    id: powermeter0
    name: "${name} smartmeter instantaneous power"
    entity_id: sensor.sonoff_1001553f47_power
    filters:
      - throttle_average: 15s

switch:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    manual_mode:
      name: "${name} manual mode"
      restore_mode: RESTORE_DEFAULT_ON
    emergency_power_off:
      name: "${name} emergency power off"
      restore_mode: RESTORE_DEFAULT_OFF

text_sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    operation_mode:
      name: "${name} limiter operation mode"

  - platform: soyosource_display
    errors:
      name: "${name} errors"
    operation_mode:
      name: "${name} operation mode"
    operation_status:
      name: "${name} operation status"

Battery costant power works well but with limiter I don't understand which are the right parameters.
In this case I use this istant meter (not reverse energy) ...but I bought a Tuya dual meter for this scope.

I would like to use original power meter because I want use 3 inverters on parallel RS485 wires
I don't understand the logical under settings.
The original power meter is connected to the first, second and third inverter through RS485 ...is ok
But how D1 mini is connected? Only through USB? In this case which versione I could use?
Another problem is: where must be place the CT and the inverter over the "house wires"? The istructions tell one thing, but other people tell another one.
In my case the first counter from grid is on long distance from inverters and I will use 2 RS485 to wifi converters (Elfin EW11A) and just tried them but the text string has some "not decoded" chars. (I must study it)
Ok ok very much questions and ....problems :-)
Thank you again!

Does the TX LED of your RS485 module blink periodically?

Battery constant power works well but with limiter I don't understand which are the right parameters.

If "constant power works" does it mean you have used the manual mode of this project to pass a constant power demand to the inverter or did you change the inverter settings to constant power?

In this case I use this istant meter (not reverse energy) ...but I bought a Tuya dual meter for this scope.

Let's try to get this project up and running first and lets discuss the different possible to drive the limiter later on.

Does the TX LED of your RS485 module blink periodically?

Yes, TX led blinks

If "constant power works" does it mean you have used the manual mode of this project to pass a constant power demand to the inverter or did you change the inverter settings to constant power?
I selected "battery costant mode", I setted only "output power limit" (first item) and "manual mode" switch. It works well!

I have 3 D1 mini for 3 inverters and I've installed on all the same project.
If I attach the original power meter to the inverter RS485 port, do I need the RS485 converter? I think no, right?
Or do I must connect POWER_METER->RS485_CONVERTER->INVERTER?
I don't understant this thing.
Thank you very much again
PS: I love this project, if I can offer a beer to you, I'll be happy :)

If I attach the original power meter to the inverter RS485 port, do I need the RS485 converter? I think no, right?

If you use the original current clamp no converter is needed. The clamp should simply measure the current flow on some wire and tries to request this amount of power using RS485 at the inverter.
It's possible the original clamp doesn't do a good job because the clamp is unable to understand the direction of the current flow. For example if you feed 900W into the grid the clamp will measure the same power demand as if you import 900W from the grid.
This project avoids the original current clamp and passes a power demand retrieved using alternative measurement devices to the inverter.

I'm happy about any donation supporting this project:
https://paypal.me/syssi84
https://buymeacoffee.com/syssi

I'm happy about any donation supporting this project:
https://paypal.me/syssi84 https://buymeacoffee.com/syssi

OK!

If I attach the original power meter to the inverter RS485 port, do I need the RS485 converter? I think no, right?

If you use the original current clamp no converter is needed. The clamp should simply measure the current flow on some wire and tries to request this amount of power using RS485 at the inverter.
It's possible the original clamp doesn't do a good job because the clamp is unable to understand the direction of the current flow. For example if you feed 900W into the grid the clamp will measure the same power demand as if you import 900W from the grid.
This project avoids the original current clamp and passes a power demand retrieved using alternative measurement devices to the inverter.

Ok, I don't use original CT and Elfin converters, I bought this (next week I should receive it):

Bidirectional meter, I will add through Tuya Local on Home assiatant (one clip of course)
I will modify your(my) code with this and I hope that it works.
My goal is: use my 3 inverters in parallel (with 3 different 24V batteries) always on ...2100W max on demand (700x3).
I think that need esp32 (D1 mini has poor performace) with RS485 to TTL converter AND connect in parallel to 3 inverters
For this project I will need your precious help :)
Thank you very much again!

This sounds like a good decision. Let me summarize your future setup:

The tuya device will be installed next to your electricity meter to measure the energy imported from the grid.
The tuya device will publish the measurements so they are available in Home Assistant
One ESP will drive three inverters using the same RS485 bus. All inverters will be attached to the same RS485 converter.
The ESP will receive the measurements of the tuya device via Home Assistant. F.e. if the tuya device reports a power demand of 300W the demand will be divided by 3 (because of the power_demand_divider: 3) setting. A power demand of 100W will be reported using RS485. Each attached inverter will ramp up and produce 300W in total.

This sounds like a good decision. Let me summarize your future setup:

The tuya device will be installed next to your electricity meter to measure the energy imported from the grid.
The tuya device will publish the measurements so they are available in Home Assistant
One ESP will drive three inverters using the same RS485 bus. All inverters will be attached to the same RS485 converter.
The ESP will receive the measurements of the tuya device via Home Assistant. F.e. if the tuya device reports a power demand of 300W the demand will be divided by 3 (because of the power_demand_divider: 3) setting. A power demand of 100W will be reported using RS485. Each attached inverter will ramp up and produce 300W in total.

Yes! :)
Can you check if this configuration is right? I will use ESP32 Mini (dual core, 240 Mhz)
substitutions:
  name: soyosource-gtn-virtual-meter
  device_description: "Monitor multiple Soyosource GTNs and control the power output on demand both via RS485"
  device0: Inverter_0
  device1: Inverter_1
  device2: Inverter_2
  external_components_source: github://syssi/esphome-soyosource-gtn-virtual-meter@main
  tx_pin_ttl_wifi_uart_0: GPIO17
  rx_pin_ttl_wifi_uart_0: GPIO16
  tx_pin_ttl_wifi_uart_1: GPIO32
  rx_pin_ttl_wifi_uart_1: GPIO12
  tx_pin_ttl_wifi_uart_2: GPIO26
  rx_pin_ttl_wifi_uart_2: GPIO13
  tx_pin_rs485_uart_3: GPIO33
  rx_pin_rs485_uart_3: GPIO14

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "syssi.esphome-soyosource-gtn-virtual-meter"
    version: 2.1.0

esp32:
  board: esp32dev
  framework:
    type: arduino

external_components:
  - source: ${external_components_source}
    refresh: 0s

#ethernet:
#  type: LAN8720
#  mdc_pin: GPIO23
#  mdio_pin: GPIO18
#  clk_mode: GPIO17_OUT
#  phy_addr: 0

ota:

logger:
  baud_rate: 0
  level: INFO

# If you use Home Assistant please remove this `mqtt` section and uncomment the `api` component!
# The native API has many advantages over MQTT: https://esphome.io/components/api.html#advantages-over-mqtt
mqtt:
  broker: !secret mqtt_host
  username: !secret mqtt_username
  password: !secret mqtt_password
  id: mqtt_client

api:

uart:
  - id: uart_0
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_0}
    rx_pin: ${rx_pin_ttl_wifi_uart_0}
  - id: uart_1
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_1}
    rx_pin: ${rx_pin_ttl_wifi_uart_1}
  - id: uart_2
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_2}
    rx_pin: ${rx_pin_ttl_wifi_uart_2}
  - id: uart_3
    baud_rate: 4800
    tx_pin: ${tx_pin_rs485_uart_3}
    rx_pin: ${rx_pin_rs485_uart_3}

soyosource_modbus:
  - id: modbus0
    uart_id: uart_3
    # flow_control_pin: GPIO12
    # The name is used as prefix for some log messages and should
    # help to distinguish between different instances/devices
    name: Inverter_0
  - id: modbus1
    uart_id: uart_3
    name: Inverter_1
    # flow_control_pin: GPIO13
  - id: modbus2
    uart_id: uart_3
    name: Inverter_2
    # flow_control_pin: GPIO13

soyosource_inverter:
  - id: inverter0
    soyosource_modbus_id: modbus0
  - id: inverter1
    soyosource_modbus_id: modbus1
  - id: inverter2
    soyosource_modbus_id: modbus2

soyosource_virtual_meter:
  - id: virtualmeter0
    soyosource_modbus_id: modbus0
    update_interval: 3s

    # the state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter0
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    # operation_status_id: operation_status_id0

  - id: virtualmeter1
    soyosource_modbus_id: modbus1
    update_interval: 3s
    # the state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter1
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    # operation_status_id: operation_status_id1

  - id: virtualmeter2
    soyosource_modbus_id: modbus2
    update_interval: 3s
    # the state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter2
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    # operation_status_id: operation_status_id1

binary_sensor:
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter0
    fan_running:
      name: "${device0} fan running"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter1
    fan_running:
      name: "${device1} fan running"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter2
    fan_running:
      name: "${device2} fan running"

number:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    buffer:
      name: "${device0} buffer"
      initial_value: 10
      restore_value: true
    manual_power_demand:
      name: "${device0} manual power demand"
    max_power_demand:
      name: "${device0} max power demand"
      initial_value: 600
      restore_value: true
    power_demand_divider:
      name: "${device0} power demand divider"
      initial_value: 3
      restore_value: true

  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter1
    buffer:
      name: "${device1} buffer"
      initial_value: 10
      restore_value: true
    manual_power_demand:
      name: "${device1} manual power demand"
    max_power_demand:
      name: "${device1} max power demand"
      initial_value: 600
      restore_value: true
    power_demand_divider:
      name: "${device1} power demand divider"
      initial_value: 3
      restore_value: true

  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter2
    buffer:
      name: "${device2} buffer"
      initial_value: 10
      restore_value: true
    manual_power_demand:
      name: "${device2} manual power demand"
    max_power_demand:
      name: "${device2} max power demand"
      initial_value: 600
      restore_value: true
    power_demand_divider:
      name: "${device2} power demand divider"
      initial_value: 3
      restore_value: true

sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    power_demand:
      name: "${device0} power demand"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter1
    power_demand:
      name: "${device1} power demand"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter2
    power_demand:
      name: "${device2} power demand"

  - platform: soyosource_inverter
    soyosource_inverter_id: inverter0
    operation_status_id:
      name: "${device0} operation status id"
      id: operation_status_id0
    battery_voltage:
      name: "${device0} battery voltage"
    battery_current:
      name: "${device0} battery current"
    battery_power:
      name: "${device0} battery power"
    ac_voltage:
      name: "${device0} ac voltage"
    ac_frequency:
      name: "${device0} ac frequency"
    temperature:
      name: "${device0} temperature"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter1
    operation_status_id:
      name: "${device1} operation status id"
      id: operation_status_id1
    battery_voltage:
      name: "${device1} battery voltage"
    battery_current:
      name: "${device1} battery current"
    battery_power:
      name: "${device1} battery power"
    ac_voltage:
      name: "${device1} ac voltage"
    ac_frequency:
      name: "${device1} ac frequency"
    temperature:
      name: "${device1} temperature"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter2
    operation_status_id:
      name: "${device2} operation status id"
      id: operation_status_id1
    battery_voltage:
      name: "${device2} battery voltage"
    battery_current:
      name: "${device2} battery current"
    battery_power:
      name: "${device2} battery power"
    ac_voltage:
      name: "${device2} ac voltage"
    ac_frequency:
      name: "${device2} ac frequency"
    temperature:
      name: "${device2} temperature"

  # mqtt subscribe example
  #- id: powermeter0
  #  internal: true
  #  platform: mqtt_subscribe
  #  name: "${device0} instantaneous power consumption"
  #  topic: "smartmeter/sensor/firstfloor/obis/1-0:16.7.0/255/value"
  #  accuracy_decimals: 2
  #  unit_of_measurement: W
  #  device_class: power
  #  filters:
  #    - throttle_average: 15s

  #- id: powermeter1
  #  internal: true
  #  platform: mqtt_subscribe
  #  name: "${device1} instantaneous power consumption"
  #  topic: "smartmeter/sensor/groundfloor/obis/1-0:16.7.0/255/value"
  #  accuracy_decimals: 2
  #  unit_of_measurement: W
  #  device_class: power
  #  filters:
  #    - throttle_average: 15s

   # import smartmeter reading from homeassistant f.e.
   # requires the "api" component see above
   - platform: homeassistant
    id: powermeter0
    name: "${device0} smartmeter instantaneous power"
    entity_id: sensor.to_define_local_tuya_same_as_power_meter_1_and_2

  - platform: homeassistant
    id: powermeter1
    name: "${device1} smartmeter instantaneous power"
    entity_id: sensor.to_define_local_tuya_same_as_power_meter_0_and_2

  - platform: homeassistant
    id: powermeter2
    name: "${device2} smartmeter instantaneous power"
    entity_id: sensor.to_define_local_tuya_same_as_power_meter_0_and_1

switch:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    manual_mode:
      name: "${device0} manual mode"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter1
    manual_mode:
      name: "${device1} manual mode"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter2
    manual_mode:
      name: "${device2} manual mode"

text_sensor:
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter0
    operation_status:
      name: "${device0} operation status"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter1
    operation_status:
      name: "${device1} operation status"
  - platform: soyosource_inverter
    soyosource_inverter_id: inverter2
    operation_status:
      name: "${device2} operation status"

  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    operation_mode:
      name: "${device0} limiter operation mode"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter1
    operation_mode:
      name: "${device1} limiter operation mode"
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter2
    operation_mode:
      name: "${device2} limiter operation mode"

Thank you again

esp32:
  board: esp32dev
  framework:
    type: arduino

I prefer the ESP-IDF framework over arduino. It adds less overhead to the project.
uart:
  - id: uart_0
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_0}
    rx_pin: ${rx_pin_ttl_wifi_uart_0}
  - id: uart_1
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_1}
    rx_pin: ${rx_pin_ttl_wifi_uart_1}
  - id: uart_2
    baud_rate: 9600
    tx_pin: ${tx_pin_ttl_wifi_uart_2}
    rx_pin: ${rx_pin_ttl_wifi_uart_2}
  - id: uart_3
    baud_rate: 4800
    tx_pin: ${tx_pin_rs485_uart_3}
    rx_pin: ${rx_pin_rs485_uart_3}

A ESP32 supports 3 hardware UARTs in total. SoftwareSerial isn't available here. Using 4 UARTs won't be possible AFAIK.
soyosource_virtual_meter:
  - id: virtualmeter0
    soyosource_modbus_id: modbus0
    update_interval: 3s

    # the state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter0
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 900
    zero_output_on_min_power_demand: true
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    # operation_status_id: operation_status_id0

Please use a single soyosource_virtual_meter instance because you want to drive all three inverters simultaneously.

I prefer the ESP-IDF framework over arduino. It adds less overhead to the project.

How to do this? I've installed ESPHome with usb cable and adopt in home assistant, that is an automatic written

A ESP32 supports 3 hardware UARTs in total. SoftwareSerial isn't available here. Using 4 UARTs won't be possible AFAIK.

Noooo, just now I read this, SWSerial is avaible only on esp8266 :/
Three option remaining:
1-use D1mini with GPIO 1,3 4,5 14,12 13,15 (will it work? don't know)
2-use Esp8266 NodeMCU with more GPIOs
3-use Esp32 with this

Please use a single soyosource_virtual_meter instance because you want to drive all three inverters simultaneously.

Ok!

1-use D1mini with GPIO 1,3 4,5 14,12 13,15 (will it work? don't know)

You have to make sure to disable the logger on GPIO1/3 by setting the baud_rate to 0.

2-use Esp8266 NodeMCU with more GPIOs

The number of GPIOs aren't the limiting factor probably. Maintaining 3 SoftwareSerial interfaces is heavy for a ESP8266.

3-use Esp32 with this

This looks like a good choice. I've no experience with this specific board. It looks like the component does expose the additional UARTs as regular UartDevice istances so it should work out of the box.

Just use
esp32:
  board: esp32dev
  framework:
    type: esp-idf

instead of
esp32:
  board: esp32dev
  framework:
    type: arduino

to change the framework + compile & flash again as always.

You have to make sure to disable the logger on GPIO1/3 by setting the baud_rate to 0.

Yes, logger must be disabled

The number of GPIOs aren't the limiting factor probably. Maintaining 3 SoftwareSerial interfaces is heavy for a ESP8266.

I think so too, but some GPIOs on D1mini do not react as you expect, I will try with this board and old nodemcu that I have somewhere

This looks like a good choice. I've no experience with this specific board. It looks like the component does expose the additional UARTs as regular UartDevice istances so it should work out of the box.

I've just bought 2 modules :) (hope next week will be here)
Thank for to change framework and all
Sorry for another question:

Please use a single soyosource_virtual_meter instance because you want to drive all three inverters simultaneously.

If I use single virtual meter I can't drive each inverter, right?
With three virtual meter If I want drive all three inverters simultaneously AND drive each one separately I can set auto on two inverters and manual on third and all other combinations (f.e. if third battery is down) ...or is this another thing?

If I use single virtual meter I can't drive each inverter, right?
With three virtual meter If I want drive all three inverters simultaneously AND drive each one separately I can set auto on > two inverters and manual on third and all other combinations (f.e. if third battery is down) ...or is this another thing?

If you attach all inverters to the same RS485 bus all devices gets the same instructions. The inverters cannot be addressed using device addresses or something. It's more like a broadcast. The ESP broadcasts "please produce 100W". If a single inverter is attached to the bus 100W will be produced. If three inverteres will receive the message each inverter will produce 100W and you will receive 300W in total.
If you attach three RS485 converters to the ESP to have 3 independent busses you can drive each inverter individually using a virtual meter instance per device.

Thank, I understood you but look this scenario:
esp32/8266 -->TTL --> inverter0
|                 |----> inverter1
|                 |----> inverter2
|
|-------->RS485-->inverter0-->inverter1-->inverter2
With one virtual meter I have only one item for three inverters for:
buffer
manual power demand
max power demand
power demand divider
power demand
manual mode
limiter operation mode
With three virtual meter I can:
-set inverter0 and inverter1 on Auto and Battery limit, they will receive commands through RS485
-set inverter2 on Manual and battery costant power, it will not receive any command through RS485
I'm right?
Sorry for questions

With one virtual meter I have only one item for three inverters for

Correct because the virtual meter is like a small guy which checks your energy meter all the time. As soon there is some energy imported from the grid the guy decides what needs to be broadcasted via RS485. Because of the power demand divider: 3 the power demand gets devided by 3.

With three virtual meter I can:
-set inverter0 and inverter1 on Auto and Battery limit, they will receive commands through RS485

Correct. But you will need a RS485 bus per inverter (additional UARTs and RS485 converters!).

-set inverter2 on Manual and battery costant power, it will not receive any command through RS485

If you use the manual mode switch a constant power demand is requested via RS485 periodically. F.e. if you set the manual power demand  to 500W the ESP will transmit this demand once per second via RS485.

Correct. But you will need a RS485 bus per inverter (additional UARTs and RS485 converters!).
Ahhhh ok ok
A wrong think was: use n-virtual meter with one converter

If you use the manual mode switch a constant power demand is requested via RS485 periodically. F.e. if you set the manual power demand to 500W the ESP will transmit this demand once per second via RS485.

for now I use "manual mode" and "battery constant power", it works without attached power meter on inverter RS485 plug. I set only "output power limit" to n-W, "Manual power demand" is set to 0W.
Output power on esphome is 0W but I can check through L line CT and tasmota+pzem-004T. It works because I think that the command is received from USB (TTL) port and not from RS485.
Thank you so much for patience with me.
At this point I must decide what I want to do. ahahahah :)

Output power on esphome is 0W but I can check through L line CT and tasmota+pzem-004T. It works because I think that the command is received from USB (TTL) port and not from RS485.

The "output power limit" is a config setting of the inverter. You could remove the ESP and the inverter will continue to output the constant power. The "manual mode" is just a static power demand passed periodically via RS485. This should be used for automations. If you are using the "battery constant power" mode you haven't proved yet the RS485 connection is working in general.

Hello syssi and all oter users, I'm here again :)

With three virtual meter I can:
-set inverter0 and inverter1 on Auto and Battery limit, they will receive commands through RS485

Correct. But you will need a RS485 bus per inverter (additional UARTs and RS485 converters!).
In this schenario:
I have 3 inverters with 3 original wifi stick, I use 1 CT clamp and set on it 3 devices and connect it in parallel mode on the 3 inverters through rs485.
I use original android application, what happen? Can I drive all 3 inverters separately?
I will have 3 devices on my application and I can decide if "auto/manual" or "operation mode" for each one.
Am I wrong?

PS: i2c to dual uart module converter is here  :)
Always a big thank you

I have 3 inverters with 3 original wifi stick, I use 1 CT clamp and set on it 3 devices and connect it in parallel mode on the 3 inverters through rs485. I use original android application, what happen? Can I drive all 3 inverters separately?

The current clamp has some buttons. You can set the number of attached inverters here.

I use original android application, what happen? Can I drive all 3 inverters separately?

It looks like your understanding of your inverter features and the additional feature of this project aren't pretty clear yet.

Imagine your inverter would have a display and some buttons (the OEM wifi dongle is just a replacement/alternative for the display). You can use the button to navigation, open the inverter settings menu and change the operation mode of the inverter from "limiter mode" to "constant power mode". There is a second option to set the maximum output power. In limiter mode this is the upper limit (f.e. if the power demand is 2000W requested via RS485 and the maximum output power is set to 300W the inverter will output 300W only!). In "constant power mode" the maximum output power is the constant power the inverter will provide permanently.

You shouldn't change the inverter settings multiple times per day because they are written into an EEPROM or flash storage which will be worn out pretty fast.
Let's call these features "inverter firmware settings/features" in future. These inverter firmware settings/feature can be changed/controlled using this project individually as soon a ESP is connected to the display port of the inverter.

The soyosource_virtual_meter component of this project expects the inverter is always in limiter mode. The inverter is able to receive a single message via RS485 this is the so called "power demand" (in words: "Dear inverter, please provide 300W now!"). The soyosource_virtual_meter component provides two controls called "manual power mode" and "manual power demand". If you enable the manual power mode the manual power demand value will be passed periodically to the inverter via RS485. If the value of the manual power demand is set to 150W (using Home Assistant or MQTT) the soyosource_virtual_meter will send the power demand of 150W periodically to the inverter using RS485.

Let's call the features of the soyosource_virtual_meter in future project features.
Could you rephrase your question:

I use original android application, what happen? Can I drive all 3 inverters separately?

Are you talking about inverter firmware settings?

It looks like your understanding of your inverter features and the additional feature of this project aren't pretty clear yet.

Yes, I dont understand yet the logic, I'm very sorry.

I use original android application, what happen? Can I drive all 3 inverters separately?

Are you talking about inverter firmware settings?

I mean: with original application, original wifi stick and original CT connected on parallel to 3 inverters, Can I set f.e. the first and second inverters on auto - battery limit and the third one on manual - costant power?
I've used "all original" for two days because I don't like it, I don't know if that settings are applicable.
For now I have 2 inverters always on (for third inverter I haven't yet the battery and it off for now), 2 wemos d1_mini, 2 rs485 converters.
Each inverter is connected with the own (your "Monitor and control the Soyosource GTN (WiFi version) via the display port and control the power output on demand via RS485") module.
The settings are the same on the two modules:
Output power limit 700
manual mode OFF
manual power demand 0
max power demand 1800
divider 2
If the first battery is under 20% of charge I tell to home assistant to switch "manual mode - ON" and if the "manual power demand" is set to 0, the inverter stop the AC output (1 or 2 watts only). When the state of charge is over f.e. 40% I tell to home assistant to switch again to "manual mode - OFF" ...and so on.
In the same time the second battery is on 50%, second inverter is always in "manual mode - OFF" and his output will be the double because the first inverter is in manual and power demand is 0.
Problem: in this scenario when the first inverter switch to auto again, his output is some watts (f.e. 5/10/40) because the output of second inverter remain f.e. to 300W, they are not synched.
Solution 1: power on microwave (1500W), the two inverters go to max power, power off microwave, the two inverter are "more or less" synched (f.e. the first output is 130W and the second is 170W if my house power demand is 300W)
Solution 2: turn on "manual mode" togheter inverters, turn off manual mode and to hope that they sync togheter , if not try again.
Solution 3: use one module that drive 2 (or more) inverters togheter with 1 power meter that always sync the two output power. Is it possible this thing?
Thank you for patience

This is an example:
Actual Power from grid of my house

Outpout power from 2 inverters (2 tasmota d1 mini + pzem-004 with clips put on output L line of each inverter)

Output power through this project from Inverter 1

Output power through this project from Inverter 2

As you can see the output of 2 inverter are not the same.
Is there any configuration that I can to do to sync them?
1 esp32 with 2 ttl interface (3 in future) and 1 rs485 that drive 2 inverters, could to solve the sync?
If yes and if I can't set "manual mode" on each inverter, I can switch OFF a channell where is attached that inverter if the battery is under 20%.
I have this, directly connected with inverters fro each channel

But I don't know if is good remove AC from inverter, can it damage?
Another think: with only one "virtual meter" the esp32 does not to know which inverter I want to set on manual mode. I'm right?
This is because there is not address to set for individual inverter. I'm right?

Hello to all :)
I made the first version: control 2 inverters (3 in the next future) with one virtual meter, it works and the outputs are synced.
substitutions:
  name: soyosource-gtn-display
  device_description: "Monitor and control multi Soyosource GTN (WiFi version) via the display port and control the power output on demand via RS485"
  external_components_source: github://syssi/esphome-soyosource-gtn-virtual-meter@main
  # The display port should be connected to these GPIOs using a USB connector (VCC, RX, TX, GND)
  # A optocoupler / optical isolator (f.e. ADUM1201) between the display port and the ESP is recommended if the ESP isn't powered by the display port!
  device0: Inverter 0
  device1: Inverter 1
  tx_pin_rs485_uart_0: GPIO1
  rx_pin_rs485_uart_0: GPIO3

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "syssi.esphome-soyosource-gtn-virtual-meter"
    version: 2.1.0

esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf

external_components:
  - source: ${external_components_source}
    refresh: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

ota:

logger:
  level: INFO

# If you use Home Assistant please remove this `mqtt` section and uncomment the `api` component!
# The native API has many advantages over MQTT: https://esphome.io/components/api.html#advantages-over-mqtt
mqtt:
  broker: <IP_ADDRESS>
  username: mqtt_user
  password: 3zeri3uno@
  #id: mqtt_client

api:

# Allow provisioning Wi-Fi via serial
improv_serial:

i2c:
  sda: GPIO21
  scl: GPIO22
  scan: true
  id: bus_a

wk2132_i2c:
  - address: 0x70
    id: wk2168_bridge_i2c
    uart:
      - id: i2c_uart_0
        channel: 0
        baud_rate: 9600
        parity: none
      - id: i2c_uart_1
        channel: 1
        baud_rate: 9600
        parity: none

uart:
  - id: uart_0
    baud_rate: 4800
    tx_pin: ${tx_pin_rs485_uart_0}
    rx_pin: ${rx_pin_rs485_uart_0}

soyosource_modbus:
  - id: modbus0
    uart_id: uart_0
    name: Inverter

soyosource_virtual_meter:
  - id: virtualmeter0
    soyosource_modbus_id: modbus0
    # The state of this sensor (instantaneous power in watt) is used as source
    power_id: powermeter0

    # Optional settings
    power_sensor_inactivity_timeout: 20s
    power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
    min_power_demand: 0
    max_power_demand: 1800
    zero_output_on_min_power_demand: true
    # Split/distribute the power demand if you have multiple inverters attached to the same RS485 bus
    power_demand_divider: 2
    # A positive buffer value (10) tries to avoid exporting power to the grid (demand - 10 watts)
    # A negative buffer value (-10) exports power to the grid (demand + 10 watts)
    buffer: 10
    # The operation_status_id sensor is expected here. Passing the operation_status won't work
    # The state is used to suspend the limiter if the operation status of the inverter isn't 0x0 (normal)
    #operation_status_id: operation_status_id0

    # The update interval is important and defaults to 3 seconds. If the demand is sent too frequently
    # or rarely the interverter stops. TODO: Identify and validate the lower and upper update limit
    update_interval: 3s

soyosource_display:
  - id: display0
    uart_id: i2c_uart_0
    protocol_version: SOYOSOURCE_WIFI_VERSION
    update_interval: 5s
  - id: display1
    uart_id: i2c_uart_1
    protocol_version: SOYOSOURCE_WIFI_VERSION
    update_interval: 5s

binary_sensor:
  - platform: soyosource_display
    soyosource_display_id: display0
    fan_running:
      name: "${device0} fan running"
    limiter_connected:
      name: "${device0} limiter connected"
  - platform: soyosource_display
    soyosource_display_id: display1
    fan_running:
      name: "${device1} fan running"
    limiter_connected:
      name: "${device1} limiter connected"

button:
  - platform: soyosource_display
    soyosource_display_id: display0
    restart:
      name: "${device0} restart"
  - platform: soyosource_display
    soyosource_display_id: display1
    restart:
      name: "${device1} restart"

number:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    buffer:
      name: "${name} buffer"
      initial_value: 10
      restore_value: true
    manual_power_demand:
      name: "${name} manual power demand"
      max_value: 1800
    max_power_demand:
      name: "${name} max power demand"
      initial_value: 0
      max_value: 1800
      restore_value: true
    power_demand_divider:
      name: "${name} power demand divider"
      initial_value: 2
      restore_value: true

  - platform: soyosource_display
    soyosource_display_id: display0
    start_voltage:
      name: "${device0} start voltage"
    shutdown_voltage:
      name: "${device0} shutdown voltage"
    # Maximum output power in limiter mode / Output power in constant power mode
    output_power_limit:
      name: "${device0} output power limit"
    start_delay:
      name: "${device0} start delay"
  - platform: soyosource_display
    soyosource_display_id: display1
    start_voltage:
      name: "${device1} start voltage"
    shutdown_voltage:
      name: "${device1} shutdown voltage"
    # Maximum output power in limiter mode / Output power in constant power mode
    output_power_limit:
      name: "${device1} output power limit"
    start_delay:
      name: "${device1} start delay"

select:
  - platform: soyosource_display
    soyosource_display_id: display0
    operation_mode:
      name: "${device0} operation mode"
      optionsmap:
        1: "PV"
        2: "Battery Constant Power"
        17: "PV Limit"
        18: "Battery Limit"
  - platform: soyosource_display
    soyosource_display_id: display1
    operation_mode:
      name: "${device1} operation mode"
      optionsmap:
        1: "PV"
        2: "Battery Constant Power"
        17: "PV Limit"
        18: "Battery Limit"

sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    power_demand:
      name: "${name} power demand"

  - platform: soyosource_display
    soyosource_display_id: display0
    error_bitmask:
      name: "${device0} error bitmask"
    operation_mode_id:
      name: "${device0} operation mode id"
#    operation_status_id:
#      name: "${device0} operation status id"
#      id: operation_status_id0
    battery_voltage:
      name: "${device0} battery voltage"
    battery_current:
      name: "${device0} battery current"
    battery_power:
      name: "${device0} battery power"
    ac_voltage:
      name: "${device0} ac voltage"
    ac_frequency:
      name: "${device0} ac frequency"
    temperature:
      name: "${device0} temperature"
    output_power:
      name: "${device0} output power"
  - platform: soyosource_display
    soyosource_display_id: display1
    error_bitmask:
      name: "${device1} error bitmask"
    operation_mode_id:
      name: "${device1} operation mode id"
#    operation_status_id:
#      name: "${device1} operation status id"
#      id: operation_status_id0
    battery_voltage:
      name: "${device1} battery voltage"
    battery_current:
      name: "${device1} battery current"
    battery_power:
      name: "${device1} battery power"
    ac_voltage:
      name: "${device1} ac voltage"
    ac_frequency:
      name: "${device1} ac frequency"
    temperature:
      name: "${device1} temperature"
    output_power:
      name: "${device1} output power"

  - platform: homeassistant
    id: powermeter0
    name: "${name} smartmeter instantaneous power"
    entity_id: sensor.total_power

switch:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    manual_mode:
      name: "${name} manual mode"
      restore_mode: RESTORE_DEFAULT_ON
    emergency_power_off:
      name: "${name} emergency power off"
      restore_mode: RESTORE_DEFAULT_OFF

text_sensor:
  - platform: soyosource_virtual_meter
    soyosource_virtual_meter_id: virtualmeter0
    operation_mode:
      name: "${name} limiter operation mode"

  - platform: soyosource_display
    soyosource_display_id: display0
    errors:
      name: "${device0} errors"
    operation_mode:
      name: "${device0} operation mode"
    operation_status:
      name: "${device0} operation status"
  - platform: soyosource_display
    soyosource_display_id: display1
    errors:
      name: "${device1} errors"
    operation_mode:
      name: "${device1} operation mode"
    operation_status:
      name: "${device1} operation status"

this is the hardware:

The third inverter will be attached to serial 2 on esp32.
The suggestions for improvement are welcome :)
Thank you Syssi and all other :)


.NET SDK version specification

Great docs, thanks a lot.
However, I have a small adjustment. Source generators doesn't work for me with version of .NET SDK 6.0.100 (msbuild 17.0). It works only with new update - .NET SDK 6.0.201 (msbuild 17.1). If possible and it is not a bug, please mention it on docs.

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

ID: 99a4410c-4c8d-0107-845b-9a951bb76682
Version Independent ID: f1ed9873-3e29-b4bd-2dbb-44dd9a05d790
Content: Source Generators
Content Source: docs/csharp/roslyn-sdk/source-generators-overview.md
Product: dotnet-csharp
Technology: csharp-roslyn
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Adding @jmarolf
Is this a known issue?

@Scensna Can you please define "how" it doesn't work? and what version of Microsoft.CodeAnalysis are you using? It's known that each version of Microsoft.CodeAnalysis requires a minimum version of .NET SDK.
So you probably was using a Microsoft.CodeAnalysis version that requires .NET SDK 6.0.201. In this case you need to do one of the following:

Upgrade to newer .NET SDK (as you already did)
Downgrade Microsoft.CodeAnalysis to an older version.

@Youssef1313 That is possible, thanks. I missed this information somehow. I used version 3.3.3 of Microsoft.CodeAnalysis with .NET SDK 6.0.100.
The original problem was that the final dll file missed methods and variables from generated code (checked by dotpeek). But as you said, it was solved by upgrading .NET SDK to 6.0.201 and I just missed the information about version combination.

@Scensna I think 3.3.3 should be compatible with any version of .NET 6.
@jmarolf got any idea what could have happened?


EPMRPP-63675: UI validation

https://jiraeu.epam.com/browse/EPMRPP-63675
DESCRIPTION:

Added  UI validation for integration creation form.

ok for me


Inline touch/main.js

http://web-animations.github.io/web-animations-demos/#touch
If you click the Code button, all it shows is an HTML scaffold that marshals out to main.js.  To maintain consistency with the other demos, the script should be inlined.

I've resolved this but we've also currently disabled the demo as it only works in touch environments.


Song sorting puts all capital initials in front of lower cases

Right now the sorting is probably by ASCII value only, but it would be better if the songs are sorted like AaBbCcDd instead of ABCDabcd.

I agree

Fixed in 1.3.


Feature Like Quick View

Description of the new feature / enhancement
Instead of the file explorer ad ons to view the files without opening them, a feature like quick look could be introduced which triggers the preview of file explorer files by simply pressing the space bar.
Scenario when this would be used?
This would be used each and every time someone wants to preview their files without wasting the time to actually open them.
Supporting information
No response

/dup #80


Associations with gene category object need to be binned into Causal v Correlated

This will effect the entity call that returns counts, and the single association based on category object call

We need to define the mapping of all of the computed labels needed.

Implemented with association types


[FEATURE] Add priority numbers to catalog schemas.

Is your feature request related to a problem?
When a user attempts to manually create an integration index template after automatic creation via the available options, there is a conflict on the matching index patterns. This manifests as an error resembling:
[illegal_argument_exception]: index template [logs] has index patterns [ss4o_logs-*-*] matching patterns from existing templates [logs_1.0.0] with patterns (logs_1.0.0 => [ss4o_logs-nginx-*-sample]) that have the same priority [0], multiple index templates may not match during index creation, please use a different priority

What solution would you like?
While code can be implemented to apply priority numbers to sample indices, the most stable solution is to have them available as part of the schemas already. This was the route taken with the local copies of the schemas used in the integrations project. This is as easy as adding a "priority": 900 line to every schema in the repo.
What alternatives have you considered?
It could be handled in-code. As mentioned, it's more stable and configurable to have it assigned in the repo as-is.
Do you have any additional context?
N/A

I dont think this is the solution here - if an existing log patterns is conflicting with a new pattern - user has to resolve the pattern conflict rather than assume some priority would save all the different cases in a similar manner.
a user should reconcile the patterns according to his own needs - this can be done using the index management plugin configuration


Azure disk limitations not up to date anymore

The information in the section "Azure disk limitations" (https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/aks/availability-zones.md#azure-disks-limitations) seems not to be correct anymore:
From all what i could find, Kubernetes is aware of Azure availability zones since version 1.12 and scheduler does schedule the pod only in the zone, where its volume is. I did not need to configure anything special regarding that. That is why the part with the taint and tolerations confused me a lot. Can it be updated?

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

ID: 471c32a2-1f6a-88d1-7df4-80b8f6fbc4a4
Version Independent ID: 10de5ee1-942d-e30f-5f0c-f163bd45904d
Content: Use availability zones in Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/availability-zones.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@timdeluxe  Thank you for your feedback, our team will further look into this and get back to you at the earliest.

Can you please confirm if availability zones is still not compatible with azure disks?

Taking this, I'll check our docs and update them to make sure they reflect the newest information.

Updated and corrected, thanks @timdeluxe for the issue :)
I think this can be closed @Karishma-Tiwari-MSFT

Thanks for bringing this to our attention. We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.


Expose smoothing functions

This PR exposes the smooth_MLS2D from vedo to the plugin.

[x] demo notebook
[x] no abbreviation variables in code
[x] docstring in function explaining what parameters do

Addresses   #21

Hi @haesleinhuepf ,
these functions (smoothing) are already part of main, but lack docstrings and entries in napari.yaml. Also, smoothMLS2D works on PointsData and not on SurfaceData - I changed this in the tools menu.


Newbie here trying to get this running

If I try and run the following:
py manage.py runserver_socketio
I get this error:
ImportError: cannot import name 'execute_manager' from 'django.core.management'
Any ideas on how to get this to work?

It's been a very, very long time since this code was written and run, close
to 10 years. I suspect a lot of the versioning here is so far out of date
that is what's causing the problems.
I would suggest looking at the core code and consider it instructive at
this point.
If you want something that will work with Django you might need to re
implement and start with a modern Django approach+ python 3.
If you're just after something that will display real-time data to a web
browser I would suggest using node, Mosca and mqttjs to get this effect as
the most lightweight and modern approach.
On Sat, 19 Mar 2022, 08:21 rtalich, @.***> wrote:

If I try and run the following:
py manage.py runserver_socketio
I get this error:
ImportError: cannot import name 'execute_manager' from
'django.core.management'
Any ideas on how to get this to work?
—
Reply to this email directly, view it on GitHub
https://github.com/ajfisher/realtime-temperature/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA5DI72FGVAOI7EUVYFHJTVATXWHANCNFSM5RC56UXA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thank you so much for the reply!  Like you said… this is very old code and so I wasn’t sure if I’d get a reply or not.  I am just getting into this so I have not even scratched the surface yet… youtube is absolutely amazing for learning!!  I think I have some grasp on the overall structures… its mainly the wording and syntax used in all these java scripts that  have me puzzled.
I have started looking into node.js and hope to have something workable to accomplish what I am after.
Robert Talich
Electrical Engineer, Network Solutions
T:<PHONE_NUMBER>
Leviton Network Solutions
www.leviton.comhttp://www.leviton.com |<EMAIL_ADDRESS>From: ajfisher @.>
Sent: Friday, March 18, 2022 11:07 PM
To: ajfisher/realtime-temperature @.>
Cc: Talich, Rob @.>; Author @.>
Subject: Re: [ajfisher/realtime-temperature] Newbie here trying to get this running (Issue #1)
CAUTION: This email originated from outside of the organization.
It's been a very, very long time since this code was written and run, close
to 10 years. I suspect a lot of the versioning here is so far out of date
that is what's causing the problems.
I would suggest looking at the core code and consider it instructive at
this point.
If you want something that will work with Django you might need to re
implement and start with a modern Django approach+ python 3.
If you're just after something that will display real-time data to a web
browser I would suggest using node, Mosca and mqttjs to get this effect as
the most lightweight and modern approach.
On Sat, 19 Mar 2022, 08:21 rtalich, @.***> wrote:

If I try and run the following:
py manage.py runserver_socketio
I get this error:
ImportError: cannot import name 'execute_manager' from
'django.core.management'
Any ideas on how to get this to work?
—
Reply to this email directly, view it on GitHub
https://github.com/ajfisher/realtime-temperature/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA5DI72FGVAOI7EUVYFHJTVATXWHANCNFSM5RC56UXA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHubhttps://github.com/ajfisher/realtime-temperature/issues/1#issuecomment-1072950330, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYJKQZUH3UIDBEEYNZUT3S3VAVVIFANCNFSM5RC56UXA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>


Design Extensions Interface

What should the format be?
A Working Implementation
I made a implementation that works if you choose to use otherwise it is here to base yours off of.
Clone It At:
https://github.com/TheBrokenRail/scratch-blocks.git Branch: feature/extensions
More About Example Implementation:
How To Load Extension
Push the JSON to Blockly.Extensions.EXTENSIONS
JSON Block Example
{
    "xml":"<block></block>",
    "jsonSpec": {
        "message0": "if on edge, bounce",
        "previousStatement": null,
        "nextStatement": null
    },
    "id":"example_block",
    "run":"console.log('Do Stuff');"
}

Extensions are arrays containing JSON blocks
Example Implementation For Scratch-VM
var block = Blockly.Extentions.lookupBlock(args.mutation.id);
eval(block.run);

Is there any way for me to put my implementation and it's documentation elsewhere like a design example pull request?

Updated example to use json init and toolbox xml instead of parsing a string.

The best option for things like this is to put up a branch (e.g. feature/extensions) in your fork and then post a link to it in this issue. Example PRs are hard for us to work with a can be very noisy / intrusive.

There: https://github.com/TheBrokenRail/scratch-blocks.git Branch: feature/extensions

Updated with proper example.

Any comments on the example implementation?

Tracking in scratch-vm. Current direction documented here:
https://github.com/LLK/scratch-vm/wiki/Extensions-Proposal


submit instructions & button not showing for some valid submissions

discovered by @ESapenaVentura
Steps to reproduce:

go to ingest ui and show Submission - dcp1219560702433721
go to Submit tab
instructions and submit buttons do not appear (see screenshot)
notice a JS error in the browser console

This happens only for this submissions. The submit instructions and button show for all other valid submissions in Prod. For example: Submission - HealthyAndCirrhoticLiver

Error message in browser console:
'''
main-es2015.6bc03aea3e9741e99099.js:1 ERROR TypeError: Cannot read properties of undefined (reading 'subscribe')
at e.ngOnInit (main-es2015.6bc03aea3e9741e99099.js:1)
'''
screenshot

Original spreadsheet with uuids: https://app.zenhub.com/files/299258791/5ef3dbed-69b1-4eee-bc01-7dcec8a621cb/download

Dev notes:
The submission manifest shows that there is a mismatch actual links/expected links count which may mean that linking hasn't finished.
actualLinks: 1500
expectedLinks: 1526

Enrique removed the supplementary file and that seems to have fixed the issue.
The submission manifest was showing:
actualLinks: 1524
expectedLinks: 1524

Still need to investigate the root cause.

It looks like this only happens when the project is created before uploading the spreadsheet. The project isn't being linked in the supplementary file because the importer doesn't do any linking for existing entities.

@aaclan-ebi Is this a bug?

@amnonkhen yes, it is! Before, projects are being created as part of the spreadsheet. I guess this is something not handled when we allowed the projects to be created first before the submission.

@aaclan-ebi & @ESapenaVentura to create a ticket for the bug, and document the workaround in this ticket.

I've updated this ticket with new steps to replicate the bug and updated the title to be more specific.
Workarounds:

Remove supplementary files and update project metadata with links to files
Put the project worksheet in the metadata spreadsheet

Alegria still working on the comments. She will work on this today

Have tested as above:

Created project in the UI
uploaded spreadsheet as a submission
Checked the submission manifest

"actualLinks" : 1526,   "expectedLinks" : 1526
Shows the expected number of links.

This is deployed in prod now.

https://gitlab.ebi.ac.uk/hca/ingest-broker/-/pipelines/204639


DNS Resolution failed - socket busy

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
Kong 3.5 and 3.6
Current Behavior
Requests fail randomly with the following log:
[error] 1282#0: *5585 [lua] init.lua:371:
execute(): DNS resolution failed: failed to send request
 to UDP server <IP_ADDRESS>:53: socket busy.
Tried: ["(short)xxx:(na) - cache-miss","xxx.local:33 - cache-miss/querying"],
client: xxx, server: kong, request: "GET /path HTTP/1.1", host: "xxx", request_id: "5a27c00c11b735727f5c452bf425f26d"

The client gets the following message back:
{ message:
       'failed the initial dns/balancer resolve for \'xxx\' with: failed to send request to UDP server <IP_ADDRESS>:53: socket busy',
      request_id: '2ae16d137decfc5bd7a5051975d9b922' }

Expected Behavior
Requests go through as per Kong 3.4.2
Steps To Reproduce
I don't know, since it happens only sporadically
Edit: It happens quite frequently when the configuration option dns_no_sync is turned off (so dns sync is on -> default behavior as of Kong 3.5.0) and quite sporadically with it turned on.
We have the following setup:

Declarative config file
Kubernetes. The redacted xxx host paths are from K8s internal DNS
Mostly default configuration (with custom plugin)

Anything else?
It works perfecly with Kong 3.4.2. We tried upgrading back in November to 3.5, which gave us the same flaky behavior. Found some very old issues, which seem to be resolved.

Could it be related to this issue (currently open): https://github.com/Kong/kong/issues/12290
It's not the same error in the logs, but a similar response and related to DNS as well

We found the change that causes our issue: https://github.com/Kong/kong/pull/11871
We updated our kong.conf with dns_no_sync = on (the name confused me a bit, first I turned it off, thinking it would turn off dns_sync, then I noticed the no in there)
This resolves our problem, but the underlying issue is still there if someone cares to investigate

Possibly related to https://github.com/Kong/kong/issues/3223?

Any input on this?

@chobits , could you give us some comments about this?

will look into it later

Hi @chobits, thanks for chipping in
Here are the logs. I included some startup logs as well so you can see the configuration. It happened right off the bat as well
kong-logs.csv
The problem is quite severe for us (at least with the DNS sync enabled) and happens even if there are very few request being made. The example above are a few system tests that run through. I guess that there are about 50 calls within 2 minutes. I don't imagine it is a heavy load problem, rather a configuration problem on our end or something else
Some more information that could possibly be relevant:

We have a custom auth plugin installed with a few lua deps
We use the official ubuntu image and update the dependencies in our custom dockerfile (because of our vulnerability management policies)
We are inside a Google Kubernetes Cluster and behind a Load Balancer that provides the SSL-Support
We deploy via a custom helm chart, since we just need a minimal setup

hi I have thought of a method to mitigate your issue, you could configure dns_stale_ttl from 4s to a longer value. Currently in kong latest version, we have set it to 3600s, you could also set it to this value, which gives your dns records a longer lifespan.

Thanks for the reply.
Yes xxx is a real kubernetes domain name(s) (internal DNS)
It seems like the staleTtl is already at 3600 as far as I can tell. Please correct me if I'm wrong here. Here a snippet from the logs that describes the DNS settings more verbosely (staleTtl being the second from the bottom):
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:647: init(): [dns-client] emptyTtl = 30 s","2024-03-07T08:24:08.956815518Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:645: init(): [dns-client] badTtl = 1 s","2024-03-07T08:24:08.956632467Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:633: init(): [dns-client] search = king.svc.cluster.local, svc.cluster.local, cluster.local, google.internal","2024-03-07T08:24:08.956478982Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:631: init(): [dns-client] ndots = 5","2024-03-07T08:24:08.956330928Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:627: init(): [dns-client] timeout = 2000 ms","2024-03-07T08:24:08.956134323Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:618: init(): [dns-client] no_random = true","2024-03-07T08:24:08.955963978Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:611: init(): [dns-client] attempts = 5","2024-03-07T08:24:08.955823817Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:606: init(): [dns-client] nameserver <IP_ADDRESS>","2024-03-07T08:24:08.955685968Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:565: init(): [dns-client] validTtl = nil","2024-03-07T08:24:08.955670959Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: localhost = [::1]","2024-03-07T08:24:08.955662768Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:541: init(): [dns-client] adding A-record from 'hosts' file: localhost = <IP_ADDRESS>","2024-03-07T08:24:08.955627713Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-allrouters = [fe00::2]","2024-03-07T08:24:08.954856727Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-localnet = [fe00::0]","2024-03-07T08:24:08.954672873Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-allnodes = [fe00::1]","2024-03-07T08:24:08.954364051Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-loopback = [::1]","2024-03-07T08:24:08.954047780Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-localhost = [::1]","2024-03-07T08:24:08.953833227Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:541: init(): [dns-client] adding A-record from 'hosts' file: xxx = xxx","2024-03-07T08:24:08.953549257Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:556: init(): [dns-client] adding AAAA-record from 'hosts' file: ip6-mcastprefix = [fe00::0]","2024-03-07T08:24:08.953099393Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:501: init(): [dns-client] query order = LAST, SRV, A, CNAME","2024-03-07T08:24:08.952530616Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:482: init(): [dns-client] noSynchronisation = false","2024-03-07T08:24:08.950206705Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:478: init(): [dns-client] staleTtl = 3600","2024-03-07T08:24:08.950063140Z"
"2024/03/07 08:24:08 [debug] 1325#0: *1294 [lua] client.lua:473: init(): [dns-client] (re)configuring dns client","2024-03-07T08:24:08.949858585Z"

We don't override any DNS related options in the config file. Here our current kong.conf (injected into the kong:3.4.2 image):
plugins = auth-internal
declarative_config = /etc/kong/kong.yml
nginx_http_lua_shared_dict=auth_internal 10m
# Change for kong>=3.5 cf https://github.com/Kong/kong/issues/12568
# dns_no_sync = on

Thanks @chobits for your support :pray:

hi @henrythethird
Could you try this docker image: kong/kong:3a034e9417743fcf946deb6f98d2993049b1e589-ubuntu which is built from https://github.com/Kong/kong/pull/12305 based 3.6.x.x.
In this PR, we refactor our DNS client, if you could try this PR's docker image, it could help us to verify whether this issue still be there in new DNS client. If both versions of kong have this problem, I guess DNS client socket might be messed up by some other subsystem in kong.

Thanks for the update. We get the following error with kong/kong:3a034e9417743fcf946deb6f98d2993049b1e589-ubuntu:
2024/03/26 08:27:37 [error] 1331#0: *90612 lua entry thread aborted: runtime error: /usr/local/share/lua/5.1/kong/resty/dns_client/init.lua:669: attempt to call method 'lower' (a nil value)
stack traceback:
coroutine 0:
	/usr/local/share/lua/5.1/kong/resty/dns_client/init.lua: in function 'execute_original_func'
	/usr/local/share/lua/5.1/kong/dynamic_hook/init.lua:144: in function 'raw_func'
	/usr/local/share/lua/5.1/kong/tracing/instrumentation.lua:288: in function 'toip'
	/usr/local/share/lua/5.1/kong/runloop/balancer/init.lua:364: in function 'execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:832: in function 'balancer_execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:1352: in function 'after'
	/usr/local/share/lua/5.1/kong/init.lua:1186: in function 'access'
	access_by_lua(nginx-kong.conf:112):2: in main chunk, client: <IP_ADDRESS>, server: kong, request: "POST /path/to/resource HTTP/1.1", host: "xxx", request_id: "2a1bbe203f4c2a309845b0777f2b7862"

Thanks for the update @chobits. We get the following error with kong/kong:3a034e9417743fcf946deb6f98d2993049b1e589-ubuntu:
2024/03/26 08:27:37 [error] 1331#0: *90612 lua entry thread aborted: runtime error: /usr/local/share/lua/5.1/kong/resty/dns_client/init.lua:669: attempt to call method 'lower' (a nil value)
stack traceback:
coroutine 0:
	/usr/local/share/lua/5.1/kong/resty/dns_client/init.lua: in function 'execute_original_func'
	/usr/local/share/lua/5.1/kong/dynamic_hook/init.lua:144: in function 'raw_func'
	/usr/local/share/lua/5.1/kong/tracing/instrumentation.lua:288: in function 'toip'
	/usr/local/share/lua/5.1/kong/runloop/balancer/init.lua:364: in function 'execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:832: in function 'balancer_execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:1352: in function 'after'
	/usr/local/share/lua/5.1/kong/init.lua:1186: in function 'access'
	access_by_lua(nginx-kong.conf:112):2: in main chunk, client: xxx, server: kong, request: "POST /path/to/resource HTTP/1.1", host: "xxx", request_id: "2a1bbe203f4c2a309845b0777f2b7862"

Additionally in the beginning we get the following (still the same)
[error] 1330#0: *90586 [lua] init.lua:371: execute(): DNS resolution failed: DNS server error: failed to send request to UDP server <IP_ADDRESS>:53: socket busy, Query Time:<PHONE_NUMBER>.111 0.000. Tried: [["cluster.address.local:SRV","DNS server error: failed to send request to UDP server <IP_ADDRESS>:53: socket busy, Query Time:<PHONE_NUMBER>.111 0.000"]], client: xxx, server: kong, request: "GET /path/to/resource", host: "xxx", request_id: "0b7dc268d13c6648f089681aa55df436"

__

Thanks for the update @chobits. We get the following error with kong/kong:3a034e9417743fcf946deb6f98d2993049b1e589-ubuntu:
2024/03/26 08:27:37 [error] 1331#0: *90612 lua entry thread aborted: runtime error: /usr/local/share/lua/5.1/kong/resty/dns_client/init.lua:669: attempt to call method 'lower' (a nil value)
stack traceback:
coroutine 0:
	/usr/local/share/lua/5.1/kong/resty/dns_client/init.lua: in function 'execute_original_func'
	/usr/local/share/lua/5.1/kong/dynamic_hook/init.lua:144: in function 'raw_func'
	/usr/local/share/lua/5.1/kong/tracing/instrumentation.lua:288: in function 'toip'
	/usr/local/share/lua/5.1/kong/runloop/balancer/init.lua:364: in function 'execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:832: in function 'balancer_execute'
	/usr/local/share/lua/5.1/kong/runloop/handler.lua:1352: in function 'after'
	/usr/local/share/lua/5.1/kong/init.lua:1186: in function 'access'
	access_by_lua(nginx-kong.conf:112):2: in main chunk, client: xxx, server: kong, request: "POST /path/to/resource HTTP/1.1", host: "xxx", request_id: "2a1bbe203f4c2a309845b0777f2b7862"

Did it constantly occur if you request this request: "POST /path/to/resource HTTP/1.1", host: "xxx", request_id: "2a1bbe203f4c2a309845b0777f2b7862"?
Did your plugin call this kind of methods: kong.service.set_target() or kong.service.set_upstream().
From kong's logic, it seems that the balancer_data.host should be a string, so if we call balancer_data.host:lower(), it will success while not reporting a runtime error.

Additionally in the beginning we get the following (still the same)
[error] 1330#0: *90586 [lua] init.lua:371: execute(): DNS resolution failed: DNS server error: failed to send request to UDP server <IP_ADDRESS>:53: socket busy, Query Time:<PHONE_NUMBER>.111 0.000. Tried: [["cluster.address.local:SRV","DNS server error: failed to send request to UDP server <IP_ADDRESS>:53: socket busy, Query Time:<PHONE_NUMBER>.111 0.000"]], client: xxx, server: kong, request: "GET /path/to/resource", host: "xxx", request_id: "0b7dc268d13c6648f089681aa55df436"

So it might be the dns socket messed up, but currently your image has no nginx debug log enabled like --with-debug, so if you enable debug level, we could not get debug log from nginx's logic/lua-nginx-module's logic, only get the debug log from kong's lua land. Let me think of how to trace it.

Did it constantly occur if you request this request: "POST /path/to/resource HTTP/1.1", host: "xxx", request_id: "2a1bbe203f4c2a309845b0777f2b7862"?
No only sporadically. It happens even less with the dns_no_sync turned on

Did your plugin call this kind of methods: kong.service.set_target() or kong.service.set_upstream().
No we don't call any of these methods. We have a static yaml that sets those parameters

I just tried again with the latest 3.6.1-Dockerfile and now it seems to work :confused:. Strange, but I'll take it. Thanks for your support. Must be something with the dependencies I'd imagine

Because of a hunch I replaced the http dependency of our plugin with resty.http. So far we haven't had any more issues. Seems like for some reason the lua-http dependency was hogging the DNS-Socket. Not sure why that was only happening with newer versions of Kong, probably some kind of race condition. Anyways, cheers for the support

Because of a hunch I replaced the http dependency of our plugin with resty.http. So far we haven't had any more issues. Seems like for some reason the lua-http dependency was hogging the DNS-Socket. Not sure why that was only happening with newer versions of Kong, probably some kind of race condition. Anyways, cheers for the support

Hi @henrythethird could you please help what exact change did you make, how did you replaced the dependency ?
my email id-<EMAIL_ADDRESS>waiting for your reply

The http library is not suited for use with OpenResty, if combined it will result in blocking IO.

@mayank-allen
This is very specific to our project. I can give you a snippet of what I did though:
Removed
    local request = http.new_from_uri(uri)

    request.follow_redirects = false
    request.headers:upsert(header_key, key)
    request.headers:upsert(":method", "POST")

    local headers, stream = request:go(10)

Instead added

```lua
    local http_client = http.new()

    local response, err = http_client:request_uri(url, {
        method = "POST",
        path = path,
        headers = {
            [header_key] = key,
        }
    })

@Tieske it's maybe worth adding that to the documentation then (if it's not already in there). We struggled with this quite a bit.


No response

Hi,
it seems that the web service is not responding anymore.

Nope, my fault! Let's hope this is not going to happen bwt!


[Feature Request] Provide Github container registry as docker container registry

Description
Hi,
due to many docker things in the last weeks and the rate limit it would be nice, if you provide the docker image via the ghcr als github packages.
Just to have an option to pull the container from.
Thanks.
Desired Behavior
Have a docker hub alternative
Additional Context
No response
Code of Conduct

[X] I agree to follow Overseerr's Code of Conduct

I have been planning to do so too

:tada: This issue has been resolved in version 1.8.0 :tada:
The release is available on:

v1.8.0
GitHub release

Your semantic-release bot :package::rocket:


Update to MSAL 4.38.0

Update to MSAL 4.38.0

Build was run here
https://identitydivision.visualstudio.com/IDDP/_build/results?buildId=847937&view=results


Trigger update when non source code file changes

Might be a weird question, but would it trigger a refresh in the sim when a non source code file in the project is changed?
My case is to quickly see changes to a json file reflected in the simulator..
This will of cause require the modified json to be injected when changed...

No, you can use my file watcher lib to enable stuff like that


Wrong button position when using KeyboardAvoidingView in combination with SafeAreaView and autofocus

Description
I have an input with autoFocus, a SafeAreaView, and a KeyboardAvoidingView. However the Button which should have his position exactly above the keyboard gets some margin when using SafeAreaView in combination with autoFocus.
It is to mention that if I add a delay to autoFocus of around 250ms it is working as expected.
I've build an expo snack here: https://snack.expo.io/@simbob/keyboardavoidingview-bug

React Native version:
react: ~16.11.0 => 16.11.0
react-native: https://github.com/expo/react-native/archive/sdk-38.0.2.tar.gz => 0.62.2

Expected Results
Button should have the same position all time.
Steps To Reproduce
import React from "react";
import {
  StyleSheet,
  Text,
  View,
  TextInput,
  KeyboardAvoidingView,
  TouchableOpacity,
  Keyboard,
  SafeAreaView,
} from "react-native";

export default function App() {
  return (
    <SafeAreaView style={styles.container}>
      <KeyboardAvoidingView style={styles.container} behavior="padding">
        <View style={styles.top}>
          <Text>Open up App.js to start working on your app!</Text>
          <TextInput style={{ borderWidth: 1 }} autoFocus={true} />
        </View>
        <View style={styles.bottom}>
          <TouchableOpacity
            style={styles.loginScreenButton}
            onPress={Keyboard.dismiss}
          >
            <Text style={styles.loginText}>Blur</Text>
          </TouchableOpacity>
        </View>
      </KeyboardAvoidingView>
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    marginHorizontal: 16,
  },
  top: {
    flex: 0.7,
  },
  bottom: {
    flex: 0.3,
    justifyContent: "flex-end",
  },
  loginScreenButton: {
    paddingTop: 10,
    paddingBottom: 10,
    backgroundColor: "#1E6738",
    borderWidth: 1,
  },
  loginText: {
    color: "#fff",
    textAlign: "center",
  },
});

Possibly related to #29467 but the reverted changes which are mentioned there do not help.

I experience the same issue. Does anyone have a solution?

I'm on react-native 0.63.3 and still face this issue

I experience the same issue.
I can say that I see it on iOS only. It does not appear on most of the devices that I've tried. It appears on iPhone Xr.
Removing the autoFocus from the input solves the issue with the padding but introduces bad UX in my case :(

this is a really common use case. are there any workaround people have found other than removing autoFocus?

Sort-of workaround is to wrap the TextInput component and focus the input manually (based on autofocus prop) with a little timeout. This breaks the screen transition animation if navigating (with react-navigation) to the next screen which also has autofocus on an input though. Unless you increase that timeout quite a bit (like 500ms), but then the keyboard lags for a while to open after the screen transition...

Can confirm this bug still exists.
Manually focusing requires too much delay sadly.

+1
In my case it's because of react-navigation.
My workaround:
// With ref
const ref = useRef(null);
useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', () => {
      ref.current?.focus();
    });
    return unsubscribe;
}, [navigation]);

// Without ref
const [isNavMounted, setNavMounted] = useState(false);

useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', () => {
      setNavMounted(true);
    });
    return unsubscribe;
}, [navigation]);

return (
<View>{isNavMounted && <Component autoFocus={true} />}</View>
)

+1
In my case it's because of react-navigation.
My workaround:
// With ref
const insets = useSafeAreaInsets();
const headerHeight = useHeaderHeight();
const ref = useRef(null);

useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', () => {
      ref.current?.focus();
    });
    return unsubscribe;
}, [navigation]);

return (
<KeyboardAvoidingView
behavior={Platform.OS === 'ios' ? 'padding' : undefined}
keyboardVerticalOffset={headerHeight + insets.bottom}>
  <View>
    <TextInput ref={ref} />
  </View>
</KeyboardAvoidingView>
)

// Without ref (In case you can't set ref)
const insets = useSafeAreaInsets();
const headerHeight = useHeaderHeight();
const [isNavMounted, setNavMounted] = useState(false);

useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', () => {
      setNavMounted(true);
    });
    return unsubscribe;
}, [navigation]);

return (
<KeyboardAvoidingView
behavior={Platform.OS === 'ios' ? 'padding' : undefined}
keyboardVerticalOffset={headerHeight + insets.bottom}>
  <View>
    {isNavMounted && <Component autoFocus/>}
  </View>
</KeyboardAvoidingView>
)

Thank you, works like a charm!

Refactored the above to the following 2 hooks:
Hook to return transition complete based on react navigation
// Returns finished as true when transition is complete
const useScreenTransitionEnded = () => {
  const navigation = useNavigation();
  const [finished, setTransitionFinished] = useState(false);
  useEffect(() => {
    const unsubscribe = navigation.addListener('transitionEnd', () => {
      setTransitionFinished(true);
    });
    return unsubscribe;
  }, [navigation]);

  return {finished};
};

Hook to focus an input when the above returns finished
// focuses an input ref when transition is completed
const useInputFocusAfterTransition = inputRef => {
  const {finished} = useScreenTransitionEnded();
  useEffect(() => {
    if (finished && inputRef.current) {
      inputRef.current?.focus();
    }
  }, [finished]);
};

Usage

const nameRef = useRef('name');
useInputFocusAfterTransition(nameRef);

...

 <TextInput  ref={nameRef} />

Just pass the hook the input ref, it will handle all the logic and autofocus when transition is done
Thanks @oliverfrat

Still face the issue on react-native 0.66.3

Still face the issue on react-native 0.68.2
Here is the best way to handle this issue from my side:
export const useScreenTransitionEnded = () => {
  const navigation = useNavigation();

  const [isTransitionFinished, setTransitionFinished] = React.useState(false);

  React.useEffect(() => {
    const unsubscribe = navigation.addListener("transitionEnd", () => {
      setTransitionFinished(true);
    });

    return unsubscribe;
  }, [navigation]);

  return isTransitionFinished;
};

export const useKeyboardVerticalOffset = (offset = 0) => {
  const isTransitionFinished = useScreenTransitionEnded();
  const inset = useSafeAreaInsets();
  return isTransitionFinished
    ? offset + (inset.top + inset.bottom)
    : offset;
};

Usage:
const Component = () => {
  const keyboardVerticalOffset = useKeyboardVerticalOffset(64);

  return (
    <KeyboardAvoidingView keyboardVerticalOffset={keyboardVerticalOffset}>
      {/* ... */}
    </KeyboardAvoidingView>
  )
}

I've tried useInputFocusAfterTransition but there were little delay before autoFocus. In my case it was unacceptable.

This is still a (common?) issue with seemingly no good workaround. Could we have some dev input?

While the useEffect with the transitionEnded listener works, its a bit too large for my liking. I managed to solve this issue by firing the focus function using the onLayout prop. Also this error only happened with "email-address" keyboard type text inputs in my case.
<TextInput     onLayout={() => emailInputRef.current?.focus()}     textContentType="emailAddress"     keyboardType="email-address"     autoCorrect={false}     autoCapitalize="none"     ref={emailInputRef} />

https://github.com/react-navigation/react-navigation/issues/10681
https://github.com/software-mansion/react-native-screens/issues/1504
same issue. I think it is caused by react-navigation

While the useEffect with the transitionEnded listener works, its a bit too large for my liking. I managed to solve this issue by firing the focus function using the onLayout prop. Also this error only happened with "email-address" keyboard type text inputs in my case.
<TextInput
    onLayout={() => emailInputRef.current?.focus()}
    textContentType="emailAddress"
    keyboardType="email-address"
    autoCorrect={false}
    autoCapitalize="none"
    ref={emailInputRef}
/>

Bonus: the focus happens a lot faster when navigating, giving you the behavior you were looking for.

This does not consistent work from my testing. Looks like the react-navigation underlying issue makes the other workaround that uses ontransition end a more reliable solution.

Hey guys, in my specific case, I was able to fix it by using router.push() instead of <Redirect/>.
Note 1: It is an workaround, not a proper fix
Note 2: I am using expo-router, there might be an equivalent to other routers. Not sure what changed at render-level but hope to help other devs in the same circunstances.
Before
import { Redirect, usePathname } from 'expo-router'
// ...
const currentRoute = usePathname()
// ...
if (user && currentRoute !== '/name') {
  if (!user.name) return <Redirect href="/name" />
  return <Redirect href="/(app)" />
}

After
import { router, usePathname } from 'expo-router'
// ...
const currentRoute = usePathname()
// ...
if (user && currentRoute !== '/name') {
  if (!user.name) return router.push('/name')
  return router.push('/app')
}

@SimonVillage Can you remove the Stale label? As far as I know, this is still an issue

I was having the same problem. Using onLayout seemed to work for the most part, but I did experience the inconsistent behavior that @Maker-Mark was talking about, so I sought to investigate the cause behind the matter.
For iOS, the solution for me was removing padding from my KeyboardAvoidingView styles and putting it in a direct child View. Its behavior is padding, which I assumed already put some padding styles on it, so I guessed that the two could possibly be interfering, performed that fix, and it works in my app now.
For Android, using behavior='padding' seemed to cause bad flickering and using behavior='height' ironically miscalculated the appropriate height for one Stack.Screen. So a couple of Stack Overflow posts told me that Android doesn't really need to have a KeyboardAvoidingView. Instead of using conditional logic, you can just set behavior='undefined' for Android and it should function just like a regular View. So behavior={Platform.OS === 'ios' ? 'padding' : undefined} [Platform.select(...) works too].
In either case, there was no need to use keyboardVerticalOffset, which I'm very happy about. Screen sizes vary so much that I don't like its absolute nature. I haven't tested these exhaustively (only iPhone 12 and Pixel 3a simulator), but hopefully this helps.

⬆ Removing the stale label. As far as I know, this is still an issue.

Can anyone create an updated repro with only the react-native core?
ex: v0.76.3+ and with the new architecture enabled.


Fix requirements

When running bin/composer.phar install --no-dev:
PHP Fatal error:  Class 'Liip\FunctionalTestBundle\LiipFunctionalTestBundle' not found in /apps/components/engineblock/OpenConext-engineblock-5.7.0/app/AppKernel.php on line 37
It is actually a requirement

Hi Tim,
see AppKernel.php:
        if (in_array($this->getEnvironment(), array('dev', 'test'))) {
            $bundles[] = new Symfony\Bundle\DebugBundle\DebugBundle();
            $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
            $bundles[] = new Liip\FunctionalTestBundle\LiipFunctionalTestBundle();

            // own bundles
            $bundles[] = new OpenConext\EngineBlockFunctionalTestingBundle\OpenConextEngineBlockFunctionalTestingBundle();
        }

When running composer install without --no-scripts, the post-install scripts require a functioning EngineBlock. So if you use --no-dev, you must make sure you export SYMFONY_ENV=prod. For example, this should work:
SYMFONY_ENV=prod composer install --no-dev

Now that's why I shouldn't do upgrades at 1am :(
Thanks @jorissteyn !


Refactor code to use a separate Language Server

https://microsoft.github.io/language-server-protocol/

This issue was solved via pull request https://github.com/BeardedFish/vscode-robots-dot-txt-support/pull/11.


endpoint to retrieve privacy notices by data use

Partially closes #2834 (1 of 2 required endpoints)
Code Changes

new GET /api/v1/privacy-notice-by-data-use endpoint that returns a map of DataUses with their corresponding PrivacyNotices

Only DataUses that are associated with a System are included in the map.
DataUses that do not have any PrivacyNotice associated with them are included
in the map, with empty lists.

Steps to Confirm

add some Systems with privacy declarations (easiest to do thru the UI)
add some PrivacyNotices that have DataUses that overlap with the privacy declarations of your Systems (must be manual POST /api/v1/privacy-notice API calls for now)
invoke the GET /api/v1/privacy-notice-by-data-use endpoint, and ensure the result looks as expected

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[x] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

OK @pattisdr i think this one is also just about good to go, but no big rush on it!
there's a codecov miss i'm not too concerned about, although i'll try to circle back to it to provide some targeted tests on the System.get_system_data_uses() classmethod if i've got time!

Starting review..

@pattisdr i think this is ready for another look when you get a chance. i've taken your suggestion on the behavior for hierarchical overlaps - let me know if that looks correct to you!
(codecov still "fails" but doesn't even give me a concrete miss! 😒 )

looking now!