text:
Add essential ValueSets

We need some valuesets to support the profiles
Minimal CSV should look like :

code
system
designation

---
---
----

More advanced code systems can include things like languages:

code
system
designation
language 1
designation in language 1
language N
designation in language N

---
---
----
----
----
----
----

and/or hierarchies, polyhierarchies:

code
system
designation
property type (e.g. "is parent of")
property value (e.g. the code of the parent)

---
---
----
----
----

(properties can be relations to other codes, or text, or dates,...

Just looking at this makes me want to go to sleep.
I'll have to wait until my motivation gets shipped.

if we need valuesets, this is how we make them. This, or manually editing XMLs according to the spec

if we need valuesets, this is how we make them. This, or manually editing XMLs according to the spec

I'm still not an idiot, José. Just lazy.

Which is why I recommend the CSVs, I am more experienced at being lazy
On Thu, Nov 3, 2022 at 2:50 PM rlindstrm @.***> wrote:

if we need valuesets, this is how we make them. This, or manually editing
XMLs according to the spec
I'm still not an idiot, José. Just lazy.
—
Reply to this email directly, view it on GitHub
https://github.com/hl7-eu/unicom-ig/issues/32#issuecomment-1302144745,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HUUFCVE2RM4PDFG54WR3WGO7JPANCNFSM6AAAAAARWEELQI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Two/three value sets I need to unblock my profiling:
1) Authorised Dose Form
Combines four SPOR lists (they are also separate like this in EDQM). Note, that all SPOR lists are basically separate code systems in FHIR.

Pharmaceutical Dose Form   | https://spor.ema.europa.eu/rmswi/#/lists/200000000004/terms
Combined Pharmaceutical Dose Form   | https://spor.ema.europa.eu/rmswi/#/lists/200000000006/terms
Combined Term   | https://spor.ema.europa.eu/rmswi/#/lists/200000000007/terms
Combination Package   | https://spor.ema.europa.eu/rmswi/#/lists/200000000008/terms

2) Unit of Measurement and Unit of Presentation.
If I can bind two value sets to one element, then I'd keep them separately.
It's only the presentation strength denominator, where the unit can be either one or the other (60mg/0.6ml or 60mg/vial would both be considered presentation strength if the vial is 0.6ml)

Unit of Presentation   |  https://spor.ema.europa.eu/rmswi/#/lists/200000000014/terms
Units of Measurement | https://spor.ema.europa.eu/rmswi/#/lists/100000110633/terms

I believe others need these value sets, too. They're pretty essential.
There are many other SPOR lists, but those I can define as system.value and save myself from handling too many value sets.
And now you tell me to send you the codes... I'll get there. One step at the time. I need a nap now.

Two/three value sets I need to unblock my profiling: 1) Authorised Dose Form Combines four SPOR lists (they are also separate like this in EDQM). Note, that all SPOR lists are basically separate code systems in FHIR.

Pharmaceutical Dose Form   | https://spor.ema.europa.eu/rmswi/#/lists/200000000004/terms
Combined Pharmaceutical Dose Form   | https://spor.ema.europa.eu/rmswi/#/lists/200000000006/terms
Combined Term   | https://spor.ema.europa.eu/rmswi/#/lists/200000000007/terms
Combination Package   | https://spor.ema.europa.eu/rmswi/#/lists/200000000008/terms

2) Unit of Measurement and Unit of Presentation. If I can bind two value sets to one element, then I'd keep them separately. It's only the presentation strength denominator, where the unit can be either one or the other (60mg/0.6ml or 60mg/vial would both be considered presentation strength if the vial is 0.6ml)

Unit of Presentation   |  https://spor.ema.europa.eu/rmswi/#/lists/200000000014/terms
Units of Measurement | https://spor.ema.europa.eu/rmswi/#/lists/100000110633/terms

I believe others need these value sets, too. They're pretty essential. There are many other SPOR lists, but those I can define as system.value and save myself from handling too many value sets.
And now you tell me to send you the codes... I'll get there. One step at the time. I need a nap now.

Shouldn't be a problem, you can find the valuesets at this links (normally works, for some reasons RMS is down right now):

Pharmaceutical Dose Form
Combined Pharmaceutical Dose Form
Combined Term
Combination Package
Unit Of Presentation
Units of Measurement

You need to register and login in order to visualize this valuesets.

Can anyone make CSVs?
On Thu, Nov 3, 2022 at 4:57 PM Francesco Galisi @.***>
wrote:

Two/three value sets I need to unblock my profiling: 1) Authorised Dose
Form Combines four SPOR lists (they are also separate like this in
EDQM). Note, that all SPOR lists are basically separate code systems in
FHIR.

Pharmaceutical Dose Form |
https://spor.ema.europa.eu/rmswi/#/lists/200000000004/terms
Combined Pharmaceutical Dose Form |
https://spor.ema.europa.eu/rmswi/#/lists/200000000006/terms
Combined Term |
https://spor.ema.europa.eu/rmswi/#/lists/200000000007/terms
Combination Package |
https://spor.ema.europa.eu/rmswi/#/lists/200000000008/terms

2) Unit of Measurement and Unit of Presentation. If I can bind two
value sets to one element, then I'd keep them separately. It's only the
presentation strength denominator, where the unit can be either one or the
other (60mg/0.6ml or 60mg/vial would both be considered presentation
strength if the vial is 0.6ml)

Unit of Presentation |
https://spor.ema.europa.eu/rmswi/#/lists/200000000014/terms
Units of Measurement |
https://spor.ema.europa.eu/rmswi/#/lists/100000110633/terms

I believe others need these value sets, too. They're pretty essential.
There are many other SPOR lists, but those I can define as system.value and
save myself from handling too many value sets.
And now you tell me to send you the codes... I'll get there. One step at
the time. I need a nap now.
Shouldn't be a problem, you can find the valuesets at this links (normally
works, for some reasons RMS is down right now):

Pharmaceutical Dose Form
https://spor.ema.europa.eu/v1/lists/200000000004
Combined Pharmaceutical Dose Form
https://spor.ema.europa.eu/v1/lists/200000000006
Combined Term https://spor.ema.europa.eu/v1/lists/200000000007
Combination Package
https://spor.ema.europa.eu/v1/lists/200000000008
Unit Of Presentation
https://spor.ema.europa.eu/v1/lists/200000000014
Units of Measurement
https://spor.ema.europa.eu/v1/lists/100000110633

You need to register and login in order to visualize this valuesets.
—
Reply to this email directly, view it on GitHub
https://github.com/hl7-eu/unicom-ig/issues/32#issuecomment-1302324403,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HUUFDKTTI46XPBAENLN3WGPOGBANCNFSM6AAAAAARWEELQI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Can anyone make CSVs?

EMA SPOR is down. Time to get a life.

Robert suggests 2 more value sets:

Substances with role of PAI - we only have the codes for 35 substances
Moiety - we only have the codes for 35 substances
ATC

For dose form,
Giorgio suggests that we look at eHDSI to see if they are aligned / overlapping. Question: EDQM or SPOR?
We agree to start with EDQM. The ValueSet / CodeSystem is available.
Assignees:

Pharmaceutical Dose Form (FG)
Combined Pharmaceutical Dose Form (FG)
Combined Term (FG)
Combination Package (FG)
Unit Of Presentation (FG)
Units of Measurement (FG)
ATC (GC)
Substances (PAI And moiety) (RVS + FG)

Substances with role of PAI - we only have the codes for 35 substances
Moiety - we only have the codes for 35 substances
ATC

What is PAI? Primary active ingredient?
As far as I know, you cannot differentiate active ingredients, moieties or excipience in SMS value set. All you get is a value set of 50 000 concepts (available in eHDSI, not the newest version but should work ok). Role of the substance is defined in medication data.
eHDSI ATC and EDQM value sets should be ok, we included combination package dose forms quite recently. But they don't have SPOR codes.
Unit of Measurement in eHDSI and SPOR have slight differences, which I'd like to have a rant about.

Thank Giorgio
This being in the hands of HL7 and since it is in the terminology server,
perhaps we can do it intensionally.
Agree?
On Fri, Nov 4, 2022 at 2:26 PM Giorgio Cangioli @.***>
wrote:

Assignees:
<...>

ATC (GC)

The ATC code system in FHIR can be get from here
https://github.com/FHIR/packages/blob/master/packages/fhir.tx.support.r4/package/CodeSystem-atc.json
let's decide then if it should be an intensional or extensional value
set....
—
Reply to this email directly, view it on GitHub
https://github.com/hl7-eu/unicom-ig/issues/32#issuecomment-1303538656,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HUUGNP23MT44RHBVGQY3WGUFJHANCNFSM6AAAAAARWEELQI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Agree?

It seems to be a version that is 2 years old, but the big changes took place in 2020 and seem to be in. Ok for piloting, but they should really update it every year.
And EMA uses SPOR codes instead of ATC codes. Just saying, and hoping you would understand and document how this will be a problem one day:

This was my idea as well. Define the value set intentionally makes it independent from the version (it is a matter of expansion)
We can reuse this value set https://build.fhir.org/ig/HL7/fhir-ips/ValueSet-whoatc-uv-ips.html or just copy the content and have it in our guide as a new value set

What is PAI? Primary active ingredient?
As far as I know, you cannot differentiate active ingredients, moieties or excipience in SMS value set. All you get is a value set of 50 000 concepts (available in eHDSI, not the newest version but should work ok). Role of the substance is defined in medication data.

PAI is for Precise Active Ingredient. If I understood correctly, a substance has the role of Precise Active Ingredient when it's used as the only ingredient of a ManufacturedItem. I agree with you that it makes no sense to have a valueset for that since IDMP has the "role" attribute inside Ingredient.

<..> i would copy the content of the IPS to our IG so that we can mess with it as we want. If you agree, do you want to do it?

added https://build.fhir.org/ig/hl7-eu/unicom-ig/ValueSet-whoatc-unicom.html

I just realised, that some of the RMS value sets I need are defined in 5.0.0 Ballot resources as Example value sets (they were not there for Snapshot, not sure when they appeared).
Anyway.. Some are clearly incomplete and useless, some might be usable. How would I go about them? Can I use them as value sets or should I just steal the content and define my own?
For example, they have in specification:
http://hl7.org/fhir/2022Sep/codesystem-legal-status-of-supply.html
And EMA has defined it at some point as:
https://spor.ema.europa.eu/rmswi/#/lists/100000072051/terms | Legal Status of Supply
EMA does not have their lists published in FHIR format, and I'm a little confused which value set and code system I would use for profiles - the Example one that exists, or the official one that doesn't?

Maturity level 1, Trial use, Any context, Case sensitive (!).
And no indication that the codes are from EMA SPOR RMS.
https://build.fhir.org/codesystem-unit-of-presentation.html
https://build.fhir.org/codesystem-administrable-dose-form.html
Please help me understand what to make of this.

The HL7 community could not publish EMA valusets because they were not
openly available (strategy miss from EMA, IMO. They could have the FHIR
world looking at their values if they had presented those ValueSets).
And the FHIR specs are always expected to have some value set for codeable
elements. This was not there in R5.0.0-snapshot*1 *(we should get used to
say snapshot1, because in a few weeks there'll be a snapshot2). So
R5.0.0-ballot fixed that by adding any value sets just to give some
examples.
The binding strength is example so everyone can use different valuesets.
In practice: Just create new ones, stealing as you need.
On Sat, Nov 5, 2022 at 5:08 PM Rutt Lindström @.***>
wrote:

Maturity level 1, Trial use, Any context, Case sensitive (!).
And no indication that the codes are from EMA SPOR RMS.
https://build.fhir.org/codesystem-unit-of-presentation.html
https://build.fhir.org/codesystem-administrable-dose-form.html
Please help me understand what to make of this.
—
Reply to this email directly, view it on GitHub
https://github.com/hl7-eu/unicom-ig/issues/32#issuecomment-1304574415,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HUUCMPDYZYXGJVS7Q5X3WG2A6RANCNFSM6AAAAAARWEELQI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thanks @Censacrof
I had a different approach (from CSVs) but what matters is to have the valuesets.
We can perhaps put this in a branch to get it validated - we need to see where. For this, 2 remarks:

I guess these are the "original" EMA ones - we had decided for using the "global" codes. We can use the different slices for the regulatory part, and perhaps for the MAL?
@rlindstrm I think you are the best to validate if these code systems pass the smell test, once we publish them in the IG - and hopefully you can advise where we use them (I presume in the corresponding slices in the profiles)

@costateixeira These are EDQM ones, not EMA.
Looks pretty advanced, @Censacrof  :)

