"Images Lazy Load" does not work well with dynamic added images

e.g.
Dom7('#imgtest').append('<img data-src="http://lorempixel.com/500/500/nature/3" width="100%" class="lazy lazy-fadeIn">');
http://codepen.io/Poordeveloper/pen/RrVOjq
though I can use https://github.com/aFarkas/lazysizes instead, but I still hope F7 can be more bugless.

In this case you have to init lazy script manually using, for example: app.initImagesLazyLoad('.page');

Where should I write app.initImagesLazyLoad('.page');.
After var myApp = new Framework7(); ?
I should be -> myApp.initImagesLazyLoad('.page');

Try adding this before adding dynamic view
$$('div.lazy').trigger('lazy'); for
or
$$('img.lazy').trigger('lazy'); for
this works in some conditions


new_feature: Sign Up form shifts to the left of the screen

Fixes #
#3463
Describe the changes you have made in this PR -
Sign Up form shift to the left portion of the screen @width : 768px
Screenshots of the changes (If any) -
Before:

After

@vedant-jain03 is it okay now??

@vedant-jain03 is it okay now??

Almost, make code climate happy!


Error on plugin startup when solar radiation is enabled

Describe The Bug:

During Homebridge and plugin startup this appears in the logs
This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.
To Reproduce:

This only appears when solar radiation is enabled
Expected behavior:

