'Firmware Downgrade with SPI Rescue' question

Hi.  But before, I would like to clarify some things.
Whether I correctly understood, to downgrade the EC image, I have to download the "11.0.0 (RP1A.200720.009, Sep 2020)" image, unpack it, mount the 'vendor' partition, extract the 'ec.rec' from there and then push it to the device by means of the fastboot tool?
UPDATE: Just found that the EC version which has required bugs is in the "11.0.0 RQ1A.210105.003, Jan 2021" factory image. ec.bin from that image exposes such string:
brick_v0.0.8232-b1e3ea340 2020-09-25 16:57:52 wfrichar
which is matched to the reported one.
The log of flashing the ec image:
$ fastboot stage ec.rec
Sending 'ec.rec' (185 KB)                          OKAY [  0.119s]
Finished. Total time: 0.210s
$ fastboot oem citadel rescue
                                                   (bootloader) Recovering citadel - it may take a couple of minutes
OKAY [ 28.708s]
Finished. Total time: 28.710s

At the first glance, the image was written successfully. Are there options to verify from the userspace that the required image indeed runs?
The /vendor/bin/hw/citadel_updater command doesn't work for this purpose.
blueline:/data/local/tmp # /vendor/bin/hw/citadel_updater -l
ERROR: Unable to connect
ERROR: execute_command failed(1)!

AOSP has such comment/code:
    // Citadel info (only enabled on -eng and -userdebug builds)
    if (!PropertiesHelper::IsUserBuild()) {
        RunCommandToFd(fd, "Citadel ID", {"/vendor/bin/hw/citadel_updater", "--id"});
        RunCommandToFd(fd, "Citadel VER", {"/vendor/bin/hw/citadel_updater", "-lv"});
        RunCommandToFd(fd, "Citadel SELFTEST", {"/vendor/bin/hw/citadel_updater", "--selftest"});
    }

Could you, please, describe in more details how the firmware update based on the nugget task works. The presentation describes briefly how the firmware is updated by means of the nugget task. The unclear part is what app (from the userspace level) triggers firmware updating?
Thanks.

It seems that you were successful in downgrading the firmware. You can also check this by running:
$ fastboot oem citadel version

On userspace side, the script /vendor/bin/hw/init_citadel will try to update the firmware if the version embedded in the system in more recent (it uses citadel_updater). See my answer to issue #3 to overcome this.

 Total time: 0.086s

Ah the system updated the firmware anyway and both slot are now using the downgraded version. To use our exploit, you should run the slot A. So you need either a lower Android version (one that embed a firmware older than the one you want to downgrade to). Or simply patch your Android vendor image and rename the init_citadel script.

I will try to rename the init_citadel first as it is simpler for me to do. Does this mean the exploit is adopted for the memory addresses in the range 0x44000 - 0x70000 (I didn't learn the exploit yet as I have been trying to setup a working environment).
It is still not clear for me the concept of choosing the specific RO -> RW chain. Namely, how the BootROM choose what RO image to run (A or B). And after that whether, say, RO_A can launch RW_B image? Or RO_A can launch only RW_A but RO_B only RW_B?

Just learned the state immediately after flashing the ec.rec. Active RW_B was invalidated.
$ fastboot oem citadel version
                                                   (bootloader) Citadel version:
(bootloader) Chip:    Google Citadel C2-PVT
(bootloader) Board:   0
(bootloader) RO_A:    0.0.3/d55cc99c ok
(bootloader) RO_B:  * 0.0.3/874a9517 ok
(bootloader) RW_A:  * 0.0.3/brick_v0.0.8232-b1e3ea340 ok
(bootloader) RW_B:    Error
OKAY [  0.148s]
Finished. Total time: 0.148s

Yes, we based our exploit on RW_A image (offset ad addresses). The loaders and the bootrom will check the magic number, the version and the signature of the next image. It starts with the most recent one, and if the verification fails for some reasons, it tries the second one.

 The one thing is still unclear is whether the nugget-task based update (initiated via init_citadel) is able to activate and then jump on the just activated image when the Android was already booted up? In my case it was the RW_B image.

Yes, nugget task can update the firmware. However, this update feature will replace the magic number from the image header. The result is that the loader won't try to boot on the image. To enable the image, there is a specific nugget command that requires the user password.


TFLite MaxPool2D GPU op seems to modify source tensor

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Mac os x 10.15.4
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: Pixel 4
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): tf-nightly==2.2.0.dev20200420, also using the nightly tflite (cpu and gpu) build on android.
Python version: 3.6.10

Describe the current behavior
Here's a fun one.  When running the max pool operator on the gpu (only tested the CL delegate), the input tensor was modified.  When running the model on the cpu, it outputs the original tensor as expected.
I unfortunately don't have good code to repro on android, but the models produced in the snippet below should should the expected behavior when running on the cpu and then the gpu.
Describe the expected behavior
The input tensor is not modified when running a max pool 2d on the source tensor.
Standalone code to reproduce the issue
import tensorflow as tf
import pathlib
import numpy

def convert(model, name):
    converter = tf.lite.TFLiteConverter.from_keras_model(model)
    tflite_model = converter.convert()
    pathlib.Path(name).write_bytes(tflite_model)

inpt = tf.keras.layers.Input(shape=[256, 256, 3])
conv = tf.keras.layers.Conv2D(32, 1, padding="same")(inpt)

out = tf.keras.layers.Lambda(
    lambda x: tf.nn.max_pool2d(
        x, 16, strides=1, padding="SAME"
    )
)(conv)
model = tf.keras.Model(inpt, [conv, out])
convert(model, 'out_gpu.tflite')

# Now force this to the maxpool to run on the cpu
inpt = tf.keras.layers.Input(shape=[256, 256, 3])
conv = tf.keras.layers.Conv2D(32, 1, padding="same")(inpt)
# This op should force the tensor onto the cpu.
out = tf.where(tf.equal(conv, conv), conv, tf.zeros_like(conv))
out = tf.keras.layers.Lambda(
    lambda x: tf.nn.max_pool2d(
        x, 16, strides=1, padding="SAME"
    )
)(out)
model = tf.keras.Model(inpt, [conv, out])
convert(model, 'out_cpu.tflite')

Other info / logs
Sample output of running out_gpu.tflite on the GPU.
// conv
Row 0: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,]
// out
Row 0: [0.0029296875, 0.0029296875, 0.0029296875, 0.0029296875, 0.0029296875, 0.0029296875, 0.0029296875, 0.0029296875, -0.0087890625]

Same model, but ran on cpu only:
// conv
Row 0: [-0.23471934, -0.25280565, -0.26997373, -0.27565137, -0.2950689, -0.3190521, -0.34115076, -0.346938]
// out:
Row 0: [0.0030363789, 0.0030363789, 0.0030363789, 0.0030363789, 0.0030363789, 0.0030363789, 0.0030363789, 0.0030363789, -0.0088257985]

@jdduke @impjdi Could you confirm if this is expected or a bug?

Yeah, this may be broken unless you use the old GL delegate.  The new GPU delegate has a bug with intermediate tensors being graph output tensors.  Someone is in the process of fixing this, but I don't have an ETA.

Thanks for the response!
Which delegate are you referring to when you say old GL delegate? using the current nightly build,
I believe we saw this issue when using a phone that only had OpenGL.
Also, would you consider the tensor an output tensor if it is moving from GPU -> CPU? In the actual model we're using, the equivalent of conv is used further in the graph and gets corrupted at that step.

Old delegate: //tf/lite/delegates/gpu/gl_delegate.cc
New delegate: //tf/lite/delegates/gpu/delegate.cc
I didn't fully get what you meant by "it is moving from GPU -> CPU".  did you mean that the next op is an op not supported by the GPU, and thus moves to CPU execution?

Ah okay.
Yes that's exactly it.  I think equals isn't support? the output of the select node is messed up

Equal isn't supported, but neither are ZerosLike, Select, TopkV2 and what not.  The graph should probably fall back to CPU around there, either cut off at Logistic or MaxPool2D.  Depends on the topological sort.

Yup! From my digging it cuts off after the MaxPool2D, which causes the corruption of the maxpool's input tensor which is being passed to other tensors being ran on the cpu. (sorry having a hard time clearly putting this into words 😁)
Re your comment: "The new GPU delegate has a bug with intermediate tensors being graph output tensors."
The graph output tensor doesn't have to be the ultimate output returned to the user, correct? but can also be the output to a slice of the graph that is running on the cpu.

That is correct, it's just about the input/output tensors of the subgraph that the GPU delegate will handle.

I tried to run the code with TF v2.5 on colab & getting warning message ,please find the gist here..Thanks


Add a contributor guideline

What things you want to be in your contributor guideline

@Rishabh04-02  Thank you for volunteering to help . Looks like @dilumn already finished it .

Thanks @ransty for adding the CONTRIBUTION.md as well


⚠ AGEG website (prod) has degraded performance