@costateixeira These are EDQM ones, not EMA. Looks pretty advanced, @Censacrof :)

@rlindstrm yep, these are only the EDQM ones, all of them, even the ones that we probably won't need. This was my first time working with SUSHI, please let me know if I need to change or improve anything.

Thanks @Censacrof I had a different approach (from CSVs) but what matters is to have the valuesets. We can perhaps put this in a branch to get it validated - we need to see where.

I branched from master but I think that GitHub allows you to merge my pull request in a new branch if you want.

UCUM in eHDSI

11/11 Francesco has done all the valuesets except UCUM - will get the info from Rutt's comment above.
Robert will continue with Substances
José will merge Giorgio's ATC values

I also added the CodingSystem for the UcumUnits to the pull request #36 . Please, review it so that we can merge it.

UCUM in eHDSI
I also have the whole value set catalogue in Excel, if you need. Contains EMA SMS codes as well.

Thanks! I think that will be useful to create a mapping between UCUM and Spor

MVC_610-ainult-ravimid-20220706.xlsx
This is eHDSI master value set catalogue for wave 6. This file only contains prescription-specific value sets.
UCUM-SPOR mappings are theoretically present in RMS Unit of Measurement list, not too easy to extract, but I think you'll manage (I know I wouldn't).

Robert's value set for PPL substances with mappings and divisions into categories (see different sheets) SubtancesCodeTemplate_RVS_V5.xlsx
Some SMS codes are missing from the file, but I can see they exist in the eHDSISubstance value set based on SMS, so I think this won't be a problem.
The email discussion was about if this value set can be created and maintained for production use. At this point it cannot, so we have to keep an eye on SRS, SMS and SNOMED developments.

Which code do we stick to in the ValueSet? I think we need to pick one for now - right @gcangioli ?

eP guidelines say SMS. But you can have several value sets and make use of the mappings Robert has created.

Discussion: For the codesystems that are not available (i.e. they are behind EMA login), we can create a CodeSystem (Supplement) and use that. At the end we need ValueSets referring to valid CodeSystems, even if the CodeSystems are themselves "temporary local copies".
Action: Giorgio to validate the code systems and see whether they need to be simply changed to ValueSets.
@gcangioli this: https://github.com/hl7-eu/unicom-ig/pull/36/files

@Censacrof : the code systems I looked at are value sets.
In order to keep  the different languages, unfortunately, you cannot simply change the declaration from CodeSystem to ValueSet and removing the definitions.
attached an example of how it can be done in sushi (just for one coded concept)
fsh-example.txt
Hope this helps :-)

this is how is shown in the guide

@costateixeira : is the publisher or the template that create the table ?

I understand that the table is made by the publisher java code
On Thu, Dec 1, 2022 at 7:50 PM Giorgio Cangioli @.***>
wrote:

@costateixeira https://github.com/costateixeira : is the publisher or
the template that create the table ?
—
Reply to this email directly, view it on GitHub
https://github.com/hl7-eu/unicom-ig/issues/32#issuecomment-1334200341,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HUUBOUJTHFDTSHNHAVQ3WLDXPHANCNFSM6AAAAAARWEELQI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Censacrof : the code systems I looked at are value sets. In order to keep the different languages, unfortunately, you cannot simply change the declaration from CodeSystem to ValueSet and removing the definitions.
attached an example of how it can be done in sushi (just for one coded concept) fsh-example.txt
Hope this helps :-)

Hi @gcangioli, i'm working on it. I have one question: if I create FHS files like in your example, when I compile with SUSHI, it counts them as Instances rather then ValueSet(s). Is this ok / desirable? I guess it doesn't make a difference in the end but I want to be sure.

@gcangioli why is copyright "CC-BY-SA-4.0"  in your example? Is this a mistake?

I created all ValueSets for UCUM, EDQM and SMS substances in #36 .
Please @costateixeira @gcangioli @rlindstrm. Can you please review my work, and In case merge the pull request on the r4b so that we can close this issue?

@costateixeira @gcangioli @rlindstrm
I updated the EDQM valuesets so that they will only include localizations for only 7 (instead of 30+)  common languages. This resulted in way faster compilation time. Also, I fixed all the warnings saying that we were using languages that are not included in the "Common Languages" ValueSet.
I will now close this issue, as all essential ValueSets are in the IG and are working.

authors: Censacrof costateixeira gcangioli rlindstrm


text:
No way to interrupt direnv when running it takes ages

What did you expect to happen?
I'm using direnv together with Nix in order to provide all my tools in a console. This is great that doom automatically runs direnv when using the direnv module, but sometimes I'd like to be able to cancel this. The reason is that it can sometimes take ages to compile a given direnv environment, and sometimes I just want to edit quickly a file. In the terminal I can press C-c to stop direnv, would it be possible to provide a similar command inside doom?
Steps to reproduce:

Install and configure direnv. For example, I use nix and home-manager, configured using:

{ config, pkgs, ... }:
# https://rycee.gitlab.io/home-manager/
{
  # Let Home Manager install and manage itself.
  programs.home-manager.enable = true;

  # Direnv
  programs.bash.enable = true;
  programs.direnv.enable = true;
  programs.direnv.enableNixDirenvIntegration = true;
}

Create a .envrc that takes some time to be generated, for example using echo "sleep 20" > .envrc (in real-life, this comes from shell.nix files that takes lots of time to build the packages)
Allow that folder to use direnv, by running direnv allow
Try to open with doom-emacs, with the module :tool direnv enabled, the file .envrc for example. Note that I think that you need to run emacs from another folder than the one where you created your direnv environment, otherwise I don't think it runs direnv.

Note that pressing C-g does not just stop direnv, but it cancel the whole file openning.
System information:

```
SYSTEM  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /run/current-system/sw/bin/bash
        uname      Linux 5.4.66 #1-NixOS SMP Thu Sep 17 11:47:56 UTC 2020 x86_64
        path       (/run/wrappers/bin ~/.nix-profile/bin /etc/profiles/per-user/$USER/bin /nix/var/nix/profiles/default/bin /run/current-system/sw/bin /nix/store/ih9bwzlkp0r5p999fnrdx1m1xkm0kfb6-emacs-26.3/libexec/emacs/26.3/x86_64-pc-linux-gnu/)
EMACS   dir        ~/Documents/Informatique/Emacs_configurations/2020_doom/dot_emacs_dot_d/
        version    26.3
        build      nov. 03, 2020
        buildopts  --prefix=/nix/store/ih9bwzlkp0r5p999fnrdx1m1xkm0kfb6-emacs-26.3 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200
        features   XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
        traits     (server-running envvar-file)
DOOM    dir        ~/Documents/Informatique/Emacs_configurations/2020_doom/dot_doom_dot_d/
        version    2.0.9
        build      grafted, HEAD -> develop, origin/develop, origin/HEAD 807f00a 2020-11-02 23:56:43 -0500
        elc-files  0
        modules    (:completion company (ivy +fuzzy +prescient +icons) :ui doom doom-dashboard doom-quit (emoji +unicode) hl-todo minimap modeline ophints (popup +defaults) vc-gutter vi-tilde-fringe :editor file-templates fold snippets :emacs dired electric undo vc :checkers syntax spell grammar :tools direnv (eval +overlay) lookup lsp magit :os tty :lang cc emacs-lisp (haskell +dante) (latex +latexmk +cdlatex +lsp +fold) lua markdown nix ocaml org rst sh web :config (default +bindings +smartparens))
        packages   (n/a)
        unpin      (n/a)
        elpa       (n/a)
```

As of d45155aec, direnv will no longer run more than once in some buffers. As of f7293fb, aborting direnv won't abort opening the file. With this your issue should be resolved.
Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!

Works perfectly, thank you so much!

source: gharchive/issue

authors: hlissner tobiasBora

repo: hlissner/doom-emacs

license: MIT

license_type: permissive

license_source: github-api


text:
bump: :tools biblio

andras-simonyi/citeproc-el@c8ff95862823 -> andras-simonyi/citeproc-el@e5b5f86defe2
bdarcus/citar@41ec5d4d5d62 -> bdarcus/citar@9e6817900160
tmalsburg/helm-bibtex@bb47f355b0da -> tmalsburg/helm-bibtex@aa775340ba69
A simple bump commit.

Thanks again!

source: gharchive/pull-request

authors: bdarcus hlissner


text:
Feature/solarized dark

Add solarized dark. Basic inverse of solarized-light
Fixed a few issues with highlighting.

 What it looks like so far. I think the modeline needs to be fixed, as well as M-x

I'm still keen on debugging this, @hlissner can you hit me up on discord sometime when you're free? preferably when @Emiller88 is online too

How is this going? I've been itching to use solarized dark with doom for a while now :)

@jmorag Feel free to use it and put your complaints here. It's mainly been a lack of testing that's held it back from making the finishing touches on it!

Really looking forward this dark solarized theme.
I would like to test this on my laptop, but I still very new to Emacs eco-system.
Is there any guide that can tell how to I can set this dark theme on my laptop, please?

The easiest way would probably be to just go to the Files changed pane of this pull request, copy and paste the diff into a doom-solarized-dark.el file and load it.

@Emiller88 I'm trying this on my Mac, and the folder color in modeline, (and also the language color) looks terrible for me.
Can we make a change for the color, please?

@bittopaz sorry for the extremely late reply. What color did you have in mind? You can also make a PR to this with any changes you want to see.

@Emiller88 no worries, I'm not using this theme anymore.

repo: hlissner/emacs-doom-themes

license: mit

license_source: bigquery


text:
stdlib issue when build in linux

Hi,
I tried to build the example in linux (Ubuntu 22.04 - amd64). Currently, I get the following issue.
I did updated few lines of code here. This solved the issue.
Anyway, I want to double check if this is expected?
Br,
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:83:36: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:97:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:98:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:110:36: error: use of undeclared identifier 'realloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:140:39: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:221:40: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:231:40: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:241:40: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:251:38: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:261:39: error: use of undeclared identifier 'malloc'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:302:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:308:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:314:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:320:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:326:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:332:5: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:355:3: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:885:7: error: use of undeclared identifier 'free'
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/common/webview_value.cc:905:7: error: use of undeclared identifier 'free'
fatal error: too many errors emitted, stopping now [-ferror-limit=]
/home/dxta/dev/kiosk/fl_app/linux/flutter/ephemeral/.plugin_symlinks/webview_cef/linux/webview_cef_plugin.cc:273:11: error: variable 'res' set but not used [-Werror,-Wunused-but-set-variable]

@DxTa I guess it is caused by different C++ compilers.The reference to 'stdlib.h' may be necessary for some 'strict' compilers.
The function 'system' is weird that some compilers need a variable to handle the return value, i will check if there is anything wrong.

In that file, add the header: #include <stdlib.h>

Should be fixed in this PR https://github.com/hlwhl/webview_cef/pull/148

authors: DxTa SinyimZhi cadivus yk3372


text:
Merge pull request #53 from hlxsites/feature/header-bugs

fixed the header issues
Test URLs:

Before: https://main--aldevron--hlxsites.hlx.page/
After: https://feature-header-bugs--aldevron--hlxsites.hlx.page/

Need to create again

repo: hlxsites/aldevron


text:
Things to Do Content

/caesars-palace/things-to-do
/caesars-palace/things-to-do/garden-of-the-gods-pool-oasis
/caesars-palace/things-to-do/golf
/caesars-palace/things-to-do/nightlife
/caesars-palace/things-to-do/nightlife/alto-bar
/caesars-palace/things-to-do/nightlife/vista-cocktail-lounge
/caesars-palace/things-to-do/nightlife/montecristo-cigar-bar
/caesars-palace/things-to-do/nightlife/lobby-bar
/caesars-palace/things-to-do/nightlife/numb-bar-and-frozen-cocktails
/caesars-palace/things-to-do/nightlife/stadia
/caesars-palace/things-to-do/nightlife/purple-zebra
/caesars-palace/things-to-do/nightlife/galleria-bar
/caesars-palace/things-to-do/shopping
/caesars-palace/things-to-do/qua
/caesars-palace/things-to-do/hairdreams-salon
/caesars-palace/things-to-do/weddings
/caesars-palace/things-to-do/weddings/inquiry
/caesars-palace/things-to-do/weddings/spa-and-salon-services
/caesars-palace/things-to-do/basketball
/caesars-palace/things-to-do/hoopsredirect
/caesars-palace/things-to-do/caesars-experiences
/caesars-palace/things-to-do/football