Expect not to see error message about zero values, solar radiation is usually zero at night :)
Logs:
[22/01/2024, 21:10:02] [homebridge-ambient-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.
[22/01/2024, 21:12:00] [homebridge-ambient-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.
[22/01/2024, 21:14:02] [homebridge-ambient-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.
[22/01/2024, 21:16:00] [homebridge-ambient-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.
[22/01/2024, 21:18:02] [homebridge-ambient-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 0 exceeded minimum of 0.0001. See https://homebridge.io/w/JtMGR for more info.

Plugin Config:
 "name": "Our Weather",
    "apiKey": "xxxxx",
    "applicationKey": "xxxx",
    "temperatureSensors": true,
    "humiditySensors": true,
    "solarRadiationSensors": true,
    "platform": "AmbientWeatherSensors"

Screenshots:

Environment:

Plugin Version: 1.2.1
Homebridge Version: 1.7.0
Node.js Version: v20.9.0
NPM Version:
Operating System: Raspian>

@WotAGitUR thanks for the detailed bug report.
this issue has been resolved with v1.2.2

Thank you @peledies
Installed that version and no longer see that appearing in the logs :)


Tidy/change new icons (locks + ear)

I cleaned up both lock icons. I also changed them such that they use the shades of red and green that are present elsewhere in the theme.
I also changed the ear icon to an outlined avatar as I think this reads better. (also the human ear just feels a bit weird if I'm honest)
This isn't part of the PR, but I also suggest renaming 'ear.svg' to 'listen.svg' or something like that to improve clarity even if you reject this PR.

It would be good if you provided some images that show the new icons :point_up:

@chili-b are the red and green tones you used for the looks the same tones that are used in other Mumble icons?
Looking at the icons here on GitHub I still prefer the stronger tones I originally used for them but as has been mentioned in #28, it's inconsistent with the rest of the UI. Thus if you have chosen the colors to match the tones used throughout the rest of the UI, I'm totally fine with the changes you made to the lock icons :+1:

The ear on the other hand is a different issue. I see how using the proposed icon instead of an actual ear stays closer to the icon set we already have. Thus this is a plus for consistency.
On the other hand this could also be a drawback in this case as the feature related to the ear icon is completely new and therefore it might be worth it to have a new icon for it (in order to clearly communicate that this is a new feature...
I think ultimately though the choice here should only be made by comparing the icons within the UI instead of as individual icons.
I will prepare a few screenshots that we can then compare side-by-side...

Okay so here we go:

I think I still prefer the old ear icon over the new one. But that could be due to me already being used to the "old" ones...
Another advantage I see in with the old icons is that I could tell more quickly in which channel MyUser actually is in and which channels that user only listens to (simply because the listener icon is completely different from a user's icon).
Another issue with the proposed icon is that users could think that it marks a new transmission state (similar to silent, speaking, shouting, whispering). It could of course be debated whether listening to a channel should indeed be seen as a new state in this area :thinking:

I think we'll need a few more opinions on this topic.
/cc @davidebeatrici @Kissaki @ZeroAbility @toby63

To answer your question: Yes, I copied the hex codes for the red and green tone from the user avatar and mute icon respectively.
I think that your concern about users confusing listen with a new transmission state is valid, but I'm leaning more towards saying it's okay because in the rest of the theme, transmission is always indicated by a change in colour as well as two curved lines on each side of the icon. Neither of these features are present in my proposed icon.

Thx for pinging me :slightly_smiling_face:.
Regarding:

The Lock icons:

Colour:
Yes I think using the original colours is good.
Though I now think the red tone is a bit too orange (not just here, but in the other official icons as well), maybe we could test    slightly different colours for the red icons.
I would like to have a tone that is a little more red, but still a bit darker; @Krzmbrzl's icon is a bit too bright imo.

Unlocked state:
The unlocked icon can be used as is, but if I could, I would maybe change it, so it represents the open state a bit better; two ideas:
- a hanging lock (the lock is turned by 20 degrees maybe)
- a green key symbol (instead of a lock)

The ear icon:
I agree with @chili-b that the human ear looks weird, so we should use something else.
Nonetheless I also agree with @Krzmbrzl that the "empty" avatar is not sufficient for this.
How about a radiostation type of icon (duckduckgo search) ? I just remembered that something similar was used in the classic theme for the avatar. Nonetheless I think that something like this could clearly indicate the purpose of the icon.

I have another suggestion for the listening indicator: Perhaps the link icon could be incorporated as users listening to channels is somewhat analogous to linking channels. I think that while the radio tower is related to the behaviour, the icon should try to avoid introducing new metaphors if possible.

I have another suggestion for the listening indicator: Perhaps the link icon could be incorporated as users listening to channels is somewhat analogous to linking channels. I think that while the radio tower is related to the behaviour, the icon should try to avoid introducing new metaphors if possible.

I think the link icon will not be understood.

Using the chain would definitely be an option.
What was also suggested in our meeting today was to use just the head of the current avatar icon (aka: a green circle) and then put some simple headphones on that and then use this as the icon for listeners.

All great arguments here, thank you all for the very constructive discussion.
Although this may not happen now or ever, I’d love to see a design documentation that shows and describes the icons with argumentation why they are used, for a feature and in relation to others.
I agree with all of your arguments.
Listening in results in a similar thing like linking channels. So we have a connection here. At the same time, it is on a user level. I do not think linking works here, because the user is an actor, not a structuring object/room. I may be worth thinking about replacing the link icon in the future for a more consistent icon theme between the two, but for now we can just look at the user.
We also make linked channels cursive, so this may be worth a thought, but I think it's ultimately not helpful and more confusing.
I am a little confused by the screenshot with the ear-icon replacement. Where am I as a user in this screenshot? I see two "listen in" actors in two channels. Am I in a different channel that is not visible?
If the user listens in from another channel I would say they are more, closer connected to you. So the icon should be stronger rather than weaker. The suggested ear replacement is definitely a lot weaker than the default all green. So I think that icon would go against intuition and be misleading.
My suggestion would be to try and use the ear, or even a simpler ear, and remove the "realistic" coloring. Simplify the ear icon to something that fits our icon and color scheme.
Other users listening in to you is represented quite well with an ear icon [directed at you].

I think we should keep in mind that the icons are very small, so a too detailed approach is maybe not good.
How about keeping the avatar but giving it a different colour?
For example black?
This would indicate that the user is not really there, but still there (like a phantom).

Oh and I support @Kissaki's idea of a documentation.
I added a seperate issue for tracking that: #33.

I am a little confused by the screenshot with the ear-icon replacement. Where am I as a user in this screenshot? I see two "listen in" actors in two channels. Am I in a different channel that is not visible?

The local user (aka "you") is the one highlighted in bold font. The screenshots are thus taken from different client's perspectives because I messed up on selecting the same one for the second screenshot xD

We also make linked channels cursive, so this may be worth a thought, but I think it's ultimately not helpful and more confusing.

Listeners are already rendered in italics

If the user listens in from another channel I would say they are more, closer connected to you. So the icon should be stronger rather than weaker. The suggested ear replacement is definitely a lot weaker than the default all green. So I think that icon would go against intuition and be misleading.

I don't think I would follow this argument here. I would consider a user that is in the same channel as I am to be "closer" to me than someone that is only listening to what is spoken in my channel :thinking:

My suggestion would be to try and use the ear, or even a simpler ear, and remove the "realistic" coloring. Simplify the ear icon to something that fits our icon and color scheme.

Hm - let me see what I can come up with :thinking:

Other users listening in to you is represented quite well with an ear icon [directed at you].

That I definitely agree on :+1:

I think we should keep in mind that the icons are very small, so a too detailed approach is maybe not good.

Absolutely. That's what makes this so hard ^^

How about keeping the avatar but giving it a different colour?
Or different colours (lika two colours for example).

Even though that would of course be possible, I think it just wouldn't represent what this is supposed to stand for really well :thinking:

Here are a few more suggestions for the ear icon:
Bunny ears

Green ear

Headphones

Bunny ears: I don't think they quite fit into the rest of the theme
Green ears: The shape still has the same complexity
Headphones: This one will probably be harder to recognize on first glance
The problem I faced when trying to reduce the ear shape's complexity was that as soon as I take away strokes from it, it's no longer recognizable as an ear (imo) :thinking:

What about representing the idea of listening instead of the ear itself using something like this? The avatar is smaller than the regular one, so that should help with recognition as well

:thinking: Honestly I don't think any of the suggestions are good (no offense).
What about this:

Some kind of robot icon:
https://duckduckgo.com/?t=ffab&q=bot+icon&iax=images&ia=images
(Would also be good for Bots by the way).

A tag like "Listener":
This would make things very clear and we wouldn't need a symbol.
In combination we could use a different coloured avatar.

@chili-b I think I like your suggestion :+1:
We probabky have to experiment with the size relations of the avatar vs the sound wave but the general idea is pretty nice. And it should also fit ibto the existing icons nicely.
@toby63 I don't think I like the idea of a robot icon. I would approve it for actual bots but listeners are no bots.
And I'm not really sure what you mean by "tag". Where do you want to display such a tag?

I don't think I like the idea of a robot icon. I would approve it for actual bots but listeners are no bots.

:thinking: I guess you are right.
Maybe something else:

A symbol that resembles a placeholder...
A greyed out avatar? (though that would be against @Kissaki's argumentation)

And I'm not really sure what you mean by "tag". Where do you want to display such a tag?

I found a better word for it now: a label, just like labels on Github it could be behind the username or before it.
Some programs add them to the username (without special colouring etc.), like [Admin] user1.

Just had a crazy idea, what about a vanishing avatar?
You know, like star trek beaming. :smile:

Regarding the lock symbols:
I just noticed that lines thickness is a too thin imo (I know perfectionism).
But look at this screenshot from @Krzmbrzl: https://github.com/mumble-voip/mumble/pull/3929#issuecomment-569495834.
I would:

increase the thickness of the lines (they could be nearly as thick as the central line (strike-through) in muted_suppressed.svg) and
maybe fill the lock with colour instead of the keyhole.

So far I like the green icon and also the idea of extending the existing user icon with additional state. Between the two, from the screenshots without gui context, I think I still prefer the ear though.
What's the problem with the ear complexity? Is it an issue on small sizes?

If the user listens in from another channel I would say they are more, closer connected to you. So the icon should be stronger rather than weaker. The suggested ear replacement is definitely a lot weaker than the default all green. So I think that icon would go against intuition and be misleading.

I don't think I would follow this argument here. I would consider a user that is in the same channel as I am to be "closer" to me than someone that is only listening to what is spoken in my channel 🤔

I agree someone in my channel is closer to me. They also hear me. But someone in another channel listening in is closer to me than someone in another channel not listening to me. I guess at the moment we do not have separate icons for own vs other channel though, ppl that can hear and those who can not. :)

I think we should split this PR. There seems to be two concerns here. The lock icons color, which was discussed and seemingly quickly decided upon. And the ear icon which we are still discussing.
@chili-b Can you split the two?

If it is about small sizes, how about filling the inner ear black to reduce complexity? Sketchup something like

What’s our icon size? 32px?

A greyed out avatar?

This one is actually already used in 1.4.0

What's the problem with the ear complexity? Is it an issue on small sizes?

I assume so. Though personally I did not have concerns ^^

If it is about small sizes, how about filling the inner ear black to reduce complexity?

I guess that could work. However as it stands to me it is now rather hard to recognize this as an ear without knowing that that's what it's supposed to be :thinking:
Maybe we'd have to adjust the outline a bit as well...

Just sayin, the ear is really "horrible".
It is not only about the perception and size.
It is also about the ear itself, it is something weird, "ugly", "scary", not fitting into the rest of the design.
It reminds me of the classic theme, which also had this weird mouth and stuff.
It is only an advice, but I would stick to the design decision xpoke made and leave such stuff out.
If you can't find a better solution, use one of the ideas by @chili-b.

Here is an example for a two-coloured avatar:

@Krzmbrzl
Could you maybe split the PR (so you could merge at least the correctly coloured locks), as you now start to release dev snapshots of 1.4?
And discuss the ear issue in one of your meetings :slightly_smiling_face: ?

@Krzmbrzl
Could you maybe split the PR (so you could merge at least the correctly coloured locks), as you now start to release dev snapshots of 1.4?
And discuss the ear issue in one of your meetings :slightly_smiling_face: ?

I currently don't have a lot of time and since this is nothing urgent, I don't think I'll get to it any time soon.
If @chili-b splits the PR though, I'll happily merge the changes to the lock icon.
The ear suggestion currently need to be put in the software in order to get some proper screenshots. I did not get to doing that yet for the reasons mentioned above. So if someone wants to speed up the process, it'd be very helpful if these screenshots were created by someone else than me :point_up:

I currently don't have a lot of time and since this is nothing urgent, I don't think I'll get to it any time soon.
If @chili-b splits the PR though, I'll happily merge the changes to the lock icon.
The ear suggestion currently need to be put in the software in order to get some proper screenshots. I did not get to doing that yet for the reasons mentioned above. So if someone wants to speed up the process, it'd be very helpful if these screenshots were created by someone else than me :point_up:

The ear suggestion currently need to be put in the software in order to get some proper screenshots

Yes you are right, that would probably be helpful.
I will see if I have time to do that.

The ear suggestion currently need to be put in the software in order to get some proper screenshots

Yes you are right, that would probably be helpful.
I will see if I have time to do that.

So here is an overview of how the different icon concepts would look in Mumble:
Black Ear by Kissaki:

Headphones by @Krzmbrzl:

Empty Avatar with Send by @chili-b :

Vertical-Cut avatar (green/white) by me:

Vertical-Cut avatar (green/grey) by me:

Original Avatar for Comparison:

So here is an overview of how the different icon concepts would look in Mumble:
Black Ear by Kissaki:

Headphones by @Krzmbrzl:

Empty Avatar with Send by @chili-b :

Vertical-Cut avatar (green/white) by me:

Vertical-Cut avatar (green/grey) by me:

Original Avatar for Comparison:

Thanks for creating the screenshots :+1:

green ear: I still think that turning the ear green makes it even harder to recognize as such
headphones: I think from the examples shown here this actually is one of the most distinct icons (compared to the regular avatar) that has the advantage of symbolizing the act of listening reasonably good.
empty avatar: I really liked the idea when looking at a larger image but in the client it seems like it is barely visible. Maybe this could be changed by increasing the line width in the image?
vertical cut (green/white): This does look strange imo (given that the white part basically merges with the background
vertical cut (green/gray): Looks a lot better but probably suffers the same issues in the dark theme, the other one does in the lite theme

My favorite would in fact be the headphone avatar. The line width of the headphone has to be increased but in terms of visibility and symbolic meaning this is the best option we have so far :thinking:

The UI parts are in general too small; maybe this should be changed.

Nah I don't think so. Making the icons larger would mean that a single user entry requires more space which will make you loose overview more quickly with growing users. And enlarging all icons just be did not found a good icon for one particular use-case yet seems a bit of an overkill anyways :shrug:

Like an arrow -> or two slash lines \ (maybe in green and black), or something like that.

How would that represent someone listening?
If we are looking for a different symbol a microphone might be something to investigate (listening is kinda similar to someone recording what is spoken from a different room) :eyes:

I also still like the idea of adding some kind of label, like listener, behind it.

So if User is the name you'd want something like
<icons> User  (listener)

? Given that listeners don't show any other tags (afaik) this should be okay, I guess. Would have to look at that in code though. If we find a nice icon for it, I think a tag is superfluous though :thinking:

Thanks for creating the screenshots :+1:

green ear: I still think that turning the ear green makes it even harder to recognize as such
headphones: I think from the examples shown here this actually is one of the most distinct icons (compared to the regular avatar) that has the advantage of symbolizing the act of listening reasonably good.
empty avatar: I really liked the idea when looking at a larger image but in the client it seems like it is barely visible. Maybe this could be changed by increasing the line width in the image?
vertical cut (green/white): This does look strange imo (given that the white part basically merges with the background
vertical cut (green/gray): Looks a lot better but probably suffers the same issues in the dark theme, the other one does in the lite theme

My favorite would in fact be the headphone avatar. The line width of the headphone has to be increased but in terms of visibility and symbolic meaning this is the best option we have so far :thinking:

The UI parts are in general too small; maybe this should be changed.

Nah I don't think so. Making the icons larger would mean that a single user entry requires more space which will make you loose overview more quickly with growing users. And enlarging all icons just be did not found a good icon for one particular use-case yet seems a bit of an overkill anyways :shrug:

Like an arrow -> or two slash lines \ (maybe in green and black), or something like that.

How would that represent someone listening?
If we are looking for a different symbol a microphone might be something to investigate (listening is kinda similar to someone recording what is spoken from a different room) :eyes:

I also still like the idea of adding some kind of label, like listener, behind it.

So if User is the name you'd want something like
<icons> User  (listener)

? Given that listeners don't show any other tags (afaik) this should be okay, I guess. Would have to look at that in code though. If we find a nice icon for it, I think a tag is superfluous though :thinking:

So if User is the name you'd want something like

<icons> User  (listener)

Yes. But I would like to have real label, not just text added to the username.
Though the text could be an intermediate solution.

If we find a nice icon for it, I think a tag is superfluous though thinking

I think we will not find any icon that represents it perfectly, so this would be a clear and visible one.

So if User is the name you'd want something like

<icons> User  (listener)

Yes. But I would like to have real label, not just text added to the username.
Though the text could be an intermediate solution.

If we find a nice icon for it, I think a tag is superfluous though thinking

I think we will not find any icon that represents it perfectly, so this would be a clear and visible one.

I almost agree with the "most distinct" argument, but I think that we only recognize the headphones as such, because we know it (if you know what I mean).
Regarding the interpretation: I think users might associate that with something different (like a user who uses a headphone smiley ).

Fair enough. I think users initially thinking about the other client using headphones before realizing what this actually means is not too bad though since at least this would still be about the act of listening (to some degree anyways) which I think speaks for its symbolic character.
In the end however I think that we either have to find more volunteers to evaluate the screenshots or make a decision based on our opinions even though it could be that we recognize certain images (better) because we know what it's supposed to be :shrug:

A microphone is also very hard to recognize at that size.

But maybe better than some of the other approaches since a mic can stand for itself and does not need an auxiliary icon next to it (e.g. a head) to make sure what it is supposed to be. Thus it could use more of the available space for the actual icon.

Yes. But I would like to have real label, not just text added to the username.

So what would be a "label" for you? 'cause you say that icons are too small but it is not text that you had in mind. That now makes me wonder what kind of label you are thinking about :thinking:

I almost agree with the "most distinct" argument, but I think that we only recognize the headphones as such, because we know it (if you know what I mean).
Regarding the interpretation: I think users might associate that with something different (like a user who uses a headphone smiley ).

Fair enough. I think users initially thinking about the other client using headphones before realizing what this actually means is not too bad though since at least this would still be about the act of listening (to some degree anyways) which I think speaks for its symbolic character.
In the end however I think that we either have to find more volunteers to evaluate the screenshots or make a decision based on our opinions even though it could be that we recognize certain images (better) because we know what it's supposed to be :shrug:

A microphone is also very hard to recognize at that size.

But maybe better than some of the other approaches since a mic can stand for itself and does not need an auxiliary icon next to it (e.g. a head) to make sure what it is supposed to be. Thus it could use more of the available space for the actual icon.

Yes. But I would like to have real label, not just text added to the username.

So what would be a "label" for you? 'cause you say that icons are too small but it is not text that you had in mind. That now makes me wonder what kind of label you are thinking about :thinking:

more volunteers

Thats probably a good idea, but they would need to be tested "blind", so they don't know the meaning and we ask them what this symbole means in their oppinion.
I might ask some friends; but then you only get the oppinion through me, which is not verifiable.

But maybe better than some of the other approaches since a mic can stand for itself and does not need an auxiliary icon next to it (e.g. a head) to make sure what it is supposed to be. Thus it could use more of the available space for the actual icon.

In general that would be true, but a microphone is more complicated imo.
It involves very detailed forms (to be recognizable as microphone).

So what would be a "label" for you? 'cause you say that icons are too small but it is not text that you had in mind. That now makes me wonder what kind of label you are thinking about thinking

What I mean is not just adding text to the username like username (text), but to have a real label behind the username like username coloured label with text.
I think there already was a feature request for that somewhere...
But to clarify, that is not a must-have, a simple text would be good as well (i think).

more volunteers

Thats probably a good idea, but they would need to be tested "blind", so they don't know the meaning and we ask them what this symbole means in their oppinion.
I might ask some friends; but then you only get the oppinion through me, which is not verifiable.

But maybe better than some of the other approaches since a mic can stand for itself and does not need an auxiliary icon next to it (e.g. a head) to make sure what it is supposed to be. Thus it could use more of the available space for the actual icon.

In general that would be true, but a microphone is more complicated imo.
It involves very detailed forms (to be recognizable as microphone).

So what would be a "label" for you? 'cause you say that icons are too small but it is not text that you had in mind. That now makes me wonder what kind of label you are thinking about thinking

What I mean is not just adding text to the username like username (text), but to have a real label behind the username like username coloured label with text.
I think there already was a feature request for that somewhere...
But to clarify, that is not a must-have, a simple text would be good as well (i think).

Ah okay so sonething like a colored badge. Yes I think there is a FR for thst indeed.

Ah okay so sonething like a colored badge. Yes I think there is a FR for thst indeed.

I think we should split this PR. There seems to be two concerns here. The lock icons color, which was discussed and seemingly quickly decided upon. And the ear icon which we are still discussing.
@chili-b Can you split the two? They are separate concerns, and can be resolved at different speeds and independently.

Sorry for the late response. I forgot that this PR was still open. I've undone the changes made to ear.svg so the only files modified are the lock icons.

Thanks :+1:


Multiplication of a invest decison value and timeseries data doesn't work

Multiplying an invest decision value with a timeseries value returns an error because then the invest decision value or the timeseries is not recognized, but I think this would be a useful functionality to have.
For example, I have timeseries data with heat output per m2 for solar thermal and would like to multiply this with an invest decision for how many m2 of solar thermal should be built, and use this as the value for my solar thermal supply profile.
I can multiply either the decision variable or the timeseries data by a scalar like this:
    value: 2 * solar_thermal_heat_out_per_m2@hourly_data
    value: 2 * solar_thermal_area_invest:value

However multiplying the decision value by the timeseries data as i would like to doesnt work:
    value: solar_thermal_area_invest:value * solar_thermal_heat_out_per_m2@hourly_data

Example code for all the components:
components:
  # Supply: solar thermal and invest decision on m2
  solar_thermal:
    type: Profile
    mode: fixed
    carrier: heat
    node_to: grid_heat
    value: solar_thermal_area_invest:value * solar_thermal_heat_out_per_m2@hourly_data # multiply m2 built  by heat output per m2
  solar_thermal_area_invest:
    type: Decision
    lb : 0
    ub: 20  # m2
    cost: 10  # €/m2

  # Heat grid
  grid_heat:
    type: Node
    carrier: heat

  # Demand profile and extra destroy profile in case there is more solar thermal than demand
  demand:
    type: Profile
    carrier: heat
    node_from: grid_heat
    value: demand_heat@hourly_data
  destroy_heat_surplus:
    type: Profile
    carrier: heat
    mode: destroy
    node_from: grid_heat
    cost: 1e6

Yea... that's a current limitation of the way we parse "strings in YAML" to what we internally call "expressions". There is a rework (and more related issues) in the internal GitLab (not linking here, but see merge request "#23" there), but we currently do not have any proper solution for that here.
I'll keep this open as it is - maybe I'm able to include this into the currently open redesign in #20 (since then we could keep a few breaking changes in one take). But in the meanwhile, I'll post a "solution" in the next comment.

Workaround:
Since you actually allow for "getting rid of heat" (via destroy_heat_surplus), this could be seen as a curtailable solar thermal asset, right? If it the case that it is okay to not use the full available heat during each time step, then all of this (the curtailment, the investment, and the scaling) are better handled by a Unit (Profiles are not made for this type of thing).
The following could be a reformulation that should work:
  grid_heat:
    type: Node
    carrier: heat

  demand:
    type: Profile
    carrier: heat
    node_from: grid_heat
    value: demand_heat@hourly_data

  solar_thermal:
    type: Unit
    outputs: {heat: grid_heat}
    conversion: ~ -> 1 heat
    capacity: solar_thermal_area_invest:value out:heat
    availability_factor: solar_thermal_heat_out_per_m2@hourly_data

  solar_thermal_area_invest:
    type: Decision
    lb : 0
    ub: 20
    cost: 10

Observe:

The ~ -> 1 heat conversion, which just means "open input" (therefore also no inputs defined), which is just a convenience thing that we have especially for renewables: Generating energy, using a Unit, but - while there certainly is an "input primary energy" - not caring about the actual input use of energy.
Curtailment does not induce costs now (1e6 previously), which may or may not be wanted - but that is an actual difference to your example.
But if there are actual costs to consider they are (almost) definitely not 1000000 EUR per unit of heat, and should then be changed to a correct value (just pointing this out, since - depending on the other data - this 1e6 may be an unnecessary source for numerical problems).

Does that work for now?

This was fixed as part of #20, see this comment for details.

@nyashags Please report back whether this left any special case non-working or whether everything's fixed now.


⚠ Bofrost.fr has degraded performance

In c226d39, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1522 ms

Resolved: Bofrost.fr performance has improved in 7155a9e after 29 minutes.


Dynamically creating overlays with multus

Hi,
I'm trying to use multus to dynamically define topologies. What I call "topology" is a k8s manifest that defines pods and net-attach-def such that the pods have multiple links with each other.
I'm thinking of using flannel for this, since apparently I can have multiple flannel networks. This sounds similar to https://github.com/intel/multus-cni/issues/7 but not quite: I want the creation and deletion of flannel networks to be dynamic. I don't know in advance how many networks I'll need.
I'm unsure if multus will help me here, because if I understand correctly, I'll need to run one flanneld instance for each network, and multus won't help me with that. It will only call the flannel plugin to create the interfaces in the containers, and attach them to the flannel bridge.
Do you have any pointers for what I'm trying to achieve? Or is multus not the right tool for me?

Hey Corentin, I need to think about this -- and I'm replying mobile, so
it's brief (sorry) but... I'm curious about your use case -- would you
attach these dynamically during run-time? That's something we are likely
going to consider for v4, I believe.
Join up the slack at some point, too. Worth discussing and documenting here
to capture the use case. Sounds interesting
On Tue, Sep 4, 2018, 7:48 PM Corentin Henry<EMAIL_ADDRESS>wrote:

Hi,
I'm trying to use multus to dynamically define topologies. What I call
"topology" is a k8s manifest that defines pods and net-attach-def such
that the pods have multiple links with each other.
I'm thinking of using flannel for this, since apparently I can have
multiple flannel networks
https://coreos.com/flannel/docs/latest/running.html#multiple-networks.
This sounds similar to #7 https://github.com/intel/multus-cni/issues/7
but not quite: I want the creation and deletion of flannel networks to be
dynamic. I don't know in advance how many networks I'll need.
I'm unsure if multus will help me here, because if I understand correctly,
I'll need to run one flanneld instance for each network, and multus won't
help me with that. It will only call the flannel plugin to create the
interfaces in the containers, and attach them to the flannel bridge.
Do you have any pointers for what I'm trying to achieve? Or is multus not
the right tool for me?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/intel/multus-cni/issues/147, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFN_vYqQ_D_dGQnjjf9Vbkrj-4EeLQiRks5uXxFkgaJpZM4WZ8_w
.

Hi Doung!

I'm curious about your use case -- would you attach these dynamically during run-time?

We're building a networking product. To test it, we want to be able to create topologies where multiple  docker containers are connected to each other in various ways, and destroy these topologies after the tests finished.

That's something we are likely going to consider for v4, I believe.

That would be awesome !

@little-dude -- do you think you could expand on the use case here? We're not sure if it's necessarily proper for Multus to dynamically create more Flannels networks (and... I might be misunderstanding your issue again as I re-read a little later). Network attachment dynamically is definitely on our radar.
At any rate -- want to make sure we're addressing your concerns before we close out the issue, and... Don't want to close it if we haven't addressed your concerns and/or learned from it!!
Thanks for sure

@dougbtv
I'd like to ask how the dynamically network attaching is going since the last comment was 1 years ago.
In our company, we are heavily relying on multus-cni and we also have some real use case for the dynamic attachment.

Currently we do not have plans to manage dynamic attachments for Multus CNI.
One suggestion may be to create a custom controller to watch net-attach-defs and then take action when they're added/removed/changed/etc.
We're still curious about use cases, and we'd love to have them shared with the NPWG to help further explore this topic, more details @ https://www.google.com/url?q=https://docs.google.com/document/d/1oE93V3SgOGWJ4O1zeD1UmpeToa0ZiiO6LqRAmZBPFWM/edit&sa=D&ust=1585147325830000&usg=AOvVaw0OPUEz-BGEGL572YIlXpyW


Todo List for server api !!

@idrice24
Can you do your own todo list,
See my own:
After prototyp we can do it on github (Projects-Tab) .. i mean project management.
https://github.com/idrice24/MNS/blob/master/frontend/Todo-List.md

https://github.com/idrice24/MNS/blob/master/backend/ToDoList.md


issue with tool0 and tool0_controller when using jnt_cartesian_traj_controller

Hello,
I have used  a controller of type jnt_cartesian_traj_controller from this package  with ur10e.  However, now that I added an
extender and gripper,  the tcp has been changed and it is given as tool0_controller. For this I changed the tip parameter to tool0_controller in the controller config file.
I now have an error when trying to use jnt_cartesian_traj_controller   with a controller configuration of tip:tool0_controller.  I have  read in the controller description that links must be in the urdf for them to qualify as base and tip link.  Is there a solution to this?

Hi @wendwosen

I have read in the controller description that links must be in the urdf for them to qualify as base and tip link.

Yes, that's correct. The controller builds an internal kinematics chain between base and tip from information in the URDF and solves the Inverse Kinematics problem using the given joints in between. The default case is explained here.

However, now that I added an extender and gripper, the tcp has been changed and it is given as tool0_controller.

I wasn't aware that one could change this tool0_controller. Was that done somehow on the UR side? Anyway, the solution is to add some additional link to your robot URDF that is semantically identical to your new tool0_controller and specify that instead in the controller .yaml.
As an example, let's say you mounted your gripper on your UR10e's end-effector flansh (tool0) and measured the distance to the grasping center to be 15 cm with same orientation (which shall be your new tool0_controller).
You would then add it to your URDF. Something like:
<?xml version="1.0"?>
<robot name="robot" xmlns:xacro="http://ros.org/wiki/xacro">

        <!-- Includes -->
        <xacro:include filename="$(find ur_e_description)/urdf/ur10e.urdf.xacro" />

        <!-- Create robot instances -->
        <xacro:arg name="kinematics_config" default=""/>
        <xacro:ur10e_robot prefix="" joint_limited="false" />

        <!-- Connect robot to world -->
        <link name="world" />
        <joint name="world_joint" type="fixed">
                <parent link="world" />
                <child link = "base_link" />
                <origin xyz="0.0 0.0 0.0" rpy="0.0 0.0 0.0" />
        </joint>

        <!-- Add gripper frame for Cartesian trajectory controller -->
        <link name="grasping_center" />
        <joint name="grasping_center_joint" type="fixed">
                <parent link="tool0" />
                <child link = "grasping_center" />
                <origin xyz="0.0 0.0 0.15" rpy="0 0 0" />
        </joint>

</robot>

And specify that in your controller .yaml:
joint_based_cartesian_traj_controller:
    type: position_controllers/CartesianTrajectoryController

    # UR driver convention
    base: base
    tip: grasping_center
    joints: *robot_joints

If using melodic-devel-staging (or @fmauch's fork): flange is the EEF attachment point. Not tool0.

I wasn't aware that one could change this tool0_controller.

tool0_controller is published by the driver. It's going to be equivalent to whatever the controller reports as the current pose (relative to the Base feature on the controller). It's somewhat unfortunately named, as tool0 is not supposed to ever change. That frame is "equivalent to an unconfigured tool frame, always".

Thank you @stefanscherzinger
I did as you suggested.  It is working correctly now.


Inconsistent lock binaryState/state in MQTT

Today I noticed that lock sensor in HA was reporting unlocked when Nuki was locked, I checked MQTT and noticed this:

You will notice that lock/binaryState is unlocked but lock/state is locked.
I restarted Nuki Hub to force it to reset the states from the lock and everything was good again.
BTW: is it possible to add a restart button in the UI? right now I go into settings and hit save to force it to restart)

Thanks, I'll look into it.

Thanks to you.
Another weird thing, that might be related: I found some strange topics in MQTT that were similar to nuki_hub topics, but with parts missing: _hub_hub with battery info, then I found another weird topic, I made a screenshot yesterday but can't find it...I'll'attach it as soon as I find it. It's like there was some problem in sending data to MQTT from Nuki Hub. It only happened 2 times...I'm on latest version of the firmware.

Yeah, I have several of those too. Looks like there is some memory corruption going on somewhere (which would also explain why Mosquitto complains about malformed messages every once in a while.

I hope it's a sw bug that will be solved.

There's nothing obvious, the state and binaryState are always updated together. If it's an MQTT problem, it'll get more complicated. I don't have any such malformed topics, but I'm not using mosquitto. As far as I can see the correct topic is passed to the MQTT stack (pubsubclient), what happens from there I don't know since it's not my code.

Is it possible that memory on the ESP32 is getting corruped, maybe by a parallel thread? (I am thinking of the WiFi stack in particular, as that would be something you would not experience on your own device?)

I've reviewed the code building MQTT paths.  If this fixes  the actual issue with the binary state I don't know, please test.

I don't have any such malformed topics, but I'm not using mosquitto.

I don't use mosquitto either, I use EMQX v5.  If this fixes the actual issue with the binary state I don't know, please test.

That's what I hoped: some sw bug that could easily be solved. Thank you.
Question is: why did it never occur to you since you never observed the issue?

If this fixes the actual issue with the binary state I don't know, please test.

That inconsistency condition only happened 1 time since I installed Nuki Hub, so I will monitor things and report back in case I observe it again. What allows me to be optimistic is that I observed those messed-up topics and the inconsistency in the same time-frame.
Will keep you poste, thank you for reacting so quickly.

After fixing those errors, I'm somewhat surprised that it did work before. I'm using iobrokers built-in MQTT broker, maybe it handles garbled messages/paths better than mosquitto.

I'm using iobrokers built-in MQTT broker, maybe it handles garbled messages/paths better than mosquitto.

I think you have to follow a strict protocol/spec in order for an MQTT broker to accept data, so if the integrated broker is a true MQTT broker, it means it received the topics malformed, and so it should process them as EMQX and Mosquitto did.
The fact that it worked before also for me for almost a month will remain a magic mistery. :)
I have some other issues with the web interface (also with previous 6.0 fw), pages render with no formatting often, if I refresh a couple of times I see the formatting (black background, etc.), but sometimes it throws an http error (a connection reset error) then after 2-3s it appears again. It seems like http connections are not managed very well...that's the feeling.
Thanks a lot for your support.

Im still seeing this issue:

didn't occur to me yet, after 6.1. But I used nuki_hub for quite some time without the issue, then one day it happened...when I started seeing malformed topics in mqtt.
Do you have malformed topics? open all nuki_hub subtopics to check for weird names...

Let's keep in mind that the malformed topics aren't necessarily related to the incosistent states.

For me it seems te be related to having multiple nuki locks: https://github.com/technyon/nuki_hub/issues/53 I have moved one back to another project and now I don't see this anymore.

Let's keep in mind that the malformed topics aren't necessarily related to the incosistent states.

Correct, we don't know, that's why I asked, so we can check for patterns.

I have updated my device to 6.1 and cleaned out all the messed up topics using mosquitto_pub. After a few days, it looks like new broken topics have appeared. Is it possible there is still an issue somewhere else in the MQTT code?

The question is where this happens. As far as I can tell, the paths should be built correctly now. After that comes the MQTT library. Just to verify everything is correct on my side, I've built a version that outputs all paths to the serial console.
Uploading nuki_hub-mqtt-dbg-1.zip…

I have updated my device to 6.1 and cleaned out all the messed up topics using mosquitto_pub. After a few days, it looks like new broken topics have appeared. Is it possible there is still an issue somewhere else in the MQTT code?

Since 6.1 I haven't seen malformed topics, but I guess it's too soon to say it's fixed. I'll keep monitoring it and keep you posted.

Unfortunately, for me they are still there. To make sure they are not artifacts, I cleaned up again after posting https://github.com/technyon/nuki_hub/issues/51#issuecomment-1336360175 and this is a screenshot of today:

Few other examples from 6.7:

I am cleaning everything again. Could it be related to automated or triggered restarts?

I am cleaning everything again. Could it be related to automated or triggered restarts?

So the bug is still there. I just checked mine, and very interestingly, the same Topic is malformed, can't be a coincidence:

I attempted to find issues in the code but the only thing I found that could cause memory issues is a RSSI value that would not be not integer (not even sure that this possible). The itoa() would cause unexpected results.
https://github.com/technyon/nuki_hub/blob/master/Network.cpp#L376
Or maybe it's another bug in the Network::buildMqttPath function.
It would mean that checking for end of strings with "0x00" would not always work or that the fact that the generated path itself would cause issues because its array is too big and padded with "0x00". I am not familiar with this method of initializing string arrays with 0x00 so sorry if I say stupid things.
https://github.com/technyon/nuki_hub/blame/master/Network.cpp#L303

@Mincka In C (and derived languages like C++), strings are pointers to zero-terminated arrays of characters.

It's a mystery to me why this is happening. There's nothing too special about the rssi node, it's published via the publishInt() method, which is used by for a few other nodes too (batteryDrain, lockDistance, ledBrightness). Maybe the bug is triggered more easily with the rssi node because it's constantly updated ... same goes for wifiRssi and presenceDetection though.

I have the issue with other nodes as well (see previous screenshots). It is not limited to any single topic.

I just saw this in the log:

The ESP rebooted after the configured 30 minutes restart. I'm thinking about a corrupted MQTT command because the ESP is restarted during the publishing of a value. It would happen more frequently with wifiRssi than others because there are more chances that every 30 minutes, when the device is rebooting, it's also updating wifiRssi.

Do you have multiple locks @mundschenk-at and @alexdelprete ?

only one lock.
what about external libraries? how does the sw interface the mqtt broker? could it be a bug in the library used for that scope?

It is not limited to any single topic.

true. it's not the same topic. I found 4-5 different topics and subtopics malformed.

NUKI Hub uses the wiedely used PubSubClient to act as an MQTT client.

Does it use TCP to communicate with the broker? If so, corruption can't happen at that level, so it must be the buffer/parameters being passed to PubSubClient originally that sometimes is malformed. The problem is that you can't reproduce the issue to debug it. :(

The corruption could happen at several layers, I think it's unlikely though that it happens in PubSubClient, the Wifi or TCP stack, that code is used in many other projects, I think it would be fixed by now. Maybe it makes sense to log the topic on each publish to see if anything malformed is passed to PubSubClient, I can build a binary.

I don't know if you have the automated restart schedule

Nope, I have it disabled (-1).

Maybe it makes sense to log the topic on each publish to see if anything malformed is passed to PubSubClient, I can build a binary.

Sounds like a very good idea to understand what is going on.

Here you go. It logs all published topics, only to the serial line though in order to not interfere with MQTT. Not sure how helpful it'll be, because it's a lot of output.
nuki_hub-6.9-log-topics.zip

ouch! on serial only? is it possible to write to a network share or a syslog?

I still have the issue: the malformed topic seems like a weird merge of the lock topic and the maintenance topic.

@alexdelprete It's a form of memory corruption, so the mashup is expected.

If anyone wants to add their own logs, I've uploaded a virtual machine that can compile the firmware. Have a look at the end of the readme.

@alexdelprete It's a form of memory corruption, so the mashup is expected.

memory corruption? I don't think it's a hw bug. But we should agree on what memory corruption is: being a little old, I tend to think about hw issue when referring to memory corruption.
I think it's a sw issue, not a hw issue, also because it happens on different kind of devices.

I think we're talking about a software problem here. In C++ it's easy to write to a memory location by accident, this would be what you refer to as memory corruption. In this case it looks like bytes are changed somehow at the memory location where the MQTT topic is stored.

I agree Jan, it looks like a classic pointer issue or buffer overflow issue of C++. But I guess you already triple-checked where the topic is created and managed. That's why I was thinking about the library/component more than your code. But since it's a well established component, like you said, it would have come out in other projects.

I didn't intend to imply a hardware issue.

Yes I double and triple checked the code. The most likely candidate would be buildMqttPath() in Network.cpp, that's where all the components of the path are concatenated. I don't see anything going wrong there though. It seems anyway that something else is writing there. For example "maintenance" becomes "locntenance", so something must have written "loc" to that memory location. Why that happens is a mystery.

Any possibility of reentrancy issues? (I really don't know much about ESP32 programming.)

Actually yes, still reading:
https://github.com/knolleary/pubsubclient/issues/832
Could indeed be a library problem. As far as I understand if a an incoming messages is received while publishing, it can corrupt memory.

I've added the check from the first post in that topic. Anyone want to give it a try?
nuki_hub-6.11-tryfix-mqtt-1.zip

I've cleaned out the MQTT topics again and installed the new firmware. Hopefully, there will be no corrupted topics next week.

Could indeed be a library problem. As far as I understand if a an incoming messages is received while publishing, it can corrupt memory.

So we old dinosaurs of IT still have a good instinct when troubleshooting. ;)
I'll try the updated firmware and keep you guys posted. Thanks a lot for all the support from everybody.

Jan, I read that the two PRs proposed in that PubSubClient thread were not merged, so which fix did you implement in the end?

Jan, I see that https://github.com/knolleary/pubsubclient/pull/835 has never been merged. And also https://github.com/knolleary/pubsubclient/pull/843.
So from my merspective, the problem is still in the library. Question: is there another library that could be used to manage MQTT communication?

Also an option:
https://github.com/bertmelis/espMqttClient
Now  which one to choose?

The first one (arduino-libraries) should be maintained by the official Arduino Team:
This organization hosts the official libraries maintained or supervised by the Arduino team

Here you go, NUKI Hub with ArduinoMqttClient. I had to work out a few quirks of the new lib, but all in all it wasn't too hard to replace. Please go ahead and test.
nuki_hub-7.0-arduino-mqtt-1.zip

Thanks again for the effort. I hope this helps. Both ESP are now running 7.0-arduino-mqtt-1. I removed one from the door and put it next to the ESP just to see if it also makes a difference for my connection issue.
Quick question: why the nuki_hub.bin above in the zip is not the same as the nuki_hub.bin in the ZIP artefact for this build (1488 KB vs 1388 KB)? I was thinking we could use the bin from the build artefacts directly.

Here you go, NUKI Hub with ArduinoMqttClient. I had to work out a few quirks of the new lib, but all in all it wasn't too hard to replace. Please go ahead and test.

Wow Jan, I didn't expect it so quickly. Hope it didn't take too much of your time.
I just upgraded and made sure the MQTT topics were "clean". Now let's wait some days to see what happens.
Thank you so much for this. :)

@Mincka I'd need to check ... I think the CI is still running with Arduino core for ESP32 2.0.5, I'm using 2.0.6 ... or maybe some cmake options, or because I'm using ninja instead of make. The difference is size is somewhat significant though, I'll investigate it when I have time.

The default tx buffer size is only 256 bytes. Upped it to 6144, please give it a try.
nuki_hub-7.0-arduino-mqtt-2.zip

I'm confused I thought it was about being lowercase, so I changed db to dB. This is not a valid unit?
@rodriguezst Could you check if encrypted MQTT still works with the new library?

@rodriguezst Changed from PubSubClient ro Arduino MQTT because the former has some memory corruption issues. Thanks for the update
Let's test it a bit longer, if everything works I'll merge it prepare a release.

No malformed topic on 7.0-arduino-mqtt-1 neither. Using 7.0-arduino-mqtt-2 now on both locks.

No malformed topic on 7.0-arduino-mqtt-1 neither. Using 7.0-arduino-mqtt-2 now on both locks.

I thought we had solved...:(

Well damn. I'm still in favor of using the new library, PubSubClient seems to be unsupported, not commits for two years.

I agree. It's much better. Since my last report, no malformed topics.
And this library is officially supported by the Arduino team.

Let's test it one more day, and I'll do a new release tomorrow.

Let's test it one more day, and I'll do a new release tomorrow.

Agreed. Maybe that malformed topic was an old one I forgot to delete...;)

Still not seeing this issue on my side but it was always very random and often after few days.

Still not seeing this issue on my side but it was always very random and often after few days.

With the previous library, I saw malformed topics at least every 2 days, sometimes even more often.
I would wait another day (3 days) just to be on the safe side.

Only two minor issues left:

Even if the Nuki Opener is disabled, the topic is created:

A small typo:

I went ahead and released it as 7.0 ... the new library is better anyway. Fingers crossed the garbled topics are gone.

I went ahead and released it as 7.0 ... the new library is better anyway. Fingers crossed the garbled topics are gone.

Makes perfectly sense. Let's see how it goes...:)

Guys, do we consider this malformed (drain)?

Can anyone observe messages like in issue #87 or #88 ?

Yes, both.

Can anyone observe messages like in issue #87 or #88 ?

Can you check if the new library has an option for persistent connections? It seems to open a new connection every time it needs to communicate with the broker. That is a common problem found also in other projects with an MQTT client.

There's not that much to configure:

connection timeout which defaults to 30 seconds
keep alive interval which defaults to 60 seconds. When the interval runs out, it sends a MQTT ping request

Actually not so fast! Persistent connections in MQTT are configured via the clean sessions flag (what a misleading name). Settings it to false makes connections persistent, of course it defaults to true.
Try this binary with clean sessions set to false:
nuki_hub-7.0-cs-false.zip

Finally, I also got a buggy one:

Now running 7.0-cs-false.

Persistent connections in MQTT are configured via the clean sessions flag

Do we use a dynamic clientID? That could be a problem. It would be also good to have an option in MQTT config section to define a specific clientID (with a default maybe) and also id Clean Session flag should be on or off (default off).
ref. https://www.emqx.com/en/blog/mqtt-session

I also hope the library takes care of this:

Finally, I also got a buggy one:

You had the malformed one with the clean session firmware or with the previous one?
I don't think it's a coincidence RSSI topic is often the malformed one, it's the one that is updated more frequently.

@technyon RSSI is updating every 1-2s, I think this is a problem, if the value comes from the Nuki BLE API because it will drain the battery. If it's the RSSI on the ESP32 side, no battery issue, but anyway it's too chatty, it should be updated like the other values.

Finally, I also got a buggy one:

You had the malformed one with the clean session firmware or with the previous one?

With the previous one.

There's no battery drain from the bluetooth rssi value. The lock (or opener) sends beacons all the time anyway, the ESP just picks them up. This is actually what is changed by the "energy-saving" setting in the app. Depending on wether you set it to slow or fast, more or less beacons are sent, hence the battery drains faster on fast.

the ESP just picks them up

ok, that's what I needed to clear, thanks.
one issue remains: the 1s update is also being picked up by HA through MQTT, and usually it's not recommended to have an entity recorded that updates so frequently. Is there any chance we can have that throttled in some way? An option to align the frequency update to the other sensors?

I don't see an issue with this personally. The broker is getting lots of updates per second and can handle this without issues. Since it has no impact on the Nuki battery, throttling mechanism would just add more complexity in the code without being sure that will fix anything, it's just hypothetical.
In the end, what's the impact of having a malformed maintenance or wifi topic once in the while? You just miss an update of a non critical sensor. We can live with that. We have no proof that's related to reboots. I have reboots without malformed requests.

Actually not so fast! Persistent connections in MQTT are configured via the clean sessions flag (what a misleading name). Settings it to false makes connections persistent, of course it defaults to true.
Try this binary with clean sessions set to false:

Does not seem to have helped much (if at all), the Mosquitto log still looks the same (lots of connects, including error messages about Bad client <nukihub> sending multiple CONNECT messages.).

@technyon, while I understand the wish to change to a maintained library, the results with the new one are not good so far. I have created #90 for the new issue of binary data in the payload. It looks like the new library has a buffer corruption problem as well (albeit a different one). For me, the most stable version was https://github.com/technyon/nuki_hub/issues/51#issuecomment-1383137614.

I don't see an issue with this personally. The broker is getting lots of updates per second and can handle this without issues.

Like I wrote above, it's not about the broker, MQTT brokers are designed for heavy loads. The problem is HA recorder. Some users with RPi might have issues, very frequent updates are not the HA realm on those kind of setups. For me I have no issues, HA is running on a pretty good server with SSDs etc. but I'm thinking about other users. Eventually, they could exclude RSSI entity from the recorder, but sincerely, I see no value updating that sensor every second. It should update like the others.

In the end, what's the impact of having a malformed maintenance or wifi topic once in the while? You just miss an update of a non critical sensor.

The RSSI is not a critical sensor either, so why updating it every second?

We have no proof that's related to reboots

I didn't say it causes reboots, I said it't contributing to malformed topics. In my case the RSSI topic is usually the malformed one. And I don't believe in coincidences when they are so frequent.

Can you check with your broker that nuki_hub is actually using a persistent connection? I verified with mine and it's using it.

How would I do that?

How would I do that?

I don't know with Mosquitto, that's one of the reasons I chose EMQX vs Mosquitto.
With EMQX I can check the Clean Session flag via the admin UI:

Maybe with mosquitto there's some cli command or maybe in the logs...

Looks like its not possible without storing the client IDs manually on connect. Maybe I should switch as well.

Looks like its not possible without storing the client IDs manually on connect. Maybe I should switch broker as well.

Nuki Hub uses the hostname as client ID when it connects, it's not dynamic. What to they mean by "manually"?

Looks like its not possible without storing the client IDs manually on connect. Maybe I should switch broker as well.

Nuki Hub uses the hostname as client ID when it connects, it's not dynamic. What to they mean by "manually"?

That you have to code the logic yourself. See this Stack Overflow post for details: https://stackoverflow.com/questions/9767040/get-a-list-of-connected-client-ids-from-mqtt-client

That you have to code the logic yourself.

Luckily, when I chose what broker to use for my homelab, I spent quite some time doing my research. I will never regret that decision. EMQX v5 is higly recommended if you want to properly manage the broker.

Like I wrote above, it's not about the broker, MQTT brokers are designed for heavy loads. The problem is HA recorder. Some users with RPi might have issues, very frequent updates are not the HA realm on those kind of setups. For me I have no issues, HA is running on a pretty good server with SSDs etc. but I'm thinking about other users. Eventually, they could exclude RSSI entity from the recorder, but sincerely, I see no value updating that sensor every second. It should update like the others.

Any setup with a single smart plug with power metering will get updates every few seconds, so hopefully no HA setup, even on Raspberry should die from this.
There's no update "every second" anyway, it's at least 2:

In the code, presence and BT RSSI are updated with a minimum interval of 3 seconds but it's only 2 seconds between Wi-FI RSSI updates, so I guess it's fair to align all of them with a minimum of 3 seconds.

2 seconds is an eternity for a CPU, even a low-spec raspberry. If this really is a problem for anyone in the sense that some hardware can't cope with it, I can add an option to disable it.

The problem would not be CPU overload, but very frequent writes to the SD card in the HA default configuration on Raspberry Pis.

2 seconds is an eternity for a CPU, even a low-spec raspberry. If this really is a problem for anyone in the sense that some hardware can't cope with it, I can add an option to disable it.

The problem is the recorder of HA: writes to DB. On RPi tipically it's an SD card. It's a well known problem in HA's community, and HA devs always recommend to not update sensors every 1-2s.
I didn't ask to disable, I asked to align the reporting cycle to the other entities. Personally, even if I don't have a problem with frequent updates, I don't need RSSI reports every 1-2s, and I don't see why that would be needed.
Anyway, if nobody agrees on this, I will find another solution, at the broker level possibly to throttle the update frequency.

Any setup with a single smart plug with power metering will get updates every few seconds, so hopefully no HA setup, even on Raspberry should die from this.

"every few seconds" is very different than 1-2 seconds. And if you read HA forums, there are issues with those very frequent updates on SD cards writes. Anyway, generally speaking, I don't see any reason for an RSSI sensor to update so frequently.

There's no update "every second" anyway, it's at least 2:

2 seconds is very high frequency for an RSSI sensor, why do you need to know that value every 2s? Doesn't make sense to me, that's why I'm asking for it to be aligned with the rest.

so I guess it's fair to align all of them with a minimum of 3 seconds.

the only sensors updating very frequently are the Wifi RSSI, the BT RSSI, and the presence one. I think 5s for all these 3 is well more than enough. But that is only my suggestion because I don't see any need for higher frequency. Ideally, it should be configurable, like other parameters.

I agree with @alexdelprete, but I think we should move the discussion of the RSSI update frequency to #89.

Thanks for 7.1 with configurable RSSI update frequency @technyon. Does it also contain the Clean Session flag? I didn't see it mentioned in the changelog.

I haven't changed it for this release, because I'm not really sure what the impact is. So it is on for now.

I haven't changed it for this release, because I'm not really sure what the impact is. So it is on for now.

Maybe the CS flag should be configurable too, even though I'd recommend using persistent connections by default. I'm looking for a chart I read some months ago, made by someone who benchmarked an MQTT client with persistent connections and without them: the overhead of establishing a new session everytime an update was sent to the broker was huge, particularly with frequent updates. Establishing many TCP connections every time has its toll, hence persistent connections is adviced in many use cases.
As soon as I find it I'll share it.

@technyon The benefit of CS=false is really leveraged only with QoS=1, and I noticed NH always uses QoS=0, so there's no broker acknowledgement nor queueing of messages.

I've thought about switching to to QoS 1, the library does support it ... it's just that QoS 0 is the default. It also supports QoS 2, there's some issue with it open though, I'd need to check.

At least QoS 1 sounds like a good idea for this usecase.

I've thought about switching to to QoS 1, the library does support it ... it's just that QoS 0 is the default. It also supports QoS 2, there's some issue with it open though, I'd need to check.

QoS 2 is a little bit too much for resource constrained device, I think QoS 1 is a good compromise.
I'm studying a little bit MQTT because I never did before, and it's interesting. I wanted to understand better this Clean Sessions vs Persistent Sessions thing. And I think we definitely want to use Persistent Sessions, because it's true NH mainly publishes messages, but it's also a consumer of very important messages (commands) that it doesn't want to lose (e.g. after a sudden reboot), so with Persistent Sessions and QoS 1 we tell the broker to store those in a queue until they are consumed by NH:

@alexdelprete Any news about the official MQTT support by the way? Did they have such details in their specs?

Any news about the official MQTT support by the way? Did they have such details in their specs?

I'mm not following them anymore, had a harsh discussion with Jurgen after I asked him a simple question: will MQTT support be available for the Nuki Bridge? He didn't answer clearly. So I pushed him again and he didn't want to answer. So from what I understand, they only want to support MQTT on SL3 model, to push sales (old SL2 users will have to upgrade).
So I got a little bit upset and wrote in the forum that would be my last post supporting the initiative, and I also wrote that with a $10 device and Nuki Hub project we have the best bridge there is, with active developement and everything working fine. And I left them to their destiny...I don't like their approach, no transparency, they lie on functionalities (remember zigbee support? never happened in the end).
On the technical side: QoS=2 might be a little overkill for a low resource device, but we could experiment, maybe a configurable QoS option with 1/2 to test things and then decide? cc @technyon

Thanks for the feedback. Their hybrid approach with QoS=2 only for device control seems to make sense but is more complicated to implement. Is it possible that with QoS=1, we'd risk to have an unlock command sent twice by HA and lead to side effects if lock command is sent by a third-party in-between? I mean, maybe QoS=1 could do more harm than QoS=0 in some cases. Very hard to tell.

Is it possible that with QoS=1, we'd risk to have an unlock command sent twice by HA and lead to side effects if lock command is sent by a third-party in-between? I mean, maybe QoS=1 could do more harm than QoS=0 in some cases. Very hard to tell.

QoS=0 is the worst of all, duplication is an issue at all lower levels than QoS=2, it's not a specific issue of QoS=1. So for me the baseline should be QoS=1, and QoS=2 for very critical commands.

I'm a bit hesitant to go to QOS 2 because:
https://github.com/arduino-libraries/ArduinoMqttClient/issues/64
You can give QOS 1 a try though:
nuki_hub-7.1-qos-1.zip

This has the CS flag set to false, right? QoS=1 goes with CS=False.

@technyon if it's not too much work, can you prepare a test fw with all options we discussed configurable?

RSSI frequency
CS True/False
QoS 0/1/2 (so I can also test with 2 and EMQX vs Mosquitto)

It would be good so we can play with the settings and find a good configuration.

Any chance you could compile the binaries yourself, would make a lot easier. Check the readme, I've provider a virtual machine to compile. RSSI interval is already configurable via the web interface. I've put QOS and CS into "Config.h", you just have to change the defines and recompile.

@alexdelprete It's still quite new, but in the Community repository: https://github.com/hassio-addons/addon-emqx

It's still quite new, but in the Community repository

Oh, I don't follow the addons because I use HA Core. Every app/service is installed outside of HA environment (docker and LXCs), and then integrated through integrations.

Any chance you could compile the binaries yourself, would make a lot easier. Check the readme, I've provider a virtual machine to compile. RSSI interval is already configurable via the web interface. I've put QOS and CS into "Config.h", you just have to change the defines and recompile.

Sure, I'll try. If I have problems I'll let you know. Thanks.

@technyon Jan, where do I set this?

I need it to check what I have enabled/disabled while testing.

Change the flags here before compiling and the name of the version here with what you set, eg. 7.2-cs-false-qos-1.

I had already changed Config.h, I missed Version.h. :)
Thanks.

They could be merged into file actually.

Yeah...probably it would be a good choice. Let me know if you merge them.

I didn't allocate the time yet to do a proper test. For now I allocated time to import the VM in my Proxmox and customize the image because the settings weren't working for me. Now the VM is ok and I know how to compile etc., but I need to schedule the test activity. Probably by tomorrow. :)
I will let you know...the only worry I have is that actually I'm using 7.0-cs-false and I'm not having serious issues (reboots, etc.). So I don't know how significative will my test be. :)

I understand. If it ain't broke, don't fix it. ;) That's better with your stable setup because we'll know if potential issues are related to the QoS overload. In my case, I could certainly not deduce anything from playing with this yet.

BTW: if you guys use discord, I setup a dedicated chat for Nuki Hub, you can join here.


[Bug] Clicking both mouse buttons in FTB chunk claiming mode permanently brightens chunk on map

When holding one mouse button and pressing the other, the chunk becomes brighter on the map, regardless of whether or not FTB overlay is enabled. There's no way to reverse it and it persists until you rejoin the server.

what's your game and mod version


client: make list a subcommand of other commands

In some cases it feels like list command could be a subcommand of other command: /gc ls to list group chats, /ab ls to list address book, etc.
Just an UX idea.

While I like this idea not every list fits the mold (e.g. joins) and therefore it will break my OCD. I can be convinced to make this change but we need to identify what lists and make sure it isn't confusing.


Multiple windows with different browser cache

What is your Scenario?
I need to run tests where I have multiple users logged in at the same time and test the interactions between these users. To do this, ideally there would be an option to open a page in a new window that has its own browser cache.
Currently multi-windows reports this limitation:
Cookies and User Roles Limitations in Child Windows
TestCafe’s User Roles preserve browser storage contents (cookies, localStorage and sessionStorage). A TestCafe instance can only have one active User Role at a time.
If you switch between roles in any browser window, cookies and local/session storage contents inside that role are applied to the remaining windows.
What are you suggesting?

Provide an optional parameter for t.openWindow() to specify that the new window will have it's own isolated cache
Provide an optional parameter for t.useRole() to specify that the role and browser cache update only applies to the current window

What alternatives have you considered?
most likely we are stuck having these be a manual tests
Additional context
No response

It's a duplicate of https://github.com/DevExpress/testcafe/issues/5291


TensorRT official webui

when will release?

Probably when it can be run with ease on a majority of computers. So not in the near future.

I found Tensorrt official's version always get black image on sd 2.1

That is one of the known issues.

Black images
No dynamic shape by default (limited to the shape you setup with)
Dynamic shapes have limits (the combination of shapes and batch size can't exceed a certain value see pull request)
ONNX conversion issues (file gets split, file contains duplications, various version can't be output on various hardware combinations)
TensorRT conversion issues (Fails without a proper error. Ex. "An error occurred because an error occurred")
ONNX parsing issues on various versions
TensorRT models are version specific (Model built on 8.6.X will not work on any version above or below)
TensorRT model built on one GPU will not work on other GPUs (Model built on 4090 won't work other cards, but may load on other 40 series with speed penalty)
TensorRT leverages other libraries that aren't specified (C/C++ compilers, it won't mention them but it fails just the same, easier to remedy on linux)
TensorRT can't be used with controlnet currently
TensorRT can't be trained on (Lora Dreambooth, and hypernetwork)
Polygraphy errors (ranges from wrong architecture, wrong version, overclock issues, etc.)

For my own personal take, even when someone compiles a model with the same GPU as myself, it still doesn't load, gives the same Error code 1. Even on verbose it doesn't say anything of substance happened to prevent it from loading, but nevertheless, it fails.
Most developers opted to use AITemplate, but that is Linux only. On WSL2 it works easily, gets stuck every now and then, but functions.


Fix contact us links

Should give opportunity to go to Slack, Teams or group email.
Currently doesn't go anywhere.
Should this simply link to the contact us page in our user guide?

https://github.com/ministryofjustice/find-moj-data/pull/604


Skin Script

Hi Megabyte,
I'm using your skin script, and the skin only shows up when i put in regular (keyboard) characters. When i try putting in something like ᑭᕼΣ𐍈Ɲ𐌆✘⚔⚔一ϺƬ♜ the skin doesn't show. Any fix?
-PheoniX

I will look into it.

@Megabyte918 @PheoniXAgario Same Problem...

@Megabyte918 How did raga.pw made there own game mode and work using the skin :3

@NameYT Is it agar client clone or agario client?

@AlexandriteErikParacelsus Agario cilent

@Megabyte918 FIX THIS PLZ

Guys, @Megabyte918 is looking into it, stop pestering him with redundant messages

@PheoniXAgario are you sure?

@Megabyte918 Fix This problem pls

I legit don't know how to fix this :/
The extension doesn't seem to modify anything having to do with the name, all it does is get the value of what you put in by using document.getElementById(\'nick\').value, so maybe it's just a client sided problem? I'm not sure.

Guys i will try making an extension that has ERT controls and lets u use your own skin :)

@Megabyte918 Can you link me to the extension they are talking about so I can look at it?

@MastaCoder  Hey, is this script : https://raw.githubusercontent.com/Megabyte918/MultiOgar-Edited/master/src/scripts/CustomSkins.js

Solution. Click right in box of nickname. browse in elements MaxLenght. already as puted in 15, double click and change to 999,

@AlexByte918 That's not the problem. Skins don't show up with fancy characters, not length.

Same problem for me, I can't use custom skin using my nick (愛✈⊶ΛτнσM༅⎇ᵇᶺₑ) ... I can only see it when puting a keyboard name :(

Oh I just tested, lettre by letter, to write my name, and I just found out that this caracter: "Λ" isn't supported... All others caracters that are in my name are working perfectly using my skin ^^ I think I have to change this letter in my nickname xD

Can you try this: delete random skins, and try to add custom skins like in ogar unlimited master (if you dont know how, go to YT).

Because we cant see random skins on ourself.

Only on our m8

Server can't send images.

I mean that it needs protocol modifications

Oh ok i understand

But maybe it can work with any extension

Sure it would with if it supports custom skins.

@NameYT , raga made their own Client , so they were able to add Skins and their Gamemodes.
Greetings Flare !

@Megabyte918 @FantasyIsBae @AlexandriteErikParacelsus Close? Well it is something client sided

hey guys i made a script of skins...you can find all the skins and you can add if you want..i just i wanted to share with you guys...i know this is noob but i'll be batter in the futer
skins.txt

@SAVAGE2001 is fine

@Jhair2015 thank you  😊 😊


[SearchResults] Page Refresh is not retaining the data, blank page is displaying.

From @turpu-rakesh on July 16, 2018 6:43
On refreshing the search page it is displaying blank page.
Copied from original issue: Microsoft/Access2Justice#237

@svasylenko Were you able to reproduce this defect?  I believe this needs to be revisited.  Please confirm.

@KellyeDC
Issue isn't reproduced, so it can be closed.


Jscpd counts fewer lines of code than other tools, eg cloc

OS: MacOs
Same Directory
The result from jscpd

The result from cloc

The jscpd tool skip huge files. You can play with parameters:
-x, --max-lines [number]   max size of source in lines (Default is 500)
-z, --max-size [string]    max size of source in bytes, examples: 1kb, 1mb, 120kb (Default is 30kb)

Sorry ，that is my fault.  The thrift gen files is too large to skiped by jscpd。by the way , dose jscpd skip blank lines？
It seems not。


change default branch

@catch22 can you change the "default branch" under Settings from master to main?
On one of my other repos it looks like this:

Happy new year! There is also an option to rename to master branch to main. Would this be easier on the history? Which one would you prefer?

And to you!
I'm not sure: I've been pushing both in-sync.  So maybe it won't really matter, or maybe it won't let you rename since I created a main branch...

While you're at it, maybe add @mmuetzel as a collaborator?  They are an Octave dev and have been following my changes: I think its generally good to increase ownership of these projects.

Added @mmuetzel and changed the default branch to main. Shall we delete master to avoid confusion?

PS: I think some time ago we discussed moving this repo to an organization; this would allow us to give you (and possibly others) admin privileges, unlike with a personal repo like this one. I forget why we didn't pursue this further, perhaps because at the time we were thinking of getting doctest added to octave proper? Worth pursuing this idea again?

Yes let's delete master.

I've been thinking the same about https://github.com/cbm755/octsympy
How much breakage does one get?  Anyone with a remote clone needs to do some updating for the new URL...

Closing as this is done.  Other discussion can continue at #277.


Injection with arguments returns nil

Hey,
sorry for issue spam but i cannot run swinject in my project for 2 days
i have flow controllers in project, that mean that i have additional layer between UIViewController and UINavigationController. But i cannot use it, i'm getting error when i try to pass argument.
I created FlowControllersAssembly of AssemblyType, something like that:
class FlowControllerAssembly: AssemblyType {

    func assemble(container: Container) {

        container.register(FlowControllerCoordinatorService.self) { r in
            return FlowControllerCoordinator()
        }.inObjectScope(.Container)

        container.register(MagazinesFlowController.self) { r, storyboard, navigationController in
            MagazinesFlowController(storyboard: storyboard, navigationController: navigationController)
            }.initCompleted { (r, flowController) in
                flowController.userModel = r.resolve(UserModelService.self)
        }

// problem here
        container.register(DashboardFlowControllerService.self) { r, storyboard  in
            return DashboardFlowController(storyboard: storyboard)
        }
    }
}

and my AppDelegate
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    let container = Container()

    var assembler : Assembler?

    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
    self.assembler = try! Assembler(assemblies: [
            ClientAssembly(),
            ViewControllerAssembly(),
            ModelAssembly(),
            FlowControllerAssembly()
        ], propertyLoaders: nil, container: self.container)

     let bundle = NSBundle(forClass: DashboardViewController.self)
        let storyboard = SwinjectStoryboard.create(name: "Main", bundle: bundle, container: self.container)
        SwinjectStoryboard.defaultContainer = self.container
    let coordinator = container.resolve(FlowControllerCoordinatorService.self)
// flow will be nil :(
    let flow = self.container.resolve(DashboardFlowControllerService.self, argument: storyboard)
    coordinator!.continueWithFlowController(flowController: flow!)
return true
}

if i remove argument from register
container.register(DashboardFlowControllerService.self) { r  in
            return DashboardFlowController(storyboard: UIStoryboard())
        }

and try to resolve this flow controller:
let flow = self.container.resolve(DashboardFlowControllerService.self)

flow will be returned propertly
I'm doing something wrong?
any help appreciated

I investigated it futher, seems that Swinject cannot take as argument anything, i mean if i wrap UINavigationController or UIStoryboard, i can pass this without any problem, otherwise resolve dependency with arguments like Storyboard or NavigationController will return nil :/
My wrapper:
final class ArgumentBox<T :AnyObject> {
    weak var argument: T?

    required init(argument: T) {
        self.argument = argument
    }
}

From the quick pass over your code it seems that type of storyboard parameter in your constructors is UIStoryboard, i.e. DasbhoardFlowController.init(storyboard: UIStoryboard).
If that is the case,
container.register(DashboardFlowControllerService.self) { r, storyboard  in
   return DashboardFlowController(storyboard: storyboard)
 }

sets the type of storyboard argument to UIStoryboard, while when you call the resolve method, you are invoking it with argument of type SwinjectStoryboard - swinject can't tell that they are in fact related, so it fails, because it couldn't find registration with exactly specified arguments.
Easy way to solve this would be to explicitly upcast:
 let flow = self.container.resolve(DashboardFlowControllerService.self, argument: storyboard as UIStoryboard)

@jakubvano, thank you for the answer.
@CurlyHeir, this document might be helpful to understand the background of the issue:

SwinjectStoryboard inherits from UIStoryboard, so why polymorphism don't work in this case?
so, if i want pass argument that conforms to some protocol, it's not possible?
i mean
container.register(DashboardFlowControllerService.self) { r, storyboard, context  in
   return DashboardFlowController(storyboard: storyboard, context: context)
 }

and
return DashboardFlowController(storyboard: SwinjectStoryboard, context: Context)

when Context is some protocol, then it's not possible to resolve dependency from Swinject, cause type of passed argument is diffrent from parameter type, thats right?

I suggest reading this document and trying your code. I think it's the best way to understand what Swinject can do and cannot.

Closing this issue. @CurlyHeir, please feel free to reopen this issue if you still see the issue after the try👍


Dev/lostern/grid9 1

NvidiaGPU changes for GRID9.1

New driver is at the top as array index 0.
DirLink is sort of the true source of the file. FwLink is what the code uses internally since it allows us the freedom to change FwLinks (Externally) to point wherever we want. Hence, the requirement to have FwLink for all versions, even if it is really a download.microsoft.link and not necessarily a 'fwlink'.
As mentioned in the comment on the top of the file, once a new file/driver is added, the FwLink corresponding to this should be updated to point to this new file. This reminds me that I should get you permissions to the FwLinks which need to be kept updated. Working on that now ...


Fixes odata of NetworkAdapter* and the missing Network in a Zone:

Missing Network Resource Block in a Zone when SPT has no connections
Fix odata_id links for NetworkAdapterCollection and NetworkAdapter (api)

Closes #484
Closes #483

Coverage decreased (-0.007%) to 91.537% when pulling ba25eeba9010659413a09d649d065b5b1dbf9e42 on bugfix/missing_network_block_in_zone into ff6e93f5f656463cb33832259726263179a785ba on master.


Update outdated benchmarks in README

Benchmarks are from initial proof-of-concept CCF codec.  We should update benchmarks and comparisons with a reminder that we are not comparing apples to apples.
Prior formats (CBF and JSON-Cadence Data Interchange) didn't specify requirements for validity, sorting, etc.
Sorting data, deterministic encoding, etc. are not free.

Are you able to run the benchmarks?
> TIMBRE_LEVEL=':warn' clj -M:benchmark run -f :connection -d '[1000]' -c file -t feature -o edn feature.edn
Syntax error compiling at (benchmark/cli.clj:31:1).
No such var: dc/default-search-cache-size

I got a compile error. Is there something I'm not doing correctly?

CCF codec is almost ready for initial reviews.  PR will be opened to add it to onflow/cadence within 1-2 days.
Preliminary Size Comparisons
In the future, using CCF in "detached" mode (when appropriate) can make CCF about 1/4 the size of JSON-Cadence Data Interchange.
For now, this comparison uses CCF with deterministic and fully self-describing mode (Cadence types are included in each CCF message).  In this mode, CCF will be less than 1/2 the size of JSON-Cadence Data Interchange.

Batch events count is 48,309.
Batch events encoded in JSON total 13,858,836 bytes
Batch events encoded in CCF total 6,159,931 bytes
(for simplicity, values from first event of each type was used).

Preliminary Benchmark Comparisons
This is from real transaction with 48,309 events from mainnet.  Number of events for each type of event as well as types of events exactly match the real transaction.
However, to simplify benchmark code (it's Sunday night), the values in each type of event are the same (i.e. values are from first event of each type).
                     │ 48k_events_encode_json.log │     48k_events_encode_cbor.log      │
                     │           sec/op           │   sec/op     vs base                │
EncodeBatchEvents-20                 89.84m ± 17%   69.28m ± 3%  -22.88% (p=0.000 n=10)

                     │ 48k_events_encode_json.log │      48k_events_encode_cbor.log      │
                     │            B/op            │     B/op      vs base                │
EncodeBatchEvents-20                 32.45Mi ± 0%   25.82Mi ± 0%  -20.45% (p=0.000 n=10)

                     │ 48k_events_encode_json.log │     48k_events_encode_cbor.log      │
                     │         allocs/op          │  allocs/op   vs base                │
EncodeBatchEvents-20                  756.6k ± 0%   370.4k ± 0%  -51.05% (p=0.000 n=10)

                     │ 48k_events_decode_json.log │     48k_events_decode_cbor.log      │
                     │           sec/op           │   sec/op     vs base                │
DecodeBatchEvents-20                  646.2m ± 8%   158.3m ± 5%  -75.50% (p=0.000 n=10)

                     │ 48k_events_decode_json.log │      48k_events_decode_cbor.log      │
                     │            B/op            │     B/op      vs base                │
DecodeBatchEvents-20                234.97Mi ± 0%   56.16Mi ± 0%  -76.10% (p=0.000 n=10)

                     │ 48k_events_decode_json.log │     48k_events_decode_cbor.log      │
                     │         allocs/op          │  allocs/op   vs base                │
DecodeBatchEvents-20                  4.746M ± 0%   1.288M ± 0%  -72.86% (p=0.000 n=10)


[Event Request] Codeunit 22 - Function PostItem

We are using BC 14.0 - 14.0.29530.
We need to change the rules about when the blocked check is run, based on some fields in the item journal line. To do this, we need function PostItem in codeunit 22 to be modified, around line 426. The change would need to be something like this:
IF Item.GET("Item No.") THEN BEGIN
  OnBeforeBlockedCheck(ItemJnlLine,BlockedCheckIsHandled); // NEW
  //IF NOT CalledFromAdjustment THEN // OLD
  IF NOT CalledFromAdjustment AND NOT BlockedCheckIsHandled THEN // NEW
    Item.TESTFIELD(Blocked,FALSE);
  Item.CheckBlockedByApplWorksheet;
END;

With a new event definition:
LOCAL [IntegrationEvent] OnBeforeBlockedCheck(VAR ItemJnlLine : Record "Item Journal Line";VAR BlockedCheckIsHandled : Boolean)

--- EDIT ---
Just realised another change will be necessary. This time to function PrepareItem. The PrepareItem function will need to be something like this:
LOCAL PrepareItem(VAR ItemJnlLineToPost : Record "Item Journal Line")
ItemJnlLine.COPY(ItemJnlLineToPost);

GetGLSetup;
GetInvtSetup;
OnBeforeCheckItem(ItemJnlLineToPost,IsHandled); // NEW
IF NOT IsHandled then // NEW
CheckItem(ItemJnlLineToPost."Item No.");

OnAfterPrepareItem(ItemJnlLineToPost);

With a new event definition:
LOCAL [IntegrationEvent] OnBeforeCheckItem(VAR ItemJnlLine : Record "Item Journal Line", VAR IsHandled)

Look at latest version, this is already fixed

Look at latest version, this is already fixed

Thanks Alexander. I am now looking at version 14.0.35570.
I can see that the code in PostItem has changed a little, but not quite what I need. This:
Item.TESTFIELD(Blocked,FALSE);

has been replaced with:
DisplayErrorIfItemIsBlocked(Item);

and DisplayErrorIfItemIsBlocked gives me no ability to handle the error.
So I guess if the function DisplayErrorIfItemIsBlocked  in table 83 gave me the ability to handle it (and prevent the rest of the function being run), that would solve my problem.
Nothing has changed for the PrepareItem function though.


First cut at request_update

Fixes #1073. This version is largely for discussion, as it hasn't been
tested at all.

This does now work for e.g Tabs in my binding-scroll branch


⚠ Bofrost.be has degraded performance

In fccc440, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2363 ms

Resolved: Bofrost.be performance has improved in 4b47580.


Blockmeter runs on 1.20.4, but crashes under unknown condition.

Minecraft version: 1.20.4
Blockmeter version: 1.11.0 (1.20.2 Fabric)
I was running Blockmeter on the latest 1.20 version (1.20.4). The mod does load fine and had no issues with it at first. I had two different colour measurements going at the same time, when my game suddenly crashes. I have included the game log when it happened.
Crash Log:
crash-2024-01-03_20.07.34-client.txt

fixed in version https://github.com/ModProg/BlockMeter/releases/tag/v1.12.0


[test] Disable inherits_NSObject.swift on watchOS.

This was failing alongside inherits_ObjCClasses.swift (they were failing at the
same time).
Until MikeA has time to look at this disable this as well.
rdar://problem/50898688

The original: #24962.


WeChat QR expired

二维码过期了，方便更新一下吗，谢谢。

@ZhuZean I will entirely update this repository, please wait for some time.


Create new OpenSearch domain with our preferred config and migrate indices to it

@amywieliczka @bibliotechy OK, I created a new rikolti OpenSearch domain (named rikolti-2) with the following configuration changes compared to the old domain:

6 data nodes
node type or1.medium.search
2 availability zones

Other things done:

created OpenSearch roles and users for the new domain
updated the rikolti index template to specify the number of replicas as 1
updated the rikolti code to change the default number of retained indices to 0
modified startup.sh for our MWAA environment to set INDEX_RETENTION=0

I then copied the 852 indices aliased to rikolti-stg from the old domain to the new domain.
We have 1759 shards in the new rikolti-2 domain (an improvement over 3000!).
I updated the configuration for the https://calisphere-stage.cdlib.org ElasticBeanstalk to point to the new OpenSearch endpoint: https://search-rikolti-2-xxbcriyfw5iqysaj7p3fhhscae.us-west-2.es.amazonaws.com
Related PRS (which I went ahead and merged in):
https://github.com/cdlib/pad-rikolti-deploy/pull/6/files
https://github.com/ucldc/rikolti/pull/912
Here's a PR with the script I wrote that does the migration: https://github.com/ucldc/rikolti/pull/914 . The rikolti repo seems like a good place to store things like this?
If you can QA/sanity check things, then once things look good, all we need to do is update startup.sh to set RIKOLTI_ES_ENDPOINT to the new endpoint, and harvesting can recommence.

All done. We should be able to add new collection indices to OpenSearch now.


Get rid of old Clickhouse legacy?

@lomik Do you think it's time to change the following:

Convert table creation SQL to a new CH format?
Remove the unneeded Date column from graphite_tree table? Recent CH allows to specify arbitrary primary key.
Rename Timestamp to Version in series table? To avoid confusion.

I can provide patches if it's feasible.

Yes, it seems it is already possible to remove support of very old CH versions.

@lomik Good, I've started the cleanup, will do a PR.
One more question: Deleted column.
Is it used anywhere? carbon-clickhouse does not seem to write or update it and graphite-clickhouse only checks if it is = 0 in a number of queries.
Maybe we should drop it from both of them and from tables?

I think that Deleted was no longer needed after release of ALTER TABLE DELETE

Ok, then we can drop it safely probably from both daemons.

@lomik BTW If I'm reading CH docs correctly we need to have a DateTime column for GraphiteMergeTree table engine, but now we have uint32 for it with unix timestamp.
Although Clickhouse seem to work fine with it maybe we need to move to the documented structure, what do you think?

May be problem in documentation
Graphouse is using uint32 too https://github.com/yandex/graphouse/blob/master/doc/install.md
I know another problem with documentation https://github.com/yandex/ClickHouse/issues/1960

@lomik It looks like that DateTime type is just a representation of uint32 column type (CH does not have a separate column type for Dates). So CH does not care for the data type, it just treats it as UNIX timestamp under the hood anyway.
So docs are right, they just don't state that uint's will work too.