In 808ef56, AGEG website (prod) (https://www.ageg.ca/) experienced degraded performance:

HTTP code: 200
Response time: 13895 ms

Resolved: AGEG website (prod) performance has improved in 9a727e4.


Temporarily disable bloom filter.

#453

Coverage increased (+0.01%) to 93.138% when pulling 6bc2e4684885bf97a3a182c2b6ddca7546ed3286 on KRuelY:disableBloom into 1f58fe92727974c97607f5310424c4e5a16a099a on cloudfoundry-incubator:master.

Coverage decreased (-0.03%) to 93.089% when pulling 77b832121bdde645463ec458613f76b740f15a74 on KRuelY:disableBloom into 1f58fe92727974c97607f5310424c4e5a16a099a on cloudfoundry-incubator:master.


How to access the monaco object of a ngx-monaco-editor?

Assume that I have an ngx-monaco-editor component inside one of my templates, how can I get the editor object to use it for example with a language client?
I'm using angular 6 and ngx-monaco-editor 6.

I use (onInit)="onInitEditor($event)". Event is editor

You can also use @ViewChild and call the component like @kostuk stated.
`
  // Your component
 import { Component , ViewChild } from "@angular/core";
 ....
 export class <yourComponent> {
 @ViewChild("editor") editor: any;

  ....
   public onInitEditor($event: any) {
    // See the editor component
     console.log(this.editor);
    }
  }

    // Your .html
     <ngx-monaco-editor #editor [options]="editorOptions" [(ngModel)]="code"
        (onInit)="onInitEditor($event)"></ngx-monaco-editor>

`


⚠ Bofrost.lu has degraded performance

In 2dfb6ef, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 829 ms

Resolved: Bofrost.lu performance has improved in b1b75fb after 6 minutes.


try to write a ObjC version of Popover, thanks

https://github.com/Assuner-Lee/PopoverObjC
Objc version of Popover (https://github.com/corin8823/Popover)

Thank you. We are expecting your library.


export Extents.extent

export Extents.extent. Addresses #757

Uggg probably DD should have the same export too

Big fan of this one, I've written Rasters.Extents.extent way to many times


Revert "Reattempt using OSBotify installation token in actions"

Straight reverts Expensify/App#28291
cc @roryabraham @justinpersaud

Not an emergency, straight revert of CI change

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/mountiny in version: 1.3.76-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.76-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/mountiny in version: 1.3.77-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.77-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


ACM-5402: Fixes problem when synchronizing informers

Related Issue
https://issues.redhat.com/browse/ACM-5402
Description of changes

The loop to poll CRDs and start the informers was blocked on initialized <- struct{}{}
Refactored the code to write to the initialized channel only once.
Minor log adjustments.

/lgtm
/hold

/lgtm

/override ci/prow/sonar-pre-submit
This PR improves test coverage, but doesn't meet the gate. Overriding gate to allow continuous improvement in this legacy project.

/unhold


Lighting reduce memory + Fix lighting not sending + Performance

This is huge.

@iam4722202468 please add me for review when this is ready

Mattw? more like mattread this pr and merge it thanks


fix: wander again

i noticed that the path creation is buggy. there are more paths in the cworld member than in trenchbroom. i think we should rethink our path list at some point.
i simplified the wander behaviour more and added a debug view. i hope that this will work now
there is again lots of formatting stuff in this pr. @michaeleggers could we talk about this again?

Do you have an example map where there are more paths added to CWorld than defined in TB? If I make two paths in TB, CWorld has two as well. I could not reproduce this error.


Draft on the changes to make the loss ignore empty batches

Changelogs

Removed the filtering of 0-losses, as they only change the logged loss, not the loss used in the bacward
Added a function for checking how many batches are empty within an accum-batch (the combination of all accumulated batches)
Added the parameter loss_empty_factor in Predictor.compute_loss

Checklist:

[x] Was this PR discussed in an issue? It is recommended to first discuss a new feature into a GitHub issue before opening a PR.
[ ] Add tests to cover the fixed bug(s) or the new introduced feature(s) (if appropriate).
[x] Update the API documentation if a new function is added, or an existing one is deleted.
[x] Write concise and explanatory changelogs above.
[ ] If possible, assign one of the following labels to the PR: feature, fix or test (or ask a maintainer to do it for you).

discussion related to that PR

The current implementation of averaging the loss for non-empty batches, implemented by @zhiyil-graphcore in PR #391  does not work. It only changes the logged metric since the loss was already passed via the backward call that happens after training_step.
The current implementation is an incomplete draft showing what needs to change in the dataloader to make it work.
The current implementation only works for IPU's, since it requires pre-loading all batches of a global-batch. Current CPU/GPU implementations load batches one at a time, which makes it much more tricky to know in advance how many batches are missing.
Not sure how much a priority this is since the problem can already be mitigated via the following measures:

For the datasets that are much larger, use a epoch_fraction_sampling that is very small, so that no dataset is entirely sparse
Consider using accumulate_grad_batches > 30, such that statistically, the number of missing batches is similar across global-batches, which means that only little noise is added

One thing I'd like to get some clarification:
We compute loss with total_loss = torch.sum(torch.stack(list(all_task_losses.values())), dim=0)
and use the sum of 5 task losses for gradient descent, is that right?
That means the probability of getting zero loss is really low?

One thing I'd like to get some clarification: We compute loss with total_loss = torch.sum(torch.stack(list(all_task_losses.values())), dim=0) and use the sum of 5 task losses for gradient descent, is that right? That means the probability of getting zero loss is really low?

You are right, not only it is unlikely, but it will simply never happen because each dataset has at least one data point per molecule. So the total loss is never 0, unless the model is perfect. So the filtering of 0 loss makes no sense

Closing, related to issue #413


Only one battery showing in Venus and frequently disconnects

Describe the bug
My Setup
Victron Cerbo GX
Victron MPPT 250|100 Solar Charge Controller
Victron Multiplus-II 48/5000/70
Battery 1 - 280AH x18s LiFePo4, Daly 150A BMS, Parralel protection board, 1A active Balancer and WNT board
Battery 2 - 280AH x18s LiFePo4, Daly 150A BMS, Parralel protection board, 1A active Balancer and WNT board
Batteries are connected in series.
dbus serial battery driver version 1.4.20240902dev (nightly release)
The Daly WNT board offers RS485, RS232 and CAN connection, Batteries are addressed via dip switches.
The issue I am having is connecting both batteries to the dbus serial driver (via RS485) at once. I have 2x USB to serial converters connected to the cerbo, they both work individually, but if you plug both in at the same time, it causes the first battery to show as disconnected, The driver does not display both modules at the same time, which is what I am hoping to achieve.
Solutions I have already tried

Alternative settings of the dip switches (all off, swapped addresses, set the same etc)
CAN-bus connection to the cerbo - again, it recognises the first battery, when connecting the second, the values change between something completely incorrect to the values of battery pack 1. I have the correct patch leads for going between cerbo and daly, have tried using the line terminator, again tried re-addressing the units ect.
have tried each RS485-USB device separately, both work individually and read correctly, but not together.
4 have NOT tried dbus driver on CAN (cant find the CAN addresses)

How to reproduce
Try to add 2x daly smart BMS in series on RS485 to driver

Expected behavior
I was expecting for the driver to displace data for both Battery 1 and Battery 2.

Driver version
1.4.20240902dev (nightly release)
Venus OS device type
Cerbo GX
Venus OS version
v3.41
BMS type
Daly Smart BMS
Cell count
18
Battery count
2
Connection type
Serial USB adapter to RS485
Config file
[DEFAULT]

; --------- Set logging level ---------
; ERROR: Only errors are logged
; WARNING: Errors and warnings are logged
; INFO: Errors, warnings and info messages are logged
; DEBUG: Errors, warnings, info and debug messages are logged
LOGGING = INFO

; --------- Battery Current limits ---------
MAX_BATTERY_CHARGE_CURRENT    = 75
MAX_BATTERY_DISCHARGE_CURRENT = 150

; --------- Cell Voltages ---------
; Description:
;     Cell min/max voltages which are used to calculate the min/max battery voltage
; Example:
;     16 cells * 3.45V/cell = 55.2V max charge voltage. 16 cells * 2.90V = 46.4V min discharge voltage
MIN_CELL_VOLTAGE   = 2.900
; Max voltage (can seen as absorption voltage)
MAX_CELL_VOLTAGE   = 3.450
; Float voltage (can be seen as resting voltage)
FLOAT_CELL_VOLTAGE = 3.375

; --------- SOC reset voltage ---------
; Description:
;     May be needed to reset the SoC to 100% once in a while for some BMS, because of SoC drift.
;     Specify the cell voltage where the SoC should be reset to 100% by the BMS.
;       - JKBMS: SoC is reset to 100% if one cell reaches OVP (over voltage protection) voltage
;     As you have to adopt this value to your system, I reccomend to start with
;     OVP voltage - 0.030 (see Example).
;       - Try to increase (add) by 0.005 in steps, if the system does not switch to float mode, even if
;         the target voltage SOC_RESET_VOLTAGE * CELL_COUNT is reached.
;       - Try to decrease (lower) by 0.005 in steps, if the system hits the OVP too fast, before all
;         cells could be balanced and the system goes into protection mode multiple times.
; Example:
;     If OVP is 3.650, then start with 3.620 and increase/decrease by 0.005
; Note:
;     The value has to be higher as the MAX_CELL_VOLTAGE
;     You also have to set CELL_VOLTAGES_WHILE_CHARGING accordingly, if you set CCCM_CV_ENABLE to true
;         else the charging current will be reduced to 0 before the target voltage is reached and the
;         battery will never switch to float
SOC_RESET_VOLTAGE = 3.650
; Specify after how many days the soc reset voltage should be reached again
; The timer is reset when the soc reset voltage is reached
; Leave empty if you don't want to use this
; Example:
;     Value is set to 15
;     day 1: soc reset reached once
;     day 16: soc reset reached twice
;     day 31: soc reset not reached since it's very cloudy
;     day 34: soc reset reached since the sun came out
;     day 49: soc reset reached again, since last time it took 3 days to reach soc reset voltage
SOC_RESET_AFTER_DAYS =

; --------- Bluetooth BMS ---------
; Description:
;     Specify the Bluetooth BMS and it's MAC address that you want to install. Leave emty to disable
; Available Bluetooth BMS:
;     Jkbms_Ble, LltJbd_Ble
; Example for one BMS:
;     BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:00:00:00
; Example for multiple BMS:
;     BLUETOOTH_BMS = Jkbms_Ble C8:47:8C:00:00:00, Jkbms_Ble C8:47:8C:00:00:11, Jkbms_Ble C8:47:8C:00:00:22
BLUETOOTH_BMS =

; --------- Bluetooth use USB ---------
; Description:  Some users reported issues to the built in bluetooth module, you can try to fix it with an USB
;     module. After a change you have to run reinstall-local.sh and to manual reboot the device!
;     The usb bluetooth module must have BLE support (bluetooth version >= 4.0)
;     Other bluetooth devices such as Ruuvi tags not tested yet.
; False: Use the built in bluetooth module
; True: Disable built in bluetooth module and try to use USB module
BLUETOOTH_USE_USB = False

; --------- CAN BMS ---------
; Description:
;     Specify the CAN port(s) where the BMS is connected to. Leave empty to disable
; Available CAN BMS:
;     Daly_Can, Jkbms_Can
; Example for one CAN port:
;     CAN_PORT = can0
; Example for multiple CAN ports:
;     CAN_PORT = can0, can8, can9
CAN_PORT =

; --------- BMS disconnect behaviour ---------
; Description:
;     Block charge and discharge when the communication to the BMS is lost. If you are removing the
;     BMS on purpose, then you have to restart the driver/system to reset the block.
; False:
;     Charge and discharge is not blocked on BMS communication loss for 20 minutes, if cell voltages are between
;     3.25 V and 3.35 V. Else the driver block charge and discharge after 60 seconds.
; True:
;     Charge and discharge is blocked on BMS communication loss, it's unblocked when connection is established
;     again or the driver/system is restarted. This is the Victron Energy default behaviour.
BLOCK_ON_DISCONNECT = False

; --------- Charge mode ---------
; Choose the mode for voltage / current limitations (True / False)
; False is a step mode: This is the default with limitations on hard boundary steps
; True is a linear mode:
;     For CCL and DCL the values between the steps are calculated for smoother values (by WaldemarFech)
;     For CVL max battery voltage is calculated dynamically in order that the max cell voltage is not exceeded
LINEAR_LIMITATION_ENABLE = True

; Specify in seconds how often the linear values should be recalculated
LINEAR_RECALCULATION_EVERY = 60
; Specify in percent when the linear values should be recalculated immediately
; Example:
;     5 for a immediate change, when the value changes by more than 5%
LINEAR_RECALCULATION_ON_PERC_CHANGE = 5

; --------- Charge Voltage limitation (affecting CVL) ---------
; Description:
;     Limit max charging voltage (MAX_CELL_VOLTAGE * cell count), switch from max voltage to float
;     voltage (FLOAT_CELL_VOLTAGE * cell count) and back
;     False: Max charging voltage is always kept
;     True: Max charging voltage is reduced based on charge mode
;         Step mode: After max voltage is reached for MAX_VOLTAGE_TIME_SEC it switches to float voltage. After
;             SoC is below SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT it switches back to max voltage.
;         Linear mode: After max voltage is reachend and cell voltage difference is smaller or equal to
;             CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL it switches to float voltage after MAX_VOLTAGE_TIME_SEC
;             additional seconds.
;             After cell voltage difference is greater or equal to CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT
;             OR
;             SoC is below SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT
;             it switches back to max voltage.
; Example when set to True:
;     Step mode:
;          The battery reached max voltage of 55.2V and hold it for 900 seconds, the the CVL is switched to
;          float voltage of 53.6V to don't stress the batteries. Allow max voltage of 55.2V again, if SoC is
;          once below 80%
;     Linear mode:
;          The battery reached max voltage of 55.2V and the max cell difference is 0.010V, then switch to float
;          voltage of 53.6V after 900 additional seconds to don't stress the batteries. Allow max voltage of
;          55.2V again if max cell difference is above 0.080V or SoC below 80%.
; Charge voltage control management enable (True/False).
CVCM_ENABLE = True

; -- CVL reset based on cell voltage diff (linear mode)
; Specify cell voltage diff where CVL limit is kept until diff is equal or lower
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL        = 0.010
; Specify cell voltage diff where MAX_VOLTAGE_TIME_SEC restarts if diff is bigger
CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_TIME_RESTART = 0.013
; Specify cell voltage diff where CVL limit is reset to max voltage, if value get above
; the cells are considered as imbalanced, if the cell diff exceeds 5% of the nominal cell voltage
; e.g. 3.2 V * 5 / 100 = 0.160 V
CELL_VOLTAGE_DIFF_TO_RESET_VOLTAGE_LIMIT        = 0.080

; -- CVL reset based on SoC option (step mode & linear mode)
; Specify how long the max voltage should be kept
;     Step mode: If reached then switch to float voltage
;     Linear mode: If cells are balanced keep max voltage for further MAX_VOLTAGE_TIME_SEC seconds
MAX_VOLTAGE_TIME_SEC = 900
; Specify SoC where CVL limit is reset to max voltage
;     Step mode: If SoC gets below
;     Linear mode: If cells are unbalanced or if SoC gets below
SOC_LEVEL_TO_RESET_VOLTAGE_LIMIT = 80

; --------- SOC calculation ---------
; Description:
;     Calculate the SOC in the driver. Do not use the SOC reported by the BMS
; SOC_CALCULATION:
;     True: Calc SOC in the driver, do not use SOC reported from BMS
;         - The SOC is calculated by integration of the current reported by the BMS
;         - The current reported from the BMS can be corrected by
;           the map (SOC_CALC_CURRENT_REPORTED_BY_BMS, SOC_CALC_CURRENT_MEASURED_BY_USER)
;         - The SOC is set to 100% if the following conditions apply for at least SOC_RESET_TIME seconds:
;             * Current is lower than SOC_RESET_CURRENT amps
;             * Sum of cell voltages >= self.max_battery_voltage - VOLTAGE_DROP
;         - The calculated SOC is stored in dbus to persist a driver restart
;     False: Use SOC reported from BMS (none of the other parameters apply)
; More info: https://github.com/Louisvdw/dbus-serialbattery/pull/868
SOC_CALCULATION   = False
SOC_RESET_CURRENT = 7
SOC_RESET_TIME    = 60
SOC_CALC_CURRENT_REPORTED_BY_BMS  = -300, 300
SOC_CALC_CURRENT_MEASURED_BY_USER = -300, 300
; Example to set small currents to zero
;     SOC_CALC_CURRENT_REPORTED_BY_BMS  = -300, -0.5, 0.5, 300
;     SOC_CALC_CURRENT_MEASURED_BY_USER = -300,    0,   0, 300

; --------- Cell Voltage Current limitation (affecting CCL/DCL) ---------
; Description: Maximal charge / discharge current will be in-/decreased depending on min and max cell voltages
; Example:
;     18 cells * 3.55V/cell = 63.9V max charge voltage
;     18 cells * 2.70V/cell = 48.6V min discharge voltage
;     But in reality not all cells reach the same voltage at the same time. The (dis)charge current
;     will be (in-/)decreased, if even ONE SINGLE BATTERY CELL reaches the limits

; Charge current control management referring to cell-voltage enable (True/False).
CCCM_CV_ENABLE = True
; Discharge current control management referring to cell-voltage enable (True/False).
DCCM_CV_ENABLE = True

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
CELL_VOLTAGES_WHILE_CHARGING      = 3.55, 3.50, 3.45, 3.30
MAX_CHARGE_CURRENT_CV_FRACTION    =    0, 0.05,  0.5,    1

CELL_VOLTAGES_WHILE_DISCHARGING   = 2.70, 2.80, 2.90, 3.10
MAX_DISCHARGE_CURRENT_CV_FRACTION =    0,  0.1,  0.5,    1

; --------- Cell Voltage limitation (affecting CVL) ---------
; This function prevents a bad balanced battery to overcharge the cell with the highest voltage and the bms to
; switch off because of overvoltage of this cell.
;
; Example:
;     15 cells are at 3.4v, 1 cell is at 3.6v. Total voltage of battery is 54.6v and the Victron System sees no reason to
;     lower the charging current as the control_voltage (Absorbtion Voltage) ist 55.2v
;     In this case the Cell Voltage limitation kicks in and lowers the control_voltage to keep it close to the MAX_CELL_VOLTAGE.
;
; In theory this can also be done with CCL, but doing it with CVL has 2 advantages:
;     - In a well balanced system the current can be kept quite high till the end of charge by using MAX_CELL_VOLTAGE for charging.
;     - In systems with MPPTs and DC-feed-in activated the victron systems do not respect CCL, so CVL is the only way to prevent the
;       highest cell in a bad balanced system from overcharging.
;
; There are 2 methods implemented to calculate CVL:
;   1. penalty_sum-Method (CVL_ICONTROLLER_MODE = False)
;      The voltage-overshoot of all cells that exceed MAX_CELL_VOLTAGE is summed up and the control voltage is lowered by this "penalty_sum".
;      This is calculated every LINEAR_RECALCULATION_EVERY seconds.
;      In fact, this is a P-Controller.
;   2. I-Controller (CVL_ICONTROLLER_MODE = True)
;      An I-Controller tries to control the voltage of the highest cell to MAX_CELL_VOLTAGE + CELL_VOLTAGE_DIFF_KEEP_MAX_VOLTAGE_UNTIL.
;      (for example 3.45V+0.01V =3.46V). If the voltage of the highest cell is above this level, CVL is reduced. If the voltage is below, CVL is
;      increased until cellcount*MAX_CELL_VOLTAGE.
;      An I-Part of 0.2 V/Vs (CVL_ICONTROLLER_FACTOR) has proved to be a stable and fast controlling-behaviour.
;      This method is not as fast as the penalty_sum-Method but usually smoother and more stable against toggeling and has no stationary deviation.
; More info: https://github.com/Louisvdw/dbus-serialbattery/pull/882
CVL_ICONTROLLER_MODE   = False
CVL_ICONTROLLER_FACTOR = 0.2

; --------- Temperature limitation (affecting CCL/DCL) ---------
; Description:
;     Maximal charge / discharge current will be in-/decreased depending on temperature
; Example:
;     The temperature limit will be monitored to control the currents. If there are two temperature senors,
;     then the worst case will be calculated and the more secure lower current will be set.
; Charge current control management referring to temperature enable (True/False).
CCCM_T_ENABLE = True
; Charge current control management referring to temperature enable (True/False).
DCCM_T_ENABLE = True

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
TEMPERATURES_WHILE_CHARGING      =    0,    2,    5,   10,   15,   20,   35,   40,   55
MAX_CHARGE_CURRENT_T_FRACTION    = 0.00, 0.10, 0.20, 0.40, 0.80, 1.00, 1.00, 0.40, 0.00

TEMPERATURES_WHILE_DISCHARGING   =  -20,    0,    5,   10,   15,   45,   55
MAX_DISCHARGE_CURRENT_T_FRACTION = 0.00, 0.20, 0.30, 0.40, 1.00, 1.00, 0.00

; --------- SOC limitation (affecting CCL/DCL) ---------
; Description:
;     Maximal charge / discharge current will be increased / decreased depending on State of Charge
;     Since the SoC is not as accurate as the cell voltage, this option is disabled by default
; Example:
;     The SoC limit will be monitored to control the currents.
; Charge current control management enable (True/False).
CCCM_SOC_ENABLE = False
; Discharge current control management enable (True/False).
DCCM_SOC_ENABLE = False

; Set steps to reduce battery current
; The current will be changed linear between those steps if LINEAR_LIMITATION_ENABLE is set to True
SOC_WHILE_CHARGING                 =   98,   95,   90,   85
MAX_CHARGE_CURRENT_SOC_FRACTION    = 0.10, 0.20, 0.50, 1.00

SOC_WHILE_DISCHARGING              =    5,   10,   15,   20
MAX_DISCHARGE_CURRENT_SOC_FRACTION = 0.10, 0.20, 0.50, 1.00

; --------- Time-To-Go ---------
; Description:
;     Calculates the time to go shown in the GUI
;     Recalculation is done based on TIME_TO_SOC_RECALCULATE_EVERY
TIME_TO_GO_ENABLE = True

; --------- Time-To-Soc ---------
; Description:
;     Calculates the time to a specific SoC
; Example:
;     TIME_TO_SOC_POINTS = 50, 25, 15, 0
;     6h 24m remaining until 50% SoC
;     17h 36m remaining until 25% SoC
;     22h 5m remaining until 15% SoC
;     28h 48m remaining until 0% SoC
; Set of SoC percentages to report on dbus and MQTT. The more you specify the more it will impact system performance.
; [Valid values 0-100, comma separated list. More that 20 intervals are not recommended]
; Example: TIME_TO_SOC_POINTS = 100, 95, 90, 85, 75, 50, 25, 20, 10, 0
; Leave empty to disable
TIME_TO_SOC_POINTS =
; Specify TimeToSoc value type [Valid values 1, 2, 3]
; 1 Seconds
; 2 Time string <days>d <hours>h <minutes>m <seconds>s
; 3 Both seconds and time string "<seconds> [<days>d <hours>h <minutes>m <seconds>s]"
TIME_TO_SOC_VALUE_TYPE = 1
; Specify in seconds how often the TimeToSoc should be recalculated
; Minimum are 5 seconds to prevent CPU overload
TIME_TO_SOC_RECALCULATE_EVERY = 60
; Include TimeToSoC points when moving away from the SoC point [Valid values True, False]
; These will be as negative time. Disabling this improves performance slightly
TIME_TO_SOC_INC_FROM = False

; --------- Additional settings ---------
; Specify one or more BMS types to load else leave empty to try to load all available
; Available BMS:
;     Daly, Ecs, HeltecModbus, HLPdataBMS4S, Jkbms, Lifepower, LltJbd, Renogy, Seplos
; Available BMS, but disabled by default (just enter one or more below and it will be enabled):
;     ANT, MNB, Sinowealth
BMS_TYPE = Daly

; Exclute this serial devices from the driver startup
; Example:
;     /dev/ttyUSB2, /dev/ttyUSB4
EXCLUDED_DEVICES =

; Auto reset SoC
; If on, then SoC is reset to 100%, if the value switches from absorption to float voltage
; Currently only working for Daly BMS and JKBMS BLE
AUTO_RESET_SOC = True

; Publish the config settings to the dbus path "/Info/Config/"
PUBLISH_CONFIG_VALUES = True

; Select the format of cell data presented on dbus [Valid values 0,1,2,3]
; 0 Do not publish all the cells (only the min/max cell data as used by the default GX)
; 1 Format: /Voltages/Cell (also available for display on Remote Console)
; 2 Format: /Cell/#/Volts
; 3 Both formats 1 and 2
BATTERY_CELL_DATA_FORMAT = 1

; Simulate Midpoint graph (True/False).
MIDPOINT_ENABLE = False

; Battery temperature
; Specify how the battery temperature is assembled
; 0 Get mean of temperature sensor 1 to sensor 4
; 1 Get only temperature from temperature sensor 1
; 2 Get only temperature from temperature sensor 2
; 3 Get only temperature from temperature sensor 3
; 4 Get only temperature from temperature sensor 4
TEMP_BATTERY = 0

; Temperature sensor 1 name
TEMP_1_NAME = Temp 1

; Temperature sensor 2 name
TEMP_2_NAME = Temp 2

; Temperature sensor 2 name
TEMP_3_NAME = Temp 3

; Temperature sensor 2 name
TEMP_4_NAME = Temp 4

; --------- BMS specific settings ---------

; -- LltJbd settings
; SoC low levels
; Note:
;     SOC_LOW_WARNING is also used to calculate the Time-To-Go even if you are not using a LltJbd BMS
SOC_LOW_WARNING = 20
SOC_LOW_ALARM   = 10

; -- Daly settings
; Battery capacity (amps), if the BMS does not support reading it
BATTERY_CAPACITY = 50
; Invert Battery Current. Default non-inverted. Set to -1 to invert
INVERT_CURRENT_MEASUREMENT = 1

; -- JKBMS settings
; Predefines cell count for Jkbms_can
; The cell count should be auto-detected by identifying the highest cell number,
; but this process may be sometimes slow what could cause that cells voltage is not not
; updated in VenusOS. Try this workaround if you experience problems with cell voltage.
JKBMS_CAN_CELL_COUNT = 1

; -- ESC GreenMeter and Lipro device settings
GREENMETER_ADDRESS  = 1
LIPRO_START_ADDRESS = 2
LIPRO_END_ADDRESS   = 4
LIPRO_CELL_COUNT    = 15

; -- HeltecModbus (Heltec SmartBMS/YYBMS) settings
; Set the Modbus addresses from the adapters
; Separate each address to check by a comma like: 1, 2, 3, ...
; factory default address will be 1
HELTEC_MODBUS_ADDR = 1

; --------- Voltage drop ---------
; If you have a voltage drop between the BMS and the charger because of wire size or length
; then you can specify the voltage drop here. The driver will then add the voltage drop
; to the calculated CVL to compensate.
; Example:
;     cell count: 16
;     MAX_CELL_VOLTAGE = 3.45
;     max voltage calculated = 16 * 3.45 = 55.20
;     CVL is set to 55.20 V and the battery is now charged until the charger reaches 55.20 V.
;     The BMS now measures 55.05 V since there is a voltage drop of 0.15 V on the cable.
;     Since the dbus-serialbattery reads the voltage of 55.05 V from the BMS the max voltage
;     of 55.20 V is never reached and max voltage is kept forever.
;     By setting the VOLTAGE_DROP to 0.15 V the voltage on the charger is increased and the
;     target voltage on the BMS is reached.
VOLTAGE_DROP = 0.00

Relevant log output
@4000000066e1549813e78714 *** CCGX booted (0) ***
@4000000066e154983237a104 *** starting serial-starter ***
@4000000066e154991ae619cc serstart starting
@4000000066e154991c35daec INFO: loading config file /etc/venus/serial-starter.conf
@4000000066e1549a18ea97ec INFO: loading config file /data/conf/serial-starter.d/dbus-serialbattery.conf
@4000000066e1549b317f8434 INFO: Create daemontools service mk2-dbus.ttyS4
@4000000066e1549d1396464c INFO: Create daemontools service vedirect-interface.ttyS5
@4000000066e1549e351516a4 INFO: Create daemontools service vedirect-interface.ttyS6
@4000000066e154a01b8900ec INFO: Create daemontools service vedirect-interface.ttyS7
@4000000066e154a205fc1cb4 INFO: Start service mk2-dbus.ttyS4
@4000000066e154a2205f6444 INFO: Create daemontools service dbus-serialbattery.ttyUSB0
@4000000066e154a32214ad94 INFO: Start service vedirect-interface.ttyS5
@4000000066e154a42d9e98b4 INFO: Create daemontools service dbus-serialbattery.ttyUSB1
@4000000066e154a506aaf66c INFO: Start service vedirect-interface.ttyS6
@4000000066e154a6287a4824 INFO: Start service vedirect-interface.ttyS7
@4000000066e154a835c9a934 INFO: Start service dbus-serialbattery.ttyUSB0 once
@4000000066e154aa3791cabc INFO: Start service dbus-serialbattery.ttyUSB1 once
@4000000066e154ad28b5b314 INFO: Create daemontools service gps-dbus.ttyUSB0
@4000000066e154b013ab31c4 INFO: Create daemontools service gps-dbus.ttyUSB1
@4000000066e154b33b567f94 INFO: Start service gps-dbus.ttyUSB0 once
@4000000066e154b623ca21dc INFO: Start service gps-dbus.ttyUSB1 once
@4000000066e154bf0d4f10fc INFO: Create daemontools service vedirect-interface.ttyUSB0
@4000000066e154c11503e3f4 INFO: Create daemontools service vedirect-interface.ttyUSB1
@4000000066e154c51b2495e4 INFO: Start service vedirect-interface.ttyUSB0 once
@4000000066e154c722d8fb7c INFO: Start service vedirect-interface.ttyUSB1 once
@4000000066e154cb39423dc4 INFO: Create daemontools service dbus-cgwacs.ttyUSB0
@4000000066e154cd2a8dca8c INFO: Create daemontools service dbus-cgwacs.ttyUSB1
@4000000066e154d20b21ff9c INFO: Start service dbus-cgwacs.ttyUSB0 once
@4000000066e154d334da99fc INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e154d50fe2f2ac INFO: Create daemontools service dbus-fzsonick-48tl.ttyUSB0
@4000000066e154d8283dcbc4 INFO: Create daemontools service dbus-fzsonick-48tl.ttyUSB1
@4000000066e154db174a0f1c INFO: Start service dbus-fzsonick-48tl.ttyUSB0 once
@4000000066e154de2c44060c INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
@4000000066e154e03a5e3ce4 INFO: Create daemontools service dbus-imt-si-rs485tc.ttyUSB0
@4000000066e154e705ce1774 INFO: Start service dbus-imt-si-rs485tc.ttyUSB0 once
@4000000066e154e7083e503c INFO: Create daemontools service dbus-imt-si-rs485tc.ttyUSB1
@4000000066e154ed14da573c INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
@4000000066e154ef1628051c INFO: Create daemontools service dbus-modbus-client.serial.ttyUSB0
@4000000066e154f51ffcaad4 INFO: Start service dbus-modbus-client.serial.ttyUSB0 once
@4000000066e154f525a6159c INFO: Create daemontools service dbus-modbus-client.serial.ttyUSB1
@4000000066e154fb2c7c34dc INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
@4000000066e154ff241119d4 INFO: Start service dbus-serialbattery.ttyUSB0 once
@4000000066e1550237a696f4 INFO: Start service dbus-serialbattery.ttyUSB1 once
@4000000066e155243a7e4804 INFO: Start service gps-dbus.ttyUSB1 once
@4000000066e1552e2f84257c INFO: Start service vedirect-interface.ttyUSB1 once
@4000000066e155341039c924 INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e155611426e9a4 *** CCGX booted (0) ***
@4000000066e1556133de2514 *** starting serial-starter ***
@4000000066e155621b9bfc4c serstart starting
@4000000066e155621b9bfc4c serstart starting
@4000000066e155621c0e9ff4 INFO: loading config file /etc/venus/serial-starter.conf
@4000000066e1556316cfdddc INFO: loading config file /data/conf/serial-starter.d/dbus-serialbattery.conf
@4000000066e155642ed98d9c INFO: Create daemontools service mk2-dbus.ttyS4
@4000000066e155660cc34bbc INFO: Create daemontools service vedirect-interface.ttyS5
@4000000066e155672e385814 INFO: Create daemontools service vedirect-interface.ttyS6
@4000000066e15569154e27ac INFO: Create daemontools service vedirect-interface.ttyS7
@4000000066e1556a3b734e94 INFO: Start service mk2-dbus.ttyS4
@4000000066e1556b1df482ac INFO: Create daemontools service dbus-serialbattery.ttyUSB0
@4000000066e1556c1bdd3784 INFO: Start service vedirect-interface.ttyS5
@4000000066e1556d2c239d2c INFO: Create daemontools service dbus-cgwacs.ttyUSB1
@4000000066e1556d36bb15e4 INFO: Start service vedirect-interface.ttyS6
@4000000066e1556f1eae7054 INFO: Start service vedirect-interface.ttyS7
@4000000066e155712c0d1f5c INFO: Start service dbus-serialbattery.ttyUSB0 once
@4000000066e155733ae50c9c INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e15576185126ac INFO: Create daemontools service gps-dbus.ttyUSB0
@4000000066e1557908ddf36c INFO: Create daemontools service dbus-fzsonick-48tl.ttyUSB1
@4000000066e1557c29a18244 INFO: Start service gps-dbus.ttyUSB0 once
@4000000066e1557f172ac74c INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
@4000000066e1558803479f5c INFO: Create daemontools service vedirect-interface.ttyUSB0
@4000000066e1558c1d156964 INFO: Create daemontools service dbus-imt-si-rs485tc.ttyUSB1
@4000000066e1558e0dee8934 INFO: Start service vedirect-interface.ttyUSB0 once
@4000000066e1559228a501a4 INFO: Create daemontools service dbus-cgwacs.ttyUSB0
@4000000066e155922ba9a684 INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
@4000000066e1559835b6bd74 INFO: Start service dbus-cgwacs.ttyUSB0 once
@4000000066e1559a1403a64c INFO: Create daemontools service dbus-modbus-client.serial.ttyUSB1
@4000000066e1559d2ae5f4dc INFO: Create daemontools service dbus-fzsonick-48tl.ttyUSB0
@4000000066e155a01858817c INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
@4000000066e155a32f2cf144 INFO: Start service dbus-fzsonick-48tl.ttyUSB0 once
@4000000066e155aa09ffedcc INFO: Create daemontools service dbus-serialbattery.ttyUSB1
@4000000066e155ad2a67e36c INFO: Create daemontools service dbus-imt-si-rs485tc.ttyUSB0
@4000000066e155b014bad0ec INFO: Start service dbus-serialbattery.ttyUSB1 once
@4000000066e155b3321e21ac INFO: Start service dbus-imt-si-rs485tc.ttyUSB0 once
@4000000066e155b929f8702c INFO: Create daemontools service dbus-modbus-client.serial.ttyUSB0
@4000000066e155bf2fce3e3c INFO: Start service dbus-modbus-client.serial.ttyUSB0 once
@4000000066e155c91728f674 INFO: Start service dbus-serialbattery.ttyUSB0 once
@4000000066e155cc30163034 INFO: Create daemontools service gps-dbus.ttyUSB1
@4000000066e155d23363c8dc INFO: Start service gps-dbus.ttyUSB1 once
@4000000066e155dc17af9b34 INFO: Create daemontools service vedirect-interface.ttyUSB1
@4000000066e155e21a64c46c INFO: Start service vedirect-interface.ttyUSB1 once
@4000000066e155e80bf9d584 INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e155ed38a0930c INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
@4000000066e155f30f6137bc INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
@4000000066e155f701306ba4 INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
@4000000066e15621395e41a4 INFO: Start service vedirect-interface.ttyUSB1 once
@4000000066e156270f4cbd8c INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e1562a23faea24 INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
@4000000066e1562e0fb25944 INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
@4000000066e1563126ef182c INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
@4000000066e1563901b89704 INFO: Start service dbus-serialbattery.ttyUSB1 once
@4000000066e156921acfc6f4 INFO: Start service gps-dbus.ttyUSB1 once
@4000000066e1569c1809bd6c INFO: Start service vedirect-interface.ttyUSB1 once
@4000000066e156a2026b3594 INFO: Start service dbus-cgwacs.ttyUSB1 once
@4000000066e156a915abeb94 INFO: Start service dbus-fzsonick-48tl.ttyUSB1 once
@4000000066e156ae308c2b54 INFO: Start service dbus-imt-si-rs485tc.ttyUSB1 once
@4000000066e156b408ac2954 INFO: Start service dbus-modbus-client.serial.ttyUSB1 once
@4000000066e156bd20f0f1fc INFO: Start service dbus-serialbattery.ttyUSB1 once

@4000000066e154e5218a5b6c INFO:SerialBattery:========== Settings ==========
@4000000066e154e52198846c INFO:SerialBattery:> Connection voltage: 60.0 V | Current: 0.0 A | SoC: 85.8%
@4000000066e154e521a54224 INFO:SerialBattery:> Cell count: 18 | Cells populated: 0
@4000000066e154e521b11194 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
@4000000066e154e52277a96c INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.375 V
@4000000066e154e522844bcc INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 75.0 A | MAX BATTERY DISCHARGE CURRENT: 150.0 A
@4000000066e154e522a3e98c INFO:SerialBattery:> CVCM:     True
@4000000066e154e522f3885c INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
@4000000066e154e522f3a79c INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
@4000000066e154e522f3b354 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
@4000000066e154e522fadf44 INFO:SerialBattery:> CHARGE FET: None | DISCHARGE FET: None | BALANCE FET: None
@4000000066e154e52306e564 INFO:SerialBattery:Serial Number/Unique Identifier: 20230708
@4000000066e154f90230ef9c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e154f91932a154 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e154f91a31ae4c WARNING:SerialBattery:Polling took too long. Set to 2.000 s
@4000000066e154f93501dcc4 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e154fa107518bc INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e154fb0139ed3c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e154fb1855ba8c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e154fc1290d884 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e154fd0fcd576c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e154fd270069c4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155351d52d7f4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155372183b064 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155610b89dd74 *** CCGX booted (0) ***
@4000000066e155931299e8d4 INFO:SerialBattery:
@4000000066e1559312a87b4c INFO:SerialBattery:Starting dbus-serialbattery
@4000000066e1559314fec374 INFO:SerialBattery:Venus OS v3.41
@4000000066e15593154123a4 INFO:SerialBattery:dbus-serialbattery v1.4.20240902dev
@4000000066e155a31684cf04 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
@4000000066e155a31691466c INFO:SerialBattery:Testing Daly at address "\x40"
@4000000066e155a332fb3754 INFO:SerialBattery:Connection established to Daly
@4000000066e155a82a8dd644 INFO:SerialBattery:Found existing battery with DeviceInstance = 1
@4000000066e155a907e1344c INFO:SerialBattery:DeviceInstance = 1
@4000000066e155a90805276c INFO:SerialBattery:PID file created successfully: /var/tmp/dbus-serialbattery_1.pid
@4000000066e155a908177304 INFO:SerialBattery:Used DeviceInstances = ['2', '1']
@4000000066e155a9084b776c INFO:SerialBattery:com.victronenergy.battery.ttyUSB0__0
@4000000066e155a90f530ebc INFO:SerialBattery:publish config values = False
@4000000066e155a911f55404 INFO:SerialBattery:Polling data every 1.000 s
@4000000066e155a9121be31c INFO:SerialBattery:Battery Daly connected to dbus from /dev/ttyUSB0
@4000000066e155a912b2ef14 INFO:SerialBattery:========== Settings ==========
@4000000066e155a913026ea4 INFO:SerialBattery:> Connection voltage: 60.1 V | Current: -0.06 A | SoC: 86.0%
@4000000066e155a913127fec INFO:SerialBattery:> Cell count: 18 | Cells populated: 0
@4000000066e155a913219b1c INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
@4000000066e155a9133142ec INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.375 V
@4000000066e155a91374666c INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 75.0 A | MAX BATTERY DISCHARGE CURRENT: 150.0 A
@4000000066e155a913856dcc INFO:SerialBattery:> CVCM:     True
@4000000066e155a913967144 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
@4000000066e155a913a6152c INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
@4000000066e155a913b76aac INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
@4000000066e155a9143652f4 INFO:SerialBattery:> CHARGE FET: None | DISCHARGE FET: None | BALANCE FET: None
@4000000066e155a9144cffa4 INFO:SerialBattery:Serial Number/Unique Identifier: 20230708
@4000000066e155b908110294 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155b90d80d344 WARNING:SerialBattery:Polling took too long. Set to 3.000 s
@4000000066e155c326240bb4 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155c3392fc34c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155c43a400a6c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155c515ac0ad4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155c53120223c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155c60cba2bcc INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155c70d059864 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155c7242b29b4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155ca07b50f84 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155ca1c5da66c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155e91e465014 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155ea1a2cdbec INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155eb237f074c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e155f008510d1c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e155f022431c4c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156151398cad4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a213545b4c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e156a227c0912c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a32394a28c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a430657914 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a5301983c4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a62670c83c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156a713d80e24 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e156a735e1c12c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156ba3704b58c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e156d4018bf924 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e1574f2b7a553c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e1575004712b3c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e157510ea6e09c INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e15765057149a4 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e157653b652d64 WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e1576618ab25bc INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e157670e1ca1fc INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.
@4000000066e1576735b2642c WARNING:SerialBattery:No data received in read_alarm_data()
@4000000066e157680e3c4b74 INFO:SerialBattery:refresh_data: result: False. If you don't see this warning very often, you can ignore it.

Any other information that may be helpful
Nil

Hello, this is only one log, of one battery/serial adapter. Please post both logs.

Hi Louis,There is only one log in that location? Is there another location for the other log? Thanks, Nick On 11 Sep 2024, at 17:16, Manuel @.***> wrote:
Hello, this is only one log, of one battery/serial adapter. Please post both logs.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Hi Nick, I'm not Louis. You can find everything in the documentation: https://mr-manuel.github.io/venus-os_dbus-serialbattery_docs/troubleshoot/#datalogdbus-serialbatteryttyusbcurrent-or-datalogdbus-serialbatteryttyama0current


[BUG] Search for items with cyrillic titles dosnt work

Environment
Self-Hosted (Docker)
System
Google chrome 117.0.5938.152,  Ubuntu 22.04.3 LTS , Docker 24.0.6
Version
2.1.1
Describe the problem
After adding new items with cyrillic title, can`t search for them after.
Seach with not cyrillic titles works normal.
Additional info
No response
Please tick the boxes

[X] You have explained the issue clearly, and included all relevant info
[X] You are using a supported version of Dashy
[X] You've checked that this issue hasn't already been raised
[X] You've checked the docs and troubleshooting guide
[X] You agree to the code of conduct

This should now be fixed, thanks Denior


[BUG] bulk ignoring more than one operation

What is the bug?
Firstly thanks for maintaining the library folks!
The bug I found is related to the bulk call that performs multiple operations, possibly on different indices.
How can one reproduce the bug?
Implement your onDocument callback to return more than one operation. Below example with upserting data to two different indices.

client.helpers.bulk({
  datasource: [{ id: '1234', someField: 1, maybeAnotherField: 0 }],
  onDocument (document) {
    return [
      {
        update: { _id: document.id, _index: 'index_a' }
      },
      {
        doc: { someField: document.someField },
        doc_as_upsert: true
      },
      {
        update: { _id: document.id, _index: 'index_b' }
      },
      {
        doc: { maybeAnotherField: document.maybeAnotherField },
        doc_as_upsert: true
      }
    ]
  }
})

What is the expected behavior?
Expected behaviour is that both index_a and index_b are updated, however the library is making bulk requests to only the first index.
The OpenSearch API allows you to specify different operations to different indices. I've tested this manually through curl to confirm and can attach example request if needed.
What is your host/environment?
OS: Ubuntu 22.04 x86_64
node: v18.13.0
opensearch-js: 2.3.1
Do you have any screenshots?
n/a
Do you have any additional context?
The bug is caused by assumption that you will perform just one operation, see this line.
Please take a look and let me know what do you think.

Looks legit. Want to try to write a unit test that reproduces this? Maybe a fix? :)

Sure, I can do this in spare time. For my personal patch fix I've just added iteration over all { action, payload } pairs and it does the job. I just need to cover edge cases, for example: what if user uses odd number of elements in the array.

Is this issue something we are still looking to fix? I can work on creating the unit test for this.

Hi @AbhinavGarg90! Sure, unit tests would be super helpful! Here's the patch I mentioned before.
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index a648aea..09e689b 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -530,28 +530,36 @@ class Helpers {
         if (shouldAbort === true) break;
         timeoutRef.refresh();
         const result = onDocument(chunk);
-        const [action, payload] = Array.isArray(result) ? result : [result, chunk];
-        const operation = Object.keys(action)[0];
-        if (operation === 'index' || operation === 'create') {
-          actionBody = serializer.serialize(action);
-          payloadBody = typeof payload === 'string' ? payload : serializer.serialize(payload);
-          chunkBytes += Buffer.byteLength(actionBody) + Buffer.byteLength(payloadBody);
-          bulkBody.push(actionBody, payloadBody);
-        } else if (operation === 'update') {
-          actionBody = serializer.serialize(action);
-          payloadBody =
-            typeof chunk === 'string'
-              ? `{"doc":${chunk}}`
-              : serializer.serialize({ doc: chunk, ...payload });
-          chunkBytes += Buffer.byteLength(actionBody) + Buffer.byteLength(payloadBody);
-          bulkBody.push(actionBody, payloadBody);
-        } else if (operation === 'delete') {
-          actionBody = serializer.serialize(action);
-          chunkBytes += Buffer.byteLength(actionBody);
-          bulkBody.push(actionBody);
-        } else {
-          clearTimeout(timeoutRef);
-          throw new ConfigurationError(`Bulk helper invalid action: '${operation}'`);
+
+        // This is temporary patch to support multiple operations, instead of just one.
+        // https://github.com/opensearch-project/opensearch-js/issues/593
+        for (let i = 0; i < result.length - 1; i = i + 2) {
+          const action = result[i]
+          const payload = result[i + 1]
+
+          const operation = Object.keys(action)[0];
+          if (operation === 'index' || operation === 'create') {
+            actionBody = serializer.serialize(action);
+            payloadBody = typeof payload === 'string' ? payload : serializer.serialize(payload);
+            chunkBytes += Buffer.byteLength(actionBody) + Buffer.byteLength(payloadBody);
+            bulkBody.push(actionBody, payloadBody);
+          } else if (operation === 'update') {
+            actionBody = serializer.serialize(action);
+            payloadBody =
+              typeof chunk === 'string'
+                ? `{"doc":${chunk}}`
+                : serializer.serialize({ doc: chunk, ...payload });
+            chunkBytes += Buffer.byteLength(actionBody) + Buffer.byteLength(payloadBody);
+            bulkBody.push(actionBody, payloadBody);
+          } else if (operation === 'delete') {
+            actionBody = serializer.serialize(action);
+            chunkBytes += Buffer.byteLength(actionBody);
+            bulkBody.push(actionBody);
+          } else {
+            clearTimeout(timeoutRef);
+            throw new ConfigurationError(`Bulk helper invalid action: '${operation}'`);
+          }
+
         }

         if (chunkBytes >= flushBytes) {

Thanks, I'll look into this and make the PR.


Podfile 内开启 use_frameworks! 后编译失败

flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Mac OS X 10.14.4 18E226, locale zh-Hans-CN)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
[✓] iOS tools - develop for iOS devices
[✓] Android Studio (version 3.4)
[✓] VS Code (version 1.32.3)
[✓] Connected device (2 available)

• No issues found!

编译错误信息：
Showing All Messages
ld: framework not found zegoliveroom_plugin

已修复。


SDC umbra 1.5.0

what's the path for the blockchain?
shadowcash umbra platform.

on which OS? it hasn't changed, we figured best to leave it where it is for now.
%appdata%/shadowcoin on windows I believe, ~/.shadowcoin on linux and ~/Library/Application\ Support/ShadowCoin on OSX

https://slack.shadowproject.io || https://shadowproject.slack.com

On OSX it's ~/Users//Library/Application Support/Shadowcoin/


Build for arm64

What feature you'd like to add:
a build for arm64 (kubernetes.io/arch=arm64) would be great to have.
Why is this feature needed:
increasing availability on providers

JuiceFS CSI Driver support arm64. You can refer to https://github.com/juicedata/juicefs-csi-driver/blob/master/docs/en/csi-in-arm64.md

thanks. saw the arch appearing with tag v0.11.1

@zwwhdls please reopen, does not work on oracle cloud with exec format error. I even pulled the specific digest for arm64 of v0.13.0. seems like the buildbot is broken

0.11.1 seems working

@stevefan1999-personal THX for reporting, I create a new issue : https://github.com/juicedata/juicefs-csi-driver/issues/284

Hi @stevefan1999-personal , v0.13.1 is released, fixing tini in Dockerfile (https://github.com/juicedata/juicefs-csi-driver/pull/285). You can have a try.


Fix stacktraces compilation issues

Drop linux/limits.h, we don't use it anyway. Also, do not require backtrace lib when enable_stacktraces=no.
Should fix #2720

This now includes two fixes, see PR description/individual commits.


feature request: change default for -f

It would be nice if one could change the default template used for a given command that has the -f option (hub pr list, hub ci-status).
For example, we typically want to do pr list - but we almost always want to get the pr url which is not in the default.  It would be nice if I could override the default format used by setting a value in the config file.  (-f would still override the default)

Good idea! An old issue #964 proposed exactly something like this: a way to specify default flags for a command. In that thread we also talked about the possibility to specify default flags per-repo (i.e. only in the current project) and globally (i.e. for any hub commands run for the current system user).
The reason why that issue is still open is because I haven't had time to dive into implementing this feature, but it's definitely on our roadmap. I will close this in favor of the referenced issue.


Is there any documentation for this plugin and how to configure them (there is nothing in the Wiki either)

As the title says. I'm curious how people are actually settings this up to their liking without any documentation.
Are people reading the source code and figuring things out?

There is plenty of documentation, did you try :h cmp from inside Neovim?
Alternatively you can read it online in the repo https://github.com/hrsh7th/nvim-cmp/blob/main/doc/cmp.txt

There is plenty of documentation, did you try :h cmp from inside Neovim? Alternatively you can read it online in the repo https://github.com/hrsh7th/nvim-cmp/blob/main/doc/cmp.txt

@bew
Superb!! To be honest, I didn't even think about it because it lacked Wiki and I couldn't find any reference pointing to the help.
Perhaps fix the README and the Wiki links?

README.md

https://github.com/hrsh7th/nvim-cmp

vimhelp

https://github.com/hrsh7th/nvim-cmp/blob/main/doc/cmp.txt
:help cmp

Community Tips (Wiki)

https://github.com/hrsh7th/nvim-cmp/wiki

GitHub Discussion

https://github.com/hrsh7th/nvim-cmp/discussions


Trouble querying the accumulator manually

From the code it looks like the accumulator can be queried with a request to /rates/{timestamp} however I seem to only get 404s:
$ http http://<IP_ADDRESS>:8080/rates/1513971645  Authorization:"$(cat ~/.cf/config.json | jq -r .AccessToken)"
HTTP/1.1 404 Not Found
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Fri, 22 Dec 2017 19:49:20 GMT

I can see that when I call the accumulator it is making the requests to the nozzles:
2017/12/22 19:23:53 Server bound to <IP_ADDRESS>:8080
<IP_ADDRESS> - - [22/Dec/2017:19:41:30 +0000] "GET /rates/1513971199 HTTP/1.1" 404 0
<IP_ADDRESS> - - [22/Dec/2017:19:44:55 +0000] "GET /rates/1513971645 HTTP/1.1" 404 0
<IP_ADDRESS> - - [22/Dec/2017:19:45:45 +0000] "GET /rates/1513971645 HTTP/1.1" 404 0
<IP_ADDRESS> - - [22/Dec/2017:19:47:26 +0000] "GET /rates/1513971645 HTTP/1.1" 404 0
<IP_ADDRESS> - - [22/Dec/2017:19:49:19 +0000] "GET /rates/1513971645 HTTP/1.1" 404 0
<IP_ADDRESS> - - [22/Dec/2017:19:55:16 +0000] "GET /rates/1513971645 HTTP/1.1" 404 0

Hey @j-kaplan,
Sorry we are lacking documentation on this so far.
The nozzle will collect log and store rates by the minute by default. Every minute it takes the log rates and stores them in an in memory store. Rates are retained for 1 hour by default. To query the rates the timestamp your timestamp should be truncated to the minute. For example, your timestamp,<PHONE_NUMBER> is Friday, December 22, 2017 7:40:45 PM, instead you should query for<PHONE_NUMBER> which is  Friday, December 22, 2017 7:40:00 PM.
Also keep in mind that when you have multiple nozzles deployed, they can have different timestamps, so we recommend querying for rates ~1.5 minutes ago (truncated of course to the nearest minute of course)
If the accumulator was to automatically truncate your timestamp for you would you find this helpful or more confusing?


#1504 Icon overlaps the last column of query result

Description

워크벤치 쿼리 결과에서 마지막 row 의 마지막 column 값이 확인 불가함
Related Issue : #1504

How Has This Been Tested?

워크벤치에서 쿼리 실행합니다.
쿼리 결과가 표시된 후 스크롤을 제일 아래로 내렸을 떄 아이콘 이미지가 숨겨지는지 ( 흐릿하게 ) 확인합니다.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project. it will be added soon
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document. it will be added soon
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Additional Context

run build
deploy to 2

@metatron-app/design @AnnieHwang plz review this pr

@eltriny I do not know if the build is working properly. But I think the modified function does not work.

@kyungtaak 수정했습니다.

run build
deploy to 2

run build
deploy to 2


Human readable summary?

Hi!
First of all, thank you for creating this comprehensive package! It looks very clean and even includes i18n.
However, I'm looking for a convenient way to convert raw METAR and TAF to human readable format just like https://www.metar-taf-decoder.com/ do. I want to integrate it into my telegram bot.
I'm currently using METAR and pytaf packages, but I have to install both and write some customized code to display additional things like airport name etc. into their summary. I wonder if there is a easy way or some example code to achieve the same thing here. What the other two packages does is basically this. It is a very common functionality, so I expect this package should have a similar method to get a summary. Not sure if anyone have the same need, but it seems to be very common. Could you please provide some sample code to construct a summary based on parsed objects?
If such functionality is not available at the moment but PR welcome, I may find some time to draft a PR. No guarantee when I will have some time. Might be months from now.
Thank you!

Hello @jqqqqqqqqqq
Thank you for your interest in the project.
The website https://www.metar-taf-decoder.com/ uses the java  version of the project and the frontend is a angular application.
I do not directly use the string representation of METAR and TAF objects but the objects attributes and a template from the angular application.
Implementing a toString method was in my TODO list for this project. I may have a local branch for it but I never finished the work.
I can implement  a__str__ method to match the toString version of the java project

Yes, the current code and readme only presents the "parsing" of METAR and TAF, but we need a little doc on object hierarchy and organisation and how to get the information out of the parsed structure. Otherwise, the parallel between METAR and TAF is very well abstracted in the hierarchy.
Thank you.

@jqqqqqqqqqq I opened a PR to fix the issue.


Main window stopped responding

My cat walked on my keyboard, somehow this triggered a change in layout where the feed name and item title were on top of each other instead of side-by-side. I wanted to go back to my regular view so, my first attempt was to restart Vienna, but now it seems soft-locked :(
The process runs, no windows open, but I can get to the menu. Window -> Main Window shows me the main window, but it's empty - I thought maybe "all my settings got nuked somehow" but adding a new folder / feed doesn't help either. It looks like the basic structure of the window is fine but it's disconnected from the database somehow?

I've tried moving ~/Library/Application Support/Vienna to Vienna.bak and restarting, but that doesn't seem to have helped. Are there settings stored somewhere else too?

Hi @shish I should be able to help, but first I'm going to need to see a photo of the cat that did this.
Thanks!

Here she is, returning to the scene of the crime~ Unfortunately while randomly mashing keyboard shortcuts appears to have caused the problem, further random keyboard mashing didn't fix it :(

defaults delete -app Vienna said Can't determine domain name for application Vienna; defaults unchanged - but I fiddled around using that command as a starting point, and defaults delete uk.co.opencommunity.vienna2 worked :)
Before doing a reset I exported the broken settings, in case there's something in here that helps to figure out which edge case I hit - https://gist.github.com/shish/ae4046ae0805618353ad33e480a54d25

Oh that's annoying - I had originally prepared the defaults delete uk.co.opencommunity.vienna2 but when I was reading the man page for defaults I saw the -app Vienna version and tried it out and it worked too.
Thanks for sharing the settings! I'll take a proper look this week.

Also just noticed: while the UI and the database appeared to be disconnected, I tried using the "new folder" button to see if any new content would be visible. It didn't help, but now that things are working again, I see that the folder is there. So the database is connected, just something in those settings made everything (tree of feeds, list of items, preview pane) invisible at once.


Implement Bjorn for indel flagging with help from Andersen lab

In addition to current indel flag based on pairwise alignments, implement Bjorn with help from Andersen lab to provide needed outputs for manual review.
From: "Laurent, Louise"
Date: Thursday, March 18, 2021 at 11:21 AM
Subject: Re: Indel flag and Pangolin calls
Hi All,
A few adjustments to the below, based on Kristian's input on this morning's 10 am call -- pending Katie/Amanda checking with Karthik and Al that these fit what Bjorn does:
[snip]

Bjorn outputs A new manual_review_flagged column will be added to the summary csv files.  Any sample whose id is returned by line 40 of the github gkarthik/tabulate_variants.py script will have its manual_review_flagged value set to TRUE. All other samples will have their manual_review_flagged value set to FALSE. UCSD folks to "observe" Al/Karthik running Bjorn to understand nitty gritty of steps/settings.

[snip]

We will of course retain the pairwise alignments as part of the CCBB pipeline process, but I think we should drop the actual indel_flagged value from our code’s output since it is no longer deemed useful.

Current plan is Andersen lab will run bjorn, at least for first data release. As both bjorn and Niema's plans with respect to indels and alignments are changing fairly rapidly, this should be on hold for now until that plan stabilizes since it is not on our critical path to data release.


Linting errors for useCopyToClipboard

Maby I'm doing something wrong, but I'm getting unsafe linting errors when using the useCopyToClipboard hook.

Can you provide a codesandbox?

I'm getting a violation of no-unsafe-call with useOnClickOutside as well

Hi! Thanks for the feedback.
I added the recommended stricter  @typescript-eslint presets here #450 to prevent this kind of issue. It'll be released in the week.
I will close this issue due to both inactivity and missing bug reproduction.
Feel free to re-open or create a new issue if the problem reappears.


ADRIFT 4 Sophie's Adventure doesn't work in Parchment

https://ifdb.org/viewgame?id=clpc8d5s70z8v63j
https://iplayif.com/?story=https%3A%2F%2Fifarchive.org%2Fif-archive%2Fgames%2Fcompetition2003%2Fadrift%2Fsophie%2Fsophie.taf

Glk SCARE Error
Unable to load an Adrift game from the requested file.

IFDB is configured to link to https://play.adrift.co/?game=http%3A%2F%2Fwww.ifarchive.org%2Fif-archive%2Fgames%2Fcompetition2003%2Fadrift%2Fsophie%2Fsophie.taf to play this game online, which works, but it would be great to fix Parchment.
If we can get Parchment playing ADRIFT 4 games reliably, we might then switch IFDB's ADRIFT 4 online player to Parchment. https://github.com/iftechfoundation/ifdb/issues/1223

It doesn't work in Gargoyle either.

I've filed that as https://github.com/garglk/garglk/issues/910

Definitely a SCARE error but cool if those of you who make multi-interpreters can solve it anyway. :D - slightly related, would it be possible to start an ADRIFT 4 game with an automatic command?


Implement SE-0112: Improved NSError bridging

What's in this pull request?
This pull request implements SE-0112
Resolved bug number: (rdar://problem/27174964)

It looks like this PR might address several other open issues on bugs.swift.org. I'll scrub those as well.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci please test and merge

@swift-ci please test and merge

@swift-ci please test and merge


Remove gem fastly-rails

The gem "fastly-rails" does not work on Rails 6, so we
must eliminate it to upgrade to Rails 6.
They recommend switching to the "fastly" gem (aka "fastly-ruby"),
but fastly-ruby is not designed to support multi-threading (WHAT?!).
The only workable solution I could find was to modify our code
to directly call the Fastly API instead.
This turned out to be more complicated than expected, and
frankly was a big pain. However, this is a blocker to upgrading
Rails, and the version of Rails we use is no longer supported,
so this needed to be done.
We need to test this on the real system to ensure that it really works.
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

The only way to really test this is to merge it, unfortunately, so that's what I'm going to do.

The only way to really test this is to merge it, unfortunately, so that's what I'm going to do.


Expanding terminal window makes lines disappear from terminal output

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.66.2
OS Version: Windows 11

Steps to Reproduce:

In VS Code terminal run a program that prints numbers from 1 to 20; each number on its own line
2. The height of the terminal panel should be about 8 lines long
3. Scroll the output to make sure all numbers got printed
Expand the terminal window by clicking [^] button on the right size of the terminal panel's title
Scroll the terminal and observe that the numbers disappeared from the output

Video demonstrating the weird behavior: https://user-images.githubusercontent.com/958706/163682945-8edf5183-1d39-4be3-bf02-d66c0f9b950a.mp4 This video shows the issue in its simplest form; it can also take more advanced forms if there was already text present in the terminal beforehand.
This behavior might be especially harmful for the beginner programmers because they might think that their program is coded wrong if they see lines missing from the terminal output.

/duplicate #134448


DBZ-7272 Guarding against implicit offset invalidation

https://issues.redhat.com/browse/DBZ-7272

@jcechace Applied, thanks


Create deploy-lambda in GitHub actions

Incomplete
Closes #24
Description
Created a GitHub Action using .github/workflows yml file. This Action is triggered when changes are pushed to my issue branch ab-24.  The Action deploys the code to the aws lambda function that was created.
Testing

Creates actions in GitHub Actions which runs when a change is pushed to the ab-24 branch

Action does not successfully run !!

Hi @Annelisebx, I noticed that the node_modules are included in your PR. The node_modules usually aren't included in PRs since it makes it hard to notice any changes that you've added in your PR, and the node_modules also add to the project file size. How to gitignore node_modules

I removed a lot of folders and the PR is down to 6 files. I think only the one file I created/updated needs to be included. Can I delete the 5 other files directly from this PR and I can pull them again from development branch?

I removed a lot of folders and the PR is down to 6 files. I think only the one file I created/updated needs to be included. Can I delete the 5 other files directly from this PR and I can pull them again from development branch?

Your commit history shows the deletes, I am not sure if this will mess up the development branch.  For our group, we closed the original PR, started a new branch based off of the current development branch, and added our relevant files to the new branch. We copied and pasted the old PR info into new ones. We didn't want there to be a history of deletes.

Besides the changes and requests Kristin and Courtney mentioned.
I believe, and I base this on the github action I too had to create, but I think you need to add the development branch under current branch for this action to still work once your branch is pushed into development (line 8).

great catch, thank you

Closing pull request. See new PR 65


It doesn't converse faster when I set the parameter(batch_size) to a number greater than one.

Describe the bug
It doesn't converse faster when I set the parameter(batch_size) to a number greater than one.
To Reproduce
Steps to reproduce the behavior:
e.g.

Run cells in video_to_slomo.py
Set batch_size to a number greater than one.
Error/Abnormal behavior: It uses more memory of cuda but doesn't converse faster.

Expected behavior
It can really converse faster.
Interpolated results/error output
Add frames or terminal output as applicable.
Desktop (please complete the following information):

OS:  Windows
Device Used GPU
Setup Info [e.g. PyTorch 0.4.1, Python 3.6, ]

Additional context
The utilization rate of the gpu <10%.(with Quadro P6000)

I have not tested that feature yet. Also, though I am not sure but when you use GPU, saving the image might become a bottleneck as I have to save every image one by one.


add more tests on the modem

Codecov Report

Merging #28 into master will increase coverage by 5.52%.
The diff coverage is 69.23%.

@@            Coverage Diff             @@
##           master      #28      +/-   ##
==========================================
+ Coverage   60.67%   66.19%   +5.52%
==========================================
  Files           4        4
  Lines         417      423       +6
==========================================
+ Hits          253      280      +27
+ Misses        150      121      -29
- Partials       14       22       +8

Impacted Files
Coverage Δ

pkg/modem/modem.go
53.68% <69.23%> (+26.71%)
:arrow_up:

Continue to review full report at Codecov.

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


Add nrfconnect switch app in build targets script

Fixes #23450 Missing nrfconnect light-switch app in NRF builder
I would add nrfconnect light-switch app in NRF builder to be able to build it with the global script.

Thanks


Missing Egl Support Error

Hello I Am Fairly Familiar With Linux But There Is An Error I'm Getting When I Try Install Any Release. When I Tried To Download Debian Stretch With A Target Of Kde The Installation Runs And Then I Get An Error, And If I Try Updating It Gives The Same. The Error Is "unity target does not work in xephyr in trusty due to missing egl support." I Am Using A Samsung Chromebook With An ARMV7 Processor. (V71)
Please Respond ASAP.
Thanks Ahead Of Time

The Command I Run is sudo sh ~/Downloads/crouton -r stretch -t kde -n debian

@Linux-Distros - Try Using The 'xiwi' Xmethod/Target:

When Installing: sudo sh ~/Downloads/crouton -r stretch -t xiwi,kde -n debian
After Installing: sudo sh ~/Downloads/crouton -t xiwi -n debian -u

ok ill try

ill get back to you when its done or whatever happens.

the download finished now im running the update...

it has worked, thanks for the help! :smile:

btw is there anyway to speed up the performance? its kinda of laggy

Cool!
I'm sorry, I should have ben more clear about the instructions though.
You only needed to do the 'After Install ...' part if you already had it installed without the 'xiwi' target.
No harm done though...

@Linux-Distros,

btw is there anyway to speed up the performance? its kinda of laggy

Unfortunately no, that's the one drawbck with 'xiwi', there's no hardware acceleration - yet...

ok thanks


versions: Bump to kernel 4.19.10

We need to bump the kernel version from 4.14.67 to 4.19.10 in order
to follow the recent kernel config bump.
Fixes #1029
Signed-off-by: Sebastien Boeuf<EMAIL_ADDRESS>

/test

@jodh-intel updated!

@sboeuf - commit comment references .10, but the file change is still showing as .9?

@jodh-intel I forgot to modify it... Fixed now :)

lgtm

lgtm

Ping @kata-containers/runtime - Happy New Year'n'all! Please review this ;)

LGTM. Adding do-not-merge as it depends on kata-containers/packaging/pull/288

Need to be merged together? or merge  kata-containers/packaging#288 firstly?


Investigate and fix the update_plugin_versions.py script

The script does not perform proper version updates when running against post releases
To reproduce the issue

Set the plugin version to 1.28.0.post1 on plugins/aea-cli-ipfs/setup.py:31 and deploy-image/Dockerfile:19
Run python scripts/update_plugin_versions.py --update "open-aea-cli-ipfs,1.29.0"

This bumps the version to 1.29.0 in the setup.py but in the Dockerfile it updates the version to 1.29.0.post1

@angrybayblade
the problem - is manual edit of the docker file.
bump from 1.28.0 to 1.28.0.post1 makes line RUN pip install --upgrade --force-reinstall open-aea[all]==1.28.0.post1 "open-aea-cli-ipfs<2.0.0,>=1.28.0"
not RUN pip install --upgrade --force-reinstall open-aea[all]==1.28.0.post1 "open-aea-cli-ipfs<2.0.0,>=1.28.0.post1"
and it's ok to the algo.
looks .post1 was added manually that caused script problems


Sentry JWKS validator: add support for passing root CA certs

Allows fetching a JWKS from a HTTPS server that uses a custom CA certificate

Moving to v1.14 milestone as we are beyond v1.13 feature freeze and imminently going into code freeze.

This is a P0 for Microsoft for 1.13. It's only 5 LOCs if you exclude tests.

@ItalyPaleAle this has not been discussed with the project more widely and cannot be pushed through without consensus. Please create an issue as to why we need an exception to be included and the bug this is fixing. New features will not be accepted at this stage.

@ItalyPaleAle this has not been discussed with the project more widely and cannot be pushed through without consensus. Please create an issue as to why we need an exception to be included and the bug this is fixing. New features will not be accepted at this stage.

@mukundansundar is aware and agreed.
Reason is pretty self-evident and it's related to security, we need to set the CA cert for when fetching a JWKS from a HTTPS endpoint. It's required for security otherwise the only option is HTTP, which doesn't allow authenticating the origin server, so the JWKS could be spoofed.

Thank you @yaron2.
I agree that sooner would have been better. We didn't realize this was needed this till yesterday.

I agree to accept this change. I also recommend vendors to use internal fork to have their urgent needs met without the need to workaround the OSS release process.


Spike: T2 meets SCS

We'd like to be able to deploy to SCS (https://scs.community/).
Once we have credentials for a testbed this can be worked on.
SCS is backed by OpenStack.

Sorry @lfrancke, I didn't see this ticket when I created #131. I close this one.