Need to check is /caesars-palace/things-to-do/basketball and
/caesars-palace/things-to-do/hoopsredirect are still current and should be migrated too.

authors: amol-anand tmathern

repo: hlxsites/caesars


text:
HMAN-493 run existing FTAs against a BEFTA pre-release

JIRA link (if applicable)
HMAN-493 "Next Hearing Date Updater - for preview pipelines enable cleanup of helm release on success"
Change description
Build against the next befta-fw pre-release, see hmcts/befta-fw#195.

see also:

hmcts/ccd-data-store-api#2180

Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Closing as evidence of GREEN run added to ticket

Closing as evidence of GREEN run added to ticket.

repo: hmcts/ccd-definition-store-api


text:
CIV-10849 dashboard-design-structure

JIRA link
https://tools.hmcts.net/jira/browse/CIV-10849
Change description

Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

impacts R1 - should we expect that?

It won't mess with R1, but it'll mess with the release 2 tickets. Keep in mind that the first version is just placeholders, and there's no actual functionality in there, so responding to claims, for example, won't work.
For your peace of mind, we've created a branch called "dashboard_dev," and you can rest assured that it won't disrupt any aspect of the CUI.

repo: hmcts/civil-citizen-ui


text:
CIV-7140 mediation cya

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-7140
Change description
when mediation is selected by the claimant in lr vs lr set state to in mediation
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

something going wrong with ccd definition import after a few builds so closing this one and reopening a new pr

repo: hmcts/civil-service


text:
Update values.preview.template.yaml

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)
[ ] the enable_keep_helm label has been added, if the helm release should be persisted after a successful build

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Closing this dummy PR as testing is completed

authors: channa-patil sealDebolina

repo: hmcts/prl-citizen-frontend


text:
BAU - remove un-used Typescript

fixes form re-submission warning problem

This will also allow:
https://github.com/hmrc/build-jobs/pull/8739

Was there a css selector for the existing js back links that can be removed now as well?

authors: SteveSugden crosslandwa


text:
Clodius process killed when converting bigWig to hitile

In preparation for ingesting bigWig signal tracks, I tried converting a test bigWig file to hitile format using conda (Python v3.6.4) and clodius v0.7.4. The host is a t2.micro EC2 instance running Ubuntu Xenial v16.04.
The aggregation proceeds up to the point of processing chr1 and the process is then killed.
The file /tmp/LN43287.75_20.normalized.GRCh38_no_alts.bw is a bigWig file containing DNase I density signal. I can make this available privately, if useful.
Here is the log of my conversion attempt:
$ clodius aggregate bigwig /tmp/LN43287.75_20.normalized.GRCh38_no_alts.bw \
--output-file /tmp/LN43287.75_20.normalized.GRCh38_no_alts.bw.hitile \
--assembly hg38
there
chrom_order: ['chr1', 'chr2', 'chr3', 'chr4', 'chr5', 'chr6', 'chr7', 'chr8', 'chr9', 'chr10', 'chr11', 'chr12', 'chr13', 'chr14', 'chr15', 'chr16', 'chr17', 'chr18', 'chr19', 'chr20', 'chr21', 'chr22', 'chrX', 'chrY', 'chrM', 'chr15_KI270905v1_alt', 'chr6_GL000256v2_alt', 'chr6_GL000254v2_alt', 'chr6_GL000251v2_alt', 'chr6_GL000253v2_alt', 'chr6_GL000250v2_alt', 'chr6_GL000255v2_alt', 'chr6_GL000252v2_alt', 'chr17_KI270857v1_alt', 'chr16_KI270853v1_alt', 'chr16_KI270728v1_random', 'chr17_GL000258v2_alt', 'chr5_GL339449v2_alt', 'chr14_KI270847v1_alt', 'chr17_KI270908v1_alt', 'chr14_KI270846v1_alt', 'chr5_KI270897v1_alt', 'chr7_KI270803v1_alt', 'chr19_GL949749v2_alt', 'chr19_KI270938v1_alt', 'chr19_GL949750v2_alt', 'chr19_GL949748v2_alt', 'chr19_GL949751v2_alt', 'chr19_GL949746v1_alt', 'chr19_GL949752v1_alt', 'chr8_KI270821v1_alt', 'chr1_KI270763v1_alt', 'chr6_KI270801v1_alt', 'chr19_GL949753v2_alt', 'chr19_GL949747v2_alt', 'chr8_KI270822v1_alt', 'chr4_GL000257v2_alt', 'chr12_KI270904v1_alt', 'chr4_KI270925v1_alt', 'chr15_KI270852v1_alt', 'chr15_KI270727v1_random', 'chr9_KI270823v1_alt', 'chr15_KI270850v1_alt', 'chr1_KI270759v1_alt', 'chr12_GL877876v1_alt', 'chrUn_KI270442v1', 'chr17_KI270862v1_alt', 'chr15_GL383555v2_alt', 'chr19_GL383573v1_alt', 'chr4_KI270896v1_alt', 'chr4_GL383528v1_alt', 'chr17_GL383563v3_alt', 'chr8_KI270810v1_alt', 'chr1_GL383520v2_alt', 'chr1_KI270762v1_alt', 'chr15_KI270848v1_alt', 'chr17_KI270909v1_alt', 'chr14_KI270844v1_alt', 'chr8_KI270900v1_alt', 'chr10_GL383546v1_alt', 'chr13_KI270838v1_alt', 'chr8_KI270816v1_alt', 'chr22_KI270879v1_alt', 'chr8_KI270813v1_alt', 'chr11_KI270831v1_alt', 'chr15_GL383554v1_alt', 'chr8_KI270811v1_alt', 'chr18_GL383567v1_alt', 'chrX_KI270880v1_alt', 'chr8_KI270812v1_alt', 'chr19_KI270921v1_alt', 'chr17_KI270729v1_random', 'chr17_JH159146v1_alt', 'chrX_KI270913v1_alt', 'chr6_KI270798v1_alt', 'chr7_KI270808v1_alt', 'chr22_KI270876v1_alt', 'chr15_KI270851v1_alt', 'chr22_KI270875v1_alt', 'chr1_KI270766v1_alt', 'chr19_KI270882v1_alt', 'chr3_KI270778v1_alt', 'chr15_KI270849v1_alt', 'chr4_KI270786v1_alt', 'chr12_KI270835v1_alt', 'chr17_KI270858v1_alt', 'chr19_KI270867v1_alt', 'chr16_KI270855v1_alt', 'chr8_KI270926v1_alt', 'chr5_GL949742v1_alt', 'chr3_KI270780v1_alt', 'chr17_GL383565v1_alt', 'chr2_KI270774v1_alt', 'chr4_KI270790v1_alt', 'chr11_KI270927v1_alt', 'chr19_KI270932v1_alt', 'chr11_KI270903v1_alt', 'chr2_KI270894v1_alt', 'chr14_GL000225v1_random', 'chrUn_KI270743v1', 'chr11_KI270832v1_alt', 'chr7_KI270805v1_alt', 'chr4_GL000008v2_random', 'chr7_KI270809v1_alt', 'chr19_KI270887v1_alt', 'chr4_KI270789v1_alt', 'chr3_KI270779v1_alt', 'chr19_KI270914v1_alt', 'chr19_KI270886v1_alt', 'chr11_KI270829v1_alt', 'chr14_GL000009v2_random', 'chr21_GL383579v2_alt', 'chr11_JH159136v1_alt', 'chr19_KI270930v1_alt', 'chrUn_KI270747v1', 'chr18_GL383571v1_alt', 'chr19_KI270920v1_alt', 'chr6_KI270797v1_alt', 'chr3_KI270935v1_alt', 'chr17_KI270861v1_alt', 'chr15_KI270906v1_alt', 'chr5_KI270791v1_alt', 'chr14_KI270722v1_random', 'chr16_GL383556v1_alt', 'chr13_KI270840v1_alt', 'chr14_GL000194v1_random', 'chr11_JH159137v1_alt', 'chr19_KI270917v1_alt', 'chr7_KI270899v1_alt', 'chr19_KI270923v1_alt', 'chr10_KI270825v1_alt', 'chr19_GL383576v1_alt', 'chr19_KI270922v1_alt', 'chrUn_KI270742v1', 'chr22_KI270878v1_alt', 'chr19_KI270929v1_alt', 'chr11_KI270826v1_alt', 'chr6_KB021644v2_alt', 'chr17_GL000205v2_random', 'chr1_KI270765v1_alt', 'chr19_KI270916v1_alt', 'chr19_KI270890v1_alt', 'chr3_KI270784v1_alt', 'chr12_GL383551v1_alt', 'chr20_KI270870v1_alt', 'chrUn_GL000195v1', 'chr1_GL383518v1_alt', 'chr22_KI270736v1_random', 'chr10_KI270824v1_alt', 'chr14_KI270845v1_alt', 'chr3_GL383526v1_alt', 'chr13_KI270839v1_alt', 'chr22_KI270733v1_random', 'chrUn_GL000224v1', 'chr10_GL383545v1_alt', 'chrUn_GL000219v1', 'chr5_KI270792v1_alt', 'chr17_KI270860v1_alt', 'chr19_GL000209v2_alt', 'chr11_KI270830v1_alt', 'chr9_KI270719v1_random', 'chrUn_GL000216v2', 'chr22_KI270928v1_alt', 'chr1_KI270712v1_random', 'chr6_KI270800v1_alt', 'chr1_KI270706v1_random', 'chr2_KI270776v1_alt', 'chr18_KI270912v1_alt', 'chr3_KI270777v1_alt', 'chr5_GL383531v1_alt', 'chr3_JH636055v2_alt', 'chr14_KI270725v1_random', 'chr5_KI270796v1_alt', 'chr9_GL383541v1_alt', 'chr19_KI270885v1_alt', 'chr19_KI270919v1_alt', 'chr19_KI270889v1_alt', 'chr19_KI270891v1_alt', 'chr19_KI270915v1_alt', 'chr19_KI270933v1_alt', 'chr19_KI270883v1_alt', 'chr19_GL383575v2_alt', 'chr19_KI270931v1_alt', 'chr12_GL383550v2_alt', 'chr13_KI270841v1_alt', 'chrUn_KI270744v1', 'chr18_KI270863v1_alt', 'chr18_GL383569v1_alt', 'chr12_GL877875v1_alt', 'chr21_KI270874v1_alt', 'chr3_KI270924v1_alt', 'chr1_KI270761v1_alt', 'chr3_KI270937v1_alt', 'chr22_KI270734v1_random', 'chr18_GL383570v1_alt', 'chr5_KI270794v1_alt', 'chr4_GL383527v1_alt', 'chrUn_GL000213v1', 'chr3_KI270936v1_alt', 'chr3_KI270934v1_alt', 'chr9_GL383539v1_alt', 'chr3_KI270895v1_alt', 'chr22_GL383582v2_alt', 'chr3_KI270782v1_alt', 'chr1_KI270892v1_alt', 'chrUn_GL000220v1', 'chr2_KI270767v1_alt', 'chr2_KI270715v1_random', 'chr2_KI270893v1_alt', 'chrUn_GL000218v1', 'chr18_GL383572v1_alt', 'chr8_KI270817v1_alt', 'chr4_KI270788v1_alt', 'chrUn_KI270749v1', 'chr7_KI270806v1_alt', 'chr7_KI270804v1_alt', 'chr18_KI270911v1_alt', 'chrUn_KI270741v1', 'chr17_KI270910v1_alt', 'chr19_KI270884v1_alt', 'chr19_GL383574v1_alt', 'chr19_KI270888v1_alt', 'chr3_GL000221v1_random', 'chr11_GL383547v1_alt', 'chr2_KI270716v1_random', 'chr12_GL383553v2_alt', 'chr6_KI270799v1_alt', 'chr22_KI270731v1_random', 'chrUn_KI270751v1', 'chrUn_KI270750v1', 'chr8_KI270818v1_alt', 'chrX_KI270881v1_alt', 'chr21_KI270873v1_alt', 'chr2_GL383521v1_alt', 'chr8_KI270814v1_alt', 'chr12_GL383552v1_alt', 'chrUn_KI270519v1', 'chr2_KI270775v1_alt', 'chr17_KI270907v1_alt', 'chrUn_GL000214v1', 'chr8_KI270901v1_alt', 'chr2_KI270770v1_alt', 'chr16_KI270854v1_alt', 'chr8_KI270819v1_alt', 'chr17_GL383564v2_alt', 'chr2_KI270772v1_alt', 'chr8_KI270815v1_alt', 'chr5_KI270795v1_alt', 'chr5_KI270898v1_alt', 'chr20_GL383577v2_alt', 'chr1_KI270708v1_random', 'chr7_KI270807v1_alt', 'chr5_KI270793v1_alt', 'chr6_GL383533v1_alt', 'chr2_GL383522v1_alt', 'chr19_KI270918v1_alt', 'chr12_GL383549v1_alt', 'chr2_KI270769v1_alt', 'chr4_KI270785v1_alt', 'chr12_KI270834v1_alt', 'chr7_GL383534v2_alt', 'chr20_KI270869v1_alt', 'chr21_GL383581v2_alt', 'chr3_KI270781v1_alt', 'chr17_KI270730v1_random', 'chrUn_KI270438v1', 'chr4_KI270787v1_alt', 'chr18_KI270864v1_alt', 'chr2_KI270771v1_alt', 'chr1_GL383519v1_alt', 'chr2_KI270768v1_alt', 'chr1_KI270760v1_alt', 'chr3_KI270783v1_alt', 'chr17_KI270859v1_alt', 'chr11_KI270902v1_alt', 'chr18_GL383568v1_alt', 'chr22_KI270737v1_random', 'chr13_KI270843v1_alt', 'chr22_KI270877v1_alt', 'chr5_GL383530v1_alt', 'chr11_KI270721v1_random', 'chr22_KI270738v1_random', 'chr22_GL383583v2_alt', 'chr2_GL582966v2_alt', 'chrUn_KI270748v1', 'chrUn_KI270435v1', 'chr5_GL000208v1_random', 'chrUn_KI270538v1', 'chr17_GL383566v1_alt', 'chr16_GL383557v1_alt', 'chr17_JH159148v1_alt', 'chr5_GL383532v1_alt', 'chr21_KI270872v1_alt', 'chrUn_KI270756v1', 'chr6_KI270758v1_alt', 'chr12_KI270833v1_alt', 'chr6_KI270802v1_alt', 'chr21_GL383580v2_alt', 'chr22_KB663609v1_alt', 'chr22_KI270739v1_random', 'chr9_GL383540v1_alt', 'chrUn_KI270757v1', 'chr2_KI270773v1_alt', 'chr17_JH159147v1_alt', 'chr11_KI270827v1_alt', 'chr1_KI270709v1_random', 'chrUn_KI270746v1', 'chr16_KI270856v1_alt', 'chr21_GL383578v2_alt', 'chrUn_KI270753v1', 'chr19_KI270868v1_alt', 'chr9_GL383542v1_alt', 'chr20_KI270871v1_alt', 'chr12_KI270836v1_alt', 'chr19_KI270865v1_alt', 'chr1_KI270764v1_alt', 'chrUn_KI270589v1', 'chr14_KI270726v1_random', 'chr19_KI270866v1_alt', 'chr22_KI270735v1_random', 'chr1_KI270711v1_random', 'chrUn_KI270745v1', 'chr1_KI270714v1_random', 'chr22_KI270732v1_random', 'chr1_KI270713v1_random', 'chrUn_KI270754v1', 'chr1_KI270710v1_random', 'chr12_KI270837v1_alt', 'chr9_KI270717v1_random', 'chr14_KI270724v1_random', 'chr9_KI270720v1_random', 'chr14_KI270723v1_random', 'chr9_KI270718v1_random', 'chrUn_KI270317v1', 'chr13_KI270842v1_alt', 'chrY_KI270740v1_random', 'chrUn_KI270755v1', 'chr8_KI270820v1_alt', 'chr1_KI270707v1_random', 'chrUn_KI270579v1', 'chrUn_KI270752v1', 'chrUn_KI270512v1', 'chrUn_KI270322v1', 'chrUn_GL000226v1', 'chrUn_KI270311v1', 'chrUn_KI270366v1', 'chrUn_KI270511v1', 'chrUn_KI270448v1', 'chrUn_KI270521v1', 'chrUn_KI270581v1', 'chrUn_KI270582v1', 'chrUn_KI270515v1', 'chrUn_KI270588v1', 'chrUn_KI270591v1', 'chrUn_KI270522v1', 'chrUn_KI270507v1', 'chrUn_KI270590v1', 'chrUn_KI270584v1', 'chrUn_KI270320v1', 'chrUn_KI270382v1', 'chrUn_KI270468v1', 'chrUn_KI270467v1', 'chrUn_KI270362v1', 'chrUn_KI270517v1', 'chrUn_KI270593v1', 'chrUn_KI270528v1', 'chrUn_KI270587v1', 'chrUn_KI270364v1', 'chrUn_KI270371v1', 'chrUn_KI270333v1', 'chrUn_KI270374v1', 'chrUn_KI270411v1', 'chrUn_KI270414v1', 'chrUn_KI270510v1', 'chrUn_KI270390v1', 'chrUn_KI270375v1', 'chrUn_KI270420v1', 'chrUn_KI270509v1', 'chrUn_KI270315v1', 'chrUn_KI270302v1', 'chrUn_KI270518v1', 'chrUn_KI270530v1', 'chrUn_KI270304v1', 'chrUn_KI270418v1', 'chrUn_KI270424v1', 'chrUn_KI270417v1', 'chrUn_KI270508v1', 'chrUn_KI270303v1', 'chrUn_KI270381v1', 'chrUn_KI270529v1', 'chrUn_KI270425v1', 'chrUn_KI270396v1', 'chrUn_KI270363v1', 'chrUn_KI270386v1', 'chrUn_KI270465v1', 'chrUn_KI270383v1', 'chrUn_KI270384v1', 'chrUn_KI270330v1', 'chrUn_KI270372v1', 'chrUn_KI270548v1', 'chrUn_KI270580v1', 'chrUn_KI270387v1', 'chrUn_KI270391v1', 'chrUn_KI270305v1', 'chrUn_KI270373v1', 'chrUn_KI270422v1', 'chrUn_KI270316v1', 'chrUn_KI270338v1', 'chrUn_KI270340v1', 'chrUn_KI270583v1', 'chrUn_KI270334v1', 'chrUn_KI270429v1', 'chrUn_KI270393v1', 'chrUn_KI270516v1', 'chrUn_KI270389v1', 'chrUn_KI270466v1', 'chrUn_KI270388v1', 'chrUn_KI270544v1', 'chrUn_KI270310v1', 'chrUn_KI270412v1', 'chrUn_KI270395v1', 'chrUn_KI270376v1', 'chrUn_KI270337v1', 'chrUn_KI270335v1', 'chrUn_KI270378v1', 'chrUn_KI270379v1', 'chrUn_KI270329v1', 'chrUn_KI270419v1', 'chrUn_KI270336v1', 'chrUn_KI270312v1', 'chrUn_KI270539v1', 'chrUn_KI270385v1', 'chrUn_KI270423v1', 'chrUn_KI270392v1', 'chrUn_KI270394v1']
assembly size (max-length) 3209286105
max-width 4294967296
max_zoom: 22
chunk-size: 16777216
chrom-order [b'chr1' b'chr2' b'chr3' b'chr4' b'chr5' b'chr6' b'chr7' b'chr8' b'chr9'
 b'chr10' b'chr11' b'chr12' b'chr13' b'chr14' b'chr15' b'chr16' b'chr17'
 b'chr18' b'chr19' b'chr20' b'chr21' b'chr22' b'chrX' b'chrY' b'chrM'
 b'chr15_KI270905v1_alt' b'chr6_GL000256v2_alt' b'chr6_GL000254v2_alt'
 b'chr6_GL000251v2_alt' b'chr6_GL000253v2_alt' b'chr6_GL000250v2_alt'
 b'chr6_GL000255v2_alt' b'chr6_GL000252v2_alt' b'chr17_KI270857v1_alt'
 b'chr16_KI270853v1_alt' b'chr16_KI270728v1_random' b'chr17_GL000258v2_alt'
 b'chr5_GL339449v2_alt' b'chr14_KI270847v1_alt' b'chr17_KI270908v1_alt'
 b'chr14_KI270846v1_alt' b'chr5_KI270897v1_alt' b'chr7_KI270803v1_alt'
 b'chr19_GL949749v2_alt' b'chr19_KI270938v1_alt' b'chr19_GL949750v2_alt'
 b'chr19_GL949748v2_alt' b'chr19_GL949751v2_alt' b'chr19_GL949746v1_alt'
 b'chr19_GL949752v1_alt' b'chr8_KI270821v1_alt' b'chr1_KI270763v1_alt'
 b'chr6_KI270801v1_alt' b'chr19_GL949753v2_alt' b'chr19_GL949747v2_alt'
 b'chr8_KI270822v1_alt' b'chr4_GL000257v2_alt' b'chr12_KI270904v1_alt'
 b'chr4_KI270925v1_alt' b'chr15_KI270852v1_alt' b'chr15_KI270727v1_random'
 b'chr9_KI270823v1_alt' b'chr15_KI270850v1_alt' b'chr1_KI270759v1_alt'
 b'chr12_GL877876v1_alt' b'chrUn_KI270442v1' b'chr17_KI270862v1_alt'
 b'chr15_GL383555v2_alt' b'chr19_GL383573v1_alt' b'chr4_KI270896v1_alt'
 b'chr4_GL383528v1_alt' b'chr17_GL383563v3_alt' b'chr8_KI270810v1_alt'
 b'chr1_GL383520v2_alt' b'chr1_KI270762v1_alt' b'chr15_KI270848v1_alt'
 b'chr17_KI270909v1_alt' b'chr14_KI270844v1_alt' b'chr8_KI270900v1_alt'
 b'chr10_GL383546v1_alt' b'chr13_KI270838v1_alt' b'chr8_KI270816v1_alt'
 b'chr22_KI270879v1_alt' b'chr8_KI270813v1_alt' b'chr11_KI270831v1_alt'
 b'chr15_GL383554v1_alt' b'chr8_KI270811v1_alt' b'chr18_GL383567v1_alt'
 b'chrX_KI270880v1_alt' b'chr8_KI270812v1_alt' b'chr19_KI270921v1_alt'
 b'chr17_KI270729v1_random' b'chr17_JH159146v1_alt' b'chrX_KI270913v1_alt'
 b'chr6_KI270798v1_alt' b'chr7_KI270808v1_alt' b'chr22_KI270876v1_alt'
 b'chr15_KI270851v1_alt' b'chr22_KI270875v1_alt' b'chr1_KI270766v1_alt'
 b'chr19_KI270882v1_alt' b'chr3_KI270778v1_alt' b'chr15_KI270849v1_alt'
 b'chr4_KI270786v1_alt' b'chr12_KI270835v1_alt' b'chr17_KI270858v1_alt'
 b'chr19_KI270867v1_alt' b'chr16_KI270855v1_alt' b'chr8_KI270926v1_alt'
 b'chr5_GL949742v1_alt' b'chr3_KI270780v1_alt' b'chr17_GL383565v1_alt'
 b'chr2_KI270774v1_alt' b'chr4_KI270790v1_alt' b'chr11_KI270927v1_alt'
 b'chr19_KI270932v1_alt' b'chr11_KI270903v1_alt' b'chr2_KI270894v1_alt'
 b'chr14_GL000225v1_random' b'chrUn_KI270743v1' b'chr11_KI270832v1_alt'
 b'chr7_KI270805v1_alt' b'chr4_GL000008v2_random' b'chr7_KI270809v1_alt'
 b'chr19_KI270887v1_alt' b'chr4_KI270789v1_alt' b'chr3_KI270779v1_alt'
 b'chr19_KI270914v1_alt' b'chr19_KI270886v1_alt' b'chr11_KI270829v1_alt'
 b'chr14_GL000009v2_random' b'chr21_GL383579v2_alt' b'chr11_JH159136v1_alt'
 b'chr19_KI270930v1_alt' b'chrUn_KI270747v1' b'chr18_GL383571v1_alt'
 b'chr19_KI270920v1_alt' b'chr6_KI270797v1_alt' b'chr3_KI270935v1_alt'
 b'chr17_KI270861v1_alt' b'chr15_KI270906v1_alt' b'chr5_KI270791v1_alt'
 b'chr14_KI270722v1_random' b'chr16_GL383556v1_alt' b'chr13_KI270840v1_alt'
 b'chr14_GL000194v1_random' b'chr11_JH159137v1_alt' b'chr19_KI270917v1_alt'
 b'chr7_KI270899v1_alt' b'chr19_KI270923v1_alt' b'chr10_KI270825v1_alt'
 b'chr19_GL383576v1_alt' b'chr19_KI270922v1_alt' b'chrUn_KI270742v1'
 b'chr22_KI270878v1_alt' b'chr19_KI270929v1_alt' b'chr11_KI270826v1_alt'
 b'chr6_KB021644v2_alt' b'chr17_GL000205v2_random' b'chr1_KI270765v1_alt'
 b'chr19_KI270916v1_alt' b'chr19_KI270890v1_alt' b'chr3_KI270784v1_alt'
 b'chr12_GL383551v1_alt' b'chr20_KI270870v1_alt' b'chrUn_GL000195v1'
 b'chr1_GL383518v1_alt' b'chr22_KI270736v1_random' b'chr10_KI270824v1_alt'
 b'chr14_KI270845v1_alt' b'chr3_GL383526v1_alt' b'chr13_KI270839v1_alt'
 b'chr22_KI270733v1_random' b'chrUn_GL000224v1' b'chr10_GL383545v1_alt'
 b'chrUn_GL000219v1' b'chr5_KI270792v1_alt' b'chr17_KI270860v1_alt'
 b'chr19_GL000209v2_alt' b'chr11_KI270830v1_alt' b'chr9_KI270719v1_random'
 b'chrUn_GL000216v2' b'chr22_KI270928v1_alt' b'chr1_KI270712v1_random'
 b'chr6_KI270800v1_alt' b'chr1_KI270706v1_random' b'chr2_KI270776v1_alt'
 b'chr18_KI270912v1_alt' b'chr3_KI270777v1_alt' b'chr5_GL383531v1_alt'
 b'chr3_JH636055v2_alt' b'chr14_KI270725v1_random' b'chr5_KI270796v1_alt'
 b'chr9_GL383541v1_alt' b'chr19_KI270885v1_alt' b'chr19_KI270919v1_alt'
 b'chr19_KI270889v1_alt' b'chr19_KI270891v1_alt' b'chr19_KI270915v1_alt'
 b'chr19_KI270933v1_alt' b'chr19_KI270883v1_alt' b'chr19_GL383575v2_alt'
 b'chr19_KI270931v1_alt' b'chr12_GL383550v2_alt' b'chr13_KI270841v1_alt'
 b'chrUn_KI270744v1' b'chr18_KI270863v1_alt' b'chr18_GL383569v1_alt'
 b'chr12_GL877875v1_alt' b'chr21_KI270874v1_alt' b'chr3_KI270924v1_alt'
 b'chr1_KI270761v1_alt' b'chr3_KI270937v1_alt' b'chr22_KI270734v1_random'
 b'chr18_GL383570v1_alt' b'chr5_KI270794v1_alt' b'chr4_GL383527v1_alt'
 b'chrUn_GL000213v1' b'chr3_KI270936v1_alt' b'chr3_KI270934v1_alt'
 b'chr9_GL383539v1_alt' b'chr3_KI270895v1_alt' b'chr22_GL383582v2_alt'
 b'chr3_KI270782v1_alt' b'chr1_KI270892v1_alt' b'chrUn_GL000220v1'
 b'chr2_KI270767v1_alt' b'chr2_KI270715v1_random' b'chr2_KI270893v1_alt'
 b'chrUn_GL000218v1' b'chr18_GL383572v1_alt' b'chr8_KI270817v1_alt'
 b'chr4_KI270788v1_alt' b'chrUn_KI270749v1' b'chr7_KI270806v1_alt'
 b'chr7_KI270804v1_alt' b'chr18_KI270911v1_alt' b'chrUn_KI270741v1'
 b'chr17_KI270910v1_alt' b'chr19_KI270884v1_alt' b'chr19_GL383574v1_alt'
 b'chr19_KI270888v1_alt' b'chr3_GL000221v1_random' b'chr11_GL383547v1_alt'
 b'chr2_KI270716v1_random' b'chr12_GL383553v2_alt' b'chr6_KI270799v1_alt'
 b'chr22_KI270731v1_random' b'chrUn_KI270751v1' b'chrUn_KI270750v1'
 b'chr8_KI270818v1_alt' b'chrX_KI270881v1_alt' b'chr21_KI270873v1_alt'
 b'chr2_GL383521v1_alt' b'chr8_KI270814v1_alt' b'chr12_GL383552v1_alt'
 b'chrUn_KI270519v1' b'chr2_KI270775v1_alt' b'chr17_KI270907v1_alt'
 b'chrUn_GL000214v1' b'chr8_KI270901v1_alt' b'chr2_KI270770v1_alt'
 b'chr16_KI270854v1_alt' b'chr8_KI270819v1_alt' b'chr17_GL383564v2_alt'
 b'chr2_KI270772v1_alt' b'chr8_KI270815v1_alt' b'chr5_KI270795v1_alt'
 b'chr5_KI270898v1_alt' b'chr20_GL383577v2_alt' b'chr1_KI270708v1_random'
 b'chr7_KI270807v1_alt' b'chr5_KI270793v1_alt' b'chr6_GL383533v1_alt'
 b'chr2_GL383522v1_alt' b'chr19_KI270918v1_alt' b'chr12_GL383549v1_alt'
 b'chr2_KI270769v1_alt' b'chr4_KI270785v1_alt' b'chr12_KI270834v1_alt'
 b'chr7_GL383534v2_alt' b'chr20_KI270869v1_alt' b'chr21_GL383581v2_alt'
 b'chr3_KI270781v1_alt' b'chr17_KI270730v1_random' b'chrUn_KI270438v1'
 b'chr4_KI270787v1_alt' b'chr18_KI270864v1_alt' b'chr2_KI270771v1_alt'
 b'chr1_GL383519v1_alt' b'chr2_KI270768v1_alt' b'chr1_KI270760v1_alt'
 b'chr3_KI270783v1_alt' b'chr17_KI270859v1_alt' b'chr11_KI270902v1_alt'
 b'chr18_GL383568v1_alt' b'chr22_KI270737v1_random' b'chr13_KI270843v1_alt'
 b'chr22_KI270877v1_alt' b'chr5_GL383530v1_alt' b'chr11_KI270721v1_random'
 b'chr22_KI270738v1_random' b'chr22_GL383583v2_alt' b'chr2_GL582966v2_alt'
 b'chrUn_KI270748v1' b'chrUn_KI270435v1' b'chr5_GL000208v1_random'
 b'chrUn_KI270538v1' b'chr17_GL383566v1_alt' b'chr16_GL383557v1_alt'
 b'chr17_JH159148v1_alt' b'chr5_GL383532v1_alt' b'chr21_KI270872v1_alt'
 b'chrUn_KI270756v1' b'chr6_KI270758v1_alt' b'chr12_KI270833v1_alt'
 b'chr6_KI270802v1_alt' b'chr21_GL383580v2_alt' b'chr22_KB663609v1_alt'
 b'chr22_KI270739v1_random' b'chr9_GL383540v1_alt' b'chrUn_KI270757v1'
 b'chr2_KI270773v1_alt' b'chr17_JH159147v1_alt' b'chr11_KI270827v1_alt'
 b'chr1_KI270709v1_random' b'chrUn_KI270746v1' b'chr16_KI270856v1_alt'
 b'chr21_GL383578v2_alt' b'chrUn_KI270753v1' b'chr19_KI270868v1_alt'
 b'chr9_GL383542v1_alt' b'chr20_KI270871v1_alt' b'chr12_KI270836v1_alt'
 b'chr19_KI270865v1_alt' b'chr1_KI270764v1_alt' b'chrUn_KI270589v1'
 b'chr14_KI270726v1_random' b'chr19_KI270866v1_alt'
 b'chr22_KI270735v1_random' b'chr1_KI270711v1_random' b'chrUn_KI270745v1'
 b'chr1_KI270714v1_random' b'chr22_KI270732v1_random'
 b'chr1_KI270713v1_random' b'chrUn_KI270754v1' b'chr1_KI270710v1_random'
 b'chr12_KI270837v1_alt' b'chr9_KI270717v1_random'
 b'chr14_KI270724v1_random' b'chr9_KI270720v1_random'
 b'chr14_KI270723v1_random' b'chr9_KI270718v1_random' b'chrUn_KI270317v1'
 b'chr13_KI270842v1_alt' b'chrY_KI270740v1_random' b'chrUn_KI270755v1'
 b'chr8_KI270820v1_alt' b'chr1_KI270707v1_random' b'chrUn_KI270579v1'
 b'chrUn_KI270752v1' b'chrUn_KI270512v1' b'chrUn_KI270322v1'
 b'chrUn_GL000226v1' b'chrUn_KI270311v1' b'chrUn_KI270366v1'
 b'chrUn_KI270511v1' b'chrUn_KI270448v1' b'chrUn_KI270521v1'
 b'chrUn_KI270581v1' b'chrUn_KI270582v1' b'chrUn_KI270515v1'
 b'chrUn_KI270588v1' b'chrUn_KI270591v1' b'chrUn_KI270522v1'
 b'chrUn_KI270507v1' b'chrUn_KI270590v1' b'chrUn_KI270584v1'
 b'chrUn_KI270320v1' b'chrUn_KI270382v1' b'chrUn_KI270468v1'
 b'chrUn_KI270467v1' b'chrUn_KI270362v1' b'chrUn_KI270517v1'
 b'chrUn_KI270593v1' b'chrUn_KI270528v1' b'chrUn_KI270587v1'
 b'chrUn_KI270364v1' b'chrUn_KI270371v1' b'chrUn_KI270333v1'
 b'chrUn_KI270374v1' b'chrUn_KI270411v1' b'chrUn_KI270414v1'
 b'chrUn_KI270510v1' b'chrUn_KI270390v1' b'chrUn_KI270375v1'
 b'chrUn_KI270420v1' b'chrUn_KI270509v1' b'chrUn_KI270315v1'
 b'chrUn_KI270302v1' b'chrUn_KI270518v1' b'chrUn_KI270530v1'
 b'chrUn_KI270304v1' b'chrUn_KI270418v1' b'chrUn_KI270424v1'
 b'chrUn_KI270417v1' b'chrUn_KI270508v1' b'chrUn_KI270303v1'
 b'chrUn_KI270381v1' b'chrUn_KI270529v1' b'chrUn_KI270425v1'
 b'chrUn_KI270396v1' b'chrUn_KI270363v1' b'chrUn_KI270386v1'
 b'chrUn_KI270465v1' b'chrUn_KI270383v1' b'chrUn_KI270384v1'
 b'chrUn_KI270330v1' b'chrUn_KI270372v1' b'chrUn_KI270548v1'
 b'chrUn_KI270580v1' b'chrUn_KI270387v1' b'chrUn_KI270391v1'
 b'chrUn_KI270305v1' b'chrUn_KI270373v1' b'chrUn_KI270422v1'
 b'chrUn_KI270316v1' b'chrUn_KI270338v1' b'chrUn_KI270340v1'
 b'chrUn_KI270583v1' b'chrUn_KI270334v1' b'chrUn_KI270429v1'
 b'chrUn_KI270393v1' b'chrUn_KI270516v1' b'chrUn_KI270389v1'
 b'chrUn_KI270466v1' b'chrUn_KI270388v1' b'chrUn_KI270544v1'
 b'chrUn_KI270310v1' b'chrUn_KI270412v1' b'chrUn_KI270395v1'
 b'chrUn_KI270376v1' b'chrUn_KI270337v1' b'chrUn_KI270335v1'
 b'chrUn_KI270378v1' b'chrUn_KI270379v1' b'chrUn_KI270329v1'
 b'chrUn_KI270419v1' b'chrUn_KI270336v1' b'chrUn_KI270312v1'
 b'chrUn_KI270539v1' b'chrUn_KI270385v1' b'chrUn_KI270423v1'
 b'chrUn_KI270392v1' b'chrUn_KI270394v1']
chrom: chr1

Killed

For this test, I am using v0.3.11 of the pyBigWig library, which appears to be the current version.
I am wondering if there are perhaps specific versions of Python or libraries I should be using for data conversion, or are there memory requirements for conversion that would be satisfied with a host with more memory?

Running the same conversion on a t2.large EC2 instance running Ubuntu Xenial v16.04 seemed to work without errors.

repo: hms-dbmi/clodius


text:
FF-275

Exp set browse up to table formatting discussed with Nils and Burak on 10/7.

Coverage increased (+0.8%) to 51.038% when pulling 80c94cb7190c917d04107b1894c4a9f74deea7dd on FF-275 into 0d34b0d2039dcee51cd7a657d746375ce8d768ea on master.

Coverage increased (+0.8%) to 51.038% when pulling 9719a88b3299cc442f17811f5168c6ff1a2636ef on FF-275 into 0d34b0d2039dcee51cd7a657d746375ce8d768ea on master.

authors: carlvitzthum coveralls

repo: hms-dbmi/fourfront


text:
Improve comment

Fix timecop_scale comment.

👍

authors: hnw tenkoma

repo: hnw/php-timecop


text:
Make WebViewMessageService more type safe

Realistically, there is one message handler for the backend, which handles a single type of message (with different variants). We could represent this in the frontend by making WebViewMessageService generic over a type that represents this message, to match with handle_yew_message() in the backend, to ensure that the frontend cannot send incompatible messages to the backend (instead of using the generic Value which will accept anything invalid). The type used would be provided by a crate shared between the frontend and backend.

I have toyed around a bit with that idea, but wasn't really able to come up with something that provided much value without needlessly increasing complexity.
I do have such a shared crate and type, and its very simple:
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Debug)]
pub enum SharedMsg {
    SelectFile,
    FileRead(Vec<u8>),
}

Through the exhaustive variant matching in Rust, it seems pretty hard to accidentally send incompatible messages. To me, this more seems to be a documentation rather than a code problem.

I've currently got this work in progress change as an idea for how to implement this (and #7 ) https://github.com/AleoHQ/yew_webview_bridge/pull/1
It does change the API a little with the introduction of an Arc around the message, but this allows it to avoid an unnecessary clone of the message (which could be expensive if passing something large), and the requirement for the message to implement Clone. The current API gets around that requirement by deserializing to Value, cloning, and then deserializing to the message, which is twice as expensive I guess.

authors: hobofan kellpossible


text:
Luna1 https://lcd.terra.dev/cosmos/tx/v1beta1/txs returns 403

Luna1 report is not working.
https://lcd.terra.dev/cosmos/tx/v1beta1/txs returns 403, permission denied.

Thanks for the info.  I'll need to update documentation somewhere but looks like lcd.terra.dev became restricted sometime around the birth of Terra 2.0.  You can find alternative LCD endpoints here https://github.com/cosmos/chain-registry/blob/master/terra/chain.json .
Example:
export STAKETAX_TERRA_LCD_NODE=https://...

Updated code not to use lcd.terra.dev as default: https://github.com/hodgerpodger/staketaxcsv/commit/e35cae782467b28836b2fa85e88686a73fd80ad3

repo: hodgerpodger/staketaxcsv


text:
Change the license

I wonder why you set the license LGPL? This license prevent use the library in commercial project without release the project source code. LGPL allow to link the lib without using the same license but with static file, it is nearly impossible with ESP32 project.
The original ESP http server using Apache-2.0 license, ESPAsyncServer not using any license as you mention in the commit https://github.com/hoeken/PsychicHttp/commit/e3225537252205f2f1075ccfdfdb391f72f25861
So better change license to MIT or Apache license.

well, its mainly because the original library i forked (ArduinoMongoose) was LGPL.  i'll email the guy and see if he's okay with me changing it.  pretty sure there won't be any issues.
don't worry, you can definitely use this library in a closed source, commercial project.  nobody will be coming after you :)

well, its mainly because the original library i forked (ArduinoMongoose) was LGPL. i'll email the guy and see if he's okay with me changing it. pretty sure there won't be any issues.
don't worry, you can definitely use this library in a closed source, commercial project. nobody will be coming after you :)

Yes, but have a commercial ready better.

authors: dzungpv hoeken

repo: hoeken/PsychicHttp


text:
improve time entry handling

Hörsuppe API returns times in localtime for Europe/Berlin (compare .ical data X-WR-TIMEZONE)
This leads to problems when

requireing UTC timestamps for further processing
processing data in different timezone

Additionally to solving the (intermediate) timezone-agnostic processing, this solution would handle transition to UTC times like hoerapi.php would.
The existing date processing made a transition to proper time information for API calls impossible.

oh, so there is actually someone using this :) what are you building?
Looks good to me. Merged and published as v2.0. Thank you!

From what i can grasp this module is used as (sole?) data source for shownotes database.
I only came across this when tracking strange browser behaviour with their (similar but different ambiguous) API date output format.
With the potential incopatibility solved by this update the Hörsuppe API at least should be be able to switch to explicit ISO 8601 UTC timestamps. :-)
(Some JS-interpreters handle the current Hörsuppe API date format incorrectly (some not at all), which makes integration harder/impossible.)

authors: becm luto


text:
Comparison to other monitoring tools

This project is entering a field already crowded with alternative solutions for monitoring. For tools that are competitors or alternative approaches, it's important to clarify how this one differs, so that people can make an informed choice. For other complementary tools, it's important to clarify how they could be used with this one, e.g. by providing data that it can use or interfacing with it in some other way. In part because some projects include both competitive and complementary components, it's not always obvious which of those categories (or some other category) a related tool falls into. It would be great if the docs could clarify these relationships at least as a rough categorization, which I've started as a first pass below. Of course, there are easily hundreds if not thousands of potentially competitive or complementary tools, but hopefully this selection will give the basic idea and make it easier to categorize any new tool you encounter.
As a background for comparison, the tool in this repo is:

Python - easily extensible by Python programmers to cover any data source
Configurable - Controlled with YAML whose capabilities can be extended in Python
Focused on data science artifacts - making it simple to monitor common classes of locally authored servers, such as Python-based dashboards and REST servers
General purpose, but focused on higher level needs (not network packets or hardware, but locally maintained apps)
Fully open source
Locally installed (not a web service)

Competitors/alternatives: (tools providing monitoring and graphing of external data sources)

Kibana - specific to Elasticsearch
Grafana - not Python-configurable
Sentry - web service focused on app monitoring and error reporting
glances - lower level
graphite/web - hard coded web interface to graphite tool
SolarWinds, MRTG, Zabbix, cacti, zenoss and many, many others - mainly IT audience (networks, attached devices, etc.) compared to this tool's data-science audience (less focused on networks, more focused on domain-relevant info that can be extracted from running servers)

Complements: (possible data sources, add-ons, etc.)

graphite/carbon, graphite/whisper, Prometheus, RRDtool, Bucky, collectd - logging data that could be queried
pagerduty - commercial; alerting

@jbednar How does this project compare with python panel? Is this intended to be a compliment to it or a replacement? It's not obvious based on the github page. Also, are there any working examples I can look at so I understand the intent?

@jbednar How does this project compare with python panel? Is this intended to be a compliment to it or a replacement? It's not obvious based on the github page. Also, are there any working examples I can look at so I understand the intent?

Good question; this issue is about other monitoring tools, but of course it's important to know how Lumen relates to other tools as well.
In this case, Lumen is built on top of Panel and Intake, letting users write a declarative specification for what they want to monitor or analyze. Lumen then uses Intake to fetch the data and Panel to set up a dashboard or app to view or work with it. Thus Lumen is complementary to Panel in terms of functionality (as Panel doesn't offer a way to turn a declarative text file into a dashboard), but more to the point Lumen is built directly on Panel (and thus requires Panel to be installed).
Basically, Lumen provides some of the power of Panel, without having to write any Python!  We anticipate that current users of Panel will continue to use Panel for what they use Panel for, and that Lumen users will either be from a different background (not Python programmers) or else be doing different things (e.g. monitoring a bunch of Panel apps, which was our original goal, or maybe automatically generating .yml files that can be used a specialized apps).
You won't be able to tell whether you're looking at a Lumen app or a Panel app, the same way you can't tell whether you're looking directly at a Bokeh app or at one created by Panel or HoloViews, but the process for generating the app is completely different in all these cases.
Examples and docs are coming! We'll officially announce Lumen once those are ready. Should be in the next couple of months, as we are giving a presentation on Lumen in mid-March.

Good question; this issue is about other monitoring tools, but of course it's important to know how Lumen relates to other tools as well.
In this case, Lumen is built on top of Panel and Intake, letting users write a declarative specification for what they want to monitor or analyze. Lumen then uses Intake to fetch the data and Panel to set up a dashboard or app to view or work with it. Thus Lumen is complementary to Panel in terms of functionality (as Panel doesn't offer a way to turn a declarative text file into a dashboard), but more to the point Lumen is built directly on Panel (and thus requires Panel to be installed).
Basically, Lumen provides some of the power of Panel, without having to write any Python!  We anticipate that current users of Panel will continue to use Panel for what they use Panel for, and that Lumen users will either be from a different background (not Python programmers) or else be doing different things (e.g. monitoring a bunch of Panel apps, which was our original goal, or maybe automatically generating .yml files that can be used a specialized apps).
You won't be able to tell whether you're looking at a Lumen app or a Panel app, the same way you can't tell whether you're looking directly at a Bokeh app or at one created by Panel or HoloViews, but the process for generating the app is completely different in all these cases.
Examples and docs are coming! We'll officially announce Lumen once those are ready. Should be in the next couple of months, as we are giving a presentation on Lumen in mid-March.

authors: jbednar rgpdx

repo: holoviz/lumen


text:
Does == work as we'd like for Parameterized instances?

Converted from SourceForge issue 2333811, submitted by ceball
Submit Date: 2008-11-23 17:24 GMT

see also discussion in #269

Closing. No immediate action, but reopen or open a new issue if you have a proposal for how this should work.

authors: ceball kcpevey sf-issues

repo: holoviz/param


text:
wip: initial shelly gen2 auth support

This PR provides some of the logic needed to support Shelly gen2 digest authentication for websocket connections. See original issue at https://github.com/home-assistant/core/issues/63621
References:

Shelly docs on digest auth
typescript implementation

I'm not super familiar with the structure of the rest of the codebase, so there's probably a lot here that needs to be restructured.
Anyway, the following code is what I used to verify that authentication is working for a local device
import asyncio
from pprint import pprint

import aiohttp
import async_timeout

from aioshelly.common import ConnectionOptions
from aioshelly.rpc_device import RpcDevice

async def test_rpc_device():
    """Test Gen2 RPC (WebSocket) based device."""
    shelly_ip = "192.168.33.1"
    api_url = f"http://{shelly_ip}/rpc/Switch.Toggle?id=0"
    options = ConnectionOptions(shelly_ip, password="super-secret")

    async with aiohttp.ClientSession() as aiohttp_session:
        try:
            async with async_timeout.timeout(10):
                #device = await WsRPC.connect(aiohttp_session, options)
                device = await RpcDevice.create(aiohttp_session, options)
        except asyncio.TimeoutError:
            print("Timeout connecting to", ConnectionOptions.ip_address)
            return

        method = "Switch.Toggle"
        params = {"id": 0}
        response = await device.call_rpc(method, params)
        pprint("toggle response:")
        pprint(response)

if __name__ == "__main__":
    asyncio.run(test_rpc_device())

All the authorization logic should be handled in wsrpc and not in rpc_device.
The authorization parameters are pass using the ConnectionOptions class:
https://github.com/home-assistant-libs/aioshelly/blob/25296175e96df9e634e9ff9ed3a6f4a68e9410dd/aioshelly/common.py#L20-L28
Please look at the example how we use it for Gen1 devices: https://github.com/home-assistant-libs/aioshelly/blob/main/example.py

Took another stab at it

All the authorization logic should be handled in wsrpc and not in rpc_device.

Moved

The authorization parameters are pass using the ConnectionOptions class:

Passing password in using ConnectionOptions

If I'm not wrong, there should be a way to know if device requires auth without doing a try/except.
Simone

If I'm not wrong, there should be a way to know if device requires auth without doing a try/except.
Simone

We do, same as for Gen1, @figadore I highly suggest to look at how we implement it for Gen1. /shelly should include a flag if auth required.

If I'm not wrong, there should be a way to know if device requires auth without doing a try/except.

https://shelly-api-docs.shelly.cloud/gen2/Overview/CommonDeviceTraits/#authentication-process
I tried to get this to work with just the requires_auth property, but I can't find a way. The docs seem to indicate that you get the challenge parameters from the first 401 response. If you know how else this can be accomplished, let me know

@thecode , @chemelli74, I wasn't able to find the auth challenge parameters in the initial request. The requires_auth property of RpcDevice can be incorporated somewhere if needed, but it still looks like this won't help to avoid doing a try/catch to get the params needed to construct the auth property for future requests. Let me know if I'm missing anything, or if there's anything else I can do to improve this PR

@thecode , @chemelli74, I wasn't able to find the auth challenge parameters in the initial request. The requires_auth property of RpcDevice can be incorporated somewhere if needed, but it still looks like this won't help to avoid doing a try/catch to get the params needed to construct the auth property for future requests. Let me know if I'm missing anything, or if there's anything else I can do to improve this PR

Check the the data in /shelly or look at the example I linked for Gen1

Check the the data in /shelly

@thecode What/where is /shelly?

look at the example I linked for Gen1

Gen 1's BlockDevice class uses self.options.auth and self.requires_auth (e.g. here), but I don't think either of these can be used to prevent an initial request that produces a 401, if that's what you're suggesting. The workflow as described by the Shelly docs is as follows. Note that there is no way (that I know of) to provide credentials in 3. without getting the response from 2. at least once.
Steps in the process:

1. Client requests a protected resource without providing credentials.
2. Server response containing error 401 (unauthorized) is received.
3. Client requests the same protected resource but this time providing credentials.
4. The request is successful and access to the resource is granted.

If it's not what you're suggesting, I'm all for consistency, so what other areas should be changed so the Gen2 auth lines up more closely with Gen 1?

Check the the data in /shelly

@thecode What/where is /shelly?

Check auth_en from http://ip_address/shelly:
{
  "name": "Test 1Plus",
  "id": "shellyplus1-**redacted**",
  "mac": "**redacted**",
  "model": "SNSW-001X16EU",
  "gen": 2,
  "fw_id": "20220308-100547/0.10.0-g4eda0ff",
  "ver": "0.10.0",
  "app": "Plus1",
  "auth_en": false,
  "auth_domain": null
}

@figadore thanks for working on this!

Thanks for the feedback. I ended up revamping my home network to accommodate the lack of auth support in gen 2 Shelly, so my immediate need for this has been reduced. Additionally, my life has become busy again, but I do plan on getting back to this in the coming weeks. Meanwhile, I'm definitely not against anyone hijacking this PR to bring it to completion (or even scrapping it and starting over)

Replaced by #209

Replaced by #209

authors: chemelli74 figadore thecode

repo: home-assistant-libs/aioshelly


text:
Refactor the tests for forecast.solar

This PR replaces the old tests with new ones, up to 94% codecoverage.

Add new package: aresponses, syrupy and pytest-freezer
Add new CI, which testing matrix for python 3.11, 3.12 and upload coverage to codecov (add key in repo secrets!)

My proposal is to keep the CI as I initially committed, because even with the last suggestions (one last commit) I see that the coverage file is not found. So I'd rather keep what I know for sure works, than continue to muddle through.

zwave-js is using different upload/download artifact versions,
Currently codecov does not see a config file, so nothing is uploaded...

@MartinHjelmare can you add a codecov token secret to this repository?


text:
Update nginx.conf

My propose is to use only TLS v1,2 and 1,3 with cipher suite recommended by https://wiki.mozilla.org/Security/Server_Side_TLS.
In march 2020 many web browsers  will drop support for the encryption protocols TLS 1.0 and TLS 1.1.

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

Please update the changelog and bump the version on the config file.

Ok, I'll do everything this evening. And I will modify also the HSTS parameter as recommended by Mozilla

authors: homeassistant jumping2000 pvizeli

repo: home-assistant/hassio-addons


text:
Integrations don't show anything

When i'm going to the integrations screen in settings and click on an integration I don't see anything on the screen.

When checking the error log I see this error:
http://hassio.local:8123/frontend_latest/app-5e219b20.js:91:305 Uncaught Error: The intl string context variable 'fabrikant' was not provided to the string 'door {fabrikant}'
And from the console:
app-5e219b20.js:2108 Uncaught Error: The intl string context variable 'fabrikant' was not provided to the string 'door {fabrikant}'     at MessageFormat.format (app-5e219b20.js:2108)     at HTMLElement.<anonymous> (app-5e219b20.js:2116)     at runMethodEffect (app-5e219b20.js:1067)     at Function._evaluateBinding (app-5e219b20.js:1067)     at Object.runBindingEffect [as fn] (app-5e219b20.js:1067)     at runEffectsForProperty (app-5e219b20.js:1067)     at runEffects (app-5e219b20.js:1067)     at HTMLElement._propagatePropertyChanges (app-5e219b20.js:1067)     at HTMLElement._propertiesChanged (app-5e219b20.js:1067)     at HTMLElement._flushProperties (app-5e219b20.js:1446)
I'm on version 0.80.0 and supervisor version 135.

Did fixed this by removing the database and let it generate a new one.

I have the same issue. I use MariaDB and created a new database. Error stil persist.
2018-11-02 14:01:09 ERROR (MainThread) [frontend.js.latest.201810261] https://myurl:8123/frontend_latest/app-c039924c.js:91:1362 Error: The intl string context variable 'fabrikant' was not provided to the string 'door {fabrikant}'

authors: Blackpander tdolder

repo: home-assistant/hassio


text:
Widgets do not appear in 1.6.0 version

Hello,
I have problem with widgets in 1.6.0 version. I can't create any. In 1.5.0 everything was ok. Old widgets don't work
Bug report grom android on attachement.
I'm using Xiaomi mi 8 se, android 9 and Nova launcher

There was a change to how widgets worked that very likely broke the old widgets.  However, you should be able to create new ones.  Is this screenshot from trying to create a new widget or launch an old one?  It looks like a widget configuration crash.

FWIW I was able to create a widget in the latest build.  I did not carry any over.  Sometimes we do need to start over.

@KBerstene this screenshot is taken after deleting old widgets and trying to create a new one.

@piotrdal Thanks for the info.  I think I have an idea of where this is originating from, but I'd like to gather a bit more info, if you don't mind.  It looks like you might have a service in a format that was unaccounted for in the widget configuration setup, specifically the service auto-populate method.  If I can narrow down what the service is (it doesn't seem to exist in my system), then I might be able to fix it.
I'm working in Lovelace, so I don't know if this is different for you.  If you go into Home Assistant and select Developer Tools, you should have a Services tab available.  If you type "log_event" in that service box, I am curious if it will auto-complete a domain and service (e.g. homeassistant.log_event).  If it does, could you please provide a screenshot and perhaps the name of the integration you're using that would have the log_event option?

@KBerstene I Hope it's what you need...
i'm using edgeos integration

@piotrdal That was exactly what I was looking for.  It looks like the edgeos log_events field doesn't conform to how the rest of the Home Assistant services are laid out.
For future notes:
In edgeos' services.yaml, the log_events field needs to be changed to have a description member rather than just being a string member itself.
However, this doesn't fix all possible cases for importing services to the app.  I'll have to look into what changes can be made to assure that this issue doesn't come up in the app if any other components are similarly non-conformist.

@KBerstene 👍  We shouldn't crash, but I don't think we should go too far out of way to handle custom components that don't follow the standard.  We might be able to add a check for this in HA it's self to have the custom component not load at all if not conforming.  Not sure how @balloob feels about that plan?

@JBassett I agree, we should just have it not load the service if it fails for whatever reason.  However, my only hesitation there is that we might want to add in some sort of "add custom field" button to be able to add an extra field to service data if the service you're trying to call doesn't auto-populate the fields.

@KBerstene commenting log_events in services.yaml from edgeos component enables creating widgets. Thanks a lot :)
Btw - on 1.5.0 it was working without any problems with edgeos component fully enabled

@piotrdal Awesome!  I'm glad that works.  You could try editing your custom_components/edgeos/services.yaml with the correction I proposed here and see if that would enable the widget configuration page to load the log_event service correctly.

Ok...hmmm...I don't know exactly how it can be changed... The services.yaml from edgeos component looks quite the same to me as the services.yaml from your link except for the comments...

I agree with @JBassett. We're not going to support formats that do not conform to our services format.
Home Assistant currently doesn't check it because it is provided by the developer, and so should follow our formats (but I guess it doesn't always).

authors: JBassett KBerstene balloob dshokouhi piotrdal

repo: home-assistant/home-assistant-android


text:
Nest no longer being loaded after upgrade to 0.81.5

Home Assistant release with the issue:
0.81.5
Last working Home Assistant release (if known):
0.81.0
Operating environment (Hass.io/Docker/Windows/etc.):
Hasbian
Component/platform:
Nest platform
Description of problem:
After upgrading to 0.81.5 nest platform is not working anymore. No climate entity is available.
Nest is added to the configurated integrations but is says "This integration has no devices."
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
nest:
  client_id: !secret nest_client
  client_secret: !secret nest_secret

Traceback (if applicable):
2018-11-03 14:39:43 WARNING (MainThread) [homeassistant.components.climate] Setup of platform nest is taking over 10 seconds.
2018-11-03 14:39:43 WARNING (MainThread) [homeassistant.components.camera] Setup of platform nest is taking over 10 seconds.
2018-11-03 14:39:43 WARNING (MainThread) [homeassistant.components.binary_sensor] Setup of platform nest is taking over 10 seconds

Additional information:

I noticed some weirdness/slowness with my Nest components earlier this morning prior to updating to 81.4.  Starting to wonder if there's a problem with the Nest API itself and not HA.  Earlier (prior to updating, was still on 81.2) I went to adjust my thermostat in HA and it didn't adjust.

Same here. Reverting back to 0.81.2 fixed it in my case.

Same here. Had to revert back to 0.81.2 to get my nest connection back.

Reverting did not fix it for me. I was on 0.81.4 for the last day or so and it worked fine till this morning, going back to 0.81.2 didn't help.  Seems more like an issue with the Nest API.

authors: ParadingLunatic bachya brg468 dvand nelbs

repo: home-assistant/home-assistant


text:
Unable to reset utility_meter unless specifying tariff.

Home Assistant release with the issue:

0.87.1
Last working Home Assistant release (if known):
Unknown
Operating environment (Hass.io/Docker/Windows/etc.):

Debian venv
Component/platform:

https://www.home-assistant.io/components/utility_meter/
Description of problem:
It is not possible to call the utility_meter.reset service on the sensors created by the component, this service can only be called on utility_meter.* entities.
As these entities are only created when using the tariff config option, it is not possible to reset the meter unless specifying at least one tariff.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
# Not possible to reset.
utility_meter:
  energy:
    source: sensor.energy_in_kwh
    cycle: monthly

# Can be reset
utility_meter:
  energy:
    source: sensor.energy_in_kwh
    cycle: monthly
    tariffs:
      - option

Traceback (if applicable):

Additional information:
The sensors should either be changed to utility_meter type entities (preferred as they are part of that component) or it should be possible to call the utility_meter services on sensor entities.

It was never supposed to be exposed
https://github.com/home-assistant/home-assistant/pull/20878

The reset service should be exposed. The tariffs are not always needed.
In this case only the reset service should be available, the next tariff should not be available.

authors: cnrd dgomes imval


text:
Z-Wave switch - turning on and off after HA update

Home Assistant release with the issue:

Home Assistant 0.102.3
Last working Home Assistant release (if known):
Home Assistant 0.101.0
Operating environment (Hass.io/Docker/Windows/etc.):

Docker
Integration:

Z-Wave
Description of problem:
I upgraded from 0.101 to 0.102.3 version and one Z-Wave switch (other five worked OK) was stuck in an endless loop of turning it and on and off.  I tried all the steps (soft reset, stop network, heal network) in 'Z-Wave Network Management' but that didn't resolve this issue. It's been a while since I touched these Z-Wave switches. I did multiple restarts of HA but that didn't resolve this issue. I had to turn off the breaker switch to stop this switch issue.
After the last restart, I noticed this entry in the log file. Now all Z-Wave switches are offline.
2019-12-03 17:42:49 WARNING (Dummy-12) [openzwave] Z-Wave Notification DriverFailed : {'notificationType': 'DriverFailed', 'homeId': 0, 'nodeId': 255}
2019-12-03 17:47:29 WARNING (MainThread) [homeassistant.components.zwave] Z-Wave not ready after 300 seconds, continuing anyway
2019-12-03 17:47:29 INFO (MainThread) [homeassistant.components.zwave] final network state: 1 Driver failed
2019-12-03 17:47:29 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/zwave/__init__.py", line 892, in _finalize_start
    network.set_poll_interval(polling_interval, False)
  File "/usr/local/lib/python3.7/site-packages/openzwave/network.py", line 894, in set_poll_interval
    self.manager.setPollInterval(milliseconds, bIntervalBetweenPolls)
  File "/usr/local/lib/python3.7/site-packages/openzwave/network.py", line 564, in manager
    raise ZWaveException(u"Manager not initialised")
openzwave.object.ZWaveException: 'Zwave Generic Exception : Manager not initialised'

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

arch
x86_64

dev
false

docker
true

hassio
false

os_name
Linux

python_version
3.7.4

timezone
America/Chicago

version
0.102.3

virtualenv
false

After another restart, I was able to bring all nodes except the one which has this issue. I removed the node via Z-Wave Network Management.
Later I manually turned off the switch by  resetting to factory default

2019-12-03 20:12:04 INFO (SyncWorker_2) [homeassistant.components.zwave] Sending 1 test-messages to node 3.
2019-12-03 20:12:51 INFO (SyncWorker_9) [homeassistant.components.zwave] Trying to remove zwave node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594093060096}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594101481476}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594098483252}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594098483268}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726660}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726673}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726696}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726705}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726724}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726742}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726760}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726776}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726788}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594102726806}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594103037959}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594103037975}) on node 3
2019-12-03 20:12:51 WARNING (Dummy-12) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 72057594103037991}) on node 3
2019-12-03 20:12:51 DEBUG (Dummy-12) [homeassistant.components.zwave] Removing Entity - value: 3-72057594093060096 - entity_id: switch.ge_12722_onoff_relay_switch_switch_2
2019-12-03 20:12:51 DEBUG (MainThread) [homeassistant.components.zwave] Removing Device - de5129e2567248fc956fb4d4970c0945 - Unknown Node 3
2019-12-03 20:13:37 INFO (SyncWorker_2) [homeassistant.components.zwave] Z-Wave heal running


text:
Sony Bravia smart TV module doesn't show HDMI inputs on sources

Home Assistant release (hass --version):
0.30.2
Python release (python3 --version):
Python 3.4.2
Component/platform:
Sony Bravia
Description of problem:
This module doesn't seem to pick up the HDMI sources on my TV.
Before i deleted all of my TV channels, it showed all channels saved on my TV in the sources drop down menu so it can definitely find sources available on my TV just not HDMI.
Would be grateful for any clarification if the intended behavior is only to show TV channels in the sources menu.
Expected:
I would have hoped it would have picked up my HDMI list and allowed me to switch them.
Problem-relevant configuration.yaml entries and steps to reproduce:
media_player TV:
  platform: braviatv
  host: 192.168.0.XX

Thanks

Under sources I only find TV Channels.
I developed a Sony Bravia TV Remote application so I know that there is some kind of missunderstanding of the implementation.

authors: Charliedean CoalaJoe


text:
asuswrt device_tracker shows device as away when router in AP mode

Home Assistant release (hass --version):0.32.2
Python release (python3 --version):Python 3.5.2+
Component/platform:device_tracker/asuswrt
Description of problem:
ASUS RT-N66U router with firmware 380.61 in AP mode shows device as away when it is home.
Expected:
The device should be shown as home.
Problem-relevant configuration.yaml entries and steps to reproduce:
device_tracker asus:
  - platform: asuswrt
    host: IPADDRESS
    username: USERNAME
    password: PASSWORD
    mode: ap
    track_new_devices: true

Install firmware 380.61 on an ASUS router that supports it. I assume it doesn't need to be a ASUS RT-N66U.
Configure the ASUS device tracker component in the configuration.yaml as shown above
Connect a device to the router

The device shows as away instead of at home.

Additional Info:
The problem is because the 'arp -n' command  that is issued on the router to get the mac addresses returns the address in upper case but asuswrt.py expects it in lowercase.

You can convert it with string.lower(). Change it on code and test it. If it will work you can make a PR :+1:

I got it working last night.  I will attempt to get a PR done in the next couple of days but wanted to look at writing some unit tests.

@Binkoth @pvizeli hey, any updates? I couldn't find the right place to add .lower().

Also, the device in question doesn't actually appear in arp -n, even though it shows in { wl -i eth2 assoclist & wl -i eth1 assoclist ; }
So not sure if .lower() actually helps.

Hm. Have you tested this in 0.33? I attempted a fix on this in #4189 . It works well for me, at least (I also had devices that wouldn't show up in arp).
If you try running nvram get client_info_tmp you probably will find the device in question.
assoclist provides such updated and consistent data that I've always wondered if it'd be better to toss out the MAC-to-IP resolution part of asuswrt.

authors: Binkoth EricReiche linjef pvizeli


text:
Update init.py

Description:
When using Ecosmart dimmable light bulbs (link from home depot below), the value of model is not string type, it is a long byte array which throws an exception when calling slugify(model).
The only way to add/use the those Ecosmat Zigbee bulbs is using the above fix which I have to apply now as custom component to override the base ZHA component.
Bulbs:
https://www.homedepot.ca/en/home/p.connected-60w-equivalent-daylight-5000k-a19-dimmable-led-light-bulb.1000835496.html

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

This seems like something that should be fixed upstream in the bellows library

authors: alexgerch balloob homeassistant


text:
[WIP] Allow custom order from config for Daikin list of operation, fan modes and swing modes

Description:
Just sort alphabetically those dropdowns.
Checklist:

[x] The code change is tested and works locally.

If the code communicates with devices, web services, or third-party tools:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Hi @fredrike, this was what u wanted in order to sort the operation modes for Daikin. Right ?

Yes I think so (will test it tomorrow or so). It would be great if you could do the same for fan and swing mode.
I do like Heat better than Hot too but that is just a matter of taste (and perhaps there is a road map to support translated options and then this will be a no issue).
Thank you!
(now I just need to figure out how to move the historical sensor data to the new component, but that is another problem).

I've just sorted those texts alphabetically.
However I've found your old post and u wanted manual sorting.
Is this ok ?

I can't visualize it, can you please drop a screen shot.
BTW, did you keep the sensors as separate sensor or do I need to use templating to get access to them?

I don't understand ur 2nd question, the daikin sensors are located in a separate file in sensors/daikin.py

It looks good, but imho the modes should be grouped ie hot and cold should be together..
What about this manual sorting: off, auto, dry, cool, heat, fan?

@fredrike i've marked this PR as wip to not be merged by mistake.
Anyway I'm pretty sure that custom order is what u actually want specified from the config. It will be optinal and can be used for anyone to specify their own order and of course even remove values not supported by their models.
Can u confirm that this is what want to know if I should finish this or otherwise close it ?

Yes you are absolutely right custom order is what I'm talking about!
But your changes are a step in the right way.

Hi guys,
Slightly off topic, but I'm new to HA so don't know where else to ask.
I have 6 Daikin units and all are detected and work fine, but there is one "flaw/feature" that prevents me from using HA daily over native Daikin app.
When I turn off a unit through HA it changes the mode to "auto"  no matter what mode was previously selected with the unit. That is really a pain, since if some units remain on "hot" and some are on "auto" I can even get mode conflicts (if temp is set on 22 and auto, sometimes it can even start cooling).
Please let me know if there is any way around this (even if I can setup "hot" as default mode and change it to "cold" in summer, that would be an improvement.).
Cheers!

authors: Notrial fredrike rofrantz


text:
Fix sonos default errorcodes

Description:
This avoids a NoneType exception when no errors are flagged to be ignored.
Checklist:

[X] The code change is tested and works locally.

If the code communicates with devices, web services, or third-party tools:

[X] Local tests with tox run successfully.
[ ] New dependencies have been added to the REQUIREMENTS variable.
[ ] New dependencies are only imported inside functions that use them.
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

Hi,
With new version 0.64 there are problems. No picture of the album in web interface and there is no possibility to start or stop music playback.
Could you check?
Tnx

This errors. I can't select what is played.
media_player.select_source
{  "entity_id": "media_player.kitchen", "source" : "Pink Martini Radio"}

Error: Error on select_source with UPnP Error 800 received:  from 1.1.1.1
I was able to get something from my speaker by
media_player.turn_on
{ "entity_id": "media_player.kitchen" }

@bbrendon Please create a new issue and describe in details what that source is as well as what "I can't select what is played" means.

authors: amelchio bbrendon ranathan14


text:
Add config entry for LIFX

Description:
This is a minimal PR to add a config entry for LIFX. I plan additional PRs for a more complete experience.
Breaking change: Configuring LIFX via light platform config has been deprecated. LIFX can now be configured from the integrations page in the config panel and advanced configuration is available through the LIFX component.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#6565
Example entry for configuration.yaml (if applicable):
lifx:
  light:
    server: 10.0.2.14
    broadcast: 10.0.2.255

Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox.

If user exposed functionality or configuration variables are added/changed:

[X] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[X] New dependencies have been added to the REQUIREMENTS variable (example).
[X] New dependencies are only imported inside functions that use them (example).
[X] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[X] New files were added to .coveragerc.

I refrained from moving more stuff into the component in order to keep the PR small. If you think it's better to move the config schema in this PR, I can work on that.

Since config validation is part of the component, it should be there.

authors: amelchio balloob


text:
mqtt: Fix logic when embedded and broker configs are present.

Description:
Fix logic in mqtt initialization.
Unable to start broker and auto-configure MQTT.
Example entry for configuration.yaml (if applicable):
I specify a "compex" configuration for the embedded MQTT server and
a broker configuration:
mqtt:
  embedded:
    listeners:
        default:
            max-connections: 50
            type: tcp
            bind: 0.0.0.0:8081
            ssl: 'on'
            certfile: /home/pi/ssl/server.crt
            keyfile: /home/pi/ssl/server.key
    timeout-disconnect-delay: 2
    auth:
        plugins: ['auth_file']
        allow-anonymous: false
        password-file: /home/pi/.homeassistant/mqtt/password
  broker: mascot
  port: 8081
  client_id: home-assistant-1
  keepalive: 60
  username: <>
  password: <>
  certificate: /home/pi/ssl/server.crt
  protocol: 3.1.1

In the current code, because both CONF_EMBEDDED and CONF_BROKER are specified, we would fail the MQTT autoconfiguration at line 199.
Autogenerated broker_config is useful only if CONF_EMBEDDED is not present (line 196).
If CONF_EMBEDDED is not present, but CONF_BROKER is, we won't even start the mqtt server, we will not autogenerate a broker_config, so we must set the broker with CONF_BROKER data.
if CONF_EMBEDDED is present, we will start the mqtt server, but the broker autoconfig will not be generated, so we must rely on a CONF_BROKER.
In consequence, it does not matter if CONF_EMBEDDED is present or not at line 198.
Checklist:
If the code does not interact with devices:

[x] Local tests with tox run successfully.
[ ] Tests have been added to verify that the new code works.

Fix test to prevent early exit of mqtt init handler when
both embedded and broker configs are present.
Signed-off-by: Gwendal Grignou gwendal@gmail.com

Looks good! :dolphin:

authors: balloob gwendalg